Definiciones

1. Instituto Politécnico Nacional
Escuela Superior de Cómputo
Distributed Data Base
Hernández Rubio Erika
3CM6
Gutiérrez González Gustavo
Resumen

2. Resumen
1.1 Distributed data processing
1.2 What is a Distributed database system?
1.3 Data Delivery Alternatives
1.4 Promises of DDBSs
1.4.1 Transparent Management of Distributed and Replicated Data
1.4.1.1 Data Independence
1.4.1.2 Network Transparency
1.4.1.3 Replication Transparency
1.4.1.4 Fragmentation Transparency
1.4.1.5 Who should Provide Transparency
1.4.2 Reliability Through Distributed Transactions
1.4.3 Improved Performance
1.4.4 Easier System Expansion
1.5 Complications Introduced by Distribution
1.6 Design Issues
1.6.1 Distributed Database Design
1.6.2 Distributed Directory Management
1.6.3 Distributed Query Processing
1.6.4 Distributed Concurrency Control
1.6.5 Distributed Deadlock Management
1.6.6 Reliability of Distributed DBMS
1.6.7 Replication
1.6.8 Relationship among Problems

3. 1.1 Distributed data processing
El sistema de base de datos distribuido se trata de una serie de procesos autónomos de
elementos no necesariamente homogéneos que están interconectados por una red de
computadora y que cooperan en el desempeño de las tareas asignadas. Se asume
implícitamente que un sistema de base de datos distribuidos en su lógica o elementos
de procesamiento se distribuyen. La ejecución de varias tareas podría distribuirse en
lugar de ser realizada por un sistema informático.
1.2 What is a Distributed database system?
Una base de datos distribuida como una colección de múltiples, lógicamente inter-
relacionadas bases de datos distribuidas a través de una red informática.
El DBMS se define como el sistema de software que permite la gestión de la base de
datos distribuida y hace que la distribución sea transparente para los usuarios.
El DDBS se utiliza para referirse conjuntamente a la base de datos distribuida y el DBMS
distribuido.
Los dos términos importantes en estos las definiciones están "lógicamente
interrelacionadas" y "distribuidas a través de una red informática".
1.3 Data Delivery Alternatives
En las bases de datos distribuidas, los datos se "envían" desde los sitios donde se
almacenan donde se plantea la consulta.
Se caracterizan las alternativas de entrega de datos a lo largo de tres dimensiones
ortogonales: modos de entrega, frecuencia y métodos de comunicación.
Los modos de entrega alternativos son solo extracción, solo inserción e híbrido. En el
modo pullonly de entrega de datos, se inicia la transferencia de datos de los servidores
a los clientes.

4. La principal característica de la entrega basada en pull es que la llegada de nuevos
elementos de datos o actualizaciones de elementos de datos existentes se llevan a cabo
en un servidor sin notificación a los clientes a menos que los clientes sondean
explícitamente el servidor.
Hay tres medidas de frecuencia típicas que se pueden utilizar para clasificar regularidad
de la entrega de datos. Son periódicos, condicionales y ad hoc o irregulares.
En la entrega periódica, los datos se envían desde el servidor a los clientes a intervalos
regulares. Los intervalos se pueden definir por defecto del sistema o por los clientes que
utilizan sus perfiles.
En la entrega condicional, los datos se envían desde servidores siempre que se
cumplan determinadas condiciones instalados por los clientes en sus perfiles están
satisfechos. Tales condiciones pueden ser tan simples como un lapso de tiempo dado
o tan complicado como las reglas de evento-condición-acción.
El tercer componente del espacio de diseño de alternativas de entrega de información
es el Método de comunicación. Estos métodos determinan las diversas formas en que
los servidores y los clientes se comunican para entregar información a los clientes.
1.4 Promises of DDBSs
Las ventajas de los DDBS van desde razones para la descentralización hacia una mejor
economía. Entre las promesas de la tecnología DDBS están:
Gestión transparente de datos distribuidos y replicados, fiable acceso a los datos a
través de transacciones distribuidas, rendimiento mejorado y expansión del sistema.
1.4.1 Transparent Management of Distributed and Replicated Data
La transparencia se refiere a la separación de la semántica de nivel superior de un
sistema de problemas de implementación de nivel inferior.
La ventaja de un DBMS completamente transparente es el alto nivel de soporte que
proporciona para el desarrollo de aplicaciones complejas.
Para que un sistema maneje adecuadamente este tipo de consultas en una base de
datos distribuida, fragmentada y replicada, necesita poder lidiar con varios tipos de
transparencias.
1.4.1.1 Network Transparency
En los sistemas de bases de datos centralizados, el único recurso disponible que debe
protegerse del usuario son los datos (es decir, el sistema de almacenamiento). En un
entorno de base de datos distribuida, sin embargo, hay un segundo recurso que debe
administrarse en mucho de la misma manera: la red.
Se puede considerar la transparencia de la red desde el punto de vista de los servicios
proporcionado o los datos. Desde la primera perspectiva, es deseable tener un uniforme
medios por los que se accede a los servicios. Desde una perspectiva DBMS, la
distribución. La transparencia requiere que los usuarios no tengan que especificar dónde
se encuentran los datos.

5. 1.4.1.2 Replication Transparency
La replicación ayuda al rendimiento, ya que se pueden establecer requisitos de usuario
diversos y conflictivos. Si los datos se replican la cuestión de la transparencia, el usuario
debe ser consciente de la existencia de copias o si el sistema debe manejar la gestión
de copias y el usuario debe actuar como si hubiera una única copia de los datos.
La transparencia de la replicación se refiere solo a la existencia de réplicas, no a su
ubicación real. Tenga en cuenta también que distribuir estas réplicas a través de la red
de una manera transparente es el dominio de la red transparencia.
1.4.1.3 Fragmentation Transparency
La forma final de transparencia que debe abordarse en el contexto de un sistema de
base de datos distribuido es el de la transparencia de la fragmentación.
La fragmentación puede reducir los efectos negativos de replicación. Cada réplica no es
la relación completa, sino solo un subconjunto de ella; así menos espacio es necesario
y se necesitan gestionar menos elementos de datos.
Hay dos tipos generales de alternativas de fragmentación. En un caso, llamado
fragmentación horizontal, una relación se divide en un conjunto de sub-relaciones cada
una de los cuales tienen un subconjunto de las tuplas (filas) de la relación original. La
segunda alternativa es la fragmentación vertical donde cada sub-relación se define en
un subconjunto de los atributos (columnas) de la relación original.
1.4.1.4 Who should Provide Transparency
Para proporcionar un acceso fácil y eficiente por los usuarios novatos a los servicios del
DBMS, uno querría tener una transparencia total, involucrando a todos los diversos tipos
que discutimos. Sin embargo, el nivel de la transparencia es inevitablemente un
compromiso entre la facilidad de uso, la dificultad y gastos generales de proporcionar
altos niveles de transparencia.
1.4.2 Reliability Through Distributed Transactions
Los DBMS distribuidos están destinados a mejorar la confiabilidad, ya que se han
replicado componentes y, por lo tanto, eliminar puntos únicos de falla. El fracaso de un
solo sitio, o la falla de un enlace de comunicación que hace que uno o más sitios sean
inaccesibles, no es suficiente para derribar todo el sistema.

6. 1.4.3 Improved Performance
El caso a favor del rendimiento mejorado de los DBMS distribuidos suele basado en dos
puntos. Primero, un DBMS distribuido fragmenta la base de datos conceptual,
permitiendo que los datos se almacenen muy cerca de sus puntos de uso (también
llamados datos localización). Esto tiene dos ventajas potenciales:
1. Dado que cada sitio maneja solo una parte de la base de datos, la disputa por la CPU
y los servicios de E / S no son tan severos como para las bases de datos centralizadas.
2. La localización reduce las demoras en el acceso remoto que generalmente están
involucradas redes de área (por ejemplo, la propagación mínima de mensajes de ida y
vuelta el retraso en los sistemas basados en satélites es de aproximadamente 1
segundo).
1.4.4 Easier System Expansion
En un entorno distribuido, es mucho más fácil acomodar el aumento de tamaños de la
base de datos. Rara vez son necesarias grandes revisiones del sistema; la expansión
generalmente puede ser manejado agregando potencia de procesamiento y
almacenamiento a la red. Puede No ser posible obtener un aumento lineal de "potencia",
ya que esto también depende de los gastos generales de distribución. Sin embargo, aún
son posibles mejoras significativas.
1.5 Complications Introduced by Distribution
Los problemas encontrados en los sistemas de bases de datos adquieren complejidad
adicional en un entorno distribuido, aunque los principios básicos subyacentes son los
mismos. Además, esta complejidad adicional da lugar a nuevos problemas influidos
principalmente por tres factores.
Primero, los datos se pueden replicar en un entorno distribuido. Una base de datos
distribuida Puede diseñarse para que toda la base de datos, o partes de ella, resida en
diferentes sitios. de una red informática.
En segundo lugar, si algunos sitios fallan (por ejemplo, por un mal funcionamiento del
hardware o del software), o si algunos enlaces de comunicación fallan (haciendo que
algunos de los sitios sean inaccesibles) mientras un se está ejecutando la actualización,
el sistema debe asegurarse de que los efectos se reflejen en los datos que residen en
los sitios fallidos o inalcanzables tan pronto como el sistema pueda recuperarse del
fracaso.
El tercer punto es que, dado que cada sitio no puede tener información instantánea
sobre las acciones que se están llevando a cabo actualmente en los otros sitios, las
sincronizaciones de las transacciones en varios sitios son considerablemente más
difíciles que en un sistema centralizado.
1.6 Design Issues
Tomando en cuenta las promesas de la tecnología DBMS distribuida, destacando los
desafíos que deben superarse para hacerlos realidad. Nos basamos en esta discusión
presentando los problemas de diseño que surgen al construir un DBMS distribuido.

7. 1.6.1 Distributed Database Design
Hay dos alternativas básicas para colocar datos: particionados (o no replicados) y
replicados. En el esquema particionado la base de datos se divide en varias particiones
separadas, cada una de las cuales se coloca en un sitio diferente. Los diseños
replicados se pueden replicar completamente (también llamados duplicado) donde toda
la base de datos se almacena en cada sitio, o parcialmente replicado (o parcialmente
duplicado) donde cada partición de la base de datos se almacena en más de un sitio,
pero no en todos los sitios. Los dos problemas fundamentales del diseño son la
fragmentación, la separación de la base de datos en particiones llamadas fragmentos,
y la distribución, la distribución óptima de fragmentos
1.6.2 Distributed Directory Management
Un directorio contiene información (como descripciones y ubicaciones) sobre datos
elementos de la base de datos. Los problemas relacionados con la gestión de directorios
son de naturaleza similar al problema de ubicación de la base de datos discutido en la
sección anterior. Un directorio puede ser global para todo el DDBS o local para cada
sitio; se puede centralizar en uno sitio o distribuido en varios sitios; puede haber una
sola copia o varias copias.
1.6.3 Distributed Query Processing
El procesamiento de consultas se ocupa del diseño de algoritmos que analizan
consultas y convierten convertirlos en una serie de operaciones de manipulación de
datos. El problema es como decidir en una estrategia para ejecutar cada consulta a
través de la red de la manera más rentable manera, sin embargo, se define el costo. Los
factores a considerar son la distribución de datos, costos de comunicación y falta de
suficiente información disponible localmente.
1.6.4 Distributed Concurrency Control
El control de concurrencia implica la sincronización de accesos a la base de datos
distribuida, de manera que se mantenga la integridad de la base de datos. Es, sin duda
alguna, uno de los problemas más estudiados en el campo de DDBS. La concurrencia.
El problema de control en un contexto distribuido es algo diferente que en un contexto
centralizado marco de referencia. Uno no solo tiene que preocuparse por la integridad
de una sola base de datos, sino también sobre la consistencia de múltiples copias de la
base de datos. La condición que requiere que todos los valores de múltiples copias de
cada elemento de datos converjan en el mismo el valor se llama consistencia mutua.
1.6.5 Distributed Deadlock Management
El problema del interbloqueo en los DDBS es de naturaleza similar al que se encuentra
al operar sistemas. La competencia entre usuarios por acceder a un conjunto de
recursos puede resultar en un interbloqueo si el mecanismo de sincronización se basa
en el bloqueo. Las conocidas alternativas de prevención, evitación y detección /
recuperación también aplicar a DDBS.

8. 1.6.6 Reliability of Distributed DBMS
Una de las ventajas potenciales de los sistemas distribuidos es una mayor fiabilidad y
disponibilidad. Es importante que se proporcionen mecanismos para garantizar la
coherencia de la base de datos, así como para detectar fallas y recuperarse de ellas. La
implicación para DDBS es que cuando ocurre una falla y varios sitios se vuelven
inoperables o inaccesibles, las bases de datos en los sitios operativos permanecen
consistentes y actualizadas.
Además, cuando el sistema informático o la red se recupera de la falla, Los DDBS
deberían poder recuperar y actualizar las bases de datos de los sitios fallidos.
Esto puede resultar especialmente difícil en el caso de particiones de red, donde los
sitios están divididos en dos o más grupos sin comunicación entre ellos.
1.6.7 Replication
Si la base de datos distribuida se replica (parcial o totalmente), es necesario
implementar protocolos que garantizan la coherencia de las réplicas, es decir, copias
del mismo elemento de datos tienen el mismo valor. Estos protocolos pueden estar
ansiosos porque fuerzan las actualizaciones para aplicarse a todas las réplicas antes de
que se complete la transacción, o pueden ser perezoso para que la transacción actualice
una copia (llamada maestra) desde la cual se actualiza se propagan a los demás una
vez finalizada la transacción.
1.6.8 Relationship among Problems
Naturalmente, estos problemas no están aislados unos de otros. Cada problema se ve
afectado por las soluciones encontradas para los demás, y a su vez afecta el conjunto
de soluciones factibles para ellos. En esta sección discutimos cómo se relacionan.
Los diseños de las bases de datos distribuidas afectan a muchas áreas. Afecta a la
gestión de directorios, porque la definición de los fragmentos y su ubicación determinan
el contenido del directorio (o directorios) así como las estrategias que se pueden
emplear para administrarlos.
La replicación de fragmentos cuando se distribuyen afecta la concurrencia estrategias
de control que podrían emplearse.
Existe una fuerte relación entre el problema de control de simultaneidad, el problema de
gestión de interbloqueos y los problemas de confiabilidad. Esto es de esperar, ya que
juntos suelen denominarse problema de gestión de transacciones. La concurrencia y el
algoritmo de control que se emplea determinarán si un interbloqueo separado se
requiere facilidad de manejo.
Surge la necesidad de protocolos de replicación si la distribución de datos implica
réplicas. Existe una fuerte relación entre los protocolos de replicación y técnicas de
control de concurrencia, ya que ambas se ocupan de la consistencia de los datos, pero
desde perspectivas diferentes.

9. Referencias:
[1]https://e.edim.co/126467004/kU11gcJX7Q4ZUVo9.pdf?response-content-
disposition=filename%3D%22_M._Tamer__zsu__Patrick_Valduriez__Principles_of__BookFi.org_.pdf%22%3B%20filename%2A%3DUTF-
8%27%27%255BM._Tamer_%25C3%2596zsu%252C_Patrick_Valduriez%255D_Principles_of_%2528BookFi.org%2529.pdf&Expires=1601744609&Signature
=OgNEwRZl5jX33oupeZQQNpYk45p01jCanJr5A5oH0bJYQ53Pq55ha6C21zN3lceG~TrvCLNbziGLiVD5CpL5jg~qe2EMkJSMZ~DedyC7qbeE672a~Vnn48-
IWUFbXnld9xsAwWnIk-2a9ZMit5OkDCf2kxHx3mEF8i65dkE4sPXkj86bu~9QpX5hWxrx6~3QIkj8CkbTO-
6piwfvisrw1aJ0QZfu3aQgF0lKK5NB61aGSs23~fEHceLDpfjerePaFpVr2MWi5TcWuP~sD2ueXDPH7qVRPJiSqXI4Xr3g4Q0oU-
qANcGqWfMBWxEtZwOkaaITNx8EtZZJMplVlq-7gw__&Key-Pair-Id=APKAJMSU6JYPN6FG5PBQ