Apuntes bdd2

Instituto Tecnológico de Torreón
Apuntes de la Materia de Bases de Datos Distribuidas

Ing. José Luis Ibarra Casiano
Unidad 1 Fundamentos Bases de Datos Distribuidas Conceptos Básicos
1.2 Objetivos Bases de Datos Distribuidas
1.3 Disciplinas Estudio Bases de Datos Distribuidas
1.4 Arquitectura Bases de Datos Distribuidas
Unidad 2 Diseño de bases de datos distribuidas
2.1 Consideraciones Diseño Bases de Datos Distribuidas
2.2 Diccionario de Datos
2.3 Niveles de Transparencia
2.3.1 Transparencia de Localización
2.3.2 Transparencia de Fragmentación
2.3.3 Transparencia de Replica
2.4 Fragmentación de Datos
2.4.1 Fragmentación Horizontal
2.4.2 Fragmentación Vertical
2.4.3 Fragmentación Hibrida
2.5 Distribución de Datos
2.5.1 Algoritmos Distribución Datos No Replicados
2.5.2 Algoritmos Distribución Datos Replicados
1
Unidad 3 Procesamiento de consultas distribuidas
3.1 Metodología Procesamiento Consultas Distribuidas
3.2 Estrategias Procesamiento Consultas Distribuidas
3.2.1 Arboles de Consultas
3.2.2 Transformaciones Equivalentes Consultas Distribuidas
3.2.3 Métodos Ejecución del Join
3.3 Optimización de Consultas Distribuidas
3.3.1 Optimización Global Consultas Distribuidas
3.3.2 Optimización Local Consultas Distribuidas
Unidad 4 Manejo de transacciones
4.1 Transacciones Conceptos
4.1.1 Estructura de Transacciones
4.1.2 Ejecución Transacciones Centralizada Distribuida
4.1.3 Estructura de transacciones
4.2 Control de Concurrencia
4.2.1 Serializacion de Transacciones
4.2.2 Algoritmos de Control de Concurrencia
4.2.2.1 Basados en Bloqueo
4.2.2.2 Basados en Estampas de Tiempo
2
4.2.2.3 Pruebas Validación Optimistas
4.2.3 Disciplinas del Interbloqueo prevención detección eliminación y recuperación
4.3 Confiabilidad
4.3.1 Conceptos Básicos de Confiabilidad
4.3.2 Protocolos Redo Undo
4.3.3 Puntos de Verificación checkpoints
4.3.4 Protocolo 2PC de Confiabilidad Distribuida
3
Unidad 1
Fundamentos Bases de Datos Distribuidas Conceptos Básicos
El procesamiento de bases de datos distribuidas es el procesamiento de bases de datos

en el cual la ejecución de transacciones y la recuperación y actualización de los datos
acontece a través de dos o más computadoras independientes, por lo general separadas
geográficamente.
Las Bases de Datos Distribuidas ( BDD ), no son simplemente implementaciones

distribuidas de bases de datos centralizadas, por que ellas permiten el diseño de sistemas
que representan diferentes características de las tradicionales, de sistemas centralizados.
Esto es por lo tanto útil para ver las características típicas de BDD. Los rasgos que
caracterizan las BD tradicionales se aproximan al control centralizado, independencia
de datos, reducción de redundancia, estructuras físicas complejas para acceso eficiente,
integridad, recuperación control de concurrencia, privacidad y seguridad.
Control Centralizado: La posibilidad de proporcionar control centralizado sobre los

recursos de información de una empresa entera u organización, fue considerada como
una de las motivaciones más fuerte para introducir BD; ellas fueron desarrolladas como
la evolución de sistemas de información en las cuales cada aplicación tiene sus propios
archivos privados. La función fundamental del Administrador de Bases de Datos ( DBA
) fue garantizar la seguridad de los datos; los mismos datos fueron reconocidos como
una inversión importante de las empresas las cuales requieren una responsabilidad
centralizada.
En una BDD la idea del control centralizado está mucho menos enfatizado. Esto
depende además de la arquitectura.
**********************************************************************
La cantidad de innovaciones tecnológicas que ha habido en los últimos años ha

promovido un cambio en la forma de observar a los sistemas de información y, en
general, a las aplicaciones computacionales. Existen avances tecnológicos que se
realizan continuamente en circuitos, dispositivos de almacenamiento, programas y
metodologías. Sin embargo, los cambios tecnológicos van de la mano con la demanda
de los usuarios y programas para la explotación exhaustiva de tales dispositivos
mejorados. Por tanto, existe un continuo desarrollo de nuevos productos los cuales
incorporan ideas nuevas desarrolladas por compañías e instituciones académicas.
4
Aún cuando es posible que un usuario común no perciba los desarrollos relevantes de
nuevos productos, para las aplicaciones existe una demanda permanente por mayor
funcionalidad, mayor número de servicios, más flexibilidad y mejor rendimiento. Así, al
diseñar un nuevo sistema de información o al prolongar la vida de uno ya existente, se
debe buscar siempre formas para enlazar las soluciones ofrecidas por la tecnología
disponible a las necesidades de las aplicaciones de los usuarios.
Una área en la cual las soluciones están integrando tecnología con nuevas arquitecturas
o formas de hacer las cosas es, sin lugar a dudas, el área de los sistemas distribuidos de
información. Ellos se refieren al manejo de datos almacenados en facilidades de
cómputo localizadas en muchos sitios ligados a través de una red de comunicaciones.
Un caso específico de estos sistemas distribuidos es lo que se conoce como bases de
datos distribuidas, tópico a estudiar en estas notas.
MOTIVACION
Existen dos fuerzas que han impulsado la evolución de los sistemas de bases de datos.
Por un lado los usuarios como parte de organizaciones más complejas han demandado
una serie de capacidades que se han ido incorporando en los sistemas de bases de datos
(Figura 1.1). Un ejemplo de esto es la necesidad de integrar información proveniente de
fuentes diversas. Por otro lado, la tecnología ha hecho posible que algunas facilidades
inicialmente imaginadas solo en sueños se conviertan en realidad. Por ejemplo, las
transacciones en línea que permite el sistema bancario actual no hubiera sido posible sin
el desarrollo de los equipos de comunicación. Los sistemas de cómputo distribuido son
ejemplos claros en donde presiones organizacionales se combinan con la disponibilidad
de nuevas tecnologías para hacer realidad tales aplicaciones.
La presión por datos distribuidos
La presión de los usuarios
Las bases de datos grandes permiten organizar la información relevantes a alguna parte
de la operación de una organización como por ejemplo servicios de salud, corporaciones
industriales o bancos. Casi cualquier organización que ha incorporado sistemas de
información para su funcionamiento ha experimentado dos fases.
Figura 1.1. Fuerzas evolucionarias en los sistemas de bases de datos.
5
En la primera fase, se ha agrupando toda la información en un solo lugar. La idea

original era que todos los accesos a datos podrían ser integrados en un solo lugar usando
herramientas de bases de datos tales como lenguajes de descripción de datos, lenguajes
de manipulación de datos, mecanismos de acceso, verificadores de restricciones y
lenguajes de alto nivel. Para poder tener estos mecanismos de almacenamiento y
recuperación de información, las organizaciones hicieron fuertes inversiones en equipos
computacionales sofisticas y con grandes capacidades. Sin embargo, después de
experimentar por un tiempo con este enfoque, muchas organizaciones encontraron que
el sistema completo era satisfactorio, en algún grado, para un buen número de usuarios
pero muy pocos obtenían un servicio óptimo. Más aún, bajo este esquema centralizado
los "propietarios" u originadores de la información específica perdieron el control sobre
el manejo de su información ya que ésta no se almacenaba en sus lugares de trabajo.
Algunos experimentos mostraron que el 90% de las operaciones de entrada y salida de

información eran "locales" (correspondientes al departamento que las generaba) y solo
el 10% de tales operaciones involucraba información cruzada (información proveniente
de más de un departamento). Así, en la segunda fase se promovió la descentralización
de los sistemas de bases de datos corporativos. Entonces, se empezaron a adquirir
sistemas de software y hardware departamentales. Este enfoque presentó grandes
beneficios para el control de la seguridad de la información y la disponibilidad de la
misma. Permitió que los esquemas de mantenimiento y planeación de los sistemas de
información afectara en menor medida al funcionamiento general de la organización.
Sin embargo, muy pronto empezaron a aparecer inconvenientes con este enfoque. Se
presentaron problemas de consistencia de la información entre los sistemas locales y
central y se hallaron dificultados al transferir información de entre departamentos
diferentes de una corporación.
De esta manera, en una tercera fase (la cual aún no ha concluido) se ha tratado de
formalizar la descentralización de las bases de datos y de sus funciones manteniendo la
integridad de la información y quizá algún tipo de control centralizado o distribuido.
La presión de la tecnología
Existen buenas razones técnicas para distribuir datos. La más obvia es la referente a la
sobrecarga de los canales de entrada y salida a los discos en donde se almacena
finalmente la información. Es mucho mejor distribuir los accesos a la información sobre
diferentes canales que concentrarlos en uno solo. Otra razón de peso es que las redes de
computadoras empezaron a trabajar a velocidades razonables abriendo la puerta a la
distribución del trabajo y la información.
El hacer una descentralización de la información se justifica desde el punto de vista

tecnológico por las siguientes razones:
• Para permitir autonomía local y promover la evolución de los sistemas y los

cambios en los requerimientos de usuario.
• Para proveer una arquitectura de sistemas simple, flexible y tolerante a fallas.
6
• Para ofrecer buenos rendimientos.
Existen aplicaciones que nacieron distribuidas. Para ellas ha sido necesario el uso de
nuevas tecnologías para integrar sistemas de información diferentes, de forma que, no
se afecte de manera sustancial el estilo de trabajo o de hacer las cosas de los usuarios.
Aunque la idea de distribución de datos es bastante atractiva, su realización conlleva la

superación de una serie de dificultades tecnológicas entre las que se pueden mencionar:
• Asegurar que el acceso entre diferentes sitios o nodos y el procesamiento de

datos se realice de manera eficiente, presumiblemente óptima.
• Transformar datos e integrar diferentes tipos de procesamiento entre nodos de un

ambiente distribuido.
• Distribuir datos en los nodos del ambiente distribuido de una manera óptima.
• Controlar el acceso a los datos disponibles en el ambiente distribuido.
• Soportar la recuperación de errores de diferentes módulos del sistema de manera

segura y eficiente.
• Asegurar que los sistemas locales y globales permanezcan como una imagen fiel
del mundo real evitando la interferencia destructiva que pueden ocasionar
diferentes transacciones en el sistema.
Así también, la aplicación de técnicas de distribución de información requiere de

superar algunas dificultades de índole organizacional y algunas otras relacionadas con
los usuarios. Entre ellas se puede mencionar:
• El desarrollo de modelos para estimar la capacidad y el tráfico esperado en el

sistema distribuido.
• Soportar el diseño de sistemas de información distribuidos. Por ejemplo, ayudar

a decidir donde localizar algún dato particular o donde es mejor ejecutar un
programa de aplicación.
• Considerar la competencia que habrá por el uso de los recursos entre nodos
diferentes.
Aun cuando las dificultades mencionadas son importantes, las ventajas de la

distribución de información han promovido su aplicación en ambientes del presente y
del futuro.
7
Heterogeneidad y la presión para integrar datos
La descentralización de los sistemas de información y el advenimiento de los sistemas

distribuidos están bien justificados. Sin embargo, existe todavía un argumento
importante para el desarrollo de sistemas de bases de datos distribuidas; éste se refiere a
la integración de necesidades de procesamiento no locales en donde es necesario
intercambiar información proveniente de otras áreas o departamentos. La
descentralización de la información promueve la heterogeneidad en su manejo. La
heterogeneidad se puede dar a muchos niveles, desde la forma y significado de cada
dato hasta el formato y el medio de almacenamiento que se elige para guardarlo. La
integración de la información es de importancia mayor para el funcionamiento de una
organización.
En resumen, en los sistemas de bases de datos distribuidas se persigue la integración de

sistemas de bases de datos diversos no necesariamente homogéneos para dar a los
usuarios una visión global de la información disponible. Este proceso de integración no
implica la centralización de la información, más bien, con la ayuda de la tecnología de
redes de computadoras disponible, la información se mantiene distribuida (localizada en
diversos lugares) y los sistemas de bases de datos distribuidos permiten el acceso a ella
como si estuviera localizada en un solo lugar. La distribución de la información permite,
entre otras cosas, tener accesos rápidos a la información, tener copias de la información
para accesos más rápidos y para tener respaldo en caso de fallas.
Computación Distribuida
Los sistemas de bases de datos distribuidas son un caso particular de los sistemas de
cómputo distribuido en los cuales un conjunto de elementos de procesamiento
autónomos (no necesariamente homogéneos) se interconectan por una red de
comunicaciones y cooperan entre ellos para realizar sus tareas asignadas.
Históricamente, el cómputo distribuido se ha estudiado desde muchos puntos de vista.
Así, es común encontrar en la literatura un gran número de términos que se han usado
para identificarlo. Entre los términos más comunes que se utilizan para referirse al
cómputo distribuido podemos encontrar: funciones distribuidas, procesamiento
distribuido de datos, multiprocesadores, multicomputadoras, procesamiento satelital,
procesamiento tipo "backend", computadoras dedicadas y de propósito específico,
sistemas de tiempo compartido, sistemas funcionalmente modulares.
Existen muchas componentes a distribuir para realizar una tarea. En computación

distribuida los elementos que se pueden distribuir son:
• Control. Las actividades relacionadas con el manejo o administración del

sistema.
• Datos. La información que maneja el sistema.
8
• Funciones. Las actividades que cada elemento del sistema realiza.
• Procesamiento lógico. Las tareas específicas involucradas en una actividad de

procesamiento de información.
Figura 1.2. Motivación de los sistemas de bases de datos distribuidos.
Sistemas de bases de datos distribuidas
Una base de datos distribuida (BDD) es un conjunto de múltiples bases de datos

lógicamente relacionadas las cuales se encuentran distribuidas entre diferentes sitios
interconectados por una red de comunicaciones (ver Figura 1.2).
Un sistema de bases de datos distribuida (SBDD) es un sistema en el cual múltiples

sitios de bases de datos están ligados por un sistema de comunicaciones, de tal forma
que, un usuario en cualquier sitio puede accesar los datos en cualquier parte de la red
exactamente como si los datos estuvieran almacenados en su sitio propio.
Un sistema de manejo de bases de datos distribuidas (SMBDD) es aquel que se

encarga del manejo de la BDD y proporciona un mecanismo de acceso que hace que la
distribución sea transparente a los usuarios. El término transparente significa que la
aplicación trabajaría, desde un punto de vista lógico, como si un solo SMBD ejecutado
en una sola máquina, administrara esos datos.
Un sistema de base de datos distribuida (SBDD) es entonces el resultado de la

integración de una base de datos distribuida con un sistema para su manejo.
Dada la definición anterior, es claro que algunos sistemas no se pueden considerar como
SBDD. Por ejemplo, un sistema de tiempo compartido no incluye necesariamente un
sistema de manejo de bases de datos y, en caso de que lo haga, éste es controlado y
administrado por una sola computadora.
Un sistema de multiprocesamiento puede administrar una base de datos pero lo hace

usualmente a través de un solo sistema de manejo de base de datos; los procesadores se
9
utilizan para distribuir la carga de trabajo del sistema completo o incluso del propio
SMBD pero actuando sobre una sola base de datos. Finalmente, una base de datos la
cual reside en un solo sitio de una red de computadoras y que es accesada por todos los
nodos de la red no es una base de datos distribuida (Figura 1.3). Este caso se trata de
una base de datos cuyo control y administración esta centralizada en un solo nodo pero
se permite el acceso a ella a través de la red de computadoras.
El medio ambiente típico de un SMBDD consiste de un conjunto de sitios o nodos los

cuales tiene un sistema de procesamiento de datos completo que incluye una base de
datos local, un sistema de manejo de bases de datos y facilidades de comunicaciones. Si
los diferentes sitios pueden estar geográficamente dispersos, entonces, ellos están
interconectados por una red de tipo WAN. Por otro lado, si los sitios están localizados
en diferentes edificios o departamentos de una misma organización pero
geográficamente en la misma ubicación, entonces, están conectados por una red local
(LAN) (Figura 1.4).
Figura 1.3. Un sistema centralizado sobre una red.
10
Figura 1.4. Un medio ambiente distribuido para bases de datos.
Ambientes con múltiples procesadores
Desde el punto de vista de las bases de datos, conceptualmente existen tres tipos de
ambientes que se integran con múltiples procesadores:
1. Arquitecturas de memoria compartida. Consisten de diversos procesadores los

cuales accesan una misma memoria y un misma unidad de almacenamiento (uno
o varios discos). Algunos ejemplos de este tipo son las computadoras Sequent
Encore y los mainframes IBM4090 y Bull DPS8 (Figura 1.5).
Figura 1.5. Arquitectura de memoria compartida.
2. Arquitecturas de disco compartido. Consiste de diversos procesadores cada uno

de ellos con su memoria local pero compartiendo una misma unidad de
almacenamiento (uno o varios discos). Ejemplos de estas arquitecturas son los
cluster de Digital, y los modelos IMS/VS Data Sharing de IBM (Figura 1.6).
11
Figura 1.6. Arquitectura de disco compartido.
3. Arquitecturas nada compartido. Consiste de diversos procesadores cada uno con

su propia memoria y su propia unidad de almacenamiento. Aquí se tienen los
clusters de estaciones de trabajo, la computadoras Intel Paragon, NCR 3600 y
3700 e IBM SP2 (Figura 1.7).
Figura 1.7. Arquitectura nada compartido.
Aplicaciones
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.
12
• Cadenas hoteleras.
• Servicios bancarios y financieros.
Ventajas
Los SMBDD 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.
Las razones por las que compañías y negocios migran hacia bases de datos distribuidas
incluyen razones organizacionales y económicas, para obtener una interconexión
confiable y flexible con las bases de datos existente, y por un crecimiento futuro. El
enfoque distribuido de las bases de datos se adapta más naturalmente a la estructura de
las organizaciones. Además, la necesidad de desarrollar una aplicación global (que
incluya a toda la organización), se resuelva fácilmente con bases de datos distribuidas.
Si una organización crece por medio de la creación de unidades o departamentos
nuevos, entonces, el enfoque de bases de datos distribuidas permite un crecimiento
suave.
Los datos se pueden colocar físicamente en el lugar donde se accesan más

frecuentemente, haciendo que los usuarios tengan control local de los datos con los que
interactúan. Esto resulta en una autonomía local de datos permitiendo a los usuarios
aplicar políticas locales respecto del tipo de accesos a sus datos.
Mediante la replicación de información, las bases de datos distribuidas pueden presentar

cierto grado de tolerancia a fallas haciendo que el funcionamiento del sistema no
dependa de un solo lugar como en el caso de las bases de datos centralizadas.
Desventajas
La principal desventaja se refiere al control y manejo de los datos. Dado que éstos
residen en muchos nodos diferentes y se pueden consultar por nodos diversos de la red,
la probabilidad de violaciones de seguridad es creciente si no se toman las precauciones
debidas.
La habilidad para asegurar la integridad de la información en presencia de fallas no

predecibles tanto de componentes de hardware como de software es compleja. La
integridad se refiere a la consistencia, validez y exactitud de la información.
Dado que los datos pueden estar replicados, el control de concurrencia y los
mecanismos de recuperación son mucho más complejos que en un sistema centralizado.
13
Aspectos importantes de los SMBD distribuidos
Existen varios factores relacionados a la construcción de bases de datos distribuidas que

no se presentan en bases de datos centralizadas. Entre los más importantes se encuentran
los siguientes:
1. Diseño de la base de datos distribuida. En el diseño de bases de datos

distribuidas se debe considerar el problema de como distribuir la información
entre diferentes sitios. Existen razones organizacionales las cuales determinan en
gran medida lo anterior. Sin embargo, cuando se busca eficiencia en el acceso a
la información, se deben abordar dos problemas relacionados. Primero, como
fragmentar la información. Segundo, como asignar cada fragmento entre los
diferentes sitios de la red. En el diseño de la BDD también es importante
considerar si la información está replicada, es decir, si existen copias múltiples
del mismo dato y, en este caso, como mantener la consistencia de la
información. Finalmente, una parte importante en el diseño de una BDD se
refiere al manejo del directorio. Si existen únicamente usuarios globales, se debe
manejar un solo directorio global. Sin embargo, si existen también usuarios
locales, el directorio combina información local con información global.
2. Procesamiento de consultas. El procesamiento de consultas es de suma
importancia en bases de datos centralizadas. Sin embargo, en BDD éste adquiere
una relevancia mayor. El objetivo es convertir transacciones de usuario en
instrucciones para manipulación de datos. No obstante, el orden en que se
realizan las transacciones afecta grandemente la velocidad de respuesta del
sistema. Así, el procesamiento de consultas presenta un problema de
optimización en el cual se determina el orden en el cual se hace la menor
cantidad de operaciones. Este problema de optimización es NP-difícil, por lo que
en tiempos razonables solo se pueden obtener soluciones aproximadas. En BDD
se tiene que considerar el procesamiento local de una consulta junto con el costo
de transmisión de información al lugar en donde se solicitó la consulta.
3. Control de concurrencia. El control de concurrencia es la actividad de
coordinar accesos concurrentes a la base de datos. El control de concurrencia
permite a los usuarios accesar la base de datos en una forma multiprogramada
mientras se preserva la ilusión de que cada usuario está utilizándola solo en un
sistema dedicado. El control de concurrencia asegura que transacciones
múltiples sometidas por usuarios diferentes no interfieran unas con otras de
forma que se produzcan resultados incorrectos. En BDD el control de
concurrencia es aún más complejo que en sistemas centralizados. Los algoritmos
más utilizados son variaciones de aquellos usados en sistemas centralizados:
candados de dos fases, ordenamiento por estampas de tiempo, ordenamiento por
estampas de tiempo múltiples y control de concurrencia optimista. Un aspecto
interesante del control de concurrencia es el manejo de interbloqueos. El sistema
no debe permitir que dos o más transacciones se bloqueen entre ellas.
4. Confiabilidad. En cualquier sistema de bases de datos, centralizado o
distribuido, se debe ofrecer garantías de que la información es confiable. Así
cada consulta o actualización de la información se realiza mediante
transacciones, las cuales tienen un inicio y fin. En sistemas distribuidos, el
14
manejo de la atomicidad y durabilidad de las transacciones es aún más complejo,

ya que una sola transacción puede involucrar dos o más sitios de la red. Así, el
control de recuperación en sistemas distribuidos debe asegurar que el conjunto
de agentes que participan en una transacción realicen todos un compromiso
(commit) al unísono o todos al mismo tiempo restablezcan la información
anterior (roll-back).
En la Figura 1.8 se presenta un diagrama con las relaciones entre los aspectos relevantes
sobre las BDD.
Figura 1.8. Factores importantes en BDD.
Estado del Arte
Aun cuando los beneficios del uso de BDD son claramente perceptibles, en la
actualidad muchos de los desarrollos se encuentran únicamente en sistemas
experimentales (de investigación). A continuación se discute el estado actual de las
bases de datos comerciales respecto de cuatro logros potenciales asequibles en BDD.
1. Manejo transparente de datos distribuidos, fragmentados y replicados.

Comercialmente aún no se soporta la replicación de información. La
fragmentación utilizada es únicamente de tipo horizontal (ésta se discute en el
capítulo 3). La distribución de información no se realiza aún con la transparencia
requerida. Por ejemplo, el usuario debe indicar la localización de un objeto y el
acceso a los datos es mediante sesiones remotas a bases de datos locales. La
mayoría de los sistemas comerciales utilizan el modelo múltiples clientes-un
solo servidor.
2. Mejoramiento de la confiabilidad y disponibilidad de la información
mediante transacciones distribuidas. Algunos sistemas como Ingres, NonStop
SQL y Oracle V 7.x ofrecen el soporte de transacciones distribuidas. En Sybase,
15
por ejemplo, es posible tener transacciones distribuidas pero éstas deber ser
implementadas en las aplicaciones mediante primitivas dadas. Respecto del
soporte para replicación de información o no se ofrece o se hace a través de la
regla une-lee-todos-escriben.
3. Mejoramiento de la eficiencia. Una mayor eficiencia es una de las grandes
promesas de los SMBDD. Existen varias partes en donde ésto se puede lograr.
En primer lugar, la ubicación de los datos a lugares próximos a donde se usan
puede mejorar la eficiencia en el acceso a la información. Sin embargo, para
lograrlo es necesario tener un buen soporte para fragmentación y replicación de
información. Otro punto en donde se puede incrementar la eficiencia es
mediante la explotación del paralelismo entre operaciones. Especialmente en el
caso de varias consultas independientes, éstas se pueden procesar por sitios
diferentes. Más aún, el procesamiento de una sola consulta puede involucrar
varios sitios y así procesarse de manera más rápida. Sin embargo, la explotación
del paralelismo requiere que se tenga tanta información requerida por cada
aplicación en el sitio donde la aplicación se utiliza, lo cual conduciría a una
replicación completa, esto es, tener toda la información en cada sitio de la red.
El manejo de réplicas es complicado dado que las actualizaciones a este tipo de
datos involucran a todos los sitios teniendo copias del dato. Los sistemas
comerciales ofrecen únicamente aproximaciones a este requisito. Por ejemplo,
en los bancos se destina usualmente el horario de oficina para hacer lecturas y
las horas no hábiles para hacer actualizaciones. Otra estrategia es tener dos bases
de datos, una para consultas y otra para actualizaciones.
4. Mejor escalabilidad de las BD. El tener sistemas escalables de manera fácil y
económica se ha logrado por el desarrollo de la tecnología de microprocesadores
y estaciones de trabajo. Sin embargo, respecto de la escalabilidad, la
comunicación de la información tiene un costo el cual no se ha estudiado con
suficiente profundidad.
16
1.2 Objetivos Bases de Datos Distribuidas

Una Base de Datos Distribuida es, una base de datos construida sobre una red
computacional y no por el contrario en una máquina aislada.
La información que constituye la base de datos esta almacenada en diferentes sitios en

la red, y las aplicaciones que se ejecutan accesan datos en distintos sitios.
Una Base de Datos Distribuida entonces es una colección de datos que pertenecen
lógicamente a un sólo sistema, pero se encuentra físicamente esparcido en varios
“sitios” de la red. Un sistema de base de datos distribuidas se compone de un conjunto
de sitios, conectados entre sí mediante algún tipo de red de comunicaciones, en el cual :
1. cada sitio es un sistema de base de datos en sí mismo, pero
2. los sitios han convenido en trabajar juntos (si es necesario) con el fin de que un
usuario de cualquier sitio pueda obtener acceso a los datos de cualquier punto de la red
tal como si todos los datos estuvieran almacenados en el sitio propio del usuario.
En consecuencia, la llamada “base de datos distribuida” es en realidad una especie de

objeto virtual, cuyas partes componentes se almacenan físicamente en varias bases de
datos “reales” distintas ubicadas en diferentes sitios. De hecho, es la unión lógica de
esas bases de datos.
En otras palabras, cada sitio tiene sus propias bases de datos “reales” locales, sus
propios usuarios locales, sus propios DBMS y programas para la administración de
transacciones (incluyendo programas de bloqueo, bitácoras, recuperación, etc.), y su
propio administrador local de comunicación de datos (administrador DC).
En particular un usuario dado puede realizar operaciones sobre los datos en su propio
sitio local exactamente como si ese sitio no participara en absoluto en el sistema
distribuido (al menos, ése es uno de los objetivos). Así pues, el sistema de bases de
datos distribuidas puede considerarse como una especie de sociedad entre los DBMS
individuales locales de todos los sitios.
Un nuevo componente de software en cada sitio (en el aspecto lógico, una extensión del
DBMS local) realiza las funciones de sociedad necesarias; y es la combinación de este
nuevo componente y el DBMS ya existente lo que constituye el llamado “sistema de
administración de bases de datos distribuidas” (DDBMS, distributed database
management system ).
17
1.3 Disciplinas Estudio Bases de Datos Distribuidas
Aunque la materia Bases de Datos tiene un carácter propedéutico para la

disciplina de los sistemas de bases de datos y el área más general de sistemas de
información, es necesario conocer cuál ha sido la evolución y estado actual de la
tecnología de bases de datos, con el objetivo de estar preparados para los cambios que,
inevitablemente, se van a dar en el área de las bases de datos y los sistemas de
información.
Para ello, en este informe se relata brevemente la evolución de los sistemas de bases de
datos, centrándose en los fundamentos de la tecnología actual y su motivación. Haremos
un repaso de las nociones y evolución básicas de los modelos pre-relacionales,
relacional, objetual y objeto-relacional, las bases de datos paralelas y distribuidas,
multimedia, los almacenes de datos, la relación entre las bases de datos y la web, así
como otras áreas y aplicaciones. Esto nos lleva a evaluar la situación actual,
especialmente las nuevas demandas sobre sistemas de información exigidas por el
aumento de interconectividad, los nuevos imperativos de publicación e intercambio de
información, los datos semiestructurados y el estándar XML, así como el análisis de
datos para la toma de decisión y los avances y perspectivas en las “bases de
conocimiento”. Se comentan también las líneas de investigación abiertas más
importantes en el área y una opinión personal sobre hacia donde parece dirigirse la
disciplina. Finalmente, se estudia sucintamente la sociología de la disciplina, su
interrelación con otras disciplinas del área de Lenguajes y Sistemas Informáticos y las
organizaciones, congresos y publicaciones más importantes.
1.1. La Evolución de los Sistemas de Bases de Datos

Los sistemas de información existen desde las primeras civilizaciones. El concepto más
esencial de sistema de información no ha variado desde los censos romanos, por poner
un ejemplo. Los datos se recopilaban, se estructuraban, se centralizaban y se
almacenaban convenientemente. El objetivo inmediato de este proceso era poder
recuperar estos mismos datos u otros datos derivados de ellos en cualquier momento,
sin necesidad de volverlos a recopilar, paso que solía ser el más costoso o incluso
irrepetible. El objetivo ulterior de un sistema de información, no obstante, era
proporcionar a los usuarios información fidedigna sobre el dominio que representaban,
con el objetivo de tomar decisiones y realizar acciones más pertinentes que las que se
realizarían sin dicha información.
Llamamos base de datos justamente a esta colección de datos recopilados y

estructurados que existe durante un periodo de tiempo. Por ejemplo, un libro contable,
debido a su estructura, se puede considerar una base de datos. Una novela, por el
contrario, no tiene casi estructura, y no se suele considerar una base de datos.
Generalmente, un sistema de información consta de una o más bases de datos, junto con
los medios para almacenarlas y gestionarlas, sus usuarios y sus administradores.
18
Hoy en día, sin embargo, solemos asociar las bases de datos con los ordenadores, y su
gestión no suele ser manual, sino altamente automatizada. Más concretamente, la
tecnología actual insta a la delegación de la gestión de una base de datos a unos tipos de
aplicaciones software específicas denominadas sistemas de gestión de bases de datos
(SGBD) o, simplemente, sistemas de bases de datos. Por esta razón, hablar de la
tecnología de bases de datos es prácticamente lo mismo que hablar de la tecnología de
los sistemas de gestión de bases de datos.
Las funciones básicas de un sistema de gestión de base de datos son :
1. Permitir a los usuarios crear nuevas bases de datos y especificar su estructura,

utilizando un lenguaje o interfaz especializado, llamado lenguaje o interfaz de
definición de datos.
2. Dar a los usuarios la posibilidad de consultar los datos (es decir, recuperarlos parcial
o totalmente) y modificarlos, utilizando un lenguaje o interfaz apropiado, generalmente
llamado lenguaje de consulta o lenguaje de manipulación de datos.
3. Permitir el almacenamiento de grandes cantidades de datos durante un largo periodo
de tiempo, manteniéndolos seguros de accidentes o uso no autorizado y permitiendo un
acceso eficiente a los datos para consultas y modificaciones.
4. Controlar el acceso a los datos de muchos usuarios a la vez, impidiendo que las
acciones de un usuario puedan afectar a las acciones de otro sobre datos diferentes y que
el acceso simultáneo no corrompa los datos.
1.1.1. Primeros Sistemas de Base de Datos

Los primeros sistemas de bases de datos aparecieron a finales de los cincuenta. En este
periodo, muchas compañías se fueron dando cuenta de que los primeros sistemas
informáticos brindaban la posibilidad de aplicar soluciones mecánicas más baratas y
eficientes. Los primeros sistemas evolucionaron de los sistemas de ficheros que
proporcionaban la función comentada anteriormente: los sistemas de ficheros
almacenan datos durante un largo periodo de tiempo y permiten el almacenamiento de
grandes cantidades de datos. Sin embargo, los sistemas de ficheros no garantizaban
generalmente que los datos no se perdían ante fallos bastante triviales, y se basaban casi
exclusivamente en recuperación por copia de seguridad. Además, los sistemas de
ficheros proporcionaban de una manera limitada la función es decir, un lenguaje de
consultas para los datos en los ficheros. El soporte de estos sistemas para la función un
esquema para los datos también era limitada y de muy bajo nivel. Finalmente, los
sistemas de ficheros no satisfacen la función. Cuando permiten acceso concurrente a
ficheros por parte de varios usuarios o procesos, un sistema de ficheros no previene
generalmente las situaciones en la que dos usuarios modifican el mismo fichero al
mismo tiempo, con lo que los cambios realizados por uno de ellos no llegan aparecer
definitivamente en el fichero.
Las primeras aplicaciones importantes de los sistemas de ficheros fueron aquellas en la

que los datos estaban compuestos de partes bien diferenciadas y la interrelación entre
ellas era reducida. Algunos ejemplos de estas aplicaciones eran los sistemas de reserva
(p.ej. reserva e información de vuelos), los sistemas bancarios donde se almacenaban las
operaciones secuencialmente y luego se procesaban, y los primeros sistemas de
organización corporativos (ventas, facturación, nóminas, etc.).
19
Los primeros verdaderos SGBDs, evolucionados de los sistemas de ficheros, obligaban

a que el usuario visualizara los datos de manera muy parecida a como se almacenaban.
Los primeros sistemas de ficheros habían logrado pasar del código máquina a un
lenguaje ensamblador con ciertas instrucciones de acceso a disco, nociones que se
pueden ver en sistemas todavía en funcionamiento hoy en día, tales como la línea AS de
IBM.
No es de extrañar que con este nivel de abstracción la manera de recuperar los datos
estaba estrechamente ligada al lenguaje de programación utilizado. Un avance
importante lo constituyó el comité formado en la COnference on DAta SYstems and
Languages, CODASYL, en 1960 estableciendo el COmmon Business-Oriented
Language (COBOL) como un lenguaje estándar para interrelacionar con datos
almacenados en ficheros. Aunque hoy en día puede parecer un lenguaje “muy físico”,
en aquella época representó lo que se vinieron a llamar los lenguajes de programación
de tercera generación. Las instrucciones específicas de un programa Cobol para
tratamiento de ficheros eran las de abrir un fichero, leer un fichero y añadir un registro a
un fichero. Lo típico en gestión de datos en esta época era un fichero ‘batch’ de
transacciones que se aplicaba a un maestro viejo en cinta, produciendo como resultado
un nuevo maestro también en cinta y la impresión para el siguiente día de trabajo.
Pero pronto los discos magnéticos empezaron a sustituir a las cintas magnéticas, lo que
supuso una reconcepción del almacenamiento, al pasarse del acceso secuencial al
acceso aleatorio (este paso es el que se conoce como el paso de los sistemas de bases
de datos de primera a segunda generación).
Durante los sesenta empezaron a aparecer distintos modelos de datos para describir la
estructura de la información en una base de datos, con el objetivo de conseguir una
independencia un poco mayor entre las aplicaciones y la organización física de los
datos. Esto se consiguió inicialmente mediante la abstracción entre varios
(sub)esquemas externos para las aplicaciones frente a la organización física de los
mismos. Esta separación en dos niveles fue propuesta por el grupo Data Base Task
Group (DBTG) del comité CODASYL.
Los modelos más popularizados fueron el modelo jerárquico o basado en árboles, y el

modelo en red o basado en grafos. Los SGBD acordes con estos modelos se conocieron
como SGBD de tercera generación.
Pasemos a comentar brevemente estos dos modelos:

El modelo jerárquico no tiene una historia demasiado bien documentada. Se deriva de
los sistemas de gestión de información de los cincuenta y los sesenta. En 1968, IBM
introdujo el sistema IMS, derivado del programa Apollo de la NASA sobre sus
System/360, basado en el modelo jerárquico. Este modelo fue adoptado por muchos
bancos y compañías de seguros que todavía los utilizan en algún caso hoy en día. Los
sistemas de base de datos jerárquicos todavía se pueden encontrar en algunos
departamentos de instituciones públicas y hospitales para gestionar el inventario y la
contabilidad, aunque la renovación provocada por el efecto 2000 ha eliminado
prácticamente su uso, así como el reciclaje de los expertos en estos sistemas a otros más
modernos. El modelo jerárquico se basa en almacenar los datos en una serie de
registros, los cuales tienen campos asociados a ellos. Para crear enlaces entre los tipos
de registros, el modelo jerárquico utiliza las relaciones padre-hijo, correspondencias 1:N
20
entre tipos de registro. Esto se realiza mediante el uso de árboles. A diferencia de otros
modelos, como el modelo en red que veremos a continuación, el modelo jerárquico
representa precisamente eso, todas las relaciones están jerarquizadas en un árbol, por lo
que no es capaz de establecer enlaces entre hijos o entre capas, si no es padre-hijo.
La ventaja del modelo jerárquico es su gran estructuración, que en aquel tiempo se veía
como una gran ventaja para mejorar el rendimiento de las transacciones (inserción,
modificación y borrado de registros), así como para simplificar la interfaz para los
usuarios.
El modelo en red se estandarizó a finales de los sesenta mediante un informe de

CODASYL (COnference on DAta SYstems and Languages) Data Base Task Group
(DBTG) Por eso, a veces se le conoce como el modelo DBTG o el modelo CODASYL.
El primer informe de CODASYL ya incluía la sintaxis y semántica de un lenguaje de
definición de datos (DDL, Data Definition Language) y de un lenguaje de manipulación
de datos (DML, Data Manipulation Language). Siguiendo muchos comentarios y
revisiones de expertos y usuarios se realizó un nuevo informe [CODASYL 1971], en el
que ya se incluía la posibilidad de definir vistas para los distintos grupos de usuarios. El
término base de datos en red no se refería (al contrario de lo que se entendería hoy en
día) a que la base de datos estuviera almacenada en una red de ordenadores, sino por la
manera en la que los datos se enlazaban con otros datos. Se llama, por tanto, modelo en
red porque representa los datos que contiene en la forma de una red de registros y
conjuntos (en realidad listas circulares llamadas sets) que se relacionan entre sí,
formando una red de enlaces. Para hacer esto utiliza registros, tipos de registro y tipos
de conjunto.
El modelo en red tampoco se utiliza casi hoy en día y si subsiste es como consecuencia
del mantenimiento de un sistema todavía no reconvertido o no portado a modelos y
SGBD más modernos. Aunque este modelo permite más flexibilidad que el modelo
jerárquico, y en algunos casos se adapta muy bien a algunos tipos de transacciones, se
considera superado por otros modelos, como el relacional, o subsumido en parte por
modelos más modernos, como el objetual.
En resumen, los modelos jerárquico y red, con el paso de los años, se pueden considerar
como modelos puente hacia el modelo relacional, ya que se incorporan en los primeros
sistemas de gestión de bases de datos que introducen un mayor nivel de independencia,
respecto a la estructura interna, pero siguen teniendo una estructura de cierto bajo nivel
y de compleja manipulación.
Otro problema con estos modelos y sistemas iniciales era que no iban acompañados de
lenguajes de consulta de alto nivel. Por ejemplo, el lenguaje de consulta CODASYL
tenía sentencias que permitían al usuario saltar de un elemento de datos a otro a través
de grafos de punteros entre estos elementos. Se requería un gran esfuerzo para escribir
estos programas, incluso para consultas muy sencillas.
Antes de pasar a ver los sistemas de base de datos relacionales, hay que destacar el
nacimiento y definición del concepto de transacción y sus propiedades asociadas, lo que
se conoce como el “ACID test”. Aunque el concepto de transacción evoluciona en las
primeras décadas del desarrollo de las bases de datos, se considera el trabajo de James
21
Gray [Gray 1981] como el que le da su forma actual. Se dice que un SGBD cumple el
“ACID
test” si observa las propiedades de (A)tomicidad, (C)onsistencia, a(I)slamiento y
(D)urabilidad. En concreto:
 Atomicidad: los resultados de una transacción o bien pasan a ser completados todos
(commit) o bien
pasan a ser todos deshechos (rollback). Es decir, o todos los cambios incluidos en una
transacción tienen
efecto o no lo tiene ninguno.
4
Consistencia: las bases de datos se transforman de estados íntegros a estados íntegros,
es decir, entre
estados válidos. Una transacción sólo se puede completar si el estado final es íntegro.
A  islamiento: los resultados de una transacción son invisibles para el resto de
transacciones de otros
procesos hasta que la transacción se ha completado.
D  urabilidad o permanencia: una vez una transacción ha sido completada, los
resultados (cambios) de la
transacción se hacen permanentes, incluso frente a fallos del sistema y de medios de
almacenamiento.
Sólo si estas propiedades de las transacciones se cumplen, podemos considerar que un
SGBD cumple las
propiedades 3 y 4 comentadas al principio.
1.1.2. Sistemas de Base de Datos Relacionales
Al menos un investigador de IBM no estaba satisfecho ni con los productos Codasyl, ni
con los sistemas
jerárquicos de la propia IBM. Edgar F. (Ted) Codd, un matemático formado en Oxford,
que había entrado en
IBM en 1949, empezó a trabajar en una serie de informes técnicos acerca de una manera
‘nueva’ de organizar y
acceder a los datos. A partir de estos trabajos publicó el artículo “A Relational Model of
Data for Large Shared
Data Banks” en 1970 [Codd 1970]. Codd propuso que los sistemas de bases de datos
deberían presentarse a los
usuarios con una visión de los datos organizados en estructuras llamadas relaciones. Las
relaciones se definen
como conjuntos de tuplas, no como series o secuencias de objetos, con lo que el orden
no es importante. Por
tanto, detrás de una relación puede haber cualquier estructura de datos compleja que
permita una respuesta
rápida a una variedad de consultas. Además, aunque no es un aspecto intrínseco del
modelo relacional, según la
propuesta de Codd, el usuario de un sistema relacional no tenía que preocuparse de la
estructura de
almacenamiento, sólo debía preocuparse por el qué consultar y no el cómo. Hoy en día
es válido todavía el
resumen de su artículo [Codd 1970], especialmente la siguiente parte:
“Future users of large data banks must be protected from having to know how the data
is organized in the machine (the
22
internal representation). [...] Activities of users at terminals and most application

programs should remain unaffected
when the internal representation of data is changed and even when some aspects of the
external representation are
changed. Changes in data representation will often be needed as a result of changes in
query, update, and report traffic
and natural growth in the types of stored information.”1
Además, las consultas podían expresarse en un lenguaje de muy alto nivel, lo que
incrementaba en gran medida la
eficiencia de los programadores sobre bases de datos. En resumen, Codd concibió un
sistema donde el usuario
sería capaz de acceder a la información con comandos parecidos al lenguaje natural y
donde la información
estuviera almacenada en ‘tablas’.
Pese a sus virtudes, la aceptación del modelo relacional no fue inmediata, debido en
parte a la naturaleza
técnica del artículo y a su base matemática que, aunque muy simple, no era común para
la industria de bases de
datos de la época. Además, se dudaba de la eficiencia del modelo. Más aún, dentro de
IBM, la reticencia fue muy
grande, ya que IBM había invertido una gran cantidad de esfuerzo y dinero en el
producto ya existente IMS y
líder del mercado. La nueva tecnología relacional debía demostrar que era mucho mejor
que la existente para
cambiar la situación. De hecho, Codd publicó el artículo en una revista de ámbito
científico y abierto porque
nadie en IBM (ni siquiera él mismo) reconoció en su momento el impacto que tendría
después. Todos se
sorprendieron pronto de que la respuesta externa al artículo fuera muy positiva. Incluso
se acogió la idea con
todo su potencial comercial. La reacción inicial de IBM fue tajante: declaró IMS su
producto estratégico con
exclusividad y consideró el modelo relacional como contrario a sus intereses. Codd, por
su parte, no cedió en su
defensa pública de las ventajas de su propuesta e incluso mantuvo un debate público
con Charles Bachman, el
mayor defensor del estándar Codasyl, ignorando del debate al modelo jerárquico, en el
cual se basaba el IMS.
Esto dejaba al modelo jerárquico del IMS en una situación incómoda. Afortunadamente,
y en parte debido a esta
publicidad, desde fuera, la Universidad de California en Berkeley creyó en la idea del
modelo relacional y obtuvo
financiación militar y de la NSF (National Science Foundation) para desarrollar un
sistema relacional, el Ingres.
1 “Los usuarios futuros de grandes bancos de datos deben ser protegidos de tener que
saber cómo están organizados los datos en la
máquina (la representación interna). [...] Las actividades de los usarios en sus terminales
y la mayoría de programas de aplicación no se
23
deberían ver afectados cuando se cambia la representación interna de los datos o incluso
cuando se cambian algunos de los aspectos de la
representación externa. Se necesitará cambiar la representación de los datos a menudo
como resultado de los cambios en el tráfico de las
consultas, actualizaciones e informes y como consecuencia del crecimiento natural en
los tipos de información almacenada.”
5
La contra-reacción de IBM fue inmediata, puso en marcha el desarrollo de otro sistema
relacional, el “System
R”2.
El grupo de investigación de IBM a cargo del proyecto esperaba crear un sistema de
bases de datos relacional
que pudiera convertirse eventualmente en un producto. Su primer prototipo, elaborado
entre 1974 y 1975, se
utilizó experimentalmente por diversas organizaciones, como p.ej. la “MIT Sloan
School of Management”
[Astrahan et al. 1976]. No obstante, este primer prototipo se abandonó en pro del
rediseño de “System R” como
un sistema multiusuario y con completa funcionalidad, con un lenguaje de consulta
estructurado, el SEQUEL
[Boyce & Chamberlin 1974], que luego pasaría a llamarse SQL (Structured Query
Language).
Sin embargo, el primer SGBD Relacional (SGBDR) completamente funcional, Ingres,
se desarrolló en la
Universidad de California en Berkeley por un grupo liderado por Michael Stonebraker y
Eugene Wong.
Alrededor de 1974, consiguieron la primera versión completamente funcional del
mismo Ingres [Stonebraker et
al. 1976], aunque el producto se revisó continuamente durante toda la década con los
comentarios y
realimentación de muchos usuarios en otras Universidades y centros que lo adaptaban a
sus cada día más baratas
máquinas DEC (el código fuente del Ingres era inicialmente público) [Stonebraker
1980]. Ingres incluía su propio
lenguaje de consultas, QUEL, que era similar en algunos aspectos al SQL. A finales de
los setenta se comercializó
por Relational Technology, Inc. Más tarde, Ingres se convirtió en un SGBDR comercial
distribuido por Ingres,
Inc., una subsidiaria de ASK, Inc., y, actualmente, lo distribuye Computer Associates.
Pero no fue éste (ni el de
IBM) el primer producto relacional comercial. Este hito le corresponde a Honeywell
Information Systems Inc.,
que sacó su primer producto comercial relacional en junio de 1976. Se basaba en los
mismos principios que el
sistema de IBM, pero se diseñó de manera separada al trabajo de IBM.
Durante estos desarrollos se produjo la publicación de la separación en tres niveles de
los SGBD descrita por
el informe del comité ANSI/SPARC de 1975 [ANSI/SPARC 1975] [Fry & Sibley
1976]: externo, conceptual e
24
interno. Ésta se hizo independientemente de la propuesta anterior de dos niveles

(externo e interno) del
CODAYSL/DBTG. Posteriormente, el CODASYL reformuló su propuesta a partir de la
del comité
ANSI/SPARC, presentando la arquitectura de tres niveles más popular: subesquemas
externos, esquema lógico y
esquema físico (también llamado almacenado o interno). Este comité propuso un
lenguaje para definir este
último esquema, el DSDL (Data Storage Definition Language). También comenzaba a
perfilarse el uso
diferenciado del valor nulo y la extensión del álgebra relacional a una lógica trivaluada.
Independientemente de la lentitud e indecisión para lanzar sus productos al mercado, el
esfuerzo de
desarrollo mayor se realizó en IBM en el San José Research Center (hoy llamado
Almaden Research Center).
Algunos de sus grandes méritos, como el SQL, tardó en ser reconocido por la compañía.
De nuevo, fue la
presión de otra compañía, en este caso Oracle, creada por Larry Ellison, la que, al
desarrollar y vender un
producto compatible con SQL, hizo reaccionar a IBM. Es importante destacar que
Ellison había conocido el
SQL a partir de las publicaciones del System R. Del mismo modo, la amenaza de otros
productos, como los
desarrollados por Software AG, motivaron a IBM a continuar investigando en la línea
de System R. Esta
investigación condujo al anuncio por parte de IBM de dos sistemas de gestión de bases
de datos relacionales
(SGBDR) en los ochenta: en 1981 se introdujo SQL/DS para los entornos DOS/VSE
(disk operating
system/virtual storage extended) y VM/CMS (virtual machine/conversational
monitoring system); en 1983 se
introdujo DB2 para el sistema operativo MVDS. En el desarrollo de estos productos,
IBM introdujo ideas
pioneras en la optimización de consultas, en la independencia de datos del esquema
externo (vistas), en las
transacciones (ficheros log y bloqueos) y en la seguridad (el modelo grant-revoke).
Otros SGBDR comerciales muy populares de esta época son, Oracle de Oracle Inc.,
como hemos visto;
Sybase de Sybase Inc.; RDB de Digital Equipment Corp, ahora en propiedad de
Compaq; Informix de Informix
Inc.; y Unify de Unify Inc. Ésta es la época de los llamados SGBD de cuarta
generación.
Aparte de los SGBDR mencionados anteriormente, muchas implementaciones del
modelo relacional
aparecieron en el ámbito de los ordenadores personales en los ochenta. Éstos son RIM,
RBASE 5000, Paradox,
OS/2 Database Manager, DBase IV, XDB, Watcom SQL, SQL Server de Sybase, Inc.,
SQL Server y Access de
25
Microsoft, y MySQL. Inicialmente eran sistemas mono-usuario, pero muchos de ellos

han comenzado a
incorporar arquitecturas cliente/servidor e interconectividad con otras bases de datos.
Respecto a los lenguajes de consulta, Codd introdujo el álgebra relacional en [Codd
1970] y [Kuhns 1967]
consideró anteriormente el uso de la lógica para realizar consultas, que llevaría a
lenguajes lógicos como el
Cálculo Relacional de Tuplas o Dominios. De hecho fue el propio Codd quien presentó
el Cálculo Relacional
como alternativa al álgebra relacional en [Codd 1971]. Con el tiempo se realizaron
diversas generalizaciones de
2 Una historia del System R se puede encontrar en [Chamberlin 1998] o en
(http://www.mcjones.org/System_R/).
6
ambos lenguajes para incluir operaciones agregadas [Klug 1982] o cuantificadores del
estilo “el número de”
[Merrett 1978] [Badia et al. 1995].
Algunos resultados importantes teóricos son la demostración de la equivalencia
expresiva entre el álgebra
relacional y el cálculo relacional completo, demostrada por el mismo Codd [Codd
1972b], así como [Chandra &
Merlin 1977] mostraron que determinar si dos consultas conjuntivas (es decir, que sólo
contienen selecciones,
proyecciones y productos cartesianos) son equivalentes es NP completo (sobre
conjuntos de tuplas). La
equivalencia entre consultas incluyendo unión se demostró decidible en [Sagiv &
Yannakakis 1980]. La noción de
optimización semántica de consultas se basa en transformaciones que preservan la
equivalencia sólo cuando
algunas restricciones de integridad se cumplen. Esta idea la introdujo [King 1981].
Sin embargo, en la práctica, aunque muy útiles para presentar el modelo relacional, o
demostrar propiedades
como las anteriores, ninguno de los lenguajes algebraicos o lógicos se llega a utilizar en
los SGBDR comerciales.
Es el SQL, una mezcla de ambos con sintaxis inspirada en el lenguaje natural (inglés),
que se convierte en el
lenguaje estándar de consultas. Como hemos dicho, la versión original de SQL se
desarrolló como el lenguaje de
consulta del proyecto System R de IBM [Boyce & Chamberlin 1974], [Chamberlin et
al. 1976]. Gracias a sus
virtudes (y a pesar de sus defectos [Date 1984]), el SQL comenzó una difusión y una
estandarización
(especialmente entre 1982 y 1986). El estándar SQL pasó de IBM a ANSI (American
National Standard
Institute) en 1982, formándose el comité X3H2. que junto a la ISO (International
Standard Organization) publica
el llamado SQL/ANS en 1986, siendo norma ISO en 1987, versión 1 del estándar. En
1989 se revisa en la
26
versión 1 addendum. En 1992 aparece SQL2 o SQL92, la versión hoy en día más
difundida [ISO/IEC 1992]
[ANSI 1992] [ISO/IEC 1994]. Con la aparición de la segunda versión del estándar
(SQL2) en 1992,
prácticamente todos los SGBR, incluso los no relacionales, incluían soporte a SQL. Hoy
en día, SQL se ha
convertido en el lenguaje de consulta más utilizado. En 1999 apareció SQL3
[ANSI/ISO/IEC 1999] y, desde
entonces, se trabaja sobre la estandarización del SQL/MM y se espera la versión SQL4
en los próximos años.
Existen opiniones, personificadas por C.J. Date, que el estándar ha cedido mucho a los
SGBD comerciales,
desvirtuándose el modelo relacional, especialmente en el hecho de permitir duplicados
en las tablas.
El proyecto QBE (Query By Example) lo lideró Zloof [Zloof 1975], resultando en el
primer lenguaje de
consulta a base de datos “visual”, que influyó de manera importante a otros productos
del mismo estilo como
Paradox de Borland o Access de Microsoft.
Las dependencias funcionales también se introdujeron en [Codd 1970], junto con el
concepto de tercera
formal normal. Los axiomas para inferir dependencias funcionales y que caracterizan a
las mismas se presentaron
en [Armstrong 1974]. La BCNF (Boyce Codd Normal Form) se introdujo en [Codd
1972a]. El concepto de
cobertura mínima fue introducido por [Paredaens 1977]. Los algoritmos para el cálculo
de coberturas no
redundantes se introdujo en [Beeri & Bernstein 1979]. En [Maier 1983] se puede
encontrar una recopilación de
todos estos resultados.
La razón y uso de las formas normales es evitar la repetición innecesaria de datos
(redundancia). Una solución
a este problema es repartirlos en varias tablas y utilizar referencias por valor entre ellas.
Este es el ejemplo típico
de que la tupla de cada empleado no debe repetir toda la información de su
departamento, sino que debe utilizar
una referencia por valor a la tupla de la relación departamento donde estén todos estos
datos. Este
procedimiento ahorra espacio de almacenamiento y al evitar la redundancia evita
modificaciones parciales o
incompletas que podrían dar lugar a inconsistencias.
Este proceso se conoce como normalización. Generalmente se habla de seis formas
normales, de la forma
normal 1 a la 3, luego la BNF, seguidas de las formas normales 4 y 5. Al nivel más bajo
(primera forma normal)
se tiene todo en una tabla con todos los atributos requeridos en ella. Al mayor nivel
(quinta forma normal) se
tienen un gran número de tablas pequeñas a las que sólo se hace referencia si se requiere
la información que
27
contienen. Parece ser que esto reduce el espacio, al no tener información repetida. Esto
empieza a ser cierto
hasta la tercera forma normal. A partir de ahí se utiliza mucho espacio para referencias
por valor. Del mismo
modo puede parecer que una normalización extrema podría reducir el tiempo para
procesar las consultas, ya que
los datos no necesarios no se recuperan y se necesita menos espacio de almacenamiento
temporal. Sin embargo,
a medida que nos movemos a formas normales mayores, se experimenta el problema de
que se incrementa el
tiempo necesario para concatenar las tablas. Por esta razón, en la práctica, la mayoría de
organizaciones llegan
hasta la tercera normal (ya introducias en [Codd 1970] como hemos dicho) a no ser que
exista alguna otra razón
para normalizarlas más.
Por todo lo anterior, en 1980, la ACM (Association for Computer Machinery) otorgaba
a Codd el “Turing
Award”, uno de los premios más prestigiosos en el campo de la informática. El modelo
relacional era imparable.
7
Aún así, todavía a principios de los ochenta existían numerosas voces dispares al
modelo relacional. Esta
reacción al cambio venía fundamentada en ideas erróneas sobre los sistemas de bases de
datos relacionales. Se
decía que se necesitaban conocimientos teóricos para utilizar bases de datos
relacionales, que la teoría de la
normalización limitaba el uso de los mismos, que el rendimiento de los SGBDR era
malo, que el modelo
relacional era muy pobre y también era muy rígido. Estos mitos (recogidos con ironía en
[Gardarin & Valduriez
1987]), fueron cayendo con el tiempo.
Teniendo en cuenta todo lo anterior, la aceptación del modelo relacional se puede
considerar hoy en día
como generalizada. En libros de hace poco más de una década, el modelo relacional
aparecía a la par con los
otros dos modelos tradicionales (también llamados navegacionales): el modelo en red o
el modelo jerárquico
[Ullman 1980] [Date 1981][Everest 1986] [Gardarin 1988]. Sólo los libros
explícitamente denominados “bases de
datos relacionales” (p.ej. [Delobel & Adiba 1985] [Gardarin & Valduriez 1987]) se
atrevían a centrarse en este
modelo. En los libros genéricos sobre bases de datos, los modelos navegacionales han
sido desplazados a
apéndices o han desaparecido completamente de los mismos. Bien es cierto que su lugar
ha sido ocupado por el
modelo objetual u objeto-relacional, aunque generalmente con menos profusión que el
relacional [Date 1999]
[Elsmasri & Navathe 2000]. También hay que destacar que estos dos últimos modelos
tienen ciertas cosas en
28
común con los navegacionales, cosa que justifica en gran medida el concepto de
“modelo de datos” como
abstracción que recoge todos estos cambios tecnológicos.
La siguiente gráfica muestra que hasta 1992 las ventas de SGBD relacionales no
superaron las ventas de
SGBD tradicionales (red, jerárquicos y otros pre-relacionales):
VENTAS MUNDIALES DE SGBD 1991-1999
1991 1992 1993 1994 1995 1996 1997 1998 1999 Crec. Medio
1994-1999
Pre-relacional 2.000 2.090 2.109 2.050 1.866 1.721 1.701 1.689 1.638
Crecimiento - 4,5 0,9 -2,8 -9,0 -7,8 -1,2 -0,7 -3,0 -4,4%
Cuota de mercado 52,0 45,5 38,8 31,6 24,0 18,4 15,2 12,6 10,3
Relacional 1.844 2.502 3.328 4.435 5.925 7.652 9.513 11.685 14.254
Crecimiento - 35,7 33,0 33,3 33,6 29,1 24,3 22,8 22,0 26,3%
Cuota de mercado 48,0 54,5 61,2 68,4 76,0 81,6 84,8 87,4 89,7
SGBD total 3.844 4.592 5.437 6.485 7.791 9.373 11.214 13.374 15.892
Crecimiento - 19,5 18,4 19,3 20,1 20,3 19,6 19,3 18,8 19,6%
Fuente: IDC (tomado de [de Miguel & Piattini 1997])
No obstante es de destacar que, en entornos empresariales, hay mucha cantidad de datos
hoy en día que se
almacenan en hojas de cálculo en vez de bases de datos, y que un porcentaje importante
de los datos de
producción todavía se encuentran en sistemas heredados (legacy systems), es decir,
sistemas tecnológicamente
obsoletos pero que se mantienen por el coste de realizar la migración.
Toda esta historia muestra que ciertas ideas requieren un contexto y una competencia
para hacerse efectivas.
Existen muchos otros casos de mejoras tecnológicas que no han llegado a imponerse por
falta de apoyo por la
industria o por la defensa a ultranza de soluciones peores por gigantes de la informática.
En este caso, si no se
hubiera producido el desarrollo por parte de la Universidad de California en Berkeley
del sistema Ingres, IBM no
habría visto ninguna amenaza en el modelo relacional, y no habría invertido esfuerzos
en el System R. También
fue importante la difusión del código de las primeras versiones del Ingres, lo que
permitió a la comunidad
científica experimentar con las ideas relacionales [NAP 1999]. Esto refuerza el papel de
instituciones
independientes, como las Universidades, para no sólo generar nuevas tecnologías sino
promoverlas (aunque sean
ajenas, como en el caso del modelo relacional), cuando las empresas grandes no tienen
interés en perder sus
cuotas de mercado.
Respecto al modelado de bases de datos, aparece la noción de modelo semántico, es
decir, modelos dedicados
específicamente a representar la realidad sobre la cual versa la base de datos. Al separar
este modelo semántico
29
del modelo lógico, el diseñador no tiene que preocuparse en cuestiones del modelo
concreto de trabajo y de
ciertas particularidades. El modelo entidad relación (ER) fue propuesto por [Chen
1976]. La generalización y la
agregación se propusieron en [Smith & Smith 1977]. El modelo ER con estas dos
extensiones se conoce como
modelo entidad relación extendido (ERE). Debido a la simplicidad de este modelo, su
expresividad y la
relativamente sencilla transformación de este modelo a un esquema lógico relacional se
popularizó rápidamente
como herramienta para representar el modelo conceptual de un sistema de información,
creando la clásica
separación en las etapas del desarrollo de un sistema de información: diseño conceptual,
diseño lógico, diseño
8
físico e implantación. El modelo ER era exclusivamente estático, expresaba las
entidades de la realidad y sus
relaciones. El diseño conceptual basado en los Diagramas ER (ERD) adolecía, por
tanto, de dinámica. Para paliar
esta carencia, inicialmente se solía combinar el ER con los populares diagramas de flujo
de datos (DFD)
[Constantine & Yourdon 1978], hablándose de análisis de datos (ERD) y análisis
funcional o de procesos (DFD).
Hoy en día se suele combinar los ERDs con lenguajes lógico-conceptuales o lenguajes
de especificación de
transaccionales. El modelo entidad relación ha tenido una influencia muy importante en
otros lenguajes de
modelado utilizados en ingeniería del software, incluso en los orientados a objetos.
Posteriormente al modelo
ER, aparecieron otros modelos, como el SDM de [Hammer & MacLeod 1981], el FDM
(DAPLEX) de [Shipman
1981] y el modelo semántico general de [Hull & King 1987].
El software de los SGBDR se fue refinando continuamente durante los ochenta. Esto se
debió en parte por la
realimentación de los clientes, el desarrollo de sistemas para nuevas industrias que no
solían utilizar SGBDs y el
uso creciente de ordenadores personales y sistemas distribuidos. Por ejemplo, el
proyecto Ingres continuó
investigando las bases de datos distribuidas, la inferencia en bases de datos y las bases
de datos activas.
La mayoría de sistemas empezaban a ir acompañados de un lenguaje de programación
llamado de cuarta
generación (los 4GLs). Dentro de estos lenguajes se podía utilizar el SQL embebido
(embedded SQL). Por SQL
embebido se entiende el uso de comandos SQL dentro de un lenguaje de programación,
p.ej. lenguajes genéricos
como el Pascal o el C, o lenguajes específicos como el PL/SQL de Oracle. Una de las
doce reglas fundamentales
30
de un SGBDR (enunciadas por Codd en 1985 [Codd 1985a, 1985b]) es que el lenguaje
4GL no puede saltarse las
restricciones que se impongan sobre la base de datos. Otro de los usos de rápido
crecimiento de los 4GL fue la
de expresar la actividad en bases de datos, especialmente reglas de actividad (triggers)
combinando el trío eventocondición-
acción, donde el evento y la condición estaban expresados en términos similares al
lenguaje de
manipulación (adaptando SQL) y la acción se expresaba en 4GL (que a su vez podía
contener sentencias de
lenguaje de manipulación). Estas reglas de actividad pueden responder tanto a eventos
internos como externos.
Éste es el principio de las bases de datos activas [Widom & Ceri 1996], imprescindible
para aplicaciones de
control: plantas de fabricación, tráfico, sistemas de urgencias, reactores y motores, etc.
La aparición de diversos sistemas relacionales, aunque estuvieran la mayoría de ellos
basados en SQL,
planteaba problemas de compatibilidad. Existían muchas corporaciones que utilizaban
distintos SGBDs para
diferentes partes de su sistema de información, debido a razones históricas y evolución
de la propias firmas,
además de organizaciones departamentales muy estancas. Era muy usual que la
organización contará con un
sistema central con su SGBD además de otros SGBD sobre ordenadores personales.
Que estos SGBD se
interrelacionaran y pudieran compartir sus datos era fundamental. Ya no sólo el poder
importarlos o exportarlos
entre los distintos SGBD, sino poder acceder a ellos, es decir utilizar un SGBD para
acceder a los datos que
gestionaba otro SGBD. Como esta problemática era mayor cuando se combinaban
sistemas centrales con
personales, aparecieron protocolos para la conectividad entre bases de datos. El estándar
más utilizado es el
ODBC (Open Database Connectivity) de Microsoft que sirve tanto para conectar bases
de datos como para que
las aplicaciones puedan acceder a diferentes bases de datos. Aparece el concepto de
“fuente de datos”, en el que
incluso el SGBD que lo gestiona puede pasar desapercibido.
El ODBC (http://www.microsoft.com/data/odbc/) es una API (Applications
Programming Interface) para
enlazar aplicaciones con una base de datos. Se diseñó por Microsoft como un modo de
que los programas se
conectaran a una base de datos sin tener que usar los comandos y características
específicos del SGBD. Los
comandos ODBC se utilizan en los programas y luego se traducen en los comandos
específicos por la interfaz
ODBC que hay sobre el SGBD. Esto permite además que los programas se puedan
portar de SGBD a SGBD
31
con un mínimo de cambios de código, ya que permite al usuario indicar qué fuente de
datos ODBC está
utilizando, lo que permite un cambio y adaptación a otros SGBD, especialmente los
nuevos SGBD y versiones
que van apareciendo.
Existen muchas otras características desarrolladas durante los ochenta y los noventa que
se asocian con el
modelo relacional, auqneu son tecnologías en su mayor parte independientes del modlo.
Quizás desde un punto
de vista más teórico, el modelo relacional sí que ha generado muchos avances propios a
él, en general ligados a la
visión de una base de datos relacional como una teoría lógica, lo que ha permitido
portar los avances de la
programación lógica, como comentaremos.
Para una referencia actualizada y rigurosa sobre el modelo relacional se recomienda
[Levene & Loizou 1999].
9
1.1.3. Bases de Datos Orientadas a Objetos
Alrededor de la mitad de los ochenta, algunas aplicaciones exigían mayor expresividad
en los datos con los que
trabajaban. Por ejemplo, las bases de datos médicas, las bases de datos multimedia y
algunas bases de datos
científicas requerían mayor flexibilidad en la manera en la que los datos se
representaban y eran accedidos.
Coincidiendo con la entrada de los lenguajes orientados a objetos como Smalltalk o C+
+ en el ámbito
industrial, los investigadores se plantearon transportar estas ideas a las bases de datos y
permitir que el tipo de
datos marcara cómo se representaba y se manipulaba dependiendo de los métodos que
se definían para dicho
tipo o clase.
La idea de una base de datos orientada a objetos se articuló por primera vez por
[Copeland & Maier 1984],
con el sistema prototipo GemStone. Uno de los sistemas más famosos de los finales de
los ochenta y principios
de los noventa fue el sistema ObjectStore [Lamb et al. 1991]. Al principio de los
noventa, los primeros Sistemas
de Gestión de Bases de Datos Orientados a Objetos (SGBDOO, o simplemente,
SGBDO) empezaron a
aparecer en el mercado, a partir de compañías como Objectivity.
En este modelo la información sobre una entidad se almacena como un objeto
persistente y no como una fila
en una tabla. Esto, en principio, lo hace más eficiente en términos de requerimientos de
espacio y asegura que los
usuarios puedan manipular los datos sólo de las maneras en las que el programador haya
especificado. También
es más eficiente en el uso de espacio de disco requerido para las consultas, ya que en
vez de almacenar la
32
consulta, simplemente se construye una serie de índices (punteros) a los objetos

seleccionados. A esto hay que
sumar las ventajas derivadas del modelo orientado a objetos, ya explotadas en sus
lenguajes de programación, la
mayor expresividad y su adecuación para almacenar muchos tipos de datos diferentes.
Alguien podría pensar, por tanto, que las bases de datos orientadas a objetos deberían de
haber superado en la
práctica a las relacionales. De hecho, a veces se denominan postrelacionales. No
obstante, después de más 15
años, el mercado de las bases de datos orientadas a objetos no supone más de un 5% del
mercado de las
relacionales
La situación no ha variado significativamente en los últimos años, y, en el ejercicio
2001, de los 8.844 millones de
dólares de ingresos por nuevas licencias, 7.107 millones de dólares correspondieron a
sistemas relacionales. Esto
supone un 80,4% de los nuevos sistemas, con lo que no parece haber ninguna señal clara
de que la situación vaya a
cambiar en el futuro [Graham 2002]. Más aún si tenemos en cuenta que los mercados de
los SGBD prerelacionales
y objetuales tuvieron un incremento negativo en 2000, mientras que los relacionales
crecieron un
15% [IDG 2001] [SMITT 2002].
Hay varias razones para explicar este hecho. En primer lugar, las bases de datos
objetuales acarrean consigo
algunas de las propiedades no deseables de los modelos pre-relacionales. El
programador tiene que tener mucha
información sobre la estructura de los datos. Si se conocen las propiedades de los
objetos, la consulta es rápida y
simple. Pero la realidad es que en muchos casos se desconocen las identidades de los
objetos. Lo que preocupa o
interesa es almacenar los atributos de los objetos y relacionar los valores de estos
atributos, aspecto en el que el
modelo relacional es más sencillo.
En segundo lugar, el hecho de que las organizaciones sean capaces de alterar los
métodos de bajo nivel
utilizados en los SGBDO, hace que sea más difícil para terceros el hacer productos
añadidos. Mientras que las
bases de datos relacionales se pueden beneficiar del software realizado por otras firmas,
los usuarios de SGBDO
tienen que producir el software en casa para adaptarse a sus propias particularidades,
parte de ellas incorporadas
al comportamiento de los objetos.
En tercer lugar y quizás más importante es el hecho que las organizaciones tiendan a ser
conservadoras en
relación con las bases de datos, uno de sus activos más valiosos. Muchas organizaciones
aunque utilizan lenguajes
orientados a objetos como el C++ para las aplicaciones microinformáticas o
aplicaciones específicas, desconfían
33
de los lenguajes orientados a objetos en general por no considerarlos suficientemente

estables para trabajar con
información crucial para la organización. Mito o realidad, el hecho es que no acaban de
decidirse por embarcarse
en un SGBDO y siguen aferrados al SQL para realizar sus informes y al SQL embebido
para interrelacionar las
aplicaciones con el SGBD, manteniendo una separación que consideran imprescindible.
Del mismo modo que evolucionaba el modelo objetual para el nivel lógico y el nivel
físico, debían también
evolucionar o desarrollarse nuevos modelos conceptuales y metodologías orientadas a
objetos. El modelo
entidad relación (extendido) se mostró insuficiente para la etapa de diseño conceptual de
bases de datos
orientadas a objetos. Para ello se importaron o adaptaron lenguajes de modelado e
incluso gran parte de las
metodologías utilizadas en ingeniería del software orientada a objetos. Por ejemplo, la
metodología Object Modeling
Technique (OMT) desarrollada a principios de los noventa en General Electric
[Rumbaugh et al. 1996], la
11
metodología (análisis y diseño O-O) de Booch [Booch 1991, 1994] o posteriormente el
lenguaje de modelado
‘unificado’ UML [Booch et al. 1997] [Booch et al. 1999], aunque pensadas para el
desarrollo de software
orientado a objetos, se han ido adaptando o importando al campo de las bases de datos
como herramienta de
modelado conceptual de bases de datos orientadas a objetos.
El estándar UML y su integración en metodologías de diseño y modelado de bases de
datos ha supuesto
quizás el mayor gran impulso a este modelo de datos desde su introducción en los
ochenta. El cuerpo principal
del lenguaje de modelado unificado UML se desarrolló principalmente a principio de
los noventa, por un grupo
de ‘gurús’ de la ingeniería de software orientada a objetos, especialmente los ahora
llamados “tres amigos”:
Booch, Jacobson y Rumbaugh. Cuestiones comerciales aparte, el UML fue aceptado
como estándar por el
ODMG (del que hablaremos más abajo) y el hecho de haberse estandarizado un
lenguaje de modelado orientado
a objetos y que éste esté basado en lo “mejor” de otras metodologías anteriores, hace
que la adaptación de
profesionales y su movilidad entre distintas organizaciones sea más sencilla.
UML puede utilizarse para cualquier sistema orientado a objetos, lo que le hace también
apropiado para el
diseño de bases de datos orientadas a objetos. Especialmente lo hace apropiado para que
los especialistas en
bases de datos y analistas especifiquen lo que quieren que los programadores realicen,
en términos del SGBDO y
34
de los programas que interaccionan con él. Finalmente hay que recordar que UML es
sólo un lenguaje y no una
metodología, con lo que también es posible utilizar UML como notación para expresar
el modelo entidadrelación
(véase p.ej. [Muller 1999] o [Connolly & Begg 2000]).
El ODMG (Object Database Management Group) es un grupo de vendedores y
usuarios de bases de datos que
desarrollan estándares para los SGBDO (www.odmg.org). El primer documento fue el
ODMG 1.0 in 1993, que
incluía el OQL (Object Query Language), un lenguaje de consultas orientado a objetos
muy inspirado en el SQL.
Aunque durante los principios de los noventa tuvo bastante fuerza, hoy su importancia
es menor debido a que
SQL3 incluye muchas características orientadas a objetos, como veremos a
continuación.
Además del OQL, el ODMG v.3.0 incluye un modelo de objetos estándar y enlaces para
los tres lenguajes
orientados a objetos más populares: C++, Smalltalk y Java. La especificación del
ODMG 3.0 se puede encontrar
en (www.odmg.org), en [ODMG 2000] o en [Cattell & Bary 2000]. Para una
información más general sobre las
bases de datos orientadas a objetos, se recomienda [Eaglestone 2000].
1.1.4. Bases de Datos Relacionales Orientadas a Objetos (u Objeto-Relacionales)
El modelo objeto-relacional es un desarrollo más reciente y parece haber tenido bastante
efecto. No es una
tecnología en sí, sino una aglutinación de los modelos relacional y orientado a objetos.
De hecho, algunas
extensiones objetuales a los sistemas relacionales se pueden datar en los principios de
los ochenta [Zaniolo 1983].
Como hemos dicho antes, existía la necesidad imperiosa de la industria y de sus clientes
de tratar con nuevos
tipos de datos: audio, imágenes y vídeo, además de tipos definidos por el usuario con
sus propias propiedades.
Por otra parte, hemos visto que las organizaciones eran reticentes a migrar de un
SGBDR a un SGBDO por
diversos motivos.
Además, el mantenimiento de los SGBDR empezaba a crear desajustes con un cada día
más generalizado uso
de los lenguajes orientados a objetos. Los programadores en estos lenguajes tenían que
realizar una serie de pasos
de traducción de la estructura objetual del programa y de los datos en memoria principal
a la estructura relacional
de los datos.
Aquí es donde el modelo objeto-relacional puede demostrar su valor. El modelo objeto-
relacional se define
como una extensión objetual del modelo relacional, permitiendo la definición de nuevos
tipos y de relaciones de
herencia, entre otras cosas [Stonebraker et al. 1998] [Maro-Saracco 1998]. Permite a las
organizaciones continuar
35
usando sus sistemas existentes y sus datos, sin realizar prácticamente cambios y les
permiten empezar a utilizar
gradualmente características orientadas a objetos, especialmente si se hace en
conjunción con aplicaciones
desarrolladas en entornos también orientados a objetos.
Uno de los ejemplos de este mestizaje es, por ejemplo, JDBC (Java DataBase
Connectivity). Aunque pensado
para interrelacionar bases de datos relacionales con Java, va incorporando algunos
detalles objeto-relacionales.
De una manera más precisa, JDBC es una API (Applications Programming Interface)
desarrollada por Sun
Microsystems (http://java.sun.com/products/jdbc/index.html) para conectar Java con las
bases de datos, con
una filosofía inspirada en ODBC. De hecho es usual conectar un programa Java con una
base de datos
directamente o a través de ODBC, dependiendo de si el fabricante de la base de datos ha
creado los drivers
necesarios para Java.
12
Otro ejemplo de mestizaje a un nivel diferente es el SQL3 [ANSI/ISO/IEC 1999]. SQL3
es la nueva versión
desarrollada por los comités ANSI X3H2 e ISO DBL para extender SQL2 con el
tratamiento de datos
orientados a objetos (entre otras cosas). Hablamos de mestizaje porque esta extensión se
ha hecho de tal manera
que el SQL3 es compatible hacia adelante con el SQL-2.
Las facilidades orientadas a objetos del SQL3 se centran en extensiones de los tipos y
las tablas en SQL. Las
partes del SQL3 que proporcionan la base para trabajar con estructuras orientadas a
objetos son: tipos definidos
por el usuario (user-defined types, UDTs), constructores de tipo para tipos de fila y
tipos referencia, tipos
constructores para colecciones (conjuntos, listas, ...) y funciones y procedimientos
definidos por el usuario.
Una de las ideas básicas detrás de estas extensiones es que, además de los tipos
predefinidos (built-in) de
SQL, el usuario puede definir otros tipos que pueden ser utilizados después como los
tipos predefinidos.
Siguiendo el paradigma orientado a objetos, una definición de UDT encapsula los
atributos y las operaciones en
una única entidad o clase, que en SQL3 se llama tipo. En concreto en SQL3 se define un
UDT declarando los
atributos que almacenan el valor y estado del UDT, definiendo las operaciones de
igualdad y de orden para el
tipo, y, finalmente, definiendo las operaciones que determinan el comportamiento
específico del UDT. Las
operaciones (lo que en el paradigma orientado a objetos se suelen llamar métodos) se
implementan mediante
36
procedimientos llamados rutinas. Las operaciones pueden incluir comandos de

manipulación SQL embebidas
(SELECT, INSERT, UPDATE, DELETE).
El SQL3 también está provisto de herencia y delegación. Mediante la especificación de
“UNDER <nombre
del UDT >” en la parte de subtipo de una definición UDT, se puede definir un UDT
como un subtipo (lo que se
conoce normalmente como especialización, clase derivada o subclase) de un UDT
existente. Un subtipo hereda
todos los atributos y el comportamiento de sus supertipos y se pueden extender con más
atributos y variar su
comportamiento. Una instancia de un subtipo se puede utilizar en cualquier lugar donde
una de las instancias de
sus supertipos se pueda utilizar. De momento, SQ3 no soporta la herencia múltiple, con
lo que un UDT puede
tener como mucho un supertipo.
A pesar de todas estas extensiones, la estructura principal de representación lógica del
SQL3 sigue siendo la
tabla, con lo que el modelo subyacente del SQL3 se puede considerar objeto-relacional.
1.1.5. Bases de Datos Paralelas y Distribuidas
Las bases de datos paralelas se empezaron a desarrollar alrededor de 1980,
especialmente con el proyecto Gamma
[DeWitt et al. 1990], un sistema de base de datos sobre una serie de procesadores de
propósito general
funcionando en paralelo. Este sistema es en el que se inspiran la mayoría de sistemas
paralelos de IBM, Tandem,
Oracle, Informix, Sybase y AT&T. Además, el uso de sistemas paralelos para la minería
de datos es uno de los
campos de investigación más activos actualmente.
Los sistemas de bases de datos paralelos, como casi toda la tecnología paralela, fue
acuñada como la
tecnología del futuro en cuanto a altas prestaciones. Hoy en día la postura es más
realista y se reconoce su uso en
sistemas de muy altas prestaciones, aunque para sistemas de uso corriente, incluso
grandes empresas, su uso es
más limitado.
No obstante, por muy paralelo que fuera el sistema, todo ordenador tiene su límite.
Aunque la capacidad de
proceso aumentara, existían limitaciones en la cantidad de memoria que el sistema
direccionaba, el número de
discos duros que podían conectarse a un mismo procesador y el número de procesadores
que podían correr en
paralelo. En la práctica, esto significa que, a medida que la cantidad de información de
una gran base de datos
aumenta, un único sistema, aunque sea paralelo, deja de poder dar abasto con toda la
información que tiene que
almacenarse, ordenarse y consultarse.
Aunque es posible comprar sistemas cada día más grandes y rápidos, a veces no es
económico sustituir el
37
hardware cada pocos años o incluso meses, periodo en el que se suele duplicar la
información de una
organización. En cambio, es mucho más realista tener varios servidores de bases de
datos e ir añadiendo a
medida que la organización necesita más capacidad. Esto se debe hacer de manera que
los usuarios crean que
siguen trabajando con un único sistema, el sistema integrado de la organización.
Mediante esta filosofía, la
organización tiene más flexibilidad en sus ampliaciones, se realizan de una manera
menos traumática y con
ordenadores de talla media, que suelen ser mucho más baratos que uno grande
equivalente en potencia.
13
Este concepto lleva al paradigma de las bases de datos distribuidas3, y tienen las
características comunes de
que los datos se almacenan en dos o más ordenadores, llamados nodos, y que estos
nodos están conectados en
una red. Hoy en día, con el aumento de la descentralización, debido al abaratamiento,
ancho de banda y
flexibilidad de las redes de computadores, ha hecho que el uso de las bases de datos
distribuidas haya aumentado
considerablemente.
Si hablamos de un único sistema de gestión de bases de datos que actúa sobre distintos
ordenadores
distribuidos y gestionando la misma base de datos, hablamos propiamente de bases de
datos distribuidas. En el
caso que cada sistema esté formado por varios SGBD, se suele hablar de Sistemas de
Múltiples Bases de Datos, que
pueden estar fuertemente acoplados o débilmente acoplados, llamándose estos últimos
sistemas interoperantes
de bases de datos [Litwin & Chien 1994].
Sin entrar en demasiadas distinciones terminológicas entre los sistemas de bases de
datos distribuidos y los
sistemas de múltiples bases de datos, o si los datos pueden o no estar replicados, el
punto fundamental de todos
estos sistemas es que los usuarios no deben percatarse de esta dispersión espacial de los
datos, es decir, los
usuarios deben percibir lo mismo que si trabajaran con un único sistema centralizado.
En general, se suele realizar la siguiente clasificación habitual entre sistemas de bases
de datos homogéneos y
heterogéneos.
Las bases de datos distribuidas homogéneas usan el mismo software de SGBD y
tienen las mismas
aplicaciones en cada nodo. Tienen un esquema común y pueden tener grados diversos
de autonomía
local. Pueden estar basadas en cualquier SGBD que soporte estas características, pero
no puede haber
más de un SGBD en el sistema. La autonomía local especifica cómo el sistema funciona
desde la
38
perspectiva de los usuarios y programadores. Por ejemplo, podemos tener un sistema

con poca o sin
autonomía local, donde todas las peticiones se envían a un nodo central, llamado
gateway. Desde aquí se
asigna al nodo que contiene esa información o aplicación requerida. Esto es lo típico
que se ve con los
mirrors de sitios web muy populares a los cuales una página central deriva las
peticiones de sus usuarios
dependiendo de su origen geográfico.
En el otro lado de la escala, se encuentran las bases de datos heterogéneas con un alto
grado de
autonomía local. Cada nodo en el sistema tiene sus propios usuarios, aplicaciones y
datos locales y es el
sistema el que trata con ellos directamente y sólo conecta con otros nodos en busca de
información que
no tiene. Este tipo de base de datos se suele llamar sistema federado o federación. Se ha
hecho cada día más
popular en las organizaciones, tanto por su escalabilidad, su capacidad de mezclar
distintos paquetes
software y su reducido coste al añadir nuevos nodos cuando es necesario. A diferencia
de los sistemas
homogéneos, los sistemas heterogéneos pueden incluir diferentes SGBD en los nodos.
Esto los hace
atractivos en grandes corporaciones, ya que pueden mantener sus sistemas heredados
antiguos (legacy
systems) junto con los nuevos sistemas.
Uno de los primeros sistemas distribuidos fue R*, desarrollado en IBM [Williams et al.
1998] a principios de los
ochenta. Últimamente el área de las bases de datos distribuidas está cada vez más en
relación con Internet y la
tecnología web, hablándose de bases de datos distribuidas de área global [Stonebraker et
al. 1996]. Una fuente
actual sobre sistemas de bases de datos distribuidas se puede encontrar en [Ozsu &
Valduriez 1999]
1.1.6. Bases de Datos Multimedia
Las bases de datos multimedia almacenan una gran variedad de tipos de datos. Estos
tipos incluyen texto,
imágenes, audio y vídeo. Hasta hace unos años estas bases de datos eran difíciles de
implementar, debido al
tamaño de los objetos y la complejidad de los datos. El añadir metadatos a los ficheros
multimedia (p.ej. el
formato WAV) resolvía parcialmente el problema. Esta cabecera incluye datos del
formato, el creador, el
contenido, la longitud del stream de datos, etc. El problema es que está información no
suele estar indizada
conveniente y no se puede utilizar para realizar consultas.
Imaginemos una base de datos que contiene clases grabadas en vídeo. La
metainformación que nos puede
39
interesar de cada vídeo puede ser: compañía/universidad donde se dio la clase, quién la
dio, cuándo se dio, de
qué va, cuánto duró, etc. Esta información es la que se utilizará cuando los usuarios
busquen clases en la base de
datos.
3 Debido al avance en las redes de computadores la división entre bases de datos
paralelas y bases de datos distribuidas es cada día más
sutil, y existen muchos sistemas híbridos.
14
Hay dos métodos principales para incluir metadatos en una base de datos multimedia:
mediante análisis
automático o mediante análisis manual [Chorafas 1994]:
A  unque el análisis manual es más efectivo, porque permite anotar aquellas
características del objeto
multimedia que son importantes, requiere mucho tiempo y por tanto es muy costoso.
Además es difícil
conseguir homogeneidad en los criterios que se utilizan para agregar estos metadatos.
El análisis automático es mucho más rápido, pero las técnicas todavía son limitadas
en algunos casos
(especialmente en imagen y sonido). Su mayor ventaja es que proporciona una
descripción consistente
de los datos y no se ve afectada por estilos individuales.
Si hace pocos años, las bases de datos multimedia no eran asequibles para los usuarios
de ordenadores
personales, el abaratamiento de discos con gran capacidad de almacenamiento, hace que
cualquier ordenador
personal pueda contener una biblioteca de imágenes y piezas musicales, y en breve, de
películas. Otro problema
es el uso de estas bases de datos para distribución por Internet (especialmente VoD,
Video on Demand), para el
cual el ancho de banda todavía tiene que crecer enormemente.
Una referencia más amplia y actualizada del área de las bases de datos multimedia se
puede encontrar en
[Subrahmanian 1998] o [Furht & Marques 2000].
1.1.7. Almacenes de Datos
La mayoría de decisiones de empresas, organizaciones e instituciones se basan en
información de experiencias
pasadas. Generalmente, la información que se quiere investigar sobre un cierto dominio
de la organización se
encuentra en bases de datos y otras fuentes muy diversas, tanto internas como externas.
Muchas de estas fuentes son las que se utilizan para el trabajo diario. Tradicionalmente
el análisis para la toma
de decisiones se realizaba sobre estas mismas bases de datos de trabajo o bases de datos
transaccionales. La
situación era la siguiente.
Se mantiene el trabajo transaccional diario de los sistemas de información originales
(conocido como
OLTP, On-Line Transactional Processing).
40
Se hace análisis de los datos en tiempo real sobre la misma base de datos (conocido
como OLAP, On-
Line Analytical Processing),
Esta perspectiva provoca algunos problemas. En primer lugar, disturba el trabajo
transaccional diario de los
sistemas de información originales, ya que se realizan consultas muy pesadas (“killer
queries”). A veces, la
perturbación es tal que estas consultas para generar informes se deben hacer por la
noche o en fines de semana.
En segundo lugar, la base de datos está diseñada para el trabajo transaccional, no para el
análisis de los datos.
Esto hace que el análisis sea lento, con lo que no podemos hablar de OLAP, sino
simplemente de AP.
Para poder operar eficientemente con esos datos, y gracias a que los costes de
almacenamiento masivo y
conectividad se han reducido drásticamente en los últimos años, parece razonable
recoger (copiar) los datos en
un sistema unificado.
A partir de aquí nacen los almacenes de datos (data-warehouses) y toda su tecnología
asociada (data-warehousing).
Los almacenes de datos facilitan el análisis de los datos en tiempo real (OLAP) y no
disturban el OLTP de las
bases de datos originales. El hecho de separar los datos a analizar con respecto a sus
fuentes transaccionales (se
copia/almacena toda la información histórica) requiere una tecnología sobre cómo
organizarlos y sobretodo
cómo tenerlos actualizados (cargas periódicas) respecto a los datos originales.
Especialmente, un aspecto muy importante es la organización de la información
copiada. El esquema del
almacén de datos no suele coincidir con el esquema transaccional. De hecho, los
esquemas de almacenes de
datos suelen desnormalizarse, con el objetivo de acelerar ciertas consultas analíticas. En
general, se distinguen
dos tipos de almacenes de datos:
ROLAP (Relational OLAP): el almacén de datos es relacional.
M  OLAP (Multidimensional OLAP): el almacén de datos es una matriz
multidimensional.
El objetivo es que la información esté estructurada de manera que facilite la tarea de dos
tipologías de usuarios:
‘picapedreros’ (o ‘granjeros’): se dedican fundamentalmente a realizar informes
periódicos, ver la
evolución de determinados parámetros, controlar valores anómalos, etc.
15
‘exploradores’: encargados de encontrar nuevos patrones significativos utilizando
técnicas de minería de
datos, que comentaremos más adelante.
En definitiva, los almacenes de datos tienen un fin bien diferente de los sistemas
transaccionales y por tanto
41
tienen una tecnología y problemática diferentes. Las mayores diferencias entre los
sistemas transaccionales y los
almacenes de datos son las siguientes:
SISTEMA TRANSACCIONAL ALMACÉN DE DATOS
Propósito Operaciones diarias Recuperación de información histórica y análisis
SGBD más usuales SGBDR SGBDR o SGBDM
Estructura de los datos Normalizado Multi-dimensional
Tipo de datos Datos para el funcionamiento de la organización Datos que es interesante
analizar
Condición de los datos Cambiantes, incompletos Históricos, descriptivos.
La organización matricial, también conocida como Data Cubes [Gray et al. 1997], está
especialmente diseñada
para los almacenes de datos con la ventaja de optimizar y unificar los operadores de
agregación tradicionales:
group by y subtotales. En esta organización, cada atributo relevante se establece en una
dimensión, que se puede
agregar o desagregar. La base de datos está completamente desnormalizada. Existe una
terminología propia para
estos operadores: roll-up (consolidación o sumarización), drill-down (detalle), slicing
and dicing (combinaciones
cruzadas).
En el caso de los almacenes de datos sobre sistemas relacionales, la estructura también
está muy
desnormalizada, centrándose alrededor de tablas de hechos, de las que derivan otras
tablas detalle, según varias
dimensiones. De ahí, el nombre que se le dan a estas estructuras: estrella simple o
estrella jerárquica (copo de
nieve). Esta estructura también permite la sumarización, la visualización y la
navegación según las dimensiones de
la estrella.
No es de extrañar que las consultas realizadas de tipo OLAP al almacén de datos sean
complejas. Por
ejemplo, elegir los cinco clientes con mayor volumen de compras no es una consulta
trivial en SQL. Si además se
requiere esta información por zonas geográficas y se quiere explotar la estructura del
esquema del almacén de
datos, la consulta puede complicarse bastante. Si además, se requiere que sea eficiente,
es posible que se deban
utilizar vistas parciales y otros mecanismos para obtener los informes más rápidamente.
Finalmente, si hace unos años los almacenes de datos se limitaban a recoger
información interna de la
organización, con el crecimiento de las redes y de la información disponible, los
almacenes de datos también
recogen información externa o del contexto de la organización, como por ejemplo:
D  emografías (censo), páginas amarillas, psicografías, gráficos web, información de
otras organizaciones.
D  atos compartidos en una industria o área de negocio, organizaciones y colegios
profesionales,
catálogos, etc.
42
D  atos resumidos de áreas geográficas, distribución de la competencia, evolución de la

economía,
información de calendarios y climatológicas, programaciones televisivas-deportivas,
catástrofes, etc.
Bases de datos externas compradas a otras compañías.
En resumen, aunque los almacenes de datos es una área de gran interés actualmente, se
puede considerar como
una rama establecida de la tecnología de las bases de datos, especialmente vigente en
grandes organizaciones e
industrias de la distribución, y suele funcionar en relación con los sistemas de toma de
decisión (DSS, Decision
Support System) y los Sistemas de Información Ejecutiva (EIS, Executive Information
System). Es relevante
constatar que el uso de los almacenes de datos es el original de los sistemas de
información: recopilar datos para
analizarlos y tomar decisiones a partir de este análisis.
1.2. Situación Actual
Hoy en día se puede observar en perspectiva el cambio de los sistemas de gestión de
bases de datos. Inicialmente
se trataba de software muy caro, sobre grandes y costosos ordenadores. Actualmente
existen sistemas de gestión
de bases de datos para ordenadores personales, como hemos visto, siendo muchos de
ellos económicos o incluso
gratuitos. Esta tendencia al abaratamiento y disminución en tamaño físico de los
sistemas contrasta con la cada
16
vez mayor capacidad, potencia y prestaciones de los SGBD. Sólo median menos de 30
años desde el primer
sistema de gestión relacional, el “System R”, cuyo primer prototipo podía almacenar
8MB de datos hasta los
terabytes usuales hoy en día en cualquier organización discreta.
Algunos proyectos en desarrollo actualmente parecían impensables hace sólo unos años.
Por ejemplo, el
proyecto RD45 (http://wwwinfo.cern.ch/asd/cernlib/rd45/index.html), es uno de los
proyectos más
ambiciosos que se están desarrollando en el CERN con el objetivo de crear una base de
datos distribuida capaz
de almacenar en 2005 un Exabyte (1 Exabyte = 1.024 Petabytes 1  1 018 bytes).
1.2.1. Bases de Datos y la Web
Quizás uno de los aspectos que se han notado más recientemente en el campo de las
bases de datos (como en
casi cualquier otro campo de la informática) es el crecimiento vertiginoso de Internet y
del WWW. La conexión
de las bases de datos con la web ha ido progresando de una interrelación realizada a
través de herramientas ad
hoc hasta la situación actual, en la que prácticamente todo SGBD proporciona un
módulo o toda una serie de
herramientas para publicar la información de la base de datos en la red, siendo accesible
desde cualquier punto,
43
utilizando un navegador [Feiler 1999]. Con el uso de Internet y de las intranets, la

disponibilidad de los datos de
la organización se ha hecho prácticamente ubicua, sin necesidad para las operaciones
más comunes y sencillas del
desarrollo de ninguna aplicación cliente, exceptuando el navegador. Los catálogos,
inventarios, stocks,
indicadores, etc. de cualquier empresa o comercio están disponibles a cualquier usuario
en cualquier momento,
con sus respectivos permisos y de manera concurrente.
Es de destacar que la tecnología web ha hecho evolucionar la tecnología cliente/servidor
de dos capas a una
tecnología comúnmente estructura en tres capas (1. cliente / 2. servidor de aplicaciones /
3. servidor de datos),
aunque la mayoría de los aspectos del paradigma cliente/servidor son aplicables a la
web.
En definitiva, con el advenimiento de la web, la gestión de datos se ha ramificado para
tratar con la variedad
de información disponible en el WWW. La mayoría de accesos web de hoy en día
disparan alguna forma de
generación de contenido de una base de datos, mientras que el comercio electrónico está
destinado a hacer un
uso intensivo de las aplicaciones basadas en un SGBD.
En consecuencia de todo esto, el interés de la comunidad científica y de las empresas
del sector se centra en la
revisión o extensión de modelos de datos y de lenguajes de consulta, la integración de
datos tan diversos, la
reconcepción de los índices, las transacciones y el procesamiento de consultas, con el
objetivo de adaptarse a las
características y la escala de los datos en la web. Se han identificado nuevos problemas,
como saber tratar con el
solapamiento de información y la detección de copia, así como cuestiones específicas de
la web como
herramienta de publicación. También hay un gran interés por el lenguaje XML, del cual
hablaremos más
adelante, y por la extracción y recogida de información de la web, su almacenamiento
en un almacén de datos y
su prospección.
1.2.2. Situación del Mercado de los SGBD y Estandarización
La mayoría de sistemas de gestión de bases de datos de hoy en día son relacionales,
como se ha visto
anteriormente. Además, el mercado está muy concentrado por tres compañías: Oracle,
IBM y Microsoft.
Según un estudio de Dataquest (www.dataquest.com), ahora llamado Gartner Group
(www.gartner.com),
IBM y Oracle han estado codo con codo durante los últimos años con cerca del 30% de
ingresos por ventas de
nuevas licencias en el mercado de SGBD cada uno [Graham 2002].
PORCENTAJE DEL MERCADO DE SGBD
Compañía 1998 1999 2000 2001
44
Oracle 30.7 31.1 34.1 32.0

IBM 30.0 29.9 30.3 31.7
Microsoft 10.7 13.1 14.0 16.3
Informix 4.8 4.3 3.3 3.0
Sybase 3.6 3.3 3.2 2.6
Otros 20.2 18.3 15.0 14.4
TOTAL 100.0 100.0 100.0 100.0
No obstante, hay que destacar que la distribución de estos porcentajes no es uniforme en
la gama de
aplicaciones. Por ejemplo, IBM sigue siendo líder en el área de los mainframes,
especialmente con su línea
17
OS/390 y AS/400. Por el contrario, si quitamos los mainframes, Oracle lidera el
mercado con una gran ventaja.
Según un último estudio del Gartner Group, la situación en mayo de 2002 sigue siendo
hegemónica para Oracle,
IBM y Microsoft [Nicolett 2002]. La gama de SGBD de Informix se ha venido a menos
en cuota de mercado.
De hecho en 2001, fue absorbida por IBM, para que ésta aumentara su cuota en las
plataformas Unix y Windows
[Burton 2001]. Además, si sumamos los SGBD de IBM actuales, incluyendo los
absorbidos de Informix,
tenemos la mayor cuota, un 34,7% en 2001. No obstante, a medio plazo ocurrirá que
muchos de los usuarios de
Informix migren a DB2. Más aún si tenemos en cuenta que IBM ha intentado aumentar
su presencia mediante la
potenciación de las versiones UNIX y NT de su DB2, que han crecido
considerablemente en los últimos años.
Si atendemos al porcentaje de mercado de los sistemas de gestión de bases de datos
relacionales, podemos
observar todavía una mayor concentración:
PORCENTAJE DEL MERCADO DE SGBD RELACIONALES
Compañía 2000 2001
Oracle 42.5 39.8
IBM 29.5 30.7
Microsoft 11.6 14.4
Informix 3.1 3.3
Sybase 4.0 3.3
Otros 9.3 8.5
TOTAL 100.0 100.0
Considerando sólo los sistemas relacionales, mientras sobre sistemas operativos
Windows, Microsoft es el líder
en 2001 con el 39.9% del mercado (respecto a un 34.0% de Oracle), en sistemas
operativos UNIX, Oracle es
claramente predominante, con un 63.3%.
La excesiva concentración del mercado plantea serias dudas sobre la implantación del
nuevo SQL3, porque
las compañías no tienen excesivo interés por hacer su SQL fácilmente portable a otros
sistemas, con el riesgo de
45
poder perder clientes. No obstante, parte del nuevo SQL3 ha ido recogiendo los
estándares ‘de facto’ que estas
mismas compañías han ido introduciendo, como el soporte para los objetos grandes
incorporados (BLOB y
LOB) o los triggers, ambas extensiones presentes en el sistema emblema de Oracle, por
ejemplo.
La incorporación de estas y otras extensiones de SQL3 (especialmente las orientadas a
objeto y las consultas
recursivas) a la mayoría de sistemas será un proceso lento. De hecho, hoy en día, ningún
sistema es todavía
completamente compatible con todas las características de SQL2. El tema parece estar
mucho peor para
incorporar las instrucciones de control y de definición de rutinas del SQL3 (CASE, IF,
THEN, ELSE, ELSEIF,
LOOP, WHILE, REPEAT, FOR, ITERATE, LEAVE), ya que la mayoría de sistemas
incorporan su propia
sintaxis para los procedimientos, arrastrada de sus lenguajes 4GL.
1.2.3. Diseño y Desarrollo de Bases de Datos
No sólo la tecnología es suficiente para que los sistemas de información de hoy en día
funcionen mejor que los
de hace unos años. Asociadas a las tecnologías suelen asociarse unas metodologías, que
intentan sacar provecho
de las primeras. Utilizar un sistema de gestión de bases de datos relacional no es por sí
solo una garantía de que el
sistema de información que se construya utilizándolo vaya a funcionar bien. De hecho,
dada la simplicidad del
modelo relacional y de algunos SGBR para ordenadores personales, existen verdaderas
plepas realizadas por no
profesionales funcionando en pequeñas y grandes organizaciones, causando casi más
problemas de los que
resuelven.
A continuación se realiza un rápido repaso (y bastante simplista) de los pasos usuales
que se suelen utilizar a
la hora de diseñar una base de datos. Generalmente se habla de las siguientes etapas:
planificación-definición del
sistema, análisis de requerimientos, diseño conceptual, elección de SGBD/modelo,
diseño lógico, diseño físico,
implementación y ajuste de rendimiento. Para las primeras tres etapas los pasos suelen
ser bastante coincidentes
(aunque con herramientas diferentes) para las bases de datos relacionales y las
objetuales, notándose más la
diferencia en las cuatro últimas etapas.
1. Planificación y definición del sistema: aunque a veces estas fases se engloban en la
siguiente fase de
análisis de requerimientos, consisten en determinar cuáles van a ser las fases del diseño
de la base de
datos y dar una visión global del sistema.
2. Análisis de requerimientos: En esta fase de un proyecto, el mayor objetivo es
proporcionar una imagen
46
más clara del sistema de información cuyos datos se quiere informatizar. Para ello se
deben definir cuáles
18
son los componentes concretos del sistema de información (usuarios, contexto, etc.),
definir qué se
espera que el sistema haga y qué datos en concreto se requerirán para su
funcionamiento.
3. Diseño conceptual: Una vez que se tiene la especificación inicial del sistema, un
profesional (o un grupo)
experto en bases de datos o un analista puede empezar a realizar el esquema conceptual
del sistema. Éste
es una visión de alto nivel del sistema que registra qué información se va a almacenar,
qué formato va a
tener y cómo se relaciona con otra información. Este esquema conceptual también
especifica los
derechos de acceso de grupos y programas. Para las bases de datos relacionales se suele
utilizar el
modelo entidad relación para proporcionar una visión conjunta del sistema. En algunos
casos, sobretodo
si los datos son muy heterogéneos, se puede decidir realizar el modelo utilizando
lenguajes de modelado
orientados a objetos como UML.
4. Elección de SGBD: No es una fase realmente, porque este paso se suele pensar antes
del desarrollo de
una base de datos en concreto o se decide para ser utilizado con varios fines. No
obstante, si la
organización dispusiera de varios, o de ninguno, con lo que tendría que elegir, esta
elección se limita por
muchas razones: monetarias, conocimientos disponibles de los profesionales
informáticos, decisiones de
gestión y un número importante de otros factores, específicos a cada organización. De
todos los
sistemas disponibles, se intentará encontrar el sistema más apropiado para la base de
datos que se desea
diseñar. Las siguientes fases se podrán realizar ya acordes con las capacidades y
limitaciones del sistema
elegido.
5. Diseño lógico: Durante esta fase del proceso, se toma el esquema producido en el
diseño conceptual y se
convierte al modelo sobre el que trabaja el SGBD. Esta fase nos acerca ya al sistema
final, ya que se tiene
un modelo que se adapta al SGBD donde funcionará.
6. Diseño Físico: En esta fase, se centran los esfuerzos en la implementación práctica de
la base de datos.
En esta fase se incluyen las pruebas de hardware, el cálculo del nivel de estrés (carga)
que el sistema
puede aguantar. Esto es importante, especialmente si los datos van a accederse
frecuentemente y pueden
47
existir picos. Además los discos que albergan los datos más usados tienen un acceso
más regular y por
tanto aumenta su probabilidad de fallo. Este tipo de información, junto con otra
información crítica,
debe mantenerse distribuida y salvaguardada mediante el uso de mirrors o de
organizaciones de pilas de
discos. En esta fase también se estudian los índices y otras estructuras de organización
física más
apropiadas para optimizar el rendimiento.
7. Implementación: una vez realizados todos los pasos anteriores, debidamente
documentados, se puede
pasar a implementar el sistema. Los detalles de implementación dependen en gran
medida del SGBD, de
los lenguajes de programación de las aplicaciones, de una serie de estándares y
protocolos que puedan
estar utilizando tanto el SGBD como las aplicaciones y otros muchos factores. Cuanto
más detallada y
clara es la especificación inicial, más rápida será la implementación. Al contrario, si las
primeras fases se
han descuidado o han venido marcadas por las prisas, la fase de implementación se
alargará y el sistema
estará lleno de parches y de modificaciones sobre modificaciones, degradándose su
eficacia y su
seguridad. Además, las modificaciones, como en casi cualquier desarrollo de un
proyecto, son más
costosas cuanto más tarde se hagan.
8. Conversión y carga de datos y pruebas: en el caso de una migración se debe hacer una
conversión de los
datos existente en fuentes de información previas o anteriores a la base de datos que se
acaba de
implementar. Si no existe migración se deberá realizar una primera carga de datos
ficticios o reales para
realizar pruebas más completas del sistema.
9. Ajuste de rendimiento: Una vez el sistema comienza a estar operativo y se tienen
datos (aunque en esta
fase todavía pueden ser ficticios), se puede comenzar a ajustar el rendimiento, utilizando
y simulando las
cargas que se prevén en el funcionamiento normal del sistema.
Una vez que la base de datos adquiere un volumen de datos real importante (ya sea por
migración de otra base de
datos, la cual se debería diseñar cuidadosamente, o por inserción de nuevos datos), es
cuando realmente se
empieza a evaluar si las decisiones de diseño fueron correctas. Evidentemente, casi
todos los sistemas se revisan
y se amplían, pero estas modificaciones deben seguir los pasos anteriores a partir de
aquél que haya motivado el
cambio o extensión (requerimientos, conceptual, lógico, físico o de rendimiento). En
estos cambios hay que
48
tener en cuenta los costes a medio plazo, ya que pequeños retoques baratos a corto plazo
pueden no resolver el
problema a medio y largo plazo.
19
1.2.4. Aplicaciones
Hoy en día, la existencia de un sistema de información organizacional sin un SGBD
detrás es un error, ya no sólo
tecnológico sino económico. Incluso áreas que tenían unas particularidades muy
especiales para las cuales hace
unos años se dudaba del uso de SGBD, hoy han desarrollado una tecnología particular,
o los SGBD generales
son capaces de soportarlas sin demasiados problemas. De este modo, el rango de
aplicaciones de las bases de
datos a principios de este siglo XXI se ha ampliado de una manera importante. Así, se
utilizan sistemas de
gestión de bases de datos para los sistemas de información geográfica [Burrough et al.
1998], las bases de datos
multimedia en [Furht & Marques 2000], las bases de datos médicas [Rondel et al.
1999], las bases de datos
genéticas [Bishop 1999] y otras bases de datos científicas y estadísticas.
No obstante, siguen siendo las bases de datos de gestión de empresas y organizaciones
las más importantes en
volumen y número. Además, la perspectiva de las compañías suministradoras de SGBD
tiende a proporcionar
herramientas más globales e integradoras, en las que la organización se debe dedicar a
personalizarlas para su área
de negocio. Estamos hablando de los paquetes integrados de gestión, las ERP
(Enterprise Resource Planning) y CRM
(Customer Relationship Management). Aunque estos paquetes existen desde hace una o
dos décadas y hay algunos
muy populares (Baan, Navision, SAP), los paquetes globales perfectamente integrados
con el SGBD, como el
Oracle E-Business Suite, han sido acogidos de una manera espectacular por el mercado,
con un 66% de
crecimiento en el año 2000.
A medida que las empresas despliegan más sistemas web para la interacción con los
clientes, los paquetes
CRM se hacen más importantes. Según Dataquest (ahora Gartner Group,
www.gartner.com), los paquetes CRM
alcanzaron los 19,9 billones de dólares en 2000, un incremento del 28% sobre 1999.
Además, se prevé unos
crecimientos mayores en el futuro.
1.3. Líneas de Investigación Actuales y Futuro de las Bases de Datos
Muchas de las tecnologías que aparecen como futuras en libros clásicos de bases de
datos las hemos incluido en los apartados anteriores. Las restricciones y las reglas de
actividad, la tecnología orientada a objetos en las bases de datos (especialmente en la
etapa de diseño), los datos multimedia, los almacenes de datos, la interrelación con
la web o incluso las bases de datos distribuidas, son tecnologías maduras que se utilizan
hoy en numerosas aplicaciones.
49
La tecnología de bases de datos ha ido automatizando los procesos que tienen lugar en
los sistemas de información: recopilación, almacenamiento, consulta, reacción, análisis
y toma de decisiones. El primer paso, el de recopilación de datos era antiguamente
manual; hoy en día está altamente automatizado o semiautomatizado, el SGBD se
encarga de manejar los datos hasta su lugar de almacenamiento, de manera masiva y
eficiente. La recuperación de información básica o derivada simple (agregada,
interrelacionada) experimentó su madurez a partir de los lenguajes de consulta
declarativos, como SQL. El mantenimiento de la integridad y seguridad de la
información ha sido uno de los aspectos donde el avance ha sido más significativo. Los
sistemas impiden cualquier operación que contravenga esta integridad (actuación
preventiva) y son capaces de tomar medidas compensatorias para mantenerla (actuación
curativa). Esta última ha derivado hacia la posibilidad de que los sistemas sean
reactivos, es decir, ciertos estados u operaciones de la base de datos hacen que el
sistema tome unas medidas (alertas, informes, procesos, ...) que antes habían de
dispararse manualmente. Esta función está muy automatizada gracias a la existencia de
reglas de actividad (‘disparadores’), con lo que, para muchas aplicaciones, no es
necesario el uso de controladores humanos. Respecto al análisis, los sistemas de hoy en
día permiten hacer consultas impensables hace unos años, gracias a la tecnología OLAP
y los almacenes de datos, lo que permite tener información altamente sumarizada en
tiempo real. Éste es el penúltimo paso para el uso final (y no transaccional) de la
información, tomar decisiones acerca del contexto que esa información representa. Esta
toma de decisiones empieza a semiautomatizarse, mediante la evolución de las
herramientas de generación de modelos estadísticos a los sistemas de prospección de
datos, minería de datos y simulación predictiva, que facilitan y automatizan gran parte
del proceso de toma de decisiones, cambiando la filosofía de los sistemas de toma de
decisión (DSS, decision support systems) tradicionales.
Toda esta automatización y la integración con otras tecnologías abre nuevas
posibilidades y plantea nuevos retos. Se sigue investigando activamente en indización
de datos, en el uso de inferencia para la recuperación de datos, en la compilación más
eficiente de consultas, la ejecución de consultas en paralelo, en la integración de datos a
partir de fuentes diversas, en el análisis del rendimiento, en la extensión del modelo
transaccional para poder tratar transacciones largas y flujos de trabajo (transacciones
que incluyen tanto pasos de un sistema informático como de un humano), etc. La
disponibilidad de almacenamiento masivo terciario ha motivado también el estudio de
modelos de consulta para dispositivos de acceso muy lento.
Por poner un ejemplo de las áreas de interés en bases de datos, el “Call For Papers” de
la conferencia internacional más importante en bases de datos, la conferencia del
SIGMOD (Special Interest Group on the Management of Data), incluía aspectos tanto
aspectos clásicos como más novedosos. Las áreas de la edición de 2001
1.3.1. Bases de Datos y el eXtended Mark-up Language (XML)

El Lenguaje de Marcas Generalizado Estandarizado (Standardized Generalized Markup
Language, SGML) fue definido por ISO 8879 en 1986 mucho antes de que la web fuera
una palabra familiar en todos los ámbitos. El SGML es el formato normalizado de
documento estructurado más antiguo reconocido por el ISO. Aunque reconocido por el
ISO en 1986, el SGML se inspira en los trabajos de Charles F. Goldfarb que desarrolló
en IBM el lenguaje de marcas generalizado (GML, Generalized Markup Language) a
partir de 1969. Por tanto, El SGML es un lenguaje de marcas generalizado y el HTML
no es más que una instancia hipertexto del mismo, que se ha utilizado para publicar
50
información a través de Internet, constituyendo hace unos años el World Wide Web
(WWW).
Sin embargo el HTML es un lenguaje de publicación de información, donde el formato
es tanto o más importante que el contenido. Aunque el HTML se hubiera podido
considerar inicialmente como un lenguaje para el intercambio de información, el gran
número de etiquetas, scripts y demás parafernalia con la que los fabricantes
(especialmente los fabricantes de navegadores) han ido dotando al lenguaje ha hecho
que la información contenida en una página web sea difícilmente disociable de su
presentación y muy poco digerible con herramientas automáticas.
En los últimos años se ha visto necesaria la existencia de estándares de intercambio de
información, con el objetivo de que las organizaciones puedan compartir su información
de una manera más cómoda y, sobretodo, más automática y eficiente.
XML (eXtended Mark-up Language) es un lenguaje de marcas inspirado también en el

SGML con el objetivo de permitir el intercambio de información de muy diversos tipos.
Conjuntamente el XML permite tratar datos semi-estructurados de la web, organizar
colecciones de datos de distintas fuentes y formatos, e intercambiar datos entre
diferentes sitios/organizaciones.
En lo que concierne a las bases de datos, el XML permite integrar sistemas de
información hasta ahora separados:
Sistemas de información basados en documentos (o ficheros): tienen estructura
irregular, anidados profundamente, utilizan tipos de datos relativamente simples y dan
gran importancia al orden.
Sistemas de información estructurados (p.ej. las bases de datos relacionales): tienen una
estructura muy regular, son relativamente planos, utilizan tipos de datos relativamente
complejos y dan poca importancia al orden.
Para todo esto, la sintaxis del XML es extremadamente simple. Consta exclusivamente
de marcas (de apertura y cierre como HTML) y de atributos. Los datos son de tipo texto
y se sitúan entre las marcas de apertura y las marcas de cierre. Aparte de los
documentos XML existen DTD’s (Document Type Definition) que opcionalmente
pueden ir incluidos en el propio documento XML o en otro URL. Los documentos DTD
tienen una sintaxis similar a la definición de una gramática regular. Por tanto, un
documento XML puede estar bien formado o no, pero además, si está bien formado
puede ser válido o no respecto a una DTD.
La posibilidad de definir DTDs, o más recientemente XML Schemas, para las más
diversas aplicaciones es lo que hace al XML tan potente. En realidad no es más que un
metalenguaje que se puede especializar para distintos usos utilizando DTDs apropiadas.
El hecho de que el XML permita expresar información de características y estructuras
muy diversas no quiere decir que XML venga a sustituir a las bases de datos
tradicionales. En primer lugar, XML no es una base de datos, no es tampoco un modelo
de datos; XML es simplemente un lenguaje de marcas y un documento XML no es, en
principio, nada más que un documento de texto.
Cuando por XML entendemos un documento XML, su DTD asociada, la interpretación

del mismo respecto a una semántica, y todas las tecnologías que lo rodean, podemos
llegar a comparar la tecnología XML con las bases de datos. Aparecen muchas cosas en
común: la tecnología XML usa uno o más documentos (ficheros) para almacenar la
información, define esquemas sobre la información (DTDs y otros lenguajes de
51
esquema XML), tiene lenguajes de consulta específicos para recuperar la información

requerida (XQL, XML-QL, QUILT, etc.), dispone de interfaces de programación (SAX,
DOM), etc.
Pero aparecen muchas más cosas que lo diferencian. La tecnología XML carece, en
parte por principio, de algunas de las siguientes características comunes en las bases de
datos: almacenamiento y actualización eficientes, índices, seguridad, transacciones,
integridad de datos, acceso concurrente, disparadores, etc. Por tanto es imposible pensar
que XML se vaya a utilizar para las tareas transaccionales de una organización para las
cuales sigue estando sobradamente más justificado utilizar una base de datos.
Aclarado ya este punto, pese a ser un lenguaje de marcas, XML permite representar la
mayoría de modelos de datos existentes: de red, jerárquico, relacional, objetual, etc. Es
decir, podemos representar la información contenida en una base de datos relacional en
uno o más documentos XML.
Quizás, la interrelación entre XML y el modelo objetual es cada vez más fuerte
[Chaudhri & Zicari 2000], especialmente en lenguajes de consulta. Éstos suelen
inspirarse en el SQL y en otros lenguajes de consultas como el OQL, aunque también
utilizan ciertas nociones de la programación funcional y de las técnicas de búsqueda de
rutas de árboles de directorios, ya que un documento XML se puede ver como un árbol
de términos, recorrible a través de caminos.
De momento existe el estándar XPath/XPointer para especificar rutas de búsqueda en un
documento [W3C 1999]. Sin embargo, hasta hace poco no existía todavía un estándar
de consulta; existen numerosas propuestas [Abiteboul et al. 1999]: XML-QL [Deutsch
et al. 1998-1999], XQL [Robie et al. 1998], Quilt [Chamberlin et al. 2000]. Al igual que
en SQL, la fuente y el resultado XML de las consultas son compatibles (documentos
XML),
permitiendo el encadenamiento (subconsultas).
Recientemente, el W3C XML Query Working Group (http://www.w3.org/XML/Query)
ha publicado la primera versión del borrador del lenguaje XQuery, destinado a ser el
lenguaje de consulta estándar sobre XML y que recoge muchas de las características de
sus predecesores [W3C 2002].
Además de la anterior, existen numerosas propuestas relacionadas con el XML y las
bases de datos:
El SDQL (SGML Document Query Language) definido por el comité ISO10179 es un
lenguaje de consulta sobre documentos SGML y está basado en las facilidades de
identificación de nodos de SGML definidas en el estándar ISO 10744. SDQL no
permite, sin embargo, controlar el acceso o modificar un repositorio de documentos
SGML. Estas facilidades, usuales en lenguajes como SQL y OQL, están motivando el
desarrollo de nuevos estándares, como los que vemos a continuación:
El ISO TC184/SC4 está actualmente definiendo métodos para almacenar datos
SGML como parte de sus estándares de representación e intercambio de datos de
productos (ISO 10303).
El ISO/IEC JTC1/WG4 N1946 desarrolla estándares para representar metainformación,
accederla y modificarla en sistemas de información basados en documentos SGML.
En el ISO/IEC JTC1/SC32 están definiendo maneras de almacenar documentos
estructurados en bases de datos relacionales, como parte del SQL/MM.
SQL/JRT. Surge como una mezcla del SQLJ Part 1 (SQL Routines Using the Java
Programming Language) y SQLJ Part 2 (SQL Types Using the Java Programming
Language) del SQLJ Group. Ahora su desarrollo está bajo los subcomités 331.1 y
331.2 del NCITS (National Committee for Information Technology Standards).
52
SQL/XML contiene las especificaciones para representar datos relacionales SQL

(específicamente filas y tablas de filas, así como vistas y resultado de consultas) en
formato XML, y viceversa. También se están desarrollando especificaciones para
representar esquemas SQL en XML, así como acciones (insert, update, delete) y la
especificación de protocolos relacionados con el transporte de XML cuando se utiliza
con SQL.
El World Wide Web Consortium (W3C) ha desarrollado el Resource Description
Format (RDF) bajo el RDF Working Group, con el objetivo de definir fuentes de datos
con mayor nivel de abstracción.
1.3.2. Descubrimiento de Conocimiento en Bases de Datos

El aumento del volumen y variedad de información que se encuentra informatizada en
bases de datos digitales ha crecido espectacularmente en la última década. Gran parte de
esta información es histórica, es decir, representa transacciones o situaciones que se han
producido. Aparte de su función de “memoria de la organización”, la información
histórica es útil para predecir la información futura.
El área de la extracción (semi-)automática de conocimiento de bases de datos se basa en
la construcción de modelos a partir de la información existente, con el objetivo de
extrapolar la nformación todavía desconocida.
No es extraño, por tanto, que esta área ha adquirido recientemente una importancia
científica y económica inusual.
Según [Fayyad et al. 1996], el descubrimiento de conocimiento a partir de Bases de
Datos (KDD), del inglés Knowledge Discovery from Databases, se puede definir como
el “proceso no trivial de identificar patrones válidos, novedosos, potencialmente útiles
y en última instancia comprensibles a partir de los datos”.
Las fases del KDD según [Fayyad et al. 1996] son:
Determinar las fuentes de información que pueden ser útiles y dónde conseguirlas.
Diseñar el esquema de un almacén de datos (Data Warehouse) que consiga unificar de
manera operativa toda la información recogida.
Implantación del almacén de datos que permita la “navegación” y visualización previa
de sus datos, para discernir qué aspectos puede interesar que sean estudiados.
Selección, limpieza y transformación de los datos que se van a analizar. La selección
incluye tanto una criba o fusión horizontal (filas) como vertical (atributos).
Seleccionar y aplicar el método de minería de datos apropiado.
Interpretación, transformación y representación de los patrones extraídos.
Difusión y uso del nuevo conocimiento.
Por tanto, la minería de datos (o prospección de datos) no es más que una fase de todo el
proceso, la parte que genera los nuevos patrones, que si bien es la más difícil
computacionalmente, se ve muy afectada por todas las fases anteriores, en especial la de
preparación de datos [Pyle 1999].
El KDD se nutre de diferentes disciplinas y nace como interfaz entre ellas: estadística,
sistemas de información / bases de datos, aprendizaje automático / inteligencia artificial,
visualización de datos, computación paralela / distribuida e interfaces de lenguaje
natural a bases de datos.
Es preciso distinguir las diferencias del KDD con algunas de estas disciplinas. Por
ejemplo, existe una diferencia clara con los métodos estadísticos: la estadística se utiliza
para validar o parametrizar un modelo sugerido y preexistente, no para generarlo.
53
Además, los sistemas clásicos de estadística son difíciles de usar, sus modelos a veces
difíciles de interpretar y no escalan al número de datos típicos en bases de datos.
La diferencia con “Análisis Inteligente de Datos” (IDA, del inglés Intelligent Data
Análisis, véase p.ej. [Berthold & Hand 1999] es más sutil, ya que éste correspondía con
el uso de técnicas de inteligencia artificial en el análisis de los datos. Es un término
cuyo uso está decayendo frente al más común de minería de datos, aunque muchos
paquetes integrales de KDD o de OLAP se suelen llamar “business intelligence
software”.
Por último, la diferencia más importante con el aprendizaje automático es que los datos
usuales en KDD son poco habituales para algoritmos clásicos de aprendizaje
automático: el número de registros (ejemplos) es muy grande (108-1012 bytes) y los
datos altamente dimensionales (nº de columnas/atributos): 102-104. Otras
características especiales de los datos son que éstos residen en el disco y no se pueden
escanear múltiples veces, como requieren algunos algoritmos clásicos. Otro problema es
que las bases de datos contienen sólo información positiva, mientras que algunos
algoritmos funcionan mejor si tienen evidencia positiva y negativa.
También existe el problema que algunas técnicas de muestreo no son compatibles con
algoritmos no incrementales. Finalmente, los datos de una bases de datos suelen ser
imperfectos (erróneos o faltantes).
A todo lo anterior debemos añadir una serie de restricciones. El usuario final no es un
experto en aprendizaje automático ni en estadística. El usuario no puede perder mucho
tiempo analizando los datos; en la industria un retraso en las decisiones más efectivas
haría perder ventajas competitivas, en las aplicaciones científicas se perdería la
oportunidad de investigar datos nunca analizados, bancos no cruzados, etc. Y al nivel
personal, los usuarios no verían útiles estas herramientas si no les ayudan a liberarse del
“information overload”.
Todo esto hace que haya incluido el KDD como tecnología futura. Aunque existen
paquetes disponibles
actualmente y aplicaciones específicas donde el KDD puede obtener modelos
predictivos para mejorar mucho la toma de decisiones, los requisitos anteriores de
conjugar la identificación de patrones válidos, novedosos, útiles y comprensibles no es
posible hoy en día en general.
En el momento presente, las técnicas de minería de datos más usuales [Witten & Frank
1999] [Hand et al. 2000] [Han & Kamber 2001] son aquéllas de aprendizaje automático
y estadística: clasificación, regresión y segmentación, modelos de dependencia
(modelos gráficos, estimación de densidad), sumarización (relación entre campos,
asociaciones, visualización), detección (y modelado) de cambios y desviaciones.
Quizás el ejemplo más paradigmático de adaptación o de algoritmo específico para la
minería de datos es el descubrimiento de reglas de asociaciones, muy útil en los
problemas del estilo “cesta de la compra”, en los cuales se intenta detectar aquellos
items que suelen aparecer conjuntamente con suma frecuencia.
A diferencia de otros problemas más complejos, el establecimiento de reglas de
asociaciones se puede realizar eficientemente [Agrawal & Srikant 1994] [Adamo 2000].
Las áreas de aplicación del KDD son todas aquellas relacionadas con la toma de
decisiones (banca, finanzas, seguros, márketing, políticas sanitarias/demográficas, ...) y
con la investigación científica (medicina, astronomía, meteorología, psicología, ...).
Entre las aplicaciones específicas podemos citar algunas de las más famosas [Berry &
54
Linoff 2000]: identificar patrones de compra de los clientes, buscar asociaciones entre
clientes y características demográficas, predecir respuesta a campañas de mailing,
análisis de cestas de la compra, detectar patrones de uso fraudulento de tarjetas de
crédito, identificar clientes leales, determinar gasto en tarjeta de créditos por grupos y
un largo etcétera. Algunas otras aplicaciones todavía se hallan en fases incipientes:
soporte al diseño de bases de datos [Blockeel & De Raedt 1996, 1998], ingeniería
inversa, calidad de datos y optimización de consultas [Hsu & noblock 1996].
Una de las áreas que ha irrumpido con fuerza es la minería web (Web Mining) [Chang et
al. 2001]. Ésta se refiere al proceso global de descubrir información o conocimiento
potencialmente útil y previamente desconocido a partir de datos de la Web [Etzioni
1996]. Es obvio que la minería web comparte muchas técnicas con la minería de datos y
combina objetivos y técnicas de distintas áreas: recuperación de la información,
procesamiento del lenguaje natural, minería de datos, bases de datos, tecnología web y
tecnología de agentes. La minería web se puede clasificar (no disjuntamente) en tres
tipos [Kosala & Blockeel 2000]: minería del contenido web: se trata de extraer
información del contenido de los documentos en la web; minería de la estructura web:
se intenta descubrir un modelo a partir de la topología de enlaces de la red; minería de
uso de la web: se intenta extraer información (hábitos, preferencias, etc. de los usuarios
o contenidos y relevancia de documentos) a partir de las sesiones y comportamientos de
los usuarios y navegantes.
Finalmente, en relación con el área de las bases de datos hay dos conceptos
recientemente aparecidos en el campo del KDD que merecen una atención especial, por
su interés conceptual. Se trata de las consultas inductivas y de las bases de datos
inductivas.
En las primeras, el descubrimiento en bases de datos se ve como un proceso de consulta
a una base de datos [Imielinski and Manilla 1996]. La situación actual de estos
lenguajes es muy incipiente y se parece al desarrollo de lenguajes de consulta en los
sesenta y setenta.
Una consulta inductiva o de búsqueda de patrones debe permitir al usuario restringir la

búsqueda inductiva en los siguientes aspectos [Han et al. 1999]: la parte de la base de
datos a ser minada (también llamada la vista minable o vista relevante) [Ng et al. 1998],
el tipo de patrón/reglas a ser minado (también llamado restricciones del conocimiento),
debe permitir el uso de cuantificadores estadísticos: representatividad (support),
precisión (confidence/accuracy) y debe permitir expresar otras propiedades que el
patrón debería cumplir (número y forma de las reglas, interés, novedad, etc.).
Una base de datos inductiva es un concepto más controvertido. Se trata de que el

sistema induzca reglas a partir de los datos que contiene y utilice estas reglas para poder
responder a las consultas de los usuarios. Como la inducción es un proceso hipotético
aumenta la posibilidad de que la información extraída mediante consultas sea errónea.
Para disponer de una base de datos inductiva es necesario previamente tener una base de
datos deductiva, y también es necesario que el sistema sea capaz de trabajar con
distintos grados de certeza. En realidad, llegados a este punto, de lo que se está
hablando es de una base de conocimiento.
1.3.3. Bases de Datos Deductivas y Bases de Conocimiento

Aunque situemos esta área dentro de las líneas actuales y futuras, hay que aclarar que
las bases de datos deductivas nacen con el propio modelo relacional, con lo que el
55
concepto no es, en absoluto, novedoso. De hecho, como hemos dicho, antes de la

introducción del modelo relacional por Codd en 1970, Kuhns consideró el uso de la
lógica para realizar consultas [Kuhns 1967]. De hecho, una relación puede verse como
la extensión de un predicado lógico de primer orden. Con la aparición del lenguaje
Prolog [Robinson 1979] [Kowalski 1979] y del Cálculo Relacional de Tuplas [Codd
1971], se plantea la posibilidad de definir un subconjunto de la lógica de primer orden
que sea suficiente para representar la extensión de la base de datos y las consultas sobre
ella. Nace el Datalog (véase p.ej. [Maier & Warren 1988]), que, aunque se restringe
(respecto a Prolog) a constantes y variables en los argumentos de las
relaciones/predicados, mantiene la recursividad. Proliferan las reuniones y conferencias
sobre la conexión entre “Lógica y Bases de Datos”, comenzando por la reunión
celebrada en Toulouse en 1977 [Gallaire & Minker 1978]. Se crea la equivalencia entre
base de datos relacional y teoría lógica de primer orden (con datos básicos), con lo que
se plantea la definición de relaciones en función de otras, es decir, con definiciones
intensionales en vez de extensionales. Esta visión extiende el concepto de vista como
predicado derivado deductivamente. Nacen las bases de datos deductivas [Das 1992]
que permiten consultar información derivada de la información introducida
extensionalmente con anterioridad.
Esta equivalencia ha permitido portar al campo de las bases de datos resultados y

desarrollos fundamentales del campo de la lógica, la programación lógica y la
inteligencia artificial, como ha sido la comprobación de la integridad de la deducción
automática, la asimilación de conocimiento del área de actualización y revisión de
programas lógicos, la optimización de consultas a partir de la optimización y
transformación de programas lógicos, las bases de datos con restricciones y un largo
etcétera. Una muestra de la situación de bases de datos deductivas se puede encontrar en
[Ramakrishnan & Ullman 1995] [Liu 1999]. Los sistemas basados en el conocimiento
(o knowledge-based systems) han sido un área de investigación importante durante al
menos los últimos veinte años, aunque recientemente la perspectiva ha cambiado
ligeramente y se llaman bases de conocimiento [Levesque & Lakemeyer 2001], o
incluso, desde mi punto de vista más inapropiadamente, sistemas de bases de datos
inteligentes [Bertino et al. 2001]. Las bases de conocimiento derivan de los sistemas
expertos de los setenta y los ochenta, pero con una perspectiva más informacional, a
veces llamadas bases de datos expertas [Jeffery 1992]. Se trata de sistemas que
almacenan reglas, además de datos. Estos sistemas son capaces además de aplicar estas
reglas consecuentemente a las situaciones que se les plantean, en cierto modo,
recordando las bases de datos activas. Su uso más extendido se centra en las
herramientas de diagnóstico, en las que se le introducen al sistema una serie de síntomas
o hechos y éste aplica las reglas para responder las causas y/o las consecuencias. La
aplicación más directa puede parecer la ayuda al diagnóstico médico, pero se usan
también en análisis de fallos en la industria.
En realidad los modernos DSS (Decision Support Systems) empresariales no son más
que sistemas expertos sobre un dominio bastante particular, el entorno del negocio, que
además tienen una interfaz muy fluida con la fuente de información organizacional o el
almacén de datos. Este tipo de herramientas pueden significar un paso intermedio hacia
las bases de conocimiento del futuro [Leondes 2000].
56
El mayor inconveniente de las bases de conocimiento (al igual que los sistemas
expertos) es que el conocimiento (el conjunto de reglas) se ha de incorporar
manualmente. Esto hace la creación de una base de conocimiento un proceso lento y
costoso.
El hecho de que esta área se esté revitalizando recientemente se debe a la combinación

de las bases de conocimiento con las bases de datos deductivas, activas e inductivas, las
bases de datos temporales [Tansel et al. 1993], junto con la importación y exportación
de ontologías [Bouguettaya 1999] (posiblemente en XML) para potenciar las
posibilidades de los sistemas y facilitar su desarrollo. También es muy importante la
incorporación de metainformación en estos sistemas, es decir, reglas que versen sobre el
grado de veracidad de otros datos, su aplicabilidad, su contexto, etc. Por tanto, veremos
en el futuro un gran avance de las bases de conocimiento, incorporando diferentes
procesos de adquisición, extracción, recuperación e intercambio de información
extensional (factual) o intensional (en forma de reglas, conceptos o entidades).
Finalmente, el salto a la industria y comercialización masiva de estos sistemas vendrá

cuando se puedan combinar con los sistemas de gestión de bases de datos. El objetivo es
superar las limitaciones de los SGBD (dificultades para tratar reglas declarativas,
metainformación e inconsistencias) y de los sistemas de conocimiento (problemas de
actualización de la información, de la asimilación de conocimiento, mantenimiento de la
integridad, robustez y consulta). El interés está por tanto en combinar la teoría de los
modelos relacionales y objetuales en su versión más amplia (incluyendo reglas
deductivas y reactivas) junto con los sistemas de conocimientos generales, capaces de
tratar información difusa, temporal, no fiable e inconsistente [Wagner 1998].
1.4. La Situación y Sociología de la Disciplina en el Área de Conocimiento

Las bases de datos es un área clásica y bien establecida dentro del área de conocimiento
de lenguajes y sistemas informáticos. La UNESCO, en su clasificación de la ciencia, la
engloba en el área 1203 (Ciencia de los ordenadores), con una entrada (1203/12) para
las bases de datos (bajo la terminología “bancos de datos”) y otra entrada (1203/18)
para los sistemas de información, su diseño y componentes, si bien estamos hablando de
una clasificación de los años 1985-86. Al ser un área bastante central de la informática,
las bases de datos se interrelacionan con prácticamente todas las otras áreas,
especialmente las de lenguajes y sistemas informáticos.
Inicialmente el desarrollo de las bases de datos estaba muy ligado al desarrollo de las
estructuras de datos y los sistemas operativos. Para la fundamentación teórica, las bases
de datos se nutren de la lógica de primer orden, la teoría de grafos, el álgebra, las
lógicas para la concurrencia y otras áreas de la matemática discreta.
El área se engloba dentro de un marco más general (y también más difuso) que
corresponde a los sistemas de información, donde la importancia se centra en esta
última (la información) y en su adecuación con la realidad (su calidad), para que esté al
servicio a la organización o contexto que está modelando. En este sentido se diferencia
del punto de vista del proceso, en el que el objetivo es automatizar o facilitar procesos,
mediante el desarrollo de aplicaciones que se ajusten a unas ciertas especificaciones de
funcionamiento. Evidentemente a los procesos siempre se les asocian datos y esta
dualidad (tan bien representada, p.ej., en el paradigma orientado a objetos) es
57
indisociable a la naturaleza de la informática, si ésta se ve como la ciencia del

procesamiento de la información.
Como toda área científica, las bases de datos tienen su sociología, entendida ésta como
una serie de organizaciones, autoridades, congresos y revistas respetadas y clásicas en la
disciplina. Pasemos a ver algunas de las más importantes.
1.4.1. Organizaciones
Un extracto de las organizaciones más importantes en la disciplina de bases de datos se
muestra a continuación:
ACM/SIGMOD - Special Interest Group on the Management Of Data
(http://www.acm.org/sigmod/): El grupo de interés especial de la ACM dedicado a la
gestión de datos se preocupa de los principios, técnicas y aplicaciones de los sistemas de
gestión de bases de datos y de la tecnología de gestión de datos. Sus miembros incluyen
desarrolladores de software, investigadores de los mundos académico e industrial,
practicantes, usuarios y estudiantes. SIGMOD patrocina la conferencia anual
SIGMOD/PODS, publica revistas, colecciones de literatura y publicaciones, así como
otros materiales en papel o digital.
IEEE TCDE - Technical Committee on Data Engineering
(http://www.ccs.neu.edu/groups/IEEE/tcde/index.html). El comité técnico de ingeniería
de datos de la IEEE Computer Society se preocupa del papel de los datos en el diseño,
desarrollo, gestión y utilización de sistemas de información. Los aspectos de mayor
interés incluyen el diseño de bases de datos, el conocimiento de los datos y su
procesamiento, los lenguajes para describir los datos, definir el acceso y la
manipulación de bases de datos, las estrategias y mecanismos para el acceso a los datos,
la seguridad y control de integridad, y los sistemas distribuidos. El TCDE patrocina la
International Conference on Data Engineering (ICDE) y publica trimestralmetne el
Data Engineering Bulletin.
VLDB Endowment - Very Large Data Base Endowment Inc.
(http://www.vldb.org/). Es una fundación estadounidense sin ánimo de lucro con el
propósito de promover e intercambiar trabajos eruditos en bases de datos y áreas
relacionadas en todo el mundo. Sus actividades principales son la organización de las
conferencias VLDB y la publicación de la VLDB Journal, en colaboración con
Springer-Verlag.
EDBT - Extending Database Technology (www.edbt.org). La fundación EDBT es
una organización apolítica y sin ánimo de lucro con el objetivo de promover y apoyar el
progreso en los campos de las bases de datos y la tecnología y aplicaciones de los
sistemas de información. Su mayor actividad es la promoción de la International
Conference on Extending Database Technology (EDBT), que se celebra bienalmente
desde 1988. La fundación también promueve escuelas de verano internacionales, desde
1991.
ODMG - Object Database Management Group (www.odmg.org) Como hemos visto
antes, es un grupo de fabricantes y usuarios de bases de datos que desarrolla estándares
para los sistemas de gestión de bases de datos orientadas a objetos.
ACM/SIGKDD - Special Interest Group on Knowledge Discovery in Data and
Data Mining (http://www.acm.org/sigkdd/). La tarea principal del SIGKDD es
proporcionar un foro para el avance y la adopción de la “ciencia” del descubrimiento de
conocimiento y la minería de datos. Para ellos, el SIGKDD fomenta la investigación
básica en KDD (a través de conferencias de investigación anuales, un boletín y otras
58
actividades relacionadas), la adopción de “estándares” en el mercado sobre

terminología, evaluación y metodología, así como la educación interdisciplinar entre
investigadores, practicantes y usuarios del KDD. Las actividades concretas del
SIGKDD incluyen la conferencia anual de Knowledge Discovery and Data Mining y el
boletín SIGKDD Explorations.
En menor medida, existen otras organizaciones, como la ACM/SIGMIS - Special
Interest Group on Management Information Systems (http://www.acm.org/sigmis/) o el
Transaction Processing Performance Council (http://www.tpc.org/), la AIS (Association
for Information Systems, http://www.aisnet.org/), la AITP (Association of Information
Technology Professionals, http://www.aitp.org/, antes DPMA), la SIM (Society for
Information Management, http://www.simnet.org/), la IACIS (International Association
for Computer Information Systems, http://www.iacis.org/) y la IAIM (International
Academy for Information Management, http://www.iaim.org/).
1.4.2. Congresos
El número de congresos relacionados con las bases de datos es ingente y continúa
creciendo. Atendiendo a las organizaciones que figuran detrás de los congresos y de su
publicación, podemos citar algunos pocos de los más importantes:
SIGMOD/PODS Conferences
(http://www.acm.org/sigmod/conferences/index.html) Las conferencias PODS
(Principles Of Database Systems) han sido el foro principal para que investigadores,
practicantes, desarrolladores y usuarios de bases de datos presenten su trabajo y
discutan los aspectos críticos y sus visiones sobre la tecnología, aplicaciones y técnicas
punteras en bases de datos.
VLDB Conferences (http://www.vldb.org/dblp/db/conf/vldb/index.html).
Realizadas por el grupo VLDB mencionado anteriormente, las conferencias VLDB
constituyen una de las citas más importantes (y quizás la más internacional) para la
diseminación periódica de los resultados de investigación y desarrollo en el campo de la
gestión de bases de datos.
EDBT Conferences (www.edbt.org). Organizadas por el grupo EDBT, se realizan
cada dos años y tienen un marcado carácter europeo. La de 1998 se organizó en
Valencia.
ICDE (International Conference on Data Engineering). El TCDE
(http://www.ccs.neu.edu/groups/IEEE/tcde/index.html) patrocina esta conferencia,
que suele tener un contenido más tecnológico y actual que las anteriores.
Otras conferencias importantes son la “International Conference on Database Theory”,
la “ACM SIGMOD Conference on Management of Data” o la “International conference
on Data Mining And Knowledge Discovery”. Además, cabe citar un congreso relevante
al nivel español: JISBD (Jornadas de Ingeniería del Software y Bases de Datos). Antes
llamadas “Jornadas de Investigación y Docencia en Bases de Datos” y desde 1999
conjuntas con las jornadas de ingeniería del software, permiten un intercambio de
resultados, tanto docentes como investigadores, en el campo de las bases de datos en
España.
1.4.3. Revistas
Al igual que los congresos, existen más de una centena de revistas internacionales sobre
la disciplina. Mostramos exclusivamente las revistas incluidas en el ISI SCI (las más
referenciadas).
59
ACM Transactions on Database Systems (http://www.acm.org/tods/). Publica:

Association for Computing Machinery. La revista Transactions On Database Systems
(TODS) publica artículos de carácter archivístico en el área de las bases de datos y
disciplinas afines. La mayoría de los artículos que han aparecido en TODS abordan los
fundamentos lógicos y técnicos de la gestión de datos.
Data Mining And Knowledge Discovery,
(http://www.wkap.nl/journalhome.htm/1384-5810). Publica: Kluwer Academic
Publishers. Esta revista publica artículos sobre todos los aspectos del descubrimiento de
conocimiento en bases de datos y en métodos de minería de datos para extraer
representaciones de alto nivel (patrones y modelos) a partir de los datos.
IEEE Transactions on Knowledge and Data Engineering
http://www.computer.org/tkde/). Publica: IEEE Computer. Está diseñada a informar a
los investigadores, desarrolladores, gestores, analistas estratégicos, usuarios y otros
interesados en actividades actuales en el área de la ingeniería del conocimiento y de los
datos.
ACM Transactions on Information Systems (http://www.acm.org/tois/). Publica:
Association for Computing Machinery. Esta revista considera el diseño, rendimiento y
evaluación de sistemas informáticos que facilitan la presentación de la información en
una variedad de medios, así como las tecnologías subyacentes que soportan estos
sistemas.
Information Systems (http://www.elsevier.nl). Publica: Pergamon-Elsevier Science.
Information Systems publica artículos relativos al diseño e implementación de
lenguajes, modelos de datos, software y hardware para sistemas de información.
También mostramos algunas más orientadas a la gestión empresarial:

IEEE IT Professional (http://www.computer.org/itpro/): Para desarrolladores y gestores
de sistemas de información empresarial. IT Professional (ITPro) explica la tecnología
que ayuda a construir y gestionar un sistema de información en la actualidad y
proporciona consejos sobre las tendencias tecnológicas que pueden marcar el área
empresarial en los próximos años.
Datamation, versión española (http://www.mcediciones.es/datamation/). Es una revista
más genérica, con orientación para el entorno empresarial (paquetes de gestión,
comercio electrónico, etc.)
60
1.4 Arquitectura Bases de Datos Distribuidas
En el presente capítulo se mostrará la arquitectura general de un sistema de bases de

datos distribuida, se introducirá el concepto de fragmentación de datos relacionado con
el nivel de transparencia de distribución que un SBDD debe ofrecer. Se dará una
descripción acerca de las componentes de las bases de datos distribuidas.
La arquitectura define la estructura de un sistema. Al definir la arquitectura se deben

identificar las componentes de un sistema, las funciones que realiza cada una de las
componentes y las interrelaciones e interacciones entre cada componente.
NIVELES DE TRANSPARENCIA EN SBDD
El propósito de establecer una arquitectura de un sistema de bases de datos distribuidas

es ofrecer un nivel de transparencia adecuado para el manejo de la información. La
transparencia se puede entender como la separación de la semántica de alto nivel de un
sistema de los aspectos de bajo nivel relacionados a la implementación del mismo. Un
nivel de transparencia adecuado permite ocultar los detalles de implementación a las
capas de alto nivel de un sistema y a otros usuarios.
En sistemas de bases de datos distribuidos el propósito fundamental de la transparencia

es proporcionar independencia de datos en el ambiente distribuido. Se pueden encontrar
diferentes aspectos relacionados con la transparencia. Por ejemplo, puede existir
transparencia en el manejo de la red de comunicación, transparencia en el manejo de
copias repetidas o transparencia en la distribución o fragmentación de la información.
61
La independencia de datos es la inmunidad de las aplicaciones de usuario a los cambios

en la definición y/u organización de los datos y viceversa. La independencia de datos se
puede dar en dos aspectos: lógica y física.
1.- Independencia lógica de datos. Se refiere a la inmunidad de las aplicaciones

de usuario a los cambios en la estructura lógica de la base de datos. Esto permite
que un cambio en la definición de un esquema no debe afectar a las aplicaciones
de usuario. Por ejemplo, el agregar un nuevo atributo a una relación, la creación
de una nueva relación, el reordenamiento lógico de algunos atributos.
2.- Independencia física de datos. Se refiere al ocultamiento de los detalles

sobre las estructuras de almacenamiento a las aplicaciones de usuario. Esto es, la
descripción física de datos puede cambiar sin afectar a las aplicaciones de
usuario. Por ejemplo, los datos pueden ser movidos de un disco a otro, o la
organización de los datos puede cambiar.
La transparencia al nivel de red se refiere a que los datos en un SBDD se accesan sobre
una red de computadoras, sin embargo, las aplicaciones no deben notar su existencia. La
transparencia al nivel de red conlleva a dos cosas:
1.- Transparencia sobre la localización de datos. Esto es, el comando que se

usa es independiente de la ubicación de los datos en la red y del lugar en donde
la operación se lleve a cabo. Por ejemplo, en Unix existen dos comandos para
hacer una copia de archivo. Cp se utiliza para copias locales y rcp se utiliza para
copias remotas. En este caso no existe transparencia sobre la localización.
2.- Transparencia sobre el esquema de nombramiento. Lo anterior se logra

proporcionando un nombre único a cada objeto en el sistema distribuido. Así, no
se debe mezclar la información de la localización con en el nombre de un objeto
La transparencia sobre replicación de datos se refiere a que si existen réplicas de

objetos de la base de datos, su existencia debe ser controlada por el sistema no por el
usuario. Se debe tener en cuenta que al cuando el usuario se encarga de manejar las
réplicas en un sistema, el trabajo de éste es mínimo por lo que se puede obtener una
eficiencia mayor. Sin embargo, el usuario puede olvidarse de mantener la consistencia
de las réplicas teniendo así datos diferentes.
La transparencia a nivel de fragmentación de datos permite que cuando los objetos de

la bases de datos están fragmentados, el sistema tiene que manejar la conversión de
consultas de usuario definidas sobre relaciones globales a consultas definidas sobre
fragmentos. Así también, será necesario mezclar las respuestas a consultas fragmentadas
para obtener una sola respuesta a una consulta global. El acceso a una base de datos
distribuida debe hacerse en forma transparente.
62
Ejemplo 2.1. Como un ejemplo se utilizará a lo largo de estas notas una base de
datos que modela una compañía de ingeniería. Las entidades a ser modeladas
son ingenieros y proyectos. Para cada ingeniero, se desea conocer su número de
empleado (ENO), su nombre (ENOMBRE), el puesto ocupado en compañía
(TITULO), el salario (SAL), la identificación de los nombres de proyectos en
los cuales está trabajando (JNO), la responsabilidad que tiene dentro del
proyecto (RESP) y la duración de su responsabilidad en meses (DUR).
Similarmente, para cada proyecto se desea conocer el número de proyecto
(JNO), el nombre del proyecto (JNOMBRE), el presupuesto asignado al
proyecto (PRESUPUESTO) y el lugar en donde se desarrolla el proyecto
(LUGAR).
Un ingeniero puede participar en más de un proyecto pero su salario

corresponde únicamente al puesto que ocupa en la compañía. Así, después de
aplicar normalización se obtienen las relaciones E para ingenieros, J para
proyectos, S para los salarios asignados a los puestos y G para los ingenieros
asignados a cada proyecto. Un ejemplo de las instancias para cada relación se
presenta en la siguiente figura
ENO ENOMBRE TITULO
E1 Juan Rodríguez Ingeniero Eléctrico
E2 Miguel Sánchez Analista de Sistemas
E3 Armando Legarreta Ingeniero Mecánico
E4 Beatriz Molleda Programador
E5 Jorge Castañeda Analista de Sistemas
E6 Luis Chávez Ingeniero Eléctrico
E7 Roberto Dávila Ingeniero Mecánico
E8 Julia Jiménez Analista de Sistemas
ENO JNO PUESTO DUR
E1 J1 Administrador 12
E2 J1 Analista 24
E2 J2 Analista 6
E3 J3 Consultor 10
E3 J4 Ingeniero 48
63
E4 J2 Programador 18
E7 J3 Ingeniero 36
E7 J5 Ingeniero 23
JNO JNOMBRE PRESUPUESTO LUGAR
J1 Instrumentación 150000 Monterrey
J2 Desarrollo de 135000 México

bases de datos
J3 CAD/CAM 250000 Puebla
J4 Mantenimiento 310000 México
J5 CAD/CAM 500000 Monterrey
TITULO SALARIO
Ingeniero Eléctrico 40000
Analista de Sistemas 34000
Ingeniero Mecánico 27000
Programador 24000
Figura 2.1. Bases de datos de una empresa con cuatro relaciones.
Si se quisiera obtener todos los empleados y sus salarios en la corporación quienes han
trabajado más de 12 meses se haría la consulta siguiente en SQL:
SELECT ENOMBRE, SALARIO
FROM E, G, S
WHERE JORNADA > 12 AND
E.ENO = G.ENO AND
64
E.TILE = S.TITLE
Se debe tener en cuenta que en cada sitio de la corporación puede haber esquemas
diferentes o repetidos. Por ejemplo, en la Figura 2.2 se presentan esquemas diferentes
para el manejo de proyectos, empleados y puestos en cada sitio de la bases de datos del
Ejemplo 2.1.
Figura 2.2. Diferentes sitios de una corporación.
En resumen, la transparencia tiene como punto central la independencia de datos. Los

diferentes niveles de transparencia se puede organizar en capas como se muestra en la
Figura 2.3. En el primer nivel se soporta la transparencia de red. En el segundo nivel se
permite la transparencia de replicación de datos. En el tercer nivel se permite la
transparencia de la fragmentación. Finalmente, en el último nivel se permite la
transparencia de acceso (por medio de lenguaje de manipulación de datos).
La responsabilidad sobre el manejo de transparencia debe estar compartida tanto por el

sistema operativo, el sistema de manejo de bases de datos y el lenguaje de acceso a la
base de datos distribuida. Entre estos tres módulos se deben resolver los aspectos sobre
el procesamiento distribuido de consultas y sobre el manejo de nombres de objetos
distribuidos
65
Figura 2.3. Organización en capas de los niveles de transparencia.
ARQUITECTURA DE UN SISTEMA DE BASES DE DATOS DISTRIBUIDAS
La mayoría de los sistemas de manejo de bases de datos disponibles actualmente están

basadas en la arquitectura ANSI-SPARC la cual divide a un sistema en tres niveles:
interno, conceptual y externo, como se puede apreciar en la Figura 2.4.
La vista conceptual, conocida también como vista lógica global, representa la visión de
la comunidad de usuarios de los datos en la base de datos. No toma en cuenta la forma
en que las aplicaciones individuales observan los datos o como éstos son almacenados.
La vista conceptual está basada en el esquema conceptual y su construcción se hace en
la primera fase del diseño de una base de datos.
Los usuarios, incluyendo a los programadores de aplicaciones, observan los datos a

través de un esquema externo definido a nivel externo. La vista externa proporciona una
ventana a la vista conceptual lo cual permite a los usuarios observar únicamente los
datos de interés y los aísla de otros datos en la base de datos. Puede existir cualquier
número de vistas externas y ellos pueden ser completamente independientes o
traslaparse entre sí.
El esquema conceptual se mapea a un esquema interno a nivel interno, el cual es el nivel

de descripción más bajo de los datos en una base de datos. Este proporciona una interfaz
al sistema de archivos del sistema operativo el cual es el responsable del acceso a la
base de datos. El nivel interno tiene que ver con la especificación de qué elementos
serán indexados, qué técnica de organización de archivos utilizar y como los datos se
agrupan en el disco mediante "clusters" para mejorar su acceso.
En las Figuras 2.5, 2.6 y 2.7 se presenta la definición de los esquemas conceptual,
interno y externo para las relaciones de la Figura 2.1.
66
Figura 2.4. Arquitectura ANSI/SPARC de una base de datos.
Figura 2.5. Vista conceptual de las relaciones E, S, J y G.
Figura 2.6. Definición de una vista interna a partir de la relación S.
67
Figura 2.7. Dos ejemplos de vistas externas.
Desafortunadamente, no existe un equivalente de una arquitectura estándar para

sistemas de manejo de bases de datos distribuidas. La tecnología y prototipos de
SMBDD se han desarrollado más o menos en forma independiente uno de otro y cada
sistema ha adoptado su propia arquitectura.
Para definir un esquema de estandarización en bases de datos distribuidas se debe

definir un modelo de referencia el cual sería un marco de trabajo conceptual cuyo
propósito es dividir el trabajo de estandarización en piezas manejables y mostrar a un
nivel general como esas piezas se relacionan unas con otras. Para definir ese modelo de
referencia se puede seguir uno de los siguientes tres enfoques:
Basado en componentes. Se definen las componentes del sistema junto con las
relaciones entre ellas. Así, un SMBD consiste de un número de componentes,
cada uno de los cuales proporciona alguna funcionalidad.
1. Basado en funciones. Se identifican las diferentes clases de usuarios junto con

la funcionalidad que el sistema ofrecerá para cada clase. La especificación del
sistema en esta categoría típicamente determina una estructura jerárquica para
las clases de usuarios. La ventaja de este enfoque funcional es la claridad con la
cual se especifican los objetivos del sistema. Sin embargo, este enfoque no
proporciona una forma de alcanzar los objetivos.
Basado en datos. Se identifican los diferentes tipos de descripción de datos y se

especifica un marco de trabajo arquitectural el cual define las unidades funcionales que
realizarán y/o usarán los datos de acuerdo con las diferentes vistas. La ventaja de este
enfoque es la importancia que asigna al manejo de datos. Este es un enfoque
significativo para los SMBD dado que su propósito principal es manejar datos. Sin
embargo, la desventaja de este enfoque es que es prácticamente imposible especificar un
modelo arquitectural sin especificar los modelos para cada una de sus unidades
funcionales. Este es el enfoque seguido por el modelo ANSI/SPARC
68
Figura 2.8. Dimensiones a considerar al integrar múltiples bases de datos.
ALTERNATIVAS PARA LA IMPLEMENTACION DE SMBD
En la Figura 2.8 se presentan las diferentes dimensiones (factores) que se deben

considerar para la implementación de un sistema manejador de base de datos. Las
dimensiones son tres:
Distribución. Determina si las componentes del sistema están localizadas en la

misma computadora o no.
Heterogeneidad. La heterogeneidad se puede presentar a varios niveles: hardware,

sistema de comunicaciones, sistema operativo o SMBD. Para el caso 2.3 de SMBD
heterogéneos ésta se puede presentar debido al modelo de datos, al lenguaje de
consultas o a los algoritmos para manejo de transacciones.
Autonomía. La autonomía se puede presentar a diferentes niveles:
Autonomía de diseño. La habilidad de un componente del SMBD para

decidir cuestiones relacionadas a su propio diseño.
Autonomía de comunicación. La habilidad de un componente del SMBD

para decidir como y cuando comunicarse con otros SMBD.
Autonomía de ejecución. La habilidad de un componente del SMBD para

ejecutar operaciones locales de la manera que él quiera.
69
Figura 2.9. Arquitectura de un SMBDD homogéneo.
Desde el punto de vista funcional y de organización de datos, los sistemas de datos

distribuidos están divididos en dos clases separadas, basados en dos filosofía totalmente
diferentes y diseñados para satisfacer necesidades diferentes:
1. Sistemas de manejo de bases de datos distribuidos homogéneos

2. Sistemas de manejo de bases de datos distribuidos heterogéneos
Un SMBDD homogéneo tiene múltiples colecciones de datos; integra múltiples

recursos de datos como se muestra en la Figura 2.9. Los sistemas homogéneos se
parecen a un sistema centralizado, pero en lugar de almacenar todos los datos en un solo
lugar, los datos se distribuyen en varios sitios comunicados por la red. No existen
usuarios locales y todos ellos accesan la base de datos a través de una interfaz global. El
esquema global es la unión de toda las descripciones de datos locales y las vistas de los
usuarios se definen sobre el esquema global.
Para manejar los aspectos de la distribución, se deben agregar dos niveles a la

arquitectura estándar ANSI-SPARC, como se muestra en la Figura 2.10. El esquema de
fragmentación describe la forma en que las relaciones globales se dividen entre las
bases de datos locales. La Figura 2.11 presenta el ejemplo de una relación, R, la cual se
divide en cinco fragmentos. El esquema de asignamiento especifica el lugar en el cual
cada fragmento es almacenado. De aquí, los fragmentos pueden migrar de un sitio a otro
en respuesta a cambios en los patrones de acceso.
70
Figura 2.10. Arquitectura de los esquemas de un SMBDD homogéneo.
Figura 2.11. Fragmentación de una relación global.
71
Figura 2.12. Arquitectura de un sistema multi-bases de datos.
La clase de sistemas heterogéneos es aquella caracterizada por manejar diferentes

SMBD en los nodos locales. Una subclase importante dentro de esta clase es la de los
sistemas de manejo multi-bases de datos. Un sistema multi-bases de datos (Smulti-
BD) tiene múltiples SMBDs, que pueden ser de tipos diferentes, y múltiples bases de
datos existentes. La integración de todos ellos se realiza mediante subsistemas de
software. La arquitectura general de tales sistemas se presenta en la Figura 2.12. En
contraste con los sistemas homogéneos, existen usuarios locales y globales. Los
usuarios locales accesan sus bases de datos locales sin verse afectados por la presencia
del Smulti-BD.
En algunas ocasiones es importante caracterizar a los sistemas de bases de datos

distribuidas por la forma en que se organizan sus componentes. En la Figura 2.13 se
presenta la arquitectura basada en componentes de un SMBD distribuido. Consiste de
dos partes fundamentales, el procesador de usuario y el procesador de datos. El
procesador de usuario se encarga de procesar las solicitudes del usuario, por tanto,
utiliza el esquema externo del usuario y el esquema conceptual global. Así también,
utiliza un diccionario de datos global. El procesador de usuario consiste de cuatro
partes: un manejador de la interfaz con el usuario, un controlador semántico de datos,
un optimizador global de consultas y un supervisor de la ejecución global. El
procesador de datos existe en cada nodo de la base de datos distribuida. Utiliza un
esquema local conceptual y un esquema local interno. El procesador de datos consiste
de tres partes: un procesador de consultas locales, un manejador de recuperación de
fallas locales y un procesador de soporte para tiempo de ejecución.
72
Figura 2.13. Arquitectura basada en componentes de un SMBD distribuido.
En la Figura 2.14, se presenta la arquitectura basada en componentes de un sistema

multi-bases de datos. Consiste un sistema de manejo de bases datos para usuarios
globales y de sistemas de manejo de bases de datos para usuarios locales. Las
solicitudes globales pasan al procesador global el cual consiste de un procesador de
transacciones, una interfaz de usuario, un procesador de consultas, un optimizador de
consultas, un esquema y un administrador de recuperación de fallas, todos ellos
actuando de manera global.
En cada sitio existe un SMBD completo el cual consiste de la interfaz con el usuario, el
procesador y optimizador de consultas, el manejador de transacciones, el despachador
de operaciones, el manejador de recuperación de fallas y el sistema de soporte para
tiempo de ejecución, todos ellos actuando de manera local. Para comunicar el sistema
global con los sistemas locales se define una interfaz común entre componentes
mediante la cual, las operaciones globales se convierten en una o varias acciones
locales.
El manejo de directorio de datos es de una importancia mayor en bases de datos

distribuidas. Por un lado, puede haber directorios locales o un solo directorio global. Por
otra parte, su manejo puede ser local o distribuido. Finalmente, desde otro punto de
vista el directorio puede ser replicado o no replicado. Como se puede ver en la Figura
2.15, existen combinaciones, en estas tres dimensiones, que no tienen mayor relevancia.
Sin embargo, en varios de los vértices del cubo en tres dimensiones aparecen las
combinaciones importantes para bases de datos distribuidas.
73
Figura 2.14. Arquitectura basada en componentes de un sistema multi-bases de datos.
Figura 2.15. Manejo del directorio de datos en bases de datos distribuidas
74
Unidad 2
Diseño de bases de datos distribuidas
En el presente capítulo se mostrará los aspectos importantes referentes al diseño de una

base de datos distribuida. Se revisará el problema de fragmentación de los datos así
como la transparencia que un sistema de datos distribuidos debe guardar respecto a la
vista del usuario. Se presentarán los algoritmos para fragmentación horizontal,
fragmentación horizontal derivada y fragmentación vertical. En la parte final de este
capítulo se discute el problema de asignamiento de fragmentos.
El problema de diseño
El problema de diseño de bases de datos distribuidos se refiere, en general, a hacer

decisiones acerca de la ubicación de datos y programas a través de los diferentes sitios
de una red de computadoras. Este problema debería estar relacionado al diseño de la
misma red de computadoras. Sin embargo, en estas notas únicamente el diseño de la
base de datos se toma en cuenta. La decisión de donde colocar a las aplicaciones tiene
que ver tanto con el software del SMBDD como con las aplicaciones que se van a
ejecutar sobre la base de datos.
El diseño de las bases de datos centralizadas contempla los dos puntos siguientes:
1. Diseño del "esquema conceptual" el cual describe la base de datos integrada

(esto es, todos los datos que son utilizados por las aplicaciones que tienen acceso
a las bases de datos).
2. Diseño "físico de la base de datos", esto es, mapear el esquema conceptual a

las áreas de almacenamiento y determinar los métodos de acceso a las bases de
datos.
En el caso de las bases de datos distribuidas se tienen que considerar los dos
problemas siguientes:
3. Diseño de la fragmentación, este se determina por la forma en que las

relaciones globales se subdividen en fragmentos horizontales, verticales o
mixtos.
4. Diseño de la asignación de los fragmentos, esto se determina en la forma en

que los fragmentos se mapean a las imágenes físicas, en esta forma, también se
determina la solicitud de fragmentos.
75
Objetivos del Diseño de la Distribución de los Datos.
En el diseño de la distribución de los datos, se deben de tomar en cuenta los siguientes

objetivos:
• Procesamiento local. La distribución de los datos, para maximizar el

procesamiento local corresponde al principio simple de colocar los datos tan
cerca como sea posible de las aplicaciones que los utilizan. Se puede realizar el
diseño de la distribución de los datos para maximizar el procesamiento local
agregando el número de referencias locales y remotas que le corresponden a
cada fragmentación candidata y la localización del fragmento, que de esta forma
se seleccione la mejor solución de ellas.
• Distribución de la carga de trabajo. La distribución de la carga de trabajo
sobre los sitios, es una característica importante de los sistemas de cómputo
distribuidos. Esta distribución de la carga se realiza para tomar ventaja de las
diferentes características (potenciales) o utilizaciones de las computadoras de
cada sitio, y maximizar el grado de ejecución de paralelismo de las aplicaciones.
Sin embargo, la distribución de la carga de trabajo podría afectar negativamente
el procesamiento local deseado.
• Costo de almacenamiento y disponibilidad. La distribución de la base de datos
refleja el costo y disponibilidad del almacenamiento en diferentes sitios. Para
esto, es posible tener sitios especializados en la red para el almacenamiento de
datos. Sin embargo el costo de almacenamiento de datos no es tan relevante si
éste se compara con el del CPU, I/O y costos de transmisión de las aplicaciones.
2.1 Consideraciones Diseño Bases de Datos Distribuidas
Existen dos estrategias generales para abordar el problema de diseño de bases de datos
distribuidas:
1.- El enfoque de arriba hacia abajo (top-down). Este enfoque es más apropiado
para aplicaciones nuevas y para sistemas homogéneos. Consiste en partir desde el
análisis de requerimientos para definir el diseño conceptual y las vistas de usuario.
A partir de ellas se define un esquema conceptual global y los esquemas externos
necesarios. Se prosigue con el diseño de la fragmentación de la base de datos, y de
aquí se continúa con la localización de los fragmentos en los sitios, creando las
imágenes físicas. Esta aproximación se completa ejecutando, en cada sitio, "el
diseño físico" de los datos, que se localizan en éste. En la Figura 3.1 se presenta un
diagrama con la estructura general del enfoque top-down.
2.- El diseño de abajo hacia arriba (bottom-up). Se utiliza particularmente a

partir de bases de datos existentes, generando con esto bases de datos distribuidas.
En forma resumida, el diseño bottom-up de una base de datos distribuida requiere de
la selección de un modelo de bases de datos común para describir el esquema global
76
de la base de datos. Esto se debe es posible que se utilicen diferentes SMBD.

Después se hace la traducción de cada esquema local en el modelo de datos común y
finalmente se hace la integración del esquema local en un esquema global común.
Figura 3.1. El enfoque top-down para el diseño de bases de datos distribuidas.
El diseño de una base de datos distribuida, cualquiera sea el enfoque que se siga, debe
responder satisfactoriamente las siguientes preguntas:
• Por qué hacer una fragmentación de datos?

• Cómo realizar la fragmentación?
• Qué tanto se debe fragmentar?
• Cómo probar la validez de una fragmentación?
• Cómo realizar el asignamiento de fragmentos?
• Cómo considerar los requerimientos de la información?
Figura 3.2. El problema de fragmentación de relaciones.
77
El problema de fragmentación
El problema de fragmentación se refiere al particionamiento de la información para

distribuir cada parte a los diferentes sitios de la red, como se observa en la Figura 3.2.
Inmediatamente aparece la siguiente pregunta: cuál es la unidad razonable de
distribución?. Se puede considerar que una relación completa es lo adecuado ya que las
vistas de usuario son subconjuntos de las relaciones. Sin embargo, el uso completo de
relaciones no favorece las cuestiones de eficiencia sobre todo aquellas relacionadas con
el procesamiento de consultas.
La otra posibilidad es usar fragmentos de relaciones (sub-relaciones) lo cual favorece la

ejecución concurrente de varias transacciones que accesan porciones diferentes de una
relación. Sin embargo, el uso de sub-relaciones también presenta inconvenientes. Por
ejemplo, las vistas de usuario que no se pueden definir sobre un solo fragmento
necesitarán un procesamiento adicional a fin de localizar todos los fragmentos de una
vista. Aunado a esto, el control semántico de datos es mucho más complejo ya que, por
ejemplo, el manejo de llaves únicas requiere considerar todos los fragmentos en los que
se distribuyen todos los registros de la relación. En resumen, el objetivo de la
fragmentación es encontrar un nivel de particionamiento adecuado en el rango que va
desde tuplas o atributos hasta relaciones completas (ver Figura 3.3).
Ejemplo 3.1. Considere la relación J del ejemplo.
J:

bases de datos
J5 CAD/CAM 500000 Guadalajara
La relación J se puede fragmentar horizontalmente produciendo los siguientes

fragmentos.
J1: proyectos con presupuesto menor que $200,000
78

bases de datos
J2: proyectos con presupuesto mayor que o igual a $200,000
J5 CAD/CAM 500000 Guadalajara
Ejemplo 3.2. La relación J del ejemplo anterior se puede fragmentar verticalmente

produciendo los siguientes fragmentos:
J1: información acerca de presupuestos de proyectos
JNO PRESUPUESTO
J1 150000
J2 135000
J3 250000
J4 310000
J5 500000
J2: información acerca de los nombres y ubicaciones de proyectos
JNO JNOMBRE LUGAR
J1 Instrumentación Monterrey
J2 Desarrollo de bases México

de datos
J3 CAD/CAM Puebla
J4 Mantenimiento México
J5 CAD/CAM Guadalajara
79
Figura 3.3. El grado de fragmentación.
Correctitud de una fragmentación .Al realizar la fragmentación de una relación se

deben satisfacer las siguientes condiciones para garantizar la correctitud de la misma:
1. Condición de completitud. La descomposición de una relación R en los

fragmentos R1, R2, ..., Rn es completa si y solamente si cada elemento de datos en
R se encuentra en algún de los Ri.
2. Condición de Reconstrucción. Si la relación R se descompone en los
fragmentos R1, R2, ..., Rn, entonces debe existir algún operador relacional  , tal
que,
R =  1� i� n Ri
3. Condición de Fragmentos Disjuntos. Si la relación R se descompone en los

fragmentos R1, R2, ..., Rn, y el dato di está en Rj, entonces, no debe estar en
ningún otro fragmento Rk (k� j).
Alternativas sobre replicación para el asignamiento de fragmentos
La replicación de información es de utilidad para obtener un mejor rendimiento y para

ofrecer un mayor grado de confiabilidad (tolerancia a fallas). La replicación se complica
cuando es necesario hacer actualizaciones a las copias múltiples de un dato. Por tanto,
respecto a la replicación, en el asignamiento de fragmentos se tienen tres estrategias:
1. No soportar replicación. Cada fragmento reside en un solo sitio.

2. Soportar replicación completa. Cada fragmento en cada uno de los sitios.
3. Soportar replicación parcial. Cada fragmento en algunos de los sitios.
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. En la Tabla 3.1 se comparan la complejidad de
implementar o tomar ventaja de las diferentes alternativas de replicación, respecto de
los diferentes aspectos importantes en bases de datos distribuidas.
80
Replicación Replicación Parcial Particionamiento

Completa
Procesamiento de Fácil Moderado Moderado

Consultas
Manejo de Fácil o no Moderado Moderado

Directorios existente
Control de Moderado Difícil Fácil

Concurrencia
Confiabilidad Muy alto Alto Bajo
Realidad Aplicación Realista Aplicación posible

posible
Tabla 3.1. Comparación de las estrategias de replicación de fragmentos.
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:
1. Información sobre el significado de los datos

2. Información sobre las aplicaciones que los usan
3. Información acerca de la red de comunicaciones
4. Información acerca de los sistemas de cómputo
2.2 Diccionario de Datos
Contiene las características lógicas de los sitios donde se almacenan los datos del
sistema, incluyendo nombre, descripción, alias, contenido y organización. Identifica los
procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a
la información, se desarrolla durante el análisis de flujo de datos y auxilia a los analistas
que participan en la determinación de los requerimientos del sistema, su contenido
también se emplea durante el diseño.
Razones para su utilización:
1.Para manejar los detalles en sistemas muy grandes, ya que tienen enormes
cantidades de datos, aun en los sistemas más chicos hay gran cantidad de datos.
Los sistemas al sufrir cambios continuos, es muy difícil manejar todos los detalles.
Por eso se registra la información, ya sea sobre hoja de papel o usando
procesadores de texto. Los analistas mas organizados usan el diccionario de datos
automatizados diseñados específicamente para el análisis y diseño de software.
2.Para asignarle un solo significado a cada uno de los elementos y actividades del
sistema.
81
Los diccionarios de datos proporcionan asistencia para asegurar significados

comunes para los elementos y actividades del sistema y registrando detalles
adicionales relacionados con el flujo de datos en el sistema, de tal manera que todo
pueda localizarse con rapidez.
3.Para documentar las características del sistema, incluyendo partes o
componentes así como los aspectos que los distinguen. También es necesario saber
bajo que circunstancias se lleva a cabo cada proceso y con que frecuencia ocurren.
Produciendo una comprensión mas completa. Una vez que las características están
articuladas y registradas, todos los participantes en el proyecto tendrán una fuente
común de información con respecto al sistema.
4.Para facilitar el análisis de los detalles con la finalidad de evaluar las
características y determinar donde efectuar cambios en el sistema.
Determina si son necesarias nuevas características o si están en orden los

cambios de cualquier tipo.
Se abordan las características:
* Naturaleza de las transacciones: las actividades de la empresa que se llevan a
cabo mientras se emplea el sistema.
* Preguntas: solicitudes para la recuperación o procesamiento de información
para generar una respuesta específica.
* Archivos y bases de datos: detalles de las transacciones y registros maestros
que son de interés para la organización.
* Capacidad del sistema: Habilidad del sistema para aceptar, procesar y
almacenar transacciones y datos
5- Localizar errores y omisiones en el sistema, detectan dificultades, y las presentan en
un informe. Aun en los manuales, se revelan errores.
Contenido de un registro del diccionario
El diccionario tiene dos tipos de descripciones para el flujo de datos del sistema, son los
elementos datos y estructura de datos.
Elemento dato: son los bloques básicos para todos los demás datos del sistema, por si
mismos no le dan un significado suficiente al usuario. Se agrupan para formar una
estructura de datos.
Descripción: Cada entrada en el diccionario consiste de un conjunto de detalles que
describen los datos utilizados o producidos por el sistema.
Cada uno esta identificado con:
Un nombre: para distinguir un dato de otro.
Descripción: indica lo que representa en el sistema.
Alias: porque un dato puede recibir varios nombres, dependiendo de quien uso este
dato.
Longitud: porque es de importancia de saber la cantidad de espacio necesario para cada
dato.
82
Valores de los datos: porque en algunos procesos solo son permitidos valores muy
específicos para los datos. Si los valores de los datos están restringidos a un intervalo
especifico, esto debe estar en la entrada del diccionario.
Estructura de datos: es un grupo de datos que están relacionados con otros y que en
conjunto describen un componente del sistema.
Descripción:
Se construyen sobre cuatro relaciones de componentes. Se pueden utilizar las siguientes
combinaciones ya sea individualmente o en conjunción con alguna otra.
Relación secuencial: define los componentes que siempre se incluyen en una estructura
de datos.
Relación de selección: (uno u otro), define las alternativas para datos o estructuras de
datos incluidos en una estructura de datos.
Relación de iteración: (repetitiva), define la repetición de un componente.
Relación opcional: los datos pueden o no estar incluidos, o sea, una o ninguna iteración.
Notación
Los analistas usan símbolos especiales con la finalidad de no usar demasiada cantidad
de texto para la descripción de las relaciones entre datos y mostrar con claridad las
relaciones estructurales. En algunos casos se emplean términos diferentes para describir
la misma entidad (alias) estos se representan con un signo igual (=) que vincula los
datos
2.3 Niveles de Transparencia

NIVELES DE TRANSPARENCIA EN SBDD
El propósito de establecer una arquitectura de un sistema de bases de datos distribuidas

es ofrecer un nivel de transparencia adecuado para el manejo de la información. La
transparencia se puede entender como la separación de la semántica de alto nivel de un
sistema de los aspectos de bajo nivel relacionados a la implementación del mismo. Un
nivel de transparencia adecuado permite ocultar los detalles de implementación a las
capas de alto nivel de un sistema y a otros usuarios.
En sistemas de bases de datos distribuidos el propósito fundamental de la transparencia

es proporcionar independencia de datos en el ambiente distribuido. Se pueden encontrar
diferentes aspectos relacionados con la transparencia. Por ejemplo, puede existir
transparencia en el manejo de la red de comunicación, transparencia en el manejo de
copias repetidas o transparencia en la distribución o fragmentación de la información.
La independencia de datos es la inmunidad de las aplicaciones de usuario a los cambios

en la definición y/u organización de los datos y viceversa. La independencia de datos se
puede dar en dos aspectos: lógica y física.
83
1.- Independencia lógica de datos. Se refiere a la inmunidad de las aplicaciones

de usuario a los cambios en la estructura lógica de la base de datos. Esto permite
que un cambio en la definición de un esquema no debe afectar a las aplicaciones
de usuario. Por ejemplo, el agregar un nuevo atributo a una relación, la creación
de una nueva relación, el reordenamiento lógico de algunos atributos.
2.- Independencia física de datos. Se refiere al ocultamiento de los detalles

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

2.3.1 Transparencia de Localización
La transparencia al nivel de red se refiere a que los datos en un SBDD se accesan sobre
una red de computadoras, sin embargo, las aplicaciones no deben notar su existencia. La
transparencia al nivel de red conlleva a dos cosas:
1.- Transparencia sobre la localización de datos. Esto es, el comando que se

usa es independiente de la ubicación de los datos en la red y del lugar en donde
la operación se lleve a cabo. Por ejemplo, en Unix existen dos comandos para
hacer una copia de archivo. Cp se utiliza para copias locales y rcp se utiliza para
copias remotas. En este caso no existe transparencia sobre la localización.
2.- Transparencia sobre el esquema de nombramiento. Lo anterior se logra

proporcionando un nombre único a cada objeto en el sistema distribuido. Así, no
se debe mezclar la información de la localización con en el nombre de un objeto
2.3.2 Transparencia de Fragmentación
La transparencia a nivel de fragmentación de datos permite que cuando los objetos de

la bases de datos están fragmentados, el sistema tiene que manejar la conversión de
consultas de usuario definidas sobre relaciones globales a consultas definidas sobre
fragmentos. Así también, será necesario mezclar las respuestas a consultas fragmentadas
84
para obtener una sola respuesta a una consulta global. El acceso a una base de datos
distribuida debe hacerse en forma transparente.
Ejemplo 2.1. Como un ejemplo se utilizará a lo largo de estas notas una base de
datos que modela una compañía de ingeniería. Las entidades a ser modeladas
son ingenieros y proyectos. Para cada ingeniero, se desea conocer su número de
empleado (ENO), su nombre (ENOMBRE), el puesto ocupado en compañía
(TITULO), el salario (SAL), la identificación de los nombres de proyectos en
los cuales está trabajando (JNO), la responsabilidad que tiene dentro del
proyecto (RESP) y la duración de su responsabilidad en meses (DUR).
Similarmente, para cada proyecto se desea conocer el número de proyecto
(JNO), el nombre del proyecto (JNOMBRE), el presupuesto asignado al
proyecto (PRESUPUESTO) y el lugar en donde se desarrolla el proyecto
(LUGAR).
Un ingeniero puede participar en más de un proyecto pero su salario

corresponde únicamente al puesto que ocupa en la compañía. Así, después de
aplicar normalización se obtienen las relaciones E para ingenieros, J para
proyectos, S para los salarios asignados a los puestos y G para los ingenieros
asignados a cada proyecto. Un ejemplo de las instancias para cada relación se
presenta en la siguiente figura
ENO ENOMBRE TITULO
E1 Juan Rodríguez Ingeniero Eléctrico
E2 Miguel Sánchez Analista de Sistemas
E3 Armando Legarreta Ingeniero Mecánico
E4 Beatriz Molleda Programador
E5 Jorge Castañeda Analista de Sistemas
E6 Luis Chávez Ingeniero Eléctrico
E7 Roberto Dávila Ingeniero Mecánico
E8 Julia Jiménez Analista de Sistemas
ENO JNO PUESTO DUR
E2 J1 Analista 24
85
E2 J2 Analista 6
E3 J3 Consultor 10
E3 J4 Ingeniero 48
E4 J2 Programador 18
E7 J3 Ingeniero 36
E7 J5 Ingeniero 23

bases de datos
J5 CAD/CAM 500000 Monterrey
TITULO SALARIO
Ingeniero Eléctrico 40000
Analista de Sistemas 34000
Ingeniero Mecánico 27000
Programador 24000
Figura 2.1. Bases de datos de una empresa con cuatro relaciones.
Si se quisiera obtener todos los empleados y sus salarios en la corporación quienes han
trabajado más de 12 meses se haría la consulta siguiente en SQL:
SELECT ENOMBRE, SALARIO
86
FROM E, G, S
WHERE JORNADA > 12 AND
E.ENO = G.ENO AND
E.TILE = S.TITLE
Se debe tener en cuenta que en cada sitio de la corporación puede haber esquemas
diferentes o repetidos. Por ejemplo, en la Figura 2.2 se presentan esquemas diferentes
para el manejo de proyectos, empleados y puestos en cada sitio de la bases de datos del
Ejemplo 2.1.
Figura 2.2. Diferentes sitios de una corporación.
En resumen, la transparencia tiene como punto central la independencia de datos. Los

diferentes niveles de transparencia se puede organizar en capas como se muestra en la
Figura 2.3. En el primer nivel se soporta la transparencia de red. En el segundo nivel se
permite la transparencia de replicación de datos. En el tercer nivel se permite la
transparencia de la fragmentación. Finalmente, en el último nivel se permite la
transparencia de acceso (por medio de lenguaje de manipulación de datos).
La responsabilidad sobre el manejo de transparencia debe estar compartida tanto por el

sistema operativo, el sistema de manejo de bases de datos y el lenguaje de acceso a la
base de datos distribuida. Entre estos tres módulos se deben resolver los aspectos sobre
el procesamiento distribuido de consultas y sobre el manejo de nombres de objetos
distribuidos
87
Figura 2.3. Organización en capas de los niveles de transparencia.
2.3.3 Transparencia de Replica

88
2.4 Fragmentación de Datos
Fragmentación de datos. Consiste

en subdividir las relaciones y
distribuirlas entre los sitios de la
red, tiene como objetivo buscar
formas alternativas de dividir una
las instancias (tablas) de relaciones
en otras más pequeñas. La
fragmentación se puede realizar por
tuplas individuales (fragmentación
horizontal), por atributos individuales fragmentación vertical) o una combinación de
ambas (fragmentación híbrida). El principal problema de la fragmentación radica en
encontrar la unidad apropiada de distribución. Una relación no es una buena unidad por
muchas razones. Normalmente las vistas de una relación están formadas por
subconjuntos de relaciones. Además, las aplicaciones acceden localmente a
subconjuntos de relaciones. Por ello, es necesario considerar a los subconjuntos de
relaciones como unidad de distribución. Al descomponer de una relación en fragmentos,
tratados cada uno de ellos como una unidad de distribución, permite el proceso
concurrente de las transacciones. El conjunto de estas relaciones, provocará la ejecución
paralela de una consulta al ser dividida en una serie de subconsultas que operará sobre
los fragmentos. Cuando las vistas definidas sobre una relación son consideradas como
unidad de distribución que se ubican en diferentes sitios de la red, podemos optar por
dos alternativas diferentes: La relación no estará replicada y se almacena en un único
sitio, o existe réplica en todos o algunos de los sitios en los cuales reside la aplicación.
Las consecuencias de esta estrategia son la generación de un volumen de accesos
remotos que pueden ser innecesarios con un mal manejo de estas replicas. Además, las
réplicas innecesarias pueden causar problemas en la ejecución de las actualizaciones y
puede no ser deseable si el espacio de almacenamiento está limitado. Los
inconvenientes de la fragmentación están dados en que si las pueden estar definidas por
fragmentos mutuamente exclusivos y al recuperar los datos de dos fragmentos situados
en sitios diferentes es necesario trasmitir los datos de un sitio a otro y realizar sobre
ellos la operación de unión (Join), lo cual puede ser costoso. El control semántico
cuando los atributos implicados en una dependencia una relación se descompone en
diferentes fragmentos y estos se ubican en sitios diferentes puede ser muy costos porque
es necesario hacer búsquedas en un gran número de sitios.
Criterios para escoger la distribución
89
• 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 como colocar
la data de tal forma que se optimicen los accesos a la data locales.
• 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 donde 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 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.
2.4.1 Fragmentación horizontal
La fragmentación horizontal primaria de una relación se obtiene usando predicados que

están definidos en esa relación.
Para poder construir una fragmentación, es necesario proporcionar información acerca

de la base de datos y acerca de las aplicaciones que las utilizan. En primer término, es
necesario proporcionar la información acerca del esquema conceptual global. En este
sentido es importante dar información acerca de las relaciones que componen a la base
de datos, la cardinalidad de cada relación y las dependencias entre relaciones. Por
ejemplo, en la Figura de abajo se presenta un diagrama mostrando el esquema
conceptual de la base de datos.
En segundo lugar se debe proporcionar información acerca de la aplicación que utiliza

la base de datos. Este tipo de información es cuantitativa y consiste de los predicados
usados en las consultas de usuario.
90
Esquema conceptual de la base de datos
Ejemplo 3.7. Las siguientes expresiones se consideran como predicados simples.
No. De Registro = 230
No de Registro < 200000
2.4.2 FRAGMENTACION VERTICAL
Una fragmentación vertical de una relación R produce fragmentos R1, R2, ..., Rr, cada
uno de los cuales contiene un subconjunto de los atributos de R así como la llave
primaria de R. El objetivo de la fragmentación vertical es particionar una relación en un
conjunto de relaciones más pequeñas de manera que varias de las aplicaciones de
usuario se ejecutarán sobre un fragmento. En este contexto, una fragmentación "óptima"
es aquella que produce un esquema de fragmentación que minimiza el tiempo de
ejecución de las consultas de usuario.
La fragmentación vertical ha sido estudiada principalmente dentro del contexto de los

sistemas de manejo de bases de datos centralizados como una herramienta de diseño, la
cual permite que las consultas de usuario traten con relaciones más pequeñas haciendo,
por tanto, un número menor de accesos a páginas.
La fragmentación vertical es inherentemente más complicada que particionamiento

horizontal ya que existe un gran número de alternativas para realizarla. Por lo tanto, se
utilizan heurísticas para hacer el particionamiento. Los dos enfoques básicos son:
1. Agrupamiento. Inicia asignando cada atributo a un fragmento, y en cada paso,

algunos de los fragmentos satisfaciendo algún criterio se unen para formar un
solo fragmento.
2. División. Inicia con una sola relación realizar un particionamiento basado en el
comportamiento de acceso de las consultas sobre los atributos.
91
Requerimientos de información para la fragmentación vertical
Como en el caso de la fragmentación horizontal, es necesario proporcionar información

para poder realizar una adecuada fragmentación vertical. Ya que el particionamiento
vertical coloca en un fragmento aquellos atributos que se accesan juntos, se presenta la
necesidad de una medida que relacione la afinidad de los atributos, la cual indica qué
tan relacionados están los atributos. Esta medida se obtiene por datos primitivos.
Ejemplo. Considere la relación J de la Figura de abajo. Suponga que las

siguientes consultas se definen sobre esta relación:
Esquema conceptual de la base de datos.
q1: Encuentre el presupuesto de un proyecto dado su número de identificación.
SELECT PRESUPUESTO
FROM J
WHERE JNO=valor
q2: Encuentre los nombres y presupuestos de todos los proyectos.
SELECT JNOMBRE, PRESUPUESTO
FROM J
q3: Encuentre los nombres de los proyectos en una ciudad dada.
SELECT JNOMBRE
FROM J
WHERE LUGAR=valor
q4: Encuentre el presupuesto total de los proyectos en cada ciudad.
SELECT SUM(PRESUPUESTO)
92
FROM J
WHERE LUGAR=valor
2.4.3 Fragmentación Hibrida
En muchos casos la fragmentación vertical u horizontal del esquema de la base de datos

no será suficiente para satisfacer los requisitos de las aplicaciones. Como ya se citó al
comienzo de este documento podemos combinar ambas, utilizando por ello la
denominada fragmentación mixta. Cuando al proceso de fragmentación vertical le sigue
una horizontal, es decir, se fragmentan horizontalmente los fragmentos verticales
resultantes, se habla de la fragmentación mixta HV. En el caso contrario, estaremos ante
una fragmentación VH. Una característica común a ambas es la generación de árboles
que representan la estructura de fragmentación
Figura 8. Estructura arbórea de fragmentación mixta.
No se desea entrar en excesivos detalles sobre las reglas y condiciones para efectuar la
fragmentación mixta. Entre otras razones porque, tanto a la fragmentación HV como la
fragmentación VH, se le pueden aplicar los mismos criterios y reglas que a la fragmentación
horizontal y vertical.
También debe tenerse en cuenta el número de niveles arbóreos que se generen, es decir,
nadie impide que tras realizar una fragmentación VH, podamos aplicar a los fragmentos
resultantes una nueva fragmentación vertical, y a estos últimos una nueva
fragmentación horizontal, etc. Dicho número puede ser grande, pero también será
ciertamente finito. En el caso horizontal, el nivel máximo de profundidad se alcanzará
cuando cada fragmento albergue una única tupla, mientras que en el caso vertical el
final llegará cuando cada fragmento contenga un único atributo. Sin embargo, aunque
no deba tomarse como dogma, el número de niveles no debería superar el par (VH y
93
HV). El porqué de esta afirmación es bien sencillo, piense, por ejemplo, en el coste que
supondría realizar la unión o el yunto de una relación con fragmentación nivel 7.
Evidentemente, el coste sería muy elevado y ese aumento de rendimiento que se
persigue al aplicar estas técnicas, quizás, no se produzca.
2.5 Distribucion de Datos
2.5.1 Algoritmos Distribucion Datos No Replicados
2.5.2 Algoritmos Distribucion Datos Replicados
Unidad 3 Procesamiento de consultas distribuidas
3.1 Metodologia Procesamiento Consultas Distribuidas
3.2 Estrategias Procesamiento Consultas Distribuidas
3.2.1 Arboles de Consultas
3.2.2 Transformaciones Equivalentes Consultas Distribuidas
3.2.3 Metodos Ejecucion del Join
3.3 Optimizacion de Consultas Distribuidas
3.3.1 Optimizacion Global Consultas Distribuidas
3.3.2 Optimizacion Local Consultas Distribuidas
Unidad 4 Manejo de transacciones
Una transacción en un Sistema de Gestión de Bases de Datos (SGBD), es un conjunto

de órdenes que se ejecutan formando una unidad de trabajo, es decir, en forma
indivisible o atómica.
Un SGBD se dice transaccional, si es capaz de mantener la integridad de los datos,

haciendo que estas transacciones no puedan finalizar en un estado intermedio. Cuando
94
por alguna causa el sistema debe cancelar la transacción, empieza a deshacer las órdenes
ejecutadas hasta dejar la base de datos en su estado inicial (llamado punto de
integridad), como si la orden de la transacción nunca se hubiese realizado.
Para esto, el lenguaje de consulta de datos SQL (Structured Query Language), provee
los mecanismos para especificar que un conjunto de acciones deben constituir una
transacción.
• BEGIN TRAN: Especifica que va a empezar una transacción.

• COMMIT TRAN: Le indica al motor que puede considerar la transacción
completada con éxito.
• ROLLBACK TRAN: Indica que se ha alcanzado un fallo y que debe restablecer
la base al punto de integridad.
En un sistema ideal, las transacciones deberían garantizar todas las propiedades ACID;
en la práctica, a veces alguna de estas propiedades se simplifica o debilita con vistas a
obtener un mejor rendimiento.
Un ejemplo de transacción
La transferencia de fondos entre dos cuentas corrientes de un banco. Si queremos

transferir, supongamos 5000.00 pesos de la cuenta corriente de A y B y las cuentas
tienen, respectivamente, 20000.00 pesos y 0.00 pesos de saldo los pasos lógicos serían:
1. Comprobar si en la cuenta A hay dinero suficiente.

2. Restar 5000.00 pesos de la cuenta de A, con lo que su saldo pasa a ser de
15000.00 pesos
3. Sumar 5000.00 pesos a la cuenta de B, con lo que los saldos quedan A=
15000.00 pesos y B= 5000.00 pesos Ahora bien, si entre el paso 2 y el 3 el
sistema sufre una parada o error inesperado las cuentas quedarían como A=
15000 y B= 0 con lo cual se han volatilizado 5000€ y presumiblemente ni A ni B
estarán contentos, y hubiesen preferido que la transacción nunca hubiese sido
iniciada.
Este ejemplo ilustra por qué las transacciones tienen un comportamiento deseado de
Todo o nada, o se realiza completamente o no debe tener ningún efecto.
4.1 Transacciones Conceptos
Toda transacción debe cumplir cuatro propiedades ACID:
En bases de datos se denomina ACID a un conjunto de características necesarias para

que una serie de instrucciones puedan ser consideradas como una transacción. Así pues,
si un sistema de gestión de bases de datos es ACID compliant quiere decir que el mismo
95
cuenta con las funcionalidades necesarias para que sus transacciones tengan las
características ACID.
En concreto ACID es un acrónimo de Atomicity, Consistency, Isolation and Durability:

Atomicidad, Consistencia, Aislamiento y Durabilidad en español.
1. Atomicidad (Atomicity): es la propiedad que asegura que la operación se ha

realizado o no, y por lo tanto ante un fallo del sistema no puede quedar a medias.
2. Consistencia (Consistency): es la propiedad que asegura que sólo se empieza
aquello que se puede acabar. Por lo tanto, se ejecutan aquellas operaciones que
no van a romper la reglas y directrices de integridad de la base de datos.
3. Aislamiento (Isolation): es la propiedad que asegura que una operación no puede
afectar a otras. Esto asegura que la realización de dos transacciones sobre la
misma información nunca generará ningún tipo de error.
4. Permanencia (Durability): es la propiedad que asegura que una vez realizada la
operación, ésta persistirá y no se podrá deshacer aunque falle el sistema.
La atomicidad frente a fallos se suele implementar con mecanismos de journaling, y la

protección frente a accesos concurrentes mediante bloqueos en las estructuras afectadas.
La serialibilidad viene garantizada por la atomicidad. La permanencia se suele
implementar forzando a los periféricos encargados de almacenar los cambios a
confirmar la completa y definitiva transmisión de los datos al medio (generalmente, el
disco).
La forma algorítmica que suelen tener las transacciones es la siguiente:
iniciar transacción (lista de recursos a bloquear)

ejecución de las operaciones individuales.
if (todo_ok){
aplicar_cambios
}
else{
cancelar_cambios
}
En cualquier momento, el programa podría decidir que es necesario hacer fallar la

transacción, con lo que el sistema deberá revertir todos los cambios hechos por las
operaciones ya hechas. En el lenguaje SQL se denomina COMMIT a aplicar_cambios y
ROLLBACK a cancelar_cambios.
Las transacciones suelen verse implementadas en sistemas de bases de datos y, más

recientemente, se han visto incorporadas a como gestiona un sistema operativo la
interacción con un sistema de archivos (como varias características de las bases de
datos, debido a que son muy similares arquitectónicamente).
96
Los principios básicos de cualquier sistema transaccional son los mismos. Sin embargo,
la terminología puede variar de un sistema a otro, los términos utilizados aquí no tienen
porque ser universales.
Rollback
Los gestores transacciones aseguran la integridad de las bases de datos registrando

todos los estados intermedios de una base de datos mientras se modifica. En caso de que
la transacción falle, se usan esos registros para devolver la base de datos a un estado
consistente. Por ejemplo, se copia información de la base de datos antes de que sea
modificada por una transacción, de tal manera que si parte de la transacción acaba
incorrectamente, se usan esas copias (llamadas before image) para restablecer la
integridad de los datos
Rollforward
También es posible mantener una copia (llamada after image) de todas aquellas
modificaciones realizadas sobre una base de datos. No es necesario para hacer rollback
de las transacciones que finalizaron incorrectamente, pero sí es útil para actualizar la
base de datos en un escenario de una recuperación.
Si la base de datos falla estrepitosamente, la restauración se debe iniciar desde la copia

de seguridad más reciente, aunque no reflejará aquellos cambios posteriores a la copia.
Sin embargo, una vez se ha restablecido la copia de seguridad se aplica la copia after
image que contendrá todas las modificaciones entre la copia de seguridad y el fallo de la
base de datos. Desgraciadamente, esta copia también contiene todas aquellas
modificaciones que estaban en vuelo en el momento del fallo. Por ello, es necesario
aplicar la copia before image que hará rollback de las transacciones con un estado
intermedio, devolviendo la base de datos a un estado seguro y consistente.
Commit
En el contexto de la Ciencia de la computación y la gestión de datos, commit (acción de

cometer) se refiere a la idea de hacer que un conjunto de cambios "tentativos, o no
permanentes" se conviertan en permanentes. Un uso popular es al final de una
transacción de base de datos.
Una sentencia COMMIT en SQL finaliza una transacción de base de datos dentro de un
sistema gestor de base de datos relacional (RDBMS) y pone visibles todos los cambios
a otros usuarios. El formato general es emitir una sentencia BEGIN WORK, una o más
sentencias SQL, y entonces la sentencia COMMIT. Alternativamente, una sentencia
ROLLBACK se puede emitir, la cual deshace todo el trabajo realizado desde que se
emitió BEGIN WORK. Una sentencia COMMIT publicará cualquiera de los
savepoints(puntos de recuperación) existentes que puedan estar en uso.
97
Bloqueos mutuos
En algunos casos, dos transacciones pueden en el transcurso de su ejecución, competir

por dos recursos al mismo tiempo de tal manera que impide seguir con su ejecución. Un
bloqueo mutuo (o interbloqueo, deadlock en inglés) ocurre, por ejemplo, cuando la
transacción A intenta acceder al área X de la base de datos mientras la transacción B
intenta acceder al área Y de la base de datos. Si, en algún punto intermedio, la
transacción A intenta acceder al área Y mientras al mismo tiempo la transacción B
intenta acceder al área X se genera un bloqueo mutuo que impide a ambas transacciones
progresar. Los sistemas transacciones están diseñados para detectar este tipo de
bloqueos cuando ocurren y actuar en concordancia. O bien ambas transacciones son
canceladas y el sistema hace rollback de todos los cambios para luego volver a
ejecutarlas automáticamente en diferente orden de tal forma que no se vuelva a formar
otro bloqueo mutuo, o bien cancelar y hacer rollback de una de ellas y volverla a lanzar
después de una pequeña espera
4.1.1 Estructura de Transacciones
Introducción
Una transacción es un conjunto de operaciones que van a ser tratadas como una única
unidad. Estas transacciones deben cumplir 4 propiedades fundamentales comúnmente
conocidas como ACID (atomicidad, coherencia, asilamiento y durabilidad).
La transacción más simple en SQL es una única sentencia SQL. Por ejemplo una
sentencia como esta:
UPDATE Products SET UnitPrice=20 WHERE ProductName =’Chai’
Esta es una transacción ‘autocommit’, una transacción autocompletada.

Cuando enviamos esta sentencia al SQL Server se escribe en el fichero de transacciones
lo que va a ocurrir y a continuación realiza los cambios necesarios en la base de datos.
Si hay algún tipo de problema al hacer esta operación el SQL Server puede leer en el
fichero de transacciones lo que se estaba haciendo y si es necesario puede devolver la
base de datos al estado en el que se encontraba antes de recibir la sentencia.
Por supuesto este tipo de transacciones no requieren de nuestra intervención puesto que
el sistema se encarga de todo. Sin embargo si hay que realizar varias operaciones y
98
queremos que sean tratadas como una unidad tenemos que crear esas transacciones de
manera explícita.
Sentencias para una transacción
Como decíamos una transacción es un conjunto de operaciones tratadas como una sola.
Este conjunto de operaciones debe marcarse como transacción para que todas las
operaciones que la conforman tengan éxito o todas fracasen.
La sentencia que se utiliza para indicar el comienzo de una transacción es ‘BEGIN

TRAN’.
Si alguna de las operaciones de una transacción falla hay que deshacer la transacción en
su totalidad para volver al estado inicial en el que estaba la base de datos antes de
empezar. Esto se consigue con la sentencia ‘ROLLBACK TRAN’.
Si todas las operaciones de una transacción se completan con éxito hay que marcar el
fin de una transacción para que la base de datos vuelva a estar en un estado consistente
con la sentencia ‘COMMIT TRAN’.
Un ejemplo
Trabajaremos con la base de datos Northwind.

Vamos a realizar una transacción que modifica el precio de dos productos de la base de datos.
USE NorthWind
DECLARE @Error int
--Declaramos una variable que utilizaremos para almacenar un posible código de error
BEGIN TRAN
--Iniciamos la transacción
UPDATE Products SET UnitPrice=20 WHERE ProductName =’Chai’
--Ejecutamos la primera sentencia
SET @Error=@@ERROR
--Si ocurre un error almacenamos su código en @Error
--y saltamos al trozo de código que deshara la transacción. Si, eso de ahí es un
--GOTO, el demonio de los programadores, pero no pasa nada por usarlo
--cuando es necesario
IF (@Error<>0) GOTO TratarError
--Si la primera sentencia se ejecuta con éxito, pasamos a la segunda
UPDATE Products SET UnitPrice=20 WHERE ProductName=’Chang’
SET @Error=@@ERROR
--Y si hay un error hacemos como antes
99
IF (@Error<>0) GOTO TratarError

--Si llegamos hasta aquí es que los dos UPDATE se han completado con
--éxito y podemos "guardar" la transacción en la base de datos
COMMIT TRAN
TratarError:
--Si ha ocurrido algún error llegamos hasta aquí
If @@Error<>0 THEN
BEGIN
PRINT ‘Ha ecorrido un error. Abortamos la transacción’
--Se lo comunicamos al usuario y deshacemos la transacción
--todo volverá a estar como si nada hubiera ocurrido
ROLLBACK TRAN
END
Como se puede ver para cada sentencia que se ejecuta miramos si se ha producido o no un error, y
si detectamos un error ejecutamos el bloque de código que deshace la transacción.
Hay una interpretación incorrecta en cuanto al funcionamiento de las transacciones que esta
bastante extendida. Mucha gente cree que si tenemos varias sentencias dentro de una transacción y
una de ellas falla, la transacción se aborta en su totalidad.
¡Nada más lejos de la realidad!

Si tenemos dos sentencias dentro de una transacción.
BEGIN ;
UPDATE Profesores SET ProfesorID=2000 WHERE Nom_prof='casiano';
UPDATE Profesores SET Ap_Pat="ibarra" WHERE Nom_prof='casiano';
commit
Estas dos sentencias se ejecutarán como una sola. Si por ejemplo en medio de la transacción (después del
primer update y antes del segundo) hay un corte de electricidad, cuando el SQL Server se recupere se
encontrará en medio de una transacción y, o bien la termina o bien la deshace, pero no se quedará a
medias.
100
El error está en pensar que si la ejecución de la primera sentencia da un error se cancelará la transacción.
El SQL Server sólo se preocupa de ejecutar las sentencias, no de averiguar si lo hacen correctamente o si
la lógica de la transacción es correcta. Eso es cosa nuestra.
Por eso en el ejemplo que tenemos más arriba para cada sentencia de nuestro conjunto averiguamos si se
ha producido un error y si es así actuamos en consecuencia cancelando toda la operación.
*****************
Puesta en práctica
Poner las características ACID en ejecución no es tan sencillo. El proceso de una

transacción requiere a menudo un número de cambios pequeños al ser realizado,
incluyendo la puesta al día de los índices que son utilizados en el sistema para acelerar
búsquedas. Esta secuencia de operaciones puede fallar por un número de razones; por
ejemplo, el sistema puede no tener ningún sitio disponible en sus accionamientos de
disco, o puede haber sobrepasado su tiempo de CPU asignado.
ACID sugiere que la base de datos pueda realizar todas estas operaciones
inmediatamente. De hecho esto es difícil de conseguir. Hay dos clases de técnicas
populares: escribir a un registro antes de continuar y la paginación de la sombra. En
ambos casos, los bloqueos se deben implantar antes que la información sea actualizada,
y dependiendo de la técnica puesta en práctica, todos los datos se tienen que haber leído.
En escribir a un registro antes de continuar, la atomicidad es garantizada

asegurándose que toda la información esté escrita a un registro antes que se escriba a la
base de datos. Eso permite que la base de datos vuelva a un estado anterior en caso de
un desplome. En sombrear, las actualizaciones se aplican a una copia de la base de
datos, y se activa la nueva copia cuando la transacción sea confiable. La copia refiere a
partes sin cambios de la vieja versión de la base de datos, en vez de ser un duplicado
entero.
Esto significa que debe realizarse un bloqueo en cualquier momento antes de procesar
datos en una base de datos, incluso en operaciones leídas. Mantener una gran cantidad
de bloqueos da lugar a un aumento substancial indirecto de los procesos así como a una
alteración de la concurrencia de ellos. Si el usuario A está procesando una transacción
que ha leído una fila de los datos que el usuario B desea modificar, por ejemplo, el
usuario B debe esperar hasta que el otro usuario acabe.
Una alternativa a la fijación es mantener copias separadas de cualquier dato que se

modifique. Esto permite a usuarios leer datos sin adquirir ningún bloqueo. Usando de
nuevo el ejemplo anterior, cuando la transacción del usuario consigue los datos que el
usuario B ha modificado, la base de datos puede recuperar la versión exacta de los datos
para que el usuario A comience su transacción. Esto asegura de que el usuario A
consiga una vista constante de la base de datos aunque otros usuarios estén cambiando
datos.
101
Es difícil garantizar características en un ambiente de red. Las conexiones de red

pudieron fallar, o dos usuarios pudieron utilizar la misma parte de la base de datos al
mismo tiempo.
El bifásico se aplica típicamente en transacciones distribuidas para asegurarse de que

cada participante en la transacción conviene aceptar si se debe confiar en la transacción
no.
Se debe tener cuidado cuando trabajan transacciones en paralelo. La fijación bifásica se

aplica típicamente para garantizar el aislamiento completo.
4.1.2 Ejecucion Transacciones Centralizada Distribuida
Transacciones distribuidas abarcan dos o más servidores conocidos como

administradores de recursos. La administración de la transacción debe ser coordinada
entre los administradores de recursos mediante un componente de servidor llamado
administrador de transacciones. Cada instancia de SQL Server Database Engine (Motor
de base de datos de SQL Server) puede funcionar como administrador de recursos en las
transacciones distribuidas que coordinan los administradores de transacciones, como el
Coordinador de transacciones distribuidas de Microsoft (MS DTC) u otros
administradores que admitan la especificación Open Group XA del procesamiento de
transacciones distribuidas
Una transacción de una sola instancia de Database Engine (Motor de base de datos) que
abarque dos o más bases de datos es, de hecho, una transacción distribuida. La instancia
administra la transacción distribuida internamente; para el usuario funciona como una
transacción local.
En la aplicación, una transacción distribuida se administra de forma muy parecida a una

transacción local. Al final de la transacción, la aplicación pide que se confirme o se
revierta la transacción. El administrador de transacciones debe administrar una
confirmación distribuida de forma diferente para reducir al mínimo el riesgo de que, si
se produce un error en la red, algunos administradores de recursos realicen
confirmaciones mientras los demás revierten la transacción. Esto se consigue mediante
la administración del proceso de confirmación en dos fases (la fase de preparación y la
fase de confirmación), que se conoce como confirmación en dos fases (2PC).
Fase de preparación
Cuando el administrador de transacciones recibe una solicitud de confirmación,

envía un comando de preparación a todos los administradores de recursos
implicados en la transacción. Cada administrador de recursos hace lo necesario
para que la transacción sea duradera y todos los búferes que contienen imágenes
del registro de la transacción se pasan a disco. A medida que cada administrador
de recursos completa la fase de preparación, notifica si la preparación ha tenido
éxito o no al administrador de transacciones.
102
Fase de confirmación
Si el administrador de transacciones recibe la notificación de que todas las

preparaciones son correctas por parte de todos los administradores de recursos,
envía comandos de confirmación a cada administrador de recursos. A
continuación, los administradores de recursos pueden completar la
confirmación. Si todos los administradores de recursos indican que la
confirmación ha sido correcta, el administrador de transacciones envía una
notificación de éxito a la aplicación. Si algún administrador de recursos informó
de un error al realizar la preparación, el administrador de transacciones envía un
comando para revertir la transacción a cada administrador de recursos e indica a
la aplicación que se ha producido un error de confirmación.
Las aplicaciones de Database Engine (Motor de base de datos) pueden administrar

transacciones distribuidas a través de Transact-SQL o de la API de base de datos.
4.1.3 Estructura de transacciones
La misma de 3.1.1.
4.2 Control de Concurrencia
El control de concurrencia trata con los problemas de aislamiento y consistencia del

procesamiento de transacciones. El control de concurrencia distribuido de una DDBMS
asegura que la consistencia de la base de datos se mantiene en un ambiente distribuido
multiusuario. Si las transacciones son internamente consistentes, la manera más simple
de lograr este objetivo es ejecutar cada transacción sola, una después de otra. Sin
embargo, esto puede afectar grandemente el desempeño de un DDBMS dado que el
nivel de concurrencia se reduce al mínimo. El nivel de concurrencia, el número de
transacciones activas, es probablemente el parámetro más importante en sistemas
distribuidos. Por lo tanto, los mecanismos de control de concurrencia buscan encontrar
un balance entre el mantenimiento de la consistencia de la base de datos y el
mantenimiento de un alto nivel de concurrencia.
Si no se hace un adecuado control de concurrencia, se pueden presentar dos anomalías.

En primer lugar, se pueden perder actualizaciones provocando que los efectos de
algunas transacciones no se reflejen en la base de datos. En segundo término, pueden
presentarse recuperaciones de información inconsistentes.
103
4.2.1 Serializacion de Transacciones
Teoría de la seriabilidad
Una calendarización (schedule), también llamado una historia, se define sobre un

conjunto de transacciones T = { T1, T2, ..., Tn } y especifica un orden entrelazado de la
ejecución de las operaciones de las transacciones. La calendarización puede ser
especificada como un orden parcial sobre T.
Ejemplo 6.1. Considere las siguientes tres transacciones:
T1: Read( x ) T2: Write( x ) T3: Read( x )

Write( x ) Write( y ) Read( y )
Commit Read( z ) Read( z )
Commit Commit
Una calendarización de las acciones de las tres transacciones anteriores puede

ser:
H1 = { W2(x), R1(x), R3(x), W1(x), C1, W2(y), R3(y), R2(z), C2, R3(z), C3 }
Dos operaciones Oij(x) y Okl(x) (i y k no necesariamente distintos) que accesan el mismo

dato de la base de datos x se dice que están en conflicto si al menos una de ellas es una
escritura. De esta manera, las operaciones de lectura no tienen conflictos consigo
mismas. Por tanto, existen dos tipos de conflictos read-write (o write-read) y write-
write. Las dos operaciones en conflicto pueden pertenecer a la misma transacción o a
transacciones diferentes. En el último caso, se dice que las transacciones tienen
conflicto. De manera intuitiva, la existencia de un conflicto entre dos operaciones indica
que su orden de ejecución es importante. El orden de dos operaciones de lectura es
insignificante.
Una calendarización completa define el orden de ejecución de todas las operaciones en

su dominio. Formalmente, una calendarización completa STc definido sobre un conjunto
de transacciones T = { T1, T2, ..., Tn } es un orden parcial STc = {  T, <T } en donde
1.  T =  i  i , para todos los i = 1, 2, ..., n

2. <T  i <i , para todos los i = 1, 2, ..., n
3. Para cualesquiera dos operaciones en conflicto Oij y Okl   T, ó Oij <T Okl ó
104
Okl <T Oij
La primera condición establece simplemente que el dominio de la calendarización es la

unión de los dominios de las transacciones individuales. La segunda condición define la
relación de ordenamiento como un superconjunto de la relación de ordenamiento de
transacciones individuales. Esto mantiene el ordenamiento de las operaciones dentro de
cada transacción. La condición final define el orden de ejecución entre dos operaciones
en conflicto.
Ejemplo 6.2. Considere las tres transacciones del Ejemplo 6.1, una posible
calendarización completa está dada por la siguiente gráfica dirigida acíclica
(DAG).
Una calendarización se define como un prefijo de una calendarización completa. Un

prefijo de un orden parcial se define como sigue. Dado un orden parcial P = {  , < },
P� = {  �, <� }, es un prefijo de P si
1.  �   i
2.  ei   �, e1 <� e2, si y solamente si, e1 < e2, y
3.  ei   �, si  ej   y ej < ei, entonces, ej   �
Las primeras dos condiciones definen a P� como una restricción de P en el dominio 

�, en donde las relaciones de ordenamiento en P se mantienen por P�. La última
condición indica que para cualquier elemento de  �, todos sus predecesores en 
deben ser incluidos también en  �.
Ejemplo 6.3. La siguiente calendarización es un prefijo de la calendarización

del Ejemplo 6.2.
Si en una calendarización S, las operaciones de varias transacciones no están

entrelazadas, esto es, si las operaciones de una transacción ocurren de manera
consecutiva, entonces se dice que la calendarización es serial. Si cada transacción es
consistente (obedece las reglas de integridad), entonces la base de datos se garantiza ser
consistente al final de la calendarización serial. La historia asociada a este tipo de
calendarización se le conoce como serial.
Ejemplo 6.4. La siguiente es una historia serial para el Ejemplo 6.1.
105
HS = { W2(x), W2(y), R2(z), C2, R1(x), W1(x), C1, R3(x), R3(y), R3(z), C3 }
Las transacciones se ejecutan de manera concurrente, pero el efecto neto de la historia

resultante sobre la base de datos es equivalente a alguna historia serial. Bassada en la
relación de precedencia introducida por el orden parcial, es posible discutir la
equivalencia de diferentes calendarizaciones con respecto a sus efectos sobre la base de
datos.
Dos calendarizaciones, S1 y S2, definidas sobre el mismo conjunto de transacciones T, se

dice que son equivalentes si para cada par de operaciones en conflicto Oij y Okl (i  k),
cada vez que Oij <1 Okl, entonces, Oij <2 Okl. A esta relación se le conoce como
equivalencia de conflictos puesto que define la equivalencia de dos calendarizaciones en
término del orden de ejecución relativo de las operaciones en conflicto en ellas.
Una calendarización S se dice que es serializable, si y solamente si, es equivalente por

conflictos a una calendarización serial.
Ejemplo 6.5. Las siguientes calendarizaciones no son equivalentes por

conflicto:
H1 = { W2(x), R1(x), R3(x), W1(x), C1, W2(y), R3(y), R2(z), C2, R3(z), C3 }
Las siguientes calendarizaciones son equivalentes por conflictos; por lo tanto H2

es serializable:
H2 = { W2(x), R1(x), W1(x), C1, R3(x), W2(y), R3(y), R2(z), C2, R3(z), C3 }
La función primaria de un controlador de concurrencia es generar una calendarización

serializable para la ejecución de todas las transacciones. El problema es, entonces,
desarrollar algoritmos que garanticen que únicamente se generan calendarizaciones
serializables.
4.2.2 Algoritmos de Control de Concurrencia
Taxonomía de los mecanismos de control de concurrencia
El criterio de clasificación más común de los algoritmos de control de concurrencia es

el tipo de primitiva de sincronización. Esto resulta en dos clases: aquellos algoritmos
que están basados en acceso mutuamente exclusivo a datos compartidos (candados) y
aquellos que intentar ordenar la ejecución de las transacciones de acuerdo a un conjunto
de reglas (protocolos). Sin embargo, esas primitivas se pueden usar en algoritmos con
dos puntos de vista diferentes: el punto de vista pesimista que considera que muchas
106
transacciones tienen conflictos con otras, o el punto de vista optimista que supone que
no se presentan muchos conflictos entre transacciones.
Los algoritmos pesimistas sincronican la ejecución concurrente de las transacciones en

su etapa inicial de su ciclo de ejecución. Los algoritmos optimistas retrasan la
sincronización de las transacciones hasta su terminación. El grupo de algoritmos
pesimistas consiste de algoritmos basados en candados, algoritmos basados en
ordenamiento por estampas de tiempo y algoritmos híbridos. El grupo de los algoritmos
optimistas se clasifican por basados en candados y basados en estampas de tiempo (Ver.
Figura 6.1).
Figura 6.1. Clasificación de los algoritmos de control de concurrencia.
Seriabilidad en SMBD distribuidos
En bases de datos distribuidas es necesario considerar dos tipos de historia para poder
generar calendarizaciones serializables: la calendarización de la ejecución de
transacciones en un nodo conocido como calendarización local y la calendarización
global de las transacciones en el sistema. Para que las transacciones globales sean
serializables se deben satisfacer las siguientes condiciones:
• cada historia local debe ser serializable, y

• dos operaciones en conflicto deben estar en el mismo orden relativo en todas las
historias locales donde las operaciones aparecen juntas.
La segunda condición simplemente asegura que el orden de serialización sea el mismo

en todos los nodos en donde las transacciones en conflicto se ejecutan juntas.
107
Ejemplo 6.6. Considere las siguientes tres transacciones:
T1: Read( x ) T2: Read( x )

xx+5 xx*5
Write( x ) Write( x )
Commit Commit
Las siguientes historias locales son individualmente serializables (de hecho son
seriales), pero las dos transacciones no son globalmente serializables.
LH1 = { R1(x), W1(x), C1, R2(x), W2(x), C2 }
LH2 = { R2(x), W2(x), C2, R1(x), W1(x), C1 }
4.2.2.1 Basados en Bloqueo
6.4 Algoritmos basados en candados
En los algoritmos basados en candados, las transacciones indican sus intenciones

solicitando candados al despachador (llamado el administrador de candados). Los
candados son de lectura (rl), también llamados compartidos, o de escritura (wl), también
llamados exclusivos. Como se aprecia en la tabla siguiente, los candados de lectura
presentan conflictos con los candados de escritura, dado que las operaciones de lectura y
escritura son incompatibles.
rl wl
rl si no
wl no no
En sistemas basados en candados, el despachador es un administrador de candados

(LM). El administrador de transacciones le pasa al administrador de candados la
operación sobre la base de datos (lectura o escritura) e información asociada, como por
ejemplo el elemento de datos que es accesado y el identificador de la transacción que
está enviando la operación a la base de datos. El administrador de candados verifica si el
elemento de datos que se quiere accesar ya ha sido bloqueado por un candado. Si
candado solicitado es incompatible con el candado con que el dato está bloqueado,
entonces, la transacción solicitante es retrasada. De otra forma, el candado se define
sobre el dato en el modo deseado y la operación a la base de datos es transferida al
procesador de datos. El administrador de transacciones es informado luego sobre el
resultado de la operación. La terminación de una transacción libera todos los candados y
se puede iniciar otra transacción que estaba esperando el acceso al mismo dato.
Candados de dos fases (2PL)
108
En los candados de dos fases una transacción le pone un candado a un objeto antes de
usarlo. Cuando un objeto es bloqueado con un candado por otra transacción, la
transacción solicitante debe esperar. Cuando una transacción libera un candado, ya no
puede solicitar más candados. Así una transacción que utiliza candados de dos fases se
comporta como en la Figura 6.2. En la primera fase solicita y adquiere todos los
candados sobre los elementos que va a utilizar y en la segunda fase libera los candados
obtenidos uno por uno.
La importancia de los candados de dos fases es que se ha demostrado de manera teórica

que todos las calendarizaciones generadas por algoritmos de control de concurrencia
que obedecen a los candados de dos fases son serializables.
Puede suceder que si una transacción aborta después de liberar un candado, otras
transacciones que hayan accesado el mismo elemento de datos aborten también
provocando lo que se conoce como abortos en cascada. Para evitar lo anterior, los
despachadores para candados de dos fases implementan lo que se conoce como los
candados estrictos de dos fases en los cuales se liberan todos los candados juntos
cuando la transacción termina (con commit o aborta). El comportamiento anterior se
muestra en la Figura 6.3.
Figura 6.2. Gráfica del uso de los candados de dos fases.
Figura 6.3. Comportamiento de los candados de dos fases estrictos.
109
6.4.1 Candados de dos fases centralizados
En sistemas distribuidos puede que la administración de los candados se dedique a un

solo nodo del sistema, por lo tanto, se tiene un despachador central el cual recibe todas
las solicitudes de candados del sistema. En la Figura 6.4 se presenta la estructura de la
comunicación de un administrador centralizado de candados de dos fases. La
comunicación se presenta entre el administrador de transacciones del nodo en donde se
origina la transacción (llamado el coordinador TM), el administrador de candados en el
nodo central y los procesadores de datos (DP) de todos los nodos participantes. Los
nodos participantes
son todos aquellos en donde la operación se va a llevar a cabo.
Figura 6.4. Comunicación en un administrador centralizado de candados de dos fases

estrictos.
La crítica más fuerte a los algoritmos centralizados es el "cuello de botella" que se

forma alrededor del nodo central reduciendo los tiempos de respuesta de todo el
sistema. Más aún, su disponibilidad es reducida a cero cuando se presentan fallas en el
nodo central.
6.4.2 Candados de dos fases distribuidos
En los candados de dos fases distribuidos se presentan despachadores en cada nodo del
sistema. Cada despachador maneja las solicitudes de candados para los datos en ese
nodo. Una transacción puede leer cualquiera de las copias replicada del elemento x,
obteniendo un candado de lectura en cualquiera de las copias de x. La escritura sobre x
requiere que se obtengan candados para todas las copias de x. La comunicación entre los
nodos que cooperan para ejecutar una transacción de acuerdo al protocolo de candados
distribuidos de dos fases se presenta en la Figura 6.5. Los mensajes de solicitud de
candados se envían a todos los administradores de candados que participan en el
sistema. Las operaciones son pasadas a los procesadores de datos por los
administradores de candados. Los procesadores de datos envía su mensaje de "fin de
operación" al administrador de transacciones coordinador.
110
4.2.2.2 Basados en Estampas de Tiempo
6.5 Algoritmos basados en estampas de tiempo
A diferencia de los algoritmos basados en candados, los algoritmos basados en estampas

de tiempo no pretenden mantener la seriabilidad por exclusión mutua. En lugar de eso,
ellos seleccionan un orden de serialización a priori y ejecutan las transacciones de
acuerdo a ellas. Para establecer este ordenamiento, el administrador de transacciones le
asigna a cada transacción Ti una estampa de tiempo única ts( Ti ) cuando ésta inicia. Una
estampa de tiempo es un identificador simple que sirve para identificar cada transacción
de manera única. Otra propiedad de las estampas de tiempo es la monoticidad, esto es,
dos estampas de tiempo generadas por el mismo administrador de transacciones deben
ser monotonicamente crecientes. Así, las estampas de tiempo son valores derivados de
un dominio totalmente ordenado.
Figura 6.5. Comunicación en candados de dos fases distribuidos.
Existen varias formas en que las estampas de tiempo se pueden asignar. Un método es
usar un contador global monotonicamente creciente. Sin embargo, el mantenimiento de
contadores globales es un problema en sistemas distribuidos. Por lo tanto, es preferible
que cada nodo asigne de manera autónoma las estampas de tiempos basándose en un
contador local. Para obtener la unicidad, cada nodo le agrega al contador su propio
identificador. Así, la estampa de tiempo es un par de la forma
<contador local, identificador de nodo>
Note que el identificador de nodo se agrega en la posición menos significativa, de

manera que, éste sirve solo en el caso en que dos nodos diferentes le asignen el mismo
contador local a dos transacciones diferentes.
El administrador de transacciones asigna también una estampa de tiempo a todas las

operaciones solicitadas por una transacción. Más aún, a cada elemento de datos x se le
asigna una estampa de tiempo de escritura, wts(x), y una estampa de tiempo de lectura,
rts(x); sus valores indican la estampa de tiempo más grande para cualquier lectura y
escritura de x, respectivamente.
111
El ordenamiento de estampas de tiempo (TO) se realiza mediante la siguiente regla:
Regla TO: dadas dos operaciones en conflicto, Oij y Okl, perteneciendo a las
transacciones Ti y Tk, respectivamente, Oij es ejecutada antes de Okl, si y
solamente si, ts(Ti) < ts(Tk). En este caso Ti se dice ser un transacción más vieja y
Tk se dice ser una transacción más joven.
Dado este orden, un conflicto entre operaciones se puede resolver de la siguiente forma:
for Ri(x) do begin for Wi(x) do begin
if ts(Ti) < wts( x ) then if ts(Ti) < rts(x) and
reject Ri(x) ts(Ti) < wts(x) then
else reject Wi(x)
accept Ri(x) else
rts(x)  ts(Ti) accept Wi(x)
end wts(x)  ts(Ti)
end
La acción de rechazar una operación, significa que la transacción que la envió necesita
reiniciarse para obtener la estampa de tiempo más reciente del dato e intentar hacer
nuevamente la operación sobre el dato.
Ordenamiento conservador por estampas de tiempo
El ordenamiento básico por estampas de tiempo trata de ejecutar una operación tan
pronto como se recibe una operación. Así, la ejecución de las operaciones es progresiva
pero pueden presentar muchos reinicios de transacciones. El ordenamiento conservador
de estampas de tiempo retrasa cada operación hasta que exista la seguridad de que no
será reiniciada. La forma de asegurar lo anterior es sabiendo que ninguna otra operación
con una estampa de tiempo menor puede llegar al despachador. Un problema que se
puede presentar al retrasar las operaciones es que ésto puede inducir la creación de
interbloqueos (deadlocks).
Ordenamiento por estampas de tiempo múltiples
Para prevenir la formación de interbloqueos se puede seguir la estrategia siguiente. Al

hacer una operación de escritura, no se modifican los valores actuales sino se crean
nuevos valores. Así, puede haber copias múltiples de un dato. Para crear copias únicas
se siguen las siguientes estrategias de acuerdo al tipo de operación de que se trate:
112
1. Una operación de lectura Ri(x) se traduce a una operación de lectura de x de una

sola versión encontrando la versión de x, digamos xv, tal que, ts(xv) es la estampa
de tiempo más grande que tiene un valor menor a ts(Ti).
2. Una operación de escritura Wi(x) se traduce en una sola version, Wi(xw), y es
aceptada si el despachador no ha procesado cualquier lectura Rj(xr), tal que,
ts(Ti) < ts(xr) < ts(Tj)
4.2.2.3 Pruebas Validación Optimistas
6.6 Control de concurrencia optimista
Los algoritmos de control de concurrencia discutidos antes son por naturaleza

pesimistas. En otras palabras, ellos asumen que los conflictos entre transacciones son
muy frecuentes y no permiten el acceso a un dato si existe una transacción conflictiva
que accesa el mismo dato. Así, la ejecución de cualquier operación de una transacción
sigue la secuencia de fases: validación (V), lectura (R), cómputo (C) y escritura (W)
(ver Figura 6.6a). Los algoritmos optimistas, por otra parte, retrasan la fase de
validación justo antes de la fase de escritura (ver Figura 6.6b). De esta manera, una
operación sometida a un despachador optimista nunca es retrasada.
Las operaciones de lectura, cómputo y escrita de cada transacción se procesan

libremente sin actualizar la base de datos corriente. Cada transacción inicialmente hace
sus cambios en copias locales de los datos. La fase de validación consiste en verificar si
esas actualizaciones conservan la consistencia de la base de datos. Si la respuesta es
positiva, los cambios se hacen globales (escritos en la base de datos corriente). De otra
manera, la transacción es abortada y tiene que reiniciar
Figura 6.6. Fases de la ejecución de una transacción a) pesimista, b) optimista.
Los mecanismos optimistas para control de concurrencia fueron propuestos

originalmente con el uso de estampas de tiempo. Sin embargo, en este tipo de
mecanismos las estampas de tiempo se asocian únicamente con las transacciones, no
con los datos. Más aún, las estampas de tiempo no se asignan al inicio de una
transacción sino justamente al inicio de su fase de validación. Esto se debe a que las
estampas se requieren únicamente durante la fase de validación.
113
Cada transacción Ti se subdivide en varias subtransacciones, cada una de las cuales se

puede ejecutar en nodos diferentes. Sea Tij una subtransacción de Ti que se ejecuta en el
nodo j. Supongamos que las transacciones se ejecutan de manera independiente y ellas
alcanzan el fin de sus fases de lectura. A todas las subtransacciones se les asigna una
estampa de tiempo al final de su fase de lectura. Durante la fase de validación se realiza
una prueba de validación, si una transacción falla, todas las transacciones se rechazan.
La prueba de validación se realiza con una de las siguientes reglas:
1. Si todas las transacciones Tk, tales que, ts( Tk ) < ts( Tij ), han terminado su fase
de escritura antes que Tij ha iniciado su fase de lectura entonces la validación
tiene éxito. En este caso la ejecución de las transacciones es completamente
serial como se muestra en la Figura 6.7a.
2. Si existe alguna transacción Tk, tal que, ts( Tk ) < ts( Tij ) y la cual completa su
fase de escritura mientras Tij está en su fase de lectura, entonces, la validación
tiene éxito si WS(Tk )  RS(Tij ) =  . En este caso, las fases de lectura y
escritura se traslapan, como se muestra en la Figura 6.7b, pero Tij no lee datos
queson escritos por Tk.
3. Si existe alguna transacción Tk, tal que, ts( Tk ) < ts( Tij ) y la cual completa su
fase de lectura antes que Tij termine su fase de lectura, entonces, la validación
tiene éxito si WS(Tk )  RS(Tij ) =  y WS(Tk )  WS(Tij ) =  . En este caso,
las fases de lectura se traslapan, como se muestra en la Figura 6.7c, pero las
transacciones no accesan datos comunes.
Figura 6.7. Casos diferentes de las pruebas de validación para control de concurrencia
optimista.
4.2.3 Disciplinas del Interbloqueo prevencion deteccion eliminacion y recuperacion
114
4.3 Confiabilidad
4.3.1 Conceptos Basicos de Confiabilidad
4.3.2 Protocolos Redo Undo
4.3.3 Puntos de Verificacion checkpoints
4.3.4 Protocolo 2PC de Confiabilidad Distribuida
115

Apuntes bdd2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Apuntes bdd2

Uploaded by

Copyright:

Available Formats

Instituto Tecnológico de Torreón

Apuntes de la Materia de Bases de Datos Distribuidas

Unidad 1 Fundamentos Bases de Datos Distribuidas Conceptos Básicos

1.2 Objetivos Bases de Datos Distribuidas

1.3 Disciplinas Estudio Bases de Datos Distribuidas

1.4 Arquitectura Bases de Datos Distribuidas

Unidad 2 Diseño de bases de datos distribuidas

2.1 Consideraciones Diseño Bases de Datos Distribuidas

2.2 Diccionario de Datos

2.3 Niveles de Transparencia

2.3.1 Transparencia de Localización

2.3.2 Transparencia de Fragmentación

2.3.3 Transparencia de Replica

2.4 Fragmentación de Datos

2.4.1 Fragmentación Horizontal

2.4.2 Fragmentación Vertical

2.4.3 Fragmentación Hibrida

2.5 Distribución de Datos

2.5.1 Algoritmos Distribución Datos No Replicados

2.5.2 Algoritmos Distribución Datos Replicados

Unidad 3 Procesamiento de consultas distribuidas

3.1 Metodología Procesamiento Consultas Distribuidas

3.2 Estrategias Procesamiento Consultas Distribuidas

3.2.1 Arboles de Consultas

3.2.2 Transformaciones Equivalentes Consultas Distribuidas

3.2.3 Métodos Ejecución del Join

3.3 Optimización de Consultas Distribuidas

3.3.1 Optimización Global Consultas Distribuidas

3.3.2 Optimización Local Consultas Distribuidas

Unidad 4 Manejo de transacciones

4.1 Transacciones Conceptos

4.1.1 Estructura de Transacciones

4.1.2 Ejecución Transacciones Centralizada Distribuida

4.1.3 Estructura de transacciones

4.2 Control de Concurrencia

4.2.1 Serializacion de Transacciones

4.2.2 Algoritmos de Control de Concurrencia

4.2.2.1 Basados en Bloqueo

4.2.2.2 Basados en Estampas de Tiempo

4.2.2.3 Pruebas Validación Optimistas

4.2.3 Disciplinas del Interbloqueo prevención detección eliminación y recuperación

4.3.1 Conceptos Básicos de Confiabilidad

4.3.2 Protocolos Redo Undo

4.3.3 Puntos de Verificación checkpoints

4.3.4 Protocolo 2PC de Confiabilidad Distribuida

Fundamentos Bases de Datos Distribuidas Conceptos Básicos

El procesamiento de bases de datos distribuidas es el procesamiento de bases de datos

Las Bases de Datos Distribuidas ( BDD ), no son simplemente implementaciones

Control Centralizado: La posibilidad de proporcionar control centralizado sobre los

La cantidad de innovaciones tecnológicas que ha habido en los últimos años ha

La presión por datos distribuidos

La presión de los usuarios

Figura 1.1. Fuerzas evolucionarias en los sistemas de bases de datos.

En la primera fase, se ha agrupando toda la información en un solo lugar. La idea

Algunos experimentos mostraron que el 90% de las operaciones de entrada y salida de

El hacer una descentralización de la información se justifica desde el punto de vista

• Para permitir autonomía local y promover la evolución de los sistemas y los

• Para proveer una arquitectura de sistemas simple, flexible y tolerante a fallas.

• Para ofrecer buenos rendimientos.

Aunque la idea de distribución de datos es bastante atractiva, su realización conlleva la

• Asegurar que el acceso entre diferentes sitios o nodos y el procesamiento de

• Transformar datos e integrar diferentes tipos de procesamiento entre nodos de un

• Controlar el acceso a los datos disponibles en el ambiente distribuido.