Está en la página 1de 22

Introducción a los Sistemas de Bases de Datos.

INTRODUCCIÓN A LOS SISTEMAS DE


BASES DE DATOS.
Evolución de los sistemas de bases de datos.

Uno de los usos más frecuentes de los ordenadores es el de almacenamiento masivo de datos.
Aquí es importante hacer distinción entre datos e información. Cuando nos referimos a datos, estamos
hablando de un texto, un número o un conjunto arbitrariamente grande de ambos. En el momento en
que hablamos de información, nos referimos a datos que pueden ser relacionados entre sí, de forma
más o menos inteligente, con el objetivo de sacar alguna conclusión que nos permita tomar decisiones
importantes en nuestra empresa u organización.
El ordenador en sí no es inteligente, lo que pasa es que es capaz de hacer millones de
operaciones simples en muy poco tiempo, con lo que es posible procesar un enorme número de datos
para extraer información. ¿Cómo extraer información de los datos? Hay muchas formas: obtener
estadísticas sobre destinos hoteleros preferidos, obtener movimientos turísticos según la procedencia,
emitir facturas en una agencia de viajes, enviar cartas a nuestros mejores clientes, etc.
Para poder realizar todas estas operaciones es necesario almacenar de alguna forma datos
sobre los clientes, los paquetes de viajes, las reservas, información estadística, etc. según la información
que se desee obtener.
Tradicionalmente, antes del uso de ordenadores, la información se extraía tras un minucioso
examen de los datos almacenados en fichas de cartón que se guardaban en los cajones de grandes
ficheros en una oficina, lo cual era muy costoso debido al tiempo requerido, o bien a la poca exactitud
de los resultados obtenidos, que hacía tomar decisiones poco acertadas.
Con la llegada de los ordenadores, y los dispositivos de almacenamiento electrónico, discos
duros, tambores magnéticos, fichas perforadas, cintas magnéticas, etc., aparece el concepto de fichero
electrónico. Un fichero electrónico es igual que un fichero con cajones y fichas de cartón en su interior,
sólo que están almacenados sobre una superficie magnética (con el consiguiente ahorro de espacio),
y son gestionados a través de un ordenador (con el consiguiente ahorro en velocidad a la hora de
acceder), lo que posibilita su examen de forma veloz a través de la máquina.
Normalmente, los datos necesarios no se almacenan en un sólo fichero, sino que para extraer
una determinada información, es necesario consultar ficheros de distinto tipo: ficheros de clientes, de
pedidos, de proveedores, de ofertas, de facturas, de albaranes, etc. P.ej., para realizar un pedido de
comestibles en un hotel, sería necesario consultar un fichero de existencias o stock, y el fichero de
proveedores, realizar un pedido, y dejar constancia del mismo en el fichero de pedidos, para que, una
vez recibido el pedido, nos cercioremos de que lo que se ha recibido es aquello que se pidió.
Este fue un gran paso en lo que respecta al almacenamiento y gestión de los datos. No
obstante, a medida que pasó el tiempo, se observó que la información extraída de estos ficheros era
a menudo contradictoria y propensa a errores de coordinación (incoherentes): aparecen albaranes con
números de clientes que no existen en el fichero de clientes, cada vez que es necesario indicar un
proveedor en la ficha de pedidos hay que poner su nombre y dirección, con lo cual un mismo
proveedor puede aparecer con varias direcciones distintas por error, etc.
Para solucionar este problema, interviene de nuevo la capacidad de los ordenadores para hacer

1
Introducción a los Sistemas de Bases de Datos.

rápidamente muchas cosas simples. Se optó por hacer que el ordenador controlase la concordancia
entre los datos, y para ello se dio a los datos una estructura distinta, ya no basada en ficheros como
tales, sino basada en listas o tablas de fichas (llamadas tuplas o líneas), y en cada una de las cuales no
se encontraba toda la información, sino que era necesario relacionar datos de varias tablas para obtener
la información deseada. Aparecen así las bases de datos.
La evolución de la informática ha pasado por numerosas formas de abordar los problemas
mediante programas, en función de la potencia de las máquinas en cada época, y de la experiencia de
los informáticos que ha ido aumentando a lo largo de los años. De esta forma, aparecieron las bases
de datos jerárquicas y en red, cuyas características veremos más adelante. Posteriormente las bases
de datos relacionales, que son las que nosotros estudiaremos, sustituyeron rápidamente a estas dos,
ya que las relacionales se basan en estudios matemáticos que aseguran la eficiencia de las operaciones
que permite realizar, así como su correctitud y completitud, y definen claramente la forma en que deben
abordarse los problemas.
Actualmente, las bases de datos relacionales son las más usadas a nivel profesional, aunque
para aplicaciones avanzadas y en los ambientes académicos también tienen bastante importancia las
bases de datos orientadas a objetos (especialmente para trabajos sobre Internet), y las bases de datos
deductivas (para trabajos en Inteligencia Artificial).

Ver el punto 2.1 de OBJETOS: Conceptos, métodos y herramientas. (Valduriez).

Objetivos a cubrir por una base de datos.

Los objetivos que debe cubrir una base de datos son:


- Evitar la redundancia e inconsistencia en los datos.
No sólo se debe aprovechar la enorme capacidad de los ordenadores para almacenar
grandes cúmulos de información. Éstos pueden emplearse en controlar que los datos existentes
sean consistentes entre sí, y que no haya información contradictoria entre los datos
almacenados.
Por otro lado, es el usuario quien tiene que decidir qué se almacena en la base de datos
y qué no. Evidentemente sólo deben almacenarse aquellos datos que se necesitan para algo,
aquello que nos será útil en nuestro trabajo. El usuario es quien debe decidir además en que
forma se almacenan los datos: si un número de teléfono se almacenará como un número, o
como una tira de letras (lo cual permitiría guardar el guión que separa el prefijo del número en
sí), etc. Como veremos, existen numerosas reglas que el diseñador de bases de datos debe
tener en cuenta a la hora de realizar un diseño eficiente y depurado. Evitar redundancias (datos
o información repetida) en los datos almacenados es un objetivo prioritario ya que con ello se
consigue:
a) No desperdiciar capacidad de almacenamiento (cinta, disco, etc.).
b) Evitar la extracción de una misma información por dos caminos distintos, con lo que
la información extraída puede ser contradictoria.
- Facilitar el acceso a los datos.
En los sistemas antiguos, los datos almacenados en ficheros electrónicos sólo podían

2
Introducción a los Sistemas de Bases de Datos.

ser accedidos a través de programas de ordenador que realizaban alguna tarea específica muy
concreta. Para cada tipo de información que se necesitaba, era necesario crear un programa
que la extrajera de los datos de los ficheros; de esta manera, si un empleado de contabilidad
deseaba saber los clientes de Ronda que habían comprado más de un millón de pesetas en el
año 1.996, debía presentar dicha necesidad al departamento de proceso de datos, que debía
crear un programa para atender tal requerimiento.
Evidentemente, esta forma de trabajo es lenta, y tiene un cuello de botella en el centro
de proceso de datos, con el agravante de que da lugar a una miríada de programas distintos,
cada uno para atender una necesidad particular. Además, si por cualquier causa, cambia la
estructura de los datos (p.ej., se decide que en lugar de almacenar al completo el nombre y
apellidos de un cliente, se guardará por un lado el nombre, y por otro los apellidos), algunos
de los programas ya hechos no servirán, porque fueron creados en base a una estructura
determinada, que ahora se ha visto alterada.
Para evitar todos estos problemas, se inserta entre el nivel a que se hallan los datos,
y las aplicaciones, un programa auxiliar de máxima importancia: es el Sistema Gestor de Bases
de Datos (S.G.B.D.), cuyas múltiples funciones iremos viendo a lo largo de la asignatura. Una
de estas funciones es la de suministrar un lenguaje que permita consultar fácilmente la base de
datos sin necesidad de hacer un programa para cada consulta; bastará con formular la consulta
según este lenguaje simple, para obtener un resultado más o menos inmediato fruto de las
gestiones realizadas por el S.G.B.D. sobre los datos.
- Facilitar la creación de programas que trabajen sobre los datos.
Como se ha indicado anteriormente, los datos pueden estar repartidos en múltiples
tablas o en múltiples ficheros; incluso puede haber varias bases de datos de cuyo conjunto sea
necesario extraer información. Es más, cada base de datos puede estar creada con un sistema
distinto (es algo así como si en cada base de datos la ficha de cartón que guarda los datos de
un cliente tuviera los datos cambiados de sitio, o incluso distintos datos).
De esta forma, es difícil crear aplicaciones que trabajen sobre los datos. De nuevo,
esto se soluciona con un S.G.B.D. que aisla al creador de aplicaciones de este caos de datos,
y le da una visión uniforme de los datos, facilitando de esta manera la programación de
aplicaciones complejas.
- Permitir el acceso concurrente.
Un ordenador es una máquina que sólo es capaz de hacer una cosa cada vez: leer de
memoria, escribir en ella, realizar un cálculo, etc.; en definitiva cosas muy simples. Sin embargo,
en la mayoría de los trabajos se requiere que varias personas puedan trabajar a la vez, quizás
aparentemente no con la misma máquina (cada persona tendrá un teclado y un monitor distinto,
por supuesto; es lo que se llama un terminal), pero sí sobre los mismos datos; piénsese si no
en un programa de reserva de billetes de avión de una compañía determinada. En este caso los
datos sobre reservas se almacenan una sola vez en un ordenador central, que gestiona todas
las operaciones efectuadas sobre cada terminal de usuario.
Así, cada usuario podrá efectuar peticiones sobre el ordenador central en el momento
en que lo necesite, y la central deberá responderle en un tiempo prudencial (no debe hacer
esperar innecesariamente). Dado que varias personas trabajan a la vez, es posible que el
ordenador central reciba peticiones de acceso sobre los datos de forma simultánea: es lo que

3
Introducción a los Sistemas de Bases de Datos.

se llama acceso concurrente.


Para observar los problemas que puede producir el acceso concurrente, supongamos
que el ordenador central es un escribiente al que cada usuario le dicta la ficha que debe tomar
y lo que debe hacer sobre ella: consultar un dato de la misma, modificar algún campo, destruir
la ficha o tomar una ficha en blanco e insertar datos en ella.
Si no hubiese requerimientos de tiempo por parte de cada usuario, no habría problema,
pues al escribiente le bastaría con atender las peticiones por riguroso orden de llegada. Sin
embargo, para dar la sensación de que el escribiente atiende a todo el mundo por igual, este
hace uso de una técnica llamada tiempo compartido, o sea, reparte cada minuto de su tiempo
en partes iguales, una para cada usuario que le ha hecho una petición.
De esta forma, pueden aparecer problemas en los accesos concurrentes a los datos.
P.ej., ¿qué pasa si un usuario pide que se elimine la ficha del cliente Hotel Miramar, mientras
que otro dice que se le modifique el apartado de correos?. Si hacemos primero la eliminación,
¡¿cómo modificar una ficha que no existe?!
Este problema se ve agravado enormemente en el momento en que se introduce el
concepto de transacción. Una transacción es un conjunto de operaciones sobre los datos que
debe ser tratada como una única operación: o se hace entera, o no se hace. Un ejemplo de
transacción puede ser: Incrementar en un 2'8% el crédito máximo dado a cada cliente. Si
tenemos varios miles de clientes, ésta es una operación que puede durar bastante tiempo, y
mientras se produce puede que sea necesario atender otras peticiones. Por la estructura propia
de la transacción (o se ejecuta al completo, o no se hace nada), es necesario hacer uso de
copias de cada ficha de cliente afectado (de manera que si se produce algún problema, se
destruyen todas las copias, pero los originales quedan intactos). ¿Qué ocurre si mientras se
gestionan las copias de las fichas aparece una petición de cambiar el crédito máximo del cliente
Bar Juamig? ¿Se le aumenta también el 2'8%, se pone el nuevo valor, o se deja como estaba?
Todo esto debe ser gestionado también por el S.G.B.D., que debe asegurar que el resultado
final debe ser consistente, y debe informar al usuario afectado si se ha producido algún error
en la transacción que intentó realizar.
- Controlar la seguridad en los accesos a los datos.
En los antiguos sistemas de fichas de cartón, los ficheros más importantes se hallaban
fuera del alcance de la mayoría de los usuarios, y sólo podían tener acceso algunos
privilegiados. Este método de seguridad tomaba muchas formas, según el grado de seguridad
con que se quería dotar a esos datos: puertas con cerrojo, tarjetas magnéticas, guardas de
seguridad con porras disuasorias, e incluso encriptación de los datos más importantes, al más
puro estilo del agente 007.
Cuando se trabaja con ficheros electrónicos, el ordenador que los almacena, como se
indicó en el apartado anterior, suele recibir peticiones de otros terminales, con lo que el acceso
a los datos no está restringido sólo a los que tocan el ordenador directamente, pudiendo ser
utilizado desde un terminal remoto situado, posiblemente, en cualquier parte del mundo. Por
tanto los métodos de seguridad tradicionales no son suficientes (aunque siguen siendo
necesarios con objeto de, p.ej., evitar la destrucción malintencionada del ordenador central por
parte de algún saboteador industrial, o por algún hecho fortuito), y es necesario recurrir a
medios electrónicos de protección que impidan acceder a los datos más importantes, excepto

4
Introducción a los Sistemas de Bases de Datos.

a aquellas personas que estén autorizadas.


P.ej., el departamento de pedidos no tiene porqué tener acceso a las nóminas del
personal de la empresa, datos que estarán restringidos al personal contable de la misma.
Para conseguir esto, se asignan una serie de prioridades a cada usuario, así como un
nivel de seguridad a cada tipo de dato, de manera que cada usuario sólo puede acceder a los
datos de nivel inferior o igual a su prioridad. Además, existe un registro electrónico que toma
nota de los accesos a los datos de mayor nivel, dejando así constancia de la fecha, hora y
usuario que efectuó el acceso, o intentó un acceso frustrado.
Todo esto es llevado a cabo por el S.G.B.D. y debe ser inspeccionado regularmente
por el departamento de proceso de datos, en busca de intentos de violación del sistema.
- Asegurar la integridad de la base de datos.
Este es uno de los aspectos más importantes, y que hacen uso intensivo de la
capacidad de los ordenadores para procesar la información.
Los datos deben poseer unas características determinadas en función de lo que se
pretende hacer con ellos, y del área de trabajo en que se desarrolla la empresa. Nos referimos
a características que hacen que los datos almacenados representen una información coherente
para el usuario que los maneja. Es lo que se llama la Integridad de la base de datos.
P.ej., se debe impedir que en el NIF de un cliente se coloque su Nombre, o que su Nº
de teléfono aparezca vacío, o incluso cosas más complejas que relacionen varios ficheros,
como p.ej. que haya un pedido pendiente a proveedor, y dicho proveedor no exista en el
fichero de proveedores, o que haya una reserva de viaje en un vuelo que no existe, o incluso
que el número de reservas en un vuelo a Bangkok supere el overbooking máximo permitido
(el 10%).
Todas estas son restricciones de integridad que el S.G.B.D. debe mantener en la base
de datos, permitiendo, eso sí, en los casos en que sea necesario, una situación momentánea de
falta de integridad, como p.ej. insertar una reserva por parte de un cliente inexistente, siempre
y cuando el usuario asegure que va a dar de alta en breve a dicho cliente.

Ver Silberschatz, capítulo 1.

Definición de base de datos.

Existen numerosas definiciones de lo que es una base de datos, y de lo que es un S.G.B.D. De


hecho, a menudo se confunden ambos términos dada la relación biunívoca existente entre ambos.
La definición más aceptada dice algo así como:
«En esencia, una base de datos no es más que una colección de información que existe a lo largo de
un período de tiempo, a menudo de varios años. Más claramente, el término base de datos se refiere
a una colección de datos gestionada por un Sistema Gestor de Bases de Datos, S.G.B.D., o
simplemente Sistema de Bases de Datos». Ver Ullman: A first course in database systems.
Silberschatz extiende un poco más el concepto de base de datos, incluyendo en el término a
los programas para acceder a estos datos, aunque no deja claro si son sólo los programas
componentes del S.G.B.D., o incluye también a los programas de aplicación, hecho que, otros autores,

5
Introducción a los Sistemas de Bases de Datos.

como Julio Carmona, dan por sentado, aunque con mucha menos rigurosidad.
Nosotros consideraremos como base de datos a la colección de datos junto con el S.G.B.D.
Idealmente, el S.G.B.D. debe poseer una serie de características indispensables para satisfacer
a los usuarios:
- Debe poseer un lenguaje de definición de datos que permita fácilmente la creación de nuevas
bases de datos, así como la modificación de su estructura.
- Debe poseer un lenguaje de manipulación de datos, que permita la inserción, eliminación,
modificación y consulta de los datos de la base, de la forma más eficiente y conveniente
posible.
- Debe permitir el almacenamiento de enormes cantidades de datos (miles de millones de
caracteres), sin que el usuario perciba una degradación en cuanto al rendimiento global del
sistema.
- Debe permitir la gestión segura de los datos, con respecto a accesos no autorizados, y a
accidentes producidos por los dispositivos mecánicos o electrónicos que soportan los datos
almacenados.
- Debe permitir el acceso simultáneo por parte de varios usuarios, impidiendo además, que
dichos accesos concurrentes den lugar a datos corruptos o inconsistentes.
- Debe suministrar independencia física de los datos, que asegure que, sea cual sea la
estructura de los datos en los dispositivos electromecánicos de almacenamiento, el usuario y
las aplicaciones los percibirán siempre de manera uniforme y útil.

Estas características dan lugar a otra definición de base de datos, quizás más orientada a la
moda actual en informática: el diseño orientado a objetos, que consiste en hacer programas viendo el
mundo como un conjunto de objetos que se relacionan entre sí para conseguir un objetivo común.
Según esta visión, podemos considerar una base de datos como «una organización coherente de datos
permanentes, y accesibles para usuarios concurrentes». Esta definición lleva implícito el concepto de
S.G.B.D., ya que es éste quien se debe encargar de almacenar los datos (y por tanto de hacerlos
permanentes y no volátiles), de gestionar su integridad (y por tanto de que sean coherentes), y de
controlar a los múltiples usuarios (permitiendo así la concurrencia).

La forma en que las distintas bases de datos comerciales y académicas abordan estas
características difieren enormemente, no sólo por las técnicas utilizadas sino también por las
aproximaciones o paradigmas con que se han desarrollado. Aunque en el tema 2 haremos un breve
estudio de los tipos de bases de datos, nos centraremos exclusivamente en el tipo más extendido: las
bases de datos relacionales, ya que tienen un formalismo subyacente que las hace muy potentes.
Además, fueron desarrolladas hace ya bastantes años, y han evolucionado lo suficiente como para
suministrar poderosas herramientas que hacen fácil su gestión. De hecho, todas las características que
hemos visto que debe poseer un S.G.B.D., son suministradas a través de entornos e interfaces
amigables y comprensibles que permiten un rápido aprendizaje de todas las funciones propias de una
base de datos.
En contraposición, otro tipo de bases de datos, como las Orientadas a objetos, requieren que
casi todas las funciones de creación de base de datos, manipulación, etc., se efectúen a través de
programas, lo cual requiere un profundo conocimiento de las técnicas de programación, impropio de

6
Introducción a los Sistemas de Bases de Datos.

una carrera como la de Turismo.


Por otro lado, sistemas igual de evolucionados, como el jerárquico o en red, han caído en
desuso, y su aprendizaje supone un esfuerzo que aporta más bien poco al estudiante que debe
enfrentarse de inmediato ante un mundo de datos básicamente relacional.

Componentes de un sistema de base de datos.

Hasta ahora hemos visto una idea general de lo que es una base de datos, y la necesidad de
que exista un gestor central que separe los datos en sí de los usuarios, y que facilite una serie de tareas,
así como se asegure de que se cumplen determinados requisitos indispensables para el buen
funcionamiento del sistema.
Ahora vamos a desmenuzar un poco más el concepto de base de datos, y vamos describir sus
componentes básicos, justificando además la necesidad de cada uno de ellos.

Datos.

Efectivamente, una base de datos no tiene sentido sino está compuesta por datos. Lo que no
está tan claro es la forma en que estos datos se deben disponer, qué datos se deben almacenar, y cómo
los debe entender la máquina.
La disposición de los datos depende del ámbito de aplicación concreto en que se enmarque
la base de datos. No es lo mismo una base de datos que almacene un dibujo vectorial de monumentos
históricos que una base de datos para almacenar las reservas de clientes en un hotel. Lo que varía
fundamentalmente en uno y otro caso, es la forma en que los datos se relacionan entre sí, y el tipo de
accesos a la información que va a realizar el usuario.
Además, los datos deben disponerse de manera que las consultas sean lo más eficiente posible,
evitando a la vez la existencia de datos duplicados que pueden dar al traste con la coherencia de la
base de datos. De esta forma, no sólo se consideran datos aquellos que el usuario desea almacenar,
sino toda estructura de apoyo que el sistema necesite para hacer más eficiente una consulta. P.ej.,
supongamos que trabajamos en un hotel cuya base de datos posee un fichero con todas las agencias
de viajes que contratan nuestros servicios de alojamiento en alguno de sus paquetes de viajes.
Supongamos que para facilitar los accesos más comunes tenemos las fichas de tales agencias
ordenadas por nombre. ¿Qué ocurre si queremos acceder a todas las agencias de Egipto para
mandarles una carta felicitándolas por el año nuevo musulmán?. Resulta inaceptable que miremos una
por una todas las agencias de nuestro fichero, ya que esto nos llevaría un tiempo desorbitado.
La solución informática a este problema consiste en crear un fichero aparte cuyas fichas
contienen sólo dos campos: País de la agencia, y Nombre de la agencia. Las fichas de este fichero
estarán ordenadas por País, y dentro de cada país, por orden alfabético del Nombre de la agencia.
Para acceder a las agencias de Egipto, no accedemos al fichero principal, sino que nos dirigimos a este
fichero auxiliar ordenado por país, y de ahí podemos averiguar directamente cuáles son los nombres
de las agencias de Egipto. A continuación nos vamos al fichero principal, accediendo sólo a las fichas
cuyos nombres hemos extraído anteriormente del auxiliar y de estas extraemos la dirección, lo que
permite, finalmente, el envío de las cartas. El fichero auxiliar es lo que se llama un índice del fichero

7
Introducción a los Sistemas de Bases de Datos.

principal.
La gran ventaja de este método, es que el mantenimiento del fichero auxiliar, cuando
trabajamos con un ordenador, lo realiza automáticamente el sistema, lo que nos ahorra la tarea de tener
que escribir explícitamente una ficha auxiliar cada vez que se inserta una nueva agencia en el fichero
principal. De esta forma se obtiene una gran eficiencia en las consultas, sin que el usuario tenga que
trabajar más: el ordenador trabaja por nosotros.
Pues bien, este fichero aparte, creado con el único objetivo de facilitar el acceso a la
información, también lo consideramos datos, aunque deban ser gestionados automáticamente, e incluso
algunos usuarios no tengan ni la menor idea de su existencia.

Por otro lado, es muy importante decidir qué datos son los que se van a almacenar. A menudo
ocurre que en una base de datos se almacenan las facturas con una antigüedad inferior a x años. El
número de años que se desea almacenar una factura electrónicamente puede ser una decisión crucial
dependiendo de la capacidad de almacenamiento de nuestra máquina y del volumen de facturas que
se expidan anualmente.
Además, si casi no se necesita acceder a dicha información histórica, puede ser más interesante
destruir electrónicamente esa información, y almacenarla exclusivamente en papel, con lo que el ahorro
de espacio en disco puede contrarrestar el esfuerzo de hacer las consultas manualmente.
Contrariamente, cuando se crea la base de datos, pueden parecer innecesarios ciertos datos
de un cliente, como p.ej. Fecha de nacimiento. Posteriormente, si trabajamos en una agencia de viajes,
y creamos un paquete de viajes de aventura por la selva del Amazonas, puede interesarnos
promocionarlo sólo a aquellos clientes menores de 35 años, con lo que nos damos cuenta de que
habría sido buena idea almacenar la fecha de nacimiento. Aunque el S.G.B.D. nos permite modificar
la estructura de la base de datos para almacenar este nuevo campo, introducirlo para todos los clientes
es una tarea ardua y fatigosa.

Por último, también es interesante, por cuestiones de seguridad y aprovechamiento de los


recursos del ordenador, decidir en qué formato se van a almacenar los datos: si se van a almacenar
encriptados para que nadie los pueda copiar, o si se van a codificar o a comprimir de alguna forma
para hacer que ocupen menos espacio.
Existe toda una teoría sobre compresión y codificación de datos, que puede hacer que,
dependiendo de las características de los datos a almacenar, se requiera mucha menos memoria de la
necesaria siguiendo los métodos convencionales de almacenamiento.

Metadatos.

La evolución de las bases de datos, ha hecho que los informáticos se den cuenta de
determinados problemas, y que los hayan ido subsanando a medida que perfeccionaban sus productos.
Uno de los problemas que se producían consiste en la propia evolución de la base de datos.
Desde el momento en que se crea una base de datos, hasta el momento en que se desecha
porque se compra un sistema mejor, o se instala una nueva base de datos, la estructura de la base de
datos (o sea, los datos que se deciden almacenar, y la estructura con que se almacenan) cambia a

8
Introducción a los Sistemas de Bases de Datos.

medida que cambian las necesidades sobre la información a obtener de la base de datos, de manera
que puede ser necesario introducir nuevas fichas, nuevos campos en fichas ya existentes, eliminar
campos, modificar lo que se almacena en determinados campos, e incluso reestructurar la base de
datos entera, creando ficheros de apoyo, etc.
Dado que la base de datos que solucione unas necesidades concretas puede adoptar muchas
formas posibles, es muy interesante el poseer algún lugar que indique al personal encargado de
mantener la base de datos, cuál es el objetivo de cada dato particular almacenado en la base, así como
en qué aplicaciones es utilizado, y con qué propósito, si es un dato fundamental, o si puede ser omitido
por el que introduce los datos, etc.
De esta forma, antes de modificar el esquema o estructura de la base de datos, el departamento
de proceso de datos debe consultar esta información sobre los datos de la base, con cuidado para no
cometer errores graves que repercutan sobre el buen funcionamiento de todo el sistema.
Esta información que el sistema guarda sobre los datos almacenados, es lo que se llaman
metadatos. Es más, estos metadatos se almacenan como otra base de datos propiamente dicha, y
puede ser gestionada y consultada como tal.
Estos metadatos suelen conformar lo que se da en llamar diccionario de datos.

El sistema gestor de bases de datos.

El sistema gestor de bases de datos (S.G.B.D.) ha sido ya introducido, y su importancia


destacada en todas las características que debe poseer una base de datos.
Según Silberschatz, podemos considerar un S.G.B.D. como «un programa que proporciona
la interfaz entre los datos de bajo nivel almacenados en la base de datos, y los programas de aplicación
y consultas hechos al sistema».
Ya hemos indicado las características propias de una base de datos, la mayoría de las cuales
recae precisamente sobre el S.G.B.D. Para dejarlas más patentes, las reunimos y ampliamos aquí:
- Interactuar con el Sistema Operativo. Como se ha indicado, el S.G.B.D. no es más que un
programa. El Sistema Operativo es el programa principal que se encarga de controlar que el
ordenador funciona bien, entre otras cosas permitiendo el acceso a los dispositivos de entrada
y de salida, como el teclado, el ratón, el monitor, y los dispositivos de almacenamiento: el disco
duro, las disqueteras, el CD-ROM, las cintas magnéticas, etc.
Así, para asegurar que no pasan cosas raras, el único que puede tocar estos
dispositivos es el Sistema Operativo (S.O.). Dado que el S.G.B.D. necesita almacenar datos
en el disco duro, p.ej., debe interactur con el S.O. para poder acceder al disco duro y que allí
se almacenen los datos que se quieren. Igualmente debe contactar con el S.O. siempre que
desee recuperar algún dato de estos dispositivos.
- Mantener la integridad. Como ya se ha dicho, debe mantener las restricciones de integridad
propias de la aplicación concreta que sea. P.ej., evitar que la edad de un cliente supere los 90
años.
- Mantener la seguridad. Evitar accesos fraudulentos a los datos, así como la extracción de
información codificada.
- Permitir las copias de seguridad. Dado que un ordenador no es un sistema infalible, y puede

9
Introducción a los Sistemas de Bases de Datos.

romperse por causas propias (fallo de un circuito), o ajenas (aumento de la tensión en la red
eléctrica), es posible que los datos almacenados por él lleguen a corromperse con la
consiguiente pérdida de información y los problemas que ello puede acarrear a la empresa.
Para evitar estos desagradables resultados, es buena idea el efectuar una copia de los
datos a un dispositivo auxiliar de almacenamiento, pensado precisamente para guardar fiel
copia del contenido de la base de datos en un momento determinado. Si los datos originales
se destruyen, bastará volcar la copia sobre el disco duro del ordenador central, con lo que lols
datos volverán a tomar la misma forma que cuando se efectuó la copia. De esta manera, para
que la base de datos recupere la forma que tenía en el momento en que quedó destruída,
bastará con efectuar los cambios que se hicieron en el tiempo transcurrido desde la copia de
seguridad que se acaba de volcar.
- Controlar la concurrencia. Como ya se explicó anteriormente, debe permitirse el acceso
simultáneo a los datos por parte de varios usuarios, lo que conlleva numerosos problemas de
coherencia y coordinación. el S.G.B.D. debe controlar que la información representada por
los datos al final de cada acceso de usuario siga siendo consistente.
- Suministrar mecanismos que faciliten la interacción con la base de datos. Estos mecanismos
suelen venir dados en forma de lenguajes de manipulación y definición de datos. Además,
suministran indepencia de los datos, en el sentido de que, a pesar de la evolución del esquema
de los datos, las aplicaciones deben sufrir las mínimas modificaciones imprescindibles. P.ej.,
si las aplicaciones antiguas están pensadas para trabajar sobre números de teléfono expresados
mediante dígitos, ¿qué ocurre si se decide cambiar todos llos números a formato textual? En
este caso, debe haber un mecanismo que oculte a las aplicaciones antiguas el nuevo formato
de los números de teléfono, y le haga vez el formato antiguo; en definitiva, debe haber algo que
suministre a las aplicaciones antiguas una visión ligeramente distinta de lo que hay realmente
almacenado en la base de datos.

Usuarios de la base de datos. El administrador.

Hasta ahora, hemos entendido como usuarios a aquellos individuos que esperan
obtener algún resultado de la base de datos. Sin embargo, también podemos considerar usuario a toda
persona encargada del mantenimiento y puesta a punto de los datos. De esta forma, podemos dividir
a los usuarios en dos grandes grupos:
a) Administrador. Es aquella persona o conjunto de personas encargada (exclusivamente, en
la mayoría de los casos) del control global de la base de datos. Sus tareas son:
- Definición del esquema: Como se ha indicado, el esquema de una base de datos está compuesto por
el tipo de fichas que almacena, el formato que toman cada una de ellas, así como sus características
y reglas para ser rellenadas.
El administrador es, pues, quien decide qué se va a almacenar, y cómo. La información del
esquema debe ser almacenada como metadatos, o sea, información sobre el formato de los datos
almacenados.
- Definición de la estructura de almacenamiento y de los métodos de acceso. Indicamos anteriormente
que el S.G.B.D. interactuaba con el S.O. para poder acceder a los datos guardados sobre los

10
Introducción a los Sistemas de Bases de Datos.

dispositivos de almacenamiento, o sea en los ficheros. Pues bien, estos ficheros están a su vez
estructurados en base a unidades más pequeñas con el objetivo de facilitar al S.O. el acceso a los
datos. Es tarea del administrador el decidir las características de estas unidades mínimas de
almacenamiento a fin de agilizar la recuperación de los datos, y de mejorar los accesos en función de
las características propias de las consultas más frecuentes por parte de los usuarios.
También en base a las consultas más frecuentes, el administrador debe decidir sobre la
necesidad de mantener estructuras de apoyo que hagan más fácil la recuperación de determinados
datos. Cuando hablamos de estructuras de apoyo, nos referimos a los índices que veíamos en un punto
anterior. Creando los índics apropiados, la velocidad de determinadas consultas puede aumentar
vertiginosamente, incrementando así la satisfacción de los usuarios en el manejo de la base de datos.
Por otro lado, veíamos que los índices son mantenidos automáticamente por el sistema, lo que puede
producir ralentizaciones ante algunas operaciones de inserción, eliminación o modificación de datos,
sin que aparentemente haya motivo alguno. Además, un índice ocupa un espacio cuyo tamaño depende
del del fichero original, por lo que la creación de excesivos índices puede requerir una cantidad de
memoria nada proporcional a los beneficios obtenidos de su utilización.
- Modificación del esquema y de la organización física. A medida que la empresa que utiliza la base
de datos evoluciona para adecuarse a las condiciones cambiantes del mercado, es necesario adecuar
dicha base de datos a las necesidades cambiantes que se producen. De esta forma, debe ser posible
alterar el esquema de los datos, así como la forma de almacenamiento para hacer que las nuevas
necesidades sean satisfechas de forma eficiente.
Asimismo, es interesante que las aplicaciones antiguas sigan funcionando con un mínimo de
modificaciones, por lo que es de desear que, a pesar de dichas modificaciones, las aplicaciones
antiguas tengan una visión alterada de los datos, pero adecuada a su forma de funcionamiento. Por
supuesto, estas visiones, o vistas, deben ser coherentes con los datos almacenados en el esquema
nuevo, y no tergiversar el contenido de los datos.
- Concesión de permisos y privilegios para el acceso a los datos. Asignación de prioridades a los
datos. Para gestionar la seguridad en la base de datos, hemos comentado la necesidad de que los datos
dispongan de una serie de niveles de importancia, de manera que sólo puedan ser accedidos por los
usuarios con un privilegio superior o igual a dicho nivel. Pues bien, es el administrador quien se encarga
de asignar dichos niveles y privilegios, en función de las características particulares de cada usuario.
Asimismo, debe asignar inicialmente las claves de acceso a los usuarios, ya que cada uno de ellos sólo
puede acceder al sistema mediante una contraseña particular.
- Especificación de restricciones de integridad. Los datos almacenados en la base de datos guardan
una relación entre sí, en función de las necesidades que pretenden cubrir, de manera que la información
que se pueda extraer de ellos sea útil y coherente. Esta coherencia viene determinada por un conjunto
de reglas o restricciones que los datos deben poseer; p.ej. ningún cliente debe tener pendientes de pago
facturas cuyo montante supere el crédito máximo permitido. El administrador debe indicar estas
restricciones de integridad, así como modificarlas o flexibilizarlas a medida que evolucionan las
necesidades de la empresa.
A menudo, estas restricciones se suelen considerar incluso como parte integrante del esquema,
con lo que también quedan reflejadas en el diccionario de datos.

b) Otros usuarios. El resto del personal que interactúa con la base de datos puede considerarse

11
Introducción a los Sistemas de Bases de Datos.

simplemente como usuarios, aunque también podemos distinguir distintos tipos entre ellos:
b.1) Programadores de aplicaciones. suelen formar parte del departamento de proceso de
datos. Reciben peticiones de otros usuarios, en forma de necesidades de acceso a los datos,
y se encargan de escribir los programas que satisfacen dichas necesidades. Normalmente estos
programas están escritos en un lenguaje de programación convencional (pascal, Basic, C, etc.),
en el que se insertan órdenes especiales que es capaz de comprender el S.G.B.D. De esta
forma el S.G.B.D. suministra los datos, y el lenguaje convencional (también llamado anfitrión
porque alberga las sentencias reconocidas por el S.G.B.D.) los procesa, presenta al usuario,
modifica, etc.
b.2) Usuarios directos. Son aquellos que interactúan con la base de datos haciendo uso
directamente del lenguaje que proporciona el S.G.B.D. En posteriores capítulo estudiaremos
el SQL como principal lenguaje de manipulación y definición de datos. El administrador debe
tener cuidado con la prioridad que asigna a estos usuarios, ya que al tocar directamente sobre
la base de datos, pueden alterar su estructura si disponen de contraseñas de alta prioridad, o
si por error se les ha suministrado una prioridad demasiado grande.
b.3) Usuarios indirectos. Son aquellos que no saben nada de la base de datos, excepto que
existe. Interaccionan con ella a través de las aplicaciones desarrolladas por los programadores,
y son incapaces de acceder a los datos directamente a través del lenguaje del S.G.B.D. El
administrador debe prestar especial atención a que este tipo de usurios no acceda directamente
a los datos por los problemas que su inexperiencia pueda acarrear.

Elementos de seguridad.

El administrador debe conocer en profundidad los elementos de seguridad que suministra el


S.G.B.D. de que dispone, y sacar el máximo partido posible de ellos. En general, se pueden tener
niveles de acceso clasificados por:
- Las fichas o tuplas a que se tiene acceso. En una empresa grande y ampliamente informatizada, cada
usuario debe poder acceder exclusivamente a los datos que competen a su tarea. El departamento de
contabilidad no tiene porqué acceder a la información sobre reservas de alojamiento, aunque sí a las
peticiones de tintorería, para hacer los cargos correspondientes a cada cliente. A su vez, el
recepcionista, sól accederá a las reservas efectuadas, y podrá abrir una factura de alojamiento en la
que se irán insertando por parte de cada sección del hotel los cargos de los servicios prestados al
cliente, pero no podrá tener en ningún momento acceso a las nóminas, ya que ello es responsabilidad
de la habilitación.
De esta forma vemos que cada usuario sólo debe tener acceso a un tipo de información, o lo
que es lo mismo, a un tipo de fichas determinado. Por tanto, debe existir un mecanismo de seguridad
que restrinja el ámbito de acceso de cada usuario en función de sus competencias.
- Las operaciones que se pueden realizar sobre las fichas o tuplas. Siguiendo con el caso anterior, la
sección de contabilidad tendrá acceso a las facturas a clientes, pero no podrá modificarlas, sino tan
sólo consultarlas a efectos contables para generar el balance de cada mes. Por otro lado, las diferentes
secciones de cafetería, restaurante, tintorería, sauna, joyería, etc. sí que deben poder acceder a las
facturas de los clientes para realizar en ella los cargos pertinentes. Sin embargo, no podrán crear

12
Introducción a los Sistemas de Bases de Datos.

facturas nuevas, si sólo pueden atender a clientes que se alojen en el hotel.


Por tanto, no sólo es importante el acceder o no a los datos, sino también la forma en que este
acceso se produce, en función de las características propias de la sección: la habilitación sólo puede
consultar facturas de clientes; la recepción puede crear y modificar, así como cerrar una factura; la
tintorería sólo puede añadir cargos; la joyería puede crear y añadir cargos, etc.
En general, las operaciones que se pueden efectuar sobre un tipo de fichas se agrupan en
cuatro grandes bloques: Altas, Bajas, Modificaciones, y Consultas.
- El acceso al diccionario de datos y a la estructura de la base de datos. Como se ha comentado
anteriormente, los metadatos almacenados en el diccionario de datos y que almacenan información
sobre la estructura de la base de datos, son gestionados, a su vez, como si de una base de datos
especial se tratase. Sin embargo, dada su primordial importancia, su acceso debe estar muy restringido,
ya que cualquier modificación puede dar lugar a resultados desastrosos en la base de datos: pérdida
de información, corrupción en los datos, falta de integridad, etc. Por ello, es necesaria la existencia de
prioridades o privilegios especiales que sólo permitan el acceso al personal que compone la
administración de la base de datos, que es el único capacitado para modificar estos metadatos.

Lenguajes de bases de datos.

La interacción del usuario con la base de datos debe efectuarse a través de alguna técnica que
haga fácil la comunicación, y que permita al usuario centrarse en el problema que desea solucionar, más
que en la forma de expresarlo con las técnicas que se le suministran. La mejor forma de alcanzar este
objetivo, es darle un lenguaje parecido al lenguaje natural, que le permita expresar de forma sencilla
los requerimientos. en función de estos requerimientos, podemos tener, fundamentalmente dos tipos
de lenguajes para comunicarnos con el S.G.B.D.:
- Lenguaje de definición de datos (LDD). Este lenguaje es utilizado en exclusiva por el administrador
de la base de datos, ya que permite la construcción de frases o sentencias que le indican al S.G.B.D:
las características particulares de la base de datos sobre la que se está trabajando, así como la creación
de nuevas bases de datos. La creación de esquemas y su modificación, la creación y supresión de
índices, la especificación de unidades de almacenamiento en los ficheros, así como la asignación y
privación de prioridades se realizan a través de este lenguaje. Además permite la creación y
recuperación de copias de seguridad, así como la importación de datos desde sistemas antiguos, y la
exportación a nuevos sistemas que vayan a sustituir al actual.
- Lenguaje de manipulación de datos (LMD). El lenguaje de manipulación de datos es el que usan los
usuarios directos para efectuar sus operaciones sobre la base de datos. Como se indicó, estas
operaciones son básicamente de inserción, eliminación,modificación y consulta de datos, aunque
también se pueden introducir capacidades para crear visiones de los datos que faciliten otros accesos.
Los usuarios directos interacciones con el S.G.B.D. a través de este lenguaje, mediante una interfaz
agradable y fácil de usar.
Los programadores de aplicaciones emplean el LMD dentro de un lenguaje de programación
queles da potencia expresiva, o sea permite sacar cosas por pantalla de una forma agradabla, facilitar
las operaciones de los usuarios indirectos, etc. Para ello, el LMD que emplean se extiende de diferentes
formas para poderse integrar fácilmente en el lenguaje anfitrión, ya que ambos, LMD y lenguaje

13
Tipos de Bases de Datos.

anfitrión deben poderse comunicar adecuadamente para que las aplicaciones resultantes sean
simples de programar y de utilizar.

Modelo relacional.

En este apartado tan sólo daremos unas nociones iniciales sobre este modelo, ya que todo
nuestro trabajo se basará en él, y será estudiado con mucho mayor detalle en capítulos posteriores.
Este modelo intenta representar la base de datos como un conjunto de tablas. Aunque las
tablas son un concepto simple e intuitivo, existe una correspondencia directa entre el concepto
informático de una tabla, y el concepto matemático de relación, lo cual es una gran ventaja, pues
permite efectuar formalizaciones de una forma estricta mediante las herramientas matemáticas
asociadas, como pueda ser el álgebra relacional en el ámbito de las consultas.
Gracias a Dios, no será necesario enfrentarnos con todos estos formalismos propios de los
matemáticos, sino que dispondremos de unas herramientas fáciles de manejar que nos permitirán
interactuar con la base de datos.
Los conceptos básicos del modelo relacional son:
- Registro: Es algo así como cada ficha de un fichero convencional.
- Tabla: Es un conjunto de fichas de un mismo tipo.

Con estos dos conceptos es posible crear cualquier tipo de datos, y asociarlos entre sí, sin las
restricciones propias del modelo jerárquico o en red. P.ej., si necesitamos diseñar una base de datos
para una agencia de alquiler de coches, necesitaremos una tabla en la que se guarde información sobre
los coches, como puede verse en la figura.

14
Tipos de Bases de Datos.

De esta forma, vemos que cada tabla


Marca Modelo Color Matrícula Situación
está compuesta por filas, también llamadas
Lamborghi. Diablo 630 Amarillo MA-2663-BC En renta
tuplas o registros, cada uno de los cuales
Ferrari F-40 Rojo MA-8870-BC Disponible
posee una serie de campos en los que se
almacenan los datos básicos. El esquema de Sbärro R. Decade Blanco VD-870-GTH Disponible

una tabla nos indica los nombres de cada uno De Tomaso Pantera Blanco ML-7890-B En renta
de los campos que contiene, así como el tipo Pontiac Trans-Am Negro KNIGHT En taller
de información que debe contener. Austin M. S3'40 Marrón CA-5647-AB Disponible
Una tabla es para nosotros un conjunto
Jaguar Destructor Verde AD-768-TTY En renta
de registros; por tanto, los registros no pueden
repetirse. Figura 7Ejemplo de tabla relacional.
Para poder acceder a un registro
concreto, es necesario hacer una consulta a través de algún campo que identifique a dicho registro,
como puede ser p.ej. el número de la matrícula. A este campo especial que identifica cada registro se
le llama clave del registro. La figura siguiente ilustra una tabla de clientes.
En el modelo anterior disponíamos de Apellidos Nombre D.N.I. Edad
los conjuntos para asociar información entre sí;
González Aranda Javier 75836934 27
¿cómo nos las apañamos para indicar ahora
qué cliente se hace responsable de cada coche Beato Apóstol Antonio 28836746 43
alquilado? Fácilmente, a través de una nueva Campos Ortega Adriano 82665358 36
tabla que relaciona los clientes con los coches. Ruíz Rojo Juan 83667228 35
Para ello dado que cada registro queda Figura 8Tabla de clientes de la agencia
identificado por su clave, nos basta con incluir de alquiler de coches.
en esta nueva tabla a las claves de ambas
tablas, en lugar de todos sus campos. Así, podemos obtener una nueva tabla de alquileres que contenga
la matrícula del coche, y el D.N.I. del cliente, tal como se ve en la figura siguiente.
En esta última tabla podemos observar varias cosas interesantes. Por un lado, un cliente se
puede responsabilizar de más de un coche, o sea, puede alquilar más de un coche, pues vemos que
Javier González Aranda ha alquilado tanto el Lamborghini como el Jaguar. Pero, a su vez, más de una
persona puede hacerse cargo de un coche: Javier González Aranda y Adriano Campos Ortega
comparten el alquiler del Jaguar.
De esta forma, el modelo relacional soluciona
Matrícula D.N.I.
el problema que se planteaba en el caso de las listas
de embarque mediante enlaces artificiosos, y lo MA-2663-BC 75836934
soluciona de una manera intuitiva a través de las ML-7890-B 83667228
tablas, y eliminando el concepto de conjunto. AD-768-TTY 75836934
Este método de expresar los datos facilita AD-768-TTY 82665358
además las consultas, que se realizan ahora a través
Figura 9Tabla que relaciona los
de estas tablas especiales que relacionan a otras coches en renta con los clientes
tablas. P.ej., si queremos saber los coches que ha que se responsabilizan de ellos.
alquilado González Aranda, basta con buscar su clave
en la tabla de clientes (75836934), y a continuación ver que matrículas tiene asociadas en la tabla de
alquileres (MA-2663-BC, y AD-768-TTY); a continuación, buscamos en la tabla de coches cuales

15
Tipos de Bases de Datos.

son los coches que poseen esas claves, y obtenemos como resultado: Lamborghini y Jaguar.
Por otro lado, además de los modelos propios de base de datos existentes en la realidad,
existen los llamados modelos semánticos, que permiten expresar relaciones entre los datos,
independientemente del tipo de base de datos que se emplee finalmente. Uno de estos modelos, el
modelo Entidad-Relación, que estudiaremos en el capítulo siguiente, tiene grandes similitudes con el
modelo relacional, siendo esta otra gran ventaja del modelo relacional, esto es, se pueden expresar las
relaciones entre los datos a través de diagramas fáciles de comprender y de modificar, y,
posteriormente, pasar el resultado a un esquema relacional.

16
El modelo relacional.

EL MODELO RELACIONAL
En capítulos anteriores hemos estudiado que existen distintos modelos según los cuales la
información puede ser almacenada y relacionada entre sí. Actualmente, para la mayoría de las
aplicaciones de gestión que utilizan bases de datos, el modelo más empleado es el modelo relacional,
por su gran versatilidad, potencia y por los formalismos matemáticos sobre los que se basa.
Este modelo permite representar la información del mundo real de una manera intuitiva,
introduciendo conceptos cotidianos y fáciles de entender por cualquier inexperto. Asimismo, mantiene
información sobre las propias características de la base de datos (metadatos), que facilitan las
modificaciones, disminuyendo los problemas ocasionados en las aplicaciones ya desarrolladas. Por otro
lado, incorpora mecanismos de consulta muy potentes, totalmente independientes del S.G.B.D., e
incluso de la organización física de los datos; el propio S.G.B.D. es el encargado de optimizar estas
preguntas en formato estándar, a sus características propias de almacenamiento.
El modelo relacional fue propuesto por E.F. Codd en los laboratorios de IBM en California.
Se trata de un modelo lógico [Irene Luque Ruiz- Ed. Ra-ma], que establece una estructura sobre los
datos, aunque posteriormente éstos puedan ser almacenados de múltiples formas para aprovechar
características físicas concretas de la máquina sobre la que se implante la base de datos realmente. Es
algo así como guardar unos libros en una biblioteca; dependiendo del número de salas de la biblioteca,
del tamaño y forma de cada una de ellas, su número de estanterías, y en definitiva, de las características
físicas del recinto, podremos disponer los libros de una forma u otra para hacer más cómoda y fácil su
consulta y acceso. Los libros son los mismos, pero pueden ubicarse de muy distintas formas.

Vamos a estudiar entonces, las características concretas de este modelo de datos, sin entrar
para nada en cómo los almacena físicamente cada ordenador, o cada S.G.B.D.

Estructura general.

El nombre de modelo relacional viene de la estrecha relación que existe entre el elemento
básico de este modelo, y el concepto matemático de relación. Podemos decir que una relación R sobre
los conjuntos D1, D2, .., Dn, se define como:
R f D1 × D2 × ... × Dn
donde los conjuntos D1, D2, .., Dn pueden ser
Nombre
cualesquiera, e incluso estar repetidos.
Los conjuntos pueden ser Juan
Antonio Nombre Oficio Sueldo
cualesquiera, aunque en el momento en que se - Juan Cocinero 100
trabaja con ordenadores, hay que imponer Pedro Oficio - Pedro Botones 700
- Juan Cocinero 200
ciertas restricciones de discretización. Cocinero - Pedro Cocinero 700
- Juan Cocinero 1200
Botones
100
Si nos fijamos en el dibujo adjunto, 200 Esto es una relación.
Dado que se trata de un conjunto
podemos ver que una de estas relaciones no es 500 700 no puede haber elementos
repetidos.
más que una lista de líneas, donde cada línea 1200
está dividida en trozos. Sueldo

17
El modelo relacional.

Para observar bien el porqué ha surgido el método relacional, pensemos en cómo


almacenaríamos las líneas de la lista anterior, si los ordenadores no existiesen.
Para almacenar estas líneas, tendríamos que emplear papel, de manera que en un folio
escribiríamos todas las líneas de la lista, empezando por la primera y continuando en el folio
secuencialmente; si el folio se acaba, cogemos otro, y hacemos la misma operación, de forma que, al
final, la lista está escrita o almacenada en varios folios. Este método, que es el más directo, tiene el
problema de qué ocurre cuando se desean introducir nuevas líneas. Inicialmente, la tarea parece fácil,
pues nos basta con seguir escribiendo líneas tras la última línea de la última página, e ir tomando nuevos
folios a mediada que las páginas se vayan llenando. No obstante, este método sólo es adecuado si las
líneas no están ordenadas según un criterio. Si las líneas ya están ordenadas, y deseamos introducir una
nueva, ¿cómo lo hacemos?, ¿escribiendo una línea por enmedio con letra más pequeña?, o bien
¿escribiendo de nuevo todas las líneas, pero esta vez con la que se desea insertar? Está claro que
ninguna de estas posibilidades es una solución factible.
Otra posibilidad de registrar esas líneas es utilizando una ficha de cartón para cada una de ellas.
Cada ficha de cartón será parecida a las que el alumno rellena para el profesor de cada asignatura a
la que asiste, con la variante de que en lugar de poner el nombre, apellidos, dirección, etc. del alumno,
se pondrá la información que nos interese guardar. de esta manera cada línea queda almacenada en
una ficha de cartón. Si se desea insertar una nueva ficha basta con rellenarla y meterla en su posición
adecuada. De la misma forma se puede proceder a la hora de eliminar alguna ficha.
Pues bien, este último método es el
que, a grandes rasgos, intenta utilizar el modelo Nombre: Juan
Oficio: Cocinero
relacional. El modelo relacional representa las Sueldo: 100
listas de líneas mediante registros o fichas cada Nombre: Pedro
una de las cuales puede ser manejada Oficio: Botones
Nombre: Juan
Sueldo: 700Oficio: Cocinero
individualmente y con independencia de las Sueldo: 200
demás. No obstante, a efectos de facilitar la Nombre: Pedro
Oficio: Cocinero
visualización, puede ser posible ver todas las Sueldo: 700
líneas juntas como si de una lista se tratase. Nombre: Juan
Ver figura. Oficio: Cocinero
Sueldo: 1200
De esta manera, tendremos varios
tipos de fichas: fichas de clientes, de
proveedores, de facturas, de albaranes, de reservas, de empleados, de apuntes contables, etc., cada
una de las cuales podemos almacenar en un cajón o en un fichero independiente. De cada tipo de ficha
tendremos un montón de fichas rellenas: 100 ó 200 clientes, 4 ó 5 proveedores, miles de facturas, etc.
Por tanto, es interesante distinguir entre un tipo de ficha, que no hace referencia a ninguna ficha rellena
en concreto (p.ej. una ficha de clientes), y una ficha concreta, rellena con unos datos concretos (la ficha
de Juan el Cocinero).
Pues bien, el modelo relacional plasma en un ordenador este mismo esquema, aprovechando
las enormes características de computación y almacenamiento de las máquinas actuales.

Concepto de tabla. Dominios y atributos.

18
El modelo relacional.

Una tabla en el modelo relacional viene a ser como una de las listas descritas anteriormente.
Una tabla o relación es una matriz rectangular que almacena líneas con una estructura concreta:

• La primera línea de una tabla, es una cabecera que indica el nombre de cada columna. O sea, cada
columna tiene asignado un nombre único, e indica que los ítemes almacenados en esa columna
deben pertenecer a un conjunto de valores concreto: Números, Letras, Frases, etc.
• Cada línea (excepto la primera) recibe el nombre de tupla, y almacena ítemes concretos para cada
columna.
• Todas las filas deben ser diferentes entre sí.
• El orden de las filas y de las columnas carece de importancia a efectos del S.G.B.D. Este hecho es
el que verdaderamente diferencia las tablas relacionales del concepto matemático de relación, en
el que el orden de las columnas es fundamental.

En la figura aparece una tabla de


PLATOS
Platos. Toda tabla debe poseer al menos la
primera línea, que identifica el nombre de la Código Nombre Precio Menú
columna. En este caso, nuestra tabla o relación 15 Solomillo a la pimienta 1000 No
contiene las columnas Código, Nombre, 23 Fondue Neûchatel 1500 No
Precio y Menú (que indica si ese plato 17 Migas con chocolate 850 Sí
pertenece o no a las opciones del menú del 34 Ajo blanco con uvas 850 Sí
día). 12 Paella valenciana 1100 Sí
El grado de esta tabla es el número de 21 Mono a la cantonesa 7500 No
campos que posee, en nuestro caso 4. La 07 Sopa de aleta de tiburón 525 Sí
cardinalidad es el número de tuplas concretas
que almacena: 7. Nótese que el grado de una
tabla es independiente del momento en que observemos la tabla (el número de columnas es invariable,
y queda definido en el momento en que se crea la tabla), mientras que la cardinalidad depende de la
situación real que represente la tabla y puede variar en el tiempo; p.ej., la lista de platos puede cambiar
todos los meses, o según la estación del año, para adecuarse a los gustos propios de cada una de ellas.

La primera fila de una tabla es la más importante, ya que nos da su estructura. Esta columna
identifica los nombres de campo o atributos de que consta cada tabla. En otras palabras, cada tupla
está formada por un conjunto de información estructurada en elementos más simples llamados atributos.
El nombre del atributo debe describir el significado de la información que representa. En la tabla
Platos, el atributo Precio tendrá como cometido almacenar el valor en pesetas con el que ese plato
se vende al público. A menudo suele ser necesario añadir una pequeña descripción a cada atributo que
aclare su naturaleza: ¿el precio lleva I.V.A. o no?
En el atributo Menú no está claro que es lo que se almacena. Una descripción del mismo
aclararía más las cosas: Indica si el cliente puede pedir este plato o no en el menú del día.

Por otro lado, está claro que un atributo en una tupla no puede tomar un valor cualquiera, p.ej.,
no tiene sentido que en el precio del Ajo blanco con uvas se guarde una palabra como pueda ser
Gerente. Para evitar este tipo de situaciones anómalas en la medida de lo posible, obligaremos a que

19
El modelo relacional.

cada atributo sólo pueda tomar los valores pertenecientes a un conjunto de valores previamente
establecido, o sea, un atributo tiene asociado un dominio de valores. En el caso anterior se tiene que
el atributo Precio sólo puede tomar valores numéricos, mientras que el Nombre sólo puede contener
frases textuales.
Los dominios a que puede pertenecer un atributo, suelen depender de los que proporcione el
S.G.B.D. que empleemos. Suelen ser comunes dominios como: Texto, Número entero, Número
Sí/No etc.
decimal, Fecha, Hora, Sí/No,
Por otro lado, un dominio como pueda ser Número entero
entero, es un dominio cuyo conjunto de
valores es infinito, y dado que trabajamos con ordenadores, es imprescindible poner un límite que
permita almacenar un valor concreto debido a las limitaciones de memoria, y sobre todo al hecho de
que toda tupla debe poseer el mismo tamaño. Tomemos como ejemplo el Nombre del Plato, que es
evidentemente del tipo TextoTexto; las limitaciones del ordenador nos impiden almacenar nombres
ilimitadamente largos, como puedan ser «Magret de pato al vinagre de grosella con guarnición de higos
malagueños al vino moscatel Pedro Ximénez». Es necesario, por tanto, establecer una cota al número
máximo de letras que podemos teclear, por lo que el dominio del atributo Nombre puede ser Texto
caracteres
de 20 caracteres.
Así, la estructura completa de la tabla Platos quedaría como sigue:

Platos:
Código. Número entero.
Número con el que el plato aparece en la carta.
Nombre. Texto de 20 caracteres.
Nombre del plato.
Precio. Número decimal simple.
Precio del plato. no incluye I.V.A. ni descuentos, etc.
Menú. Sí/No.
Indica si ese plato puede ser consumido dentro del precio del menú del día.

La información anterior son los metadatos que definen la estructura de la tabla.

Algunos S.G.B.D. simplifican la tarea de indicar el dominio de un atributo, asignando un


dominio por defecto, o estableciendo una jerarquía de dominios. P.ej., Microsoft Access® toma como
dominio por defecto el Texto
Texto, y en concreto de 50 caracteres
caracteres. Se pueden cambiar los dominios a uno
cualquiera dentro de las siguientes posibilidades: Texto, Numérico, Fecha/Hora, Moneda, Sí/No,
Memo, Autonumérico, Objeto OLE, o Hipervínculo
Hipervínculo. A su vez, cada uno de estos tipos se puede
dividir en otras clases, una de las cuales es la que se toma por defecto; p.ej. el tipo Numérico tiene a
su vez los subtipos: Byte, Entero, Entero largo, Simple y Doble. Si sólo escogemos Numérico
Numérico, por
defecto se toma el subtipo Entero largo
largo, que permite guardar números enteros (sin parte decimal) desde
el -2.147.483.648 hasta el 2.147.483.647. Si el subtipo por defecto no es el que se quiere puede
especificarse otro.

Independientemente del dominio a que pertenezca un atributo, cualquier atributo puede tomar
un valor especial que designa la ausencia de dato; es el valor NULO (en inglés NULL o NIL). Cuando,

20
El modelo relacional.

por cualquier circunstancia, se desconoce el valor de un atributo, como p.ej. la dirección de un cliente,
o bien ese atributo carece de sentido (el atributo Teléfono de un empleado que no tiene teléfono en su
casa), podemos asociar a dicho atributo este valor especial, común a cualquier dominio. El equivalente
en nuestro símil de las fichas de cartón sería dejar ese hueco en blanco. Hay que hacer notar la
diferencia entre el valor NULO, y el valor «espacios en blanco»; el ordenador considera un espacio
en blanco como cualquier otro carácter, por lo que a efectos computacionales, la introducción de
caracteres «espacios en blanco» es distinta al concepto de «ausencia de información». Los espacios
en blanco sí son datos, y pertenecen al dominio Texto
Texto.

Restricciones.

En el apartado anterior observamos que cada atributo está obligado a tomar un valor
perteneciente a un dominio concreto, siendo imposible el que guarde otro distinto. Esto supone una
restricción sobre los atributos
Otras restricciones ya comentadas son:
• La imposibilidad de repetir tuplas en una misma tabla.
• La imposibilidad de establecer un orden en las tuplas, aunque algunos S.G.B.D. relajen un poco esta
restricción.

En este apartado vamos a introducir otras restricciones más importantes que posee el modelo
relacional, así como los conceptos implicados. Por último veremos las posibilidades que tiene el usuario
para definir restricciones en función de las características propias de su trabajo.

Reglas fundamentales. Claves.

El modelo relacional intenta representar con una tabla a un tipo de objetos de la vida real, como
puedan ser Empleados, Clientes, etc., e incluso considera las relaciones entre estos objetos como
objetos en sí mismos. Para ello, designa cada tipo de objetos por un conjunto de atributos que son los
que darán la «forma particular» a cada objeto. Volvamos al caso de nuestra tabla de Platos.
Para representar a un Plato, hemos escogido los atributos: Código, Nombre, Precio y Menú.
Un plato concreto puede ser p.ej., (17, «Migas con chocolate», 850, Sí). Este plato concreto, como
cualquier otro objeto distinguible del mundo real posee unas características que lo distinguen de los
demás de su mismo tipo, tal y como lo hace el ADN de una persona. El ADN conforma la esencia o
clave de toda persona. Es más, todo objeto posee algo concreto que lo hace diferente; incluso puede
poseer más de una cosa por la que se le puede diferenciar: una persona puede distinguirse también por
su nacionalidad y su D.N.I., lo que conforma otra clave de esa persona.
Como en una tabla, las tuplas pueden estar en cualquier orden, no podemos referenciar una
tupla concreta mediante su posición entre las demás, y necesitamos alguna forma de seleccionar una
tupla concreta. La forma de hacerlo es mediante una clave.
Una clave es un atributo o conjunto de atributos cuyo valor es único y diferente para cada
tupla.

21
El modelo relacional.

Cada tabla puede poseer más de una clave. P.ej., en nuestro caso de la tabla Platos, la clave
puede ser tanto el atributo Código, como el atributo Nombre. Tenemos dos claves potenciales,
también llamadas claves candidatas.
De entre todas las claves candidatas, el administrador, cuando define la tabla, debe decidir cuál
de ellas va a ser la clave principal o clave primaria, mientras que el resto de las claves pasan a
denominarse claves alternativas o claves alternas. La distinción entre clave principal y claves
alternativas, es sólo a efectos de acceso interno a los datos, y para que el S.G.B.D. adopte ciertas
decisiones sobre cómo almacenar esos datos en los sistemas de almacenamiento masivos.
Por otro lado, la clave de una tabla debe ser propia, o sea, ninguno de los atributos que la
forman debe ser superfluo. Siguiendo con la tabla de Platos, si tomamos el grupo de atributos
(Código, Precio), vemos que posee todas las características necesarias para considerarlo como una
clave candidata. sin embargo, el atributo Código por sí sólo ya es una clave candidata, con lo cual el
hecho de añadir el atributo Precio y crear una clave nueva, no aporta información de identificación,
ya que el resto de los atributos (el Código en este caso) identifica por sí sólo a una tupla de la tabla de
Platos. Así pues, el atributo Precio es superfluo en el grupo de atributos (Código, Precio), con lo que
dicho grupo no es una clave candidata. Para distinguir cuando un grupo de atributos es clave o no,
basta con probar con ir eliminando uno a uno cada uno de los atributos del grupo; si los atributos
restantes siguen poseyendo las propiedades de clave, el atributo eliminado es superfluo, por lo que el
grupo de atributos de partida no es clave propia.
Más adelante veremos como esta situación se deriva del hecho de que el valor del atributo que
sobra (el superfluo) viene determinado por los valores de los otros atributos (la clave propia), en lo que
se ha dado en llamar dependencia funcional.

El concepto de clave es tan importante, que da lugar a una serie de restricciones fundamentales
sobre la base de datos. Son la regla de identificación única y la regla de integridad referencial.

Regla de identificación única.

Esta restricción ya fue estudiada en el tema de los diagramas E-R. En esencia, los conceptos
de clave de una entidad en el diagrama E-R, y de clave de una tabla coinciden plenamente. Así pues,
al igual que en aquel momento, podemos enunciar esta regla de la misma forma:

«En ninguna tupla de una tabla, ninguno de los atributos que formen parte de la clave primaria de una
relación podrá tomar un valor nulo. El valor de la clave será único para cada tupla de la tabla».

Esta regla nos dice que una vez escogida la clave primaria de una tabla, y dado que ninguno
de los atributos que la componen es superfluo, no podemos dejar de lado el valor de ninguno de ellos
para identificar unívocamente a una tupla. O sea, el que todos los atributos de la tabla sean necesarios
está en contradicción con que alguno de ellos pueda carecer de valor. Ningún atributo de la clave
puede ser vacío porque en tal caso no sería una característica identificativa propia del objeto a que
pertenece.

22

También podría gustarte