BASE DE DATOS DISTRIBUIDAS (EJERCICIO DE APLICACIÓN)

ENRIQUE ALCOCER DANIEL OCHOA

PROFESORJOHN JAIRO LONDOÑO

UNIVERSIDAD DISTRITAL FRANCISO JOSÉ DE CALDASBASE DE DATOS

BOGOTA2014

BASES DE DATOS DISTRIBUIDAS

Un sistema distribuido de bases de datos, almacena la información en varios computadores y varios medios de comunicación como las redes de alta velocidad son las encargadas de poner contacto los distintos computadores de un sistema distribuido. Estos no comparten recursos físicos como memorias y discos, además pueden variar en tamaño y función pudiendo abarcar desde las estaciones de trabajo hasta grandes sistemas.

Dependiendo del contexto en el que se mencionen existen diferentes nombres para referirse a los computadores que forman parte de un sistema distribuido, tales como sitios o nodos. Para enfatizar la distribución física de estos sistemas se usa principalmente el término sitio. En la siguiente figura se muestra la estructura general de un sistema distribuido:

FRAGMENTACIÓN

El diseño de la fragmentación es conocido como una característica distintiva de las bases de datos distribuidas y hace referencia a la fragmentación o divisiones lógicas de una relación global. La fragmentación en un sistema de base de datos distribuido determina como serán subdivididas las relaciones propias de las tablas diseño de la base de datos, ya sean de manea horizontal, vertical o mixta (una combinación de horizontal y vertical).

Al diseñar una fragmentación en un sistema distribuido se debe cumplir con las siguientes reglas: Todos los datos de la relación global deberán ser mapeados a algún fragmento Debe ser siempre posible reconstruir la relación global a partir de sus fragmentos Es conveniente que los fragmentos sean disjuntos (nada en común).

Fragmentos: Cada relación global puede ser dividida en porciones llamados fragmentos. El mapa resultante se denomina esquema de fragmentación. Una relación global puede dividirse en n fragmentos y un fragmento sólo puede pertenecer a una relación global. Los fragmentos se referencian por un nombre de relación global y un subíndice.

FRAGMENTACIÓN HORIZONTAL.

Se realiza sobre las tuplas de la relación, es decir que cada fragmento será un subconjunto de las tuplas de la relación. Una tabla T se divide en subconjuntos, T1, T2,...Tn. Los fragmentos se definen mediante una operación de selección. Su reconstrucción se realizará mediante la unión de los fragmentos componentes.

Existen dos tipos de fragmentación como es: fragmentación horizontal primaria y la fragmentación horizontal derivada.

La fragmentación horizontal primaria. Consiste en particionar las tuplas de una relación global en subconjuntos, donde cada subconjunto tenga propiedades comunes, se puede definir expresando cada fragmento como una operación de selección sobre la relación global.

La fragmentación horizontal derivada Consiste en dividir una relación partiendo de los predicados definidos sobre alguna otra, debido a que la relación R depende de la relación Q, sobre cuyos atributos está definido el predicado de la fragmentación.

Las tres entradas necesarias para desarrollar la fragmentación horizontal derivada son las siguientes: el conjunto de particiones de la relación propietaria, la relación miembro y el conjunto de predicados resultados de aplicar el semi−yunto entre la propietaria y la miembro. Es decir La fragmentación de la tabla primaria, se aplica a tablas secundarias, o bien se debe partir de una fragmentación horizontal primaria.

Nota: La relación al final de la conexión es llamada propietario de la conexión y la relación que está en la cabeza de la conexión es llamada miembro.

FRAGMENTACIÓN VERTICAL.

El objetivo de la fragmentación vertical consiste en dividir la relación en un conjunto de relaciones más pequeñas tal que algunas de las aplicaciones de usuario sólo hagan uso de un fragmento. Sobre este marco, una fragmentación óptima es aquella que produce un esquema de división que minimiza el tiempo de ejecución de las aplicaciones que emplean esos fragmentos.

La fragmentación vertical se basa en los atributos de la relación para realizar la división, es decir: la subdivisión de atributos en grupos. La fragmentación es correcta si cada atributo se mapea en al menos un atributo del fragmento.

La partición vertical resulta más complicada que la horizontal. Esto se debe al aumento del número total de alternativas que tenemos disponibles.

Existen dos enfoques heurísticos para la fragmentación vertical de relaciones:

Agrupación: Comienza asignando cada atributo a un fragmento, y en cada paso, junta algunos de los fragmentos hasta que satisface un determinado criterio. La agrupación sugirió en principio para bases de datos centralizadas y se usó posteriormente para las bases de datos distribuidas.

Escisión: A partir de la relación se deciden que fragmentos resultan mejores, basándose en las características de acceso de las aplicaciones a los atributos. Esta técnica se presentó, también, para bases de datos centralizadas. Posteriormente, se extendió al entorno distribuido.

La escisión genera fragmentos no solapados mientras que la agrupación normalmente produce fragmentos solapados. Dentro del contexto de los sistemas de bases de datos distribuidos, son preferibles los fragmentos no solapados por obvias razones. Los fragmentos no solapados se refieren únicamente a atributos clave no primarios.

Ejemplo de aplicación de base datos distribuidos:

MODELO BDD

Relación de Fragmentación Horizontal y Fragmentación Vertical al modelo:La Fragmentación Horizontal se puede ver en el modelo anterior en las tablas de transacciones, tabla de transacciones de la base de datos nativa y la tabla de transacciones foráneo, estas tablas están fragmentadas por la ciudad. No hay evidencias de la Fragmentación Vertical en este modelo.

Desarrollo del ejercicio el motor de base de datos MySQL:

Se crean tres bases de datos, de las cuales dos tienen el mismo diseño para las sucursales de Bogotá y Medellín (banco_bogota, banco_medellin) y una del Data center (datacenter).

Se maneja 2 ciudades en cada base de datos de bancos (1-Bogotá, 2-Medellin):

Se manejan 2 tipos de transacciones en cada base de datos de bancos (1-Retiro, 2- Abono).

Se inserta una cuenta en la base de datos de Bogotá con un saldo de $500000:

Se inserta una cuenta en la base de datos de Medellín con un saldo de $1000000:

Se insertan las 2 cuentas en la base de datos del DataCenter:

Se inserta un registro a la tabla de transacciones foráneas de Bogotá de una transacción de retiro de $200000 realizada por el cliente de Medellín:

Se actualiza el saldo en la tabla de cuentas del Datacenter para el cliente de Medellín cobrando el valor de la transacción que son $10000, por lo tanto el saldo

queda así:$1000000 - $200000 - $10000=$790000

Se inserta un registro a la tabla de transacciones foráneas de Medellín de una transacción de abono de $100000 realizada por el cliente de Bogotá:

Se actualiza el saldo en la tabla de cuentas del Datacenter para el cliente de Bogotá cobrando el valor de la transacción que son $10000, por lo tanto el saldo queda así:$500000 + $100000 - $10000=$590000

Se ejecuta el procedimiento almacenado motor_distribución:Definición:CREATE DEFINER=`root`@`localhost` PROCEDURE `motor_distribucion`()MODIFIES SQL DATABLOCK1: BEGIN

DECLARE doneBogota INT DEFAULT 0; DECLARE MEDELLIN INT DEFAULT 2;DECLARE cuentab, cuentamvarchar(20); DECLARE valorbBIGINT(20);DECLARE tipob INT; DECLARE fechab TIMESTAMP; DECLARE ciudadb INT;DECLARE curBogota CURSOR FOR SELECT cuenta, valor, tipo, fecha, ciudad FROM banco_bogota.transaccion_foranea WHERE fecha=CURDATE();DECLARE CONTINUE HANDLER FOR SQLSTATE '02000' SET doneBogota = 1;

OPEN curBogota; /*transaccionesforeanes de bogota*/ REPEAT FETCH curBogota INTO cuentab, valorb, tipob, fechab, ciudadb;IF NOT doneBogota THEN /*ciudad de medellin*/IF ciudadb=MEDELLIN THEN/*se almacena un registro en transacciones de medellin*/ INSERT INTO banco_medellin.transaccion(cuenta, valor, tipo, fecha) VALUES (cuentab, valorb, tipob, fechab);

/*se actualiza el saldo para la cuenta de medellin*/ UPDATE banco_medellin.cuenta_cliente mcc SET mcc.saldo = ( SELECTdcc.saldo FROM datacenter.cuenta_cliente dcc WHERE dcc.cuenta = cuentab) WHERE mcc.num = cuentab; /*se almacena el registro de la transaccion*/ INSERT INTO auditoria(cuenta, valor, tipo, fecha, ciudad) VALUES (cuentab, valorb, tipob, CURDATE(), ciudadb); END IF; END IF; UNTIL doneBogota END REPEAT; CLOSE curBogota;

BLOCK2: BEGIN DECLARE doneMedellin INT DEFAULT 0;

DECLARE cuentab, cuentamvarchar(20); DECLARE valormBIGINT(20);

DECLARE tipom INT; DECLARE fecham TIMESTAMP;DECLARE ciudadm INT; DECLARE BOGOTA INT DEFAULT 1;DECLARE curMedellin CURSOR FOR SELECT cuenta, valor, tipo, fecha, ciudad FROM banco_medellin.transaccion_foranea WHERE fecha=CURDATE();DECLARE CONTINUE HANDLER FOR SQLSTATE '02000' SET doneMedellin = 1;

OPEN curMedellin;

/*transaccionesforeanes de medellin*/REPEAT FETCH curmedellin INTO cuentam, valorm, tipom, fecham, ciudadm;IF NOT doneMedellin THEN/*ciudad de bogota*/ IF ciudadm=BOGOTA THEN/*se almacena un registro en transacciones de bogota*/ INSERT INTO banco_bogota.transaccion(cuenta, valor, tipo, fecha) VALUES (cuentam, valorm, tipom, fecham); /*se actualiza el saldo para la cuenta de bogota*/ UPDATE banco_bogota.cuenta_clientebcc SET bcc.saldo = ( SELECTdcc.saldo FROM datacenter.cuenta_cliente dcc WHERE dcc.cuenta = cuentam) WHERE bcc.num = cuentam; /*se almacena el registro de la transaccion*/ INSERT INTO auditoria(cuenta, valor, tipo, fecha, ciudad) VALUES (cuentam, valorm, tipom, CURDATE(), ciudadm); END IF; END IF; UNTIL doneMedellin END REPEAT; CLOSE curMedellin;END Block2;END Block1

El procedimiento se ejecuta sin problemas:

Se Verifica la tabla de transacciones de la base de datos del banco de Bogotá y se verifica que se registró la transacción realizada desde Medellín:

Se Verifica el saldo del cliente de Bogotá de la base de datos del banco de Bogotá:

Se verifica la tabla de transacciones de la base de datos del banco de Medellín y se verifica que se registró la transacción realizada desde Bogotá:

Se verifica el saldo del cliente de Medellín de la base de datos del banco de Medellín:

Verificamos que se hayan almacenado los registros de que se realizó las transaccciones en la tabla Auditoria del DataCenter: