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

Originalmente se almacenaba la información 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 creación de almacenamiento distribuido, los cuales hoy en día proveen características indispensables en el manejo de información; es decir, la combinación de las redes de comunicación y las bases de datos.

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 globalización y a la vez las operaciones de las empresas son cada vez más descentralizadas geográficamente. También el poder de las computadoras personales aumentó y el costo de los Mainframes ya no tenía sentido. Además la necesidad de compartir datos ha hecho que crezca el mercado de las bases de datos distribuidas.

El hardware utilizado no difiere mucho del hardware utilizado en un servidor normal. Al principio se creía que si los componentes de una base de datos eran especializados serían más eficientes y rápidos, pero se comprobó que el descentralizar todo y adoptar un enfoque "nada compartido" (shared-nothing) resultaba más barato y eficaz. Por lo que el hardware que compone una base de datos distribuida se reduce a servidores y la red.

Este sistema está formado por las transacciones y los administradores de la base de datos distribuidos. Un SBDD implica un conjunto de programas que operan en diversas computadoras, estos podría consistir de una colección de programas de diferentes fuentes.

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 libre.

Es un programa que procesa cierta porción de la base de datos distribuida. Se encarga de recuperar y actualizar datos del usuario y generales de acuerdo con los comandos recibidos de los DTM.

Un nodo es una computadora que ejecuta un DTM o un DBM o ambos. Un nodo de transacción ejecuta un DTM y un nodo de base de datos ejecuta un DBM.

El planificador 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 planificación. Parte del trabajo del planificador es realizar estas operaciones de forma que sean serializables y recuperables.

Dos planificadores son serializables (o equivalentes) si

• Cada operación de lectura lee valores de los datos que son producidos por la misma operación de escritura en ambas planificaciones (es decir son iguales)
• La operación final de escritura en cada elemento de la data es la misma en ambas planificaciones

Un bloqueo en general es cuando una acción que debe ser realizada está esperando a un evento. Para manejar los bloqueos hay distintos acercamientos: prevención, detección, y recuperación. También es necesario considerar factores como que hay sistemas en los que permitir un bloqueo es inaceptable y catastrófico, y sistemas en los que la detección del bloqueo es demasiado costosa.

En el caso específico 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 básicas:

• Autónoma: cada nodo es responsable por sus propios bloqueos de recursos.
  • Una transacción sobre un elemento con n réplicas requiere 5n mensajes
  • Petición del recurso
  • Aprobación de la petición
  • Mensaje de la transacción
  • Reconocimientos de transacción exitosa
  • Peticiones de liberación de recursos
• Copia Primaria: un nodo primario es responsable para todos los bloqueos de recursos
  • Una transacción sobre un elemento con n copias requiere 2n+3 mensajes
  • Una petición del recurso
  • Una aprobación de la peticiónConceptos de Bases de Datos Distribuidas
  • n mensajes de la transacción
  • n reconocimientos de transacción exitosa
  • Una petición de liberación de recurso

Podemos definir que dos operaciones entran en conflicto que debe ser resuelto si ambas acceden a los mismos datos, y una de ellas es de escritura y si fueron realizadas por transacciones distintas.

El ejemplo más común de un bloqueo mutuo es cuando un recurso A está siendo utilizado por una transacción A que a su vez solicita un recurso B que está siendo utilizado por una transacción B que solicita el recurso A.

• El problema de las actualizaciones perdidas: cuando dos transacciones concurrentes borran el efecto una de la otra
• Recuperaciones inconsistentes: acceder a información modificada parcialmente por una transacción de Ian.

El control de concurrencia y detección y manejo de bloqueos es un área de mucho estudio en las bases de datos distribuidas, a pesar de esto no hay ningún algoritmo aceptado para solucionar el problema. Esto se debe a varios factores de los cuales se consideran a los siguientes tres los más determinantes:

1. El dato 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 comunicación con un nodo falla mientras se realiza una actualización, el manejador debe asegurarse de que los efectos se reflejen una vez el nodo se recupere del fallo.
3. La sincronización de transacciones en sitios o nodos múltiples es difícil ya que los nodos no pueden obtener información inmediata de las acciones realizadas en otros nodos concurrentemente.

Para el control de bloqueos mutuos no se ha desarrollado ninguna solución viable y la forma más simple y que la mayoría de productos utilizan es la implementación de un tiempo máximo de espera en las peticiones de bloqueos.

Causa de estas dificultades más de 20 algoritmos de control de concurrencia se han propuesto en el pasado, y aun así siguen apareciendo nuevos. Una revisión bibliográfica muestra que la mayoría de los algoritmos son variantes del 2PL (2-phase locking o bloqueo de dos fases) o el algoritmo de time-stamp. A continuación se explican estos dos algoritmos básicos.

El algoritmo 2PL utiliza bloqueos de lectura y escritura para prevenir conflictos entre operaciones. Consiste en los siguientes pasos para una transacción T:

1. Obtiene bloqueo de lectura para un elemento L (bloqueo compartido)
2. Obtiene bloqueo de escritura para un elemento E (bloqueo exclusivo)
3. Lee el elemento L
4. Escribe en el elemento E
5. Libera el bloqueo de L
6. Libera el bloqueo de E

Las reglas básicas para manejar los bloqueos son: transacciones distintas no pueden tener acceso simultáneamente 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 transacción crecerán mientras no libere ninguno y luego de liberar alguno solo puede liberar los demás.

Ejemplos del algoritmo 2PL son

• La básica 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 atómica más pequeña que el sistema permite bloquear, cual es el intervalo de sincronización para todas las copias de un elemento, donde se deben colocar las tablas con la información de los bloqueos y por último que tan probable es que ocurra por los factores anteriores un bloqueo mutuo.

Cada transacción realizada se le asigna un timestamp (literalmente: sello de tiempo) único en el nodo que se originó. Este sello se adjunta a cada petición 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 serializándolo 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.

Una transacción es una secuencia de una o más operaciones agrupadas como una unidad. El inicio y el final de la transacción definen los puntos de consistencia de la base de datos. Si una acción de la transacción no se puede ejecutar, entonces ninguna acción dentro de la secuencia que conforma la transacción tendrá efecto.

• Atomicidad: Una transacción es una unidad atómica de procesamiento, esta se realiza o no se realiza.
• Consistencia: Si se ejecuta una transacción sobre un estado consistente, el resultado será un nuevo estado consistente.
• Aislamiento: Una transacción no hará visibles sus modificaciones a otras transacciones hasta que termine de ejecutarse completamente. Es decir, una transacción desconoce si otras transacciones se estén ejecutando en el sistema.
• Durabilidad: Una vez una transacción se ejecuta exitosamente y realiza cambios sobre el sistema, estos cambios nunca se deben perder a causa de fallas en el sistema.

Una transacción puede clasificarse de diferentes maneras dependiendo básicamente de tres criterios:

1. Áreas de aplicación. 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 transacción que realiza un commit son durables, la única forma de deshacer los efectos de una transacción con commit es mediante otra transacción. A este tipo de transacciones se les conoce como transacciones compensatorias. Finalmente, en ambientes heterogéneos se presentan transacciones heterogéneas sobre los datos.
2. Tiempo de duración. Tomando en cuenta el tiempo que transcurre desde que se inicia una transacción hasta que se realiza un commit o se aborta, las transacciones pueden ser de tipo batch o en línea. Estas se pueden diferenciar también como transacciones de corta y larga vida. Las transacciones en línea se caracterizan por tiempos de respuesta muy cortos y por acceder un porción relativamente pequeña 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 transacción se examinan dos aspectos: si una transacción puede contener a su vez subtransacciones o el orden de las acciones de lectura y escritura dentro de una transacción.

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 transacción o se cancela la ejecución de una, mantener protocolos de fiabilidad, implementar algoritmos para el control de la concurrencia y sincronizar las transacciones que se ejecutan simultáneamente.

El manejador recibe solicitudes de procesamiento de transacciones y las traduce en acciones para el calendarizador.

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

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

Una de las decisiones más importantes que el diseñador de bases de datos distribuidas debe tomar es el posicionamiento de la data en el sistema y el esquema bajo el cual lo desea hacer. Para esto existen cuatro alternativas principales: centralizada, replicada, fragmentada, e híbrida.

Es muy similar al modelo de Cliente/Servidor en el sentido que la BDD está centralizada en un lugar y los usuarios están 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.

El esquema de BDD de replicación consiste en que cada nodo debe tener su copia completa de la base de datos. Es fácil ver que este esquema tiene un alto costo en el almacenamiento de la información. Debido a que la actualización de los datos debe ser realizada en todas las copias, también 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 dónde la disponibilidad y fiabilidad de los datos sea de máxima importancia.

Un fragmento no es más que la división de una gran base de datos en partes más pequeñas.

Este modelo consiste en que solo hay una copia de cada elemento, pero la información está distribuida a través de los nodos. En cada nodo se aloja uno o más fragmentos disjuntos de la base de datos. Como los fragmentos no se replican esto disminuye el costo de almacenamiento, pero también 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 fragmentación. La fragmentación se puede realizar también de cuatro formas:

• Horizontal primaria: Los fragmentos son subconjuntos de una tabla (análogo a un restringir)
• Horizontal derivada: La división por fragmentación derivada, está definida por una relación R diferente a la relación S que se fragmentará.
• Vertical: Los fragmentos son subconjuntos de los atributos con sus valores (análogo 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) también se fragmentan por lo que su procesamiento es en paralelo y más eficiente, pero también se sacrifica con casos especiales como usar JUNTAR o PRODUCTO, en general casos que involucren varios fragmentos de la BDD.

Para que una fragmentación sea correcta esta debe cumplir con las siguientes reglas:

• Debe ser Completa: Si una relación R se fragmenta en R₁,R₂, ... , R_n, cada elemento de la data de R debe estar en algún R_i.
• Debe ser Reconstruible: Debe ser posible definir una operación relacional que a partir de los fragmentos obtenga la relación.
• Los fragmentos deben ser Disjuntos: Si la fragmentación es horizontal entonces si un elemento e está en R_i este elemento no puede estar en ningún R_k (para k distinto a i). En el caso de fragmentación vertical es necesario que se repitan las llaves primarias y esta condición solo se debe cumplir para el conjunto de atributos que no son llave primaria

Esta división está dada por la llave foránea, es decir, la operación usada será entre la relación "hija" con la relación "padre", es importante saber que se aplicará la operación de semi-join, permitiendo conservar únicamente las columnas de la relación S.

Es común mantener los fragmentos horizontales primarios y derivados en un mismo nodo, permitiendo así, una mejora de eficiencia en el uso de la red al realizar operaciones como el join.

Este esquema simplemente representa la combinación del esquema de partición y replicación. Se particiona la relación y a la vez los fragmentos están selectivamente replicados a través del sistema de BDD.

• Localidad de la data: la data debería ser colocada donde esta se accede más seguido. El diseñador 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 geográficamente apartados se logra maximizar la probabilidad de que la data va a ser recuperable en caso de que ocurra daño físico 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, aún 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 transmisión, 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.
• Distribución 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 más eficiente.
• Costo de comunicación: el diseñador debe considerar también el costo de usar las comunicaciones de la red para obtener data. Los costos de comunicación 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 consideración 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 recuperación de daños físicos deben tomarse en cuenta para escoger el esquema correcto.

Desde hace ya varios años las bases de datos son ampliamente utilizadas en departamentos de gobiernos, empresas comerciales, bancos, hospitales, etc. Actualmente se está cambiando el esquema bajo el cual 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 prácticas de seguridad ya que el ambiente ya no es tan controlado como el esquema antiguo.

Los problemas de mayor importancia en seguridad son autenticación, identificación, y refuerzo de los controles de acceso apropiados. El sistema de seguridad de niveles múltiples. Éste consiste en muchos usuarios con distintos niveles de permisos para una misma base de datos con información 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 un bajo nivel de seguridad debía enviar su petición a un servidor de bajo nivel de seguridad por lo cual se podría divulgar información sensible. En el esquema replicado entonces la data se repite en cascada de tal forma que el nivel más alto tiene una copia entera de la base de datos, y el más bajo solamente la información de más bajo nivel. El otro acercamiento de data y control distribuido cada nodo contiene información de distintos niveles y está diseñado para aceptar peticiones de cualquier nivel de usuario.

El problema de inferencia consiste en usuarios tratando de ejecutar consultas sobre la BD y estos infiriendo información sobre la respuesta legítima que la base de datos debe responder. Las herramientas para minería de datos hacen este problema aún más peligroso ya que hacen que sea más fácil para cualquier novato poder deducir patrones e información importantes de simplemente probar consultas.

En un sistema de bases de datos distribuidas, existen varios factores que deben tomar en consideración que definen la arquitectura del sistema:

• Distribución: Los componentes del sistema están localizados en la misma computadora o no.
• Heterogeneidad: Un sistema es heterogéneo cuando existen en él componentes que se ejecutan en diversos sistemas operativos, de diferentes fuentes, etc.
• Autonomía: Se puede presentar en diferentes niveles, los cuales se describen a continuación:

1. Autonomía de diseño: Habilidad de un componente del sistema para decidir cuestiones relacionadas con su propio diseño.
2. Autonomía de comunicación: Habilidad de un componente del sistema para decidir como y cuando comunicarse con otros SGBD (Sistema Gestor de Bases de Datos).
3. Autonomía de ejecución: Habilidad de un componente del sistema para ejecutar operaciones locales como quiera.

Cuando una base de datos distribuida es muy homogénea se dice que es multi base de datos distribuida.

Cuando una base de datos distribuida tiene mucha autonomía local se dice que es federada.

Al implementar una base de datos distribuida se tienen ciertos objetivos comunes:

• Transparencia de ubicación. Permite a los usuarios tener acceso a los datos sin que tenga conocimiento de la ubicación de estos. Se puede conseguir este nivel de transparencia al utilizar los administradores de transacciones distribuidas, los cuales son capaces de determinar la localización 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 duplicación. Para que la transparencia de duplicación sea posible, los administradores de transacciones deben traducir las solicitudes de procesamiento de transacción 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 información sobre el rendimiento de varios nodos respecto al sitio de consulta, así podrá seleccionar el nodo de mejor rendimiento. La actualización y escritura de datos duplicados suelen ser más complicadas, ya que el manejador de transacciones debe emitir una acción 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 deberán afectarse. La transparencia de concurrencia se logra si los resultados de todas las transacciones concurrentes son consistentes de manera lógica con los resultados que se habrían 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 atómicas, 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 cuándo 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 mínimo de complicaciones.

• Localidad del procesamiento. Los datos se deben distribuir lo más 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. Diseñar una distribución que maximice localidad del procesamiento puede hacerse añadiendo la cantidad de referencias locales y remotas correspondientes a cada fragmentación candidata y asignar la fragmentación eligiendo la mejor solución. Independencia de configuración. La independencia de configuración permite añadir 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 duplicación 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 más de una localidad se ve limitada la disponibilidad de los datos. La fiabilidad también puede verse limitada cuando se produce un fallo en el sistema de cálculo de una localidad se afecta la disponibilidad de los datos de esa localidad no estén disponible para los usuarios en cualquier parte del sistema.

• Fragmentación 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 más pequeñas. La fragmentación se puede realizar por tuplas individuales (fragmentación horizontal), por atributos individuales fragmentación vertical) o una combinación de ambas (fragmentación híbrida). El principal problema de la fragmentación radica en encontrar la unidad apropiada de distribución. Una relación no es una buena unidad por muchas razones. Normalmente las vistas de una relación están formadas por subconjuntos de relaciones. Además, las aplicaciones acceden localmente a subconjuntos de relaciones. Por ello, es necesario considerar a los subconjuntos de relaciones como unidad de distribución. Al descomponer de una relación en fragmentos, tratados cada uno de ellos como una unidad de distribución, permite el proceso concurrente de las transacciones. El conjunto de estas relaciones, provocará la ejecución paralela de una consulta al ser dividida en una serie de subconsultas que operará sobre los fragmentos. Cuando las vistas definidas sobre una relación son consideradas como unidad de distribución que se ubican en diferentes sitios de la red, podemos optar por dos alternativas diferentes: La relación no estará replicada y se almacena en un único sitio, o existe réplica en todos o algunos de los sitios en los cuales reside la aplicación. Las consecuencias de esta estrategia son la generación de un volumen de accesos remotos que pueden ser innecesarios con un mal manejo de estas réplicas. Además, las réplicas innecesarias pueden causar problemas en la ejecución de las actualizaciones y puede no ser deseable si el espacio de almacenamiento está limitado. Los inconvenientes de la fragmentación están 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 operación de unión (Join), lo cual puede ser costoso. El control semántico cuando los atributos implicados en una dependencia una relación se descompone en diferentes fragmentos y estos se ubican en sitios diferentes puede ser muy costos porque es necesario hacer búsquedas en un gran número de sitios.

El diseño y la implementación de optimizadores de consultas son fundamentales para abordar los desafíos asociados con el procesamiento distribuido. Estos optimizadores se encargan de traducir consultas globales en planes de ejecución eficientes, considerando factores como la fragmentación de datos, la replicación y los costos de comunicación entre nodos.

1. Optimizadores basados en búsqueda exhaustiva:
   • Generan todas las combinaciones posibles para ejecutar una consulta, lo que garantiza soluciones óptimas.
   • Sin embargo, su complejidad puede escalar exponencialmente con el número de tablas involucradas.
2. Optimizadores basados en heurísticas:
   • Reducen costos de ejecución al aplicar reglas como:
     • Priorizar operaciones de bajo costo (selección, proyección).
     • Sustituir joins por semi-joins para minimizar el intercambio de datos entre nodos.
     • Reordenar operaciones para reducir el tamaño de resultados intermedios.
   • Aunque no garantizan soluciones óptimas, son más rápidos y eficientes en entornos distribuidos.
3. Optimizadores híbridos:
   • Combinan enfoques estáticos (antes de ejecutar la consulta) y dinámicos (durante la ejecución).
   • Se adaptan a resultados intermedios, ajustando estrategias para mejorar el desempeño.

• Cardinalidad y fragmentación: El volumen de datos en fragmentos afecta significativamente los costos de entrada/salida y comunicación.
• Complejidad de operadores: Operaciones como joins o productos cartesianos pueden ser costosas si no se gestionan adecuadamente.
• Replicación y elección de nodos: La disponibilidad de fragmentos replicados permite seleccionar el nodo más cercano, reduciendo la latencia.

• Refleja una estructura organizacional - los fragmentos de la base de datos se ubican en los departamentos a los que tienen relación.
• Autonomía local - un departamento puede controlar los datos que le pertenecen.
• Disponibilidad - un fallo en una parte del sistema solo afectará a un fragmento, en lugar de a toda la base de datos.
• Rendimiento - los datos generalmente se ubican cerca del sitio con mayor demanda, también los sistemas trabajan en paralelo, lo cual permite balancear la carga en los servidores.
• Economía - es más barato crear una red de muchas computadoras pequeñas, que tener una sola computadora muy poderosa.
• Modularidad - se pueden modificar, agregar o quitar sistemas de la base de datos distribuida sin afectar a los demás sistemas (módulos).

• Complejidad - Se debe asegurar que la base de datos sea transparente, se debe lidiar con varios sistemas diferentes que pueden presentar dificultades únicas. El diseño de la base de datos se tiene que trabajar tomando en cuenta su naturaleza distribuida, por lo cual no podemos pensar en hacer joins que afecten varios sistemas.
• Economía - la complejidad y la infraestructura necesaria implica que se necesitará una mayor mano de obra.
• Seguridad - se debe trabajar en la seguridad de la infraestructura, así como cada uno de los sistemas.
• Integridad - Se vuelve difícil mantener la integridad, aplicar las reglas de integridad a través de la red puede ser muy caro en términos de transmisión de datos.
• Falta de experiencia - las bases de datos distribuidas son un campo relativamente nuevo y poco común por lo cual no existe mucho personal con experiencia o conocimientos adecuados.
• Carencia de estándares - aún no existen herramientas o metodologías que ayuden a los usuarios a convertir un DBMS centralizado en un DBMS distribuido.
• Diseño de la base de datos se vuelve más complejo - además de las dificultades que generalmente se encuentran al diseñar una base de datos, el diseño de una base de datos distribuida debe considerar la fragmentación, replicación y ubicación de los fragmentos en sitios específicos.

• Microsoft SQL Server 2008.^[2]​
• Oracle 11g.^[3]​
• Apache Cassandra URL oficial
• Apache HBase
• MySQL Cluster
• MongoDB
• Bases de datos distribuidas basadas en cadenas de bloques como por ejemplo: Bitcoin, Litecoin, Dogecoin, Namecoin y Ethereum

Una cadena de bloques es un tipo de base de datos distribuida especialmente adecuada para procesar datos ordenados en el tiempo. En la cadena de bloque la seguridad está embebida en su propio diseño haciendo prácticamente imposible modificar o borrar entradas de la base de datos. En contraste, para conseguir este comportamiento en los sistemas de datos distribuidos tradicionales, se usa una autoridad central la cual constituye un posible punto de fallo.^[4]​

La desventaja de la cadena de bloques frente a los sistemas tradicionales es que tienen una comparativamente lenta confirmación de las transacciones y un menor grado de escalabilidad.^[4]​

• Almacén de datos
• Base de datos orientada a objetos
• Cadena de bloques
• Replicación (informática)
• Shard (arquitectura de base de datos)
• Sistema de gestión de base de datos

• Historia de las bases de datos en Ciencia de la Información, última visita 12 de enero de 2012. [1]
• Vargas, J., Mendoza, M. et al, Fundamentos teóricos de bases de datos distribuidas.
• Tecnomaestros, Bases de datos distribuidas, última visita 12 de enero de 2012. [2]
• SACBEOB, Información de bases de datos distribuidas por RUBI #ICQ 44323906, última visita 12 de enero de 2012. [3]
• DeWitt, David J., Gray, J., Parallel database systems: the future of high performance database processing, última visita 12 de enero de 2012. [4]
• Ho, M., Distributed database management systems
• William Perrizo, Distributed database management system (DDBMS) [5] Archivado el 20 de julio de 2008 en Wayback Machine.
• Umar, Amjad, Distributed database management systems: issues and approachesS, University of Michigan, última visita 12 de enero de 2012. [6]
• Wrembel, R., Designing distributed databas
• Sistemas de bases de datos distribuidas, Universidad de Colima, última visita 12 de enero de 2012. [7] (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última).
• Köse, Ilker, Distributed database security.
• Gertz, Michel, Distributed transaction management.
• Álvarez Carrión, Guillermo, Integración de esquemas en bases de datos heterogéneas fuertemente acopladas, última visita 12 de enero de 2012. [8]
• Mas, Fernando A., Procesamiento de transacciones en sistemas distribuidos, última visita 12 de enero de 2012. [9]
• De La Rosa Téllez, Maidel, Bases de datos distribuidas, Ministerio de Educación Superior de la República de Cuba, Centro Universitario Vladimir Ilich Lenin.
• De Andreu Tellez, Pablo Base de datos importante, Ministerio de Ies Joan Ramis Ramis.