Facultad Politécnica

Trabajo Práctico de Base de Datos 2

Profesora: Helena Gómez

Alumnos:
• Jorge M. Carvallo G.
• José Morínigo
 Introducción
Una de las principales motivaciones para el desarrollo de sistemas de bases de datos es
el deseo de integrar los datos operacionales de una organización y proporcionar un
acceso controlado a esos datos. Aunque la integración y el acceso controlado pueden
implicar la necesidad de utilizar mecanismos de descentralización, el objetivo en
realidad no es ese. De hecho, el desarrollo de redes informáticas promueve el modo
descentralizado de trabajo. Esta técnica descentralizada imita la estructura
organizativa de muchas empresas, que están distribuidas de modo lógico en divisiones,
departamentos, proyectos, etc., y están distribuidas de modo físico en oficinas,
fábricas e instalaciones, manteniendo cada unidad sus propios datos operacionales. La
posibilidad de compartir los datos y la eficiencia del acceso a los mismos puede
mejorarse mediante el desarrollo de sistemas de bases de datos distribuidas que
reflejen esta estructura organizativa, que hagan que los datos de todas las unidades
sean accesibles y que almacenen esos datos en algún lugar próximo a aquel donde más
frecuentemente se utilice.
 1- Concepto
Una base de datos distribuida es un conjunto de múltiples bases de datos
lógicamente relacionadas las cuales se encuentran distribuidas entre diferentes sitios
interconectados por una red de comunicaciones, los cuales tienen la capacidad de
procesamiento autónomo lo cual indica que puede realizar operaciones locales o
distribuidas. Un sistema de Bases de Datos Distribuida es un sistema en el cual
múltiples sitios de bases de datos están 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 los datos estuvieran siendo accedidos de forma local.

Arquitecturas
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:
Autonomía de diseño: Habilidad de un componente del para decidir cuestiones
relacionadas a su propio diseño.
Autonomía de comunicación: Habilidad de un componente del para decidir como y
cuando comunicarse con otros SMBD.
Autonomía de ejecución: Habilidad de un componente del para ejecutar operaciones
locales como quiera.

2.-Ventajas y desventajas de base de datos distribuidas.

Ventajas
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).
Desventajas
Complejidad - Se debe asegurar que la base de datos sea transparente, se debe lidiar
con varios sistemas diferentes que puden 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.

3- Reglas que deben cumplirse en un sistema distribuido.

a. Autonomía Local.
Los sitios de un sistema distribuido deben ser autónomos . La autonomía local significa
que todas las operaciones en un sitio dado se controlan en ese sitio; ningún sitio X
deberá depender de algún otro sitio Y para su buen funcionamiento (pues de otra
manera el sitio X podría ser incapaz de trabajar, aunque no tenga en sí problema
alguno, si cae el sitio Y, situación a todas luces indeseable). La autonomía local implica
también un propietario y una administración locales de los datos, con responsabilidad
local : todos los datos pertenecen " en realidad" a una base de datos local, aunque
sean accesibles desde algún sitio remoto. Por tanto, las cuestiones de seguridad,
integridad y representación en almacenamiento de los datos locales permanecen bajo
el control de la instalación local.
b. No dependencia de un sitio central.
La autonomía local implica que todos los sitios deben tratarse igual; no debe haber
dependencia de un sitio central "maestro" para obtener un servicio central, como por
ejemplo un procesamiento centralizado de las consultas o una administración
centralizada de las transacciones, de modo que todo el sistema dependa de ese sitio
central. Este segundo objetivo es por tanto un corolario del primero ( si se logra el
primero, se logrará pro fuerza el segundo ) . Pero la "no dependencia de un sitio
central" es deseable por sí misma, aun si no se logra la autonomía local completa. Por
ello vale la pena expresarlo como un objetivo separado.
La dependencia de un sitio central sería indeseable al menos por las siguientes razones
: en primer lugar, ese sitio central podrí ser un cuello de botella; en segundo lugar, el
sistema sería vulnerable ; si el sitio central sufriera un desperfecto, todo el sistema
dejaría de funcionar.
c. Operación continua.
En un sistema distribuido, lo mismo que en uno no distribuido, idealmente nunca
debería haber necesidad de apagar a propósito el sistema . Es decir, el sistema nunca
debería necesitar apagarse para que se pueda realizar alguna función, como añadirse
un nuevo sitio o instalar una versión mejorada del DBMS en un sitio ya existente.
d. Independencia con respecto a la localización.
La idea básica de la independencia con respecto a la localización (también conocida
como transparencia de localización) es simple : no debe ser necesario que los usuarios
sepan dónde están almacenados físicamente los datos, sino que más bien deben poder
comportarse - al menos desde un punto de vista lógico - como si todos los datos
estuvieran almacenados en su propio sitio local. La independencia con respecto a la
localización es deseable porque simplifica los programas de los usuarios y sus
actividades en la terminal. En particular, hace posible la migración de datos de un sitio
a otro sin anular la validez de ninguno de esos programas o actividades. Esta
posibilidad de migración es deseable pues permite modificar la distribución de los
datos dentro de la red en respuesta a cambios en los requerimientos de desempeño.
e. Independencia con respecto a la fragmentación.
Un sistema maneja fragmentación de los datos si es posible dividir una relación en
partes o "fragmentos" para propósitos de almacenamiento físico. La fragmentación es
deseable por razones de desempeño: los datos pueden almacenarse en la localidad
donde se utilizan con mayor frecuencia, de manera que la mayor parte de las
operaciones sean sólo locales y se reduzca al tráfico en la red. Por ejemplo, la relación
empleados EMP podría fragmentarse de manera que los registros de los empleados de
Nueva York se almacenen en el sitio de Nueva York, en tanto que los registros de los
empleados de Londres se almacenan en el sitio de Londres.
Existen en esencia dos clases de fragmentación, horizontal y vertical, correspondientes
a las operaciones relacionales de restricción y proyección; respectivamente. En
términos más generales, un fragmento puede ser cualquier subrelación arbitraria que
pueda derivarse de la relación original mediante operaciones de restricción y
proyección ( excepto que, en el caso de la proyección es obvio que las proyecciones
deben conservar la clave primaria de la relación original ). La reconstrucción de la
relación original a partir de los fragmentos se hace mediante operaciones de reunión y
unión apropiadas ( reunión en el caso de fragmentación vertical, y la unión en casos de
fragmentación horizontal ).
Ahora llegamos a un punto principal : un sistema que maneja la fragmentación de los
datos deberá ofrecer también una independencia con respecto a la fragmentación
(llamada también transparencia de fragmentación). La independencia con respecto a la
fragmentación ( al igual que la independencia con respecto a la independencia con
respecto a la localización) es deseable porque simplifica los programas de los usuarios
y sus actividades en la terminal.
f. Independencia de réplica.
Un sistema maneja réplica de datos si una relación dada (ó en términos más generales,
un fragmento dado en una relación) se puede representar en el nivel físico mediante
varias copias almacenadas o réplicas , en muchos sitios distintos.
La réplica es deseable al menos por dos razones : en primer lugar, puede producir un
mejor desempeño (las aplicaciones pueden operar sobre copias locales en vez de tener
que comunicarse con sitios remotos) ; en segundo lugar, también puede significar una
mejor disponibilidad (un objeto estará disponible para su procesamiento en tanto esté
disponible por lo menos una copia, al menos para propósitos de recuperación). La
desventaja principal de las réplicas es desde luego que cuando se pone al día un cierto
objeto copiado, deben ponerse al día todas las réplicas de ese objeto : el problema de
la propagación de actualizaciones.
g. Procesamiento distribuido de consultas.
En este aspecto debemos mencionar dos puntos amplios.
Primero consideremos la consulta "obtener los proveedores de partes rojas en
Londres". Supongamos que el usuario está en la instalación de Nueva York y los datos
están en el sitio de Londres. Supongamos también que son n</I< los registros
proveedor que satisfacen solicitud. Si sistema es relacional, consulta implicará en
esencia dos mensajes : uno transmitir la solicitud Nueva York a Londres, y otro para
devolver el conjunto resultante de n registros de Londres a Nueva York. Si, por otro
lado, el sistema no es relacional, sino de un registro a la vez, la consulta implicará en
esencia 2n mensajes : n de Nueva York a Londres solicitando el siguiente registro, y n
de Londres a Nueva York para devolver ese siguiente registro
h. Manejo distribuido de transacciones.
El manejo de transacciones tiene dos aspectos principales, el control de recuperación y
el control de concurrencia, cada uno de los cuales requiere un tratamiento más amplio
en el ambiente distribuido. Para explicar ese tratamiento más amplio es preciso
introducir primero un término nuevo, "agente". En un sistema distribuido, una sola
transacción puede implicar la ejecución de código en varios sitios ( en particular puede
implicar a actualizaciones en varios sitios ). Por tanto, se dice que cada transacción
está compuesta de varios agentes, donde un agente es el proceso ejecutado en
nombre de una transacción dada en determinado sitio. Y el sistema necesita saber
cuándo dos agentes son parte de la misma transacción; por ejemplo, es obvio que no
puede permitirse un bloqueo mutuo entre dos agentes que sean parte de la misma
transacción. La cuestión especifica del control de recuperación; : para asegurar, pues
que una transacción dada sea atómica ( todo o nada ) en el ambiente distribuido, el
sistema debe asegurarse de que todos los agentes correspondientes a esa transacción
se comprometan al unísono o bien que retrocedan al unísono. Este efecto puede
lograrse mediante el protocolo de compromiso en dos fases.
En cuanto al control de concurrencia, esta función en un ambiente distribuido estará
basada con toda seguridad en el bloqueo, como sucede en los sistemas no distribuidos.
i. Independencia con respecto al equipo.
En realidad, no hay mucho que decir acerca de este tema, el título lo dice todo. Las
instalaciones de cómputo en el mundo real por lo regular incluyen varias máquinas
diferentes -máquinas IBM, DEC, HP, UNISYS, PC etc- y existe una verdadera necesidad
de poder integrar los datos en todos esos sistemas y presentar al usuario "una sola
imagen del sistema". Por tanto conviene ejecutar el mismo DBMS en diferentes
equipos, y además lograr que esos diferentes equipos participen como socios iguales
en un sistema distribuido.
j. Independencia con respecto al sistema operativo.
Este objetivo es un corolario del anterior. Es obvia la conveniencia no sólo de poder
ejecutar el mismo DBMS en diferentes equipos, sino también poder ejecutarlo en
diferentes sistemas operativos y lograr que una versión MVS y una UNIX y una PC/DOS
participen todas en el mismo sistema distribuido.
k. Independencia con respecto a la red.
Si el sistema ha de poder manejar múltiples sitios diferentes, con equipo distinto y
diferentes sistemas operativos, resulta obvia la conveniencia de poder manejar
también varias redes de comunicación distintas.

l. Independencia con respecto al DBMS

Bajo este título consideramos las implicaciones de relajar la suposición de
homogeneidad estricta. Puede alegarse que esa suposición es quizá demasiado rígida.
En realidad, no se requiere sino que los DBMS en los diferentes sitios manejen todos la
misma interfaz ; no necesitan ser por fuerza copias del mismo sistema.

4- Transparencia en un sistema de base de datos distribuidas. Niveles.

El propósito de establecer una arquitectura de un sistema de bases de datos

distribuidas es ofrecer un nivel de transparencia adecuado para el manejo de la
información.
La transparencia se define como la separación de la semántica de alto nivel de un
sistema de los aspectos de bajo nivel relacionados a la implementación del mismo. Un
nivel de transparencia adecuado permite ocultar los detalles de implementación a las
capas de alto nivel de un sistema y a otros usuarios.
El sistema de bases de datos distribuido permite proporcionar independencia de los
datos.
La independencia de datos se puede dar en dos aspectos: lógica y física.

a. Independencia lógica de datos. Se refiere a la inmunidad de las aplicaciones de

usuario a los cambios en la estructura lógica de la base de datos. Esto permite que un
cambio en la definición de un esquema no debe afectar a las aplicaciones de usuario.
Por ejemplo, el agregar un nuevo atributo a una relación, la creación de una nueva
relación, el reordenamiento lógico de algunos atributos.

b. Independencia física de datos. Se refiere al ocultamiento de los detalles sobre las

estructuras de almacenamiento a las aplicaciones de usuario. la descripción física de
datos puede cambiar sin afectar a las aplicaciones de usuario. Por ejemplo, los datos
pueden ser movidos de un disco a otro, o la organización de los datos puede cambiar.

La transparencia al nivel de red se refiere a que los datos en un SBDD se accedan sobre
una red de computadoras, sin embargo, las aplicaciones no deben notar su existencia.
La transparencia al nivel de red conlleva a dos cosas:
a. Transparencia sobre la localización de datos. el comando que se usa es
independiente de la ubicación de los datos en la red y del lugar en donde la operación
se lleve a cabo. Por ejemplo, en Unix existen dos comandos para hacer una copia de
archivo. Cp se utiliza para copias locales y rcp se utiliza para copias remotas. En este
caso no existe transparencia sobre la localización.
b. Transparencia sobre el esquema de nombramiento. Lo anterior se logra
proporcionando un nombre único a cada objeto en el sistema distribuido. Así, no se
debe mezclar la información de la localización con en el nombre de un objeto.
La transparencia sobre replicación de datos se refiere a que si existen réplicas de
objetos de la base de datos, su existencia debe ser controlada por el sistema no por el
usuario. Se debe tener en cuenta que cuando el usuario se encarga de manejar las
réplicas en un sistema, el trabajo de éste es mínimo por lo que se puede obtener una
eficiencia mayor. Sin embargo, el usuario puede olvidarse de mantener la consistencia
de las réplicas teniendo así datos diferentes.
La transparencia a nivel de fragmentación de datos permite que cuando los objetos de
la bases de datos están fragmentados, el sistema tiene que manejar la conversión de
consultas de usuario definidas sobre relaciones globales a consultas definidas sobre
fragmentos. Así también, será necesario mezclar las respuestas a consultas
fragmentadas para obtener una sola respuesta a una consulta global. El acceso a una
base de datos distribuida debe hacerse en forma transparente.
En resumen, la transparencia tiene como punto central la independencia de datos.
La responsabilidad sobre el manejo de transparencia debe estar compartida tanto por
el sistema operativo, el sistema de manejo de bases de datos y el lenguaje de acceso a
la base de datos distribuida. Entre estos tres módulos se deben resolver los aspectos
sobre el procesamiento distribuido de consultas y sobre el manejo de nombres de
objetos distribuidos.

5- Estrategia de distribución de datos. Ventajas y desventajas

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 cuál lo desea hacer. Para esto existen cuatro alternativas principales:
centralizada, replicada, fragmentada, e híbrida. La forma centralizada 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.
Replicadas
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.
Particionadas
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
tres formas:
Horizontal: Los fragmentos son subconjuntos de una tabla (análogo a un restringir)
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 R1,R2, ... , Rn, cada elemento de
la data de R debe estar en algún Ri.
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 Ri este elemento no puede estar en ningún Rk (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.
Híbrida
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.

6 - Diseño de una base de datos distribuida. Estrategias

En el enfoque Top-Down se comienza diseñando el esquema global, luego
se concibe la fragmentación de la BD y la localización de los fragmentos en los sitios. Se
completa ejecutando, en cada sitio, el diseño físico de los datos.
Por otro lado el enfoque Bottom-Up se basa en la integración de esquemas ya creados
en un esquema global a partir de las BD existentes.

7- Seguridad de los datos

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 cuál 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.
Conceptos
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 de 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.

8 - Diccionario de datos
El DBMS debiera incluir una función de diccionarios de datos (Meta _ datos), se
puede decir que es una base de Datos del sistema y no del usuario cuyo contenido
puede considerarse como “Datos acerca de los Datos” que en el fondo son definiciones
de objetos de datos y otros objetos del sistema.

9 - Procesamiento de consultas. Estrategias y optimización

Existen varios medios para calcular la respuesta a una consulta. En el caso de
sistemas centralizado, el criterio principal para determinar el costo de una estrategia
específica es el número de accesos al disco. En un sistema distribuido es preciso tener
en cuenta otros factores, como son:
El costo de transmisión de datos en la red.
El beneficio potencial que supondría en la ejecución el que varias localidades
procesaran en paralelo partes de la consulta.
El costo relativo de la transferencia de datos en la red y la transferencia de datos entre
la memoria y el disco varía en forma considerable, dependiendo del tipo de red y de la
velocidad de los discos. Por tanto, en un caso general, no podemos tener en cuenta
solo los costos del disco o los de la red. es necesario llegar a un equilibrio adecuado
entre los dos.
 Conclusión
A lo largo de este documento se ha intentado dar una visión global y genérica de los
conceptos y características que contiene el diseño de una base de datos distribuida.
También debería tenerse presente la existencia de enfoques de fragmentación
distintos y, posiblemente, más complejos, pero se debe pensar que más eficientes.
Pese a la aparición de los métodos de bases de datos distribuidas hace ya años, parece
que el salto de lo centralizado a lo distribuido a escala comercial está por venir.
Todavía no se ha extendido suficientemente el esquema distribuido, pero se espera
que próximamente se produzca el avance definitivo. Considere los dos componentes
básicos de los sistemas de bases de datos distribuidos (la propia base de datos y la red
de ordenadores) y piense en la situación actual de la informática. Si las bases de datos
es una de las ramas más antiguas e importantes de la informática, muchas empresas
compran ordenadores para dedicarlos exclusivamente a la gestión de sus datos y,
como parece ser que se ha asumido por parte de todo tipo de empresarios los
beneficios que acarrea la conexión de los ordenadores, la instalación de una red, se
puede concluir diciendo que el terreno ya está abonado para su extensión comercial.
 Bibliografía

http://www.mitecnologico.com/Main/DiccionarioDeDatos

Universidad de Castilla-La Mancha – Bases de datos distribuidas

http://www.abcdatos.com/tutoriales/tutorial/l3724.html