Bases de datos 1
TEMA 1 LOS DATOS: CONCEPTOS INTRODUCTORIOS
Tema 1
Los datos: conceptos
introductorios
1. Los tres mundos: el real, el
conceptual y el de las
representaciones
2. El mundo conceptual:
entidades y atributos
3. El mundo de las
representacionesl
4. La memoria externa
Los tres mundos
1. LOS 3 MUNDOS: EL REAL, EL CONCEPTUAL Y EL DE LAS REPRESENTACIONES
Los términos que manejaremos en la asignatura, se distinguen en 3
ámbitos diferentes:
 El mundo real: con los objetos cotidianos que nos rodean. Es la realidad que
nos interesa y la que percibimos con nuestros sentidos, compuesta por objetos
concretos, ya sean físicos o no.
 El mundo de las conceptualizaciones lógicas: estos conceptos se obtienen
tras observar y abstraer determinados conocimientos de la realidad que nos
interesan en un momento dado. La información es un conocimiento
transmisible y es en esta asignatura el único conocimiento que nos interesa.
Eso sí, en el paso del mundo real a las conceptualizaciones encontramos
pluralismo; así un profesor le interesará del alumno su calificación en la
asignatura; mientras que en secretaría estarán más interesados en datos del
tipo si el alumno tiene beca o no, el importe de su matrícula, etc.
 El mundo de las representaciones informáticas o datos: aquí
toman forma las abstracciones del mundo anterior; es decir para
transmitir esos conocimientos y poder comunicarlos es necesario
representarlos físicamente de alguna manera: los datos. Los datos
son, por tanto, las representaciones físicas de los conocimientos que
tenemos de los objetos del mundo real. El paso de los conocimientos a
los datos no es automático, sino que es un proceso humano: un
proceso de diseño.
Sin duda, las tareas más importantes del analista/diseñador de
aplicaciones informáticas son: analizar los objetos del mundo real para
hacer abstracciones y obtener una concepción lógica de ellos; y
posteriormente diseñar una representación informática concreta que se
pueda tratar eficientemente. Hoy día, gracias a la evolución tecnológica
se ha simplificado el proceso de diseño con lo cual la principal tarea
suele ser la observación/abstracción.
2. EL MUNDO CONCEPTUAL: ENTIDADES Y ATRIBUTOS
Para nuestro mundo conceptual, será imprescindible conocer una serie de
términos:
 Entidad: es el objeto que conceptualizamos como distinguible y viene a ser el
término “sujeto” que utilizamos en lingüística; así por ejemplo en la frase “El
alumno Pedro nació en el año 1979”; tenemos como entidad al alumno Pedro.
 Atributo: Es la propiedad que describimos de la entidad y que en la lingüística
forma parte del predicado; así el atributo de la frase anterior sería “nació en el
año”.
 Valor: Es la magnitud a la que hace referencia el atributo; en este caso
“1979”. Lógicamente para conocer una información debemos conocer a quién
hace referencia (entidad), sobre qué versa (atributo) y cual es la magnitud de
ese atributo (valor).
 El tiempo: La información no es independiente del tiempo y este detalle habría
que saber reflejarlo en nuestro sistema de bases de datos. Quizá nos parezca
que la fecha de nacimiento de alguien no va a cambiar, o el DNI; quizá nos
equivoquemos, pues el DNI puede tener un error policial y tener que cambiarse
2 · Bases de datos 1

por otro, o incluso la fecha de nacimiento que nosotros hemos introducido en la

base de datos esté erróneo y haya que cambiarlo. Tanto el cambio posterior
como todo el tiempo en que ese error se ha mantenido y se ha estado
difundiendo esa información errónea convendría tenerlo registrado. Así, para
tener bien caracterizada una información, necesitaremos la entidad, el atributo,
el valor y el tiempo.
 Dominios y valores nulos: El conjunto de valores válidos o legales que
puede tener un atributo recibe el nombre de dominio. Así, en fecha de
nacimiento de un alumno, podemos llegar a tomas desde 1900 hasta al
actualidad. Ojo, no confundamos el dominio con el tipo; es cierto que el valor
fecha debe ser de tipo numérico, y esto limita en parte los valores aceptables,
pero no todos, dado que 23456 sería un valor aceptable, pero irreal en nuestro
caso. El valor nulo puede definirse como el valor vacío, y debemos hacer saber
a nuestro sistema si para un determinado atributo se admite ese valor vacío
(por ejemplo un alumno de menos de 18 años, no tiene porqué tener DNI).
 Identificadores y claves: Los atributos que conforman aplicaciones
inyectivas se denominan identificadores. Es decir, si hablamos de personas
adultas, el DNI es un identificador único; pero si hablamos de accidentes de
tráfico, el DNI de la persona involucrada no es un identificador, pues puede
haberse encontrado envuelto en más de un accidente. Una clave es un
atributo o conjunto de ellos que permite identificar las entidades individuales.
En el ejemplo anterior, el conjunto de atributos DNI, fecha y hora, sí que puede
considerarse una clave, aunque cada uno de sus componentes no sean un
identificador en sí mismos.

3. EL MUNDO DE LAS REPRESENTACIONES

Ya dijimos anteriormente que para transmitir y procesar la Representación tabular

información, requerimos representarla mediante datos. Una
representación formal muy utilizada es la representación tabular
como la que vemos al margen, en ellas se utiliza una entidad por fula
y un atributo de cada una de esas entidades por columna. Al
productor cartesiano entidades x atributos es a lo que se denomina
representación tabular. Ahora bien, se denomina registro a la
representación de una entidad (es decir, una fila cualquiera de la
tabla) y campo a la representación del valor de un atributo de una
entidad (es decir los campos son columnas).

Una base de datos es un conjunto de ficheros de datos interrelacionados.

Por ejemplo en secretaria de una universidad, tenemos 3 ficheros de base de
datos: alumnos (con sus atributos DNI, nombre, fecha nacimiento…), asignaturas
(código, nombre y créditos) y profesores (DNI, nombre y despacho). Para obtener
por ejemplo la nota de un alumno en una asignatura, no podemos asignar el campo
nota a la asignatura, pues al ser de valor único todos los alumnos obtendrían la
misma nota, ni al alumno, pues obtendría la misma nota en todas las asignaturas
en las que estuviera matriculado. El campo nota, es el resultante de la interrelación
alumno/asignatura; interrelación que puede ser múltiple para cada alumno, pues
hay muchas asignaturas en las que puede estar matriculado. Así nacieron los
sistemas de gestión de bases de datos, para poder manipular y tratar esta
información que quedaba fuera del concepto de base de datos.

Para poder almacenar esta información existen diversas fórmulas; cintas,

DAT, CDs, el propio disco duro; cada una de ellas con sus particularidades; pero
casi lo que más nos interesa es el acceso a la información: tenemos según
diferentes criterios el acceso secuencial y el directo; y por otro lado el acceso por
valor o por posición; implementando ambos obtenemos:
 Acceso secuencial por posición: Tras haber accedido a un dato, accedemos al
siguiente de la lista por posición.
 Bases de datos 1 · 3

 Acceso directo por posición: Queremos acceder al registro que ocupa la

posición x (por ejemplo, el alumno que es la mediana de todas las notas de una
asignatura).
 Acceso secuencial por valor: Queremos obtener el siguiente alumno por orden
alfabético a partir del alumno x; realmente nuestra lista está ordenada por
código de alumno, así que este sería un acceso secuencial por valor (apellido) y
no por posición.
 Acceso directo por valor: El alumno que ha obtenido un 5,6 por ejemplo.

4. LA MEMORIA EXTERNA

La necesidad de almacenar datos nos obliga a utilizar memorias externas

con soportes permanentes. La no-volatilidad de esta información (las memorias
internas pierden su contenido en cuanto se apaga el PC), la gran capacidad que
tienen y su bajo precio los hacen ideales para ello; solo tienen un pequeño
inconveniente, el tiempo de acceso.

El tiempo de acceso a un disco duro es igual al tiempo de búsqueda (el

brazo portador de los cabezales se coloca en el cilindro seleccionado), más el
tiempo de espera (hay que esperar a que en su giro constante el cabezal pase por
la zona de datos a transferir), más el tiempo de transferencia.

Los soportes que más se suelen utilizar son:

 Disco duro: no es transportable, es rápido, fiable, barato y de gran capacidad.
 CD-ROM: si es solo grabable se utiliza para ficheros históricos o definitivos, y
solo para realizar consultas.
 Cintas: solo tienen acceso secuencial por lo que se suelen utilizar únicamente
como copia de seguridad (backup).
4 · Bases de datos 1

TEMA 2 INTRODUCCIÓN A LAS BASES DE DATOS

1. CONCEPTO Y ORIGEN DE LAS BD Y DE LOS SGBD Tema 2

Introducción a las bases de
datos
Las aplicaciones informáticas de los años 60 acostumbraban a darse 1. Concepto y origen de las BD y
totalmente por lotes (batch). Cada BD solía trabajar con un único fichero maestro de los SGBD
2. Evolución de los SGBD
que se encontraba sobre una cinta magnética, y con su acceso secuencial. Cuando 3. Objetivos y servicios de los
se quería añadir una aplicación que requería alguno de los datos de dicha cinta y SGBD
4. Arquitectura de los SGBD
otros nuevos, se diseñaba un fichero nuevo copiando todos los datos repetidos 5. Modelos de BD
(redundancia) y añadiendo los nuevos, para evitar que un mismo programa tuviera 6. Lenguajes y usuarios
que leer varios ficheros distintos. 7. Administración de BD

Cuando aparecieron líneas de comunicación y se podía acceder de forma

on-line y a medida que se integraban las diferentes aplicaciones, fue necesario
eliminar toda la redundancia y diseñar un conjunto de ficheros interrelacionados
entre sí. A este conjunto de ficheros, con estructuras complejas y compartidos por
varias procesos de forma simultánea se le conoce como bases de datos. A partir
de los 80 fue saliendo al mercado software que permitía gestionar e interrelacionar
todos estos ficheros, y es lo que se denominó sistemas de gestión de bases de
datos. Una base de datos, en otras palabras, es un conjunto estructurado de datos
que representa entidades y sus interrelaciones; representación única e integrada
que a su vez permite utilizaciones varias y simultáneas.

2. EVOLUCIÓN DE LOS SGBD

 Años 60 y 70: Se pueden definir estos años con dos palabras sistemas
centralizados; es decir, un gran ordenador para toda la empresa y una red de
terminales sin inteligencia ni memoria conectados a él; era la visión hardware
de la época que además, se apoyaba en el software de sistema operativo
existente en aquel momento. Los programas de aplicación para acceso,
consulta y escritura en la base de datos estaban escritos en alto nivel y eran
gran cantidad de órdenes y subrutinas que requerían que el programador
conociera todos los detalles de diseño físico y lógico; todo hacía que la
programación fuese muy costosa. Lo que interesaba en esta época era
maximizar el rendimiento: disminuir el tiempo de respuesta y aumentar las
transacciones por segundo.
 Años 80: Sistemas de gestión de base de datos relacionales. La aparición de
ordenadores micro extendieron la informática a todas las empresas e
instituciones. Aparecen los primeros SGBD relacionales que facilitan la
programación de aplicaciones y consiguen que los programas sean
independientes de los aspectos físicos de la base de datos. La estandarización
en el año 1986 del lenguaje SQL produce una auténtica explosión de este tipo
de programas.
 Años 90: Caracterizados por la distribución, el modelo cliente/servidor y 4GL.
A pesar de que las SGBD ya aparecen en la década anterior, no es hasta este
momento en el que las empresas se dan cuenta de que han comprado
ordenadores departamentales y existen multitud de bases de datos diferentes
pululando por la empresa. La necesidad de tener una visión global de la
empresa y de interrelacionar las diferentes aplicaciones llevan a buscar un
programa que tratase todas las BD como una sola: base de datos
distribuida; esta distribución es mejor cuando hay homogeneidad (misma
marca de SGBD), lo cual es difícil que ocurra en toda la empresa; no obstante
aunque existe heterogeneidad, gracias al lenguaje SQL se pueden tratar todas
las bases de datos, aunque no se da la apariencia de que se trata de una sola.
En otras ocasiones también se da una distribución deseada, dado que pueden
existir varias copias de BD iguales en distintos puntos (por cercanía, por
acceso, por utilización, etc) o solo con aquellos datos que se vayan a utilizar
frecuentemente. Así si una BD queda fuera de servicio, el resto puede seguir
 Bases de datos 1 · 5

funcionando, además el coste se reduce así también sensiblemente. La

tecnología que se suele utilizar para esta distribución es la cliente/servidor.
Cualquier PC puede ser servidor (acepta una consulta de BD y la sirve) o ser
cliente (pide una consulta o un dato) o ambas a la vez. Además el éxito de las
BD hasta en los ordenadores personales, ha llevado a la aparición de los
lenguajes de cuarta generación 4GL, fáciles, potentes, y muy visuales a la hora
de realizar consultas o cambios en la BD.
 Tendencias actuales: Actualmente las bases de datos están en plena
transformación (¿no lo están siempre?) para adaptarse a la multimedia, a la
orientación de objetos y a internet. Se pueden establecer consultas desde la
web, se pueden reconocer gran cantidad de objetos multimedia como tipos de
bases de datos, etc. También recalcar que actualmente existe lo que se da en
llamar almacén de datos, es decir, en las grandes empresas y sobre todo
fruto de las fusiones, se quiere tener un almacén en el que se reflejen todos los
datos (por pequeños que sean) para poder ser analizados desde distintos
prismas y poder hacer consultas con información valiosa para la empresa.

3. OBJETOS Y SERVICIOS DE LOS SGBD

 Consultas no predefinidas y complejas: Se debe pedir a un sistema de

base de datos que permita a los usuarios hacer consultas de cualquier tipo y
complejidad, sin que estén preestablecidas, sin que se tenga que compilar un
programa exclusivamente para ello y que sea sencillo y cómodo para el usuario.
Consultas del tipo; “Quiero un listado ordenado por apellidos de los alumnos
nacidos entre 1965 y 1971, que estén matriculados de 3 o menos asignaturas y
que vivan en Barcelona capital”.
 Flexibilidad e independencia: Interesa obtener la máxima independencia
posible entre los datos y los procesos usuarios, para que cuando existan
cambios tecnológicos se puedan implementar con facilidad. En ese sentido nos
tiene que dar igual el Sistema operativo o el tipo de fichero en el que los datos
estén escritos (independencia física de los datos); pero es que además
queremos que diferentes usuarios tengan unas visiones distintas e
independientes de la base de datos (como hablábamos en el tema anterior de
la visión de una base de alumnos desde el punto de vista del profesor o de la
secretaría); a esto se le denomina independencia lógica de los datos.
 Problemas de redundancia: Es necesario eliminar la redundancia de datos,
dado que cuando se quiere consultar alguno de ellos, podemos estar basando
la consulta sobre datos anticuados o erróneos, lo cual revierte claramente en
una pérdida de integridad de los mismos. Además, cuando un dato es
calculado (o derivado) producto de dos o más datos; es el SGBD quien debe
servir ese dato calculado en el momento, pues al programador o al usuario
puede habérsele olvidado realizar el cálculo tras actualizar los nuevos datos.
 Integridad de los datos: Se requiere un mantenimiento de alta calidad de los
datos en cualquier circunstancia. Cuando se define una base de datos, se
definen sus tipos y también las reglas de integridad que debe cumplir; reglas
de dos tipos: las reglas de integridad del modelo (por ejemplo, no aceptar
datos duplicados) y reglas de integridad del usuario (por ejemplo no aceptar
alumnos de menos de 18 años en la universidad ni de más de 120). Además los
procesos de backup y restauración tras un accidente, deben estar
automatizados y ser transparentes al usuario.
 Concurrencia de usuarios: Cuando muchos usuarios concurren en la misma
base de datos en modo lectura, el único problema es el rendimiento; pero si un
usuario o más están variando datos, se pueden dar problemas de interferencia;
se minimizan estos problemas con la transacción de BD; consiste en un
conjunto de operaciones simples que se ejecutan de manera atómica, es decir
o se ejecutan por completo o no se ejecuta ninguna; nunca, en cualquier caso,
se ejecutará parcialmente. Así por ejemplo si realizamos una transferencia de
efectivo de la cuenta A a la B; primero nos quitan el dinero de A y antes de
ingresarlo en B sucede una caída de tensión; entonces ¿Dónde irá ese dinero?
6 · Bases de datos 1

Para evitar estos problemas se define una transacción de BD, que utilizará la
operación COMMIT para indicar que ya ha terminado; si no puede acabar la
transacción, no llega a esta COMMIT, se deshará todo lo realizado, con la
operación denominada ROLLBACK. Además mientras tiene lugar esta
transferencia, para que se ejecute felizmente, se aísla de las demás
operaciones con la técnica de bloqueo, que pone limitaciones a los accesos del
resto de las transacciones para que no interfieran; lo malo de esto es que
produce esperas, retenciones y, en consecuencia, el sistema se ralentiza. El
esfuerzo actual de los SGBD se centra en minimizar estos efectos negativos.
 Seguridad: No hacemos aquí referencia a los backups que ya habíamos
tratado anteriormente, sino a temas relativos a la confidencialidad,
autorizaciones, derechos de acceso, etc. Los datos manejados en bases de
datos están en España protegidos por ley; y los diferentes sistemas de gestión
de bases de datos utilizan técnicas de limitar las autorizaciones e incluso de
encriptación de datos.

4. ARQUITECTURA DE LOS SGBD

Ya comentamos en puntos anteriores los niveles existentes en una base

de datos: el nivel lógico y el nivel físico; el comité conocido como ANSI/SPARC
definió en 1980 otra definición de estos niveles, denominados esquemas:

 Esquemas externos: Se sitúan las diferentes Esquemas y niveles

visiones lógicas que los usuarios tendrán de las
partes de las BD que utilizarán.
 Esquema conceptual: Es único y global y sirve de
referencia para todos los sistemas: se describen aquí
las entidades tipo, atributos, interrelaciones,
restricciones, reglas de identidad, etc. Así, los
esquemas externos se nutren en la parte que les
interese del esquema conceptual. Si por ejemplo en
el esquema conceptual tenemos los atributos de
alumno: nombre, apellido1, apellido2… quizá en
algún esquema externo aparezca el atributo persona,
que sea la refundición de
nombre+apellido1+apellido2.
 Esquema interno: Se corresponde completamente con el nivel físico del que
hablábamos anteriormente: caminos de acceso,
Independencia física
codificación de datos, gestión del espacio y del
tamaño de la página….

Con esta nueva arquitectura de los SGBD la

independencia de los datos está asegurada; así,
hablaremos de independencia física, cuando los
cambios en la organización física (esquema interno) no
afectan al mundo exterior (es decir, los esquemas
externos). Si cambiamos, como se ve en la figura lateral
unos datos de un soporte a otro, no se verán afectados
ni los programas ni los usuarios directos; pero tampoco
se tendrían que ver afectados por ejemplo si cambiamos
el método de acceso a un conjunto de registros
determinados; solo deben variar las correspondencias
entre el esquema conceptual y el nivel físico, pero nada
más.
La independencia lógica también está asegurada:
cuando existen cambios en el esquema conceptual,
dichos cambios no afectarán a los esquemas externos
que no hagan referencia a entidades o atributos
modificados; por otro lado cuando es efectúan cambios en un esquema externo,
 Bases de datos 1 · 7

solo debe afectar a los usuarios de dicho esquema, pero no a usuarios de otros
esquemas externos, ni al esquema conceptual ni, por supuesto al esquema interno.

Flujo y control Por último, destacaremos en este

punto el flujo y control habitual que suelen
hacer los SGBD cuando, por ejemplo, reciben
una consulta desde un esquema externo.
Supongamos que desde un programa usuario
de secretaría de la universidad se piden los
datos académicos de un alumno. El proceso es
el siguiente:
1. Empieza una llamada al programa SGBD
en el que se envía la operación de consulta.
2. El SGBD se basa en el esquema externo
en el que está trabajando y por supuesto en el
conceptual. Se da el visto bueno a la consulta.
3. Entonces el SGBD determina cual es el
mejor mecanismo para responderla.
Supongamos que hemos encontrado el
registro del alumno en cuestión y nos devuelve
como resultado la página donde se encuentran
estos datos, entre los de otros muchos
alumnos.
4. Cuando se sabe en qué página se
encuentra, se consulta el buffer por si esta
página ya se encontrase cargada en memoria,
como resultado de una consulta anterior sobre
ese u otro alumno. De ser así, nos saltamos el punto 5.
5. La página no estaba en memoria, así que hay que buscarla en disco y cargarla
en buffer.
6. El SGBD aplica datos eventuales a las transformaciones lógicas que implica el
esquema externo y las lleva al área de trabajo del programa donde se espera
recibir el resultado de la consulta inicial.
7. A continuación el SGBD retorna el control al programa del usuario y da por
terminada la ejecución de la consulta.

5. MODELOS DE BD

Modelos de BD Todo modelo de base de datos debe

proveernos de estructuras de datos para construir la
BD (tablas, árboles…), restricciones o reglas de
identidad que deben cumplir los datos introducidos y
luego una serie de operaciones para trabajar con los
datos: borrado, consulta, inserciones, búsquedas…

Existen 3 modelos principales de BD que

vamos a estudiar según su evolución histórica:
 Modelo Jerárquico: Sus estructuras son
registros interrelacionados en forma de árboles, son
propios de los años sesenta.
 Modelo en red: De principios de los 70, hay
registros e interrelaciones, aunque ya no obliga
como en el anterior, que un registro sea hijo de un
solo registro.
 Modelo relacional: Se basa en el concepto
matemático de relación, entendiéndola como tabla.
El modelo relacional se limita al nivel lógico (no hace
consideración alguna sobre las representaciones
8 · Bases de datos 1

físicas, por lo que nos da una independencia total), mientras que los dos
modelos anteriores prerrelacionales sí.

En los últimos años se está extendiendo el modelo de BD relacional con

objetos, añadiendo tipos abstractos de datos (TAD) a los tipos reconocidos y
manipulados por la BD; esto acerca los sistemas relacionales al paradigma de la
orientación a objetos.

6. LENGUAJES Y USUARIOS

Para comunicarse con el SGBD, el usuario, ya sea un programador, o un

usuario directo, se vale de un lenguaje. Hay lenguajes especializados en la escritura
de esquemas, es decir en la descripción de las BD, son llamados genericamente
DDL (data definition language; otros están especializados en la utilización de la BD
y se denominan DML (Data management language). Aunque es frecuente que un
lenguaje disponga de construcciones para las dos funciones. De entre ellos, el más
utilizado es el lenguaje SQL, que tiene verbos (instrucciones) de varios tipos:
 Verbos DML: por ejemplo SELECT, para hacer consultas, INSERT, DELETE,
para el mantenimiento de datos… Dentro de este aspecto hay lenguajes muy
declarativos (se especifica qué se debe hacer y no cómo) y otros más
procedimentales (nos exigen conocer cuestiones del funcionamiento de las
SGBD).
 Verbos DDL: como CREATE TABLE para definir las tablas, sus columnas,
restricciones.
 Verbos de control del entorno: como COMMIT y ROLLBACK, como ya vimos
anteriormente.

Otros lenguajes son el 4GL de muy alto nivel que pretende facilitar el uso de la
BD y también la definición de menús, pantallas, diálogos; las herramientas o
interfaces visuales permiten usar el estilo visual de windows con ventanas que
facilitan el trabajo.

7. ADMINISTRACIÓN DE BD

Hay un tipo de usuario en la BD muy especial, el administrador: es el

responsable del correcto funcionamiento de la base de datos y velan para que
siempre esté accesible y útil. En algunas empresas multinacionales el administrador
de BD pueden llegar a ser 10 personas distintas las que se encarguen de ello. El
administrador debe facilitar los backups, resolución de emergencias, vigilancia de la
integridad y calidad de los datos…

Tema 3
El modelo relacional y el álgebra
relacional
1. Estructura de datos
2. Operaciones del modelo
relacional
3. Reglas de integridad
4. El álgebra relacional
Esquema de relación
Empleados
DNI Nombre Apellido Sueldo
40444 Juan Garcia 2000
33567 Marta Roca 2500
55898 Luis Bernal 3000
Extensión de la relación
Bases de datos 1 · 9
TEMA 3 EL MODELO RELACIONAL Y EL ÁLGEBRA RELACIONAL
1. ESTRUCTURA DE DATOS
El modelo relacional es un modelo de datos y tiene muy en cuenta los 3
siguientes aspectos:
 La estructura que debe permitir representar la información que nos interesa
del mundo real.
 La manipulación de esa información mediante la actualización y consulta de
los datos.
 La integridad que da consistencia a los datos mediante el establecimiento de
reglas que éstos deben cumplir.
Los principios del modelo de base de datos relacional fueron establecidos en el
año 1970; aunque no fue hasta la década de los 80 en que se empezaron a
comercializar los primeros SGBD con rendimientos aceptables. Su principal objetivo
es facilitar que la base de datos sea percibida por el usuario con una estructura
lógica consistente en un conjunto de relaciones, olvidándonos de la implementación
física (independencia de los datos).
Visión formal de una relación
Un dominio es un conjunto de valores atómicos (indivisibles). Estos
dominios pueden ser de dos tipos:
 Predefinidos: Corresponde a tipos de datos como enteros, cadenas de
caracteres, reales…
 Definidos por el usuario: Que pueden ser más específicos y adaptables a
cada base de datos.
Toda relación se compone del esquema y de la extensión. El esquema
consiste en el nombre de una relación y el conjunto de atributos; mientras que la
extensión es un conjunto de tuplas. En la tabla lateral, el esquema está consituido
por las dos primeras filas: empleados y el nombre de sus atributos; y la extensión
por las 3 filas restantes. Algunos autores denominan tablas, columnas y filas a lo
que en BD se llaman relaciones, atributos y tuplas. Así, en este ejemplo, el nombre
de la relación es EMPLEADOS y el conjunto de atributos es {DNI, nombre, apellido,
sueldo}. Si denotamos el esquema de la relación representada en esta tabla como
EMPLEADOS {DNI, nombre, apellido, sueldo}, el conjunto de tuplas de su extensión
será el de la figura que tenemos debajo del esquema. Observamos como la primera
representación tabular es más cómoda, pero la representación en forma de
conjunto refleja mejor la realidad de la situación de la extensión.
El grado de una relación es el número de atributos que pertenecen a su
esquema; en nuestro ejemplo es 4 (DNI, nombre, apellido y sueldo); mientras que
la cardinalidad de una relación es el número de tuplas que pertenecen a su
extensión (en nuestro ejemplo la cardinalidad de empleados es 3).
Cuando un valor de un atributo es deconocido para una tupla, estamos
hablando de un valor nulo; es el caso de que un empleado desconozca su sueldo
(cosa rara) o por ejemplo el campo teléfono esté vacío dado que no tenga teléfono
ni móvil (cosa también bastante rara).
No debemos confundir relaciones con ficheros de datos; a primera vista
resultan similares, dado que los registros y los campos que forman los ficheros se
parecen a las tuplas y a los atributos de las relaciones respectivamente, pero
existen diferencias radicales e insalvables:
 Atomicidad: Los valores de los atributos de una relación son atómicos, no
deben tener estructura interna; esto da simplicidad y uniformidad al modelo
relacional.
10 · Bases de datos 1

 No repetición de tuplas: En un fichero clásico se pueden repetir registros

exactamente iguales. En el modelo relacional no es posible que una relación
contenga dos tuplas repetidas (dado que es un conjunto, no puede tener
elementos repetidos)
 No ordenación de tuplas: Dado que una relación es un conjunto, no existen
elementos ordenados; aunque luego los SGBD relaciones proporcionen una
implementación física que almacenará las tuplas de relaciones en un orden
concreto, esta ordenación no es visible en el nivel conceptual en el que nos
hayamos.
 No ordenación de los atributos: Los atributos tampoco están ordenados; así
la relación EMPLEADOS {DNI, apellido, nombre, sueldo} es la misma que
EMPELADOS {DNI, nombre, sueldo, apellido}

Claves
 Una superclave es un subconjunto de los atributos del esquema, tal que no
pueda haber dos tuplas en la extensión de la relación que tengan la misma
combinación de valores para los atributos del subconjunto. En nuestro ejemplo
de Empleados, una superclave podría ser {DNI y apellido} o también {DNI} o
también {NumSegSocial}.
 Una clave candidata es una superclave de C que cumple que ningún
subconjunto propio de C es superclave. En nuestro ejemplo anterior solo hay
dos claves candidatas {DNI} y {NumSegSocial} que son exclusivas cada una de
cada empleado.
 Clave primaria es aquella clave candidata cuyos valores se utilizan para
identificar las tuplas de la relación. Así el diseñador de la BD debe elegir de
entre todas las claves candidatas, cual será la clave primaria y el resto, se
convertirán en claves alternativas. Si en nuestro ejemplo elegimos como
clave primaria {DNI}, entonces {NumSegSocial} se convertirá en la clave
alternativa. La clave primaria se designa subrayándola, de forma que nuestra
relación empleados quedaría así: EMPLEADOS {DNI, nombre, apellido, sueldo}.
 Claves foráneas son aquellas que permiten establecer relaciones entre las Claves foráneas
tuplas de las relaciones. Por ejemplo, si la relación empleados se aumentase
con los siguientes atributos EMPLEADOS {DNI, nombre, apellido, sueldo,
DNIjefe, edificiodesp, numerodesp} y tuviésemos otra relación de despachos
del tipo DESPACHOS {edificio, numero, superficie} y así a cada empleado le
asignásemos un despacho diferente en cada uno de los edificios de los que
disponemos; nos podemos encontrar como edificiodesp y numerodesp son
claves foránes de relación con la tabla despachos. Y si además quisieramos
establecer una relación jerárquica de jefe-empleados, el DNIjefe establecería
una clave foránea con DNI dentro de la misma tupla; tal como vemos en la
imagen lateral. Toda clave foránea debe cumplir tener o valor nulo o valores
que coinciden con los valores a los que hace referencia la clave primaria. Es
decir, no podemos tener un empleado cuyo edificio sea París y despacho el
108, si no tenemos en la relación Despachos, este edificio y este número de
despacho; si se admiten, en cambio, los valores nulos. Obviamente además, el
número de atributos de la clave foránea y de la clave primaria debe ser el
mismo (biyección); y además sus dominios deben coincidir.

2. OPERACIONES DEL MODELO RELACIONAL

Las operaciones del modelo relacional deben permitir poder manipular

datos almacenados en una base de datos relacional. Hay 3 operaciones básicas de
actualización: La inserción (añadir tuplas), el borrado (suprimr tuplas) y la
modificación (alterar los valores de una o más tuplas).

La consulta de datos consiste en la obtención de datos deducibles a

partir de las relaciones que contiene la base de datos. Encontramos varios
lenguajes distintos para poder llevar a cabo estas consultas:
 Bases de datos 1 · 11

 Lenguajes basados en el álgebra relacional: Se denominan lenguajes

procedimentales, porque al basarse en la teoría de conjuntos, es necesario
seguir uno o más pasos para ir construyendo una nueva relación que
contengan los datos que responden a nuestra consulta.
 Lenguajes basados en el cálculo relacional: Se denominan lenguajes
declarativos, porque al estar basados en el cálculo de predicados de la lógica
matemática, proporcionan una notación ajustada a cada consulta que
queremos realizar.

El lenguaje SQL que estudiaremos posteriormente, es una combinación de los

dos anteriores, aunque con un predominio del cálculo relacional, por lo que se
considera un lenguaje declarativo.

3. REGLAS DE IDENTIDAD

Una base de datos debe contener datos que, en cada momento, deben
reflejar la realidad. En estas condiciones determinadas configuraciones de valores
para las tuplas de las relaciones pueden no tener sentido. Por ello, denominaremos
integridad a la propiedad de los datos de corresponder a representaciones
plausibles del mundo real.

En general, las condiciones que garantizan la integridad de los datos

pueden ser de dos tipos:
 Restricciones de integridad de usuario: Condiciones específicas de una base
de datos concreta. Por ejemplo, en nuestro ejemplo de EMPLEADOS, no tiene
sentido sueldos negativos.
 Restricciones de integridad de modelo: Son condiciones que deben cumplir
todas las bases de datos que sigan dicho modelo. Por ejemplo la regla de
identidad que garantiza que los valores de una clave primaria de una relación
no se repitan en tuplas diferentes de la misma relación. Todo modelo de base
de datos debe cumplirlo.

Son este último tipo de reglas el que pasamos a desgranar a continuación:

Unicidad de clave primaria  Regla de integridad de unicidad de la clave primaria: Toda clave primaria
Empleados que se elija para una relación, no debe tener valores repetidos. Así, en el
DNI Nombre Apellido Sueldo
40444 Juan Roca 2000
ejemplo lateral, no podría ser clave primaria {apellido}, dado que encontramos
33567 Marta Roca 2500 que está repetido. Aunque no estuviera repetido en este momento, sería
55898 Luis Bernal 3000 arriesgado ponerla como clave primaria, porque si la empresa aumenta, es
posible que en algún momento este valor se repita. Podemos elegir como clave
Entidad de clave primaria
primaria {DNI} que no puede repetirse.
Empleados
DNI Nombre Apellido Sueldo
 Regla de integridad de entidad de la clave primaria: Los atributos de la
40444 Juan Roca 2000 clave primaria de una relación no pueden tener valores nulos. Así si hemos
33567 Marta Roca 2500 elegido DNI como clave primaria, todo empleado debe proporcionárnoslo, pues
Nulo Luis Bernal 3000
no podemos tener valor nulo. En el ejemplo lateral, se provocaría un error de
integridad en la base de datos.
Integridad referencial  Regla de integridad referencial: Se relaciona con el concepto de clave
foránea. En concreto determina que todos los valores que toma una clave
foránea deben ser valores nulos o valores que existen en la clave primaria que
referencia. O sea, que en el ejemplo lateral, los valores no nulos de edificiodesp
y numerodesp deben hacer referencia a un valor que exista en la relación
Despachos. Para asegurarse el SGBD de que esta relación siempre se cumpla,
deberá efectuar comprobaciones cada vez que se produzcan varios tipos de
operaciones:
o Inserciones en una relación que tenga clave foránea (Por ejemplo
en edificiodesp en EMPLEADOS)
o Modificaciones que afecten a atributos que perteneces a la clave
foránea de la relación
o Borrados en relaciones referenciadas por otras relaciones (por
ejemplo, borrado de una tupla en la relación DESPACHOS)
12 · Bases de datos 1

o Modificaciones que afecten a los atributos que pertenecen a la

clave primaria de una relación referenciada por otra relación
(modificación de edificio o número en la relación DESPACHOS).

En estas comprobaciones pueden aplicarse diferentes políticas: de

restricción, actualización en cascada o anulación, que pasamos a explicar,
es el diseñador de la base de datos el que debe tomar en cuenta el
significado de cada clave que asigna para así introducir una u otra política
de integridad en cada una de ellas:
o Restricción: La restricción en caso de borrado consiste en no
permitir borrar una tupla si tiene una clave primaria referenciada
por alguna clave foránea; restricción en caso de modificación
consiste en no permitir modificar ningún atributo de la clave
primaria de una tupla si tiene una clave primaria referenciada por
alguna clave foránea. Así si tenemos una tupla con los nombres de
los clientes, referenciada a otra tupla con los pedidos realizados; no
podremos borrar un cliente que tenga pedidos pendientes.
o Actualización en cascada: Consiste en permitir la operación de
actualización de la tupla y en efectuar operaciones compensatorias
que propaguen en cascada la actualización a las tuplas que la
referenciaban. Así, en cado de borrado podemos permitir borrar las
tuplas referenciadas (en el ejemplo, si borramos el cliente,
borramos también sus pedidos pendientes); en caso de
modificación, permite modificar los atributos en las tuplas que
referenciaba (así, si le cambiamos el número de cliente, también
cambiará el número de cliente en el pedido pendiente).
o Anulación: Consiste en permitir la operación de actualización y
compensarlo poniendo valores nulos a los atributos de la clave
foránea de las tuplas que la reverenciaban. En caso de borrado,
permite el borrado de una tupla y modifica todas las tuplas
referenciadas con ese atributo poniendo valor nulo; en caso de
modificación, los atributos de las tuplas referenciadas no tomarán
el nuevo valor como en la actualización en cascada, sino que
también tomarán un valor nulo.

 Regla de integridad de Dominio: Tiene a su vez dos condiciones. La primera

es que todos los valores no nulos que contiene la base de datos para un
determinado atributo, deben ser del dominio declarado para dicho atributo. Así,
si en una base de datos hemos declarado el dominio DNI como el de los
números enteros, no permitirá introducir el dato “Luis”; también si hemos
definido como edad del trabajador el dominio “16 a 65” años, no se admitirán
valores que estén por encima o debajo de estos dados.
La segunda condición sirve para establecer qué operadores pueden
aplicarse sobre los valores que tengan los dominios. Así no podrá consultarse el
DNI con operaciones del tipo: DNI=”Luis” dado que Luis no es un real. Otro
ejemplo podría ser que si hemos definido edad como de 16 a 65, tampoco
debería poder comparar DNI con edad, dado que aunque sean ambos números
reales, el dominio es distinto. No obstante los SGBD actuales no implementan
esta regla de integridad de dominio, todavía queda camino por recorrer.

4. EL ÁLGEBRA RELACIONAL

Las operaciones que se pueden realizar en el álgebra relacional son las

siguientes: Redenominar, unión, intersección, diferencia, producto cartesiano,
selección, proyección, combinación y división.
A continuación pasamos a estudiar cada una de ellas; pero para ello,
primero estableceremos unas relaciones de ejemplo que usaremos en todas y cada
una de estas operaciones para llegar a su completa comprensión.
 Bases de datos 1 · 13

Relaciones de ejemplo

Operación Redenominar (:=)

La denotaremos con el símbolo := y permite asignar un nombre R
cualquiera a la relación que resulta de una operación del álgebra relacional; por
ejemplo, si queremos sumar los nombres de todos los empleados de la empresa,
independientemente que trabajen en administración o en producción, podemos
hacer:
EMPLEADOS:= EMPLEADOS_ADM  EMPLEADOS_PROD

Operación Unión (  )
La unión es una operación en la que, a partir de dos relaciones, se obtiene
una nueva relación formada por todas las tuplas que están en alguna de las
relaciones de partida. Solo tiene sentido aplicar la unión a relaciones que tengan
tuplas similares y que ambas sean compatibles; es decir, que tengan el mismo
grado y que se pueda establecer una biyección entre los atributos. Así, si llevamos
a cabo:
R:= EMPLEADOS_ADM  EMPLEADOS_PROD
Obtendremos:

R
DNI nombre apellido edificiodesp numerodesp
40444255 Juan García Marina 120
33.567.711 Marta Roca Marina 120
55.898.425 Carlos Buendía Diagonal 120
77.232.144 Elena Pla Marina 230
21.335.245 Jorge Soler NULO NULO
88.999.210 Pedro González NULO NULO

Y se deducirá que a DNI de empleados_adm le corresponde DNI de

empleados_prod… y todas las relaciones subsiguientes. Siempre y por convención,
haremos que los atributos de la relación resultante, coincidan con los atributos de
la relación que figura en primer lugar.

Operación Intersección (  )
A partir de dos relaciones, se obtiene una nueva relación formada por las
tuplas que pertenecen a las dos relaciones de parida. Al igual que la unión solo se
puede aplicar a relaciones que tengan tuplas similares. Como ejemplo:

R:= EMPLEADOS_ADM  EMPLEADOS_PROD

R
DNI nombre apellido edificiodesp numerodesp
33.567.711 Marta Roca Marina 120
14 · Bases de datos 1

Solo obtenemos, por tanto, los elementos que se encuentran en las dos
relaciones, tanto en empleados_adm como en empleados_prod.

Operación Diferencia (-)

En la unión, a partir de dos relaciones, se obtiene una nueva relación
formada por todas las tuplas que están en la primera relación y, en cambio, no
están en la segunda. Solo tiene sentido, obviamente, si se aplica a tuplas similares
y es necesario que las relaciones sean compatibles.

R:= EMPLEADOS_ADM - EMPLEADOS_PROD

R
DNI nombre apellido edificiodesp numerodesp
40444255 Juan García Marina 120

Producto Cartesiano (x)

Es una operación que, a partir de dos relaciones, obtiene una nueva
relación formada por todas las tuplas que resultan de concatenar tuplas de la
primera relación con tuplas de la segunda. Las tuplas no tienen que ser compatibles
y no deben tener ningún nombre de atributo común. En estas condiciones podemos
hacer el producto cartesiano de DESPACHOS y EDIFICIOS_EMP, que requiere una
redenominación para no incurrir en atributos con el mismo nombre:
EDIFICIOS (nombreedificio, supmediadesp):= EDIFICIOS_EMP(edificio, supmediadesp)
R:= EDIFICIOS x DESPACHOS

R
nombreedificio supmediadesp edificio numero superficie
Marina 15 Marina 120 10
Marina 15 Marina 230 20
Marina 15 Diagonal 120 10
Marina 15 Diagonal 440 10
Diagonal 10 Marina 120 10
Diagonal 10 Marina 230 20
Diagonal 10 Diagonal 120 10
Diagonal 10 Diagonal 440 10

Conviene señalar que el producto cartesiano raramente se utiliza de forma

explícita, pues su resultado no suele ser muy útil, en cambio sí se utiliza como
operación primitiva de la combinación.

Selección T(C)
Es una operación que a través de unas condiciones (C) pretende
seleccionar algunas tuplas (T) del resto. Por ejemplo:

R:= DESPACHOS (edificio = Marina y superficie > 12)

R
edificio numero superficie
Marina 230 20

Seleccionamos así los despachos del edificio Marina, cuya superficie es

mayor de 12.

Proyección T[A1, A2…]

Es una operación unaria (igual que la anterior, solo requiere una relación)
que sirve para elegir algunos atributos de una relación y eliminar el resto. Si
necesitamos hacer una consulta por ejemplo de los empleados de administración,
pero solo queremos el nombre y apellido, sin ningún dato más, podemos hacer:

R:= EMPLEADOS_ADM[nombre, apellido] R

nombre apellido
Juan García
Marta Roca
 Bases de datos 1 · 15

Combinación T[B]S
La combinación es una operación que, a partir de dos relaciones, obtiene
una nueva formada por todas las tuplas que resultan de concatenar tuplas de la
primera relación con tuplas de la segunda y que cumplen una condición de
combinación especificada.
Para ello se requieren que las dos tuplas que participan (T y S) no tengan
ningún nombre de atributo común, siendo B la condición de combinación. Así, si
queremos obtener una relación que contenga todos los datos de cada uno de los
despachos cuya superficie es mayor o igual a la media del edificio en el que se
encuentran, podemos hacer (primero redenominamos atributos):

EDIFICIOS (nombreedificio, supmediadesp):=EDIFICIOS_EMP(edificio, supmediadesp)

R:= EDIFICIOS[nombreedificio = edificio, supmediadesp <= superficie] DESPACHOS

R
nombreedificio supmediadesp edificio numero superficie
Marina 15 Marina 230 20
Diagonal 10 Diagonal 120 10
Diagonal 10 Diagonal 440 10

Cuando existe una equicombinación (hemos utilizado el operador = en las

condiciones que había que cumplir), siempre aparecen una o más parejas de
atributos que tienen valores idénticos en todas las tuplas. En el caso anterior
nombreedificio y edificio son iguales. Puesto que de este par de atributos uno es
supérfluo, se utiliza la combinación natural (T*S) comouna equicombinación
seguida de la eliminción de los atributos supérfluos. Así, podemos hacer:

R:= EDIFICIOS_EMP * DESPACHOS

R
nombreedificio supmediadesp numero superficie
Marina 15 120 10
Marina 15 230 20
Operaciones relacionales Diagonal 10 120 10
Diagonal 10 440 40
Redenominar (:=)
Unión ( )
Intersección ( )
Diferencia (-) División (:)
Producto Cartesiano (x) Es una combinación de una proyección, del producto cartesiano y de la
Selección T(C)
Proyección T[A1, A2…]
diferencia. La división de una relación R1 (dividendo) por otra R2 (divisor) es una
Combinación T[B]S relación R (cociente) tal que al realizarse su combinación con el divisor, todas las
División (:) tuplas resultantes están en el dividendo.

Secuencias de operaciones del álgebra relacional

Como en muchos casos para formular una consulta en álgebra relacional e
spreciso utilizar varias operaciones que se aplican en un cierto orden, es mejor
descomponer la expresión en varios pasos, donde cada paso aplique una sola
operación y obtenga una relación intermedia que se pueda utilizar en los pasos
siguientes.
Así, por ejemplo, si queremos obtener el nombre del edificio y el número de
los despachos situados en edificios en los que la superficie media de estos
despachos es mayor que 12, podemos utilizar la siguiente secuencia de
operaciones:

A:= EDIFICIOS_EMP (supmediadesp > 12)

B:= DESPACHOS * A
R:= B[edificio, numero]
16 · Bases de datos 1

TEMA 4 EL LENGUAJE SQL

1. SENTENCIAS DE DEFINICIÓN Tema 4

El lenguaje SQL
1. Sentencias de definición
Para poder trabajar con bases de datos relacionales, lo primero que hay 2. Sentencias de manipulación
que hacer es definirlas. En el estándar SQL92 (estándar que vamos a utilizar en 3. Sentencias de control
4. Sublenguajes especializados
toda la asignatura) vamos a llevar a cabo las siguientes operaciones:
 Creación y borrado de una base de datos relacional.
 Creación de tablas.
 Modificación y borrado de tablas.
 Creación y borrado de vistas.

Creación y borrado de una base de datos relacional

El estándar SQL92 no dispone de ninguna sentencia para crear ni para
borrar una base de datos relacional, ya que como una base de datos no es más que
un conjunto de tablas, este lenguaje se concentra en la creación, modificación y
borrado de estas tablas. De lo que sí disponemos es de una sentencia más potente
que la creación de bases de datos y es la denominada CREATE SCHEMA, con la que se
pueden agrupar un conjunto de elementos de la base de datos que son propiedad
de un usuario. La sintaxis es:
CREATE SCHEMA {[nombre_esquema] | [AUTHORIZATION usuario]} [lista-elementos]

Aunque todos los parámetros de la sentencia anterior son opcionales, como mínimo
debemos dar el nombre del esquema o el usuario. Para borrar el esquema:

DROP SCHEMA nombre_esquema {RESTRICT|CASCADE}

Restrict hace que el esquema sólo se pueda borrar si no contienen ningún

elemento, mientras que si elegimos Cascade borraremos el esquema aunque no
esté completamente vacío.

Creación de tablas
Para crear una tabla es necesario utilizar la sentencia Create table, en la
que definiremos el nombre de tabla y después de definición de cada columna con el
tipo de daos o el dominio y sus restricciones:

CREATE TABLE departamentos

(nombre_dep CHAR(20),
ciudad_dep CHAR(20),
telefono INTEGER DEFAULT NULL,
PRIMARY KEY (nombre_dep, ciudad_dep)
);

Creamos así una tabla de departamentos de una empresa, cuya clave

primaria es el nombre del departamento y la ciudad en que se encuentra.
Podríamos añadir sentencias de restricciones de dominio, que podría ser:

CREATE DOMAIN dom_ciudades AS CHAR (20)

CONSTRAINT ciudades_validas
CHECK (VALUE IN (`Barcelona´, `Madrid´, `Valencia´))

Donde nos aseguramos con la orden CONSTRAINT (restricción de dominio)

que todas las ciudades sean una de las 3 que hemos incluido posteriormente. Para
borrar un dominio utilizamos el formato:

DROP DOMAIN nombre_dominio {RESTRICT|CASCADE}

Donde al igual que antes restrict hace que el dominio solo se pueda borrar
si no se utiliza en ningún sitio,mientras que cascade borra el dominio aunque esté
referenciado.
 Bases de datos 1 · 17

Para modificar un dominio utilizamos la sentencia ALTER DOMAIN, así por ejemplo:

ALTER DOMAIN dom_ciudades DROP CONSTRAINT ciudades_validas;

Eliminamos la restricción de dominio antigua y ahora introducimos una

nueva restricción.:

ALTER DOMAIN dom_ciudades ADD CONSTRAINT ciudades_validas

CHECK (VALUE IN (`Barcelona´, `Madrid´, `Valencia´, `Mataro´));

La orden def_defecto nos permite especificar que nomenclatura queremos

dar a nuestros valores por omisión. Por ejemplo, para un empelado que todavía no
se ha decidido cuánto ganará, podemos elegir que de momento tenga un suelo de
0 euros (DEFAULT 0.0) o bien que tenga un sueldo con valor nulo (DEFAULT NULL),
eso sí, la columna para la que daremos la definición por defecto de valor nulo debe
admitir valores nulos.

Recordemos también que en el tema anterior vimos 3 políticas aplicables a

los casos de borrado y modificación de filas que tienen una clave primaria
referenciada por claves foráneas, éstas eran: restricción, cascada y anulación; bien,
cuando especificamos una clave foránea, SQL nos permite definir qué política de las
tres anteriores queremos seguir, sería asi:

FOREIGN KEY clave_secundaria REFERENCES tabla[(clave_primaria)]

[ON DELETE {NO ACTION | CASCADE | SET DEFAULT | SET NULL}]
[ON UPDATE {NO ACTION | CASCADE | SET DEFAULT | SET NULL}]

Así, NO ACTION corresponde a la política de restricción; CASCADE a la

actualización es cascada y SET NULL la anulación; además SET DEFAULT es una
variante de SET NULL donde en lugar de valores nulos se puede poner el valor
especificado por defecto.

Modificación y borrado de tablas

Para modificar una tabla es preciso utilizar la sentencia ALTER TABLE,
normalmente querremos añadir o borrar una columna, modificar las definiciones
por defecto para una columna, añadir o borrar alguna restricción de tabla.

Creación y borrado de vistas

Las vistas no existen realmente como un conjunto de valores almacenados
en la base de datos, sino que son tablas ficticias denominadas derivadas (no
materializadas) construidas a partir de tablas reales.

CREATE VIEW proyectos_por_cliente (codigo_cli, numero_proyectos) AS (SELECT

c.codigo_cli, COUNT(*)
FROM proyectos p, clientes c
WHERE p.codigo_cliente = c.codigo_cli
GROUP BY c.codigo_cli)

Todo el código anterior parte de una tabla clientes y una tabla proyectos
referenciada a la primera, y se ha creado una vista en la que obtenemos el código
de cliente y el número de proyectos en los que se está trabajando con cada cliente
actualmente.

Para borrar una vista utilizamos la orden DROP VIEW e igualmente

elegiremos entre las opciones RESTRICT o CASCADE. Con la primera la vista no se
borrará si está referenciada (por ejemplo en otra vista); en cambio con CASCADE
todo lo que referencia a la vista se borrará con esta.

DROP VIEW clientes RESTRICT;

18 · Bases de datos 1

2. SENTENCIAS DE MANIPULACIÓN

Una vez creada la base de datos con sus tablas, debemos poder insertar,
modificar y borrar los valores de las filas de la tabla. Esto es lo que vamos a llevar a
cabo en los siguientes apartados:
 Inserción de filas en una tabla
 Borrado de filas en una tabla
 Modificación de filas en una tabla
 Consultas a una base de datos relacional

Inserción de filas en una tabla

La inserción de filas en una tabla se lleva a cabo con la sentencia INSERT
INTO seguida del nombre de la tabla y de los valores a insertar:

INSERT INTO clientes

VALUES (10, `EGIGSA´, `37.248.573-C´, `ARAGON 242´, `Barcelona´, DEFAULT);

O bien si estos datos introducidos para esta fila no estuviesen en orden, le

indicados tras insert into el orden de los datos que introducimos (todo entre
paréntesis) y procedemos luego a VALUES.

Borrado de filas en una tabla

Se utiliza la sentencia DELETE y se selecciona con WHERE las condiciones para
borrar esos datos, por ejemplo:

DELETE FROM proyectos

WHERE codigo_cliente=2;

Se borrará de la base de datos proyectos todas las filas cuyo código_cliente

sea 2, y se pueden borrar multiples filas con esta sentencia.

Modificación de filas en una tabla

Se lleva a cabo con una combinación de sentencias: UPDATE seguido del
nombre de tabla, SET para saber qué columna vamos a cambiar y WHERE donde se
establecen los condicionantes:

UPDATE empleados
SET sueldo = sueldo+1000
WHERE num_proyec = 2

Le acabamos de subir en 1000 euros el sueldo a los empleados que están

trabajando en el proyecto número dos.

Consultas a una base de datos relacional

Haremos uso de la sentencia SELECT seguido de las columnas que
queremos seleccionar de esa tabla y FROM la tabla de la que extraemos; si después
de SELECT hacemos uso de la sentencia AS renombraremos las tablas (alias). Así:
SELECT *
FROM clientes;

SELECT codigo_cli, nombre_cli, direccion, ciudad

FROM clientes
WHERE num_proyec=4;

En la primera consulta seleccionamos todas las columnas y filas de la base

de datos clientes; en cambio en la segunda solo seleccionamos las columnas
especificadas del proyecto número 4. Si resulta que de nuestros condicionantes se
repiten resultados en la consulta, podemos evitar que aparezcan los repetidos con
la clave DISTINCT inmediatamente después de SELECT, por defecto, aparecerá
todo (ALL).
Tras el WHERE pueden aparecer también consultas dentro de la consulta, y
predicados como BETWEEN, para establecer entre qué dos límites debe moverse
 Bases de datos 1 · 19

el resultado, IN para indicar que el resultado debe coincidir con alguno de los que
Funciones de agregación pongamos después entre paréntesis, LIKE implica alguna característica, por
COUNT Nº total de filas ejemplo WHERE nombre_empl LIKE `J%´ implicará que el empleado empiece por J o
seleccionadas WHERE nombre_emple LIKE `S _ _ _´ buscará aquellos empleados que empiecen por
SUM Suma valores de una S y tengan cuatro letras, como Sara. También aparecen otros predicados como IS
columna
NULL para indicar que buscamos los nulos (o IS NOT NULL).
MIN Valor mínimo de la
columna
MAX Valor máximo de la También podemos utilizar funciones de agregación, que son las que vemos
columna en la tabla lateral, como por ejemplo:
AVG Valor medio
SELECT COUNT (*) AS numero_dep
FROM departamentos
WHERE ciudad_dep = `LERIDA´;

Obtenemos así el número de departamentos que tenemos en la ciudad de

Lérida. Tras la consulta, podemos pedir que la tabla se ordene con ORDER BY,
como por ejemplo:

SELECT codigo_empl, nombre_empl, apellido_empl, sueldo

FROM empleados
CORDER BY sueldo DESC, nombre_empl

Donde obtenemos las 4 columnas pedidas en SELECT sobre todos los

empleados (no hemos puesto ningún condicionante) y queremos que nos salda
ordenado por el sueldo y, a igual sueldo, ordenado posteriormente por el apellido.
Además hemos pedido que nos lo ordene de mayor a menor sueldo (DESC).

A continuación vamos a llevar las mismas consultas que llevábamos a cabo

en la unidad anterior en lenguaje SQL, por tanto:

 Combinación
SELECT proyectos.codigo_proyecto, proyectos.precio, clientes.nif
FROM clientes, proyectos
WHERE clientes.codigo_cli=proyectos.codigo_cliente AND
clientes.codigo_cli=20;

Combinamos de dos tablas proyectos y clientes, aquellos proyectos que son

del cliente con código 20. Podemos ahorrarnos repetir proyectos y clientes,
utilizando un alias, como se ve en el ejemplo inferior, en el que hemos utillizado p
para proyectos y c para clientes y hemos “limpiado” un poco el código:

SELECT p.codigo_proyecto, p.precio, c.nif

FROM clientes c, proyectos p
WHERE c.codigo_cli=p.codigo_cliente AND c.codigo_cli=20;

Haciendo uso de otro SQL más evolucionado, la sentencia anterior sería

SELECT p.codigo_proyecto, p.precio, c.nif

FROM clientes c JOIN proyectos p on c.codigo_cli=p.codigo_cliente
WHERE c.codigo_cli=20;

 Combinación natural
SELECT p.codigo_proyecto, p.precio, c.nif
FROM clientes c NATURAL JOIN proyectos p
WHERE c.codigo_cli=20;

Queda entendido que en clientes y proyectos debe existir una columna con
el mismo nombre para poder realizarse esta combinación natural. Al igual que en
Lenguaje SQL teníamos combinación por la derecha, por la izquierda o completa. La
combinación interna es la que hemos realizado anteriormente, se pierden los
valores de las dos tablas que no coinciden INNER JOIN, pero podemos hacer uso
de la combinación por la izquierda (NATURAL LEFT OUTER JOIN), por la derecha
(NATURAL RIGHT OUTER JOIN) o combinación externa plena (NATURAL FULL
OUTER JOIN)
20 · Bases de datos 1

 La Unión
Se lleva a cabo con la cláusula UNION
SELECT ciudad
FROM clientes
UNION
SELECT ciudad_dep
FROM departamentos;

 Intersección
Se lleva a cabo con la cláusula INTERSECT, pero de la misma forma que la Unión.

 Diferencia
Se utiliza la cláusula EXCEPT como en el ejemplo:
SELECT codigo_cli
FROM clientes
EXCEPT
SELECT codigo_cliente
FROM proyectos;

De esta consulta extraemos el código de clientes que no tienen ningún

proyecto contratado ahora mismo con nosotros.

3. SENTENCIAS DE CONTROL

Además de todo lo anterior, debemos establecer una serie de mecanismos

de control para resolver problemas de concurrencia por un lado (transacciones) y
garantizar la seguridad por otro (autorizaciones).

Una transacción es una unidad lógica y atómica de trabajo; es decir, es

un conjunto de sentencias que se ejecutan como si fuesen una sola. Para iniciar
una transacción se utiliza la cláusula SET TRANSACTION y para finalizarla COMMIT
(confirma todos los cambios producidos) o ROLLBACK (deshace todos los cambios
desde el inicio de la transacción)
SET TRANSACTION READ WRITE;
UPDATE empleados SET sueldo=sueldo-1000 WHERE num_proyec=3;
UPDATE empleados SET sueldo=sueldo+1000 WHERE num_proyec=1;
COMMIT;

Acabamos de aumentar en 1000 el sueldo de los empleados del proyecto 3

y, a la par, disminuir en 1000 el sueldo de los empleados del proyecto 1.

Las autorizaciones se llevan a cabo con la sentencia:

GRANT privilegios ON objeto TO usuarios [WITH GRANT OPTION]

Donde privilegios puede ser sustituido por ALL PRIVILEGES (todos los
privilegios), USAGE (según el objeto), SELECT (Consultas), INSERT [Columnas]
(inserción de según qué columna), UPDATE, DELETE, REFERENCES. Los objetos
pueden ser un dominio, una tabla o una vista; y por fin, los usuarios pueden ser
todos (PUBLIC) o una lista de identificadores de usuario. Asimismo, se puede
utilizar la opción WITH GRANT OPTION, que permite al usuario autorizado a
autorizar a otros usuarios con los mismos privilegios que él ha sido autorizado.

Para desautorizar la orden utilizada es REVOKE:

REVOKE [GRANT OPTION FOR] privil ON objeto TO usuarios [RESTRICT|CASCADE]

La opción Restrict no nos permite desautorizar a un usuario si éste ha

autorizado a otros y la opción cascada sí, y además hace que queden todos
desautorizados a la vez.
 Bases de datos 1 · 21

4. SUBLENGUAJES ESPECIALIZADOS
Lenguaje hospedado
Para poder utilizar el SQL desde un lenguaje de
programación, podemos utilizar el SQL hospedado y
para ello precisamos de un precompilador que separe
las sentencias del lenguaje de programación de las del
lenguaje de base de datos. Una alternativa interesante
son las tuinas SQL/CLI. El precompilador separa las
sentencias del SQL y las sentencias de programación;
así donde hay una sentencia de acceso a la base de
datos, tendremos una llamada a la interfaz del SGBD.
Todas las sentencias que hemos usado hasta
ahora son las mismas que se van a seguir usando pero
precedidas de la cláusula EXEC SQL.

Las SQL/Call-Level Interface, denominadas de

forma abreviada CLI permiten que aplicaciones
desarrolladas en un cierto lenguaje de programación
puedan incluir sentencias SQL mediante llamadas a
librerías; por ejemplo la interfaz ODBC define una
librería de funciones que permite a las aplicaciones
acceder al SGBD utilizando el SQL.
22 · Bases de datos 1

TEMA 5 INTRODUCCIÓN AL DISEÑO DE BASES DE DATOS

1. INTRODUCCIÓN AL DISEÑO DE BASES DE DATOS Tema 5

Introducción al diseño de bases
de datos
El diseño de una base de datos consiste en definir la estructura de los datos 1. Introducción al diseño de
que debe tener la base de datos en un sistema de información determinado; así bases de datos
2. Diseño conceptual: El
que deberemos definir los atributos, dominios de atributos, claves primarias y modelo ER
foráneas, etc. 3. Diseño lógico: Del modelo ER
al modelo relacional

Las etapas de diseño que reconocemos en una base de datos son tres:

 Diseño conceptual: Obtenemos aquí una estructura de la información de la

futura BD independiente de la tecnología a emplear, el resultado se sitúa en el
mundo de las concepciones; así que nos concentraremos únicamente en la
problemática de la estructura de la información sin tener que preocuparnos de
resolver cuestiones tecnológicas. Uno de los modelos de datos de alto nivel
más empleados es el modelo entidad-interrelación (entity-relationship), que
abreviaremos con la sigle ER y es el que utilizaremos en el siguiente capítulo.
 Diseño lógico: Partimos del diseño conceptual anterior ajustando el modelo
obtenido al SGBD con el que implementaremos la base de datos; aprenderemos
a transformar un modelo ER en un modelo relacional.
 Diseño físico: Transformaremos la estructura obtenida en el diseño lógico con
el objetivo de conseguir mayor eficiencia.

2. DISEÑO CONCEPTUAL: EL MODELO ER

Dentro de este modelo distinguiremos las construcciones básicas y las

extensiones.

CONSTRUCCIONES BÁSICAS

Por entidad entendemos un objeto del mundo real que podemos distinguir Entidad
del resto de objetos y del que nos interesan algunas propiedades (que
denominaremos atributos). Las entidades, como la entidad EMPLEADO de la
figura lateral se representan con un rectángulo y su nombre en mayúsculas en el
interior. Los atributos se representan mediante un nombre en minúsculas unido con
un guión al rectángulo de la entidad. La clave primaria de entre todas las
candidatas se subraya para distinguirla del resto de las claves (dni).

Definimos interrelación como una asociación entre entidades, y en

ocasiones estas interrelaciones también tendrán atributos, y al igual que los de las
entidades, tendrán un cierto dominio. Estudiaremos este aspecto profundizando en Interrelación binaria
el grado de las interrelaciones, este grado es el número de entidades que
asocia una interrelación. Las interrelaciones se representan con un rombo que une
las dos entidades relacionadas y, a veces, con un atributo que califica esta relación.
Una relación binaria es aquella que se da entre dos entidades. Por ejemplo, en la
relación estudiante-asignatura que tenemos en la figura lateral, es una relación
binaria que relaciona dos entidades y que queda calificada por el atributo nota.
Nótese que para cada alumno que cursa una determinada materia, existe una nota,
y por ello obtenemos la interrelación en el nivel de clase y, más abajo, en el nivel
de ocurrencias.
La conectividad de una relación expresa el tipo de correspondencia que
se establece entre las ocurrencias de las entidades asociadas en esta interrelación.
Así, a nivel binario podemos tener:
 Conectividad uno a uno (1:1): Ponemos un 1 al lado de cada entidad. Por
ejemplo si tuviésemos una interrelación binaria de una empresa que asocia
delegaciones con capitales de provincia; expresando que en cada capital solo
 Bases de datos 1 · 23

hay una delegación y que además tenemos delegaciones en todas las capitales
de provincia, la conectividad sería 1:1.
 Conectividad 1:N: Conectividad despacho, empleado con la relación Asignación.
Resulta que todo despacho debe estar ocupado, con uno o más empleados y
que todo empleado tiene despacho pero solo uno. Por tanto en el lado de
despacho pondremos un 1 y en el lado de empleado una N.
 Conectividad M:N: Varios a varios. Así las notas que un estudiante puede tener
en una misma asignatura, no tiene porqué ser solo una, sino que puede tener
varias hasta que consiga aprobarla; de la misma forma, una misma asignatura
Dependencia es cursada por varios estudiantes, con lo cual tenemos también muchas notas.

Es muy habitual que las interrelacionas binarias M:N y todas las n-arias (>2)
tengan atributos, en cambio las binarias 1:1 y 1:N no tienen por qué tenerlos; dado
que siempre se le pueden asignar atributos a la entidad del lado N en el caso de
1:N y a cualquiera de las dos en el caso 1:1.

En algunos casos además se da una dependencia de la existencia, en la

cual una entidad individual solo9 puede existir si hay como mínimo otra entidad
individual asociada con ella mediante una interrelación binaria determinada. Por
ejemplo, en el modelo lateral vemos que la entidad empleado es obligatoria (línea
perpendicular que la cruza) en su relación con dirección es decir, cada
departamento tiene un empleado (y sólo uno) que le sirve de director; pero no
todos los empleados tienen porqué ser directores de departamento,
(circunferencia).
Relación ternaria
Muchas veces, el modelo binario no nos sirve para modelas todas las
situaciones de la vida real; así por ejemplo, retomando el ejemplo del alumno que
se matricula en una asignatura, si la suspende, tiene que volver a matricularse y
volverá a obtener, como resultado de ello, otra calificación. Nos interesa modelar
esta situación y, en este caso hablaremos de una relación ternaria (además 1:1:1),
en la que cada alumno obtiene para cada asignatura, una nota en cada semestre.
Interrelación recursiva
Las interrelaciones recursivas son aquellas en las que la misma entidad
está asociada más de una vez. Un ejemplo sería persona y boda. Toda persona se
tiene que casar con otra persona, y normalmente en estos casos se refleja el papel
o rol diferenta que tiene cada una de ellas en la interrelación; fijémonos además
que se trata de una relación de dependencia, establecida por los círculos que
marcan cada rol en su relación.
Entidad débil

Las entidades débiles son aquellas cuyos atributos no la identifican

completamente, sino solo parcialmente y debe participar en una interrelación que
ayude a identificarle. Se representan con un rectángulo doble y la interrelación que
ayuda a identificarla con una línea doble. Así, en el ejemplo lateral, la entidad
despacho no queda perfectamente definida por su número, sino que depende del
edificio en el que esté situada para definirse completamente (dado que un mismo
despacho, el 106 puede existir en ambos edificios y ser distinto, lógicamente). Esta
interrelación obligatoriamente debe ser binaria con conectividad 1:N y la entidad
débil debe estar del lado de la N. Además la entidad del lado 1 debe ser obligatoria
en la relación.

EXTENSIONES DEL MODELO ER

Estudiaremos dos extensiones: la generalización/especialización y las

entidades asociativas.

La generalización/especialización permite reflejar el hecho de que hay

una entidad general, que denominaremos aquí superclase, que se puede
especializar en entidades subclase. Estas últimas tienen, además de las
características de la superclase a la que pertenecen, algunas características propia
de su especialización.
24 · Bases de datos 1

Así, por ejemplo, en el modelo lateral, Generalización/Especialización

observamos que tanto los directivos, técnicos como
administrativos son subclases (por la flecha que les
une) de la superclase Empleado. Tienen los tributos
DNI, nombre, apellido, dirección y teléfono de la
superclase, pero además el directivo tiene una
característica que no tienen los demás y es contar con
coche de la empresa, el técnico tiene titulación y del
administrativo nos interesa la antigüedad. Además la
generalización puede ser:

 Disjunta/Solapada: Una misma ocurrencia no

puede aparecen en dos entidades subclase distintas (disjunta) o sí puede
(Solapada).
 Total/Parcial: Toda ocurrencia de la entidad superclase debe pertenecer a
alguna de las entidades subclase (Total) o no (Parcial).

En el ejemplo anterior se trata de una generalización/especialización disjunta, total.

Las entidades asociativas son las que resultan de considerar Entidad asociativa
una interrelación entre entidades como si fuese una entidad, y tendrá el
mismo nombre que la interrelación sobre la que se define. Así nos
permite tener interrelaciones en las que a su vez intervienen
interrelaciones. Se denota una entidad asociativa recuadrando el rombo
de la interrelación de la que proviene
Hay que considerar que el mecanismo de las entidades
asociativas subsume el de las entidades débiles y resulta todavía más
potente. En el ejemplo lateral hemos sustituido la entidad débil
despacho que tiene la interrelación asignación con la entidad empleado;
y vemos en el diagrama inferior la sustitución. Observamos así que
siempre que utilicemos una entidad débil podremos sustituirla pro una
entidad asociativa, pero no al revés. Hay ocasiones en las que no nos
interesa el cambio, sobre todo porque en el modelo ER resultan menos
complejas y son suficientes para modelizar las situaciones que se
producen en el mundo real.

3. DISEÑO LÓGICO: DEL MODELO ER AL MODELO RELACIONAL

En esta etapa tenemos que transformar el modelo ER obtenido en la fase

anterior en una estructura de datos de modelo relacional. En este sentido las
entidades originarán relaciones y las interrelaciones pueden dar lugar a claves
foráneas de alguna relación ya obtenida o pueden dar lugar a una nueva relación.
Pasamos a analizar todos los casos posibles.

Transformación de entidades
Entidad
Cada entidad ER pasa a ser como decíamos anteriormente, una relación del
modelo relacional. Los atributos de la entidad serán atributos de la relación y, de
forma análoga, la clave primaria de la entidad, será la clave primaria de la relación.
Así, en el ejemplo lateral ya conocido de la entidad empleado,
obtendríamos la relación:

EMPLEADO(DNI, NSS, nombre, apellido, sueldo)

Una vez transformadas todas las entidades, se hace necesario transformar

todas las interrelaciones en las que intervienen estas entidades.
 Bases de datos 1 · 25

Transformación de interrelaciones binarias

Conectividad 1:1

 Conectividad 1:1: Sólo es necesario añadir a estas dos relaciones ya

convertidas una clave foránea que referencia a la otra relación. En el ejemplo
lateral, donde para cada ciudad hay una y solo una delegación, tenemos dos
opciones y ambas referencian correctamente la relación:
DELEGACION(nombre_del,…, nombre-ciudad)
Donde{nombre-ciudad} referencia CIUDAD
CIUDAD (nombre-ciudad…)

DELEGACION (nombre-del,…)
CIUDAD (nombre-ciudad, …nombre-del)
Donde {nombre-del} referencia DELEGACION

Conectividad 1:N  Conectividad 1:N: Solo debemos añadir en la relación correspondiente a la

entidad del lado N, una clave foránea que referencie la otra relación. Así en el
ejemplo lateral donde un empleado puede tener solo un despacho, pero este
despacho ser a su vez de varios empleados, la interrelación se transforma en:

DESPACHO (desp, ….)

EMPLEADO (emp, …, desp)
Donde {desp} referencia DESPACHO

 Conectividad M:N: Una interrelación M:N se transforma en una relación. Su

clave primaria estará formada por los atributos de la clave primaria de las dos
entidades interrelacionadas. Los atributos de la interrelación serán atributos de
Conectividad M:N
la nueva relación. Así el ejemplo lateral se convierte en:
ESTUDIANTE (est, …)
ASIGNATURA (asign, …)
EVALUACION (est,
asign, nota)
Donde {est} referencia ESTUDIANTE y {asign} referencia
ASIGNATURA

 Influencia de la existencia de dependencia: Hay que tener en cuenta que

si una de las entidades es opcional en la interrelación y la transformación ha
consistido en poner una clave foránea que corresponde a la otra entidad,
entonces esta clave foránea puede tomar valores nulos. Así en el primer
ejemplo de esta página, si no en todas las ciudades existiesen delegaciones y
optamos por la segunda opción, tendremos en cuenta que nombre-del puede
tomar valores nulos; en este caso nos decantaremos por la primera opción.

Transformación de interrelaciones ternarias

Conectividad M:N:P
La transformación de una relación ternaria siempre da lugar a una
nueva relación, que tendrá como atributos las claves primarias de las tres
entidades interrelacionadas y todos los atributos que tenga la interrelación.
Ahora bien, la clave primaria de la nueva relación depende de la
conectividad de la misma; y por tanto estudiaremos los casos posibles:

 Conectividad M:N:P: En este caso la clave primaria de la nueva

relación está formada por las claves primarias de las tres entidades
interrelacionadas. Por ejemplo, estudiando el caso de la imagen lateral, la
interrelación sería:
ESTUDIANTE (est, …)
ASIGNATURA (asign, …)
SEMESTRE (sem, …)
EVALUACIÓN-SEMESTRAL (est, asign, sem, nota) donde {est} referencia
ESTUDIANTE, {asign} referencia ASIGNATURA y {sem} referencia SEMESTRE
26 · Bases de datos 1

 Conectividad M:N:1: La clave primaria de la nueva relación está formada por Conectividad M:N:1
todos los atributos que forman las claves primarias de las dos entidades de los
lados de la interrelación etiquetados como M y N. Así para el ejemplo lateral
obtenemos como resultado:

MAESTRO (codigo-maestro, …)
CURSO (codigo-curso, …)
ESCUELA (codigo-escuela, …)
DESTINO (codigo-maestro, codigo-curso, codigo-escuela) donde {codigo-
maestro} referencia MAESTRO, {codigo-curso} referencia CURSO y {codigo-
escuela} referencia ESCUELA

 Conectividad N:1:1: La clave primaria la forman la clave primaria de la Conectividad N:1:1

entidad del lado N y los que forman la clave primaria de cualquiera de los dos
lados con conectividad 1. Así para el ejemplo lateral escogemos el siguiente
ejemplo de los dos posibles:

HORA-SEMANAL (codigo-hora, …)
AULA (codigo-aula, …)
ASIGNATURA (asign, …)
CLASE (codigo-hora, codigo-aula, asign, duracion) donde {codigo-hora}
referencia HORA SEMANAL, {codigo-aula} referencia AULA y {asign}
referencia ASIGNATURA

 Conectividad 1:1:1: La clave primaria la forman la clave primaria de dos Conectividad 1:1:1
entidades cualesquiera de las que forman la relación. Por ejemplo en la
interrelación que registra la información de defensas de los proyectos de fin de
carrera, intervienen el estudiante, el proyecto y el tribunal. De las 3 opciones
disponibles, hemos elegido la siguiente:

TRIBUNAL (trib, …)
ESTUDIANTE (est, …)
PROYECTO (proy, …)
DEFENSA (trib, est, proy, fecha-defensa) donde {trib} referencia TRIBUNAL
{EST} referencia ESTUDIANTE y {proy} referencia PROYECTO

Transformación de interrelaciones n-arias

Es una generalización de lo explicado para las ternarias; consistirá pues en

la obtención de una nueva relación que contiene todos los atributos que forman las
claves primarias de las n entidades interrelacionadas y todos los atributos de la
interrelación. Además, si todas las entidades están conectadas con muchos, la clave
primaria de la nueva relación se formará por los atributos de las claves de las n
entidades interrelacionadas; si una o más entidades están conectados con 1,
entonces la nueva clave primaria tendrá n-1 claves interrelacionadas, con la única
condición que la clave no incluida pertenecerá a una conexión 1.

Transformación de interrelaciones recursivas

Las interrelaciones recursivas se tratan igual que el resto de las Conectividad 1:1:1
interrelaciones; por ello si tiene conectividad 1:1 ó 1:N da lugar a una clave
foránea, mientras que si la conectividad es M:N o n-aria, originará una nueva
relación. Así para el ejemplo de la persona y la boda, el resultado puede ser:

PERSONA (codigo-per, codigo-conyuge …) donde {codigo-conyuge} referencia

PERSONA y codigo-conyuge admite valores nulos.
 Bases de datos 1 · 27

Entidades débiles
Transformación de entidades débiles

Se traducen al modelo relacional igual que el resto de entidades, con una

pequeña diferencia; siempre se encuentran en el lado N de una interrelación 1:N
que completa su identificación; así pues la clave foránea debe formar parte de la
clave primaria de la relación correspondiente a la entidad débil. El ejemplo se
transforma tal y como se muestra a continuación:

EDIFICIO (nombre, direccion)

DESPACHO (nombre, numero, superficie)donde {nombre} referencia EDIFICIO

Transformación de la generalización/especialización

Generalización/Especialización En este caso, cada una de las entidades

superclase y subclase se transforman en una
relación:
 La relación de la entidad superclase tiene como
clave primaria la clave de la entidad superclase y
contiene todos los atributos comunes.
 Las relaciones de las entidades subclase tienen
como clave primaria la clave de la entidad superclase
y contienen los atributos específicos de la subclase.

Si retomamos el ejemplo que vimos anteriormente

para la generalización/especialización, se traduciría
así para el modelo relacional:

EMPLEADO (dni, nombre, direccion, telefono)

DIRECTIVO (dni, coche) donde {dni} referencia EMPLEADO
ADMINISTRATIVO (dni, antiguedad) donde {dni} referencia EMPLEADO
TECNICO (dni, titulo) donde {dni} referencia EMPLEADO
PROYECTO {pro, …}
TRABAJA (dni, pro, superficie) donde {dni} referencia TECNICO y {pro}
referencia PROYECTO

Transformación de entidades asociativas

Entidades asociativas Como una entidad asociativa tiene su origen

en una interrelación, la transformación de la
interrelación originaria es, al mismo tiempo, la
transformación de la entidad asociativa.

CIUDAD (nombre-ciudad, …)
VIAJE (id-viaje, …)
RECORRIDO (nombre-ciudad, id-viaje) donde {nombre-
ciudad} referencia CIUDAD e {id-viaje} referencia
VIAJE
CLIENTE (codigo-cliente, …)
REPARTO (nombre-ciudad, id-viaje, codigo-cliente,
paq-car, paq-desc) donde {nombre-ciudad, id-viaje}
referencia RECORRIDO y {codigo-cliente} referencia CLIENTE
28 · Bases de datos 1

Finalmente, se propone una tabla que muestra los aspectos más básicos de
todas las transformaciones estudiadas en este apartado:

Elemento modelo ER Transformación al modelo relacional

Entidad Relación
Interrelación 1:1 Clave foránea
Interrelación 1:N Clave foránea
Interrelación M:N Relación
Interrelación n-aria Relación
 Clave foránea para binarias 1:1 y 1:N
Interrelación recursiva
 Relación para binarias M:N y n-arias
La clave foránea de la interrelación identificadota forma parte de
Entidad débil
la clave primaria
 Relación para la entidad superclase
Generalización/especialización
 Relación para cada una de las entidades subclase
La transformación de la interrelación que la origina es a la vez su
Entidad asociativa
transformación.

Texto elaborado a partir de:

Bases de datos I
Rafael Camps Paré, Xavier Franch Gutiérrez, Carme Martín Escofet, Dolors Costal Costa
Febrero 2004