INSTITUTO TECNOLGICO SUPERIOR DE LA MONTAA

INFORMTICA

TEMA:
ENSAYO UNIDAD IV

DOCENTE:
ING. NOEL DOMINGUEZ CARDONA

ALUMNO:
LEONEL TIBURCIO GARCA

TLAPA DE COMONFORT, GUERRERO, A 18 DE ENERO DE 2012

NDCE

CONTENIDO Introduccin.1

Unidad 4 Manejo de transacciones.2 4.1 Transacciones.............2 4.1.1 Estructura de Transacciones..3 4.1.2 Ejecucin Transacciones Centralizada Distribuida.4 4.2 Control de Concurrencia.4 4.2.1 Serializaion de Transacciones5 4.2.2 Algoritmos de Control de Concurrencia5 4.2.2.1 Basados en Bloqueo.5 4.2.2.2 Basados en estampas de tiempo7 4.2.2.3 pruebas de validacin optimistas9 4.3 Confiabilidad...11 4.3.1 Conceptos bsicos de confiabilidad11 4.3.2 Protocolos REDO/UNDO..11 4.3.3 Puntos de verificacin (checkpoints)..12 4.3.4 Protocolo 2pc de confiabilidad distribuida..13 Conclusin Bibliografa

NTRODUCCON
La gran cantidad de avances e innovaciones tecnolgicas que se produjeron en los ltimos aos tuvieron como resultado un cambio en la forma de observar a los sistemas de informacin, en general a las aplicaciones computacionales. Existen avances tecnolgicos que se realizan de forma constante en dispositivos de almacenamiento, circuitos, programas y metodologas. Dichos avances van de la mano junto con la demanda de los usuarios y programas para la explotacin de dichos dispositivos mejorados. 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. A continuacin se muestra una parte de informacin relacionada con base de datos distribuidos en la cual se muestra los tipos de estrategias, las optimizaciones etc.

MANEJO DE TRANSACCONES

4.1 TRANSACCIONES 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. PROPIEDADES Las transacciones deben cumplir cuatro propiedades ACID: 1. Atomicidad (Atomicity): es la propiedad que asegura que la operacin se ha realizado o no, y por lo tanto ante un fallo del sistema no puede quedar a medias. 2. Consistencia (Consistency): es la propiedad que asegura que slo se empieza aquello que se puede acabar. Por lo tanto, se ejecutan aquellas operaciones que no van a romper la reglas y directrices de integridad de la base de datos. 3. Aislamiento (Isolation): es la propiedad que asegura que una operacin no puede afectar a otras. Esto asegura que la realizacin de dos transacciones sobre la misma informacin nunca generar ningn tipo de error. 4. Permanencia (Durability): es la propiedad que asegura que una vez realizada la operacin, sta persistir y no se podr deshacer aunque falle el sistema.

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. A continuacin se describir brevemente cada una de ellas. Transacciones planas: Consisten en 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 dependen de otras, estas transacciones estn incluidas dentro de otras de un nivel superior y se las conoce como subtransacciones. La transaccin de nivel superior puede producir hijos (subtransacciones) que hagan ms fcil la programacin del sistema y mejoras del desempeo. En estas las operaciones de una transaccin pueden ser as mismo otras transacciones. Por ejemplo: BEGIN _TRANSACTION Reservacin ......... BEGIN _TRANSACTION Vuelo ....... END.( Vuelo ) ...... BEGIN _TRANSACTION Hotel ........ END ...... END. Una transaccin 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 transaccin anidada: debe empezar despus que su padre y debe terminar antes que el. El compromiso de una subtransaccion es condicional al compromiso de su padre, si el padre de una o varias subtransacciones aborta, las subtransacciones hijas tambin sern abortadas. Las transacciones anidadas brindan un nivel mas alto de concurrencia entre transacciones. Ya que una transaccin consiste de varias transacciones es posible tener mayor concurrencia dentro de una sola transaccin.

Tambin se deben considerar el orden de las lecturas y escrituras. Si las acciones de lectura y escritura pueden ser mezcladas sin ninguna restriccin, entonces, a este tipo de transacciones se les conoce como Generales .Por el contrario, si se restringe o impone que un dato debe ser ledo antes de que pueda ser escrito entonces se tendrn transacciones Restringidas. Si las transacciones son restringidas a que todas las acciones de lectura se realicen antes de las acciones de escritura entonces se les conoce como de Dos Pasos. Finalmente existe un modelo de accin para transacciones restringidas en donde se aplica aun ms la restriccin de que cada par < read , write > tiene que ser ejecutado de manera atmica. 4.1.2 EJECUCIN DE TRANSACCIONES CENTRALIZADA Y DISTRIBUIDA
1. Ejecutar transacciones serializadas: Es un sistema que permite el procesamiento de transacciones en forma secuencial o serializado dndole una secuencia a cada transaccin, este proceso reduce el rendimiento del sistema, pero tiene como ventaja que el proceso de sincronizacin es ms sencillo. 2. Ejecutar transacciones calendarizadas: Permite el proceso de transacciones asignndoles tiempos de procesamiento el cual permite incrementar el rendimiento del sistema ya que se ejecuta un mximo de procesos en forma concurrente y no a travs de una serie. La ventaja es que a un mismo tiempo de reloj se pueden hacer dos operaciones, aunque el proceso de sincronizacin es ms complicado. Un aspecto muy importante en el manejo de transacciones es el de mantener y aplicar algoritmos de control sobre los datos o recursos; para ese control tambin se utilizan protocolos que proporcionen confiabilidad como lo siguientes: Atomicidad Protocolos de recuperacin total Protocolos de compromiso global

4.2 CONTROL DE CONCURRENCIA.

Los algoritmos de control de concurrencia pesimistas asumen que los conflictos entre transacciones son muy frecuentes y no permiten el acceso a un dato si existe una transaccin conflictiva que accesa el mismo dato. As, la ejecucin de cualquier operacin de una transaccin sigue la secuencia de fases: validacin, lectura, cmputo y escritura. Los algoritmos optimistas, por otra parte, retrasan la fase de validacin justo antes de la fase de escritura. De esta manera, una operacin sometida a un despachador optimista nunca es retrasada.

Las operaciones de lectura, cmputo y escritura de cada transaccin se procesan libremente sin actualizar la base de datos corriente. Cada transaccin inicialmente hace sus cambios en copias locales de los datos. La fase de validacin consiste en verificar si esas actualizaciones conservan la consistencia de la base de datos. Si la respuesta es positiva, los cambios se hacen globales (escritos en la base de datos corriente). De otra manera, la transaccin es abortada y tiene que reiniciar Lo que se hace es dejar ejecutar las transacciones y si al terminar se detecta que ha habido conflicto se aborta y se reinicia la transaccin.

4.2.1 SERIALIZACIN DE TRANSACCIONES. Una canderilizacion ischedulel tambin llamado una historia se define un conjunto de transacciones l= {T1, T2, TN} y especifican orden entrelazado de la ejecucin de las operaciones de las transacciones. La canderilizacin puede ser especificada como una orden parcial T. 4.2.2 ALGORITMOS DE CONTROL DE CONCURRENCIA. El criterio de clasificacin ms comn de los algoritmos de control de concurrencia es el tipo de primitiva de sincronizacin. Esto resulta en dos clases: aquellos algoritmos que estn basados en acceso mutuamente exclusivo a datos compartidos (candados) y aquellos que intentar ordenar la ejecucin de las transacciones de acuerdo a un conjunto de reglas (protocolos). Sin embargo, esas primitivas se pueden usar en algoritmos con dos puntos de vista diferentes: el punto de vista pesimista que considera que muchas transacciones tienen conflictos con otras, o el punto de vista optimista que supone que no se presentan muchos conflictos entre transacciones. Los algoritmos pesimistas sincronizan la ejecucin concurrente de las transacciones en su etapa inicial de su ciclo de ejecucin. Los algoritmos optimistas retrasan la sincronizacin de las transacciones hasta su terminacin. El grupo de algoritmos pesimistas consiste de algoritmos basados en candados, algoritmos basados en ordenamiento por estampas de tiempo y algoritmos hbridos. El grupo de los algoritmos optimistas se clasifican por basados en candados y basados en estampas de tiempo. 4.2.2.1 Basados en bloqueo. En los algoritmos basados en candados, las transacciones indican sus intenciones solicitando candados al despachador (llamado el administrador de candados). Los candados son de lectura (rl), tambin llamados compartidos, o de escritura (wl), tambin llamados exclusivos. Como se aprecia en la tabla

siguiente, los candados de lectura presentan conflictos con los candados de escritura, dado que las operaciones de lectura y escritura son incompatibles.

rl rl wl si no

wl no no

En sistemas basados en candados, el despachador es un administrador de candados (LM). El administrador de transacciones le pasa al administrador de candados la operacin sobre la base de datos (lectura o escritura) e informacin asociada, como por ejemplo el elemento de datos que es accesado y el identificador de la transaccin que est enviando la operacin a la base de datos. El administrador de candados verifica si el elemento de datos que se quiere accesar ya ha sido bloqueado por un candado. Si candado solicitado es incompatible con el candado con que el dato est bloqueado, entonces, la transaccin solicitante es retrasada. De otra forma, el candado se define sobre el dato en el modo deseado y la operacin a la base de datos es transferida al procesador de datos. El administrador de transacciones es informado luego sobre el resultado de la operacin. La terminacin de una transaccin libera todos los candados y se puede iniciar otra transaccin que estaba esperando el acceso al mismo dato. Candados de dos fases (2PL) En los candados de dos fases una transaccin le pone un candado a un objeto antes de usarlo. Cuando un objeto es bloqueado con un candado por otra transaccin, la transaccin solicitante debe esperar. Cuando una transaccin libera un candado, ya no puede solicitar ms candados. As una transaccin que utiliza candados de dos fases se comporta como en la Figura 6.2. En la primera fase solicita y adquiere todos los candados sobre los elementos que va a utilizar y en la segunda fase libera los candados obtenidos uno por uno. La importancia de los candados de dos fases es que se ha demostrado de manera terica que todos las calendarizaciones generadas por algoritmos de control de concurrencia que obedecen a los candados de dos fases son serializables. Puede suceder que si una transaccin aborta despus de liberar un candado, otras transacciones que hayan accesado el mismo elemento de datos aborten tambin provocando lo que se conoce como abortos en cascada. Para evitar lo anterior, los despachadores para candados de dos fases implementan lo que

se conoce como los candados estrictos de dos fases en los cuales se liberan todos los candados juntos cuando la transaccin termina (con commit o aborta).

4.2.2.2 Basados en estampas de tiempo. A diferencia de los algoritmos basados en candados, los algoritmos basados en estampas de tiempo no pretenden mantener la seriabilidad por exclusin mutua. En lugar de eso, ellos seleccionan un orden de serializacin a priori y ejecutan las transacciones de acuerdo a ellas. Para establecer este ordenamiento, el administrador de transacciones le asigna a cada transaccin Ti una estampa de tiempo nica ts( Ti ) cuando sta inicia. Una estampa de tiempo es un identificador simple que sirve para identificar cada transaccin de manera nica. Otra propiedad de las estampas de tiempo es la monoticidad, esto es, dos estampas de tiempo generadas por el mismo administrador de transacciones deben ser monotonicamente crecientes. As, las estampas de tiempo son valores derivados de un dominio totalmente ordenado. Existen varias formas en que las estampas de tiempo se pueden asignar. Un mtodo es usar un contador global monotonicamente creciente. Sin embargo, el mantenimiento de contadores globales es un problema en sistemas distribuidos. Por lo tanto, es preferible que cada nodo asigne de manera autnoma las estampas de tiempos basndose en un contador local. Para obtener la unicidad, cada nodo le agrega al contador su propio identificador. As, la estampa de tiempo es un par de la forma <contador local, identificador de nodo> Note que el identificador de nodo se agrega en la posicin menos significativa, de manera que, ste sirve solo en el caso en que dos nodos diferentes le asignen el mismo contador local a dos transacciones diferentes. El administrador de transacciones asigna tambin una estampa de tiempo a todas las operaciones solicitadas por una transaccin. Ms an, a cada elemento de datos x se le asigna una estampa de tiempo de escritura, wts(x), y una estampa de tiempo de lectura, rts(x); sus valores indican la estampa de tiempo ms grande para cualquier lectura y escritura de x, respectivamente. El ordenamiento de estampas de tiempo (TO) se realiza mediante la siguiente regla: Regla TO: dadas dos operaciones en conflicto, Oij y Okl, perteneciendo a las transacciones Ti y Tk, respectivamente, Oij es ejecutada antes de Okl, si y solamente si, ts(Ti) < ts(Tk). En

este caso Ti se dice ser un transaccin ms vieja y Tk se dice ser una transaccin ms joven.

Dado este orden, un conflicto entre operaciones se puede resolver de la siguiente forma: for Ri(x) do begin if ts(Ti) < wts( x ) then reject Ri(x) else accept Ri(x) rts(x) ts(Ti) end for Wi(x) do begin if ts(Ti) < rts(x) and ts(Ti) < wts(x) then reject Wi(x) else accept Wi(x) wts(x) ts(Ti) end La accin de rechazar una operacin, significa que la transaccin que la envi necesita reiniciarse para obtener la estampa de tiempo ms reciente del dato e intentar hacer nuevamente la operacin sobre el dato. Ordenamiento conservador por estampas de tiempo El ordenamiento bsico por estampas de tiempo trata de ejecutar una operacin tan pronto como se recibe una operacin. As, la ejecucin de las operaciones es progresiva pero pueden presentar muchos reinicios de transacciones. El ordenamiento conservador de estampas de tiempo retrasa cada operacin hasta que exista la seguridad de que no ser reiniciada. La forma de asegurar lo anterior es sabiendo que ninguna otra operacin con una estampa de tiempo menor puede llegar al despachador. Un problema que se puede presentar al retrasar las operaciones es que esto puede inducir la creacin de interbloqueos (deadlocks). Ordenamiento por estampas de tiempo mltiples Para prevenir la formacin de interbloqueos se puede seguir la estrategia siguiente. Al hacer una operacin de escritura, no se modifican los valores actuales sino se crean nuevos valores. As, puede haber copias mltiples de un

dato. Para crear copias nicas se siguen las siguientes estrategias de acuerdo al tipo de operacin de que se trate: 1. Una operacin de lectura Ri(x) se traduce a una operacin de lectura de x de una sola versin encontrando la versin de x, digamos xv, tal que, ts(xv) es la estampa de tiempo ms grande que tiene un valor menor a ts(Ti). 2. Una operacin de escritura Wi(x) se traduce en una sola version, Wi(xw), y es aceptada si el despachador no ha procesado cualquier lectura Rj(xr), tal que, ts(Ti) < ts(xr) < ts(Tj)

4.2.2.3 Pruebas de validacin optimistas. Los algoritmos de control de concurrencia discutidos antes son por naturaleza pesimistas. En otras palabras, ellos asumen que los conflictos entre transacciones son muy frecuentes y no permiten el acceso a un dato si existe una transaccin conflictiva que accesa el mismo dato. As, la ejecucin de cualquier operacin de una transaccin sigue la secuencia de fases: validacin (V), lectura (R), cmputo (C) y escritura (W). Los algoritmos optimistas, por otra parte, retrasan la fase de validacin justo antes de la fase de escritura. De esta manera, una operacin sometida a un despachador optimista nunca es retrasada. Las operaciones de lectura, cmputo y escrita de cada transaccin se procesan libremente sin actualizar la base de datos corriente. Cada transaccin inicialmente hace sus cambios en copias locales de los datos. La fase de validacin consiste en verificar si esas actualizaciones conservan la consistencia de la base de datos. Si la respuesta es positiva, los cambios se hacen globales (escritos en la base de datos corriente). De otra manera, la transaccin es abortada y tiene que reiniciar

Figura 1. Fases de la ejecucin de una transaccin a) pesimista, b) optimista.

Los mecanismos optimistas para control de concurrencia fueron propuestos originalmente con el uso de estampas de tiempo. Sin embargo, en este tipo de mecanismos las estampas de tiempo se asocian nicamente con las transacciones, no con los datos. Ms an, las estampas de tiempo no se asignan al inicio de una transaccin sino justamente al inicio de su fase de validacin. Esto se debe a que las estampas se requieren nicamente durante la fase de validacin. Cada transaccin Ti se subdivide en varias subtransacciones, cada una de las cuales se puede ejecutar en nodos diferentes. Sea Tij una subtransaccin de Ti que se ejecuta en el nodo j. Supongamos que las transacciones se ejecutan de manera independiente y ellas alcanzan el fin de sus fases de lectura. A todas las subtransacciones se les asigna una estampa de tiempo al final de su fase de lectura. Durante la fase de validacin se realiza una prueba de validacin, si una transaccin falla, todas las transacciones se rechazan. La prueba de validacin se realiza con una de las siguientes reglas: 1. Si todas las transacciones Tk, tales que, ts( Tk ) < ts( Tij ), han terminado su fase de escritura antes que Tij ha iniciado su fase de lectura entonces la validacin tiene xito. En este caso la ejecucin de las transacciones es completamente serial como se muestra en la Figura 6.7a. 2. Si existe alguna transaccin Tk, tal que, ts( Tk ) < ts( Tij ) y la cual completa su fase de escritura mientras Tij est en su fase de lectura, entonces, la validacin tiene xito si WS(Tk ) RS(Tij ) = . En este caso, las fases de lectura y escritura se traslapan, como se muestra en la Figura 6.7b, pero Tij no lee datos queson escritos por Tk. 3. Si existe alguna transaccin Tk, tal que, ts( Tk ) < ts( Tij ) y la cual completa su fase de lectura antes que Tij termine su fase de lectura, entonces, la validacin tiene xito si WS(Tk ) RS(Tij ) = y WS(Tk ) WS(Tij ) = . En este caso, las fases de lectura se traslapan, como se muestra en la Figura 2, pero las transacciones no accesan datos comunes.

Figura 2. Casos diferentes de las pruebas de validacin para control de concurrencia optimista.

4.2.3 DISCIPLINAS DEL INTERBLOQUEO: PREVENCIN, DETECCIN, ELIMINACIN Y RECUPERACIN. Interbloqueo: Un esquema para resolver el interbloque en su detencin. Prevencin: Las tcnicas de interbloqueo utilizan el concepto de marca de tiempo de transaccin existen dos esquemas que evitan el interbloqueo. Recuperacin: El objetivo de esta parte de la asignacin es conocer y entender las distintas fallas que pueden ocurrir en un BMS y como es posible restaurar el sistema despus de dichas fallas este tema se llama recuperacin de fallas.

4.3 CONFIABILIDAD. La confiabilidad se puede ver como una medida con la cual un sistema conforma su comportamiento a alguna especificacin. Tambin se puede interpretar como la probabilidad de que un sistema no haya experimentado ninguna falla dentro de un periodo de tiempo dado. La confiabilidad se utiliza tpicamente como un criterio para describir sistemas que no pueden ser reparados o donde la operacin continua del sistema es crtica. 4.3.1 CONCEPTOS BSICOS DE CONFIABILIDAD. Disponibilidad, por otro lado, es la fraccin del tiempo que un sistema satisface su especificacin. En otras palabras, la probabilidad de que el sistema sea operacional en un instante dado de tiempo. 4.3.2 PROTOCOLOS REDO/UNDO. Protocolos REDO/UNDO Recuperacin in-place Dado que las actualizacin in-place hacen que los valores anteriores se pierdan, es necesario mantener suficiente informacin de los cambios de estado en la base de datos. Esta informacin puede incluir entre otras cosas: Identificador de la transaccin, Tipo de operacin realizada, Los datos accesados por la transaccin para realizar la accin, El valor anterior del dato (imagen anterior), El valor nuevo del dato (imagen nueva).

Operacin de REDO: utiliza la informacin del registro de la base de datos y realiza de nuevo las acciones que pudieron haber sido realizadas antes de la falla. Genera una nueva imagen. Operacin UNDO: restablece un dato a su imagen anterior utilizando la informacin del registro. Si no hay registros undo y se escriben datos sucios a disco, en presencia de fallos se violara la atomicidad de la transaccin. Para garantizar la atomicidad sin escribir registros undo no hay que permitir la escritura de datos sucios (dirty writes, modificaciones no comprometidas) a disco. Es necesario escribir registros redo antes de comprometer para poder garantizar que las modificaciones de la transaccin se aplicarn incluso si hay un fallo justo despus del compromiso. Este esquema es conocido tambin como shadowing. Existe un directorio principal que apunta a la ltima versin comprometida de cada dato y uno secundario que apunta a la versin actual de cada dato. Cuando la transaccin compromete: o Las pginas modificadas son apuntadas por un nuevo directorio. o Se conmuta atmicamente del antiguo al nuevo directorio. 4.3.3 PUNTOS DE VERIFICACIN (CHECKPOINTS). Cuando ocurre una falta en el sistema es necesario consultar la bitcora para determinar cuales son las transacciones que necesitan para volver hacerse cuando no necesiten hacerse. Estos puntos de verificacin nos ayudan para reducir el gasto de tiempo consultando la bitcora. El punto de verificacin en un registro que se genera en la bitcora para concluir en todo lo que se encuentra antes de ese punto esta correcto y verificado. La operacin de recuperacin requiere recorrer todo el registro de la base de datos. As, el buscar todas las transacciones a las cuales es necesario aplicarles un UNDO o REDO puede tomar una cantidad de trabajo considerable. Para reducir este trabajo se pueden poner puntos de verificacin (checkpoints) en el registro de la base de datos para indicar que en esos puntos la base de datos est actualizada y consistente. En este caso, un REDO tiene que iniciar desde un punto de verificacin y un UNDO tiene que regresar al punto de verificacin ms inmediato anterior. La colocacin de puntos de verificacin se realiza con las siguientes acciones:

Se escribe un begin_checkpoint en el registro de la base de datos. Se recolectan todos los datos verificados en la base de datos estable. Se escribe un fin_de_checkpoint en el registro de la base de datos. 4.3.4 PROTOCOLO 2PC DE CONFIABILIDAD DISTRIBUIDA. Es un protocolo que consume un gran volumen de tiempo en la ejecucin de una transferencia durante el procesamiento normal se puede eliminar accesos a disco o el numero de mensajes en el proceso de la transaccin la pertenencia 2pc podra ser mejorada. El 2pc en conocido tambin como el protocolo que no resume nada para que trate todas las transacciones de la misma forma sin importar si las mismas cometen o abortan.

BBLOGRAFA

1. http://sacbeob.8m.com /tutoriales/bddistribuidas/index.htm. 2. http://www.cs.cinvestav.mx/SC/prof_personal/adiaz/Disdb/Cap_1.html 3. http://www.ingenieria.unam.mx/Paginas/Carreras/planes2010/Computacion/ Bases_de_datos/bases_de_datos_distribuidas.pdf 4. http://www.slideshare.net/natalialuva/diseo-de-bases-de-datos-distribuidas

CONCLUSON
Para terminar con la investigacin cabe mencionar que el uso de las transacciones en la actualidad posee grandes ventajas como son:

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. Modularidad: Se pueden modificar, agregar o quitar sistemas de la base de datos distribuida sin afectar a los dems sistemas (mdulos).