MATERIAL DE APOYO [BASE DE DATOS DISTRIBUIDAS]

SESIÓN N°08: DISEÑO DE BASE DE DATOS RELACIONALES DISTRIBUIDAS

Es importante considerar los siguientes conceptos, que se profundizarán más adelante y con la práctica.
• Fragmentación. Una relación puede dividirse en una serie de subrelaciones, denominadas
fragmentos, que a continuación se distribuyen. Hay dos tipos principales de fragmentación:
horizontal y vertical.
Los fragmentos horizontales son subconjuntos de tuplas, mientras que los fragmentos verticales
son subconjuntos de atributos.
• Asignación. Cada fragmento se almacena en el nodo 'óptimo' desde el punto de vista de la
distribución.
• Replicación. El SGBDD puede mantener una copia de un fragmento en varios nodos diferentes.
La definición y asignación de fragmentos debe estar basada en el modo en que se va a utilizar la base de
datos. Esto implica analizar las transacciones. Generalmente, no es posible analizar todas las
transacciones, por lo que habremos de concentramos en las más importantes. Algunos autores sugieren
que el 20% de consultas de usuario más utilizadas representan el 80% de los accesos totales a los datos,
y esta regla 80/20 puede utilizarse como guía a la hora de llevar a cabo el análisis (Wiederhold, 1983).
El diseño debe estar basado en información tanto cuantitativa como cualitativa. La información
cuantitativa se usa para la asignación; la información cualitativa se usa durante la fragmentación. La
información cuantitativa puede incluir:
 La frecuencia con la que se ejecuta cada transacción;
 El nodo desde el que se ejecuta una transacción;
 Los criterios de rendimiento para las transacciones.
La información cualitativa puede incluir información acerca de las transacciones que se ejecutan, como
por ejemplo:
 Las relaciones, atributos y tuplas a las que se accede;
 El tiempo de acceso (lectura o escritura);
 Los predicados de las operaciones de lectura.
La definición y asignación de fragmentos se lleva a cabo de manera estratégica para conseguir los
siguientes objetivos:
• Localidad de referencia. Siempre que sea posible los datos deben almacenarse en un punto
próximo al de su utilización. Si un fragmento se utiliza en varios nodos, puede ser conveniente
almacenar copias del fragmento en todos esos nodos.
• Mayor fiabilidad y disponibilidad. La fiabilidad y la disponibilidad se mejoran gracias a la
replicación: hay otra copia del fragmento disponible en otro nodo, en caso de que uno de los
nodos falle.
• Rendimiento aceptable. Una mala asignación puede dar como resultado la aparición de cuellos
de botella, es decir, que un nodo se vea inundado de solicitudes procedentes de otros nodos, lo
que quizá traiga consigo una degradación significativa en el rendimiento. Alternativamente, una
mala asignación puede provocar una infrautilización de los recursos.
• Equilibrio entre la capacidad de almacenamiento y el coste. Debe prestarse atención a la
disponibilidad y coste del almacenamiento en cada nodo, para que puedan utilizarse soportes de
almacenamiento masivo de bajo coste, siempre que sea posible. Este criterio debe equilibrarse
con el de localidad de referencia.
• Costes de comunicaciones mínimos. También hay que prestar atención al coste de las
solicitudes remotas.

DJCV | UPAGU 27
 MATERIAL DE APOYO [BASE DE DATOS DISTRIBUIDAS]

Los costes de extracción de datos se minimizan cuando se optimiza la localidad de referencia o cuando
cada nodo dispone de su propia copia de los datos. Sin embargo, cuando se actualizan los datos
replicados, la actualización debe llevarse a cabo en todos los nodos que mantengan una copia duplicada,
incrementándose así los costes de comunicaciones.
¿POR QUÉ FRAGMENTAR?
Antes de hablar en detalle de la fragmentación, indiquemos cuatro razones para fragmentar una
relación:
• Utilización. En general, las aplicaciones funcionan con vistas, en lugar de con relaciones
completas. Por tanto, para la distribución de datos, parece apropiado trabajar con subconjuntos
de las relaciones como unidad de distribución.
• Eficiencia. Los datos se almacenan cerca del lugar donde se los utiliza más frecuentemente.
Además, los datos que las aplicaciones locales no necesitan no se almacenan en ese nodo.
• Paralelismo. Utilizando el fragmento como unidad de distribución, una transacción puede
dividirse en varias sub consultas que operan sobre distintos fragmentos. Esto debería permitir
incrementar el grado de concurrencia o paralelismo en el sistema, permitiendo así que se
ejecuten en paralelo aquellas transacciones que puedan paralelizarse con seguridad.
• Seguridad. Los datos no requeridos por las aplicaciones locales no se almacenan en ese nodo y,
consecuentemente, no están disponibles para los usuarios no autorizados.
La fragmentación tiene dos desventajas principales, que ya hemos mencionado antes:
• Rendimiento. El rendimiento de las aplicaciones globales que requieren datos de diversos
fragmentos ubicados en diferentes nodos puede ser menor.
• Integridad. El control de integridad puede ser más difícil si los datos y las dependencias
funcionales están fragmentados y ubicados en nadas distintos.

CORRECCIÓN DE LA FRAGMENTACIÓN
La fragmentación no puede llevarse a cabo descuidadamente. Hay tres reglas que es preciso respetar
durante la fragmentación:
(1) Completud. Si una instancia R de una relación se descompone en fragmentos R¡, Rz, ... ,
Rm cada elemento de datos que aparezca en R debe aparecer al menos en un fragmento.
Esta regla es necesaria para garantizar que no haya pérdida de datos durante la
fragmentación.
(2) Reconstrucción. Debe ser posible definir una operación relacional que permita
reconstruir la relación R a partir de los fragmentos. Esta regla garantiza que se
preserven las dependencias funcionales.

DJCV | UPAGU 28
 MATERIAL DE APOYO [BASE DE DATOS DISTRIBUIDAS]

(3) Disyunción. Si un elemento de datos d¡ aparece en el fragmento R¡, no debe aparecer en

ningún otro fragmento. La fragmentación vertical es la excepción a esta regla, ya que los
atributos de clave principal deberán estar repetidos para permitir la reconstrucción de
la relación. Esta regla garantiza una redundancia mínima de los datos.
En el caso de la fragmentación horizontal, el elemento de datos es la tupla; para la fragmentación
vertical, el elemento de datos es un atributo.
TIPOS DE FRAGMENTACI ÓN
Hay dos tipos principales de fragmentación: horizontal y vertical. Los fragmentos horizontales son
subconjuntos de tuplas y los fragmentos verticales son subconjuntos de atributos.
Hay también otros dos tipos de fragmentación: mixta y derivada, un tipo de fragmentación horizontal.
Vamos a proporcionar a continuación ejemplos de los diferentes tipos de fragmentación, utilizando la
instancia de la base de datos de DreamHome mostrada en la Figura 3.3. (ANEXO)

1. FRAGMENT ACIÓN HORIZO NTAL

La fragmentación horizontal agrupa las tuplas de una relación que son utilizadas de manera
colectiva por las transacciones de mayor importancia. Los fragmentos horizontales se generan
especificando un predicado que imponga una restricción a las tuplas de la relación. Dicho
predicado se define utilizando la operación de selección del álgebra relacional. La operación de
selección agrupa tuplas que tengan alguna propiedad común; por ejemplo, las tuplas que sean
utilizadas por una misma aplicación o que sean utilizadas en un mismo nodo. Dada una relación
R, un fragmento horizontal se define como:
 P (R)
Donde: p es un predicado basado en uno o más atributos de la relación.

Ejemplo: Fragmentación horizontal

Suponiendo que sólo haya dos tipos de inmuebles, Flat (apartamento) y House (casa), la
fragmentación horizontal de PropertyForRent de acuerdo con el tipo de inmueble puede
obtenerse de la forma siguiente:
P1:  t y p e ='House·(PropertyForRent)
P2:  t y p e ='Flat·(PropertyForRent)

DJCV | UPAGU 29
MATERIAL DE APOYO [BASE DE DATOS DISTRIBUIDAS]

Esto genera dos fragmentos (P1 y P2), uno compuesto por aquellas tuplas para las que el valor
del atributo type es 'House' y el otro compuesto por aquellas tuplas para las que el valor del
atributo type es 'Flat'. Esta estrategia de fragmentación concreta puede ser ventajosa si se
utilizan aplicaciones distintas para gestionar las casas y los apartamentos. El esquema de
fragmentación satisface las reglas de corrección:

 Completud. Cada tupla de la relación aparece en el fragmento P1 o en el

fragmento P2.
 Reconstrucción. La relación PropertyForRentpuede reconstruirse a partir de los
fragmentos utilizando el operador de unión: P1 U P2 = PropertyForRent
 Disyunción. Los fragmentos son disjuntos; no puede haber ningún inmueble que
sea a la vez de tipo 'House'y 'Flat'.
En ocasiones, la elección de la estrategia de fragmentación horizontal resulta obvia. Sin
embargo, en otros casos, es necesario analizar la aplicación en detalle. El análisis implica un
examen de los predicados (o condiciones de búsqueda) usados por las transacciones o consultas
en las aplicaciones. Los predicados pueden ser simples, implicando un solo atributo, o
complejos, implicando múltiples atributos. Los predicados para cada atributo pueden ser
univaluados o multivaluados. En este último caso, los valores pueden ser discretos o implicar
rangos de valores.
La estrategia de fragmentación requiere encontrar un conjunto de predicados mínimo (es decir,
completo y relevante) que pueda usarse como base para el esquema de fragmentación (Ceri et
al., 1982). Un conjunto de predicados es completo si y sólo si cualquiera de las dos tuplas del
mismo fragmento se referencian con la misma probabilidad por cualquier transacción. Un
predicado es relevante si existe al menos una transacción que acceda de manera distinta a los
fragmentos resultantes. Por ejemplo, si el único requisito es seleccionar tuplas de
PropertyForRentbasándose en el tipo de inmueble, el conjunto {type = 'House', type = 'Flat'} es
completo, mientras que el conjunto {type = 'House'} no es completo. Por otro lado, con este
requisito, el predicado (city = 'Aberdeen') no sería relevante.
EJERCICIOS: Fragmentación Horizontal
A. Utilizando la BD Northwind, acceda a las tablas PROVEEDOR. Identificar los
atributos que podrían ser utilizados para la fragmentación. Muestre los
fragmentos, resultado de su análisis.
B. CONFIGUR AR UN A BASE DE DATOS DISTRIBUIDA – UTILIZ ANDO
FRAGMENT ACIÓN HORIZONTAL.
1) DESACTIVAR EL FIREW ALL DE W INDOW S.
• Sólo máquina virtual. De ser el caso en el que se trabaja en dos
equipos, se debe desactivar el firewall para ambos equipos.
2) CONFIGURAR LA RED:
• Para ambos equipos asignar su ip y máscara.
• Se puede probar la conexión a través de una consulta ping.

DJCV | UPAGU 30
MATERIAL DE APOYO [BASE DE DATOS DISTRIBUIDAS]

3) CREAR LAS BD EN AMBOS SERVIDORES.

• Crear la base de datos PROVEEDOR que tendrá como referencia la
base de datos SUPPLIERS.
• Crear las tablas para su base de datos, utilizar sólo algunos
campos considerando el PREDICADO DE FRAGMENTACIÓN
HORIZONTAL.
• En el NODO 1, INSERTAR los registros correspon dientes al
fragmento.
4) CREAR USUARIO EN EL NODO 2.
• Acceder a la carpeta seguridad (Raíz principal). Y luego a la
carpeta Inicio de Sesión. Allí creará un nuevo usuario.
• Acceder a la carpeta de Base de datos creada. Ir a la carpeta
Seguridad. Luego Usuarios y crear un NUEVO USUARIO. (No olvide
asignarle propiedades de OW NER).
5) CREAR SERVIDOR VINCULADO
• En el NODO 1. Acceder a la opción: Objetos de servidor, para
crear un nuevo servidor vinculado. En este caso se le asignará la
dirección IP del NODO 2.
6) INSERTAR VALORES EN EL NODO 2:
• Desde una nueva consulta en el NODO 1, seleccionando la BD
Northwind, insertar los datos en el NODO 2. Puede utilizar la
siguiente referencia de consulta.
INSERT INTO [10.0.2.2].[PRUEBA].dbo.CLIENTE(id_cliente,
nom_cliente, contacto_cli, country)
SELECT customerid,companyname, contactname, country FROM
Northwind.dbo.Customers
WHERE Country='Mexico'

7) UNIR LOS FRAGMENTOS IDENTIFICADOS:

• Puede utilizar como referencia:
select * from CLIENTE
UNION
SELECT * FROM [10.0.2.2].[PRUEBA].[dbo].[CLIENTE]

DJCV | UPAGU 31
 MATERIAL DE APOYO [BASE DE DATOS DISTRIBUIDAS]

2. FRAGMENT ACIÓN VERTIC AL

El mecanismo de fragmentación vertical agrupa los atributos de una relación que son utilizados
de manera conjunta por las transacciones de mayor importancia. Un fragmento vertical se
define utilizando la operación de proyección del álgebra relacional. Dada una relación R, un
fragmento vertical se define como:
a1, ….aN( R )
Donde al, ... , an son atributos de la relación R

Ejemplo: Fragmentación vertical

La aplicación de nóminas de DreamHome requiere el número de empleado staffNo y los
atributos position, sex, DOB y salary de cada empleado; el departamento de personal
requiere los atributos staffNo, fName, IName y branchNo. La fragmentación vertical de
Staff para este ejemplo puede obtenerse de la forma siguiente:
= , , , , ( )
= , , , ( )
Esto produce dos fragmentos (SI y S2), como se muestra en la siguiente Figura.

Observe que ambos fragmentos contienen la clave principal, staffNo, para permitir
reconstruir la relación original. La ventaja de la fragmentación vertical es que los
fragmentos pueden almacenarse en los nodos que los necesitan. Además, las
prestaciones se mejoran, ya que el fragmento es más pequeño que la relación base
original. Este esquema de fragmentación satisface las reglas de corrección:
• Completud. Cada atributo de la relación Staff aparece en el fragmento S 1 o S2·
• Reconstrucción. La relación Staff puede reconstruirse a partir de dos
fragmentos utilizando la operación de combinación natural:
=

DJCV | UPAGU 32
MATERIAL DE APOYO [BASE DE DATOS DISTRIBUIDAS]

• Disyunción. Los fragmentos son disjuntos, salvo por la clave principal, que es
necesaria para la reconstrucción.
Los fragmentos verticales se determinan estableciendo la afinidad de un atributo con otro. Una
forma de hacer esto es crear una matriz que muestre el número de acceso que se refiere a cada
pareja de atributos. Por ejemplo, una transacción que acceda a los atributos a1, a2 y a4 de la
relación R con atributos (al, a2, a3, a4) puede representarse mediante la siguiente matriz:

1 2 3 4
1 1 0 1
2 0 1
3 0
4
La matriz es triangular; no es necesario rellenar la diagonal, ya que la mitad inferior es una
imagen especular de la superior. Los unos representan un acceso que implica la correspondiente
pareja de atributos, y se los puede reemplazar por números que representen la frecuencia de la
transacción. Hay que crear una matriz para cada transacción y luego generar una matriz global
que muestre la suma de todos los accesos para cada pareja de atributos. Las parejas con una alta
afinidad deben aparecer en el mismo fragmento vertical; las parejas con baja afinidad pueden
separarse. Claramente, si trabajamos con atributos individuales y con todas las transacciones
principales, los cálculos pueden ser muy engorrosos. Por tanto, si se conoce que algunos
atributos están relacionados, puede que sea mejor trabajar con grupos de atributos.
Esta técnica se conoce con el nombre de división y fue propuesta por primera vez por Navathe
et al. (1984). Genera un conjunto de fragmentos no solapados, lo que garantiza el cumplimiento
de la regla de disfunción anteriormente definida. De hecho, la característica de no solapamiento
se aplica únicamente a los atributos que no forman parte de la clave principal. Los campos de la
clave principal aparecen en todos los fragmentos, por lo que pueden omitirse del análisis. Para
obtener información adicional sobre esta técnica, el lector puede consultar Ozsu y Valduriez
(1999).

EJERCICIOS: Fragmentación Vertical

A. Utilizando la BD Northwind. Realice la fragmentación vertical de la tabla
SUPPLIERS. Identificar las tablas con sus respectivos atributos. Mostrar los
fragmentos resultado de su análisis.
B. CONFIGUR AR UN A BASE DE D ATOS DISTRIBUID A – APLIC AR
FRAGMENT ACIÓN VERTIC AL
1) DESACTIVAR EL FIREW ALL DE W INDOW S.
• Sólo máquina virtual. De ser el caso en el que se trabaja en dos
equipos, se debe desactivar el firewall para ambos equipos.
2) CONFIGURAR LA RED:
• Para ambos equipos asignar su ip y máscara.
• Se puede probar la conexión a través de una consulta ping.
3) CREAR LAS BD EN AMBOS SERVIDORES.
• Crear la base de datos PROVEEDOR V que tendrá como referencia
la base de datos SUPPLIERS.
• Crear las tablas para su base de datos, utilizar sólo algunos
campos considerando el PREDICADO DE FRAGMENTACIÓN
VERTICAL.
4) CREAR USUARIO EN EL NODO 2.

DJCV | UPAGU 33
MATERIAL DE APOYO [BASE DE DATOS DISTRIBUIDAS]

• Acceder a la carpeta de Base de datos creada. Ir a la carpeta

Seguridad. Luego Usuarios y crear un NUEVO USUARIO. (No olvide
asignarle propiedades de OW NER).
5) CREAR SERVIDOR VINCULADO
• En el NODO 1. Acceder a la opción: Objetos de servidor, para
crear un nuevo servidor vinculado. En este caso se le asignará la
dirección IP del NODO 2.
6) INSERTAR VALORES EN LOS NODOS:
• NODO 1: Habilite una nueva consulta utilizando la bd
PROVEEDORV.
INSERT INTO PROVEEDOR (proveedorid,nombreprov, pais, direccion,
ciudad)
SELECT SupplierID, CompanyName, Country, Address, City FROM
Northwind.DBO.Suppliers
• NODO 2:
INSERT INTO
[10.0.2.2].PRUEBAV.DBO.CONTACTO(proveedorid,nombrecontacto,
cargocontacto)
SELECT SupplierID, ContactName, ContactTitle FROM
Northwind.DBO.Suppliers

7) UNIR LOS FRAGMENTOS IDENTIFICADOS:

• Puede utilizar como referencia:
select * from [10.0.2.2].PRUEBAV.DBO.CONTACTO CP
INNER JOIN PROVEEDOR p
ON CP.proveedorid=p.proveedorid

DJCV | UPAGU 34
 MATERIAL DE APOYO [BASE DE DATOS DISTRIBUIDAS]

3. FRAGMENT ACIÓN MIXT A

Para algunas aplicaciones, la fragmentación horizontal o vertical de un esquema de base de
datos puede ser insuficiente por sí misma para distribuir los datos adecuadamente. En su lugar,
puede que se requiera una fragmentación mixta o híbrida.
Está compuesto por un fragmento horizontal que se fragmenta a continuación verticalmente, o
por un fragmento vertical que se fragmenta a continuación horizontalmente. Un fragmento
mixto se define utilizando las operaciones de selección y proyección del álgebra relacional.
Dada una relación R, un fragmento mixto se define como:
 (∏ … ( )) O (∏ …  ( ))
Donde P es un predicado basado en uno o más atributos de R y a1 ... an son atributos de R.
EJEMPLO: FRAGMENTACIÓN MIXTA
En el Ejemplo 22.3, hemos fragmentado verticalmente Staff para los departamentos de
nóminas y de personal, obteniendo:
S1: Π staffNo, position, sex, DOB, salary (Staff)
S2: Π staffNo, fName, lName, branchNo (Staff)
Podríamos ahora fragmentar horizontalmente S 2 de acuerdo con el número de sucursal
(por simplicidad, vamos a suponer que sólo hay tres sucursales):
S21: σbranchNo = ‘B003’(S2)
S22: σbranchNo = ‘B005’(S2)
S23: σbranchNo = ‘B007’(S2)

Esto produce tres fragmentos (S21, S22 y S23), uno de ellos compuesto por tuplas para las
que el número de sucursal es B003 (S21), otro compuesto de aquellas tuplas en las que el
número de sucursal es B005 (S22) Y el otro compuesto de aquellas tuplas en las que el
número de sucursal es B007 (S23)' como muestra la Figura anterior. El esquema de
fragmentación satisface las reglas de corrección:
• Completud. Cada atributo de la relación Staff aparece en los fragmentos S 1 o en
los fragmentos S2; cada tupla aparece (parcialmente) en el fragmento S 1 y en uno
de los fragmentos S21, S22 o S23'

DJCV | UPAGU 35
MATERIAL DE APOYO [BASE DE DATOS DISTRIBUIDAS]

• Reconstrucción. La relación Staff puede reconstruirse a partir de los fragmentos

utilizando las' operaciones de unión y de combinación natural:
(
• Disyunción. Los fragmentos son disjuntos; no puede haber ningún empleado
que trabaje en más de una sucursal y S1 Y S2 son disjuntos, salvo por la necesaria
duplicación de la clave principal.
EJERCICIOS: Fragmentación Mixta
A. Utilizando la BD Northwind. Realice la fragmentación mixta de la tabla
SUPPLIERS. Identifique los fragmentos, resultado de su análisis.
B. CONFIGUR AR UN A BASE DE D ATOS DISTRIBUID A – APLIC AR
FRAGMENT ACIÓN MIXT A
1) CREAR LAS BD EN AMBOS SERVIDORES.
• Crear la base de datos FMIXTA que tendrá como referencia la base
de datos SUPPLIERS.
• Crear las tablas para su base de datos, utilizar sólo algunos
campos considerando el PREDICADO DE FRAGMENTACIÓN
MIXTA.
2) CREAR USUARIO PARA LA BD FMIXTA.
• Acceder a la carpeta de Base de datos creada. Ir a la carpeta
Seguridad. Luego Usuarios y crear un NUEVO USUARIO. (No olvide
asignarle propiedades de OW NER) y configurar con el inicio de
sesión creado anteriormente.
3) INSERTAR VALORES EN LOS NODOS:
--- INSERTANDO VALORES EN EL SITIO 1 - DESDE EL SITIO 1: BD NORTHWIND
INSERT INTO CONTACTO(idproveedor,nomcontacto,cargocontacto)
SELECT SupplierID,ContactName, ContactTitle
FROM Northwind.DBO.Suppliers
WHERE Country='USA'

INSERT INTO PROVEEDOR(idproveedor,nombreprov,country)

SELECT SupplierID,CompanyName,Country
FROM Northwind.DBO.Suppliers
WHERE Country='USA'

--- INSERTANDO VALORES EN EL SITIO 2 - DESDE EL SITIO 1: BD NORTHWIND

INSERT INTO
[10.0.2.2].[EJEMPLOM].DBO.PRODUCTO(productoid,nomprod,proveedorid,preci
ounit)
SELECT ProductID,ProductName,S.SupplierID,UnitPrice
FROM Northwind.DBO.Products P INNER JOIN Northwind.DBO.Suppliers S
ON P.SupplierID=S.SupplierID
WHERE Country='USA'

INSERT INTO
[10.0.2.2].[EJEMPLOM].DBO.PROVEEDOR(proveedorid,nomprov,country)
SELECT SupplierID, CompanyName, Country
FROM Northwind.DBO.Suppliers
WHERE Country='USA'

4) UNIENDO DOS FRAGMENTOS: Para unir los fragmentos se deben

utilizar los operadores INNER JOIN y UNION, a fin de integrar los
registros, tal cual se indica:

DJCV | UPAGU 36
MATERIAL DE APOYO [BASE DE DATOS DISTRIBUIDAS]

--- UNIENDO LAS DIFERENTES FRAGMENTOS VERTICALES

SELECT * FROM [10.0.2.2].[EJEMPLOM].[dbo].[PRODUCTO] P
INNER JOIN [10.0.2.2].[EJEMPLOM].[dbo].[PROVEEDOR] PROV
ON P.proveedorid=PROV.proveedorid INNER JOIN
EJEMPLOMIXTA.DBO.PROVEEDOR PROVE
ON PROVE.idproveedor=PROV.proveedorid INNER JOIN
EJEMPLOMIXTA.DBO.CONTACTO C
ON C.idproveedor=PROVE.idproveedor

DJCV | UPAGU 37
 MATERIAL DE APOYO [BASE DE DATOS DISTRIBUIDAS]

L ABORATORIO DIRIGIDO

1. Aplicar los fundamentos teóricos de fragmentación horizontal, vertical y mixta. Utilizando las tablas
PRODUCTO y PROVEEDOR de la base de datos NORTHWIND.

DJCV | UPAGU 38