UNIDAD 1


Sistema de Base de Datos distribuidas

1.1 CONCEPTOS BASICOS DE BASES DE DATOS DISTRIBUIDAS

DEFINICION DE BASE DE DATOS DISTRIBUIDAS:  
Es una colección de datos que pertenecen lógicamente a un sólo sistema, pero se encuentra fisicamente esparcido en varios sitios de la red. Un sistema de base de datos distribuidas se compone de un conjunto de sitios, conectados entre sí mediante algún tipo de red de comunicaciones.



los sitios han convenido en trabajar juntos ( si es necesario ) con el fin de que un usuario de cualquier sitio pueda obtener acceso a los datos de cualquier punto de la red tal como si todos los datos estuvieran almacenados en el sitio propio del usuario.


El procesamiento de bases de datos distribuidas es el proceso en el cual la ejecución de transacciones y la recuperación y actualización de los datos acontece a través de dos o más computadoras independientes, por lo general separadas geográficamente.
Las Bases de Datos Distribuidas , no son simplemente implementaciones distribuidas de bases de datos centralizadas, por que ellas permiten el diseño de sistemas que representan diferentes características de las tradicionales, de sistemas centralizados. Esto es por lo tanto útil para ver las características típicas de BDD. Los rasgos que caracterizan las BD tradicionales se aproximan al control centralizado, independencia de datos, reducción de redundancia, estructuras físicas complejas para acceso eficiente, integridad, recuperación control de concurrencia, privacidad y seguridad.
 Los principales factores que distinguen un SBDD de un sistema centralizado son los siguientes:
  • Hay múltiples computadores, llamados sitios o nodos.
  • Estos sitios deben de estar comunicados por medio de algún tipo de red de comunicaciones para transmitir datos y órdenes entre los sitios






    1.2 DISEÑO DE BASES DE DATOS DISTRIBUIDAS


    BASE DE DATOS DISTRIBUIDAS
    Una base de datos distribuida (BDD) es un conjunto de múltiples bases de datos lógicamente relacionadas las cuales se encuentran distribuidas entre diferentes sitios interconectados por una red de comunicaciones, los cuales tienen la capacidad de procesamiento autónomo lo cual indica que puede realizar operaciones locales o distribuidas. Un sistema de Bases de Datos Distribuida (SBDD) es un sistema en el cual múltiples sitios de bases de datos están ligados por un sistema de comunicaciones de tal forma que, un usuario en cualquier sitio puede acceder los datos en cualquier parte de la red exactamente como si los datos estuvieran siendo accedidos de forma local.

    En un sistema distribuido de bases de datos se almacenan en varias computadoras. Los principales factores que distinguen un SBDD de un sistema centralizado son los siguientes:
    Hay múltiples computadores, llamados sitios o nodos.
    Estos sitios deben de estar comunicados por medio de algún tipo de red de comunicaciones para transmitir datos y órdenes entre los sitios.
    Por lo que el hardware que compone una base de datos distribuida se reduce a servidores y la red.

    También consta con una serie de software:
    Sistema de Administración de Base de Datos Distribuida (DDBMS)
    Este sistema está formado por las transacciones y los administradores de la base de datos distribuidos.

    Administrador de transacciones distribuidas (DTM)
    Este es un programa que recibe las solicitudes de procesamiento de los programas de consulta o transacciones y las traduce en acciones para los administradores de la base de datos.
    Administrador de la base de datos (DBM)
    Es un programa que procesa cierta porción de la base de datos distribuida. Se encarga de recuperar y actualizar datos del usuario y generales de acuerdo con los comandos recibidos de los DTM.

    Nodo
    Un nodo es una computadora que ejecuta un DTM o un DBM o ambos. Un nodo de transacción ejecuta un DTM y un nodo de base de datos ejecuta un DBM.
    Ventajas y Desventajas
    Ventajas
    Refleja una estructura organizacional - los fragmentos de la base de datos se ubican en los departamentos a los que tienen relación.
    Autonomía local - un departamento puede controlar los datos que le pertenecen.
    Disponibilidad - un fallo en una parte del sistema solo afectará a un fragmento, en lugar de a toda la base de datos.

    Rendimiento - los datos generalmente se ubican cerca del sitio con mayor demanda, también los sistemas trabajan en paralelo, lo cual permite balancear la carga en los servidores.
    Economía - es más barato crear una red de muchas computadoras pequeñas, que tener una sola computadora muy poderosa.
    Modularidad - se pueden modificar, agregar o quitar sistemas de la base de datos distribuida sin afectar a los demás sistemas (módulos).

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

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

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

    Integridad - Se vuelve difícil mantener la integridad, aplicar las reglas de integridad a través de la red puede ser muy caro en términos de transmisión de datos.
    Falta de experiencia - las bases de datos distribuidas son un campo relativamente nuevo y poco común por lo cual no existe mucho personal con experiencia o conocimientos adecuados.
    Carencia de estándares - aún no existen herramientas o metodologías que ayuden a los usuarios a convertir un DBMS centralizado en un DBMS distribuido.

    Diseño de la base de datos se vuelve más complejo - además de las dificultades que generalmente se encuentran al diseñar una base de datos, el diseño de una base de datos distribuida debe considerar la fragmentación, replicación y ubicación de los fragmentos en sitios específicos.  








    1.3. Procesamiento de operaciones de actualización distribuidas

     

    Una transacción es una unidad lógica de trabajo, la cual no necesariamente consta de una sola operación en la base de datos; más bien, es en general una secuencia de varias de esas operaciones mediante la cual un estado consistente de la base de datos se transforma en otro estado consistente, sin conservar por fuerza la consistencia en todos los puntos intermedios. El punto importante aquí es asegurar que la base de datos regresa a un estado consistente al fin de la ejecución de una transacción. Una transacción es también la invocación a un procedimiento remoto (RPC) que ejecuta un conjunto de operaciones sobre una base de datos bajo el principio de todo o nada.

    El concepto fundamental aquí es la noción de “ejecución consistente” o “procesamiento confiable” asociada con el concepto de una consulta. El concepto transacción es usado dentro del dominio de la base de datos como una unidad básica de cómputo consistente y confiable.

    Mecanismos de recuperación
    A fin de soportar una respuesta favorable para la ejecución de transacciones, el DBMS (Sistema Manejador de Bases de Datos) deberá de manejar el procesamiento de transacciones. Esto es, deberá de garantizar que si la transacción ejecuta algunas modificaciones y después se presenta una falla (por cualquier razón), antes de que llegue al término normal de la transacción, se anularán esas modificaciones. Así, o bien se lleva a cabo la transacción en su totalidad, o se cancela en su totalidad. De esta manera puede lograrse que una secuencia de operaciones, la cual en esencia no es atómica, aparente serlo desde un punto de vista externo. El componente del sistema encargado de lograr esta apariencia de atomicidad se conoce como Manejador de transacciones, y las operaciones de COMMIT (comprometer) y ROLLBACK (retroceder) son la clave de su funcionamiento.

    La operación COMMIT señala el término exitoso de la transacción: le dice al manejador de transacciones que se ha finalizado con éxito una unidad lógica de trabajo, que la base de datos esta (o debería estar) de nuevo en un estado consistente, y que se pueden hacer permanentes todas las modificaciones efectuadas por esa unidad de trabajo.

    La operación ROLLBACK, en cambio, señala e término no exitoso de la transacción: le dice al manejador de transacciones que algo salió mal, que la base de datos podría estar en un estado inconsistente y que todas las modificaciones efectuadas hasta el momento por la unidad lógica de trabajo deben retroceder o anularse.

     

     

    1.4. Procesamiento de consultas distribuidas.     

     

                                                                                 

    METODOLOGIA DE PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS
    Primeramente se debe de contar con heterogeneidad de los datos, para que puedan ser usados para formular consultas. Tenemos los siguientes ejemplos:

    1
    BD CENTRALIZADA
    2

    BD DISTRUIBUIDA
    Así como también necesitamos contar con:

    • -Localización de los datos para generar reglas heurísticas
    • -Descomposición de consultas en paralelo en cada nodo
    • -Reducir la cantidad de datos a transferir en la red

    Estrategias de procesamiento de consultas de bases de datos distribuidas
    3

    Contamos con la estrategia de Reformulación de consultas, que nos sirve para encontrar q la información que nos va a proveer sea solo la que se le pidió por la fuente

    También se cuenta con la estrategia de descomposición de las fuentes, q consiste en que según las fuentes q pidan cierto tipo de datos sean las atenidas con mayor velocidad.
    Optimización de consultas distribuidas
    Para poder optimizar una consulta necesitamos tener claras las propiedades del algebra relacional para asegurar la reformulación de la consulta, al optimizar una consulta obtenemos los siguientes beneficios:

    • -minimizar costos
    • -Reducir espacios de comunicaciones
    • -Seguridad en envíos de información
    Estrategias de procesamiento de consultas distribuidas
    4

    Investigar, sobre las diferentes estrategias de procesamiento de consultas distribuidas, tales como: árboles de consultas, transformaciones equivalentes, métodos de ejecución del join.

    El procesamiento de consultas tiene varias etapas a seguir para resolver una consulta SQL, las características del modelo relacional permiten que cada motor de base de datos elija su propia representación que, comúnmente, resulta ser el álgebra relacional. La optimización de consultas es, entonces, una de estas etapas.

    Existen distintos métodos para optimizar consultas relacionales, sin embargo el enfoque de optimización basada en costos combinado con heurísticas que permitan reducir el espacio de búsqueda de la solución es el método mayormente utilizado por los motores de base de datos relaciones de la actualidad, en todo caso, independiente del método elegido para optimizar la consulta, la salida de este proceso debe ser un plan de ejecución, el cual comúnmente es representado en su forma de árbol relacional.


    1.5. Manejo de transacciones.

     

    Una transacción en un Sistema de Gestión de Bases de Datos (SGBD), es un conjunto de órdenes que se ejecutan formando una unidad de trabajo, es decir, en forma indivisible o atómica.
    Un SGBD se dice transaccional, si es capaz de mantener la integridad de los datos, haciendo que estas transacciones no puedan finalizar en un estado intermedio. Cuando por alguna causa el sistema debe cancelar la transacción, empieza a deshacer las órdenes ejecutadas hasta dejar la base de datos en su estado inicial (llamado punto de integridad), como si la orden de la transacción nunca se hubiese realizado.
    Para esto, el lenguaje de consulta de datos SQL (Structured Query Language), provee los mecanismos para especificar que un conjunto de acciones deben constituir una transacción.
    • BEGIN TRAN: Especifica que va a empezar una transacción.
    • COMMIT TRAN: Le indica al motor que puede considerar la transacción completada con éxito.
    • ROLLBACK TRAN: Indica que se ha alcanzado un fallo y que debe restablecer la base al punto de integridad.
    En un sistema ideal, las transacciones deberían garantizar todas las propiedades ACID; en la práctica, a veces alguna de estas propiedades se simplifica o debilita con vistas a obtener un mejor rendimiento.
    Un ejemplo de transacción
    Un ejemplo habitual de transacción es el traspaso de una cantidad de dinero entre cuentas bancarias. Normalmente se realiza mediante dos operaciones distintas, una en la que se decremento el saldo de la cuenta origen y otra en la que incrementamos el saldo de la cuenta destino. Para garantizar la atomicidad del sistema (es decir, para que no aparezca o desaparezca dinero), las dos operaciones deben ser atómicas, es decir, el sistema debe garantizar que, bajo cualquier circunstancia (incluso una caída del sistema), el resultado final es que, o bien se han realizado las dos operaciones, o bien no se ha realizado ninguna.
    Estructura de las transacciones
    La estructura de una transacción usualmente viene dada según el modelo de la transacción, estas pueden ser planas (simples) o anidadas.
    Transacciones planas: Consisten en una secuencia de operaciones primitivas encerradas entre las palabras clave BEGIN y END. Por ejemplo:
    5
                BEGIN _TRANSACTION Reservación
                  ….
                 END.
    Transacciones Anidadas: Consiste en tener transacciones que dependen de otras, estas transacciones están incluidas dentro de otras de un nivel superior y se las conoce como subtransacciones. La transacción de nivel superior puede producir hijos (subtransacciones) que hagan más fácil la programación del sistema y mejoras del desempeño.
    En las transacciones anidadas las operaciones de una transacción pueden ser así mismo otras transacciones. Por ejemplo:

    Una transacción anidada dentro de otra conserva las mismas propiedades que las de su padre, esto implica, que puede contener así mismo transacciones dentro de ella. Existen restricciones obvias en una transacción anidada: debe empezar después que su padre y debe terminar antes que él. El compromiso de una subtransaccion es condicional al compromiso de su padre, si el padre de una o varias subtransacciones aborta, las subtransacciones hijas también serán abortadas. Las transacciones anidadas brindan un nivel más alto de concurrencia entre transacciones. Ya que una transacción consiste de varias transacciones es posible tener mayor concurrencia dentro de una sola transacción.
    Así también, es posible recuperarse de fallas de forma independiente de cada sub transacción. Esto limita el daño a una parte más pequeña de la transacción, haciendo que el costo de la recuperación sea el menor.
    También se deben considerar el orden de las lecturas y escrituras. Si las acciones de lectura y escritura pueden ser mezcladas sin ninguna restricción, entonces, a este tipo de transacciones se les conoce como Generales .Por el contrario, si se restringe o impone que un dato debe ser leído antes de que pueda ser escrito entonces se tendrán transacciones Restringidas. Si las transacciones son restringidas a que todas las acciones de lectura se realicen antes de las acciones de escritura entonces se les conoce como de Dos Pasos. Finalmente existe un modelo de acción para transacciones restringidas en donde se aplica aún más la restricción de que cada par < read, write > tiene que ser ejecutado de manera atómica.
    Operaciones de una transacción
    • Inicio de Transacción: Operación que marca el momento en el que una transacción comienza a ejecutarse.
    • Leer o Escribir: Operaciones de lectura/escritura de elementos de la base de datos.
    • Fin de la Transacción: Se verifica si la transacción debe abortarse por alguna razón.
    • Confirmar (COMMIT): La operación termino con éxito.
    • Abortar (ROLLBACK): La transacción termino sin éxito.

    Estados de una Transacción
    • Transacción Activa: se encuentra en este estado justo después de iniciar su ejecución.
    • Transacción Parcialmente Confirmada: en este punto, se efectúan diferentes operaciones de verificación para asegurar que la transacción no interfiera con otras transacciones en ejecución.
    • Transacción Confirmada: Ha concluido su ejecución con éxito.
    • Transacción Fallida: En este caso, es posible que la transacción deba ser cancelada.
    • Transacción Terminada: indica que la transacción ha abandonado el sistema.
    • Representación de los estados de una transacción
    6
    Problemas de concurrencia 
    La concurrencia es un fenómeno que se presenta en varios contextos. Uno de ellos es la multiprogramación ya que el tiempo del procesador es compartido dinámicamente por varios procesos. Otro caso son las aplicaciones estructuradas, donde la programación estructurada se implementa como un conjunto de procesos concurrentes. Y por último se tiene que la misma estructuración recién mencionada es utilizada en el diseño de los sistemas operativos, los cuales se implementan como un conjunto de procesos.
    El termino concurrencia se refiere al hecho de que los DBMS (SISTEMAS DE ADMINISTRACION DE BD) permiten que muchas transacciones puedan accesar a una misma base de datos a la vez.
    En un sistema de estos se necesitan algún tipo de mecanismos de control de concurrencia para asegurar que las transacciones concurrentes no interfieran entre sí.
    En sistemas multiusuario, es necesario un mecanismo para controlar la concurrencia. Se pueden producir inconsistencias importantes derivadas del acceso concurrente, como por ejemplo, el problema de la operación perdida.
    En un sistema de biblioteca, existe un campo que almacena el número de copias disponibles para préstamo. Este campo debe incrementarse en uno cada vez que se devuelve un ejemplar del libro y disminuirse en uno cada vez que se presta un ejemplar.
    Si existen varias bibliotecarias, una de ellas inicia la transacción t1, leyendo la variable numero ejemplares (n), cuyo contenido se guarda en la variable n1. Tiempo después, otra bibliotecaria podría leer la misma variable incrementándola en una unidad, transacción t2. Después, la transacción t1 añade una unidad a esa variable y la actualiza, el resultado es erróneo, ya que la variable N debería haber aumentado en 2 unidades, y solo ha aumentado en una. La transacción t2 se ha perdido
    CONFIABILIDAD
    Se debe de tener la certeza de que un sistema en línea no puede fallar dado que si existe algún error en nuestro algoritmo ocasionaría no solo que se estropeara una operación, pueden significar estos errores perdidas económicas bastante grandes, para que nuestro sistema de bases de datos sea confiable se tienen que tener probadas todas las posibles operaciones que se pueden realizar en el para simular una transacción de un cliente en un tiempo determinado.

No hay comentarios.:

Publicar un comentario