INSTITUTO TECNOLOGICO

de
villahermosa
ING EN TECNOLOGIA DE LA INFORMACION
Y LAS COMUNICACIONES
MATERIA:
BASE DE DATOS DISTRIBUIDAS
TEMA:
12 REGLAS DE LAS BASE DE DATOS
DISTRIBUIDAS

ALUMNOS:

FATIMA MENENDEZ CALLES

Villahermosa, Tab. 05 DE SEP. 2014.

INDICE

INTRODUCCION..1

1. PRINCIPIO FUNDAMENTAL DE LAS BASE DE DATOS DISTRIBUIDAS ..2

2. LAS 12 REGLAS .3

2.1 Autonoma Local ..3

2.2 No dependencia de un sitio central. .3
2.3 Operacin contina. .....3
2.4 Independencia con respecto a la localizacin ..3
2.5 Independencia con respecto a la fragmentacin. ..4
2.6 Independencia de rplica. 5
2.7 Procesamiento distribuido de consultas. ..5
2.8 Manejo distribuido de transacciones. ....6
2.9 Independencia con respecto al equipo. .6
2.10 Independencia de rplica. ...6
2.11 Independencia con respecto a la red. ..7
2.12 Independencia con respecto al DBMS ...7
CONCLUSION ....8
REFERENCIA BIBLIOGRAFICA .9

INTRODUCCCION

Una Base de Datos Distribuida (BDD) es una coleccin de datos distribuidos en diferentes
nodos de una red de computadoras. Cada sitio de la red es autnomo, puede ejecutar
aplicaciones locales y al menos una aplicacin global, lo cual requiere el acceso a datos,
ubicados en varios sitios, usando un subsistema de comunicacin

Es importante saber lo fundamental para hacer una base de datos distribuidas ya que por
medio de ellas podemos resolver problemas que se nos presentan a diario en nuestra vida
cotidiana, para ello necesitamos saber alguna reglas bsicas o fundamentales para poder
hacer una base de datos distribuidas.

Los Sistemas de Bases

de
Datos Distribuidas
representan
ms
naturalmente
la estructura geogrficamente descentralizada de una organizacin, aumentan la
disponibilidad de los datos, reducen el trfico de comunicacin y es justificable, adems,
por el abaratamiento de los costos en el equipamiento y la infraestructura
de comunicaciones de las redes de computadoras.

1. El principio fundamental de las bases de datos distribuidas:

Desde el punto de vista del usuario, un sistema distribuido deber ser idntico un sistema
no distribuido. En otras palabras, los usuarios de un sistema distribuido debern
comportarse exactamente como si el sistema no estuviera distribuido. Todos los problemas
de los sistemas distribuidos son (o deberan ser) internos o a nivel de realizacin, no
externos o a nivel del usuario. Llamaremos al principio fundamental recin identificado la
"regla cero" de los sistemas distribuidos. La regla cero conduce a varios objetivos o reglas
secundarios - doce en realidad- siguientes:
Autonoma local.
No dependencia de un sitio central.
Operacin contina.
Independencia con respecto a la localizacin.
Independencia con respecto a la fragmentacin.
Independencia de rplica.
Procesamiento distribuido de consultas.
Manejo distribuido de transacciones.
Independencia con respecto al equipo.
Independencia con respecto al sistema operativo.
Independencia con respecto a la red.
Independencia con respecto al DBMS.
Estas doce reglas no son todas independientes entre s, ni son por fuerza exhaustivas, ni
tienen todas la misma importancia (diferentes usuarios darn diferentes grados de
importancia a diferentes reglas en diferentes ambientes). Sin embargo, s son tiles como
fundamento para entender la tecnologa distribuida y como marco de referencia para
caracterizar la funcionalidad de sistemas distribuidos especficos.
Un ltimo punto introductorio: es importante distinguir los sistemas distribuidos de bases
de datos verdaderos, generalizados, de los sistemas que tan solo ofrecen algn tipo de
acceso remoto a los datos (llamados a veces sistemas de procesamiento distribuido o
sistemas de red). En un " sistema de acceso remoto a los datos ", el usuario podra ser capaz
de trabajar con datos de un sitio remoto, o aun con datos de varios sitios remotos al mismo
tiempo, pero " se notan las costuras; el usuario definitivamente est consciente (en mayor
o menor grado) de que los datos son remotos, y debe comportarse de manera acorde. En
cambio, en un sistema distribuido verdadero, las costuras son invisibles.

1
2

2. Las doce reglas.

2.1 Autonoma Local.
Los sitios de un sistema distribuido deben ser autnomos. La autonoma local significa que
todas las operaciones en un sitio dado se controlan en ese sitio; ningn sitio X deber
depender de algn otro sitio Y para su buen funcionamiento (pues de otra manera el sitio X
podra ser incapaz de trabajar, aunque no tenga en s problema alguno, si cae el sitio Y,
situacin a todas luces indeseable). La autonoma local implica tambin un propietario y
una administracin locales de los datos, con responsabilidad local: todos los datos
pertenecen " en realidad" a una base de datos local, aunque sean accesibles desde algn
sitio remoto. Por tanto, las cuestiones de seguridad, integridad y representacin en
almacenamiento de los datos locales permanecen bajo el control de la instalacin local.
2.2. No dependencia de un sitio central.
La autonoma 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 administracin 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 autonoma local completa. Por ello vale la pena expresarlo como un
objetivo separado.
La dependencia de un sitio central sera indeseable al menos por las siguientes razones: en
primer lugar, ese sitio central podr ser un cuello de botella; en segundo lugar, el sistema
sera vulnerable; si el sitio central sufriera un desperfecto, todo el sistema dejara de
funcionar.
2.3. Operacin contina.
En un sistema distribuido, lo mismo que en uno no distribuido, idealmente nunca debera
haber necesidad de apagar a propsito el sistema. Es decir, el sistema nunca debera
necesitar apagarse para que se pueda realizar alguna funcin, como aadirse un nuevo sitio
o instalar una versin mejorada del DBMS en un sitio ya existente.
2.4. Independencia con respecto a la localizacin.
La idea bsica de la independencia con respecto a la localizacin (tambin conocida como
transparencia de localizacin) es simple : no debe ser necesario que los usuarios sepan
dnde estn almacenados fsicamente los datos, sino que ms bien deben poder
comportarse - al menos desde un punto de vista lgico - como si todos los datos estuvieran
almacenados en su propio sitio local. La independencia con respecto a la localizacin es
deseable porque simplifica los programas de los usuarios y sus actividades en la terminal.
En particular, hace posible la migracin de datos de un sitio a otro sin anular la validez de
ninguno de esos programas o actividades. Esta posibilidad de migracin es deseable pues
permite modificar la distribucin de los datos dentro de la red en respuesta a cambios en los
requerimientos de desempeo.

2.5. Independencia con respecto a la fragmentacin.

Un sistema maneja fragmentacin de los datos si es posible dividir una relacin en partes o
"fragmentos" para propsitos de almacenamiento fsico. La fragmentacin es deseable por
razones de desempeo: los datos pueden almacenarse en la localidad donde se utilizan con
mayor frecuencia, de manera que la mayor parte de las operaciones sean slo locales y se
reduzca al trfico en la red. Por ejemplo, la relacin empleados EMP podra 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 fragmentacin, horizontal y vertical, correspondientes a las
operaciones relacionales de restriccin y proyeccin; respectivamente. En trminos ms
generales, un fragmento puede ser cualquier subrelacin arbitraria que pueda derivarse de
la relacin original mediante operaciones de restriccin y proyeccin (excepto que, en el
caso de la proyeccin es obvio que las proyecciones deben conservar la clave primaria de la
relacin original). La reconstruccin de la relacin original a partir de los fragmentos se
hace mediante operaciones de reunin y unin apropiadas (reunin en el caso de
fragmentacin vertical, y la unin en casos de fragmentacin horizontal).

Ahora llegamos a un punto principal: un sistema que maneja la fragmentacin de los datos
deber ofrecer tambin una independencia con respecto a la fragmentacin (llamada
tambin transparencia de fragmentacin). La independencia con respecto a la
fragmentacin (al igual que la independencia con respecto a la independencia con respecto
a la localizacin) es deseable porque simplifica los programas de los usuarios y sus
actividades en la terminal.

2.6. Independencia de rplica.

Un sistema maneja rplica de datos si una relacin dada (o en trminos ms generales, un
fragmento dado en una relacin) se puede representar en el nivel fsico mediante varias
copias almacenadas o rplicas, en muchos sitios distintos.

La rplica es deseable al menos por dos razones: en primer lugar, puede producir un mejor
desempeo (las aplicaciones pueden operar sobre copias locales en vez de tener que
comunicarse con sitios remotos); en segundo lugar, tambin puede significar una mejor
disponibilidad (un objeto estar disponible para su procesamiento en tanto est disponible
por lo menos una copia, al menos para propsitos de recuperacin). La desventaja principal
de las rplicas es desde luego que cuando se pone al da un cierto objeto copiado, deben
ponerse al da todas las rplicas de ese objeto: el problema de la propagacin de
actualizaciones.
La rplica como la fragmentacin, debe ser "transparente para el usuario". En otras
palabras, un sistema que maneja la rplica de los datos deber ofrecer tambin una
independencia de rplica (conocida tambin como transparencia de rplica); es decir, los
usuarios debern poder comportarse como si slo existiera una copia de los datos. La
independencia de rplica es buena porque simplifica los programas de los usuarios y sus
actividades en la terminal. En particular, permite la creacin y eliminacin dinmicas de las
rplicas en cualquier momento en respuesta a cambios en los requerimientos, sin anular la
validez de esos programas o actividades de los usuarios.
2.7. 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 instalacin de Nueva York y los datos estn en el sitio
de Londres. Supongamos tambin 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. As, el ejemplo ilustra el punto de que un sistema relacional tendr con
toda probabilidad un mejor desempeo que uno no relacional (para cualquier consulta que
solicite varios registros), quiz en varios rdenes de magnitud.
En segundo lugar, la optimizacin es todava ms importante en un sistema distribuido que
en uno centralizado. Lo esencial es que, en una consulta como la anterior, donde estn
implicados varios sitios, habr muchas maneras de trasladar los datos en la red para
satisfacer la solicitud, y es crucial encontrar una estrategia suficiente. Por ejemplo, una
solicitud de unin de una relacin Rx almacenada en el sitio X y una relacin Ry
almacenada en el sitio Y podra llevarse a cabo trasladando Rx a Y o trasladando Ry a X, o
trasladando las dos a un tercer sitio Z.
2.8. Manejo distribuido de transacciones.
El manejo de transacciones tiene dos aspectos principales, el control de recuperacin y el
control de concurrencia, cada uno de los cuales requiere un tratamiento ms amplio en el
ambiente distribuido. Para explicar ese tratamiento ms amplio es preciso introducir
primero un trmino nuevo, "agente". En un sistema distribuido, una sola transaccin puede
implicar la ejecucin de cdigo en varios sitios (en particular puede implicar a
actualizaciones en varios sitios). Por tanto, se dice que cada transaccin est compuesta de
varios agentes, donde un agente es el proceso ejecutado en nombre de una transaccin dada
en determinado sitio. Y el sistema necesita saber cundo dos agentes son parte de la misma
transaccin; por ejemplo, es obvio que no puede permitirse un bloqueo mutuo entre dos
agentes que sean parte de la misma transaccin. La cuestin especifica del control de
recuperacin; para asegurar, pues que una transaccin dada sea atmica (todo o nada) en el
ambiente distribuido, el sistema debe asegurarse de que todos los agentes correspondientes
a esa transaccin se comprometan al unsono o bien que retrocedan al unsono. Este efecto
puede lograrse mediante el protocolo de compromiso en dos fases.
En cuanto al control de concurrencia, esta funcin en un ambiente distribuido estar basada
con toda seguridad en el bloqueo, como sucede en los sistemas no distribuidos.
2.9. Independencia con respecto al equipo.
En realidad, no hay mucho que decir acerca de este tema, el ttulo lo dice todo. Las
instalaciones de cmputo en el mundo real por lo regular incluyen varias mquinas
diferentes -mquinas 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 adems
lograr que esos diferentes equipos participen como socios iguales en un sistema distribuido.
2.10. Independencia con respecto al sistema operativo.
Este objetivo es un corolario del anterior. Es obvia la conveniencia no slo de poder
ejecutar el mismo DBMS en diferentes equipos, sino tambin poder ejecutarlo en diferentes

sistemas operativos y lograr que una versin MVS y una UNIX y una PC/DOS participen
todas en el mismo sistema distribuido.
2.11. Independencia con respecto a la red.
Si el sistema ha de poder manejar mltiples sitios diferentes, con equipo distinto y
diferentes sistemas operativos, resulta obvia la conveniencia de poder manejar tambin
varias redes de comunicacin distintas.
2.12. Independencia con respecto al DBMS
Bajo este ttulo consideramos las implicaciones de relajar la suposicin de homogeneidad
estricta. Puede alegarse que esa suposicin es quiz demasiado rgida. 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.
Ventajas
Existen cuatro ventajas del procesamiento de bases de datos distribuidas. La primera, puede
dar como resultado un mejor rendimiento que el que se obtiene por un procesamiento
centralizado. Los datos pueden colocarse cerca del punto de su utilizacin, de forma que el
tiempo de comunicacin sea ms ms corto. Varias computadoras operando en forma
simultnea pueden entregar ms volumen de procesamiento que una sola computadora.
Segundo, los datos duplicados aumentan su confiabilidad. Cuando falla una computadora,
se pueden obtener los datos extrados de otras computadoras. Los usuarios no dependen de
la disponibilidad de una sola fuente para sus datos.

Una tercera ventaja, es que los sistemas distribuidos pueden variar su tamao de un modo
ms sencillo. Se pueden agregar computadoras adicionales a la red conforme aumentan el
nmero de usuarios y su carga de procesamiento. A menudo es ms fcil y ms barato
agregar una nueva computadora ms pequea que actualizar una computadora nica y
centralizada. Despus, si la carga de trabajo se reduce, el tamao de la red tambin puede
reducirse.
Por ltimo, los sistemas distribuidos se pueden adecuar de una manera ms sencilla a las
estructuras de la organizacin de los usuarios.

CONCLUSION

Para finalizar es importante recalcar que cada regla es indispensable para la elaboracin de
una base de datos distribuidas son puntos importantes que debemos conocer, ya que por
medio de estas podremos saber si nuestra base de datos esta correcta y si la estaos haciendo
bien, as tendremos un amplio conocimiento en cuanto a la lgica de un problema cuando
se pretenda resolver.

Un sistema distribuido es una coleccin de computadoras independientes interconectadas

entre s que aparecen ante los usuarios del sistema como una nica computadora .

REFERENCIAS BIBLIOGRAFICA

http://www.monografias.com/trabajos82/base-datos-distribuidas/base-datosdistribuidas.shtml