I UNIDAD BASES DE DATOS DISTRIBUIDAS

1.1 Conceptos básicos. 3 1.2 Objetivos de las B.D.D. 7 1.3 Disciplinas de estudio. 12 1.4 Arquitectura de bases de datos distribuidas. 13

UNIDAD 2 DISEÑO DE BASES DE DATOS DISTRIBUIDAS

2.1 Consideraciones de diseño de bases de datos distribuidas. 20 2.2 Diccionario de datos. 27 2.3 Niveles de transparencia. 28

2.3.1 Transparencia de localización. 30 2.3.2 Transparencia de fragmentación. 31 2.3.3 Transparencia de réplica. 31

2.4 Fragmentación de datos. 32 2.4.1 Fragmentación horizontal. 34 2.4.2 Fragmentación vertical. 37 2.4.3 Fragmentación híbrida. 38

2.5 Distribución de datos. 40 2.5.1 Algoritmos de distribución de datos no replicados. 42 2.5.2 Algoritmos de distribución de datos replicados. 43

UNIDAD 3 PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS

3.1 Metodología del procesamiento de consultas distribuidas. 47 3.2 Estrategias de procesamiento de consultas distribuidas. 53

3.2.1 Árboles de consultas. 56 3.2.2 Transformaciones equivalentes. 60 3.2.3 Métodos de ejecución del Join. 60

3.3 Optimización de consultas. 70 3.3.1 Optimización global de consultas. 73 3.3.2 Optimización local de consultas. 75

UNIDAD 4

MANEJO DE TRANSACCIONES

4.1 Transacciones 82 4.1.2 Ejecución de transacciones centralizada y distribuida 84 4.1.3 Estructura de transacciones. 87 4.1.4 Ejecución de transacciones centralizada y distribuida. 88

2

4.2 Control de concurrencia.

89

. 4.2.1 Serialización de transacciones. 90 4.2.2 Algoritmos de control de concurrencia. 4.2.2.1 Basados en bloqueo. 91 4.2.2.2 Basados en estampas de tiempo. 94 4.2.2.3 Pruebas de validación optimistas. 9 4.2.3 Disciplinas del Interbloqueo: prevención, detección, eliminación y recuperación

98

4.3 Confiabilidad 99 4.3.1 Conceptos básicos de confiabilidad. 100 4.3.2 Protocolos REDO/UNDO. 101 4.3.3 Puntos de verificación (checkpoints). 103 4.3.4 Protocolo 2PC de confiabilidad distribuida. 10

BIBLIOGRAFIA

3

1 UNIDAD: FUNDAMENTOS DE BASE DE DATOS DISTRIBUIDAS

1.1 CONCEPTOS BASICOS

Una base de datos o banco de datos es un conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente para su posterior uso. En este sentido, una biblioteca puede considerarse una base de datos compuesta en su mayoría por documentos y textos impresos en papel e indexados para su consulta. En la actualidad, y debido al desarrollo tecnológico de campos como la informática y la electrónica, la mayoría de las bases de datos están en formato digital (electrónico), que ofrece un amplio rango de soluciones al problema de almacenar datos.

Existen programas denominados sistemas gestores de bases de datos, abreviados SGBD, que permiten almacenar y posteriormente acceder a los datos de forma rápida y estructurada. Las propiedades de estos SGBD, así como su utilización y administración, se estudian dentro del ámbito de la informática.

Las aplicaciones más usuales son para la gestión de empresas e instituciones públicas. También son ampliamente utilizadas en entornos científicos con el objeto de almacenar la información experimental.

Aunque las bases de datos pueden contener muchos tipos de datos, algunos de ellos se encuentran protegidos por las leyes de varios países. Por ejemplo en España, los datos personales se encuentran protegidos por la (LOPD).

Base de datos distribuidas: Son un grupo de datos que pertenecen a un sistema pero a su vez está repartido entre ordenadores de una misma red, ya sea a nivel local o cada uno en una diferente localización geográfica, cada sitio en la red es autónomo en sus capacidades de procesamiento y es capaz de realizar operaciones locales y en cada uno de estos ordenadores debe estar ejecutándose una aplicación a nivel global que permita la consulta de todos los datos como si se tratase de uno solo. Es un conjunto de múltiples bases de datos lógicamente relacionadas las cuales se encuentran distribuidas entre diferentes sitios interconectados por una red de comunicaciones. Características de la base de datos distribuidos:

Los datos deben estar físicamente en más de un ordenador (distintas sedes)

4

Las sedes deben estar interconectadas mediante una red (cada sede es un nodo de la red)

Los datos han de estar lógicamente integrados (recuperación y actualización) tanto en local como remoto (esquema lógico global y único)

En una única operación se puede acceder (recuperar o actualizar) datos que se encuentran en más de una sede (acceso a datos locales o remotos)

Todas las acciones que necesiten realizarse sobre más de una sede serán transparentes al usuario (transparencia de distribución para el usuario)

Ventajas de la base de datos distribuidos:

Organizativas:

Económicas:

Técnicas: Desventajas de la base de datos distribuidos

Complejidad del sistema, desarrollo de software más costoso, problemas de sincronización, dificultad para conocer la corrección de los algoritmos paralelos, detección de caídas de nodos

Dependencia de la red de comunicaciones, sobrecarga de procesamiento de mensajes

Dificultad de diseño, fases adicionales

Poca madurez de los productos comerciales, orientados a replicación

Funciones de administración compleja, sincronización y coordinación

Dificultad de cambio, inexistencia de metodologías

Personal especializado

5

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

Factores importantes en BDD. Componentes de una base de datos

BD locales

SGBDD

Diccionario o directorio global

Sgbdd:

Es un software que administra y controla las bases de datos distribuidas de manera transparente. Las responsabilidades del sgbdd serán:

6

Transparencia de red

Transparencia de fragmentación

Transparencia de copias o duplicación

Propagación de actualizaciones

Procesamiento de consultas distribuidas, definición de estrategias

Mantener un diccionario integrado

Control de concurrencia, integridad de la BDD, consistencia entre las múltiples copias de los datos

Fiabilidad de los SGBDD, capaz de recuperar y devolver a las bases de datos implicadas en el fallo un estado consistente y estable

Soporte de sistema operativo

Bases de datos heterogéneas, mecanismos de traducción Sgbdd paralelo:

Este sistema gestor se ejecuta sobre múltiples procesadores y hace uso de múltiples discos, se encuentra diseñado para poder realizar operaciones en paralelo, siempre que sea posible, con la finalidad de mejorar las prestaciones.

COMPARACION DE LAS BASES DE DATOS DISTRIBUIDAS CON LAS CENTRALIZADAS.

CENTRALIZADO DISTRIBUIDO

Control centralizado: un solo DBA

Control jerárquico: DBA global y DBA local

7

1.2 OBJETIVOS DE LA BASE DE DATOS DISTRIBUIDAS

Objetivos de Implementación

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

Transparencia de ubicación. Permite a los usuarios tener acceso a los datos sin que tenga conocimiento de la ubicación de éstos. Se puede conseguir este nivel de transparencia al utilizar los administradores de transacciones distribuidas, los cuales son capaces de determinar la localización de los datos y de emitir acciones a los calendarizadores apropiados, lo cual puede ejecutarse cuando los administradores de transacciones distribuidas poseen acceso a los directorios de localizaciones de los datos.

Transparencia de duplicación. Para que la transparencia de duplicación sea posible, los administradores de transacciones deben traducir las solicitudes de procesamiento de transacción en acciones para el administrador de datos. Para las lecturas el administrador de transacciones selecciona uno de los nodos que almacena los datos y ejecuta la lectura. Para optimizar el proceso, el administrador de transacciones necesita información sobre el rendimiento de varios nodos respecto al sitio de consulta, así podrá seleccionar el nodo de mejor rendimiento. La actualización y escritura de datos duplicados suelen ser más complicadas, ya que el manejador de transacciones debe emitir una acción de escritura para cada uno de los calendarizadores que almacena una copia de los datos.

Independencia de Datos: Organización de los datos es transparente para el programador

Transparencia en la Distribución: Localización de los datos es un aspecto adicional de independencia de datos

Reducción de redundancia: Una sola copia de datos que se comparta

Replicación de Datos: Copias múltiples de datos que incrementa la localidad y la disponibilidad de datos

Estructuras físicas complejas para accesos eficientes

No hay estructuras intersitios. Uso de optimización global para reducir transferencia de datos

Seguridad Problemas de seguridad intrínsecos

8

Transparencia de concurrencia. Cuando varias transacciones se ejecuten al mismo tiempo, los resultados de las transacciones no deberán afectarse. La trasparencia de concurrencia se logra 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 cualquier orden secuencial.

Transparencia de fallas. Significa que a pesar de fallas las transacciones sean procesadas de un modo correcto. Frente a una falla, las transacciones deben ser atómicas, significa que se procesen todas o ninguna de ellas. Para este tipo de problemas es importante tener resguardo de la base de datos, y así poder restaurarla cuando sea conveniente. El sistema debe detectar cuándo 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.

Localidad del procesamiento. Los datos se deben distribuir lo más cerca posible de las aplicaciones que los usan para maximizar la localidad del procesamiento, este principio responde a minimizar el acceso remoto a los datos. Diseñar una distribución que maximice localidad del procesamiento puede hacerse añadiendo la cantidad de referencias locales y remotas correspondientes a cada fragmentación candidata y asignar la fragmentación eligiendo la mejor solución. Independencia de configuración. La independencia de configuración permite añadir o reemplazar hardware sin tener que cambiar componentes de software existentes en el sistema de base de datos distribuida.

Particionamiento de la Base de Datos. La base de datos se distribuye de modo que no haya solapamiento o duplicación de los datos mantenidos en las diferentes localidades, como no hay duplicaciones de los datos, se evitan los costos asociados con el almacenamiento y mantenimiento de datos redundantes. Si un mismo segmento de datos se usa en más de una localidad se ve limitada la disponibilidad de los datos. La fiabilidad también puede verse limitada cuando se produce un fallo en el sistema de cálculo de una localidad se afecta la disponibilidad de los datos de esa localidad no estén disponible para los usuarios en cualquier parte del sistema.

Fragmentación de datos. Consiste en subdividir las relaciones y distribuirlas entre los sitios de la red, tiene como objetivo buscar formas alternativas de dividir una las instancias (tablas) de relaciones en otras más pequeñas. La fragmentación se puede realizar por tuplas individuales (fragmentación horizontal), por atributos individuales fragmentación vertical) o una combinación de ambas (fragmentación híbrida). El principal problema de la fragmentación radica en encontrar la unidad apropiada de distribución.

9

Una relación no es una buena unidad por muchas razones. Normalmente las vistas de una relación están formadas por subconjuntos de relaciones. Además, las aplicaciones acceden localmente a subconjuntos de relaciones. Por ello, es necesario considerar a los subconjuntos de relaciones como unidad de distribución. Al descomponer de una relación en fragmentos, tratados cada uno de ellos como una unidad de distribución, permite el proceso concurrente de las transacciones. El conjunto de estas relaciones, provocará la ejecución paralela de una consulta al ser dividida en una serie de subconsultas que operará sobre los fragmentos. Cuando las vistas definidas sobre una relación son consideradas como unidad de distribución que se ubican en diferentes sitios de la red, podemos optar por dos alternativas diferentes: 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 que pueden ser innecesarios con un mal manejo de estas replicas. Además, las réplicas innecesarias pueden causar problemas en la ejecución de las actualizaciones y puede no ser deseable si el espacio de almacenamiento está limitado. Los inconvenientes de la fragmentación están dados en que si las pueden estar definidas por fragmentos mutuamente exclusivos y al recuperar los datos de dos fragmentos situados en sitios diferentes es necesario trasmitir los datos de un sitio a otro y realizar sobre ellos la operación de unión (Join), lo cual puede ser costoso. El control semántico cuando los atributos implicados en una dependencia una relación se descompone en diferentes fragmentos y estos se ubican en sitios diferentes puede ser muy costos porque es necesario hacer búsquedas en un gran número de sitios.

Ventajas

Refleja una estructura organizacional - los fragmentos de la base de datos se ubican en los departamentos a los que tienen relación.

Autonomía local - un departamento puede controlar los datos que le pertenecen.

Disponibilidad - un fallo en una parte del sistema solo afectará a un fragmento, en lugar de a toda la base de datos.

Rendimiento - los datos generalmente se ubican cerca del sitio con mayor demanda, también los sistemas trabajan en paralelo, lo cual permite balancear la carga en los servidores.

Economía - es más barato crear una red de muchas computadoras pequeñas, que tener una sola computadora muy poderosa.

Modularidad - se pueden modificar, agregar o quitar sistemas de la base de datos distribuida sin afectar a los demás sistemas (módulos).

10

Desventajas

Complejidad - Se debe asegurar que la base de datos sea transparente, se debe lidiar con varios sistemas diferentes que pueden presentar dificultades únicas. El diseño de la base de datos se tiene que trabajar tomando en cuenta su naturaleza distribuida, por lo cual no podemos pensar en hacer joins que afecten varios sistemas.

Economía - la complejidad y la infraestructura necesaria implica que se necesitará una mayor mano de obra.

Seguridad - se debe trabajar en la seguridad de la infraestructura así como cada uno de los sistemas.

Integridad - Se vuelve difícil mantener la integridad, aplicar las reglas de integridad a través de la red puede ser muy caro en términos de transmisión de datos.

Falta de experiencia - las bases de datos distribuidas son un campo relativamente nuevo y poco común por lo cual no existe mucho personal con experiencia o conocimientos adecuados.

Carencia de estándares - aún no existen herramientas o metodologías que ayuden a los usuarios a convertir un DBMS centralizado en un DBMS distribuido.

PRINCIPIO FUNDAMENTAL

“ANTE EL USUARIO, UN SISTEMA DISTRIBUIDO DEBE LUCIR

EXACTAMENTE IGUAL QUE UN SISTEMA QUE NO ES DISTRIBUIDO”

1.-AUTONOMÍA LOCAL

Los sitios en un sistema distribuido deben ser autónomos, la autonomía local significa que todas las operaciones en un sitio dado están controladas por ese sitio; ningún sitio X debe depender de algún otro sitio Y para su operación satisfactoria. La seguridad, integridad y representación de almacenamiento de los datos locales permanecen bajo el control y jurisdicción del sitio local. 2.-NO DEPENDENCIA DE UN SITIO CENTRAL La autonomía local implica que todos los sitios deben ser tratados como iguales.

Por lo tanto, no debe haber particularmente ninguna dependencia de un sitio “maestro” central para algún servicio central, tal que todo el sistema dependa de ese sitio central.

Razones por las cuales no debería haber un sitio central:

El sitio central puede ser un cuello de botella

El sistema sería vulnerable; es decir, si el sitio central falla, también fallará todo el sistema

11

3.-OPERACIÓN CONTINUA Una ventaja de los sistemas distribuidos es que deben proporcionar mayor confiabilidad y mayor disponibilidad. Confiabilidad. La probabilidad de que el sistema esté listo y funcionando en cualquier momento dado. Los SD no son una propuesta de todo o nada; pueden continuar operando cuando hay alguna falla en algún componente independiente. Disponibilidad. La probabilidad de que el sistema esté listo y funcionando continuamente a lo largo de un período especificado. 4.- INDEPENDENCIA DE UBICACIÓN. Conocida también como transparencia de ubicación, donde los usuarios no tienen que saber dónde están almacenados físicamente los datos, sino que deben ser capaces de comportarse como si todos los datos estuvieran almacenados en su propio sitio local. Esto simplifica los programas de los usuarios. En particular, permite que los datos emigren de un sitio a otro sin invalidar ninguno de estos programas o actividades 5.- INDEPENDENCIA DE FRAGMENTACIÓN. Un sistema soporta la fragmentación de datos cuando puede ser dividida en o partes o fragmentos, para efectos de almacenamiento físico. La fragmentación es necesaria por razones de rendimiento: los datos pueden estar almacenados en la ubicación donde son usados más frecuentemente para que la mayoría de las operaciones sean locales y se reduzca el tráfico en la red. Los usuarios deben comportarse como si los datos en realidad estuvieran sin fragmentación alguna. 6.- INDEPENDENCIA DE REPLICACIÓN. El sistema soporta replicación de datos cuando un fragmento puede ser representado por muchas copias distintas, o réplicas, guardadas en muchos sitios distintos. Las réplicas son necesarias por dos razones principales: Significan un mejor rendimiento (las aplicaciones pueden operar sobre las copias locales en lugar de tener que comunicarse con sitios remotos) Pueden significar una mejor disponibilidad (un objeto replicado permanece disponible para su procesamiento, mientras esté disponible al menos una copia). Por supuesto, la principal desventaja de las réplicas es que al actualizarlas es necesario actualizar todas: el problema de la propagación de la actualización. 7.- PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS. La optimización es importante en un sistema distribuido que en uno centralizado, incluso mucho más.

12

El punto básico es que en una consulta que involucra a varios sitios, habrá muchas formas posibles de mover los datos en el sistema para satisfacer la solicitud, y es crucialmente importante que se encuentre una estrategia eficiente. 8.- ADMINISTRACIÓN DE TRANSACCIONES DISTRIBUIDAS. Existen dos aspectos principales en la administración de transacciones: control de recuperación y control de la concurrencia. Ambos aspectos requieren un tratamiento amplio en el ambiente distribuido. Ya que una sola transacción puede involucrar la ejecución de código en muchos sitios. Puede involucrar actualizaciones en muchos sitios y se debe de cuidar que la transacción no caiga en un bloqueo mortal (basado en el bloqueo). Para el control de la recuperación, es necesario asegurarse que una transacción dada sea atómica en el ambiente distribuido, el sistema debe por lo tanto asegurarse de que la transacción sea confirmada o deshecha (se puede utilizar el protocolo de confirmación de dos fases). 9.- INDEPENDENCIA DE HARDWARE. Soporte para un gran número de máquinas diferentes. Poder integrar todos los datos de todos estos sistemas y presentar al usuario una “imagen del sistema único”. 10.- INDEPENDENCIA DE SISTEMA OPERATIVO.

Obviamente es necesario no sólo tener la posibilidad de ejecutar el mismo DBMS en diferentes plataformas de hardware, sino también ejecutarlo en diferentes plataformas de sistema operativo. 11.- INDEPENDENCIA DE RED. Si el sistema va a tener la posibilidad de soportar muchos sitios distintos es obviamente necesario tener la posibilidad de soportar también una variedad de redes de comunicación distintas

1.3 DISCIPLINAS ESTUDIO BASES DE DATOS DISTRIBUIDAS

Las disciplinas de estudio de las bases de datos distribuidas son muchas,

constan de estudiar en si cómo se comportan los datos mediante unas bases de

datos y como tener que procesarse esa información que se almacena, cabe

mencionar que cada base de datos tiene su propio fin y cada una de ellas varia su

funcionamiento como por ejemplo:

13

Multi Base de Datos Distribuida

Cuando una base de datos distribuida es muy homogénea se dice que es multi base de datos distribuida.

Base de Datos Federada

Cuando una base de datos distribuida tiene mucha autonomía local se dice que es federada.

1.4 ARQUITECTURA DE BASE DE DATOS DISTRIBUIDAS

En un sistema de bases de datos distribuidas, existen varios factores que deben tomar en consideración que definen la arquitectura del sistema:

1. Distribución: Los componentes del sistema están localizados en la misma computadora o no.

2. Heterogeneidad: Un sistema es heterogéneo cuando existen en él componentes que se ejecutan en diversos sistemas operativos, de diferentes fuentes, etc.

3. Autonomía: Se puede presentar en diferentes niveles, los cuales se describen a continuación:

Autonomía de diseño: Habilidad de un componente del para decidir cuestiones relacionadas a su propio diseño.

Autonomía de comunicación: Habilidad de un componente del para decidir cómo y cuándo comunicarse con otros SMBD.

Autonomía de ejecución: Habilidad de un componente del para ejecutar operaciones locales como quiera.

Hay tres características importantes inherentes a los sistemas de bases de datos: la separación entre los programas de aplicación y los datos, el manejo de múltiples vistas por parte de los usuarios y el uso de un catálogo para almacenar el esquema de la base de datos. En 1975, el comité ANSI-SPARC (American National Standard Institute - Standards Planning and Requirements Committee) propuso una arquitecturade tres niveles para los sistemas de bases de datos, que resulta muy útil a la hora de conseguir estas tres características.

La definición de un sistema de información es la descripción detallada de la arquitectura del sistema. Las arquitecturas de bases de datos han evolucionado mucho desde sus comienzos, aunque la considerada estándar hoy en día es la descrita por el comité ANSI/X3/SPARC (Standard Planning and Requirements Committee of the American National Standards Institute on Computers and Information Processing), que data de finales de los años setenta. Este comité propuso una arquitectura general para DBMSs basada en tres niveles o esquemas: el nivel físico, o de máquina, el nivel externo, o de usuario, y el nivel

14

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

Arquitectura ANSI

La arquitectura de sistemas de bases de datos de tres esquemas fue aprobado por la ANSI-SPARC (American National Standard Institute - Standards Planning and Requirements Committee) en 1975 como ayuda para conseguir la separación entre los programas de aplicación y los datos, el manejo de múltiples vistas por parte de los usuarios y el uso de un catálogo para almacenar el esquema de la base de datos.

Nivel interno: Tiene un esquema interno que describe la estructura física de almacenamiento de base de datos. Emplea un modelo físico de datos y los únicos datos que existen están realmente en este nivel.

Nivel conceptual: tiene esquema conceptual. Describe la estructura de toda la base de datos para una comunidad de usuarios. Oculta los detalles físicos de almacenamiento y trabaja con elementos lógicos como entidades, atributos y relaciones.

Nivel externo o de vistas: tiene varios esquemas externos o vistas de usuario. Cada esquema describe la visión que tiene de la base de datos a un grupo de usuarios, ocultando el resto.

El objetivo de la arquitectura de tres niveles es el de separar los programas de aplicación de la base de datos física.

La mayoría de los SGBD no distinguen del todo los tres niveles. Algunos incluyen detalles del nivel físico en el esquema conceptual. En casi todos los SGBD que se manejan vistas de usuario, los esquemas externos se especifican con el mismo modelo de datos que describe la información a nivel conceptual, aunque en algunos se pueden utilizar diferentes modelos de datos en los niveles conceptuales y externos.

Hay que destacar que los tres esquemas no son más que descripciones de los mismos datos pero con distintos niveles de abstracción. Los únicos datos que existen realmente están a nivel físico, almacenados en un dispositivo como puede ser un disco. En un SGBD basado en la arquitectura de tres niveles, cada grupo de usuarios hace referencia exclusivamente a su propio esquema externo. Por lo tanto, el SGBD debe transformar cualquier petición expresada en términos de un esquema externo a una petición expresada en términos del esquema conceptual, y luego, a una petición en el esquema interno, que se procesará sobre la base de datos almacenada. Si la petición es de una obtención (consulta) de datos, será preciso modificar el formato de la información extraída de la base de datos almacenada, para que coincida con la vista externa del usuario. El proceso de transformar peticiones y resultados de un nivel a otro se denomina

15

correspondencia o transformación. Estas correspondencias pueden requerir bastante tiempo, por lo que algunos SGBD no cuentan con vistas externas.

La arquitectura de tres niveles es útil para explicar el concepto de independencia de datos que podemos definir como la capacidad para modificar el esquema en un nivel del sistema sin tener que modificar el esquema del nivel inmediato superior.

Se pueden definir dos tipos de independencia de datos:

La independencia lógica es la capacidad de modificar el esquema conceptual sin tener que alterar los esquemas externos ni los programas de aplicación. Se puede modificar el esquema conceptual para ampliar la base de datos o para reducirla. Si, por ejemplo, se reduce la base de datos eliminando una entidad, los esquemas externos que no se refieran a ella no deberán verse afectados.

La independencia física es la capacidad de modificar el esquema interno sin tener que alterar el esquema conceptual (o los externos). Por ejemplo, puede ser necesario reorganizar ciertos ficheros físicos con el fin de mejorar el rendimiento de las operaciones de consulta o de actualización de datos. Dado que la independencia física se refiere sólo a la separación entre las aplicaciones y las estructuras físicas de almacenamiento, es más fácil de conseguir que la independencia lógica.

En los SGBD que tienen la arquitectura de varios niveles es necesario ampliar el catálogo o diccionario, de modo que incluya información sobre cómo establecer la correspondencia entre las peticiones de los usuarios y los datos, entre los diversos niveles. El SGBD utiliza una serie de procedimientos adicionales para realizar estas correspondencias haciendo referencia a la información de correspondencia que se encuentra en el catálogo. La independencia de datos se consigue porque al modificarse el esquema en algún nivel, el esquema del nivel inmediato superior permanece sin cambios, sólo se modifica la correspondencia entre los dos niveles. No es preciso modificar los programas de aplicación que hacen referencia al esquema del nivel superior.

Por lo tanto, la arquitectura de tres niveles puede facilitar la obtención de la verdadera independencia de datos, tanto física como lógica. Sin embargo, los dos niveles de correspondencia implican un gasto extra durante la ejecución de una consulta o de un programa, lo cual reduce la eficiencia del SGBD. Es por esto que muy pocos SGBD han implementado esta arquitectura completa.

En el presente punto se mostrará la arquitectura general de un sistema de bases

de datos distribuida

La arquitectura define la estructura de un sistema. Al definir la arquitectura se deben identificar las componentes de un sistema, las funciones que realiza cada una de las componentes y las interrelaciones e interacciones entre cada componente.

16

1.-Arquitecturas de memoria compartida

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

2.-Arquitectura de disco compartido

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

17

3. Arquitecturas de nada compartido

Consiste de diversos procesadores cada uno con su propia memoria y su propia unidad de almacenamiento. Aquí se tienen los clústers de estaciones de trabajo, las computadoras Intel paragón, NCR 3600 y 3700 e IBM SP2

18

TÉRMINOS DE REPASO

Sgbdd

Base de de datos centralizados

Base de datos distribuidos

Objetivos de la base de datos distribuidos

Independencia de replicación

Autonomía local

Operación continua

Complejidad del sistema

Dependencia de la red de comunicaciones

Control de concurrencia

Reducción de redundancia

Procesamiento de consultas distribuidas.

Arquitectura de disco compartido

19

AUTO EVALUACION

1.- Explique la diferencia que existe entre la base de datos distribuido y uno

centralizado.

2.- Enliste los objetivos de la base de datos distribuidos.

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

4.-Menciona las características de la base de datos distribuidos

5.-La base de datos distribuidos posee ciertas ventajas, cuáles son:

6.-Menciona 4 desventajas de la base de datos distribuidos.

7.- Explique la diferencia de un Sgbdd y un Sgbdd en paralelo.

8.- A que objetivo se le conoce también como transparencia de ubicación

9.- Existen dos aspectos principales en la administración de transacciones, cuales

son:

10.-Las réplicas son necesarias por dos razones principales, menciónalas:

11.-Menciona una ventaja de los sistemas distribuidos

12.- Define que es una arquitectura de memoria compartida

13.-Mencione las responsabilidades del sgbdd.

20

2 UNIDAD: DISEÑO DE BASES DE DATOS DISTRIBUIDAS

2.1 CONSIDERACIONES DE DISEÑO DE BASES DE DATOS DISTRIBUIDAS

BASE DE DATOS DISTRIBUIDAS: Una base de datos distribuidas (llamada también BDD),es una colección de datos relacionados lógicamente ,pero dispersos sobre diferentes puntos de una red de computadoras. Cada sitio en la red tiene la capacidad de procesamiento autónomo y puede ejecutar aplicaciones locales.

Consideraciones al distribuir la base de datos Existen varias razones para construir sistemas distribuidos de bases de datos que incluyen compartir la 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

21

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.

22

Existen varios factores relacionados a la construcción de bases de datos distribuidas que no se presentan en bases de datos centralizadas. Entre los más importantes se encuentran los siguientes:

Diseño de la base de datos distribuidas

Procesamiento de consultas

Control de concurrencia

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

23

Niv

el

de c

om

part

ició

n

Características de

acceso

Inexistentes

Compartición de datos

y programas

Compartición de datos

Cada aplicación y sus datos se ejecutan en una

maquina sin comunicación con otros programas o

datos

Cada máquina posee sus propias aplicaciones

locales pero se comparten los datos

Las aplicaciones locales en una maquina

pueden invocar servicios en otras y edemas

comparten los datos

Estático

Dinámico

El modelo de acceso a los datos no varía con el

tiempo

El modelo de acceso a los datos varía con el tiempo

24

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 (botton – up).- En este caso se partirá de los esquemas conceptuales locales y se trabajaría para llegar a conseguir el esquema conceptual global. Después se pasaría al diseño de distribución. Esta estrategia suele ser utilizada para integrar varias bases de datos centralizadas existentes La estrategia descendente (top - Dow).- Se parte de cero y se avanza en el desarrollo del trabajo. Los pasos a realizar mediante esta estrategia son:

Análisis de requisitos

Diseño de vistas

Diseño conceptual

Diseño de la distribución

Fragmentación

Asignación

Diseño físico

Monitorización y ajuste

Niv

el

de c

on

ocim

ien

to

Sin información

Con información

parcial

Con información

total

Los diseñadores no tienen información de cómo

acceden los usuarios a los datos

Los diseñadores no poseen toda la información de

cómo acceden los usuarios a los datos

Los diseñadores poseen toda la información de

cómo aceden los usuarios a los datos

25

Factores tomados en cuenta:

Repetición.- El diseñador debe considerar que ese sistema mantendrá varias copias idénticas. Cada copia se almacenara en una localidad diferente lo que resulta en una repetición de la información.

Fragmentación.- Las relaciones de una base de datos distribuida se puede dividir en varios fragmentos. Cada fragmento se almacenara en una localidad diferente, es decir el diseñador debe evaluar la propiedad de que haya fragmentado en diferentes localidades.

Repetición y fragmentación.- Esta consideración es de suma importancia porque es la combinación de los dos conceptos antes mencionados; es decir, el sistema debe de ser capaz de mantener varias copias idénticas de cada uno de los fragmentos.

26

27

2.2 DICCIONARIO DE DATOS

Es el lugar donde se deposita información acerca de todos los datos que forman la base de datos. Es una guía en la que se describe la base de datos y los objetos que la forman.

Los diccionarios de datos son el segundo componente del análisis del flujo de datos. En sí mismos los diagramas de flujo de datos no describen por completo el objeto de la investigación. El diccionario de datos proporciona información adicional sobre el sistema. Esta sección analiza que es un diccionario de datos, por qué se necesita en el análisis de flujo de datos y como desarrollarlo. Se utilizará el ejemplo del sistema de contabilidad para describir los diccionarios de datos.

Un diccionario de datos es una lista de todos los elementos incluido en el conjunto de los diagramas de flujo de datos que describen un sistema. Los elementos principales en un sistema, estudiados en las secciones anteriores, son el flujo de datos, el almacenamiento de datos y los procesos. El diccionario de datos almacena detalles y descripciones de estos elementos.

El diccionario contiene las características lógicas de los sitios donde se almacenan los datos del sistema, incluyendo nombre, descripción, contenido y organización. Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información. Un diccionario de datos debe cumplir las siguientes características:

Debe soportar las descripciones de los modelos conceptual, lógico, interno y externo de la dase de datos.

Debe estar integrado dentro del SGBD.

Debe apoyar la transferencia eficiente de información al SGBD. La conexión entre los modelos internos y externo debe ser realizada en un tiempo de ejecución.

Debe comenzar con la reorganización de versiones de producción de la base de datos. Además debe reflejar los cambios en la descripción de la BD. Cualquier cambio a la descripción de programas ha de ser reflejado automáticamente en la librería de descripción de programas con la ayuda del diccionario de datos.

Debe estar almacenado en un medio de almacenamiento con acceso directo para la fácil recuperación de información

28

Ejemplo de diccionario de datos:

2.3 NIVELES DE TRANSPARENCIA

El propósito de establecer una arquitectura de un sistema de bases de datos distribuidas es ofrecer un nivel de transparencia adecuado para el manejo de la información. La transparencia se puede entender como la separación de la semántica de alto nivel de un sistema de los aspectos de bajo nivel relacionados a la implementación del mismo. Un nivel de transparencia adecuado permite ocultar los detalles de implementación a las capas de alto nivel de un sistema y a otros usuarios. En sistemas de bases de datos distribuidos el propósito fundamental de la transparencia es proporcionar independencia de datos en el ambiente distribuido. La independencia de datos es la inmunidad de las aplicaciones de usuario a los cambios en la definición y/u organización de los datos y viceversa. La independencia de datos se puede dar en dos aspectos: lógica y física. Independencia lógica de datos. Se refiere a la inmunidad de las aplicaciones de usuario a los cambios en la estructura lógica de la base de datos. Esto permite

29

que un cambio en la definición de un esquema no deba afectar a las aplicaciones de usuario. Por ejemplo, el agregar un nuevo atributo a una relación, la creación de una nueva relación, el reordenamiento lógico de algunos atributos. Independencia física de datos. Se refiere al ocultamiento de los detalles sobre las estructuras de almacenamiento a las aplicaciones de usuario. Esto es, la descripción física de datos puede cambiar sin afectar a las aplicaciones de usuario. Por ejemplo, los datos pueden ser movidos de un disco a otro, o la organización de los datos puede cambiar. Los diferentes niveles de transparencia se pueden organizar en capas como se muestra en la figura siguiente. En el primer nivel se soporta la transparencia de red. En el segundo nivel se permite la transparencia de replicación de datos. En el tercer nivel se permite la transparencia de la fragmentación. Finalmente, en el último nivel se permite la transparencia de acceso (por medio de lenguaje de manipulación de datos). La responsabilidad sobre el manejo de transparencia debe estar compartida tanto por el sistema operativo, el sistema de manejo de bases de datos y el lenguaje de acceso a la base de datos distribuida.

Según el manual de referencia ANSA y el modelo de referencia para el procesamiento distribuido abierto de la organización internacional de estándares, el concepto se aplica a 8 aspectos diferentes:

Transparencia de acceso: oculta las diferencias entre la representación de los datos y la manera en que los recursos son accedidos.

Transparencia de ubicación: oculta la localización de los recursos y permite el acceso a los mismos sin la necesidad de conocer su localización.

Transparencia de migración: oculta que un recurso o un cliente del sistema sea reubicado, lo que permite hacer dichas reubicaciones sin afectar la operación de los usuarios y los servicios.

Transparencia de recolocación: oculta que un recurso o cliente del sistema pueda moverse a una ubicación diferente mientras están en uso.

Transparencia de replicación: oculta la existencia de múltiples ejemplares del mismo recurso.

Transparencia de concurrencia: oculta que un recurso sea compartido por varios usuarios sin interferir entre ellos mismos.

Transparencia frente a fallos: oculta los fallos y recuperación de un recurso dentro del sistema, dejando que los usuarios terminen sus tareas a pesar de los fallos de hardware o software que pudieran presentarse.

Transparencia de persistencia: oculta si un recurso de software está almacenado en memoria o en disco.

30

Se pueden encontrar diferentes aspectos relacionados con la transparencia. Por ejemplo, puede existir transparencia en el manejo de copias repetidas o transparencia en la distribución o fragmentación de la información

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

Organización en Capas de los Niveles de Transparencia.

31

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.

2.3.2 TRANSPARENCIA DE FRAGMENTACION La transparencia a nivel de fragmentación de datos permite que cuando los objetos de la bases de datos están fragmentados, el sistema tiene que manejar la conversión de consultas de usuario definidas sobre relaciones globales a consultas definidas sobre fragmentos. Así también, será necesario mezclar las respuestas a consultas fragmentadas para obtener una sola respuesta a una consulta global. El acceso a una base de datos distribuida debe hacerse en forma transparente. Es el mayor nivel, el usuario o programador no necesita saber que una base de datos esta en particiones. Ni los nombres, ni la ubicación se especifican antes de acceder a los datos. Permite al usuario acceso a la información de un archivo fragmentado como si todos los datos del archivo estuvieran en una misma computadora. Es decir, cuando se crea transparencia de fragmentación, el sistema crea la ilusión de que los archivos no están fragmentados La transparencia a nivel de fragmentación de datos permite que cuando los objetos de las bases de datos están fragmentados, el sistema tiene que manejar la conversación de consultas de usuarios definidas sobre relaciones globales a consultas definidas sobre fragmentos. Así también, será necesario mezclar las respuestas a consultas fragmentadas para obtener una sola respuesta a una consulta global. El acceso a una base de datos distribuida debe hacerse en forma transparente.

2.3.3 TRANSPARENCIA DE REPLICA

Los usuarios no pueden indicar el número de copias existentes. La transparencia sobre la replicación de datos se refiere a que si existen réplicas de objetos de la base de datos, su existencia debe ser controlada por el sistema, no por usuario, se debe tener en cuenta que cuando el sistema se encarga de manejar las réplicas en un sistema, el trabajo de éste es mínimo por lo que se puede obtener una eficiencia mayor. Sin embargo, el usuario puede olvidarse de mantener la consistencia de las réplicas teniendo así datos diferentes. Por lo que se sugiere que las réplicas las haga el sistema en su totalidad sin que el usuario se percate si está trabajando o no sobre una réplica.

32

Los usuarios ven cada objeto de datos como lógicamente único. Puede que el sistema distribuido replique los objetos para incrementar el rendimiento del sistema o la disponibilidad de los datos. Los usuarios no deben preocuparse por los objetos que se hayan replicado ni por la ubicación de esas réplicas. El sistema conserva replicas (copias) idénticas de la relación y guarda cada replica en un sitio diferente. La alternativa a las réplicas es almacenar solo una copia de la relación r. Si un archivo esta replicado, el usuario no distingue cual de las réplicas está leyendo. Si un proceso realiza una actualización, el sistema operativo deberá actualizar todas las replica. Ventajas:

Disponibilidad: El sistema sigue funcionando aun en caso de caída de uno de los nodos

Aumento de paralelismo: Varios nodos pueden realizar consultas en paralelo sobre la misma tabla. Cuantas más replicas existan de la tabla, mayor será la posibilidad de que el dato buscado se encuentre en el nodo desde el que se realiza la consulta, minimizando con ello el tráfico de datos entre nodos.

2.4 FRAGMENTACION DE DATOS

La fragmentación consiste en particionar la información para distribuir cada parte en diferentes lugares de la red. De forma que cada relación se divide en varios fragmentos. Cada fragmento se guarda en una localización diferente. Si la relación r está fragmentada, se dividirá en cierto número de fragmentos r1, r2… rn. Estos fragmentos contendrán suficiente información como para permitir la reconstrucción de la relación original r.

La fragmentación de la información se puede llevar a cabo de tres formas: Fragmentación vertical. Fragmentación horizontal. Fragmentación mixta o hibrida.

33

El problema de fragmentación se refiere al particionamiento de la información para distribuir cada parte a los diferentes nodos y sitios de la red. 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 que cada tupla 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.

1.- Completitud. 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.

2.- 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.

3.- 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.

2.4.1 FRAGMENTACION HORIZONTAL

La tabla T se divide en subconjuntos, T1, T2, ...Tn. Cada tupla de T debe pertenecer al menos a uno de los fragmentos para poder reconstruir la tabla original a partir de los fragmentos. Los fragmentos se definen a través de una operación de selección y su reconstrucción se realizará en base a una operación de unión de los fragmentos componentes.

34

En el ejemplo siguiente, se ilustra una posible fragmentación de la tabla Alumnos de dos fragmentos: uno para el nodo de la EUI y otro para el nodo de la EUIT. Nodos de las Escuelas:

La recuperación de la relación original se realizará a partir de la unión de cada uno

de los fragmentos: T= T1∪ T2∪...∪ Tn

En nuestro caso: ALUMNOS=ALUMNOS_EUI ∪ ALUMNOS_EUIT

35

EJEMPLO 2

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

36

Fragmentación horizontal primaria Consiste del particionamiento en tuplas de una relación global en subconjuntos, donde cada subconjunto puede contener datos que tienen propiedades comunes y se puede definir expresando cada fragmento como una operación de selección sobre la relación global. Ejemplo Considere la relación global

SUPPLIER ( SNUM, NAME, CITY )

Entonces, la fragmentación horizontal puede ser definida como:

SUPPLIER1 = SLcity == "SF"SUPPLIER SUPPLIER1 = SLcity == "LA"SUPPLIER

1. Esta fragmentación satisface la condición de completes si "SF" y "LA" son solamente los únicos valores posibles del atributo CITY. 2. La condición de reconstrucción se logra con: SUPPLIER = SUPPLIER1 unión SUPPLIER2 3. La condición de disjuntos se cumple claramente en este ejemplo. Fragmentación horizontal derivada La fragmentación derivada horizontal se define partiendo de una fragmentación horizontal. En esta operación se requiere de Semi-junta (Semi-Join) el cual nos sirve para derivar las tuplas o registros de dos relaciones. Ejemplo Las siguientes relaciones definen una fragmentación horizontal derivada de la relación SUPPLY.

SUPPLY1 = SUPPLYSJsnum == snumSUPPLIER1 SUPPLY2 = SUPPLYSJsnum == snumSUPPLIER2

37

2.4.2 FRAGMENTACION VERTICAL

La fragmentación vertical, en cambio, se basa en los atributos de la relación para efectuar la división o fragmentación. Ejemplo:

La fragmentación vertical es la subdivisión de atributos en grupos. Los fragmentos se obtienen proyectando la relación global sobre cada grupo. La fragmentación es correcta si cada atributo se mapea en al menos un atributo del fragmento. Ejemplo Considere la siguiente relación global:

EMP ( empnum, name, sal, tax, mgrnum, depnum )

Una fragmentación vertical de esta relación puede ser definida como: EMP1 = PJempnum, name, mgrnum, depnum EMP

EMP2 = PJempnum, sal, tax EMP la reconstrucción de la relación EMP puede ser obtenida como:

EMP = EMP1 (JN empnum) EMP2 porque empnum es una clave de EMP

38

2.4.3 FRAGMENTACION MIXTA O HIBRIDA Fragmentación mixta o hibrida 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: 1.- Desarrollando primero la fragmentación vertical y posteriormente, aplicando partición horizontal de los fragmentos verticales (denominada partición VH) 2.- Aplicando primero una división horizontal para luego, sobre los fragmentos generados, desarrollar una fragmentación vertical (llamada partición HV) 3.- De forma directa considerando la semántica de las transacciones. Ejemplo de la fragmentación mixta HV: Ejemplo Considere la relación global

EMP( empnum, name, sal, tax,

mrgnum, depnum )

Las siguientes son para obtener una fragmentación mixta, aplicando la vertical seguida de la horizontal:

EMP1 = SL depnum <= 10

PJempnum, name, mgrnum, depnum EMP EMP2 = SL 10 < depnum <= 20 PJempnum, name, mgrnum, depnum EMP

EMP3 = SL depnum > 20 PJempnum, name, mgrnum, depnum EMP EMP4 = PJ empnum, name, sal, tax EMP

La reconstrucción de la relación EMP es definida por la siguiente expresión:

EMP = UN(EMP1, EMP2, EMP3)JNempnum =

empnumPJempnum, sal, tax EMP4

Finalmente, como otro ejemplo considere el siguiente esquema global

EMP(EMPNUM, NAME, SAL, TAX, MGRNUM, DEPNUM)

39

DEP(DEPNUM, NAME, AREA, MGRNUM) SUPPLIER(SNUM, NAME, CITY)

SUPPLY(SNUM, PNUM, DEPNUM, QUAN)

Después de aplicar una fragmentación mixta se obtiene el siguiente esquema fragmentado

EMP1 = Sldepnum <= 10 PJempnum, name, mgrnum, depnum (EMP) EMP2 = SL 10 < depnum <= 20 PJempnum, name, mgrnum, depnum

(EMP) EMP3 = SL depnum > 20 PJempnum, name, mgrnum, depnum (EMP)

EMP4 = PJ empnum, name, sal, tax (EMP) DEP1 = SL depnum <= 10 (DEP)

DEP2 = SL 10 < depnum <= 20 (DEP) DEP3 = SL depnum > 20 (DEP)

SUPPLIER1 = SL city == "SF" (SUPPLIER) SUPPLIER2 = SL city == "LA" (SUPPLIER)

SUPPLY1 = SUPPLYSJsnum == snumSUPPLIER1 SUPPLY2 = SUPPLYSJsnum == snumSUPPLIER2

¨

40

2.5 DISTRIBUCION DE DATOS

Describe el proceso de decidir donde localizar los datos. Una de las decisiones más importantes que el diseñador de bases de datos distribuidas debe tomar es el posicionamiento de los datos en el sistema y el esquema bajo el cual lo desea hacer Replicación de datos La replicación de datos se refiere al almacenamiento de copias de datos en sitios múltiples servidos por una red de computadoras. Pueden guardarse copias de fragmento para satisfacer requerimientos de información específicos. La replicación en SQL Server consiste, en el transporte de datos entre dos o más instancias de servidores.

Base de datos totalmente replicada, guarda varias copias de cada fragmento de la base de datos en varios sitios. No es práctica debido la cantidad de carga impuesta al sistema.

Base de datos parcialmente replicada, guarda múltiples copias de algunos fragmentos de la base de datos en múltiples sitios. Se tiene un buen manejo

Base de datos no replicada, guarda cada fragmento de base de datos en un solo sitio.

Suponga que la base de datos A esta dividida en fragmentos: A1 Y A2 dentro de una base de datos distribuida replicada, es posible el escenario ilustrado en la fig.10.20: el fragmento A1 se guarda en los sitios S1 y S2, mientras que el A2 se guarda en los sitios S2y S3.

Los datos replicados requiere que todas las copias de fragmentos de datos sean idéntica, por consiguiente para mantener la consistencia de los datos entre las replicas, el DDBMS debe garantizar que se realice una actualización de la base de datos donde existen replicas.

La replicación exige más complejidad de procesamiento del DDBMS por que cada copia de dato debe ser mantenida por el sistema.

41

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

accesar Una operación read (lectura) selecciona la copia más cercana para

satisfacer la transacción. Una operación write (escritura) requiere que todas las copias se

seleccionen y se actualizan. Tipos de replicación Los tipos básicos de replicación son:

replicación de instantáneas replicación transaccional replicación de mezcla

REPLICACIÓN DE INSTANTÁNEAS En la replicación de instantáneas los datos se copian tal y como aparecen exactamente en un momento determinado. Por consiguiente, no requiere un control continuo de los cambios. Las publicaciones de instantáneas se suelen replicar con menos frecuencia que otros tipos de publicaciones. Puede llevar más tiempo propagar las modificaciones de datos a los suscriptores. Se recomienda utilizar: cuando la mayoría de los datos no cambian con frecuencia REPLICACIÓN TRANSACCIONAL En este caso se propaga una instantánea inicial de datos a los suscriptores, y después, cuando se efectúan las modificaciones en el publicador, las transacciones individuales se propagan a los suscriptores REPLICACIÓN DE MEZCLA Permite que varios sitios funcionen en línea o desconectados de manera autónoma, y mezclar más adelante las modificaciones de datos realizadas en un resultado único y uniforme. TIPOS DE RELACIONES:

1.- RELACIONES BASE O REALES: Corresponde al concepto de Tabla es

decir una relación autónoma cuya importancia está dada por el diseñador para un uso especifico dentro de una aplicación

2.- RELACIONES VIRTUALES: (Relaciones de Vistas) Una vista es una

relación derivada con nombre representada dentro del sistema exclusivamente mediante su definición en término de otras relaciones, no posee datos

42

almacenados propios, separados y distinguibles a diferencia de las relaciones Bases, en si una VISTA.

3.- RELACIONES INSTANTANEAS: (Snap Shop) Es también una relación

derivada con nombre como una vista pero a diferencia de esta última las instantáneas son reales no virtuales, es decir, están representadas no solo por su definición, en término de otras relaciones con nombre, sino, también por sus propios datos almacenados:

(Snap Shop = consulta rápida, corta) Las estrategias que se tienen son:

Colocación centralizada de los datos, toda la base de datos se guarda en un sitio

Colocación particionada de los datos, la base de datos se divide en varias partes desarticuladas (fragmentos) y se guardan en varios sitios.

Colocación replicada de los datos, se guardan copias de uno o más fragmentos de la base de datos en varios sitios.

La distribución de los datos se logra mediante la partición de los datos, replicados de los datos o mediante una combinación de ambas.

La colocación de los datos está estrechamente relacionada en como la BD se divide o fragmenta. La colocación de los datos ve que datos localizar y en donde.

Los algoritmos de colocación de los datos consideran varios factores, incluidos:

Objetivos de desempeño y disponibilidad de los datos. Tamaño, numero de filas y el número de relaciones que una entidad

mantiene con otras entidades. Tipos de transacciones a ser aplicadas a la base de datos.

2.5 1 ALGORITMOS DE DISTRIBUCION DE DATOS NO REPLICADOS

Permite maximizar el costo de comunicación y al mismo tiempo maximizar el tiempo de respuesta. El administrador de bases de datos debe de evaluar el modo de operar de la base de datos, es decir como su nombre lo indica no podemos realizar el algoritmo en aquellas copias, pero debe ser sobre la base de datos original. La fragmentación hibrida es de preferencia lo que debe de llevar este tipo de algoritmos, porque estas utilizan las tres fragmentaciones y las más aconsejables. Hablar de algoritmos implica sobre la Programación Hay gestores que son muy flexibles en cuestiones de programación, mientras que otros ofrecen más rendimiento. Así, al diseñar el algoritmo tendrá que hacer toda la información referente a la vida de la base de datos pero por otro lado deberá

43

buscar siempre de darle soluciones al usuario, pues este será el que al final de cuentas interesa. Existen en la actualidad infinidad de tecnologías en cuanto a los gestores de la base de datos se refiere, el que utilizaremos (el más actual) será SQL SERVER, este gestor comenzó a crearse por la década de los 90´s, ofrece muchas ventajas sobre otros gestores, la única desventaja que podríamos encontrar en su compatibilidad con los Windows más comerciales como el 98, XP entre otros. Se preguntaran que tiene que ver el gestor con los algoritmos de datos no replicados, sin embargo la respuesta es muy sencilla, y esta es que este algoritmo es fácil de implantar en SQL SERVER.

2.5.2 ALGORITMOS DE DISTRIBUCION DE DATOS REPLICADOS

Se refiere al almacenamiento de copias de datos en sitios múltiples, puede ser para satisfacer requerimientos de información, además de mejorar la disponibilidad de los datos y el tiempo respuesta; finalmente estas copias reducen los costos de comunicación y de consulta total. Los datos replicados se someten a la regla de consistencia mutua, la cual requiere que todas las copias de fragmentos de datos sean idénticas, esto quiere decir que cuando hay una actualización de la base de datos se realiza en todos los sitios donde hay replicas. El algoritmo de distribución de datos replicados será realizado principalmente para los datos que ya tengan una copia aunque es muy útil, lo cual podemos asegurar que su utilización y programación dependerá de un 100% del gestor que se utilizando SQL SERVER a pesar de su facilidad de utilización también incorpora herramientas sofisticadas para aquellos usuarios de nivel avanzado. Entre algunas de las novedades que trae SQL SERVER, es que integra un servidor completo y un módulo para la transformación de datos. Otras de las características que posee SQL SERVER es un bloqueo dinámico a nivel de fila, paralelismo entre consultas; consultas distribuidas y permite aceptar bases de datos de gran tamaño. Para crear una base de datos en SQL SERVER lo podemos hacer primeramente usando el asistente de base de datos y la interfaz predefinida para la creación de base de datos. Tabla en SQL SERVER

Columna Name Data Type Lenght Allow Nulls

Esta parte se debe colocar todos los nombres de los campos que tendrá la tabla.

Aquí se coloca el tipo de dato que lleva el campo anteriormente ubicado.

Tamaño del campo.

Si se activa esta opción significara que esta opción permitirá valores nulos.

44

Propiedades de los campos de las tablas

Descripción.- Esta propiedad es exclusiva para el diseñador o bien para el administrador. Default value.- Se usa para especificar un valor predeterminado para la columna. Precisión.- Se utiliza para campos numéricos, por aquí se indica la cantidad de dígitos que llevara un número. Scale.- Indica el número de dígitos decimales. Identify.- Si esta opción se marca con un si estaremos indicando que el campo tendrá un número generado automáticamente. Identify Seed.- Indica el valor inicial para el primer registró. Identify Increment.- Indica el valor del incremento. Is Row Guid.- Esta propiedad creara un contenido global y único. Cualquier tabla puede tener este tipo de columna en el momento que se crea necesario por el diseñador. Fórmula.- Es una propiedad exclusiva y diseñadas para aquellos campos que necesitan alguna función. Collation.- En este campo se debe de especificar a qué base de datos pertenece la tabla que estamos generando se hace por default esta tabla pertenecerá a la base de datos desde donde fue fragmentada.

45

TÉRMINOS DE REPASO

Base de datos distribuidos

Nivel de compartición

Botton – up

Top-Dow

Fragmentación

Monitorización y ajuste

Diccionario de datos

Niveles de transparencia

Independencia física

Independencia lógica

Transparencia de localización

Transparencia de fragmentación

Transparencia de replica

Aumento de paralelismo

Fragmentación vertical

Fragmentación horizontal

Fragmentación mixta o hibrida

Grado de fragmentación

Completitud

Reconstrucción

Disyunción

Algoritmos de colocación de los datos

Algoritmos de distribución de datos no replicados

Default value

Scale

Identify

Identify Seed

Is Row Guid

46

AUTO EVALUACION 1.- En el diseño de bases de datos distribuidas se debe considerar el problema de cómo distribuir la información entre diferentes sitios, cuales son: 2.- Qué diferencia hay entre la estrategia ascendente (botton – up) y la estrategia

descendente (top-Dow)

3.- Mencione los pasos para realizar la estrategia descendente (top-Dow):

4.- Cuales son las características que un diccionario de datos debe cumplir

5.- La independencia de datos se puede dar en dos aspectos, menciónelos:

6.- Cual es la diferencia entre la transparencia de localización y la transparencia

de fragmentación.

7.- Menciona 2 ventajas de la transparencia de replica

8.-En que consiste la fragmentación de datos

9.- La fragmentación de la información se puede llevar a cabo de tres formas, cuales son: 10.-Define la fragmentación vertical y ejemplifique 11.- La fragmentación mixta puede llevarse a cabo de tres formas diferentes, cuales son y descríbalos 12.- Ejemplifique la fragmentación mixta HV 13.-Mencione las estrategias que utiliza la distribución de datos: 14.-En que consisten los algoritmos de distribución de datos no replicados 15.-Que diferencia existe entre los algoritmos de distribución de datos no replicados y los algoritmos de distribución de datos replicados.

47

3UNIDAD: PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS

3.1 Metodología del procesamiento de consultas distribuidas Las consultas distribuidas obtienen acceso a datos de varios orígenes de datos

heterogéneos. Estos orígenes de datos pueden estar almacenados en el mismo

equipo o en equipos diferentes. Microsoft SQL Serveradmite consultas distribuidas

utilizando OLE DB.

Los usuarios de SQL Server pueden utilizar consultas distribuidas para obtener

acceso a lo siguiente:

Datos distribuidos almacenados en varias instancias de SQL Server.

Datos heterogéneos almacenados en varios orígenes de datos relacionales

y no relacionales a los que se obtiene acceso mediante un proveedor OLE

(Object Linking and Embedding (Incrustación y Vinculación de Objetos) DB.

•

•

48

Operaciones Aritméticas en Consultas

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

varios campos de la base de datos utilizando operaciones matemáticas.

• Las operaciones básicas son suma (+), resta (-), división (/) y multiplicación

(*).

• A continuación vamos a mostrar algunos ejemplos:

Operaciones Aritméticas – Mult.

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

atributo salario sólo tiene el pago mensual)

• SELECT emp_nombre, emp_salario * 12

• FROM empleado;

49

Operaciones Aritméticas - SumaOperaciones Aritméticas – Suma

• ¿A cuánto subiría el salario de cada empleado si le incluimos 300 dólares

de aumento? Mostrar el nombre y el salario incluyéndole el aumento de

300 dólares.

• SELECT emp_nombre, emp_salario + 300

• FROM empleado;

Operaciones Aritméticas – Varios

• Mostrar el nombre y lo que gana el empleado en comisión para aquellos

que son vendedores.

• SELECT emp_nombre, emp_commision * emp_salario / 100

• FROM empleado

• WHERE emp_titulo = ‘Vendedores’;

Operaciones Alfanuméricas en Consultas

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

• Permiten una mejor presentación de los datos en pantalla y/o reportes.

• Ayuda en la búsqueda de instancias en la tabla.

• A continuación mostramos algunos ejemplos

Operaciones Alfanuméricas en Consultas – Ejemplo 1

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

blanco)

• SELECT emp_nombre || emp_apellidos

FROM empleado;

Operaciones Aritméticas con Fechas en Consultas

• SQL permite ejecutar queries que incluyan operaciones aritméticas con

fechas.

• Es útil para manejar días, diferencias entre fechas y calcular estimados de

tiempo.

50

• A continuación mostramos algunos ejemplos:

Operaciones Aritméticas con Fechas en Consultas – Ejemplo 1

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

corresponde evaluarlo en la empresa ( La evaluación se hace después de

los primeros 6 meses de comenzar a trabajar)

• SELECT emp_nombre, emp_fecha_inicio,

ADD_MONTHS(emp_fecha_inicio,6) AS ‘Fecha

• Evaluación’

• FROM empleado;

La función principal de un procesador de consultas relacionales es transformar una consulta en una especificación de alto nivel, típicamente en cálculo relacional, a una consulta equivalente en una especificación de bajo nivel, típicamente alguna variación del álgebra relacional. La consulta de bajo nivel implementa de hecho la estrategia de ejecución para la consulta. La transformación debe ser correcta y eficiente. Es correcta si la consulta de bajo nivel tiene la misma semántica que la consulta original, esto es, si ambas consultas producen el mismo resultado.

51

Ejemplo: E( ENO, ENOMBRE, TITULO ) G( ENO, JNO, RESPONSABLE, JORNADA ) y la siguiente consulta de usuario: "Encuentre todos los nombres de empleados que manejan un proyecto" La expresión de la consulta en SQL se puede ver como SELECT ENOMBRE FROM E, G WHERE E.ENO = G.ENO AND RESPONSABLE = "ADMINISTRADOR" Dos consultas equivalentes en el álgebra relacional que son transformaciones correctas de la consulta en SQL son: Como es intuitivamente obvio, la segunda estrategia que evita calcular el producto cartesiano entre E y G, consume mucho menos recursos que la primera y, por lo tanto, es mejor.

52

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

53

3.2 ESTRATEGIAS DE PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS

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

comunicaciones.

Objetivo: la reducción de la cantidad de datos transferidos.

Optimización mediante operación de semijoin.

En un sistema distribuido existen factores que complican el proceso de

consulta en comparación con los sistemas centralizados.

Costo de transferencia de datos a través de la red.

Ejemplos de consulta distribuida:

54

Tamaño de la relación EMPLEADO es 100 * 10.000 = 106 bytes

Tamaño de la relación DEPARTAMENTO es 35 * 100 = 3500 bytes.

Consideremos la consulta:

“Por cada empleado, obtener el nombre del empleado y el nombre del

departamento al que pertenece”.

La expresión de ésta consulta en álgebra relacional será:

El resultado de ésta consulta constará de 10.000 tuplas. Cada tupla resultante

será de una longitud de 40 bytes. El tamaño del resultado será por tanto de

400.000 bytes.

Supongamos que el resultado viaja al nodo 3, denominado nodo respuesta ya que

será el lugar donde se requiera el resultado de dicha consulta. Sin embargo, ni la

relación EMPLEADO ni DEPARTAMENTO residen en dicho nodo.

Ejemplo de consulta distribuida:

Contador:

TODEPARTAMENEMPLEADOQ NombreDptoApellidoNombre *: ,,

TODEPARTAMENEMPLEADOQ NombreDptoApellidoNombre *: ,,

40 * 10000

400000

Nodo 2 departamento

NombreDeppto 10

Resultado de la

consulta Nodo empleado1

Nombre 15 Apellido 15

55

Estrategias:

1. Transferir la relación EMPLEADO y DEPARTAMENTO al nodo

respuesta (nodo 3) y realizar allí la operación de join. En éste caso se

transfieren 1.000.000 + 3.500 = 1.003.500 bytes.

Contador:

2. Transferir la relación EMPLEADO al nodo 2, ejecutar el join en este

nodo y enviar el resultado al nodo 3. Esto implicaría transferir 1.000.000

bytes de EMPLEADO + 400.000 bytes del resultado, es decir: 1.400.000

bytes.

Contador:

40 * 10000

1000000 +

400000

1400000 Nodo 3 Resultado

Nodo 1 empleado

1000000

1000000

Nodo 3 Resultado

Nodo 2 Departamento

3500

1003500

1000000 + 3500

Nodo 2 departamento

56

3. Transferir la relación DEPARTAMENTO al nodo 1, ejecutar el join en este nodo

y enviar el resultado al nodo 3. En este caso, los bytes transferidos serán: 3.500

de la relación DEPARTAMENTO más 400.000 del resultado. Es decir 403.500

bytes.

Contador:

Realizar las operaciones de selección lo antes posible

Combinar el producto cartesiano con una operación de selección subsiguiente cuyo predicado represente una condición de combinación, para formar una operación de combinación

Utilizar la asociatividad de las operaciones binarias para reordenar los nodos hoja de modo que los nodos hoja con las operaciones de selección más restrictivas se ejecuten primero

Realizar las operaciones de proyección lo antes posible

Calcular una única vez las expresiones posibles.

3.2.1 ÁRBOLES DE CONSULTAS. Árbol: En ciencias de la informática, un árbol es una estructura de datos ampliamente usada que imita la forma de un árbol (un conjunto de nodos conectados). Un nodo es la unidad sobre la que se construye el árbol y puede tener cero o más nodos hijos conectados a él. Se dice que un nodo a es padre de un nodo b si existe un enlace desde a hasta b (en ese caso, también decimos que b es hijo de a). Sólo puede haber un único nodo sin padres, que llamaremos raíz. Un nodo que no tiene hijos se conoce como hoja. Los demás nodos (tienen padre y uno o varios hijos) se les conoce como rama.

Nodo 2 departamento

3500

3500 + 4000000

Nodo 1 empleado

403500

Nodo 3 Resultado

403500

57

Consulta: método para acceder a los datos en la base de datos. Con las consultas se puede modificar, mostrar agregar datos de una BD. ÁRBOL DE LA CONSULTA SQL Es una representación interna de una sentencia SQL donde las partes individuales que la construyó se almacenan por separado. Estos árboles de consulta son visibles cuando se inicia el Postgre SQL y escribir consultas en la interfaz de usuario interactivo. Definición de árbol de consulta

Un árbol de consulta es una estructura de árbol que corresponde a una expresión

del álgebra relacional, donde las relaciones iniciales son representadas a través

de los nodos hojas del árbol y las operaciones son representadas en los nodos

internos.

Una ejecución de un árbol de consulta consiste en la ejecución de una operación

de un nodo interno siempre que sus operadores estén disponibles y luego

sustituyendo este nodo por la relación que resulte de ejecutar la operación.

La ejecución termina cuando el nodo raíz es ejecutado y produce la relación

resultante.

El bloque de consulta tiene la siguiente forma:

SELECT < lista de atributos >

FROM < lista de tablas>

WHERE < condición >

La lista de atributos, es la lista de nombres de atributos cuyos valores serán

recuperados en la consulta.

La lista de tablas, es la lista de nombres de las tablas o relaciones necesarias para

procesar la consulta.

La condición, es la expresión condicional (booleana) que identifica las tuplas que

serán recuperadas por la consulta.

Ejemplo de árbol de consulta

“Listar los nombres de los empleados nacidos antes de 1960 que trabajen en un

proyecto llamado Géminis”

58

SELECT enombre

FROM Empleado, Trabaja-en, Proyecto

WHERE pnombre = “Géminis” AND pnumero = pnum AND Empleado.c.i.=Trabaja-

en.c.i. AND fnac < 01/01/1960

59

Las partes de un árbol de consulta

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

El tipo de comando .- Este es un valor simple decir que comando (SELECT, INSERT, UPDATE, DELETE) produjo el árbol de análisis.

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

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

La lista de objetivos La lista de objetivos es una lista de expresiones que definen el resultado de la consulta. En el caso de una SELECT, las expresiones son las que se basa el resultado final de la consulta. DELETE no necesitan una lista de objetivos, ya que no producen ningún resultado. CTID En INSERT la lista objetivo describe las nuevas filas que deben entrar en la relación resultado. En las consultas UPDATE, la lista de objetivos describe las nuevas filas que deben sustituir a los antiguos

La calificación La consulta de calificación es una expresión muy similar a uno de los que figuran en la lista de entradas de destino. El valor del resultado de esta expresión es un valor booleano que indica si la operación (INSERT, UPDATE, DELETE o SELECT)

60

para la fila de resultado final debe ser ejecutado o no. SQL Es la cláusula WHERE de una instrucción SQL.

3.2.2 TRANSFORMACIONES EQUIVALENTES

Cuando una base de datos se encuentra en múltiples servidores y distribuye a un número determinado de nodos tenemos:

El servidor recibe una petición de un nodo. El servidor es atacado por el acceso concurrente a la base de datos

cargada localmente. El servidor muestra un resultado y le da un hilo a cada una de las

maquinas nodo de la red local.

Cuando una base de datos es acezada de esta manera la técnica que se utiliza es la de fragmentación de datos que puede ser hibrida, horizontal y vertical.

En esta fragmentación lo que no se quiere es perder la consistencia de los datos, por lo tanto se respetan las formas normales de la base de datos.

Bueno para realizar una transformación en la consulta primero desfragmentamos siguiendo los estándares marcados por las reglas formales y posteriormente realizamos el envió y la maquina que recibe es la que muestra el resultado pertinente para el usuario, de esta se puede producir una copia que será la equivalente a la original.

3.2.3 MÉTODOS DE JOIN

La sentencia JOIN en SQL permite combinar registros de dos o más tablas en una base de datos relacional. En el Lenguaje de Consultas Estructurado (SQL), hay tres tipos de JOIN: interno, externo, y cruzado.

Matemáticamente, JOIN es composición relacional, la operación fundamental en el álgebra relacional, y generalizando es una función de composición.

61

Tablas de ejemplo

Todas las explicaciones que están a continuación utilizan las siguientes dos tablas para ilustrar el efecto de diferentes clases de uniones JOIN.

Tabla Empleado

Apellido IDDepartamento

Andrade 31

Jordán 33

Steinberg 33

Róbinson 34

Solano 34

36

La tabla Empleado contiene a los empleados con el número del departamento al que pertenecen; mientras que la tabla Departamento, contiene el nombre de los departamentos de la empresa, se puede notar que existe un empleado que tiene asignado un número de departamento que no se encuentra en la tabla Departamento (Gaspar), igualmente, en la tabla Departamento existe un departamento al cual no pertenece empleado alguno (Mercadeo). Esto servirá para presentar algunos ejemplos más adelante.

NombreDepartamento IDDepartamento

Ventas 31

Ingeniería 33

Producción 34

Mercadeo 35

62

Combinación interna (INNER JOIN)

Con esta operación se calcula el producto cruzado de todos los registros; así cada registro en la tabla A es combinado con cada registro de la tabla B; pero sólo permanecen aquellos registros en la tabla combinada que satisfacen las condiciones que se especifiquen. Este es el tipo de JOIN más utilizado por lo que es considerado el tipo de combinación predeterminado.

Sql especifica dos formas diferentes para expresar estas combinaciones. La primera, conocida como explícita usa la palabra JOIN, mientras que la segunda es implícita y usa ',' para separar las tablas a combinar en la sentencia FROM de la declaración SELECT. Entonces siempre se genera el producto cruzado del cual se seleccionan las combinaciones que cumplan lo que indica la sentencia WHERE.

Es necesario tener especial cuidado cuando se combinan columnas con valores nulos NULL ya que el valor nulo no se combina con otro valor o con otro nulo, excepto cuando se le agregan predicados tales como IS NULL o IS NOT NULL.

Como ejemplo, la siguiente consulta toma todos los registros de la tabla Empleado y encuentra todas las combinaciones en la tabla Departamento. La sentencia JOIN compara los valores en la columna IDDepartamento en ambas tablas. Cuando no existe esta correspondencia entre algunas combinaciones, éstas no se muestran; es decir que si el número de departamento de un empleado no coincide con los números de departamento de la tabla Departamento, no se mostrará el empleado con su respectivo departamento en la tabla resultante.

Las dos consultas siguientes son similares, y se realizan de manera explícita (A) e implícita (B).

A. Ejemplo de la sentencia INNER JOIN explícita:

SELECT * FROM empleado INNER JOIN departamento ON empleado.IDdepartamento = departamento.IDdepartamento

B. Ejemplo de la sentencia INNER JOIN implícita:

SELECT * FROM empleado, departamento WHERE empleado.IDdepartamento = departamento.IDDepartamento

63

Resultados:

Empleado.Apellido

Empleado.Iddepartamento

departamento.NombreDepartamento

departamento.IDDepartamento

Solano 34 Producción 34

Jordán 33 Ingeniería 33

Róbinson 34 Producción 34

Steinberg 33 Ingeniería 33

Andrade 31 Ventas 31

El empleado Gaspar y el departamento de Mercadeo no son presentados en los resultados ya que ninguno de éstos tiene registros correspondientes en la otra tabla. No existe un departamento con número 36 ni existe un empleado con número de departamento 35.

Combinación externa (OUTER JOIN)

Mediante esta operación no se requiere que cada registro en las tablas a tratar tenga un registro equivalente en la otra tabla. El registro es mantenido en la tabla combinada si no existe otro registro que le corresponda.

En sql no existe una notación implícita para las combinaciones externas.

Este tipo de operación se subdivide dependiendo de la tabla a la cual se le admitirán los registros que no tienen correspondencia, ya sean de tabla izquierda, de tabla derecha, o combinación completa.

De tabla izquierda (LEFT OUTER JOIN o LEFT JOIN)

El resultado de esta operación siempre contiene todos los registros de la tabla de la izquierda (la primera tabla que se menciona en la consulta), aun cuando no exista un registro correspondiente en la tabla de la derecha, para uno de la izquierda.

La sentencia LEFT OUTER JOIN retorna la pareja de todos los valores de la tabla izquierda con los valores de la tabla de la derecha correspondientes, o retorna un valor nulo NULL en caso de no correspondencia.

A diferencia del resultado presentado en los ejemplos A y B (de combinación interna) donde no se mostraba el empleado cuyo departamento no existía; en el

64

siguiente ejemplo se presentarán los empleados con su respectivo departamento, e inclusive se presentará el empleado, cuyo departamento no existe.

Ejemplo de tabla izquierda para la combinación externa:

SELECT distinct * FROM empleado LEFT OUTER JOIN departamento ON empleado.IDDepartamento = departamento.IDDepartamento

Empleado.Apellido

Empleado.IDDepartamento

Departamento.NombreDepartamento

Departamento.IDDepartamento

Jordán 33 Ingeniería 33

Andrade 31 Ventas 31

Róbinson 34 Producción 34

Solano 34 Producción 34

Gaspar 36 NULL NULL

Steinberg 33 Ingeniería 33

De tabladerecha (RIGHT OUTER JOIN o RIGHT JOIN)

Esta operación es inversa a la anterior; el resultado de esta operación siempre contiene todos los registros de la tabla de la derecha (la segunda tabla que se menciona en la consulta), aun cuando no exista un registro correspondiente en la tabla de la izquierda, para uno de la derecha.

La sentencia RIGHT OUTER JOIN retorna la pareja de todos los valores de la tabla derecha con los valores de la tabla de la izquierda correspondientes, o retorna un valor nulo NULL en caso de no correspondencia.

65

Ejemplo de tabla derecha para la combinación externa:

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

Empleado.Apellido

Empleado.IDDepartamento

Departamento.NombreDepartamento

Departamento.IDDepartamento

Solano 34 Producción 34

Jordán 33 Ingeniería 33

Róbinson 34 Producción 34

Steinberg 33 Ingeniería 33

Andrade 31 Ventas 31

NULL NULL Mercadeo 35

En este caso el área de Mercadeo fue presentada en los resultados, aunque aún no hay empleados registrados en dicha área.

Combinacióncompleta (FULL OUTER JOIN)

Esta operación presenta los resultados de tabla izquierda y tabla derecha aunque no tengan correspondencia en la otra tabla. La tabla combinada contendrá, entonces, todos los registros de ambas tablas y presentará valores nulos NULLs para registros sin pareja.

66

Ejemplo de combinación externa completa:

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

Empleado.Apellido

Empleado.IDDepartamento

Departamento.NombreDepartamento

Departamento.IDDepartamento

Solano 34 Producción 34

Jordán 33 Ingeniería 33

Róbinson 34 Producción 34

Gaspar 36 NULL NULL

Steinberg 33 Ingeniería 33

Andrade 31 Ventas 31

NULL NULL Mercadeo 35

Como se puede notar, en este caso se encuentra el empleado Gaspar con valor nulo en su área correspondiente, y se muestra además el departamento de Mercadeo con valor nulo en los empleados de esa área.

Algunos sistemas de bases de datos no soportan esta funcionalidad, pero esta puede ser emulada a través de las combinaciones de tabla izquierda, tabla derecha y de la sentencia de unión.

67

K. El mismo ejemplo puede expresarse así:

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

Cruzada (Cross join)

Presenta el producto cartesiano de todos los registros de las dos tablas.

El código SQL para realizar este producto cartesiano enuncia las tablas que serán combinadas, pero no incluye algún predicado que filtre el resultado.

Ejemplo de combinación cruzada explícita:

SELECT * FROM empleado CROSS JOIN departamento

Ejemplo de combinación cruzada implícita:

SELECT * FROM empleado, departamento;

68

Empleado.Apellido

Empleado.IDDepartamento

Departamento.NombreDepartamento

Departamento.IDDepartamento

Andrade 31 Ventas 31

Jordán 33 Ventas 31

Steinberg 33 Ventas 31

Solano 34 Ventas 31

Róbinson 34 Ventas 31

Gaspar 36 Ventas 31

Andrade 31 Ingeniería 33

Jordán 33 Ingeniería 33

Steinberg 33 Ingeniería 33

Solano 34 Ingeniería 33

Róbinson 34 Ingeniería 33

Gaspar 36 Ingeniería 33

Andrade 31 Producción 34

69

Jordán 33 Producción 34

Steinberg 33 Producción 34

Solano 34 Producción 34

Róbinson 34 Producción 34

Gaspar 36 Producción 34

Andrade 31 Mercadeo 35

Jordán 33 Mercadeo 35

Steinberg 33 Mercadeo 35

Solano 34 Mercadeo 35

Róbinson 34 Mercadeo 35

Gaspar 36 Mercadeo 35

Esta clase de combinaciones son usadas pocas veces, generalmente se les agregan condiciones de filtrado con la sentencia WHERE para hallar resultados específicos.

70

3.3.- OPTIMIZACIÓN DE CONSULTAS

Cada día se necesita procesar mayor cantidad de datos y obtener de manera más rápida y precisa la información. Muchos de los problemas de rendimiento se deben entre otras cosas al hardware, al software, al motor de base de datos y por sobre todo al diseño, índices y mala formulación de consultas SQL. Existe la posibilidad de encontrar algunas Consultas SQL, que al momento de ejecutarse, generen problemas en el SBD, tales como: -Elevada carga del CPU -Bloquean procesos de trabajo durante largo tiempo. -Leen muchos bloques de datos a la memoria intermedia (Paginamiento) - Las Consultas SQL que generan este tipo de problema, se las denomina “COSTOSAS” o “INEFICIENTES”.

La optimización de consultas es el proceso de la selección del plan de evaluación de las consultas más eficiente entre las muchas estrategias generalmente disponibles para el procesamiento de una consulta dada, especialmente si la consulta es compleja. No se espera que los usuarios escriban las consultas de modo que puedan procesarse de manera eficiente. Por el contrario se espera que el sistema cree un plan de evaluación de las consultas que minimice el coste de la evaluación de las consultas aquí es donde entra la optimización de consultas. El procesamiento de consultas tiene varias etapas a seguir para resolver una

consulta SQL. Las características del modelo relacional permiten que cada motor

de base de datos elija su propia representación que, comúnmente, resulta ser el

álgebra relacional. Una de las etapas es:

71

• >La optimización de consultas

Supone la utilización de una medida de costo que sea común a lo largo del

proceso, esta medida debe representar el criterio de minimización en la utilización

de recursos del sistema. ). Este enfoque estima un costo que estará determinado

por formulas predefinidas y por la información del catalogo inherente a la consulta.

Sin embargo el optimizador no siempre escoge el plan más óptimo, ya que una

búsqueda exhaustiva de la estrategia óptima puede consumir demasiado tiempo

de proceso.

El catálogo de la base de datos guarda información estadística de cada una de las

relaciones como también de los índices de cada una de la relaciones, estas

estadísticas permiten estimar los tamaños de los resultados de varias

operaciones.

Una mala administración de la información que contiene el catálogo conducirá

inevitablemente a una desafortunada elección del plan de ejecución.

Consiste en la actualización automática de las estadísticas que algunos motores

de base de datos incluyen como opción. Otro enfoque es la opción de guardar en

el catálogo planes de ejecución precalculados que además le ahorran al motor el

tiempo de cálculo del plan.

Uno de los primeros optimizadores de consultas y el que se conoce como base

para la mayoría de los optimizadores tradicionales es el optimizador de System R.

System R es un optimizador basado en costos pero que utiliza heurísticas para

desplazar selecciones y proyecciones hacia abajo en el árbol de la consulta. El

primer paso de un optimizador de consultas es encontrar una expresión del

álgebra de relaciones que sea equivalente a la expresión dada y cuyo costo

estimado de ejecución sea menor.

La optimización incide:

La optimización El coste de comunicación de acceso a almacenamiento secundario.

El coste de almacenamiento. El coste de computación. El optimizador interviene también en las actualizaciones y borrados.

72

PASOS PARA GENERAR UNA OPTIMIZACIÓN:

1. Generar un Plan de Ejecución 2. Escribir la consulta 3. Crear y gestionar índices: los índices se utilizan para agilizar las búsquedas

de información. 4. Aplicación del plan

TIEMPO DE OPTIMIZACIÓN Una consulta puede ser optimizada en tiempos diferentes con relación a tiempo de ejecución de la consulta. La optimización se puede realizar de manera estática antes de ejecutar la consulta o de forma dinámica durante la ejecución de la consulta.

Optimización estática se hace en tiempo de compilación de la consulta. Así, el costo de la optimización puede ser amortizada sobre múltiples ejecuciones de la misma consulta.

Optimización de consultas dinámica la elección de la mejor operación

siguiente se puede hacer basado en el conocimiento exacto de los resultados de las operaciones anteriores. Por tanto, se requiere tener estadísticas acerca del tamaño de los resultados intermedios para aplicar esta estrategia.

Híbrido: utiliza básicamente un enfoque estático, pero se puede aplicar un

enfoque dinámico cuando los tamaños de las relaciones estimados están alejados de los tamaños actuales.

LA OPTIMIZACIÓN DE CONSULTAS se hace de dos maneras:

A nivel del Álgebra relacional: es un lenguaje de consulta procedural. Consta de un conjunto de operaciones que toman como entrada una o dos relaciones y producen como resultado una nueva relación; el sistema intenta hallar una expresión que sea equivalente a la expresión dada, pero de ejecución más eficiente. (utilizando el selección, proyección, producto artesiano, unión). Este tipo de OPTIMIZACIÓN es para las consultas globales.

Algoritmos de sistemas centralizados: estrategia detallada para el

procesamiento de las consultas para ejecutar la operación, la selección de los índices concretos que se van a emplear, etc. Este tipo de OPTIMIZACIÓN es para las consultas locales

73

3.3.1 OPTIMIZACIÓN GLOBAL DE CONSULTAS

Optimización se define desde un punto de vista informático, como la búsqueda y el hecho de mejorar el rendimiento de un sistema operativo, programa o dispositivo, a partir de determinados cambios lógicos (software) o físicos (hardware) Cuando hablamos de optimización de consultas nos referimos a mejorar los tiempos de respuesta en un sistema de gestión de bases de datos relacional, pues la optimización es el proceso de modificar un sistema para mejorar su eficiencia o también el uso de los recursos disponibles. Dada una consulta algebraica sobre fragmentos, el objetivo de esta capa es hallar una estrategia de ejecución para la consulta cercana a la óptima. La estrategia de ejecución para una consulta distribuida puede ser descrita con los operadores del álgebra relacional y con primitivas de comunicación para transferir datos entre nodos. Para encontrar una buena transformación se consideran las características de los fragmentos, tales como, sus cardinalidades. Un aspecto importante de la optimización de consultas es el ordenamiento de juntas, dado que algunas permutaciones de juntas dentro de la consulta pueden conducir a un mejoramiento de varios órdenes de magnitud. La salida de la capa de optimización global es una consulta algebraica optimizada con operación de comunicación incluida sobre los fragmentos. • La optimización global se da con respecto a todo el código. • Este tipo de optimización es más lenta pero mejora el desempeño general de todo programa. • Las optimizaciones globales pueden depender de la arquitectura de la máquina.

74

Descomposición de consultas

La primera capa descompone una consulta en el cálculo relacional en una consulta en el álgebra relacional que opera sobre relaciones globales. Consiste de cuatro partes:

1. Normalización. Involucra la manipulación de los cuantificadores de la consulta y de los calificadores de la misma mediante la aplicación de la prioridad de los operadores lógicos.

2. Análisis. Se detecta y rechazan consultas semánticamente incorrectas. 3. Simplificación. Elimina predicados redundantes. 4. Reestructuración. Mediante reglas de transformación una consulta en el

cálculo relacional se transforma a una en el álgebra relacional. Se sabe que puede existir más de una transformación. Por tanto, el enfoque seguido usualmente es empezar con una consulta algebraica y aplicar transformaciones para mejorarla.

Localización de Datos

La entrada a esta capa es una consulta algebraica definida sobre relaciones distribuidas. El objetivo de esta capa es localizar los datos de la consulta usando la información sobre la distribución de datos. Esta capa determina cuales fragmentos están involucrados en la consulta y transforma la consulta distribuida en una consulta sobre fragmentos.

Optimización Global de Consultas

Dada una consulta algebraica sobre fragmentos, el objetivo de esta capa es hallar una estrategia de ejecución para la consulta cercana a la óptima. La estrategia de ejecución para una consulta distribuida puede ser descrita con los operadores del álgebra relacional y con primitivas de comunicación para transferir datos entre nodos. Para encontrar una buena transformación se consideran las características de los fragmentos, tales como, sus cardinalidades. Un aspecto importante de la optimización de consultas es el ordenamiento de juntas, dado que algunas permutaciones de juntas dentro de la consulta pueden conducir a un mejoramiento de varios órdenes de magnitud. La salida de la capa de optimización global es una consulta algebraica optimizada con operación de comunicación incluida sobre los fragmentos.

Optimización Local de Consultas

El trabajo de la última capa se efectúa en todos los nodos con fragmentos involucrados en la consulta. Cada subconsulta que se ejecuta en un nodo, llamada consulta local, es optimizada usando el esquema local del nodo. Hasta este momento, se pueden eligen los algoritmos para realizar las operaciones relacionales. La optimización local utiliza los algoritmos de sistemas centralizados.

75

3.3.2 OPTIMIZACIÓN LOCAL DE CONSULTAS

¿Que se busca con la optimización local de consultas? El programador al momento de diseñar sus bases de datos, busca mejorar los siguientes dos criterios:

• Tiempo de ejecución • Espacio de memoria utilizado

Esto se realiza mediante operaciones, métodos, que ayudan a reducir los costos de comunicación y el consumo de recursos de la CPU. El manejo de los costos de comunicación se define por las métricas utilizadas, para cada nodo, como las bases de datos distribuidas operan bajo una arquitectura de red, se definen costos de comunicaciones. Los diferentes factores pueden tener pesos diferentes dependiendo del ambiente distribuido en el que se trabaje. La optimización local se basa específicamente en condiciones locales dentro de un programa fuente, y no se contempla el flujo de ejecución del programa, para este tipo de optimización lo que se contempla es particionar el código en bloques básicos de código (alto nivel) y sobre estos fragmentos se lleva a cabo la optimización. El trabajo de la última capa se efectúa en todos los nodos con fragmentos involucrados en la consulta. Cada subconsulta que se ejecuta en un nodo, llamada consulta local, es optimizada usando el esquema local del nodo. Hasta este momento, se pueden eligen los algoritmos para realizar las operaciones relacionales. La optimización local sirve cuando un bloque de programa o sección es crítico por ejemplo: la E/S, la concurrencia, la rapidez y confiabilidad de un conjunto de instrucciones. Características

La optimización local se realiza sobre módulos del programa.

La optimización sólo se ve reflejada en dichas secciones.

Como el espacio de soluciones es más pequeño la optimización local es

más rápida.

76

TÉRMINOS DE REPASO

Procesamiento distribuido de consultas

Estrategias para el procesamiento de las consultas

Arboles

Tiempos de ejecución

Método de join

Costos de comunicación

Algoritmos de sistemas centralizados

Algoritmos de optimización

Hibrido

Tiempo de optimización

Optimización local y global.

77

AUTO EVALUACION

1.- Menciones los problemas más comunes que se presentan en los sistemas de bases de datos distribuidas? 2.- ¿Qué es una consulta? 3.- Mencione las partes de un árbol de la consulta 4.- ¿En qué consiste la combinación interna (INNER JOIN)? 5.- Explique el método de combinación externa (OUTER JOIN)? 6.- ¿En qué consiste la combinación completa? 7.- ¿Qué es la optimización? 8.- ¿Qué es la optimización de consultas? 9.- ¿Cuáles son los pasos para generar una optimización? 10.- Mencione los criterios a mejorar al momento de diseñar una base de datos. 11.- Escriba las características de la optimización global de consultas. 12.- Escriba las características de la optimización local de consultas. 13.- Explique las maneras para hacer la optimización de consultas. 14.- Explica las maneras en las que se puede realizar la optimización. 15.-Cuál es la función principal de un procesador de consultas relacional 16.-Cuando es correcta y eficiente la transformación 17.-Representa el procesador de consultas 18.-Las consultas distribuidas se realizarán con la operación… 19.-Menciona las estrategias de procesamiento de consultas distribuidas

78

UNIDAD 4.- MANEJO DE TRANSACCIONES

4.1 TRANSACCIONES Concepto: Es una unidad de ejecución en un programa que accede y posiblemente actualiza varios elementos de datos. Una transacción es una colección de acciones que hacen transformaciones consistentes de los estados de un sistema preservando la consistencia del sistema. Se dice que una base de datos está en un estado consistente si obedece todas las restricciones de integridad definidas sobre ella. Los cambios de estado ocurren debido a actualizaciones, inserciones, y supresiones de información. 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. Es un conjunto de acciones llevadas a cabo por un usuario o un programa de aplicación, que acceden o cambian el contenido de la base de datos.

Una transacción consiste en una serie de operaciones performed on a database. Realizado en una base de datos. The important issue in La cuestión importante en transaction management is that if a database was in a la gestión de transacciones es que si una base de datos estaba en un consistent state prior to the initiation of a transaction, estado coherente antes de la iniciación de una transacción, then the database should return to a consistent state a continuación, la base de datos debe volver a un estado coherente after the transaction is completed. Después de la transacción se ha completado. This should be done Esto se debe hacer irrespective of the fact that transactions were independientemente del hecho de que las transacciones se successfully executed simultaneously or there were ejecutado con éxito al mismo tiempo o hay failures during the execution, (Ozsu et al., 1991). fallos durante la ejecución. Thus, a transaction is a unit of consistency and Por lo tanto, una transacción es una unidad de la coherencia y la reliability. fiabilidad. Las transacciones fueron originalmente desarrolladas para ser utilizadas dentro de los sistemas de base de datos, donde se usaba para ayudar en el mantenimiento de los datos de las aplicaciones y que 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

79

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 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.

80

Instrucciones para el uso de transacciones 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 integran 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. Ejemplo 1: Considere la siguiente consulta en SQL para incrementar el 10% del presupuesto del proyecto CAD/CAM de la base de datos de ejemplo.

UPDATE J

SET BUDGET = BUDGET*1.1

WHERE JNAME = "CAD/CAM"

Esta consulta puede ser especificada, usando la notación de SQL, como una transacción otorgándole un nombre:

Begin_transaction ACTUALIZA_PRESUPUESTO

begin

UPDATE J

SET BUDGET = BUDGET*1.1

WHERE JNAME = "CAD/CAM"

end.

81

Ejemplo 2: Considere una agencia de reservaciones para líneas aéreas con las siguientes relaciones:

FLIGHT( FNO, DATE, SRC, DEST, STSOLD, CAP )

CUST( CNAME, ADDR, BAL )

FC( FNO, DATE, CNAME, SPECIAL )

Una versión simplificada de una reservación típica puede ser implementada mediante la siguiente transacción:

Begin_transaction Reservación

begin

input( flight_no, date, customer_name );

EXEC SQL UPDATE FLIGHT

SET STSOLD = STSOLD + 1

WHERE FNO = flight_no

AND DATE = date

EXEC SQL INSERT

INTO FC( FNAME, DATE, CNAME,

SPECIAL )

VALUES (flight_no, date, customer_name,

null )

output("reservación terminada");

end.

Las transacciones cuentan con las siguientes propiedades:

Atomicidad: Una transacción es tratada como una unidad de operación. Por lo tanto todas las acciones de la transacción se llevan a cabo o ninguna de ellas se realiza .La atomicidad requiere que si una transacción se interrumpe por una falla, sus resultados parciales deben ser deshechos. Se efectúan todas las transacciones, pero en caso de fallas no se realiza ninguna. Una transacción debe concluir

82

comprometida o abortada. En el caso del compromiso se instalan todas las actualizaciones y en el aborto se descartan todas las actualizaciones. Consistencia : Una transacción es un programa correcto que lleva la base de datos de un estado consistente a otro con la misma característica. Gracias a esto, las transacciones no violan las reglas de integridad de una base de datos. Aislamiento : Durante la ejecución de una transacción, esta no debe revelar sus resultados a otras transacciones concurrentes antes de su compromiso. Si varias transacciones se ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se hubieran ejecutado en forma secuencial (Seriabilidad). La seriabilidad consiste en asegurarse que los cambios siguen un orden adecuado. Durabilidad : Es la propiedad de las transacciones que asegura que una vez que una transacción realiza su compromiso, sus resultados son permanentes y no pueden ser borrados de la base de datos, se asegura que los resultados de una transacción sobrevivirán a fallas del sistema. Las transacciones brindan una ejecución atómica y confiable en presencia de fallas, una ejecución correcta en presencia de accesos de usuario múltiples y un manejo correcto de replicas (en el caso que se soporten).

4.1.1 ESTRUCTURA DE 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 de 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 pueden ser de otras transacciones, están incluidas dentro de otras de un nivel superior que se les conoce como subtransacciones. Por ejemplo: Begin_transaction Reservación Begin_transaction Vuelo …

83

End. (Vuelo) Begin_transaction Hotel … End … End. Una transacción anidada da otra transacción conserva las mismas propiedades que la de sus padres, esto implica, que puede contener así mismo transacciones dentro de ella. Existen restricciones obvias en una transacción anidada: debe empezar después que su padre y debe terminar antes que él. Más aún, el commit de una subtransacción es condicional al commit de su padre, en otras palabras, si el padre de una o varias transacciones aborta, las subtransacciones hijas también serán abortadas. Las transacciones anidadas 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.

4.1.2 EJECUCIÓN DE TRANSACCIONES CENTRALIZADA Y DISTRIBUIDA

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.

84

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: 1.- 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.

2- 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.

85

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 Para llevar el control de concurrencia dentro de un proceso de transacciones se manejan dos modos: Ejecución centralizada de transacciones Ejecución distribuida de transacciones

Ejecucion centralizada de transacciones

86

Ejecución distribuida de transacciones

4.1.3 ESTRUCTURA DE TRANSACCIONES.

Las transacciones planas consisten de una secuencia de operaciones primitivas

encerradas entre las palabras clave begin y end. Por ejemplo,

Begin_transaction Reservación

. . .

end.

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 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

........

87

END.( Vuelo ) ......

BEGIN _TRANSACTION Hotel

........

END

......

END.

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

mismo transacciones. Por ejemplo,

Begin_transaction Reservación

. . .

Begin_transaction Vuelo

. . .

end. {Vuelo}

. . .

Begin_transaction Hotel

. . .

end.

Las transacciones anidadas proporcionan un nivel más alto de concurrencia

entre transacciones. Ya que una transacción consiste de varios transacciones, es

posible tener más concurrencia dentro de una sola transacción. Así también, es

posible recuperarse de fallas de manera independiente de cada subtransacción.

Esto limita el daño a un parte más pequeña de la transacción, haciendo que costo

de la recuperación sea menor.

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

propiedades que la de sus padres, esto implica, que puede contener así mismo

transacciones dentro de ella. Existen restricciones obvias en una transacción

anidada: debe empezar después que su padre y debe terminar antes que él. Más

aún, el commit de una subtransacción es condicional al commit de su padre, en

otras palabras, si el padre de una o varias transacciones aborta, las

subtransacciones hijas también serán abortadas

88

4.2 CONTROL DE CONCURRENCIA

El control de concurrencia trata con los problemas de aislamiento y consistencia del procesamiento de transacciones. El control de concurrencia distribuido de una DDBMS asegura que la consistencia de la base de datos se mantiene en un ambiente distribuido multiusuario. Si las transacciones son internamente consistentes, la manera más simple de lograr este objetivo es ejecutar cada transacción sola, una después de otra. Un método de control de concurrencia es correcto si es serializable, es decir existe una secuencia equivalente en que las operaciones de cada transacción aparecen antes o después de otra transacción pero no entremezcladas. Una ejecución serial de transacciones es siempre correcta. Si no se hace un adecuado control de concurrencia, se pueden presentar

dos anomalías.

En primer lugar, se pueden perder actualizaciones provocando que los

efectos de algunas transacciones no se reflejen en la base de datos.

En segundo término, pueden presentarse recuperaciones de información

inconsistentes.

El control de concurrencia es una actividad de coordinar accesos concurrentes a la base de datos. El control de concurrencia permite a los usuarios accesar a la base de datos. El control de concurrencia permite a los usuarios accesar a la base de datos en una forma multi programada mientras se preserva la ilusión de que cada usuario este utilizando solo en un sistema dedicado. El control de concurrencia asegura que las transacciones multiples sometidos por usuarios diferentes no interfieren unos con otros de forma que se produzca resultados incorrectos. La finalidad del control de concurrencia es asegurar la consistencia de los datos al ejecutar transacciones, y que cada acción atómica sea completada en un tiempo finito. Uno de los problemas de concurrencia específicos de las bases de datos distribuidas es la consistencia de copia múltiple, se produce cuando un mismo dato esta en varias localizaciones. Además se siguen dando los mismos problemas para bases de datos centralizadas pérdida de actualizaciones, dependencia neutral uncommitted dependency y análisis inconsistentes.

89

4.2.1 SERIALIZACIÓN DE TRANSACCIONES

Seriabilidad.

La seriabilidad consiste en asegurarse que los cambios siguen un orden

adecuado.

Teoría de la serializad Una canderilizacion ischedulel también llamado una historia se define un conjunto de transacciones I= {T1,T2, TN} y especifican orden entrelazada de la ejecución de las operaciones de las transacciones. La canderilizacion puede ser especificada como una orden parcial sobre T. T1=read (x) T2=write(x) T3=read (x) Write (x) write (y) read (y) Commit read(z) read (z) Comimit commit Una candelizacion de las acciones de las tres transacciones de las tres transacciones anteriores puede ser: H1 = {W2 (x), R1(x), R3(x), W1(x), C1, W2 (y), R3(y), R2(z), C2, R3(z), C3 } En bases de datos distribuidos es necesario considerar dos tipos de historia para poder generar calendarizaciones serializables: la canderizacion de la ejecución de transacciones globales serán serializables se deben satisfacer las siguientes condiciones:

Cada historia local debe ser serializable.

Dos operaciones en conflicto deben estar en el mismo orden relativo en todas las historias locales donde las operaciones aparecen juntas.

Dos operaciones Oij(x) y Okl(x) (i y k no necesariamente distintos) que accesan el mismo dato de la base de datos x se dice que están en conflicto si al menos una de ellas es una escritura. De esta manera, las operaciones de lectura no tienen conflictos consigo mismas. Por tanto, existen dos tipos de conflictos read-write (o write-read) y write-write. Las dos operaciones en conflicto pueden pertenecer a la misma transacción o a transacciones diferentes. En el último caso, se dice que las transacciones tienen conflicto. De manera intuitiva, la existencia de un conflicto entre dos operaciones indica que su orden de ejecución es importante. El orden de dos operaciones de lectura es insignificante.

Una calendarización completa define el orden de ejecución de todas las operaciones en su dominio. Formalmente, una calendarización completa ST

c definido sobre un conjunto de transacciones T = { T1, T2, ..., Tn } es un orden parcial ST

c = { S T, <T } en donde

90

1. S T = U i S i , para todos los i = 1, 2, ..., n 2. <T Ê i <i , para todos los i = 1, 2, ..., n 3. Para cualesquiera dos operaciones en conflicto Oij y Okl Î S T, ó Oij <T Okl ó

Okl <T Oij

La primera condición establece simplemente que el dominio de la calendarización es la unión de los dominios de las transacciones individuales. La segunda condición define la relación de ordenamiento como un superconjunto de la relación de ordenamiento de transacciones individuales. Esto mantiene el ordenamiento de las operaciones dentro de cada transacción. La condición final define el orden de ejecución entre dos operaciones en conflicto.

4.2.2 ALGORITMOS DE CONTROL DE CONCURRENCIA Aquellos algoritmos que están basados en acceso mutuamente exclusivo a datos compartidos (candados o bloqueos) y aquellos que intentar ordenar la ejecución de las transacciones de acuerdo a un conjunto de reglas (protocolos). Sin embargo, estas primitivas se pueden usar en algoritmos con dos puntos de vista diferentes: El punto de vista pesimista que considera que muchas transacciones tienen conflictos con otras, o el punto de vista optimista que supone que no se presentan muchos conflictos entre transacciones. Los algoritmos pesimistas sincronizan la ejecución concurrente de las transacciones en su etapa inicial de su ciclo de ejecución. Los algoritmos optimistas retrasan la sincronización de las transacciones hasta su terminación. El grupo de algoritmos pesimistas consiste de algoritmos basados en candados, algoritmos basados en ordenamiento por estampas de tiempo y algoritmos híbridos. Los algoritmos para el control de concurrencia son útiles cuando se ejecutan varias transacciones al mismo tiempo

91

Clasificación de algoritmos de control de concurrencia.

4.2.2.1 BASADOS EN BLOQUEO

En los algoritmos basados en candados, las transacciones indican sus intenciones

solicitando candados al despachador. Los candados son de lectura (rl), también

llamados compartidos, o de escritura (wl), también llamados exclusivos. Como se

aprecia en la tabla siguiente:

rl wl

rl si no

wl no no

Los candados de lectura presentan conflictos con los candados de escritura, dado

que las operaciones de lectura y escritura son incompatibles.

92

Existen diversos enfoques para complementar el gestor de bloqueos, cada uno de ellos con ventaja y desventaja se describen a continuación los principales enfoques. Gestión único de bloqueo.- El sistema conserva un único de bloqueos que reside en un único emplazamiento a modo de todas las solicitudes de bloqueo y desbloqueos se realizan sobre él. Cada transacción solicita a esta localidad los bloqueos que necesita y luego, en caso de lectura. La misma se realiza sobre cualquier copia, si es una escritura se debe resolver sobre todas las copias. Esta solución tiene por ventaja una implementación muy sencilla le exige dos mensajes para tratar las solicitudes de bloqueo y una para tratar la de desbloqueo y un tratamiento muy sencillo para desbloqueo (dado que todas las solicitudes de bloque y desbloqueo se realiza en un mismo modo, se puede aplicar los métodos).

Candados de dos fases (2PL)

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. La importancia de los candados de dos fases es que se ha demostrado de manera teórica que todos las calendarizaciones generadas por algoritmos de control de concurrencia que obedecen a los candados de dos fases son serializables.

Gráfica del uso de los candados de dos fases

93

Comportamiento de los candados de dos fases estrictos.

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. Se presenta la estructura de

la comunicación de un administrador centralizado de candados de dos fases. La

comunicación se presenta entre el administrador de transacciones del nodo en

donde se origina la transacción (llamado el coordinador TM), el administrador de

candados en el nodo central y los procesadores de datos (DP) de todos los nodos

participantes. Los nodos participantes son todos aquellos en donde la operación

se va a llevar a cabo.

Comunicación en un administrador centralizado de candados de dos fases estrictos.

94

4.2.2.2 BASADOS EN ESTAMPAS DE TIEMPO Los algoritmos basados en estampas de tiempo no pretenden mantener la seriabilidad por exclusión mutua. En lugar de eso, ellos seleccionan un orden de serialización a prioridad y ejecutan las transacciones, de acuerdo a ellas. Para establecer este ordenamiento, el administrador de transacciones le asigna a cada transacción T1 una estampa de tiempo única t1 (T1) cuando ésta inicia. Una estampa de tiempo es un identificador simple que sirve para identificar cada transacción de manera única. Otra propiedad de las estampas de tiempo es la menoticidad, esto es, dos estampas de tiempo generadas por el mismo administrador de transacciones deben ser monofónicamente crecientes.

Existen varias formas en que las estampas de tiempo se pueden asignar. Un método es usar un contador global monotonicamente creciente. Sin embargo, el mantenimiento de contadores globales es un problema en sistemas distribuidos. Por lo tanto, es preferible que cada nodo asigne de manera autónoma las estampas de tiempos basándose en un contador local.

Ordenamiento conservador por estampas de tiempo

El ordenamiento básico por estampas de tiempo trata de ejecutar una operación tan pronto como se recibe una operación. Así, la ejecución de las operaciones es progresiva pero pueden presentar muchos reinicios de transacciones. El ordenamiento conservador de estampas de tiempo retrasa cada operación hasta que exista la seguridad de que no será reiniciada. La forma de asegurar lo anterior es sabiendo que ninguna otra operación con una estampa de tiempo menor puede llegar al despachador. Un problema que se puede presentar al retrasar las operaciones es que ésto puede inducir la creación de interbloqueos (deadlocks).

95

Ordenamiento por estampas de tiempo múltiples

Para prevenir la formación de interbloqueos se puede seguir la estrategia siguiente. Al hacer una operación de escritura, no se modifican los valores actuales sino se crean nuevos valores. Así, puede haber copias múltiples de un dato. Para crear copias únicas se siguen las siguientes estrategias de acuerdo al tipo de operación de que se trate:

1. Una operación de lectura Ri(x) se traduce a una operación de lectura de x de una sola versión encontrando la versión de x, digamos xv, tal que, ts(xv) es la estampa de tiempo más grande que tiene un valor menor a ts(Ti).

2. Una operación de escritura Wi(x) se traduce en una sola version, Wi(xw), y es aceptada si el despachador no ha procesado cualquier lectura Rj(xr), tal que,

ts(Ti) < ts(xr) < ts(Tj)

4.2.2.3 PRUEBAS DE VALIDACIÓN OPTIMISTAS

El protocolo mas reciente propuesta es el denominado optimista (OPT) el cual acentúa la pertenencia general del sistema reduciendo el bloqueo proveniente de aquellas transacciones que están preparadas para terminar pero que aun no lo hicieron. Los mecanismos optimistas para el control de concurrencia fueron propuestos originalmente con el uso de estampas de tiempo. Sin embargo, en este tipo de mecanismos, no con los datos más aun así con las estampas de tiempo no se asignan al inicio de una transacción sino justamente al inicio de su fase de validación. Esto se debe a que las estampas se requieren únicamente durante la fase de validación. Los algoritmos optimistas, retrasan la fase de validación justo antes de la fase de

escritura (ver Figura). De esta manera, una operación sometida a un despachador

optimista nunca es retrasada. Las operaciones de lectura, cómputo y escrita 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. De otra manera, la transacción es abortada y tiene que reiniciar.

96

Cada transacción Ti se subdivide en varias subtransacciones, cada una de las

cuales se puede ejecutar en nodos diferentes. Sea Tij una subtransacción de Ti

que se ejecuta en el nodo j. Supongamos que las transacciones se ejecutan de

manera independiente y ellas alcanzan el fin de sus fases de lectura. A todas las

subtransacciones se les asigna una estampa de tiempo al final de su fase de

lectura. Durante la fase de validación se realiza una prueba de validación, si una

transacción falla, todas las transacciones se rechazan.

La Prueba De Validación Se Realiza Con Una De Las Siguientes Reglas:

1.- Si todas las transacciones Tk, tales que, ts( Tk ) < ts( Tij ), han terminado su

fase de escritura antes que Tij ha iniciado su fase de lectura entonces la validación

tiene éxito. En este caso la ejecución de las transacciones es completamente

serial como se muestra en la Figura.

2.- Si existe alguna transacción Tk, tal que, ts( Tk ) < ts( Tij ) y la cual completa su

fase de escritura mientras Tij está en su fase de lectura, entonces, la validación

tiene éxito si WS(Tk ) Ç RS(Tij ) = Æ . En este caso, las fases de lectura y escritura

se traslapan, como se muestra en la Figura 6.7b, pero Tij no lee datos queson

escritos por Tk.

3.- Si existe alguna transacción Tk, tal que, ts( Tk ) < ts( Tij ) y la cual completa su

fase de lectura antes que Tij termine su fase de lectura, entonces, la validación

tiene éxito si WS(Tk ) Ç RS(Tij ) = Æ y WS(Tk ) Ç WS(Tij ) = Æ . En este caso, las

fases de lectura se traslapan, como se muestra en la Figura 6.7c, pero las

transacciones no accesan datos comunes.

97

Los mecanismos optimistas para control de concurrencia fueron propuestos originalmente con el uso de estampas de tiempo. Sin embargo, en este tipo de mecanismos las estampas de tiempo se asocian únicamente con las transacciones, no con los datos.

Algoritmos optimistas

No realiza ninguna verificación durante la ejecución. Los cambios se realizan sobre copias locales. Al final de la ejecución existe una fase de validación que comprueba

que cualquiera de las actualizaciones violaba la seriabilidad.

98

4.2.3 DISCIPLINAS DEL INTERBLOQUEO: PREVENCIÓN, DETECCIÓN, ELIMINACIÓN Y RECUPERACIÓN.

El interbloqueo.- Un esquema para resolver el interbloque en su detención, es un bloqueo permanente de un conjunto de procesos que compiten por los recursos del sistema o bien se comunican unos con otros. A diferencia de otros problemas de la gestión concurrente de procesos, no existe una solución eficiente para el caso general. Formas de presentar el interbloqueo Grafo de esperas. Grafo de reservas. Grafo de esperas.- Es un grafo en el cual los nodos son las transacciones y la relación de espera entrenada se define como sigue: Una transacción y relación de espera a otra transacción “T9 si te ha solicitado el bloqueo de un granulo y esta petición no puede ser aceptada porque T9 lo tiene bloqueado”. Grafo de reservas.- Grafo con dos tipos de nodos, los de las transacciones y los Correspondientes a gránulos. Un nodo une un granulo G1 a una transacción T10 si T9 tiene bloqueado el granulo G1. Un arco une una transacción T9 con un granulo G1 si T9 ha solicitado un bloqueo del granulo pero no le ha conseguido. Una condición necesaria para que haya un interbloqueo es que Q1 exista con ciclo en el grafo de reservas. Detención.- Existen diversos algoritmos para ello en la detención de ciclos en el grafo de esperas, entre ellos: Algoritmo 1.- Comprueba la existencia de ciclos mediante la eliminación de nodos terminales. Algoritmo 2.- Comprueba posibles ciclos desde la última transacción bloqueada y marcando los nodos por lo que pasa. Si pasa dos veces por el mismo nodo a detectado un ciclo. Prevención.- Las técnicas de interbloqueo utilizan el concepto de marca de tiempo detransacción existen dos esquemas que evitan el interbloqueo. Recuperación.- El objetivo de esta parte de la asignación es conocer y entender las distintas fallas que pueden ocurrir en un BMS y cómo es posible restaurar el sistema después de dichas fallas este tema se llama recuperación de fallas. La recuperación de fallas esta internamente ligado Al procesamiento de las transacciones tiene la cualidad de ser anotómica a pesar de que puede estar

99

compuesto de varias operaciones de atomicidad se controla como llegada al commit. Si una transacción no sufrió ningún problema y se pudo ejecutar completa, entonces el DBMS debe de “comprometerse” hacer permanentes los cambios que la transacción hizo sobre la base de datos y a que esta debido quedar en un estado de conciencia.

4.3 CONFIABILIDAD Un sistema de manejo de bases de datos confiable es aquel que puede continuar

procesando las solicitudes de usuario aún cuando el sistema sobre el que opera

no es confiable. En otras palabras, aun cuando los componentes de un sistema

distribuido fallen, un DBMS confiable debe seguir ejecutando las solicitudes de

usuario sin violar la consistencia de la base de datos.

La confiabilidad de un DBMS se refiere a la atomicidad y durabilidad de las

transacciones. El sistema sobre el cual se ejecutan los mecanismos de control de

concurrencia debe de ser confiable.

PROPIEDADES:

ATOMICIDAD: Se refiere cuando las operaciones de una transacción se ejecutan

todas o ninguna.

DURABILIDAD: Después de que una transacción se ejecutó con éxito, los

cambios en la BD persisten, más allá de las fallas del sistema.

La confiabilidad se refiere a la consistencia de los resultados. La confiabilidad se busca que los resultados de un cuestionario concuerden con los resultados del mismo cuestionario en otra ocasión. Si esto ocurre se puede decir que hay un alto grado de confiabilidad. Un sistema de manejo de base de datos confiables aquel que puede continuar procesando las solicitudes de usuario aun cuando el sistema sobre el que opera no es confiable en otras palabras, aun cuando los componentes de un sistema distribuido fallen un DDMBS confiable debe seguir ejecutándose las solicitudes de usuario sin violar la consistencia de la base de datos.

100

4.3.1 CONCEPTOS BÁSICOS DE CONFIABILIDAD

SISTEMA, ESTADO Y FALLA:

Un sistema se refiere a un mecanismo que consiste de una colección de

componentes y sus interacciones con el medio ambiente que responden a

estímulos que provienen del mismo con un patrón de comportamiento reconocible.

Un estado externo de un sistema se puede definir como la respuesta que un

sistema proporciona a un estímulo externo. Por lo tanto, es posible hablar de un

sistema que se mueve dentro de estados externos de acuerdo a un estímulo

proveniente del medio ambiente. Un estado interno es, por lo tanto, la respuesta

del sistema a un estímulo interno.

Cualquier desviación de un sistema del comportamiento descrito en su

especificación se considera como una falla.

Cualquier error en los estados internos de los componentes del sistema se le

conoce como una falta en el sistema. Así, una falta causa un error lo que puede

inducir una falla del sistema.

La confiabilidad de un sistema, R(t), se define como la siguiente probabilidad

condicional:

R(t) = Pr{ 0 fallas en el tiempo [0,t] | no hubo fallas en t = 0 }

Si la ocurrencia de fallas sigue una distribución de Poisson, entonces,

R(t) = Pr{ 0 fallas en el tiempo [0,t] }.

El cálculo de la confiabilidad y disponibilidad puede ser tedioso. Por lo tanto, es

acostumbrado usar dos métricas de un sólo parámetro para modelar el

comportamiento del sistema. Las dos métricas son el tiempo medio entre fallas

(MTBF por sus siglas en inglés) y el tiempo medio para reparaciones (MTTR). El

MTBF puede ser calculado ó a partir de datos empíricos ó de la función de

confiabilidad.

La confiabilidad es una condición necesaria, pero no suficiente para la validez. Las evidencias de validez siempre han de ir de la mano con las evidencias de Confiabilidad. La confiabilidad indica el grado de consistencia, pero no dice si las inferencias que Se hacen y las decisiones que se toman partiendo del cuestionario son defendibles.

101

La confiabilidad también se refiere a la medida en la cual un instrumento de recopilación de datos producirá los mismos resultados cada vez que se administra. En la investigación cualitativa, la confiabilidad significa hasta qué punto diferentes investigadores, al exponerse a la misma situación, llegarían a las mismas conclusiones. En términos de confiabilidad lo que preocupa es la consistencia de los resultados. Se necesita la confiabilidad para poder hablar de resultados válidos, puesto que no es posible evaluar algo que cambia continuamente.

4.3.2 PROTOCOLOS REDO/UNDO En un protocolo con escritura previa en bitácora, las entradas en la bitácora se

dividen en dos tipos: las necesarias para operaciones REDO (entradas write_ítem

conteniendo sólo nuevos valores) y las necesarias para operaciones UNDO

(entradas write_ítem conteniendo los valores viejo y nuevo, y entradas read_ítem).

Cuando se produce un fallo, el esquema de recuperación consulta a la bitácora

para determinar que transacciones deben deshacerse o rehacerse.

UNDO (T): cuando la bitácora contiene el registro <T,start> pero no contiene el

registro <T,commit>.

REDO (T): cuando la bitácora contiene tanto el registro <T,start> como el registro

<T,commit>.

El esquema de recuperación usa la operación REDO “rehacer” usando

información de la bitácora. En caso de que ocurra una caída o fallo de una

transacción se debe recurrir a una operación UNDO que “deshace” los cambios

hechos.

Undo (T): restaura todos los datos que T actualiza a los valores que tenía

anteriormente. Redo (T): asigna los nuevos valores a todos los datos que actualiza

la transacción T.

Es importante respetar el orden de ejecución de las operaciones para la

recuperación. Las operaciones UNDO deben realizarse antes que las operaciones

REDO. Las operaciones de UNDO se realizan recorriendo la bitácora desde abajo

hacia arriba, esto es, en orden inverso al que se ejecutaron. Las operaciones de

REDO se realizan recorriendo la bitácora desde arriba hacia abajo, esto es, en el

mismo orden en que se actualizó.

102

Ejemplo:

<Ti,A,10,20>

<Tj,A,20,30>

<Tj,commit> Ti aborta pero Tj comete

Si se realiza un REDO primero, A quedará en 30 y el posterior UNDO dejará a A

con 10. El valor final de A debería ser 30, y eso es posible de alcanzar si se realiza

primero el UNDO y luego el REDO.

La operación redo utiliza la información del registro de la base de datos y realiza de nuevo las acciones que pueden haber sido realizadas antes de la falla, la operación redo genera nueva imagen.

Es posible que el administrador del buffer haya realizado la escritura en la base de datos estable de algunas de las páginas de la base de datos volátil correspondientes a la transacción T2. Así, la información de recuperación debe incluir datos suficientes para permitir deshacer ciertas actualizaciones en el nuevo estado de la base de datos y regresarla al estado anterior. La operación UNDO restablece un dato a su imagen anterior utilizando la información del registro de bases de datos.

103

Independientemente de que la escritura del registro sea síncrona o asíncrona, se debe observar un protocolo importante para el mantenimiento del registro de la base de datos. Considere el caso donde las actualizaciones a la base de datos son escritas en el almacenamiento estable antes de que el registro sea modificado en el registro estable para reflejar la actualización. Si una falla ocurre antes de que el registro sea escrito, la base de datos permanecerá en forma actualizada, pero el registro no indicará la actualización lo que hará imposible recuperar la base de datos a un estado consistente antes de la actualización.

4.3.3 PUNTOS DE VERIFICACIÓN (CHECK POINTS)

Los checkpoints buscan reducir los tiempos extra en los procesos de búsqueda en

la bitácora. Al disparar un checkpoint el sistema realiza la siguiente secuencia de

acciones:

• Grabar en memoria estable todos los registros de bitácora que están en memoria principal.

• Grabar en disco los bloques modificados de los registros intermedios (buffer).

• Grabar un registro de bitácora <checkpoint> en memoria estable.

Cuando ocurre un fallo del sistema es necesario consultar la bitácora para ver

cuáles transacciones deben rehacerse y cuáles deshacerse.

PASOS A SEGUIR ANTE FALLOS:

1.- Para cada transacción Ti tal que aparece en la bitácora el registro <Ti,commit>

antes del registro <checkpoint>, no es necesario ejecutar un REDO.

2.- Después de un fallo, se examina la bitácora para determinar cuál fue la última

transacción Ti que comenzó a ejecutarse antes del último checkpoint. *Esto se

hace examinando la bitácora hacia atrás buscando el primer registro <checkpoint>

y cual es el registro <Ti,start> más cercano. *Luego, se aplica REDO o UNDO

sobre Ti y todas las transacciones que le suceden.

Un punto de control (checkpoints). Es registrado en la bitácora periódicamente

en el momento en que el sistema ha grabado en la BD en disco los efectos de

todas las operaciones de escritura de las transacciones confirmadas.

En un esquema sin concurrencia, en el proceso de recuperación solamente se

consideraban: *Aquellas transacciones que comenzaron después del checkpoint

más reciente. *La única transacción (si existía) que estaba activa al momento del

más reciente checkpoint. En un esquema concurrente puede haber más de una

transacción activa al momento del checkpoint.

104

Las operaciones de recuperación requieren recorrer todo el registro de la base de datos. Así, el buscar todas las transacciones a las cuales es necesario aplicarles un UNDO o REDO puede tomar una cantidad de trabajo considerable. Para reducir este trabajo se pueden poner puntos de verificación (checkpoints) en el registro de la base de datos para indicar que en esos puntos la base de datos está actualizada y consistente. En este caso, un REDO tiene que iniciar desde un punto de verificación y un UNDO tiene que regresar al punto de verificación más inmediato anterior. La colocación de puntos de verificación se realiza con las siguientes acciones: Se escribe un “begin_checkpoint” en el registro de la base de datos. Se recolectan todos los datos verificados en la base de datos estable. Se escribe un “fin_de_checkpoint” en el registro de la base de datos. Estos puntos de verificación nos ayudan para reducir el gasto de tiempo consultando la bitácora. El punto de verificación en un registro que se genera en la

105

bitácora para concluir en todo lo que se encuentra antes de ese punto esta correcto y verificado. Si el sistema se llega a caer se realiza la bitácora buscando del final al inicio el primer registro check point ya encontrado se procesan los registros que se encuentran después del check point.

4.3.4 PROTOCOLOS 2PC DE CONFIABILIDAD DISTRIBUIDA Es un protocolo que consume un gran volumen de tiempo en la ejecución de una Transferencia durante el procesamiento normal se puede eliminar accesos a disco o el número de mensajes en el proceso de la transacción la pertenencia 2pc podría ser mejorado. El 2pc es conocido también como el protocolo “que no resume nada” para que trata todas las transacciones de la misma forma sin importar si las mismas cometen o abortan. En el protocolo de bloqueo de dos fases estricto cada subtransacción debe

informar a las otras subtransacciones de que ha requerido todos los bloqueos.

Una transacción T que fue iniciada en un sitio S y dividida en varias

subtransacciones ejecutándose en diferentes sitios.

Las subtransacción se ordenan en un coordinador y las otras participantes.

• Cada subtransacción Ti decide si cometer o abortar, y envía al coordinador

un mensaje “. El coordinador toma la decisión final en función de las

votaciones de todos los participantes.

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

de bloqueo, esto es, una subtransacción en un sitio que no falló no puede

cometer ni abortar hasta que se repare la falla en el sitio de origen.

PROTOCOLO DE COMPROMISO DE 2 FASES:

• Mejora: Cada subtransacción mide el tiempo máximo de espera por una

respuesta.

• Un participante que alcanza el tiempo máximo pasa al estado de intentar

recuperarse.

• Para ello envía un mensaje de ayuda “help me” a los otros participantes.

Ante el pedido de ayuda, otros participantes según su estado contestan:

• Si está en estado cometida, le envía un mensaje “commit”.

• Si está en estado abortado, le envía un mensaje “abort”.

106

• Si está en estado decidiendo (no votó aún) decide abortar y envía “abort T”

al coordinador.

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

En la siguiente figura se presentan las dos fases de comunicación para realizar un

commit en sistemas distribuidos. El esquema presentado en la figura se conoce

como centralizado ya que la comunicación es solo entre el coordinador y los

participantes; los participantes no se comunican entre ellos.

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

107

EJERCICIOS DE ALGEBRA RELACIONAL

Ejercicio 1:

Resultados:

a) Obtener los nombres de las papelerías abastecidas por algún editorial

de Madrid

∏NOMP (PAPELERIAS *ELP(σ CIUDAD =´MADRID´(EDITORIALES))

b) Obtener los valores de E# para las editoriales que suministran alas papelería P1 y P2 libros publicados en 1978. ∏NOME (EDITORIALES *∏E#(σ AÑO=´1978´(LIBROS)*σP#=´p1´(ELP)) n ∏E#(σ AÑO =´1978´(LIBROS)* P# =´P3´(ELP)) c) obtener los valores de p# de las papelerías abastecidas completamente por la editorial ∏NOMP (PAPELERIA *(∏P#(ELP)÷ ∏E# (ELP))) d) Obtener los valores de L# para los libros suministrados para todas las papelerías que no sean de ´ Madrid´. ∏TITULO (LIBRO (σ CIUDAD ≠ ´MADRID´)-∏L#(ELP)))

Ejercicio 2: Se pide expresar en términos de algebra relacional la secuencia de operaciones necesaria para efectuar las siguientes consultas de base de datos:

A) Obtener los usuarios (U#) que usan al menos todos los programas del distribuidor D1

∏ U#(σusuarios=distribuidor (programas)*( ´D1´) B) Obtener los programas (P#) que solo son usados por el usuario U5.

∏ P# (σ programas*(∏U#(usos)-∏U#(σ usuarios= ´5´(usos))

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

108

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

D) Obtener los modelos de los ordenadores que son usados por personas mayores de 30 años por más de 3 horas.

∏ O# ( σ edad ≥´30´(usuarios)*ordenadores* (σ tiempo=´3´(usos)))

Ejercicio 3:

B) videoclubes que disponen de alguna película que le guste a josé pérez

Π videoclub, película (videoclub, película)=x= π película (σ aficionado=”josé Pérez” (gusta ))

C) aficionados que son socios al menos de un videoclub que dispone de alguna película de su gusto

Π aficionado, videoclub (socio) u π aficionado, película (gusta) D) aficionados que no son socios de ningún videoclub donde tengan

alguna película de su gusto.

Π aficionado(gusta) - π aficionado (socio)

Ejercicio 4:

A) obtener todo los valores de T# que usan todas la maquinas del tipo 1. ∏T#(σ maquina =tipo(matricula)*(tipo1)

A) Obtener todas los F# para aquellas fincas en la qu ean realizados

trabajos las maquinas M1 y M3 ∏F#(σ fincas *(∏F#(maquinas =1(trabajos)-∏T#(σmaquina=3)(trabajos))))

B) Obtener el velor de M# para aquellas maquinas que no han sido utilizadas nunca en ningún trabajo

∏M#(tipo=trabajo(maquinas) *(nombre))

109

C) Obtenr todos los nombres de todas las fincas en la que se a trabajado mas de 5 horas con maquinas cuyo precio por hora sea superior a 200 pts.

∏M#(fincas*∏F#(σ horas ›5 (trabajos) * precios = ´200´(fincas))))

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

B) Obtener los nombres de los alumnos que han entregado todas las practicas de tercer curso

∏nombre(σ alumno*(A#(curso=tercero(practica) *entrega))))

C) Obtener los alumnos que han entregados practicas de segundo y tercer curso

∏alumnos (σ practica * (σ(curso=segundo(entrega)-∏alumno))n(∏

practicas₊(σcurso=tercero(entrega)

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

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

E) Obtener los alumnos que solo han entregado practicas de segundo curso y pertenecen al grupo BD-11 ∏ alumnos (practica*∏P#(σcurso=segundo(A#) * grupo=´BD-11´(practica)))

F) Obtener los nombres de los alumnos que no han suspendido ninguna practica de las que han entregado.

∏nombre (σ alumno * (practica = curso (entrega)

110

Ejercicio 6:

A) Obtener los ciclistas que solo han participado en competiciones inferior a 15 días.

∏C# (σciclistas * (duración = ´15´ min(competiciones)))

B) Obtener los ciclistas de equipos españoles que han competido en todas las competiciones de España.

∏C#(equipo * (∏M# (σ país = ´España´ (competiciones)))) C) Obtener los ciclistas que han obtenido un primer y un segundo lugar

puestos en competición con una duración inferior a 15 días. ∏ nombre (σ competiciones * (σ puesto = ´primer´ (clasificación * (∏competiciones *(σ puesto=´segundo´(clasificación))))) n ∏C#(σ ciclistas *(duración = = ´15 días´(competición)))

Ejercicio 7:

A) Obtener el nombre e aquellos conductores que hallan sido denunciados por todas las infracciones inferiores a 100000 ptas.

∏ nombreC (denuncia-(∏C#(σ infracción = › 10000(infracción )) * (conductor))

B) Obtener el código de aquellos agentes que solo hayan denunciado

infracciones de estacionamiento. ∏A# (agentes * infracción (σ descrip= ´ estacionamiento´ (denuncia)

C) Obtener el código de aquellos conductores que no tengan ninguna

denuncia pendiente de pago.

∏C#(conductores * denuncia (σ pagada = ´ S´ o ´ N´)

111

TERMINOS DE REPASO

Ejecución de transacciones

Concurrencia

Estructura de las transacciones

Transacciones centralizadas

Transacciones distribuidas

Algoritmos basados en concurrencia

Serializacion

Interbloqueo

Protocolos redo

Protocolos undo

112

AUTOEVALUACION

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

113

Bibliografía Fundamentos de Bases de Datos, (Tercera Edición), Autores: Abraham Silberschatz, Henry F. Korth, S. Sudarshan Modelos avanzados de bases de datos, universidad de castilla-la mancha, esc.superior de informática. Distributed Databases, School of Science & Technology, Bell College (Hamilton) Silberschatz, Korth, y Sudarshan, Fundamentos de Bases de Datos, 4ª ed. Mc Graw Hill CONNOLLY, Thomas M. y BEGG, Carolyn E., Sistemas de bases de datos: diseño, implementación y gestión. Pearson - Addison Wesley, 4ª edición. Armes A. Elmasri y Shamkant B. Navathe, Fundamentos de Sistemas de Bases de Datos. 3ª ed. Addison Wesley. http://www.fing.edu.uy/inco/cursos/interop/interPresencial/transparencias/queries.pdf http://www.mitecnologico.com/Main/OptimizacionDeConsultasDistribuidas http://sistemas-distribuidos-unerg.blogspot.com/2007/12/bases-de-datosdistribuidas.html http://catarina.udlap.mx/u_dl_a/tales/documentos/msp/alvarez_c_g/capitulo1.pdf