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

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

CENTRALIZADOControl centralizado: un solo DBA

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

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

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 datos40

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

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 La lista de atributos, es la lista de nombres de atributos cuyos valores sern40

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

3440

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 motor40

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 EVALUACION1.- 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 + 140

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

Ta