1.

Concepto y origen de las BD y de los SGBD

Las aplicaciones informticas de los aos sesenta acostumbraban a darse totalmente

por lotes (batch) y estaban pensadas para una tarea muy especfica relacionada
con muy pocas entidades tipo.
Cada aplicacin (una o varias cadenas de programas) utilizaba ficheros de movimientos
para actualizar (creando una copia nueva) y/o para consultar uno o
dos ficheros maestros o, excepcionalmente, ms de dos. Cada programa trataba
como mximo un fichero maestro, que sola estar sobre cinta magntica y,
en consecuencia, se trabajaba con acceso secuencial. Cada vez que se le quera
aadir una aplicacin que requera el uso de algunos de los datos que ya existan
y de otros nuevos, se diseaba un fichero nuevo con todos los datos necesarios
(algo que provocaba redundancia) para evitar que los programas
tuviesen que leer muchos ficheros.
A medida que se integraban las aplicaciones, se tuvieron que interrelacionar
sus ficheros y fue necesario eliminar la redundancia. El nuevo conjunto de ficheros
se deba disear de modo que estuviesen interrelacionados; al mismo
tiempo, las informaciones redundantes (como por ejemplo, el nombre y la direccin
de los clientes o el nombre y el precio de los productos), que figuraban
en los ficheros de ms de una de las aplicaciones, deban estar ahora en un solo
lugar.
El acceso on-line y la utilizacin eficiente de las interrelaciones exigan estructuras
fsicas que diesen un acceso rpido, como por ejemplo los ndices, las
multilistas, las tcnicas de hashing, etc.
Estos conjuntos de ficheros interrelacionados, con estructuras complejas y
compartidos por varios procesos de forma simultnea (unos on-line y otros por
lotes), recibieron al principio el nombre de Data Banks, y despus, a inicios de
los aos setenta, el de Data Bases. Aqu los denominamos bases de datos (BD).

Los ficheros tradicionales y las BD

Aunque de forma muy simplificada, podramos enumerar las principales diferencias entre los
ficheros tradicionales y las BD tal y como se indica a continuacin:
1) Entidades tipos:
Ficheros: tienen registros de una sola entidad tipo.
BD: tienen datos de varias entidades tipo.
2) Interrelaciones:
Ficheros: el sistema no interrelaciona ficheros.
BD: el sistema tiene previstas herramientas para interrelacionar entidades.
3) Redundancia:
Ficheros: se crean ficheros a la medida de cada aplicacin, con todos los datos necesarios
aunque algunos sean redundantes respecto de otros ficheros.
BD: todas las aplicaciones trabajan con la misma BD y la integracin de los datos es bsica,
de modo que se evita la redundancia.
4) Usuarios
Ficheros: sirven para un solo usuario o una sola aplicacin. Dan una sola visin del mundo
real.
BD: es compartida por muchos usuarios de distintos tipos. Ofrece varias visiones del
mundo real.

2. Evolucin de los SGBD

Los SGBD de los aos sesenta y setenta (IMS de IBM, IDS de Bull, DMS
de Univac, etc.) eran sistemas totalmente centralizados, como corresponde
a los sistemas operativos de aquellos aos, y al hardware para el
que estaban hechos: un gran ordenador para toda la empresa y una red
de terminales sin inteligencia ni memoria.

Los aos noventa: distribucin, C/S y 4GL

Al acabar la dcada de los ochenta, los SGBD relacionales ya se utilizaban prcticamente en todas

las empresas. A pesar de todo, hasta la mitad de los noventa, cuando se ha necesitado un

rendimiento elevado se han seguido utilizando los SGBD prerrelacionales.

A finales de los ochenta y principios de los noventa, las empresas se han encontrado con el hecho

de que sus departamentos han ido comprando ordenadores departamentales y personales, y han

ido haciendo aplicaciones con BD.

En la actualidad, gracias principalmente a la estandarizacin del lenguaje SQL, los SGBD de marcas

diferentes pueden darse servicio unos a otros y colaborar para dar servicio a un programa de

aplicacin. No obstante, en general, en los casos de heterogeneidad no se llega a poder dar en el

programa que los utiliza la apariencia de que se trata de una nica BD.

Las razones bsicas por las que interesa esta distribucin

son las siguientes:

1) Disponibilidad. La disponibilidad de un sistema con una BD distribuida puede ser ms alta,

porque si queda fuera de servicio uno de los sistemas, los dems seguirn funcionando.

2) Coste. Una BD distribuida puede reducir el coste. En el caso de un sistema centralizado, todos

los equipos usuarios, que pueden estar distribuidos por distintas y lejanas reas geogrficas, estn

conectados al sistema central por medio de lneas de comunicacin. Tendencias actuales Los tipos

de datos que se pueden definir en los SGBD relacionales de los aos ochenta y noventa son muy

limitados. La incorporacin de tecnologas multimedia imagen y sonido en los SI hace necesario

que los SGBD relacionales acepten atributos de estos tipos.

Sin embargo, algunas aplicaciones no tienen suficiente con la incorporacin de tipos

especializados en multimedia. Necesitan tipos complejos que el desarrollador pueda definir a

medida de la aplicacin.

En los SI se inicia tambin la adopcin, tmida de momento, de la OO. La utilizacin de lenguajes

como C++ o Java requiere que los SGBD relacionales se adapten a ellos con interfaces adecuadas.

A lo largo de los aos que han trabajado con BD de distintas aplicaciones, las empresas han ido

acumulando gran cantidad de datos de todo tipo. Si estos datos se analizan convenientemente

pueden dar informacin valiosa*.

Por lo tanto, se trata de mantener una gran BD con informacin proveniente de toda clase de

aplicaciones de la empresa (e, incluso, de fuera). Los datos de este gran almacn, el Data

Warehouse, se obtienen por una replicacin ms o menos elaborada de las que hay en las BD que

se utilizan en el trabajo cotidiano de la empresa. Estos almacenes de datos se utilizan

exclusivamente para hacer consultas, de forma especial para que lleven a cabo estudios* los

analistas financieros, los analistas de mercado, etc.

Actualmente, los SGBD se adaptan a este tipo de aplicacin, incorporando, por ejemplo,

herramientas como las siguientes:

a) La creacin y el mantenimiento de rplicas, con una cierta elaboracin de los datos.

b) La consolidacin de datos de orgenes diferentes.

c) La creacin de estructuras fsicas que soporten eficientemente el anlisis

multidimensional.

3. Objetivos y servicios de los SGBD

Los SGBD que actualmente estn en el mercado pretenden satisfacer un conjunto

de objetivos directamente deducibles de lo que hemos explicado hasta

ahora. A continuacin, los comentaremos, pero sin entrar en detalles que ya se

vern ms adelante en otras asignaturas.

3.1. Consultas no predefinidas y complejas

El objetivo fundamental de los SGBD es permitir que se hagan consultas no

predefinidas (ad hoc) y complejas.

Consultas que afectan a ms de una entidad tipo:

Se quiere conocer el nmero de alumnos de ms de veinticinco aos y con nota

media superior a siete que estn matriculados actualmente en la asignatura Bases

de datos I.

De cada alumno matriculado en menos de tres asignaturas, se quiere obtener el

nombre, el nmero de matrcula, el nombre de las asignaturas y el nombre de

profesores de estas asignaturas.

Los usuarios podrn hacer consultas de cualquier tipo y complejidad directamente

al SGBD. El SGBD tendr que responder inmediatamente sin que estas consultas

estn preestablecidas; es decir, sin que se tenga que escribir, compilar y ejecutar

un programa especfico para cada consulta.

3.2. Flexibilidad e independencia

La complejidad de las BD y la necesidad de irlas adaptando a la evolucin del SI

hacen que un objetivo bsico de los SGBD sea dar flexibilidad a los cambios.

Interesa obtener la mxima independencia posible entre los datos y los procesos

usuarios para que se pueda llevar a cabo todo tipo de cambios tecnolgicos y

variaciones en la descripcin de la BD, sin que se deban modificar los programas

de aplicacin ya escritos ni cambiar la forma de escribir las consultas (o

actualizaciones) directas.

Para conseguir esta independencia, tanto los usuarios que hacen consultas (o

actualizaciones) directas como los profesionales informticos que escriben

programas que las llevan incorporadas, deben poder desconocer las

caractersticas fsicas de la BD con que trabajan. No necesitan saber nada sobre

el soporte fsico, ni estar al corriente de qu SO se utiliza, qu ndices hay, la

compresin o no compresin de datos, etc. De este modo, se pueden hacer

cambios de tecnologa y cambios fsicos para mejorar el rendimiento sin afectar a

nadie. Este tipo de independencia recibe el nombre de independencia fsica de los

datos.

Ejemplos de independencia lgica

1) El personal administrativo de secretara podra tener una visin de la entidad

alumno sin que fuese necesario que existiese el atributo nota. Sin embargo, los

usuarios profesores (o los programas dirigidos a ellos) podran tener una visin en

la que existiese el atributo nota pero no el atributo fecha de pago.

2) Decidimos ampliar la longitud del atributo nombre y lo aumentamos de treinta a

cincuenta caracteres, pero no sera necesario modificar los programas que ya

tenemos escritos si no nos importa que los valores obtenidos tengan slo los

primeros treinta caracteres del nombre.

3.3. Problemas de la redundancia

En el mundo de los ficheros tradicionales, cada aplicacin utilizaba su fichero. Sin

embargo, puesto que se daba mucha coincidencia de datos entre aplicaciones se

produca tambin mucha redundancia entre los ficheros. Ya hemos dicho que uno

de los objetivos de los SGBD es facilitar la eliminacin de la redundancia.

Seguramente pensis que el problema de la redundancia es el espacio perdido.

Antiguamente, cuando el precio del byte de disco era muy elevado, esto era un

problema grave, pero actualmente prcticamente nunca lo es. Qu problema

hay, entonces? Simplemente, lo que todos hemos sufrido ms de una vez; si

tenemos algo apuntado en dos lugares diferentes no pasar demasiado tiempo

hasta que las dos anotaciones dejen de ser coherentes, porque habremos

modificado la anotacin en uno de los lugares y nos habremos olvidado de hacerlo

en el otro. As pues, el verdadero problema es el grave riesgo de inconsistencia o

incoherencia de los datos; es decir, la prdida de integridad que las

actualizaciones pueden provocar cuando existe redundancia.

El SGBD debe permitir que el diseador defina datos redundantes, pero entonces

tendra que ser el mismo SGBD el que hiciese automticamente la actualizacin

de los datos en todos los lugares donde estuviesen repetidos.

La duplicacin de datos es el tipo de redundancia ms habitual, pero tambin

tenemos redundancia cuando guardamos en la BD datos derivados (o calculados)

a partir de otros datos de la misma BD. De este modo podemos responder

rpidamente a consultas globales, ya que nos ahorramos la lectura de gran

cantidad de registros.

Integridad de los datos:

La redundancia puede provocar prdida de integridad de los datos, pero no es la nica causa

posible. Se podra perder la correccin o la consistencia de los datos por muchas otras razones:

errores de programas, errores de operacin humana, avera de disco, transacciones incompletas

por corte de alimentacin elctrica, etc.

Cuando el SGBD detecte que un programa quiere hacer una operacin que va contra las reglas

establecidas al definir la BD, no se lo deber permitir, y le tendr que devolver un estado de error.

Al disear una BD para un SI concreto y escribir su esquema, no slo definiremos los datos, sino

tambin las reglas de integridad que queremos que el SGBD haga cumplir.

Aparte de las reglas de integridad que el diseador de la BD puede definir y que el SGBD

entender y har cumplir, el mismo SGBD tiene reglas de integridad inherentes al modelo de datos

que utiliza y que siempre se cumplirn. Son las denominadas reglas de integridad del modelo. Las

reglas definibles por parte del usuario son las reglas de integridad del usuario. El concepto de

integridad de los datos va ms all de prevenir que los programas usuarios almacenen datos

incorrectos. En casos de errores o desastres, tambin podramos perder la integridad de los datos.

Los procesos de restauracin (restore o recovery) de los que todo SGBD dispone pueden

reconstruir la BD y darle el estado consistente y correcto anterior al incidente. Esto se acostumbra

a hacer gracias a la obtencin de copias peridicas de los datos (se denominan copias de seguridad

o back-up) y mediante el mantenimiento continuo de un diario (log) donde el SGBD va anotando

todas las escrituras que se hacen en la BD.

Concurrencia de usuarios:

Cuando el SGBD detecte que un programa quiere hacer una operacin que va contra las reglas

establecidas al definir la BD, no se lo deber permitir, y le tendr que devolver un estado de error.

Al disear una BD para un SI concreto y escribir su esquema, no slo definiremos los datos, sino

tambin las reglas de integridad que queremos que el SGBD haga cumplir.

Aparte de las reglas de integridad que el diseador de la BD puede definir y que el SGBD

entender y har cumplir, el mismo SGBD tiene reglas de integridad inherentes al modelo de datos

que utiliza y que siempre se cumplirn. Son las denominadas reglas de integridad del modelo. Las

reglas definibles por parte del usuario son las reglas de integridad del usuario. El concepto de

integridad de los datos va ms all de prevenir que los programas usuarios almacenen datos

incorrectos.

Cuando los accesos concurrentes son todos de lectura (es decir, cuando la BD slo se consulta), el

problema que se produce es simplemente de rendimiento, causado por las limitaciones de los

soportes de que se dispone.

Cuando un usuario o ms de uno estn actualizando los datos, se pueden producir problemas de

interferencia que tengan como consecuencia la obtencin de datos errneos y la prdida de

integridad de la BD. Para tratar los accesos concurrentes, los SGBD utilizan el concepto de

transaccin de BD, concepto de especial utilidad para todo aquello que hace referencia a la

integridad de los datos.

Nos interesar que el SGBD ejecute las transacciones de forma que no se interfieran; es decir, que

queden aisladas unas de otras. Para conseguir que las transacciones se ejecuten como si

estuviesen aisladas, los SGBD utilizan distintas tcnicas. La ms conocida es el bloqueo (lock).

El bloqueo de unos datos en beneficio de una transaccin consiste en poner limitaciones a los

accesos que las dems transacciones podrn hacer a estos datos.

Cuando se provocan bloqueos, se producen esperas, retenciones y, en consecuencia, el sistema es

ms lento. Los SGBD se esfuerzan en minimizar estos efectos negativos.