Unidad 1

Introduccin a las bases de datos

Introduccin

En esta unidad se hablar de cuales son los objetivos de los sistemas de gestin de las
bases de datos (SGBD) y, a continuacin, daremos una visin general de la arquitectura, el
funcionamiento y el entorno de estos sistemas.

Objetivos

Encontraremos las herramientas para adquirir una visin global del mundo de las BD y de
los SGBD, as como para alcanzar los siguientes objetivos:
1. Conocer a grandes rasgos la evolucin de los SGBD desde los aos sesenta hasta la
actualidad.
2. Distinguir los principales objetivos de los SGBD actuales y contrastarlos con los
sistemas de ficheros tradicionales.
3. Saber explicar mediante ejemplos los problemas que intenta resolver el concepto de
transaccin.
4. Relacionar la idea de flexibilidad en los cambios con la independencia lgica y fsica
de los datos, as como con la arquitectura de tres niveles.
5. Distinguir los principales modelos de BD.
6. Conocer a grandes rasgos el funcionamiento de un SGBD.

7. Saber relacionar los diferentes tipos de lenguajes con los diferentes tipos de
usuarios.

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 fueron introduciendo las lneas de comunicacin, los terminales y los
discos, se fueron escribiendo programas que permitan a varios usuarios consultar los
mismos ficheros on-line y de forma simultnea. Ms adelante fue surgiendo la necesidad de
hacer las actualizaciones tambin on-line.
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).
El software de gestin de ficheros era demasiado elemental para dar satisfaccin a todas
estas necesidades. Por ejemplo, el tratamiento de las interrelaciones no estaba previsto, no
era posible que varios usuarios actualizaran datos simultneamente, etc. La utilizacin de
estos conjuntos de ficheros por parte de los programas de aplicacin era excesivamente
compleja, de modo que, especialmente durante la segunda mitad de los aos setenta, fue
saliendo al mercado software ms sofisticado: los Data Base Management Systems, que
aqu denominamos sistemas de gestin de BD (SGBD).

En otras palabras, una base de datos es un conjunto estructurado de datos que

representa entidades y sus interrelaciones. La representacin ser nica e
integrada, a pesar de que debe permitir utilizaciones varias y simultneas.
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

Para entender mejor qu son los SGBD, haremos un repaso de su evolucin
desde los aos sesenta hasta nuestros das.

2.1. Los aos sesenta y setenta: sistemas centralizados

Los primeros SGBD en los aos sesenta todava no se les denominaba as

estaban orientados a facilitar la utilizacin de grandes conjuntos de datos en
los que las interrelaciones eran complejas. El arquetipo de aplicacin era el Bill
of materials o Parts explosion, tpica en las industrias del automvil, en la
construccin de naves espaciales y en campos similares. Estos sistemas
trabajaban exclusivamente por lotes (batch).
Al aparecer los terminales de teclado, conectados al ordenador central
medianteuna lnea telefnica, se empiezan a construir grandes aplicaciones online transaccionales (OLTP). Los SGBD estaban ntimamente ligados al software
de comunicaciones y de gestin de transacciones.
Aunque para escribir los programas de aplicacin se utilizaban lenguajes de
alto nivel como Cobol o PL/I, se dispona tambin de instrucciones y de
subrutinas especializadas para tratar las BD que requeran que el programador
conociese muchos detalles del diseo fsico, y que hacan que la programacin
fuese muy compleja.
Puesto que los programas estaban relacionados con el nivel fsico, se deban
modificar continuamente cuando se hacan cambios en el diseo y la
organizacin de la BD. La preocupacin bsica era maximizar el rendimiento: el
tiempo de respuesta y las transacciones por segundo.

2.2. Los aos ochenta: SGBD relacionales

Los ordenadores minis, en primer lugar, y despus los ordenadores micros,
extendieron la informtica a prcticamente todas las empresas e instituciones.
Esto exiga que el desarrollo de aplicaciones fuese ms sencillo. Los SGBD de
los aos setenta eran demasiado complejos e inflexibles, y slo los poda
utilizar un personal muy cualificado.

Todos estos factores hacen que se extienda el uso de los SGBD. La

estandarizacin, en el ao 1986, del lenguaje SQL produjo una autntica
explosin de los SGBD relacionales.

2.3. 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. El resultado ha sido que en el seno de la empresa hay numerosas BD y
varios SGBD de diferentes tipos o proveedores. Este fenmeno de
multiplicacin de las BD y de los SGBD se ha visto incrementado por la fiebre
de las fusiones de empresas.

Esta distribucin ideal se consigue cuando las diferentes BD son soportadas por
una misma marca de SGBD, es decir, cuando hay homogeneidad. Sin embargo,
esto no es tan sencillo si los SGBD son heterogneos. 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.

Adems de esta distribucin impuesta, al querer tratar de forma integrada

distintas BD preexistentes, tambin se puede hacer una distribucin
deseada, diseando una BD distribuida fsicamente, y con ciertas partes

replicadas en diferentes sistemas. 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 de ms seguirn funcionando. Si los datos residentes en el
sistema no disponible estn replicados en otro sistema, continuarn
estando disponibles. En caso contrario, slo estarn disponibles los datos
de los dems sistemas.
2) Costo. 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. El coste total de
las comunicaciones se puede reducir haciendo que un usuario tenga ms
cerca los datos que utiliza con mayor frecuencia; por ejemplo, en un
ordenador de su propia oficina o, incluso, en su ordenador personal.

Por ejemplo, un programa de aplicacin que un usuario ejecuta en su PC (que

est conectado a una red) pide ciertos datos de una BD que reside en un
equipo UNIX donde, a su vez, se ejecuta el SGBD relacional que la gestiona. El
programa de aplicacin es el cliente y el SGBD es el servidor.
Un proceso cliente puede pedir servicios a varios servidores. Un servidor puede
recibir peticiones de muchos clientes. En general, un proceso A que hace de
cliente, pidiendo un servicio a otro proceso B puede hacer tambin de servidor
de un servicio que le pida otro proceso C (o incluso el B, que en esta peticin
sera el cliente). Incluso el cliente y el servidor pueden residir en un mismo
sistema.

La facilidad para disponer de distribucin de datos no es la nica razn, ni

siquiera la bsica, del gran xito de los entornos C/S en los aos noventa. Tal
vez el motivo fundamental ha sido la flexibilidad para construir y hacer crecer
la configuracin informtica global de la empresa, as como de hacer
modificaciones en ella, mediante hardware y software muy estndar y barato.
El xito de las BD, incluso en sistemas personales, ha llevado a la aparicin de
los Fourth Generation Languages (4GL), lenguajes muy fciles y potentes,
especializados en el desarrollo de aplicaciones fundamentadas en BD.
Proporcionan muchas facilidades en el momento de definir, generalmente de
forma visual, dilogos para introducir, modificar y consultar datos en entornos
C/S.

2.4. 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 definitiva, se
necesitan tipos abstractos de datos: TAD. Los SGBD ms recientes ya
incorporaban esta posibilidad, y abren un amplio mercado de TAD predefinidos
o libreras de clases.

Esto nos lleva a la orientacin a objetos (OO). El xito de la OO al final de

aos ochenta, en el desarrollo de software bsico, en las aplicaciones
ingeniera industrial y en la construccin de interfaces grficas con
usuarios, ha hecho que durante la dcada de los noventa se extendiese
prcticamente todos los campos de la informtica.

los
de
los
en

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.
La rpida adopcin de la web a los SI hace que los SGBD incorporen recursos
para ser servidores de pginas web, como por ejemplo la inclusin de SQL en
guiones HTML, SQL incorporado en Java, etc. Notad que en el mundo de la web
son habituales los datos multimedia y la OO.
Durante estos ltimos aos se ha empezado a extender un tipo de aplicacin
de las BD denominado Data Warehouse, o almacn de datos, que tambin
produce algunos cambios en los SGBD relacionales del mercado.
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.

El usuario debe formular la consulta con un lenguaje sencillo (que se quede,

obviamente, en el nivel lgico), que el sistema debe interpretar directamente.
Sin embargo, esto no significa que no se puedan escribir programas con
consultas incorporadas (por ejemplo, para procesos repetitivos).
La solucin estndar para alcanzar este doble objetivo (consultas no
predefinidas y complejas) es el lenguaje SQL, que explicaremos en otro mdulo
didctico.

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.

En el mundo de los ficheros ya haba independencia fsica en un cierto grado,

pero en el mundo de las BD acostumbra a ser mucho mayor.

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.
Por lo tanto, convendra evitar la redundancia. En principio, nos conviene hacer
que un dato slo figure una vez en la BD. Sin embargo, esto no siempre ser
cierto.
Por ejemplo, para representar una interrelacin entre dos entidades, se suele
repetir un mismo atributo en las dos, para que una haga referencia a la otra.
Otro ejemplo podra ser el disponer de rplicas de los datos por razones de
fiabilidad, disponibilidad o costes de comunicaciones.

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.
En los casos de datos derivados, para que el resultado del clculo se mantenga
consistente con los datos elementales, es necesario rehacer el clculo cada vez
que stos se modifican. El usuario (ya sea programador o no) puede olvidarse
de hacer el nuevo clculo; por ello convendr que el mismo SGBD lo haga
automticamente.

3.4. Integridad de los datos

Nos interesar que los SGBD aseguren el mantenimiento de la calidad de los
datos en cualquier circunstancia. Acabamos de ver que 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.
En el subapartado anterior hemos visto que podremos decir al SGBD que nos
lleve el control de las actualizaciones en el caso de las redundancias, para
garantizar la integridad. Del mismo modo, podremos darle otras reglas de

integridad o restricciones para que asegure que los programas las cumplen
cuando efectan las actualizaciones.

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. El SGBD nos debe dar las
herramientas para reconstruir o restaurar los datos estropeados.