Grado en

Ingeniería
Informática

BASES DE DATOS

TEMA 1
Introducción a las Bases de Datos

Docentes:

Jesús Maudes Raedo

Índice de contenidos
[Link]ÓN..................................................................... 3
[Link].......................................................................... 3
[Link] ESPECÍFICOS DEL TEMA...............................4
1.¿Qué es un Sistema Gestor de Bases de Datos?.................4
1.1.¿Qué es una Base de Datos?........................................... 6
[Link] de las Bases de Datos..................................... 6
[Link] de Datos y Niveles de Abstracción.......................6
[Link]ón del Modelo Relacional.....................................8
[Link]ón de Primera Forma Normal.............................13
[Link] Ajenas y Restricción de Integridad Referencial....14
[Link]........................................................................... 16
[Link]........................................................................... 17
[Link]ÍA..................................................................18
[Link] COMPLEMENTARIO.........................................19
Grado en Ingeniería Informática

I. Introducción

Las bases de datos y los sistemas informáticos que las sustentan cumplen un papel casi
imprescindible en nuestros días. Desde las transacciones bancarias, facturaciones y datos en
general de gestión, pasando por la gestión de datos de control de fabricación, de diseño o de uso
de los propios sistemas, casi toda la información que está disponible para ser consultada, está
registrada en una base de datos.
Existen distintas formas de especificar cómo se va a organizar la información en la base de
datos. Para ello, existen los llamados Modelos de Datos, cada uno de los cuales definen unas
reglas que hay que seguir para llevar a cabo esa especificación de cómo se va a organizar la base
de datos. Hay modelos de datos con mayor poder de abstracción y que son parcos en detalles,
pero permiten pensar y comunicar cómo queremos organizar la base de datos, y les hay también
menos abstractos, más ricos en detalles, orientados a que puedan ser comprendidos por una
máquina.
El modelo de datos relacional no es ni demasiado abstracto, ni demasiado concreto, y es el más
extendido en la industria. Veremos que es un modelo basado en fundamentos matemáticos
inspirados en la teoría de conjuntos, y esa base matemática le ha permitido no estar al arbitrio de
las decisiones de los fabricantes de bases de datos, por lo que es precisamente, la que le ha
dotado de una estabilidad en la que se basa gran parte de su éxito durante décadas.
En este capítulo conoceremos desde un punto de vista teórico los conceptos y restricciones
asociados al modelo relacional intentando no abusar demasiado de las matemáticas subyacentes.

II. Objetivos

OBJETIVO 1: Definir los conceptos básicos en bases de datos.

OBJETIVO 2: Presentar los conceptos de esquema, nivel de abstracción y modelo de
datos.
OBJETIVO 3: Conocer los conceptos y restricciones asociados al modelo relacional.
OBJETIVO 4: Entender la primera forma normal y las restricciones de integridad
referencial como elementos fundamentales del modelo.

Bases de Datos
3
Grado en Ingeniería Informática

III. Contenidos específicos del tema

1. ¿Qué es un Sistema Gestor de Bases de Datos?

Un Sistema Gestor de Base de Datos (SGBD1 en adelante) es un sistema para la gestión de
grandes volúmenes de datos persistentes. Se dice que los datos son persistentes cuando perviven
de una sesión a otra. Todos sabemos que los datos en memoria se pierden, por ejemplo, al
apagar el ordenador, porque la memoria es un dispositivo volátil, pero los datos que están en el
disco duro no, pues es un dispositivo persistente.
La gestión de grandes volúmenes de datos ofrece ciertos problemas que justifican la existencia
de un sistema tal. Algunos de estos problemas son:
• Un gran volumen de datos habitualmente no se puede almacenar por completo en
memoria, sino que debe de apoyarse en la utilización de un dispositivo de
almacenamiento externo (que además será persistente), típicamente un disco duro. El
flujo de información entre el disco duro y la memoria ha de ser fluido si se quiere unos
buenos tiempos de respuesta cuando se consulte o se actualice la información.
• Derivado del punto anterior, la implementación de algoritmos que provean de esa
eficiencia al sistema no es una tarea trivial, por tanto es interesante que existan sistemas
que ya los tengan implementados, y que hagan estas cuestiones transparentes a los
usuarios que consultan y actualizan los datos.
En concreto, la dificultad de estos algoritmos se complica muchísimo si al sistema se le
dota de la posibilidad de acceso y modificación concurrente de la información. La
concurrencia en base de datos, es la propiedad por la cual varios usuarios pueden
actualizar y consultar datos compartidos simultáneamente. Como hemos dicho, nos
interesa que todas estas cuestiones “complejas” sean tratadas de forma transparente al
usuario. Así, en un buen SGBD nunca notaremos que hay más usuarios utilizando la
base de datos, a lo sumo notaremos pequeñas esperas si estamos accediendo a datos
modificados por otro usuario, o modificando datos accedidos por otro usuario. El cómo
de pequeñas sean esas esperas, es en buena medida producto de lo eficiente que sea el
SGBD.
• Los datos no están normalmente aislados, sino que están relacionados entre ellos. Por

1 En textos en inglés veremos que se refieren a un SGBD como DBMS (Data Base Management System).

Bases de Datos
4
Grado en Ingeniería Informática

ejemplo, los datos de los alumnos están relacionados con las asignaturas de las que
están matriculados, e indirectamente con los profesores que las imparten. Por ello, es
interesante que un sistema como un SGBD provea de mecanismos para plasmar y
controlar este tipo de relaciones, impidiendo situaciones inconsistentes, como por
ejemplo que un alumno se matricule de (este relacionado con) una asignatura que no
existe en la base de datos.
• Los datos deben de poder ser sometidos a procedimientos de seguridad de manera
automatizada. Esta seguridad debe de ser a dos niveles: física y lógica.
La física trataría la no pérdida o corrupción de los datos, normalmente debida a un fallo
de funcionamiento hardware, y/o de sistema operativo, comunicaciones etc. Por
ejemplo, es típico el problema que surge cuando se va la corriente eléctrica a mitad de
un proceso de actualización de datos (i.e., una transacción). Un SGBD dejará
consistente la base de datos al re-arrancarse, y lo hará de forma transparente al usuario.
Esa consistencia consistirá en que la base de datos regrese al estado en el que estaba
antes de comenzar esa transacción.
La seguridad lógica trataría de controlar el acceso y manipulación de los datos por
usuarios no autorizados, estableciendo un sistema de usuarios, permisos y privilegios.
Por ejemplo, tal usuario puede consultar los datos de matrícula de las asignaturas, pero
no puede modificarlos.
Ejemplos de SGBDs hay muchos. Entre los más extendidos en la actualidad están Oracle,
Informix, IBM-DB2, Microsoft SQL-Server etc. Estos SGBDs son capaces de gestionar grandes
volúmenes de información, posiblemente distribuida entre varias máquinas, con cientos de
usuarios concurrentes. Otro SGBD conocido en la actualidad es Microsoft Access, el cual está
pensado para una utilización más doméstica/departamental. Pese a ser un sistema muy conocido
por multitud de usuarios, no es el ideal cuando se busca concurrencia, seguridad o gestión
eficiente de grandes volúmenes de datos. Sin embargo, es el mejor ejemplo de base de datos de
sobremesa, y de base de datos integrada en un entorno ofimático (i.e., Microsoft Office).
En la actualidad existen también otros SGBDs con capacidad de tratamiento concurrente de
grandes volúmenes de información, y que además son gratuitos, como mySQL o PostgreSQL.
De la misma manera [Link] Base, emula a Access, pero también es de uso gratuito.
Con frecuencia, a un SGBD la gente lo llama en un abuso del lenguaje “Base de Datos”.
Nosotros en este curso algunas veces también adoptaremos esta denominación, pues siempre se
puede deducir del contexto que realmente nos estamos refiriendo a un SGBD y no a una Base de
Datos. Pero entonces, ¿qué es propiamente una base de datos?.

Bases de Datos
5
Grado en Ingeniería Informática

1.1. ¿Qué es una Base de Datos?

Una Base de Datos (BD en adelante) es una colección de datos interrelacionados que están
gestionados por un SGBD. Por ejemplo, Access es un SGBD, pero en ese SGBD podemos tener
una base de datos de alumnos, con su nombre, DNI, fecha de nacimiento, teléfono etc...

1.2. Lenguajes de las Bases de Datos

Un SGBD, además de una serie de herramientas, suele presentar tres lenguajes:

1. DDL (Data Definition Language): El lenguaje de definición de datos permite definir las
estructuras lógicas de los datos: cómo se relacionan entre ellos, si son numéricos o
cadenas, qué valores no pueden tomar.
2. DML (Data Management Language): El lenguaje de manejo de datos permite consultar,
modificar, dar de alta y baja los datos.
3. DCL (Data Control Language): El lenguaje de control de datos permite asignar y
revocar permisos de lectura, modificación, borrado y creación de los datos o de las
estructuras que los contienen.

2. Modelos de Datos y Niveles de Abstracción

Un modelo de datos es un conjunto de conceptos y restricciones que permiten describir, a
distintos niveles de abstracción, la estructura de una base de datos, a la cual denominamos
esquema.
Por ejemplo, un esquema de una BD de alumnos definiría de alguna forma que la BD debería
contener información de los alumnos, las asignaturas y los profesores, que los alumnos tendrían
nombre, DNI, teléfono etc..., que todo alumno al menos debería de poder estar relacionado con
una asignatura, pero que puede quizás estar relacionado con varias, etc..
Eso es el esquema. La forma de expresar o representar ese esquema puede ser más abstracta o
más concreta (i.e., puede estar sujeta a distintos niveles de abstracción) dependiendo de los
conceptos que manejemos. Por ejemplo, a un nivel muy abstracto quizás obviaríamos decir que
el nombre del alumno es una cadena de caracteres de longitud máximo cuarenta, o que el
fichero que contiene la información de los alumnos reside en tal o cual posición del disco duro.
En un modelo de datos poco abstracto habría conceptos que permitirían concretar hasta el
último detalle del esquema.
Podríamos pensar equivocadamente que entonces, son mejores los modelos de datos más
concretos, pues realmente son los únicos que permiten especificar a la máquina cuál va ser la
representación física de un esquema. No obstante, esta impresión es equivocada por varias

Bases de Datos
6
Grado en Ingeniería Informática

razones:
1. El usuario que define un esquema normalmente partirá de un esquema con pocos
detalles, al que luego le irá proveyendo más y más matices hasta completarlo. Esto hace
conveniente tener modelos de datos que sirvan para expresar el esquema cuando se está
empezando a conocer o analizar, y modelos de datos más concretos donde ya
especificar toda suerte de detalles. Por ejemplo, no tiene sentido hablar de si el nombre
de los alumnos ocupará cuarenta caracteres como mucho, sin antes haber definido que
un alumno tiene nombre, y mucho menos aún tiene sentido hablar de en qué posiciones
de disco se almacenará la información del alumno.
2. Por otro lado, una especificación exhaustiva o muy concreta tiene el problema de que el
usuario que la utilice ha de tener profundos conocimientos del sistema a nivel físico. No
tiene sentido decir que la información de los alumnos va en este disco duro, y la de las
asignaturas en otro, sin saber cuáles van a ser las consecuencias que va a arrastrar esta
decisión en el rendimiento del sistema. Si cualquier usuario de base de datos tuviera que
conocer estas cuestiones (que además en general serán distintas para cada SGBD) el
número de usuarios potenciales de bases de datos se restringiría muchísimo (que era lo
que ocurría con los SGBDs de los años 70).
Por tanto, tiene sentido el que haya niveles de abstracción en los que:
1. Ya haya una especificación del esquema que pueda interpretar y seguir la máquina.
2. Pero que omita ciertos detalles complejos, a la espera de que la máquina tome por si
sola una decisión aceptable al respecto.
En bases de datos hablaremos de tres niveles de abstracción: Conceptual, Lógico y Físico.
1. En el nivel conceptual la abstracción es máxima, el modelo de datos que se utiliza es el
llamado Entidad/Relación. El esquema que se obtiene no es utilizable por la máquina,
pero sirve al usuario/diseñador, para comprender/modelar el problema en cuestión
centrándose en los conceptos y omitiendo los detalles de implementación.
2. En el nivel lógico la abstracción es intermedia. El modelo de datos lógico más habitual
es el modelo Relacional, que representa a través de tablas o relaciones la información.
Un esquema lógico ya contiene suficiente nivel de detalle para ser comprendido y usado
por la máquina, sin embargo omite ciertas cuestiones complejas de cómo se implementa
físicamente el sistema, lo que permite que usuarios no expertos definan en la máquina
bases de datos.
3. En el nivel físico ya no habría abstracción. Cada SGBD puede tener conceptos propios,
y por lo tanto modelos de datos propios, para especificar cómo se va a representar y
almacenar internamente la información. Por tanto, los usuarios capaces de utilizar este

Bases de Datos
7
Grado en Ingeniería Informática

tipo de modelos conocerán a fondo el SGBD en cuestión. A estos usuarios, es frecuente

que se los llame Administradores (administradores físicos o del esquema interno) de la
base de datos. En cualquier medio anunciante demandando profesionales informáticos,
nunca veremos que se quiere un Administrador de Base de Datos “en abstracto”, sino
un administrador Oracle, o un administrador DB2 etc... El papel de los administradores
en grandes BDs es fundamental, pues al conocer el SGBD a fondo, son capaces de
especificar un esquema físico de la base de datos que optimice su funcionamiento
teniendo en cuenta cuestiones como el tamaño de la BD, el hardware, el número de
usuarios, como evoluciona éste número a lo largo del día, qué tablas sólo se leen y no se
modifican, qué tablas son las más accedidas etc.
Durante este curso veremos dos modelos de datos: el Entidad/Relación y el Relacional, que
como ya se ha dicho, se corresponden con los dos primeros niveles de abstracción.
Recordemos que un modelo de datos, es un conjunto de conceptos y restricciones que permiten
describir a distintos niveles de abstracción el esquema. Pues bien:
• El modelo de datos Relacional representa la información mediante el concepto de tabla,
campo etc...
• El modelo Entidad/Relación representa la información mediante el concepto de entidad,
relación, cardinalidad etc...
¿Y las restricciones?: En todo modelo de datos existen dos tipos de restricciones: las inherentes
y las semánticas. Las inherentes siempre se cumplirán dentro de un modelo. Por ejemplo, toda
tabla del modelo relacional ha de tener un nombre, es una restricción inherente. Las
restricciones semánticas no siempre tendrán lugar, sino que su ocurrencia será voluntad del
diseñador cuando esté especificando el esquema en cuestión. Por ejemplo, en el modelo
relacional es posible decir que un campo no repite sus valores en una tabla. En el caso de los
alumnos, su DNI no debería de repetirse a lo largo de todos los alumnos. Observa que el
especificar que el DNI no puede repetirse, es una decisión que el diseñador toma para este
problema, pero que puede no tomar para otro: imagina que quieres definir una tabla de DNIs
falsos, por ejemplo.

3. Descripción del Modelo Relacional

El modelo relacional [Codd 1970] es el más utilizado actualmente en la industria. Es un modelo
de datos que podemos considerar que se corresponde con un nivel de abstracción lógico
(intermedio).
Comenzaremos por introducir algunos aspectos del modelo relacional. Empezaremos por
algunos de sus conceptos:

Bases de Datos
8
Grado en Ingeniería Informática

• Dominio: “Es un conjunto finito de valores homogéneos y atómicos caracterizados por

un nombre” [de Miguel y Piattini 1993]. Por ejemplo, el dominio de los números
enteros de 5 cifras o menos. El conjunto de los números enteros no es un dominio
propiamente, por no ser finito. Un conjunto que consista en la unión de los enteros de 5
cifras o menos con los booleanos, no es un dominio, porque no es homogéneo. Un
conjunto formado por tripletas en las que los 20 primeros caracteres son letras, los 5
siguientes son números y los 10 siguientes son letras, quizás sea muy útil para guardar
un nombre junto con un sueldo y la provincia de alguien, pero no es un dominio, porque
no es atómico. Atómico significa indivisible, y la tripleta como hemos visto, se puede
dividir en tres partes. Cabría la discusión, en ese sentido, de si las fechas son un
dominio, pues es argumentable que se componen de año, mes y día (otro caso similar es
el de las horas), pero a efectos prácticos asumiremos que las fechas en un determinado
rango son dominios.
• Atributo o Campo: Es un papel que desempeña un dominio en una BD. Por ejemplo, el
atributo edad, es un papel que desempeñan los enteros positivos menores que 150 en la
BD. En los textos técnicos se suele hablar de campo, mientras que en los teóricos y
científicos es más habitual hablar de atributo.
• Relación o Tabla: Es un subconjunto del producto cartesiano de n dominios (cada uno
correspondiente a un atributo) no necesariamente distintos.
Recuerda que un producto cartesiano de dos conjuntos es el conjunto de todos los
posibles pares que se forman al combinar un elemento del primer conjunto con un
elemento del segundo conjunto. Por ejemplo, el producto cartesiano del conjunto de
chicas con el de chicos daría lugar a todas las parejas heterosexuales posibles.
El producto cartesiano se puede extender a n conjuntos, de manera que se obtendrían
todas las posibles combinaciones formadas por un elemento del primer conjunto, otro
del segundo, ... , y otro del n-ésimo. Por ejemplo, el producto cartesiano del conjunto de
alumnos, por el conjunto de asignaturas, por el de profesores, daría lugar a todas las
tripletas ( alumno, asignatura, profesor) posibles.
Supongamos una tabla donde guardamos la información de los alumnos, que por
ejemplo permita registrar el DNI, el nombre, el primer apellido, el segundo apellido y la
fecha de nacimiento. Supongamos que el DNI es un atributo en el dominio de los
enteros positivos con menos de nueve cifras, que nombre, y los apellidos primero y
segundo pertenecen al dominio de las cadenas de caracteres de longitud máxima veinte,
y que la fecha de nacimiento se representa en el dominio de las fechas de los últimos
cien años. Observa que hay dominios que no son iguales, el dominio de los nombres y

Bases de Datos
9
Grado en Ingeniería Informática

los apellidos es el mismo. Si ahora hiciéramos el producto cartesiano de los dominios

correspondientes a los cinco atributos tendríamos un conjunto formado por todas las
combinaciones posibles de un DNI válido, con una cadena de veinte letras cualquiera
representando el nombre, otra cadena similar representando el apellido primero, otra el
segundo y una fecha cualquiera de los últimos cien años. No obstante, muchas de esas
combinaciones no se corresponderán con un alumno, por ejemplo (DNI=0,
Nombre=”XX”, Apellido1=”Lo que sea”, Apellido2=”hkjhkn”,
FechaNacimiento=1/1/2005). Lógicamente, nadie se llama así, incluso la fecha de
nacimiento es precoz para un alumno. Así pues, hay combinaciones que no se
corresponden con alumnos, pero es lógico pensar que otras combinaciones en el
producto cartesiano si se corresponden con algún alumno. Por ello, la definición
anterior dice que una relación es un “subconjunto” del producto cartesiano de los
dominios.
Quizás esta definición resulte enrevesada, pero es la que originalmente dio quien
“inventó” el modelo relacional (E. Codd), y por otro lado muchos coincidimos en alabar
su concisión y belleza.
• Grado de una Relación: Es el número de atributos de la misma (número de columnas
de la tabla).
• Tupla o Fila: Es un elemento de la relación.
• Cardinalidad de la Relación: Es el número de tuplas de la relación.
• Esquema de la Relación: Es una especificación formada por el nombre de una relación,
los nombres de su colección de atributos, y los dominios de cada uno.
Por ejemplo: Empleados ( DNI: Cadena[8], Nombre: Cadena[20], FechaAlta:Fecha de
los últimos 10 años).
Aunque para ser lo más correcto posible, en un esquema de relación habría que
especificar los dominios, nosotros para ganar algo de abstracción, normalmente no lo
haremos. Así, cuando nos pidan un esquema relacional en un ejercicio de este curso,
bastará con especificar Empleados ( DNI, Nombre, FechaAlta).
• Esquema relacional, es un compendio de varios esquemas de relación, aunque también
intervienen otras especificaciones que iremos viendo a lo largo del curso, y que son
fundamentalmente restricciones semánticas aplicadas a un determinado esquema.
Ya podemos enunciar algunas restricciones inherentes al modelo relacional:
• Toda relación tiene un nombre único en el esquema.
• Todo atributo tiene un nombre único en su relación.
• Toda relación tiene un grado mayor que cero.

Bases de Datos
10
Grado en Ingeniería Informática

• En una relación el orden de las tuplas es irrelevante (también se dice que no existe).
Sin embargo, el orden de los atributos por un lado sí que es irrelavante (también se dice que no
existe), pues podemos designarlos a través de su nombre, sin importarnos el orden en el que se
hayan declarado en el esquema; pero por otro lado si que existen operaciones en las que ese
orden es importante (por ejemplo, la operación de cociente que veremos más adelante en el
tema dedicado al álgebra relacional). En el el artículo de Codd [Codd 1970] también aparece
esta controversia.
Otros conceptos interesantes del modelo relacional son:
• Superclave: Es un conjunto de atributos de una relación cuyos valores no se repiten en
ninguna tupla de la misma.
En una tabla de personas. <DNI> es superclave pero según la definición de arriba,
también lo sería <DNI, color del pelo>, o <DNI, edad>, o <DNI, sexo, edad> etc... en
general DNI con cualquier cosa sería superclave.
• Clave Candidata: Es una superclave que en su interior no incluye otra superclave salvo
ella misma. Así <DNI, edad> es una superclave, pero no es clave candidata, porque en
su interior está <DNI>, que es superclave, y además clave candidata, pues en su interior
no hay otra superclave salvo ella misma.
Normalmente son simples, que significa que ese conjunto de atributos está formado por
un solo atributo. Por ejemplo, el DNI de la tabla de alumnos sería una clave candidata,
pues nunca habría de repetirse, y es simple , pues el DNI es un sólo atributo.
Las claves candidatas también pueden ser compuestas, si están constituidas por más de
un atributo. Por ejemplo, supón que en tu universidad las asignaturas se identifican con
un número llamado IdAsignatura, pero que dos asignaturas pueden tener el mismo
IdAsignatura si son de distinta titulación. Esto significa que en la misma carrera no
puede haber dos asignaturas con el mismo IdAsignatura. Si cada titulación se identifica
por otro número único, llamado IdTitulación, diremos que en la tabla de asignaturas lo
que no se puede repetir son “conjuntamente” los valores de IdAsignatura e IdTitulación,
lo que quiere decir que { IdAsignatura, IdTitulación } es una clave candidata compuesta
de la relación asignaturas.
Una restricción inherente del modelo relacional es que toda relación ha de tener -al
menos- una clave candidata (si bien veremos más adelante que en la práctica esta
restricción es posible saltársela en algunos lenguajes relacionales). La consecuencia
inmediata de esta restricción, es que en una relación no puede haber dos tuplas
repetidas, porque al menos se diferenciarían en el valor de sus claves candidatas.
Lo que si que puede ocurrir es que una relación tenga varias claves candidatas. Por

Bases de Datos
11
Grado en Ingeniería Informática

ejemplo, los alumnos de nuestra base de datos quizás pueden identificarse

indistintamente tanto por su DNI, como por un campo llamado IdAlumno, que son dos
claves candidatas simples, donde IdAlumno es un número único que la universidad
asigna a cada alumno.
En la representación que en este texto vamos a hacer de los esquemas relacionales
subrayaremos las claves candidatas. Por ejemplo:
Alumnos ( IdAlumno, DNI, Nombre, FechaNacimiento )
Asignaturas ( IdAsignatura, IdTitulación, Nombre, Curso, NumCréditos )

Observa que en alumnos hay dos subrayados (dos claves simples), y en asignaturas hay
otros dos subrayados que abarcan dos atributos (dos claves compuestas). En este
ejemplo las dos claves compuestas tienen el atributo IdTitulación en común.
La elección de claves candidatas es una restricción semántica del modelo, pues es el
diseñador quien dice que unas veces el DNI es clave candidata, y quizás otras veces no.
Date cuenta que es un restricción, porque al declararla esta restringiendo, o prohibiendo,
que -por ejemplo- haya DNIs repetidos en la tabla de alumnos.
• Clave Primaria: Es una clave candidata que el diseñador elige libremente para
representar las tuplas de una relación. He ahí, porqué a las claves candidatas, las
llamamos así: porque todas son “candidatas” a ser elegidas como primarias. Por
ejemplo, el diseñador del esquema relacional podría decidir que IdAlumno es la clave
primaria de alumnos y DNI no. Cuando la relación tiene una única clave candidata esta
será a su vez la primaria, pero cuando hay varias no hay un criterio objetivo que permita
elegir la idónea. Sin embargo, a efectos de mejora de rendimiento de la base de datos es
recomendable que la clave primaria sea lo más corta posible, lo que significa:
1. Intenta evitar las claves compuestas como clave primarias.
2. Si todas tus claves candidatas son muy largas, o son compuestas quizás debas
de añadir una clave artificial. Por ejemplo, si voy a tener 3.000 alumnos, elegir
el DNI como clave es excesivo, porque cada uno va a ocupar como poco 8
bytes, y no necesito 8 cifras para identificar a 3.000 personas. Por ello, podría
ser recomendable añadir una clave artificial, como IdAlumno, y que por ejemplo
sea un entero positivo de 4 o 5 cifras.
Claramente, la clave primaria es una restricción semántica, pues la elige el diseñador, y
restringe que haya elementos repetidos. La clave primaria tiene también un papel
importante a la hora de combinar información de varias tablas, pero eso se verá más
adelante.
Lo que es una restricción inherente, es que toda relación ha de tener clave primaria,
pues como hemos visto, ha de tener al menos una clave candidata. Otra restricción

Bases de Datos
12
Grado en Ingeniería Informática

inherente es que una relación no puede tener más de una clave primaria.
En este texto representaremos las claves primarias en los esquemas relacionales con las
siglas PK (Primary Key) debajo del subrayado, y las claves candidatas no primarias con
UNQ (Unique) debajo del subrayado. Por ejemplo:
Alumnos ( IdAlumno, DNI, Nombre, FechaNacimiento )
PK UNQ

Asignaturas ( IdAsignatura, IdTitulación, Nombre, Curso, NumCréditos )

PK UNQ

Observa que en alumnos hay dos subrayados (una claves primaria, y otra candidata no
primaria), pero que en asignaturas hay dos subrayados que abarcan dos atributos (una
clave primaria compuesta y otra no candidata compuesta).

4. Restricción de Primera Forma Normal

Una restricción inherente del modelo relacional dice que toda relación ha de estar en primera
forma normal (también se dice que toda relación ha de estar normalizada). Esto significa que
cada atributo sólo puede tomar un valor en cada fila.
En otras palabras esta restricción significa que:
1. No podemos tener un campo que represente una colección de valores (e.g., no podemos
tener un campo que sea un array de teléfonos).
Por tanto, no es relacionalmente correcto:
Alumnos ( IdAlumno, DNI, Nombre, FechaNacimiento, teléfonos )
PK UNQ
Si lo sería:
Alumnos ( IdAlumno, DNI, Nombre, FechaNacimiento)
PK UNQ
TeléfonosAlumnos ( IdAlumno, teléfono )
PK

Donde vemos que tenemos una segunda tabla con una fila por cada teléfono de un
alumno. Esa tabla curiosamente tiene una clave primaria compuesta que significa que el
mismo alumno no puede tener dos veces el mismo teléfono.
2. No podemos tener un campo que en su interior tenga otros (como ocurre en un struct de
C, por ejemplo)2.

2 Una excepción a esta restricción son los dominios compuestos, como son las fechas (compuestas por día, mes y año), las horas
(compuestas por horas, minutos, segundos, etc … ), y los números en coma flotante (compuestos por mantisa y exponente).
Haremos estas excepciones por consideraciones meramente prácticas, y porque en el fondo todos estos casos representan, de
otra forma, un número. Por ejemplo, la fecha en el fondo es el número de días transcurrido desde el 1-1-1, o la hora es el
número de segundos transcurridos desde las 0:00.

Bases de Datos
13
Grado en Ingeniería Informática

5. Claves Ajenas y Restricción de Integridad Referencial

En el ejemplo anterior:
1. Sabemos de qué alumno es un teléfono, porque en la tabla donde aparece el teléfono, en
la misma fila hay un valor de IdAlumno, que es clave primaria de la tabla de alumnos y
que por tanto identifica al alumno propietario del teléfono unívocamente.
2. Sabemos qué teléfonos tiene un alumno porque dado su IdAlumno, basta buscar en la
tabla de telefonosAlumnos las filas con ese IdAlumno.
Por tanto, no sufrimos ninguna pérdida de información, y todo gracias a traernos la clave
primaria de la tabla de alumnos a la tabla que contiene los teléfonos. Por ello, esta clave que nos
traemos de otra tabla se llama clave ajena o externa.
Las claves ajenas a diferencia de las vistas anteriormente no implican unicidad, es decir sus
valores se pueden repetir en la tabla en la que aparecen. Por ejemplo, no hay problema en que
en la tabla teléfonosAlumnos haya varias filas con el mismo idAlumno, pues eso significa que
ese alumno tiene varios teléfonos.
Nosotros representaremos las claves ajenas con una raya superior o inferior y las letras FK
(Foreign Key). Esta notación es propia, no la encontraréis en otros textos, pero es muy útil. Por
ejemplo:
Alumnos ( IdAlumno, DNI, Nombre, FechaNacimiento, dirección)
PK UNQ

FK
TeléfonosAlumnos ( IdAlumno, teléfono )
PK
Las claves ajenas también pueden ser compuestas. Supongamos que cada profesor sólo puede
impartir una asignatura (ojalá) y que cada asignatura puede tener varios profesores. Entonces,
ampliando el ejemplo de la clave primaria visto anteriormente podríamos representarlo así
Asignaturas ( IdAsignatura, IdTitulación, Nombre, Curso, NumCréditos )
PK
Profesores ( IdProfe, Nombre, Despacho, Tfno, IdAsignatura, IdTitulación)
PK FK
En este caso, no basta con llevar a profesores el IdAsignatura pues la asignatura 5 puede existir
en varias titulaciones, hay que llevarse los dos campos para poder expresar que el profesor
Pepito imparte la asignatura 5 de la titulación no-se-cuantos.
Por tanto, una clave ajena es un conjunto de atributos que conforman una clave primaria en otra
relación R1, y que los importamos a otra relación R2, para que así R2 pueda relacionarse con
R1.
Podemos pensar que los ejemplos anteriores se hubiesen simplificado notablemente si
juntásemos todos los atributos en una única tabla, es decir:
Alumnos ( IdAlumno, DNI, Nombre, FechaNacimiento, dirección, Telefono)
Esto supone que:

Bases de Datos
14
Grado en Ingeniería Informática

1. Ahora tenemos una fila por cada teléfono del alumno. Lo que implica repetir todos los
datos del alumno por cada teléfono, con lo que
2. Si el alumno cambiase de dirección habría que cambiarlo en todas sus filas sin olvidar
ninguna, mientras que cuando teníamos el mismo problema representado en dos tablas
sólo había que cambiar la dirección en una fila.
3. Borrar/añadir un teléfono sería borrar/añadir una fila. Habría que dar un tratamiento
especial al caso añadir el alumno, para poder dar de alta un alumno sin teléfono y al
caso borrar el único teléfono de un alumno, para no perder los datos del alumno. En la
representación con dos tablas las altas y bajas de teléfonos son siempre altas y bajas de
una fila en la tabla de TeléfonosAlumnos.
4. No podemos restringir que dos alumnos no tengan el mismo DNI o idAlumno, porque si
lo restringimos con una clave candidata o primaria, obligamos a que el número de
teléfonos máximo por alumno sea uno.
Por tanto, hacerlo con una sola tabla no es una alternativa 3.
Una relación puede tener cero o n claves ajenas. Un ejemplo con varias claves ajenas:
Profesores ( IdProfe, Nombre, Despacho, Tfno, IdAsignatura, IdTitulación, Departamento)
PK FK FK
Un profesor además de impartir una asignatura, pertenece a un departamento, cuyos datos (tfno,
fax, director... ) no queremos repetir por cada fila de profesor, y por eso relacionamos la tabla de
profesores con la de departamentos a través de una clave ajena.
Siguiendo con el ejemplo de los teléfonos, podemos tener filas de la tabla teléfonosAlumnos en
el que el campo IdAlumno no se correspondiese con ningún alumno de la tabla de alumnos, o
que en la tabla de profesores hubiese algunos cuya combinación titulación-asignatura no
existiese en la tabla de asignaturas. En estos casos la base de datos es inconsistente, porque hay
un teléfono que no se corresponde con ningún alumno, o un profesor cuya asignatura no existe.
Por ello, las bases de datos relacionales permiten definir las restricciones semánticas llamadas
de Integridad Referencial. Según esta restricción, cuando declaremos una clave ajena, sus
valores han de existir en la clave primaria correspondiente.
Esto lo representaremos mediante una flecha que conecte la FK con la PK asociada. Por
ejemplo:
Alumnos ( IdAlumno, DNI, Nombre, FechaNacimiento, dirección)
PK UNQ

FK
TeléfonosAlumnos ( IdAlumno, teléfono )
PK

3 A veces en la práctica este caso se trata como Alumno (Id, dni, nombre, fechnac, dirección, tfno1, tfno2). Esa solución es
correcta siempre que no haya problema en guardar sólo 2 teléfonos por alumno como máximo.

Bases de Datos
15
Grado en Ingeniería Informática

O bien:

Asignaturas ( IdAsignatura, IdTitulación, Nombre, Curso, NumCréditos )

PK

Profesores ( IdProfe, Nombre, Despacho, Tfno, IdAsignatura, IdTitulación)

PK FK

Nota que aunque exista la titulación T1 y la asignatura A5, ambos por separado, es posible que
la restricción de integridad referencial en profesores no admita que un profesor imparta la
asignatura (A5, T1) pues puede que la titulación T1 no tenga esa asignatura (la tienen quizás
otras titulaciones). Por tanto, en el caso de la clave compuesta la restricción exige que esa
combinación de valores se dé en la clave primaria y no se conforma con que los valores se den
por separado.

IV. Resumen

1. Los SGBDs son los sistemas que albergan lo datos de una BD. Esos datos pueden
definirse mediante el DDL y tanto consultarse como manipularse mediante el DML.
2. Se ha introducido el concepto de modelo de datos a partir del concepto de nivel de
abstracción; y hemos señalado el nivel de máxima abstracción, o nivel conceptual,
como el nivel en el que pensaremos y diseñaremos la base de datos antes de
implementarla, mientras que el nivel lógico será el que usaremos para especificar el
esquema de la BD al SGBD. El nivel físico es propio de cada SGBD y queda fuera del
alcance del curso.
3. El modelo relacional representa la información de la base de datos a través de
relaciones o tablas, lo que constituye una estructura clara y fácil de formalizar
matemáticamente. En una tabla siempre ha de existir al menos una clave candidata, de
entre las cuales elegiremos una como más representativa, a la cual llamaremos clave
primaria. En una misma tabla no puede haber más de una clave primaria.
4. Todas los campos, o atributos, de una tabla no pueden tomar más de un valor en cada
fila o tupla; es lo que se conoce como restricción de primera forma normal. Debido a
esta cuestión, la única forma de representar que un atributo de una tabla T puede tomar
varios valores, es crear otra tabla T' aparte a la que llevaremos como atributos
adicionales, los que constituyen la clave primaria de T. Estos atributos adicionales se
conocen como clave ajena, y no implican ninguna restricción de unicidad (i.e., sus

Bases de Datos
16
Grado en Ingeniería Informática

valores pueden repetirse), pero si implican una restricción llamada “de integridad
referencial”, por la cual los valores de a clave ajena en T' deben de existir previamente
en la clave primaria de T.

V. Glosario

En este tema no incluimos glosario de las secciones de la III.3. a la [Link] no ser

redundantes, ya que son secciones que en si mismas conforman un denso glosario de términos
que iremos usando en temas posteriores.
Base de Datos (BD). Es una colección de datos interrelacionados que están gestionados por un
SGBD
Concurrencia. En base de datos, es la propiedad por la cual varios usuarios pueden actualizar y
consultar datos compartidos simultáneamente.
CSV (Comma Separated Values). Formato de intercambio de información que utiliza ficheros
de texto plano. En estos ficheros cada línea representa un registro o ítem, y en cada línea cada
campo está separado del siguiente por una coma.
Datos persistentes. Se dice que los datos son persistentes cuando perviven de una sesión a otra.
DBMS (DataBase Management System). Sistema Gestor de Bases de Datos en inglés.
DCL (Data Control Language). El lenguaje de control de datos permite asignar y revocar
permisos de lectura, modificación, borrado y creación de los datos o de las estructuras que los
contienen.
DDL (Data Definition Language). El lenguaje de definición de datos permite definir las
estructuras lógicas de los datos: cómo se relacionan entre ellos, si son numéricos o cadenas, qué
valores no pueden tomar.
DML (Data Management Language). El lenguaje de manejo de datos permite consultar,
modificar, dar de alta y baja los datos.
Índice. Es una estructura de datos auxiliar que sirve para que – en este caso – los SGBDs hagan
búsquedas más rápidas. Un índice en base de datos sirve en principio para lo mismo que los
índices inversos que hay al final de muchos libros técnicos, en los que podemos buscar una
palabra y encontrar todas las páginas en las que se encuentra esa palabra sin tener que leernos el
libro de principio a fin. En el caso de las bases de datos los índices no indican páginas de un
libro, sino la dirección física (ver puntero en este mismo glosario) donde se encuentra un dato al
que se pretende acceder. Los índices se estudian en la asignatura de Estructuras de Datos y
presentan forma de árbol para acelerar las búsquedas.

Bases de Datos
17
Grado en Ingeniería Informática

Puntero. Un puntero es una dirección física. En programación los punteros representan una
dirección de memoria donde se localiza un dato (por ejemplo, en el lenguaje C el paso por
referencia internamente es un puntero). Sin embargo, en bases de datos los punteros suelen
representar direcciones de disco (i.e., en qué pista, y qué sector dentro de esa pista está el bloque
de disco con la información deseada; y cuántos bytes hay entre el comienzo de ese bloque y el
lugar exacto donde comienza esa información).
QBE (Query By Example). Técnica de programación visual de consultas sobre bases de datos
relacionales. Una consulta QBE se especifica en una rejilla o tabla. Hay una columna por cada
dato que se quiere mostrar o filtrar. En cada celda de la rejilla se especifica una condición de
filtrado sobre su columna. Dos condiciones en la misma fila de la rejilla hacen Y lógico. Dos
condiciones en filas distintas de la rejilla hacen O lógico.
Sistema Gestor de Base de Datos (SGBD). es un sistema para la gestión de grandes volúmenes
de datos persistentes.

VI. Bibliografía

Referencias:
[Codd 1970] Codd, Edgar F. A Relational Model of Data for Large Shared Data Banks.
Communications of the ACM Vol. 13(6), 1970. pp 377-387.
(Disponible en acceso abierto en [Link]

[Connolly y Begg 2005]. Connolly, Thomas M. y Begg, Carolyn E. Sistemas de Bases de Datos
4ª ed. Pearson, 2005.
(Disponible en UBUvirtual: [Link]
cod_primaria=1000187&codigo_libro=2155)

[de Miguel y Piattini 1993] de Miguel, Adoración y Piattini, Mario. Concepción y Diseño de
Bases de Datos. Del Modelo E/R al Modelo Relacional. RA-MA, 1993.
[Elmasri y Navathe 2007] Elmasri Ramez y Navathe Shamkant B. Fundamentos de Sistemas
de Bases de Datos 5ª ed. Pearson, 2007
(Disponible en UBUvirtual: [Link]
cod_primaria=1000187&codigo_libro=2886)

[Silberschatz et. al 2006] Silberschatz, Abraham, Korth, Henry F. y Sudarshan, S.

Fundamentos de Bases de Datos 5ªEd. McGraw-Hill, 2006.
(Disponible en UBUvirtual: [Link]
cod_primaria=1000187&codigo_libro=4356 ).

Bases de Datos
18
Grado en Ingeniería Informática

[Tsichritzis y Klug 1978] Tsichritzis, Dennis y Klug, Anthony The ANSI/X3/SPARC DBMS
framework report of the study group on database management systems. Information
Systems, Vol. 3(3), 1978, pp 173-191.
Bibliografía comentada:
La sección III.2. está tomada fundamentalmente de [de Miguel y Piattini 1993] (introducción
del capítulo 7). La fuente original donde se explica por primera vez el modelo relacional es
[Codd 1970]. La sección III.3. está inspirada en el capítulo 15 de [de Miguel y Piattini 1993],
pero casi todos los libros de introducción a las bases de datos dedican también un buen número
de páginas a la revisión de estos conceptos (e.g.; la sección 2.1 en [Silberschatz et. al 2006], las
secciones 3.2 y 3.3 en [Connolly y Begg 2005] y las secciones 5.1 y 5.2 en [Elmasri y Navathe
2007], si bien en estas dos últimas referencias se amplia el repertorio inicial de restricciones
semánticas influenciado por las restricciones en SQL que veremos en posteriores temas).

VII. Material complementario

DB1 Introduction and Relational Databases. Video 1: Introduccion to Databases.

Prof. Jennifer Widom, Standford University
[Link]
vid-introduction/ (tiene subtítulos en español).

Bases de Datos
19
Grado en Ingeniería Informática

Licencia
Autor: Jesús Maudes Raedo
Área de Lenguajes y Sistemas Informáticos
Departamento de Ingeniería Civil
Escuela Politécnica Superior
UNIVERSIDAD DE BURGOS
2017

Este obra está bajo una licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 3.0 Unported. No se
permite un uso comercial de esta obra ni de las posibles obras derivadas, la distribución de las cuales se debe hacer
con una licencia igual a la que regula esta obra original
Licencia disponible en [Link]

Bases de Datos
20