Las bases de datos distribuidas tienen características muy definidas a la hora de implementar y trabajar con o sobre ellas.

Cuando un usuario usa una aplicación, no conoce que hay detrás de este sistema, con respecto a su base de datos. Ya que todo esto sucede de manera transparente y rápida. Si algún fallo en su equipo no le permite continuar trabajando, fácilmente puede sustituir este y continuar con sus actividades, esto hace que tenga un mejor rendimiento en las actividades laborales y en cualquier otra área que use un sistema de bases distribuido.

Christopher J. Date (nacido en 1941) es un autor, conferencista, investigador y consultor independiente, especializado en teoría de bases de datos relacionales.

Las 12 reglas establecidas por Christopher Date para los DDBMS.

  1. Independencia local 

Los nodos en un sistema distribuido deben ser autónomos o independientes entre sí. Cada nodo en un sistema distribuido debe proporcionar su propia seguridad, bloqueo, registro, integridad y recuperación. Las operaciones locales usan y afectan solo los recursos locales y no dependen de otros sitios.

  1. Independencia del sitio central 

Un sistema no debe depender de un sitio o nodo central, ya que un solo sitio central puede convertirse en un único punto de falla, afectando a todo el sistema. Además, un sitio central puede convertirse en un cuello de botella que afecta el rendimiento de todo el sistema distribuido. Cada sitio de un sistema de base de datos distribuida proporciona su propia seguridad, bloqueo, registro, integridad y recuperación, y maneja su propio diccionario de datos. Ningún sitio central debe estar involucrado en cada transacción distribuida.

  1. Independencia de fallas 

Un sistema distribuido nunca debe de tener tiempos de inactividad demasiados largos. Debe proporcionar respaldo y recuperación en línea, y un servicio de archivo completo e incremental. La copia de seguridad y la recuperación deben ser lo suficientemente rápidas para realizarse en línea sin un efecto perjudicial perceptible en el rendimiento total del sistema.

  1. Transparencia de ubicación 

Los usuarios y aplicaciones no deben saber  dónde se almacenan físicamente los datos, la base de datos debe comportarse como si todos los datos se almacenarán localmente.

La transparencia de la ubicación puede ser respaldada por sinónimos extendidos y uso extensivo del diccionario de datos. La independencia de ubicación permite que las aplicaciones se transfieran fácilmente de un sitio en un sistema de base de datos distribuido a otro sin modificaciones.

  1. Transparencia de fragmentación 

 Las tablas relacionales pueden dividirse en fragmentos y almacenarse en diferentes sitios transparentes para los usuarios y las aplicaciones. De tal manera similar a la regla de transparencia de ubicación, los usuarios y las aplicaciones no deben tener en cuenta el hecho de que algunos datos pueden almacenarse en un fragmento de una tabla en un sitio diferente al sitio donde está almacenada la tabla.

  1. Transparencia de replicación 

Los datos se pueden replicar de manera transparente en múltiples sistemas informáticos a través de una red.

Similar a la ubicación de datos y las reglas de independencia de fragmentación, la independencia de replicación está diseñada para liberar a los usuarios de las preocupaciones sobre dónde se almacenan los datos. En el caso de la replicación, los usuarios y las aplicaciones no deben saber que el sistema mantiene y sincroniza automáticamente las réplicas de los datos.

  1. Procesamiento de consulta distribuida 

El procesamiento de una consulta determinada debe ser independiente del sitio en el que se envía la consulta dado que un sistema de administración de bases de datos relacionales proporciona acceso no virtual a los datos (a través de SQL), dicho sistema debe admitir un optimizador que pueda seleccionar no solo la mejor ruta de acceso dentro de un nodo dado, sino también optimizar una consulta distribuida con respecto a la ubicación de datos, la utilización de CPU y el rendimiento del tráfico de red.

  1. Procesamiento de transacciones distribuidas 

 Un sistema distribuido debería ser capaz de soportar miles de transacciones. Las propiedades de transacción de atomicidad, consistencia, durabilidad, aislamiento y serialización deben ser compatibles no solo para transacciones locales, sino también para transacciones distribuidas que pueden abarcar múltiples sistemas

  1. Independencia del hardware 

 Un sistema de base de datos distribuida debe ser capaz de operar y acceder a los datos distribuidos en una amplia variedad de plataformas de hardware.

 Cualquier sistema DBMS verdaderamente distribuido no debe depender de una característica de hardware particular, ni debe estar limitado a una cierta arquitectura de hardware o proveedor.

  1. Independencia del sistema operativo 

 Un sistema de base de datos distribuida debe poder ejecutarse en diferentes sistemas operativos. No debe de estar casado con windows, unix o linux si no que debe poder adaptarse en cualquier ambiente de trabajo.

  1. Independencia de la red 

Un sistema de base de datos distribuida debe diseñarse para ejecutarse independientemente de los protocolos de comunicación y la topología de red utilizados para interconectar varios nodos del sistema.

  1. Independencia de la base de datos

Un sistema ideal de administración de bases de datos distribuidas debe ser capaz de admitir la interoperabilidad entre sistemas DBMS que se ejecutan en diferentes nodos, incluso si estos sistemas DBMS son diferentes .

Todos los participantes en los sistemas de administración de bases de datos distribuidos deben usar interfaces estándares comunes (API) para interactuar entre ellos y participar en el procesamiento distribuido de la base de datos.

Para que una base de datos distribuida esté bien implementada debe al menos cumplir todas las reglas anteriores mencionadas. Está claro que cada proyecto o implementación requiere y tiene sus propias limitaciones. Tanto como el software o hardware con el que se tomará como base de trabajo.

Lo importante es conocer la distribución, la redundancia, la transparencia, la recuperación de fallos y su independencia.

Bibliografía

Igor Lukyanov. C.J. Date’s 12 Distributed DBMS Rules. 2018, de appservgrid. Sitio web:http://www.appservgrid.com/mywww/html/infradb.htm

Publicado por carloscordova

Creador y administrador del blog

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *