DISEÑO DE BDD - copia

56
LA FRAGMENTACION DE LA BDD LOCALIZACION DE LOS FRAGMENTOS PROCESAMIENTO DISTRUBUIDO DE CONSULTAS MANEJO DE TRANSACCIONES CONTROL DE CONCURRENCIAS PRESENTA: MIYOSHI ESPINOZA MARTINEZ DISEÑO DE UNA BASE DE DATOS DISTRIBUIDA

Transcript of DISEÑO DE BDD - copia

Page 1: DISEÑO DE BDD - copia

LA FRAGMENTACION DE LA BDDLOCALIZACION DE LOS FRAGMENTOSPROCESAMIENTO DISTRUBUIDO DE CONSULTASMANEJO DE TRANSACCIONES CONTROL DE CONCURRENCIAS

PRESENTA:MIYOSHI ESPINOZA MARTINEZ

DISEÑO DE UNA BASE DE DATOS DISTRIBUIDA

Page 2: DISEÑO DE BDD - copia

DISEÑO DE UNA BDD

INTRODUCCION

El problema de diseño de bases de datos distribuidos se refiere, en general, a hacer decisiones acerca de la ubicación de datos y programas a través de los diferentes sitios de una red de computadoras.

La decisión de donde colocar a las aplicaciones tiene que ver tanto con el software del SMBDD como con las aplicaciones que se van a ejecutar sobre la base de datos.

2

Page 3: DISEÑO DE BDD - copia

El diseño de un sistema de base de datos distribuido implica la toma de decisiones sobre la ubicación de los programas que accederán a la base de datos y sobre los propios datos que constituyen esta última, a lo largo de los diferentes puestos que configuren una red de ordenadores.

La ubicación de los programas, a priori, no debería suponer un excesivo problema dado que se puede tener una copia de ellos en cada máquina de la red (de hecho, en este documento se asumirá que así es). Sin embargo, cuál es la mejor opción para colocar los datos: en una gran máquina que albergue a todos ellos, encargada de responder a todas las peticiones del resto de las estaciones – sistema de base de datos centralizado –, o podríamos pensar en repartir las relaciones, las tablas, por toda la red.

3

Page 4: DISEÑO DE BDD - copia

FRAGMENTACION DE LA BDD

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

4

Page 5: DISEÑO DE BDD - copia

La fragmentación es la forma en cómo se pueden extraer los datos al ser consultados en un Ambiente distribuido, se puede hacer una fragmentación de distintas tablas pertenecientes a diversas Bases de Datos localizadas en diversos servidores.

Existen tres tipos de fragmentación:

Fragmentación horizontal.

Fragmentación vertical.

Fragmentación híbrida

5

Page 6: DISEÑO DE BDD - copia

Fragmentación horizontalFragmentar significa tomar datos lógicamente de una tabla

para formar otro.

La fragmentación horizontal se realiza sobre las tuplas de la

relación, cada fragmento que se toma será un subconjunto de

las tuplas de la relación.

6

Page 7: DISEÑO DE BDD - copia

Una tabla T se divide en subconjuntos, T1, T2, ...Tn. Los fragmentos se definen a través de una operación de selección y su reconstrucción se realizará con una operación de unión de los fragmentos componentes.

Cada fragmento se sitúa en un nodo.Pueden existir fragmentos no disjuntos: combinación de

fragmentación y replicación.

7

Page 8: DISEÑO DE BDD - copia

Fragmentación horizontal: Ejemplo.

•Tabla Inicial de los alumnos de la UPM (T)

8

Page 9: DISEÑO DE BDD - copia

Fragmento de la EUI: σEscuela="EUI"(T)

Fragmento de la EUI: σEscuela="EUI"(T)

9

Page 10: DISEÑO DE BDD - copia

Existen dos variantes de la fragmentación horizontal;

la primaria derivada.

La fragmentación horizontal primaria de una relación se

desarrolla empleando los predicados definidos en esa relación.

La fragmentación horizontal derivada consiste en dividir en una

relación partiendo de los predicados definidos sobre alguna otra.

10

Page 11: DISEÑO DE BDD - copia

Información necesaria para la fragmentación horizontal

Esta información implica al esquema conceptual global. Es

importante señalar como las relaciones de las bases de datos se

conectan con otras.

Es una conexión de relaciones normalmente se denominan relación

propietaria, a aquella situada en la cola del enlace, mientras que se

llama relación miembro a la ubicada en la cabeza del vinculo.

11

Page 12: DISEÑO DE BDD - copia

La fragmentación vertical

Ha sido estudiada principalmente dentro del contexto de los sistemas de

manejo de bases de datos centralizados como una herramienta de diseño,

la cual permite que las consultas de usuario traten con relaciones más

pequeñas haciendo, por tanto, un número menor de accesos a páginas.

Es inherentemente más complicada que particionamiento horizontal ya que

existe un gran número de alternativas para realizarla. Por lo tanto, se

utilizan heurísticas para hacer el particionamiento.

12

Page 13: DISEÑO DE BDD - copia

Una tabla T se divide en subconjuntos, T1, T2, ...Tn. Los fragmentos se definen a través de una operación de proyección.

Cada fragmento debe incluir la clave primaria de la tabla. Su reconstrucción se realizará con una operación de join de los fragmentos componentes.

Cada fragmento se sitúa en un nodo.Pueden existir fragmentos no disjuntos: combinación de

fragmentación y replicación.

13

Page 14: DISEÑO DE BDD - copia

Departamento infraestructura

Departamento ordenación académica

Datos Rectorado (R)

ΠEscuela, Número_alumnos(R)

ΠEscuela,Situación(R)

Fragmentación vertical: Ejemplo.

14

Page 15: DISEÑO DE BDD - copia

Información necesaria para la fragmentación vertical

Se refiere a las aplicaciones por tanto, este punto trata de especificar la

información de una aplicación que funciona sobre la base de datos,

podemos extraer teniendo en cuenta que la fragmentación vertical coloca

un fragmento de aquellos atributos a los que accede de forma

simultanea, necesitaremos alguna medida que defina con mas precisión

el concepto de simultaneidad.

Esta medida es la afinidad de los atributos que indican la relación

estrecha existente entre los atributos. No es muy realista esperar valores

por ello una forma para la cual obtengamos esos valores partiendo de

datos más básicos.

15

Page 16: DISEÑO DE BDD - copia

La fragmentación mixta o híbrida

En muchos casos la fragmentación vertical u horizontal del esquema de la base de datos no será suficiente para satisfacer los requisitos de las aplicaciones. Como ya se citó al comienzo de este documento podemos combinar ambas, utilizando por ello la denominada fragmentación mixta. Cuando al proceso de fragmentación vertical le sigue una horizontal, es decir, se fragmentan horizontalmente los fragmentos verticales resultantes, se habla de la fragmentación mixta HV. En el caso contrario, estaremos ante una fragmentación VH. Una característica común a ambas es la generación de árboles que representan la estructura de fragmentación.

16

Page 17: DISEÑO DE BDD - copia

ΠDNI,Escuela,Escuela,Nombre,Beca(E)

Secretaría

ΠDNI,Escuela,Nombre,Notaingreso(E)

Datos EUI (E)

Jefatura estudios

17

Fragmentación híbrida: Ejemplo.

Page 18: DISEÑO DE BDD - copia

LOCALIZACION DE LOS FRAGMENTOS

Si el sistema es transparente en cuanto a repetición y fragmentación, se ocultará al usuario gran parte del esquema de la base de datos distribuida. Sin embargo, el componente de los nombres que identifican a la localidad obliga al usuario a darse cuenta del hecho de que cl sistema está distribuido.

La transparencia de localización se logra creando un conjunto de seudónimos o alias para cada usuario. Así, el usuario puede referirse a los datos usando nombres sencillos que el sistema traduce a nombres completos.

Con el uso de seudónimos, no será necesario que el usuario conozca la localización física de un dato. Además,el administrador de la base de datos puede cambiar un dato de una localidad a otra sin afectar a los usuarios.

18

Page 19: DISEÑO DE BDD - copia

PROCESAMIENTO DISTRIBUIDO DE CONSULTAS

Las consultas distribuidas detienen acceso a datos de varios orígenes

de datos heterogéneos. Estos orígenes de datos pueden estar

almacenados en el mismo equipo o en equipos diferentes.

Los usuarios de SQL SERVER pueden utilizar consultas distribuidas

para obtener acceso a lo siguiente:

Datos distribuidos almacenados en varias estancias de SQL

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

relacionales y no relacionales a los que se obtienen acceso mediante

un proveedor OLE BD.

19

Page 20: DISEÑO DE BDD - copia

Se estudia el coste de las comunicaciones.

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

Optimización mediante operación de semijoin.

20

Page 21: DISEÑO DE BDD - copia

Ejemplo de consulta distribuida

Nodo1:EMPLEADO

10.000 tuplas. Cada tupla tiene 100 bytes de longitud.

El campo COD tiene 9 bytes de longitud.

El campo Dpto tiene 4 bytes de longitud.

El campo Nombre tiene 15 bytes de longitud.

El campo Apellido tiene 15 bytes de longitud.

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

Nombre Apellido COD Dir Sexo Suelo Fecha nac. Depto.

21

Page 22: DISEÑO DE BDD - copia

Ejemplo de consulta distribuida

NODO2:DEPARTAMENTO

100 tuplas.

Cada tuplatiene 35 bytes de longitud.

El campo NombreDptotiene 10 bytes de longitud.

El campo NDptotiene 4 bytes de longitud.

El campo Responsable tiene 9 bytes de longitud.

Tamaño de la relación: 35 * 100 = 3500 bytes

NombreDpto NDpto Responsable Edificio

22

Page 23: DISEÑO DE BDD - copia

Estrategias de procesamiento de consultas

distribuidas

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.

23

Page 24: DISEÑO DE BDD - copia

En un sistema distribuido es preciso tener en cuenta

otros factores como son:

El costo de transmisión de datos en la red.

Repetición y fragmentación.

Procesamiento de intersección simple.

24

Page 25: DISEÑO DE BDD - copia

Árboles de consultas

Parsing y traducción de la

consulta.

Optimización.

Generación de código.

Ejecución de la consulta.

25

Page 26: DISEÑO DE BDD - copia

Transformaciones equivalentes

Cuando una base de datos se encuentra en múltiples servidores y

distribuye a un número determinado de nodos tenemos:

El servidor recibe una petición de un nodo.

El servidor es atacado por el acceso concurrente a la base de datos

cargada localmente.

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

maquinas nodo de la red local.

26

Page 27: DISEÑO DE BDD - copia

Métodos de ejecución del Join

Existen diferentes algoritmos que pueden obtener transformaciones eficientes en

el procesamiento de consultas.

Join en bucles (ciclos) anidados

Join en bucles anidados por bloques

Join por mezcla

Join por asociación.

Join por asociación híbrida

Join Complejos

Outer Join (Join externos)

27

Page 28: DISEÑO DE BDD - copia

Join en bucles (ciclos) anidados

Si z = r s, r recibirá el nombre de relación externa y s se llamará relación

interna, el algoritmo de bucles anidados se puede presentar como sigue:

Para cada tupla tr en s si (tr,ts) si satisface la condición, entonces añadir tr * ts

al resultado Donde tr * ts será la concatenación de las tuplas tr y ts. Como para

cada registro de r se tiene que realizar una exploración completa de ts, y

suponiendo el peor caso, en el cual la memoria intermedia sólo puede

concatenar un bloque de cada relación, entonces el número de bloques a

acceder es de sr bn b.

28

Page 29: DISEÑO DE BDD - copia

Join en bucles anidados por bloques

Una variante del algoritmo anterior puede lograr un ahorro en el acceso a

bloques, si se procesan las relaciones por bloques en vez de por tuplas.

Para cada bloque Br dar a igual para cada bloque Bs de s, para cada tupla

tr en Br.

La diferencia principal en costos de este algoritmo con el anterior es que en

el peor de los casos cada bloque de la relación interna s se lee una vez por

cada bloque de dr y no por cada tupla de la relación externa.

29

Page 30: DISEÑO DE BDD - copia

Join por mezcla

Este algoritmo se puede utilizar para calcular si un Join natural es óptimo en la

búsqueda o consulta. Para tales efectos, ambas relaciones deben estar

ordenadas para los atributos en común es decir se asocia un puntero a cada

relación, al principio estos punteros apuntan al inicio de cada una de las

relaciones.

Según avance el algoritmo el puntero se mueve a través de la relación. De este

modo se leen en memoria un grupo de tuplas de una relación con el mismo valor

en los atributos de las relaciones.

30

Page 31: DISEÑO DE BDD - copia

Join por asociación.

Al igual que el algoritmo de join por mezcla, el algoritmo de join por asociación se puede

utilizar para un Join natural o un equi-join. Este algoritmo utiliza una función de asociación

h para dividir las tuplas de ambas relaciones. La idea fundamental es dividir las tuplas de

cada relación en conjuntos con el mismo valor de la función de asociación en los atributos

de join.

El número de bloques ocupados por las particiones podría ser ligeramente mayor que.

Debido a que los bloques no están completamente llenos. El acceso a estos bloques

puede añadir un gasto adicional de 2·max a lo sumo, ya que cada una de las particiones

podría tener un bloque parcialmente ocupado que se tiene que leer y escribir de nuevo.

31

Page 32: DISEÑO DE BDD - copia

Join por asociación híbrida

El algoritmo de Join por asociación híbrida realiza otra optimización; es

útil cuando el tamaño de la memoria es relativamente grande pero aún

así, no cabe toda la relación s en memoria. Dado que el algoritmo de Join

por asociación necesita max +1 bloques de memoria para dividir ambas

relaciones se puede utilizar el resto de la memoria (M – max – 1 bloques)

para guardar en la memoria intermedia la primera partición de la relación

s, esto es, así no es necesaria leerla ni escribirla nuevamente y se puede

construir un índice asociativo.

32

Page 33: DISEÑO DE BDD - copia

Join Complejos

Los Join en bucle anidado y en bucle anidado por bloques son útiles siempre, sin

embargo, las otras técnicas de Join son más eficientes que estas, pero sólo se

pueden utilizar en condiciones particulares tales como Join natural o equi-Join. Se

pueden implementar Join con condiciones más complejas tales como conjunción

o disyunción Dado un Join de las forma se pueden aplicar una o más de las

técnicas de Join descritas anteriormente en cada condición individual, el resultado

total consiste en las tuplas del resultado intermedio que satisfacen el resto de las

condiciones. Estas condiciones se pueden ir comprobado según se generen las

tuplas. La implementación de la disyunción es homóloga a la conjunción.

33

Page 34: DISEÑO DE BDD - copia

Outer Join (Join externos)

Un outer Join es una extensión del operador Join que se utiliza a menudo

para trabajar con la información que falta.

Optimización de consultas

El objetivo del procesamiento de consultas en un ambiente distribuido es

transformar una consulta sobre una base de datos distribuida en una

especificación de alto nivel a una estrategia de ejecución eficiente

expresada en un lenguaje de bajo nivel sobre bases de datos locales.

34

Page 35: DISEÑO DE BDD - copia

El problema de optimización de consultas es minimizar una función de costo tal que función de costo total = costo de I/O + costo de CPU + costo de comunicación.

35

Page 36: DISEÑO DE BDD - copia

Optimización global de consultas

Optimización global es una consulta algebraica optimizada con

operación de comunicación incluida sobre los fragmentos.

Un aspecto importante de la optimización de consultas es el

ordenamiento de juntas, dado que algunas permutaciones de

juntas dentro de la consulta pueden conducir a un mejoramiento de

varios órdenes de magnitud.

36

Page 37: DISEÑO DE BDD - copia

Optimización local de consultas

El trabajo de la última capa se efectúa en todos los nodos con

fragmentos involucrados en la consulta. Cada consulta que se ejecuta en

un nodo, llamada consulta local, es optimizada usando el esquema local

del nodo. Hasta este momento, se eligen los algoritmos para realizar las

operaciones relacionales. La optimización local utiliza los algoritmos de

sistemas centralizados.

37

Page 38: DISEÑO DE BDD - copia

MANEJO DE TRANSACCIONES

Transacciones

Es un conjunto de acciones llevadas a cabo por un usuario o un

programa de aplicación, que acceden o cambian el contenido de la

base de datos.

Es relativamente simple, aun que su manejo es mas complicado sobre

todo cuando hablamos de un ambiente distribuido. La cantidad de

transacciones que se ejecutan en una base de datos distribuida delimita

el proceso y la transacción así, como la velocidad de los datos .

38

Page 39: DISEÑO DE BDD - copia

Conceptos básicos:

Atomicidad.- Asegura que todos los efectos de la transacción en la B.D. o bien

ninguno de ellos.

Consistencia.- Si la B.D. es consistente inicialmente la ejecución de la transacción

deja la B.D. en su estado consistente.

Aislamiento.- asegura que la ejecución concurrente de transacciones estas estén

aisladas unas de otras, de tal manera que cada una tiene la intención de que

ninguna se ejecuta concurrentemente.

Durabilidad.- Una vez que una transacción se ha comprometido las actualizaciones

hechas para la transacción, no se pierden incluso si hay un fallo en el sistema.

39

Page 40: DISEÑO DE BDD - copia

Estructura de transacciones

La estructura de una transacción usualmente viene dada según el

modelo de la transacción, estas pueden ser planas (simples) o anidadas.

Transacciones planas.- Consisten de una secuencia de operaciones

primitivas encerradas entre las palabras clave begin y end.

40

Page 41: DISEÑO DE BDD - copia

Transacciones anidadas.- Consiste en tener transacciones que pueden ser de otras transacciones, están incluidas dentro de otras de un nivel superior que se les conoce como subtransacciones.

41

Page 42: DISEÑO DE BDD - copia

Ejecución de transacciones centralizada y distribuida

Consiste en una serie de modificaciones (transacciones) aun determinado

recurso del sistema (por ejemplo una base de datos) y en donde se define

un punto de inicio (Begin Tran) y un punto de terminación que define un

bloque entre el conjunto de operaciones que son realizadas.

Dentro de este proceso en bloque los demás usuarios no pueden

modificar nada hasta que no se presente un estado estable de los datos,

esto ocasiona inconsistencia temporal y conflictos.

42

Page 43: DISEÑO DE BDD - copia

Ejecutar transacciones serializadas.- Es un sistema que permite el procesamiento de transacciones en forma secuencial o serializado y consiste en asignarle una secuencia a cada transacción, este proceso reduce el rendimiento del sistema.

Ejecutar transacciones calendarizadas.- Es un sistema que permite el proceso de transacciones asignándole tiempos de procesamiento el cual permite incrementar el rendimiento del sistema ya que se ejecuta un máximo de proceso en forma concurrente y no a través de una serie.

43

Page 44: DISEÑO DE BDD - copia

CONTROL DE CONCURRENCIAS

El control de concurrencia trata con los problemas de aislamiento y

consistencia del procesamiento de transacciones.

El control de concurrencia distribuido de una DDBMS asegura que la

consistencia de la base de datos se mantiene en un ambiente distribuido

multiusuario.

Si las transacciones son internamente consistentes, la manera más

simple de lograr este objetivo es ejecutar cada transacción sola, una

después de otra.

44

Page 45: DISEÑO DE BDD - copia

Serialización de transacciones

Una canderilizacion ischedulel también llamado una historia se define un

conjunto de transacciones I= {T1,T2, TN} y especifican orden entrelazada

de la ejecución de las operaciones de las transacciones. La

canderilizacion puede ser especificada como una orden parcial sobre T.

45

Page 46: DISEÑO DE BDD - copia

Algoritmos de control de concurrencia

El criterio de clasificación más común de los algoritmos de control de concurrencia es

el tipo de primitiva de sincronización.

Esto resulta en dos clases:

Aquellos algoritmos que están basados en acceso mutuamente exclusivo a datos

compartidos (candados o bloqueos).

Aquellos que intentar ordenar la ejecución de las transacciones de acuerdo a un

conjunto de reglas (protocolos).

46

Page 47: DISEÑO DE BDD - copia

Basados en bloqueo

Existen diversos enfoques para complementar el gestor de bloqueos.

Gestión único de bloqueo.- El sistema conserva un único de bloqueos

que reside en un único emplazamiento a modo de todas las solicitudes

de bloqueo y desbloqueos se realizan sobre el. Cada transacción

solicita a esta localidad los bloqueos que necesita y luego, en caso de

lectura. La misma se realiza sobre cualquier copia, si es una escritura

se debe resolver sobre todas las copias.

47

Page 48: DISEÑO DE BDD - copia

Basados en estampas de tiempo

Los algoritmos basados en estampas de tiempo no pretenden mantener la

seriabilidad por exclusión mutua. En lugar de eso, ellos seleccionan un orden de

serialización a prioridad y ejecutan las transacciones, de acuerdo a ellas. Para

establecer este ordenamiento, el administrador de transacciones le asigna a

cada transacción T1 una estampa de tiempo única t1 (T1) cuando ésta inicia.

Una estampa de tiempo es un identificador simple que sirve para identificar cada

transacción de manera única.

48

Page 49: DISEÑO DE BDD - copia

Pruebas de validación optimistas

El protocolo mas reciente propuesta es el denominado optimista (OPT)

el cual acentúa la pertenencia general del sistema reduciendo el

bloqueo proveniente de aquellas transacciones que están preparadas

para terminar pero que aun no lo hicieron.

OPT comparte las mismas suposiciones que por este, las transacciones

tendieran a cometer si alcanzan el estado de parcialmente competidas.

49

Page 50: DISEÑO DE BDD - copia

Disciplinas del Interbloqueo: prevención, detección,

eliminación y recuperación

Interbloqueo.- Un esquema para resolver el interbloque en su detención.

Prevención.- Las técnicas de interbloqueo utilizan el concepto de marca

de tiempo de transacción existen dos esquemas que evitan el

interbloqueo.

Recuperación.- El objetivo de esta parte de la asignación es conocer y

entender las distintas fallas que pueden ocurrir en un BMS y como es

posible restaurar el sistema después de dichas fallas este tema se llama

recuperación de fallas.

50

Page 51: DISEÑO DE BDD - copia

Detención.- Existen diversos algoritmos para ello en la detención

de ciclos en el grafo de esperas, entre ellos:

Algoritmo 1.- Comprueba la existencia de ciclos mediante la

eliminación de nodos terminales.

Algoritmo 2.- Comprueba posibles ciclos desde la ultima

transacción bloqueada y marcando los nodos por lo que pasa. Si

pasa dos veces por el mismo nodo a detectado un ciclo.

51

Page 52: DISEÑO DE BDD - copia

Confiabilidad

La confiabilidad se refiere a la consistencia de los resultados.

Un sistema de manejo de base de datos confiables aquel que puede

continuar procesando las solicitudes de usuario aun cuando el sistema

sobre el que opera no es confiable en otras palabras, aun cuando los

componentes de un sistema distribuido fallen un DDMBS confiable debe

seguir ejecutándose las solicitudes de usuario sin violar la consistencia de

la base de datos.

52

Page 53: DISEÑO DE BDD - copia

Protocolos REDO/UNDO

La operación redo utiliza la información del registro de la base de datos y realiza

de nuevo las acciones que pueden haber sido realizadas antes de la falla, la

operación redo genera nueva imagen.

Por otra parte, es posible que el administrador del buffer haya realizado la

escritura en la base de datos volátil correspondiente debe de incluir datos

suficientes para permitir deshacer ciertas actualizaciones en el nuevo estado de

la base de datos y regresarla al estado anterior a esta operación se le conoce

como UNDO.

53

Page 54: DISEÑO DE BDD - copia

Puntos de verificación (checkpoints)

Cuando ocurre una falta en el sistema es necesario consultar la bitácora

para determinar cuales son las transacciones que necesitan para volver

hacerse cuando no necesiten hacerse.

Estos puntos de verificación nos ayudan para reducir el gasto de tiempo

consultando la bitácora. El punto de verificación en un registro que se

genera en la bitácora para concluir en todo lo que se encuentra antes de

ese punto esta correcto y verificado.

54

Page 55: DISEÑO DE BDD - copia

Protocolo 2PC de confiabilidad distribuida

Es un protocolo que consume un gran volumen de tiempo en la ejecución

de una transferencia durante el procesamiento normal se puede eliminar

accesos a disco o el numero de mensajes en el proceso de la transacción

la pertenencia 2pc podría ser mejorada.

El 2pc es conocido también como el protocolo “que no resume nada” para

que trata todas las transacciones de la misma forma sin importar si las

mismas cometen o abortan.

55

Page 56: DISEÑO DE BDD - copia

REFERENCIAS ELECTRÓNICAS

http://sacbeob.8m.com/tutoriales/bddistribuidas/index.htmhttp://www.cs.cinvestav.mx/SC/prof_personal/adiaz/

Disdb/Cap_1.html http://www.ingenieria.unam.mx/paginas/Carreras/

planes2010/Computacion/Bases_de_datos/bases_de_datos_distribuidas.pdf

http://www.slideshare.net/natalialuva/diseo-de-bases-de-datos-distribuidas

56