Bases de datos distribuidas

Bases de datos distribuidas

Una base de datos distribuida (BDD) es un conjunto de mltiples bases de datos lgicamente relacionadas las cuales se encuentran distribuidas en diferentes espacios lgicos (pej. un servidor corriendo 2 mquinas virtuales) e interconectados por una red de comunicaciones. Dichas BDD tienen la capacidad de realizar procesamiento autnomo, esto permite realizar operaciones locales o distribuidas. Un sistema de Bases de Datos Distribuida (SBDD) es un sistema en el cual mltiples sitios de bases de datos estn 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 estos fueran accedidos de forma local. 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 mltiples computadores, llamados sitios o nodos. Estos sitios deben de estar comunicados por medio de algn tipo de red de comunicaciones para transmitir datos y rdenes entre los sitios.

Historia
La necesidad de almacenar datos de forma masiva dio paso a la creacin de los sistemas de bases de datos. En 1970 Edgar Frank Codd escribi un artculo con nombre: "A Relational Model of Data for Large Shared Data Banks" ("Un modelo relacional para grandes bancos de datos compartidos"). Con este artculo y otras publicaciones, defini el modelo de bases de datos relacionales y reglas para poder evaluar un administrador de bases de datos relacionales. El cuadrado.

Inicio de las bases de datos distribuidas

Originalmente se almacenaba la informacin de manera centralizada, pero con el paso del tiempo las necesidades aumentaron y esto produjo ciertos inconvenientes que no era posible solucionarlos o volverlos eficientes de la forma centralizada. Estos problemas impulsaron la creacin de almacenamiento distribuido, los cuales hoy en da proveen caractersticas indispensables en el manejo de informacin; es decir, la combinacin de las redes de comunicacin y las bases de datos.

Evolucin
Hay varios factores que han hecho que las bases de datos evolucionen a bases de datos distribuidas. En el mundo de los negocios se ha dado una globalizacin y a la vez las operaciones de las empresas son cada vez ms descentralizadas geogrficamente. Tambin el poder de las computadoras personales aument y el costo de los Mainframes ya no tena sentido. Adems la necesidad de compartir datos ha hecho que crezca el mercado de las bases de datos distribuidas.

Componentes
Hardware involucrado
El hardware utilizado no difiere mucho del hardware utilizado en un servidor normal. Al principio se crea que si los componentes de una base de datos eran especializados seran ms eficientes y rpidos, pero se comprob que el decentralizar todo y adoptar un enfoque "nada compartido" (shared-nothing) resultaba ms barato y eficaz. Por lo que el hardware que compone una base de datos distribuida se reduce a servidores y la red.

Bases de datos distribuidas

Software
Sistema manejador de base de datos distribuida (DDBMS) Este sistema est formado por las transacciones y los administradores de la base de datos distribuidos. Un DDBMS implica un conjunto de programas que operan en diversas computadoras, estos programas pueden ser subsistemas de un nico DDBMS de un fabricante o podra consistir de una coleccin de programas de diferentes fuentes. 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. Los DTM se encargan de coordinar y controlar estas acciones. Este DTM puede ser propietario o desarrollado en casa. Sistema manejador de base de datos (DBMS) Es un programa que procesa cierta porcin 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 transaccin ejecuta un DTM y un nodo de base de datos ejecuta un DBM.

Consideraciones importantes
Calendarizador distribuido
El calendarizador est encargado de ordenar un conjunto de transacciones u operaciones que se deseen realizar sobre una base de datos. Cualquier orden en el que se decidan hacer este conjunto de operaciones se denomina calendarizacin. Parte del trabajo del calendarizador es realizar estas operaciones de forma que sean serializables y recuperables. Dos calendarizaciones son serializables (o equivalentes) si Cada operacin de lectura lee valores de los datos que son producidos por la misma operacin de escritura en ambas calendarizaciones (es decir son iguales) La operacin final de escritura en cada elemento de la data es la misma en ambas calendarizaciones

Deteccin de bloqueos y concurrencia

Bloqueos Un bloqueo en general es cuando una accin que debe ser realizada est esperando a un evento. Para manejar los bloqueos hay distintos acercamientos: prevencin, deteccin, y recuperacin. Tambin es necesario considerar factores como que hay sistemas en los que permitir un bloqueo es inaceptable y catastrfico, y sistemas en los que la deteccin del bloqueo es demasiado costosa. En el caso especfico de las bases de datos distribuidas usar bloqueo de recursos, peticiones para probar, establecer o liberar bloqueos requiere mensajes entre los manejadores de transacciones y el calendarizador. Para esto existen dos formas bsicas: Autnoma: cada nodo es responsable por sus propios bloqueos de recursos. Una transaccin sobre un elemento con n replicas requiere 5n mensajes Peticin del recurso Aprobacin de la peticin

Bases de datos distribuidas Mensaje de la transaccin Reconocimientos de transaccin exitosa Peticiones de liberacin de recursos Copia Primaria: un nodo primario es responsable para todos los bloqueos de recursos Una transaccin sobre un elemento con n copias requiere 2n+3 mensajes Una peticin del recurso Una aprobacin de la peticin n mensajes de la transaccin n reconocimientos de transaccin exitosa Una peticin de liberacin de recurso

Podemos definir que dos operaciones entran en conflicto que debe ser resuelto si ambas acceden a la misma data, y una de ellas es de escritura y si fueron realizadas por transacciones distintas. Concurrencia El ejemplo ms comn de un bloqueo mutuo es cuando un recurso A est siendo utilizado por una transaccin A que a su vez solicita un recurso B que est siendo utilizado por una transaccin B que solicita el recurso A. Entre los ejemplos especficos para las bases de datos distribuidas podemos destacar:: Control de concurrencia El problema de las actualizaciones perdidas: cuando dos transacciones concurrentes borran el efecto una de la otra Recuperaciones inconsistentes: acceder a informacin modificada parcialmente por una transaccin de Ian. Soluciones El control de concurrencia y deteccin y manejo de bloqueos es un rea de mucho estudio en las bases de datos distribuidas, a pesar de esto no hay ningn algoritmo aceptado para solucionar el problema. Esto se debe a varios factores de los cuales se consideran a los siguientes tres los ms determinantes: 1. La data puede estar duplicada en un BDD, por tanto, el manejador de la BDD es responsable de localizar y actualizar la data duplicada. 2. Si un nodo falla o la comunicacin con un nodo falla mientras se realiza una actualizacin, el manejador debe asegurarse de que los efectos se reflejen una vez el nodo se recupere del fallo. 3. La sincronizacin de transacciones en sitios o nodos mltiples es difcil ya que los nodos no pueden obtener informacin inmediata de las acciones realizadas en otros nodos concurrentemente. Para el control de bloqueos mutuos no se ha desarrollado ninguna solucin viable y la forma ms simple y que la mayora de productos utilizan es la implementacin de un tiempo mximo de espera en las peticiones de bloqueos. Causa de estas dificultades ms de 20 algoritmos de control de concurrencia se han propuesto en el pasado, y aun as siguen apareciendo nuevos. Una revisin bibliogrfica muestra que la mayora de los algoritmos son variantes del 2PL (2-phase locking o bloqueo de dos fases) o el algoritmo de time-stamp. A continuacin se explican estos dos algoritmos bsicos.

Bases de datos distribuidas Bloqueo de dos fases (2PL) El algoritmo 2PL utiliza bloqueos de lectura y escritura para prevenir conflictos entre operaciones. Consiste en los siguientes pasos para una transaccin T: 1. 2. 3. 4. 5. 6. Obtiene bloqueo de lectura para un elemento L (bloqueo compartido) Obtiene bloqueo de escritura para un elemento E (bloqueo exclusivo) Lee el elemento L Escribe en el elemento E Libera el bloqueo de L Libera el bloqueo de E

Las reglas bsicas para manejar los bloqueos son: transacciones distintas no pueden tener acceso simultneamente a un elemento (lectura-escritura o escritura-escritura), y una vez se libere un bloqueo no se puede pedir otro, es decir, los bloqueos de la transaccin crecern mientras no libere ninguno y luego de liberar alguno solo puede liberar los dems. Ejemplos del algoritmo 2PL son La bsica en la que se sigue el esquema previamente explicado con la variante que el bloqueo de escritura se pide para todas las copias del elemento. 2PL de copia primaria: en vez de pedir bloqueo para cada copia del elemento de escritura se le pide a una copia primaria o principal. 2PL de voto: se pide a todos los nodos que voten para ver si se concede el bloqueo. 2PL centralizado: el manejador de bloqueos est centralizado y todas las peticiones de bloqueo las maneja el. Antes de implementar un algoritmo de control de concurrencia 2PL es necesario considerar distintos factores como cual es la unidad atmica ms pequea que el sistema permite bloquear, cual es el intervalo de sincronizacin para todas las copias de un elemento, donde se deben colocar las tablas con la informacin de los bloqueos y por ltimo que tan probable es que ocurra por los factores anteriores un bloqueo mutuo. Time-stamp Cada transaccin realizada se le asigna un timestamp (literalmente: sello de tiempo) nico en el nodo que se origin. Este sello se adjunta a cada peticin de lectura y escritura. En el caso de que se d un conflicto de que dos operaciones de escritura traten de acceder al mismo elemento, este se resuelve serializandolo respecto a los sellos que tengan. A pesar de que existen varios algoritmos de control de concurrencia basados en timestamps, muy pocos son utilizados en aplicaciones comerciales. Esto es en gran parte porque se requiere que el sistema distribuido cuente con un reloj sincronizado que es raro que se tenga implementado.

Manejador de transacciones distribuido (DTM)

Definicin de transacciones Una transaccin es una secuencia de una o ms operaciones agrupadas como una unidad. El inicio y el final de la transaccin definen los puntos de consistencia de la base de datos. Si una accin de la transaccin no se puede ejecutar, entonces ninguna accin dentro de la secuencia que conforma la transaccin tendr efecto. Propiedades de las transacciones Atomicidad: Una transaccin es una unidad atmica de procesamiento, esta se realiza o no se realiza. Consistencia: Si se ejecuta una transaccin sobre un estado consistente, el resultado ser un nuevo estado consistente. Aislamiento: Una transaccin no hara visibles sus modificaciones a otras transacciones hasta que termine de ejecutarse completamente. Es decir, una transaccin desconoce si otras transacciones se estn ejecutando en el

Bases de datos distribuidas sistema. Durabilidad: Una vez una transaccin se ejecuta exitosamente y realiza cambios sobre el sistema, estos cambios nunca se deben perder a causa de fallas en el sistema. Tipos de transacciones Una transaccin puede clasificarse de diferentes maneras dependiendo bsicamente de tres criterios: 1. reas de aplicacin. En primer lugar, las transacciones se pueden ejecutar en aplicaciones no distribuidas. Las transacciones que operan en datos distribuidos se les conoce como transacciones distribuidas. Por otro lado, dado que los resultados de una transaccin que realiza un commit son durables, la nica forma de deshacer los efectos de una transaccin con commit es mediante otra transaccin. A este tipo de transacciones se les conoce como transacciones compensatorias. Finalmente, en ambientes heterogneos se presentan transacciones heterogneas sobre los datos. 2. Tiempo de duracin. Tomando en cuenta el tiempo que transcurre desde que se inicia una transaccin hasta que se realiza un commit o se aborta, las transacciones pueden ser de tipo batch o en lnea. Estas se pueden diferenciar tambin como transacciones de corta y larga vida. Las transacciones en lnea se caracterizan por tiempos de respuesta muy cortos y por acceder un porcin relativamente pequea de la base de datos. Por otro lado, las transacciones de tipo batch toman tiempos relativamente largos y accedan grandes porciones de la base de datos. 3. Estructura. Considerando la estructura que puede tener una transaccin se examinan dos aspectos: si una transaccin puede contener a su vez subtransacciones o el orden de las acciones de lectura y escritura dentro de una transaccin. Funcin del manejador El manejador de transacciones es el encargado de definir la estructura de las transacciones, mantener la consistencia en la base de datos cuando se ejecuta una transaccin o se cancela la ejecucin de una, mantener protocolos de fiabilidad, implementar algoritmos para el control de la concurrencia y sincronizar las transacciones que se ejecutan simultneamente. El manejador recibe solicitudes de procesamiento de transacciones y las traduce en acciones para el calendarizador. La operacin COMMIT seala el trmino exitoso de la transaccin: le dice al manejador de transacciones que se ha finalizado con xito una unidad lgica de trabajo, que la base de datos esta (o debera estar) de nuevo en un estado consistente, y que se pueden hacer permanentes todas las modificaciones efectuadas por esa unidad de trabajo. La operacin ROLLBACK, en cambio, seala el trmino no exitoso de la transaccin: le dice al manejador de transacciones que algo sali mal, que la base de datos podra estar en un estado inconsistente y que todas las modificaciones efectuadas hasta el momento por la unidad lgica de trabajo deben retroceder o anularse.

Distribucin de los datos

Una de las decisiones ms importantes que el diseador de bases de datos distribuidas debe tomar es el posicionamiento de la data en el sistema y el esquema bajo el cul lo desea hacer. Para esto existen cuatro alternativas principales: centralizada, replicada, fragmentada, e hbrida. Centralizada Es muy similar al modelo de Cliente/Servidor en el sentido que la BDD est centralizada en un lugar y los usuarios estn distribuidos. Este modelo solo brinda la ventaja de tener el procesamiento distribuido ya que en sentido de disponibilidad y fiabilidad de los datos no se gana nada.

Bases de datos distribuidas Replicadas El esquema de BDD de replicacin consiste en que cada nodo debe tener su copia completa de la base de datos. Es fcil ver que este esquema tiene un alto costo en el almacenamiento de la informacin. Debido a que la actualizacin de los datos debe ser realizada en todas las copias, tambin tiene un alto costo de escritura, pero todo esto vale la pena si tenemos un sistema en el que se va a escribir pocas veces y leer muchas, y dnde la disponibilidad y fiabilidad de los datos sea de mxima importancia. Particionadas Este modelo consiste en que solo hay una copia de cada elemento, pero la informacin est distribuida a travs de los nodos. En cada nodo se aloja uno o ms fragmentos disjuntos de la base de datos. Como los fragmentos no se replican esto disminuye el costo de almacenamiento, pero tambin sacrifica la disponibilidad y fiabilidad de los datos. Algo que se debe tomar en cuenta cuando se desea implementar este modelo es la granularidad de la fragmentacin. La fragmentacin se puede realizar tambin de tres formas: Horizontal: Los fragmentos son subconjuntos de una tabla (anlogo a un restringir) Vertical: Los fragmentos son subconjuntos de los atributos con sus valores (anlogo a un proyectar) Mixto: Se almacenan fragmentos producto de restringir y proyectar una tabla. Una ventaja significativa de este esquema es que las consultas (SQL) tambin se fragmentan por lo que su procesamiento es en paralelo y ms eficiente, pero tambin se sacrifica con casos especiales como usar JUNTAR o PRODUCTO, en general casos que involucren varios fragmentos de la BDD. Para que una fragmentacin sea correcta esta debe cumplir con las siguientes reglas: Debe ser Completa: Si una relacin R se fragmenta en R1,R2, ... , Rn, cada elemento de la data de R debe estar en algn Ri. Debe ser Reconstruible: Debe ser posible definir una operacin relacional que a partir de los fragmentos obtenga la relacin. Los fragmentos deben ser Disjuntos: Si la fragmentacin es horizontal entonces si un elemento e est en Ri este elemento no puede estar en ningn Rk (para k distinto a i). En el caso de fragmentacin vertical es necesario que se repitan las llaves primarias y esta condicin solo se debe cumplir para el conjunto de atributos que no son llave primaria. Hbrida Este esquema simplemente representa la combinacin del esquema de particin y replicacin. Se particiona la relacin y a la vez los fragmentos estn selectivamente replicados a travs del sistema de BDD. Criterios para escoger la distribucin Localidad de la data: la data debera ser colocada donde sta se accede ms seguido. El diseador debe analizar las aplicaciones y determinar como colocar la data de tal forma que se optimicen los accesos a la data locales. Fiabilidad de la data: Almacenando varias copias de la data en lugares geogrficamente apartados se logra maximizar la probabilidad de que la data va a ser recuperable en caso de que ocurra dao fsico en cualquier sitio. Disponibilidad de la data: como en la fiabilidad, almacenar varias copias asegura que los usuarios tengan a su disponibilidad los elementos de la data, an si el nodo al que usualmente acceden no est disponible o falla. Capacidades y costos de almacenamiento: a pesar de que los costos de almacenamiento no son tan grandes como los de transmisin, los nodos pueden tener diferentes capacidades de almacenamiento y procesamiento. Esto se debe analizar cuidadosamente para determinar donde poner la data. El costo de almacenamiento se disminuye significativamente minimizando la cantidad de copias de la data. Distribucin de la carga de procesamiento: una de las razones por la cual se escoge un sistema de BDD es porque se desea poder distribuir la carga de procesamiento para hacer este ms eficiente.

Bases de datos distribuidas Costo de comunicacin: el diseador debe considerar tambin el costo de usar las comunicaciones de la red para obtener data. Los costos de comunicacin se minimizan cuando cada sitio tiene su propia copia de la data, por otro lado cuando la data es actualizada se debe actualizar en todos los nodos. Uso del sistema: debe tomarse en consideracin cual ser el tipo principal de uso del sistema de BDD. Factores como la importancia en la disponibilidad de la data, la velocidad de escritura y la capacidad de recuperacin de daos fsicos deben tomarse en cuenta para escoger el esquema correcto.

Seguridad
Desde hace ya varios aos las bases de datos son ampliamente utilizadas en departamentos de gobiernos, empresas comerciales, bancos, hospitales, etc. Actualmente se est cambiando el esquema bajo el cul se utilizan las bases de datos, ya no son utilizadas nicamente de forma interna, sino que se tiene muchos accesos externos de tipos distintos. Estos cambios que se han introducido en el uso de las bases de datos ha creado la necesidad mejorar las prcticas de seguridad ya que el ambiente ya no es tan controlado como el esquema antiguo. Conceptos Los problemas de mayor importancia en seguridad son autenticacin, identificacin, y refuerzo de los controles de acceso apropiados. El sistema de seguridad de niveles mltiples. ste consiste en muchos usuarios con distintos niveles de permisos para una misma base de datos con informacin de distintos niveles. En las bases de datos distribuidas se han investigado dos acercamientos a este modelo: data distribuida y control centralizado, y data y control distribuidos. En el acercamiento de data distribuida y control centralizado se divide en dos soluciones: particionado y replicado. En el primero de estos lo que se tiene es un conjunto de nodos y cada uno de ellos opera a cierto nivel de seguridad, as el usuario con nivel de permisos X accede al servidor que maneja la data para X. El replicado surgi debido a que si alguien con altos derechos de seguridad deseaba consultar data con de bajo nivel de seguridad deba enviar su peticin a un servidor de bajo nivel de seguridad por lo cual se podra divulgar informacin sensible. En el esquema replicado entonces la data se repite en cascada de tal forma que el nivel ms alto tiene una copia entera de la base de datos, y el ms bajo solamente la informacin de ms bajo nivel. El otro acercamiento de data y control distribuido cada nodo contiene informacin de distintos niveles y est diseado para aceptar peticiones de cualquier nivel de usuario. El problema de inferencia El problema de inferencia consiste en usuarios tratando de ejecutar consultas sobre la BD y estos infiriendo informacin sobre la respuesta legtima que la base de datos debe responder. Las herramientas para minera de datos hacen este problema an ms peligroso ya que hacen que sea ms fcil para cualquier novato poder deducir patrones e informacin importantes de simplemente probar consultas.

Tipos de arquitecturas/implementaciones
En un sistema de bases de datos distribuidas, existen varios factores que deben tomar en consideracin que definen la arquitectura del sistema: Distribucin: Los componentes del sistema estn localizados en la misma computadora o no. Heterogeneidad: Un sistema es heterogneo cuando existen en l componentes que se ejecutan en diversos sistemas operativos, de diferentes fuentes, etc. Autonoma: Se puede presentar en diferentes niveles, los cuales se describen a continuacin: 1. Autonoma de diseo: Habilidad de un componente del sistema para decidir cuestiones relacionadas a su propio diseo.

Bases de datos distribuidas 2. Autonoma de comunicacin: Habilidad de un componente del sistema para decidir como y cuando comunicarse con otros SGBD (Sistema Gestor de Bases de Datos). 3. Autonoma de ejecucin: Habilidad de un componente del sistema para ejecutar operaciones locales como quiera. 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. 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. La 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 transparencia 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. Particionado 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

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

Bases de datos distribuidas

10

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. Diseo de la base de datos se vuelve ms complejo - adems de las dificultades que generalmente se encuentran al disear una base de datos, el diseo de una base de datos distribuida debe considerar la fragmentacin, replicacin y ubicacin de los fragmentos en sitios especficos.

Productos existentes
Microsoft SQL Server 2008 [1] Oracle 11g [2] Apache Cassandra [3]

Notas y referencias
Historia de las bases de datos en Ciencia de la Informacin, ltima visita 12 de enero 2012. [4] Vargas, J., Mendoza, M. et al, Fundamentos tericos de bases de datos distribuidas. Tecnomaestros, Bases de datos distribuidas, ltima visita 12 de enero 2012. [5] SACBEOB, Informacin de bases de datos distribuidas por RUBI #ICQ 44323906, ltima visita 12 de enero 2012. [6] DeWitt, David J., Gray, J., Parallel database systems: the future of high performance database processing, ltima visita 12 enero 2012. [7] Ho, M., Distributed database management systems William Perrizo, Distributed database management system (DDBMS) [8] Umar, Amjad, Distributed database management systems: issues and approachesS, University of Michigan, ltima visita 12 de enero 2012. [9] Wrembel, R., Designing distributed databas Sistemas de bases de datos distribuidas, Universidad de Colima, ltima visita 12 de enero 2012. [10] Kse, Ilker, Distributed database security. Gertz, Michel, Distributed transaction management. lvarez Carrin, Guillermo, Integracin de esquemas en bases de datos heterogneas fuertemente acopladas, ltima visita 12 de enero 2012. [11] Mas, Fernando A., Procesamiento de transacciones en sistemas distribuidos, ltima visita 12 de enero 2012. [12] De La Rosa Tllez, Maidel, Bases de datos distribuidas, Ministerio de Educacin Superior de la Repblica de Cuba, Centro Universitario Vladimir Ilich Lenin.

Bases de datos distribuidas

11

Referencias
[1] [2] [3] [4] http:/ / msdn. microsoft. com/ en-us/ library/ ms191440. aspx http:/ / www. oracle. com/ database/ product_editions. html http:/ / cassandra. apache. org/ http:/ / recursostic. javeriana. edu. co/ wiki/ index. php/ Historia_de_las_bases_de_datos_en_Ciencia_de_la_Informacin#Historia_de_los_sistemas_de_bases_de_datos [5] http:/ / tecnomaestros. awardspace. com/ bases_datos_distribuidas. php [6] http:/ / sacbeob. 8m. com/ tutoriales/ bddistribuidas/ index. htm [7] http:/ / pages. cs. wisc. edu/ ~dewitt/ includes/ paralleldb/ cacm. pdf [8] http:/ / www. cs. ndsu. nodak. edu/ ~perrizo/ classes/ 765/ dis. html [9] http:/ / deepblue. lib. umich. edu/ bitstream/ 2027. 42/ 8042/ 4/ bam0426. 0001. 001. txt [10] http:/ / docente. ucol. mx/ vpc1052/ public_html/ Expo%20SBDD. doc [11] http:/ / catarina. udlap. mx/ u_dl_a/ tales/ documentos/ msp/ alvarez_c_g/ indice. html [12] http:/ / www. fa-mas-dbms. blogspot. com/

Fuentes y contribuyentes del artculo

12

Fuentes y contribuyentes del artculo

Bases de datos distribuidas Fuente: http://es.wikipedia.org/w/index.php?oldid=59667286 Contribuyentes: Acratta, Aipni-Lovrij, Desgraci, Dhidalgo, Gins90, Hprmedina, Jkbw, Josemarinalcaide, Matdrodes, Poco a poco, Sergio Andres Segovia, SrOC, Technopat, Tempuslumen, Ucevista, Xris5, Yodigo, 69 ediciones annimas

Licencia
Creative Commons Attribution-Share Alike 3.0 Unported //creativecommons.org/licenses/by-sa/3.0/