I UNIDAD BASES DE DATOS DISTRIBUIDAS 1.1 Conceptos bsicos. 1.2 Objetivos de las B.D.D. 1.3 Disciplinas de estudio. 1.

4 Arquitectura de bases de datos distribuidas. UNIDAD 2 DISEO DE BASES DE DATOS DISTRIBUIDAS 2.1 Consideraciones de diseo de bases de datos distribuidas. 2.2 Diccionario de datos. 2.3 Niveles de transparencia. 2.3.1 Transparencia de localizacin. 2.3.2 Transparencia de fragmentacin. 2.3.3 Transparencia de rplica. 2.4 Fragmentacin de datos. 2.4.1 Fragmentacin horizontal. 2.4.2 Fragmentacin vertical. 2.4.3 Fragmentacin hbrida. 2.5 Distribucin de datos. 2.5.1 Algoritmos de distribucin de datos no replicados. 2.5.2 Algoritmos de distribucin de datos replicados. UNIDAD 3 PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS 3.1 Metodologa del procesamiento de consultas distribuidas. 3.2 Estrategias de procesamiento de consultas distribuidas. 3.2.1 rboles de consultas. 3.2.2 Transformaciones equivalentes. 3.2.3 Mtodos de ejecucin del Join. 3.3 Optimizacin de consultas. 3.3.1 Optimizacin global de consultas. 3.3.2 Optimizacin local de consultas. UNIDAD 4 MANEJO DE TRANSACCIONES 4.1 Transacciones 4.1.2 Ejecucin de transacciones centralizada y distribuida 82 84 3 7 12 13

20 27 28 30 31 31 32 34 37 38 40 42 43

47 53 56 60 60 70 73 75

4.1.3 Estructura de transacciones. 4.1.4 Ejecucin de transacciones centralizada y distribuida. 4.2 Control de concurrencia. . 4.2.1 Serializacin de transacciones. 4.2.2 Algoritmos de control de concurrencia. 4.2.2.1 Basados en bloqueo. 4.2.2.2 Basados en estampas de tiempo. 4.2.2.3 Pruebas de validacin optimistas. 4.2.3 Disciplinas del Interbloqueo: prevencin, eliminacin y recuperacin 4.3 Confiabilidad 4.3.1 Conceptos bsicos de confiabilidad. 4.3.2 Protocolos REDO/UNDO. 4.3.3 Puntos de verificacin (checkpoints). 4.3.4 Protocolo 2PC de confiabilidad distribuida. BIBLIOGRAFIA

87 88 89 90

91 94 9 deteccin, 98 99 100 101 103 10

40

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 sistemticamente para su posterior uso. En este sentido, una biblioteca puede considerarse una base de datos compuesta en su mayora por documentos y textos impresos en papel e indexados para su consulta. En la actualidad, y debido al desarrollo tecnolgico de campos como la informtica y la electrnica, la mayora de las bases de datos estn en formato digital (electrnico), 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 rpida y estructurada. Las propiedades de estos SGBD, as como su utilizacin y administracin, se estudian dentro del mbito de la informtica. Las aplicaciones ms usuales son para la gestin de empresas e instituciones pblicas. Tambin son ampliamente utilizadas en entornos cientficos con el objeto de almacenar la informacin experimental. Aunque las bases de datos pueden contener muchos tipos de datos, algunos de ellos se encuentran protegidos por las leyes de varios pases. Por ejemplo en Espaa, 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 localizacin geogrfica, cada sitio en la red es autnomo en sus capacidades de procesamiento y es capaz de realizar operaciones locales y en cada uno de estos ordenadores debe estar ejecutndose una aplicacin a nivel global que permita la consulta de todos los datos como si se tratase de uno solo. Es un conjunto de mltiples bases de datos lgicamente relacionadas las cuales se encuentran distribuidas entre diferentes sitios interconectados por una red de comunicaciones. Caractersticas de la base de datos distribuidos: Los datos deben estar fsicamente en ms de un ordenador (distintas sedes)

40

 Las sedes deben estar interconectadas mediante una red (cada sede es un nodo de la red) Los datos han de estar lgicamente integrados (recuperacin y actualizacin) tanto en local como remoto (esquema lgico global y nico) En una nica operacin se puede acceder (recuperar o actualizar) datos que se encuentran en ms de una sede (acceso a datos locales o remotos) Todas las acciones que necesiten realizarse sobre ms de una sede sern transparentes al usuario (transparencia de distribucin para el usuario) Ventajas de la base de datos distribuidos: Organizativas: Econmicas: Tcnicas: Desventajas de la base de datos distribuidos Complejidad del sistema, desarrollo de software ms costoso, problemas de sincronizacin, dificultad para conocer la correccin de los algoritmos paralelos, deteccin de cadas de nodos Dependencia de la red de comunicaciones, sobrecarga de procesamiento de mensajes Dificultad de diseo, fases adicionales Poca madurez de los productos comerciales, orientados a replicacin Funciones de administracin compleja, sincronizacin y coordinacin Dificultad de cambio, inexistencia de metodologas Personal especializado

40

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 sern:
40

Transparencia de red Transparencia de fragmentacin Transparencia de copias o duplicacin Propagacin

de actualizaciones Procesamiento de consultas distribuidas, definicin de estrategias Mantener un diccionario integrado Control de concurrencia, integridad de la BDD, consistencia entre las mltiples 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 heterogneas, mecanismos de traduccin
Sgbdd paralelo:

Este sistema gestor se ejecuta sobre mltiples procesadores y hace uso de mltiples discos, se encuentra diseado 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.

40

CENTRALIZADO
Control centralizado: un solo DBA

DISTRIBUIDO
Control jerrquico: DBA global y DBA local

Independencia de Datos: Transparencia en la Distribucin: Organizacin de los datos es transparente Localizacin de los datos es un aspecto para el programador adicional de independencia de datos

Reduccin de redundancia: Una sola copia de datos que se comparta

Replicacin de Datos: Copias mltiples de datos que incrementa la localidad y la disponibilidad de datos

Estructuras fsicas complejas para accesos No hay estructuras intersitios. Uso de eficientes optimizacin global para reducir transferencia de datos

Seguridad

Problemas de seguridad intrnsecos

1.2 OBJETIVOS DE LA BASE DE DATOS DISTRIBUIDAS Objetivos de Implementacin Al implementar una base de datos distribuida se tienen ciertos objetivos comunes:

Transparencia de ubicacin. Permite a los usuarios tener acceso a los datos sin que tenga conocimiento de la ubicacin de stos. Se puede conseguir este nivel de transparencia al utilizar los administradores de transacciones distribuidas, los cuales son capaces de determinar la localizacin 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 duplicacin. Para que la transparencia de duplicacin sea posible, los administradores de transacciones deben traducir las solicitudes de procesamiento de transaccin 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 informacin sobre el rendimiento de varios nodos respecto al sitio de consulta, as podr seleccionar el nodo de mejor rendimiento. La
40

actualizacin y escritura de datos duplicados suelen ser ms complicadas, ya que el manejador de transacciones debe emitir una accin de escritura para cada uno de los calendarizadores que almacena una copia de los datos.

Transparencia de concurrencia. Cuando varias transacciones se ejecuten al mismo tiempo, los resultados de las transacciones no debern afectarse. La trasparencia de concurrencia se logra si los resultados de todas las transacciones concurrentes son consistentes de manera lgica con los resultados que se habran obtenido si las transacciones se hubieran ejecutado una por una, en 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 atmicas, 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 cundo falla una localidad y tomar las medidas necesarias para recuperarse del fallo. El sistema no debe seguir utilizando la localidad que fall. Por ltimo, cuando se recupere o repare esta localidad, debe contarse con mecanismos para reintegrarla al sistema con el mnimo de complicaciones. Localidad del procesamiento. Los datos se deben distribuir lo ms 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. Disear una distribucin que maximice localidad del procesamiento puede hacerse aadiendo la cantidad de referencias locales y remotas correspondientes a cada fragmentacin candidata y asignar la fragmentacin eligiendo la mejor solucin. Independencia de configuracin. La independencia de configuracin permite aadir 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 duplicacin 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 ms de una localidad se ve limitada la disponibilidad de los datos. La fiabilidad tambin puede verse limitada cuando se produce un fallo en el sistema de clculo de una localidad se afecta la disponibilidad de los datos de esa localidad no estn disponible para los usuarios en cualquier parte del sistema. Fragmentacin de datos. Consiste en subdividir las relaciones y distribuirlas entre los sitios de la red, tiene como objetivo buscar formas

40

alternativas de dividir una las instancias (tablas) de relaciones en otras ms pequeas. La fragmentacin se puede realizar por tuplas individuales (fragmentacin horizontal), por atributos individuales fragmentacin vertical) o una combinacin de ambas (fragmentacin hbrida). El principal problema de la fragmentacin radica en encontrar la unidad apropiada de distribucin. Una relacin no es una buena unidad por muchas razones. Normalmente las vistas de una relacin estn formadas por subconjuntos de relaciones. Adems, las aplicaciones acceden localmente a subconjuntos de relaciones. Por ello, es necesario considerar a los subconjuntos de relaciones como unidad de distribucin. Al descomponer de una relacin en fragmentos, tratados cada uno de ellos como una unidad de distribucin, permite el proceso concurrente de las transacciones. El conjunto de estas relaciones, provocar la ejecucin paralela de una consulta al ser dividida en una serie de subconsultas que operar sobre los fragmentos. Cuando las vistas definidas sobre una relacin son consideradas como unidad de distribucin que se ubican en diferentes sitios de la red, podemos optar por dos alternativas diferentes: La relacin no estar replicada y se almacena en un nico sitio, o existe rplica en todos o algunos de los sitios en los cuales reside la aplicacin. Las consecuencias de esta estrategia son la generacin de un volumen de accesos remotos que pueden ser innecesarios con un mal manejo de estas replicas. Adems, las rplicas innecesarias pueden causar problemas en la ejecucin de las actualizaciones y puede no ser deseable si el espacio de almacenamiento est limitado. Los inconvenientes de la fragmentacin estn 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 operacin de unin (Join), lo cual puede ser costoso. El control semntico cuando los atributos implicados en una dependencia una relacin se descompone en diferentes fragmentos y estos se ubican en sitios diferentes puede ser muy costos porque es necesario hacer bsquedas en un gran nmero de sitios. Ventajas

Refleja una estructura organizacional - los fragmentos de la base de datos se ubican en los departamentos a los que tienen relacin. Autonoma 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, tambin los sistemas trabajan en paralelo, lo cual permite balancear la carga en los servidores. Economa - es ms barato crear una red de muchas computadoras pequeas, que tener una sola computadora muy poderosa.
40

Modularidad - se pueden modificar, agregar o quitar sistemas de la base de datos distribuida sin afectar a los dems sistemas (mdulos).

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 diseo 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. Economa - 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 difcil mantener la integridad, aplicar las reglas de integridad a travs de la red puede ser muy caro en trminos de transmisin de datos. Falta de experiencia - las bases de datos distribuidas son un campo relativamente nuevo y poco comn por lo cual no existe mucho personal con experiencia o conocimientos adecuados. Carencia de estndares - an no existen herramientas o metodologas 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.-AUTONOMA LOCAL Los sitios en un sistema distribuido deben ser autnomos, la autonoma local significa que todas las operaciones en un sitio dado estn controladas por ese sitio; ningn sitio X debe depender de algn otro sitio Y para su operacin satisfactoria. La seguridad, integridad y representacin de almacenamiento de los datos locales permanecen bajo el control y jurisdiccin del sitio local. 2.-NO DEPENDENCIA DE UN SITIO CENTRAL La autonoma 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 algn servicio central, tal que todo el sistema dependa de ese sitio central. Razones por las cuales no debera haber un sitio central: El sitio central puede ser un cuello de botella

40

 El sistema sera vulnerable; es decir, si el sitio central falla, tambin fallar todo el sistema 3.-OPERACIN 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 algn componente independiente. Disponibilidad. La probabilidad de que el sistema est listo y funcionando continuamente a lo largo de un perodo especificado. 4.- INDEPENDENCIA DE UBICACIN. Conocida tambin como transparencia de ubicacin, donde los usuarios no tienen que saber dnde estn almacenados fsicamente 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 FRAGMENTACIN. Un sistema soporta la fragmentacin de datos cuando puede ser dividida en o partes o fragmentos, para efectos de almacenamiento fsico. La fragmentacin es necesaria por razones de rendimiento: los datos pueden estar almacenados en la ubicacin donde son usados ms frecuentemente para que la mayora de las operaciones sean locales y se reduzca el trfico en la red. Los usuarios deben comportarse como si los datos en realidad estuvieran sin fragmentacin alguna. 6.- INDEPENDENCIA DE REPLICACIN. El sistema soporta replicacin de datos cuando un fragmento puede ser representado por muchas copias distintas, o rplicas, guardadas en muchos sitios distintos. Las rplicas 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 rplicas es que al actualizarlas es necesario actualizar todas: el problema de la propagacin de la actualizacin. 7.- PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS.

40

La optimizacin es importante en un sistema distribuido que en uno centralizado, incluso mucho ms. El punto bsico 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.- ADMINISTRACIN DE TRANSACCIONES DISTRIBUIDAS. Existen dos aspectos principales en la administracin de transacciones: control de recuperacin y control de la concurrencia. Ambos aspectos requieren un tratamiento amplio en el ambiente distribuido. Ya que una sola transaccin puede involucrar la ejecucin de cdigo en muchos sitios. Puede involucrar actualizaciones en muchos sitios y se debe de cuidar que la transaccin no caiga en un bloqueo mortal (basado en el bloqueo). Para el control de la recuperacin, es necesario asegurarse que una transaccin dada sea atmica en el ambiente distribuido, el sistema debe por lo tanto asegurarse de que la transaccin sea confirmada o deshecha (se puede utilizar el protocolo de confirmacin de dos fases). 9.- INDEPENDENCIA DE HARDWARE. Soporte para un gran nmero de mquinas 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 slo tener la posibilidad de ejecutar el mismo DBMS en diferentes plataformas de hardware, sino tambin 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 tambin una variedad de redes de comunicacin 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 cmo se comportan los datos mediante unas bases de datos y como tener que procesarse esa informacin que se almacena, cabe

40

mencionar que cada base de datos tiene su propio fin y cada una de ellas varia su funcionamiento como por ejemplo: Multi Base de Datos Distribuida Cuando una base de datos distribuida es muy homognea se dice que es multi base de datos distribuida. Base de Datos Federada Cuando una base de datos distribuida tiene mucha autonoma local se dice que es federada. 1.4ARQUITECTURA DE BASE DE DATOS DISTRIBUIDAS En un sistema de bases de datos distribuidas, existen varios factores que deben tomar en consideracin que definen la arquitectura del sistema:
1. Distribucin: Los componentes del sistema estn localizados en la misma

computadora o no.
2. Heterogeneidad: Un sistema es heterogneo cuando existen en l

componentes que se ejecutan en diversos sistemas operativos, de diferentes fuentes, etc. 3. Autonoma: Se puede presentar en diferentes niveles, los cuales se describen a continuacin:

Autonoma de diseo: Habilidad de un componente del para decidir cuestiones relacionadas a su propio diseo. Autonoma de comunicacin: Habilidad de un componente del para decidir cmo y cundo comunicarse con otros SMBD. Autonoma de ejecucin: Habilidad de un componente del para ejecutar operaciones locales como quiera.

Hay tres caractersticas importantes inherentes a los sistemas de bases de datos: la separacin entre los programas de aplicacin y los datos, el manejo de mltiples vistas por parte de los usuarios y el uso de un catlogo 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 caractersticas. La definicin de un sistema de informacin es la descripcin detallada de la arquitectura del sistema. Las arquitecturas de bases de datos han evolucionado mucho desde sus comienzos, aunque la considerada estndar hoy en da es la descrita por el comit ANSI/X3/SPARC (Standard Planning and Requirements Committee of the American National Standards Institute on Computers and
40

Information Processing), que data de finales de los aos setenta. Este comit propuso una arquitectura general para DBMSs basada en tres niveles o esquemas: el nivel fsico, o de mquina, el nivel externo, o de usuario, y el nivel 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 separacin entre los programas de aplicacin y los datos, el manejo de mltiples vistas por parte de los usuarios y el uso de un catlogo para almacenar el esquema de la base de datos. Nivel interno: Tiene un esquema interno que describe la estructura fsica de almacenamiento de base de datos. Emplea un modelo fsico de datos y los nicos datos que existen estn 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 fsicos de almacenamiento y trabaja con elementos lgicos como entidades, atributos y relaciones.

Nivel externo o de vistas: tiene varios esquemas externos o vistas de usuario. Cada esquema describe la visin 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 aplicacin de la base de datos fsica. La mayora de los SGBD no distinguen del todo los tres niveles. Algunos incluyen detalles del nivel fsico 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 informacin 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 ms que descripciones de los mismos datos pero con distintos niveles de abstraccin. Los nicos datos que existen realmente estn a nivel fsico, 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 peticin expresada en trminos de un esquema externo a una peticin expresada en trminos del esquema conceptual, y luego, a una peticin en el esquema interno, que se procesar sobre la base de datos almacenada. Si la peticin es de una obtencin (consulta) de datos, ser preciso modificar el formato de la informacin extrada de la base de datos
40

almacenada, para que coincida con la vista externa del usuario. El proceso de transformar peticiones y resultados de un nivel a otro se denomina correspondencia o transformacin. 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 lgica es la capacidad de modificar el esquema conceptual sin tener que alterar los esquemas externos ni los programas de aplicacin. 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 debern verse afectados. La independencia fsica 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 fsicos con el fin de mejorar el rendimiento de las operaciones de consulta o de actualizacin de datos. Dado que la independencia fsica se refiere slo a la separacin entre las aplicaciones y las estructuras fsicas de almacenamiento, es ms fcil de conseguir que la independencia lgica. En los SGBD que tienen la arquitectura de varios niveles es necesario ampliar el catlogo o diccionario, de modo que incluya informacin sobre cmo 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 informacin de correspondencia que se encuentra en el catlogo. La independencia de datos se consigue porque al modificarse el esquema en algn nivel, el esquema del nivel inmediato superior permanece sin cambios, slo se modifica la correspondencia entre los dos niveles. No es preciso modificar los programas de aplicacin que hacen referencia al esquema del nivel superior. Por lo tanto, la arquitectura de tres niveles puede facilitar la obtencin de la verdadera independencia de datos, tanto fsica como lgica. Sin embargo, los dos niveles de correspondencia implican un gasto extra durante la ejecucin 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.

40

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 clster de digital, y los modelos IMS/VS data sharing de IBM.

40

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 clsters de estaciones de trabajo, las computadoras Intel paragn, NCR 3600 y 3700 e IBM SP2

40

TRMINOS DE REPASO

Sgbdd Base de de datos centralizados Base de datos distribuidos Objetivos de la base de datos distribuidos Independencia de replicacin Autonoma local Operacin continua Complejidad del sistema Dependencia de la red de comunicaciones Control de concurrencia

40

Reduccin de redundancia Procesamiento de consultas distribuidas. Arquitectura de disco compartido

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 caractersticas de la base de datos distribuidos 5.-La base de datos distribuidos posee ciertas ventajas, cules 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 tambin como transparencia de ubicacin

40

9.- Existen dos aspectos principales en la administracin de transacciones, cuales son: 10.-Las rplicas son necesarias por dos razones principales, mencinalas: 11.-Menciona una ventaja de los sistemas distribuidos 12.- Define que es una arquitectura de memoria compartida 13.-Mencione las responsabilidades del sgbdd.

2 UNIDAD: DISEO DE BASES DE DATOS DISTRIBUIDAS 2.1 CONSIDERACIONES DE DISEO DE BASES DE DATOS DISTRIBUIDAS BASE DE DATOS DISTRIBUIDAS: Una base de datos distribuidas (llamada tambin BDD),es una coleccin de datos relacionados lgicamente ,pero dispersos sobre diferentes puntos de una red de computadoras. Cada sitio en la red tiene la capacidad de procesamiento autnomo 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 informacin, fiabilidad y disponibilidad y agilizar el
40

procesamiento de las consultas. Pero tambin tiene sus desventajas, como desarrollos de software ms costosos, mayor posibilidad de errores y costos extras de procesamiento. Ventajas de la distribucin de datos La principal ventaja de los sistemas distribuidos es la capacidad de compartir y acceder a la informacin de una forma fiable y eficaz. Utilizacin compartida de los datos y distribucin del control La ventaja principal de compartir los datos por medio de la distribucin es que cada localidad pueda controlar hasta cierto punto los datos almacenados localmente. En un sistema centralizado, el administrador de base de datos de la localidad central controla la base de datos. En un sistema distribuido existe un administrador global de la base de datos que se encarga de todo el sistema. Parte de esta responsabilidad se delega al administrador de base de datos de cada localidad. Dependiendo del diseo del sistema distribuido, cada administrador local podr tener un grado de autonoma diferente, que se conoce como autonoma local. La posibilidad de contar con autonoma local es en 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 dems localidades puedan seguir trabajando. En particular, si los datos se repiten en varias localidades, una transaccin que requiere un dato especfico puede encontrarlo en ms de una localidad. As, el fallo de una localidad no implica necesariamente la desactivacin del sistema. El sistema debe detectar cuando falla una localidad y tomar las medidas necesarias para recuperarse del fallo. El sistema no debe seguir utilizando la localidad que fall. Por ltimo, cuando se recupere o repare esta localidad, debe contarse con mecanismos para reintegrarla al sistema con el mnimo de complicaciones. La disponibilidad es fundamental para los sistemas de bases de datos que se utilizan en aplicaciones de tiempo real. Por ejemplo, si una lnea area no puede tener acceso a la informacin, es posible que pierda clientes a favor de la competencia. Agilizacin del procesamiento de consultas Si una consulta comprende datos de varias localidades, puede ser posible dividir la consulta en varias subconsultas que se ejecuten en paralelo en distintas localidades. Sin embargo, en un sistema distribuido no se comparte la memoria principal, as que no todas las estrategias de interseccin se pueden aplicar en

40

estos sistemas. En los casos en que hay repeticin de los datos, el sistema puede pasar la consulta a las localidades ms ligeras de carga. Desventajas de la distribucin de los datos La desventaja principal de los sistemas distribuidos es la mayor complejidad que se requiere para garantizar una coordinacin adecuada entre localidades. El aumento de la complejidad se refleja en: Coste del desarrollo de software: es ms difcil estructura un sistema de bases de datos distribuidos y por tanto su coste es menor Mayor posibilidad de errores: puesto que las localidades del sistema distribuido operan en paralelo, es ms difcil garantizar que los algoritmos sean correctos. Mayor tiempo extra de procesamiento: el intercambio de mensajes y los clculos adicionales son una forma de tiempo extra que no existe en los sistemas centralizados.

Existen varios factores relacionados a la construccin de bases de datos distribuidas que no se presentan en bases de datos centralizadas. Entre los ms importantes se encuentran los siguientes: Diseo de la base de datos distribuidas Procesamiento de consultas Control de concurrencia Confiabilidad

En el diseo de bases de datos distribuidas se debe considerar el problema de cmo distribuir la informacin 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 informacin, se deben abordar dos problemas relacionados. 1.- Como fragmentar la informacin 2.- Como asignar cada fragmento entre los diferentes sitios de la red En el diseo de la base de datos distribuidos tambin es importante considerar si la informacin esta replicada, es decir, si existen copias mltiples del mismo dato y, en caso, como mantener la consistencia de la informacin. Finalmente, una parte importante en el diseo 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 tambin usuarios locales, el directorio combina informacin local con informacin global.

40

La organizacin de los sistemas de base de datos distribuidos se pude analizar en 3 dimensiones:

Inexistentes

Cada aplicacin y sus datos se ejecutan en una maquina sin comunicacin con otros programas o datos

Nivel de comparticin

Comparticin de datos

Cada mquina posee sus propias aplicaciones locales pero se comparten los datos

Comparticin de datos y programas

Las aplicaciones locales en una maquina pueden invocar servicios en otras y edemas comparten los datos

40

Esttico

El modelo de acceso a los datos no vara con el tiempo

Caractersticas de acceso Dinmico El modelo de acceso a los datos vara con el tiempo

Sin informacin

Los diseadores no tienen informacin de cmo acceden los usuarios a los datos

Nivel de conocimiento

Con informacin parcial

Los diseadores no poseen toda la informacin de cmo acceden los usuarios a los datos

Con informacin total

Los diseadores poseen toda la informacin de cmo aceden los usuarios a los datos

40

A la hora de abordar el diseo 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 trabajara para llegar a conseguir el esquema conceptual global. Despus se pasara al diseo de distribucin. 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: Anlisis de requisitos Diseo de vistas Diseo conceptual Diseo de la distribucin Fragmentacin Asignacin Diseo fsico Monitorizacin y ajuste

Factores tomados en cuenta: Repeticin.- El diseador debe considerar que ese sistema mantendr varias copias idnticas. Cada copia se almacenara en una localidad diferente lo que resulta en una repeticin de la informacin. Fragmentacin.- 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 diseador debe evaluar la propiedad de que haya fragmentado en diferentes localidades. Repeticin y fragmentacin.- Esta consideracin es de suma importancia porque es la combinacin de los dos conceptos antes mencionados; es decir, el sistema debe de ser capaz de mantener varias copias idnticas de cada uno de los fragmentos.

40

2.2 DICCIONARIO DE DATOS

40

Es el lugar donde se deposita informacin acerca de todos los datos que forman la base de datos. Es una gua en la que se describe la base de datos y los objetos que la forman. Los diccionarios de datos son el segundo componente del anlisis del flujo de datos. En s mismos los diagramas de flujo de datos no describen por completo el objeto de la investigacin. El diccionario de datos proporciona informacin adicional sobre el sistema. Esta seccin analiza que es un diccionario de datos, por qu se necesita en el anlisis 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 caractersticas lgicas de los sitios donde se almacenan los datos del sistema, incluyendo nombre, descripcin, contenido y organizacin. Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la informacin. Un diccionario de datos debe cumplir las siguientes caractersticas: Debe soportar las descripciones de los modelos conceptual, lgico, interno y externo de la dase de datos. Debe estar integrado dentro del SGBD. Debe apoyar la transferencia eficiente de informacin al SGBD. La conexin entre los modelos internos y externo debe ser realizada en un tiempo de ejecucin. Debe comenzar con la reorganizacin de versiones de produccin de la base de datos. Adems debe reflejar los cambios en la descripcin de la BD. Cualquier cambio a la descripcin de programas ha de ser reflejado automticamente en la librera de descripcin de programas con la ayuda del diccionario de datos. Debe estar almacenado en un medio de almacenamiento con acceso directo para la fcil recuperacin de informacin

Ejemplo de diccionario de datos:

40

2.3 NIVELES DE TRANSPARENCIA El propsito de establecer una arquitectura de un sistema de bases de datos distribuidas es ofrecer un nivel de transparencia adecuado para el manejo de la informacin. La transparencia se puede entender como la separacin de la semntica de alto nivel de un sistema de los aspectos de bajo nivel relacionados a la implementacin del mismo. Un nivel de transparencia adecuado permite ocultar los detalles de implementacin a las capas de alto nivel de un sistema y a otros usuarios. En sistemas de bases de datos distribuidos el propsito 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 definicin y/u organizacin de los datos y viceversa. La independencia de datos se puede dar en dos aspectos: lgica y fsica. Independencia lgica de datos. Se refiere a la inmunidad de las aplicaciones de usuario a los cambios en la estructura lgica de la base de datos. Esto permite que un cambio en la definicin de un esquema no deba afectar a las aplicaciones

40

de usuario. Por ejemplo, el agregar un nuevo atributo a una relacin, la creacin de una nueva relacin, el reordenamiento lgico de algunos atributos. Independencia fsica de datos. Se refiere al ocultamiento de los detalles sobre las estructuras de almacenamiento a las aplicaciones de usuario. Esto es, la descripcin fsica 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 organizacin 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 replicacin de datos. En el tercer nivel se permite la transparencia de la fragmentacin. Finalmente, en el ltimo nivel se permite la transparencia de acceso (por medio de lenguaje de manipulacin 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. Segn el manual de referencia ANSA y el modelo de referencia para el procesamiento distribuido abierto de la organizacin internacional de estndares, el concepto se aplica a 8 aspectos diferentes: Transparencia de acceso: oculta las diferencias entre la representacin de los datos y la manera en que los recursos son accedidos. Transparencia de ubicacin: oculta la localizacin de los recursos y permite el acceso a los mismos sin la necesidad de conocer su localizacin. Transparencia de migracin: oculta que un recurso o un cliente del sistema sea reubicado, lo que permite hacer dichas reubicaciones sin afectar la operacin de los usuarios y los servicios. Transparencia de recolocacin: oculta que un recurso o cliente del sistema pueda moverse a una ubicacin diferente mientras estn en uso. Transparencia de replicacin: oculta la existencia de mltiples 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 recuperacin 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.
Organizacin en Capas de los Niveles de Transparencia.

40

Se pueden encontrar diferentes aspectos relacionados con la transparencia. Por ejemplo, puede existir transparencia en el manejo de copias repetidas o transparencia en la distribucin o fragmentacin de la informacin

2.3.1 TRANSPARENCIA DE LOCALIZACION Transparencia sobre la localizacin de datos. Esto es, el comando que se usa es independiente de la ubicacin de los datos en la red y del lugar en donde la operacin 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 localizacin. Permite a los usuarios accesar a la informacin de un archivo cualquiera de la base de datos sin necesidad de indicar en qu computadora se encuentra el archivo. La transparencia de localizacin busca que los usuarios no puedan distinguir la localizacin de los recursos.

40

P.ej.: no usar nombres como:

maq1:/src/prog.c La transparencia de localizacin se logra creando un conjunto de seudnimos o alias para cada usuario. As, el usuario puede referirse a los datos usando nombres sencillos que el sistema traduce a nombres completos. Con el uso de seudnimos, no ser necesario que el usuario conozca la localizacin fsica de un dato. Adems, el administrador de la base de datos puede cambiar un dato de una localidad a otra sin afectar a los usuarios. 2.3.2 TRANSPARENCIA DE FRAGMENTACION La transparencia a nivel de fragmentacin de datos permite que cuando los objetos de la bases de datos estn fragmentados, el sistema tiene que manejar la conversin de consultas de usuario definidas sobre relaciones globales a consultas definidas sobre fragmentos. As tambin, 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 ubicacin se especifican antes de acceder a los datos. Permite al usuario acceso a la informacin de un archivo fragmentado como si todos los datos del archivo estuvieran en una misma computadora. Es decir, cuando se crea transparencia de fragmentacin, el sistema crea la ilusin de que los archivos no estn fragmentados La transparencia a nivel de fragmentacin de datos permite que cuando los objetos de las bases de datos estn fragmentados, el sistema tiene que manejar la conversacin de consultas de usuarios definidas sobre relaciones globales a consultas definidas sobre fragmentos.

40

As tambin, 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 nmero de copias existentes. La transparencia sobre la replicacin de datos se refiere a que si existen rplicas 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 rplicas en un sistema, el trabajo de ste es mnimo por lo que se puede obtener una eficiencia mayor. Sin embargo, el usuario puede olvidarse de mantener la consistencia de las rplicas teniendo as datos diferentes. Por lo que se sugiere que las rplicas las haga el sistema en su totalidad sin que el usuario se percate si est trabajando o no sobre una rplica. Los usuarios ven cada objeto de datos como lgicamente 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 ubicacin de esas rplicas. El sistema conserva replicas (copias) idnticas de la relacin y guarda cada replica en un sitio diferente. La alternativa a las rplicas es almacenar solo una copia de la relacin r. Si un archivo esta replicado, el usuario no distingue cual de las rplicas est leyendo. Si un proceso realiza una actualizacin, el sistema operativo deber actualizar todas las replica. Ventajas: Disponibilidad: El sistema sigue funcionando aun en caso de cada de uno de los nodos Aumento de paralelismo: Varios nodos pueden realizar consultas en paralelo sobre la misma tabla. Cuantas ms 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 trfico de datos entre nodos. 2.4 FRAGMENTACION DE DATOS

40

La fragmentacin consiste en particionar la informacin para distribuir cada parte en diferentes lugares de la red. De forma que cada relacin se divide en varios fragmentos. Cada fragmento se guarda en una localizacin diferente. Si la relacin r est fragmentada, se dividir en cierto nmero de fragmentos r1, r2 rn. Estos fragmentos contendrn suficiente informacin como para permitir la reconstruccin de la relacin original r. La fragmentacin de la informacin se puede llevar a cabo de tres formas: Fragmentacin vertical. Fragmentacin horizontal. Fragmentacin mixta o hibrida.

El problema de fragmentacin se refiere al particionamiento de la informacin para distribuir cada parte a los diferentes nodos y sitios de la red.
Grado de fragmentacin.

Cuando se va a fragmentar una base de datos deberamos sopesar qu grado de fragmentacin va a alcanzar, ya que ste ser un factor que influir notablemente en el desarrollo de la ejecucin de las consultas. El grado de fragmentacin puede variar desde una ausencia de la divisin, considerando a las relaciones unidades de fragmentacin; o bien, fragmentar a un grado en el que cada tupla o atributo forme un fragmento. Ante estos dos casos extremos, evidentemente se ha de buscar un compromiso intermedio, el cual debera establecerse sobre las caractersticas de las aplicaciones que hacen uso de la base de datos. 1.- Completitud. Si una relacin R se descompone en una serie de fragmentos R1, R2, ..., Rn, cada elemento de datos que pueda encontrarse en R deber poder encontrarse en uno o varios fragmentos Ri. Esta propiedad extremadamente importante asegura que los datos de la relacin global se proyectan sobre los fragmentos sin prdida alguna. 2.- Reconstruccin. Si una relacin R se descompone en una serie de fragmentos R1, R2, ..., Rn, puede definirse una operador relacional tal que

40

El operador ser diferente dependiendo de las diferentes formas de fragmentacin. La reconstruccin de la relacin a partir de sus fragmentos asegura la preservacin de las restricciones definidas sobre los datos en forma de dependencias. 3.- Disyuncin. Si una relacin R se descompone horizontalmente en una serie de fragmentos R1, R2, ..., Rn, y un elemento de datos di se encuentra en algn fragmento Rj, entonces no se encuentra en otro fragmento Rk (k j). Esta regla asegura que los fragmentos horizontales sean disjuntos. Si una relacin 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 travs de una operacin de seleccin y su reconstruccin se realizar en base a una operacin de unin de los fragmentos componentes. En el ejemplo siguiente, se ilustra una posible fragmentacin 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:

40

La recuperacin de la relacin original se realizar a partir de la unin de cada uno de los fragmentos: T= T1 T2... Tn En nuestro caso: ALUMNOS=ALUMNOS_EUI ALUMNOS_EUIT

EJEMPLO 2 Considere la relacin J

40

La relacin J se puede fragmentar horizontalmente produciendo los siguientes fragmentos

Fragmentacin horizontal primaria Consiste del particionamiento en tuplas de una relacin global en subconjuntos, donde cada subconjunto puede contener datos que tienen propiedades comunes y se puede definir expresando cada fragmento como una operacin de seleccin sobre la relacin global. Ejemplo Considere la relacin global SUPPLIER ( SNUM, NAME, CITY ) Entonces, la fragmentacin horizontal puede ser definida como: SUPPLIER1 = SLcity == "SF"SUPPLIER SUPPLIER1 = SLcity == "LA"SUPPLIER 1. Esta fragmentacin satisface la condicin de completes si "SF" y "LA" son solamente los nicos valores posibles del atributo CITY. 2. La condicin de reconstruccin se logra con: SUPPLIER = SUPPLIER1 unin SUPPLIER2 3. La condicin de disjuntos se cumple claramente en este ejemplo.

40

Fragmentacin horizontal derivada La fragmentacin derivada horizontal se define partiendo de una fragmentacin horizontal. En esta operacin 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 fragmentacin horizontal derivada de la relacin SUPPLY. SUPPLY1 = SUPPLYSJsnum == snumSUPPLIER1 SUPPLY2 = SUPPLYSJsnum == snumSUPPLIER2

2.4.2 FRAGMENTACION VERTICAL La fragmentacin vertical, en cambio, se basa en los atributos de la relacin para efectuar la divisin o fragmentacin. Ejemplo:

40

La fragmentacin vertical es la subdivisin de atributos en grupos. Los fragmentos se obtienen proyectando la relacin global sobre cada grupo. La fragmentacin es correcta si cada atributo se mapea en al menos un atributo del fragmento. Ejemplo Considere la siguiente relacin global: EMP ( empnum, name, sal, tax, mgrnum, depnum ) Una fragmentacin vertical de esta relacin puede ser definida como: EMP1 = PJempnum, name, mgrnum, depnum EMP EMP2 = PJempnum, sal, tax EMP la reconstruccin de la relacin EMP puede ser obtenida como: EMP = EMP1 (JN empnum) EMP2 porque empnum es una clave de EMP

2.4.3 FRAGMENTACION MIXTA O HIBRIDA Fragmentacin mixta o hibrida cuando el proceso de particin hace uso de los dos tipos anteriores. La fragmentacin mixta puede llevarse a cabo de tres formas diferentes: 1.- Desarrollando primero la fragmentacin vertical y posteriormente, aplicando particin horizontal de los fragmentos verticales (denominada particin VH) 2.- Aplicando primero una divisin horizontal para luego, sobre los fragmentos generados, desarrollar una fragmentacin vertical (llamada particin HV)
40

3.- De forma directa considerando la semntica de las transacciones. Ejemplo de la fragmentacin mixta HV: Ejemplo Considere la relacin global EMP( empnum, name, sal, tax, mrgnum, depnum ) Las siguientes son para obtener una fragmentacin 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 reconstruccin de la relacin EMP es definida por la siguiente expresin: EMP = UN(EMP1, EMP2, EMP3)JNempnum = empnumPJempnum, sal, tax EMP4 Finalmente, como otro ejemplo considere el siguiente esquema global EMP(EMPNUM, NAME, SAL, TAX, MGRNUM, DEPNUM) DEP(DEPNUM, NAME, AREA, MGRNUM) SUPPLIER(SNUM, NAME, CITY) SUPPLY(SNUM, PNUM, DEPNUM, QUAN) Despus de aplicar una fragmentacin 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)

40

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 ms importantes que el diseador 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 Replicacin de datos La replicacin de datos se refiere al almacenamiento de copias de datos en sitios mltiples servidos por una red de computadoras. Pueden guardarse copias de fragmento para satisfacer requerimientos de informacin especficos. La replicacin en SQL Server consiste, en el transporte de datos entre dos o ms instancias de servidores.
Base de datos totalmente replicada, guarda varias copias de cada

fragmento de la base de datos en varios sitios. No es prctica debido la cantidad de carga impuesta al sistema. Base de datos parcialmente replicada, guarda mltiples copias de algunos fragmentos de la base de datos en mltiples 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 idntica, por consiguiente para mantener la consistencia de los datos entre las replicas, el DDBMS debe garantizar que se realice una actualizacin de la base de datos donde existen replicas. La replicacin exige ms complejidad de procesamiento del DDBMS por que cada copia de dato debe ser mantenida por el sistema.

40

 Si la base de datos est fragmentada el DDBMS debe decidir que copia accesar Una operacin read (lectura) selecciona la copia ms cercana para satisfacer la transaccin. Una operacin write (escritura) requiere que todas las copias se seleccionen y se actualizan. Tipos de replicacin Los tipos bsicos de replicacin son: replicacin de instantneas replicacin transaccional replicacin de mezcla REPLICACIN DE INSTANTNEAS En la replicacin de instantneas 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 instantneas se suelen replicar con menos frecuencia que otros tipos de publicaciones. Puede llevar ms tiempo propagar las modificaciones de datos a los suscriptores. Se recomienda utilizar: cuando la mayora de los datos no cambian con frecuencia REPLICACIN TRANSACCIONAL En este caso se propaga una instantnea inicial de datos a los suscriptores, y despus, cuando se efectan las modificaciones en el publicador, las transacciones individuales se propagan a los suscriptores REPLICACIN DE MEZCLA Permite que varios sitios funcionen en lnea o desconectados de manera autnoma, y mezclar ms 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 relacin autnoma cuya importancia est dada por el diseador para un uso especifico dentro de una aplicacin 2.- RELACIONES VIRTUALES: (Relaciones de Vistas) Una vista es una relacin derivada con nombre representada dentro del sistema exclusivamente mediante su definicin en trmino de otras relaciones, no posee datos
40

almacenados propios, separados y distinguibles a diferencia de las relaciones Bases, en si una VISTA. 3.- RELACIONES INSTANTANEAS: (Snap Shop) Es tambin una relacin derivada con nombre como una vista pero a diferencia de esta ltima las instantneas son reales no virtuales, es decir, estn representadas no solo por su definicin, en trmino de otras relaciones con nombre, sino, tambin por sus propios datos almacenados: (Snap Shop = consulta rpida, corta) Las estrategias que se tienen son: Colocacin centralizada de los datos, toda la base de datos se guarda en un sitio Colocacin particionada de los datos, la base de datos se divide en varias partes desarticuladas (fragmentos) y se guardan en varios sitios. Colocacin replicada de los datos, se guardan copias de uno o ms fragmentos de la base de datos en varios sitios. La distribucin de los datos se logra mediante la particin de los datos, replicados de los datos o mediante una combinacin de ambas. La colocacin de los datos est estrechamente relacionada en como la BD se divide o fragmenta. La colocacin de los datos ve que datos localizar y en donde. Los algoritmos de colocacin de los datos consideran varios factores, incluidos: Objetivos de desempeo y disponibilidad de los datos. Tamao, numero de filas y el nmero 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 comunicacin 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 fragmentacin hibrida es de preferencia lo que debe de llevar este tipo de algoritmos, porque estas utilizan las tres fragmentaciones y las ms aconsejables. Hablar de algoritmos implica sobre la Programacin Hay gestores que son muy flexibles en cuestiones de programacin, mientras que otros ofrecen ms rendimiento. As, al disear el algoritmo tendr que hacer toda la informacin referente a la vida de la base de datos pero por otro lado deber
40

buscar siempre de darle soluciones al usuario, pues este ser el que al final de cuentas interesa. Existen en la actualidad infinidad de tecnologas en cuanto a los gestores de la base de datos se refiere, el que utilizaremos (el ms actual) ser SQL SERVER, este gestor comenz a crearse por la dcada de los 90s, ofrece muchas ventajas sobre otros gestores, la nica desventaja que podramos encontrar en su compatibilidad con los Windows ms 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 fcil de implantar en SQL SERVER. 2.5.2 ALGORITMOS DE DISTRIBUCION DE DATOS REPLICADOS Se refiere al almacenamiento de copias de datos en sitios mltiples, puede ser para satisfacer requerimientos de informacin, adems de mejorar la disponibilidad de los datos y el tiempo respuesta; finalmente estas copias reducen los costos de comunicacin 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 idnticas, esto quiere decir que cuando hay una actualizacin de la base de datos se realiza en todos los sitios donde hay replicas. El algoritmo de distribucin de datos replicados ser realizado principalmente para los datos que ya tengan una copia aunque es muy til, lo cual podemos asegurar que su utilizacin y programacin depender de un 100% del gestor que se utilizando SQL SERVER a pesar de su facilidad de utilizacin tambin 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 mdulo para la transformacin de datos. Otras de las caractersticas que posee SQL SERVER es un bloqueo dinmico a nivel de fila, paralelismo entre consultas; consultas distribuidas y permite aceptar bases de datos de gran tamao. 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 creacin de base de datos. Tabla en SQL SERVER Columna Name Data Type Lenght Esta parte se debeAqu se coloca elTamao colocar todos lostipo de dato quecampo. nombres de loslleva el campo campos que tendranteriormente la tabla. ubicado.

Allow Nulls delSi se activa esta opcin significara que esta opcin permitir valores nulos.

40

Propiedades de los campos de las tablas Descripcin.- Esta propiedad es exclusiva para el diseador o bien para el administrador. Default value.- Se usa para especificar un valor predeterminado para la columna. Precisin.- Se utiliza para campos numricos, por aqu se indica la cantidad de dgitos que llevara un nmero. Scale.- Indica el nmero de dgitos decimales. Identify.- Si esta opcin se marca con un si estaremos indicando que el campo tendr un nmero generado automticamente. 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 diseador. Frmula.- Es una propiedad exclusiva y diseadas para aquellos campos que necesitan alguna funcin. 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.

40

TRMINOS DE REPASO
Base de datos distribuidos Nivel de comparticin Botton up Top-Dow Fragmentacin Monitorizacin y ajuste Diccionario de datos Niveles de transparencia Independencia fsica Independencia lgica Transparencia de localizacin Transparencia de fragmentacin Transparencia de replica Aumento de paralelismo Fragmentacin vertical Fragmentacin horizontal Fragmentacin mixta o hibrida Grado de fragmentacin Completitud

40

 Reconstruccin Disyuncin Algoritmos de colocacin de los datos Algoritmos de distribucin de datos no replicados Default value Scale Identify Identify Seed Is Row Guid

AUTO EVALUACION
1.- En el diseo de bases de datos distribuidas se debe considerar el problema de cmo distribuir la informacin 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 caractersticas que un diccionario de datos debe cumplir 5.- La independencia de datos se puede dar en dos aspectos, mencinelos: 6.- Cual es la diferencia entre la transparencia de localizacin y la transparencia de fragmentacin. 7.- Menciona 2 ventajas de la transparencia de replica 8.-En que consiste la fragmentacin de datos 9.- La fragmentacin de la informacin se puede llevar a cabo de tres formas, cuales son: 10.-Define la fragmentacin vertical y ejemplifique

40

11.- La fragmentacin mixta puede llevarse a cabo de tres formas diferentes, cuales son y descrbalos 12.- Ejemplifique la fragmentacin mixta HV 13.-Mencione las estrategias que utiliza la distribucin de datos: 14.-En que consisten los algoritmos de distribucin de datos no replicados 15.-Que diferencia existe entre los algoritmos de distribucin de datos no replicados y los algoritmos de distribucin de datos replicados.

3UNIDAD: PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS

3.1 Metodologa del procesamiento de consultas distribuidas Las consultas distribuidas obtienen acceso a datos de varios orgenes de datos heterogneos. Estos orgenes 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 heterogneos almacenados en varios orgenes de datos relacionales

y no relacionales a los que se obtiene acceso mediante un proveedor OLE (Object Linking and Embedding (Incrustacin y Vinculacin de Objetos) DB.

40

Operaciones Aritmticas en Consultas

40

Dentro de un SELECT podemos mostrar resultados que provienen de uno o varios campos de la base de datos utilizando operaciones matemticas. Las operaciones bsicas son suma (+), resta (-), divisin (/) y multiplicacin (*). A continuacin vamos a mostrar algunos ejemplos:

Operaciones Aritmticas Mult. Mostrar el nombre y el salario anual de los empleados. (asuma que el atributo salario slo tiene el pago mensual) SELECT emp_nombre, emp_salario * 12 FROM empleado;

Operaciones Aritmticas - SumaOperaciones Aritmticas Suma A cunto subira el salario de cada empleado si le incluimos 300 dlares de aumento? Mostrar el nombre y el salario incluyndole el aumento de 300 dlares. SELECT emp_nombre, emp_salario + 300 FROM empleado;

Operaciones Aritmticas Varios Mostrar el nombre y lo que gana el empleado en comisin para aquellos que son vendedores. SELECT emp_nombre, emp_commision * emp_salario / 100 FROM empleado WHERE emp_titulo = Vendedores;

Operaciones Alfanumricas en Consultas En estas operaciones se juega con el manejo de caracteres y string. Permiten una mejor presentacin de los datos en pantalla y/o reportes. Ayuda en la bsqueda de instancias en la tabla. A continuacin mostramos algunos ejemplos

40

Operaciones Alfanumricas 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 Aritmticas con Fechas en Consultas

SQL permite ejecutar queries que incluyan operaciones aritmticas con fechas. Es til para manejar das, diferencias entre fechas y calcular estimados de tiempo. A continuacin mostramos algunos ejemplos:

Operaciones Aritmticas 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 evaluacin se hace despus de los primeros 6 meses de comenzar a trabajar) SELECT emp_nombre, ADD_MONTHS(emp_fecha_inicio,6) AS Fecha Evaluacin FROM empleado; emp_fecha_inicio,

40

La funcin principal de un procesador de consultas relacionales es transformar una consulta en una especificacin de alto nivel, tpicamente en clculo relacional, a una consulta equivalente en una especificacin de bajo nivel, tpicamente alguna variacin del lgebra relacional. La consulta de bajo nivel implementa de hecho la estrategia de ejecucin para la consulta. La transformacin debe ser correcta y eficiente. Es correcta si la consulta de bajo nivel tiene la misma semntica que la consulta original, esto es, si ambas consultas producen el mismo resultado.

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

40

Como es intuitivamente obvio, la segunda estrategia que evita calcular el producto cartesiano entre E y G, consume mucho menos recursos que la primera y, por lo tanto, es mejor. En el procesamiento distribuido de consultas se estudia el coste de las comunicaciones. Las consultas distribuidas se realizarn, ante todo, con la operacin de semijoin para poder optimizar dichas consultas. En un sistema distribuido hay varios factores adicionales que complican el proceso de consulta en comparacin con los sistemas centralizados. El primero de estos factores es el coste de transferencia de datos a travs de la red. Los datos son enviados a ficheros intermedios que a su vez se envan 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 reduccin de la cantidad de datos transferidos. Algunos de los problemas ms 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 an funcionan. Si el nodo a recuperar es una base de datos local, se debern separar los datos entre los nodos restantes antes de volver a unir de nuevo el sistema. - Copias mltiples 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 recuperacin es el responsable de hacer copias consistentes de los datos de los nodos que han fallado y que despus se recuperarn. - Transaccin distribuida correcta. Se pueden producir fallos durante la ejecucin de una transaccin correcta si se plantea el caso de que al acceder a alguno de los nodos que intervienen en la transaccin, 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 ms extremo es el que se produce cuando se divide la red. Esto puede producir la

40

separacin de dos o ms particiones donde las particiones de cada nodo pueden comunicarse entre s pero no con particiones de otros nodos.

3.2 ESTRATEGIAS DE PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS

En el procesamiento distribuido de consultas se estudia el coste de las comunicaciones. Objetivo: la reduccin de la cantidad de datos transferidos.
Optimizacin mediante operacin de semijoin.

En un sistema distribuido existen factores que complican el proceso de consulta en comparacin con los sistemas centralizados.

Costo de transferencia de datos a travs de la red. Ejemplos de consulta distribuida:

40

Tamao de la relacin EMPLEADO es 100 * 10.000 = 106 bytes Tamao de la relacin 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 expresin 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 tamao del resultado ser por tanto de 400.000 bytes.
Q : el resultado viaja Supongamos queNombre , Apellido , NombreDpto al( EMPLEADO * DEPARTAMENrespuesta ya que nodo 3, denominado nodo TO ) ser el lugar donde se requiera el resultado de dicha consulta. Sin embargo, ni la relacin EMPLEADO ni DEPARTAMENTO residen en dicho nodo.

Ejemplo de consulta distribuida:

Q : Nombre
, Apellido , NombreDpto

( EMPLEADO

* DEPARTAMEN

TO )

Contador:
40 * 10000 Nodo 2 departamento NombreDeppto 400000 Resultado de la consulta
40

10

Nodo empleado1 Nombre 15 Apellido 15

Estrategias:
1. Transferir la relacin EMPLEADO y DEPARTAMENTO al nodo respuesta (nodo 3) y realizar all la operacin de join. En ste caso se transfieren 1.000.000 + 3.500 = 1.003.500 bytes.

Contador:
1000000 + 3500 40 * 10000 Nodo 2 Departamento 3500 1003500 Nodo 3 Resultado

1000000

2. Transferir la relacin EMPLEADO al nodo 2, ejecutar el join en este nodo y enviar el resultado al nodo 3. Esto implicara transferir 1.000.000 bytes de EMPLEADO + 400.000 bytes del resultado, es decir: 1.400.000 bytes. Contador:
1000000 + 400000
40

Nodo 2 departamento

1400000

Nodo 3 Resultado

Nodo 1 empleado 1000000

3. Transferir la relacin DEPARTAMENTO al nodo 1, ejecutar el join en este nodo y enviar el resultado al nodo 3. En este caso, los bytes transferidos sern: 3.500 de la relacin DEPARTAMENTO ms 400.000 del resultado. Es decir 403.500 bytes. Contador:
3500 + 4000000 Nodo 2 departamento 3500 403500 Nodo 1 empleado 403500 Nodo 3 Resultado

Realizar las operaciones de seleccin lo antes posible Combinar el producto cartesiano con una operacin de seleccin subsiguiente cuyo predicado represente una condicin de combinacin, para formar una operacin de combinacin Utilizar la asociatividad de las operaciones binarias para reordenar los nodos hoja de modo que los nodos hoja con las operaciones de seleccin ms restrictivas se ejecuten primero Realizar las operaciones de proyeccin lo antes posible Calcular una nica vez las expresiones posibles. 3.2.1 RBOLES DE CONSULTAS.

40

rbol: En ciencias de la informtica, 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 ms 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, tambin decimos que b es hijo de a). Slo puede haber un nico nodo sin padres, que llamaremos raz. Un nodo que no tiene hijos se conoce como hoja. Los dems nodos (tienen padre y uno o varios hijos) se les conoce como rama.

Consulta: mtodo 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 representacin 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. Definicin de rbol de consulta Un rbol de consulta es una estructura de rbol que corresponde a una expresin del lgebra relacional, donde las relaciones iniciales son representadas a travs de los nodos hojas del rbol y las operaciones son representadas en los nodos internos. Una ejecucin de un rbol de consulta consiste en la ejecucin de una operacin de un nodo interno siempre que sus operadores estn disponibles y luego sustituyendo este nodo por la relacin que resulte de ejecutar la operacin. La ejecucin termina cuando el nodo raz es ejecutado y produce la relacin resultante. El bloque de consulta tiene la siguiente forma: SELECT < lista de atributos > FROM < lista de tablas> WHERE < condicin > La lista de atributos, es la lista de nombres de atributos cuyos valores sern
40

recuperados en la consulta. La lista de tablas, es la lista de nombres de las tablas o relaciones necesarias para procesar la consulta. La condicin, es la expresin condicional (booleana) que identifica las tuplas que sern 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 Gminis SELECT enombre FROM Empleado, Trabaja-en, Proyecto WHERE pnombre = Gminis AND pnumero = pnum AND Empleado.c.i.=Trabajaen.c.i. AND fnac < 01/01/1960

40

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

La tabla de rango La tabla es una lista amplia de las relaciones que se utilizan en la consulta. En una instruccin SELECT se trata de las relaciones dadas despus 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 relacin resultado Este es un ndice en la tabla de rango que identifica la relacin donde van los resultados de la consulta. Las consultas SELECT normalmente no tienen una relacin de resultados.

40

En las consultas INSERT, UPDATE y DELETE la relacin 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 ningn resultado. CTID En INSERT la lista objetivo describe las nuevas filas que deben entrar en la relacin resultado. En las consultas UPDATE, la lista de objetivos describe las nuevas filas que deben sustituir a los antiguos La calificacin La consulta de calificacin es una expresin muy similar a uno de los que figuran en la lista de entradas de destino. El valor del resultado de esta expresin es un valor booleano que indica si la operacin (INSERT, UPDATE, DELETE o SELECT) para la fila de resultado final debe ser ejecutado o no. SQL Es la clusula WHERE de una instruccin SQL. 3.2.2 TRANSFORMACIONES EQUIVALENTES Cuando una base de datos se encuentra en mltiples servidores y distribuye a un nmero determinado de nodos tenemos: El servidor recibe una peticin 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 tcnica que se utiliza es la de fragmentacin de datos que puede ser hibrida, horizontal y vertical. En esta fragmentacin 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 transformacin en la consulta primero desfragmentamos siguiendo los estndares 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.

40

3.2.3 MTODOS DE JOIN La sentencia JOIN en SQL permite combinar registros de dos o ms tablas en una base de datos relacional. En el Lenguaje de Consultas Estructurado (SQL), hay tres tipos de JOIN: interno, externo, y cruzado. Matemticamente, JOIN es composicin relacional, la operacin fundamental en el lgebra relacional, y generalizando es una funcin de composicin.

Tablas de ejemplo Todas las explicaciones que estn a continuacin utilizan las siguientes dos tablas para ilustrar el efecto de diferentes clases de uniones JOIN. Tabla Empleado

NombreDepartamento

IDDepartament

Produccin

34

40

La tabla Empleado contiene a los empleados con el nmero 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 nmero 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 ms adelante. Combinacin interna (INNER JOIN) Con esta operacin 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 slo permanecen aquellos registros en la tabla combinada que satisfacen las condiciones que se especifiquen. Este es el tipo de JOIN ms utilizado por lo que es considerado el tipo de combinacin predeterminado. Sql especifica dos formas diferentes para expresar estas combinaciones. La primera, conocida como explcita usa la palabra JOIN, mientras que la segunda es implcita y usa ',' para separar las tablas a combinar en la sentencia FROM de la declaracin 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 nmero de departamento de un empleado no coincide con los nmeros de departamento de la tabla Departamento, no se mostrar el empleado con su respectivo departamento en la tabla resultante.

40

Las dos consultas siguientes son similares, y se realizan de manera explcita (A) e implcita (B). A. Ejemplo de la sentencia INNER JOIN explcita: SELECT * FROM empleado INNER JOIN departamento ON empleado.IDdepartamento = departamento.IDdepartamento B. Ejemplo de la sentencia INNER JOIN implcita: SELECT * FROM empleado, departamento WHERE empleado.IDdepartamento = departamento.IDDepartamento

Resultados:

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 nmero 36 ni existe un empleado con nmero de departamento 35. Combinacin externa (OUTER JOIN) Mediante esta operacin 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.

40

En sql no existe una notacin implcita para las combinaciones externas. Este tipo de operacin se subdivide dependiendo de la tabla a la cual se le admitirn los registros que no tienen correspondencia, ya sean de tabla izquierda, de tabla derecha, o combinacin completa. De tabla izquierda (LEFT OUTER JOIN o LEFT JOIN) El resultado de esta operacin 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 combinacin interna) donde no se mostraba el empleado cuyo departamento no exista; en el siguiente ejemplo se presentarn los empleados con su respectivo departamento, e inclusive se presentar el empleado, cuyo departamento no existe. Ejemplo de tabla izquierda para la combinacin externa: SELECT distinct * FROM empleado LEFT OUTER JOIN departamento ON empleado.IDDepartamento = departamento.IDDepartamento Empleado. Apellido Empleado.IDDe partamento Departamento.Nombr eDepartamento Departamento.IDD epartamento

Jordn

33

Ingeniera

33

Andrade

31

Ventas

31

Rbinson

34

Produccin

34

Solano

34

Produccin

34

40

Gaspar

36

NULL

NULL

Steinberg

33

Ingeniera

33

De tabladerecha (RIGHT OUTER JOIN o RIGHT JOIN) Esta operacin es inversa a la anterior; el resultado de esta operacin 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.

Ejemplo de tabla derecha para la combinacin externa: SELECT * FROM empleado RIGHT OUTER JOIN departamento ON empleado.IDDepartamento = departamento.IDDepartamento

Empleado. Apellido

Empleado.IDDe partamento

Departamento.Nombr eDepartamento

Departamento.IDD epartamento

Solano

34

Produccin

34

Jordn

33

Ingeniera

33

Rbinson

34

Produccin

34
40

Steinberg

33

Ingeniera

33

Andrade

31

Ventas

31

NULL

NULL

Mercadeo

35

En este caso el rea de Mercadeo fue presentada en los resultados, aunque an no hay empleados registrados en dicha rea. Combinacincompleta (FULL OUTER JOIN) Esta operacin 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.

Ejemplo de combinacin externa completa: SELECT * FROM empleado FULL OUTER JOIN departamento ON empleado.IDDepartamento = departamento.IDDepartamento Empleado. Apellido Empleado.IDDe partamento Departamento.Nombr eDepartamento Departamento.IDD epartamento

Solano

34

Produccin

34

40

Jordn

33

Ingeniera

33

Rbinson

34

Produccin

34

Gaspar

36

NULL

NULL

Steinberg

33

Ingeniera

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 adems 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 travs de las combinaciones de tabla izquierda, tabla derecha y de la sentencia de unin.

K. El mismo ejemplo puede expresarse as: SELECT * FROM empleado LEFT JOIN departamento ON empleado.IDDepartamento = departamento.IDDepartamento UNION SELECT * FROM empleado

40

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 cdigo SQL para realizar este producto cartesiano enuncia las tablas que sern combinadas, pero no incluye algn predicado que filtre el resultado. Ejemplo de combinacin cruzada explcita: SELECT * FROM empleado CROSS JOIN departamento Ejemplo de combinacin cruzada implcita: SELECT * FROM empleado, departamento;

Empleado. Apellido

Empleado.IDDe partamento

Departamento.Nombr eDepartamento

Departamento.IDD epartamento

Andrade

31

Ventas

31

40

Jordn

33

Ventas

31

Steinberg

33

Ventas

31

Solano

34

Ventas

31

Rbinson

34

Ventas

31

Gaspar

36

Ventas

31

Andrade

31

Ingeniera

33

Jordn

33

Ingeniera

33

Steinberg

33

Ingeniera

33

Solano

34

Ingeniera

33

Rbinson

34

Ingeniera

33

Gaspar

36

Ingeniera

33

Andrade

31

Produccin

34

Jordn

33

Produccin

34

40

Steinberg

33

Produccin

34

Solano

34

Produccin

34

Rbinson

34

Produccin

34

Gaspar

36

Produccin

34

Andrade

31

Mercadeo

35

Jordn

33

Mercadeo

35

Steinberg

33

Mercadeo

35

Solano

34

Mercadeo

35

Rbinson

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

40

3.3.- OPTIMIZACIN DE CONSULTAS Cada da se necesita procesar mayor cantidad de datos y obtener de manera ms rpida y precisa la informacin. 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 diseo, ndices y mala formulacin 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 optimizacin de consultas es el proceso de la seleccin del plan de evaluacin de las consultas ms 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 evaluacin de las consultas que minimice el coste de la evaluacin de las consultas aqu es donde entra la optimizacin de consultas. El procesamiento de consultas tiene varias etapas a seguir para resolver una consulta SQL. Las caractersticas del modelo relacional permiten que cada motor
40

de base de datos elija su propia representacin que, comnmente, resulta ser el lgebra relacional. Una de las etapas es:

>La optimizacin de consultas

Supone la utilizacin de una medida de costo que sea comn a lo largo del proceso, esta medida debe representar el criterio de minimizacin en la utilizacin de recursos del sistema. ). Este enfoque estima un costo que estar determinado por formulas predefinidas y por la informacin del catalogo inherente a la consulta. Sin embargo el optimizador no siempre escoge el plan ms ptimo, ya que una bsqueda exhaustiva de la estrategia ptima puede consumir demasiado tiempo de proceso. El catlogo de la base de datos guarda informacin estadstica de cada una de las relaciones como tambin de los ndices de cada una de la relaciones, estas estadsticas permiten estimar los tamaos de los resultados de varias operaciones. Una mala administracin de la informacin que contiene el catlogo conducir inevitablemente a una desafortunada eleccin del plan de ejecucin. Consiste en la actualizacin automtica de las estadsticas que algunos motores de base de datos incluyen como opcin. Otro enfoque es la opcin de guardar en el catlogo planes de ejecucin precalculados que adems le ahorran al motor el tiempo de clculo del plan. Uno de los primeros optimizadores de consultas y el que se conoce como base para la mayora de los optimizadores tradicionales es el optimizador de System R. System R es un optimizador basado en costos pero que utiliza heursticas para desplazar selecciones y proyecciones hacia abajo en el rbol de la consulta. El primer paso de un optimizador de consultas es encontrar una expresin del lgebra de relaciones que sea equivalente a la expresin dada y cuyo costo estimado de ejecucin sea menor. La optimizacin incide:

La optimizacin El coste de comunicacin de acceso a almacenamiento secundario. El coste de almacenamiento. El coste de computacin. El optimizador interviene tambin en las actualizaciones y borrados.

40

PASOS PARA GENERAR UNA OPTIMIZACIN: 1. Generar un Plan de Ejecucin 2. Escribir la consulta 3. Crear y gestionar ndices: los ndices se utilizan para agilizar las bsquedas de informacin. 4. Aplicacin del plan TIEMPO DE OPTIMIZACIN Una consulta puede ser optimizada en tiempos diferentes con relacin a tiempo de ejecucin de la consulta. La optimizacin se puede realizar de manera esttica antes de ejecutar la consulta o de forma dinmica durante la ejecucin de la consulta. Optimizacin esttica se hace en tiempo de compilacin de la consulta. As, el costo de la optimizacin puede ser amortizada sobre mltiples ejecuciones de la misma consulta. Optimizacin de consultas dinmica la eleccin de la mejor operacin siguiente se puede hacer basado en el conocimiento exacto de los resultados de las operaciones anteriores. Por tanto, se requiere tener estadsticas acerca del tamao de los resultados intermedios para aplicar esta estrategia. Hbrido: utiliza bsicamente un enfoque esttico, pero se puede aplicar un enfoque dinmico cuando los tamaos de las relaciones estimados estn alejados de los tamaos actuales. LA OPTIMIZACIN 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 relacin; el sistema intenta hallar una expresin que sea equivalente a la expresin dada, pero de ejecucin ms eficiente. (utilizando el seleccin, proyeccin, producto artesiano, unin). Este tipo de OPTIMIZACIN es para las consultas globales. Algoritmos de sistemas centralizados: estrategia detallada para el procesamiento de las consultas para ejecutar la operacin, la seleccin de

40

los ndices concretos que se van a emplear, etc. Este tipo de OPTIMIZACIN es para las consultas locales

3.3.1 OPTIMIZACIN GLOBAL DE CONSULTAS Optimizacin se define desde un punto de vista informtico, como la bsqueda y el hecho de mejorar el rendimiento de un sistema operativo, programa o dispositivo, a partir de determinados cambios lgicos (software) o fsicos (hardware) Cuando hablamos de optimizacin de consultas nos referimos a mejorar los tiempos de respuesta en un sistema de gestin de bases de datos relacional, pues la optimizacin es el proceso de modificar un sistema para mejorar su eficiencia o tambin el uso de los recursos disponibles. Dada una consulta algebraica sobre fragmentos, el objetivo de esta capa es hallar una estrategia de ejecucin para la consulta cercana a la ptima. La estrategia de ejecucin para una consulta distribuida puede ser descrita con los operadores del lgebra relacional y con primitivas de comunicacin para transferir datos entre nodos. Para encontrar una buena transformacin se consideran las caractersticas de los fragmentos, tales como, sus cardinalidades. Un aspecto importante de la optimizacin 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 optimizacin global es una consulta algebraica optimizada con operacin de comunicacin incluida sobre los fragmentos. La optimizacin global se da con respecto a todo el cdigo. Este tipo de optimizacin es ms lenta pero mejora el desempeo general de todo programa. Las optimizaciones globales pueden depender de la arquitectura de la mquina.

40

Descomposicin de consultas La primera capa descompone una consulta en el clculo relacional en una consulta en el lgebra relacional que opera sobre relaciones globales. Consiste de cuatro partes:
1. Normalizacin. Involucra la manipulacin de los cuantificadores de la

consulta y de los calificadores de la misma mediante la aplicacin de la prioridad de los operadores lgicos. 2. Anlisis. Se detecta y rechazan consultas semnticamente incorrectas. 3. Simplificacin. Elimina predicados redundantes. 4. Reestructuracin. Mediante reglas de transformacin una consulta en el clculo relacional se transforma a una en el lgebra relacional. Se sabe que puede existir ms de una transformacin. Por tanto, el enfoque seguido usualmente es empezar con una consulta algebraica y aplicar transformaciones para mejorarla. Localizacin 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 informacin sobre la distribucin de datos. Esta capa determina cuales fragmentos estn involucrados en la consulta y transforma la consulta distribuida en una consulta sobre fragmentos. Optimizacin Global de Consultas

40

Dada una consulta algebraica sobre fragmentos, el objetivo de esta capa es hallar una estrategia de ejecucin para la consulta cercana a la ptima. La estrategia de ejecucin para una consulta distribuida puede ser descrita con los operadores del lgebra relacional y con primitivas de comunicacin para transferir datos entre nodos. Para encontrar una buena transformacin se consideran las caractersticas de los fragmentos, tales como, sus cardinalidades. Un aspecto importante de la optimizacin 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 optimizacin global es una consulta algebraica optimizada con operacin de comunicacin incluida sobre los fragmentos. Optimizacin Local de Consultas El trabajo de la ltima capa se efecta 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 optimizacin local utiliza los algoritmos de sistemas centralizados. 3.3.2 OPTIMIZACIN LOCAL DE CONSULTAS Que se busca con la optimizacin local de consultas? El programador al momento de disear sus bases de datos, busca mejorar los siguientes dos criterios: Tiempo de ejecucin Espacio de memoria utilizado

Esto se realiza mediante operaciones, mtodos, que ayudan a reducir los costos de comunicacin y el consumo de recursos de la CPU. El manejo de los costos de comunicacin se define por las mtricas 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 optimizacin local se basa especficamente en condiciones locales dentro de un programa fuente, y no se contempla el flujo de ejecucin del programa, para este tipo de optimizacin lo que se contempla es particionar el cdigo en bloques bsicos de cdigo (alto nivel) y sobre estos fragmentos se lleva a cabo la optimizacin.

40

El trabajo de la ltima capa se efecta 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 optimizacin local sirve cuando un bloque de programa o seccin es crtico por ejemplo: la E/S, la concurrencia, la rapidez y confiabilidad de un conjunto de instrucciones. Caractersticas La optimizacin local se realiza sobre mdulos del programa. La optimizacin slo se ve reflejada en dichas secciones. Como el espacio de soluciones es ms pequeo la optimizacin local es ms rpida.

TRMINOS DE REPASO
Procesamiento distribuido de consultas Estrategias para el procesamiento de las consultas Arboles Tiempos de ejecucin Mtodo de join Costos de comunicacin Algoritmos de sistemas centralizados Algoritmos de optimizacin Hibrido Tiempo de optimizacin Optimizacin local y global.

40

AUTO EVALUACION
1.- Menciones los problemas ms 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 combinacin interna (INNER JOIN)? 5.- Explique el mtodo de combinacin externa (OUTER JOIN)? 6.- En qu consiste la combinacin completa? 7.- Qu es la optimizacin? 8.- Qu es la optimizacin de consultas? 9.- Cules son los pasos para generar una optimizacin? 10.- Mencione los criterios a mejorar al momento de disear una base de datos.

40

11.- Escriba las caractersticas de la optimizacin global de consultas. 12.- Escriba las caractersticas de la optimizacin local de consultas. 13.- Explique las maneras para hacer la optimizacin de consultas. 14.- Explica las maneras en las que se puede realizar la optimizacin. 15.-Cul es la funcin principal de un procesador de consultas relacional 16.-Cuando es correcta y eficiente la transformacin 17.-Representa el procesador de consultas 18.-Las consultas distribuidas se realizarn con la operacin 19.-Menciona las estrategias de procesamiento de consultas distribuidas

UNIDAD 4.- MANEJO DE TRANSACCIONES 4.1TRANSACCIONES Concepto: Es una unidad de ejecucin en un programa que accede y posiblemente actualiza varios elementos de datos. Una transaccin es una coleccin 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 informacin. Una transaccin en un Sistema de Gestin de Bases de Datos (SGBD), es un conjunto de rdenes que se ejecutan formando una unidad de trabajo, es decir, en forma indivisible o atmica. Es un conjunto de acciones llevadas a cabo por un usuario o un programa de aplicacin, que acceden o cambian el contenido de la base de datos. Una transaccin consiste en una serie de operaciones performed on a database. Realizado en una base de datos. The important issue in La cuestin importante en transaction management is that if a database was in a la gestin de transacciones es que si una base de datos estaba en un consistent state prior to the initiation of

40

a transaction, estado coherente antes de la iniciacin de una transaccin, then the database should return to a consistent state a continuacin, la base de datos debe volver a un estado coherente after the transaction is completed. Despus de la transaccin 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 ejecucin. Thus, a transaction is a unit of consistency and Por lo tanto, una transaccin 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 dependan de la consistencia de la informacin almacenada. Las transacciones son mecanismos que ayudan a simplificar la construccin de sistemas confiables mediante procesos que proporcionan soporte uniforme para invocar y sincronizar operaciones como: Operaciones de comparacin de datos Aseguramiento de la seriabilidad de las transacciones con otras Atomicidad en su comportamiento Recuperacin de fallas

La palabra transaccin describe una secuencia de operaciones con uno o ms recursos que transforman su estado actual en un nuevo estado de consistencia. Es un conjunto de operaciones sobre datos que son tratadas como una unidad. Una transaccin puede terminar, haciendo sus cambios persistentes, o abortar voluntaria o involuntariamente Una transaccin es una coleccin de operaciones que hacen transformaciones consistentes de los estados de un sistema conservando la consistencia del sistema. Una base de datos est en estado consistente si cumple todas las restricciones de integridad definidas sobre ella. Los cambios de estado se dan debido a actualizacin, insercin y eliminacin de la informacin. Se quiere asegurar que la base de datos no entre en un estado de inconsistencia, pero durante la ejecucin de una transaccin, la base de datos puede estar temporalmente en un estado inconsistente. Lo importante aqu es asegurar que la base de datos vuelva a un estado consistente al concluir la ejecucin de una transaccin (Figura A)

40

Figura A . Un modelo de transaccin.

Lo que se persigue con el uso de transacciones es por un lado contar con una transparencia adecuada de las acciones concurrentes a una base de datos y por el otro tener una transparencia adecuada en el manejo de las fallas que se pueden presentar en una base de datos.

Instrucciones para el uso de transacciones La programacin con uso de transacciones requiere de instrucciones especiales, las cuales deben ser proporcionadas por el sistema operativo, por el compilador del lenguaje o por el manejador de la base de datos, algunos son: BEGIN _TRANSACCIN: Los comandos siguientes forman una transaccin END _ TRANSACCIN: Termina la transaccin y se intenta un compromiso ABORT_ TRANSACCIN: Se elimina la transaccin, se recuperan los valores anteriores READ: Se leen datos de un archivo WRITE: Se escriben datos en un archivo Las operaciones entre BEGIN y END integran el cuerpo de la transaccin y deben ejecutarse todas o ninguna de ellas. La cantidad exacta de instrucciones disponibles para manejar transacciones depende del tipo de objetos y operaciones que deban ser procesadas. 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.

40

UPDATE J SET BUDGET = BUDGET*1.1 WHERE JNAME = "CAD/CAM"

Esta consulta puede ser especificada, usando la notacin de SQL, como una transaccin otorgndole un nombre: Begin_transaction ACTUALIZA_PRESUPUESTO begin UPDATE J SET BUDGET = BUDGET*1.1 WHERE JNAME = "CAD/CAM" end.

Ejemplo 2: Considere una agencia de reservaciones para lneas areas con las siguientes relaciones: FLIGHT( FNO, DATE, SRC, DEST, STSOLD, CAP ) CUST( CNAME, ADDR, BAL ) FC( FNO, DATE, CNAME, SPECIAL ) Una versin simplificada de una reservacin tpica puede ser implementada mediante la siguiente transaccin: Begin_transaction Reservacin begin input( flight_no, date, customer_name ); EXEC SQL UPDATE FLIGHT SET STSOLD = STSOLD + 1
40

WHERE FNO = flight_no AND DATE = date EXEC SQL INSERT INTO FC( FNAME, DATE, CNAME, SPECIAL ) VALUES (flight_no, date, customer_name, null ) output("reservacin terminada"); end. Las transacciones cuentan con las siguientes propiedades: Atomicidad: Una transaccin es tratada como una unidad de operacin. Por lo tanto todas las acciones de la transaccin se llevan a cabo o ninguna de ellas se realiza .La atomicidad requiere que si una transaccin se interrumpe por una falla, sus resultados parciales deben ser deshechos. Se efectan todas las transacciones, pero en caso de fallas no se realiza ninguna. Una transaccin debe concluir comprometida o abortada. En el caso del compromiso se instalan todas las actualizaciones y en el aborto se descartan todas las actualizaciones.
Consistencia :

Una transaccin es un programa correcto que lleva la base de datos de un estado consistente a otro con la misma caracterstica. Gracias a esto, las transacciones no violan las reglas de integridad de una base de datos. Aislamiento : Durante la ejecucin de una transaccin, 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 transaccin realiza su compromiso, sus resultados son permanentes y no pueden ser borrados de la base de datos, se asegura que los resultados de una transaccin sobrevivirn a fallas del sistema.

40

Las transacciones brindan una ejecucin atmica y confiable en presencia de fallas, una ejecucin correcta en presencia de accesos de usuario mltiples y un manejo correcto de replicas (en el caso que se soporten). 4.1.1 ESTRUCTURA DE TRANSACCIONES La estructura de una transaccin usualmente viene dada segn el modelo de la transaccin, estas pueden ser planas (simples) o anidadas. Transacciones planas.- Consisten de una secuencia de operaciones primitivas encerradas entre las palabras clave begin y end. Por ejemplo: Begin_transaction Reservacin End Transacciones anidadas.- Consiste en tener transacciones que pueden ser de otras transacciones, estn incluidas dentro de otras de un nivel superior que se les conoce como subtransacciones. Por ejemplo: Begin_transaction Reservacin Begin_transaction Vuelo End. (Vuelo) Begin_transaction Hotel End End. Una transaccin anidada da otra transaccin 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 transaccin anidada: debe empezar despus que su padre y debe terminar antes que l. Ms an, el commit de una subtransaccin es condicional al commit de su padre, en otras palabras, si el padre de una o varias transacciones aborta, las subtransacciones hijas tambin sern abortadas. Las transacciones anidadas brindan un nivel ms alto de concurrencia entre transacciones. Ya que una transaccin consiste de varias transacciones es posible tener mayor concurrencia dentro de una sola transaccin. As tambin, es posible recuperarse de de fallas de forma independiente de cada subtransaccion. Esto limita el dao a una parte ms pequea de la transaccin, haciendo que el costo de la recuperacin sea el menor.
40

Tambin se deben considerar el orden de las lecturas y escrituras. Si las acciones de lectura y escritura pueden ser mezcladas sin ninguna restriccin, entonces, a este tipo de transacciones se les conoce como Generales .Por el contrario, si se restringe o impone que un dato debe ser ledo antes de que pueda ser escrito entonces se tendrn transacciones Restringidas. Si las transacciones son restringidas a que todas las acciones de lectura se realicen antes de las acciones de escritura entonces se les conoce como de Dos Pasos. Finalmente existe un modelo de accin para transacciones restringidas en donde se aplica aun ms la restriccin de que cada par < read , write > tiene que ser ejecutado de manera atmica.
4.1.2 EJECUCIN DE TRANSACCIONES CENTRALIZADA Y DISTRIBUIDA

Los siguientes son los aspectos ms importantes relacionados con el procesamiento de transacciones Modelo de estructura de transacciones. Es importante considerar si las transacciones son planas o anidadas. Consistencia de la base de datos interna. Los algoritmos de control de datos tienen que satisfacer las restricciones de integridad cuando una transaccin pretende hacer un compromiso. Protocolos de confiabilidad En transacciones distribuidas es necesario introducir medios de comunicacin entre los diferentes nodos de una red para garantizar la atomicidad de las transacciones. Algoritmos de control de concurrencia Deben sincronizar la ejecucin de transacciones concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas. Protocolos de control de replicas Se refiere a cmo garantizar la consistencia mutua de datos replicados. El procesamiento de transacciones bsicamente consiste en una serie de modificaciones (transacciones) a un determinado recurso del sistema (por ejemplo una base de datos) y en donde se define un punto de inicio y un punto de terminacin que define un bloque entre el conjunto de operaciones que son realizadas. Dentro de este proceso en bloque los dems usuarios no pueden modificar nada hasta que no se presente un estado estable de los datos, esto ocasiona

40

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 dndole una secuencia a cada transaccin, este proceso reduce el rendimiento del sistema, pero tiene como ventaja que el proceso de sincronizacin es ms sencillo.

2- Ejecutar transacciones calendarizadas: Permite el proceso de transacciones asignndoles tiempos de procesamiento el cual permite incrementar el rendimiento del sistema ya que se ejecuta un mximo de procesos en forma concurrente y no a travs de una serie. La ventaja es que a un mismo tiempo de reloj se pueden hacer dos operaciones, aunque el proceso de sincronizacin es ms complicado.

Un aspecto muy importante en el manejo de transacciones es el de mantener y aplicar algoritmos de control sobre los datos o recursos; para ese control tambin se utilizan protocolos que proporcionen confiabilidad como lo siguientes: Atomicidad Protocolos de recuperacin total Protocolos de compromiso global Para llevar el control de concurrencia dentro de un proceso de transacciones se manejan dos modos: Ejecucin centralizada de transacciones
40

Ejecucin distribuida de transacciones Ejecucion centralizada de transacciones

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

40

... end. La estructura de una transaccin usualmente viene dada segn el modelo de la transaccin, estas pueden ser planas (simples) o anidadas. Transacciones Anidadas: Consiste en tener transacciones que dependen de otras, estas transacciones estn incluidas dentro de otras de un nivel superior y se las conoce como subtransacciones. La transaccin de nivel superior puede producir hijos (subtransacciones) que hagan ms fcil la programacin del sistema y mejoras del desempeo. En las transacciones anidadas las operaciones de una transaccin pueden ser as mismo otras transacciones. Por ejemplo: BEGIN _TRANSACTION Reservacin .......... BEGIN _TRANSACTION Vuelo ........ END.( Vuelo ) ...... BEGIN _TRANSACTION Hotel ........ END ...... END. En las transacciones anidadas las operaciones de una transaccin pueden ser as mismo transacciones. Por ejemplo, Begin_transaction Reservacin ... Begin_transaction Vuelo ... end. {Vuelo} ...

40

Begin_transaction Hotel ... end. Las transacciones anidadas proporcionan un nivel ms alto de concurrencia entre transacciones. Ya que una transaccin consiste de varios transacciones, es posible tener ms concurrencia dentro de una sola transaccin. As tambin, es posible recuperarse de fallas de manera independiente de cada subtransaccin. Esto limita el dao a un parte ms pequea de la transaccin, haciendo que costo de la recuperacin sea menor. Una transaccin anidada dentro de otra transaccin 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 transaccin anidada: debe empezar despus que su padre y debe terminar antes que l. Ms an, el commit de una subtransaccin es condicional al commit de su padre, en otras palabras, si el padre de una o varias transacciones aborta, las subtransacciones hijas tambin sern abortadas

4.2CONTROL 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 ms simple de lograr este objetivo es ejecutar cada transaccin sola, una despus de otra. Un mtodo de control de concurrencia es correcto si es serializable, es decir existe una secuencia equivalente en que las operaciones de cada transaccin aparecen antes o despus de otra transaccin pero no entremezcladas. Una ejecucin serial de transacciones es siempre correcta. Si no se hace un adecuado control de concurrencia, se pueden presentar dos anomalas. En primer lugar, se pueden perder actualizaciones provocando que los efectos de algunas transacciones no se reflejen en la base de datos.

40

 En segundo trmino, pueden presentarse recuperaciones de informacin 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 ilusin 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 accin atmica sea completada en un tiempo finito. Uno de los problemas de concurrencia especficos de las bases de datos distribuidas es la consistencia de copia mltiple, se produce cuando un mismo dato esta en varias localizaciones. Adems se siguen dando los mismos problemas para bases de datos centralizadas prdida de actualizaciones, dependencia neutral uncommitted dependency y anlisis inconsistentes.

4.2.1 SERIALIZACIN DE TRANSACCIONES

Seriabilidad.
La seriabilidad consiste en asegurarse que los cambios siguen un orden adecuado. Teora de la serializad Una canderilizacion ischedulel tambin llamado una historia se define un conjunto de transacciones I= {T1,T2, TN} y especifican orden entrelazada de la ejecucin 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 }
40

En bases de datos distribuidos es necesario considerar dos tipos de historia para poder generar calendarizaciones serializables: la canderizacion de la ejecucin de transacciones globales sern 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 estn 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 readwrite (o write-read) y write-write. Las dos operaciones en conflicto pueden pertenecer a la misma transaccin 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 ejecucin es importante. El orden de dos operaciones de lectura es insignificante. Una calendarizacin completa define el orden de ejecucin de todas las operaciones en su dominio. Formalmente, una calendarizacin completa STc definido sobre un conjunto de transacciones T = { T1, T2, ..., Tn } es un orden parcial STc = { S T, <T } en donde

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 condicin establece simplemente que el dominio de la calendarizacin es la unin de los dominios de las transacciones individuales. La segunda condicin define la relacin de ordenamiento como un superconjunto de la relacin de ordenamiento de transacciones individuales. Esto mantiene el ordenamiento de las operaciones dentro de cada transaccin. La condicin final define el orden de ejecucin entre dos operaciones en conflicto. 4.2.2 ALGORITMOS DE CONTROL DE CONCURRENCIA Aquellos algoritmos que estn basados en acceso mutuamente exclusivo a datos compartidos (candados o bloqueos) y aquellos que intentar ordenar la ejecucin de las transacciones de acuerdo a un conjunto de reglas (protocolos). Sin
40

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 ejecucin concurrente de las transacciones en su etapa inicial de su ciclo de ejecucin. Los algoritmos optimistas retrasan la sincronizacin de las transacciones hasta su terminacin. El grupo de algoritmos pesimistas consiste de algoritmos basados en candados, algoritmos basados en ordenamiento por estampas de tiempo y algoritmos hbridos. Los algoritmos para el control de concurrencia son tiles cuando se ejecutan varias transacciones al mismo tiempo

Clasificacin 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), tambin llamados compartidos, o de escritura (wl), tambin llamados exclusivos. Como se aprecia en la tabla siguiente:

40

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.

Existen diversos enfoques para complementar el gestor de bloqueos, cada uno de ellos con ventaja y desventaja se describen a continuacin los principales enfoques. Gestin 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 transaccin 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 solucin tiene por ventaja una implementacin 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 mtodos). Candados de dos fases (2PL) En los candados de dos fases una transaccin le pone un candado a un objeto antes de usarlo. Cuando un objeto es bloqueado con un candado por otra transaccin, la transaccin solicitante debe esperar. Cuando una transaccin libera un candado, ya no puede solicitar ms candados. La importancia de los candados de dos fases es que se ha demostrado de manera terica que todos las calendarizaciones generadas por algoritmos de control de concurrencia que obedecen a los candados de dos fases son serializables.

40

Grfica del uso de los candados de dos fases

Comportamiento de los candados de dos fases estrictos. Candados de dos fases centralizados En sistemas distribuidos puede que la administracin de los candados se dedique a un solo nodo del sistema, por lo tanto, se tiene un despachador central el cual recibe todas las solicitudes de candados del sistema. Se presenta la estructura de la comunicacin de un administrador centralizado de candados de dos fases. La comunicacin se presenta entre el administrador de transacciones del nodo en donde se origina la transaccin (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 operacin se va a llevar a cabo.

40

Comunicacin en un administrador centralizado de candados de dos fases estrictos.

4.2.2.2

BASADOS EN ESTAMPAS DE TIEMPO

Los algoritmos basados en estampas de tiempo no pretenden mantener la seriabilidad por exclusin mutua. En lugar de eso, ellos seleccionan un orden de serializacin a prioridad y ejecutan las transacciones, de acuerdo a ellas. Para establecer este ordenamiento, el administrador de transacciones le asigna a cada transaccin T1 una estampa de tiempo nica t1 (T1) cuando sta inicia. Una estampa de tiempo es un identificador simple que sirve para identificar cada transaccin 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 monofnicamente crecientes.

40

Existen varias formas en que las estampas de tiempo se pueden asignar. Un mtodo 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 autnoma las estampas de tiempos basndose en un contador local. Ordenamiento conservador por estampas de tiempo El ordenamiento bsico por estampas de tiempo trata de ejecutar una operacin tan pronto como se recibe una operacin. As, la ejecucin de las operaciones es progresiva pero pueden presentar muchos reinicios de transacciones. El ordenamiento conservador de estampas de tiempo retrasa cada operacin hasta que exista la seguridad de que no ser reiniciada. La forma de asegurar lo anterior es sabiendo que ninguna otra operacin 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 creacin de interbloqueos (deadlocks).

Ordenamiento por estampas de tiempo mltiples Para prevenir la formacin de interbloqueos se puede seguir la estrategia siguiente. Al hacer una operacin de escritura, no se modifican los valores actuales sino se crean nuevos valores. As, puede haber copias mltiples de un dato. Para crear copias nicas se siguen las siguientes estrategias de acuerdo al tipo de operacin de que se trate:
1. Una operacin de lectura Ri(x) se traduce a una operacin de lectura

de x de una sola versin encontrando la versin de x, digamos xv, tal que, ts(xv) es la estampa de tiempo ms grande que tiene un valor menor a ts(Ti). 2. Una operacin 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 VALIDACIN OPTIMISTAS El protocolo mas reciente propuesta es el denominado optimista (OPT) el cual acenta la pertenencia general del sistema reduciendo el bloqueo proveniente de aquellas transacciones que estn 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.

40

Sin embargo, en este tipo de mecanismos, no con los datos ms aun as con las estampas de tiempo no se asignan al inicio de una transaccin sino justamente al inicio de su fase de validacin. Esto se debe a que las estampas se requieren nicamente durante la fase de validacin. Los algoritmos optimistas, retrasan la fase de validacin justo antes de la fase de escritura (ver Figura). De esta manera, una operacin sometida a un despachador optimista nunca es retrasada. Las operaciones de lectura, cmputo y escrita de cada transaccin se procesan libremente sin actualizar la base de datos corriente. Cada transaccin inicialmente hace sus cambios en copias locales de los datos. La fase de validacin consiste en verificar si esas actualizaciones conservan la consistencia de la base de datos. Si la respuesta es positiva, los cambios se hacen globales. De otra manera, la transaccin es abortada y tiene que reiniciar.

Cada transaccin Ti se subdivide en varias subtransacciones, cada una de las cuales se puede ejecutar en nodos diferentes. Sea Tij una subtransaccin 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 validacin se realiza una prueba de validacin, si una transaccin falla, todas las transacciones se rechazan. La Prueba De Validacin 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 validacin tiene xito. En este caso la ejecucin de las transacciones es completamente serial como se muestra en la Figura. 2.- Si existe alguna transaccin 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 validacin tiene xito si WS(Tk ) RS(Tij ) = . En este caso, las fases de lectura y escritura

40

se traslapan, como se muestra en la Figura 6.7b, pero Tij no lee datos queson escritos por Tk. 3.- Si existe alguna transaccin 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 validacin 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.

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 verificacin durante la ejecucin. Los cambios se realizan sobre copias locales. Al final de la ejecucin existe una fase de validacin que comprueba que cualquiera de las actualizaciones violaba la seriabilidad.

40

4.2.3 DISCIPLINAS DEL INTERBLOQUEO: PREVENCIN, DETECCIN,

ELIMINACIN Y RECUPERACIN. El interbloqueo.- Un esquema para resolver el interbloque en su detencin, 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 gestin concurrente de procesos, no existe una solucin 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 relacin de espera entrenada se define como sigue: Una transaccin y relacin de espera a otra transaccin T9 si te ha solicitado el bloqueo de un granulo y esta peticin 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 grnulos. Un nodo une un granulo G1 a una transaccin T10 si T9 tiene bloqueado el granulo G1. Un arco une una transaccin T9 con un granulo G1 si T9 ha solicitado un bloqueo del granulo pero no le ha conseguido. Una condicin necesaria para que haya un interbloqueo es que Q1 exista con ciclo en el grafo de reservas. Detencin.- Existen diversos algoritmos para ello en la detencin de ciclos en el grafo de esperas, entre ellos: Algoritmo 1.- Comprueba la existencia de ciclos mediante la eliminacin de nodos terminales. Algoritmo 2.- Comprueba posibles ciclos desde la ltima transaccin bloqueada y

40

marcando los nodos por lo que pasa. Si pasa dos veces por el mismo nodo a detectado un ciclo. Prevencin.- Las tcnicas de interbloqueo utilizan el concepto de marca de tiempo detransaccin existen dos esquemas que evitan el interbloqueo. Recuperacin.- El objetivo de esta parte de la asignacin es conocer y entender las distintas fallas que pueden ocurrir en un BMS y cmo es posible restaurar el sistema despus de dichas fallas este tema se llama recuperacin de fallas. La recuperacin de fallas esta internamente ligado Al procesamiento de las transacciones tiene la cualidad de ser anotmica a pesar de que puede estar compuesto de varias operaciones de atomicidad se controla como llegada al commit. Si una transaccin no sufri ningn problema y se pudo ejecutar completa, entonces el DBMS debe de comprometerse hacer permanentes los cambios que la transaccin hizo sobre la base de datos y a que esta debido quedar en un estado de conciencia. 4.3CONFIABILIDAD Un sistema de manejo de bases de datos confiable es aquel que puede continuar procesando las solicitudes de usuario an 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 transaccin se ejecutan todas o ninguna. DURABILIDAD: Despus de que una transaccin se ejecut con xito, los cambios en la BD persisten, ms 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 ocasin. 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 ejecutndose las solicitudes de usuario sin violar la consistencia de la base de datos.
40

4.3.1 CONCEPTOS BSICOS DE CONFIABILIDAD SISTEMA, ESTADO Y FALLA: Un sistema se refiere a un mecanismo que consiste de una coleccin de componentes y sus interacciones con el medio ambiente que responden a estmulos que provienen del mismo con un patrn de comportamiento reconocible. Un estado externo de un sistema se puede definir como la respuesta que un sistema proporciona a un estmulo externo. Por lo tanto, es posible hablar de un sistema que se mueve dentro de estados externos de acuerdo a un estmulo proveniente del medio ambiente. Un estado interno es, por lo tanto, la respuesta del sistema a un estmulo interno. Cualquier desviacin de un sistema del comportamiento descrito en su especificacin 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 distribucin de Poisson, entonces, R(t) = Pr{ 0 fallas en el tiempo [0,t] }. El clculo de la confiabilidad y disponibilidad puede ser tedioso. Por lo tanto, es acostumbrado usar dos mtricas de un slo parmetro para modelar el comportamiento del sistema. Las dos mtricas son el tiempo medio entre fallas (MTBF por sus siglas en ingls) y el tiempo medio para reparaciones (MTTR). El

40

MTBF puede ser calculado a partir de datos empricos de la funcin de confiabilidad. La confiabilidad es una condicin 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. La confiabilidad tambin se refiere a la medida en la cual un instrumento de recopilacin de datos producir los mismos resultados cada vez que se administra. En la investigacin cualitativa, la confiabilidad significa hasta qu punto diferentes investigadores, al exponerse a la misma situacin, llegaran a las mismas conclusiones. En trminos de confiabilidad lo que preocupa es la consistencia de los resultados. Se necesita la confiabilidad para poder hablar de resultados vlidos, puesto que no es posible evaluar algo que cambia continuamente. 4.3.2 PROTOCOLOS REDO/UNDO En un protocolo con escritura previa en bitcora, las entradas en la bitcora se dividen en dos tipos: las necesarias para operaciones REDO (entradas write_tem conteniendo slo 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 recuperacin consulta a la bitcora para determinar que transacciones deben deshacerse o rehacerse. UNDO (T): cuando la bitcora contiene el registro <T,start> pero no contiene el registro <T,commit>. REDO (T): cuando la bitcora contiene tanto el registro <T,start> como el registro <T,commit>. El esquema de recuperacin usa la operacin REDO rehacer usando informacin de la bitcora. En caso de que ocurra una cada o fallo de una transaccin se debe recurrir a una operacin UNDO que deshace los cambios hechos. Undo (T): restaura todos los datos que T actualiza a los valores que tena anteriormente. Redo (T): asigna los nuevos valores a todos los datos que actualiza la transaccin T.

40

Es importante respetar el orden de ejecucin de las operaciones para la recuperacin. Las operaciones UNDO deben realizarse antes que las operaciones REDO. Las operaciones de UNDO se realizan recorriendo la bitcora desde abajo hacia arriba, esto es, en orden inverso al que se ejecutaron. Las operaciones de REDO se realizan recorriendo la bitcora desde arriba hacia abajo, esto es, en el mismo orden en que se actualiz.

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 debera ser 30, y eso es posible de alcanzar si se realiza primero el UNDO y luego el REDO. La operacin redo utiliza la informacin del registro de la base de datos y realiza de nuevo las acciones que pueden haber sido realizadas antes de la falla, la operacin 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 pginas de la base de datos voltil correspondientes a la transaccin T2. As, la informacin de recuperacin debe incluir datos suficientes para permitir deshacer ciertas actualizaciones en el nuevo estado de la base de datos y regresarla al estado anterior. La operacin UNDO restablece un dato a su imagen anterior utilizando la informacin del registro de bases de datos.
40

Independientemente de que la escritura del registro sea sncrona o asncrona, 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 actualizacin. 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 actualizacin lo que har imposible recuperar la base de datos a un estado consistente antes de la actualizacin. 4.3.3 PUNTOS DE VERIFICACIN (CHECK POINTS) Los checkpoints buscan reducir los tiempos extra en los procesos de bsqueda en la bitcora. Al disparar un checkpoint el sistema realiza la siguiente secuencia de acciones: Grabar en memoria estable todos los registros de bitcora que estn en memoria principal. Grabar en disco los bloques modificados de los registros intermedios (buffer). Grabar un registro de bitcora <checkpoint> en memoria estable.

Cuando ocurre un fallo del sistema es necesario consultar la bitcora para ver cules transacciones deben rehacerse y cules deshacerse. PASOS A SEGUIR ANTE FALLOS: 1.- Para cada transaccin Ti tal que aparece en la bitcora el registro <Ti,commit> antes del registro <checkpoint>, no es necesario ejecutar un REDO. 2.- Despus de un fallo, se examina la bitcora para determinar cul fue la ltima transaccin Ti que comenz a ejecutarse antes del ltimo checkpoint. *Esto se hace examinando la bitcora hacia atrs buscando el primer registro <checkpoint>

40

y cual es el registro <Ti,start> ms 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 bitcora peridicamente 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 recuperacin solamente se consideraban: *Aquellas transacciones que comenzaron despus del checkpoint ms reciente. *La nica transaccin (si exista) que estaba activa al momento del ms reciente checkpoint. En un esquema concurrente puede haber ms de una transaccin activa al momento del checkpoint.

Las operaciones de recuperacin 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
40

reducir este trabajo se pueden poner puntos de verificacin (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 verificacin y un UNDO tiene que regresar al punto de verificacin ms inmediato anterior. La colocacin de puntos de verificacin 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 verificacin nos ayudan para reducir el gasto de tiempo consultando la bitcora. El punto de verificacin en un registro que se genera en la bitcora 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 bitcora buscando del final al inicio el primer registro check point ya encontrado se procesan los registros que se encuentran despus del check point. 4.3.4 PROTOCOLOS 2PC DE CONFIABILIDAD DISTRIBUIDA Es un protocolo que consume un gran volumen de tiempo en la ejecucin de una Transferencia durante el procesamiento normal se puede eliminar accesos a disco o el nmero de mensajes en el proceso de la transaccin la pertenencia 2pc podra ser mejorado. El 2pc es conocido tambin 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 subtransaccin debe informar a las otras subtransacciones de que ha requerido todos los bloqueos. Una transaccin T que fue iniciada en un sitio S y dividida en varias subtransacciones ejecutndose en diferentes sitios. Las subtransaccin se ordenan en un coordinador y las otras participantes. Cada subtransaccin Ti decide si cometer o abortar, y enva al coordinador un mensaje . El coordinador toma la decisin final en funcin 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 subtransaccin 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:

40

Mejora: Cada subtransaccin mide el tiempo mximo de espera por una respuesta. Un participante que alcanza el tiempo mximo pasa al estado de intentar recuperarse. Para ello enva un mensaje de ayuda help me a los otros participantes. Ante el pedido de ayuda, otros participantes segn su estado contestan: Si est en estado cometida, le enva un mensaje commit. Si est en estado abortado, le enva un mensaje abort. Si est en estado decidiendo (no vot an) decide abortar y enva abort T al coordinador. Si est en estado dispuesta a comenter, no puede ayudar.

En la siguiente figura se presentan las dos fases de comunicacin para realizar un commit en sistemas distribuidos. El esquema presentado en la figura se conoce como centralizado ya que la comunicacin es solo entre el coordinador y los participantes; los participantes no se comunican entre ellos.

40

Replicacin nerge Esta permite la replicacin 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 sincronizacin se encarga de actualizar las modificaciones realizadas en las copias de los suscriptores y viceversa.

EJERCICIOS DE ALGEBRA RELACIONAL

Ejercicio 1:
Resultados: a) Obtener los nombres de las papeleras abastecidas por algn editorial de Madrid NOMP (PAPELERIAS *ELP( CIUDAD =MADRID(EDITORIALES))
40

b) Obtener los valores de E# para las editoriales que suministran alas papelera P1 y P2 libros publicados en 1978. NOME (EDITORIALES *E#( AO=1978(LIBROS)*P#=p1(ELP)) n E#( AO =1978(LIBROS)* P# =P3(ELP)) c) obtener los valores de p# de las papeleras abastecidas completamente por la editorial NOMP (PAPELERIA *(P#(ELP) E# (ELP))) d) Obtener los valores de L# para los libros suministrados para todas las papeleras que no sean de Madrid. TITULO (LIBRO ( CIUDAD MADRID)-L#(ELP)))

Ejercicio 2:
Se pide expresar en trminos 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 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 aos por ms de 3 horas. O# ( edad 30(usuarios)*ordenadores* ( tiempo=3(usos)))

40

Ejercicio 3:
B) videoclubes que disponen de alguna pelcula que le guste a jos prez

videoclub, pelcula (videoclub, pelcula)=x= pelcula ( aficionado=jos Prez (gusta ))

C) aficionados que son socios al menos de un videoclub que dispone de alguna pelcula de su gusto

aficionado, videoclub (socio) u aficionado, pelcula (gusta)

D) aficionados que no son socios de ningn videoclub donde tengan alguna pelcula 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 ningn trabajo M#(tipo=trabajo(maquinas) *(nombre)) 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))))
40

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)

Ejercicio 6:
A) Obtener los ciclistas que solo han participado en competiciones inferior a 15 das. C# (ciclistas * (duracin = 15 min(competiciones)))

40

B) Obtener los ciclistas de equipos espaoles que han competido en todas las competiciones de Espaa. C#(equipo * (M# ( pas = Espaa (competiciones))))
C) Obtener los ciclistas que han obtenido un primer y un segundo lugar

puestos en competicin con una duracin inferior a 15 das. nombre ( competiciones * ( puesto = primer (clasificacin * (competiciones *( puesto=segundo(clasificacin))))) n C#( ciclistas *(duracin = = 15 das(competicin)))

Ejercicio 7:
A) Obtener el nombre e aquellos conductores que hallan sido

denunciados por todas las infracciones inferiores a 100000 ptas. nombreC (denuncia-(C#( infraccin = 10000(infraccin )) * (conductor))
B) Obtener el cdigo de aquellos agentes que solo hayan denunciado

infracciones de estacionamiento. A# (agentes * infraccin ( descrip= estacionamiento (denuncia) C) Obtener el cdigo de aquellos conductores que no tengan ninguna denuncia pendiente de pago. C#(conductores * denuncia ( pagada = S o N)

TERMINOS DE REPASO
Ejecucin de transacciones Concurrencia Estructura de las transacciones Transacciones centralizadas

40

Transacciones distribuidas Algoritmos basados en concurrencia Serializacion Interbloqueo Protocolos redo Protocolos undo

AUTOEVALUACION
1.- Defina que es una transaccin 2.- Explique las propiedades de las bases de datos para asegurar la consistencia de los datos.

40

3.- Mencione que son las transacciones planas. 4.- Explique que son las transacciones anidadas. 5.- Mencione los aspectos ms importantes relacionados con el procesamiento de transacciones. 6.- En qu consiste ejecutar transacciones serializadas? 7.- Explique en qu consiste ejecutar transacciones calendarizadas. 8.- Cul 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 caractersticas 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.

Bibliografa Fundamentos de Bases de Datos, (Tercera Edicin), Autores: Abraham Silberschatz, Henry F. Korth, S. Sudarshan Modelos avanzados de bases de datos, universidad de castilla-la mancha, esc.superior de informtica.

40

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: diseo, implementacin y gestin. Pearson - Addison Wesley, 4 edicin. 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.p df http://www.mitecnologico.com/Main/OptimizacionDeConsultasDistribuidas http://sistemas-distribuidos-unerg.blogspot.com/2007/12/bases-dedatosdistribuidas.html http://catarina.udlap.mx/u_dl_a/tales/documentos/msp/alvarez_c_g/capitulo1.pdf

40