apuntes bdd2

Instituto Tecnológico de TorreónApuntes 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

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

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

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

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

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

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

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

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

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

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

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

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

http://www.mitecnologico.com/Main/ConsideracionesDise%F1oBasesDeDatosDistribuidas

http://www.mitecnologico.com/Main/Dise%F1oDeBasesDeDatosDistribuidas

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

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

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

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



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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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



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 DatosLos 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

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



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 DatosLos 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 “ACIDtest” 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 bienpasan a ser todos deshechos (rollback). Es decir, o todos los cambios incluidos en una transacción tienenefecto o no lo tiene ninguno.4Consistencia: las bases de datos se transforman de estados íntegros a estados íntegros, es decir, entreestados válidos. Una transacción sólo se puede completar si el estado final es íntegro.Aislamiento: los resultados de una transacción son invisibles para el resto de transacciones de otrosprocesos hasta que la transacción se ha completado.Durabilidad o permanencia: una vez una transacción ha sido completada, los resultados (cambios) de latransacció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 laspropiedades 3 y 4 comentadas al principio.1.1.2. Sistemas de Base de Datos RelacionalesAl menos un investigador de IBM no estaba satisfecho ni con los productos Codasyl, ni con los sistemasjerárquicos de la propia IBM. Edgar F. (Ted) Codd, un matemático formado en Oxford, que había entrado enIBM en 1949, empezó a trabajar en una serie de informes técnicos acerca de una manera ‘nueva’ de organizar yacceder a los datos. A partir de estos trabajos publicó el artículo “A Relational Model of Data for Large SharedData Banks” en 1970 [Codd 1970]. Codd propuso que los sistemas de bases de datos deberían presentarse a losusuarios con una visión de los datos organizados en estructuras llamadas relaciones. Las relaciones se definencomo conjuntos de tuplas, no como series o secuencias de objetos, con lo que el orden no es importante. Portanto, detrás de una relación puede haber cualquier estructura de datos compleja que permita una respuestarápida a una variedad de consultas. Además, aunque no es un aspecto intrínseco del modelo relacional, según lapropuesta de Codd, el usuario de un sistema relacional no tenía que preocuparse de la estructura dealmacenamiento, sólo debía preocuparse por el qué consultar y no el cómo. Hoy en día es válido todavía elresumen 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 unaffectedwhen the internal representation of data is changed and even when some aspects of the external representation arechanged. Changes in data representation will often be needed as a result of changes in query, update, and report trafficand natural growth in the types of stored information.”1Además, las consultas podían expresarse en un lenguaje de muy alto nivel, lo que incrementaba en gran medida laeficiencia de los programadores sobre bases de datos. En resumen, Codd concibió un sistema donde el usuariosería capaz de acceder a la información con comandos parecidos al lenguaje natural y donde la informaciónestuviera almacenada en ‘tablas’.Pese a sus virtudes, la aceptación del modelo relacional no fue inmediata, debido en parte a la naturalezatécnica del artículo y a su base matemática que, aunque muy simple, no era común para la industria de bases dedatos de la época. Además, se dudaba de la eficiencia del modelo. Más aún, dentro de IBM, la reticencia fue muygrande, ya que IBM había invertido una gran cantidad de esfuerzo y dinero en el producto ya existente IMS ylíder del mercado. La nueva tecnología relacional debía demostrar que era mucho mejor que la existente paracambiar la situación. De hecho, Codd publicó el artículo en una revista de ámbito científico y abierto porquenadie en IBM (ni siquiera él mismo) reconoció en su momento el impacto que tendría después. Todos sesorprendieron pronto de que la respuesta externa al artículo fuera muy positiva. Incluso se acogió la idea contodo su potencial comercial. La reacción inicial de IBM fue tajante: declaró IMS su producto estratégico conexclusividad y consideró el modelo relacional como contrario a sus intereses. Codd, por su parte, no cedió en sudefensa pública de las ventajas de su propuesta e incluso mantuvo un debate público con Charles Bachman, elmayor 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 estapublicidad, desde fuera, la Universidad de California en Berkeley creyó en la idea del modelo relacional y obtuvofinanciació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 lamá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 larepresentación externa. Se necesitará cambiar la representación de los datos a menudo como resultado de los cambios en el tráfico de lasconsultas, actualizaciones e informes y como consecuencia del crecimiento natural en los tipos de información almacenada.”5La contra-reacción de IBM fue inmediata, puso en marcha el desarrollo de otro sistema relacional, el “SystemR”2.El grupo de investigación de IBM a cargo del proyecto esperaba crear un sistema de bases de datos relacionalque pudiera convertirse eventualmente en un producto. Su primer prototipo, elaborado entre 1974 y 1975, seutilizó 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” comoun 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 laUniversidad 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 etal. 1976], aunque el producto se revisó continuamente durante toda la década con los comentarios yrealimentación de muchos usuarios en otras Universidades y centros que lo adaptaban a sus cada día más baratasmáquinas DEC (el código fuente del Ingres era inicialmente público) [Stonebraker 1980]. Ingres incluía su propiolenguaje 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 deIBM) 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 elsistema 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 porel 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) delCODAYSL/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 yesquema 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 usodiferenciado 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 dedesarrollo 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 lapresión de otra compañía, en este caso Oracle, creada por Larry Ellison, la que, al desarrollar y vender unproducto compatible con SQL, hizo reaccionar a IBM. Es importante destacar que Ellison había conocido elSQL a partir de las publicaciones del System R. Del mismo modo, la amenaza de otros productos, como losdesarrollados por Software AG, motivaron a IBM a continuar investigando en la línea de System R. Estainvestigació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 operatingsystem/virtual storage extended) y VM/CMS (virtual machine/conversational monitoring system); en 1983 seintrodujo DB2 para el sistema operativo MVDS. En el desarrollo de estos productos, IBM introdujo ideaspioneras en la optimización de consultas, en la independencia de datos del esquema externo (vistas), en lastransacciones (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 InformixInc.; 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 relacionalaparecieron 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 aincorporar 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 elCálculo Relacional de Tuplas o Dominios. De hecho fue el propio Codd quien presentó el Cálculo Relacionalcomo alternativa al álgebra relacional en [Codd 1971]. Con el tiempo se realizaron diversas generalizaciones de2 Una historia del System R se puede encontrar en [Chamberlin 1998] o en (http://www.mcjones.org/System_R/).6ambos 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 álgebrarelacional 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). Laequivalencia entre consultas incluyendo unión se demostró decidible en [Sagiv & Yannakakis 1980]. La noción deoptimización semántica de consultas se basa en transformaciones que preservan la equivalencia sólo cuandoalgunas 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 propiedadescomo 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 ellenguaje estándar de consultas. Como hemos dicho, la versión original de SQL se desarrolló como el lenguaje deconsulta del proyecto System R de IBM [Boyce & Chamberlin 1974], [Chamberlin et al. 1976]. Gracias a susvirtudes (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 StandardInstitute) en 1982, formándose el comité X3H2. que junto a la ISO (International Standard Organization) publicael 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 haconvertido en el lenguaje de consulta más utilizado. En 1999 apareció SQL3 [ANSI/ISO/IEC 1999] y, desdeentonces, 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 deconsulta a base de datos “visual”, que influyó de manera importante a otros productos del mismo estilo comoParadox de Borland o Access de Microsoft.Las dependencias funcionales también se introdujeron en [Codd 1970], junto con el concepto de terceraformal normal. Los axiomas para inferir dependencias funcionales y que caracterizan a las mismas se presentaronen [Armstrong 1974]. La BCNF (Boyce Codd Normal Form) se introdujo en [Codd 1972a]. El concepto decobertura mínima fue introducido por [Paredaens 1977]. Los algoritmos para el cálculo de coberturas noredundantes se introdujo en [Beeri & Bernstein 1979]. En [Maier 1983] se puede encontrar una recopilación detodos estos resultados.La razón y uso de las formas normales es evitar la repetición innecesaria de datos (redundancia). Una solucióna este problema es repartirlos en varias tablas y utilizar referencias por valor entre ellas. Este es el ejemplo típicode que la tupla de cada empleado no debe repetir toda la información de su departamento, sino que debe utilizaruna referencia por valor a la tupla de la relación departamento donde estén todos estos datos. Esteprocedimiento ahorra espacio de almacenamiento y al evitar la redundancia evita modificaciones parciales oincompletas que podrían dar lugar a inconsistencias.Este proceso se conoce como normalización. Generalmente se habla de seis formas normales, de la formanormal 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) setienen 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 ciertohasta la tercera forma normal. A partir de ahí se utiliza mucho espacio para referencias por valor. Del mismomodo puede parecer que una normalización extrema podría reducir el tiempo para procesar las consultas, ya quelos 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 eltiempo necesario para concatenar las tablas. Por esta razón, en la práctica, la mayoría de organizaciones lleganhasta la tercera normal (ya introducias en [Codd 1970] como hemos dicho) a no ser que exista alguna otra razónpara normalizarlas más.Por todo lo anterior, en 1980, la ACM (Association for Computer Machinery) otorgaba a Codd el “TuringAward”, uno de los premios más prestigiosos en el campo de la informática. El modelo relacional era imparable.7Aún así, todavía a principios de los ochenta existían numerosas voces dispares al modelo relacional. Estareacción al cambio venía fundamentada en ideas erróneas sobre los sistemas de bases de datos relacionales. Sedecía que se necesitaban conocimientos teóricos para utilizar bases de datos relacionales, que la teoría de lanormalización limitaba el uso de los mismos, que el rendimiento de los SGBDR era malo, que el modelorelacional era muy pobre y también era muy rígido. Estos mitos (recogidos con ironía en [Gardarin & Valduriez1987]), fueron cayendo con el tiempo.Teniendo en cuenta todo lo anterior, la aceptación del modelo relacional se puede considerar hoy en díacomo generalizada. En libros de hace poco más de una década, el modelo relacional aparecía a la par con losotros 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 dedatos relacionales” (p.ej. [Delobel & Adiba 1985] [Gardarin & Valduriez 1987]) se atrevían a centrarse en estemodelo. En los libros genéricos sobre bases de datos, los modelos navegacionales han sido desplazados aapéndices o han desaparecido completamente de los mismos. Bien es cierto que su lugar ha sido ocupado por elmodelo 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” comoabstracció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 deSGBD tradicionales (red, jerárquicos y otros pre-relacionales):VENTAS MUNDIALES DE SGBD 1991-19991991 1992 1993 1994 1995 1996 1997 1998 1999 Crec. Medio1994-1999Pre-relacional 2.000 2.090 2.109 2.050 1.866 1.721 1.701 1.689 1.638Crecimiento - 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,3Relacional 1.844 2.502 3.328 4.435 5.925 7.652 9.513 11.685 14.254Crecimiento - 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,7SGBD total 3.844 4.592 5.437 6.485 7.791 9.373 11.214 13.374 15.892Crecimiento - 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 sealmacenan en hojas de cálculo en vez de bases de datos, y que un porcentaje importante de los datos deproducción todavía se encuentran en sistemas heredados (legacy systems), es decir, sistemas tecnológicamenteobsoletos 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 laindustria o por la defensa a ultranza de soluciones peores por gigantes de la informática. En este caso, si no sehubiera producido el desarrollo por parte de la Universidad de California en Berkeley del sistema Ingres, IBM nohabría visto ninguna amenaza en el modelo relacional, y no habría invertido esfuerzos en el System R. Tambiénfue importante la difusión del código de las primeras versiones del Ingres, lo que permitió a la comunidadcientífica experimentar con las ideas relacionales [NAP 1999]. Esto refuerza el papel de institucionesindependientes, como las Universidades, para no sólo generar nuevas tecnologías sino promoverlas (aunque seanajenas, como en el caso del modelo relacional), cuando las empresas grandes no tienen interés en perder suscuotas de mercado.Respecto al modelado de bases de datos, aparece la noción de modelo semántico, es decir, modelos dedicadosespecí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 deciertas particularidades. El modelo entidad relación (ER) fue propuesto por [Chen 1976]. La generalización y laagregación se propusieron en [Smith & Smith 1977]. El modelo ER con estas dos extensiones se conoce comomodelo entidad relación extendido (ERE). Debido a la simplicidad de este modelo, su expresividad y larelativamente sencilla transformación de este modelo a un esquema lógico relacional se popularizó rápidamentecomo herramienta para representar el modelo conceptual de un sistema de información, creando la clásicaseparación en las etapas del desarrollo de un sistema de información: diseño conceptual, diseño lógico, diseño8físico e implantación. El modelo ER era exclusivamente estático, expresaba las entidades de la realidad y susrelaciones. El diseño conceptual basado en los Diagramas ER (ERD) adolecía, por tanto, de dinámica. Para paliaresta 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 detransaccionales. El modelo entidad relación ha tenido una influencia muy importante en otros lenguajes demodelado utilizados en ingeniería del software, incluso en los orientados a objetos. Posteriormente al modeloER, aparecieron otros modelos, como el SDM de [Hammer & MacLeod 1981], el FDM (DAPLEX) de [Shipman1981] 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 larealimentación de los clientes, el desarrollo de sistemas para nuevas industrias que no solían utilizar SGBDs y eluso 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 cuartageneración (los 4GLs). Dentro de estos lenguajes se podía utilizar el SQL embebido (embedded SQL). Por SQLembebido se entiende el uso de comandos SQL dentro de un lenguaje de programación, p.ej. lenguajes genéricoscomo 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 lasrestricciones que se impongan sobre la base de datos. Otro de los usos de rápido crecimiento de los 4GL fue lade 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 demanipulación (adaptando SQL) y la acción se expresaba en 4GL (que a su vez podía contener sentencias delenguaje 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 decontrol: 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 paradiferentes 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 unsistema central con su SGBD además de otros SGBD sobre ordenadores personales. Que estos SGBD seinterrelacionaran y pudieran compartir sus datos era fundamental. Ya no sólo el poder importarlos o exportarlosentre los distintos SGBD, sino poder acceder a ellos, es decir utilizar un SGBD para acceder a los datos quegestionaba otro SGBD. Como esta problemática era mayor cuando se combinaban sistemas centrales conpersonales, aparecieron protocolos para la conectividad entre bases de datos. El estándar más utilizado es elODBC (Open Database Connectivity) de Microsoft que sirve tanto para conectar bases de datos como para quelas aplicaciones puedan acceder a diferentes bases de datos. Aparece el concepto de “fuente de datos”, en el queincluso el SGBD que lo gestiona puede pasar desapercibido.El ODBC (http://www.microsoft.com/data/odbc/) es una API (Applications Programming Interface) paraenlazar aplicaciones con una base de datos. Se diseñó por Microsoft como un modo de que los programas seconectaran a una base de datos sin tener que usar los comandos y características específicos del SGBD. Loscomandos ODBC se utilizan en los programas y luego se traducen en los comandos específicos por la interfazODBC 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 versionesque van apareciendo.Existen muchas otras características desarrolladas durante los ochenta y los noventa que se asocian con elmodelo relacional, auqneu son tecnologías en su mayor parte independientes del modlo. Quizás desde un puntode vista más teórico, el modelo relacional sí que ha generado muchos avances propios a él, en general ligados a lavisión de una base de datos relacional como una teoría lógica, lo que ha permitido portar los avances de laprogramación lógica, como comentaremos.Para una referencia actualizada y rigurosa sobre el modelo relacional se recomienda [Levene & Loizou 1999].91.1.3. Bases de Datos Orientadas a ObjetosAlrededor de la mitad de los ochenta, algunas aplicaciones exigían mayor expresividad en los datos con los quetrabajaban. Por ejemplo, las bases de datos médicas, las bases de datos multimedia y algunas bases de datoscientí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 ámbitoindustrial, los investigadores se plantearon transportar estas ideas a las bases de datos y permitir que el tipo dedatos marcara cómo se representaba y se manipulaba dependiendo de los métodos que se definían para dichotipo 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 principiosde los noventa fue el sistema ObjectStore [Lamb et al. 1991]. Al principio de los noventa, los primeros Sistemasde Gestión de Bases de Datos Orientados a Objetos (SGBDOO, o simplemente, SGBDO) empezaron aaparecer 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 filaen una tabla. Esto, en principio, lo hace más eficiente en términos de requerimientos de espacio y asegura que losusuarios puedan manipular los datos sólo de las maneras en las que el programador haya especificado. Tambiénes 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 quesumar las ventajas derivadas del modelo orientado a objetos, ya explotadas en sus lenguajes de programación, lamayor 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 lapráctica a las relacionales. De hecho, a veces se denominan postrelacionales. No obstante, después de más 15años, el mercado de las bases de datos orientadas a objetos no supone más de un 5% del mercado de lasrelacionalesLa situación no ha variado significativamente en los últimos años, y, en el ejercicio 2001, de los 8.844 millones dedólares de ingresos por nuevas licencias, 7.107 millones de dólares correspondieron a sistemas relacionales. Estosupone un 80,4% de los nuevos sistemas, con lo que no parece haber ninguna señal clara de que la situación vaya acambiar en el futuro [Graham 2002]. Más aún si tenemos en cuenta que los mercados de los SGBD prerelacionalesy objetuales tuvieron un incremento negativo en 2000, mientras que los relacionales crecieron un15% [IDG 2001] [SMITT 2002].Hay varias razones para explicar este hecho. En primer lugar, las bases de datos objetuales acarrean consigoalgunas de las propiedades no deseables de los modelos pre-relacionales. El programador tiene que tener muchainformación sobre la estructura de los datos. Si se conocen las propiedades de los objetos, la consulta es rápida ysimple. Pero la realidad es que en muchos casos se desconocen las identidades de los objetos. Lo que preocupa ointeresa es almacenar los atributos de los objetos y relacionar los valores de estos atributos, aspecto en el que elmodelo relacional es más sencillo.En segundo lugar, el hecho de que las organizaciones sean capaces de alterar los métodos de bajo nivelutilizados en los SGBDO, hace que sea más difícil para terceros el hacer productos añadidos. Mientras que lasbases de datos relacionales se pueden beneficiar del software realizado por otras firmas, los usuarios de SGBDOtienen que producir el software en casa para adaptarse a sus propias particularidades, parte de ellas incorporadasal comportamiento de los objetos.En tercer lugar y quizás más importante es el hecho que las organizaciones tiendan a ser conservadoras enrelación con las bases de datos, uno de sus activos más valiosos. Muchas organizaciones aunque utilizan lenguajesorientados 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 coninformación crucial para la organización. Mito o realidad, el hecho es que no acaban de decidirse por embarcarseen un SGBDO y siguen aferrados al SQL para realizar sus informes y al SQL embebido para interrelacionar lasaplicaciones 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énevolucionar o desarrollarse nuevos modelos conceptuales y metodologías orientadas a objetos. El modeloentidad relación (extendido) se mostró insuficiente para la etapa de diseño conceptual de bases de datosorientadas a objetos. Para ello se importaron o adaptaron lenguajes de modelado e incluso gran parte de lasmetodologías utilizadas en ingeniería del software orientada a objetos. Por ejemplo, la metodología Object ModelingTechnique (OMT) desarrollada a principios de los noventa en General Electric [Rumbaugh et al. 1996], la11metodologí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 softwareorientado a objetos, se han ido adaptando o importando al campo de las bases de datos como herramienta demodelado 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 supuestoquizás el mayor gran impulso a este modelo de datos desde su introducción en los ochenta. El cuerpo principaldel lenguaje de modelado unificado UML se desarrolló principalmente a principio de los noventa, por un grupode ‘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 elODMG (del que hablaremos más abajo) y el hecho de haberse estandarizado un lenguaje de modelado orientadoa objetos y que éste esté basado en lo “mejor” de otras metodologías anteriores, hace que la adaptación deprofesionales 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 eldiseño de bases de datos orientadas a objetos. Especialmente lo hace apropiado para que los especialistas enbases 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 unametodologí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 quedesarrollan estándares para los SGBDO (www.odmg.org). El primer documento fue el ODMG 1.0 in 1993, queincluí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 queSQL3 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 lenguajesorientados a objetos más populares: C++, Smalltalk y Java. La especificación del ODMG 3.0 se puede encontraren (www.odmg.org), en [ODMG 2000] o en [Cattell & Bary 2000]. Para una información más general sobre lasbases 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 unatecnología en sí, sino una aglutinación de los modelos relacional y orientado a objetos. De hecho, algunasextensiones 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 nuevostipos 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 pordiversos motivos.Además, el mantenimiento de los SGBDR empezaba a crear desajustes con un cada día más generalizado usode los lenguajes orientados a objetos. Los programadores en estos lenguajes tenían que realizar una serie de pasosde traducción de la estructura objetual del programa y de los datos en memoria principal a la estructura relacionalde los datos.Aquí es donde el modelo objeto-relacional puede demostrar su valor. El modelo objeto-relacional se definecomo una extensión objetual del modelo relacional, permitiendo la definición de nuevos tipos y de relaciones deherencia, 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 utilizargradualmente características orientadas a objetos, especialmente si se hace en conjunción con aplicacionesdesarrolladas en entornos también orientados a objetos.Uno de los ejemplos de este mestizaje es, por ejemplo, JDBC (Java DataBase Connectivity). Aunque pensadopara 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 SunMicrosystems (http://java.sun.com/products/jdbc/index.html) para conectar Java con las bases de datos, conuna filosofía inspirada en ODBC. De hecho es usual conectar un programa Java con una base de datosdirectamente o a través de ODBC, dependiendo de si el fabricante de la base de datos ha creado los driversnecesarios para Java.12Otro ejemplo de mestizaje a un nivel diferente es el SQL3 [ANSI/ISO/IEC 1999]. SQL3 es la nueva versióndesarrollada por los comités ANSI X3H2 e ISO DBL para extender SQL2 con el tratamiento de datosorientados a objetos (entre otras cosas). Hablamos de mestizaje porque esta extensión se ha hecho de tal maneraque 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. Laspartes del SQL3 que proporcionan la base para trabajar con estructuras orientadas a objetos son: tipos definidospor el usuario (user-defined types, UDTs), constructores de tipo para tipos de fila y tipos referencia, tiposconstructores 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) deSQL, 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 enuna única entidad o clase, que en SQL3 se llama tipo. En concreto en SQL3 se define un UDT declarando losatributos que almacenan el valor y estado del UDT, definiendo las operaciones de igualdad y de orden para eltipo, y, finalmente, definiendo las operaciones que determinan el comportamiento específico del UDT. Lasoperaciones (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 <nombredel UDT >” en la parte de subtipo de una definición UDT, se puede definir un UDT como un subtipo (lo que seconoce normalmente como especialización, clase derivada o subclase) de un UDT existente. Un subtipo heredatodos los atributos y el comportamiento de sus supertipos y se pueden extender con más atributos y variar sucomportamiento. Una instancia de un subtipo se puede utilizar en cualquier lugar donde una de las instancias desus supertipos se pueda utilizar. De momento, SQ3 no soporta la herencia múltiple, con lo que un UDT puedetener como mucho un supertipo.A pesar de todas estas extensiones, la estructura principal de representación lógica del SQL3 sigue siendo latabla, con lo que el modelo subyacente del SQL3 se puede considerar objeto-relacional.1.1.5. Bases de Datos Paralelas y DistribuidasLas 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 generalfuncionando 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 loscampos 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 latecnología del futuro en cuanto a altas prestaciones. Hoy en día la postura es más realista y se reconoce su uso ensistemas de muy altas prestaciones, aunque para sistemas de uso corriente, incluso grandes empresas, su uso esmás limitado.No obstante, por muy paralelo que fuera el sistema, todo ordenador tiene su límite. Aunque la capacidad deproceso aumentara, existían limitaciones en la cantidad de memoria que el sistema direccionaba, el número dediscos duros que podían conectarse a un mismo procesador y el número de procesadores que podían correr enparalelo. En la práctica, esto significa que, a medida que la cantidad de información de una gran base de datosaumenta, un único sistema, aunque sea paralelo, deja de poder dar abasto con toda la información que tiene quealmacenarse, 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 unaorganización. En cambio, es mucho más realista tener varios servidores de bases de datos e ir añadiendo amedida que la organización necesita más capacidad. Esto se debe hacer de manera que los usuarios crean quesiguen trabajando con un único sistema, el sistema integrado de la organización. Mediante esta filosofía, laorganización tiene más flexibilidad en sus ampliaciones, se realizan de una manera menos traumática y conordenadores de talla media, que suelen ser mucho más baratos que uno grande equivalente en potencia.13Este concepto lleva al paradigma de las bases de datos distribuidas3, y tienen las características comunes deque los datos se almacenan en dos o más ordenadores, llamados nodos, y que estos nodos están conectados enuna red. Hoy en día, con el aumento de la descentralización, debido al abaratamiento, ancho de banda yflexibilidad de las redes de computadores, ha hecho que el uso de las bases de datos distribuidas haya aumentadoconsiderablemente.Si hablamos de un único sistema de gestión de bases de datos que actúa sobre distintos ordenadoresdistribuidos y gestionando la misma base de datos, hablamos propiamente de bases de datos distribuidas. En elcaso que cada sistema esté formado por varios SGBD, se suele hablar de Sistemas de Múltiples Bases de Datos, quepueden estar fuertemente acoplados o débilmente acoplados, llamándose estos últimos sistemas interoperantesde bases de datos [Litwin & Chien 1994].Sin entrar en demasiadas distinciones terminológicas entre los sistemas de bases de datos distribuidos y lossistemas de múltiples bases de datos, o si los datos pueden o no estar replicados, el punto fundamental de todosestos sistemas es que los usuarios no deben percatarse de esta dispersión espacial de los datos, es decir, losusuarios 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 yheterogéneos.Las bases de datos distribuidas homogéneas usan el mismo software de SGBD y tienen las mismasaplicaciones en cada nodo. Tienen un esquema común y pueden tener grados diversos de autonomíalocal. Pueden estar basadas en cualquier SGBD que soporte estas características, pero no puede habermá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 sinautonomía local, donde todas las peticiones se envían a un nodo central, llamado gateway. Desde aquí seasigna al nodo que contiene esa información o aplicación requerida. Esto es lo típico que se ve con losmirrors de sitios web muy populares a los cuales una página central deriva las peticiones de sus usuariosdependiendo de su origen geográfico.En el otro lado de la escala, se encuentran las bases de datos heterogéneas con un alto grado deautonomía local. Cada nodo en el sistema tiene sus propios usuarios, aplicaciones y datos locales y es elsistema el que trata con ellos directamente y sólo conecta con otros nodos en busca de información queno tiene. Este tipo de base de datos se suele llamar sistema federado o federación. Se ha hecho cada día máspopular en las organizaciones, tanto por su escalabilidad, su capacidad de mezclar distintos paquetessoftware y su reducido coste al añadir nuevos nodos cuando es necesario. A diferencia de los sistemashomogéneos, los sistemas heterogéneos pueden incluir diferentes SGBD en los nodos. Esto los haceatractivos en grandes corporaciones, ya que pueden mantener sus sistemas heredados antiguos (legacysystems) junto con los nuevos sistemas.Uno de los primeros sistemas distribuidos fue R*, desarrollado en IBM [Williams et al. 1998] a principios de losochenta. Últimamente el área de las bases de datos distribuidas está cada vez más en relación con Internet y latecnología web, hablándose de bases de datos distribuidas de área global [Stonebraker et al. 1996]. Una fuenteactual sobre sistemas de bases de datos distribuidas se puede encontrar en [Ozsu & Valduriez 1999]1.1.6. Bases de Datos MultimediaLas 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 altamaño de los objetos y la complejidad de los datos. El añadir metadatos a los ficheros multimedia (p.ej. elformato WAV) resolvía parcialmente el problema. Esta cabecera incluye datos del formato, el creador, elcontenido, la longitud del stream de datos, etc. El problema es que está información no suele estar indizadaconveniente 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, dequé va, cuánto duró, etc. Esta información es la que se utilizará cuando los usuarios busquen clases en la base dedatos.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ássutil, y existen muchos sistemas híbridos.14Hay dos métodos principales para incluir metadatos en una base de datos multimedia: mediante análisisautomático o mediante análisis manual [Chorafas 1994]:Aunque el análisis manual es más efectivo, porque permite anotar aquellas características del objetomultimedia que son importantes, requiere mucho tiempo y por tanto es muy costoso. Además es difícilconseguir 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 consistentede 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 ordenadorespersonales, el abaratamiento de discos con gran capacidad de almacenamiento, hace que cualquier ordenadorpersonal pueda contener una biblioteca de imágenes y piezas musicales, y en breve, de películas. Otro problemaes el uso de estas bases de datos para distribución por Internet (especialmente VoD, Video on Demand), para elcual 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 DatosLa mayoría de decisiones de empresas, organizaciones e instituciones se basan en información de experienciaspasadas. Generalmente, la información que se quiere investigar sobre un cierto dominio de la organización seencuentra 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 tomade decisiones se realizaba sobre estas mismas bases de datos de trabajo o bases de datos transaccionales. Lasituación era la siguiente.Se mantiene el trabajo transaccional diario de los sistemas de información originales (conocido comoOLTP, 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 lossistemas de información originales, ya que se realizan consultas muy pesadas (“killer queries”). A veces, laperturbació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 yconectividad se han reducido drásticamente en los últimos años, parece razonable recoger (copiar) los datos enun 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 lasbases de datos originales. El hecho de separar los datos a analizar con respecto a sus fuentes transaccionales (secopia/almacena toda la información histórica) requiere una tecnología sobre cómo organizarlos y sobretodocó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 delalmacén de datos no suele coincidir con el esquema transaccional. De hecho, los esquemas de almacenes dedatos suelen desnormalizarse, con el objetivo de acelerar ciertas consultas analíticas. En general, se distinguendos tipos de almacenes de datos:ROLAP (Relational OLAP): el almacén de datos es relacional.MOLAP (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 laevolución de determinados parámetros, controlar valores anómalos, etc.15‘exploradores’: encargados de encontrar nuevos patrones significativos utilizando técnicas de minería dedatos, 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 losalmacenes de datos son las siguientes:SISTEMA TRANSACCIONAL ALMACÉN DE DATOSPropósito Operaciones diarias Recuperación de información histórica y análisisSGBD más usuales SGBDR SGBDR o SGBDMEstructura de los datos Normalizado Multi-dimensionalTipo de datos Datos para el funcionamiento de la organización Datos que es interesante analizarCondició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ñadapara 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 puedeagregar o desagregar. La base de datos está completamente desnormalizada. Existe una terminología propia paraestos operadores: roll-up (consolidación o sumarización), drill-down (detalle), slicing and dicing (combinacionescruzadas).En el caso de los almacenes de datos sobre sistemas relacionales, la estructura también está muydesnormalizada, centrándose alrededor de tablas de hechos, de las que derivan otras tablas detalle, según variasdimensiones. De ahí, el nombre que se le dan a estas estructuras: estrella simple o estrella jerárquica (copo denieve). Esta estructura también permite la sumarización, la visualización y la navegación según las dimensiones dela estrella.No es de extrañar que las consultas realizadas de tipo OLAP al almacén de datos sean complejas. Porejemplo, elegir los cinco clientes con mayor volumen de compras no es una consulta trivial en SQL. Si además serequiere esta información por zonas geográficas y se quiere explotar la estructura del esquema del almacén dedatos, la consulta puede complicarse bastante. Si además, se requiere que sea eficiente, es posible que se debanutilizar 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 laorganización, con el crecimiento de las redes y de la información disponible, los almacenes de datos tambiénrecogen información externa o del contexto de la organización, como por ejemplo:Demografías (censo), páginas amarillas, psicografías, gráficos web, información de otras organizaciones.Datos compartidos en una industria o área de negocio, organizaciones y colegios profesionales,catálogos, etc.

42



Datos 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 comouna rama establecida de la tecnología de las bases de datos, especialmente vigente en grandes organizaciones eindustrias de la distribución, y suele funcionar en relación con los sistemas de toma de decisión (DSS, DecisionSupport System) y los Sistemas de Información Ejecutiva (EIS, Executive Information System). Es relevanteconstatar que el uso de los almacenes de datos es el original de los sistemas de información: recopilar datos paraanalizarlos y tomar decisiones a partir de este análisis.1.2. Situación ActualHoy en día se puede observar en perspectiva el cambio de los sistemas de gestión de bases de datos. Inicialmentese trataba de software muy caro, sobre grandes y costosos ordenadores. Actualmente existen sistemas de gestiónde bases de datos para ordenadores personales, como hemos visto, siendo muchos de ellos económicos o inclusogratuitos. Esta tendencia al abaratamiento y disminución en tamaño físico de los sistemas contrasta con la cada16vez mayor capacidad, potencia y prestaciones de los SGBD. Sólo median menos de 30 años desde el primersistema de gestión relacional, el “System R”, cuyo primer prototipo podía almacenar 8MB de datos hasta losterabytes 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, elproyecto RD45 (http://wwwinfo.cern.ch/asd/cernlib/rd45/index.html), es uno de los proyectos másambiciosos que se están desarrollando en el CERN con el objetivo de crear una base de datos distribuida capazde almacenar en 2005 un Exabyte (1 Exabyte = 1.024 Petabytes 1 1018 bytes).1.2.1. Bases de Datos y la WebQuizás uno de los aspectos que se han notado más recientemente en el campo de las bases de datos (como encasi cualquier otro campo de la informática) es el crecimiento vertiginoso de Internet y del WWW. La conexiónde las bases de datos con la web ha ido progresando de una interrelación realizada a través de herramientas adhoc hasta la situación actual, en la que prácticamente todo SGBD proporciona un módulo o toda una serie deherramientas 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 dela organización se ha hecho prácticamente ubicua, sin necesidad para las operaciones más comunes y sencillas deldesarrollo 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 unatecnologí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 variedadde información disponible en el WWW. La mayoría de accesos web de hoy en día disparan alguna forma degeneración de contenido de una base de datos, mientras que el comercio electrónico está destinado a hacer unuso 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 larevisión o extensión de modelos de datos y de lenguajes de consulta, la integración de datos tan diversos, lareconcepción de los índices, las transacciones y el procesamiento de consultas, con el objetivo de adaptarse a lascaracterísticas y la escala de los datos en la web. Se han identificado nuevos problemas, como saber tratar con elsolapamiento de información y la detección de copia, así como cuestiones específicas de la web comoherramienta de publicación. También hay un gran interés por el lenguaje XML, del cual hablaremos másadelante, y por la extracción y recogida de información de la web, su almacenamiento en un almacén de datos ysu prospección.1.2.2. Situación del Mercado de los SGBD y EstandarizaciónLa mayoría de sistemas de gestión de bases de datos de hoy en día son relacionales, como se ha vistoanteriormente. 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 denuevas licencias en el mercado de SGBD cada uno [Graham 2002].PORCENTAJE DEL MERCADO DE SGBDCompañía 1998 1999 2000 2001

44



Oracle 30.7 31.1 34.1 32.0IBM 30.0 29.9 30.3 31.7Microsoft 10.7 13.1 14.0 16.3Informix 4.8 4.3 3.3 3.0Sybase 3.6 3.3 3.2 2.6Otros 20.2 18.3 15.0 14.4TOTAL 100.0 100.0 100.0 100.0No obstante, hay que destacar que la distribución de estos porcentajes no es uniforme en la gama deaplicaciones. Por ejemplo, IBM sigue siendo líder en el área de los mainframes, especialmente con su línea17OS/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 deInformix migren a DB2. Más aún si tenemos en cuenta que IBM ha intentado aumentar su presencia mediante lapotenciació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, podemosobservar todavía una mayor concentración:PORCENTAJE DEL MERCADO DE SGBD RELACIONALESCompañía 2000 2001Oracle 42.5 39.8IBM 29.5 30.7Microsoft 11.6 14.4Informix 3.1 3.3Sybase 4.0 3.3Otros 9.3 8.5TOTAL 100.0 100.0Considerando sólo los sistemas relacionales, mientras sobre sistemas operativos Windows, Microsoft es el líderen 2001 con el 39.9% del mercado (respecto a un 34.0% de Oracle), en sistemas operativos UNIX, Oracle esclaramente predominante, con un 63.3%.La excesiva concentración del mercado plantea serias dudas sobre la implantación del nuevo SQL3, porquelas 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 estasmismas compañías han ido introduciendo, como el soporte para los objetos grandes incorporados (BLOB yLOB) 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 consultasrecursivas) a la mayoría de sistemas será un proceso lento. De hecho, hoy en día, ningún sistema es todavíacompletamente compatible con todas las características de SQL2. El tema parece estar mucho peor paraincorporar 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 propiasintaxis para los procedimientos, arrastrada de sus lenguajes 4GL.1.2.3. Diseño y Desarrollo de Bases de DatosNo sólo la tecnología es suficiente para que los sistemas de información de hoy en día funcionen mejor que losde hace unos años. Asociadas a las tecnologías suelen asociarse unas metodologías, que intentan sacar provechode las primeras. Utilizar un sistema de gestión de bases de datos relacional no es por sí solo una garantía de que elsistema de información que se construya utilizándolo vaya a funcionar bien. De hecho, dada la simplicidad delmodelo relacional y de algunos SGBR para ordenadores personales, existen verdaderas plepas realizadas por noprofesionales funcionando en pequeñas y grandes organizaciones, causando casi más problemas de los queresuelven.A continuación se realiza un rápido repaso (y bastante simplista) de los pasos usuales que se suelen utilizar ala hora de diseñar una base de datos. Generalmente se habla de las siguientes etapas: planificación-definición delsistema, 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 ladiferencia en las cuatro últimas etapas.1. Planificación y definición del sistema: aunque a veces estas fases se engloban en la siguiente fase deanálisis de requerimientos, consisten en determinar cuáles van a ser las fases del diseño de la base dedatos 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áles18son los componentes concretos del sistema de información (usuarios, contexto, etc.), definir qué seespera 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. Éstees una visión de alto nivel del sistema que registra qué información se va a almacenar, qué formato va atener y cómo se relaciona con otra información. Este esquema conceptual también especifica losderechos de acceso de grupos y programas. Para las bases de datos relacionales se suele utilizar elmodelo entidad relación para proporcionar una visión conjunta del sistema. En algunos casos, sobretodosi los datos son muy heterogéneos, se puede decidir realizar el modelo utilizando lenguajes de modeladoorientados a objetos como UML.4. Elección de SGBD: No es una fase realmente, porque este paso se suele pensar antes del desarrollo deuna base de datos en concreto o se decide para ser utilizado con varios fines. No obstante, si laorganización dispusiera de varios, o de ninguno, con lo que tendría que elegir, esta elección se limita pormuchas razones: monetarias, conocimientos disponibles de los profesionales informáticos, decisiones degestión y un número importante de otros factores, específicos a cada organización. De todos lossistemas disponibles, se intentará encontrar el sistema más apropiado para la base de datos que se deseadiseñar. Las siguientes fases se podrán realizar ya acordes con las capacidades y limitaciones del sistemaelegido.5. Diseño lógico: Durante esta fase del proceso, se toma el esquema producido en el diseño conceptual y seconvierte al modelo sobre el que trabaja el SGBD. Esta fase nos acerca ya al sistema final, ya que se tieneun 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 sistemapuede 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 portanto 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 dediscos. En esta fase también se estudian los índices y otras estructuras de organización física másapropiadas para optimizar el rendimiento.7. Implementación: una vez realizados todos los pasos anteriores, debidamente documentados, se puedepasar a implementar el sistema. Los detalles de implementación dependen en gran medida del SGBD, delos lenguajes de programación de las aplicaciones, de una serie de estándares y protocolos que puedanestar utilizando tanto el SGBD como las aplicaciones y otros muchos factores. Cuanto más detallada yclara es la especificación inicial, más rápida será la implementación. Al contrario, si las primeras fases sehan descuidado o han venido marcadas por las prisas, la fase de implementación se alargará y el sistemaestará lleno de parches y de modificaciones sobre modificaciones, degradándose su eficacia y suseguridad. Además, las modificaciones, como en casi cualquier desarrollo de un proyecto, son máscostosas 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 losdatos existente en fuentes de información previas o anteriores a la base de datos que se acaba deimplementar. Si no existe migración se deberá realizar una primera carga de datos ficticios o reales pararealizar pruebas más completas del sistema.9. Ajuste de rendimiento: Una vez el sistema comienza a estar operativo y se tienen datos (aunque en estafase todavía pueden ser ficticios), se puede comenzar a ajustar el rendimiento, utilizando y simulando lascargas 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 dedatos, la cual se debería diseñar cuidadosamente, o por inserción de nuevos datos), es cuando realmente seempieza a evaluar si las decisiones de diseño fueron correctas. Evidentemente, casi todos los sistemas se revisany se amplían, pero estas modificaciones deben seguir los pasos anteriores a partir de aquél que haya motivado elcambio 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 elproblema a medio y largo plazo.191.2.4. AplicacionesHoy en día, la existencia de un sistema de información organizacional sin un SGBD detrás es un error, ya no sólotecnológico sino económico. Incluso áreas que tenían unas particularidades muy especiales para las cuales haceunos años se dudaba del uso de SGBD, hoy han desarrollado una tecnología particular, o los SGBD generalesson capaces de soportarlas sin demasiados problemas. De este modo, el rango de aplicaciones de las bases dedatos a principios de este siglo XXI se ha ampliado de una manera importante. Así, se utilizan sistemas degestión de bases de datos para los sistemas de información geográfica [Burrough et al. 1998], las bases de datosmultimedia en [Furht & Marques 2000], las bases de datos médicas [Rondel et al. 1999], las bases de datosgené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 envolumen y número. Además, la perspectiva de las compañías suministradoras de SGBD tiende a proporcionarherramientas más globales e integradoras, en las que la organización se debe dedicar a personalizarlas para su áreade 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 algunosmuy populares (Baan, Navision, SAP), los paquetes globales perfectamente integrados con el SGBD, como elOracle E-Business Suite, han sido acogidos de una manera espectacular por el mercado, con un 66% decrecimiento en el año 2000.A medida que las empresas despliegan más sistemas web para la interacción con los clientes, los paquetesCRM se hacen más importantes. Según Dataquest (ahora Gartner Group, www.gartner.com), los paquetes CRMalcanzaron los 19,9 billones de dólares en 2000, un incremento del 28% sobre 1999. Además, se prevé unoscrecimientos 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

52



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).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 DatosEl 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

53



para validar o parametrizar un modelo sugerido y preexistente, no para generarlo. 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 disponiblesactualmente 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, ...).

54



Entre las aplicaciones específicas podemos citar algunas de las más famosas [Berry & 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

55



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 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 laintegridad, 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 ConocimientoLas 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

57



dualidad (tan bien representada, p.ej., en el paradigma orientado a objetos) es 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. OrganizacionesUn 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

58



básica en KDD (a través de conferencias de investigación anuales, un boletín y otras 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. CongresosEl 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

59

http://www.iaim.org/



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).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

61



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.

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

E

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

G

ENO JNO PUESTO DUR

E1 J1 Administrador 12

E2 J1 Analista 24

E2 J2 Analista 6

63



E3 J3 Consultor 10

E3 J4 Ingeniero 48

E4 J2 Programador 18



E7 J3 Ingeniero 36

E7 J5 Ingeniero 23


J

JNO JNOMBRE PRESUPUESTO LUGAR

J1 Instrumentación 150000 Monterrey

J2 Desarrollo de bases de datos

135000 México

J3 CAD/CAM 250000 Puebla

J4 Mantenimiento 310000 México

J5 CAD/CAM 500000 Monterrey

S

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

64



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

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:




135000 México



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




135000 México

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


México

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 Completa

Replicación Parcial Particionamiento

Procesamiento de Consultas

Fácil Moderado Moderado

Manejo de Directorios

Fácil o no existente

Moderado Moderado

Control de Concurrencia

Moderado Difícil Fácil

Confiabilidad Muy alto Alto Bajo

Realidad Aplicación posible

Realista Aplicación 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

http://www.monografias.com/Computacion/Software/

http://www.monografias.com/trabajos12/diccienc/diccienc.shtml

http://www.monografias.com/trabajos15/historia-computador/historia-computador.shtml#prpoces

http://www.monografias.com/trabajos5/recicla/recicla.shtml#papel

http://www.monografias.com/trabajos11/teosis/teosis.shtml

http://www.monografias.com/trabajos13/diseprod/diseprod.shtml

http://www.monografias.com/trabajos11/metods/metods.shtml#ANALIT

http://www.monografias.com/trabajos7/sisinf/sisinf.shtml

http://www.monografias.com/trabajos14/administ-procesos/administ-procesos.shtml#PROCE

http://www.monografias.com/trabajos6/napro/napro.shtml

http://www.monografias.com/trabajos11/teosis/teosis.shtml

http://www.monografias.com/trabajos11/basda/basda.shtml

http://www.monografias.com/trabajos10/carso/carso.shtml



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

http://www.monografias.com/trabajos15/todorov/todorov.shtml#INTRO

http://www.monografias.com/trabajos10/esda/esda.shtml

http://www.monografias.com/trabajos7/regi/regi.shtml

http://www.monografias.com/trabajos6/maca/maca.shtml

http://www.monografias.com/trabajos12/guiainf/guiainf.shtml

http://www.monografias.com/trabajos6/napro/napro.shtml

http://www.monografias.com/trabajos7/tain/tain.shtml

http://www.monografias.com/trabajos7/regi/regi.shtml


http://www.monografias.com/trabajos7/arch/arch.shtml

http://www.monografias.com/trabajos11/empre/empre.shtml

http://www.monografias.com/trabajos7/filo/filo.shtml

http://www.monografias.com/trabajos12/pmbok/pmbok.shtml

http://www.monografias.com/trabajos14/administ-procesos/administ-procesos.shtml#PROCE

http://www.monografias.com/trabajos12/diccienc/diccienc.shtml



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

http://www.monografias.com/trabajos13/libapren/libapren.shtml

http://www.monografias.com/trabajos15/todorov/todorov.shtml#INTRO

http://www.monografias.com/trabajos14/dinamica-grupos/dinamica-grupos.shtml

http://www.monografias.com/trabajos14/nuevmicro/nuevmicro.shtml

http://www.monografias.com/trabajos14/nuevmicro/nuevmicro.shtml



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

E

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

G

ENO JNO PUESTO DUR


85



E2 J1 Analista 24

E2 J2 Analista 6

E3 J3 Consultor 10

E3 J4 Ingeniero 48

E4 J2 Programador 18



E7 J3 Ingeniero 36

E7 J5 Ingeniero 23


J




135000 México



J5 CAD/CAM 500000 Monterrey

S

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:

86



SELECT ENOMBRE, SALARIO

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

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

http://4.bp.blogspot.com/_IOiKQLPcA3s/SWN-_hBEmYI/AAAAAAAADqQ/m0o6_ChgXg4/s1600-h/SGBDD.JPG



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 HV). El

93



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

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

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

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

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

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

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

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

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

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

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

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

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



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 pesos3. 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

http://es.wikipedia.org/wiki/ACID



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

http://es.wikipedia.org/w/index.php?title=Bloqueos&action=edit&redlink=1

http://es.wikipedia.org/wiki/Journaling



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

http://es.wikipedia.org/wiki/Savepoint

http://es.wikipedia.org/wiki/Transacci%C3%B3n_de_base_de_datos

http://es.wikipedia.org/wiki/SQL

http://es.wikipedia.org/wiki/Transacci%C3%B3n_de_base_de_datos

http://es.wikipedia.org/wiki/Gesti%C3%B3n_de_datos

http://es.wikipedia.org/wiki/Ciencia_de_la_computaci%C3%B3n



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ónUna 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

http://www.monografias.com/trabajos12/elorigest/elorigest.shtml


http://www.monografias.com/trabajos34/base-de-datos/base-de-datos.shtml

http://www.monografias.com/trabajos14/sqlserver/sqlserver.shtml

http://www.monografias.com/trabajos6/diop/diop.shtml




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

http://www.monografias.com/trabajos12/eticaplic/eticaplic.shtml

http://www.monografias.com/trabajos12/elproduc/elproduc.shtml

http://www.monografias.com/trabajos16/fijacion-precios/fijacion-precios.shtml#ANTECED

http://www.monografias.com/trabajos15/llave-exito/llave-exito.shtml



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

http://www.monografias.com/trabajos10/nofu/nofu.shtml

http://www.monografias.com/trabajos37/interpretacion/interpretacion.shtml

http://ads.us.e-planning.net/ei/3/29e9/cfa010f10016a577?rnd=0.7012418771900065&pb=667f7b64720fdc45&fi=a24322d9e41d0e10&kw=ver



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

http://www.monografias.com/trabajos15/logica-metodologia/logica-metodologia.shtml



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

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

http://es.wikipedia.org/w/index.php?title=Aislamiento_(inform%C3%A1tica)&action=edit&redlink=1

http://es.wikipedia.org/w/index.php?title=Fijaci%C3%B3n_bif%C3%A1sica&action=edit&redlink=1

http://es.wikipedia.org/w/index.php?title=Paralelo_(inform%C3%A1tica)&action=edit&redlink=1



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

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




.

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 ST

c definido sobre un conjunto de transacciones T = { T1, T2, ..., Tn } es un orden parcial ST

c = { 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

if ts(Ti) < wts( x ) then

reject Ri(x)

else

accept Ri(x)

rts(x) ts(Ti)

end

for Wi(x) do begin

if ts(Ti) < rts(x) and

ts(Ti) < wts(x) then

reject Wi(x)

else

accept Wi(x)

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

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



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

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

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

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

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

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

Documents

apuntes bdd2