Teoria Bases Datos II (1)

Teoría de Bases de Datos II 1 UCENM

Teoría Bases Datos II

Universidad Cristiana Evangélica Nuevo Milenio

(UCENM)

Impresión Offset:

Corporación Nuevo Milenio (C.N.M.) Tel 2552-4100

E-mail:[email protected]

Primera Impresión:

Tegucigalpa M.D.C., Junio, 2011


INDICE

Capítulo I ………………………… 3- 41 1. Consultas

Conceptos de consultas.

Tipos de Consultas en bases de datos.

Consultas simple y complejas.

Algebra Relacional.

Comandos de Consulta.

Ejemplos de consultas.

Capítulo II ……………………… 42- 73 2. Transacciones.

Introducción a las Transacciones.

Propiedades de la Transacciones.

Gestión de Transacciones.

Instrucciones para uso de Transacciones.

Técnicas para implantación de Transacciones.

Protocolos de Compromisos.

Estructura de Transacciones.

Proceso de Transacciones.

Transacciones en sistemas Distribuidos.

Ejemplo tipo de Transacciones Distribuidas.

Capítulo III ……………………….74-100 3. Concurrencia

El control de Concurrencia

Principales algoritmos

Algoritmo de cerradura o candado.

Control común en sistema de archivo.

Prevención de Abrazo Mortales.

Introducción a la concurrencia ADO.NET

Concurrencia en base de datos

Ejemplos de concurrencia.


Capítulo IV …………………….…101- 155

4. Bases de Datos Distribuidas.

Introducción a Bases de Datos Distribuidas.

Administracion de una DDBMS

Cuadro de Ventajas y Desventajas bases datos distribuidas.

Configuraciones Principales.

Transparencia y Autonomía.

Diseño de base datos distribuidas.

Tipos de Fragmentación.

Tres entrada necesarias para desarrollo de fragmentación.

Fragmentación Mixta o Hibrida.

Tipos Bases datos Distribuidas.

Cuatro Metas de un DBMS Distribuidas.

Capitulo V ………………………156- 195 5. Base de Datos Paralelas.

Introducción a base datos paralela.

Paralelismo entre consulta.

Paralelismo entre Operaciones.

Ordenación entre Operaciones.

Eliminación de Duplicados.

Costos de evaluación en paralelo de operaciones.

Diseño de sistema Paralelos en base datos GRID.

Claves en seguridad GRID.

Gestión de Claves.

Criptografía de clave pública.

Integración de base datos de un sistema GRID.

Metadatos en base de Datos Sistema GRID.

Procesamiento Paralelo.


CONSULTAS

Objetivos del capítulo I

1. Comprender y analizar el concepto consultas en Base

……….....de Datos.

2. Conocer los tipos de esquemas en consulta.

3. Conocer las consultas simple y complejas.

4. Comprender la Algebra Relacional.

5. Conocer los Comandos de Consultas.


Introducción a las Consultas de Base de Datos

En bases de datos, una consulta es el método para acceder a los datos en las

bases de datos.

Con las consultas se puede modificar, borrar, mostrar y agregar datos en una

base de datos. Para esto se utiliza un lenguaje de consultas. El lenguaje de

consultas a base de datos más utilizado es el SQL.

Técnicamente hablando, las consultas a la base de datos se realizan a través

de un lenguaje de manipulación de datos (DML – Data Manipulation Language).

SQL es un lenguaje DML, pero además posee otras características de otros

lenguajes. Por ejemplo, permite también crear bases de datos.

Un esquema es un conjunto lógico de tablas, como la base de datos.

Usualmente, se piensa en él simplemente como “la base de datos”, pero una

base de datos puede contener más de un esquema. Por ejemplo, un esquema

estrella está compuesto de tablas, donde una gran y central tabla tiene toda la

información importante, con la que se accede, vía claves ajenas, a tablas

dimensionales, las cuales tienen información de detalle, y pueden ser usadas

en una unión para crear informes detallados.

Un esquema en estrella es aquel que tiene una tabla facturas de hechos que

contiene los datos de análisis, rodeada de las tablas lookup o de dimensiones.

Este aspecto, de tabla de hechos (o central) más grande rodeada de radios o

tablas más pequeñas es lo que asemeja con una estrella.

Una tabla facturas o tabla de hechos es la tabla central de un esquema

dimensional y contiene los valores de las medidas de negocio. Cada medida se

toma mediante la intersección de las dimensiones que la definen.

Este esquema es ideal por su simplicidad y velocidad para ser usado para

análisis: Data Marts? (Mercado de datos) y EIS (Sistemas de información

ejecutiva).

http://www.alegsa.com.ar/Dic/base%20de%20datos.php

http://www.alegsa.com.ar/Dic/sql.php

http://www.mitecnologico.com/Main/DataMarts?action=edit

http://www.mitecnologico.com/Main/DataMarts?action=edit


Permite acceder tanto a datos agregados como de detalle.

Además, permite reducir el número de joins entre tablas y deja a los usuarios

establecer jerarquías y niveles entre las dimensiones.

Finalmente, es la opción con mejor rendimiento y velocidad pues permite

indexar las dimensiones de forma individualizada sin que repercuta en el

rendimiento de la base de datos en su conjunto.

Tipos de Esquemas

Esquema en estrella:

Consiste en estructurar la información en procesos, vistas y métricas

recordando a una estrella (por ello el nombre star schema).

Es decir, tendremos una visión multidimensional de un proceso que

medimos a través de unas métricas. A nivel de diseño, consiste en una

tabla de hechos (lo que en los libros encontraremos como fact table) en

el centro para el hecho objeto de análisis y una o varias tablas de

dimensión (dimensión table) por cada dimensión de análisis que

participa de la descripción de ese hecho.

En la tabla de hecho encontramos los atributos destinados a medir

(cuantificar) el hecho: sus métricas. Mientras, en las tablas de

dimensión, los atributos se destinan a elementos de nivel (que

representan los distintos niveles de las jerarquías de dimensión) y a

atributos de dimensión (encargados de la descripción de estos

elementos de nivel). En el esquema en estrella la tabla de hechos es la

única tabla del esquema que tiene múltiples joins que la conectan con

otras tablas (foreign keys hacia otras tablas).

El resto de tablas del esquema (tablas de dimensión) únicamente hacen

join con esta tabla de hechos.


Las tablas de dimensión se encuentran además totalmente

denormalizadas, es decir, toda la información referente a una dimensión

se almacena en la misma tabla.

Esquema en copo de nieve (snowflake schema):

El esquema en copo de nieve (snowflake schema) es un esquema de

representación derivado del esquema en estrella, en el que las tablas de

dimensión se normalizan en múltiples tablas.

Por esta razón, la tabla de hechos deja de ser la única tabla del

esquema que se relaciona con otras tablas, y aparecen nuevas joins

gracias a que las dimensiones de análisis se representan ahora en tablas

de dimensión normalizadas. En la estructura dimensional normalizada, la

tabla que representa el nivel base de la dimensión es la que hace join

directamente con la tabla de hechos.

Diferencia entre ambos Esquemas.

La diferencia entre ambos esquemas (star y snowflake) reside entonces

en la estructura de las tablas de dimensión. Para conseguir un esquema

en copo de nieve se ha de tomar un esquema en estrella y conservar la

tabla de hechos, centrándose únicamente en el modelado de las tablas

de dimensión, que si bien en el esquema en estrella se encontraban

totalmente denormalizadas, ahora se dividen en subtablas tras un

proceso de normalización. Es posible distinguir dos tipos de esquemas

en copo de nieve, un snowflake completo (en el que todas las tablas de

dimensión en el esquema en estrella aparecen ahora normalizadas en el

snowflake) o un snowflake parcial (sólo se lleva a cabo la normalización

de algunas de ellas).


Esquema de relación y esquema relacional

En un esquema de relación debemos especificar los atributos y dominios sobre

los que se define la relación, así como las restricciones de integridad que se

deben cumplir para que la relación constituya una ocurrencia válida del

esquema; es decir, aquellas restricciones que afectan a cada uno de los

elementos que forman parte del correspondiente esquema de relación

(restricciones intraelementos).

Por tanto, podremos definir un esquema de relación como:

R <A:D, S>

Siendo R el nombre de la relación, A la lista de atributos, D los dominios sobre

los que están definidos los atributos y S las restricciones de integridad,

intraelementos.

El esquema de la base de datos relacional será una colección de esquemas de

relación y de restricciones de integridad ínter elementos. Esto se puede

representar:

E < {Ri}, {Ii}>

Donde E es el nombre del esquema relacional, {Ri} es el conjunto de esquemas

de relación, e {Ii} representa el conjunto de restricciones de integridad ínter

elementos.

Podemos definir una base de datos relacional –“variable relacional” siguiendo la

terminología de DATE (1995) –como un esquema relacional junto con una

ocurrencia válida de dicho esquema, es decir, una ocurrencia que cumple todas

las restricciones descritas en el esquema.

La creación de esquemas se lleva a cabo mediante la sentencia:

<Definición de esquemas>::=

CREATE SCHEMA <cláusula de nombre del esquema>


[<Especificación del conjunto de caracteres del esquema>]

[<Elementos de esquemas>…]

<Cláusula de nombre del esquema> ::=

<Nombre del esquema>

| AUTHORIZATION <id. Autorización del esquema›

| <Nombre del esquema› AUTHORIZATION <id. Autorización

Del esquema>

Podríamos, por ejemplo, crear el siguiente esquema:

CREATE SCHEMA biblioteca

AUTHORIZATION uc3m;

Diferencia entre una simple consulta de fila y una múltiple consulta de filas

Primero, para cubrir lo obvio, una consulta de una sólo fila es una consulta que

sólo devuelve una fila como resultado, y una consulta de múltiples filas es una

consulta que devuelve más de una fila como resultado. Si una consulta

devuelve una fila o más esto depende enteramente del diseño (o esquema) de

las tablas de la base de datos. Como escritor de consultas, debes conocer el

esquema, estar seguro de incluir todas las condiciones, y estructurar tu

sentencia SQL apropiadamente, de forma que consigas el resultado deseado

(aunque sea una o múltiples filas). Por ejemplo, si quieres estar seguro que una

consulta de la tabla Propietarios _ antigüedades devuelve sólo una fila,

considera una condición de igualdad de la columna de la clave primaria, ID _

propietario. Tres razones vienen inmediatamente a la mente de por qué esto es

importante. Primero, tener múltiples filas cuando tú sólo esperabas una, o

viceversa, puede significar que la consulta es errónea, que la base de datos

está incompleta, o simplemente, has aprendido algo nuevo sobre tus datos.


Segundo, se estás usando una sentencia Update o Delete, debes de estar

seguro que la sentencia que estás escribiendo va a hacer la operación en la fila

(o filas) que tú quieres… o sino, estarás borrando o actualizando más filas de

las que querías. Tercero, cualquier consulta escrita en SQL embebido debe

necesitar ser construida para completar el programa lógico requerido. Si su

consulta, por otra parte, devuelve múltiples filas, deberás usar la sentencia

Fetch, y muy probablemente, algún tipo de estructura de bucle para el

procesamiento iterativo de las filas devueltas por la consulta.

¿Hay algún filtro en general que pueda usar para hacer mis consultas SQL y

bases de datos mejores y más rápidas (optimizadas)?

Puedes intentar, si puedes, evitar expresiones en Selects, tales como SELECT

Columna A + Columna B, etc. La consulta optimizada de la base de datos, la

porción de la DBMS que determina el mejor camino para conseguir los datos

deseados fuera de la base de datos, tiene expresiones de tal forma que puede

requerir más tiempo recuperar los datos que si las columnas fueran

seleccionadas de forma normal, y las expresiones se manejaran

programáticamente.

Si estas usando una unión, trata de tener las columnas unidas por

índices (desde ambas tablas).

Cuando tengas dudas, índice.

A no ser que tengas múltiples cuentas o consultas complejas, usa

COUNT (*) (el número de filas generadas por la consulta) mejor que

COUNT (Nombre _ columna).

Escribiendo y Editando Consultas Manualmente

La tarea realizada más común con el MySQL Query Browser es ejecutar

consultas y analizar sus resultados. La manera más directa de crear consultas

es escribirlas directamente sobre el área de consultas.

http://www.mitecnologico.com/Main/ColumnaA


Con forme se va escribiendo en el área de resultados, las porciones de sintaxis

de SQL (SELECT, FROM, WHERE, etc.) se van resaltando en azul.

Una vez que se escriba la consulta, el área de consultas se expandirá desde

tres líneas iníciales de altura a un máximo de diez líneas de altura. Para

espacio adicional, usted puede presionar la tecla F11 para maximizar el área

de consultas. También puede seleccionar la opción Maximizar Área de

Consulta de el menú Ver para maximizar el área de consultas. Cuando una

consulta es maximizada, el número de líneas es desplegado para la consulta, y

el área de consulta puede ser redimensionada haciendo click y arrastrando la

línea que divide el área de consulta con el área de resultado. Para restablecer

el área de consultas, presione nuevamente la tecla F11.

Una vez que capturada la consulta, dar un click en el botón Ejecutar y los

resultados de la consulta serán desplegados en el área de resultados. Usted

puede también presionar las teclas ctrl.+ Aceptar para ejecutar la consulta. Si

hay algún error en su consulta un área de errores aparecerá en la parte de

abajo de el área de resultados desplegando el mensaje de error y el código del

error.

En adición para cargar resultados de consultas en el área de resultados activa,

usted puede también crear una nueva área de resultado para los resultados de

su consulta o dividir su área de resultado actual y cargar los resultados dentro

de la nueva sección.

Para ejecutar una consulta y cargar los resultados en un área de resultados

nueva click en la flecha hacia abajo en la parte baja del botón Ejecutar y escoja

la opción Ejecutar en nueva Pestaña o presione las teclas ctrl.+Shift+Aceptar.

Para dividir el área de resultado activa y desplegar los resultados de la consulta

dar click en la flecha hacia abajo en la parte baja del botón Ejecutar y escoja la

opción Dividir Pestaña y Ejecutar o presione las teclas ctrl.+Alt+Enter.


Usted debe establecer una base de datos por defecto antes de que usted

pueda consultar la base de datos satisfactoriamente. Puede establecer la base

de datos por defecto en la pantalla de conexión, o click-derecho en la base de

datos en el navegador de base de datos y eligiendo la opción Hacer Esquema

por Defecto, o eligiendo la opción Cambiar el esquema por defecto del menú

Archivo.

Editando Consultas desde una Herramienta de Desarrollo

En orden de ayudar a programadores a optimizar y depurar sus consultas más

eficientemente, el MySQL Query Browser puede copiar consultas desde el

código de aplicaciones usando su entorno (IDE) favorito.

Esta funcionalidad está solamente disponible para la versión de MySQL Query

Browser para Windows.

El siguiente código PHP será usado como ejemplo:

$SQL = “SELECT Id, Name, Country FROM City” .

“WHERE Name LIKE $cityname”;

Para copiar la consulta dentro de el MySQL Query Browser, copie el bloque de

código (incluyendo la porción de asignación), click derecho dentro del área de

consultas del MySQL Query Browser, y elegir la opción Pegar Contenido del

portapapeles como código PHP. Las porciones que no son consulta serán

removidas y la consulta será pegada dentro del área de consultas.

Los elementos dinámicos de la consulta son convertidos en parámetros locales,

visibles en el navegador de parámetros:

SELECT Id, Name, Country FROM City

WHERE Name LIKE: cityname


Para establecer un valor a un parámetro local, seleccione el valor en el

navegador de parámetros y presione F2. Usted también puede dar doble-click

sobre el valor para editarlo. El valor que asigne será usado cuando la consulta

sea ejecutada.

Después de editar una consulta, click-derecho dentro del área de consultas y

elegir la opción Copiar Consulta Como Código PHP. El código PHP que

corresponde será re-insertado junto con la consulta modificada. Esta

funcionalidad permite editar consultas rápidamente mientras programa.

Consultas Simples.

Empezaremos por estudiar la sentencia SELECT, que permite recuperar

datos de una o varias tablas. La sentencia SELECT es con mucho la más

compleja y potente de las sentencias SQL. Empezaremos por ver las

consultas más simples, basadas en una sola tabla.

Esta sentencia forma parte del DML (lenguaje de manipulación de datos),

en este tema veremos cómo seleccionar columnas de una tabla, cómo

seleccionar filas y cómo obtener las filas ordenadas por el criterio que

queramos.

El resultado de la consulta es una tabla lógica, porque no se guarda en el

disco sino que está en memoria y cada vez que ejecutamos la consulta se

vuelve a calcular.

Cuando ejecutamos la consulta se visualiza el resultado en forma de tabla

con columnas y filas, pues en la SELECT tenemos que indicar qué

columnas queremos que tenga el resultado y qué filas queremos

seleccionar de la tabla origen.


Si no conoces todavía las tablas que utilizaremos para los ejemplos y

ejercicios clic aquí

Sintaxis de la sentencia SELECT (consultas

simples)

La tabla origen - FROM -

Con la cláusula FROM indicamos en qué tabla tiene que buscar la

información. En este capítulo de consultas simples el resultado se

obtiene de una única tabla. La sintaxis de la cláusula es:

FROM especificación de tabla

Una especificación de tabla puede ser el nombre de una consulta

guardada (las que aparecen en la ventana de base de datos), o

el nombre de una tabla que a su vez puede tener el siguiente

formato:

http://www.aulaclic.es/sql/t_1_2.htm


Aliastabla es un nombre de alias, es como un segundo nombre que

asignamos a la tabla, si en una consulta definimos un alias para la tabla,

esta se deberá nombrar utilizando ese nombre y no su nombre real,

además ese nombre sólo es válido en la consulta donde se define. El alias

se suele emplear en consultas basadas en más de una tabla que veremos

en el tema siguiente. La palabra AS que se puede poner delante del nombre

de alias es opcional y es el valor por defecto por lo que no tienen ningún

efecto.

Ejemplo: SELECT ......FROM oficinas ofi ; equivalente a SELECT ......FROM

oficinas AS ofi esta sentencia me indica que se van a buscar los datos en la

tabla oficinas que queda renombrada en esta consulta con ofi.

En una SELECT podemos utilizar tablas que no están definidas en la base

de datos (siempre que tengamos los permisos adecuados claro), si la tabla

no está en la base de datos activa, debemos indicar en qué base de datos

se encuentra con la cláusula IN.

En la cláusula IN el nombre de la base de datos debe incluir el camino

completo, la extensión (.mdb), y estar entre comillas simples.

Supongamos que la tabla empleados estuviese en otra base de datos

llamada otra en la carpeta c:\mis documentos\, habría que indicarlo así:

SELECT *FROM empleados IN 'c:\mis documentos\otra.mdb'

Generalmente tenemos las tablas en la misma base de datos y no hay que

utilizar la cláusula IN.

Selección de columnas

La lista de columnas que queremos que aparezcan en el resultado es lo

que llamamos lista de selección y se especifica delante de la cláusula


FROM.

Utilización del *

Se utiliza el asterisco * en la lista de selección para indicar 'todas las

columnas de la tabla'.

Tiene dos ventajas:

Evitar nombrar las columnas una a una (es más corto).

Si añadimos una columna nueva en la tabla, esta nueva columna saldrá sin

tener que modificar la consulta.

Se puede combinar el * con el nombre de una tabla (ej. oficinas.*), pero esto

se utiliza más cuando el origen de la consulta son dos tablas.

SELECT * FROM oficinas

o bien

SELECT oficinas.* FROM

oficinas

Lista todos los datos de las oficinas

Columnas de la tabla origen

Las columnas se pueden especificar mediante su nombre simple (nbcol) o

su nombre cualificado (nbtabla.nbcol, el nombre de la columna precedido

del nombre de la tabla que contiene la columna y separados por un punto).

El nombre cualificado se puede emplear siempre que queramos y es

obligatorio en algunos casos que veremos más adelante.

Cuando el nombre de la columna o de la tabla contiene espacios en blanco,

hay que poner el nombre entre corchetes [ ] y además el número de

espacios en blanco debe coincidir.


Por ejemplo [codigo de cliente] no es lo mismo que [ código de cliente] (el

segundo lleva un espacio en blanco delante de código)

Ejemplos :

SELECT nombre, oficina,

contrato

FROM ofiventas

Lista el nombre, oficina, y fecha de

contrato de todos los empleados.

SELECT idfab, idproducto,

descripción, precio

FROM productos

Lista una tarifa de productos

Alias de columna.

Cuando se visualiza el resultado de la consulta, normalmente las columnas

toman el nombre que tiene la columna en la tabla, si queremos cambiar ese

nombre lo podemos hacer definiendo un alias de columna mediante la

cláusula AS será el nombre que aparecerá como título de la columna.

Ejemplo:

SELECT idfab AS fabricante,

idproducto, descripción

FROM productos

..Como título de la primera columna

….aparecerá fabricante en vez de idfab

Columnas calculadas.

Además de las columnas que provienen directamente de la tabla origen,

una consulta SQL puede incluir columnas calculadas cuyos valores se

calculan a partir de los valores de los datos almacenados.

Para solicitar una columna calculada, se especifica en la lista de selección

una expresión en vez de un nombre de columna. La expresión puede

contener sumas, restas, multiplicaciones y divisiones, concatenación & ,

paréntesis y también funciones predefinidas).


Para ver con más detalle cómo formar una expresión pincha aquí

Ejemplos:

SELECT ciudad, región, (ventas-

objetivo) AS superávit

FROM oficinas

Lista la ciudad, región y el superávit

de cada oficina.

SELECT idfab, idproducto, descripción,

(existencias * precio) AS valoración

FROM productos

De cada producto obtiene su

fabricante, idproducto, su

descripción y el valor del

inventario

SELECT nombre, MONTH(contrato),

YEAR(contrato)

FROM repventas

Lista el nombre, mes y año del

contrato de cada vendedor.

La función MONTH() devuelve el

mes de una fecha

La función YEAR() devuelve el año

de una fecha

SELECT oficina, 'tiene

ventas de ', ventas

FROM oficinas

Listar las ventas en cada oficina con el

formato: 22 tiene ventas de 186,042.00 lps

Consultas complejas

Uno de los temas que más cuesta a los que empiezan a aprender SQL son las

consultas en las que se recogen diferentes tipos de datos de una ó múltiples

tablas. Este artículo es una introducción a cómo definir consultas de este tipo

en PostgreSQL.

Unos conocimientos básicos de normalización de datos y un poco de álgebra

relacional no vienen mal para entender mejor algunos de los términos que

vamos a usar en este artículo.


La normalización de datos es tema para otro artículo, pero en este veremos

brevemente algunos conceptos de álgebra relacional que nos pueden ayudar a

entender mejor el tema que estamos tratando.

Algebra relacional

El álgebra relacional es un tipo de álgebra con una serie de operadores que

trabajan sobre una ó varias relaciones para obtener una relación resultado. Es

la base indispensable para poder escribir buenas consultas en SQL.

Las operaciones más importantes disponibles en álgebra relacional son:

Las operaciones de conjunto aplicadas a relaciones: unión(∪),

intersección(∩) y diferencia(-)

Operaciones que eliminan una parte de las relaciones:

selección(σ) y proyección(Π)

Operaciones que combinan las duplas de dos relaciones:

producto cartesiano(x), combinación natural (><) y theta

Operación que cambia el nombre de los atributos ó relación:

renombre(ρ)

A continuación vamos a dar una breve introducción sobre estas operaciones:

Unión [R∪S]

La unión de R y S es el conjunto de elementos que existen en R, ó en S, ó en

las dos. Un elemento que existe tanto en R como en S aparece solamente una

vez en la unión. En el lenguaje SQL este tipo de operación se puede realizar

con la clausula UNION

Intersección [R∩S]

La intersección de R y S es el conjunto de elementos que existen en R y en S.

En el lenguaje SQL este tipo de operación se puede realizar con la clausula

INTERSECT

Diferencia [R-S]

La diferencia de R y S es el conjunto de elementos que existen en R pero no en

S. R-S es diferente a S-R, S-R seria el conjunto de elementos que existen en S

pero no en R. En el lenguaje SQL este tipo de operación se puede realizar con

la clausula EXCEPT


Selección [σc(R)]

Esta operación aplicada a una relación R, produce una nueva relación con un

subconjunto de duplas de R. Este subconjunto de duplas satisface y cumple

cierta condición(c)

Proyección [Πa1,a2,...,an(R)]

Esta operación aplicada a una relación R, produce una nueva relación con

solamente los atributos (columnas) especificados por a1,a2,...,an

Producto cartesiano [RxS]

El producto cartesiano de dos relaciones R y S es la relación que se obtiene de

la combinación de todas las duplas de R con todas las duplas de S. Las duplas

de la relación que se obtiene están formadas por todos los atributos de R

seguidos de todos los atributos de S. En el lenguaje SQL este tipo de operación

se puede realizar con la cláusula CROSS JOIN ó separando las relaciones

usadas en el producto con comas, en el FROM de la sentencia SQL.

Combinaciones

Por medio del operador combinación (JOIN) podemos combinar dos relaciones

según una condición para obtener duplas compuestas por atributos de las dos

relaciones combinadas.

En el lenguaje SQL existen diferentes maneras de combinar dos relaciones. A

continuación tenes un resumen de las existentes en PostgreSQL:

Combinaciones internas (R INNER JOIN S): Un INNER JOIN

entre dos relaciones R y S, es el resultado que se obtiene

después de aplicar al producto cartesiano de las dos relaciones R

y S, una condición para acotar dicho producto. Existen un par de

casos especiales:

De equivalencia (Equi-join): Es un caso particular de INNER JOIN

en el que la condición que acota el resultado es una comparación

de igualdad.

R NATURAL JOIN S: Es un caso especial de equi-join en el que

en el caso de existir columnas con el mismo nombre en las


relaciones que se combinan, solo se incluirá una de ellas en el

resultado de la combinación.

Combinaciones externas (OUTER JOINS): Un OUTER JOIN entre

dos relaciones R y S contiene todas las duplas que un INNER

JOIN devolvería, más una serie de duplas que no tienen atributos

en común en las dos relaciones. Los diferentes tipos son:

R LEFT OUTER JOIN S: Un LEFT OUTER JOIN entre dos

relaciones R y S, retorna todas las duplas de la combinación que

tengan un atributo común, más todas las duplas de la relación de

la izquierda (R) que no tengan un equivalente en la relación de la

derecha (S).

R RIGHT OUTER JOIN S: Un RIGHT OUTER JOIN entre dos



la derecha (S) que no tengan un equivalente en la relación de la

izquierda (R).

R FULL OUTER JOIN S: Un FULL OUTER JOIN entre dos



la izquierda (R) que no tenga un equivalente en la relación de la

derecha (S) y todas las duplas de la relación de la derecha (S)

que no tenga un equivalente en la relación de la izquierda (R).

Esta operación aplicada a una relación R, produce una nueva relación idéntica

a R en donde el atributo 'b' ha sido renombrado a 'a'.

El uso combinado de todas estas operaciones aplicado a nuestras relaciones

dará lugar a consultas más ó menos complejas.

Utilizando los operadores definidos en algebra relacional, podemos definir de

manera gráfica (árboles) ó lineal la representación algebraica de nuestra

consulta. En consultas muy complicadas es lo que se debería de hacer antes

de empezar a escribir el código SQL, pero este es un tema para otro artículo.


Ejemplos prácticos

Nada mejor que unos ejemplos básicos para ver como se aplica la teoría que

hemos visto. Lo primero que vamos a hacer es definir un par de tablas que

utilizaremos en nuestros ejemplos:

postgres=# SELECT * FROM relacion_r;

a | b | c

---+---+---

1 | 2 | 3

4 | 5 | 6

(2 rows)

postgres=# SELECT * FROM relacion_s;

c | d | e

---+---+---

4 | 5 | 6

7 | 8 | 9

(2 rows)

En nuestro primer ejemplo realizamos una unión de las dos relaciones, el resultado

obtenido seria:

postgres=# SELECT * FROM relacion_r UNION SELECT * FROM relacion_s;

a | b | c

---+---+---

4 | 5 | 6

1 | 2 | 3

7 | 8 | 9

(3 rows)

A continuación realizamos una intersección entre las dos relaciones:

postgres=# SELECT * FROM relacion_r INTERSECT SELECT * FROM relacion_s;

a | b | c

---+---+---

4 | 5 | 6

(1 row)


La diferencia entre estas dos relaciones daría el siguiente resultado. Como

podéis ver, y por definición, no es lo mismo la diferencia entre relación y

relacion_s, que entre relacion_s y relación

postgres=# SELECT * FROM relacion_r EXCEPT SELECT * FROM relacion_s;

a | b | c

---+---+---

1 | 2 | 3

(1 row)

postgres=# SELECT * FROM relacion_s EXCEPT SELECT * FROM relacion_r;

c | d | e

---+---+---

7 | 8 | 9

(1 row)

Vamos a definir una nueva fila (3,4,5) en la tabla relacion_s para ver unos

ejemplos de cómo combinar estas dos relaciones mediante JOINs.

postgres=# SELECT * FROM relacion_r;

a | b | c

---+---+---

1 | 2 | 3

4 | 5 | 6

(2 rows)

postgres=# SELECT * FROM relacion_s;

c | d | e

---+---+---

4 | 5 | 6

7 | 8 | 9

3 | 4 | 5

(3 rows)

La manera más simple de combinar estas dos relaciones es realizar el producto

cartesiano de ambas. Esto se puede realizar de dos maneras, ó bien definiendo

las dos relaciones separadas por comas después del FROM.

postgres=# SELECT * FROM relacion_r,relacion_s;


a | b | c | c | d | e

---+---+---+---+---+---

1 | 2 | 3 | 4 | 5 | 6

1 | 2 | 3 | 7 | 8 | 9

1 | 2 | 3 | 3 | 4 | 5

4 | 5 | 6 | 4 | 5 | 6

4 | 5 | 6 | 7 | 8 | 9

4 | 5 | 6 | 3 | 4 | 5

(6 rows)

O utilizando la cláusula CROSS JOIN entre las dos relaciones.

postgres=# SELECT * FROM relacion_r CROSS JOIN relacion_s;

a | b | c | c | d | e

---+---+---+---+---+---

1 | 2 | 3 | 4 | 5 | 6

1 | 2 | 3 | 7 | 8 | 9

1 | 2 | 3 | 3 | 4 | 5

4 | 5 | 6 | 4 | 5 | 6

4 | 5 | 6 | 7 | 8 | 9

4 | 5 | 6 | 3 | 4 | 5

(6 rows)

En realidad un CROSS JOIN es el equivalente a un INNER JOIN ON (true).

Esto porque el INNER JOIN es por definición un producto cartesiano al que se

le aplica una condición para acotar el resultado. En este caso particular la

condición siempre se cumple para todas las duplas al utilizar el valor TRUE,

con lo que obtendremos todas las duplas del producto cartesiano.


postgres=# SELECT * FROM relacion_r INNER JOIN relacion_s ON (true);

a | b | c | c | d | e

---+---+---+---+---+---

1 | 2 | 3 | 4 | 5 | 6

1 | 2 | 3 | 7 | 8 | 9

1 | 2 | 3 | 3 | 4 | 5

4 | 5 | 6 | 4 | 5 | 6

4 | 5 | 6 | 7 | 8 | 9

4 | 5 | 6 | 3 | 4 | 5

(6 rows)

A continuación podeis ver cómo definir un INNER JOIN con la condición

definida dentro de ON(). Este ejemplo es un Equi-join al utilizarse una

comparación de igualdad en la condición.

postgres=# SELECT * FROM relacion_r AS r INNER JOIN relacion_s AS s ON

(r.c = s.c);

a | b | c | c | d | e

---+---+---+---+---+---

1 | 2 | 3 | 3 | 4 | 5

(1 rows)

El mismo resultado obtenido con la clausula INNER JOIN se podría haber

conseguido obteniendo el producto cartesiano de las dos relaciones y

aplicando una condición con WHERE (definición de INNER JOIN).

postgres=# SELECT * FROM relacion_r AS r, relacion_s AS s WHERE r.c = s.c;

a | b | c | c | d | e

---+---+---+---+---+---

1 | 2 | 3 | 3 | 4 | 5

(1 rows)

postgres=# SELECT * FROM relacion_r as r CROSS JOIN relacion_s as s

WHERE r.c = s.c;

a | b | c | c | d | e

---+---+---+---+---+---

1 | 2 | 3 | 3 | 4 | 5

(1 row)


Un NATURAL JOIN retorna el mismo resultado que un equi-join, pero sin

repetir las columnas comunes.

postgres=# SELECT * from relacion_r natural join relacion_s;

c | a | b | d | e

---+---+---+---+---

3 | 1 | 2 | 4 | 5

postgres=# SELECT a,b,c,d,e from relacion_r natural join relacion_s;

a | b | c | d | e

---+---+---+---+---

1 | 2 | 3 | 4 | 5

(1 row)

Como puede ver en lo que llevamos de artículo, existen diferentes maneras de

obtener un mismo resultado utilizando diferentes tipos de consultas. Teniendo

los conceptos claros y con práctica, os aseguro que todos estos tipos de

consultas os saldrán de forma natural después de un tiempo.

A continuación vamos a ver las combinaciones de tipo OUTER JOIN. En

PostgreSQL el uso de la palabra OUTER es opcional.

La primera es un LEFT OUTER JOIN.

postgres=# SELECT * FROM relacion_r AS r LEFT OUTER JOIN relacion_s AS

s ON (r.c = s.c);

a | b | c | c | d | e

---+---+---+---+---+---

1 | 2 | 3 | 3 | 4 | 5

4 | 5 | 6 | | |

(2 rows)

Seguido de un RIGHT OUTER JOIN:

postgres=# SELECT * FROM relacion_r AS r RIGHT OUTER JOIN relacion_s

AS s ON (r.c = s.c);

a | b | c | c | d | e

---+---+---+---+---+---

1 | 2 | 3 | 3 | 4 | 5

| | | 4 | 5 | 6

| | | 7 | 8 | 9


(3 rows)

Y para terminar un FULL OUTER JOIN:

postgres=# SELECT * FROM relacion_r AS r FULL OUTER JOIN relacion_s AS

s ON (r.c = s.c);

a | b | c | c | d | e

---+---+---+---+---+---

1 | 2 | 3 | 3 | 4 | 5

| | | 4 | 5 | 6

4 | 5 | 6 | | |

| | | 7 | 8 | 9

(4 rows)

Un ejemplo casi real

Los ejemplos que hemos visto hasta ahora, nos han mostrado la sintaxis básica

de las operaciones que se pueden utilizar para obtener resultados con datos de

múltiples relaciones.

En la vida real nos encontraremos con casos muchos más complicados en los

que tendremos que combinar todas estas operaciones junto con el resto de

operadores y cláusulas SQL disponibles.

En casos complicados es importante pensar antes de empezar a escribir

nuestra consulta SQL. A continuación vamos a ver un ejemplo un poco más

complicado para ver cómo podemos desglosar y resolver la consulta que

necesitamos para obtener el resultado deseado.

Utilizaremos unas tablas creadas únicamente para este ejemplo y no

representativas de un sistema real. Tenemos una tabla principal llamada 'PC',

con diferentes columnas conteniendo cadenas de identificación de los

diferentes componentes usados para el ensamblado de diferentes modelos de

PCs.

Las columnas vacías de la tabla 'PC' significan componentes no presentes en

dichos modelos. El resto de tablas contienen información adicional sobre los

diferentes componentes usados para construir un PC.


postgres=# SELECT * FROM pc;

pcid | memoria | cpu | disco | tgrafica | precio

------+---------+---------+-----------+-----------+------------------

1 | mem0001 | cpu0001 | disco0001 | ati001 | 1000

2 | mem0001 | cpu0001 | disco0002 | ati001 | 1100

3 | mem0002 | cpu0002 | disco0003 | nvidia001 | 1400

4 | mem0004 | cpu0003 | disco0004 | nvidia001 | 1600

5 | | cpu0001 | disco0001 | ati001 | 900

6 | | | | ati001 | 400

(6 rows)

postgres=# SELECT * FROM cpu ;

cpu_id | cpu_fabricante | cpu_tipo

---------+----------------+-------------------

cpu0001 | Intel | Core2 dúo

cpu0002 | Intel | Core2 Quad

cpu0003 | AMD | Athlon X2

(3 rows)

postgres=# SELECT * FROM memoria ;

mem_id | mem_capacidad | mem_tipo

---------+---------------+------------

mem0001 | 1024 | DDR SDRAM

mem0002 | 1024 | DDR2 SDRAM



(4 rows)

postgres=# SELECT * FROM disco ;

disco_id | disco_fabricante | disco_capacidad

-----------+------------------+-----------------

disco0001 | seagate | 350



disco0004 | samsung | 500

(4 rows)


postgres=# SELECT * FROM tgrafica ;

tgraf_id | tgraf_fabricante

-----------+-----------------------

ati001 | ati

nvidia001 | nvidia

Utilizando estas tablas vamos a realizar varias consultas:

Consulta 1

Obtener una relación de solo los modelos de PC 'completos' a la venta.

Queremos toda la información disponible sobre los componentes que lo

forman. Ordenar el resultado de mayor a menor precio.

Sabemos que al tener que coger datos de diferentes tablas, necesitaremos

algún tipo de clausula JOIN.

En esta consulta nos piden solamente, PCs completos, con todos sus

componentes. Por ello descartamos todas las combinaciones de tipo OUTER

JOIN y utilizamos INNER JOIN para obtener solamente las duplas con atributos

en todas las relaciones combinadas.

Cada PC tiene 4 componentes y la información de cada componente se

encuentra en una tabla separada. Con estos datos sabemos que tendremos

que realizar 4 INNER JOIN entre todas las tablas involucradas en la consulta.

Vamos a empezar a escribir la consulta SQL. Primero realizamos los INNER

JOIN y declaramos las condiciones que acotarán el resultado. Tendremos que

emparejar los atributos de componentes presentes en la tabla 'PC' con los

correspondientes atributos en el resto de tablas de componentes.

SELECT *

FROM pc AS a

INNER JOIN memoria AS b ON (a.memoria = b.mem_id)

INNER JOIN cpu AS c ON (a.cpu = c.cpu_id)

INNER JOIN disco AS d ON (a.disco = d.disco_id)

INNER JOIN tgrafica AS e ON (a.tgrafica = e.tgraf_id);

Una vez que hemos combinado todas las tablas, vamos a definir los atributos

que queremos presentar en nuestro resultado. Utilizaremos los prefijos de


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 tgrafica AS e ON (a.tgrafica = e.tgraf_id);

Y para terminar ordenamos el resultado:

SELECT

a.pcid,

b.mem_tipo,



c.cpu_tipo,




a.precio

FROM pc AS a




INNER JOIN tgrafica AS e ON (a.tgrafica = e.tgraf_id)


Consulta 4

Obtener una relación de todos los PC que tengan CPUs de AMD y discos

Samsung. Queremos toda la información disponible sobre los componentes

que lo forman

El trabajo para definir esta consulta está casi hecho. Lo único que tenemos que

hacer es aplicar mediante la sentencia WHERE, las dos condiciones que nos

piden, a la consulta 2:

SELECT

a.pcid,

b.mem_tipo,



c.cpu_tipo,




a.precio

FROM pc AS a





WHERE c.cpu_fabricante = 'amd'

AND d.disco_fabricante = 'samsung'



Y el resultado quedaria asi:

pcid | mem_tipo | mem_mb | cpu_fab | cpu_tipo | disco_fab | disco_gb | tgraf_fab | precio

------+------------+--------+---------+-----------+-----------+----------+-----------+--------------+--------

4 | DDR3 SDRAM | 2048 | AMD | Athlon X2 | Samsung | 500 | nvidia | 1600

(1 row)

Consulta 5

Obtener una relación del número de PCs que tienen CPUs de Intel y de AMD.

Ordenar de mayor a menor.

Esta consulta es un poco diferente a las anteriores. Aquí tenemos que agrupar

los resultados según el fabricante de la CPU utilizada, y contar cuantas duplas

existen en cada grupo. Al necesitar solamente información contenida en la

tabla 'CPU', solo tendremos que combinar la tabla 'PC' con la tabla 'CPU'.

Como queremos obtener solamente los PC que tienen algún tipo de CPU,

utilizaremos un INNER JOIN para descartar los PCs sin CPU definida.

SELECT *

FROM pc AS a

INNER JOIN CPU AS b ON (a.cpu = b.cpu_id);

A continuación vamos a agrupar el resultado obtenido según el fabricante de la

CPU y contaremos el número de duplas en cada grupo:

SELECT

b.cpu_fabricante,

count(*) AS total

FROM pc AS a

INNER JOIN cpu AS b ON (a.cpu = b.cpu_id)

GROUP BY b.cpu_fabricante;

Y ordenamos el resultado:

SELECT

b.cpu_fabricante,

count(*) AS total

FROM pc AS a

INNER JOIN cpu AS b ON (a.cpu = b.cpu_id)

GROUP BY b.cpu_fabricante

ORDER BY total DESC;


El resultado obtenido seria:

cpu_fabricante | total

----------------+------------

intel | 4

Amd | 1

(2 rows)

En fin, espero que tenga una idea de cómo funciona el tema de combinar

diferentes tablas para obtener un resultado.

En la vida real os encontrareis con ejemplos bastantes complicados, lo

importante es pensar la estrategia a seguir antes de empezar a escribir la

consulta SQL.

También es importante hacerlo paso a paso, aplicando las restricciones

necesarias hasta conseguir lo que queremos.

TIPOS DE COMANDOS DE CONSULTAS:

Una consulta de comandos aporta modificaciones a muchos registros con una

única operación. Existen cuatro tipos de consultas de comando

Eliminación, de Actualización, de Alineación y de Creación de Tablas y

parámetros.

1. Consultas de eliminación:

Este tipo de consulta elimina un grupo de registros de una o más tablas.

Existe la posibilidad, por ejemplo, de utilizar una consulta de eliminación para

reemplazar los productos que se han dejado de producir o para aquellos sobre

los cuales no existen pedidos. Con las consultas de eliminación siempre se

eliminan registros internos y no únicamente determinados campos de su

interior.

2. Consultas de actualización:

Este tipo aporta modificaciones globales a uno o más tablas.

Existe la posibilidad, por ejemplo, de aumentar en un 10 por ciento el precio de

todos los productos lácteos o aumentar los salarios en un 5 por ciento a las

personas pertenecientes a una determinada categoría laboral.


3. Consultas de alineación:

Estas consultas agregan un grupo de registros de una o más tablas al final de

una o más tablas. Supongamos, por ejemplo, que se han conseguido nuevos

clientes y existe una base de datos que contiene una tabla de información

sobre estos. En vez de teclear nuevamente todas estas informaciones, se

alinean en la tabla correspondiente de Clientes.

4. Consultas de creación de tablas:

Este tipo de consultas crea una nueva tabla basándose en todos los datos o

parte de estos existentes en una o más tablas.

5. Consultas de parámetros:

Una consulta de parámetros es una consulta que, cuando se ejecuta, muestra

una ventana de diálogo que solicita informaciones, como por ejemplo criterios

para recuperar registros o un valor que se desea insertar en un campo.

Otros tipos de consultas

Los campos calculados

Un campo de este tipo es aquél que no existe en la tabla y que se crea sólo

temporalmente dentro de una columna en la consulta para realizar algún tipo

de operación matemática.

Consulta sueldo 1.

Las formulas o expresiones a poner en cada columna de la vista de diseño de

la consulta son

Columna Expresión

1 Salario

2 Bonificación: salario* 5/100

3 Bruto: Salario+ Bonificación

4 Retención: Bruto* 8/100

5 Neto: Bruto – Retención

6 NombVen

Para introducir los valores en las columnas utilizaremos el generador de

expresiones, y de esta forma nos

Aseguramos de que se utilice la sintaxis correcta.


Según lo que acabamos de ver podemos utilizar las consultas para realizar

cálculos de cualquier tipo, utilizando

Nuestras propias expresiones con operadores más o menos sencillos, así

como con las funciones y operadores que trae Access.

Funciones de grupo No obstante en muchas ocasiones necesitaremos realizar

cálculos que involucren los datos contenidos en varias cada una de sus filas

contiene los datos de un único cliente, parece evidente que lo único que hay

que hacer es.

Contar las filas.

Para resolver este tipo de situaciones en las que hay que hacer cálculos

utilizando grupos de filas los gestores

de bases de datos en general disponen de varias funciones especiales que se

llaman funciones funciones agregadas. Estas funciones en Access son: de

grupo o

Función Descripción Cuenta Para contar el número de filas del grupo

Suma Para sumar el contenido del campo especificado de todas las filas del

grupo

Promedio Para hallar la media aritmética del campo especificado de todas las

filas del grupo

Mín Para hallar el menor valor del campo especificado de todas las filas del

grupo

Máx Para hallar el mayor valor del campo especificado de todas las filas del

grupo

DesvEst Para hallar la desviación típica del campo especificado de todas las

filas del grupo.


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.


7-.¿ Que significado tiene el símbolo del asterico(*) en consultas ?

8-. ¿Qué es la Algebra relacional?

9-. ¿Qué tipo de combinaciones existen en SQL para realizar consultas?

10-.¿ Caules son los tipos de comandos de consulta?

10-. Analize el ejemplo de consulta No 2,de la pagina 32.


TRANSACCIONES

Objetivos del capítulo II

1 .Comprender y analizar el concepto de Transacciones.

2 .Conocer las propiedades de las transacciones.

3 .Conocer las técnicas de Implantación.

4 .Comprender las estructuras de transacciones.

5 .Comprender los ejemplos de transacciones.


INTRODUCCION A TRANSACCIONES DE BASE DE DATOS.

Una transacción en un Sistema de Gestión de Bases de Datos (SGBD), es un

conjunto de órdenes que se ejecutan formando una unidad de trabajo, es decir,

en forma indivisible o atómica.

Un SGBD se dice transaccional, si es capaz de mantener la integridad de los

datos, haciendo que estas transacciones no puedan finalizar en un estado

intermedio. Cuando por alguna causa el sistema debe cancelar la transacción,

empieza a deshacer las órdenes ejecutadas hasta dejar la base de datos en su

estado inicial (llamado punto de integridad), como si la orden de la transacción

nunca se hubiese realizado.

Para esto, el lenguaje de consulta de datos SQL (Structured Query Language),

provee los mecanismos para especificar que un conjunto de acciones deben

constituir una transacción.

BEGIN TRAN: Especifica que va a empezar una transacción.

COMMIT TRAN: Le indica al motor que puede considerar la transacción

completada con éxito.

ROLLBACK TRAN: Indica que se ha alcanzado un fallo y que debe

restablecer la base al punto de integridad.

En un sistema ideal, las transacciones deberían garantizar todas las

propiedades ACID; en la práctica, a veces alguna de estas propiedades se

simplifica o debilita con vistas a obtener un mejor rendimiento.

Un ejemplo de transacción

Un ejemplo habitual de transacción es el traspaso de una cantidad de dinero

entre cuentas bancarias. Normalmente se realiza mediante dos operaciones

distintas, una en la que se decrementa el saldo de la cuenta origen y otra en la

que incrementamos el saldo de la cuenta destino.

http://es.wikipedia.org/wiki/SGBD

http://es.wikipedia.org/wiki/SGBD

http://es.wikipedia.org/wiki/SQL

http://es.wikipedia.org/wiki/ACID


Para garantizar la atomicidad del sistema (es decir, para que no aparezca o

desaparezca dinero), las dos operaciones deben ser atómicas, es decir, el

sistema debe garantizar que, bajo cualquier circunstancia (incluso una caída

del sistema), el resultado final es que, o bien se han realizado las dos

operaciones, o bien no se ha realizado ninguna.

Una transacción es una secuencia de operaciones realizadas como una sola

unidad lógica de trabajo. Una unidad lógica de trabajo debe exhibir cuatro

propiedades, conocidas como propiedades de atomicidad, coherencia,

aislamiento y durabilidad (ACID), para ser calificada como transacción.

PROPIEDADES DE TRANSACCIONES.

Atomicidad

Una transacción debe ser una unidad atómica de trabajo, tanto si se

realizan todas sus modificaciones en los datos, como si no se realiza

ninguna de ellas.

Coherencia

Cuando finaliza, una transacción debe dejar todos los datos en un

estado coherente. En una base de datos relacional, se deben aplicar

todas las reglas a las modificaciones de la transacción para mantener la

integridad de todos los datos. Todas las estructuras internas de datos,

como índices de árbol b o listas doblemente vinculadas, deben estar

correctas al final de la transacción.

Aislamiento

Las modificaciones realizadas por transacciones simultáneas se deben

aislar de las modificaciones llevadas a cabo por otras transacciones

simultáneas.


Una transacción reconoce los datos en el estado en que estaban antes

de que otra transacción simultánea los modificara o después de que la

segunda transacción haya concluido, pero no reconoce un estado

intermedio. Esto se conoce como seriabilidad, ya que deriva en la

capacidad de volver a cargar los datos iníciales y reproducir una serie de

transacciones para finalizar con los datos en el mismo estado en que

estaban después de realizar las transacciones originales.

Durabilidad

Una vez concluida una transacción, sus efectos son permanentes en el

sistema. Las modificaciones persisten aún en el caso de producirse un

error del sistema.

Especificar y exigir transacciones

Los programadores de SQL son los responsables de iniciar y finalizar las

transacciones en puntos que exijan la coherencia lógica de los datos. El

programador debe definir la secuencia de modificaciones de datos que los

dejan en un estado coherente en relación con las reglas de negocios de la

organización. El programador incluye estas instrucciones de modificación en

una sola transacción de forma que SQL Server Database Engine (Motor de

base de datos de SQL Server) puede hacer cumplir la integridad física de la

misma.

Es responsabilidad de un sistema de base de datos corporativo, como

una instancia de Motor de base de datos, proporcionar los mecanismos

que aseguren la integridad física de cada transacción. Motor de base de

datos proporciona:

Servicios de bloqueo que preservan el aislamiento de la transacción.

Servicios de registro que aseguran la durabilidad de la transacción.

Aunque se produzca un error en el hardware del servidor, el sistema

operativo o la instancia de Motor de base de datos, la instancia utiliza

registros de transacciones, al reiniciar, para revertir automáticamente las

transacciones incompletas al punto en que se produjo el error del

sistema.


Características de administración de transacciones que exigen la

atomicidad y coherencia de la transacción. Una vez iniciada una

transacción, debe concluirse correctamente; en caso contrario, la

instancia de Motor de base de datos deshará todas las modificaciones

de datos realizadas desde que se inició la transacción.

Gestión de transacciones y administrador de la base de datos

Varias operaciones sobre la base de datos forman a menudo una única unidad

lógica de trabajo. Un ejemplo es la transferencia de fondos, en el que de la

cuenta A se retira y en la cuenta B se deposita. Es esencial que tanto el retiro

como el depósito tengan lugar o bien no ocurra ninguno.

Este requisito de todo o nada se denomina atomicidad. Además es esencial

que la ejecución de la transferencia de fondos preserva la consistencia de la

base de datos, es decir el valor de la suma A+B se debe preservar.

Este requisito de corrección se llama consistencia. Finalmente tras la ejecución

correcta de la transferencia de fondos los nuevos valores de las cuentas A y B

deben persistir, a pesar de la posibilidad de fallo del sistema. Este requisito de

persistencia se llama durabilidad.

Una transacción es una colección de operaciones que se lleva a cabo como

una única función lógica en una aplicación de bases de datos. Cada

transacciones una unidad de atomicidad y consistencia. Así se requiere que las

transacciones no violen ninguna restricción de consistencia de la base de

datos.

Es decir si la base de datos era consistente cuando la transacción comenzó, la

base de datos debe ser consistente cuando la transacción termine con éxito


ADMINISTRADOR DE LA BASE DE DATOS

Una de las principales razones de usar un SGBDs es tener un control

centralizado tanto de los datos como de los programas que acceden a esos

datos.

La persona que tiene este control central sobre el sistema se llama

administrador de la base de datos (ABD)

FUNCIONES DEL ADMINISTRADOR DE LA BASE DE DATOS

Definición del esquema.- El DBA crea el esquema original de la base de datos

escribiendo un conjunto de instrucciones de definición de datos en el LDD.

Definición de la estructura y del método de acceso.

Modificación del esquema y de la organización física.-

Los DBA realizan cambios en el esquema y en la organización física para

reflejar las necesidades cambiantes de la organización, o para alterar la

organización física para mejorar el rendimiento.

Concesión de autorización para el acceso a los datos.- la concesión de

diferentes tipos de autorización

Permite al administrador de la base de datos determinar a qué partes de la

base de datos puede acceder cada usuario. La información de autorización se

mantiene en una estructura del sistema especial que el sistema de base de

datos consulta

Cuando se intenta el acceso a los datos del sistema.

Mantenimiento rutinario.- Algunos ejemplos de actividades rutinarias de

mantenimiento de la base de datos son:

Copia de seguridad periódica de la base de datos, para prevenir

La pérdida de datos en caso de desastres.

Asegurarse de que haya suficiente espacio libre en disco para las operaciones

normales y aumentar el espacio en disco según sea necesario.

Supervisión de los trabajos que se ejecuten en la base de datos.


DEFINICIÓN DE TRANSACIONES

Las transacciones fueron originalmente desarrolladas para ser utilizadas dentro

de los sistemas de base de datos, donde se usaba para ayudar en el

mantenimiento de los datos de las aplicaciones y que dependían de la

consistencia de la información almacenada.

Las transacciones son mecanismos que ayudan a simplificar la construcción de

sistemas confiables mediante procesos que proporcionan soporte uniforme

para invocar y sincronizar operaciones como:

Operaciones de comparación de datos

Aseguramiento de la seriabilidad de las transacciones con otras

Atomicidad en su comportamiento

Recuperación de fallas

La palabra transacción describe una secuencia de operaciones con uno o más

recursos que transforman su estado actual en un nuevo estado de

consistencia. Es un conjunto de operaciones sobre datos que son tratadas

como una unidad. Una transacción puede terminar, haciendo sus cambios

persistentes, o abortar voluntaria o involuntariamente.

Dentro del área de los sistemas computacionales el concepto de transacciones

fue inicialmente utilizado para definir la consistencia entre múltiples usuarios en

una base de datos. Una transacción es una colección de operaciones que

hacen transformaciones consistentes de los estados de un sistema

conservando la consistencia del sistema. Una base de datos está en estado

consistente si cumple todas las restricciones de integridad definidas sobre ella.

Los cambios de estado se dan debido a actualización, inserción y eliminación

de la información. Se quiere asegurar que la base de datos no entre en un

estado de inconsistencia, pero durante la ejecución de una transacción, la base

de datos puede estar temporalmente en un estado inconsistente.

Lo importante aquí es asegurar que la base de datos vuelva a un estado

consistente al concluir la ejecución de una transacción (Figura A)


Figura A . Un modelo de transacción.

Lo que se persigue con el uso de transacciones es por un lado contar con una

transparencia adecuada de las acciones concurrentes a una base de datos y

por el otro tener una transparencia adecuada en el manejo de las fallas que se

pueden presentar en una base de datos.

Comentario sobre el modelo

Una transacción es una acción atómica, siendo una unidad de control de

concurrencia y de recuperación. Las transacciones se mantienen consistentes

solo si se efectúa a partir de un estado consistente. Las transacciones

simplifican el modelo computacional dado que proveen:

Transparencia de concurrencia:

Habilita a diversos procesos para que operenconcurrentementeusando

recursos compartidos sin interferencia entre ellos

Transparencia de fallas:

Permite el encubrimiento de fallos, permitiendo a usuarios y programas

de aplicación culminar sus tareas a pesar de las fallas de componentes

hardware o software


INSTRUCCIONES PARA EL USO DE TRANSACIONES

La programación con uso de transacciones requiere de instrucciones

especiales, las cuales deben ser proporcionadas por el sistema operativo, por

el compilador del lenguaje o por el manejador de la base de datos, algunos

son:

BEGIN _TRANSACCIÓN:

Los comandos siguientes forman una transacción

END _ TRANSACCIÓN:

Termina la transacción y se intenta un compromiso

ABORT_ TRANSACCIÓN:

Se elimina la transacción, se recuperan los valores anteriores.

READ: Se leen datos de un archivo

WRITE: Se escriben datos en un archivo

Las operaciones entre BEGIN y END forman el cuerpo de la transacción y

deben ejecutarse todas o ninguna de ellas. La cantidad exacta de instrucciones

disponibles para manejar transacciones depende del tipo de objetos y

operaciones que deban ser procesadas.

TÉCNICAS DE IMPLANTACIÓN DE TRANSACCIONES

> Área de trabajo privada

> Bitácora de escritura anticipada

> Protocolo de compromiso de dos fases (two-phase)

Área de trabajo privada:

Consiste en realizar copias de los bloques que serán utilizados dentro de una

transacción de manera que se trabaje con estas copias para realizar todas las

modificaciones necesarias. Todo el espacio de trabajo con la información que


será utilizada es contenido dentro de estas copias denominado área de trabajo

privada. Los demás usuarios trabajaran con la copia original de los bloques

pero no podrán obtener una segunda copia de los mismos.

Al iniciarse la transacción el proceso obtiene una copia privada de los datos.

Lecturas y escrituras sobre la zona privada. Para optimizar solo se crean

copias privadas de los datos modificados. Una segunda optimización para los

datos que están organizados en bloques apuntados desde un índice, como los

ficheros, es crear copias solo de los fragmentos modificados.

Bitácora de escritura anticipada:

Este método consiste en realizar una copia con todas las transacciones que

van siendo ejecutadas hacia un bloque o espacio (LOG) de trabajo que sea

estable, esta lista se la conoce como lista de intenciones.

Las transacciones serán actualizadas con la información una vez que se ha

determinado el fin de la transacción.

Se modifican los datos pero antes se escribe en un log sobre memoria estable

la descripción de la operación. En el log también se escriben registros para

indicar el inicio y fin de la transacción, cuando se aborta la transacción se

recorre el log para deshacer los cambios. Después de una caída temporal, se

debe recorrer el log. Si una transacción no ha escrito su registro de fin se

aborta, si lo ha escrito, se hacen los cambios pendientes. Para evitar recorrer

todo el log después de un fallo temporal de la maquina, se usan generalmente

checkpoints.

Protocolo de compromiso de dos fases:

En un sistema distribuido una transacción puede afectar a varios procesadores

lo cual dificulta la atomicidad. La solución más típica es el protocolo de

compromiso de dos fases (C2F). En este protocolo existe un coordinador que

normalmente es el proceso que inicio la transacción.


Fase 1: El coordinador escribe en el log almacenado en memoria

estable el registro (preparar T). Manda un mensaje con ese contenido a

los nodos implicados en la transacción. Cada proceso implicado decide

si está listo para hacer el compromiso, escribe en su log la decisión (listo

T o no listo T) y la manda en un mensaje al coordinador.

Fase 2: Si el coordinador recibe alguna respuesta negativa u obtiene

alguna falla de respuesta decide abortar la transacción. En caso

contrario decide realizar el compromiso.

El coordinador escribe en el log la decisión y manda un mensaje a los

procesos implicados. Cada proceso que recibe el mensaje escribe en su

log la decisión del coordinador y realiza la acción correspondiente.

La terminación de una transacción se hace mediante la regla del compromiso

global. El coordinador aborta una transacción si y solo si al menos un proceso

implicado decide abortar. El coordinador hace un compromiso de la transacción

si y solo si todos los participantes deciden realizar el compromiso.

Comportamiento ante un fallo de un nodo:

El nodo N se recupera después de una caída transitoria y detecta que la

transacción T estaba a medias. Si el log contiene (compromiso T) se realiza la

transacción. Si contiene (abort T) se aborta la transacción, si contiene (listo T)

debe consultar al coordinador para determinar si se compromete o aborta la

transacción, si no hay mensajes en el log se aborta.

Comportamiento ante fallos del coordinador:

Cada nodo implicado N debe decidir sobre la transacción T. Si el log contiene

(compromiso T) se realiza la transacción. Si contiene (abort T) se aborta, si no

contiene (listoT) el coordinador no ha podido decidir el compromiso, por lo

tanto, lo más apropiado es abortar la transacción.


Si todos los nodos tienen (listo T) pero ninguno tiene (compromiso T) o (abort

T) no se puede determinar la decisión del coordinador. Se debería esperar que

se recuperase.

ESTRUCTURA DE LAS TRANSACCIONES

La estructura de una transacción usualmente viene dada según el modelo de la

transacción, estas pueden ser planas (simples) o anidadas.

Transacciones planas:

Consisten en una secuencia de operaciones primitivas encerradas entre las

palabras clave BEGIN y END. Por ejemplo:

BEGIN _TRANSACTION Reservación

....

END.

Transacciones Anidadas:

Consiste en tener transacciones que dependen de otras, estas transacciones

están incluidas dentro de otras de un nivel superior y se las conoce como

subtransacciones. La transacción de nivel superior puede producir hijos

(subtransacciones) que hagan más fácil la programación del sistema y mejoras

del desempeño.

En las transacciones anidadas las operaciones de una transacción pueden ser

así mismo otras transacciones. Por ejemplo:

BEGIN _TRANSACTION Reservación

..........

BEGIN _TRANSACTION Vuelo

........


END.( Vuelo )

......

BEGIN _TRANSACTION Hotel

........

END

......

END.

Una transacción anidada dentro de otra conserva las mismas propiedades que

las de su padre, esto implica, que puede contener así mismo transacciones

dentro de ella. Existen restricciones obvias en una transacción anidada: debe

empezar después que su padre y debe terminar antes que él. El compromiso

de una subtransaccion es condicional al compromiso de su padre, si el padre

de una o varias subtransacciones aborta, las subtransacciones hijas también

serán abortadas. Las transacciones anidadas brindan un nivel más alto de

concurrencia entre transacciones.

Ya que una transacción consiste de varias transacciones es posible tener

mayor concurrencia dentro de una sola transacción.

Así también, es posible recuperarse de de fallas de forma independiente de

cada subtransaccion. Esto limita el daño a una parte más pequeña de la

transacción, haciendo que el costo de la recuperación sea el menor.

También se deben considerar el orden de las lecturas y escrituras. Si las

acciones de lectura y escritura pueden ser mezcladas sin ninguna restricción,

entonces, a este tipo de transacciones se les conoce como Generales .Por el

contrario, si se restringe o impone que un dato debe ser leído antes de que

pueda ser escrito entonces se tendrán transacciones Restringidas.

Si las transacciones son restringidas a que todas las acciones de lectura se

realicen antes de las acciones de escritura entonces se les conoce como de

Dos Pasos. Finalmente existe un modelo de acción para transacciones

restringidas en donde se aplica aun más la restricción de que cada par < read,

write > tiene que ser ejecutado de manera atómica.


PROCESAMIENTO DE TRANSACCIONES

Los siguientes son los aspectos más importantes relacionados con el

procesamiento de transacciones:

Modelo de estructura de transacciones

Es importante considerar si las transacciones son planas o anidadas.

Consistencia de la base de datos interna

Los algoritmos de control de datos tienen que satisfacer las restricciones de

integridad cuando una transacción pretende hacer un compromiso.

Protocolos de confiabilidad

En transacciones distribuidas es necesario introducir medios de comunicación

entre los diferentes nodos de una red para garantizar la atomicidad de las

transacciones.

Algoritmos de control de concurrencia

Deben sincronizar la ejecución de transacciones concurrentes bajo el criterio de

correctitud. La consistencia entre transacciones se garantiza mediante el

aislamiento de las mismas.

Protocolos de control de replicas

Se refiere a cómo garantizar la consistencia mutua de datos replicados.

El procesamiento de transacciones básicamente consiste en una serie de

modificaciones (transacciones) a un determinado recurso del sistema (por

ejemplo una base de datos) y en donde se define un punto de inicio y un punto

de terminación que define un bloque entre el conjunto de operaciones que son

realizadas.


Dentro de este proceso en bloque los demás usuarios no pueden modificar

nada hasta que no se presente un estado estable de los datos, esto ocasiona

inconsistencia temporal y conflictos. Para evitar lo anterior se implementan dos

maneras diferentes:

Ejecución..de..Transacciones..Serializadas

Ejecución de transacciones calendarizadas

Ejecutar transacciones serializadas:

Es un sistema que permite el procesamiento de transacciones en forma

secuencial o serializado dándole una secuencia a cada transacción, este

proceso reduce el rendimiento del sistema, pero tiene como ventaja que el

proceso de sincronización es más sencillo.

Ejecutar transacciones calendarizadas:

Permite el proceso de transacciones asignándoles tiempos de procesamiento el

cual permite incrementar el rendimiento del sistema ya que se ejecuta un

máximo de procesos en forma concurrente y no a través de una serie. La

ventaja es que a un mismo tiempo de reloj se pueden hacer dos operaciones,

aunque el proceso de sincronización es más complicado.

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

aplicar algoritmos de control sobre los datos o recursos; para ese control

también se utilizan protocolos que proporcionen confiabilidad como lo

siguientes:

Atomicidad

Protocolos de recuperación total

Protocolos de compromiso global

El control de las transacciones también requiere de controlar la concurrencia

del acceso y uso hacia el recurso que se está manipulando, ese control de

concurrencia tiene dos objetivos:

Como sincronizar la ejecución concurrente de transacciones

Consistencia intra transacción (Aislamiento)


Para llevar a cabo el control de concurrencia dentro de un proceso de

transacciones se manejan dos modos:

Ejecución centralizada de transacciones (Figura B)

Figura C. Ejecución distribuida de transacciones.


CONDICIONES DE TERMINACION DE UNA TRANSACCION

Una transacción siempre termina, aun en la presencia de fallas. Si una

transacción termina de manera exitosa se dice que la transacción hace un

compromiso. Si la transacción se detiene sin terminar su tarea, se dice que la

transacción aborta. Cuando la transacción es abortada, puede ser por distintas

razones relacionadas con la naturaleza de la transacción misma, o por conflicto

con otras transacciones o por fallo de un proceso o computador, entonces su

ejecución es detenida y todas las acciones ejecutadas hasta el momento son

deshechas regresando a la base de datos al estado antes de su ejecución. A

esta operación también se la conoce como rollback.

TRANSACCIONES EN LOS SISTEMAS DE ARCHIVOS DISTRIBUIDOS

Como alternativa a tener clientes que instalen bloqueos individuales, algunos

servidores de archivos soportan acciones atómicas, a menudo llamadas

transacciones. Cuando está disponible esta facilidad, un cliente puede indicarle

al servidor que comience una transacción, seguida por cualquier número de

aperturas y operaciones de archivos, y finalizar con un comando para terminar

la transacción. El servidor debe ser capaz de llevar a cabo todos los

pedidos efectuados de forma atómica (indivisible) sin interferencia de otros

pedidos de clientes. Si el cliente decide abortar la transacción o finalizan sus

temporizadores, todos los archivos son restaurados al estado anterior al

comienzo de la transacción. Una transacción es cualquier operación de E/S

sobre un archivo que modifica el contenido de un archivo existente del mismo.

Esto incluye el agregar datos, cambiar el tamaño y sobrescribir datos

existentes.

En una implementación, junto al archivo de datos existe el denominado

transaction log file que mantiene la descripción de las modificaciones hechas

sobre el archivo de datos y el mantenimiento de este archivo se llama

transaction tracking.


La operación denominada transaction rollback es aquella por la cual las

alteraciones indicadas en el log se deshacen retornando los datos al estado

previo (estado inicial), que se supone consistente.

Dentro de los objetivos de diseño de un sistema de transacciones se tienen:

Minimizar la sobrecarga de los sistemas de archivos, Identificar

automáticamente las inconsistencias de datos. Una vez identificados debe

producirse una operación rollback sin la intervención del usuario. Obviamente

mientras se produce esta operación, debe negarse el acceso a los archivos

potencialmente corruptos. < maximizar la portabilidad.

La clave está en la posibilidad de volver al punto de partida y, si corresponde,

rehacer las operaciones.

Para ello debe disponerse de la siguiente información:

Identificación completa y univoca del archivo de datos.

El modo y los permisos utilizados al abrir el archivo.

La ubicación de los datos modificados.

Una copia de los datos originales.

La descripción de la alteración que tuvo lugar.

Los datos con que se llevo a cabo tal modificación.

Esta información convenientemente organizada, forma el núcleo de los

denominados registros de transacciones, la unidad de datos de datos de los

archivos log


EJEMPLOS DE TIPOS DE TRANSACCIONES en SQL Server

INJ.HN

Introducción

Una transacción es un conjunto de operaciones que van a ser tratadas como

una única unidad.

Estas transacciones deben cumplir 4 propiedades fundamentales comúnmente

conocidas como ACID (atomicidad, coherencia, asilamiento y durabilidad).

La transacción más simple en SQL Server es una única sentencia SQL. Por

ejemplo una sentencia como esta:

UPDATE Products SET UnitPrice=20 WHERE ProductName ='Chai'

Es una transacción. (Como siempre ejemplos de Northwind) Esta es una

transacción 'autocommit', una transacción autocompletada.

Cuando enviamos esta sentencia al SQL Server se escribe en el fichero de

transacciones lo que va a ocurrir y a continuación realiza los cambios

necesarios en la base de datos. Si hay algún tipo de problema al hacer esta

operación el SQL Server puede leer en el fichero de transacciones lo que se

estaba haciendo y si es necesario puede devolver la base de datos al estado

en el que se encontraba antes de recibir la sentencia.

Por supuesto este tipo de transacciones no requieren de nuestra intervención

puesto que el sistema se encarga de todo. Sin embargo si hay que realizar

varias operaciones y queremos que sean tratadas como una unidad tenemos

que crear esas transacciones de manera explícita.

Sentencias para una transacción

Como decíamos una transacción es un conjunto de operaciones tratadas como

una sola. Este conjunto de operaciones debe marcarse como transacción para

que todas las operaciones que la conforman tengan éxito o todas fracasen.

La sentencia que se utiliza para indicar el comienzo de una transacción es

'BEGIN TRAN'. Si alguna de las operaciones de una transacción falla hay que

deshacer la transacción en su totalidad para volver al estado inicial en el que

estaba la base de datos antes de empezar. Esto se consigue con la sentencia


'ROLLBACK TRAN'.

Si todas las operaciones de una transacción se completan con éxito hay que

marcar el fin de una transacción para que la base de datos vuelva a estar en un

estado consistente con la sentencia 'COMMIT TRAN'.

Un ejemplo

Trabajaremos con la base de datos Northwind en nuestros ejemplos. Vamos a

realizar una transacción que modifica el precio de dos productos de la base de

datos.

USE NorthWind

DECLARE @Error int

Declaramos una variable que utilizaremos para almacenar un posible código de

error

BEGIN TRAN

Iniciamos la transacción

UPDATE Products SET UnitPrice=20 WHERE ProductName ='Chai'

Ejecutamos la primera sentencia

SET @Error=@@ERROR

Si ocurre un error almacenamos su código en @Error

y saltamos al trozo de código que deshará la transacción. Sí, eso de

ahí es un

GOTO, el demonio de los programadores, pero no pasa nada por usarlo

Cuando es necesario

IF (@Error<>0) GOTO TratarError

Si la primera sentencia se ejecuta con éxito, pasamos a la segunda

UPDATE Products SET UnitPrice=20 WHERE ProductName='Chang'

SET @Error=@@ERROR

Y si hay un error hacemos como antes

IF (@Error<>0) GOTO TratarError

Si llegamos hasta aquí es que los dos UPDATE se han completado con

Éxito y podemos "guardar" la transacción en la base de datos

COMMIT TRAN


TratarError:

Si ha ocurrido algún error llegamos hasta aquí

If @@Error<>0 THEN

BEGIN

PRINT 'Ha ecorrido un error. Abortamos la transacción'

Se lo comunicamos al usuario y deshacemos la transacción

Todo volverá a estar como si nada hubiera ocurrido

ROLLBACK TRAN

END

Como se puede ver para cada sentencia que se ejecuta miramos si se ha

producido o no un error, y si detectamos un error ejecutamos el bloque de

código que deshace la transacción.

Hay una interpretación incorrecta en cuanto al funcionamiento de las

transacciones que está bastante extendida. Mucha gente cree que si tenemos

varias sentencias dentro de una transacción y una de ellas falla, la transacción

se aborta en su totalidad.

Ahora tenemos dos sentencias dentro de una transacción.

USE NorthWind

BEGIN TRAN



COMMIT TRAN

Estas dos sentencias se ejecutarán como una sola. Si por ejemplo en medio de

la transacción (después del primer update y antes del segundo) hay un corte de

electricidad, cuando el SQL Server se recupere se encontrará en medio de una

transacción y, o bien la termina o bien la deshace, pero no se quedará a

medias.


El error está en pensar que si la ejecución de la primera sentencia da un error

se cancelará la transacción.

El SQL Server sólo se preocupa de ejecutar las sentencias, no de averiguar si

lo hacen correctamente o si la lógica de la transacción es correcta. Eso es cosa

nuestra.

Por eso en el ejemplo que tenemos más arriba para cada sentencia de nuestro

conjunto averiguamos si se ha producido un error y si es así actuamos en

consecuencia cancelando toda la operación.

Transacciones anidadas

Otra de las posibilidades que nos ofrece el SQL Server es utilizar transacciones

anidadas. Esto quiere decir que podemos tener transacciones dentro de

transacciones, es decir, podemos empezar una nueva transacción sin haber

terminado la anterior.

Asociada a esta idea de anidamiento existe una variable global

@@TRANCOUNT que tiene valor 0 si no existe ningún nivel de anidamiento, 1

si hay una transacción anidada, 2 si estamos en el segundo nivel de

anidamiento. y así sucesivamente.

La dificultad de trabajar con transacciones anidadas está en el comportamiento

que tienen ahora las sentencias 'COMMIT TRAN' y 'ROLLBACK TRAN'

ROLLBACK TRAN: Dentro de una transacción anidada esta sentencia

deshace todas las transacciones internas hasta la instrucción BEGIN

TRANSACTION más externa.

COMMIT TRAN: Dentro de una transacción anidada esta sentencia

únicamente reduce en 1 el valor de @@TRANCOUNT, pero no "finaliza"

ninguna transacción ni "guarda" los cambios. En el caso en el que

@@TRANCOUNT=1 (cuando estamos en la última transacción)

COMMIT TRAN hace que todas las modificaciones efectuadas sobre los

datos desde el inicio de la transacción sean parte permanente de la base


de datos, libera los recursos mantenidos por la conexión y reduce

@@TRANCOUNT a 0.

Como siempre un ejemplo es lo mejor para entender cómo funciona.

CREATE TABLE Test (Columna int)

GO

BEGIN TRAN TranExterna -- @@TRANCOUNT ahora es 1

SELECT 'El nivel de anidamiento es', @@TRANCOUNT

INSERT INTO Test VALUES (1)

BEGIN TRAN TranInterna1 -- @@TRANCOUNT ahora es 2.






COMMIT TRAN TranInterna2 -- Reduce @@TRANCOUNT a 2.

Pero no se guarda nada en la base de datos.





COMMIT TRAN TranExterna -- Reduce @@TRANCOUNT a 0. Se lleva a cabo

la transacción externa y todo lo que conlleva.


SELECT * FROM Test

Por cierto que lo de usar nombre para las transacciones es por claridad, puesto

que COMMIT TRAN como ya hemos dicho solamente reduce en 1 el valor de

@@TRANCOUNT.

Veamos ahora un ejemplo de transacción anidada con ROLLBACK TRAN











ROLLBACK TRAN --@@TRANCOUNT es 0 y se deshace

La transacción externa y todas las internas


SELECT * FROM Test

En este caso no se inserta nada puesto que el ROLLBACK TRAN deshace

todas las transacciones dentro de nuestro anidamiento hasta la transacción

más externa y además hace @@TRANCOUNT=0

¿Supone este funcionamiento asimétrico del COMMIT y del ROLLBACK un

problema?. La manera de tratar las transacciones por el SQL Server es la que

nos permite programar de manera natural los anidamientos. De todos modos, si

queremos ir un poco más lejos hay una cuarta sentencia para trabajar con

transacciones: SAVE TRAN

Save Tran

Esta sentencia crea un punto de almacenamiento dentro de una transacción.

Esta marca sirve para deshacer una transacción en curso sólo hasta ese punto.

Por supuesto nuestra transacción debe continuar y terminar con un COMMIN

TRAN (o los que hagan falta) para que todo se guarde o con un ROLLBACK

TRAN para volver al estado previo al primer BEGIN TRAN.








SAVE TRAN Guadada




ROLLBACK TRAN Guadada -- se deshace lo hecho el punto guardado.


Ahora podemos decidir si la transacción se lleva a cabo

o se deshace completamente

Para deshacerla un ROLLBACK bastará como hemos visto

Pero para guardar la transacción hace falta reducir @@TRANCOUNT a 0






COMMIT TRAN TranExterna -- Reduce @@TRANCOUNT a 0.

Se lleva a cabo la transacción externa y todo lo que conlleva.


SELECT * FROM Test

Si no ponemos el nombre del punto salvado con SAVE TRAN al hacer un

ROLLBACK TRAN se deshace la transacción más externa y @@TRANCOUNT

se pone a 0.

Como podemos ver el uso de transacciones no es complicado, e incluso las

transacciones anidadas si se tratan con cuidado son fáciles de manejar.

Un par de ejemplos más


Veamos otro par de ejemplos para dejar claro como funcionan las sentencias

BEGIN, COMMIT y SAVE

BEGIN TRAN

Primer BEGIN TRAN y ahora @@TRANCOUNT = 1

BEGIN TRAN

Ahora @@TRANCOUNT = 2

COMMIT TRAN

Volvemos a @@TRANCOUNT = 1

Pero no se guarda nada ni se hacen efectivos los posibles cambios

COMMIT TRAN

Por fin @@TRANCOUNT = 0

Si hubiera cambios pendientes se llevan a la base de datos

Y volvemos a un estado normal con la transacción acabada

Uso del COMMIT

BEGIN TRAN

Primer BEGIN TRAN y @@TRANCOUNT = 1

BEGIN TRAN


COMMIT TRAN

Como antes @@TRANCOUNT = 1

Y como antes nada se guarda

ROLLBACK TRAN

Se cancela TODA la transacción. Recordemos que el COMMIT

de antes no guardo nada, solo redujo @@TRANCOUNT


COMMIT TRAN

No vale para nada porque @@TRANCOUNT es 0 por el efecto del

ROLLBACK

Uso del ROLLBACK


En cuanto al SAVE TRAN podemos recordarlo con el siguiente ejemplo:

CREATE TABLE Tabla1 (Columna1 varchar(50))

GO

BEGIN TRAN

INSERT INTO Tabla1 VALUES ('Primer valor')

SAVE TRAN Punto1

INSERT INTO Tabla1 VALUES ('Segundo valor')

ROLLBACK TRAN Punto1

INSERT INTO Tabla1 VALUES ('Tercer valor')

COMMIT TRAN

SELECT * FROM Tabla1

Columna1

--------------------------------------------------

Primer valor

Tercer valor

(2 filas afectadas)

Un ROLLBACK a un SAVE TRAN no deshace la transacción en curso ni

modifica @@TRANCOUNT, simplemente cancela lo ocurrido desde el 'SAVE

TRAN nombre' hasta su 'ROLLBACK TRAN nombre'

Transacciones y procedimientos almacenados.

Cuando trabajamos con procedimientos almacenados debemos recordar que

cada procedimiento almacenado es una unidad. Cuando se ejecuta lo hace de

manera independiente de quien lo llama. Sin embargo si tenemos un

ROLLBACK TRAN dentro de un procedimiento almacenado cancelaremos la

transacción en curso, pero si hay una transacción externa al procedimiento en

el que estamos trabajando se cancelará esa transacción externa.


Con esto no quiero decir que no se pueda usar, simplemente que hay que tener

muy claras las 4 normas sobre las sentencias BEGIN, ROLLBACK y COMMIT

que comentamos al principio de este artículo. Veamos cómo se comporta una

transacción en un procedimiento almacenado llamado desde una transacción.

CREATE PROCEDURE Inserta2

AS

BEGIN TRAN --Uno

INSERT INTO Tabla1 VALUES ('Valor2')

ROLLBACK TRAN --Uno

GO


AS

BEGIN TRAN --Dos

INSERT INTO Tabla1 VALUES ('Valor 1')

EXEC Inserta2


COMMIT TRAN --Dos

GO

En principio parece que si ejecutamos el procedimiento 'Inserta1' el resultado

sería:

EXECUTE inserta1

SELECT * FROM tabla1

txt

--------------------------------------------------

Valor1

Valor3

(2 filas afectadas)

Pero lo que obtenemos es:


EXECUTE inserta1


(1 filas afectadas)

(1 filas afectadas)

Servidor: mensaje 266, nivel 16, estado 2, procedimiento Inserta2, línea 8

El recuento de transacciones después de EXECUTE

Indica que falta una instrucción COMMIT o ROLLBACK

TRANSACTION.

Recuento anterior = 1, recuento actual = 0.

(1 filas afectadas)

Servidor: mensaje 3902, nivel 16, estado 1, procedimiento Inserta1, línea 8

La petición COMMIT TRANSACTION no tiene la correspondiente BEGIN

TRANSACTION.

txt

--------------------------------------------------

Valor3

(1 filas afectadas)

Si analizamos estos mensajes vemos que se inserta la primera fila, se salta al

segundo procedimiento almacenado y se inserta la segunda fila. Se ejecuta el

'ROLLBACK TRAN -Dos' del segundo procedimiento almacenado y se

deshacen las dos inserciones porque este ROLLBACK cancela la transacción

exterior, la del primer procedimiento almacenado. A continuación se termina el

segundo procedimiento almacenado y como este procedimiento tiene un

'BEGIN TRAN -Dos' y no tiene un COMMIT o un ROLLBACK (recordemos que

el 'ROLLBACK TRAN -Dos' termina el 'BEGIN TRAN -Uno') se produce un error

y nos avisa que el procedimiento almacenado termina con una transacción

pendiente. Al volver al procedimiento almacenado externo se ejecuta el

INSERT que inserta la tercera fila y a continuación el 'COMMIT TRAN --Uno'.

Aquí aparece otro error puesto que este 'COMMIT TRAN -Uno' estaba ahí para

finalizar una transacción que ya ha sido cancelada anteriormente.


El modo correcto

Para que nuestras transacciones se comporten como se espera dentro de un

procedimiento almacenado podemos recurrir al SAVE TRAN.

Veamos como:


AS

SAVE TRAN Guardado


ROLLBACK TRAN Guardado

GO


AS

BEGIN TRAN


EXEC Inserta2


COMMIT TRAN

GO

Ahora el 'ROLLBACK TRAN guardado' del segundo procedimiento almacenado

deshace la transacción sólo hasta el punto guardado. Además este ROLLBACK no

decrementa el @@TRANCOUNT ni afecta a las transacciones en curso.

El resultado obtenido al ejecutar este procedimiento almacenado es:

EXECUTE inserta1


(1 filas afectadas)

(1 filas afectadas)

(1 filas afectadas)

txt

Valor 1


Valor 3

(2 filas afectadas)

Una vez vistos estos ejemplos queda claro que no hay problema en utilizar

transacciones dentro de procedimientos almacenados siempre que tengamos

en cuenta el comportamiento del ROLLBACK TRAN y que utilicemos el SAVE

TRAN de manera adecuada

CUESTIONARIO

1-. ¿ Que compendio por transacciones en base de datos?

2-. ¿Cuál es el conjunto de acciones deben constituir una transacción?

3-. Enumere cuales son las propiedades de la transacciones.

4-.¿Que es la gestión y administración de base de datos?


5-. ¿Cuáles son las instrucciones para el uso de transacciones?

6-. Elabore un explicación de las TÉCNICAS DE IMPLANTACIÓN DE

TRANSACCIONES.

7-.¿Que es un protoloco de compromiso de dos fases?

8-.¿Que tipo de estructura existen indíquelas?

9-.¿Que entiende por transacciones en sistemas de archivos distribuidos?

10-.¿Que son las Transacciones y procedimientos almacenados?


CONCURRENCIA

Objetivos del capítulo III

1. Comprender y analizar el concepto de concurrencia.

2. Conocer los conceptos de los principales algoritmos.

1. Conocer la concurrencia en sistema archivo.

2. Comprender el concepto de abrazos mortales.

3. Comprender ejemplos de concurrencia.


EL CONTROL DE CONCURRENCIA EN EL MODELO

TRANSACCIONAL

Los bloqueos se pueden definir formalmente como sigue: "Un conjunto de

procesos se bloquean si cada proceso del conjunto está esperando un evento

que solo otro proceso del conjunto puede provocar". Puesto que todos los

procesos están en espera, ninguno de ellos podrá ocasionar nunca ninguno de

los eventos que podría desbloquear a algunos de los otros miembros del

conjunto y los demás procesos seguirán esperando indefinidamente

El control de concurrencia trata sobre los problemas de aislamiento y

consistencia del procesamiento de transacciones.

El control de concurrencia distribuido en sistema de manejo de bases de datos

distribuidas asegura que la consistencia de la base de datos se mantiene, en

un ambiente distribuido multiusuario. Si las transacciones son internamente

consistentes, la manera más simple de lograr este objetivo es ejecutar cada

transacción sola, una después de otra.

Sin embargo esto puede afectar enormemente el desempeño de un sistema de

manejo de bases de datos distribuidas dado que el nivel de concurrencia se

reduce al mínimo. El nivel de concurrencia, el número de transacciones activas,

es probablemente el parámetro más importante en sistemas distribuidos. Los

mecanismos de control de concurrencia buscan encontrar un balance entre el

mantenimiento de la consistencia de la base de datos y el mantenimiento de un

alto nivel de concurrencia.

El fallo en diseño de mecanismos apropiados de sincronización y en obligar su

uso por cada proceso que utiliza recursos comunes, produce frecuentemente

un comportamiento erróneo del sistema y rupturas que son notablemente

difíciles de depurar.

La concurrencia puede producir un incremento de la productividad cuando se

implementan correctamente, pero puede también degradar la fiabilidad cuando


la sincronización impropia entre procesos contamina el sistema con errores

artificios de tiempo.Si no se lleva a cabo un adecuado control de concurrencia,

se podrían llegar a presentar dos anomalías. En primer lugar, se pueden perder

actualizaciones provocando que los efectos de algunas transacciones no se

reflejen en la base de datos.

En segundo lugar, pueden presentarse recuperaciones de información

inconsistentes.

Los algoritmos para el control de concurrencia son útiles cuando se ejecutan

varias transacciones al mismo tiempo

Los principales algoritmos son:

Los de cerradura o basados en candados

El de control optimista de la concurrencia

El de las marcas de tiempo

El conjunto de algoritmos pesimistas está formado por algoritmos basados en

candados, algoritmos basados en ordenamiento por estampas de tiempo y

algoritmos híbridos. Los algoritmos optimistas se componen por los algoritmos

basados en candados y algoritmos basados en estampas de tiempo. (Figura D)

Figura D. Clasificación de los algoritmos de control de concurrencia.


ALGORITMOS DE CERRADURA O BASADOS EN CANDADOS

En los algoritmos basados en candados, las transacciones indican sus

intenciones solicitando candados al despachador (llamado el administrador de

candados) Los candados son de lectura, también llamados compartidos, o de

escritura, también llamados exclusivos.

En sistemas basados en candados, el despachador es un administrador de

candados. El administrador de transacciones le pasa al administrador de

candados la operación sobre la base de datos (lectura o escritura) e

información asociada, como por ejemplo el elemento de datos que es accesado

y el identificador de la transacción que está enviando la operación a la base de

datos.

El administrador de candados verifica si el elemento de datos que se quiere

accesar ya ha sido bloqueado por un candado. Si el candado solicitado es

incompatible con el candado con que el dato está bloqueado, entonces, la

transacción solicitante es retrasada. De otra forma, el candado se define sobre

el dato en el modo deseado y la operación a la base de datos es transferida al

procesador de datos.

El administrador de transacciones es informado luego sobre el resultado de la

operación. La terminación de una transacción libera todos los candados y se

puede iniciar otra transacción que estaba esperando el acceso al mismo dato.

Se usan cerraduras o candados de lectura o escritura sobre los datos.

Para asegurar la secuencialidad se usa un protocolo de dos fases, en la fase

de crecimiento de la transacción se establecen los cerrojos y en la fase de

decrecimiento se liberan los cerrojos. Hay que tener en cuenta que se pueden

producir interbloqueos.


En los sistemas distribuidos el nodo que mantiene un dato se encarga

normalmente de gestionar los cerrojos sobre el mismo.

Candados de dos fases:

En los candados de dos fases una transacción le pone un candado a un objeto

antes de usarlo. Cuando un objeto es bloqueado con un candado por otra

transacción, la transacción solicitante debe esperar. Cuando una transacción

libera un candado, ya no puede solicitar más candados. En la primera fase

solicita y adquiere todos los candados sobre los elementos que va a utilizar y

en la segunda fase libera los candados obtenidos uno por uno.

Puede suceder que si una transacción aborta después de liberar un candado,

otras transacciones que hayan accesado el mismo elemento de datos aborten

también provocando lo que se conoce como abortos en cascada.

Para evitar lo anterior, los despachadores para candados de dos fases

implementan lo que se conoce como los candados estrictos de dos fases en los

cuales se liberan todos los candados juntos cuando la transacción termina (con

compromiso o aborta).

Candados de dos fases centralizados:

En sistemas distribuidos puede que la administración de los candados se

dedique a un solo nodo del sistema, por lo tanto, se tiene un despachador

central el cual recibe todas las solicitudes de candados del sistema.

La comunicación se presenta entre el administrador de transacciones del nodo

en donde se origina la transacción, el administrador de candados en el nodo

central y los procesadores de datos de todos los nodos participantes. Los

nodos participantes son todos aquellos en donde la operación se va a llevar a

cabo.


Figura E. Comunicación en un administrador centralizado de candados de dos

fases.

La crítica más fuerte a los algoritmos centralizados es el "cuello de botella" que

se forma alrededor del nodo central reduciendo los tiempos de respuesta de

todo el sistema. Su disponibilidad es reducida a cero cuando se presentan

fallas en el nodo central.

Candados de dos fases distribuidos:

En los candados de dos fases distribuidos se presentan despachadores en

cada nodo del sistema. Cada despachador maneja las solicitudes de candados

para los datos en ese nodo. Una transacción puede leer cualquiera de las

copias replicada del elemento x, obteniendo un candado de lectura en

cualquiera de las copias de x. La escritura sobre x requiere que se obtengan

candados para todas las copias de x. Los mensajes de solicitud de candados

se envían a todos los administradores de candados que participan en el

sistema. Las operaciones son pasadas a los procesadores de datos por los

administradores de candados. Los procesadores de datos envían su mensaje

de "fin de operación" al administrador de transacciones coordinador


Figura F. Comunicación en candados de dos fases distribuidos

CONTROL OPTIMISTA DE LA CONCURRENCIA

Los algoritmos de control de concurrencia pesimistas asumen que los conflictos

entre transacciones son muy frecuentes y no permiten el acceso a un dato si

existe una transacción conflictiva que accesa el mismo dato. Así, la ejecución

de cualquier operación de una transacción sigue la secuencia de fases:

validación, lectura, cómputo y escritura (ver Figura G, sigte pag).

Los algoritmos optimistas, por otra parte, retrasan la fase de validación justo

antes de la fase de escritura (ver Figura G, sigte pag). De esta manera, una

operación sometida a un despachador optimista nunca es retrasada.


Las operaciones de lectura, cómputo y escritura de cada transacción se

procesan libremente sin actualizar la base de datos corriente. Cada transacción

inicialmente hace sus cambios en copias locales de los datos.

La fase de validación consiste en verificar si esas actualizaciones conservan la

consistencia de la base de datos. Si la respuesta es positiva, los cambios se

hacen globales (escritos en la base de datos corriente). De otra manera, la

transacción es abortada y tiene que reiniciar

Lo que se hace es dejar ejecutar las transacciones y si al terminar se detecta

que ha habido conflicto se aborta y se reinicia la transacción.

Cada transacción tiene tres fases:.

Fase de lectura:

Cuerpo de la transacción donde se copian datos desde la base de datos,

copias que pueden ser actualizadas pero sin copiar a la base de datos

Fase de validación:

Se comprueba que no existan conflictos

Fase de escritura:

Si no existen conflictos se instalan lo cambios en la base de datos

Conflictos entre operaciones:

Dos operaciones están en conflicto entre sí cuando, operan sobre los mismos

datos, una de las operaciones es de escritura, o cada operación pertenece a

diferentes transacciones.

Figura G. Fases de la ejecución de una transacción a) pesimista, b) optimista


ALGORITMOS BASADOS EN MARCAS DE TIEMPO

A diferencia de los algoritmos basados en candados, los algoritmos basados en

marcas de tiempo no pretenden mantener la seriabilidad por la exclusión

mutua. En su lugar eligen un orden de socialización en primera instancia y

ejecutan las transacciones de acuerdo a ese orden.

En estos algoritmos cada transacción lleva asociada una marca de tiempo.

Cada dato lleva asociado dos marcas de tiempo: uno de lectura y otro de

escritura, que reflejan la marca de tiempo de la transacción que hizo la última

operación de ese tipo sobre el dato.

Para leer la marca de tiempo de escritura del dato, debe ser menor que el de la

transacción, si no aborta. Para escribir las marcas de tiempo de escritura y

lectura del dato, deben ser menores que el de la transacción, sino se aborta.

Esta técnica está libre de Interbloqueos pero puede darse que halla que repetir

varias veces la transacción. En los sistemas distribuidos se puede usar un

mecanismo como, los relojes de Lamport para asignar marcas de tiempo.

CONTROL DE CONCURRENCIA EN SISTEMAS DE ARCHIVOS

DISTRIBUIDOS

Hasta aquí se ha hablado sobre el modelo transaccional haciendo hincapié en

lo referido a base de datos distribuidas. En adelante se desarrollara como se

emplea el control de concurrencia en sistemas distribuidos de archivos

Los sistemas de archivos que forman parte de una red de computadoras tienen

múltiples clientes de los que encargarse. Si dos o más clientes,

accidentalmente o no, deciden acceder al mismo archivo al mismo tiempo

pueden producirse conflictos. La solución utilizada es permitir a los usuarios el

uso de bloqueos sobre los archivos de trabajo.


La idea es sencilla, mientras un usuario está trabajando sobre una parte de los

datos, otros no podrán hacerlo de manera que las distintas actualizaciones se

efectuaran en forma sucesiva y ordenada sin interferencias. Se utilizan dos

clases de bloqueos: Los bloqueos compartidos que por lo general se usan para

lectura, y los bloqueos exclusivos que normalmente se usan para escritura.

La granularidad del bloqueo es otra consideración importante. Es posible

bloquear archivos enteros, pero también es posible bloquear archivos enteros o

subárboles, cuanto menor sea la unidad lógica bloqueada mayor será la

concurrencia admisible.

El concepto de bloqueo introduce varios problemas de contrapartida. Primero,

si un cliente necesita acceder a varios archivos, como ocurre de forma común

cuando se efectúan transferencias de dinero en aplicaciones bancarias, hay

una posibilidad de abrazo mortal.

Abrazos mortales:

Principalmente, existen dos métodos para manejar el problema de los abrazos

mortales. Podemos usar algún protocolo para asegurar que el sistema nunca

entrará en un estado de abrazo mortal. Alternativamente, podemos permitir que

el sistema entre en un estado de abrazo mortal y después recuperarnos.

El recuperarse de un abrazo mortal puede ser muy difícil y muy caro. Por ello,

primeramente consideraremos los métodos para asegurar que no ocurran los

abrazos mortales. Comúnmente, existen dos métodos:

El de PREVENCIÓN de abrazos mortales

LA EVASIÓN de abrazos mortales.


PREVENCIÓN de abrazos mortales.

Un conjunto de procesos está en un abrazo mortal cuando todos los procesos

en ese conjunto están esperando un evento que sólo puede ser causado por

otro proceso en el conjunto.

Los eventos a los cuales nos estamos refiriendo son

concernientes con la asignación y liberación de recursos principalmente. Sin

embargo, pueden llevara la existencia de abrazos mortales.

Para ejemplificar un estado de abrazo mortal, se considerara un sistema con

tres unidades de disco. Supongamos que existen tres procesos, cada uno de

ellos tiene asignada una de las unidades de disco. Si ahora cada proceso pide

otra unidad de disco, los tres procesos se encuentran ahora en un estado de

abrazo mortal. Cada uno está esperando el evento "unidad de disco liberada",

lo cual solo puede ser causada por alguno de los otros procesos en espera.

Este ejemplo ilustra un abrazo mortal involucrando procesos compitiendo por el

mismo tipo de recurso. Los abrazos mortales pueden también involucrar

diferentes tipos de recursos.

Por ejemplo, consideremos un sistema con una impresora y una unidad de

disco. Supongamos que el proceso A tiene asignada la unidad de disco y que

el proceso B tiene asignada la impresora. Ahora, si A pide la impresora y B pide

la unidad de disco, ocurre un abrazo mortal.

Ejemplo de un abrazo mortal.


Es obvio que un abrazo mortal es una condición indeseable. En un abrazo

mortal, los procesos nunca terminan de ejecutarse y los recursos del sistema

están amarrados, evitando que otros procesos puedan siquiera empezar.

Condiciones Necesarias. Una situación de abrazo mortal puede surgir sí y solo

sí las siguientes cuatro condiciones ocurren simultáneamente en un sistema:

Exclusión Mutua. Cada recurso se asigna por lo regular exactamente a un

proceso o bien está disponible. Al menos un recurso es mantenido en un modo

no-compartible; esto es, sólo un proceso a la vez puede usar el recurso. Si otro

proceso solicita ese recurso, tiene que ser retardado hasta que el recurso haya

sido liberado.

Retener y Esperar. Los procesos que regularmente contienen recursos

otorgados antes pueden solicitar nuevos recursos. Debe existir un proceso que

retenga al menos un recurso y esté esperando para adquirir recursos

adicionales que están siendo retenidos por otros procesos.

No existe el derecho de desasignar : Los recursos previamente otorgados no

pueden extraerse por la fuerza de un proceso. Deben ser liberados

explícitamente por el proceso que los contiene. Los recursos no pueden ser

desasignados ; esto es, un recurso sólo puede ser liberado voluntariamente por

el proceso que lo retiene, después de que el proceso ha terminado su tarea.

Espera Circular. Debe haber una cadena de dos o más procesos, cada uno de

los cuales esté esperando un recurso contenido en el siguiente miembro de la

cadena. Debe existir un conjunto {p0, p1, ...,pn} de procesos en espera tal que

p0 esté esperando por un recurso que está siendo retenido por p1, p1 está

esperando por un recurso que está siendo retenido por p2, ..., pn-1 está

esperando por un recurso que está siendo retenido por pn y pn está esperando

por un recurso que está siendo retenido por p0.


Se remarca que las cuatro condiciones deben de cumplirse para que pueda

ocurrir un abrazo mortal. La condición de espera circular implica la condición de

retener y esperar, de tal manera que las cuatro condiciones no son totalmente

independientes. Sin embargo, puede ser útil el considerar cada condición por

separado.

Una forma de modelar estas condiciones es usando un grafo de recursos:

Los círculos representan procesos.

Los cuadrados recursos.

Una arista desde un recurso a un proceso indica que el recurso ha sido

asignado al proceso. Una arista desde un proceso a un recurso indica que el

proceso ha solicitado el recurso, y está bloqueado esperándolo. Entonces, si

hacemos el grafo con todos los procesos y todos los recursos del sistema y

encontramos un ciclo, los procesos en el ciclo están bajo bloqueo mutuo.

Ejemplo de un grafo de recursos.


La discusión del control de concurrencia hasta aquí se ha centralizado

alrededor del problema de qué hacer cuando múltiples usuarios quieren

actualizar el mismo archivo. Una manera completamente diferente es prevenir

todas las actualizaciones.

Desde este punto de vista, los archivos son inmutables; una vez que se crea un

archivo no puede modificarse. En este caso, para incorporar nueva información

en el archivo, un cliente puede crear una nueva versión del archivo que

reemplaza (pero no modifica) el original. De esta manera, un archivo se vuelve

una secuencia de versiones inmutables.

La sincronización entre procesos es necesaria para prevenir y corregir errores

de sincronización debidos al acceso concurrente de recursos compartidos,

tales como estructuras de datos o dispositivos de E/S, de procesos

contendientes.

La sincronización entre procesos también permite intercambiar señales de

tiempo entre procesos cooperantes para garantizar las relaciones específicas

de precedencia impuestas por el problema que se resuelva.

Sin una sincronización adecuada entre procesos, la actualización entre

variables compartidas puede inducir a errores de tiempo relacionadas con la

concurrencia que son con frecuencia difíciles de depurar.

Una de las causas principales de este problema es que procesos concurrentes

puedan tener valores temporalmente inconsistentes de una variable compartida

mientras se actualizan.

Los semáforos son un mecanismo sencillo pero poderoso de sincronización

entre procesos. Los semáforos satisfacen la mayoría de los requerimientos que

hemos especificado para un buen mecanismo de control de concurrencia, sin

incluir suposiciones sobre las velocidades y prioridades relativas de los

procesos contendientes y sin saber nada sobre los otros contendientes excepto

que existen probablemente.


Mediante el uso de semáforos se pueden resolver algunos problemas bien

conocidos de sincronización, como los de PRODUCTOR/CONSUMIDOR y

LECTORES/ESCRITORES.

Sincronización entre procesos

La ejecución concurrente de procesos, puede producir mejoras significativas de

rendimiento respecto a la ejecución secuencial de programas. Cuando es

crítico el rendimiento, se puede dividir el trabajo en varios procesos

cooperantes definidos por el programador para explotar la posible concurrencia

de un programa o aplicación dada. Sin embargo, para que funcione

apropiadamente un grupo de procesos, se deben sincronizar sus actividades

de forma que asegure la observancia de las relaciones de precedencia dictadas

por el problema que se está resolviendo.

La sincronización entre procesos es necesaria para preservar la integridad del

sistema y prevenir problemas de tiempo producidos por el acceso concurrente

a recursos compartidos por múltiples procesos.

En general, los procesos cooperantes deben sincronizarse siempre que

intenten usar recursos compartidos por varios de ellos, tales como estructuras

de datos o dispositivos físicos comunes. El fallo en diseño de protocolos

apropiados de sincronización y en obligar su uso por cada proceso que utiliza

recursos comunes, produce frecuentemente un comportamiento erróneo del

sistema y rupturas que son notablemente difíciles de depurar.

La concurrencia puede producir un incremento de la productividad cuando se

implementan correctamente, pero puede también degradar la fiabilidad cuando

la sincronización impropia entre procesos contamina el sistema con errores

artificios de tiempo.

http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/MonogSO/COORD02.htm

http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/MonogSO/SOMA.htm

http://exa.unne.edu.ar/depar/areas/informatica/SistemasOperativos/MonogSO/REPLIC02.html


Introducción a la concurrencia de datos en ADO.NET

Cuando varios usuarios intentan modificar datos al mismo tiempo, es necesario

establecer controles para impedir que las modificaciones de un usuario influyan

negativamente en las de otros. El sistema mediante el cual se controla lo que

sucede en esta situación se denomina control de concurrencia.

Tipos de control de concurrencia

En general, existen tres formas comunes para administrar la concurrencia en

una base de datos:

Control de concurrencia pesimista:

Una fila no está disponible para los usuarios desde el momento en que

se obtiene el registro hasta que se actualiza en la base de datos.

Control de concurrencia optimista:

Una fila no está disponible para otros usuarios mientras los datos se

estén actualizando. La actualización examina la fila de la base de datos

y determina si se han realizado cambios. Si se intenta actualizar un

registro que ya se ha modificado, se produce una infracción de

concurrencia.

"El último gana":

Una fila no está disponible para otros usuarios mientras los datos se

estén actualizando. Sin embargo, no se intenta comparar las

actualizaciones con el registro original; simplemente, el registro se

escribe, con la posibilidad de sobrescribir los cambios realizados por

otros usuarios desde la última vez que se actualizaron los registros.


Concurrencia pesimista

Normalmente, la concurrencia pesimista se utiliza por dos razones. En primer

lugar, a veces existe una gran contienda por los mismos registros. El costo de

bloquear los datos es menor que el de deshacer los cambios cuando se

producen conflictos de concurrencia.

La concurrencia pesimista es útil también en situaciones en las que no es

conveniente que cambie el registro durante una transacción. Un buen ejemplo

sería una aplicación de inventario.

Consideremos que el representante de una compañía va a comprobar el

inventario para un posible cliente. Lo normal sería bloquear el registro hasta

que se generase un pedido, lo que, en líneas generales, identificaría el artículo

con el estado de pedido y lo quitaría del inventario disponible.

Si no se generase ningún pedido, el bloqueo se liberaría para que otros

usuarios que comprobasen el inventario obtuviesen un recuento exacto del

inventario disponible.

No obstante, el control de concurrencia pesimista no es posible en una

arquitectura desconectada. Las conexiones se abren sólo el tiempo suficiente

para leer los datos o actualizarlos, por lo que los bloqueos no se pueden

mantener durante períodos de tiempo prolongados. Además, una aplicación

que mantiene los bloqueos durante períodos de tiempo prolongados no es

escalable.

Nota

Si el origen de datos subyacente admite las transacciones, puede simular la

concurrencia pesimista mediante la actualización de los datos dentro de una

transacción. Para obtener más información, vea Características que

proporciona System.Transactions.

http://msdn.microsoft.com/es-es/library/0abf6ykb(v=vs.80).aspx

http://msdn.microsoft.com/es-es/library/0abf6ykb(v=vs.80).aspx


Concurrencia optimista

En la concurrencia optimista, los bloqueos se establecen y mantienen sólo

mientras se está teniendo acceso a la base de datos. Los bloqueos impiden

que otros usuarios intenten actualizar registros en ese mismo instante. Los

datos están siempre disponibles, excepto durante el momento preciso en que

está teniendo lugar una actualización. Para obtener más información, vea

Utilizar concurrencia optimista.

Cuando se intenta realizar una actualización, se compara la versión original de

una fila modificada con la fila existente en la base de datos. Si las dos son

diferentes, la actualización no se realiza debido a un error de concurrencia. En

ese instante, es de su responsabilidad la reconciliación de las dos filas

mediante su propia lógica de empresa.

El último gana

Con la técnica de "el último gana", no se realiza ninguna comprobación de los

datos originales y la actualización simplemente se escribe en la base de datos.

Es comprensible que se pueda producir el siguiente escenario:

El usuario A obtiene un registro de la base de datos.

El usuario B obtiene el mismo registro de la base de datos, lo modifica y

devuelve a la base de datos el registro actualizado.

El usuario A modifica el registro "antiguo" y lo devuelve a la base de

datos.

En el escenario anterior, los cambios que realizó el usuario B no los ve nunca

el usuario A. Asegúrese de que esta situación sea aceptable si tiene previsto

usar el planteamiento "el último gana" del control de concurrencia.

Control de concurrencia en ADO.NET y Visual Studio

ADO.NET y Visual Studio utilizan la concurrencia optimista porque la

arquitectura de datos se basa en datos desconectados.

http://msdn.microsoft.com/es-es/library/aa0416cz(v=vs.80).aspx


Por ello, es necesario agregar lógica de empresa para resolver los problemas

de la concurrencia optimista.

Si decide utilizar la concurrencia optimista, existen dos métodos generales para

determinar si se han producido cambios: el planteamiento del número de

versión (números de versión reales o marcas de fecha y hora) y el

planteamiento de guardar todos los valores.

Planteamiento del número de versión

En el planteamiento del número de versión, el registro que se va a actualizar

debe tener una columna que contenga una marca de fecha y hora o un número

de versión. La marca de fecha y hora o el número de versión se guardan en el

cliente cuando se lee el registro. Después, se hace que el valor forme parte de

la actualización.

Una forma de controlar la concurrencia es actualizar sólo si el valor de la

cláusula WHERE coincide con el valor del registro.

La representación SQL de este planteamiento es:

Copier

UPDATE Table1 SET Column1 = @newvalue1, Column2 = @newvalue2

WHERE DateTimeStamp = @origDateTimeStamp

Alternativamente, se puede realizar la comparación con el número de versión:

Copiar

UPDATE Table1 SET Column1 = @newvalue1, Column2 = @newvalue2

WHERE RowVersion = @origRowVersionValue

Si las marcas de fecha y hora o los números de versión coinciden, el registro

del almacén de datos no ha cambiado y se puede actualizar de manera segura

con los nuevos valores del conjunto de datos. Si no coinciden, se devuelve un

error. Puede escribir código para implementar esta forma de comprobar la

concurrencia en Visual Studio.


También deberá escribir código para responder a los posibles conflictos de

actualización. Para mantener la exactitud de la marca de fecha y hora o el

número de versión, necesita configurar un desencadenador en la tabla para

que se actualice cuando se produzca un cambio en alguna fila.

Planteamiento de guardar todos los valores

Una alternativa al uso de una marca de fecha y hora o un número de versión es

obtener copias de todos los campos cuando se lea el registro. El objeto

DataSet de ADO.NET mantiene dos versiones de cada registro modificado: una

versión original (la que se leyó originalmente del origen de datos) y una versión

modificada que representa las actualizaciones del usuario.

Cuando se intenta volver a escribir el registro en el origen de datos, se

comparan los valores originales de la fila de datos y el registro del origen de

datos. Si coinciden, significa que el registro de la base de datos no ha

cambiado desde que se leyó.

En ese caso, los valores modificados del conjunto de datos se escriben en la

base de datos sin problemas. Cada uno de los cuatro comandos del adaptador

de datos (DELETE, INSERT, SELECT y UPDATE) tiene una colección de

parámetros. Cada comando tiene parámetros para los valores originales y para

los valores actuales (o modificados).

Nota

Cuando se agregan registros nuevos (comando INSERT), sólo se requieren los

valores actuales, ya que no existe ningún registro original; cuando se quitan

registros (comando DELETE), sólo se requieren los valores originales para

poder localizar el registro que se desea eliminar.

http://msdn.microsoft.com/es-es/library/system.data.dataset(v=vs.80).aspx


En el ejemplo siguiente se muestra el texto de un comando del conjunto de

datos que actualiza una tabla Customers típica. El comando se especifica para

SQL dinámico y para la concurrencia optimista.

Copiar

UPDATE Customers SET CustomerID = @currCustomerID, CompanyName =

@currCompanyName, ContactName = @currContactName,ContactTitle =

currContactTitle, Address = @currAddress, City = @currCity, PostalCode =

@currPostalCode, Phone = @currPhone, Fax = @currFax

WHERE (CustomerID = @origCustomerID) AND (Address = @origAddress OR

@origAddress IS NULL AND Address IS NULL) AND (City = @origCity OR

@origCity IS NULL AND City IS NULL)

AND (CompanyName = @origCompanyName OR @origCompanyName IS

NULL AND CompanyName IS NULL) AND (ContactName =

@origContactName OR @origContactName IS NULL AND ContactName IS

NULL) AND (ContactTitle = @origContactTitle OR @origContactTitle IS NULL

AND ContactTitle IS NULL)

AND (Fax = @origFax OR @origFax IS NULL AND Fax IS NULL) AND

(Phone = @origPhone OR @origPhone IS NULL AND Phone IS NULL) AND

(PostalCode = @origPostalCode OR @origPostalCode IS NULL AND

PostalCode IS NULL);

SELECT CustomerID, CompanyName, ContactName, ContactTitle, Address,

City,

PostalCode, Phone, Fax

FROM Customers WHERE (CustomerID = @currCustomerID)


Tenga en cuenta que los nueve parámetros de la instrucción SET representan

los valores actuales que se escribirán en la base de datos, mientras que los

nueve parámetros de la instrucción WHERE representan los valores originales

que se utilizan para encontrar el registro original.

Los nueve primeros parámetros de la instrucción SET se corresponden con los

nueve primeros parámetros de la colección de parámetros. Estos parámetros

tendrían su propiedad SourceVersion establecida en Current.

Los nueve parámetros siguientes de la instrucción WHERE se utilizan para la

concurrencia optimista. Estos marcadores de posición se corresponderían con

los nueve parámetros siguientes de la colección de parámetros, y cada uno de

estos parámetros tendría la propiedad SourceVersion establecida en Original.

La instrucción SELECT se utiliza para actualizar el conjunto de datos después

de que se haya producido la actualización. Se genera cuando se establece la

opción Actualizar el conjunto de datos del cuadro de diálogo Opciones de

generación SQL avanzadas.

Nota

En la instrucción SQL anterior se utilizan parámetros con nombre, mientras que

los comandos OleDbDataAdapter usan signos de interrogación (?) como

marcadores de posición de los parámetros.

De manera predeterminada, Visual Studio crea estos parámetros

automáticamente si selecciona la opción Concurrencia optimista en el Asistente

para la configuración del adaptador de datos. Debe decidir si desea agregar

código para controlar los errores basándose en las necesidades de su

empresa. ADO.NET proporciona un objeto DBConcurrencyException que

devuelve la fila que infringe las reglas de concurrencia. Para obtener más

información, vea Cómo: Controlar errores de concurrencia.

http://msdn.microsoft.com/es-es/library/system.data.oledb.oledbdataadapter(v=vs.80).aspx

http://msdn.microsoft.com/es-es/library/system.data.dbconcurrencyexception(v=vs.80).aspx

http://msdn.microsoft.com/es-es/library/y8fyz6xy(v=vs.80).aspx


CONTROL DE CONCURRENCIA EN BASES DE DATOS

El control de transacciones concurrentes en una base de datos brinda un

eficiente desempeño del Sistema de Base de Datos, puesto que permite

controlar la ejecución de transacciones que operan en paralelo, accesando a

información compartida y, por lo tanto, interfiriendo potencialmente unas con

otras.

El hecho de reservar un asiento en una avión mediante un sistema basado en

aplicaciones web, cuando decenas de personas en el mundo pueden reservarlo

también, nos da una idea de lo importante y crucial que es el control de

concurrencia en un sistema de base de datos a mediana o gran escala.

Otro ejemplo en el que podemos observar la incidencia del control de

concurrencia en el siguiente: en una Base de Datos bancaria podría ocurrir que

se paguen dos cheques en forma simultánea sobre una cuenta que no tiene

saldo suficiente para cubrirlos en su totalidad, esto es posible evitarlo si se

tiene un control de concurrencia.

TRANSACCIONES

Los sistemas que tratan el problema de control de concurrencia permiten que

sus usuarios asuman que cada una de sus aplicaciones se ejecutan

atómicamente, como si no existieran otras aplicaciones ejecutándose

concurrentemente.

Esta abstracción de una ejecución atómica y confiable de una aplicación se

conoce como una transacción.

Un algoritmo de control de concurrencia asegura que las transacciones se

ejecuten atómicamente controlando la intercalación de transacciones

concurrentes, para dar la ilusión de que las transacciones se ejecutan

seriamente, una después de la otra, sin ninguna intercalación.

http://www.monografias.com/trabajos14/control/control.shtml

http://www.monografias.com/trabajos34/base-de-datos/base-de-datos.shtml

http://www.monografias.com/trabajos15/indicad-evaluacion/indicad-evaluacion.shtml

http://www.monografias.com/trabajos11/teosis/teosis.shtml

http://www.monografias.com/trabajos11/basda/basda.shtml

http://www.monografias.com/trabajos7/sisinf/sisinf.shtml

http://www.monografias.com/trabajos5/laweb/laweb.shtml

http://www.monografias.com/trabajos6/dige/dige.shtml#evo

http://www.monografias.com/trabajos11/opertit/opertit.shtml#CHEQ


http://www.monografias.com/trabajos15/algoritmos/algoritmos.shtml

http://www.monografias.com/


Las ejecuciones intercaladas cuyos efectos son los mismos que las

ejecuciones seriales son denominadas serializadles y son correctos ya que

soportan la ilusión de la atomicidad de las transacciones.

El concepto principal es el de transacción. Informalmente, una transacción es la

ejecución de ciertas instrucciones que accesan a una base de datos

compartida. El objetivo del control de concurrencia y recuperación es asegurar

que dichas transacciones se ejecuten atómicamente, es decir:

Cada transacción accede a información compartida sin interferir con otras

transacciones, y si una transacción termina normalmente, todos sus efectos

son permanentes, en caso contrario no tiene afecto alguno.

Una base de datos está en un estado consistente si obedece todas las

restricciones de integridad (significa que cuando un registro en una tabla haga

referencia a un registro en otra tabla, el registro correspondientes debe existir)

definidas sobre ella.

Los cambios de estado ocurren debido a actualizaciones, inserciones y

supresiones de información. Por supuesto, se quiere asegurar que la base de

datos nunca entre en un estado de inconsistencia.

Sin embargo, durante la ejecución de una transacción, la base de datos puede

estar temporalmente en un estado inconsistente.

El punto importante aquí es asegurar que la base de datos regresa a un estado

consistente al fin de la ejecución de una transacción.

http://www.monografias.com/trabajos10/teca/teca.shtml

http://www.monografias.com/trabajos16/objetivos-educacion/objetivos-educacion.shtml

http://www.monografias.com/trabajos12/elorigest/elorigest.shtml

http://www.monografias.com/trabajos7/regi/regi.shtml

http://www.monografias.com/


EJEMPLOS DE CONCURRENCIA

EL PROBLEMA DE LA RECUPERABILIDAD:

Ejemplo 1:

H1= Write1(X,2); Read2(X); Write2(Y,3); Commit2.

Supongamos que inicialmente los item X e Y tienen un valor igual a 1.

Ahora supongamos que T1 aborta y por lo tanto debería hacer un rollback y

Volver X al valor anterior- y entonces luego T2 debería también abortar y hacer

Un rollback, porque leyó un valor sucio que le dejó T1, pero si lo hacemos

Estaríamos violando la semántica del commit y esto trae confusión.

Llegamos a una situación en el que estado consistente anterior de la BD es

Irrecuperable.

Para evitar esta situación deberíamos demorar el commit de T2

Ejemplo 2:

H2= Write1(X,2); Read2(X); Write2(Y,3); Abort1.

Supongamos un caso similar al anterior pero donde T1 abortó y por lo tanto

Todavía podemos recuperar el estado consistente anterior abortando T2.

Pero sin embargo esto nos puede llevar a la situación no deseada de aborts

En cascada.

Para evitar esta situación deberíamos demorar cada Read(X) hasta que los

Correspondientes Ti que previamente hicieron un Write(X,val) hayan hecho

Abort o commit.


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?


6-.¿Que son los abrazos mortales?

7-.¿Que sinconizacion de procesos?

8-.¿Que tipos de concurrencia en ADO.NET hay?

9-.¿Que entendió por control de concurrencia en base de datos?

10-.De una explicación de lo que comprendió en los ejemplo 1 y 2 de

concurrencia de la pag 98.


BASES DE DATOS

DISTRIBUIDAS

Objetivos del capítulo IV

1. Comprender y analizar el concepto Bases de Datos

Distribuidas.

2. Conocer la administración de DDBMS.

3. Conocer el Diseño de DDBMS.

4. Comprender los tipos de Base Datos Distribuidas.

Programa de consulta o transacción



DTMx

DTMy

DTMz

DBMw

DBMx

DBMy

BDw

BDx

BDy

Nodo z

Nodo y

Nodo x

DDBMS Interfaz de solicitud

Interfaz de acción

Nodo w

DDB


INTRODUCCION

En un sistema de base de datos distribuida, los datos se almacenan en varios

computadores. Los computadores de un sistema distribuido se comunican

entre sí a través de diversos medios de comunicación, tales como cables de

alta velocidad o líneas telefónicas.

No comparten la memoria principal ni el reloj.

Los procesadores de un sistema distribuido pueden variar en cuanto su tamaño

y función. Pueden incluir microcomputadores pequeños, estaciones de trabajo

y sistemas de computadores grandes de aplicación general.

Estos procesadores reciben diferentes nombres, tales como localidades, nodos

o computadores.

Un sistema distribuido de bases de datos consiste en un conjunto de

localidades, cada uno de las cuales puede participar en la ejecución de

transacciones que accedan a datos de una o varias localidades.

La diferencia principal entre los sistemas de base de datos centralizados y

distribuidos es que, en los primeros, los datos residen en una sola localidad,

mientras que, en los últimos, se encuentran en varias localidades.


Transacciones y Administradores de una DDBMS

El sistema de administración de base de datos distribuida (DDBMS), está

formado por las transacciones y los administradores de base de datos

distribuidos de todas las computadoras. Tal y como se muestra, tal DDBMS es

un esquema genérico que implica un conjunto de programas que operan en

diversas computadoras. Estos programas pueden ser subsistemas de un

producto único DDBMS, concesionado por un sólo fabricante, o también

pudiera resultar una colección de programas de fuentes dispares: algunos

concesionados por fabricantes, y algunos otros escritos en casa. El propósito

de esta figura es ilustrar las funciones que deban atenderse en el

procesamiento de bases de datos distribuidas.

Administrador de transacciones distribuidas (DTM):

Es un programa que recibe 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 función importante del DTM es

coordinar y controlar dichas acciones. Dependiendo de la naturaleza de la

aplicación del DDBMS, el DTM puede ser proporcionado como parte de

DDBMS o puede desarrollarse en casa por la organización que pone en

práctica el sistema distribuido. En aplicaciones menos complejas, una parte de

sus funciones puede ser llevada a cabo por personas, siguiendo sólo

procedimientos manuales.

Administrador de la base de datos (DBM):

Es un programa que procesa cierta porción de la base de datos distribuida,

como es el hecho de recuperar y actualizar datos del usuario y generales, de

acuerdo con comandos de acción recibidos de los DTM. El DBM puede ser un

subconjunto de un producto DDBMS, o ser también un DBMS comercial no

distribuido.


En algunos casos, el DDBMS pudiera contener diferentes productos DBMS.

Un nodo es una computadora que ejecuta un DTM, un DBM, o inclusive ambos.

Un nodo de transacción procesa un DTM, y un nodo de base de datos procesa

un DBM y su base de datos': En la Figura 17-1, el Nodo W es un nodo de base

de datos ejecutando DBMwY almacenando BDw. El Nodo X es tanto un nodo

de transacción como de base de datos con DTMx' DBMx y BDx. De modo

similar, el Nodo Y es tanto un nodo de transacción como de base de datos,

pero el Nodo Z es solamente un nodo de transacción.

Los programas de consulta o de transacción se comunican con los DTM a

través de solicitudes parecidas a las solicitudes de acción del DBMS. Ejemplos

son SELECT EMPLOYEE WHERE E# EQ 123 o bien STORE DUE-DATE.

Estas solicitudes operan sobre estructuras lógicas. El programa de consulta o

de aplicación no se refiere a ninguna instancia física en particular de la

estructura.

Los DTM se comunican con los DBM por medio de acciones a ejecutarse en

ocurrencias específicas de datos. Por lo tanto, si la nueva ocurrencia de DUE-

DA TE debe almacenarse en DBx y en DBy, el DTM traducirá la solicitud

STORE DUE-DA TE en dos acciones. Una se dirigirá a DBMx para almacenar

los nuevos datos, y la segunda se dirigirá a DBMy para a su vez almacenar tal

información. En principio, las solicitudes y las acciones pueden también diferir

en términos de su nivel de abstracción. Por ejemplo, se puede expresar una

solicitud en términos de un objeto y puede ser traducida en acciones o

expresada en términos de relaciones compuestas distribuidas o de archivo. A la

fecha, sin embargo, no existe un DDBMS como éste.

VENTAJAS DEL PROCESAMIENTO DISTRIBUIDO

Existen cuatro ventajas del procesamiento de base de datos distribuido. La

primera, puede dar como resultado un mejor rendimiento que el que se obtiene

por un procesamiento centralizado. Los datos pueden colocarse cerca del

punto de su utilización, de forma que el tiempo de comunicación sea más corto.

Varias computadoras operando en forma simultánea pueden entregar más

volumen de procesamiento que una sola computadora.


Figura 2

Un negocio distribuido geográficamente

Segundo, los datos duplicados aumentan su confiabilidad. Cuando falla una

computadora, se pueden obtener los datos extraídos de otras computadoras.

Los usuarios no dependen de la disponibilidad de una sola fuente para sus

datos. Una tercera ventaja es que los sistemas distribuidos pueden variar su

tamaño de un modo más sencillo. Se pueden agregar computadoras

adicionales a la red conforme aumentan el número de usuarios y su carga de

procesamiento. A menudo es más fácil y más barato agregar una nueva

computadora más pequeña que actualizar una computadora única y

centralizada. Después, si la carga de trabajo se reduce, el tamaño de la red

también puede reducirse.

Por último, los sistemas distribuidos se pueden adecuar de una manera más

sencilla a las estructuras de la organización de los usuarios. La Figura 2

muestra la organización de un fabricante distribuido geográficamente.

Planta A

Planta B

Planta C

Almacén


Los gerentes generales de cada una de las plantas poseen una enorme

autoridad y libertad en la operación de sus instalaciones. Si tales plantas

dependieran de una computadora única centralizada, la arquitectura de sistema

entraría en conflicto con la filosofía y las políticas operacionales de la empresa.

Incluso en organizaciones más centralizadas, el procesamiento distribuido

ofrece una mayor flexibilidad para adecuarse a la estructura organizacional, de

lo que permite el procesamiento centralizado.

DESVENTAJAS DEL PROCESAMIENTO DISTRIBUIDO

Las primeras dos desventajas de las bases de datos distribuidas son las

mismas que las dos primeras ventajas. Primero, el rendimiento puede ser peor

para el procesamiento distribuido que para el procesamiento centralizado.

Depende de la naturaleza de la carga de trabajo, la red, el DDBMS y las

estrategias utilizadas de concurrencia y de falla, así como las ventajas del

acceso local a los datos y de los procesadores múltiples, ya que éstos pueden

ser abrumados por las tareas de coordinación y de control requeridas. Tal

situación es probable cuando la carga de trabajo necesita un gran número de

actualizaciones concurrentes sobre datos duplicados, y que deben estar muy

distribuidos.

Segundo, el procesamiento de base de datos distribuida puede resultar menos

confiable que el procesamiento centralizado. De nuevo, depende de la

confiabilidad de las computadoras de procesamiento, de la red, del DDBMS, de

las transacciones y de las tasas de error en la carga de trabajo. Un sistema

distribuido puede estar menos disponible que uno centralizado. Estas dos

desventajas indican que un procesamiento distribuido no es ninguna panacea.

A pesar de que tiene la promesa de un mejor rendimiento y de una mayor

confiabilidad, tal promesa no está garantizada.


Figura 3

Ventajas y desventajas del procesamiento de una base de datos distribuida

Una tercera desventaja es su mayor complejidad, a menudo se traduce en altos

gastos de construcción y mantenimiento. Ya que existen más componentes de

hardware, hay más cantidad de cosas por aprender y más interfaces

susceptibles de fallar. El control de concurrencia y recuperación de fallas puede

convertirse en algo complicado y difícil de implementar, puede empujar a una

mayor carga sobre programadores y personal de operaciones y quizá se

requiera de personal más experimentado y más costoso.

El procesamiento de bases de datos distribuido es difícil de controlar. Una

computadora centralizada reside en un entorno controlado, con personal de

operaciones que supervisa muy de cerca, y las actividades de procesamiento

pueden ser vigiladas, aunque a veces con dificultad. En un sistema distribuido,

las computadoras de proceso, residen muchas veces en las áreas de trabajo

de los usuarios. En ocasiones el acceso físico no está controlado, y los

procedimientos operativos son demasiado suaves y efectuados por personas

que tienen escasa apreciación o comprensión sobre su importancia. En

sistemas centralizados, en caso de un desastre o catástrofe, la recuperación

puede ser más difícil de sincronizar.

VENTAJAS Mayor rendimiento Mayor confiabilidad Cambia de tamaño con facilidad Adecuado fácilmente a la estructura de la organización

DESVENTAJAS Peor rendimiento Menor confiabilidad Mayor complejidad Costos más altos Difícil de controlar


Estructura de Base de Datos Distribuidas

Un sistema distribuido de base de datos consiste en un conjunto de

localidades, cada una de las cuales mantiene un sistema de base de datos

local. Cada localidad puede procesar transacciones locales, o bien

transacciones globales entre varias localidades, requiriendo para ello

comunicación entre ellas.

Las localidades pueden conectarse físicamente de diversas formas, las

principales son:

Red totalmente conectada

Red prácticamente conectada

Red con estructura de árbol

Red de estrella

Red de anillo

Las diferencias principales entre estas configuraciones son:

Costo de instalación: El coste de conectar físicamente las localidades

del sistema

Cost0 de comunicación: El coste en tiempo y dinero que implica enviar

un mensaje desde la localidad A a la B.

Fiabilidad: La frecuencia con que falla una línea de comunicación o una

localidad.

Disponibilidad: La posibilidad de acceder a información a pesar de fallos

en algunas localidades o líneas de comunicación.

Las localidades pueden estar dispersas, ya sea por un área geográfica extensa

(a lo largo de un país), llamadas redes de larga distancia; o en un área

reducida (en un mismo edificio), llamadas redes de área local.


Para las primeras se utilizan en la comunicación líneas telefónicas, conexiones

de microondas y canales de satélites; mientras que para las segundas se utiliza

cables coaxiales de banda base o banda ancha y fibra óptica.

Consideraciones al distribuir la base de datos

Existen varias razones para construir sistemas distribuidos de bases de datos

que incluyen compartir la información, fiabilidad y disponibilidad y agilizar el

procesamiento de las consultas. Pero también tiene sus desventajas, como

desarrollos de software más costosos, mayor posibilidad de errores y costos

extras de procesamiento.

Ventajas de la distribución de datos

La principal ventaja de los sistemas distribuidos es la capacidad de compartir y

acceder a la información de una forma fiable y eficaz.

Utilización compartida de los datos y distribución del control

La ventaja principal de compartir los datos por medio de la distribución es que

cada localidad pueda controlar hasta cierto punto los datos almacenados

localmente. En un sistema centralizado, el administrador de base de datos de

la localidad central controla la base de datos.

En un sistema distribuido existe un administrador global de la base de datos

que se encarga de todo el sistema. Parte de esta responsabilidad se delega al

administrador de base de datos de cada localidad.

Dependiendo del diseño del sistema distribuido, cada administrador local podrá

tener un grado de autonomía diferente, que se conoce como autonomía local.

La posibilidad de contar con autonomía local es en muchos casos una ventaja

importante de las bases de datos distribuidas.


Fiabilidad y disponibilidad

Si se produce un fallo en una localidad de un sistema distribuido, es posible

que las demás localidades puedan seguir trabajando. En particular, si los datos

se repiten en varias localidades, una transacción que requiere un dato

específico puede encontrarlo en más de una localidad. Así, el fallo de una

localidad no implica necesariamente la desactivación del sistema.

El sistema debe detectar cuando falla una localidad y tomar las medidas

necesarias para recuperarse del fallo.

El sistema no debe seguir utilizando la localidad que falló. Por último, cuando

se recupere o repare esta localidad, debe contarse con mecanismos para

reintegrarla al sistema con el mínimo de complicaciones.

La disponibilidad es fundamental para los sistemas de bases de datos que se

utilizan en aplicaciones de tiempo real. Por ejemplo, si una línea aérea no

puede tener acceso a la información, es posible que pierda clientes a favor de

la competencia.

Agilización del procesamiento de consultas

Si una consulta comprende datos de varias localidades, puede ser posible

dividir la consulta en varias subconsultas que se ejecuten en paralelo en

distintas localidades. Sin embargo, en un sistema distribuido no se comparte la

memoria principal, así que no todas las estrategias de intersección se pueden

aplicar en estos sistemas.

En los casos en que hay repetición de los datos, el sistema puede pasar la

consulta a las localidades más ligeras de carga.


Desventajas de la distribución de los datos

La desventaja principal de los sistemas distribuidos es la mayor complejidad

que se requiere para garantizar una coordinación adecuada entre localidades.

El aumento de la complejidad se refleja en:

Coste del desarrollo de software: es más difícil estructura un sistema de

bases de datos distribuidos y por tanto su coste es menor

Mayor posibilidad de errores: puesto que las localidades del sistema

distribuido operan en paralelo, es más difícil garantizar que los

algoritmos sean correctos.

Mayor tiempo extra de procesamiento: el intercambio de mensajes y los

cálculos adicionales son una forma de tiempo extra que no existe en los

sistemas centralizados.

Transparencia y Autonomía

En la sección anterior se vio que una relación r puede almacenarse de varias

formas en un sistema de base de datos distribuida. Es esencial que el sistema

reduzca al mínimo la necesidad de que el usuario se dé cuenta de cómo está

almacenada una relación. Como veremos. Un sistema puede ocultar los

detalles de la distribución de la información en la red.

Esto se denomina transparencia de la red. La transparencia de la red se

relaciona, en algún modo, a la autonomía local. La transparencia de la red es el

grado hasta el cual los usuarios del sistema pueden ignorar los detalles del

diseño distribuido.

La autonomía local es el grado hasta el cual el diseñador o administrador de

una localidad pueden ser independientes del resto del sistema distribuido.


Los temas de transparencia y autonomía serán considerados desde los

siguientes puntos de vista:

Nombre de los datos.

Repetición de los datos.

Fragmentación de los datos.

Localización de los fragmentos y copias.

Asignación de nombres y autonomía local

Todo elemento de información de una base de datos debe tener un nombre

único. Esta propiedad se asegura fácilmente en una base de datos que no esté

distribuida. Sin embargo, en una base de datos distribuida, las distintas

localidades deben asegurarse no utilizar el mismo nombre para dos datos

diferentes.

Una solución para este problema es requerir que se registren todos los

nombres en un asignador central de nombres. Sin embargo, este enfoque tiene

varias desventajas:

Es posible que el asignador de nombres se convierta en un cuello de

botella..

Si el asignador de nombres se cae, es posible que ninguna de las

localidades del sistema distribuido pueda seguir trabajando.

Se reduce la autonomía local, ya que la asignación de nombres se

controla de forma centralizada.

Un enfoque diferente que origina una mayor autonomía local es exigir que cada

localidad ponga como prefijo un identificador de localidad a cualquier nombre

que genere. Esto garantiza que dos localidades nunca generarán el mismo

nombre (ya que cada localidad tiene un identificador único). Además, no se

requiere un control central.


Esta solución al problema de asignación de nombres, logra autonomía local,

pero no transparencia de la red, ya que se agregan identificadores de localidad

a los nombres. Así, la relación depósito podría llamarse localidad17.depósito en

vez de depósito simplemente.

Cada copia y fragmento de un elemento de información deben tener un nombre

único. Es importante que el sistema pueda determinar qué copias son copias

del mismo elemento de información y qué fragmentos son fragmentos del

mismo elemento de información.

Transparencia de la repetición y la fragmentación

No es conveniente requerir que los usuarios hagan referencia a una copia

específica de un elemento de información. El sistema debe ser el que

determine a qué copia debe acceder cuando se le solicite su lectura, y debe

modificar todas las copias cuando se produzca una petición de escritura.

Cuando se solicita un dato, no es necesario especificar la copia. El sistema

utiliza una tabla-catálogo para determinar cuáles son todas las copias de ese

dato.

De manera similar, no debe exigirse a los usuarios que sepan cómo está

fragmentado un elemento de información. Es posible que los fragmentos

verticales contengan id-duplas, que representan direcciones de duplas. Los

fragmentos horizontales pueden haberse obtenido por predicados de selección

complejos.

Por tanto, un sistema de bases de datos distribuido debe permitir las consultas

que se hagan en términos de elementos de información sin fragmentar. Esto no

presenta problemas graves, ya que siempre es posible reconstruir el elemento

de información original a partir de sus fragmentos. Sin embargo, este proceso

puede ser ineficiente.


Transparencia de localización

Si el sistema es transparente en cuanto a repetición y fragmentación, se

ocultará al usuario gran parte del esquema de la base de datos distribuida. Sin

embargo, el componente de los nombres que identifican a la localidad obliga al

usuario a darse cuenta del hecho de que cl sistema está distribuido.

La transparencia de localización se logra creando un conjunto de seudónimos o

alias para cada usuario. Así, el usuario puede referirse a los datos usando

nombres sencillos que el sistema traduce a nombres completos.

Con el uso de seudónimos, no será necesario que el usuario conozca la

localización física de un dato. Además, el administrador de la base de datos

puede cambiar un dato de una localidad a otra sin afectar a los usuarios.

Esquema completo de asignación de nombres

Ya vimos que un nombre proporcionado por el usuario debe pasar por varios

pasos de traducción antes de que pueda servir como referencia a una copia

específica de un fragmento determinado en una localidad específica.

Para ilustrar cómo funciona el esquema, consideramos un usuario que se

encuentra en la sucursal 1 (L1).

Este usuario emplea el seudónimo depósito-local para el fragmento local

depósito-F1 de la relación deposito. Cuando este usuario hace referencia a

depósito-local, el subsistema de procesamiento de consultas busca depósito-

local en la tabla de seudónimos y la sustituye por Ll.depósito.F1. Es posible

que L1.depósito.Fl esté repetido.

Si es así, debe consultarse la tabla de copias para elegir una copia. Esta copia

podría también estar fragmentada, lo que haría necesario consultar la tabla de

fragmentación. En la mayor parte de los casos, sólo es preciso consultar una o

dos tablas.


Transparencia y actualizaciones

De alguna forma es más difícil hacer transparente la base de datos para

usuarios que la actualizan que para aquellos que sólo leen datos. El problema

principal es asegurarse de que se actualizan todas las copias de un dato y

también los fragmentos afectados.

En el caso más general, el problema de actualización de información repetida y

fragmentada está relacionado con el problema de actualización de vistas.

Diseño de la distribución:

Introducción

El diseño de un sistema de base de datos distribuido implica la toma de

decisiones sobre la ubicación de los programas que accederán a la base de

datos y sobre los propios datos que constituyen esta última, a lo largo de los

diferentes puestos que configuren una red de ordenadores.

La ubicación de los programas, a priori, no debería suponer un excesivo

problema dado que se puede tener una copia de ellos en cada máquina de la

red (de hecho, en este documento se asumirá que así es). Sin embargo, cuál

es la mejor opción para colocar los datos: en una gran máquina que albergue a

todos ellos, encargada de responder a todas las peticiones del resto de las

estaciones - sistema de base de datos centralizado -, o podríamos pensar en

repartir las relaciones, las tablas, por toda la red.

En el supuesto que nos decantásemos por esta segunda opción, ¿qué criterios

se deberían seguir para llevar a cabo tal distribución? ¿Realmente este

enfoque ofrecerá un mayor rendimiento que el caso centralizado? ¿Podría

optarse por alguna otra alternativa?


Tradicionalmente se ha clasificado la organización de los sistemas de bases de

datos distribuidos sobre tres dimensiones: el nivel de compartición, las

características de acceso a los datos y el nivel de conocimiento de esas

características de acceso.

El nivel de compartición presenta tres alternativas: inexistencia, es decir, cada

aplicación y sus datos se ejecutan en un ordenador con ausencia total de

comunicación con otros programas u otros datos; se comparten sólo los datos y

no los programas, en tal caso existe una réplica de las aplicaciones en cada

máquina y los datos viajan por la red; y, se reparten datos y programas, dado

un programa ubicado en un determinado sitio, éste puede solicitar un

Enfoque de la distribución.

Servicio a otro programa localizado en un segundo lugar, el cual podrá acceder

a los datos situados en un tercer emplazamiento. Como se comentó líneas

atrás, en este caso se optará por el punto intermedio de compartición.

Respecto a las características de acceso a los datos existen dos alternativas

principalmente: el modo de acceso a los datos que solicitan los usuarios puede

ser estático, es decir, no cambiará a lo largo del tiempo, o bien, dinámico.

El lector podrá comprender fácilmente la dificultad de encontrar sistemas

distribuidos reales que puedan clasificarse como estáticos. Sin embargo, lo

realmente importante radica, estableciendo el dinamismo como base, cómo de

dinámico es, cuántas variaciones sufre a lo largo del tiempo.

Esta dimensión establece la relación entre el diseño de bases de datos

distribuidas y el procesamiento de consultas.

La tercera clasificación es el nivel de conocimiento de las características de

acceso. Una posibilidad es, evidentemente, que los diseñadores carezcan de

información alguna sobre cómo los usuarios acceden a la base de datos.


Es una posibilidad teórica, pero sería muy laborioso abordar el diseño de la

base de datos con tal ausencia de información. Lo más práctico sería conocer

con detenimiento la forma de acceso de los usuarios o, en el caso de su

imposibilidad, conformarnos con una información parcial de ésta.

El problema del diseño de bases de datos distribuidas podría enfocarse a

través de esta trama de opciones. En todos los casos, excepto aquel en el que

no existe compartición, aparecerán una serie de nuevos problemas que son

irrelevantes en el caso centralizado.

A la hora de abordar el diseño de una base de datos distribuida podremos optar

principalmente por dos tipos de estrategias: la estrategia ascendente y la

estrategia descendente. Ambos tipos no son excluyentes, y no resultaría

extraño a la hora de abordar un trabajo real de diseño de una base de datos

que se pudiesen emplear en diferentes etapas del proyecto una u otra

estrategia.

La estrategia ascendente podría aplicarse en aquel caso donde haya que

proceder a un diseño a partir de un número de pequeñas bases de datos

existentes, con el fin de integrarlas en una sola. En este caso se partiría de los

esquemas conceptuales locales y se trabajaría para llegar a conseguir el

esquema conceptual global.

Aunque este caso se pueda presentar con facilidad en la vida real, se prefiere

pensar en el caso donde se parte de cero y se avanza en el desarrollo del

trabajo siguiendo la estrategia descendente. La estrategia descendente,

debería resultar familiar a la persona que posea conocimientos sobre el diseño

de bases de datos, exceptuando la fase del diseño de la distribución. Pese a

todo, se resumirán brevemente las etapas por las que se transcurre.


Estrategia descendente.

Todo comienza con un análisis de los requisitos que definirán el entorno del

sistema en aras a obtener tanto los datos como las necesidades de

procesamiento de todos los posibles usuarios del banco de datos. Igualmente,

se deberán fijar los requisitos del sistema, los objetivos que debe cumplir

respecto a unos grados de rendimiento, seguridad, disponibilidad y flexibilidad,

sin olvidar el importante aspecto económico.

Como puede observarse, los resultados de este último paso sirven de entrada

para dos actividades que se realizan de forma paralela. El diseño de las vistas

trata de definir las interfaces para el usuario final y, por otro lado, el diseño

conceptual se encarga de examinar la empresa para determinar los tipos de

entidades y establecer la relación entre ellas.

Existe un vínculo entre el diseño de las vistas y el diseño conceptual. El diseño

conceptual puede interpretarse como la integración de las vistas del usuario,

este aspecto es de vital importancia ya que el modelo conceptual debería

soportar no sólo las aplicaciones existentes, sino que debería estar preparado

para futuras aplicaciones.

En el diseño conceptual y de las vistas del usuario se especificarán las

entidades de datos y se determinarán las aplicaciones que funcionarán sobre la

base de datos, así mismo, se recopilarán datos estadísticos o estimaciones

sobre la actividad de estas aplicaciones. Dichas estimaciones deberían girar en

torno a la frecuencia de acceso, por parte de una aplicación, a las distintas

relaciones de las que hace uso, podría afinarse más anotando los atributos de

la relación a la que accede.

Desarrollado el trabajo hasta aquí, se puede abordar la confección del

esquema conceptual global. Este esquema y la información relativa al acceso a

los datos sirven de entrada al paso distintivo: el diseño de la distribución.


El objetivo de esta etapa consiste en diseñar los esquemas conceptuales

locales que se distribuirán a lo largo de todos los puestos del sistema

distribuido. Sería posible tratar cada entidad como una unidad de distribución;

en el caso del modelo relacional, cada entidad se corresponde con una

relación.

Resulta bastante frecuente dividir cada relación en subrelaciones menores

denominadas fragmentos que luego se ubican en uno u otro sitio. De ahí, que

el proceso del diseño de la distribución conste de dos actividades

fundamentales: la fragmentación y la asignación.

El último paso del diseño de la distribución es el diseño físico, el cual proyecta

los esquemas conceptuales locales sobre los dispositivos de almacenamiento

físico disponibles en los distintos sitios.

Las entradas para este paso son los esquemas conceptuales locales y la

información de acceso a los fragmentos. Por último, se sabe que la actividad de

desarrollo y diseño es un tipo de proceso que necesita de una monitorización y

un ajuste periódicos, para que si se llegan a producir desviaciones, se pueda

retornar a alguna de las fases anteriores.

Diseño

Existen diversas formas de afrontar el problema del diseño de la distribución.

En el primer caso, caso A, los dos procesos fundamentales, la fragmentación y

la asignación, se abordan de forma simultánea.

Esta metodología se encuentra en desuso, sustituida por el enfoque en dos

fases, caso B: la realización primeramente de la partición para luego asignar

los fragmentos generados. El resto de los casos se comentan en la sección

referente a los distintos tipos de la fragmentación.


Enfoques para realizar el diseño distributivo.

Antes de exponer las alternativas existentes de fragmentación, se desean

presentar las ventajas e inconvenientes de esta técnica. Se ha comentado en la

introducción la conveniencia de descomponer las relaciones de la base de

datos en pequeños fragmentos, pero no se ha justificado el hecho ni se han

aportado razones para efectuarlo.

Por ello, desde este punto se va a intentar aportar las razones necesarias para

llevar a cabo esa descomposición, esa fragmentación.

El principal problema de la fragmentación radica en encontrar la unidad

apropiada de distribución. Una relación no es una buena unidad por muchas

razones. Primero, las vistas de la aplicación normalmente son subconjuntos de

relaciones. Además, la localidad de los accesos de las aplicaciones no está

definida sobre relaciones enteras pero sí sobre subconjuntos de las mismas.

Por ello, sería normal considerar como unidad de distribución a estos

subconjuntos de relaciones.

Segundo, si las aplicaciones tienen vistas definidas sobre una determinada

relación (considerándola ahora una unidad de distribución) que reside en varios

sitios de la red, se puede optar por dos alternativas.

Por un lado, la relación no estará replicada y se almacena en un único sitio, o

existe réplica en todos o algunos de los sitios en los cuales reside la aplicación.

Las consecuencias de esta estrategia son la generación de un volumen de

accesos remotos innecesario.

Además, se pueden realizar réplicas innecesarias que causen problemas en la

ejecución de las actualizaciones y puede no ser deseable si el espacio de

almacenamiento está limitado.

Tercero, la descomposición de una relación en fragmentos, tratados cada uno

de ellos como una unidad de distribución, permite el proceso concurrente de las

transacciones.


También la relación de estas relaciones, normalmente, provocará la ejecución

paralela de una consulta al dividirla en una serie de subconsultas que operará

sobre los fragmentos.

Pero la fragmentación también acarrea inconvenientes. Si las aplicaciones

tienen requisitos tales que prevengan la descomposición de la relación en

fragmentos mutuamente exclusivos, estas aplicaciones cuyas vistas estén

definidas sobre más de un fragmento pueden sufrir una degradación en el

rendimiento.

Por tanto, puede ser necesario recuperar los datos de dos fragmentos y llevar a

cabo sobre ellos operación de unión y yunto , lo cual es costoso.

Un segundo problema se refiere al control semántico. Como resultado de la

fragmentación los atributos implicados en una dependencia se descomponen

en diferentes fragmentos los cuales pueden destinarse a sitios diferentes.

En este caso, la sencilla tarea de verificar las dependencias puede resultar una

tarea de búsqueda de los datos implicados en un gran número de sitios.

Tipos de fragmentación:

Dado que una relación se corresponde esencialmente con una tabla y la

cuestión consiste en dividirla en fragmentos menores, inmediatamente surgen

dos alternativas lógicas para llevar a cabo el proceso:

La división horizontal y la división vertical.

La división o fragmentación horizontal trabaja sobre las duplas, dividiendo la

relación en subrelaciones que contienen un subconjunto de las duplas que

alberga la primera.

La fragmentación vertical, en cambio, se basa en los atributos de la relación

para efectuar la división.


Estos dos tipos de partición podrían considerarse los fundamentales y básicos.

Sin embargo, existen otras alternativas.

Fundamentalmente, se habla de fragmentación mixta o híbrida cuando el

proceso de partición hace uso de los dos tipos anteriores.

La fragmentación mixta puede llevarse a cabo de tres formas diferentes:

desarrollando primero la fragmentación vertical y, posteriormente, aplicando la

partición horizontal sobre los fragmentos verticales (denominada partición VH),

o aplicando primero una división horizontal para luego, sobre los fragmentos

generados, desarrollar una fragmentación vertical (llamada partición HV), o

bien, de forma directa considerando la semántica de las transacciones.

Otro enfoque distinto y relativamente nuevo, consiste en aplicar sobre una

relación, de forma simultánea y no secuencial, la fragmentación horizontal y la

fragmentación vertical; en este caso, se generara una rejilla y los fragmentos

formaran las celdas de esa rejilla, cada celda será exactamente un fragmento

vertical y un fragmento horizontal (nótese que en este caso el grado de

fragmentación alcanzado es máximo, y no por ello la descomposición resultará

más eficiente).

Puede observarse como los casos C y D se basan en la mencionada

generación de la rejilla, con la diferencia que en el primero de ellos se produce

una fusión, una desfragmentación de las celdas, agrupándolas de la manera

más adecuada para obtener mayor rendimiento, ya que los fragmentos

generados son muy pequeños.

En el segundo caso se asignan las celdas a los sitios y luego se realiza una

rigurosa optimización de cada sitio. El caso E sería aquel en el que se utiliza la

fragmentación VH o la fragmentación HV.


Enfoques para realizar el diseño distributivo.

Grado de fragmentación.

Cuando se va a fragmentar una base de datos deberíamos pesar qué grado de

fragmentación va a alcanzar, ya que éste será un factor que influirá

notablemente en el desarrollo de la ejecución de las consultas.

El grado de fragmentación puede variar desde una ausencia de la división,

considerando a las relaciones unidades de fragmentación; o bien, fragmentar a

un grado en el cada Dupla o atributo forme un fragmento. Ante estos dos casos

extremos, evidentemente se ha de buscar un compromiso intermedio, el cual

debería establecerse sobre las características de las aplicaciones que hacen

uso de la base de datos.

Dichas características se podrán formalizar en una serie de parámetros. De

acuerdo con sus valores, se podrá establecer el grado de fragmentación del

banco de datos.

Distintos tipos de fragmentación.

Grado de Fragmentación

Cuando se va a fragmentar una base de datos deberíamos sopesar qué grado

de fragmentación va a alcanzar, ya que éste será un factor que influirá

notablemente en el desarrollo de la ejecución de las consultas.

El grado de fragmentación puede variar desde una ausencia de la división,

considerando a las relaciones unidades de fragmentación; o bien, fragmentar a

un grado en el cada Dupla o atributo forme un fragmento.

Ante estos dos casos extremos, evidentemente se ha de buscar un

compromiso intermedio, el cual debería establecerse sobre las características

de las aplicaciones que hacen uso de la base de datos.


Dichas características se podrán formalizar en una serie de parámetros. De

acuerdo con sus valores, se podrá establecer el grado de fragmentación del

banco de datos.

Reglas de corrección de la fragmentación

A continuación se enuncian las tres reglas que se han de cumplir durante el

proceso de fragmentación, las cuales asegurarán la ausencia de cambios

semánticos en la base de datos durante el proceso.

Compleción:

Si una relación R se descompone en una serie de fragmentos R1, R2, ..., Rn,

cada elemento de datos que pueda encontrarse en R deberá poder encontrarse

en uno o varios fragmentos Ri.

Esta propiedad extremadamente importante asegura que los datos de la

relación global se proyectan sobre los fragmentos sin pérdida alguna. Tenga en

cuenta que en el caso horizontal el elemento de datos, normalmente, es una

dupla, mientras que en el caso vertical es un atributo.

Reconstrucción:

Si una relación R se descompone en una serie de fragmentos R1, R2, ..., Rn,

puede definirse una operador relacional tal que el operador será diferente

dependiendo de las diferentes formas de fragmentación. La reconstrucción de

la relación a partir de sus fragmentos asegura la preservación de las

restricciones definidas sobre los datos en forma de dependencias.

Disyunción. :

Si una relación R se descompone horizontalmente en una serie de fragmentos

R1, R2, ..., Rn, y un elemento de datos di se encuentra en algún fragmento Rj,

entonces no se encuentra en otro fragmento Rk (k j). Esta regla asegura que

los fragmentos horizontales sean disjuntos.


Si una relación R se descompone verticalmente, sus atributos primarios clave

normalmente se repiten en todos sus fragmentos.

Alternativas de asignación

Partiendo del supuesto que el banco de datos se haya fragmentado

correctamente, habrá que decidir sobre la manera de asignar los fragmentos a

los distintos sitios de la red.

Cuando una serie de datos se asignan, éstos pueden replicarse para mantener

una copia. Las razones para la réplica giran en torno a la seguridad y a la

eficiencia de las consultas de lectura. Si existen muchas reproducciones de un

elemento de datos, en caso de fallo en el sistema se podría acceder a esos

datos ubicados en sitios distintos. Además, las consultas que acceden a los

mismos datos pueden ejecutarse en paralelo, ya que habrá copias en

diferentes sitios.

Por otra parte, la ejecución de consultas de actualización, de escritura,

implicaría la actualización de todas las copias que existan en la red, cuyo

proceso puede resultar problemático y complicado. Por tanto, un buen

parámetro para afrontar el grado de réplica consistiría en sopesar la cantidad

de consultas de lectura que se efectuarán, así como el número de consultas de

escritura que se llevarán a cabo.

En una red donde las consultas que se procesen sean mayoritariamente de

lectura, se podría alcanzar un alto grado de réplica, no así en el caso contrario.

Una base de datos fragmentada es aquella donde no existe réplica alguna. Los

fragmentos se alojan en sitios donde únicamente existe una copia de cada uno

de ellos a lo largo de toda la red.

En caso de réplica, podemos considerar una base de datos totalmente

replicada, donde existe una copia de todo el banco de datos en cada sitio, o

considerar una base de datos parcialmente replicada donde existan copias de

los fragmentos ubicados en diferentes sitios.


El número de copias de un fragmento será una de las posibles entradas a los

algoritmos de asignación, o una variable de decisión cuyo valor lo determine el

algoritmo. La figura de ejemplo, compara las tres alternativas de réplica con

respecto a distintas funciones de un sistema de base de datos distribuido.

Réplica total

Réplica

parcial Partición

Procesamiento de

consultas fácil dificultad similar

Gestión del directorio fácil o inexistente dificultad similar

Control de concurrencia moderado difícil fácil

Seguridad muy alta alta baja

\Realidad posible aplicación realista posible

aplicación

Información necesaria

Un aspecto importante en el diseño de la distribución es la cantidad de factores

que contribuyen a un diseño óptimo. La organización lógica de la base de

datos, la localización de las aplicaciones, las características de acceso de las

aplicaciones a la base de datos y las características del sistema en cada sitio,

tienen una decisiva influencia sobre la distribución.

La información necesaria para el diseño de la distribución puede dividirse en

cuatro categorías: la información del banco de datos, la información de la

aplicación, la información sobre la red de ordenadores y la información sobre

los ordenadores en sí. Las dos últimas son de carácter cuantitativo y servirán,

principalmente, para desarrollar el proceso de asignación. Se entrará en detalle

sobre la información empleada cuando se aborden los distintos algoritmos de

fragmentación y asignación.


Fragmentación Horizontal:

Como se ha explicada anteriormente, la fragmentación horizontal se realiza

sobre las duplas de la relación. Cada fragmento será un subconjunto de las

duplas de la relación.

Existen dos variantes de la fragmentación horizontal: la primaria y la derivada.

La fragmentación horizontal primaria de una relación se desarrolla empleando

los predicados definidos en esa relación. Por el contrario, la fragmentación

horizontal derivada consiste en dividir una relación partiendo de los predicados

definidos sobre alguna otra.

Información necesaria para la fragmentación horizontal

Información sobre la base de datos.

Esta información implica al esquema conceptual global. Es importante señalar

cómo las relaciones de la base de datos se conectan con otras. En una

conexión de relaciones normalmente se denomina relación propietaria a

aquella situada en la cola del enlace, mientras que se llama relación miembro a

la ubicada en la cabecera del vínculo.

Dicho de otra forma podemos pensar en relaciones de origen cuando nos

refiramos a las propietarias y relaciones destino cuando lo hagamos con las

miembro. Definiremos dos funciones: propietaria y miembro, las cuales

proyectarán un conjunto de enlaces sobre un conjunto de relaciones.

Además, dado un enlace, devolverán el miembro y el propietario de la relación,

respectivamente. La información cuantitativa necesaria gira en torno a la

cardinalidad de cada relación, notada como card(R).


Información sobre la aplicación.

Necesitaremos tanto información cualitativa como cuantitativa. La información

cualitativa guiará la fragmentación, mientras que la cuantitativa se necesitará

en los modelos de asignación.

La principal información de carácter cualitativo son los predicados empleados

en las consultas de usuario. Si no fuese posible investigar todas las

aplicaciones para determinar estos predicados, al menos se deberían investigar

las más importantes.

Podemos pensar en la regla "80/20" para guiarnos en nuestro análisis, esta

regla dice que el 20% de las consultas existentes acceden al 80% de los datos.

Llegados a este punto, sería interesante determinar los predicados simples.

A parte de los predicados simples, las consultas emplean predicados más

complejos resultado de combinaciones lógicas de los simples.

Una combinación especialmente interesante es la conjunción de predicados

simples, al predicado resultante se le denomina predicado mintérmino.

Partiendo de que siempre es posible transformar una expresión lógica en su

forma normal conjuntiva, usaremos los predicados mintérmino en los algoritmos

para no causar ninguna pérdida de generalidad.

Sobre la información cuantitativa necesaria relativa a las aplicaciones,

necesitaremos definir dos conjuntos de datos.

Selectividad mintérmino:

Es el número de duplas de una relación a las que accede una consulta de

acuerdo a un predicado mintérmino dado. Por ejemplo, en el ejemplo anterior,

la selectividad de m6 es 0 ya que no existe ninguna dupla que satisfaga las

condiciones; en cambio, la selectividad de m1 es 2. Notaremos la selectividad

de un mintérmino mi como sel(mi).


Frecuencia de acceso:

Es la frecuencia con la que un usuario accede a los datos. Si Q = {q1, q2, ...,

qq} es un conjunto de consultas de usuario, acc(qi) indica la frecuencia de

acceso a la consulta qi en un periodo dado.

Fragmentación horizontal primaria

Antes de presentar un algoritmo formal que lleve a cabo la fragmentación

horizontal, intentaremos explicar de manera intuitiva los procesos de

fragmentación horizontal primaria y derivada.

La fragmentación horizontal primaria se define como una operación de

selección de las relaciones propietarias del esquema de la base de datos

Ahora definiremos la fragmentación horizontal más formalmente. Un fragmento

horizontal Ri de una relación R contiene todas las duplas de R que satisfacen

un predicado mintérmino mí. Por tanto, dado un conjunto de predicados

mintérmino M, existen tantos fragmentos horizontales de la relación R como

predicados mintérmino.

Este conjunto de fragmentos horizontales también se conocen como conjuntos

de fragmentos mintérmino. En los párrafos siguientes se asumirá que la

definición de fragmentos horizontales se basa en los predicados mintérmino.

Además, el primer paso para el algoritmo de fragmentación consiste en

establecer un conjunto de predicados con ciertas propiedades.

Un aspecto importante de los predicados simples es su compleción, así como

su minimalidad. Un conjunto de predicados simples Pr se dice que es completo

si y solo si existe una probabilidad idéntica de acceder por cada aplicación a

cualquier par de duplas pertenecientes a cualquier fragmento mintérmino que

se define de acuerdo con Pr. Se puede apreciar como la definición de

compleción de un conjunto de predicados simples difiere de la regla de

compleción de la fragmentación.


El segundo paso en el proceso de fragmentación primaria consiste en derivar el

conjunto de predicados mintérmino que pueden definirse sobre los predicados

del conjunto Pr'. Estos predicados mintérmino establecen los fragmentos

candidatos para el proceso de asignación.

El establecimiento de los predicados mintérmino es trivial:

La dificultad radica en el tamaño del conjunto de predicados mintérmino, que

puede ser muy grande (de hecho, exponencial respecto al número de

predicados simples). En el paso siguiente se presentarán formas de reducir el

número de predicados mintérmino necesarios para la fragmentación.

El tercer paso aborda, como ya se ha citado, la eliminación de algunos

fragmentos mintérmino que puedan ser redundantes.

Esta eliminación se desarrolla identificando aquellos mintérminos que puedan

resultar contradictorios sobre un conjunto de implicaciones.

Fragmentación horizontal derivada

Una fragmentación horizontal derivada se define sobre una relación miembro

de acuerdo a una operación de selección especificada sobre su propietaria. Se

deben dejar claros dos puntos.

Primero, el enlace entre las relaciones propietaria y miembro se define como un

equi-yunto. Segundo, un equi-yunto puede desarrollarse a través de

semiyuntos. Este segundo punto es especialmente importante para nuestros

propósitos, ya que deseamos fraccionar una relación miembro según la

fragmentación de su propietaria, además es necesario que el fragmento

resultante se defina únicamente sobre los atributos de la relación miembro.


Las tres entradas necesarias para desarrollar la fragmentación horizontal

derivada son las siguientes:

El conjunto de particiones de la relación propietaria, la relación miembro y el

conjunto se predicados resultados de aplicar el semi-yunto entre la propietaria y

la miembro.

El algoritmo de fragmentación resulta tan trivial que no se ve la necesidad de

entrar en detalles.

Existe una posible complicación que necesita nuestro estudio. En un esquema

de base de datos, resulta frecuente que existan más de dos enlaces sobre una

relación R. En este caso, aparecen más de una posibilidad de fragmentación

horizontal derivada.

La decisión para elegir una u otra se basa en dos criterios: Uno, la

fragmentación con mejores características de yunto. Dos, la fragmentación

empleada en más aplicaciones.

Discutamos el segundo criterio primero. Resulta sencillo de establecer si

tomamos en consideración la frecuencia con la que cada aplicación accede a

los datos. Si es posible, deberíamos intentar facilitar el acceso a los usuarios

que hagan mayor uso de los datos para, de esta manera, minimizar el impacto

total del rendimiento del sistema.

Grafo de yuntos entre fragmentos.

El primer criterio, sin embargo, no es tan sencillo. Considere, por ejemplo, la

fragmentación expuesta en el ejemplo 8. El objetivo de esta fragmentación

consiste en beneficiar a la consulta que haga uso de las dos relaciones al


poder realizarse el yunto de CLIENTES y PROVINC sobre relaciones más

pequeñas (es decir, fragmentos), y posibilitar la confección de yuntos de

manera distribuida.

El primer aspecto resulta obvio. Los fragmentos de CLIENTES son más

pequeños que la propia relación CLIENTES. Por tanto, resultará más rápido

llevar a cabo el yunto de un fragmento de PROVINC con otro de CLIENTES

que trabajar con las propias relaciones.

El segundo punto, sin embargo, es más importante ya que es la esencia de las

bases de datos distribuidas. Si, además de estar ejecutando un número de

consultas en diferentes sitios, podemos ejecutar una consulta en paralelo, se

espera que el tiempo de respuesta del sistema aumente.

En el caso de yuntos, esto es posible bajo ciertas circunstancias. Considere,

por ejemplo, el grafo de yunto (los enlaces) entre los fragmentos de CLIENTES

y la derivada PROVINC. Hay únicamente un enlace entrando o saliendo de un

fragmento. De ahí, que se denomine a este grafo, grafo simple.

La ventaja de este diseño donde la relación de yunto entre los fragmentos es

simple, radica en la asignación a un sitio tanto de la propietaria como de la

miembro y los yuntos entre pares diferentes de fragmentos pueden realizarse

independientemente y en paralelo. Desgraciadamente, la obtención de grafos

de yunto simples no siempre es posible.

En tal caso, la mejor alternativa sería realizar un diseño que provoque un grafo

de yuntos fragmentados. Un grafo fragmentado consiste en dos o más

subgrafos que no están enlazados entre ellos. Por tanto, los fragmentos que se

obtengan no se distribuirán para ejecuciones paralelas de un modo tan fácil

como aquellos obtenidos a través de grafos simples, pero su asignación aún

será posible.


Procederemos ahora a probar la corrección de los algoritmos presentados con

respecto a los tres criterios enunciados:

Compleción:

La compleción de una fragmentación horizontal primaria se basa en la

selección de los predicados a usar. En la medida que los predicados

seleccionados sean completos, se garantizará que el resultado de la

fragmentación también lo será.

Partiendo de la base que el algoritmo de fragmentación es un conjunto de

predicados completos y mínimos Pr', se garantiza la compleción siempre que

no aparezcan errores al realizar la definición de Pr'. La compleción de una

fragmentación horizontal derivada es algo más difícil de definir.

La dificultad viene dada por el hecho de que los predicados que intervienen en

la fragmentación forman parte de dos relaciones. Definamos la regla de

compleción formalmente. Sea R la relación miembro de un enlace cuya

propietaria es la relación S, la cual está fragmentada como FS = {S1, S2, ...,

Sw}. Además, sea A el atributo de yunto entre R y S. Entonces para cada dupla

t de R, existirá una dupla t' de S tal que t[A] = t'[A].

Reconstrucción:

La reconstrucción de una relación global a partir de sus fragmentos se

desarrolla con el operador de unión tanto para la fragmentación horizontal

primaria como para la derivada.

Disyunción:

Resulta sencillo establecer la disyunción de la fragmentación tanto para la

primaria como para la derivada. En el primer caso, la disyunción se garantiza

en la medida en que los predicados mintérmino que determinan la


fragmentación son mutuamente exclusivos. En la fragmentación derivada, sin

embargo, implica un semi-yunto que añade complejidad al asunto.

La disyunción puede garantizarse si el grafo de yunto es simple. Si no es

simple, será necesario investigar los valores de las Duplas.

En general, no se desea juntar una dupla de una relación miembro con dos o

más duplas de una relación propietaria cuando estas duplas se encuentran en

fragmentos diferentes a los de la propietaria.

Esto no es fácil de establecer, e ilustra por qué los esquemas de la

fragmentación derivada que generan un grafo de yunto simple son siempre

más atractivos.

Fragmentación Vertical:

Recuérdese que la fragmentación vertical de una relación R produce una serie

de fragmentos R1, R2, ..., Rr, cada uno de los cuales contiene un subconjunto

de los atributos de R así como la clave primaria de R.

El objetivo de la fragmentación vertical consiste en dividir la relación en un

conjunto de relaciones más pequeñas tal que algunas de las aplicaciones de

usuario sólo hagan uso de un fragmento. Sobre este marco, una fragmentación

óptima es aquella que produce un esquema de división que minimiza el tiempo

de ejecución de las aplicaciones que emplean esos fragmentos.

La partición vertical resulta más complicada que la horizontal. Esto se debe al

aumento del número total de alternativas que tenemos disponibles. Por

ejemplo, en la partición horizontal, si el número total de predicados simples de

Pr es n, existen 2n predicados mintérminos posibles que puedan definirse.

Además, sabemos que algunos de estos predicados resultarán contradictorios

con algunas de las aplicaciones existentes, por lo que podremos reducir el

número inicial.


En el caso vertical, si una relación tiene m atributos clave no primarios, el

número de posibles fragmentos es igual a B(m), es decir el m-ésimo número de

Bell [3]. Para valores grandes de m, B(m) mm; por ejemplo, para m = 10, B(m)

115.000, para m = 15, B(m) 109, para m = 30, B(m) = 1023.

Estos valores indican que la obtención de una solución óptima de la

fragmentación vertical resultará una tarea inútil, sino nos apoyamos en el uso

de heurísticos. Existen dos enfoques heurísticos para la fragmentación vertical

de relaciones:

Agrupación:

Comienza asignando cada atributo a un fragmento, y en cada paso, junta

algunos de los fragmentos hasta que satisface un determinado criterio. La

agrupación sugirió en principio para bases de datos centralizadas y se usó

posteriormente para las bases de datos distribuidas.

Escisión:

A partir de la relación se deciden que fragmentos resultan mejores, basándose

en las características de acceso de las aplicaciones a los atributos. Esta

técnica se presentó, también, para bases de datos centralizadas.

Posteriormente, se extendió al entorno distribuido.

En este documento se tratará únicamente la técnica de escisión, ya que es más

apropiada para la estrategia descendente y porque resulta más probable

encontrar la solución para la relación entera que a partir de un conjunto de

fragmentos con un único atributo. Además, la escisión genera fragmentos no

solapados mientras que la agrupación normalmente produce fragmentos

solapados.

Dentro del contexto de los sistemas de bases de datos distribuidos, son

preferibles los fragmentos no solapados por razones obvias. Evidentemente,

los fragmentos no solapados se refieren únicamente a atributos clave no

primarios.


Antes de comenzar, vamos a aclarar un problema: la réplica de las claves de la

relación en los fragmentos. Esta es una característica de la fragmentación

vertical que permite la reconstrucción de la relación global.

Por tanto, la escisión considera únicamente aquellos atributos que no son parte

de la clave primaria.

La réplica de los atributos clave supone una gran ventaja, a pesar de los

problemas que pueda causar.

La ventaja está relacionada con el esfuerzo para mantener la integridad

semántica. Tenga en cuenta que cada dependencia (funcional, multivaluada ...)

es, de hecho, una restricción que influye sobre el valor de los atributos de las

respectivas relaciones en todo momento.

También muchas de estas dependencias implican a los atributos clave de una

relación. Si queremos diseñar una base de datos tal que los atributos clave

sean parte de una fragmento que está ubicado en un sitio, y los atributos

relacionados sean parte de otro fragmento asignado a un segundo sitio, cada

petición de actualización provocará la verificación de integridad que necesitará

de una comunicación entre esos sitios.

La réplica de los atributos clave de cada fragmento reduce esta problemática,

pero no elimina toda su complejidad, ya que la comunicación puede ser

necesaria para las restricciones de integridad que implican a las claves

primarias, así como para el control de concurrencia.

Una posible alternativa a la réplica de los atributos clave es el empleo de

identificadores de duplas, que son valores únicos asignados por el sistema a

las duplas de una relación. Mientras el sistema mantenga los identificadores,

los fragmentos permanecerán disjuntos.


Información necesaria para la fragmentación vertical

La principal información que necesitaremos se referirá a las aplicaciones. Por

tanto, este punto tratará de especificar la información que de una aplicación

que funciona sobre la base de datos podamos extraer. Teniendo en cuenta que

la fragmentación vertical coloca en un fragmento aquellos atributos a los que se

accede de manera simultánea, necesitaremos alguna medida que defina con

más precisión el concepto de simultaneidad.

Esta medida es la afinidad de los atributos, que indica la relación estrecha

existente entre los atributos. Desgraciadamente, no es muy realista esperar

que el diseñador o los usuarios puedan especificar estos valores.

Por ello, presentaremos una forma por la cual obtengamos esos valores

partiendo de datos más básicos.

El principal dato necesario relativo a las aplicaciones es la frecuencia de

acceso. Sea Q = {q1, q2, ..., qq} el conjunto de consultas de usuario

(aplicaciones) que funcionan sobre una relación R(A1, A2, ..., An).

Los vectores uso (qi,) pueden definirse muy fácilmente para cada aplicación

siempre que el diseñador conozca las aplicaciones existentes en el sistema. La

regla 80/20 expuesta páginas atrás podría resultar útil para el desarrollo de

esta tarea.

Los valores del uso de los atributos en general no son suficientes para

desarrollar la base de la escisión y la fragmentación de los atributos, ya que

estos valores no representan el peso de las frecuencias de la aplicación.

La dimensión de esta frecuencia puede incluirse en la definición de la medida

de los atributos afines afd(Ai, Aj), la cual mide el límite entre dos atributos de

una relación de acuerdo a cómo las aplicaciones acceden a ellos.


Fragmentación mixta o híbrida:

En muchos casos la fragmentación vertical u horizontal del esquema de la base

de datos no será suficiente para satisfacer los requisitos de las aplicaciones.

Como ya se citó al comienzo de este documento podemos combinar ambas,

utilizando por ello la denominada fragmentación mixta. Cuando al proceso de

fragmentación vertical le sigue una horizontal, es decir, se fragmentan

horizontalmente los fragmentos verticales resultantes, se habla de la

fragmentación mixta HV. En el caso contrario, estaremos ante una

fragmentación VH. Una característica común a ambas es la generación de

árboles que representan la estructura de fragmentación.

Considere, por ejemplo, la relación PROVINC. Recordará que se le aplicó una

fragmentación horizontal de acuerdo al valor del atributo CCODZONA

resultando cuatro fragmentos horizontales. Podríamos pensar en aplicarle una

nueva fragmentación de carácter vertical. Entonces resultarían cuatro

fragmentos horizontales divididos, por ejemplo, en dos fragmentos verticales.

En este caso el número total de fragmentos ascendería, lógicamente, a ocho.

Estructura arbórea de fragmentación mixta.

No se desea entrar en excesivos detalles sobre las reglas y condiciones para

efectuar la fragmentación mixta. Entre otras razones porque, tanto a la

fragmentación HV como la fragmentación VH, se le pueden aplicar los mismos

criterios y reglas que a la fragmentación horizontal y vertical.

Es decir, volviendo al ejemplo anterior, al cual le practicamos la fragmentación

HV, al realizar la fragmentación horizontal tal como se ha expuesto, lo que se

obtienen no son más que subrelaciones, la unión de las cuales da lugar a la

relación PROVINC. Por tanto, para fragmentar cada subrelación sería

perfectamente viable aplicarle el método de fragmentación vertical que se ha

desarrollado. Como, en este caso, se han querido generar dos fragmentos

verticales por cada uno horizontal, simplemente deberíamos confeccionar la


matriz de grupos afines (a través del algoritmo BEA) para cada fragmento

horizontal y aplicarle, posteriormente, el algoritmo de fragmentación binaria

PARTICIÓN.

También debe tenerse en cuenta el número de niveles arbóreos que se

generen, es decir, nadie impide que tras realizar una fragmentación VH,

podamos aplicar a los fragmentos resultantes una nueva fragmentación

vertical, y a estos última una nueva fragmentación horizontal, etc. Dicho

número puede ser grande, pero también será ciertamente finito.

En el caso horizontal, el nivel máximo de profundidad se alcanzará cuando

cada fragmento albergue una única dupla, mientras que en el caso vertical el

final llegará cuando cada fragmento contenga un único atributo.

Sin embargo, aunque no deba tomarse como dogma, el número de niveles no

debería superar el par (VH y HV). El porqué de esta afirmación es bien sencillo,

piense, por ejemplo, en el coste que supondría realizar la unión o el yunto de

una relación con fragmentación nivel 7. Evidentemente, el coste sería muy

elevado y ese aumento de rendimiento que se persigue al aplicar estas

técnicas, quizás, no se produzca.

Antes de pasar a estudiar el problema de la asignación se desea comentar la

técnica de fragmentación mixta basada en celdas [2]. Esta técnica se basa en

la generación de celdas de rejilla. Qué es una celda de rejilla, podríamos

definirla como un fragmento horizontal y vertical simultáneo. La técnica aplica

un algoritmo de fragmentación vertical y otro horizontal de manera concurrente

sobre la relación.

Los algoritmos realizan una fragmentación máxima, es decir, se persigue que

en cada celda únicamente haya un atributo y una dupla. Quizá el lector pueda

encontrar el método contradictorio con lo citado anteriormente respecto a la

eficiencia, dada la gran cantidad de fragmentos generados, el número es,


efectivamente, el máximo. Sin embargo, este sólo es el primer paso del

proceso.

Una vez generadas las celdas se aplica un método para optimizar la rejilla

mediante fusión o desfragmentación, de acuerdo, fundamentalmente, a las

aplicaciones que actúen sobre esos fragmentos. El método, por tanto, persigue

una fragmentación la más específica posible acorde con las aplicaciones y los

sitios existentes en la red.

Información necesaria

En esta etapa de la asignación, necesitaremos datos cuantitativos sobre la

base de datos, las aplicaciones que funcionan sobre ella, la red de

comunicaciones, las características de proceso, y el límite de almacenamiento

de cada sitio de la red.

Procederemos a discutirlos en detalle.

Información de la base de datos. Para desarrollar la fragmentación horizontal,

definimos la selectividad de los mintérminos. Ahora, necesitamos extender esta

definición a los fragmentos y definir la selectividad de un fragmento Fj con

respecto a una consulta qi. Es el número de duplas de Fj a las que se necesita

acceder para procesar qi. Este valor lo notaremos como seli(Fj). Otro elemento

informativo de los fragmentos de la base de datos es su tamaño.

El tamaño de un fragmento Fj viene dado por tamaño (Fj) = card(Fj)*long(Fj),

donde long(Fj) es la longitud (en octetos) de una tupla del fragmento Ej.

Información de los sitios. Sobre cada ordenador necesitamos conocer sus

capacidades de procesamiento y almacenamiento. Obviamente, estos valores

pueden calcularse a través de funciones elaboradas o por simples

estimaciones.


La unidad de coste de almacenar datos en el sitio Sk será denotada como

UCAk. Así mismo, especificaremos como medida de coste UPTk al coste de

procesar una unidad de trabajo en el sitio Sk. La unidad de trabajo debería ser

idéntica a aquella utilizada en las medidas RR y UR.

Información sobre la red. En nuestro modelo asumiremos la existencia de una

red simple donde el coste de comunicaciones se define respecto a una trama

de datos.

Entonces gij nota el coste de comunicación por trama entre los sitios Si y Sj.

Para permitir el cálculo del número de mensajes, usaremos tamaño como el

tamaño (en octetos) de una trama.

Es evidente que existen modelos de red mucho más elaborados que toman en

cuenta las capacidades del canal, las distancias entre sitios, las características

del protocolo, etc. Sin embargo, se cree que la derivación de estas ecuaciones

se sale fuera de este documento.

Procesamiento distribuido de consultas

Existen varios medios para calcular la respuesta a una consulta. En el caso de

sistemas centralizado, el criterio principal para determinar el costo de una

estrategia específica es el número de accesos al disco. En un sistema

distribuido es preciso tener en cuenta otros factores, como son:

El costo de transmisión de datos en la red.

El beneficio potencial que supondría en la ejecución el que varias

localidades procesaran en paralelo partes de la consulta.

El costo relativo de la transferencia de datos en la red y la transferencia de

datos entre la memoria y el disco varía en forma considerable, dependiendo del

tipo de red y de la velocidad de los discos. Por tanto, en un caso general, no

podemos tener en cuenta solo los costos del disco o los de la red. Es necesario

llegar a un equilibrio adecuado entre los dos.


Repetición y fragmentación

Considere una consulta muy sencilla: encontrar todas las duplas de la relación

depósito. Aunque la consulta es muy simple, de hecho es trivial; su

procesamiento no es trivial, ya que es posible que la relación depósito esté

fragmentada, repetido o las dos cosas, como ya se vio.

Si la relación deposito está repetida, es preciso decidir qué copia se va a

utilizar.

Si ninguna de las copias está fragmentada, se elige la copia que implique

costos de transmisión más reducidos. Pero si una copia está fragmentada, la

elección no es tan sencilla, ya que es preciso calcular varios productos o

uniones para reconstruir la relación depósito.

En tal caso, el número de estrategias para este ejemplo sencillo puede ser

grande. De hecho, la elección de una estrategia puede ser una tarea tan

compleja como hacer una consulta arbitraria.

Procesamiento de intersección simple

Considere la expresión en álgebra relacional:

cliente x deposito x sucursal

Suponemos que ninguna de las tres relaciones está repetida o fragmentada y

que cliente está almacenada en la localidad Lc, deposito en la Ld y sucursal en

la Lb. Sea Li la localidad donde se originó la consulta. El sistema debe producir

el resultado en la localidad Li. Entre las posibles estrategias para procesar esta

consulta se encuentran las siguientes:

Enviar copias de las tres relaciones a la localidad Li. Al emplear las

técnicas de procesamiento de consulta, escoger una estrategia para

procesar en forma local la consulta completa en Li.

Enviar una copia de la relación cliente a la localidad Li y calcular cliente

x depósito de Ld. Enviar cliente x depósito de Ld a Lb, donde se calcula


(cliente x depósito) x sucursal. El resultado de esta operación es enviado

a Li.

Pueden elaborarse estrategias similares a la anterior al intercambiar los

papeles de Lc, Ld y Lb.

No puede garantizarse que una estrategia sea la mejor en todos los casos.

Entre los factores que deben tomarse en cuenta están la cantidad de datos que

debe transmitirse, el costo de transmitir un bloque de datos entre dos

localidades determinadas y la velocidad de procesamiento relativa en cada

localidad.

Estrategias de intersección utilizando el paralelismo

Considere un producto de cuatro relaciones:

r1 x r2 r3 r4

Donde la relación r1 está almacenada en la localidad Li. Suponemos que el

resultado ha de presentarse en la localidad Li. Existen, por supuesto muchas

estrategias que se pueden considerar.

Un método atractivo sería utilizar la estrategia de intersección encauzada. Por

ejemplo, se puede enviar r1 a L2 y calcular r1 x r2 en L2. Al mismo tiempo se

puede enviar r3 a L4 y calcular r3 x r4 en L4.

La localidad L2 puede enviar duplas de (r1 x r2) a Li conforme se vayan

produciendo, en vez de esperar a que se calcule el producto completo. De

forma similar, L4 pude enviar duplas de (r3 x r4) a Li. Una vez que las duplas

de (r1 x r2) y (r3 x r4) lleguen a Li, esta localidad podrá empezar el cálculo de

(r1 x r2) x (r3 x r4) en paralelo con el cálculo de (r1 x r2) en L2 y de (r3 x r4) en

L4.

Estrategia de semintersección

Suponer que deseamos calcular la expresión r1 x r2, donde r1 y r2 están

almacenados en las localidades L1 y L2 respectivamente. Sean R1 y R2 los


esquemas de r1 y r2. Suponer que queremos obtener el resultado en L1. Si hay

muchas duplas de r2 que no interseccionan con ninguna de r1, entonces el

envío de r2 a S1 requiere el envío de duplas que no contribuyen al resultado.

Es conveniente borrar tales duplas antes de enviar los datos a L1,

particularmente si los costos de la red son muy elevados.

Para hacerlo vemos la siguiente estrategia:

Calcular temp1 " r1 " r2 (r1) en L1.

enviar temp1 de L1 a L2.

Calcular temp2 r2 x temp1 en L2.

Enviar temp2 de L2 a L1.

Calcular r1 x temp2 en L1.

La estrategia anterior es ventajosa particularmente cuando en el producto

participan relativamente pocas duplas de r2. Es probable que suceda esta

situación si r1 es el resultado de una expresión de álgebra relacional que

contenga la selección.

Esta estrategia es conocida como una estrategia de semiproducto, después del

operador de semiproducto, indicado por x, de álgebra relacional.

Conclusiones y consideraciones:

A lo largo de este documento se ha intentado dar una visión global y genérica

de los problemas y características que contiene el diseño de una base de datos

distribuida. Se ha hecho especial hincapié en las técnicas de fragmentación

horizontal y vertical a través de métodos y algoritmos muy frecuentes en la

literatura referida al tema.

Se espera que el lector no haya tenido demasiados problemas para su

comprensión, las técnicas son sencillas y se ha procurado incluir distintos


ejemplos para facilitar el entendimiento. Igualmente, la puesta en práctica de

los algoritmos, es decir, su codificación, no es un proceso complicado si se

poseen nociones en el desarrollo de algoritmos. Piense, por ejemplo, que los

dos algoritmos de partición vertical presentados, no hacen más que manipular

matrices.

También debería tenerse presente la existencia de enfoques de fragmentación

distintos y, posiblemente, más complejos, pero se debe pensar que más

eficientes. Sean, por ejemplo, las técnicas de fragmentación vertical basadas

en grafos, como el algoritmo de Navathe y Ra que genera en un solo pasó

fragmentos verticales.

Además, están apareciendo métodos de fragmentación mixta como el que se

ha comentado. Si bien, estos métodos son enfoques formales más que

prácticos, desarrollados por insignes investigadores en universidades, por

tanto, lejos todavía de su desarrollo comercial.

Pese a la aparición de los métodos de bases de datos distribuidas hace ya

años, parece que el salto de lo centralizado a lo distribuido a escala comercial

está por venir.

Todavía no se ha extendido suficientemente el esquema distribuido, pero se

espera que próximamente se produzca el avance definitivo. Considere los dos

componentes básicos de los sistemas de bases de datos distribuidos (la propia

base de datos y la red de ordenadores) y piense en la situación actual de la

informática.

Si las bases de datos es una de las ramas más antiguas e importantes de la

informática, muchas empresas compran ordenadores para dedicarlos

exclusivamente a la gestión de sus datos (pienso que, prácticamente, en el

100% de las PYMES se produce este hecho) y, como parece ser que se ha

asumido por parte de todo tipo de empresarios los beneficios que acarrea la

conexión de los ordenadores, la instalación de una red, se puede concluir

diciendo que el terreno ya está abonado para su extensión comercial. Sólo falta


que determinadas multinacionales decidan apostar más fuerte por este enfoque

a través de sus famosos sistemas gestores de bases de datos y que se

produzca la consolidación de la resolución de los problemas que el enfoque

distribuido acarrea.

TIPOS DE BASES DE DATOS DISTRIBUIDAS

HETEROGENEA

Las Bases de datos heterogéneas con un alto grado de autonomía local. Cada

nodo en el sistema tiene sus propios usuarios, aplicaciones y datos locales y es

el sistema el que trata con ellos directamente y sólo conecta con otros nodos

en busca de información que

no tiene.

Este tipo de base de datos se suele llamar sistema federado o federación. Se

ha hecho cada día más popular en las organizaciones, tanto por su

escalabilidad, su capacidad de mezclar distintos paquetes software y su

reducido coste al añadir nuevos nodos cuando es necesario. A diferencia de los

sistemas homogéneos, los sistemas heterogéneos pueden incluir diferentes

SGBD en los nodos. Esto los hace atractivos en grandes corporaciones, ya que

pueden mantener sus sistemas heredados antiguos (legacy systems) junto con

los..nuevos..Sistemas.

DDBMS HETEROGÉNEO

Esquema global único.

Modelo de datos y lenguaje de consultas común.

Esquema integrado.

Consultas reales distribuidas.

INTERFAZ HETEROGÉNEA

Acceso en línea a una única base de datos

No hay integración de bases de datos

El acceso usa un modelo de datos; el DBMS, otro


SISTEMA HOMOGÉNEO

Las bases de datos distribuidas homogéneas usan el mismo software de SGBD

y tienen las mismas aplicaciones en cada nodo. Tienen un esquema común y

pueden tener grados diversos de autonomía local. Pueden estar basadas en

cualquier SGBD que soporte estas características, pero no puede haber más

de un SGBD en el sistema. La autonomía local especifica cómo el sistema

funciona desde la perspectiva de los usuarios y programadores.

Por ejemplo:

Podemos tener un sistema con poca o sin autonomía local, donde todas las

peticiones se envían a un nodo central, llamado gateway. Desde aquí se asigna

al nodo que contiene esa información o aplicación requerida. Esto es lo típico

que se ve con los mirrors de sitios web muy populares a los cuales una página

central deriva las peticiones de sus usuarios dependiendo de su origen

geográfico.


CUATRO METAS PARA UN DBMS DISTRIBUIDO

Traiger y sus colegas definieron cuatro metas para un DBMS distribuido, lo que

da un excelente marco de referencia para una investigación de los temas,

problemas y soluciones propuestos para las bases de datos distribuidas. Cada

una de estas metas involucra un aspecto de transparencia.

En un sistema de base de datos distribuida la transparencia significa que las

opciones de consulta y los programas de transacciones quedan aislados de la

administración de la base de datos distribuidos, de forma tal que obtengan las

ventajas del procesamiento distribuido, sin por ello tener que involucrarse en

detalles de la distribución de la base de datos.

Los programadores y los usuarios pueden concentrarse en la naturaleza y en la

lógica del problema de la información que necesitan resolver, no viéndose

obligados a tratar asuntos que corresponden al DDBMS: para simplificar este

análisis, en el resto de este documento nos referiremos a los usuarios de

consulta y a los programas de transacción sólo como transacciones.


Las transacciones necesitan tener acceso a la base de datos vía un DDBMS

que proporcione los cuatro siguientes tipos de transparencia: localización de los

datos, duplicación de los datos, concurrencia y falla.

Lo cual significa que, en forma ideal, la transacción ni siquiera esté consciente

que los datos se encuentran distribuidos. Los cuatro temas de distribución se

manejan tras bambalinas.

TRANSPARENCIA DE LOCALIZACIÓN

Las transacciones necesitan ser independientes de la localización de un

elemento de datos particular. De no ser así, las cuestiones de localización

complicarían la lógica de la transacción.

Considere usted la empresa manufacturera que se utilizó en la Figura 2. Si el

gerente de inventarios desea mover refrigeradores de la Planta A a la Planta B,

deberán modificarse dos registros de inventario.

Suponga que los datos involucrados no están duplicados; pero que datos

puedan estar almacenados en una computadora en cualquiera de las dos

localizaciones. Si el programa que procesa esta transacción no es transparente

en lo que se refiere a localización de los datos, tendrá que considerar cuatro

casos: ambos registros en A, uno en A y uno en B, uno en B y el otro en A o

ambos en B. La lógica de la transacción se confunde por la necesidad de

considerar la localización de los datos.

La lógica sería mucho más complicada para un ejemplo más complejo, en

cualquier caso estas consideraciones son innecesarias e inapropiadas para un

programa de aplicación.

Se puede conseguir la transparencia de localización si los administradores de

transacciones distribuidas (los DTM en la Figura 1) son responsables de

determinar la localización de los datos y de emitir las acciones a los DBM

apropiados, lo cual se puede llevar a cabo si los DTM poseen acceso a los


directorios de las localizaciones de los datos. Si los datos se mueven, sólo el

DTM necesita involucrarse. Todas las transacciones quedan aisladas de la

modificación en la localización.

TRANSPARENCIA DE DUPLICACIÓN

Las transacciones son accesibles a la duplicación si pueden procesarse sin

saber cuántas veces, o incluso si los datos están duplicados. La transacción

puede actuar como si todos los datos estuvieran almacenados sólo una vez en

nada más un nodo.

Con la transparencia de duplicación, se pueden crear nuevos duplicados, o los

duplicados existentes pueden ser eliminados, sin provocar efecto alguno sobre

la transacción del usuario o el procesamiento de la consulta.

Para proporcionar transparencia en la duplicación, los administradores de

transacciones deben traducir las solicitudes de procesamiento de transacción

en acciones para los administradores de la base de datos. Las lecturas son

sencillas, el DTM selecciona uno de los nodos que almacena los datos y emite

una acción para su lectura.

Para facilitar la selección, el DTM pudiera conservar estadísticas sobre el

tiempo que se requiere para leer datos de varios nodos, y seleccionar el nodo

con el mejor rendimiento. Es más complicado la escritura de datos duplicados,

porque el DTM deberá emitir una acción de escritura para cada uno de los

DBM que almacena una copia de dichos datos.

Este análisis supone que cada DTM posee una copia exacta y actualizada de

un directorio que indique la localización de los datos. Sin embargo, aparecen

problemas interesantes, si consideramos lo que ocurriría cuando el directorio

deba modificarse para tomar en cuenta nuevas copias de datos o su

eliminación. Resulta crítica la coordinación.


Todos los directorios deberán ser instalados de forma que ningún DTM piense

que los datos están disponibles antes que así sea (en el caso de lecturas) y

que todos los DTM sepan que los datos están disponibles cuando lo estén (en

el caso de escrituras).

De lo contrario, un DTM pudiera solicitar datos que toda no estén disponibles o

dejar de emitir una orden de escritura a un DBM cuando los datos están

disponibles.

TRANSPARENCIA DE CONCURRENCIA

Aunque múltiples transacciones que involucran la base de datos distribuida se

lleven a cabo al mismo tiempo, los resultados de las transacciones no deberán

afectarse. El DDBMS proporciona transparencia de concurrencia si los

resultados de todas las transacciones concurrentes son consistentes de

manera lógica con los resultados que se habrían obtenido si las transacciones

se hubieran ejecutado una por una, en algún orden serial arbitrario.

Expresada de otra forma, la lógica de las transacciones procesadas en forma

concurrente con otras transacciones deberá de ser la misma que si la

transacción se hubiera procesado sola.

Se han desarrollado dos estrategias para proporcionar control de concurrencia.

Una de ellas conocida como bloqueo distribuido en dos fases, es una extensión

del mecanismo de control de concurrencia. Un segundo método se llama

pedido con sello de recepción. Ambos han sido implementados en productos

DDBMS. Es más común el bloqueo distribuido en dos fases.

TRANSPARENCIA DE FALLAS

La cuarta meta del DDBMS es proporcionar transparencia de fallas, lo que

significa que las transacciones sean procesadas de un modo correcto a pesar

de fallas en la transacción, en el DDBMS, en la red y en la computadora. Frente


a una falla, las transacciones deberán ser atómicas, esto es, ya sea que se

procesen todas las transacciones o ninguna de ellas.

Además, una vez comprometidos los resultados de las transacciones, serán

permanentes.

La transparencia contra fallas es la meta más difícil entre las cuatro. Parte del

problema es que existen muchos tipos distintos de fallas. En un extremo del

espectro habrá un nodo que jamás falla, a veces llamado un nodo perfecto.

En el otro extremo aparece un nodo que falla de una manera del todo

desconocida. Un nodo como éste pudiera comunicar basura a través de la red,

o bien, en razón de su falla, pudiera enviar acciones inapropiadas, pero con

formato válido por la red. Nodos como éstos se conocen como nodos

desquiciados.

Otro tipo de falla corresponde a nodos que se convierten en malévolos, lo cual

significa el nodo tiene el propósito expreso de llevar a cabo una actividad no

autorizada, o de causar daños en forma intencional. Es incluso posible

considerar fallas donde los nodos conspiran unos con otros para hacer caer al

sistema distribuido. A veces se conocen como fallas bizantinas.

Entre los extremos de los nodos perfectos y los nodos desquiciados están los

nodos sensatos. Un nodo sensato es un nodo que puede fallar, pero sólo en

una forma definida y conocida.

El ejemplo más sencillo de un nodo sensato es uno que, o es perfecto, o deja

de responder completo.

Otra razón por la cual la transparencia de falla es tan difícil es que el control de

concurrencia es muy complicado. En un sentido, los problemas de control de

concurrencia se resuelven por medio de recuperaciones de fallas. Es como una


burbuja de aire bajo el tapiz que se empuja de una esquina sólo para volver a

aparecer en otra.

Los mecanismos de control de concurrencia funcionan siempre y cuando no

ocurran fallas en ciertos momentos o en ciertos estados de la base de datos

distribuida, o siempre y cuando se pueda garantizar la recuperación en una

cierta forma, etc. En el caso general de bases de datos divididas y duplicadas

quedan aún por resolver múltiples problemas teóricos y prácticos de puesta en

práctica.


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.


5-.¿Cual es la Estructura de Base de Datos Distribuidas?

6-.¿Que comprende por Diseño de la distribución?

7-.¿Cuales son los Tipos de fragmentación que existen?

8-.¿Que Reglas de corrección de la fragmentación?

9.-¿Cuáles son los criterios para corrección de los algoritmos?

10-.¿Que tipo de Tipos de Bases de Datos Distribuidas

Hetereogenea..hay?


BASES DE DATOS

PARALELAS

Objetivos del capítulo V

1 Comprender y analizar el concepto Bases Datos

Paralelas.

2 Conocer Diseño de Sistemas paralelos.

3 Conocer la Integración de Bases paralelas.

4 Conocer el procesamiento paralelo.


Bases de Datos Paralelas.

Introducción

De forma general el concepto de paralelismo en las bases de datos lo

podríamos definir como la partición de la base de datos (normalmente a nivel

de relaciones) para poder procesar de forma paralela en distintos discos y con

distintos procesadores una sola operación sobre la base de datos.

Hace unos años este tipo de bases de datos estaban casi descartadas pero

actualmente casi todas las marcas de bases de datos venden este producto

con éxito. Esto se ha debido a:

Los requisitos transaccionales que tienen las empresas han aumentado al

mismo tiempo que ha crecido el empleo de computadoras. Además los sitios

web tienen millones de visitantes para los que se requieren bases de datos

enormes.

Las empresas utilizan cada vez mayores volúmenes de datos para planificar

sus actividades. Las consultas usadas para estos fines son de ayuda a la toma

de decisiones pueden necesitar hasta varios terabytes de datos que no se

pueden manejar con un único procesador en el tiempo necesario.

La naturaleza orientada a conjuntos de las consultas se presta a la

paralelizarían.

Las máquinas paralelas con varios procesadores son relativamente baratas.

El paralelismo se usa para mejorar la velocidad en la ejecución de consultas.

Además el paralelismo se usa para proporcionar dimensionabilidad ya que la

creciente carga de trabajo se trata sin incrementar el tiempo de respuesta pero

incrementando el grado de paralelismo.

Existen cuatro arquitecturas de sistemas paralelos:

De memoria compartida: Todos los procesadores comparten una memoria

común.


De discos compartidos:

Todos los procesadores comparten un conjunto de discos común.

Sin compartimiento:

Los procesadores no comparten ni memoria ni disco.

Jerárquica:

Este modelo es un híbrido de las arquitecturas anteriores.

Paralelismo de E/S

De forma general podemos hablar de paralelismo de E/S cuando hablamos de

divisiones en las relaciones entre varios discos para reducir el tiempo necesario

de su recuperación.

Normalmente la división más común en un entorno de bases de datos paralelas

es la división horizontal. En este tipo de división las duplas de cada relación se

dividen entre varios discos de modo que cada dupla resida en un disco distinto.

Suponiendo que tenemos n discos (D0,D1,…,Dn-

Entre los que se van a dividir los datos, existen varias estrategias de división:

Turno rotatorio:

Se recorre la relación y la i-ésima Dupla se envía al disco Di modo n quedando

una distribución homogénea de las duplas en los discos.

División por asociación:

Se escogen varios atributos del esquema de la relación y se designan como

atributos de división. Se escoge una función de asociación cuyo rango es

{0,1,…,n-1}. Cada dupla de la relación original se asocia en términos de los

atributos de división. Si la función de asociación devuelve i, la dupla de ubica

en el disco DI.

División por rangos: Se distribuye rangos contiguos de valores de los atributos

a cada disco. Para ello se escoge un atributo de división, AD, como vector de

división y la relación se divide de la siguiente manera:

o Sea [vo, v1, …, vn-2] el vector de división con i<j y vi<vj. Considérese una

dupla t

tal que t[A]=x.

o Si x< vo entonces t se ubica en el disco Do.


o Si x≥vn-2 entonces t se ubica en el disco Dn-1.

o Si vi≤x < vi+1 entonces t se ubica en el disco DI+1

Comparativa entre técnicas de división

Cuando ya hemos dividido una relación en varios discos se puede recuperar en

paralelo utilizándolos todos de la misma manera que se puede escribir en

paralelo cuando se está dividiendo una relación. Por lo tanto, cuando se quiera

leer (o escribir) la relación completa ganaremos tiempo gracias al paralelismo.

Además de leer de forma completa una relación

Eisten otro tipo de lecturas o consultas:

Exploración de la relación completa: Ya mencionada Consultas concretas:

Buscan duplas con un determinado valor para un atributo

Concreto.

Consultas de rango:

Buscan duplas con un valor que esté dentro de un rango para un atributo

concreto.

Las técnicas de división explicadas permiten estos tipos de acceso pero con

diferentes

Niveles de eficacia:

Turno rotatorio: Se adapta bien a la exploración completa pero no es eficiente

para consultas concretas y de rango ya que tiene que buscar en todos los

discos.

División por asociación: Este esquema se adapta bien a las consultas

concretas basadas en el atributo de división ya que dirigimos la consulta al

disco que se nos indica la función de asociación para el atributo y el valor del

mismo. También se adapta bien a una exploración completa si la función de

asociación reparte bien las duplas en los discos. Sin embargo no es adecuada

esta técnica para consultas concretas cuando el atributo de búsqueda no

coincide con el atributo de división.

División por rangos:

Se adapta bien a las consultas concretas y de rango basadas en el atributo de

división.

Para consultas concretas se debe analizar el vector de división para


Ver en que disco está la dupla al igual que para una consulta de rango se

consulta el vector de división para ver en que rango de discos están las Duplas.

En general se prefiere división por asociación o por rangos a turno rotatorio. En

la siguiente

Tabla se resume la comparativa:

Técnica División Relación

Completa

Consulta

Concreta

Consulta de

Rango

Turno

Rotatorio

Eficaz Ineficaz Ineficaz

Por Rango - Eficaz si coincide

Con atributo de

División

Eficaz si coincide

Con atributo de

División

Por Asociación Eficaz si la

Función reparte

Bien las duplas

Eficaz si coincide

Con atributo de

División

El problema de las divisiones por asociación es que tienden a almacenar un

alto porcentaje de duplas en algunos discos específicos, situación que no se da

con el turno rotatorio. Esto se debe a que muchas duplas contienen valores

similares en sus atributos. Para minimizar este problema se debe de elegir un

vector de división equilibrado.


Si una relación contiene un número pequeño de duplas ésta no debe ser

dividida y debe almacenarse en un solo disco.

Paralelismo entre consultas

Los sistemas de bases de datos con arquitectura paralela deben asegurar de

que dos procesadores no actualicen simultáneamente los mismos datos de

manera independiente.

Cuando un procesador accede a los datos o los actualiza, el sistema de bases

de datos debe garantizar que tenga su última versión en la memoria intermedia.

El problema de asegurar que la versión sea la última disponible se denomina

problema de coherencia del bloqueo compartido o exclusivo de la página, la

transacción lee también su copia mas reciente del disco compartido.

Antes de que una transacción libere el bloqueo exclusivo de una página, la

traslada al disco compartido, posteriormente libera el bloqueo.

Con este protocolo se garantiza que cuando una transacción establece un

bloqueo compartido o exclusivo sobre una página, obtenga la copia correcta de

la página.

Paralelismo en consultas

Es la ejecución en paralelo de una única consulta entre varios procesadores y

discos, cuyo objetivo es acelerar las consultas de ejecución prologada. Por

tanto se puede hacer paralelas las consultas haciendo paralelas las

operaciones que las forman.

Existen dos maneras de ejecutar en paralelo una sola consulta:

Paralelismo en operaciones.

Se puede acelerar el procesamiento de las

Consulta haciendo paralela la ejecución de cada una de sus operaciones

Individuales ordenación, selección, proyección y reunión.

Paralelismo entre Operaciones.

Se puede acelerar el procesamiento de la

Consulta ejecutando en paralelo las diferentes operaciones de las expresiones

de las consultas.


Por lo tanto el objetivo que se persigue es dividir la relación que interviene en la

consulta por medio de técnicas de división de relaciones, guardar dichas

relaciones en discos que van a ser gestionados cada uno de ellos por un

procesador, a su vez, cada procesador ejecuta su consulta local y cada uno de

estos resultados parciales se unen para formar la respuesta a la

Consulta.

Paralelismo en operaciones

Ya que las operaciones relacionales trabajan con relaciones que contienen

grandes conjuntos de duplas, las operaciones se pueden paralelizar

ejecutándolas sobre subconjuntos diferentes de las relaciones en paralelo.

Según el tipo de operación se siguen distintos criterios en el tratamiento que

son:

Ordenación Paralela

Reunión Paralela.

Ordenación Paralela.

Dependiendo del criterio en la división de la relación se pueden distinguir dos

tipos de ordenación:

Ordenación división de Rangos.

Esta forma de división por rangos posee dos etapas

Diferenciadas:

Redistribuir las duplas de la relación utilizando una estrategia de división

por rangos, de manera que todas las duplas que se hallen dentro del rango i-

ésimo se envíen al procesador Pi, que almacena temporalmente la relación en

el disco Di. Para implementar en paralelo la división por rangos cada

procesador lee las duplas de su disco y las envía al procesador de destino.

Cada procesador P0,P1…Pn también recibe las duplas correspondientes a su

partición y las almacena localmente.

Cada uno de los procesadores ordena localmente su partición de la relación sin

Interactuar con los demás. La operación final de mezcla es trivial ya que la

división por rangos de la primera etapa asegura que los valores de la clave del

procesador Pi sean menores que los procesador Pj


Ordenación y mezcla externa paralela.

Este tipo de ordenación es una alternativa a la efectuada por la división por

rangos. Las etapas que se definen una vez que la relación se ha divida entre

los diferentes discos D1,D2…Dn-a son las siguientes:

Cada procesador Pi ordena localmente los datos del disco Di

El sistema mezcla las partes ordenadas por cada procesador para

obtener el resultado ordenado final.

A su vez el paso en el que el sistema realiza la mezcla puede ser también

paralelizado mediante la siguiente secuencia de acciones.

El sistema divide en rangos las particiones ordenadas encada procesador Pi

Entre los procesadores P0,P1…Pn-1. Envía las duplas de acuerdo con el orden

Establecido por lo que cada procesador recibe las duplas en corrientes

Ordenadas.

Cada procesador Pi, realiza una mezcla de las corrientes según las recibe para

Obtener una sola parte ordenada.

Las partes ordenadas de los procesadores P0,P1… Pn-1 se concatenan para

Obtener el resultado final.

Reunión Paralela.

La operación reunión exige que el sistema compare pares de duplas para ver si

satisface la

Condición de reunión, si la cumple añade el par al resultado de la reunión. Los

algoritmos de reunión paralela intentan repartir entre varios procesadores los

pares que hay que comparar.

Cada procesador procesa luego localmente parte de la reunión. Después, el

sistema reúne los resultados de cada procesador para producir el resultado

final.

Existe un problema por el cual no todas los tipos de reuniones pueden ser

divididas por lo que existen distintas formas de proceder que son:

Reunión por División. Válida para reuniones de tipo equirreuniones y reuniones


Naturales, en la cual existen n procesadores y las relaciones que hay que

reunir son r y s.

La reunión por división funciona de esta forma:

El sistema divide las relaciones r y s en n particiones r0,r1,…rn-1 y s0,s1,…sn-

1 Envía las particiones ri y si al procesador Pi, donde la reunión se procesa

localmente.

Existen dos maneras diferentes de dividir las relaciones r y s y son División por

rangos de los atributos de reunión, en el que se debe usar el mismo vector

de división.

División por asociación de los atributos de reunión, se debe usar la misma

función de asociación.

Una vez divididas las relaciones se pueden utilizar localmente cualquier técnica

de reunión en cada procesador Pi para calcular la reunión de ri y si.

Reunión con fragmentos y replicas. Proporcionan una alternativa para las

Reuniones que no puede ser procesada por la técnica de reunión por división,

como por ejemplo si la condición de reunión es una desigualdad. En este tipo

de reuniones pueden paralelizarse

Utilizando una técnica denominada fragmentos y replicas, cuyo funcionamiento

es el siguiente.

El sistema divide una de las relaciones (por ejemplo s) mediante

cualquier técnica de división, incluida por turno rotatorio.

El sistema replica la otra relación r en todos los procesadores

El procesador Pi procesa localmente la reunión de ri con todos,

utilizando cualquier técnica de reunión.

Reunión por asociación dividida en paralelo. La reunión por asociación

realizada en cada procesador es independiente de las realizadas en otros

procesadores, y recibir las duplas de ri y de si es parecido a leerlas del disco.

En concreto, se puede utilizar el algoritmo híbrido de reunión por asociación

para guardar en caché algunas de las duplas de entrada, y evitar así los costes

de escribirlas y volver a leerlas.


Otras operaciones relacionales

También se puede realizar en paralelo la evaluación de otras operaciones

relacionales:

Selección. Sea la selección me(r). Considérese primero el caso en el que e es

de la forma ai = v, donde ai es un atributo y v es un valor. Si la relación r se

divide basándose en ai la selección se lleva a cabo en un solo procesador. Si e

es de la forma l ) ai ) u (es decir, que ees una selección de rango) y la relación

se ha dividido por rangos basándose en ai, entonces la selección se lleva a

cabo en cada procesador cuya partición se solape con el rango de valores

especificado. En el resto de los casos la selección se lleva a cabo en todos los

procesadores en paralelo.

Eliminación de duplicados.

La eliminación de duplicados puede llevarse a cabo por ordenación; puede

utilizarse cualquiera de las técnicas de ordenación en paralelo, con la

optimización de eliminar los duplicados durante la ordenación tan pronto como

se encuentren. También se puede realizar la eliminación de duplicados en

paralelo dividiendo las duplas (mediante división por rangos o por asociación) y

llevando a cabo localmente en cada procesador la eliminación de duplicados.

Proyección. Se puede llevar a cabo la proyección sin eliminación de duplicados

según se leen en paralelo las duplas del disco. Si se va a llevar a cabo la

eliminación de duplicados se puede utilizar las técnicas que se acaban de

describir.

Agregación.

La agregación puede considerarse una operación. Se puede paralelizar la

operación dividiendo la relación basándose en los atributos de agrupación y

procesando luego localmente los valores de agregación en cada procesador.

Se puede utilizar división por rangos o por asociación. Si la relación ya está

dividida basándose en los atributos de agrupación se puede omitir el primer

paso.

Costo de la evaluación en paralelo de las operaciones

Se puede obtener el paralelismo dividiendo la E/S entre varios discos y el

trabajo de la UCP entre varios procesadores. Si se logra un reparto así sin

sobrecarga y no hay sesgo en el reparto del trabajo, las operaciones en


paralelo que utilicen n procesadores tardarán 1/n lo que tardarían en un solo

procesador. Ya se sabe cómo estimar el coste de operaciones como la reunión

o la selección.

El coste en tiempo del procesamiento paralelo sería entonces 1/n el del

Procesamiento secuencial de la operación.

También hay que tener en cuenta los costes siguientes:

Los costos de iniciar la operación en varios procesadores.

El sesgo en la distribución de trabajo entre los procesadores, con algunos

procesadores con mayor número de duplas que otros.

La contención de recursos como la memoria, los discos y la red de

comunicaciones que dan lugar a retrasos.

El coste de construir el resultado final transmitiendo los resultados

parciales desde cada procesador.

Aunque dividir una sola consulta en varios pasos en paralelo reduce el tamaño

del paso medio, es el tiempo de procesamiento del paso más lento el que

determina el tiempo empleado en procesar la consulta en su conjunto. Una

evaluación en paralelo de las particiones, por ejemplo, sólo es tan rápida como

la más lenta de sus ejecuciones en paralelo. Por tanto, el rendimiento se ve

muy afectado por cualquier sesgo en la distribución del trabajo entre los

procesadores.

El problema del sesgo de la división está íntimamente relacionado con el del

Desbordamiento de particiones en las reuniones por asociación secuenciales.

Se puede utilizar la resolución del desbordamiento y las técnicas de evitación

desarrolladas para las reuniones por asociación para tratar el sesgo cuando se

utilice la división por asociación.

Paralelismo entre operaciones.

Hay dos formas de paralelismo entre operaciones: el paralelismo de

encauzamiento y el paralelismo independiente.

Paralelismo de encauzamiento. El encauzamiento supone una importante

fuente de economía de procesamiento para el procesamiento de consultas de

bases de datos. La ventaja principal de la ejecución encauzada de las


evaluaciones secuenciales es que se puede ejecutar una secuencia de

operaciones de ese tipo sin escribir en el disco ninguno de los resultados

intermedios.

En los sistemas paralelos el encauzamiento se utiliza principalmente por la

misma razón que en los sistemas secuenciales. Sin embargo, el

encauzamiento puede utilizarse también como fuente de paralelismo, del

mismo modo que el encauzamiento de instrucciones se utiliza como fuente de

paralelismo en el diseño de hardware. Esta forma de paralelismo se denomina

paralelismo de encauzamiento.

El paralelismo encauzado resulta útil con un número pequeño de procesadores,

pero no puede extenderse bien:

En primer lugar, las cadenas del cauce no suelen lograr la longitud

suficiente para proporcionar un alto grado de paralelismo.

En segundo lugar, no es posible encauzar los operadores de relación

que no producen resultados hasta que se ha tenido acceso a todas las

entradas, como la operación diferencia de conjuntos.

En tercer lugar, sólo se obtiene una aceleración marginal en los casos

frecuentes en que el coste de ejecución de un operador es mucho mayor

que los de los demás operadores.

Por consiguiente, cuando el grado de paralelismo es elevado, la importancia

del encauzamiento como fuente de paralelismo es secundaria respecto de la

del paralelismo de particiones.

La razón fundamental para utilizar el encauzamiento es que las ejecuciones

encauzadas pueden evitar escribir en el disco los resultados intermedios.

Paralelismo independiente. Las operaciones en las expresiones de las

consultas que son independientes entre sí pueden ejecutarse en paralelo. Esta

forma de paralelismo se denomina paralelismo independiente.

Al igual que el paralelismo encauzado, el paralelismo independiente no

proporciona un alto grado de paralelismo y es menos útil en sistemas con un

elevado nivel de paralelismo, aunque resulta útil con un grado menor de

paralelismo.


Optimización de consultas.

Un factor importante en el éxito de la tecnología relacional ha sido el diseño

con éxito de optimizadores de consultas.

Los optimizadores de consultas para la evaluación de consultas en paralelo son

más complicados que los optimizadores de consultas para la evaluación

secuencial de consultas.

En primer lugar, los modelos de costes son más complicados dado que hay

que tener en cuenta los costes de división, y deben tenerse en consideración

aspectos como el sesgo y la contención de recursos.

Resulta de mayor importancia el asunto de la paralelizarían de las consultas.

Supóngase que de algún modo se ha escogido una expresión (de entre las

equivalentes a la consulta) para utilizarla para evaluar la consulta.

Para evaluar un árbol de operadores en un sistema paralelo hay que tomar las

decisiones siguientes:

El modo en que se paralelice cada operación y el número de procesadores que

se utilizará para ello.

Las operaciones que se encauzan entre los diferentes procesadores, las

operaciones que se ejecuten independientemente en paralelo y las que se

ejecuten secuencialmente, una tras otra.

Diseño de sistemas paralelos.

La carga de datos en paralelo desde fuentes externas es un requisito

importante si se van a tratar grandes volúmenes de datos entrantes.

Un gran sistema paralelo de bases de datos debe abordar también los

siguientes aspectos de disponibilidad:

El poder de recuperación frente al fallo de algunos procesadores o discos

La reorganización interactiva de los datos y los cambios de los esquemas.


Con un gran número de procesadores y de discos la probabilidad de que al

menos un procesador o un disco funcionen mal es significativamente mayor

que en sistema con un único procesador y un solo disco.

Un sistema paralelo mal diseñado dejará de funcionar si cualquier componente

(procesador o disco) falla. Suponiendo que la probabilidad de fallo de cada

procesador o disco es pequeña, la probabilidad de fallo del sistema asciende.

Por tanto, los sistemas paralelos de bases de datos de gran escala se diseñan

para operar incluso si falla un procesador o un disco. Los datos se replican en

al menos dos procesadores.

Si falla un procesador se puede seguir teniendo acceso desde los demás

procesadores a los datos que guarda. El sistema hace un seguimiento de los

procesadores con fallos y distribuye el trabajo entre los que funcionan. Las

peticiones de los datos guardados en el emplazamiento con

Fallo se desvían automáticamente a los emplazamientos de las copias de

seguridad que guardan una réplica de los datos.

Cuando se manejan grandes volúmenes de datos (del orden de terabytes), las

operaciones sencillas, como la creación de índices, y los cambios en los

esquemas, como añadir una columna a una relación, pueden tardar mucho

tiempo (quizás horas o incluso días).

Por tanto, es inaceptable que los sistemas de bases de datos no estén

disponibles mientras se llevan a cabo tales operaciones. Los sistemas

paralelos de bases de datos permiten que tales operaciones se lleven a cabo

interactivamente, es decir, mientras el sistema ejecuta otras transacciones.

Bases de Datos GRID

Introducción.

Grid es una tecnología que surgió como una nueva forma de computación

distribuida. Ian Foster y Carl Kesselman son considerados los padres de esta

tecnología, introducida por ellos en los años 90. Esta tecnología se basa en la

utilización de recursos externos además de los locales, logrando con ello una

mayor disponibilidad de recursos para la realización de una tarea.


La tecnología estándar, o una de las más utilizadas en su comienzo al menos,

es el Globus Toolkit.

El objetivo es permitir el uso de recursos libres de otras computadoras

localizadas en otro lugar geográfico y que no estén utilizando toda su potencia.

De este modo alguien que no disponga de la suficiente potencia o recursos en

su lugar de trabajo, no se verá imposibilitado para realizar la tarea deseada ya

que podrá hacer uso de recursos ajenos.

Como consecuencia del uso de una red Grid, un usuario puede hacer uso de

recursos libres situados en los computadores que se encuentren dentro de esta

red Grid, sin importar la localización del mismo. De este modo, el usuario

dispone de un computador ficticio con la potencia, disco duro o memoria RAM

necesitada.

Por otro lado, podemos decir que con Grid, no ponemos atención en los datos

que se transmiten en sí, como es el caso de los sistemas Cliente-Servidor sino

que el punto de interés y estudio son los recursos computacionales y el uso

que se hace de ellos.

Otro avance de Grid es que genera un incremento de las posibilidades del uso

de internet ya que proporciona un incremento de su usabilidad. De este modo

se obtiene una mayor velocidad de procesamiento así como la facilidad de

tener bases de datos de mayor tamaño.

Una definición de computación Grid encontrada en la wiki pedía es la siguiente:

GRID COMPUTING:

Es una tecnología innovadora que permite utilizar de forma coordinada todo

tipo de recursos (entre ellos cómputo, almacenamiento y aplicaciones

específicas) que no están sujetos a un control centralizado. En este sentido es

una nueva forma de computación distribuida, en la cual los recursos pueden

ser heterogéneos (diferentes arquitecturas, supercomputadores,

Clúster...) y se encuentran conectados mediante redes de área extensa (por

ejemplo Internet).

Desarrollado en ámbitos científicos a principios de los años 90 su entrada al

mercado comercial siguiendo la idea de la llamada Utility Computing supone

una revolución que dará mucho que hablar.


Las características de esta arquitectura serían:

Capacidad de balanceo de sistemas: no habría necesidad de calcular la

capacidad de los sistemas en función de los picos de trabajo, ya que la

capacidad se puede reasignar desde la granja de recursos a donde se

necesite; Alta disponibilidad. Con la nueva funcionalidad, si un servidor falla, se

reasignan los servicios en los servidores restantes.

Reducción de costos:

Con esta arquitectura los servicios son gestionados por "granjas de recursos".

Ya no es necesario disponer de "grandes servidores" y podremos hacer uso de

Componentes de bajo costo.

GRID Middleware.

En las tecnologías Grid, además de tenerse en cuenta el hardware como son

los recursos, los dispositivos de almacenamiento y por supuesto la propia red

Grid, es necesario un soporte software que gestione todas las transferencias y

el modo en que se realizan, así como la seguridad, todo esto resulta una tarea

complicada y no exenta de posibles errores.

Esto no implica que la aparición de un error en un equipo y en una localización

determinada, provoque el error en toda la red.

Bases de Datos GRID.

Las Bases de Datos Grid nos proporcionan una visión uniforme de bases de

datos heterogéneas en los entornos Grid. Es decir, puesto que existen diversos

tipos de bases de datos, refiriéndonos con ellos a que éstas pueden ser

relacionales, orientadas a objetos, en XML, etcétera, nuestro sistema nos tiene

que proporcionar la abstracción necesaria de los datos para que el usuario no

distinga entre si esta accediendo a una relacional o a una orientada a objetos,


Ya que el usuario no le importa cómo se realice el trabajo, solo necesita que se

haga y debe ser el Grid middleware quien se ocupe de que se efectúe

correctamente.

Por otro lado la especificación de los servicios de bases de datos deben ser

ortogonales a los mecanismos de autentificación y autorización de los sistemas

Grid, lo que significa que las bases de datos deben poseer sistemas de

seguridad que identifiquen a un usuario del Grid y que por tanto permitan o no

su acceso.

Las propias bases de datos deben de ser transparentes al usuario, logrando así

que este se abstraiga de todo lo relacionado con el cómo se hace, donde o

incluso que recursos o almacenamiento está siendo utilizado. Del mismo modo,

no deberá preocuparse por la administración de los recursos.

Requisitos para la utilización de BBDD en GRID

Para utilizar Base de Datos en el GRID, estas primeramente deben de cumplir

una serie de condiciones previas, como son las normas de seguridad en un

GRID.

Algunos aspectos claves de la seguridad en el GRID son:

Autentificación: Verificación de la validez de la identidad de un usuario, recurso,

Servicio,..

Autorización: Cada recurso o usuario solo debe usar los servicios para los que

está permitido (control de acceso).

Integridad: Asegura que los datos no han sido alterados fraudulentamente.

Confidencialidad: Información sensible como puede ser información de carácter

Personal, orientación sexual, datos médicos o bancarios, no puede ser

observada por terceros.


Gestión de claves: Hace referencia a la gestión de seguridad, proceso de

distribución, generación y almacenamiento de claves.

Encriptación: o Simétrica:

El proceso de encriptación se realiza usando la misma clave privada.

Inconvenientes: El emisor y el receptor deben intercambiar la clave.

o Asimétrica: Se utilizan dos claves diferentes para encriptar y desencriptar

datos.

Criptografía de clave pública.

Lentitud considerable en mensajes grandes.

Aparición de patrones que puede simplificar su criptoanálisis.

Secure Socket Layer/ Transport Layer Security (SSL/ TLS): Protocolo de

comunicación segura.

Autentificación Mutua: Dos entidades que quieren comunicarse usan su clave

pública almacenada en un certificado digital para autentificarse.

Estos servicios fundamentales se garantizan mediante:

GRID Security Infrastructure (GSI)

Public Key Infrastructure (PKI)

Integración de Base de Datos en un Sistema GRID

En los sistemas de bases de datos Grid los servicios ofrecidos deben estar, en

la medida de lo posible estandarizados, y decimos en la medida de lo posible

ya que resulta imposible que todos los servicios se estandaricen debido a la

existencia de distintos tipos de bases de datos que pueden existir en el sistema

y que pueden estar usando lenguajes diferentes que no pueden ser integrados

en un único lenguaje debido a su naturaleza. De esta forma podemos aumentar

la portabilidad de dichos sistemas.


Otra de las ventajas de estandarizar siempre es reducir el esfuerzo de

construcción del sistema.

Con lo mencionado anteriormente se hace imprescindible la presencia de los

metadatos en este tipo de sistemas. Con los metadatos lo que conseguimos es

que cada sistema que se conecta al Grid pueda comunicar al resto los servicios

que ofrece. Del mismo modo podremos saber las operaciones que soporta

cada uno.

El sistema gestor de bases de datos (SGBD) va a ser el encargado de saber

que servicios ofrece cada una de las bases de datos, que operaciones se

pueden realizar sobre ellas y de gestionar los permisos de acceso a cada una.

Los servicios que cada sistema debe tener disponibles dentro del Grid son los

siguientes:

Metadatos. Nos dan la información sobre los servicios que ofrece el sistema.

Además, cuando los usuarios del sistema soliciten un servicio no saben en qué

sistema está y mediante los metadatos él se pueden construir dinámicamente

las interfaces para acceder a los distintos sistemas de bases de datos que

forman parte del Grid.

Manejo de consultas. Como hemos comentado más arriba los lenguajes

pueden ser diferentes. Por eso en los metadatos se proporciona la información

necesaria sobre el lenguaje de consulta que soporta cada base de datos.

También es importante que los resultados de una consulta se puedan enviar a

distintos destinos y que sean comprensibles por éstos para poder construir

sistemas más amplios y complejos.


Transacciones. Estas operaciones son en las que interviene un único sistema

de base de datos y a su vez que cada sistema individual tome parte en las

transacciones distribuidas.

La gran variedad de tipos de transacciones que maneja el sistema gestor de

base de datos de un sistema Grid, debido sobre todo a la heterogeneidad de

los sistemas individuales que lo componen, hace que el servicio deba poner

claramente en conocimiento del resto cual es el tipo de transacciones que

soporta el sistema individual de base de datos.

o Carga del sistema o carga de datos. Cuando tenemos grandes cantidades de

datos este tipo de servicio debe ser capaz de acceder a los protocolos de

comunicación del sistema Grid para llevar a cabo la transferencia de esos

datos o Notificación.

Sirve para notificar los cambios que se producen a los clientes que deseen

recibir esa información. Los clientes deben poder expresar si están interesados

en recibir las notificaciones cuando se inserten o se borren datos o cuando se

realicen actualizaciones o en caso de varias acciones como insertar y

actualizar.

La forma más sencilla de que este servicio se ponga en funcionamiento es que

el sistema gestor de base de datos subyacente proporcione la ayuda necesaria,

por ejemplo mediante disparadores.

Planificación. Se debe permitir por ejemplo que cuando un superordenador

conecte con un DBS, la información recuperada del DBS se pueda procesar

por el superordenador.

El ancho de banda en la red que los conecta necesita ser reservada. Como el

acceso exclusivo a un DBS no es práctico, se requieren mecanismos con

suficientes recursos (discos, CPUs, memoria, red).

Ventajas e Inconvenientes de las BBDD en un Sistema

GRID


Las bases de datos alojadas en un sistema GRID van a heredar todas las

características:

Ventajas e inconvenientes del sistema al que pertenecen.

La Computación GRID está creada con el fin de ofrecer una solución a

determinadas cuestiones, como problemas que requieren de:

Un gran número de ciclos de procesamiento o

Un acceso a una gran cantidad de datos.

Las principales ventajas de un sistema GRID son:

Nunca queda obsoleta, ya que se integran diferentes tipos de máquinas y de

recursos y todos los recursos se aprovechan. Si se renuevan todas las PCs de

una oficina, se pueden incorporar las antiguas y las nuevas.

Facilita la posibilidad de compartir, acceder y gestionar información, mediante

la colaboración y la flexibilidad operacional, aunando no sólo recursos

tecnológicos dispares, sino también personas y aptitudes diversas. o Permite a

las empresas acceder y compartir bases de datos remotas. Esto es de gran

importancia en las empresas que se dedican a la investigación, en donde

enormes cantidades de información son generadas y analizadas casi a diario.

Las empresas pueden mejorar la calidad y el tiempo de entrega de los

productos y servicios que ofrecen, a la vez que reducen costes de TI al permitir

la colaboración transparente y la compartición de recursos.

Tiende a incrementar la productividad otorgando a los usuarios finales acceso a

los recursos de computación, datos y almacenamiento que necesiten, cuando

los necesiten. o Se aprovechan los ciclos de procesamiento inutilizados de

ordenadores que se encuentran en diversas zonas geográficas.


Ejemplo: ordenadores que normalmente se encuentran inutilizados por la

noche en una compañía en Europa, podrían ser utilizados en el día por una

sede de operaciones en América.

El paralelismo puede estar visto como un problema, ya que una máquina

paralela es muy costosa.

Pero, si tenemos disponibilidad de un conjunto de máquinas heterogéneas de

pequeño o mediano porte, cuya potencia computacional sumada sea

considerable, eso permitiría generar sistemas distribuidos de muy bajo coste y

gran potencia computacional.

La tolerancia a fallos significa que si una de las máquinas que forman parte del

GRID colapsa, el sistema lo reconoce y la tarea se reenvía a otra máquina, con

lo cual se cumple el objetivo de crear infraestructuras operativas flexibles y

resistentes. Así se obtiene una tecnología más robusta y resistente, capaz de

responder a desastres.

Por tanto se puede decir que un sistema GRID proporciona:

Una forma transparente de ejecutar el trabajo que se desea:

Encuentra los recursos (maquinas) disponibles.

Asegura un acceso optimizado a los datos (incluyendo copias

locales/ cache…)

Comprueba la autorización del usuario.

Monitoriza la ejecución.

Además, si es posible monitoriza el trabajo

Los principales inconvenientes de un sistema GRID son:

Necesita para mantener su estructura, de diferentes servicios como Internet,

conexiones de 24 horas, los 365 días, con banda ancha, servidores de

capacidad, seguridad informática, VPN, firewalls, encriptación, comunicaciones

seguras, políticas de seguridad, normas ISO, y algunas características más…

Metadatos en Bases de Datos en un Sistema GRID.

¿Por qué son necesarios los metadatos?


En los sistemas de bases de datos GRID los servicios ofrecidos deben estar,

en la medida de lo posible estandarizados ya que resulta imposible que todos

los servicios se estandaricen debido a la existencia de distintos tipos de bases

de datos en el sistema GRID y que pueden estar usando lenguajes diferentes

que no pueden ser integrados en un único lenguaje.

De esta forma podemos aumentar la portabilidad de dichos sistemas. Otra de

las ventajas de estandarizar es reducir el esfuerzo de construcción del sistema.

Con lo mencionado anteriormente se hace imprescindible la presencia de los

metadatos en este tipo de sistemas. Con los metadatos lo que conseguimos es

que cada sistema que se conecta al GRID pueda comunicar al resto los

servicios que ofrece. Del mismo modo podremos saber las operaciones que

soporta cada uno.

El sistema gestor de bases de datos (SGBD) va a ser el encargado de saber

que servicios ofrece cada una de las bases de datos, que operaciones se

pueden realizar sobre ellas y de gestionar los permisos de acceso a cada una.

Servicios que describen los metadatos.

Los servicios que cada sistema debe tener disponibles dentro del GRID son los

siguientes:

Metadatos. Nos dan la información sobre los servicios que ofrece el sistema.

Además, cuando los usuarios del sistema soliciten un servicio no saben en qué

sistema está y mediante los metadatos se pueden construir dinámicamente las

interfaces para acceder a los distintos sistemas de bases de datos que forman

parte del GRID.

Manejo de consultas. Como hemos comentado más arriba los lenguajes

pueden ser diferentes. Por eso en los metadatos se proporciona la información

necesaria sobre el lenguaje de consulta que soporta cada base de datos.

También es importante que los resultados de una consulta se puedan enviar a

distintos destinos y que sean comprensibles por éstos para poder construir

sistemas más amplios y complejos.

Transacciones. Estas operaciones son en las que interviene un único sistema

de base de datos y a su vez que cada sistema individual tome parte en las


transacciones distribuidas. La gran variedad de tipos de transacciones que

maneja el sistema gestor de base de datos de un sistema GRID, debido sobre

todo a la heterogeneidad de los sistemas individuales que lo componen, hace

que el servicio deba poner claramente en conocimiento del resto cual es el tipo

de transacciones que soporta el sistema individual de base de datos.

o Carga del sistema o carga de datos. Cuando tenemos grandes cantidades de

taos este tipo de servicio debe ser capaz de acceder a los protocolos de

comunicación del sistema GRID para llevar a cabo la transferencia de esos

datos. o Notificación. Sirve para notificar los cambios que se producen a los

clientes que deseen recibir esa información. Los clientes deben poder expresar

si están interesados en recibir las notificaciones cuando se inserten o se borren

datos o cuando se realicen actualizaciones o en caso de varias acciones como

insertar y actualizar.

La forma más sencilla de que este servicio se ponga en funcionamiento es que

el sistema gestor de base de datos subyacente proporcione la ayuda necesaria,

por ejemplo mediante disparadores.

Planificación. Se debe permitir por ejemplo que cuando un superordenador

conecte con un sistema de base de datos, la información recuperada de ese

sistema pueda ser procesada por el superordenador. El ancho de banda en la

red que los conecta necesita ser reservada. Como el acceso exclusivo a un

sistema de base de datos no es práctico, se requieren mecanismos con

suficientes recursos (discos, CPUs, memoria, red).

PROCESAMIENTO PARALELO

El procesamiento paralelo es un término que se usa para denotar un grupo de

técnicas significativas que se usan para proporcionar tareas simultáneas de

procesamiento de datos con el fin de aumentar la velocidad computacional de

un sistema de computadoras. En lugar de procesar cada instrucción en forma

secuencial como es una computadora convencional, un sistema de

procesamiento paralelo puede ejecutar procesamiento concurrente de datos

para conseguir un menor tiempo de ejecución. Por ejemplo, cuando se ejecuta

una instrucción en la ALU, puede leerse la siguiente instrucción de la memoria.

http://www.monografias.com/trabajos14/dinamica-grupos/dinamica-grupos.shtml

http://www.monografias.com/trabajos6/juti/juti.shtml

http://www.monografias.com/trabajos11/basda/basda.shtml

http://www.monografias.com/trabajos13/cinemat/cinemat2.shtml#TEORICO


http://www.monografias.com/trabajos15/computadoras/computadoras.shtml


http://www.monografias.com/trabajos901/evolucion-historica-concepciones-tiempo/evolucion-historica-concepciones-tiempo.shtml

http://www.monografias.com/trabajos16/memorias/memorias.shtml


El sistema puede tener 2 o mas ALUS y ser capaz de ejecutar dos o mas

instrucciones al mismo tiempo. Además, el sistema puede tener dos o más

procesadores operando en forma concurrente.

EL propósito del procesamiento paralelo es acelerar las posibilidades de

procesamiento de la computadora y aumentar su eficiencia, esto es, la

capacidad de procesamiento que puede lograrse durante un cierto intervalo de

tiempo. La cantidades de circuitería aumenta con el procesamiento paralelo y,

con él, también el costo del sistema. Sin embargo, los descubrimientos

tecnológicos han reducido el costo de la circuitería a un punto en donde las

técnicas de procesamiento paralelo son económicamente factibles.

El procesamiento paralelo puede considerarse de diversos niveles de

complejidad. En el nivel más bajo, distinguimos entre operaciones seriales y

paralelas mediante el tipo de registros que utilizan. Los registros de corrimiento

operan en forma serial un bit a la vez, mientras que los registros con carga

paralela operan con todos los bits de la palabra en forma simultánea.

Puede obtenerse procesamiento paralelo a un nivel más alto de complejidad al

tener múltiples unidades funcionales que ejecuten operaciones idénticas o

diferentes, de manera simultánea. El procesamiento paralelo se establece al

distribuir los datos entre las unidades funcionales múltiples. Por ejemplo, las

operaciones aritméticas, lógicas y de corrimiento pueden separarse en tres

unidades y dividirse los operandos a cada una, bajo la supervisión de una

unidad de control.

Procesador con unidades funcionales múltiples

La operación ejecutada en cada unidad funcional se indica en cada bloque del

diagrama. El sumador y el multiplicador de enteros ejecutan las operaciones

aritméticas con números enteros.

Las operaciones de punto flotante se separan en tres circuitos que operan en

paralelo. Las operaciones lógicas de corrimiento y de incremento pueden

http://www.monografias.com/trabajos5/sisope/sisope.shtml


http://www.monografias.com/trabajos11/veref/veref.shtml

http://www.monografias.com/trabajos7/coad/coad.shtml#costo

http://www.monografias.com/trabajos6/diop/diop.shtml


http://www.monografias.com/trabajos13/conce/conce.shtml

http://www.monografias.com/trabajos14/control/control.shtml

http://www.monografias.com/trabajos5/sisope/sisope.shtml

http://www.monografias.com/trabajos14/flujograma/flujograma.shtml

http://www.monografias.com/trabajos10/infoba/infoba.shtml#circuito


ejecutarse en forma concurrente sobre diferentes datos. Todas las unidades

son independientes unas de otra, por lo que puede correrse un número

mientras otro se incrementa.

Por lo general, una organización multifuncional está asociada con una unidad

de control compleja para coordinar todas las agilidades entre los diferentes

componentes.

Existen varias maneras de clasificar el procesamiento paralelo. Puede

considerarse a partir de la organización interna de los procesadores, desde la

estructura de interconexión entre los procesadores o desde del flujo de

información a través del sistema.

Una clasificación presenta por M. J. Flynn considera la organización de un

sistema de computadora mediante la cantidad de instrucciones y unidades de

datos que se manipulan en forma simultánea. La operación normal de una

computadora es recuperar instrucciones de la memoria y ejecutarlas en el

procesador.

La secuencia de instrucciones leídas de la memoria constituye un flujo de

instrucciones. Las operaciones ejecutadas sobre los datos en el procesador

constituyen un flujo de datos.

El procesamiento paralelo puede ocurrir en el flujo de instrucciones, en el flujo

de datos o en ambos.

La clasificación de Flynn divide a las computadoras en cuatro grupo principales

de la manera siguiente:

Flujo de instrucción único, Flujo de datos único (SISD)

Flujo de instrucción único, Flujo de datos Múltiple (SIMD)

Flujo de instrucción Múltiple, Flujo de datos único (MISD)

Flujo de instrucción Múltiple, Flujo de datos Múltiple (MIMD)

SISD. Representa la organización de una computadora única que contiene una

unidad de control, una unidad de procesador y una unidad de memoria. Las

http://www.monografias.com/trabajos6/napro/napro.shtml

http://www.monografias.com/trabajos15/todorov/todorov.shtml#INTRO

http://www.monografias.com/trabajos7/sisinf/sisinf.shtml

http://www.monografias.com/trabajos13/memor/memor.shtml

http://www.monografias.com/trabajos6/napro/napro.shtml


instrucciones se ejecutan en forma secuencial y el sistema puede tener o no

tener posibilidades de procesamiento paralelo.

En este caso el procesamiento paralelo puede lograrse mediante unidades

funcionales múltiples o mediante una arquitectura paralela.

SIMD.

Representa una organización que influye muchas unidades de procesamiento

bajo la supervisión de una unidad de control común. Todos los procesadores

reciben la misma instrucción de la unidad de control, pero operan sobre

diferentes conjuntos de datos. La unidad de memoria compartida debe de

contener módulos múltiples para que pueda comunicarse con todos los

procesadores simultáneamente.

LA estructura MISD es sola de intereses teórico porque no se ha construido

ningún sistema práctico utilizando esta organización. La organización MIMD se

refiere a un sistema de computadoras capaz de procesar múltiples programas

al mismo tiempo la mayoría de los sistemas de multicomputadoras y

multiprocesador pueden clasificarse en esta categoría.

La clasificación de Flynn depende en la diferencia entre el desempeño de la

unidad de control y el de la unidad de procesamiento de datos.

Enfatiza las características de desempeño del sistema de computadoras más

que sus interconexiones estructurales y operacionales.

Un tipo de procesamiento paralelo que no entra en la clasificación flynn es la

arquitectura paralela (pipe-line) Las únicas dos categorías utilizadas de esta

clasificación son los procesadores de arreglo SIMD,

El procesamiento por arquitectura paralela es una técnica de implantación en

donde las suboperaciones aritméticas o las fases de un ciclo de instrucción de

computadora se traslapan en su ejecución el procesamiento de vectores

relaciona con los cálculos que implican vectores y matrices grandes.

http://www.monografias.com/trabajos6/arma/arma.shtml

http://www.monografias.com/trabajos10/historix/historix.shtml

http://www.monografias.com/Computacion/Programacion/


http://www.monografias.com/trabajos15/indicad-evaluacion/indicad-evaluacion.shtml

http://www.monografias.com/trabajos14/datos/datos.shtml#pro

http://www.monografias.com/trabajos35/vectores/vectores.shtml

http://www.monografias.com/trabajos14/matriz-control/matriz-control.shtml


Los procesadores de arquitectura paralela ejecutan cálculos sobre arreglos de

datos grandes.

Arquitectura Paralela

La arquitectura paralela o de líneas paralelas (pipe-line), es una técnica en la

que se descomponen un proceso secuencial en suboperaciones, y cada

subproceso se ejecuta en un segmento dedicado especial que opera en forma

concurrente con los otros segmentos. Una línea puede considerarse como un

conjunto de segmentos de procesamiento por el que fluye información binaria.

Cada segmento ejecuta un procesamiento parcial, dictado por la manera en

que se divide la tarea.

El resultado obtenido del cálculo en cada segmento se transfiere al siguiente

segmento en la línea. El resultado final se obtiene después de que los datos

han recorrido todos los segmentos. El nombre "línea" implica un flujo

reinformación similar a una línea de ensamblado industrial. Es característico de

las líneas que varios cálculos puedan estar en proceso en distintos segmentos,

al mismo tiempo. La simultaneidad de los cálculos es posible al asociar un

registro con cada segmento en la línea. Los registros proporcionan aislamiento

entre cada segmento para que cada uno pueda operar sobre datos distintos en

forma simultánea.

Tal vez la manera más simple de apreciar la arquitectura de líneas paralelas es

imaginar que cada segmento consta de un registro de entrada seguido de un

circuito combinatorio. El registro contiene los datos y el circuito combinatorio

ejecuta las suboperación en el segmento particular. La salida del circuito

combinacional es un segmento dado se aplica al registro de entrada del

siguiente segmento.

Se aplica un reloj a todos los registros después de que se ha transcurrido un

tiempo suficiente para ejecutar toda la actividad del segmento. De esta manera

la información fluye por la línea un paso a la vez.

http://www.monografias.com/trabajos14/administ-procesos/administ-procesos.shtml#PROCE

http://www.monografias.com/trabajos7/caes/caes.shtml



La organización de la línea se mostrará mediante un ejemplo:

Supongamos que deseamos ejecutar las operaciones multiplicar y sumar

combinadas con un flujo de números.

Ai * B1 + Ci para i=1,2,3,…7

Cada suboperación se va a implantar en un segmento dentro de la línea.

Cada segmento tiene uno o dos registros y un circuito combinatorio, como se

muestra en la figura 9.2. De R1 a R5 son registros que reciben nuestros datos

con cada pulso de reloj. El multiplicador y el sumador son circuitos

combinatorios. Las suboperaciones ejecutadas en cada segmento del conducto

son las siguientes:

Los cinco registros se cargan con datos nuevos en cada pulso de reloj. El

efecto de cada pulso de reloj se muestra en la tabla 9.-1 El primer pulso de reloj

transfiere A1 y B1 dentro de R1 y R2. El segundo pulso de reloj transfiere el

producto de R1 y R2 dentro de R3 y C1 dentro de R4. El mismo pulso de reloj

transfiere A2 y B2 dentro de R1 y R2. El tercer pulso de reloj opera sobre los

tres segmentos en forma simultánea. Coloca a A3 y B3 dentro de R1 y R2,

transfiere el producto R1 y R2 dentro de R3, transfiere C2 dentro de R4 y

coloca la suma de R3 y R4 dentro de R5. Se necesita tres pulsos de reloj para

llenar la línea y recuperar la primera salida de R5. De ahí en adelante, cada

ciclo de reloj produce una nueva salida y mueve los datos un paso adelante en

la línea. Estos sucede en tanto fluyan nuevos datos dentro del sistema cuando

ya no hay datos de entrada disponibles, el reloj debe continuar hasta que

emerge la última salida de la línea

Consideraciones generales

Cualquier operación que pueden descomponerse en una secuencia de

suboperaciones de aproximadamente la misma complejidad, puede

implementarse mediante un procesador de arquitectura paralela. La técnica es

eficiente para aquellas aplicaciones que necesitan repetir la misma tarea

http://www.monografias.com/trabajos12/elproduc/elproduc.shtml


muchas veces con diferentes conjuntos de datos. La estructura general de una

línea de cuatros segmentados .

Los operandos recorren los cuatros segmentos de una secuencia fija. Cada

segmento consta de cada circuito combinacional Si Que ejecuta una

suboperación sobre el flujo de datos que fluyen por la línea.

Los segmentos se separan mediante registros Ri Que contienen los resultados

intermedios entre las etapas. La información fluye entre etapas adyacentes

bajo el control de un reloj común aplicado a todos los registros en forma

simultánea definimos una tarea como la operación total ejecutada cuando se

recorren todos los segmentos en la línea.

Línea paralela de cuatro segmentos

Para ver el gráfico seleccione la opción "Descargar" del menú superior

El desempeño de la arquitectura paralela puede ilustrarse mediante un

diagrama espacio- tiempo. Este es un diagrama que muestra la utilización del

segmento como una función del tiempo. El diagrama espacio-tiempo de un

conducto con cuatro segmentos s.

El eje horizontal muestra el tiempo en ciclos de reloj y el eje vertical

proporciona el número de segmentos el diagrama muestra seis tareas de la T1

a la T6 ejecutada en cuatros segmentos. Al principio, ala tarea T1 se maneja

mediante el segmento.

Después del primer ciclo de reloj, el segmento 2 esta ocupado con T1 mientras

que el segmento 1 esta ocupado con la tarea T2. A continuar de esta manera la

primera tarea T1 se complementa después del cuarto ciclo de reloj.

De ahí en adelante la línea completa una tarea en cada ciclo de reloj.

No importa cuántos segmentos existan en el sistema, una vez que la línea está

llena, solo se necesita un periodo de reloj para obtener una salida.

Ahora consideremos el caso en donde se utiliza una línea de K de segmentos

para ejecutar "n" tareas con un tiempo de ciclo de reloj Tp, la primera tarea T1

necesita un tiempo igual a KTp para completar su operación, porque existen K

http://www.monografias.com/trabajos7/mafu/mafu.shtml


segmentos en la línea. Las n-1 tareas restantes emergen en la línea a una

velocidad de una tarea por ciclo de reloj y se terminará después de un tiempo

igual (n-1)tp por lo tanto, para completar n tareas una línea en K segmentos se

necesita K+ (n-1) ciclos de reloj. Por ejemplo, el diagrama de la figura 9-4

muestra cuatros segmentos y seis tareas.

El tiempo requerido para completar todas las operaciones es 4 + (6-1)=9 ciclos

de reloj según se indica en el diagrama.

1 2 3 4 5 6 7 8 9

Ciclos de

reloj

Segmento 1 T1 T2 T3 T4 T5 T6

2

T1 T2 T3 T4 T5 T6

3

T1 T2 T3 T4 T5 T6

4

T1 T2 T3 T4 T5 T6

Figura 9.4 Diagrama espacio-tiempo para línea paralela

A continuación consideremos una unidad de arquitectura no paralela que

ejecuta la misma operación y requiere un tiempo igual a Tn para completar

cada tarea. El tiempo total requerido para n tareas es NTn.

La aceleración de un procesamiento por arquitectura paralela sobre un

procesamiento no paralelo equivalente se define mediante la relación:

Conforme aumenta la cantidad de tareas, n se vuelve mucho más grande que

K-1, y K+n-1 se aproxima al valor de n. Bajo esta condición, la aceleración se

convierte en:

Si consideramos que el tiempo que se necesita para procesar una tarea es

igual en una arquitectura paralela y en una arquitectura no paralela, tendremos

Tn = KTp.

Al incluir esta suposición, la aceleración se reduce a:

Esto muestra que la máxima aceleración teórica que puede proporcionar un

conducto es K, en donde K es la cantidad de segmentos en el conducto.

http://www.monografias.com/trabajos14/nuevmicro/nuevmicro.shtml


Para duplicar la ventaja de velocidad teórica de un proceso paralelo mediante

unidades funcionales múltiples, es necesario construir k segmentos iguale el

desempeño de k copias de un circuito de arquitectura no paralela equivalente

bajo condiciones de operación iguales.

En donde están conectados en paralelo cuatro circuitos idénticos. Cada circuito

P ejecuta la misma tarea de un mismo circuito con arquitectura paralela

equivalente. En lugar de operar con los datos de entrada en secuencia, como

en una línea, los circuitos paralelos aceptan cuatro conjuntos de datos de

entrada en forma simultánea y ejecutan cuatro tareas al mismo tiempo.

En lo que se refiere a la velocidad de operación esta es equivalente a una línea

con cuatro segmentos. Nótese que el circuito de cuatro unidades, constituye

una organización de instrucción única, datos múltiples en paralelo.

Unidades funcionales múltiples en paralelo

Existen varias razones por las que una arquitectura paralela no puede operar a

su máxima velocidad teórica. Los diferentes segmentos pueden requerir

tiempos diferentes para completar su suboperación. Debe elegirse el ciclo de

reloj para iguale el tiempo de retraso del segmento con el máximo tiempo de

propagación. Esto provoca que los otros segmentos desperdicien tiempo

mientras esperan el siguiente ciclo de reloj.

Además no siempre es correcto considerar que un circuito de arquitectura tiene

el mismo retraso de tiempo que un circuito con arquitectura paralela

equivalente. Muchos de los registros intermedios no se necesitarán en un

circuito de una sola unidad el cual, por lo general, puede construirse por

completo como un circuito combinatorio.

No obstante, la técnica de arquitectura paralela proporciona una operación

más rápida que una secuencia puramente serial, aunque nunca se logra por

completo la máxima velocidad teórica.


Existen dos áreas de diseño de computadoras en las que es aplicable la

organización paralela. Una línea aritmética divide una operación aritmética en

suboperaciones que se ejecutan en los segmentos de la línea.

Una línea de instrucciones opera sobre un flujo de instrucciones al sobreponer

las fases de recuperación, decodificación y ejecución. En las siguientes

secciones se explican los dos tipos de líneas.

Línea paralela aritmética

Por lo general, se encuentran unidades aritméticas de arquitectura paralela en

computadoras de gran velocidad. Se usan para implantar operaciones de punto

flotante, multiplicación de números de punto fijo y cálculos similares

encontrados en problemas científicos.

En esencia, un multiplicador de arquitectura paralela es un arreglo multiplicador

como el que se describe en la figura 10-10, con sumadores especiales

diseñados para minimizar el tiempo de propagación de acarreo mediante los

productos parciales.

Las operaciones de punto flotante se descomponen con facilidad en

suboperaciones, como se muestra en la sección 10-5. Ahora mostraremos un

ejemplo de una unidad paralela para suma y resta de punto flotante.

Las entradas para la línea sumadora de punto flotante son dos números

binarios normalizados de punto flotante.

X = A X 2ª

Y = B X 2b

A y B son dos fracciones que representan las mantisas, en tanto que a y b son

los exponentes. Puede ejecutarse la suma y resta de punto flotante en cuatro

segmentos.

Los registros etiquetados R se colocan entre los segmentos para almacenar los

resultados intermedios. Las sub-operaciones que se ejecutan en los cuatro

segmentos son:

1. Comparar los exponentes.

http://www.monografias.com/trabajos13/diseprod/diseprod.shtml

http://www.monografias.com/trabajos15/calidad-serv/calidad-serv.shtml#PLANT

http://www.monografias.com/trabajos12/elproduc/elproduc.shtml


2. Alinear las mantisas.

3. Sumar o restar las mantisas.

4. Normalizar el resultado.

Esto se apega al procedimiento delineado, pero se usan algunas variaciones

para reducir el tiempo de ejecución de las suboperaciones. Se comparan los

exponentes al restarlos para determinar su diferencia. Se escoge el exponente

mayor como el exponente del resultado.

La diferencia entre exponentes determina cuántas veces debe ejecutarse un

corrimiento a la derecha sobre la mantisa asociada con el exponente menor.

Esto provoca un alineamiento de las dos mantisas. Debe notarse que el

corrimiento debe estar diseñado como un circuito combinatorio para reducir el

tiempo de corrimiento.

Las dos mantisas se suman o restan en el segmento 3. El resultado se

normaliza en el segmento 4. Cuando ocurre un sobre flujo, la mantisa de la

suma o diferencia se recorre a la derecha y el exponente se incrementa en 1.

Si ocurre un sobre flujo, la cantidad de números 0 significativos en la mantisa

determina el número de corrimientos a la izquierda y la cantidad que debe

restarse del exponente.

El siguiente ejemplo numérico puede aclarar las sub-operaciones que se

ejecutan en cada segmento. Por simplicidad utilizamos números binarios.

Consideremos los dos números de punto flotante normalizados:

X = 0.9504 X 103

Y = 0.8200 X 102

Línea paralela de instrucciones

El procesamiento por línea paralela puede ocurrir en el flujo de datos y también

en el flujo de instrucciones. Una línea paralela de instrucciones lee

instrucciones consecutivas de la memoria mientras, en otros segmentos, se

ejecutan instrucciones anteriores.

http://www.monografias.com/trabajos13/mapro/mapro.shtml


Una posible digresión asociada con tal esquema es que una instrucción puede

producir un brinco fuera de secuencia.

En tal caso, debe vaciarse la línea y deben descartarse todas las instrucciones

que se han leído de la memoria después de la instrucción de brinco.

Consideremos una computadora con una unidad de recuperación y una unidad

de ejecución de instrucciones diseñada para proporcionar una línea de dos

segmentos. Puede implantarse el segmento de recuperación de instrucciones

mediante un registro intermedio (buffer) primero en entrar, primero en salir

(FIFO). Este es un tipo de unidad que forma una cola en lugar de una pila.

Cuando la unidad de ejecución no está usando la memoria, el control

incrementa el contador de programa y utiliza su valor de dirección para leer

instrucciones consecutivas de la memoria.

Las instrucciones se insertan en el registro intermedio FIFO para que puedan

ejecutarse en un esquema primero en entrar, primero en salir. Por lo tanto,

puede colocarse un flujo de instrucciones en una cola, en espera que lo

decodifique y procese el segmento de ejecución.

El mecanismo de formación de colas con flujos de instrucciones proporciona

una manera eficiente para reducir el tiempo promedio de acceso a memoria

para leer instrucciones.

Cuando hay espacio en recuperación de instrucciones.

El registro intermedio actúa como una cola de la que el control obtiene las

instrucciones para la unidad de ejecución.

Las computadoras con instrucciones complejas requieren otras fases además

de las de recuperación y ejecución para procesar por completo una instrucción.

En el caso más general, la computadora necesita procesar cada instrucción

con la siguiente secuencia de pasos.

1. Recuperar la instrucción de la memoria

2. Decodificar la instrucción

3. Calcular la dirección efectiva

http://www.monografias.com/Computacion/Programacion/

http://www.monografias.com/trabajos15/direccion/direccion.shtml


4. Recuperar los operandos de la memoria

5. Ejecutar la instrucción

6. Almacenar el resultado en el lugar adecuado.

Existen ciertas dificultades que evitarán que la línea paralela de instrucciones

funcione a su velocidad máxima. Segmentos diferentes pueden necesitar

tiempos diferentes para actuar sobre la información que llega.

Se saltan algunos segmentos para ciertas operaciones. Por ejemplo, una

instrucción de modo de registro no necesita un cálculo de dirección efectiva.

Dos o más segmentos pueden requerir el acceso a la memoria al mismo

tiempo, provocando que un segmento espere hasta que otro termine su

comunicación.

En ocasiones, se resuelven los conflictos de acceso a memoria al usar dos

canales de memoria para acceder las instrucciones y los datos en módulos

separados. De esta manera, pueden leerse de forma simultánea una palabra

de instrucción y una palabra de datos de dos módulos diferentes.

El diseño de una línea paralela de instrucciones será más eficiente si se divide

el ciclo de instrucciones en segmentos de igual duración. El tiempo que

necesita cada paso para terminar su función depende de la instrucción y de la

manera como se ejecuta.

Ejemplo: Línea paralela de instrucciones de cuatro segmentos

Consideremos que pueden combinarse en un segmento de decodificación de la

instrucción y el cálculo de la dirección efectiva. Además, consideremos que la

mayoría de las instrucciones colocan el resultado en un registro de procesador,

para que la ejecución de la instrucción y el almacenamiento del resultado

puedan combinarse en un segmento. Esto reduce la línea paralela de

instrucciones a cuatro segmentos.

El ciclo de instrucciones en la CPU con una línea paralela de cuatro

segmentos. Mientras se ejecuta una instrucción en el segmento cuatro, la

siguiente instrucción en secuencia se ocupa en recuperar un operando de la

memoria en el segmento 3.

http://www.monografias.com/trabajos12/fundteo/fundteo.shtml

http://www.monografias.com/trabajos55/conflictos/conflictos.shtml

http://www.monografias.com/trabajos12/dispalm/dispalm.shtml

http://www.monografias.com/trabajos12/comptcn/comptcn.shtml#UCP


En un circuito aritmético separado puede calcularse la dirección efectiva para la

tercera instrucción y, cuando está disponible la memoria, pueden recuperarse y

colocarse en una localidad del registro intermedio FIFO la cuarta instrucción y

todas las subsecuentes. Por lo tanto, pueden traslaparse y estar en proceso

hasta cuatro suboperaciones en el ciclo de instrucciones.

De vez en cuando, una instrucción en la secuencia puede ser del tipo de

control de transferencia del programa que produce un brinco fuera de la

secuencia normal.

En ese caso, se terminan las operaciones pendientes en los últimos dos

segmentos y se borra toda la información almacenada en el registro intermedio

de instrucciones. Después, la línea paralela y vuelva a iniciar a partir de un

nuevo valor de dirección

Arquitectura paralela de CPU de cuatro segmentos.

El tiempo en el eje horizontal se divide en pasos de igual duración. En el

diagrama, los cuatro segmentos se representan con un símbolo abreviado.

1. FI es el segmento que recupera una instrucción

2. DA es el segmento que decodifica la instrucción y calcula la dirección

efectiva.

3. FO es el segmento que recupera el operando.

4. EX es el segmento que ejecuta la instrucción.

Figura 8 Temporización d línea paralela de instrucciones.

Paso 1 2 3 4 5 6 7 8 9 10 11 12 13

1 FI DA FO EX

2

FI DA FO EX

3

FI DA FO EX

4

FI - - FI DA FO EX

5

- - - FI DA FO EX


6

FI DA FO EX

7

FI DA FO EX

Se considera que el procesador tiene memorias de instrucciones y datos

separadas, por lo que puede avanzar la operación en FI y FO, al mismo tiempo.

En ausencia de una instrucción de transferencia de control, cada segmento

opera sobre instrucciones diferentes.

Por lo tanto, en el paso 4, se ejecuta la instrucción en el segmento EX; el

operando para la instrucción 2 se recupera en el segmento FO; en el segmento

DA se decodifica la instrucción 3 y en el segmento FI se recupera de la

memoria la instrucción 4.

Supongamos que la instrucción 3 es una instrucción de transferencia de

control. Tan pronto como se decodifica esta instrucción en el segmento DA en

el paso 4, se detiene la transferencia de FI a DA de las otras instrucciones,

hasta que se ejecuta la instrucción de transferencia de control en el paso 6. Si

se da la transferencia, se recupera una nueva instrucción en el paso 7.

Si no se da la transferencia, puede usarse la instrucción recuperada antes, en

el paso 4. Después, la línea paralela continua la ejecución hasta que se

encuentra una nueva instrucción de transferencia de control.

Puede ocurrir otro retraso en la línea si el segmento EX necesita almacenar el

resultado de la operación en la memoria de datos mientras el segmento FO

necesita recuperar un operando. En ese caso, el segmento FO debe esperar

hasta que el segmento EX haya terminado su operación.

En general, existen tres dificultades principales que provocan que una línea de

instrucciones se aparte de su operación normal.

1. Conflictos de recursos, provocados al accesar la memoria dos segmentos

diferentes, al mismo tiempo. Gran parte de estos conflictos pueden

resolverse al utilizar memorias de instrucciones y de datos separadas.

http://www.monografias.com/trabajos16/memorias/memorias.shtml

http://www.monografias.com/trabajos4/refrec/refrec.shtml


2. Surgen conflictos de dependencia de datos cuando una instrucción

depende del resultado de una anterior, pero éste todavía no está

disponible.

3. Se producen dificultades de transferencia de control a partir de

instrucciones que modifican el valor del PC.


CUESTIONARO

1-.¿Que comprendió por bases datos paralela?

2-.¿Que es paralelismo entre consultas?

3-.¿Que es Ordenacion Paralela?

4-.¿Cuales son las otras operaciones relacionales que existen?

5-.¿Que significa eliminación por duplicados?


6-.¿Que significa Costo de la evaluación en paralelo de las operaciones?

7-Explique en que consisten los Diseño de sistemas paralelos.

8-.¿Que es una Bases de Datos GRID?

9-.¿Caules son las características de esta arquitectura?

10-.¿Cuales son los servicion dentro del Grid(base datos?


BIBLIOGRAFIA

TTooddaass llaass ppaannttaallllaass,, LLooggooss ddee WWiinnddoowwss ssoonn mmaarrccaass

RReeggiissttrraaddaass ddee MMiiccrroossoofftt CCoorrppoorraacciióónn EEEE..UUUU yy oottrrooss

PPaaíísseess

TTooddaass llaass ppaannttaallllaass,, LLooggooss ddee MMAACC ssoonn mmaarrccaass

RReeggiissttrraaddaass

CCiissccoo NNeettwwoorrkkiinngg AAccaaddeemmyy

PPrrooggrraamm((DDeerreecchhooss

RReesseerrvvaaddooss))

VVeerrssiioonn 33..11

www.recursos-vista.es (CC) 2007

www.aulaclick.com

www.adlszone

www.microsoft.com

www.ubuntu

Sistemas operativos pearsons

www.lawebdelprogramador

www.abcdatos.com

http://www.aulaclick.com/

http://www.adlszone/

http://www.microsoft.com/

http://www.ubuntu/

http://www.lawebdelprogramador/

http://www.abcdatos.com/

Teoria Bases Datos II (1)

Documents

Transcript of Teoria Bases Datos II (1)