Bases de datos distribuidas

UNIVERSIDAD VERACRUZANA
Facultad de Contaduría y Administración
REPLICACION Y FRAGMENTACION
“REPLICACION
DE BASES DE DATOS DISTRIBUIDAS”
MONOGRAFÍA
Para obtener el Título de:
Licenciado en Sistemas
Computacionales Administrativos
Presenta:
Alejandra Zavala Mendoza
Asesor:
Mtra. María Luisa Velasco Ramírez
Xalapa-Enríquez,
Enríquez, Veracruz
Agosto 2010
1
2
UNIVERSIDAD VERACRUZANA
Facultad de Contaduría y Administración
REPLICACION Y FRAGMENTACION
“REPLICACION
DE BASES DE DATOS DISTRIBUIDAS”
MONOGRAFÍA
Para obtener el Título de:
Licenciado en Sistemas
Computacionales Administrativos
Presenta:
Alejandra Zavala Mendoza
Asesor:
Mtra. María Luisa Velasco Ramírez
Xalapa-Enríquez,
Enríquez, Veracruz
Agosto 2010
3
AGRADECIMIENTOS
Primero que nada quiero dedicar mi monografías a mis padres que son las
personas que más amo, porque gracias a ellos he podido llegar a donde estoy
por que sin su apoyo no hubiera podido lograr este gran sueño terminar mi
carrera profesional.
Gracias por todo su apoyo incondicional, comprensión y por estar siempre a mi
lado los amooo mucho.
También quiero agradecer a mis compañeros que durante estos cuatro años
siempre me brindaron su amistad: Luisito, perrota, tachi, Jorge, Juan Ramón,
increíble, etc. Los quiero mucho y los voy a extrañar demasiado.
Por último también quiero agradecer a mis amigas que siempre han estado
conmigo marinita, andri, mafer, talis las quiero mucho
4
INDICE
Pág.
Resumen…………………………………………………….………………………….1
Introducción………………………………………………….………………..............2
Contenido:
Capitulo 1: Base de datos……………………………..….……………....................5
1.1.- Antecedentes de las bases de datos….............................................6
1.2.- Bases de datos………………………….……….………………………6
1.3.- Diseño de Bases de datos……………………….……………………..9
1.4.-Usuarios finales………....………………………….…….....................10
1.5 -Control de redundancia………………...………….……………………11
1.6.- Suministros de copias de seguridad y recuperación……………….12
1.7.-Lenguaje de SGBD……………………………………….……………..14
1.7.1.- Componentes del SGBD…………….…..……………….....17
1.8.- Utilidades del Sistema de Base de Datos…………………………18
Capitulo 2: Bases de Datos Distribuidas…………………………….…………….20
2.1.- Bases de Datos Distribuidas……………………...…………………..21
2.2.- Ventajas de las Bases de Datos Distribuidas……………………….22
2.3.- Desventajas de las bases de datos distribuidas……………………25
2.4.- Aplicaciones de las bases de datos distribuidas……………………26
2.5.- Funciones de las Bases de Datos Distribuidas……………………..27
II
2.6.- Técnicas de Fragmentación replicación y asignación de las Bases
de Datos Distribuidas………………………………………………………………..29
2.6.1.- Fragmentación horizontal………………….........................30
2.6.2.- Fragmentación Vertical.………..........................................31
2.7.- Replicación y asignación de las Bases de Datos Distribuidas…….31
2.8.- Tipos de Bases de Datos Distribuidas……………………………….33
2.8.1.- Características de los Sistemas de Gestión de Bases de Datos
Distribuidas……………………………………………………………………………35
2.9.- Procesamiento de consultas de Bases de Datos Distribuidas…….37
2.10.- Control de concurrencia y recuperación en Bases de datos
distribuidas……………………………………………………………………………39
2.10.1.- Recuperación distribuida…………………………………………..43
2.11.- Arquitectura cliente servidor con bases de Datos Distribuidas….43
Capitulo
3:
Replicación
y
Fragmentación
de
una
Base
de
Datos
Distribuida………..……………………………………………………………………47
3.1.- Replicación…………………..……………………………………........48
3.1.1.- Tipos de replicación……………………….…………………50
3.1.2.- Factores para la replicación…………….……….………….51
3.1.3.- Ventajas y Desventajas de la replicación………………….52
3.2.- Fragmentación de los datos…………………………………………..53
3.2.1.- Requerimientos de información…………………………….54
3.2.2.- Fragmentación Horizontal…………………………………...54
3.2.3.- Fragmentación Vertical......................................................56
III
3.2.4.- Fragmentación mixta……………………………...…………58
3.4.- Colocación de datos.....……………………………………...………..61
3.4.1.- Criterios para escoger la distribución….………...………...62
3.5.- Transparencia………………….……………………………………….63
Conclusión……………………………………………………………………….……65
Fuentes de Información………………………………………………………..……68
Índice de Tablas………………………………………………………………..…….70
Índice de Figuras………………………………………………………………..……71
IV
RESUMEN
El siguiente trabajo titulado “Replicación y fragmentación de Bases de Datos
Distribuidas” principalmente está enfocado a la descripción de las bases de datos
distribuidas, sus características, ventajas y sus usos.
Esta investigación documental va dirigida a cualquier organización que cuente con
la necesidad de almacenar información en bases de datos y poder manipular dicha
información desde cualquier punto que lo desee gracias las bases de datos
distribuidas, mismos que por medio de una red de comunicación, pueden acceder
a la información de una forma rápida y eficiente.
El trabajo se centra en considerar la importancia de tener replicada una base de
datos, los grandes beneficios que esta proporciona, y las ventajas competitivas
que esta proporciona.
1
INTRODUCCION
2
Los almacenamientos de datos son un elemento fundamental para las empresas
por ello ha llamado la atención de estas ya que en la actualidad cualquier
compañía por pequeña que sea tiene que manejar grandes cantidades de
información, para poder tener control sobre todas las áreas de su empresa, es por
ello que surge la necesidad de emplear bases de datos dentro de las
organizaciones, no importando el giro de las empresas.
Por lo cual, se le denomina “Base de Datos” a la colección de datos aparentes
usados por el sistema de aplicaciones de una determinada empresa.
La mayoría de las empresas necesitan contar con bases de datos ya que las
bases de datos facilitan la realización de sus actividades, garantiza la seguridad,
la confiabilidad de la información, consistencia de los datos, mejora en la
disponibilidad
de
información,
guarda
información
sobres
sus
clientes,
proveedores, información financiera, inventarios, compras, ventas etc. Si
contamos con un buen control de la información se podrá llevar una empresa de
mejor manejar y mas organizadamente
La
gran
cantidad
de
información
que
producen
grandes
empresas
geográficamente distribuidas, ha generado una gran dispersión de los datos
asociados a sus sistemas de información. Para compartir dichos datos se requiere
de tecnología capaz de
integrarlos para permitir el acceso concurrente de
múltiples usuarios. Una de las tecnologías que se propone alcanzar este tipo de
objetivos son las bases de datos distribuidas
Las bases de datos distribuidas mejoran la disponibilidad de los datos pues
permite que el sistema pueda seguir operando y los usuarios desde cualquier sitio
puedan acceder a la información, exactamente igual como si los datos estuvieran
en el mismo sitio del usuario.
3
Las bases de datos distribuidas se conectan por medio de redes de
computadoras,
estas
pueden
tener
cientos
de
usuarios
conectados
concurrentemente, por lo cual es un problema en muchas empresas que compiten
en los mercados mundiales. Debido al alto grado de conectividad que provee
Internet a las empresas, se debe tener un buen diseño de replicación y
fragmentación.
Este problema consiste en tratar de determinar la mejor forma de dividir
relaciones de la base de datos en fragmentos.
las
La fragmentación mejora la
disponibilidad de la información notablemente por que el sistema puede seguir
operando mientras, por lo menos, uno de los sitios esta activo, con la replicación
también se mejora el rendimiento de la recuperación en consultas globales, por
que el resultado de semejante consulta se puede obtener localmente en cualquier
sitio, esto ayuda a contar con la información necesaria de una forma más fácil y
rápida y hoy en día para las empresas contra con la información en un corto
tiempo es un factor clave para la toma de decisiones oportunas.
4
Capitulo 1: Bases de Datos.
5
Las bases de datos, hoy en día, ocupan un lugar determinante en cualquier área
ya que se emplea en diversas empresas no importando el giro de esta, es por ello
que deben de tener los conocimientos necesarios para poder utilizar las bases de
datos .En este capítulo se hablará de las bases de datos, algunas de sus ventajas,
características, además de cuales son algunas de sus principales características,
componentes, su diseño, etc.
1.1.- Antecedentes de las bases de datos.
Según Coronel, Carlos. (2004) históricamente las primeras aplicaciones de
computadora se concentraron en tareas de oficina: en procedimientos de entradas
o pedidos o cambios, nominas, planificación del trabajo, etc. Tales aplicaciones
tenían acceso a datos guardados en archivos de computadora. Se solicitaba
información ¿Cuántos productos fueron vendidos por quien y a quien?; y se
generaban reportes para transformar los datos a
información útil para las
decisiones de la gerencia.
1.2.- Bases de datos
Siguiendo con Coronel, Carlos Bases de datos: es una colección de datos
relacionados.
Por datos: se entiende hechos conocidos que pueden registrarse y que tienen un
significado implícito. Po ejemplo, considérese los nombres, números de teléfono y
direcciones de gente que usted conoce. Usted podría registrar dichos datos en un
libro de direcciones, utilizando una computadora personal y un software como
ACCESSO EXCEL. Este es una colección de datos relacionados con un
significado implícito y por tanto es una base de datos.
Se suelen utilizar sistemas de archivos, que son muchos archivos separados y no
relacionados, las bases de datos se componen de datos lógicamente relacionados
6
guardados en un solo reposito de datos. Como se muestra en la figura 1.1 las
bases de datos brindan grandes ventajas
Figura 1.1 Comparación de una base de datos y un sistema archivos.
Una base de datos puede tener cualquier tamaño y complejidad. Por ejemplo, la
lista de nombres y direcciones mencionada, puede constar de unos pocos cientos
de registros, cada uno con una estructura sencilla.
Una base de datos puede crearse manualmente o puede estar informatizada.
7
Una base de datos informatizada puede crearse y mantenerse bien mediante un
conjunto de programas de aplicación diseñados específicamente pata dicha tarea
o bien mediante un sistema de gestión bases de datos.
Un sistema de gestión de bases de datos: (data management system o DBMS) es
una colección de programas que permiten a los usuarios crear y mantener una
base de datos. El SGBD es por tanto un sistema software de propósito general
que facilita los procesos de definición, construcción y manipulación de base de
datos para distintas aplicaciones. Las definición de una base de datos consiste en
especificar los tipos de datos, las estructuras y restricciones para los datos que se
van a almacenar en dicha base.
La construcción de una base de datos es el proceso de almacenar los datos
concretos sobre algún medio de almacenamiento controlado por el SGBD. La
manipulación de la base de datos incluye funciones tales como consultar la base
de datos para recuperar unos datos específicos, actualizar la base de datos para
reflejar los cambios ocurridos en el mini mundo, y generar informes a partir de los
datos.
No es preciso utilizar software de SGBD de propósito general para implementar
una base de datos informatizada. Se codifica un conjunto de programas para crear
y mantener la base de datos, es decir, crear software de SGBD de propósito
especifico, en cualquier caso, se use usemos o no un SGBD de propósito general,
normalmente se emplea gran cantidad de software para manipular la base de
datos. Se Denomina sistemas de base de datos al conjunto formado por la base
de datos más el SGBD. La figura 1.2 ejemplifica un SGBD.
8
Figura 1.2 Muestra un entorno de sistema de base de datos simplificado, que
ilustra los conceptos y terminología de un Sistema de Base de datos.
1.3.- Diseño de bases de datos
Según RAMEZ, Elmasri. (2006), Los diseños de bases de datos se encargan de
identificar los datos que se almacenan en la base de datos y de elegir las
estructuras apropiadas para presentar y almacenar dichos datos. Por lo general,
estas tareas se realizan antes de que se implemente la base de datos y se
carguen los datos. Los diseñadores tiene la responsabilidad de comunicarse con
toso los futuros usuarios de la base de datos con el fin de comprender sus
necesidades, y de presentar un diseño que satisfaga esos requerimientos. En
9
muchos casos los diseñadores forman parte del personal de ABD (Administrador
de bases de datos) y tal vez asuman otras responsabilidades una vez terminado el
diseño de la base de datos. Casi siempre, los diseñadores interactúan con cada
uno de los grupos de usuarios potenciales y desarrollan una vista de la base de
datos que satisfaga los requerimientos de datos y de procesamiento de cada
grupo, después, se analizan las vistas y se integran con las de otros grupos de
usuarios. El diseño final debe ser capaz de satisfacer las necesidades de todos los
grupos.
1.4.- Usuarios finales
Continuando con RAMEZ, Elmasri. (2006)., Los usuarios finales son las personas
cuyo trabajo requiere acceder a la base de datos para consultarla, actualizarla y
generar informes; las base de datos existe principalmente para que ellos la
utilicen.
•
Los usuarios finales ocasionales: acceden de vez en cuando a la base de
datos, pero es posible que requieran información diferente en cada ocasión.
Utilizan un lenguaje de consulta de base de datos avanzado para especifica
sus solicitudes y suelen ser gerentes de nivel medio o alto u otras personas
que examinan la base de datos ocasionalmente
•
Los usuarios finales simples o paramétricos: construyen una porción
apreciable de la totalidad de los usuarios finales. La función principal de su
trabajo gira en torno a consultas y actualizaciones constantes de la base de
datos, utilizando tipos estándar de consulta y actualizaciones, transacciones
programadas, que se han programado y probado con mucho cuidado. Las
tareas realizadas dichos usuarios son variadas:
Los cajeros de los bancos revisan los saldos y realizan los reintegros y depósitos
de dinero.
10
Los encargados de reservas de líneas aéreas, hoteles y compañías de alquiler de
automóviles revisan la disponibilidad para una solicitud presentada y realizan las
reservas.
Los usuarios finales avanzados: pueden ser los ingenieros, científicos, analistas
de negocios y otros, que están suficientemente familiarizados con los recursos de
SGBD como para implementar sus aplicaciones de forma que cumplan sus
complejos requerimientos.
Los usuarios autónomos: mantienen bases de datos personales mediante la
utilización de paquetes de programas comerciales que cuentan con interfaces de
fácil uso, basados en menús o en gráficos. Un ejemplo es el usuario de un
paquete fiscal que almacena diversos datos financieros personales para fines
fiscales
Normalmente los SGBD proporcionan múltiples recursos para acceder a la base
de datos. Los usuarios finales simples necesitan aprender pocas cosas sobre los
recursos proporcionados por el SGBD; solo necesitan entender los tipos de
transacciones estándar diseñadas e implementadas para que ellos las usen los
usuarios ocasionales aprender únicamente unos pocos recursos que pueden
utilizar de forma repetida. Los usuarios avanzados intentan conocer la mayoría de
los recursos del SGBD para satisfacer sus complejos requerimientos. Los usuarios
autónomos normalmente adquieren gran habilidad para utilizar un paquete de
software específico
1.5.- Control de redundancias
La redundancia: es el almacenamiento de los mismos datos varias veces, provoca
varios problemas. En primer lugar, es necesario realizar una misma actualización
lógica (como introducir los datos de un nuevo alumno varias veces: una vez por
cada fichero en el que se registren los datos de alumnos. Esto implica una
duplicación
del
trabajo.
En
segundo
lugar
se
desperdicia
espacio
de
almacenamiento al guardar los mismos datos en varios sitios, y este problema
puede ser grave si las bases de datos son grandes. En tercer lugar, es posible
11
que los ficheros que representan los mismos datos, se vuelvan inconsistentes.
Esto puede suceder porque una actualización se haya aplicado a ciertos ficheros
pero no a otros.
Restricción de los accesos no autorizados
Cuando muchos usuarios comprante una misma base de datos, es probable que
no todos tengan la autorización para acceder a toda la información que contiene.
Por ejemplo es habitual considerar que los datos financieros son confidenciales y
que solo ciertas personas pueden tener autorización para acceder a lo mismo.
Además, es posible que solo algunos usuarios tengan permiso para recuperar
datos, mientras que a otros se les permita obtenerlos y actualizarlos por tanto,
también es preciso controlar los tipos de acceso( recuperación o actualización).
Normalmente a los usuarios o grupos de usuarios se le asigna números de cuenta
protegidos, con contraseñas que sirven para detener accesos a la base de datos.
EL SGBD (Sistema de gestión de base de datos), debe contar con un sistema de
seguridad y autorización que le permita al ABD crear cuentas y especificar
restricciones para ellas. El SGBD deberá entonces garantizar automáticamente el
cumplimiento de dichas restricciones. Cabe señalar que el mismo tipo de controles
se puede aplicar al software que SGBD por ejemplo, solo el personal del ABD
tendrá autorización para utilizar ciertos software privilegiados como el que sirve
para crear cuentas nuevas. De manera similar podemos hacer que los usuarios
paramétricos solo puedan tener acceso a la base de datos a través de las
transacciones programadas que expresamente fueron creadas para ellos.
1.6.- Suministros de copias de seguridad y recuperación
Todo SGBD debe contar con recursos para recuperarse de fallos de hardware o
de software. El sistema de copias de seguridad (Backus) y recuperación del SGBD
es el responsable de llevar a cabo dicha recuperación por ejemplo si el sistema
falla mientras se está ejecutando un complejo programa de actualización el
subsistema de recuperación se encargara de asegurarse de que la base de datos
se restaure al estado en que estaba antes de comenzar la ejecución de dicho
12
programas, con alternativa el subsistema de recuperación puede asegurarse de
que el programa reanude sus ejecución en el punto en que fue interrumpido de
modo que su efecto complejo se registre en la base de datos
Arquitectura de tres esquemas de un SGBD
El objetivo de la arquitectura de tres esquemas es separar las aplicaciones del
usuario y la base de datos física. En esta arquitectura se definen esquemas de los
tres siguientes niveles:
1.- El nivel interno: tiene un esquema interno que describe la estructura física de
almacenamiento de la base de datos. El esquema interno emplea un modelos de
datos físicos y describe todos los detalles para su almacenamiento, así como los
caminos de acceso para la base de datos
2.- El nivel conceptual: el nivel conceptual tiene un esquema conceptual que
describe la estructura de la base de datos completa para una comunidad de
usuarios. El esquema conceptual oculta los detalles de las estructuras físicas de
almacenamiento y se concentra en describir entidades, tipos de datos, vínculos,
operaciones de los usuarios y restricciones. En este nivel podemos usar un
modelo de datos o uno de implementación.
3.- El nivel externos o de vistas: incluyen varios esquemas externos o vistas de
usuarios. Cada esquema externo describe de la base de datos que interesa a un
grupo de usuarios determinado, y oculta a ese grupo el resto de la base de datos.
En este nivel podemos usar un modelo de datos de alto nivel o uno de
implementación.
La estructura de tres esquemas es una herramienta adecuada para que el usuario
visualice los niveles de esquema de un sistema de base de datos. La mayoría de
los SGBD no separan los tres niveles completamente pero en algunos de ellos se
soporta, en cierta médica la arquitectura de tres esquemas. Algunos SGBD
incluyen detalles del nivel físico en el esquema conceptual. En casi todos los
SGBD se manejan vistas de usuarios, los esquemas externos se especifican en el
13
mismo modelos de datos que describe la información del nivel conceptual. Con
algunos SGBD es posible utilizar diferentes modelos de datos en los niveles
conceptual y externo.
Cabe señalar que los tres esquemas son más que descripciones de los datos; los
últimos datos que existen realmente están en el nivel físico. En un SGBD basado
en la base de arquitectura de tres esquemas cada grupo de usuarios hace
referencia exclusivamente su propio esquema externo, por lo tanto, el SGBD debe
transformar una solicitud expresada en términos de un esquema externo en una
solicitud expresada en términos del esquema conceptual y luego de una solicitud
en el esquema interno que se procesara sobre la base de datos almacenada. Si la
solicitud es una obtención de datos será preciso modificar el formato de
información extraída de la base de datos almacenada para que coincida con la
vista externa del usuario. El proceso de transformar solicitudes y resultados de un
nivel a otro se denomina correspondencia o transformación. Esta correspondencia
puede requerir bastante tiempo por lo que algunos SGBD no soportan vistas
externas. Sin embargo, incluso de tales sistemas es preciso realizar algunas
correspondencias para transformar solicitudes entre los niveles conceptual o
interno
1.7.- Lenguaje del SGBD
Silberschatz, Abraham. (2006). Una vez que se ha completado el diseño de una
base de datos y se ha elegido un SGBD para su implementación el primer paso
será identificar los esquemas conceptual o interno de la base de datos y cualquier
correspondencia existente entre ambos. El muchos SGBD en los que no se
mantienen una separación estricta de niveles, el ABD y los diseñadores de la base
de datos utilizan un mismo lenguaje; el lenguaje de definición de datos (LDD), para
definir ambos esquemas el SGBD contara con un compilador de LDD cuya función
podrá procesar las sentencias escritas en el LDD para identificar las descripciones
de los elementos de los esquemas y almacenar la descripción del esquema el
catalogo del SGBD. Cuando los SGBD se mantengan una clara separación entre
14
los niveles conceptual o externo el LDD servirá solamente para especificar el
esquema conceptual.
Para especificar el esquema interno, se utiliza otro lenguaje, el lenguaje de
definición de almacenamiento LDA las correspondencias entre los esquemas se
pueden especificar en cualquiera de los dos lenguajes. Para una verdadera
arquitectura de los tres esquemas, necesitamos un tercer lenguaje, el lenguaje de
definición de vistas LDV, para especifica las vistas de usuario y sus
correspondencias con el esquema conceptual. Sin embargo, en la mayoría de los
SGBD el LDD se utiliza tanto como para describir el esquema conceptual como el
externo.
Una vez que se han cumplido los esquemas de la base de datos y que en esta se
han introducido los datos; los usuarios requieran algún mecanismo para
manipularla. Las operaciones de manipulación más comunes son la recuperación,
inserción, la eliminación y la modificación de los datos. El SGBD ofrece un
lenguaje de manipulación de datos LMD para estos fines.
En los actuales SGBD, los tipos de lenguaje mencionados no se consideran
lenguajes diferentes más bien, se utilizan un amplio lenguaje integrado que cuenta
con elementos, para definir esquemas conceptuales, definir vistas, manipular
datos y definir su almacenamiento. La definición de almacenamiento normalmente
se mantiene separada puesto que se utiliza para definir las estructuras físicas de
almacenamiento para armonizar la ejecución del sistema de bases de datos y
normalmente se utiliza por el personal de administración de la base de datos. Un
ejemplo representativo es el lenguaje de bases de datos relacionales SQL que
representa una combinación de LDD, LDV, LMD así como sentencia para
especificación de restricciones y evolución del esquema. El LDA fue componente
de las primeras versiones del SQL, pero se ha retirado del lenguaje para
mantenerlos solo a nivel conceptual y externo.
Hay dos tipos principales de LMD, los LMD de alto nivel o de no procedimiento se
pueden utilizar de manera independiente para especificar operaciones complejas
15
de base de datos en forma concisa en muchos SGBD, es posible introducir
interactivamente instrucciones de LMD de alto nivel desde un terminal o desde un
terminal o bien embebidas en un lenguaje de programación de propósito general.
En el segundo caso es preciso identificar las sentencias del LMD dentro del
programa para que le pre compilador pueda extraerlas, y SGBD procesarlas. Los
LMD de bajo nivel o de procedimientos deben estar embebidos en un lenguaje de
programación de propósito general. En general, estos tipos de LMD recuperan
registros u objetos individuales de la base de datos y los procesa por separado.
Por tanto, necesita utilizar elementos del lenguaje de programación, como los
bucles para recupera y procesar cada registro individual de un conjunto de
registros. Por esta razón los MLD de bajo nivel, se conocen también como LMD de
registro por registro u orientados a registro los LMD de alto nivel, como SQL
pueden especificar y recuperar muchos registros con una sola instrucción de LMD
por eso se le llama LMD conjunto por conjunto u orientado a conjuntos. Las
consultad de los LMD de alto nivel suelen especificar que datos ahí que obtener y
como obtenerlos por ello tales lenguajes se denominan también declarativos.
Siempre que las instrucciones de un LMD sean de alto o de bajo nivel, estén
embebidas en un lenguaje de programación de propósito general, a ese nivel se le
denomina lenguaje anfitrión al MLD sub lenguaje de datos. Por otro lado los LMD
de alto nivel utilizados en forma interactiva e independiente se denominan
lenguajes de consulta, en general tanto las instrucciones de recuperación o de la
actualización de datos del LMD de alto nivel se pueden utilizar interactivamente,
así que se consideran parte de una lenguaje de consulta.
Normalmente los
usuarios finales ocasionales utilizan un lenguaje de consulta de alto nivel para
especificar sus solicitudes, mientras que los programadores utilizan el MLD en su
forma embebida. Para los usuarios simples y paramétricos casi siempre se
incluyen interfaces amigables con el usuario que permiten interactuar con la base
de datos; estos también pueden aprovechar los usuarios ocasionales que no
deseen aprender los detalles de un lenguaje de consulta de alto nivel.
16
1.7.1- Componentes del SGBD
Continuando con RAMEZ, Elmasri. (2006). La base de datos y el catálogo del
SGBD casi siempre se almacenan en el disco el acceso al disco suele controlarlo
principalmente el sistema operativo que planifica la entrada y salida del disco. Un
modulo gestor de datos almacenados del SGBD de más alto nivel controla el
accedo a la información el SGBD almacenada en el disco bien sea aparte de la
base de datos o del catalogo.
El gestor de datos almacenados puede emplear servicios básicos del Sistema
operativo para transferir los datos de bajo nivel entre el disco y la memoria
principal del computador, pero controla los aspectos de la transferencia de datos,
como el manejo de los buffers de la memoria principal. Una vez que los datos
estén en dichos bufes fe la memoria principal podrán ser procesados por otros
módulos del SGBD o por los programas de aplicación.
El compilador de LDD procesa las definiciones de esquemas especificadas en el
LDD y almacena las descripciones de los esquemas (metadatos) en el catalogo
del SGBD. El catalogo contiene información como los nombres de los ficheros y
de los elementos de datos los detalles de almacenamiento de cada fichero la
información que corresponde entre los esquemas y las restricciones, además de
otros tipos de información que es necesaria para los módulos del SGBD. Los
módulos del SGBD que necesitan conocer esa información deberán consultar el
catalogo
El procesador de base de datos en tiempo de ejecución se encarga de los acceso
a la misma durante la ejecución; revive operaciones de obtención o de
actualización y las ejecuta sobre la base de datos. El acceso al disco se tiene
mediante el gestor de datos almacenados. El recopilador de consultas maneja las
consultas de alto nivel que se introducen interactiva, ente analiza las sintaxis y
compila la consulta o la interpreta creando el código de acceso la base de datos y
luego genera llamadas al procesador en tiempo de para ejecutar dicho cogido.
17
El precompilador
extrae instrucciones el MLD de un programa de aplicación
escrito en un lenguaje de programación anfitrión. Estas instrucciones se envían al
compilador de MLD para convertirlas en código objeto para el acceso de la base
de datos, y el resto del programa se envía al compilador del lenguaje anfitrión el
código objeto de las instrucciones LMD y el del resto del programa se enlazan,
formando una transacción programada cuyo código ejecutable incluye llamadas al
procesador de la base de datos durante el tiempo de ejecución
El SGBD también se comunica con los compiladores de los lenguajes de
programación anfitriones de propósito general, puede ofrecer interfaces amigables
con el usuario como ayuda a cualquiera de los tipos de usuarios
1.8.- Utilidades del Sistema de Base de Datos
Además de los modelos de software que se acaban de describir, casi todos los
SGBD cuentan con utilidades de base de datos que ayudan al ABD a destinar el
sistema. Las utilidades comunes efectúan los siguientes tipos de funciones:
1.- Carga: se utiliza para cargar ficheros de datos ya existentes (como ficheros de
texto o secuenciales) en la base de datos. Normalmente a la utilidad se le
especifica el formato actual del fichero de datos (fuente) y la estructura de fichero
en la base de datos deseada (destino). La utilidad modifica automáticamente el
formato de los datos y los almacena en la base de datos. Con la proliferación de
los SGBD, la transferencia de datos de un SGBD a otro se ha vuelto algo común
en muchas organizaciones. Algunos proveedores actualmente ofrecen productos
que generan los programas de carga apropiados, de acuerdo con las
descripciones de almacenamiento de las bases de datos fuente y destino
(esquemas internos). Tales herramientas también se denominan herramientas de
conversión.
2.- Copia de seguridad backup: las utilidades de respaldo crean una copia de
seguridad de la base de datos, casi siempre volcando toda la base de datos en
18
cinta. La copia de seguridad puede servir para restaurar la base de datos en caso
de un fallo catastrófico. También se suelen usar copias de seguridad en niveles,
donde solo se registran los cambios habidos desde la anterior copia de seguridad.
La copia de seguridad ahora es más compleja, pero se ahorra espacio.
3.- Reorganización de ficheros: esta utilidad puede servir para pasar de una
organización de los ficheros de la base de datos a otra con el fin de mejorar el
rendimiento
4.- Control de rendimiento: las utilidades de este tipo supervisan la utilización de la
base de datos y proporcionan datos estadísticos al ABD, el cual los utilizan para
decidir, por ejemplo, si conviene reorganizar los ficheros con el fin de mejorar el
rendimiento
En este primer capítulo se explico que son las bases de datos, cómo funcionan y
la importancia de contar con una base de datos dentro de una organización.
Existen diversos tipos de bases de datos pero las bases de datos que actualmente
mas se demandan gracias a sus grandes ventajas competitivas son las bases de
datos distribuidas las cuales abordaremos en el siguiente capítulo.
19
Capitulo 2: Bases de Datos Distribuidas.
20
En el actual capitulo se darán a conocer en qué consisten las bases de datos
distribuidas sus principales características así como sus ventajas, principales
funciones, tipos de bases de datos distribuidas, etc.
En este capítulo se explicara la razón por la que tales bases de datos están
llegando a ser cada vez más importantes, así como algunos de los problemas que
se generan.
Las bases de datos distribuidas son una colección de sitios,
conectados por medio de una red de comunicación, los sitios trabajan juntos, a fin
de que un usuario de cualquier sitio puede acceder a los datos desde cualquier
logar de la red, exactamente como si los datos estuvieran guardados en el propio
sitio del usuario, es por ello que cada día más empresas están implementando
bases de datos distribuidas para tener acceso a su base de datos desde cualquier
sitio que desee.
2.1.- Bases de datos distribuidas
Según RAMEZ, Elmasri. (2006). Las bases de datos distribuidas aportan las
ventajas de la computación distribuida al dominio de las bases de datos. Un
sistema de computación distribuido consiste en un conjunto de elementos de
procesamiento, no necesariamente homogéneos que están interconectados por
una red de computadoras y que cooperan con la ejecución de ciertas tareas
asignadas.
Como objetivo general los sistemas de computación distribuidos dividen un
problema grande e inmanejable en piezas más pequeñas y lo resuelven
eficientemente de forma coordinada. La viabilidad económica de este enfoque
proviene de dos razones:
1.- Se aprovecha mas la potencia del ordenador para resolver tareas complejas, y
cada electo del procesamiento autónomo se puede resignar independientemente y
puede desarrollar sus propias aplicaciones.
21
2.-Definir una base de dato distribuida BDD como una colección de múltiples
bases de datos interrelacionadas lógicamente, distribuidas por una red de
computadores y un sistema de gestión de bases de datos distribuido ( SGBD)
como un sistema software que maneja una base de datos distribuida haciendo la
distribución transparente para el usuario. Una colección de ficheros almacenados
en diferentes nodos de una red y el mantenimiento de interrelaciones entre ellos
por medio de hipervínculos se ha convertido en una organización común en
internet, con los ficheros de la página web. Las funciones usuales de la gestión de
bases de datos, incluyendo el procesamiento uniforme de consultas y el
procedimiento de transacciones, no se aplican todavía a este entorno. Las
tecnología, sin embargo se está moviendo en una dirección tal que las bases de
datos Word Wide Web (www) distribuidas se harán realizad en un futuro cercano
2.2.- Ventajas de las bases de datos distribuidas
La gestión de bases de datos distribuidas se ha propuesto por varias razones
yendo
estas desde la descentralización
organizacional y procesamiento
económico hasta la gran autonomía.
1.-Gestión de datos distribuidos con diferentes niveles de transparencia:
idealmente un SGBD deberá ofrecer transparencia de distribución en el sentido
que debería ocultar los detalles de donde se almacenan físicamente cada fichero
(tabla, relación) dentro el sistema.
Otras ventajas de las bases de datos distribuidas son:
•
Transparencia de red o de distribución, hace referencia a la liberación del
usuario de los detalles operacionales de la red. Se podrá dividir la
transparencia de localización y transparencia de los nombres. Las
transparencia de localización se refiere al hecho de que la instrucción
usada para ejecutar una tarea, es independiente de la localización del dato
y de la localización el sistema donde la instrucción fue utilizada. La
transparencia de nombres implica que una vez especificado un nombre se
22
puede acceder de manera no ambigua a los objetos con nombre sin
ninguna especificación adicional.
•
Transparencia de replica: las copias de los datos se deben almacenar en
varios sitios para mejorar la disponibilidad, rendimiento, y fiabilidad. La
transparencia de replica hace que el usuario desconozca la existencia de
copias.
•
Transparencia de fragmentación: son posibles dos tipos de fragmentación,
la fragmentación horizontal distribuye una relación en conjunto de tuplas
(filas) la fragmentación distribuye una relación en sub relaciones donde
cada sub relación se define por un conjunto de columnas de la relación
original. La consulta global del usuario se debe transformar en varias
consultas sobre fragmentos. La transparencia de fragmentación hace que
el usuario desconozca la existencia del fragmento.
2.- Incremento de la fiabilidad y disponibilidad; estas dos ventajas son de las más
comunes para las bases de datos distribuidas. La fiabilidad se define claramente
como la probabilidad de que un sistema este en marcha no caído en un punto de
tiempo determinado, mientras que la disponibilidad es la probabilidad de que en
sistema esté disponible continuamente durante un intervalo de tiempo. Cuando los
datos y el software del SGBD están distribuidos por varios sitios un sitio puede
fallar mientras otros continúan operando. Solamente son inaccesibles los datos y
el software del sitio que ha fallado. Esto mejora tanto la fiabilidad y la
disponibilidad. Si se replica acertadamente tanto los datos como el software en
más de un sitio se consiguen grandes mejoras en un sistema centralizado. Un fallo
en un único sitio hace al sistema inaccesible para todos los usuarios una base de
datos distribuida, algunos de los datos podrían ser inalcanzables pero los usuarios
podrán aun acceder a otra parte de la base de datos.
3.- Mejora del rendimiento: un SGBD distribuido fragmenta la base de datos
manteniendo los datos cerca de donde más se necesita. La localización de datos
reduce la contención para la CPU y los servicios de es y simultáneamente reduce
23
los retrasos de acceso involucrados en redes de área ancha. Cuando se distribuye
una gran base de datos con múltiples sitios ahí bases de datos más pequeñas en
cada sitio. Como resultado las consultas locales y las transacciones que accede a
datos de un único sitio, tienen mejor rendimiento por que las bases de datos
locales son más pequeñas. Además cada sitio tiene un menor número de
transacciones ejecutándose que si todas las transacciones refirieren a una base
de datos centralizada. Además de un paralelismo interconsulta, puede
conseguirse ejecutando varias consultas en sitios diferentes o descomponiendo
una consulta en sub consultas, que pueden ejecutarse en paralelo. Esto
contribuye a mejorar el rendimiento.
4. Expansión más sencillas en un entorno distribuido, la expansión del sistema
mediante la adición de datos, el aumento del tamaño de la base de datos, o la
adición de más procesadores es mucho más sencillos.
La transparencia total permite ver al usuario global la vista completa del SBDD
como si fuese el único sistema centralizado. La transparencia se proporciona
como un complemento a la autonomía, que proporciona al usuario un control más
estrecho sobre sus propias bases de datos locales. Las características de la
transparencia se deben implementar como parte del lenguaje del usuario que
traduce los servicios requeridos en operaciones apropiadas. Además la
transparencia afectada a las características que debe proporcionar un sistema
operativo y el SGBD
5. Costo
de operaciones reducidas ya que es mucho más barato agregar
estaciones a una red que actualizar un sistema mainframe. El costo de las lineas
de comunicación de datos dedicadas y el software de mainframe se reduce
proporcionalmente. El trabajo de desarrollo se realiza con más rapidez y menor
costo con computadoras personales baratas que con mainframes. De hecho la
mayoría de las corporaciones prohíben el trabajo desarrollo de mainframes, las
24
mainframes no están condenadas a desaparecer de la escena de la base de
datos; su poder no puede ser descontado. No obstante de redes de computadoras
personales hace posible distribuir las cargas de trabajo con más prudencia y
reservar
las
costosas
mainframe
para
tareas
de
procesamiento
mas
especializadas.
6. Facilidad de crecimiento, ya que se pueden agregar sitios nuevos a la red sin
afectar las operaciones de otros sitios, tal flexibilidad permite que la compañía se
expanda con relativa facilidad y rapidez.
7. Interface de usuario fácil de usar, las computadoras personales y las estaciones
de trabajo en general, vienen equipadas con una interfaz de usuario grafica, esto
simplifica el uso y el entrenamiento de usuarios finales.
8.- Independencia del procesador: el usuario final es capaz de accesar cualquier
copia disponible de los datos, y la solicitud de un usuario es procesada por
cualquier procesador disponible en la ubicación de los datos. En otras palabras,
las solicitudes no dependen de un procesador especifico; cualquier procesador
disponible puede manejar dicha solicitud.
2.3.- Desventajas de las bases de datos distribuidas
Según Coronel, Carlos. (2004), Las bases de datos distribuidas están sujetas a
algunos problemas. Estos incluyen
•
Complejidad de manejo y control: el manejo de datos distribuidos es
más complejo que el de datos centralizados. Las aplicaciones deben
reconocer la ubicación de los datos y ser capaces de reunir los datos de
diferentes sitios. Los administradores de las bases de datos deben tener
la capacidad de coordinar las actividades para evitar la degradación de
estas provocada por anomalías de los datos. El manejo de
transacciones, el control de concurrencia, la seguridad, el respaldo, la
25
recuperación, la optimización de las consultas, la selección de la ruta de
acceso , etc. Deben abordarse y resolverse. En suma, mantener los
diversos componentes de bases de datos distribuidas sincronizados es
una tarea difícil
•
Seguridad: la probabilidad de fallas de seguridad se incrementa cuando
los datos están en varios sitios. La responsabilidad del manejo de los
datos se reparte entre diferentes personas en varios sitios y las redes de
área local no disponen de la compleja seguridad de las instalaciones
mainframe centralizadas.
•
Falla de estándares: aunque las bases de datos dependen de la
comunicación eficaz, no existen protocolos de comunicación estándar a
nivel de base de datos ( aunque TCP/ IP es el estándar de hecho a nivel
de red, a nivel de aplicación no existe un estándar). En realidad, existen
pocos estándares oficiales en cualquiera de los protocolos de base de
datos distribuidas, ya sea que se ocupen de la comunicación o del
control de acceso a los datos
•
Requerimientos de almacenamiento incrementados: la base de datos
distribuida guarda varias copias de los datos requeridos en diferentes
sitios, con lo que se requiere más espacio de almacenamiento de disco.
Esta desventaja es mínima, por que el espacio de almacenamiento en
disco es relativamente barato y cada vez se abarata mas
•
Mayor dificultad en el ambiente de datos. El acceso y almacenamiento
en disco es un ambiente de almacenamiento de datos más disperso, se
vuelve mas difícil tanto desde la perspectiva del software como de la
humana
•
Alto costo de entrenamiento: los costos de entrenamiento en general
son más elevados en un modelo distribuido de lo que sería en un
modelo centralizado, incluso, en ocasiones al grado de neutralizar el
ahorro de operativo y de hardware
2.4 Aplicaciones de las bases de datos distribuidas
26
Los ambientes en los que se encuentra con mayor frecuencia el uso de las bases
de datos distribuidas son:
•
Cualquier organización que tiene una estructura descentralizada.
•
Casos típicos de lo anterior son: organismos gubernamentales y/o de
servicio público.
•
La industria de la manufactura, particularmente, aquella con plantas
múltiples. Por ejemplo, la industria automotriz.
•
Aplicaciones de control y comando militar.
•
Líneas de transportación aérea.
•
Cadenas hoteleras.
•
Servicios bancarios y financieros
2.5.- Funciones de las bases de datos distribuidas
La distribución conlleva un incremento de la complejidad en el diseño e
implementación del sistema. Para conseguir las ventajas potenciales enumeradas
previamente, el software de SGBD debe poder proporcionar las siguientes
funciones además de las proporcionadas por los SGBD centralizados:
•
Mantenimiento de la pista de los datos: la capacidad para seguir la pista a
la distribución de datos, la fragmentación y la réplica expandiendo el
catalogo del SGBDD.
•
Procesamiento de consultas distribuidas: la capacidad para acceder a sitios
remotos y transmitir consultas y datos a través de varios sitios utilizando
una red de comunicación
•
Gestión de transacciones distribuidas; la capacidad para ejecutar
estrategias de ejecución para consultas y transacciones que acceden a los
datos desde más de un sitio y de sincronizar el acceso de datos distribuidos
y mantener integridad sobre todo la base de datos
•
Gestión de datos replicados: la capacidad de decidir a qué copia de un
elemento de datos replicados acceder y mantener la consistencia de copias
de los elementos de datos replicados.
27
•
Recuperación de bases de datos distribuida la capacidad de recuperarse de
caídas de sitios individuales y de nuevo tipos de fallos como enlace de
comunicación
•
Seguridad: las transacciones distribuidas se debe ejecutar con una gestión
apropiada y de seguridad de datos, y los privilegios de autorización / acceso
de los usuarios
•
Gestión del directorio (catalogo) distribuido: un directorio contiene
información (metadatos) de los datos de la base de datos. El directorio debe
ser global para toda la BDD o local para cada sitio. Las asignación y
distribución del directorio son temas de políticas y diseño
Esta función incrementa la complejidad de un SGBD respecto a un SGBD
centralizado. Antes de comprender todas las ventajas potenciales de la
distribución podemos encontrar soluciones satisfactorias a estos temas y
problemas de diseño. Incluir todas estas funcionalidades adicionales es muy difícil
de llevar acabo y encontrar soluciones óptimas lo es aun más.
En un nivel físico de hardware un sistema centralizado se distingue del un SGBDD
por los siguientes factores principales:
•
Existen varios computadores, llamados sitios o nodos
•
Estos sitios se deben conectar a algún tipo de red de comunicación para
transmitir datos e instrucciones a lo largo de los sitios
Los sitios podrán estar localizados físicamente próximos, es decir dentro del
mismo edificio o grupo de edificios adyacentes conectados mediante una red de
área local, no podría estar distribuido geográficamente uno de otro conectado
mediante una red de área ancha o de larga distancia. Las redes de área local
normalmente utilizan cables mediante las redes de larga distancia utilizan líneas
telefónicas o satélites, también es posible utilizar una combinación de los tipos de
redes
Las redes podrían tener diferentes topologías, que definen los caminos de
comunicación directos entre sitios. Los sitios de topologías de las redes utilizadas
28
podrían tener un efecto significativo en el rendimiento y por lo tanto en las
estrategias de procesamiento de consultas distribuidas y de diseño de bases de
datos distribuidas. Para temas de arquitectura de alto nivel, sin embargo no
importa el tipo de red utiliza, lo único importante es que cada sitio puede
comunicarse directa o indirectamente con todos los demás sitios
.
2.6.-
Técnicas
de
fragmentación,
replicación
y
asignación de las Bases de datos distribuidas
Según RAMEZ, Elmasri. (2006). En una BDD es preciso tomar decisiones
respecto a en que sitios se almacenaran, que porciones de la base de datos.
Antes de decidir cómo distribuir los datos debemos determinar las unidades
lógicas de las bases de datos que se va a distribuir.las unidades lógicas más
simples son las propias relaciones es decir, cada relación completa se almacenara
en un sitio especifico, como se muestra en la figura 2.1 donde replica es igual a las
demás replicas del sistema.
29
Figura 2.1 Replicación y distribución de datos en bases de datos distribuidas
2.6.1- Fragmentación horizontal
Continuando con RAMEZ, Elmasri. (2006). Un fragmento horizontal es una
relación de un subconjunto de las tuplas de esta relación. Las tuplas que
pertenecen al fragmento horizontal se especifican mediante una condición sobre
uno o más de los atributos de la relación. Con frecuencia, solo interviene un
atributo, por ejemplo podríamos definir tres fragmentos horizontales en la relación
empelado con las siguientes condiciones: (N_d = 5), (N_d=4) y (N_d=1); cada
fragmento contiene las tuplas empleado, que pertenecen a un departamento en
particular. De manera similar, podemos definir tres fragmentos horizontales para la
relación proyecto, con al condiciones (Numd = 5), (numd=4),(num=5),
cada
fragmento contiene las tuplas proyecto controladas por un departamento en
particular. La fragmentación horizontal divide una relación “horizontalmente”
agrupando filas para crear subconjuntos de tuplas, donde cada subconjunto tiene
un cierto significado lógico. Estos fragmentos pueden entonces asignarse a
diferentes sitios en el sistema distribuido. La fragmentación horizontal derivadas
aplica la participación de una relación primaria en nuestro ejemplo empleado
proyecto, que referencia a la primaria a través de una clave externa. De esta forma
los datos relacionados entre las relaciones primarias y secundarias se fragmentan
de la misma forma.
2.6.2- Fragmentación vertical
Ningún sitio tiene porque necesitar todos los atributos de una relación, lo que
indica la necesidad de otro tipo diferente de fragmentación. La fragmentación
vertical divide una relación “verticalmente” en columnas un fragmento vertical de
una relación mantiene solo ciertos atributos de la relación. Por ejemplo podríamos
30
querer dividir la relación empleado en dos fragmentos verticales. Primero incluiría
información personal; nombre, fecha de nacimiento, dirección y sexo. Y el
segundo información relacionada con el trabajo: NSS, salario, nss_superv, nd.
La fragmentación vertical lo es de todo apropiada, porque si ambos fragmentos se
almacenan por separado, no podremos juntar otra vez las tuplas de empleado
originales, ya que no existe una atributo común entre los dos fragmentos. Es
necesario incluir el atributo de clave primaria o clave candidata en todo fragmento
vertical, p ara que sea posible reconstruir la relación completa a partir de los
fragmentos pro tanto habrá que añadir el atributo
NSS al fragmento de
información personal
2.7- Replicación y asignación de los datos
La replicación resulta útil para mejorar la disponibilidad de los datos. El caso más
extremo de la replicación de toda la base de datos en todos los sitios del sistema
distribuido creando así una base de datos distribuida totalmente replicada. Puede
mejorar la disponibilidad notablemente por que el sistema puede seguir operando
mientras por lo menos unos de los sitios esta activado. También mejora el
rendimiento de la recuperación de consultas globales por que el resultado de
semejante consulta se pueden obtener totalmente en cualquier sitio así; una
consulta de recuperación se puede procesar en el sitio local donde se introduce, si
dicho sitio cuenta con un modulo servidor. La desventaja de la replicación
completa es que puede reducir drásticamente la rapidez de las operaciones de
actualización, pues una sola actualización lógica se deberá ejecutar en todas y
cada una de las copias de las bases de datos a fin de mantener la consistencia.
Esto es especialmente cierto si existen muchas copias de las bases de datos. Con
la replicación completa, las técnicas de control de concurrencia y recuperación se
vuelven más costosas de los que serian sin replicación.
En externo opuesto a la replicación completa, es no tener ninguna replicación esto
es, cada fragmento se almacena exactamente en un sitio. En este caso todos los
fragmentos deben ser disjuntos, con excepción de la repetición de claves
31
primarias en los fragmentos verticales o mixtos. Esto se denomina también
asignación no redundante.
En estos dos extremos, tenemos una amplia gana de replicación parcial de los
datos; es decir, algunos fragmentos de la base de datos pueden estar replicados y
otros no. El número de copias de cada fragmento puede ir desde uno hasta el
número total de sitios en el sistema distribuidos. Un caso especial de replicación
parcial ocurre con frecuencia en aplicaciones donde trabajadores que se
desplazan como vendedores gestores financieros y reguladores de reclamaciones
llevan con ellos bases de datos parciales replicadas en computadores portátiles y
asistentes digitales personales y las sincronizan periódicamente con la base de
datos en el servidor. En ocasiones se llama esquema de replicación a una
descripción de la replicación de los fragmentos.
Cada fragmento, o copia de un fragmento se debe asignar a un sitio determinado
en el sistema distribuido. Este proceso se denomina distribución de datos (o
asignación de los datos). La elección de sitios y el grado de replicación depende
de los objetivos de rendimiento y disponibilidad para el sistema y de los tipos de
frecuencias de transacciones introducidas en cada sitio. Por ejemplo si se requiere
una alta disponibilidad y las transacciones se pueden introducir en cualquier sitio y
si la mayoría de ellas son de recuperación, entonces una base de datos
completamente replicada será una buena opción. Sin embargo si por lo general
ciertas transacciones se tiene acceso a partes especificas de la base de datos se
introducen en un solo sitio, se podría asignar el conjunto de fragmentos
correspondiente exclusivamente a este sitio los datos que se utilizan en múltiples
sitios se puede replicar en esos sitios. Si se efectúan muchas actualizaciones
puede ser conveniente limitar la replicación. Encontrar una solución optima o
incluso buena, para la asignación de datos distribuidos en un problema de
optimización muy complejo
2.8- Tipos de sistemas de bases de datos distribuidas
32
El termino sistema de gestión de base de datos distribuida puede describir
diversos sistemas que presentan muchas diferencias entre sí. El punto principal
que todos estos sistemas tienen en común es el hecho de que los datos y el
software están distribuidos entre múltiples sitios conectados por alguna especie de
red de comunicaciones, como se muestra en la figura 2.2
Figura 2.2 Ejemplo de una Base de datos Distribuida
El primer factor a considerar es el grado de homogeneidad del software de
SGBDD. Si todos los servidores o SGBDD locales individuales utilizan software
idéntico y todos los usuarios (clientes) emplean software idéntico, se dice que el
SGBD es homogéneo en caso contrario se le denomina heterogenia. Otro factor
relacionado con el grado de homogeneidad es el grado de autonomía local. Si el
sitio local no puede funcionar con un SGBD autónomos, el sistema no tiene
33
autonomía local. Por otro lado, si se permiten las transacciones locales acceso
directo a un servidor, el sistema tendrá cierto grado de autonomía local.
En un estreno de la gana de autonomía, tenemos un SGBDD que da al usuario la
impresión de ser un SGBD centralizado. Solo hay un esquema conceptual y todo
acceso al sistema se hace a través de un sitio que es parte del SGBDD de modo
que no hay autonomía local. En el otro extremo nos encontramos con un SGBDD
denominado SGBDD federado (o sistema de múltiples bases de datos). En un
sistema así, cada servidor es un SGBD centralizado independiente y autónomo,
que tiene sus propios usuarios locales, transaccionales locales y ABD, por los
tanto posee un alto grado de autonomía local. El término “sistema de bases de
datos federadas” ( SBDF) se utiliza cuando hay algún esquema o vista global de la
federación de bases de datos que es compartido por las aplicaciones. Por otro
lado, un sistema de múltiples bases de datos no tiene un esquema global e
interactivamente, construye uno según la aplicación lo necesite. Los dos sistemas
son un hibrido entre sistemas centralizados y distribuidos, y la distribución que
hemos hecho entre ellos no se sigue estrictamente nos referimos a ambos como
SBDF en un sentido genérico.
Es un SBDF heterogenia, un servidor podría ser un SGBD relacional, otro un
SGBD en red, y un tercero SGBD jerárquico o de objetos; en un caso así es
necesario disponer de un lenguaje de un sistema canónico, e incluir traductores de
lenguaje para traducir sub consultas de lenguaje canónico al lenguaje de cada
servidor.
2.8.1- Características de los sistemas de gestión de bases
de datos
El tipo de heterogeneidad presente en los SBDF puede provenir de varias fuentes
•
Diferencias de modelos de datos; la base de datos de una organización
provienen de una variedad de modelos de datos incluyendo los llamados
modelos legados (red y jerárquicos). El modelo de datos relacional, el
34
modelo de datos de objetos e incluso ficheros. Las capacidades de
moderado de los modelos varían. Por tanto, es desafiante tratar con ellos
uniformemente a través de un único tema global o procesarlo en un único
lenguaje. Incluso si dos bases de datos son ambas del entorno de SGBDR,
la misma información podrá representarse como un nombre de atributo,
como un nombre de relación, o como un valor, en dicha base de datos
diferente. Esto requiere un mecanismo de procesamiento de consultas
inteligentes que pueda relacionar información basada en metadatos
•
Diferencia de restricciones. Las facilidades para especificar e implementar
restricciones varían de un sistema a otro. Existen características
comparables que deben reconciliarse en la construcción de un esquema
global, por ejemplo, las relaciones de los modelos ER se representan como
restricciones de integridad referencial, en el modelo relacional. En este
modelo
se
deben
utilizar
disparadores
para
implementar
ciertas
restricciones. El esquema global debe enfrentarse también a posibles
conflictos entre restricciones.
•
Diferencias en lenguaje de consulta. Incluso en el mismo modelo de datos,
los lenguajes y sus versiones varían. por ejemplo, SQL tiene muchas
versiones como sql-89, sql-92, etc. Y cada sistema tiene su propio conjunto
de tipos de datos y operadores de comparación, características de
manipulación y cadena de caracteres, etc.
Heterogeneidad semántica
La heterogeneidad semántica se da cuando hay diferencias en el significado,
interpretación y el uso propuesto de los mismos datos y de datos relacionados. La
heterogeneidad
semántica entre los sistemas de bases de datos (SGBD) de
componentes crea el obstáculo más grande en el diseño de esquemas globales de
bases de datos heterogenias. La autonomía de diseño de los SBD de
componentes se refiere a su libertad de elegir los siguientes parámetros de diseño
que afectan a la eventual complejidad de los SBDF.
35
•
El universo de discursos desde que se representa los datos; por ejemplo
dos bases de datos de cuentas de clientes de la federación podrían ser
estados unidos y Japón y podrían tener diferentes conjuntos de atributos
acerca de las cuentas de clientes requeridas para las practicas de
contabilidad. También podría presentar un problema las fluctuaciones de
las divisas. Por tanto las relaciones de estas dos bases de datos que tiene
nombres idénticos, clientes o cuenta podrían tener alguna información
común y alguna información totalmente distinta.
•
Representación y nombre: la representación y nombres de elementos de
datos y la estructura de los modelos de datos podría ser pre especificada
para cada base de datos local.
•
Entretenimiento significado, e interpretación subjetiva de los datos: estos
supone la principal contribución a la heterogeneidad semántica.
•
Restricciones de política y transacción: estas tratan del criterio de seriedad
compensación de transacciones y otras políticas de transacciones.
•
Derivación de resúmenes: la agregación, resumen y otras características
de procesamientos de datos y operaciones soportadas por el sistema.
La autonomía de comunicación de un SGBD componente se refiere a su habilidad
para decidir si comunicarse con otros SBD componentes. La autonomía de
ejecución se refiere a la habilidad de un SBD de componentes para ejecutar
operaciones locales, sin interferencia de operaciones externas de otros SBD
componentes y su habilidad para decidir el orden en que se ejecutaran. La
autonomía de asociación de un SBD componente implica que tiene la habilidad de
decidir si compartir su funcionalidad (operaciones que soporta) y recursos (datos
que gestiona) con otros SBD componentes y como. El mayor desafío en el diseño
de SBDF es permitir a los SBD componentes inter operar proporcionarles los tipos
de autonomía antes descritos
2.9- Procesamiento de consultas de bases de datos
distribuidas
36
Costos de transferencia de datos en el procesamiento de consultas distribuidas
En un sistema distribuido existen varios factores adicionales que complican aun
más el procesamiento de consultas. El primeo es el costo de transferir datos por la
red. Estos datos incluyen los ficheros intermedios que se transfieren a otros sitios
para continuar su procesamiento, así mismo los ficheros de resultado final que
puede que deban transferirse al sitio donde se necesita el resultado de la consulta.
Aunque es posible que estos costos no sean demasiado altos si los sitios están
conectados por medio de una red de área local de alto rendimiento, adquieren una
importancia considerable en otros tipos de redes. Por ello, los algoritmos que
optimización de consultas de los SGBDD consideran el objetivo de reducir la
cantidad de transferencia de datos como criterio de optimización al elegir una
estrategia de ejecución de una consulta distribuida
Procesamiento de consultas distribuidas por semirreunion
El procesamiento de consultas distribuidas mediante la operación de semirreunion
se basa en la idea de reducir el número de tuplas de una relación antes de
transferirla a otro sitio. Intuitivamente la idea es enviar la columna de reunión de
una relación R al sitio donde se encuentre la otra relación S; esta columna se
reúne entonces con S. después de esto los atributos de reunión, junto con los
atributos requeridos en el resultado, se extraen por proyección de R en una
dirección, y un subconjunto de S que no contenga tuplas o atributos que no
intervengan en el resultado se transfiere en la otra dirección. Si solo una pequeña
fracción de las tuplas S participa en la reunión, esto puede ser una solución
bastante eficiente para minimizar las tuplas de S participa en la reunión, esto
puede ser una solución bastante eficiente para minimizar la transferencia de datos
Descomposición de actualizaciones y de consultas
En un SGBD sin trasparencia de distribución, el usuario expresa su consulta
directamente en términos de fragmentación específicos.
37
Un SGBDD que ofrezca transparencia de distribución, de fragmentación y de
replicación completa permitirá al usuario especificar una consulta o solución de
actualización.
En el caso de las actualizaciones, el SGBDD se encarga de mantener la
consistencia entre los elementos replicados usando alguno de los algoritmos de
control de concurrencia distribuida.
En el caso de las consultas, un modulo de descomposición de consultas deberá
dividir o descomponer una consulta en sub consultas que se puedan ejecutar en
los sitios individuales. Además, deberá generarse una estrategia pata combinar los
resultados de las sub consultas y formar el resultado de la consulta. Siempre que
el SGBDD determine que un elemento al que se hace referencia en la consulta
esta replicado, deberá escoger o materializar una réplica especifica durante la
ejecución de dicha consulta
El SGBDD consulta la información de fragmentación, replicación y distribución
almacenada en su catálogo. En la fragmentación vertical, la lista de atributos de
cada fragmento se guarda en el catalogo. En la fragmentación horizontal, se
guarda una condición, a veces llamada de guarda, para cada fragmento, esta es
básicamente una condición de selección que especifica que tuplas están en el
fragmento. Esta es básicamente una condición de selección que especifica que
tuplas están en el fragmento; se le llama guarda porque solo las tuplas que
satisfacen esta condición pueden estar almacenadas en el fragmento. En el caso
de fragmentos mixtos, tanto la lista de atributos como la condición de guarda se
mantienen en el catalogo.
2.10- Control de concurrencia y recuperación en Bases
de datos distribuidas
El control de concurrencia y la recuperación en un entorno de SGBDD distribuido,
surge numeroso problemas que no se encuentran en los entornos de SGBD
centralizados. Como:
38
•
Manejar múltiples copias de los elemento de datos: el método de control de
concurrencia tiene la obligación de mantener la consistencia entre estas
copias. El método de recuperación debe cuidar que una copia sea
consistente con todas las demás si el sitio en el que la copia estaba
almacenada falla y se recupera posteriormente.
•
Fallo de sitio individual él: SGBDD distribuido debe continuar operando con
sus sitios activos, si es posible, cuando fallen uno o más sitios individuales,
cuando un sitio se recupere su base de datos local se deberá poner al día
con los demás sitios antes de que se incorpore al sistema.
•
Fallo en enlaces de comunicación: el sistema debe ser capaz de manejar el
fallo de uno o más de los enlaces de comunicación que conectan los sitios.
Un caso extremo de este problema es que puede haber partición de la red.
Esto divide los sitios en dos o más particiones, dentro de las cuales los
sitios pueden comunicarse entre sí pero no con sitios de otras particiones
•
Configuración distribuida: puede haber problemas para confirmar una
transacción que está teniendo acceso a la base de datos almacenadas en
múltiples sitios si algunos de estos fallan durante el proceso de
configuración. A menudo se utiliza el protocolo de confirmación en dos
fases
•
Bloqueo mortal distribuido: puede ocurrir un bloqueo mortal entre varios
sitios, lo que hace necesario extender las técnicas de manejo de bloqueos
mortales
Las técnicas de control de concurrencia y de recuperación distribuida deben
resolver estos y otros problemas.
Control de concurrencia distribuido basado en una copia distinguida
Consiste en designar una copia determinada de cada elemento de datos como
copia distinguida. Los bloqueos para este elemento de datos se asocian a la copia
distinguida, y todas las solicitudes de bloqueo y desbloqueo se envían al sitio que
contiene esa copia.
39
La técnica de sitios primario, todas las copias distinguidas se guardan en el mismo
sitio. Una modificación de este bloqueo es el sitio primario con sitio de respaldo.
Otro enfoque es el método de copia primaria, en el que las copias distinguidas de
los diversos elementos de datos se pueden almacenar en diferentes sitios. Un sitio
que incluye una copia distinguida de un elemento de datos actual básicamente
como sitio coordinador para el control de concurrencia de ese elemento.
Técnica de sitio primario: en este método se designa un solo sitio primario como
sitio coordinador pata todos los elementos de la base de datos. Por tanto, todos
los bloqueos se mantienen en ese sitio, y todas las solicitudes de bloqueo y
desbloqueo se envían a este sitio. Así pues, este método es una extensión del
enfoque centralizado. Por ejemplo, si todas las transacciones siguen el protocolo
de bloqueos en dos fases, la seriabilidad está garantizada. La ventaja de este
enfoque es que es una simple extensión del enfoque centralizado y por tanto no es
demasiado complejo. Sin embargo, posee ciertas desventajas inherentes. Una de
ellas es que todas las solicitudes de bloqueo se envían a un mismo sitio, con lo
que posiblemente se sobrecargue ese sitio y se origine un cuello de botella del
sistema. La segunda desventaja es que un fallo del sitio
primario paraliza el
sistema, ya que toda la información de bloqueo se mantiene en dicho sitio. Esto
puede limitar la fiabilidad y la disponibilidad del sistema
Sitio primario con sitio respaldo
Este enfoque busca la segunda desventaja del método anterior designado un
segundo sitio como sitio de respaldo. Toda la información de bloqueo se mantiene
tanto en el sitio primario como en el de respaldo. En caso de fallar el sitio primario,
el de respaldo puede asumir las funciones de sitio primario, y se puede escoger un
nuevo sitio de respaldo. Esta simplificada el proceso de recuperarse de un fallo del
sitio primario, ya que el sitio de respaldo asume sus funciones y el procesamiento
puede reanudarse una vez que se elija el nuevo sitio de respaldo y la información
de estado de los bloqueos se copie en el . sin embrago, el proceso de adquisición
de bloqueos se hace más lento , porque todas las solicitudes de bloqueos y la
concesión de los mismos se deben guardar tanto en el sitio primario como en el de
40
respaldo antes de enviar una respuesta la transacción solicitante. El problema de
que los sitios primarios y de respaldo se sobrecarguen con solicitudes y hagan
más lento el sistema no se alivia en absoluto
Técnica de copia primaria:
Este método intenta la carga de la coordinación de los bloqueos entre varios sitios
manteniendo las copias distribuidas
de diferentes elementos de datos
almacenadas en diferentes sitios. El fallo de un sitio afecta las transacciones que
están teniendo acceso a bloqueos sobre elementos cuyas copias primarias
residan en ese sitio, pero las demás transacciones no resultan afectadas. Este
método también puede usar sitios de respaldo para elevar la fiabilidad y la
disponibilidad
Elección de un nuevo sitio coordinador en caso de fallo
Siempre que un sitio coordinador falle en cualquiera de las técnicas, los sitio que
siguen activos deberán elegir un nuevo coordinador. En el caso del enfoque de
sitio primario sin sitio de respaldo, será preciso abortar y reiniciar todas las
transacciones en ejecución, y el proceso recuperación será bastante tedioso .
Parte de dicho proceso implica elegir un nuevo sitio primario y crear un proceso
gestor de bloqueos y un registro de toda la información de bloqueos en ese sitio.
En los métodos que usan sitios se respaldo, el procesamiento de transacciones se
suspende mientras el sitio de respaldo se desina como nuevo sitio primario, se
escoge un nuevo sitio de respaldo y se envía a él copias de roda la información de
bloqueo del nuevo sitio primario.
Si el sitio de respaldo X está a punto de convertirse en el nuevo sitio primario, x
puede escoger el nuevo sitio de respaldo entre los sitios del sistema. Sin embrago
si no hay sitios de respaldo, o si están caídos tanto el sitio primario como el de
respaldo, se puede seguir un proceso denominado elección para escoger el nuevo
sitio coordinador. En este proceso, cualquier sitio
Y que intente comunicarse
41
repetidamente con el sitio coordinador y fracase puede suponer que el coordinador
esta caído e iniciar el proceso de elección enviando un mensaje a toso los sitios
activos en el cual proponga que Y se concierta en el nuevo coordinador. Tan
pronto como Y reciba una mayoría de voto, puede declararse que es el nuevo
coordinador
2.11- Recuperación distribuida
El proceso de recuperación en las bases datos distribuidas, es bastante
complicado. Aquí daremos solo una idea de algunos de sus aspectos. En ciertos
casos incluso es bastante difícil determinar si un sito esta caído intercambiar un
gran número de mensajes con otros sitios. Por ejemplo si un sitios a envía un
mensaje al sitio b y espera una respuesta el b pero no la recibe. Hay varias
explicaciones posibles
1.- El mensaje no llego a b debido a un fallo en la comunicación
2.- El sitio b esta caído y no puede responder
3.- El sitio b esta activo y envió una respuesta, pero esta no llego
Es difícil determinar que sucedió realmente.
Otro problema con la recuperación distribuida es la configuración distribuida,
cuando una transacción está actualizando datos en varios sitios, no puede
conformarse hasta asegurarse de que el efecto de la transacción no puede
perderse en ningún sitio. Esto significa que cada sitio debe haber guardado
primero permanentemente los efectos locales de la transacción en el diario local
es el disco del sitio. A menudo se usa el protocolo de confirmación de dos fases
2.12- Arquitectura cliente-servidor y relación con bases
de datos distribuidas.
Según C, Date. (2010),SGBDD a escala completa no han sido desarrollados para
soportar todos los tipos de funcionalidades que hemos explicado. En cambio las
42
aplicaciones de bases de datos distribuidas se desarrollan en el contexto de la
arquitectura cliente- servidor
Aun no se ha establecido como dividir la funcionalidad del SGBD entre el cliente y
el servidor. Se han propuestos diferentes enfoques. Una posibilidad es incluir la
funcionalidad de un SGBD centralizado en nivel del servidor. Varios productos del
SGBD relacionadas han tomado este enfoque , en el que se proporciona a los
clientes un servidor SQL. Entonces cada cliente debe formular las consultas SQL
apropiadas y proporcionar una interfaz del usuario y funciones de interfaz del
lenguaje de programación. Mientras SQL están relacionado, algunos servidores
SQL, posiblemente proporcionados por diferentes vendedores, pueden aceptar
instrucciones SQL. El cliente suele también referirse al diccionario de datos que
incluye información de la distribución de los datos entre varios servidores SQL, así
como módulos para descomponer una consulta global en varias consultas locales
que pueden ejecutarse en varios sitios. La interacción n entre el cliente y el
servidor durante el procesamiento de una consulta SQL, podría proceder de la
siguiente manera.
1.- El cliente analiza una consulta de usuario y la descompone en varias consultas
de sitios independientes. Cada consulta de sitios se envía al correspondiente sitio
servidor
2.- Cada servidor procesa la consulta local y envía la relación resultante al sitio
cliente
3.- El sitio cliente combina los resultados de las sub consultas para producir el
resultado de la consulta original realizada
En este enfoque el servidor SQL también se denomina servidor de transacciones
(o procesador de base de datos o maquina del sistema subyacente), mientras que
el cliente se denomina procesador de aplicaciones ( o maquina del aparte visible al
usurario). La interacción entre el cliente y el servidor puede especificarla el
usuario en el nivel cliente o mediante un modulo especializado del SGBD que es
parte del paquete SGBD. Por ejemplo el usuario debería saber los datos que están
43
almacenados en cada servidor dividir manuela mente una petición de consulta en
sub consultas del sitio, y remitir las sub cuentas individuales a los diferentes sitos,
las tablas resultantes la debe combinar explícitamente las consultas del usuario en
el nivel del cliente. La alternativa es hacer que el modulo cliente se encargue de
estas acciones automáticamente. En un SGBDD típico, es usual dividir los
módulos software en tres niveles
1.- El software del servidor es el responsable de la gestión de los datos locales en
el sitio, al igual que el software del SGBD centralizado
2.- El software del cliente es el responsable de la mayoría de las funciones de
distribución, accede a la información a la distribución de los datos que están en el
catalogo del SGBDD y procesa todas la peticiones que requieren acceso a más de
un sitio. También maneja las interfaces del usuario
3.- El software de comunicaciones (alguna veces conjunto con un sistema
operativo distribuido) proporciona las primitivas de comunicación que utiliza el
cliente para transmitir instrucciones y datos entre los sitos necesario.
Esta no es una parte estrictamente del SGBDD, pero proporciona servicios y
primitivas de comunicación esenciales
El cliente es el responsable de generar un plan de ejecución distribuida para una
transacción o consulta que indique varios sitos (multisitio) y de supervisar la
ejecución distribuida enviando instrucciones a los servidores. Estas instrucciones
incluyen las consultas locales y transacciones que se van a ejecutar, así como la
instrucciones para transmitir datos a otros cliente so servidores. Por tanto el
software cliente deberá incluirse en algunos sitios donde se introduzcan las
consultas multicitios. Otra función controlada por el cliente (o coordinador) es la de
asegurar la consistencia de replicación de copias de elementos de datos,
empleando técnicas de control de concurrencia distribuida o global. El cliente debe
también asegurar la atomicidad de transacciones globales realizando una
recuperación global cuando fallen ciertos sitos analizamos la recuperación
distribuida y el control de concurrencia. Una posible función del cliente es
44
esconder los detalles de la distribución de datos del usuario; es decir permite al
usuario escribir transacciones y consulta globales como si la base de datos fuese
centralizada sin tener que especificar los sitios donde se realicen los datos
referenciados en la consulta o transacción. A esta propiedad es le denomina
transparencia de distribución algunos SGBDD no proporcionan transparencia de
distribución y requiere que el usuario este atento a los detalles de la distribución
de datos.
En este capítulo se menciono en qué consiste una base de datos distribuidas las
múltiples funciones y ventajas que esta representa y es fundamental que se
entienda que son las bases de datos distribuidas para entender en qué consiste la
fragmentación de una base de datos distribuida.
45
Capitulo 3: Replicación y Fragmentación de los
datos en una Base de Datos Distribuida.
46
La administración de bases de datos distribuidas en redes de computadoras con
cientos de usuarios conectados concurrentemente, es un problema actual en
muchas empresas que compiten en los mercados mundiales. Debido al alto grado
de conectividad que provee Internet a las empresas, el problema del diseño de la
distribución de las bases de datos ha recuperado su vigencia. Este problema
consiste en tratar de determinar la mejor forma de dividir las relaciones de la base
de datos en fragmentos en los diversos sitios de la red.
Silberschatz, Abraham. (2006) maneja tres enfoques de almacenamiento de esta
relación de la base de datos distribuida.
•
Replica: el sistema conserva replicas (copias) idénticas de la relación y guarda
cada réplica en un sitio diferente. La alternativa a la réplica es solo almacenar
una copia de la relación r
•
Fragmentación: el sistema divide la relación en varios fragmento y guarda el
fragmento en un sitio diferente.
•
Replica y fragmentación: la relación se divide en varios fragmentos. El sistema
conserva varias replicas de cada fragmento.
•
3.1- Replicación
Según
Coronel,
Carlos.
(2004),
la
replicación de
datos se
refiere al
almacenamiento de copias en sitios múltiples servidores por una red de
computadoras. Pueden guardarse copias de fragmentos en vario sitios para
satisfacer requerimientos de información específicos. Como la existencia de
copias de fragmentos puede mejorar la disponibilidad de los datos y el tiempo de
respuesta, estas copias reducen los costos de comunicación y de consulta totales.
47
La base de datos A esta dividida en dos fragmentos: A1 y A2. Dentro de una base
de datos distribuida replicada, es posible el escenario ilustrado en la figura 3. 1se
guarda en los sitios S1 y S2, mientras que el A2 se guarda en los sitios S2 y S3.
Figura 3.1 Replicación de Datos
Los datos replicados se someten a la regla de consistencia mutua. La regla de
consistencia mutua requiere que todas las copias de fragmentos de datos sean
idénticas. Por consiguiente, para mantener la consistencia de los datos entre
replicas, el DDBMS debe garantizar que se realice una actualización de la base de
datos en todos los sitios donde existen replicas.
Aunque la replicación tiene algunos beneficios, también exige más complejidad de
procesamiento del DDBMS, porque cada copia de datos debe ser mantenida por
el sistema. Para ilustrar la complejidad impuesta a un DDBMS, los procesos que el
DDBMS debe realizar para utilizar la base de datos:
•
Si la bese de datos está fragmentada, el DDBMS debe decidir que copia
acezar
•
Una operación Read (lectura) selecciona la copia más cercana para satisfacer
la transacción, una operación write (escritura) requiere que todas las copias se
seleccionen y actualicen para satisfacer la regla de consistencia muta
48
•
El procesador de transacciones envía una solicitud de datos a cada procesador
de datos para su ejecución
•
El procesador de datos recibe y ejecuta cada solicitud y envía los datos de
vuelta al procesador de transacciones
•
El procesador de transacciones arma las respuestas del procesador de datos
El problema se complica más cuando se consideran factores adicionales tales
como la topografía de la red y procesamiento de comunicación.
Como regla general se debe considerar que la replicación de fragmentos es de
utilidad cuando el número de consultas de solo lectura es (mucho) mayor que
el número de consultas para actualizaciones.
3.1.1- Tipos de replicación
De acuerdo con Silberschatz, Abraham. (2006), existen tres escenarios de
replicación: una base de datos puede ser totalmente replicada, parcialmente
replicada o no replicada.
•
Una base de datos totalmente replicada guarda varias copias de cada
fragmento de la base de datos en varios sitios. En este caso, los fragmentos de
la base de datos están replicados. Una base de datos totalmente replicada
puede no ser práctica debido la cantidad de carga impuesta al sistema y puede
reducir drásticamente la rapidez de las operaciones de actualización, pues una
solo actualización lógica se deberá ejecutar con todas y cada una de las copias
de la base de datos a manera de mantener la consistencia.
•
Una base de datos parcialmente replicada guarda múltiples copias de algunos
fragmentos de la base de datos en múltiples sitios. La mayoría de los DDBMS
son capaces de manejar bien la base de datos parcialmente replicada
•
Una base de datos no replicada guarda cada fragmento de base de datos en
un solo sitio. Por consiguiente, no existe fragmentación de base de datos
duplicados. En este caso todos los fragmentos deben ser disjunta, con
49
excepción de la repetición de claves primarias entre los fragmentos verticales
(o mixtos). Esto se denomina también reparto no redundante
Procesamiento de
Consultas
Manejo de
Directorios
Control de
Concurrencia
Confiabilidad
Realidad
Replicación
Completa
Fácil
Replicación
Parcial
Moderado
No replicada
Fácil o no
existente
Moderado
Moderado
Moderado
Difícil
Fácil
Muy alto
Aplicación
posible
Alto
Realista
Bajo
Aplicación posible
Lento
Tabla 3.1. Comparación de las estrategias de replicación de fragmentos.
3.1.2- Factores para la replicación
Según Coronel, Carlos. (2004), Varios factores influyen en la decisión de utilizar
replicación de datos:
•
Tamaño de la base de datos
•
Frecuencia de uso
•
Costo—desempeño, software, indirectos y de administración—asociados
con la sincronización de las transacciones y sus componentes contra los
beneficios de tolerancia a las fallas asociados con los datos replicados
Cuando la frecuencia de uso de los datos remotamente localizados es elevada y la
base de datos es grande, la replicación de los datos, reduce el costo de las
solicitudes de datos. La información sobre la replicación de los datos se guarda en
el catalogo de datos distribuidos (DDC), cuyo contenido es utilizado por el
50
procesador de transacciones para decidir que copia de fragmento de base de
datos acezar. La replicación de datos permite recuperar los datos perdidos.
Replica de datos si la relación r se replica se guarda una copia de dicha relación
en dos o más sitos, en el caso más extremo se tiene una réplica completa en la
que se guarda una copia en cada sitio del sistema.
3.1.3- Ventajas y Desventajas de la replicación
Continuando con Silberschatz, Abraham. (2006), quien considera que existen
varias ventajas y desventajas de la réplica:
•
Disponibilidad. Si algunos de los sitos que contiene la relación falla la relación
puede hallarse en otro sitio distinto por tanto, el sistema puede seguir
procesando las consultas que incluyan a r pese al fallo del sitio.
•
Paralelismo incrementado. En caso en que la mayoría de los acceso de la
relación r solo resulten en la lectura de la relación, varios sitios pueden
procesar en paralelo las lecturas que impliquen la r cuantas más replicas r
haya mayor será las disponibilidad de que los datos necesarios se hallan en el
sitio en que se ejecuta la transacción pro tanto la réplica de los datos minimiza
el movimiento de los datos entre los sitios
•
Sobre carga incrementado durante la actualización. El sistema debe asegurar
que todas las replicas de la relación r sean consistentes en caso contrario
pueden producirse cómputos erróneos, por eso siempre que se actualiza r ahí
que propagara la actualización a todos los sitios que contiene replicas. El
resultado de una sobre carga incrementada. Por ejemplo, en un sistema
bancario en donde se replica en varios sitios la información e las cuentas es
necesario asegurarse de que el saldo de cada cuenta concuerde en todos los
sitios. En general, la réplica mejora el rendimiento de las operación leer y
aumenta la disponibilidad de los datos para que las transacciones solo de
lectura. No obstante la transacciones de actualización suponen una mayor
51
sobrecarga. El control de las actualizaciones de actualización realizadas por
varias transacciones en los datos replicados resulta más complicado que en los
sistemas centralizados. Se puede simplificar la gestión de las replicas de la
relación r escogiendo un de ellas como copia principal de r, por ejemplo en un
sistema bancario las cuentas pueden asociarse con el sitio en que se abrieron.
de manera parecida, en un sistema de reserva de billetes de avión los vuelos
pueden asociarse con el sitio en que se origina el vuelo.
•
Coste del desarrollo de software: es más difícil estructura un sistema de bases
de datos distribuidos y por tanto su coste es menor.
•
Mayor tiempo extra de procesamiento: el intercambio de mensajes y los
cálculos adicionales son una forma de tiempo extra que no existe en los
sistemas centralizados.
La decisión del tipo de replica es muy importante ya que proporciona ventajas y
desventajas como se muestra en la figura 3.2 que compara una base da datos
unificada y una base de datos distribuida.
Figura 3.2 Ventajas y desventajas de las formas de replicación
52
3.2- Fragmentación de los datos.
Continuando con Silberschatz, Abraham. (2002), Si la relación r se fragmenta, se
divide en varios fragmentos r1, r2,… rn. Estos fragmentos contienen suficiente
información como para permitir la reconstrucción de la relación original r ahí dos
esquemas diferentes de fragmentación de las relaciones, fragmentación horizontal
y fragmentación vertical.
3.2.1 Requerimientos de información
Con el fin de realizar una fragmentación adecuada es necesario proporcionar
información que ayude a realizarla. Esta información normalmente debe ser
proporcionada por el usuario y tiene que ver con cuatro tipos:
•
Información sobre el significado de los datos
•
Información sobre las aplicaciones que los usan
•
Información acerca de la red de comunicaciones
•
Información acerca de los sistemas de cómputo
3.2.2- Fragmentación horizontal.
La fragmentación horizontal divide la relación asignando cada tuplas de r en uno
más fragmentos. La fragmentación vertical divide la relación descomponiendo el
esquema R de la relación r.
En la fragmentación horizontal de la relación r se divide en varios subconjuntos r1,
r2…rn .cada tupla de relación r debe pertenecer como mínimo a uno de los
fragmentos de modo que se pueda reconstruir la relación original, si fuera
necesario.
53
A modo de ejemplo, la cuenta puede dividirse en varios fragmentos cada uno
puede dividirse en varios fragmentos, cada uno de los cuales consiste en tuplas de
cuentas que pertenecen a una sucursal concreta.
La fragmentación horizontal suele utilizarse para conservar las tuplas de los sitios
en que más se utilizan para minimizar las transferencias de datos. En general, los
fragmentos horizontales pueden definirse como una selección de la relación global
r. es decir se utiliza un predicado Pi para construir fragmentos ri.
Una manera de asegurar que la relación r puede reconstruirse es incluir los
atributos de la llave principal de R en cada uno de los fragmentos Ri . de manera
más general se puede utilizar cualquier súper clave. Suele resultar conveniente
añadir un atributo especial denominado id- tupla al esquema R. el valor id- tupla de
una tupla es un valor único que distingue cada tupla de todas las demás tuplas.
Atributo id. Tupla por tanto, sirve como calve candidata para el esquema
aumentado y se le incluye en cada uno de los fragmentos ri. La dirección física o
lógica de la tupla puede utilizarse con id-tupla dado que cada tupla tiene una
dirección única.
Ejemplo:
Supongamos que la gerencia corporativa de la XYZ Company requiere
información sobre sus clientes en los tres estados, pero las ubicaciones de la
compañía en cada estado ( TN, FL, GA) solamente requieren datos con respecto
a clientes locales. Con base en esos requerimientos, se decide distribuir los datos
por estado . por consiguiente, se definen los fragmentos horizontales de acurdo
con la estructura mostrada en la tabla 3.1….
Tabla 3.2 Fragmentación Vertical de la Tabla Clientes
54
Cada fragmento horizontal puede tener un numero diferente de filas pero casa uno
de ellos debe, tener los atributos. Los fragmentos resultantes producen las tres
tablas ilustradas
Tabla 3.3 Fragmentación de la tabla en tres lugares
3.2.3- Fragmentación vertical
Continuando con
Silberschatz, Abraham. (2002), La fragmentación vertical
considérese una base de datos universitaria con una relación info-empleado que
almacena, para cada empleado, id-empleado, nombre, puesto y salió. Por motivos
de preservación de la intimidad puede que esta relación se fragmente en una
relación empleado-info privada que contenga id-empleado y salario, y en otra
relación empleado-info- publica que contenga los atributos id-empleado, nombre y
puesto. Puede que las dos relaciona se almacenen en sitios diferentes
nuevamente por motivos de seguridad.
Se puede aplicar a los dos tipos de fragmentación a una solo esquema; por
ejemplo, los objetos obtenidos de la fragmentación horizontal, pueden dividirse
nueva mente de maneja vertical, los fragmentos también pueden replicarse en
general los fragmentos pueden replicarse, la réplica de los fragmentos pueden
fragmentarse y más.
Ejemplo:
55
Puede dividirse la relación Cliente, en fragmentos verticales compuestos de un
conjunto de atributos. Por ejemplo suponga que la compañía está dividida en dos
departamentos, en el de servicio y el de colecciones. Cada departamento está
ubicado en un estilo distinto, y cada uno tiene intereses solamente en unos
cuentos de los atributos de la tabla Cliente. En este caso, los fragmentos se
dividen como se demuestra en la tabla.
Tabla 3.4 Fragmentación Vertical de la tabla Clientes
Cada fragmento vertical debe tener el mismo número de filas pero la inclusión de
los diferentes tributos depende de la columna clave. Los resultados de la
fragmentación vertical se muestran en la figura. Observe que el atributo clave
(CUS_NUM) es común a ambos fragmentos CUS_V1 y CUS_V2.
56
Figura 3.3 Fragmentación Vertical del contenido de la tabla
3.2.4 Fragmentación mixta
Podemos relacionar los dos tipos de fragmentación para tener una fragmentación
mixta
Esquemas de fragmentación: de una base de datos es una definición de un
conjunto de fragmentos que incluye todos los atributos y tuplas de la base de
datos y satisface la condición de que la base de datos completa se puede
reconstruir a partir de los fragmentos mediante alguna secuencia de operación de
UNION EXTERNA (reunión externa) y UNION. En ocasiones también es útil pero
no necesario que todos los fragmentos sean disjuntos, excepto la repetición de las
claves primarias de los fragmentos verticales(o mixtos) en este último caso toda la
replicación y distribución de los fragmentos se especifica claramente en una etapa
siguiente, aparte de la fragmentación.
Esquema de asignación: describe la asignación de los fragmentos entre los sitios
del SBDD; por tanto, es una correspondencia, que especifica el sitio o sitios donde
se almacena cada fragmento. Si un fragmento se almacena en más de una sitio se
dice que esta replicado.
Ejemplos
La estructura de la XYYZ Company requiere que los datos Cliente se fragmenten
horizontalmente para acomodar las diferentes ubicaciones de la compañía dentro
de las ubicaciones, los datos deben ser fragmentados verticalmente para
acomodar los diferentes departamentos (Servicio y colección). En suma, la tabla
Cliente Requiere una fragmentación mixta.
La fragmentación Mixta requiere un procedimiento de los pasos.
1.- Se introduce la fragmentación horizontal por cada sitio, con base de la
ubicación dentro de un estado (CUS_STATE). La fragmentación horizontal
57
produce los subconjuntos de tuplas Cliente (fragmentos Horizontales) localizados
en cada sitio, como los departamentos están localizados en edificios diferentes se
utiliza una fragmentación vertical dentro de cada fragmento horizontal para dividir
los atributos con los cual se satisfacen las necesidades de información de cada
departamento en cada sub sitio. La fragmentación mixta con los resultado se ven
ilustrados en la tabla 3.5
Tabla 3.5 Fragmentación Mixta de la tabla clientes
Cada fragmento mostrado en la tabla 3.5 Contienen datos de los clientes por
estado y dentro de cada estado por ubicación de departamento, para adaptarse a
los requerimientos de datos de cada departamento. Las tablas que corresponden
a los fragmentos listados en la tabla 3.5 Se muestran en la figura 3.4
58
Figura 3.4 Contenido de una tabla después del proceso de fragmentación
mezclada
59
3.4- Colocación de los datos
La colocación de los datos describe el proceso de decidir donde localizarlos. Las
estrategias de colocación de los datos son las siguientes:
•
Con la colocación centralizada de los datos: toda la base de datos se
guarda en un sitio
•
Con la colocación particionada de los datos, la base de datos se divide en
varias partes desarticuladas(fragmentos) y se guarda en varios sitios
•
En la colocación replicada de los datos: se guardan copias de uno o más
fragmentos de la base de datos en varios sitios
Según Coronel, Carlos. (2004), La distribución de los datos a través de una red de
computadora, se logra mediante la partición de los datos, replicación de los datos
o mediante una combinación de ambas. La colocación de los datos está
estrechamente relacionada con la manera en que una base de datos se divide o
fragmenta. La mayoría de los estudios de colocación de los datos se enfocan en
un tema: que datos localizar y en donde los algoritmos de colocación de los datos
consideran varios factores, incluidos:
•
Objetivos de desempeño y disponibilidad de los datos
•
Tamaño, numero de filas y numero de relaciones que una entidad
mantiene con otras entidades
•
Tipos de transacciones a ser aplicadas a la base de datos, los atributos
acezados por cada una de las transacciones, etc.
•
Algunos algoritmos incluyen datos externos, tales como la topología de la
red o la cantidad de datos procesados a través de la red. Aun no existen
algoritmos óptimos o universalmente aceptados
60
3.4.1- Criterios para escoger la colocación
Localidad de la data: la data debería ser colocada donde ésta se accede más
seguido. El diseñador debe analizar las aplicaciones y determinar cómo colocar la
data de tal forma que se optimicen los accesos a la data locales.
Suponga que hay un conjunto de fragmentos F = { F1, F2, ..., Fn } y una red que
consiste de los sitios S = { S1, S2, ..., Sm } en los cuales un conjunto de consultas
Q = { q1, q2, ..., qq } se van a ejecutar. El problema de asignamiento determina la
distribución "óptima" de F en S.
El problema de asignamiento determina la distribución "óptima" de F en S. La
optimisacion puede ser definida de acuerdo a las siguientes medidas:
•
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 dónde 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
61
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
•
Costo mínimo: Consiste del costo de comunicación de datos, del costo de
almacenamiento, y del costo procesamiento (lecturas y actualizaciones a
cada fragmento). El problema de asigna miento, entonces, pretende
encontrar un esquema de asigna miento que minimiza una función de costo
combinada
•
Rendimiento La estrategia de asigna miento se diseña para mantener una
métrica de rendimiento. Las dos métricas más utilizadas son el tiempo de
respuesta y el "throughput" (número de trabajos procesados por unidad de
tiempo).
En cualquier problema de optimización existen restricciones que se deben
satisfacer. El caso de distribución de fragmentos, las restricciones se establecen
sobre las capacidades de almacenamiento y procesamiento de cada nodo en la
red.
3.5- Transparencia
No se debe exigir a los usuarios de los sistemas distribuidos de bases de datos
que conozcan la ubicación física de los datos ni en el modo que se puede tener
acceso
a ellos en un sitio local concreto. Esta característica denominada
transparencia de los datos, puede adoptar varias formas:
62
•
Transparencia de la fragmentación. No se exige a los usuarios que conozcan el
modo en que se ha fragmentado la relación.
•
Transparencia de la replica: los usuarios ven cada objeto de datos como
lógicamente único. Puede que el sistema distribuido replique los objetos para
incrementar el rendimiento del sistema o la disponibilidad de los datos. Los
usuarios no deben preocuparse por los objetos que se hayan replicado ni por la
ubicación de estas replicas.
•
Transparencia de la ubicación. No se le exige a los usuarios que conozcan la
ubicación física de los datos. El sistema distribuido de bases de datos puede
poder hallar los datos siempre que la transacción del usuario facilite que el
identificador de los datos.
Los elementos de datos (como de las relación, los fragmentos y las replicas)
deben tener nombre únicos. Esta propiedad es decir de asegurar de una base de
datos centralizada. En las bases de datos distribuidas hay que tener cuidado para
asegurase de que dos sitios no utilicen el mismo nombre para elementos de datos
diferentes.
Una solución a este problema es exigir que todos los nombres se registren en un
servidor de nombres central. El servidor de nombres ayuda a asegurar que le
mismo nombre no se utilice para elementos de datos diferentes. También se
puede utilizar el servidor de nombre para ubicar un elemento de dato, dado que el
nombre del elemento. Este enfoque sin embrago presenta dos inconvenientes
principales en primer lugar, puede que el servidor de nombres se transforme en un
cuello de botella para el rendimiento cuando los elementos de datos, se ubican por
sus nombre, lo que da lugar a un bajo rendimiento. En segundo lugar, si el
servidor de nombres queda fuera de servicio puede que no sea posible que siga
funcionando ningún otro sito del sistema distribuido. Un enfoque alternativo más
utilizado, exige que cada sitio anteponga su propio identificador de sitio
a
cualquier nombre que generen. Este enfoque asegura que dos sitos no generan
nunca el mismo nombre (dado que cada sitio tiene un identificar único) ademan
63
son se necesita ningún control centralizado. Esta solución, no obstante no logra
conseguir la transparencia de la ubicación, dado que se adjunta a los nombres los
identificadores de los tipos. Así, se puede hacer referencia la relación en lugar de
meramente cuenta. Muchos sistemas de bases de datos utilizan la dirección de
internet de los sitios para identificarlos.
Para superar este sistema de base de datos puede crear un conjunto de nombres
alternativos, o aleas para los elementos de datos. Los usuarios se pueden referir a
los artículos mediante nombre sencillos que el sistema traduce en los nombres
completos. La asignación de los nombres reales puede almacenarse en cada sito.
Con los alias del usuario puede ignorar la ubicación física de los elementos de
datos. Además el usuario no se verá afectado si el administrador de la base de
datos decide trasladar un elemento de datos de un sitio a otro.
Los usuarios no deben tener que hacer referencia a una réplica concreta de un
elemento de datos en vez de eso, el sistema debe determinar las replicas a las
que hay que hacer referencia en la solicitudes leer y actualizar todas las replicas
de las solicitudes escribir., se puede asegura que lo hagan manteniendo una tabla
de catalogo, que le sistema utiliza para determinar todas las replicas de elementos
de datos.
64
CONCLUSION
65
El uso y la necesidad de contar con bases de datos va creciendo día con día, ya
que en cualquier empresa necesita guardar información ya sea sobre sus ventas,
compras, inventarios, clientes, empleados, información financiera, etc. Y al no
contar con esta información será muy difícil llevar un buen funcionamiento de
cualquier organización.
Las bases de datos facilitan la búsqueda y el almacenamiento de toda la
información, garantizando la fiabilidad de la información que esta contiene.
Las bases de datos distribuidas tienen múltiples ventajas. En primer lugar los
datos son localizados en lugar más cercano, por tanto, el acceso es más rápido, el
procesamiento es rápido debido a que varios nodos intervienen en el
procesamiento de una carga de trabajo, nuevos nodos se pueden agregar fácil y
rápidamente. La comunicación entre nodos se mejora, los costos de operación se
reducen, son amigables al usuario, la probabilidad de que una falla en un solo
nodo afecte al sistema es baja y existe una autonomía e independencia entre los
nodos.
Los almacenamientos de datos son un elemento fundamental para las empresas
por ello ha llamado la atención de estas ya que en la actualidad cualquier
compañía por pequeña que sea tiene que manejar grandes cantidades de
información, para poder tener control sobre todas las áreas de su empresa, es por
ello que surge la necesidad de emplear bases de datos dentro de las
organizaciones, no importando el giro de las empresas.
Por lo cual, se le denomina “Base de Datos” a la colección de datos aparentes
usados por el sistema de aplicaciones de una determinada empresa.
La mayoría de las empresas necesitan contar con bases de datos ya que las
bases de datos facilitan la realización de sus actividades, garantiza la seguridad,
la confiabilidad de la información, consistencia de los datos, mejora en la
disponibilidad
de
información,
guarda
información
sobres
sus
clientes,
proveedores, información financiera, inventarios, compras, ventas etc. Si
66
contamos con un buen control de la información se podrá llevar una empresa de
mejor manejar y mas organizadamente
La
gran
cantidad
de
información
que
producen
grandes
empresas
geográficamente distribuidas, ha generado una gran dispersión de los datos
asociados a sus sistemas de información. Para compartir dichos datos se requiere
de tecnología capaz de
integrarlos para permitir el acceso concurrente de
múltiples usuarios. Una de las tecnologías que se propone alcanzar este tipo de
objetivos son las bases de datos distribuidas
Las bases de datos distribuidas mejoran la disponibilidad de los datos pues
permite que el sistema pueda seguir operando y los usuarios desde cualquier sitio
puedan acceder a la información, exactamente igual como si los datos estuvieran
en el mismo sitio del usuario.
Las bases de datos, hoy en día, ocupan un lugar determinante en cualquier área
ya que se emplea en diversas empresas no importando el giro de esta, es por ello
que deben de tener los conocimientos necesarios para poder utilizar las bases de
datos.
Las bases de datos distribuidas se conectan por medio de redes de
computadoras,
estas
pueden
tener
cientos
de
usuarios
conectados
concurrentemente, por lo cual es un problema en muchas empresas que compiten
en los mercados mundiales. Debido al alto grado de conectividad que provee
Internet a las empresas, se debe tener un buen diseño de replicación y
fragmentación.
Este problema consiste en tratar de determinar la mejor forma de dividir
relaciones de la base de datos en fragmentos.
las
La fragmentación mejora la
disponibilidad de la información notablemente por que el sistema puede seguir
operando mientras, por lo menos, uno de los sitios esta activo, con la replicación
también se mejora el rendimiento de la recuperación en consultas globales, por
67
que el resultado de semejante consulta se puede obtener localmente en cualquier
sitio, esto ayuda a contar con la información necesaria de una forma más fácil y
rápida y hoy en día para las empresas contra con la información en un corto
tiempo es un factor clave para la toma de decisiones oportunas.
Para contar con una buena dase de datos distribuida esta debe de ser replicada y
fragmentada. La replicación y fragmentación permite tener disponible la
información, reduce costos, mejora el rendimiento de las operación leer, aumenta
la flexibilidad, se obtiene la información de una manera más fácil y rápida teniendo
un mejor procesamiento de las consultas.
Mediante la replicación de información, las bases de datos distribuidas pueden
presentar cierto grado de tolerancia a fallos haciendo que el funcionamiento del
sistema no dependa de un solo lugar como en el caso de las bases de datos
centralizadas.
68
FUENTES DE INFORMACION
C, Date. (2010). Sistemas de Bases de Datos. Séptima edición. México: Pearson
educación.
Castaño, Miguel.(2001). Diseño de Bases de datos. Primera edición .México:
Alfaomega.
Coronel, Carlos. (2004). Sistemas de bases de datos. Quinta edición. México:
Thompson Editores
Coronel, Carlos. (2004). Sistemas de bases de datos. Quinta edición. México:
Thompson Editores
Gómez, Miguel. (2004). Bases de datos. Segunda edición. México: Alfaomega
Joyanes, Luis. (1992).Diseño conceptual de bases de datos. Primera edición.
E.U.A: Addison- Wesley / Diaz de Santos
Korth, Henry.(2002). Fundamentos de Bases de Datos. Cuarta edición. Madrid: Mc
Graw-Hill
Navathe, Elmasri. Sistemas de bases de datos. Segunda Edicion. Estados Unidos
:Addison- Wesley Iberoamericana
RAMEZ, Elmasri. (2006). Fundamentos de sistemas de Bases de Datos. Tercera
edición. Madrid: Pearson educación
Silberschatz, Abraham. (2006). Fundamentos de Bases de Datos. Quinta edición.
España: Mc Graw-Hill
69
Silberschatz, Abraham. (1998). Fundamentos de Bases de Datos. Tercera edición.
España: Mc Graw-Hill
Valduriez, Patrick. (1999). Distributed Database Systems. Segunda edición. E.U.A:
Prentice Hall
Wildom, Jennifer. (1999). Introducción a los sistemas de Bases de Datos. Primera
edición. México: Prentice Hall Hispanoamericana
70
INDICE DE TABLAS
Número de Página
Tabla 3.1. Comparación de las estrategias de replicación de fragmentos….…51
Tabla 3.2 Fragmentación Vertical de la Tabla Clientes……………………………55
Tabla 3.3 Fragmentación de la tabla en tres lugares………………………………56
Tabla 3.4 Fragmentación Vertical de la tabla Clientes……………………………..57
Tabla 3.5 Fragmentación Mixta de la tabla clientes………………………………..59
71
INDICE DE FIGURAS
Número de Página
Figura 1.1 Comparación de una base de datos y un sistema archivos………….….7
Figura 1.2 Muestra un entorno de sistema de base de datos simplificado, que
ilustra los conceptos y terminología de un Sistema de Base de datos…………..….9
Figura 2.1 Replicación y distribución de datos en bases de datos distribuidas…..30
Figura 2.2 Ejemplo de una Base de datos Distribuida…………………………….…33
Figura 3.1 Replicación de Datos…………………………………………………….…49
Figura 3.2 ventajas y desventajas de las formas de replicación……………...........53
Figura 3.3 Fragmentación Vertical del contenido de la tabla………………………57
Figura 3.4 Contenido de una tabla después del proceso de fragmentación
mezclada……..…………………………………………………………………………...60
72
73