Bases de Datos Relacionales

ndice
Mdulo A
Unidad didctica 1: Introduccin a las Bases de Datos
Unidad didctica 2: Metodologas de desarrollo de Bases de Datos
3
19
Mdulo B
Unidad didctica 1: Fase de anlisis de requisitos Modelo E/R
Unidad didctica 2: Modelo Relacional
Mdulo C
33
1113
189
Unidad didctica 1: lgebra relacional

Unidad didctica 2: SQL Lenguaje de consulta estructurado
199
MDULO A
UNIDADES DIDCTICAS:
1. Introduccin a las Bases de Datos

2. Metodologas de Desarrollo de Bases de Datos
MDULO A
OBJETIVOS
En esta unidad aprenders:
Introduccin a las Bases de Datos
x
x
x
x
UNIDAD DIDCTICA 1
ndice de la unidad:
1. La Base de Datos como un componente de los

sistemas de informacin
2. Definicin de la Base de Datos
3. Sistema de Gestin de Bases de Datos
4. Arquitectura de Bases de Datos a tres niveles
5. Lenguajes de SGBD
6. Herramientas de SGBD
7. Algunas arquitecturas de Sistemas de Bases de
Datos
Qu es una base de datos y sus principales ventajas

Qu es un sistema gestor de bases de datos y sus principales
funciones
Arquitectura de una base de datos segn los tipos de usuarios
Qu es el lenguaje SQL
Diferencias entre Sistemas centralizados, cliente-servidor, sistemas
paralelos y sistemas distribuidos
El componente que nos interesa en este libro, la Base de Datos, se
1.
encuentra en el software del sistema de informacin. A continuacin, vamos a
La Base de Datos como un componente de los Sistemas de
dar una definicin ms precisa de este componente que desglosaremos en todos
Informacin
sus aspectos. Posteriormente, estudiaremos la necesidad de las Bases de Datos

Desglosando en detalle los componentes de un SI nos encontramos con
en los sistemas de informacin actuales en contraposicin a los sistemas de
cinco grandes componentes:

-
ficheros.
El Contenido, es decir, los datos con su correspondiente descripcin,

almacenados en un soporte de ordenador (por ejemplo, en unos grandes
almacenes se tendran los datos de clientes, ventas, productos, etc.).
Equipo fsico (hardware) formado por la unidad central de proceso y los

equipos perifricos (discos, terminales, impresoras, redes, ...).
Equipo lgico (software) compuesto por los programas, documentacin,

lenguajes de programacin, etc. que debe gestionar los datos (creacin,
consulta,
recuperacin
mantenimiento)
as
como
controlar
las
comunicaciones y dar soporte a tratamientos especficos (por ejemplo,

gestin de personal, facturacin, etc.).
-
El Administrador, encargado de asegurar la calidad de los datos

almacenados
de
permitir
su
uso
correcto
permanente.
El
administrador o administradores debe controlar la disponibilidad, la

confidencialidad y la integridad de los datos. La disponibilidad se refiere
a que los datos deben estar accesibles en todo momento, es decir, que
ante cualquier tipo de catstrofe o fallo, se tengan los mecanismos
adecuados de recuperacin para que el sistema siga funcionando; la
confidencialidad se encarga de no desvelar datos a usuarios no
autorizados y la integridad asegura que los datos no se falseen, es decir,
que sean correctos, vlidos y precisos.
-
Un conjunto de Usuarios formado por las personas que acceden al

sistema de informacin y que pueden ser de dos tipos: informticos
(analistas y programadores encargados de desarrollar las aplicaciones,
bases de datos, etc.) y los usuarios finales con pocos conocimientos de
informtica que requieren consultas y actualizar los datos mediante
interfaces adecuados a sus caractersticas.
partes de la BD y no se controlara: puede ocurrir que si un cliente
2.
cambia de direccin postal y slo se actualiza esta informacin en uno de
Definicin de Base de Datos
los sitios, entonces la BD quedara en estado inconsistente (el cliente

Definicin: Una Base de Datos (BD) es una coleccin o depsito de
aparece
datos integrados, almacenados en soporte secundario (no voltil) y con
Posteriormente, se volver al tema de la redundancia cuando se estudien
redundancia controlada. Los datos, que han de ser compartidos por
los modelos de datos como herramientas de diseo de Bases de Datos.
diferentes usuarios y aplicaciones, deben mantenerse independientes de
con
datos
distintos
en
distintas
partes
de
la
BD).
Por otro lado, las BD han de atender a mltiples usuarios de la organizacin
ellos y su definicin (estructura de la BD), nica y almacenada junto con
(informticos que desarrollan programas de acceso a la BD, administrativos
los datos, se ha de apoyar en un modelo de datos, el cual ha de permitir
usuarios de las aplicaciones, etc.) as como a distintas aplicaciones (por ejemplo,
captar las interrelaciones y restricciones existentes en el mundo real.
aplicaciones de contabilidad, de facturacin, etc., todas ellas accediendo a los
Los procedimientos de actualizacin y recuperacin, comunes y bien
datos contenidos en la BD de la empresa).
determinados, facilitarn la seguridad del conjunto de los datos. De

Esta visin unificada de los datos se contrapone con los sistemas
Miguel et. al (1999)
tradicionales de ficheros. Aunque no entraremos aqu en detalles de en qu

Veamos en qu consiste cada uno de los aspectos mencionados en esta
consisten los sistemas de ficheros que se utilizaban con anterioridad a la
definicin de Base de Datos que no son ms que distintas definiciones segn
aparicin de las BD s indicaremos algunos aspectos relevantes que los
distintas perspectivas.
diferencian de las BD; estos aspectos son:
La Base de Datos es un conjunto de datos relativos a una determinada
Independencia de datos y procesos: es el objetivo fundamental de las
parcela del mundo real (por ejemplo, una biblioteca, una empresa
BD, mantener separados los datos de los tratamientos que los utilizan.
petroqumica, una universidad, etc.,) que se almacenan en un soporte
En los sistemas basados en ficheros cada fichero se diseaba para
informtico no voltil (es decir, dispositivos de memoria secundaria como
responder a las necesidades de una aplicacin determinada y apenas
discos, cintas, etc. que hacen que los datos no desaparezcan "cuando no
podan utilizarse por otra aplicacin. En las BD, los datos se encuentran
se estn usando").
en un nico almacn y son accedidos por todas las aplicaciones.
Adems, no debe existir redundancia (el trmino redundancia es
Descripcin de los datos junto con los datos: la definicin y descripcin2
sinnimo de datos repetidos), es decir, no deben existir duplicidades
del conjunto de datos contenidos en la BD deben ser nicas y estar
perjudiciales ni innecesarias (a ser posible un determinado tipo de dato,
integradas con los mismos datos. Posteriormente se ver que los datos
por ejemplo, los datos de un cliente de una empresa, slo deben
estn interrelacionados y estructurados de acuerdo a un modelo capaz
aparecer en un sitio en la BD). En ocasiones, es necesaria cierta
de recoger el mximo contenido semntico. En los sistemas de ficheros,
redundancia (a nivel de almacenamiento fsico1) que mejora la eficiencia
los datos se encuentran en distintos ficheros diseados expresamente
de la BD, por ejemplo, ante determinados tipos de consultas de datos.
(ad-hoc) para cada tipo de aplicacin, y la descripcin de los datos se
Sin embargo, esta redundancia siempre debe ser controlada por el
encuentra junto con los programas de la aplicacin. Recurdese, por
sistema para que no se produzcan inconsistencias; piense el lector qu
ejemplo, un programa en un lenguaje de programacin en el que al
sucedera si los datos de los clientes de una empresa se repiten en varias
principio del cdigo se define de qu tipo son las variables y las
En secciones posteriores estudiaremos que se habla de tres niveles (conceptual, lgico y fsico) en la
arquitectura de una BD. Por ahora, nos basta saber que el nivel fsico concierne a cmo se almacenan
los datos en los ficheros de la BD.
2 En las siguientes secciones se ver que la descripcin de los datos es lo que se denomina estructura o
esquema de la BD.
estructuras de datos que se van a manejar en el programa que accede a

los ficheros.
-
Procesos
3.
de
actualizacin
recuperacin
recuperacin y actualizacin de los datos se
bien
establecidos:
la
En la seccin anterior se ha estudiado qu es una BD y se ha mencionado
realiza de acuerdo a
alguna de las funcionalidades de un SGBD. En esta seccin nos centraremos en
procesos bien determinados que se incluyen en el Sistema de Gestin de

Bases
de
Datos3
instrumentos
(SGBD).
necesarios
El
para
SGBD
el
tambin
mantenimiento
proporcionar
de
la
Sistemas de Gestin de Bases de Datos
describir en profundidad qu es un SGBD y cul es la funcionalidad que debe
los
proporcionar.
seguridad
(confidencialidad, disponibilidad e integridad) del conjunto de datos.
Definicin: Un Sistema de Gestin de Bases de Datos (SGBD4) es un

conjunto
coordinado
de
programas,
procedimientos,
lenguajes,
herramientas, etc., que suministra, tanto a los usuarios no informticos

como a los analistas, programadores o administradores de una BD, los
medios necesarios para describir y manipular los datos integrados en la
BD, manteniendo su integridad , confidencialidad y disponibilidad.
Miguel et al. (1999).
Aplicacin 1
Aplicacin 2
Aplicacin 3
SGBD
Base de
Datos
Figura 1.1: Sistema de Bases de Datos
En el siguiente apartado se estudiar que es un SGBD. Por ahora, slo decir que el conjunto de
programas y herramientas que nos permite crear, actualizar, manipular y mantener una BD.
4 En ingls, Database Management System (DBMS).

9
10
...
Aplicacin n
De
Se denomina Sistema de Bases de Datos a la unin de una BD, un SGBD

ms las aplicaciones que acceden a la BD. La Figura 1.1 muestra la arquitectura
4.
Arquitectura de BD a tres niveles
de un sistema de BD; en ella se observa que el SGBD hace de interfaz entre los
A continuacin, vamos a definir cul es la arquitectura de una BD segn la
usuarios que acceden a la BD mediante las aplicaciones y la Base de Datos que
visin que de ella tienen los distintos tipos de usuario. En una BD se identifican
contiene toda la informacin.
tres capas de estructuracin segn tres niveles de abstraccin. As, se distingue

Ya hemos mencionado en la seccin anterior que existen distintos tipos de
un nivel externo, un nivel lgico y un nivel fsico.
usuarios (administradores, programadores, usuarios finales) con necesidades

-
diferentes. Para poder dar soporte a estos usuarios el SGBD debe proporcionar
El nivel externo se corresponde con la visin de la BD que cada usuario

tiene en particular. Esto significa que no todos los usuarios necesitar
una serie de funciones que se describen a continuacin:
conocer la BD completa sino que nicamente necesitan una vista parcial

-
Funcin de definicin: permite a los diseadores de la BD describir los
de ella (la que le permita llevar a cabo su trabajo); por ejemplo, un
elementos de datos, su estructura y las relaciones que existen entre
administrativo que trabaje elaborando las nminas de los empleados de
ellos; como se estudiar ms adelante, el SGBD proporciona un lenguaje
una empresa no necesita conocer los datos relativos a las ventas de
para la definicin las tablas, los atributos que la componen, las
productos de esa empresa.
restricciones semnticas as como las caractersticas de tipo fsico o

-
almacenamiento.
El nivel lgico se corresponde con la visin total de la empresa; esta

vista global se interpone entre el nivel externo y el nivel fsico siendo
Funcin de manipulacin: permite a los usuarios de la BD aadir,
independiente tanto del equipo como de cada usuario en particular; por
suprimir o modificar los datos de la misma siempre y cuando se respeten
ejemplo, el administrador de la BD si necesita tener una vista completa
los aspectos de seguridad que haya establecido el administrador de la
de la BD de la empresa para llevar a cabo su trabajo.
BD.
-
Funcin de control: esta funcin ana los interfaces que requieren los
El nivel fsico se corresponde con la vista del soporte fsico informtico

en cuanto a que se refiere a la forma en que se organizan los datos en el
distintos tipos de usuarios para comunicarse con la BD as como las
almacenamiento fsico (ndices o punteros, longitud de los campos,
herramientas necesarias para el administrador para establecer los
caminos de acceso a los datos, particionamientos de memoria, etc.).
mecanismos de seguridad y mantenimiento de la BD.

Para que el SGBD pueda llevar a cabo estas funciones se necesita un
La gestin de estos tres niveles debe estar soportada en cualquier SGBD.
lenguaje que permita especificar lo que cada tipo de usuario necesita en su

comunicacin con la BD. En las BD relacionales se emplea el SQL (Standard
Query Language).
11
12
5.
Lenguajes de un SGBD
6.
Herramientas de un SGBD
De acuerdo a las funciones a las que debe dar soporte un SGBD estudiadas
Aparte de los lenguajes vistos en el apartado 5, los SGBD proporcionan otro
en el apartado 3 y a los distintos niveles de estructuracin de una BD vistos en
tipo de herramientas de gran utilidad en el desarrollo de aplicaciones de Bases
el apartado 4, los SGBD deben proporcionar un lenguaje para que los distintos
de Datos. Entre otras, existen:
tipos de usuario puedan comunicarse con la BD. As, en los SGBD relacionales se
tiene el lenguaje SQL que de acuerdo a su funcin se descompone en:

-
diseo
implementacin
de
BD
que
generalmente
incluyen
diagramadores para esquemas conceptuales y lgicos de bases de datos,
estructura lgica de la BD (nivel lgico), la estructuras externas
generadores de cdigo SQL, etc.

-
externo) as como la estructura interna (nivel fsico).
generadores de informes y pantallas que facilitan la presentacin de los

datos recuperados de la BD.
Lenguaje de Manipulacin de Datos (LMD): una vez se ha descrito la BD,
sta ya est preparada para cargar los datos en las estructuras definidas
generadores de aplicaciones basados en lenguajes de cuarta generacin

(4GL) que permiten a los usuarios desarrollar aplicaciones sin tener que
y para su utilizacin. As, el LMD permite aadir, suprimir, modificar y
programar en lenguajes convencionales
buscar datos en la BD. Es el SGBD el que se encarga de acceder al

correspondiente soporte fsico para localizar los datos con los que se
harn las operaciones especificadas.

-
Lenguaje de Definicin de Datos (LDD): utilizado para definir la
requeridas para el desarrollo de las diferentes aplicaciones (nivel
herramientas de ayuda al desarrollo (CASE5) en las fases de anlisis,
facilidades de usuario para facilitar la consulta de los datos (mens,

interfaces grficas, etc.).
Lenguaje de Control: el administrador de la BD utiliza este lenguaje para

especificar los aspectos de seguridad fsica (copias de seguridad,
rearranque de la BD en caso de cada, etc.) as como de proteccin
frente a accesos no permitidos (autorizaciones y contraseas, perfiles de
usuarios, etc.). El lenguaje de control tambin se requiere para definir
los interfaces que necesitan los distintos usuarios para comunicarse con
la BD.
5 Computer Aided Software Engineering

13
14
interfaz grfica. Los sistemas servidores satisfacen las peticiones generadas por
7.
los sistemas clientes.
Algunas arquitecturas de Sistemas de Bases de Datos
Se distinguen dos tipos de servidores:
En este apartado revisaremos brevemente algunos conceptos relacionados

con las distintas arquitecturas de Sistemas de BD. En una arquitectura se
reflejan aspectos como la conexin en red, el paralelismo y la distribucin:
Servidores de transacciones (servidores de consultas) con un interfaz

mediante el que los clientes envan peticiones para realizar una accin
que el servidor ejecutar y cuyos resultados se devuelven al cliente.
Red: permite que algunas tareas se ejecuten en un sistema servidor y

que otras se ejecuten en los clientes (son lo que se denominan sistemas
en las que se realiza el procesamiento enviando despus los datos de
de BD cliente-servidor).
vuelta).
Paralelismo: acelerar la ejecucin de tareas (transacciones, etc.) de

acuerdo al sistema informtico subyacente (sistemas de BD paralelos).
Servidores de datos (el servidor enva los datos a las mquinas clientes
Respecto a los sistemas paralelos representan una solucin al manejo de BD

muy grandes o con un gran volumen de transacciones por segundo. El objetivo
Distribucin: Datos situados donde se han generado o donde son ms
es realizar operaciones simultneamente mediante el uso de varios procesadores
necesarios pero accesibles desde todos los sitios (sistemas de BD
y varios discos en paralelo. Los modelos de arquitecturas para mquinas
distribuidos).
paralelas son:
Segn estos aspectos distinguimos sistemas centralizados, sistemas cliente-
servidor, sistemas paralelos y sistemas distribuidos.
Memoria compartida: Todos los procesadores comparten una memoria

comn.
En los sistemas centralizados existe un nico sistema informtico sin

-
interaccin con otros ordenadores. En estos sistemas podemos diferenciar entre:
Disco compartido: Los procesadores comparten un disco comn (cada

procesador con su memoria)
Sistema monousuario formado por un ordenador personal o por una

estacin de trabajo con una nica CPU y un sistema operativo
monousuario
(no
permite
que
varios
usuarios
puedan
acceder
Sin compartimiento: No hay comparticin ni de disco ni de memoria
Jerrquico: modelo hbrido de los anteriores.
simultneamente a la BD)
-
Sistema multiusuario formado por varias CPU y con sistema operativo

Por ltimo, en los sistemas distribuidos la BD se almacena en varios
multiusuario con terminales conectados al sistema servidor; estos
ordenadores que no comparten ni memoria ni discos pero que se comunican
terminales no poseen ninguna funcionalidad propia aparte de la de
mediante redes de alta velocidad o lneas telefnicas. Estos ordenadores se
visualizar el resultado de los procesos que se ejecutan en el servidor.
encuentran en varios lugares geogrficos distintos. En un sistema distribuido se

En los sistemas cliente-servidor existe un reparto de funcionalidades, es
dan dos tipos de transacciones:
decir, los terminales se sustituyen por ordenadores personales que gestionan el

interfaz de usuario SQL, interfaz de formularios, diseadores de informes e
15
16
Transacciones locales: Acceso a datos del ordenador en el que se inici la

transaccin
Transacciones globales: Acceso a datos de un ordenador distinto o

acceso a datos de varios ordenadores distintos.
Una Base de Datos (BD) es una coleccin o depsito de datos
integrados, almacenados en soporte secundario (no voltil) y con
Las ventajas que proporcionan los sistemas distribuidos frente a los sistemas
redundancia controlada. Las ventajas que presentan son las siguientes:
centralizados son la comparticin de datos (acceso a datos en distintos sitios),

por ejemplo,
dos sucursales bancarias pueden compartir datos entre s;
- Independencia de datos y procesos:

- Descripcin de los datos junto con los datos
- Procesos de actualizacin y recuperacin bien establecidos
la
autonoma en cuanto a que cada administrador controla su BD y, por ltimo, la

disponibilidad de los datos pues si un ordenador falla,
En una BD se identifican tres capas de estructuracin segn tres
estn los dems para
niveles de abstraccin.
poder seguir trabajando, en particular, si hay duplicacin de datos.
- El nivel externo
- El nivel lgico
- El nivel fsico
Un Sistema de Gestin de Bases de Datos (SGBD) es un conjunto
coordinado de programas, procedimientos, lenguajes, herramientas, etc.,
que suministra, tanto a los usuarios no informticos como a los analistas,
programadores o administradores de una BD, los medios necesarios para
describir y manipular los datos integrados en la BD, manteniendo su
integridad , confidencialidad y disponibilidad. Sus principales funciones son
las de definicin, manipulacin y control.
En una arquitectura de bases de datos se reflejan aspectos como la
conexin en red, el paralelismo y la distribucin. Segn estos aspectos
distinguimos sistemas centralizados, sistemas cliente-servidor, sistemas
paralelos y sistemas distribuidos.
Sistemas Centralizados
Monousuario
Multiusuario
Sistemas Cliente-Servidor
Servidores de transacciones
Servidores de datos
Sistemas paralelos
Memoria Compartida - Disco

Compartido
Sin compartimiento - Jerrquico
Sistemas distribudos
17
18
Transacciones Locales
MDULO A
OBJETIVOS
Metodologas de Desarrollo
de Bases de Datos
UNIDAD DIDCTICA 2
ndice de la unidad:
1. Qu es una metodologa y para qu sirve

2. Modelos de datos como instrumentos de diseo
de Bases de Datos
3. Una metodologa de desarrollo de BD
3.1
Modelado Conceptual
3.2
Transformacin de esquemas
conceptuales E/R a esquemas
relacionales
3.3
Diseo fsico
x
x
x
Qu es metodologa
En qu consiste el diseo de una base de datos
Descripcin de una metodologa propia de diseo de una base de
datos, basada en la construccin de esquemas E/R, creacin del
modelo relacional y posterior optimizacin de la base de datos.
Metodologas de Desarrollo de Bases de Datos
SOPORTE
CASE
Automatizadas
TCNICAS
1. Qu es una metodologa y para qu sirve
Incorporadas
Deficin: Una metodologa es un conjunto de procedimientos, tcnicas

y ayudas
Se apoyan en
METODOLOGA
a la documentacin para el desarrollo de un producto
software.", Amescua et al. (1995); en el caso que nos ocupa en este

libro, el producto software es una Base de Datos
MODELOS
Figura 1.2: Relacin entre los componentes de una metodologa
Una metodologa nos indica las actividades a seguir en el desarrollo de

principio a fin de la Base de Datos, qu es lo que hay que realizar en cada
actividad indicando qu se necesita como entrada, qu se produce como salida e
Por ltimo, las herramientas CASE permiten dar soporte automatizado a la
incluso quin est involucrado. Por lo tanto, es como un libro de recetas de
aplicacin de las tcnicas de una metodologa as como a los modelos que
cocina en el que se va indicando paso a paso todas las actividades a realizar
incorporan. Los entornos CASE no solo deben automatizar las tcnicas aisladas
para lograr la Base de Datos deseada.
correspondientes a una metodologa sino tambin dar soporte a toda la

metodologa
Como muestra la Figura 1.2, una metodologa se apoya en los siguientes
de
desarrollo
mediante
la
incorporacin
de
un
conductor
elementos: tcnicas, modelos y soporte CASE. Veamos en qu consiste cada uno
metodolgico que ayude al analista, diseador o programador a desarrollar su
de estos elementos.
labor en cada actividad definida en la metodologa.

Todos estos conceptos se estudiaran particularizados para una metodologa
Las tcnicas representan cmo llevar a cabo cada una de las actividades o
de BD en las siguientes secciones.
pasos de los que consta la metodologa, es decir, proporcionan procedimientos

para llevar a cabo cada tarea; en ocasiones estas tcnicas son procedimentales
(secuencia perfectamente definida de los pasos a realizar en una tarea como en
un algoritmo) y en otros casos son heursticas (reglas, recomendaciones o
sugerencias a seguir que en ningn caso establecen el proceso exacto de
realizacin de una tarea; generalmente se utilizan en tareas con un alto
componente creativo).
Los modelos son los instrumentos que empleamos para representar una
determinada realidad (generalmente tienen una notacin grfica que facilita su
comprensin y validacin); se utilizan en las tcnicas para soportar la actividad
que llevan a cabo. En el siguiente apartado se estudiarn los modelos de datos
involucrados en el diseo de una BD
21
22
determinada realidad (estos elementos varan de un modelo a otro
2. Modelos de datos como instrumentos de diseo de Bases de
segn su riqueza semntica).
Datos
- Elementos no permitidos: Son las restricciones que representan las

limitaciones impuestas a la estructura del modelo o a los datos que
El diseo de BD consiste en describir la estructura de la BD de forma que se
invalidan ciertos ejemplares de la BD. Las restricciones son de dos
represente fielmente la parcela del mundo real1 que se quiere almacenar. Ello se
tipos:
realiza mediante un proceso de abstraccin (que se denomina modelado) que se

apoya en un modelo de datos. Un modelo de datos es el instrumento que se
i. Restricciones inherentes: son las limitaciones impuestas a
aplica a un UD para obtener una estructura de datos que se denomina esquema
las estructuras del modelo (reglas impuestas para la
de la BD (Figura 1.3).
utilizacin y combinacin de los distintos constructores del

modelo).
ii. Restricciones
Mundo
Real
semnticas
(o
de
usuario):
son
las
restricciones que se deducen de los supuestos semnticos

explcitos o implcitos o derivados de nuestro conocimiento
Modelo
de Datos
del mundo real que se quiere reflejar en la BD (por

ejemplo,
"todo
empleado
debe
pertenecer
un
departamento", "el sueldo de un determinado empleado
Esquema
(Estructura
de Datos)
siempre ser inferior al sueldo de su jefe", etc.).

B. Dinmica: Formada por un conjunto de operadores que permiten
manipular
Figura 1.3: Aplicacin de un Modelo de Datos
los
datos
que
estn
reflejados
en
el
Lenguaje
de
Manipulacin de Datos. Como se estudiar despus, esta parte dinmica

no tiene sentido para todos los modelos de datos.
Un modelo de datos proporciona un conjunto de conceptos, reglas y
Adems, cada modelo de datos tiene una representacin grfica que suele
convenciones que nos permiten especificar y manipular los datos que queremos
ser en forma de grafos o tablas.
almacenar en la BD. Todo modelo de datos se compone de una parte esttica y

una parte dinmica como se explica a continuacin.
A lo largo del desarrollo de una BD se utilizan varios modelos de datos que
A. Esttica: Conjunto de estructuras (tambin denominados constructores
nos permiten representar la realidad segn las distintas fases de una
del modelo) que permiten definir los datos y sus restricciones asociadas
metodologa y segn distintos niveles de abstraccin. Aunque los siguientes
especificados segn un Lenguaje de Definicin de Datos (apartado 5 del
captulos se dedicarn al estudio pormenorizado de cada uno de los modelos, la
tema anterior). Esta parte esttica consta de elementos permitidos y
Tabla 1 muestra la parte esttica y dinmica del Modelo Entidad/Interpelacin
elementos no permitidos:
(E/R) para modelado conceptual y el Modelo Relacional para diseo lgico de BD.
- Elementos permitidos: son los objetos, asociaciones entre objetos,

propiedades, etc. que proporciona el modelo para representar una
En el mbito de las Bases de Datos se denomina Universo del Discurso (UD)

23
24
Modelo E/R
Modelo Relacional
Elementos
permitidos
Entidades, atributos, interrelaciones, jerarquas,

dominios
Restricciones
inherentes
Obligatoriedad de Identificador Principal de Entidad. No existen interrelaciones entre interrelaciones.

-
Dinmica
Representacin -
Restricciones sobre atributos: identificador principal,

identificador alternativo, simples/compuestos,
univaluados/multivaluados, obligatorios/opcionales y
atributos derivados.
Restricciones sobre interrelaciones: restricciones de
No existen grupos repetitivos.

Regla de integridad de entidad.
Definicin de clave primaria.
Restriccin de unicidad.
Restriccin de obligatoriedad.
Integridad referencial (clave ajena).
Restricciones de verificacin.
3. Una Metodologa de desarrollo de Bases de Datos
Obligatoriedad de clave primaria.

Orden de tuplas y atributos no es
significativo.
Restricciones
semnticas
Relacin, atributos, dominios
Aunque existen distintas metodologas para el desarrollo de BD, Elsmari y

Navathe (1997), en este libro se seguir la propuesta en De Miguel et al. (1999)
que cubre las fases de diseo conceptual, diseo lgico estndar y diseo lgico
especfico. La figura que se presenta a continuacin muestra las fases de esta
metodologa con los modelos que se aplican en cada una de ellas. Aunque el uso
de esquemas conceptuales facilita el diseo de BD no siempre la fase de
modelado conceptual se lleva a cabo. La parte derecha de la Figura muestra la
metodologa completa de diseo de BD mientras que la parte izquierda muestra
cardinalidad, tipo de correspondencia, dependencia

en existencia, dependencia en identificacin,
interrelaciones exclusivas
Restricciones sobre jerarquas:
exclusividad/solapamiento, totalidad/parcialidad
el diseo de BD partiendo del diseo relacional de una BD.
No es de inters puesto que es un modelo abstracto no implementable
Lenguaje SQL-92.
Grafos
Grafos y tablas.
MUNDO REAL
OBJETOS CON SUS SUCESOS,
PROPIEDADES,
ASOCIACIONES Y
RESTRICCIONES SEMNTICAS
Modelado Conceptual
ESQUEMA
CONCEPTUAL
MODELO
E/R
Transformacin
al modelo lgico estndar
MODELO
RELACIONAL
(SQL-92)
ESQUEMA
LGICO
ESTNDAR
MODELO
RELACIONAL
(SQL-92)
Transformacin
al modelo lgico especfico
MODELO
RELACIONAL
(SGBD)
MODELO
INTERNO
(SGBD)
ESQUEMA
LGICO
ESPECFICO
MODELO
RELACIONAL
(SGBD)
ESQUEMA
INTERNO
MODELO
INTERNO
(SGBD)
Veamos a continuacin en qu consiste cada una de estas fases:

25
26
3. 1 Modelado Conceptual
3.2 Transformacin de esquemas conceptuales E/R a esquemas

relacionales
Consiste en la representacin del UD (parte del mundo real que se quiere

almacenar
los
Una vez se ha validado con el usuario el esquema E/R correspondiente a la
constructores del modelo E/R se recoge toda la semntica que puede
en
la
BD)
en
BD ya es posible realizar la transformacin a un esquema lgico, en nuestro
obtenerse mediante la observacin del UD o bien a partir de unas
caso, a un esquema relacional. Para este paso si que existe un procedimiento
especificaciones
la
exhaustivo a seguir con el fin de traducir todos los constructores del modelo
informacin que debe contener la BD. En este libro se construirn esquemas
E/R a constructores del modelo Relacional. En un primer paso, se hace una
conceptuales de BD a partir de esquemas descriptivos.
transformacin al modelo relacional estndar (SQL-92). El modelo relacional
textuales
esquemas
(esquemas
conceptuales
descriptivos)
E/R.
que
Mediante
describan
estndar no es directamente implementable en un SGBD relacional pues cada
Esta primera fase de anlisis tiene como objetivo poder validar con el
SGBD implementa de manera libre un subconjunto de este estndar. Es en la
usuario (persona o conjunto de personas que nos encargan una BD para
fase de transformacin a un modelo lgico especfico (es decir, el propio de
cubrir sus necesidades de negocio) la informacin que contendr la BD. Por
cada SGBD comercial3) cuando ya se habla de BD directamente trasladables a
ello, los esquemas E/R son los de mayor nivel de abstraccin (capacidad para
un producto comercial.
ocultar los detalles y fijarse en lo esencial), con constructores muy naturales

(estructuras muy cercanas al usuario y fcilmente comprensibles por personas
no informticas). Ntese que los esquemas conceptuales no son directamente
3.3 Diseo Fsico
implementables en un ordenador; por ello, no tienen ninguna connotacin

fsica y pueden traducirse a cualquier modelo lgico2. El esquema E/R viene a
En esta fase se tienen en cuenta aspectos relacionados con la carga de la
ser para una BD como los planos de un arquitecto son imprescindibles para
BD, la optimizacin de consultas y otros aspectos relacionados con la
una casa: algo necesario a priori en la construccin de una BD. Sin estos
eficiencia en el almacenamiento y funcionamiento de la BD y que son
planos
realizadas por el administrador de la BD a travs de las utilidades que
es
imposible
conocer
cules
son
los
requisitos
que
debern
contemplarse en la BD.
proporciona el SGBD que se vaya a utilizar.
La construccin de esquemas E/R es una labor creativa que se realiza en
Como se observa en la parte izquierda de la Figura, tambin es posible
sucesivos pasos de refinamiento; consecuentemente, no todos los analistas
realizar el diseo de la BD directamente en el modelo relacional sin llevar a
obtendrn el mismo esquema E/R cuando modelan una determinada realidad
cabo previamente la fase de modelado conceptual. En este caso, el diseador
pues depender de la labor intelectual que lleve a cabo cada uno en su visin
plasmar directamente en un esquema relacional la semntica del mundo real
del UD. Sin embargo, si es posible seguir una serie de heursticas o
que debe quedar recogida en la BD.
recomendaciones de gran utilidad cuando se modela una BD. En el captulo

dedicado al modelo E/R se estudiarn estas heursticas en detalle.
Por ejemplo, Oracle, Access, SQL-Server, Informix, etc. son SGBD comerciales que no implementan de igual manera
el modelo relacional.
2 Aunque en este libro slo se estudia el modelo relacional como modelo para Diseo Lgico de BD
existen otros modelos (jerrquico, en red, etc.).
27
28
Una metodologa es un conjunto de procedimientos, tcnicas y ayudas

a la documentacin para el desarrollo de un producto software.
Un modelo de datos es el instrumento que se aplica a un Universo de

Discurso para obtener una estructura de datos que se denomina esquema
de la BD
Una metodologa de bases de datos consta de tres partes

fundamentales:
Modelado Conceptual a travs del Modelo Entidad-Relacin
Transformacin de esquemas conceptuales E/R a esquemas
Diseo Fsico. Eficiencia en el almacenamiento y
relacionales
funcionamiento de la base de datos
29
30
MDULO B
UNIDADES DIDCTICAS:
1. Fase de Anlisis de Requisitos: Modelo Entidad

Interrelacin (E/R)
2. Modelo Relacional
MDULO B
OBJETIVOS
Fase de Anlisis de Requisitos:

Modelo E/R
UNIDAD DIDCTICA 1
ndice de la unidad:
1. Introduccin
2. Elementos Bsicos del Modelo Entidad/Relacin
3. Extensiones del Modelo Entidad/Relacin
4. Diseo Caso Prctico Mentor
5. Diseo Caso Prctico Historia
6. Diseo Caso Prctico Constructora
7. Diseo Caso Prctico Arte
x
x
x
Qu es el modelo Entidad/Relacin
Cules son los elementos bsicos del modelo Entidad/Relacin y su
representacin grfica.
Cules son los pasos para obtener el Modelo Entidad/Relacin a partir
de los requisitos previos.
Fase de Anlisis de Requisitos : Modelo E/R
1.
conocimiento del mundo real que se desea representar a travs de un anlisis de
Introduccin
los requisitos o especificaciones del problema.
Los datos constituyen en la actualidad el arma ms poderosa de cualquier
En la realizacin del esquema o diseo conceptual de cualquier base de
organizacin o empresa. Una buena gestin de los datos puede influir de manera
datos es fundamental el conocimiento del problema a modelar y es en este
ms que notable en los beneficios de cualquier organizacin. Pongmonos en el
conocimiento donde representan un papel primordial los usuarios finales del
caso de una entidad bancaria y pensemos en los miles de clientes con cuyos
sistema, pues es en esta primera etapa de modelizacin en la que el diseador
datos se realizan operaciones diarias; la mala utilizacin de los mismos puede
de la base de datos debe hacer tantas entrevistas como sean necesarias con los
traer consigo prdidas enormes para la empresa. En ocasiones esta mala
usuarios para conseguir clarificar todas las especificaciones del problema. Una
utilizacin puede ser debida a la falta de formacin de los empleados, pero
vez clarificados los objetivos y las necesidades se deber pasar al diseo
muchas veces es ocasionada por un mal diseo del sistema de informacin o
propiamente dicho de la base de datos.
base de datos que gestiona los datos.

El modelo E/R, como todos los modelos, consiste en un conjunto de
Hoy en da todas las empresas cuentan con herramientas informticas de
conceptos, reglas y notaciones que permiten formalizar la semntica del mundo
creacin de bases de datos; entonces, por qu se producen fallos?. La
real que se pretende modelar (tambin denominada Universo del Discurso) en
respuesta no est en las herramientas en s, sino, y reincidiendo en el tema, en

cmo se
una representacin grfica o diagrama que denominamos esquema de la Base de
disea la base de datos. Cada herramienta dispone de sus propios
Datos.
utensilios de diseo, pero todos ellos se basan en los mismos conceptos tericos,
En este captulo se explican cules son los elementos bsicos que componen
conceptos que si se desconocen no pueden ser aplicados.
el modelo E/R y cmo se utilizan a la hora de disear una Base de Datos.

Por lo dicho anteriormente parece, si no completamente necesario, s al
menos muy conveniente, la utilizacin de un modelo de datos que permita
Aunque, como ya se coment anteriormente, todo modelo de datos tiene
disear bases de datos a nivel conceptual (y por tanto muy cercana al usuario) y
una parte esttica y otra dinmica; en este captulo nicamente nos referiremos
por supuesto la formacin de personal cualificado en este campo.
a la esttica del modelo E/R, pues la parte dinmica carece de utilidad al no ser
soportada por ningn SGBD actual.
El modelo Entidad/Interrelacin (E/R) es un modelo conceptual que ha

demostrado ser muy vlido para cumplir con este objetivo, pues est a un nivel
de abstraccin lo suficientemente elevado como para poder disear cualquier
base de datos con independencia de la mquina en la que se implemente.
Adems, en la actualidad disponemos en el mercado de una amplia gama de
herramientas que automatizan en gran parte las tareas del diseo1 y que toman
como base este modelo de datos.
El modelo E/R fue propuesto por Peter Chen en 1976. Desde entonces
muchos autores se han interesado por l, estudindolo y amplindolo,
consiguiendo
as
diversas
variantes
del
modelo
(distintas
formas
de
representacin de los objetos), pero todas ellas parten del mismo concepto: el
Herramientas CASE (Computer Aided Software Engineering).

35
36
Supongamos que de cada alumno queremos la informacin referente a su
2. Elementos bsicos del Modelo E/R
D.N.I., Nombre, Direccin, Telfono y Nacionalidad. En la figura 2.2, aparece

Los elementos u objetos bsicos del modelo E/R son cuatro: entidades,
interrelaciones,
cmo representamos los atributos en el modelo E/R.
atributos y dominios. A continuacin se explican cada uno de
ellos.
2. 1 Entidades
Las entidades, tambin llamadas tipos de entidad, representan conjuntos
D.N.I.
de elementos con existencia propia y que se caracterizan por las mismas
Nombre Direccin
propiedades. Generalmente son personas, cosas, lugares,..., es decir,
Telfono
conceptos sobre los que necesitamos guardar informacin y distinguibles de
ALUMNO
los dems objetos. Su representacin grfica se hace por medio de un
Nacionalidad
rectngulo dentro del cual se escribe el nombre de la entidad en maysculas

Figura 2.2: Un ejemplo de entidad con sus atributos
(generalmente un sustantivo).
Por ejemplo, si queremos disear una base de datos para gestionar todos
Los ejemplares, tambin denominados ejemplares o elementos, de un tipo
los alumnos de los cursos Mentor, entre los tipos de entidad que deberamos
de entidad se definen como los valores correspondientes a los atributos que
definir estaran ALUMNO y CURSO. El primero representara el conjunto de
hemos definido para ella.
todos los alumnos que se inscriben en los diferentes cursos, el segundo
Por ejemplo dos ejemplares del tipo de entidad ALUMNO seran:
recogera todos los cursos ofertados por el aula Mentor. Su representacin

(DNI, 7515958), (Nombre, Juan), (Direccin, C/ Irn, n 9 Madrid),
grfica sera (vase el esquema de la figura 2.1).
(Telfono, 91-675-65-65), (Nacionalidad, Espaola)

(DNI, 7077777), (Nombre, Ana),(Direccin, C/ Bailn, n 9, Madrid),
(Telfono, 91-678-98-99), (Nacionalidad, Espaola)
ALUMNO
CURSO
Por lo tanto los valores de los atributos constituyen una parte importante
de los datos que almacenaremos posteriormente en la Base de Datos. Es
Figura 2.1: Dos ejemplos de entidades
importante destacar que un mismo concepto no tiene por qu representarse

siempre de la misma forma (por ejemplo, como una entidad o como un
2. 2 Atributos
atributo). As, si estuviramos modelando una Base de Datos para una tienda
Todo tipo de entidad tiene unas caractersticas o cualidades propias que
de ropa, probablemente tendramos una entidad denominada PRENDA y uno
queremos recoger dentro de nuestro diseo. El modelo E/R define estas
de sus atributos podra ser Color (roja, negra, etc.). Sin embargo, si
cualidades como atributos, as por ejemplo el nombre del alumno, el telfono,
estuviramos hablando de una Base de Datos para gestionar la informacin
etc., describen propiedades de cada uno de los miembros que pertenecen al
de un taller de vehculos dedicado a trabajos de chapa y pintura, el concepto
tipo de entidad ALUMNO. Estas propiedades no tienen existencia propia, es
de color puede tener tal importancia que pase a ser una entidad COLOR, pues
decir, slo tienen sentido en el esquema de la Base de Datos en tanto en
tiene existencia propia y un conjunto de propiedades (cdigo de color,
cuanto aparecen formando parte de una entidad o, como veremos ms
textura, tipo de mezcla, etc.).
adelante, de otro de los elementos del modelo E/R, de una interrelacin.

37
38
Tipos de atributos
En el ejemplo de la figura 2.3, el atributo Telfono aparece representado

con una lnea de puntos lo que significa que estamos ante un Atributo
Como se puede observar en la figura 2.2 no todos los atributos se
Opcional que nos informa de que existen alumnos que puede que no tengan
representan de la misma forma; ello significa que existen diversas formas de
nmero de telfono o que al fin y al cabo es un atributo cuyo valor no es
recoger restricciones semnticas sobre los atributos de una entidad o de una
demasiado importante y por eso no lo ponemos como obligatorio. Por tanto,
interrelacin. En el ejemplo aparece el atributo D.N.I. con un crculo negro,

este tipo de atributo se denomina
cuando los valores de un atributo van a ser desconocidos o por alguna otra
identificador principal (IP) y lo que
causa no van a tener valor se denominan Atributos Opcionales.
indica es que el atributo o propiedad DNI es nico para cada ejemplar del tipo
Supongamos que para el tipo de entidad CURSO es importante recoger las
entidad ALUMNO.
siguientes propiedades: nombre, libro de consulta y direccin Web. De estas

Para poder distinguir una ejemplar de otra, dentro de un mismo tipo de
tres caractersticas de CURSO elegiremos como identificador principal el
entidad, el modelo E/R obliga a que cada vez que definimos un tipo de
nombre, ya que cada curso tiene un nombre distinto, la direccin Web sera
entidad se defina un atributo que identifique cada ejemplar, es decir, un IP.
un identificador alternativo porque toma valores nicos para cada curso y
Por lo tanto en todos los tipos de entidad tiene que aparecer de forma
libro de consulta sera un atributo opcional ya que permitimos que haya
obligatoria una caracterstica que identifique de forma nica cada uno de los
cursos que no tengan o que desconozcamos su libro de referencia. La entidad
ejemplares.
CURSO con sus atributos queda representada en la figura 2.4.
Esta es la representacin que nos proporciona el modelo E/R para

distinguir este tipo de atributo del resto de atributos que componen el tipo de
entidad. En un tipo de entidad slo puede aparecer un
Nombre
Libro de
consulta
Direccin Web
identificador
principal, pero pueden existir distintos atributos que tambin identifiquen los
CURSO
ejemplares de esta; este tipo de atributos se denominan Identificadores

Alternativos (IA).
Figura 2.4: Un ejemplo de atributos IP, IA y opcional
Veamos un ejemplo, supongamos que queremos aadir para el tipo de
Existen otras formas de recoger restricciones semnticas sobre los
entidad ALUMNO, la direccin de correo electrnico que este posee, sabiendo
atributos que se estudiarn en el captulo siguiente, en donde ampliaremos
que es nica para cada uno de los alumnos. El atributo e-mail sera un
estos conceptos.
identificador alternativo y como vemos en la figura 2.3 se representa con un

Dominios
crculo mitad negro mitad blanco, indicando que su valor es nico para cada
ejemplar del tipo de entidad ALUMNO.
Supongamos que el atributo nacionalidad, vase figura 2.5, slo puede

tomar los valores espaola o extranjera. Para los conjuntos de valores
sobre los que se definen los atributos utilizaremos un objeto del modelo E/R
denominado Dominio. Un dominio se define por un nombre y un conjunto de
D.N.I.
Nombre Direccin
e-mail
valores. En nuestro ejemplo vase la definicin del dominio Nacionalidad en la

figura 2.6 resaltado en color azul y cursiva.
Telfono
ALUMNO
Nacionalidad
Figura 2.3: La entidad ALUMNO y sus atributos
39
40
estn relacionadas con sus clientes, las editoriales se relacionan con los
D.N.I. Nombre Direccin
e-mail
libros que publican, los tutores de los cursos Mentor tienen asignados una
serie de alumnos, etc.
Telfono
Grficamente las interrelaciones se representan mediante un rombo unido
ALUMNO
a los tipos de entidad mediante lneas; dentro del rombo se escribe el nombre
Nacionalidad
de la interrelacin en minsculas, que en general, suele coincidir con un verbo
El atributo Nacionalidad toma valores del

dominio Nacionalidad = (Espaola, Extranjera)
en infinitivo.
Volviendo al ejemplo anterior veamos como se representa la relacin
Figura 2.6: Dominio Nacionalidad y su representacin textual
existente entre los alumnos que realizan cursos. Podramos definir una
interrelacin Realizar entre ambas entidades, como muestra la figura 2.7.

e-mail
ALUMNO
CURSO
Realizar
Telfono
ALUMNO
Figura 2.7: Ejemplo de Interrelacin
Nacionalidad
Nacionalidad
Nacionalidad
No todas las relaciones o asociaciones son iguales, en general se dividen
= (Espaola, Extranjera)
en relaciones que denominamos de uno a muchos, como por ejemplo la que

presentamos a continuacin: una sucursal es nicamente de una entidad
Figura 2.5: Dominio Nacionalidad
bancaria (uno) pero una entidad bancaria posee varias sucursales (muchos).
Tambin existen las relaciones muchos a muchos, como por ejemplo un
curso Mentor tiene asociados tutores (muchos) y los tutores pueden tutorar
distintos cursos Mentor (muchos).
En general los dominios no se suelen representar en el modelo por

problemas de espacio, pero para tener constancia de los valores que puede
Para
tomar un atributo se suele anotar despus de la representacin grfica una
poder
recoger
estas
caractersticas
que
nos
distinguen
unas
relaciones de otras, que nos permite, adems, recoger ms informacin
representacin textual.
acerca del problema que estamos modelando, vamos a introducir los

siguientes propiedades de una interrelacin: grado, tipo de correspondencia y
2. 3 Interrelaciones
cardinalidad.
Las interrelaciones representan asociaciones del mundo real entre una o
El grado de una interrelacin es el nmero de entidades que intervienen en
ms entidades. Por ejemplo, en la figura 2.1 presentbamos los alumnos y los
ella, debe ser como mnimo dos, es decir, el nmero de entidades que
cursos del Mentor como entidades sin ningn tipo de relacin, pero para poder
intervienen en una interrelacin debe ser de al menos dos; existe un caso
expresar que un alumno esta matriculado en distintos cursos y que en un
especial en el que slo participa una entidad en la interrelacin aunque de dos
curso se pueden matricular alumnos necesitamos una Interrelacin que nos
formas distintas (es lo que se denomina interrelacin reflexiva, como se ver
muestre la asociacin existente entre ellos. Por lo tanto, vemos la necesidad
despus). En el ejemplo de la figura 2.7 se representa una interrelacin
de poder representar este concepto ya que aparece continuamente en el
binaria, denominada as por tratarse de una interrelacin entre dos tipos de
mundo real; algunos ejemplos son: las sucursales de una entidad bancaria
41
42
entidad. De la misma forma, cuando el grado es tres se habla de
La cardinalidad de un tipo de entidad que interviene en una interrelacin
interrelaciones ternarias y, en general, de interrelaciones n-arias cuando el
binaria se define como el nmero mnimo y el nmero mximo de ejemplares
grado es n. El tipo de interrelaciones que aparece de forma habitual en el
de un tipo que pueden relacionarse con un elemento de otro tipo de entidad.
modelado de una Base de Datos es la interrelacin binaria y a partir de ahora
Para representar las cardinalidades utilizamos un par (x, y) situado sobre la
nos centraremos solo en este tipo de interrelaciones.
lnea que une el tipo de entidad con la interrelacin, donde x indica el nmero
mnimo e y el nmero mximo. Adems, y cuando la cardinalidad mxima es
El Tipo de correspondencia de una interrelacin binaria se define como el
n, se dibuja una punta de flecha hacia la entidad correspondiente (figura 2.8).
nmero mximo de ejemplares de un tipo de entidad que pueden estar
En el ejemplo que nos ocupa y suponiendo que no se establece ninguna
asociados con un ejemplar del otro tipo de entidad. Su representacin grfica
restriccin adicional, el nmero mnimo de alumnos que pueden matricularse
se hace por medio de un par X:Y colocado sobre el rombo de la interrelacin,
en un curso es uno (no tendra sentido un curso con 0 matriculados), y el
donde X e Y representan los ejemplares asociadas de los tipos de entidad en
nmero mximo n (nmero ilimitado), por tanto la cardinalidad del tipo de
estudio2. En nuestro ejemplo, en principio, el nmero de cursos a los que un
entidad ALUMNO es (1,n) como se muestra en la figura 2.10.
alumno puede optar es ilimitado y el de alumnos que realizan un curso

tambin, por tanto la correspondencia sera N:M o muchos a muchos (Figura
2.8).
M:N
ALUMNO
(1,n)
Realizar
CURSO
N:M
ALUMNO
Realizar
Figura 2.10: Ejemplo de cardinalidades
CURSO
La interpretacin de la interrelacin Realizar sera un curso Mentor es

Figura 2.8: Tipo de Correspondencia N:M
realizado como mnimo por un alumno y como mximo n. Si tuviramos
Si, por el contrario, en las especificaciones del problema se nos dijera que
limitacin en la matriculacin de los alumnos en un curso, por ejemplo, los
cada alumno solo puede matricularse de un curso, el tipo de correspondencia
cursos Mentor como mximo admiten 40 alumnos, lo representaramos de la
entre ALUMNO y CURSO cambiara, sera 1:N o uno a muchos, y se
siguiente forma:
representara de la manera que aparece en la figura 2.9.
M:N
ALUMNO
N:1
ALUMNO
Realizar
(1,40)
Realizar
CURSO
CURSO
Figura 2.11: Ejemplo de cardinalidades
Figura 2.9: Tipo de Correspondencia N:1
De la misma manera, el nmero mnimo de cursos que puede realizar un

alumno es uno y el mximo n, es decir, la cardinalidad de CURSO es (1,n) y
por tanto tendramos que representar la punta de flecha haca la entidad
CURSO y encima de esta lnea la cardinalidad como se muestra en la figura
2
2.12.
Esta representacin se puede generalizar en el caso de grado n, de la forma X:Y:Z:.....
43
44
Los atributos nombre y direccin de EMPLEADO son obligatorios ya que

dicha informacin la consideramos importante; por ejemplo, sin ellos no
podramos mandar la nmina o contactar por cualquier causa con los
M:N
ALUMNO
(1,n)
(1,n)
Realizar
CURSO
empleados de la empresa. El telfono lo podemos considerar como un atributo

opcional y, por ltimo, el nmero de afiliacin de la seguridad social (NSS) al
tomar valores nicos para cada empleado lo consideraremos un atributo
Figura 2.12: Cardinalidades de la interrelacin Realizar
alternativo. La entidad EMPLEADO con sus propiedades queda representada

Las cardinalidades mnimas y mximas son, como se puede apreciar, una
como se muestra en la figura 2.15.
extensin del tipo de correspondencia y nos dan ms informacin referente al

tipo de interrelacin que estamos representando.
Cdigo DNI Nombre Direccin
Veamos otro ejemplo con la relacin que existe entre los empleados de
NSS
una empresa y el departamento en el que trabajan. Sabemos que un
EMPLEADO
empleado trabaja en un departamento y que a cada departamento se le
Telfono
asigna al menos un empleado. De cada empleado se desea la siguiente

informacin: un cdigo de empleado (nmero que le identifica), DNI, nombre
Figura 2.15: Atributos de la entidad EMPLEADO
completo, direccin, telfono y nmero de afiliacin de la seguridad social.

Para los departamentos necesitamos un nombre, nico para cada uno de
Un
razonamiento
similar
nos
llevar
representar
la
entidad
ellos, una localizacin y un nmero de telfono. Cul sera su diseo en el
DEPARTAMENTO con las caractersticas que la definen como se muestra en la
modelo E/R?.
figura 2.16.
Podemos detectar de forma clara que necesitamos dos entidades,

Nombre Localizacin Telfono
EMPLEADO y DEPARTAMENTO, objetos que tienen existencia propia con

determinadas caractersticas. Para la entidad EMPLEADO tenemos como
identificador principal el cdigo de empleado, figura 2.13; el DNI, que es
DEPARTAMENTO
nico para cada empleado ser un atributo alternativo ya que hemos elegido
el cdigo como identificador principal por especificaciones del problema
(figura 2.14).
Figura 2.16: Atributos de la entidad DEPARTAMENTO
La interrelacin que une las entidades representadas anteriormente,

EMPLEADO y DEPARTAMENTO, es binaria ya que relaciona dos entidades; el
tipo de correspondencia es 1:N o de uno a muchos, ya que un empleado est
Cdigo
Cdigo
DNI
asignado a un departamento y a un departamento pertenecen varios

empleados.
EMPLEADO
Por
ltimo,
se
indican
las
cardinalidades
EMPLEADO
entidades participantes en dicha interrelacin (figura 2.17).
Figura 2.13: Entidad EMPLEADO y su IP
que
recogen
explcitamente como se relacionan cada una de los ejemplares de las
Figura 2.14: Entidad EMPLEADO con IP y IA
45
46
Cdigo
DNI Nombre Direccin
Nombre Direccin
e-mail
D.N.I.
N:1
NSS
Nombre
F_Comienzo
Telfono
EMPLEADO
Trabajar
(1,1)
DEPARTAMENTO
WWW
M:N
(1,n)
ALUMNO
Libro
F_Finalizacin
Realizar
Telfono
(1,n)
CURSO
Nacionalidad
Figura 2.17: Interrelacin Trabajar
Figura 2.19: Interrelacin con atributos
La interpretacin de la interrelacin Trabaja sera la siguiente: Un
Cmo seran los ejemplares de la interrelacin Realizar? Si pensamos en
empleado trabaja como mnimo y como mximo en un solo departamento
el mundo real, los valores nos vienen dados de la siguiente forma: Juan ha
(1,1) y tendramos una lnea continua entre el rombo de la interrelacin y la
realizado el curso de Iniciacin a Internet durante el periodo de 12-02-96 al
entidad DEPARTAMENTO para reflejar este hecho.
05-06-96. Algo parecido ocurre en el modelo E/R, los elementos que se

encuentran en la interrelacin Realizar son de la siguiente forma:
Si interpretamos la figura 2.18 desde el tipo de entidad DEPARTAMENTO

su lectura sera la siguiente: En un departamento trabajan como mnimo un
{(DNI, 7515458), (Nombre, Inciacin a Internet), (F_Comienzo, 12-02-
empleado y como mximo N.
96), (F_Finalizacin, 05-06-96)}.

{(DNI, 856593), (Nombre, Access Avanzado), (F_Comienzo, 02-12-96),
(F_Finalizacin, 15-03-97)}.
Cdigo
DNI Nombre Direccin
Todos estos ejemplares se corresponden con los valores de los atributos
N:1
NSS
EMPLEADO
(1,n)
Trabajar
(1,1)
identificadores de los tipos de entidad ALUMNO y CURSO que estn
DEPARTAMENTO
relacionados,
junto
con
los
atributos
propios
de
la
interrelacin.
La
Telfono
interpretacin o lectura que tienen estos elementos es la siguiente: el alumno

con DNI 7515458 ha realizado el curso Iniciacin a Internet durante el
periodo del 12-02-96 al 05-06-96; el alumno con DNI 856593 ha realizado el

Atributos de una interrelacin
curso Access Avanzado durante el periodo del 02-12-96 al 15-03-97.
Como ya se ha mencionado, los atributos no solo estn referidos a los
Hay que distinguir entre una ejemplar de un tipo de entidad y un tipo de
tipos de entidad. Las interrelaciones tambin pueden tener atributos propios,
interrelacin, pues una ejemplar de un tipo de interrelacin existe siempre y
atributos cuyos valores tienen sentido nicamente en el caso de que se
cuando existan ejemplares de los tipos de entidad que intervienen en la
establezca la relacin entre los tipos de entidad que las une, como pueden ser
asociacin. Los ejemplares no tienen representacin grfica en el modelo E/R
las fechas de comienzo y de finalizacin de un curso, que no tienen sentido si
pues se corresponden con los datos que realmente se almacenarn en la base
dicho curso no es realizado por al menos un alumno. Un ejemplo de estos
de datos y no con el diseo conceptual de sta.
atributos se muestra en la figura 2.19 en color verde.

Hemos visto los elementos bsicos del modelo E/R que nos permitirn el
diseo de la Base de Datos de forma Conceptual, es decir, tendremos una
representacin sencilla y natural del caso que queremos modelar que,
adems, no depende del Sistema Gestor de Bases de Datos que utilizamos
para su posterior implementacin y que lo que intentar ser recoger de la
47
48
mejor forma posible todas las especificaciones del problema de manera que
Grado de una
sea fcilmente comprensible por usuarios no informticos.
en una interrelacin.
Tipo
de
binarias
Elementos del
Representacin
Grfica
Descripcin
Ejemplar
en
Cosa u objeto con identidad propia de

ENTIDAD
de
Un
una entidad
ejemplar,
tambin
de
manera
nica
los
ejemplares o ejemplares de una entidad
Identificador
Distingue
alternativo
de
manera
nica
los
ejemplares o ejemplares de una entidad
Atributo
Indica que el atributo siempre debe
Obligatorio
tomar un valor para cada ejemplar de la

entidad o interrelacin a la que pertenece
Atributo
Indica que el atributo puede no tomar
Opcional
valor para cada ejemplar de la entidad o

interrelacin a la que pertenece
Interrelacin
Asociacin o relacin que existe entre

Interrelacin
mnimo
de
relacionarse con un nico ejemplar de la

otra.
de
interrelacin
Un
ejemplar,
ejemplar,
de
una
tambin
denominado
interrelacin
es
la
asociacin de los valores de los atributos
participantes en la interrelacin.
Caracterstica o propiedad de un tipo
Identifica
identificadores principales de las entidades
de entidad.
Identificador
mximo
interrelaciones
binaria
los atributos definidos para ella.
principal
Nmero
ejemplares de una entidad que puede
una
conjunto de los valores correspondientes a
(x, y)
Mxima
Ejemplar
denominado
ejemplar, de un tipo de entidad es el
Atributo
binarias
la que necesitamos guardar informacin.
con un ejemplar del otro tipo de entidad.
1:1
Cardinalidades
Mnima
Entidad
tipo de entidad que pueden estar asociados

N:M
interrelaciones
el momento:
Nmero mximo de ejemplares de un
1:N
Correspondencia en
Veamos un cuadro resumen de los conceptos del Modelo E/R tratados hasta
modelo E/R
Nmero de entidades que participan
interrelacin
entidades.
49
50
pueden serlo por dos motivos: bien porque la existencia de sus ejemplares en
3. Extensiones del Modelo E/R
la base de datos depende de una entidad fuerte bien porque sus ejemplares
Posteriormente al modelo E/R propuesto por Chen se realizaron algunas
requieran para su identificacin de los atributos identificadores (algunas veces
extensiones para darle ms riqueza semntica. Esto significa que se le han
llamados atributos externos) de otra entidad.
aadido nuevos conceptos para que el modelo se adapte mejor a la realidad que
Por ejemplo, los ejemplares correspondientes a los alumnos del MENTOR
queremos modelar, es decir, recoja mayor semntica.
no dependen de ninguna otra entidad para existir en la base de datos; por

Vamos a introducir algunos de estos nuevos conceptos retomando el
ello la entidad ALUMNO es una entidad fuerte. Sin embargo, en el caso de una
ejemplo visto en el apartado anterior sobre una empresa en el que habamos
base de datos de una cadena hotelera podramos tener el tipo de entidad
representado la relacin que exista entre los empleados y los departamentos de
HABITACIN dependiente del tipo de entidad HOTEL ya que para que existan
la empresa.
ejemplares de HABITACIN es necesario que existan ejemplares de HOTEL.
Supongamos que la empresa es un consorcio de distintas libreras
Una ejemplar de HABITACIN no tiene existencia por si misma porque
especializadas en libros y revistas informticas llamada INTERFAZ. Sabemos que
siempre estar asociada a una ejemplar de HOTEL. Adems, si se elimina un
los empleados de INTERFAZ estn asignados a un departamento y que la
determinado ejemplar de la entidad HOTEL de la base de datos tambin
relacin entre EMPLEADO y DEPARTAMENTO se representa como se indica en la
debern desaparecer los ejemplares de la entidad HABITACIN asociadas a
figura 2.20.
l. La representacin de una entidad dbil difiere de la de una entidad regular

pues el rectngulo de la entidad dbil es de doble recuadro como se muestra
en la figura 2.21.
N:1
DEPARTAMENTO
Telfono
(1, 1)
(1, n)
Trabajar
EMPLEADO
DNI
DNI
ENTIDAD DBIL
NSS
Nombre Direccin
Figura 2.21: Notacin grfica de una entidad dbil
3. 2 Interrelaciones binarias
3. 1 Entidades
La clasificacin anterior entre entidades fuertes y dbiles da lugar a dos

En el apartado 2 se estudi que las entidades en un esquema E/R son los
tipos de interrelaciones segn los tipos de entidades que asocian.
objetos principales sobre los que debe recogerse informacin y generalmente

denotan personas, lugares, cosas o eventos de inters. En esta seccin vamos
Las interrelaciones regulares relacionan tipos de entidades regulares o
a estudiar cmo las entidades pueden clasificarse por la fuerza de sus
fuertes. Las interrelaciones dbiles relacionan un tipo de entidad regular y un
atributos identificadores.
tipo de entidad dbil. Adems, en las interrelaciones dbiles podemos

distinguir:
Las entidades fuertes o regulares tienen existencia propia, es decir, poseen

identificadores internos que determinan de manera nica la existencia de sus
Dependencia en existencia. Este tipo de interrelacin refleja que los
ejemplares. Las entidades dbiles son dependientes de otras entidades y
ejemplares del tipo de entidad dbil que se relacionan con un determinado

51
52
ejemplar del tipo de entidad regular dependen de l y, si ste desaparece,
Como se muestra en la figura 2.23 el IP, es decir, el nmero de habitacin
ellos tambin. Veamos un ejemplo que clarifique esta definicin:
se repite para distintos hoteles (la habitacin nmero 1 existe en el hotel

Mar y en el hotel Sol). Para solucionar este problema, existen dos
Supongamos que la empresa INTERFAZ necesita conocer los datos de los
soluciones:
familiares que estn a cargo de cada empleado de la empresa (cnyuge,

hijos, etc.) para de esta manera apoyar a aquellos cuya carga familiar sea
numerosa.
1
Para saber los familiares que dependen de cada empleado debemos crear
Abeto
Roja
SI
SI
n_habitacin nombre WC
habitacin perteneciente al
Hotel MAR
un nuevo tipo de entidad, que denominaremos FAMILIAR, cuyos atributos

podran ser el DNI (como IP), el nombre completo y parentesco con el
habitacin perteneciente al
Hotel SOL
HABITACIN
empleado. Como se puede observar, la existencia de un miembro de la familia

depende plenamente de que ese miembro tenga a una persona de su familia
trabajando en la empresa, o lo que es lo mismo que exista un ejemplar de
El valor del IP se repite para hoteles distintos
EMPLEADO que este relacionado con l; es decir, los familiares slo existen en
Figura 2.23: Ocurrencias de la entidad HABITACIN
la base de datos si existe un empleado con el que se relacionen y si un

determinado EMPLEADO se va de la empresa, entonces se eliminarn todas
1. La primera consiste en cambiar el IP, por ejemplo, poner el nombre de
los ejemplares de FAMILIAR que dependan de l. As, tenemos una
la habitacin como IP; esto significa que los nombres de la habitacin no
interrelacin de dependencia en existencia entre EMPLEADO y FAMILIAR
pueden repetirse en los distintos hoteles y esto no es posible asegurarlo.
representada como muestra la figura 2.22.

2. La segunda, y ms razonable, consiste en crear una interrelacin dbil
de dependencia en identificacin, es decir, los ejemplares de la entidad dbil
requieren para su identificacin de los atributos identificadores de la entidad
N:1
(0, n)
FAMILIAR
fuerte.
Telfono
EMPLEADO
Encargado
As,
cada
ejemplar
de
HABITACIN
est
identificada
por
la
concatenacin de su nmero y del nombre del hotel en que se encuentra. Por
(1, 1)
ejemplo, la habitacin 1 Sol, habitacin 1 Mar, etc. Su representacin es

la que se muestra en la figura 2.24.
NSS
DNI
DNI
Nombre
Parentesco
Nombre Direccin
Figura 2.22: Ejemplo de una interrelacin con Dependencia en Existencia

N Habitacin
Dependencia en Identificacin: Este tipo de interrelacin complementa a la
Telfono
anterior en que, adems de que los ejemplares del tipo de entidad dbil
(1, n)
dependen de la existencia de un ejemplar de la entidad regular, tambin
HABITACIN
I
Posee
(1, 1)
HOTEL
necesitan para su identificacin el IP de la entidad regular. As, veamos

anteriormente que la entidad HABITACIN era dbil respecto al HOTEL al que
Nombre WC
pertenece. Si construimos las interrelacin existente entre ambas entidades

debemos pensar si el atributo N de Habitacin de la entidad HABITACIN
Figura 2.24:
es suficiente para identificar cada ejemplar de esta.

53
54
N:1
Nombre Direccin
Ejemplo de una interrelacin con Dependencia en Identificacin
Supongamos que en la entidad Empleado queremos recoger que un

empleado puede tener ms de un telfono, tendramos un atributo Telfonos
Otro tipo de interrelacin es la denominada jerrquica que expresa la
que tendra cero o ms valores, esto es lo que llamamos atributo multivaluado
clasificacin de un determinado tipo de entidad en uno o ms tipos de
y se representa como se muestra en la figura 2.26.
entidad. Por ejemplo, supongamos que la empresa Interfaz tiene tres

departamentos INFORMATICA, PUBLICACIONES y RECURSOS HUMANOS. Esta
Otro tipo de atributo es el atributo compuesto, que representa una
clasificacin de los departamentos se representara como una jerarqua
agregacin de atributos simples. Vamos a modificar el atributo Nombre de la
(tambin denominada generalizacin). Las generalizaciones nos proporcionan
entidad EMPLEADO ya que queremos un atributo, Nombre Completo,
un mecanismo de abstraccin que permite descomponer una entidad (que se
compuesto por Nombre y Primer Apellido. Su representacin sera la que se
denominar supertipo) en subtipos. De esta forma vemos un conjunto de
muestra en la figura 2.26.
ejemplares de una entidad como de otra entidad. As, por ejemplo, una
"Persona" es un "Animal" y un "Reptil" es un "Animal"; en este caso, "Animal"
puede considerarse el supertipo y "Persona" y "Reptil" son subtipos de
Nombre
Primer Apellido
"Animal". Los ejemplares o ejemplares de "Persona" lo son tambin de
Direccin
e-mail
"Animal" e igual sucede con las de "Reptil".
Nombre Completo
La figura 2.25 muestra la jerarqua de departamentos de la empresa
Telfono
EMPLEADO
D.N.I.
INTERFAZ representada por un tringulo invertido que une el supertipo con
Nacionalidad
los subtipos.
Figura 2.26: Ejemplo de atributo compuesto
Adems, todas las restricciones semnticas definidas para los atributos

Cdigo
Nombre
pueden combinarse entre s, es decir, (pueden existir en un esquema E/R
Ubicacin
atributos
Nmero de empleados
DEPARTAMENTO
Nombre director
Telfono contacto
PUBLICACIONES
Facturacin
RECURSOS
HUMANOS
INFORMTICA
e-mail de
contacto
multivaluados
simples
opcionales,
univaluados
compuestos
opcionales, multivaluados obligatorios, multivaluados compuestos, etc.).
Nmero de equipos
Figura 2.25: Ejemplo de generalizacin total exclusiva
3. 3 Atributos
En este apartado ampliaremos nuestro conocimiento acerca de las
restricciones semnticas sobre los atributos de las entidades y de las
interrelaciones para de esta forma poder representar ms fielmente los
requisitos que nos piden para el diseo de una determinada base de datos.
55
56
quiere almacenar en la BD acerca de los tutores es la siguiente: DNI,

nombre completo y direccin de correo electrnico.
La informacin que se desea almacenar en la Base de Datos se refiere
Para este caso prctico se ha pensado en una continuacin del ejemplo
a los alumnos matriculados en cada curso, teniendo en cuenta la
que se ha ido desarrollando a lo largo de este captulo sobre el diseo de una
fecha de inicio y la fecha de finalizacin de cada alumno en un
Base de Datos que recoja informacin acerca del proyecto llevado a cabo por el
determinado curso y sabiendo que un alumno se ha podido matricular
Ministerio de Educacin denominado MENTOR. Hay que tener en cuenta que los
de uno o varios cursos y que un curso tiene como mnimo un alumno.
supuestos semnticos de este ejemplo son hipotticos. A continuacin se

expondrn los requisitos que se van considerar en este apartado para llevar a
El proyecto MENTOR, adems, tiene en cuenta que ha de facilitar a los
cabo el diseo de la base de datos. Dicho proyecto se encarga de ofertar cursos
alumnos el acceso a Internet y por lo tanto ha instalado aulas con
por Internet para alumnos del territorio nacional.
todos los servicios necesarios para el pleno desarrollo de los cursos.

Cada alumno pertenece a un aula y el mantenimiento tanto de los
La informacin que se desea almacenar en la Base de Datos se refiere a
ordenadores como de los programas se lleva a cabo por los
los alumnos matriculados en cada curso, teniendo en cuenta la fecha de inicio y
administradores de aula.
la fecha de finalizacin de cada alumno en un determinado curso y sabiendo que

un alumno se ha podido matricular de uno o varios cursos y que un curso tiene
Cada aula tiene asignado un cdigo nico, descripcin y una direccin.
como mnimo un alumno.

La informacin que se necesita de cada administrador es su DNI,
nombre completo, direccin de correo electrnico.
De los alumnos se desea saber el DNI, nombre completo, direccin,

telfono, nacionalidad, pero slo interesa saber si la nacionalidad es
espaola o no, y la direccin de correo electrnico. La direccin de
correo electrnico es imprescindible para poder realizar los cursos y
adems es nica para cada alumno.
La informacin referente a los cursos consta del nombre, ttulo del libro
de consulta que se utiliza (aunque existen cursos que no lo poseen) y
direccin de Internet donde se encuentra todo el material que se
puede utilizar durante el curso.
Cada curso tiene asociado un grupo de personas expertas, llamadas
tutores, que son las encargadas de resolver las dudas propuestas por
los alumnos, la evaluacin de los mismos e incluso el hombro para
que estos se desahoguen. Dentro de los tutores de un mismo curso
existe una figura importante que es la de coordinador que se encarga
de realizar labores de unificacin y planificacin. No hay que olvidar
que una persona experta puede ser tutora de varios cursos y que
adems un coordinador de curso es un tutor. La informacin que se
57
24
La informacin referente a los cursos consta de nombre de este, ttulo
4. DISEO PROPUESTO AL CASO PRCTICO - MENTOR
del libro de consulta que utiliza (aunque existen cursos que no lo

Para realizar el diseo conceptual de la BD en el modelo E/R seguiremos una
poseen) y direccin de Internet donde se encuentra todo el material
serie de pasos que nos ayudarn a identificar los elementos bsicos del modelo.
del que consta. Curso es una entidad
Estos pasos son iterativos, es decir, un esquema E/R se construye segn

distintas fases de refinamiento. Adems, las soluciones no son nicas, cada
Cada curso tiene asociado un grupo de personas expertas, llamadas
diseador puede ver el mundo real de distinta forma, dando lugar a distintos
tutores, que son las encargadas de resolver los problemas propuestos
esquema E/R vlidos. Sin embargo, s se puede estudiar si un determinado
por los alumnos, la evaluacin de los mismos e incluso el hombro
esquema E/R refleja mejor que otro los supuestos semnticos del enunciado. No
para que estos se desahoguen. Dentro de los tutores de un mismo
hay que olvidar que en el esquema E/R de una base de datos hay que recoger la
curso existe una figura importante que es la de coordinador que se
mayor semntica posible y no dejar para las siguientes fases de desarrollo
encarga de realizar labores de unificacin. No hay que olvidar que
(diseo lgico e implementacin) ningn supuesto semntico, siempre que sea
una persona experta puede ser tutora de varios cursos y que adems
posible.
un coordinador de curso es un tutor. La informacin que se quiere

almacenar en la BD acerca de los tutores es la siguiente: DNI,
nombre completo y direccin de correo electrnico. De este prrafo
1 paso: Identificar y enumerar las posibles entidades teniendo en
podemos extraer que, por un lado necesitamos una entidad para
cuenta la siguiente heurstica: en general, un tipo de entidad es un
almacenar los datos de los tutores y por otro lado vemos que se
sustantivo dentro de una oracin con una seria de propiedades o
destaca en el texto la labor del coordinador y se podra pensar si es o
caractersticas tales como, DNI del alumno, nombre del curso, etc.
no un atributo de la entidad tutores.

La informacin que se desea almacenar en la Base de datos se refiere a los
alumnos el acceso a Internet y por lo tanto a instalado aulas con
alumnos matriculados en cada curso. Teniendo en cuenta la fecha de inicio de
cada alumno en un determinado curso as como su fecha de finalizacin y
Aunque, por ahora desconocemos posibles atributos de las aulas
sabiendo que un alumno se ha podido matricular de uno o varios cursos y que un
parece que interacta lo suficiente como para pensar en que pueda
curso tiene como mnimo un alumno.
ser una entidad
En el texto presentamos en negrita y subrayado los tipos de entidad que
Cada alumno pertenece a un aula y el mantenimiento tanto de los
hemos detectado.

administradores de aula. Aula va cogiendo peso como posible entidad

Cada aula tiene asignado un cdigo nico, una descripcin y una
direccin.
Definitivamente
aula
es
una
entidad,
ya
nos
han
especificado sus atributos
adems nica para cada alumno. Observamos que del nico

sustantivo que tenemos informacin que almacenar (DNI, nombre
completo, direccin, telfono, nacionalidad,e-mail) es de alumnos
nombre completo, direccin de correo electrnico. Este prrafo
luego ste, ser una entidad.
muestra claramente que administrador es una entidad ya que es

necesario almacenar informacin sobre l.
59
60
Los tipos de entidades que hemos localizado son: ALUMNO, CURSO, TUTOR,
por los alumnos, la evaluacin de los mismos e incluso el hombro
AULA y ADMINISTRADOR. Del enunciado se podra deducir que COORDINADOR
para que estos se desahoguen. Dentro de los tutores de un mismo
es tambin un tipo de entidad; dejamos para ms adelante la discusin sobre si
curso existe una figura importante que es la de coordinador que se
este concepto puede representarse como una entidad, un atributo o una
encarga de realizar labores de unificacin. No hay que olvidar que
interrelacin.
una persona experta puede ser tutora de varios cursos y que adems
un coordinador de curso es un tutor. La informacin que se quiere
almacenar en la BD acerca de los tutores es la siguiente: DNI,
nombre completo y direccin de correo electrnico. De este prrafo
podemos extraer que, por un lado necesitamos una entidad para
2 paso: Identificar y enumerar las posibles interrelaciones, teniendo en

cuenta la siguiente heurstica: en general, una interrelacin viene
almacenar los datos de los tutores y por otro lado vemos que se
reflejada por un verbo dentro de una oracin que relaciona dos objetos.
destaca en el texto la labor del coordinador y se podra pensar si es o

no un atributo de la entidad tutores.
En el texto aparece un nmero correlativo como superndice en los verbos
alumnos el acceso a Internet y por lo tanto a instalado aulas con
que indican la posible existencia de una interrelacin.

La informacin que se desea almacenar en la Base de datos se refiere a
Aunque, por ahora desconocemos posibles atributos de las aulas
los alumnos matriculados1 en cada curso. Teniendo en cuenta la
parece que interacta lo suficiente como para pensar en que pueda
fecha de inicio de cada alumno en un determinado curso as como su
ser una entidad
fecha de finalizacin y sabiendo que un alumno se ha podido

Cada alumno pertenece3 a un aula y el mantenimiento4 tanto de los
matricular de uno o varios cursos y que un curso tiene como mnimo
un alumno.
administradores de aula. Aula va cogiendo peso como posible entidad

Cada aula tiene asignado un cdigo nico, una descripcin y una

direccin.
especificado sus atributos
adems nica para cada alumno. Observamos que del nico
Definitivamente
aula
es
una
entidad,
ya
nos
han
sustantivo que tenemos informacin que almacenar (DNI, nombre
nombre completo, direccin de correo electrnico. Este prrafo
completo, direccin, telfono, nacionalidad,e-mail) es de alumnos
muestra claramente que administrador es una entidad ya que es
luego ste, ser una entidad.
necesario almacenar informacin sobre l.
La informacin referente a los cursos consta de nombre de este, ttulo
Para que nos sea ms sencillo saber qu tipos de entidades estn
del libro de consulta que utiliza (aunque existen cursos que no lo
relacionadas vamos a construir una matriz donde en la primera fila y la primera
poseen) y direccin de Internet donde se encuentra todo el material
columna se enuncian los tipos de entidad anteriormente enumerados y se
del que consta. Curso es una entidad
sealar en el cruce de filas y columnas aquellas interrelaciones que hemos
Cada curso tiene asociado2 un grupo de personas expertas, llamadas
detectado. De esta forma se facilita tambin la identificacin de posibles
tutores, que son las encargadas de resolver los problemas propuestos
interrelaciones que no aparecen explcitamente expresadas en los supuestos

semnticos del enunciado pero que son, bien de sentido comn, bien deducidas
61
62
del enunciado; estas interrelaciones tambin tienen que aparecer en el esquema
D.N.I.
Nombre
Direccin
ALUMNO
WWW
Telfono
ALUMNO
Interrelaciones
ALUMNO
CURSO
Libro
Nombre
e-mail
E/R de la base de datos.
CURSO
Matricular 1
TUTOR
AULA
ADMINISTRADOR
TUTOR
AULA
Pertenecer 3
Matricular
CURSO
Nacionalidad
ADMINISTRADOR
Figura 2.27: Interrelacin Matricular
Asociar 2
Coordinar?
El estudio del tipo de correspondencia y las cardinalidades mximas y
Mantener 4
mnimas tambin se realiz durante el desarrollo del captulo pero recordaremos

que la correspondencia es de muchos a muchos (N:M) ya que un alumno puede
matricularse de uno o varios cursos, cardinalidad (1,n), y en un curso se
En la tabla se muestra el nombre de las interrelaciones y una numeracin
matriculan uno o varios alumnos, cardinalidad (1,n). Adems, para saber las
que indica el orden en el que han ido apareciendo en el texto; se muestran
fechas en las que un alumno inici y finaliz un curso se introducen dos atributos
sombreadas las celdas que representan interrelaciones simtricas a las definidas
que pertenecen a la interrelacin Matricular (figura 2.28)
en el resto de las celdas. Adems de las interrelaciones extradas del texto hay
que estudiar si en las celdas vacas deberan aparecer nuevas interrelaciones.
As, podra existir la interrelacin Coordinar entre TUTOR y CURSO; dejaremos
esta interrelacin entre interrogaciones con el fin de estudiar posteriormente si
debe reflejarse de esta forma.
D.N.I.
Nombre Direccin
e-mail
Nombre
F_Comienzo
Telfono
Libro
WWW
F_Finalizacin
M:N
ALUMNO
3 paso: Dibujar las interrelaciones (estudiando el tipo de correspondencia y

las cardinalidades) y los tipos de entidad con los atributos correspondientes.
(1,n)
Matricular
(1,n)
CURSO
Nacionalidad
Figura 2.28: Interrelacin Matricular con cardinalidades y atributos en la interrelacin
Interrelacin Matricular
Tanto los atributos de CURSO como de ALUMNO se presentaron a lo largo
del captulo, pero recordamos que el IP (identificador principal) de CURSO es
Interrelacin Asociar
Nombre y el de ALUMNO es DNI. Tanto el atributo WWW como el e-mail son

Antes de analizar las propiedades de la interrelacin Asociar veamos los
identificadores alternativos, es decir, los valores que toman para cada elemento
atributos del tipo de entidad TUTOR.
del tipo de entidad CURSO o ALUMNO son nicos; Los atributos Libro y Telfono
son opcionales. La figura 2.27 muestra el esquema E/R correspondiente a la
Segn se muestra en el enunciado, la informacin que se requiere para los
interrelacin Matricular.
tutores es: DNI, nombre completo y direccin de correo. De estos tres atributos
tenemos que elegir cual de ellos puede ser el IP. Elegiremos el DNI aunque bien
podra ser la direccin de correo si esta es nica. Por lo que el e-mail ser un
atributo alternativo y el nombre completo un atributo obligatorio.
63
64
El tipo entidad
y sus atributos quedan representados como muestra la
datos siempre estarn ocupados con algn curso. Nos quedamos con la primera
figura 2.29.
alternativa para poder dejar descanso a los tutores. De esta forma la

cardinalidad mnima es 0.
DNI
Nombre
completo
e-mail
- A cuntos cursos est asociado como mximo un TUTOR? En este caso,

TUTOR
como en las especificaciones no se restringe el nmero de cursos que un tutor

puede impartir, la cardinalidad mxima ser N.
Figura 2.29: Entidad TUTOR
Grficamente, las cardinalidades de la entidad TUTOR se representan al lado

contrario de esta, es decir, junto al tipo de entidad CURSO (Figura 2.31).
La interrelacin Asociar relaciona las entidades TUTOR y CURSO (vase la
tabla del paso 2 y Figura 2.30); tenemos que estudiar el tipo de correspondencia
y las cardinalidades mximas y mnimas para completar las propiedades de la
DNI
Nombre
completo e-mail
Nombre
interrelacin.
Libro
WWW
N:M
(0,n)
Si leemos detenidamente las especificaciones del texto tenemos que un tutor
CURSO
Asociar
TUTOR
puede realizar sus labores en varios cursos y que en un curso puede ser tutorado
por varias personas expertas (tutores) por lo tanto la correspondencia es N:M o
Figura 2.31: Cardinalidad de TUTOR en la interrelacin Asociar
muchos a muchos.
De forma anloga se razonara para el caso de las cardinalidades asociadas a

DNI
Nombre
completo e-mail
Nombre
Libro
CURSO (figura 2.32). Un curso como mnimo ha de ser tutorado por un TUTOR
WWW
N:M
Asociar
TUTOR
(cardinalidad mnima 1) y como mximo por N (cardinalidad mxima N).

CURSO
DNI
Figura 2.30: Interrelacin Asociar
Nombre
completo e-mail
Nombre
Libro
WWW
N:M
(1,n)
TUTOR
(0,n)
Asociar
CURSO
Veamos ahora las cardinalidades mximas y mnimas del tipo de entidad

TUTOR en la interrelacin Asociar; para ello, tenemos que mirar al tipo de
Figura 2.32: Cardinalidades en la interrelacin Asociar
entidad TUTOR y preguntarnos:

- A cuntos cursos est asociado como mnimo un TUTOR? La respuesta
podra ser 0 si consideramos que podemos tener tutores que en un momento
En los pasos 1 y 2 dejamos sin estudiar el concepto de coordinador de los
dado no estn tutorando ningn curso, o, por el contrario, podramos poner un 1
cursos. Volviendo a releer el texto nos preguntamos qu pasa con la figura del
con lo que supondramos que todos los tutores que tenemos en nuestra base de
coordinador?, cul sera su representacin?

65
66
Como bien se indica en los supuestos semnticos del enunciado, el

coordinador es tambin un tutor y, adems, puede desarrollar una funcin
Vemoslo con los ejemplos de ejemplares de la interrelacin mostrados en la
aadida de planificacin en determinados cursos. Esto significa que un tutor en
figura 2.34; el curso Diseo de BD tiene tres tutores cuyos DNI son 3446721,
determinados cursos (pero solamente en aquellos donde participa) puede
7423412, 4567433. El tutor con DNI 4567433 no es coordinador y los tutores
realizar dos labores: tutor y coordinador. Por lo que una solucin puede ser
con DNI 3446721 y 7423412 estn definidos como coordinadores. Si no
considerar, dentro de la interrelacin Asocia un atributo, Coordinador, definido
queremos violar la restriccin semntica de que un curso no tenga ms de un
dentro del dominio Verdad que toma los valores (SI, NO), y el cual nos indicar
coordinador, entonces en el diseo lgico de la BD se debera definir algn
con el valor SI que un determinado tutor desarrolla la funcin de coordinador en
mecanismo que cuando se haya definido un coordinador para un curso, entonces
un curso con el que se relaciona (Figura 2.33).
no se permita introducir ninguno ms. Sin embargo, la solucin de la figura 2.34

si contempla la restriccin semntica consistente en que los coordinadores de los
cursos deben ser tutores de los mismos, es decir, no es posible definir un
DNI
Nombre
completo e-mail
Nombre
Libro
WWW
coordinador de un curso que no sea tutor del mismo.
N:M
(1,n)
(0,n)
CURSO
Asociar
TUTOR
DNI
Nombre
completo
Nombre
e-mail
Libro
WWW
N:M
Coordinador
Coordinador est definido dentro del Dominio VERDAD = (SI,NO)
(1, n)
TUTOR
(0, n)
CURSO
Asociar
Figura 2.33: Interpretacin de la figura Coordinador
1:N
Analicemos como se interpreta el atributo Coordinador en la interrelacin
(1, 1)
(0, n)
Asocia. El atributo Coordinador toma un valor para cada ejemplar de la
Coordinar
interrelacin Asociar; esto significa que como un determinado curso puede tener
ms de un tutor y el atributo Coordinador podra tomar el valor de SI en esas
Figura 2.35: Interrelacin Coordinar.
ejemplares de la interrelacin Asocia, entonces estamos permitiendo en el

esquema E/R que un curso tenga ms de un coordinador. Esto significa que no
Otra posible solucin para representar la semntica de la figura de
respetamos uno de los supuestos semnticos del enunciado.
coordinador de un curso consiste en utilizar otra interrelacin denominada

Coordinar entre TUTOR y CURSO con las cardinalidades mostradas en la figura
3446721
2.35. La interrelacin Coordinar representa que un determinado TUTOR puede

ser coordinador de ms de un CURSO y que un CURSO tiene uno y solo un
7423412
4567433
Asociar
TUTOR
TUTOR
la restriccin de que un curso slo tiene un coordinador, sin embargo, no recoge
SI
Asociar
TUTOR
TUTOR que lo coordina. Si bien esta propuesta de solucin recoge a la perfeccin
CURSO
CURSO
Asociar
que el coordinador de un curso tenga que ser obligatoriamente un tutor de ese
CURSO
Diseo de BD
curso (ver figura 2.36). Para controlar esta ltima restriccin habra que incluir
SI
NO
Diseo de BD
un mecanismo en el diseo lgico que obligara a que el coordinador de un curso
Diseo de BD
debe ser un tutor del mismo.
Figura 2.34: Ejemplares de la interrelacin Asociar
67
68
Interrelacin Pertenecer
3446721
7423412
Esta interrelacin asocia las entidades ALUMNO y AULA. En primer lugar se
4567433
TUTOR
TUTOR
TUTOR
CURSO
Asociar
representarn los atributos del tipo de entidad AULA que (cdigo_aula,
CURSO
Asociar
descripcin y direccin). El cdigo_aula ser el IP, y el resto de atributos sern
CURSO
Asociar
Diseo de BD
obligatorios.
Diseo de BD
2223456
Diseo de BD
Coordinar
TUTOR
Telfono
1:N
CURSO
ALUMNO
Pertenecer
AULA
Nacionalidad
Diseo de BD
e-mail
Figura 2.36: Ejemplares de la interrelacin Asociar y Coordinar
Cdigo_aula
DNI
DescripcinDireccin
Nombre
Direccin
Figura 2.38: Interrelacin Pertenecer
Aunque existen otras formas de representar la figura del coordinador de un

curso, no vamos a presentarlas aqu con el fin de no complicar el ejercicio. Se
Para la interrelacin Pertenecer tenemos un tipo de correspondencia de uno
han mostrado las dos ms significativas. Para este caso prctico se ha

seleccionado
la
primera
propuesta
de
solucin
(considerar
el
a muchos porque segn el enunciado cada ALUMNO pertenece a un AULA
atributo
(suponemos que un alumno no puede estar asociado a ms de un aula);
Coordinador en la interrelacin Asocia). De esta forma, el esquema E/R definido
adems, un AULA puede tener asociados varios ALUMNOS (figura 2.38). Las
hasta el momento se muestra en la figura 2.37:
cardinalidad mnima y mxima de ALUMNO es (1,1) ya que el alumno est

asignado a una y solo un AULA. Las asociadas a AULA seran (1,n) ya que no
tendra mucho sentido mantener un aula sin alumnos (figura 2.39).
Nombre
DNI completo e-mail
Nombre lLibro WWW

N:M
TUTOR
(1, n)
Asociar
(0, n)
F_Comienzo
Coordinador
1:N
CURSO
AULA
(1, n)
(1,1)
F_Finalizacin
Matricular
nacionalidad = (espaola, no_espaola)
(1, n)
Direccin
Cdigo_aula Descripcion
N:M
Telfono
Pertenecer
Telfono
(1,n)
ALUMNO
Nacionalidad
e-mail
DNI Nombre Direccin
Figura 2.39: Cardinalidades de la interrelacin Pertenecer
coordinador = (SI, NO)

ALUMNO
Nacionalidad
El esquema E/R obtenido hasta el momento es el mostrado en la figura 2.40.
DNI
e-mail
Nombre Direccin
Figura 2.37: Esquema E/R parcial
69
70
Nombre
DNI completo e-mail
Nombre
DNI completo e-mail
Nombre Libro WWW
N:M
N:M
TUTOR
(1, n)
Asociar
(0, n)
TUTOR
CURSO
F_Comienzo
Coordinador
Nombre Libro WWW
Asociar
(1, n)
Matricular
(0, n)
CURSO
F_Comienzo
Coordinador
F_Finalizacin
(1, n)
N:M
(1, n)
F_Finalizacin
Matricular
N:M
administrador = (SI, NO)

1:N
(1, n)
(1,n)
(1,1)
Pertenecer
AULA
Cdigo_aula Descrip Direccin
DNI
ALUMNO
1:N
Telfono
Nacionalidad
Pertenecer
AULA
e-mail
Nombre Direccin
DNI
Cdigo_aula Descripcion Direccin
Figura 2.40: Esquema E/R parcial
(1, n)
(1,n)
(1,1)
ALUMNO
Telfono
Nacionalidad
e-mail
Nombre Direccin
(1,1)
1:N
Mantener
(1,n)
ADMINISTRADOR
e-mail
DNI
Interrelacin Mantener
La interrelacin Mantener se da entre las entidades ADMINISTRADOR y
Nombre
Figura 2.41: Esquema E/R completo
AULA. Los atributos del tipo de entidad ADMISTRADOR son DNI, nombre
completo y e-mail y representan el IP, un atributo obligatorio y otro alternativo,
Observando el esquema E/R final, las entidades TUTOR y ADMINISTRADOR
respectivamente.
tienen atributos comunes. Podremos identificar generalizaciones si encontramos

El tipo de correspondencia es de uno a muchos (1:N) ya que un
una serie de atributos comunes a un conjunto de entidades; estos atributos
ADMINISTRADOR solamente puede estar asignado a un AULA y sin embargo un
comunes describirn al supertipo y los atributos particulares permanecern en
AULA puede ser mantenida por ms de un ADMINISTRADOR lo que nos indica
los subtipos. Puede ocurrir que los subtipos no tengan atributos propios, como es
tambin las cardinalidades: (1,n) para el tipo de entidad AULA y (1,1) para el
el caso que nos ocupa; en ese caso, slo existirn subtipos si stos van a
tipo de entidad ADMINISTRADOR.
participar en interrelaciones (aparte de las interrelaciones en las que participe el

supertipo). As, podemos tener, como muestra la figura 2.42, el supertipo
As, el diseo conceptual de la base de datos referente al proyecto MENTOR
PERSONA con los atributos DNI, nombre y e-mail y los subtipos TUTOR y
se representa en la figura 2.413:
ADMINISTRADOR que no tienen ningn atributo propio. Los subtipos TUTOR y

ADMINISTRADOR siguen participando en las mismas interrelaciones que en la
figura 2.41. Sin embargo, el supertipo PERSONA no participara en ninguna
interrelacin; por ello, se ha optado por eliminar la generalizacin de la solucin
Como se ha mencionado al principio del ejercicio, esta representacin conceptual no es nica; puede
haber diversas interpretaciones. Lo importante es que el usuario o la persona que nos ha encargado el
diseo este conforme con este y refleje lo ms fielmente posible las caractersticas del problema.
propuesta.
71
72
Nombre
DNI completo e-mail
En este segundo caso prctico se ha pensado en el diseo de una Base de

Datos para los estudiantes universitarios de Historia. Debemos crear una base
PERSONA
de datos que permita consultar la informacin ms relevante de la Edad Media,

y ms concretamente de las cruzadas que se llevaron a cabo en dicha poca.
Veremos a continuacin los requisitos que se plantean en este nuevo proyecto:
TUTOR
Interesa conocer la informacin de los caballeros ms importantes de

ADMINISTRADOR
los que sea almacenar la informacin de su nombre, fecha de

nacimiento y apodo.
Figura 2.42: Generalizacin de PERSONA
Tambin ser importante conocer las provincias de aquella poca, de

las que guardaremos la informacin de su denominacin, nmero de
habitantes y los caballeros que las gobernaron, teniendo en cuenta
que un caballero pudo gobernar ms de una provincia y que una
provincia estuvo gobernada por diferentes caballeros en distintas
fechas. Interesar conocer el ao de inicio y el nmero de aos que
estuve gobernada por cada caballero.
De
las cruzadas almacenaremos la informacin del nombre, la fecha
de inicio y la fecha de fin, los caballeros que participaron, la fecha en

la que se incorporaron, la fecha en la que se retiraron y el resultado
que obtuvieron (derrota, victoria o abandono).
En esta poca tambin fueron muy importantes los reyes, de los que
nos interesa conocer el nombre y sus apellidos, fecha de nacimiento,
corona y las provincias sobre las que reinaron.
Por ltimo, interesa conocer para cada rey la informacin de su
ascendente. En aquella poca ya se sabe que su ascendiente sera
otro rey.
73
74
5. DISEO PROPUESTO AL CASO PRCTICO - HISTORIA

otro rey.
Para realizar el diseo conceptual de la BD en el modelo E/R seguiremos los
Las entidades que hemos encontrado son: CABALLERO, PROVINCIA,
mismos pasos que seguimos en el ejemplo anterior con el fin de identificar los
CRUZADA y REY.
elementos bsicos del modelo. Recordemos que las soluciones no son nicas, y
cada pueden existir distintos esquema E/R vlidos.
cuenta la siguiente heurstica: en general, una interrelacin viene reflejada por
un verbo dentro de una oracin que relaciona dos objetos.

caractersticas. Por ejemplo, DNI del alumno, nombre del curso, etc.
Igual que en el ejemplo visto anteriormente, en los verbos con posiblidad de

interrelacin aparece un nmero correlativo que se muestra como superndice.
hemos detectado.

nacimiento y apodo.

nacimiento y apodo.

que un caballero pudo gobernar1 ms de una provincia y que una
que un caballero pudo gobernar ms de una provincia y que una
estuvo gobernada por cada caballero.

De las cruzadas almacenaremos la informacin del nombre, la fecha de
estuvo gobernada por cada caballero.
inicio y la fecha de fin, los caballeros que participaron2, la fecha en la

que se incorporaron, la fecha en la que se retiraron y el resultado que
De las cruzadas almacenaremos la informacin del nombre, la fecha
obtuvieron (derrota, victoria o abandono).
de inicio y la fecha de fin, los caballeros que participaron, la fecha en

la que se incorporaron, la fecha en la que se retiraron y el resultado
que obtuvieron (derrota, victoria o abandono).
nos interesa conocer el nombre y sus apellidos, fecha de nacimiento,

corona, y la provincia sobre la que rein ms tiempo, teniendo en
cuenta que una provincia pudo tener diferentes reyes.
nos interesa conocer el nombre y sus apellidos fecha de nacimiento,

corona, y las provincias sobre las que reinaron.

otro rey.
75
76
continuacin
realizaremos
la
matriz
de
interrelaciones,
donde
Fecha_Nac
Apodo Nombre
.
recordaremos que en la primera fila y en la primera columna especificaremos las
Denominacin Num_Hab
entidades localizadas en el texto, mientras que en el cruce de filas y columnas

CABALLERO
indicaremos las interrelaciones encontradas.
Interrelaciones
CABALLERO
PROVINCIA
REY
Historia 1:: Interrelacin Gobernar
Participar 2
CABALLERO
PROVINCIA
CRUZADA
PROVINCIA
Gobernar
Gobernar 1
CRUZADA
REY
Reinar 3
Ascender 4
Para el estudio de las cardinalidades, nos fijaremos en los requisitos

indicados en el enunciado, donde se afirma que Un caballero puede gobernar
ms de una provincia y que una provincia estuvo gobernada por deferentes
caballeros en distintas fechas.
La numeracin como en el ejemplo anterior, muestra el orden de aparicin
Adems nos indican que debemos conocer el
ao de inicio y el nmero de aos que estuvo gobernada por cada caballero.
en el texto. Se muestran sombreadas las celdas que representan interrelaciones

Para hallar las cardinalidades, preguntaremos:
simtricas.
- Un caballero, cuntas provincias pudo gobernar? Podemos pensar que

habr caballeros que no gobernaron ninguna provincia (0), y que habr otros
3 paso: Dibujar las interrelaciones (estudiando el tipo de correspondencia y
que habrn gobernado ms de una, por lo que las cardinalidades mnimas y
las cardinalidades) y los tipos de entidad con los atributos correspondientes.
mximas son (0,n). Recordemos que la cardinalidad se expresa en sentido

contrario.
- Una provincia, por cuntos caballeros estuvo gobernada? Siempre estuvo
Interrelacin Gobernar
gobernada como mnimo por un caballero, pero a lo largo de la historia pudo

estar gobernada por diferentes caballeros (1,n).
En esta interrelacin participan las entidades CABALLERO y PROVINCIA.

Los atributos de la entidad CABALLERO son: Nombre, Fecha de nacimiento y
Por ltimo vemos que nos hablan de dos atributos: Ao de inicio y nmero
Apodo. Elegiremos como IP (identificador principal) el atributo Apodo, ya que
de aos que un caballero estuvo gobernando una provincia. Como vemos, son
identifica de forma nica a cada caballero. En cuanto a la entidad PROVINCIA,
dos atributos que dependen de la interrelacin Gobernar.
nos interesa conocer, segn los requisitos del modelo, la Denominacin y el

Apodo Nombre
.
Nmero de Habitantes siendo el IP (identificador principal) la denominacin
Ao_inicio
Denominacin Num_Hab
Num_Aos
(nica para cada provincia).
M:N
CABALLERO
La figura Historia 1: Interrelacin Gobernar muestra la representacin de
(1,n)
(0,n)
Gobernar
PROVINCIA
las entidades Caballero y Provincia con sus atributos , y la representacin de la

Historia 2: Interrelacin Gobernar con cardinalidades y atributos de interrelacin
interrelacin Gobernar en el diagrama entidad-relacin.
77
78
Recordemos que la cardinalidad se representa grficamente en sentido
Interrelacin Participar
contrario.
Esta interrelacin representa las cruzadas en las que participaron los

caballeros. Analizaremos los atributos de la nueva relacin CRUZADA, que segn
- En una cruzada, cuntos caballeros pudieron participar? Como mnimo un
el enunciado deben ser: Nombre, la fecha en la que comenz la cruzada y la
caballero y como mximo N.
fecha en la finaliz. Como IP (identificador principal) elegiremos el atributo

Nombre.
La entidad y sus atributos quedan representados en la siguiente figura:
Nombre
Apodo completo Fecha_Nac
Fecha_Inicio
Nombre
Fecha_Fin
N:M
Nombre Fecha_Inicio
Fecha_Fin
CABALLERO
(1,n)
(1,n)
CRUZADA
Participar
CRUZADA
Historia 5: Cardinalidad de CABALLERO y CRUZADA en la interrelacin Participar
Historia 3: Entidad CRUZADA
Vemos que la cardinalidad de la interrelacin es del tipo N:M.
El siguiente paso ser establecer las cardinalidades entre las dos entidades
de esta interrelacin PARTICIPAR, donde intervienen las entidades CRUZADA y
Ahora bien, tambin interesa conocer para cada caballero que particip en
CABALLERO.
cada cruzada, la informacin de la fecha de incorporacin, la fecha de retirada y

el resultado (derrota, abandono, victoria). Estos atributos no son propios ni de la
- Un caballero, en cuntas cruzadas pudo participar? Como mnimo en una
entidad CABALLERO ni de la entidad CRUZADA, sino que la informacin depende
y como mximo en muchas (1,n).
de cada uno de los caballeros que particip en una cruzada, por lo tanto, son
atributos de la interrelacin PARTICIPAR:
Nombre
Nombre
Fecha_Inicio
Fecha_Fin
Nombre
(1,n)
CABALLERO
Participar
CRUZADA
CABALLERO
(1,n)
Nombre
F_Retirada
F_Incorpor
Resultado
N:M
(1,n)
Participar
Historia 4: Cardinalidad de CABALLERO en la interrelacin Participar
Historia 6: Esquema entidad/relacin parcial
79
80
Fecha_Inicio
CRUZADA
Fecha_Fin
Esta interrelacin asocia las relaciones PROVINCIA y REY. Sus atributos son:
(1,n)
PROVINCIA
Reinar
Nombre, Apellidos, (ID Principal) Fecha de nacimiento y Corona.
Fecha_Nac
Nombre
Denominacin Num_Habitantes
Interrelacin Reinar
Corona
REY
Historia 9 : Cardinalidad de la entidad Provincia
Nombre
Completo Fecha_Nac
Corona
REY
Un rey, cuntas provincias rein? Puedo reinar sobre uno o ms provincias.
Historia 7: Entidad REY
Veamos la representacin de la interrelacin Reinar
Fecha_Nac
Nombre
Corona
N:1
PROVINCIA
Nombre
Fecha_Nac
(1,n)
Reinar
(1,1)
REY
Corona
Historia 10 : Cardinalidad de la interrelacin
PROVINCIA
Reinar
REY
Historia 8 : Representacin de la interrelacin Reinar
Por lo tanto la cardinalidad entre estas relaciones es 1:N

- En una provincia, cuntos reyes reinaron? Uno o ms de uno (en distintas
fechas)
Interrelacin Ascender
En esta interrelacin participa nicamente la relacin REY relacionada
consigo misma.
81
82
Hasta ahora hemos representado todas las interrelaciones de forma parcial,

por lo que el siguiente paso es la representacin global de las interrelaciones a
Nombre Fecha_Nac
Completo
travs del diagrama entidad-relacin:
Corona
Apodo Nombre
.
REY
Fecha_Nac
Ao_inicio
Denominacin
Num_Aos
Num_Hab
M:N
CABALLERO
(1,n)
(0,n)
PROVINCIA
Gobernar
(1,n)
(1,n)
Ascender
Historia 11: Interrelacin Asociar
M:N
Nombre
Para hallar la cardinalidad, preguntaremos:
F_Retirada
F_Incorpor
Resultado
Participar
Fecha_Inicio
M:N
Reinar
Fecha_Fin
(1,n)
- Un rey cuntos ascendientes tiene? Tendr dos. (Se incluye la informacin
Nombre Fecha_Nac
Completo
CRUZADA
de los Reyes y de las Reinas)
Corona
(1,n)
- Un rey, de cuntos Reyes es ascendiente? De uno o ms de uno (en el
REY
caso de que haya tenido ms de un hijo). Por lo tanto, la representacin sera:

(1,n)
Nombre Fecha_Nac
Completo
Ascender
Corona
REY
Historia 13 : Diagrama Entidad- Relacin completo
(1,n)
(1,n)
Ascender
(1,n)
N:M
Historia 12: Interrelacin Asociar
83
84
N:M
6. DISEO PROPUESTO AL CASO PRCTICO - CONSTRUCTORA
Seguiremos los mismos pasos que hemos visto en ejemplos anteriores.

Recordemos que las soluciones no son nicas, y que pueden existir distintos
En este tercer caso prctico se requiere el diseo de una Base de Datos
esquemas E/R vlidos.
para una Constructora que dispone de varias sucursales dedicadas al alquiler de

sus inmuebles. Se desea almacenar la informacin de su negocio. Se exponen a
continuacin los requisitos para la creacin de la base de datos:

Cada sucursal se identifica por un cdigo y se requiere la informacin
caractersticas. Por ejemplo, DNI del alumno, nombre del curso, etc.
de su direccin, cdigo postal, poblacin y telfono.

Se desea conocer los comerciales que trabajan en las distintas
sucursales. De ellos se quiere conocer su Dni, nombre, apellidos y la
hemos detectado.
fecha de contratacin.
De los inmuebles que gestiona cada sucursal interesa conocer el
Cdigo del inmueble, su direccin, cdigo_postal, poblacin, n de

habitaciones, n de baos, y el importe de su alquiler mensual. Se
Se desea conocer los comerciales que trabajan en las distintas
tendr en cuenta que un inmueble ser gestionado por una nica
sucursal.
Los clientes reales son aquellos que tienen alquilado algn inmueble.
De los inmuebles que gestiona cada sucursal interesa conocer el
Nos interesa conocer la informacin de su DNI, nombre, apellidos, y
telfono. Tendremos en cuenta que un inmueble puede ser alquilado
por diferentes clientes a lo largo del tiempo y nos interesar conocer
la fecha de inicio, la fecha de fin y el importe mximo mensual que
sucursal.
un cliente pag por ese alquiler.
Los clientes reales son aquellos que tienen alquilado algn inmueble.
Sus clientes potenciales son aquellos que buscan el alquilar de un
inmueble. Nos interesa conocer la informacin de su DNI, nombre,
apellidos, telfono, y precio mximo que est dispuesto a pagar por
el alquiler. Un cliente potencial ser atendido por un nico comercial.

Cada sucursal depende a su vez, de una sucursal principal a la que

enviar mensualmente todos sus informes de alquileres. La sucursal
principal tendr a su cargo varias sucursales.

85
86
el alquiler. Un cliente potencial ser atendido por un nico comercial.
Cada sucursal depende a su vez, de una sucursal principal a la que

el alquiler. Un cliente potencial ser atendido4 por un nico comercial.
Las
entidades
que
hemos
encontrado
son:
SUCURSAL,
Cada sucursal depende5 a su vez, de una sucursal principal a la que
COMERCIAL,
INMUEBLE, CLIENTE REAL y CLIENTE POTENCIAL.

A
cuenta la siguiente heurstica: en general, una interrelacin viene
continuacin
realizaremos
la
matriz
de
interrelaciones,
donde
recordaremos que en la primera fila y en la primera columna especificaremos las
entidades localizadas en el texto, mientras que en el cruce de filas y columnas

indicaremos las interrelaciones encontradas.
Igual que en el ejemplo visto anteriormente, en los verbos con posiblidad de
interrelacin aparece un nmero correlativo que se muestra como superndice.
Interrelaciones
SUCURSAL
COMERCIAL
INMUEBLE

Se desea conocer los comerciales que trabajan1 en las distintas
SUCURSAL
Depender 5
COMERCIAL
Trabajar 1
INMUEBLE
Gestionar 2
CLIENTE
CLIENTE
REAL
POTENCIAL
Alquilar 3
CLIENTE REAL
De los inmuebles que gestiona2 cada sucursal interesa conocer el
CLIENTE
Atender 4
POTENCIAL

sucursal.
Recordemos que la numeracin, se corresponde con el orden de aparicin en
Los clientes reales son aquellos que tienen alquilado3 algn inmueble.
el texto. Se muestran sombreadas las celdas que representan interrelaciones
semnticas.

87
88
paso:
Dibujar
las
interrelaciones
(estudiando
el
tipo
de
correspondencia y las cardinalidades) y los tipos de entidad con los

atributos correspondientes.
Cod_Suc.
Cod_Postal
Direccion Poblacin Telfono
Nombre
Apellidos Fecha_Contrato
DNI
SUCURSAL
Interrelacin Trabajar
(1,n)
COMERCIAL
Trabajar
En esta interrelacin participan las entidades SUCURSAL y COMERCIAL.

Constructora 2::
Los atributos de la entidad SUCURSAL son: Cod_Suc, Direccin, Cod_Postal,

Poblacin y Telfono. Elegiremos como IP (identificador principal) el atributo
Cod_Suc (Cdigo de Sucursal), ya que identifica de forma nica a las distintas
sucursales con las que cuenta la Constructora. En cuanto a la entidad
COMERCIAL, nos interesa conocer para cada uno de los comerciales, su DNI que
- Un comercial, en cuntas sucursales trabaja? Lo lgico sera pensar que
ser el IP (identificador principal), su nombre, apellidos y la fecha de
un comercial trabaja nicamente en una sucursal, por lo que la cardinalidad sera
contratacin.
1:1 (Como mnimo trabajara en una sucursal y como mximo tambin en una
nica sucursal).
La figuraConstructora 1: Interrelacin Trabajar muestra el diagrama

parcial entidad-relacin.
Cod_Suc.
Cod_Postal
Cod_Suc.
Cod_Postal
Nombre
DNI
Nombre
DNI
1:N
SUCURSAL
(1,1)
(1,n)
Trabajar
SUCURSAL
Trabajar
Constructora 3::
Constructora 1::
COMERCIAL
COMERCIAL
Interrelacin Gestionar
Para el estudio de las cardinalidades, nos preguntaremos lo siguiente:
Esta interrelacin representa los inmuebles que gestiona cada sucursal.

Analizaremos los atributos de la nueva relacin INMUEBLES. En el enuanciado
nos indican que las propiedades ms relevantes para esta entidad son: Cdigo
- En una sucursal, cuntos comerciales trabajan? Puedes trabajar como
del inmueble, su direccin, cdigo_postal, poblacin, n de habitaciones, n de
mnimo 1 y como mximo N. Por lo tanto la cardinalidad ser 1:N. Recordemos
baos, y el
que la cardinalidad se expresa en el sentido contrario.
elegiremos el atributo Cdigo del inmueble ya que identificar de forma nica a
importe de su alquiler mensual. Como IP (identificador principal)
cada uno de los inmuebles de la constructora.

89
90
El tipo de entidad y sus atributos quedan representados en la siguiente

figura:
Cod_Postal
Direccin.
Num_Baos
Cod_Inmueble. Num_Habitaciones.
Importe_Alquiler
Cod_Suc.
Cod_Postal
1:N
Direccin. Poblacin
Num_Baos
Num_Habitaciones.Importe_Alquiler
Cod_Inmueble. Cod_Postal
(1,n)
(1,1)
SUCURSAL
INMUEBLE
INMUEBLE
Gestionar
Constructora 6: Cardinalidad de SUCURSAL e INMUEBLE
Constructora 4: Entidad Inmueble
Vemos que la cardinalidad de la interrelacin es del tipo 1:N.
Interrelacin Alquilar
El siguiente paso ser establecer las cardinalidades de la interrelacin

GESTIONAR, donde intervienen las entidades SUCURSAL e INMUEBLE.
Esta
interrelacin
ALQUILAR
asocia
las
entidades
CLIENTE
(real)
INMUEBLE. Los atributos de la entidad CLIENTE (real), segn el enunciado son:
- Una sucursal, cuntos inmuebles puede gestionar? Como mnimo podr
DNI, nombre, apellidos, y telfono. Elegiremos como IP (Identificador Principal)
gestionar 1 y como mximo N (Muchos).
el atributo DNI y representaremos la entidad de la siguiente forma:
Cod_Postal
Direccin.
Num_Baos
Importe_Alquiler
Cod_Suc.
Cod_Postal
(1,n)
SUCURSAL
Gestionar
DNI.
Nombre
Apellidos
Telfono
INMUEBLES
CLIENTE (real)
Constructora 5: Cardinalidad de SUCURSAL en la interrelacin Gestionar
Constructora 7: Entidad Cliente (Real)
- Un inmueble, por cuntas sucursales es gestionado? Como mnimo por

una sucursal y como mximo tambin por 1, ya que en el enunciado nos indican
que un inmueble ser gestionado por una nica sucursal.
continuacin
estableceremos
las
cardinalidades
ALQUILAR, donde intervienen las entidades CLIENTE (real)

ello, preguntaremos:
91
92
de
la
interrelacin
e INMUEBLE. Para
- Un cliente Cuntos inmuebles puede alquilar? Puede ser que alquile como
mnimo 1, y como mximo muchos (N), ya que puede alquilar diferentes
inmuebles a lo largo del tiempo.
DNI.
Nombre
Apellidos
Telfono
Cod_Postal
Direccin.
Num_Baos
Fecha_InicFecha_Fin
Importe_Alquiler
Importe_Max
N:M
(1,n)
CLIENTE (real)
DNI.
Nombre
Apellidos
Cod_Postal
Direccin.
Num_Baos
Importe_Alquiler
Telfono
(1,n)
CLIENTE (real)
Alquilar
(1,n)
Alquilar
INMUEBLE
Constructora 10: Cardinalidad y atributos de la interrelacin ALQUILAR
INMUEBLE
Interrelacin Atender
Constructora 8: Cardinalidad de CLIENTE en la interrelacin ALQUILAR
En esta interrelacin participan las entidades CLIENTE (potencial)
COMERCIAL.
Los atributos de la entidad CLIENTE (potencial) son: DNI, nombre, apellidos,
- Un inmueble, por cuntos clientes es alquilado? Como mnimo estar
telfono, y precio mximo que est dispuesto a pagar por el alquiler. Elegiremos
alquilado por un cliente y como mximo por muchos (N), ya que un inmueble
como IP (identificador principal) el atributo DNI, ya que identifica de forma
pudo estar alquilado por ms de un cliente en distintas fechas.
nica a los clientes (pontenciales).

Antes de continuar, podemos observar que los atributos de los clientes
reales y clientes potenciales son prcticamente los mismos, por lo que podemos
DNI.
Nombre
Apellidos
Telfono
N:M
(1,n)
CLIENTE (real)
hablar de una generalizacin, donde crearemos un supertipo denominado
Cod_Postal
Direccin.
Num_Baos
Importe_Alquiler
(1,n)
Alquilar
CLIENTE
dos
subtipos:
CLIENTES
(real)
CLIENTE
representacin de esta generalizacin se expone a continuacin:
INMUEBLE
Nombre
DNI
Apellidos
Constructora 9: Cardinalidad de la interrelacin ALQUILAR
Telfono
CLIENTE
Ahora bien, tambin interesa conocer la fecha de inicio, la fecha de fin y el
Precio_Max
importe mximo mensual que un cliente pag por ese alquiler. Esos atributos no
son propios ni de la entidad Cliente (real), ni de la entidad Inmueble, sino que
son propios de la relacin.
CLIENTE (REAL)
CLIENTE POTENCIAL
Constructora 11: Generalizacin de Cliente

93
94
(potencial).
La
Como la entidad cliente y cliente real, tienen los mismos atributos puesto
DNI
que la entidad cliente real no tiene ninguno propio, se decide mantener

nicamente las entidades cliente (real) y cliente potencial. La entidad cliente
Apellidos
Nombre
Telfono
Nombre
N:1
DNI
real, pasa a denominarse Cliente, por lo que a partir de ahora ya no hablaremos

CLIENTE
POTENCIAL
de cliente real y cliente potencial, sino nicamente de cliente y cliente potencial:
(1,n)
(1,1)
Atender
Constructora 13::
CLIENTE
COMERCIAL
Cardinalidad de la interrelacin Atender
CLIENTE POTENCIAL
Por lo tanto, hemos visto que la cardinalidad entre las entidades CLIENTE
POTENCIAL Y COMERCIAL es N:1.
Continuaremos analizando la cardinalidad entre las entidades CLIENTE

POTENCIAL y COMERCIAL.
Interrelacin Depender
Comenzaremos por establecer la cardinalidad de la entidad CLIENTE

POTENCIAL:
Para
finalizar,
analizaremos
la
interrelacin
Depender.
La
entidad
participante es SUCURSAL ya que se relaciona consigo misma:
- Un cliente potencial por cuntos comerciales es atendido? Segn se nos

indica en el enunciado Un cliente potencial ser atendido por un nico
comercial
Direccin Poblacin
Cod_Postal Telfono
Cod_Sucural
DNI
Apellidos
Precio_Max
Nombre
Telfono
Nombre
DNI
CLIENTE
POTENCIAL
(1,1)
Atender
Constructora 12::
SUCURSAL
COMERCIAL
Cardinalidad de Cliente
Depender
Constructora 14: Interrelacin Depender
- Un comercial a cuntos clientes potenciales atiende? Como mnimo

atender a 1 y como mximo a muchos (1:N)
A continuacin establecemos las cardinalidades:
- Una sucursal, de cuntas sucursales depende? Segn se deduce del
enunciado, una sucursal depender nicamente de otra sucursal:
95
96
Diagrama Entidad-Relacin
Direccin Poblacin
Cod_Postal Telfono
Cod_Sucural
SUCURSAL
N:1
1:1
Depender
(1,n)
(1,1
Depender
Cod_Postal
Direccin.
Num_Baos
Importe_Alquiler
Cod_Suc.
Cod_Postal
1:N
(1,1)
De Una sucursal, cuntas sucursales dependan? Pueden ser una o ms de
SUCURSAL
(1,n)
INMUEBLE
Gestionar
una.
(1,1)
(1,n)
Importe_Max
Fecha_Fin
Fecha_Ini
Direccin Poblacin
Cod_Postal Telfono
Cod_Sucural
Trabajar
Alquilar
1:N
N:M
SUCURSAL
(1,n)
1:N
1:1
DNI.
Nombre
Apellido
Telfono
(1,n)
COMERCIAL
CLIENTE
DNI
Depender
Fecha_Contrato
Nombre
Apellidos
(1,1)
N:1
DNI
1:N
Atender
Por lo tanto, estamos ante una cardinalidad N:1.
Precio_Max
Apellidos
Nombre
Telfono
(1,n)
CLIENTE
POTENCIAL
Constructora 17: Diagrama Entidad Relacin Final
97
98
7. DISEO PROPUESTO AL CASO PRCTICO OBRAS DE ARTE

Para la realizacin del diseo conceptual y con el fin de obtener el modelo
entidad-relacin,
identificaremos
los
principales
elementos
del
modelo.
Seguiremos los mismos pasos vistos en los casos prcticos anteriores:

Se necesita almacenar la informacin en una base de datos de los artistas
ms importantes del momento. Se almacenar la informacin de sus obras y de
las sedes donde
han permanecido expuestas. Se presenta a continuacin la
especificacin de los requisitos de forma detallada:

caractersticas tales como, DNI del alumno, nombre del curso, etc.
De los artistas se requiere: DNI, nombre, apellidos, sexo, apodo

(quienes lo tengan), fecha de nacimiento y su direccin de correo
hemos detectado.
electrnico.
surrealista,
impresionista,...) y diferentes tcnicas (leo, escultura, acuarela, .)
Cada estilo y cada tcnica vendrn identificadas por un cdigo y se
electrnico.
Un
artista
puede
trabajar
distintos
estilos
(cubista,
almacenar la informacin de su descripcin.
Un
artista
puede
trabajar
distintos
estilos
(cubista,
surrealista,
De las obras es necesario recoger el nombre de la obra, dimensiones
(alto, largo, ancho), valor de la ltima subasta (si es que ha sido
subastada), valor estimado por el tasador, as como el artista que la
cre. Tambin se recoger informacin del estilo al que pertenece y
de la tcnica empleada.
Adems si la obra ha estado expuesta en alguna sede, se necesita
saber el nombre y la direccin de la sede, as como la exposicin en
cre. Tambin se recoger informacin del estilo al que pertenece y
la que tuvo cabida. Una obra puede haber sido expuesta en varias
de la tcnica empleada.
sedes y en una misma sede varias veces, por lo que es importante
Adems si la obra ha estado expuesta en alguna sede, se necesita
almacenar la fecha en la que se realiz la exposicin.

almacenar la fecha en la que se realizo la exposicin.
99
100
Los tipos de entidades que hemos localizado son: ARTISTA, ESTILO,
A continuacin realizaremos la matriz que nos permitir conocer las
TCNICA, OBRA y SEDE. Del enunciado se podra deducir que SUBASTA es
relaciones existentes entre las entidades. En la primera fila y la primera columna
tambin un tipo de entidad, pero parece ser que solo interesa conocer el valor de
se enuncian los tipos de entidad anteriormente enumerados y se sealar en el
la obra en la ltima subasta, independientemente de la subasta. Parece que
cruce de filas y columnas aquellas interrelaciones que hemos detectado:
dicha entidad no cobra peso en nuestro modelo.
Interrelaciones
ARTISTA
ESTILO
ARTISTA
ESTILO
TCNICA
OBRA
SEDE
2 paso: Identificar y enumerar las posibles interrelaciones, teniendo

en cuenta la siguiente heurstica: en general, una interrelacin viene
TECNICA
OBRA
Trabajar 1
Trabajar 2 Crear 3
Pertenecer 4
Emplear 5
SEDE
Exponer 6
En el texto aparece un nmero correlativo como superndice en los

verbos que indican la posible existencia de una interrelacin.
paso:
Dibujar
las
interrelaciones
(estudiando
el
tipo
de
correspondencia y las cardinalidades) y los tipos de entidad con los
atributos correspondientes.

electrnico.
Un artista puede trabajar1/2 distintos estilos (cubista, surrealista,
Interrelacin Trabajar 1

Las entidades participantes de esta interrelacin son ARTISTA y ESTILO. La
entidad ARTISTA presenta los atributos DNI, nombre, apellidos, sexo, apodo
(quienes lo tengan), fecha de nacimiento y su direccin de correo electrnico.

Como IP se elige el atributo DNI ya que permite identificar de forma nica a
cada uno de los artistas. La entidad ESTILO contar con los atributos Cdigo de
Estilo y Descripcin.
cre3. Tambin se recoger informacin del estilo al que pertenece4 y

de la tcnica empleada5.
Adems si la obra ha estado expuesta6 en alguna sede, se necesita
La figura 1: Interrelacin Trabajar muestra el esquema parcial E/R:
almacenar la fecha en la que se realizo la exposicin.
101
102
DNI
DNI
Cod_Estilo
Fecha_Nac
Apellidos
Nombre Sexo Apodo E-mail
Descripcion
Cod_Estilo
Fecha_Nac
Apellidos
Descripcion
N:M
ARTISTA
Artistas 1:
ARTISTA
ESTILO
Trabajar
Trabajar.
Para
ver
la
(1,n)
ESTILO
Trabajar
Artistas 3: Cardinalidad de la Interrelacin Trabajar
Interrelacin Trabajar 2
Analizaremos a continuacin las cardinalidades mximas y mnimas de la

interrelacin
(1,n)
cardinalidad
de
la
entidad
Artista,
Las entidades participantes de esta interrelacin son ARTISTA y TCNICA.
preguntaremos:
La entidad ARTISTA ya la hemos visto anteriormente. La entidad TCNICA
- Un artista, cuntos estilos trabaja? Puede trabajar un estilo
contar con los atributos Cdigo de Tcnica y Descripcin.
o ms de
uno. (1:N)
La figura 1: Interrelacin Trabajar muestra el esquema parcial E/R:
DNI
Cod_Estilo
Fecha_Nac
Apellidos
Descripcion
DNI
ARTISTA
(1,n)
Trabajar
Cod_Tcnica
Fecha_Nac
Apellidos
Descripcion
ESTILO
ARTISTA
Trabajar
Artistas 2: Cardinalidad de Artista en la interrelacin Trabajar
Artistas 4:
TCNICA
Veremos ahora la cardinalidad de la entidad Estilo:
- Un estilo cuntos artistas lo pueden trabajar? Un estilo lo puede trabajar un

nico artista o ms de uno (1:N)
De la misma forma que en el ejemplo anterior, para ver la cardinalidad de la
entidad Artista, preguntaremos:
- Un artista, cuntas tcnicas trabaja? Puede trabajar una tcnica o ms de
una. (1:N)
103
104
La interrelacin Crear presenta un tipo de cardinalidad de uno a muchos,

DNI
Fecha_Nac
Apellidos
porque una obra ser creada por un nico artista y un artista crear una o varias
Cod_ Tcnica
Descripcion
obras. Esta cardinalidad se representa en la figura 8
ARTISTA
(1,n)
TCNICA
Trabajar
DNI
Artistas 5: Cardinalidad de Artista en la interrelacin Trabajar
Fecha_Nac
Apellidos
Valor_Subasta
Valor_Tasador
Nombre Dimensiones
1:N
ARTISTA
- Una tcnica cuntos artistas la pueden trabajar? Una tcnica la puede
(1,1)
(1,n)
OBRA
Crear
trabajar un nico artista o ms de uno (1:N).

Artistas 8: Cardinalidad de la Interrelacin Crear
DNI
Fecha_Nac
Apellidos
Interrelacin Pertenecer
Cod_Tcnica
Descripcion
Esta interrelacin relaciona a dos entidades que ya han sido analizadas:
N:M
ARTISTA
(1,n)
(1,n)
Trabajar
OBRA y ESTILO.
TCNICA
Analizaremos primero la cardinalidad de la entidad Obra.

Artistas 6: Cardinalidad de la Interrelacin Trabajar
- Una obra, a cuntos estilos pertenece? Pertenecer a uno y solo a uno.
Interrelacin Crear
Valor_Subasta
Valor_Tasador
Nombre Dimensiones
Cod_Estilo
Descripcion
La interrelacin Crear une las entidades OBRA y ARTISTA. Los atributos de la

OBRA
entidad OBRA son: Nombre, dimensiones, valor de la ltima subasta y valor
(1,1)
Pertenecer
ESTILO
estimado por el tasador.

Artistas 9: Cardinalidad de la Entidad Obra
Artistas
Valor_Subasta
Nombre Dimensiones Valor_Tasador
- Un estilo, a cuntas
OBRA
obras.
Artistas 7: En tidad
OBRA
105
106
obra pertenece?
Puede pertenecer a una o ms
Cod_Estilo
Valor_Subasta
Valor_Tasador
Nombre Dimensiones
Descripcion
Interrelacin Exponer
N:1
OBRA
Esta ltima interrelacin relaciona a las entidades OBRA y SEDE. Los
(1,1)
(1,n)
ESTILO
Pertenecer
atributos de la entidad Sede sern Nombre y Direccin. Como identificador

principal elegiremos el atributo Nombre ya que identificar de forma nica a
Artistas 10:
Cardinalidad de la Interrelacin Pertenecer
cada una de las sedes.
Interrelacin Emplear
Esta interrelacin tambin relaciona dos entidades que ya han sido
Nombre
Valor_Subasta
Valor_Tasador
Nombre Dimensiones
analizadas: OBRA y TCNICA. Veremos la cardinalidad de la interrelacin:

- Una obra, cuntas tcnicas emplea? En una obra se emplear una nica
Direccin
OBRA
SEDE
Exponer
tcnica predominante.
Artistas 13: Interrelacin Exponer
Cod_Tcnica
Valor_Subasta
Valor_Tasador
Nombre Dimensiones
Descripcion
Veremos a continuacin las cardinalidades mnimas y mximas de la entidad

OBRA
(1,1)
Emplear
OBRA en la interrelacin Exponer.

TCNICA
- Una obra, en cuntas sedes ha estado expuesta? Una obra puede haber sido
expuesta en varias sedes.
Artistas 11:Cardinalidad de la Entidad Obra en la interrelacin Emplear
Nombre
Valor_Subasta
Valor_Tasador
Nombre Dimensiones
- Una tcnica, en cuntas obras se emplea? Se puede emplear en una o
Direccin
ms obras.
(1,n)
OBRA
Exponer
Artistas 14: Cardinalidad de la Entidad Obra
Cod_Tcnica
Valor_Subasta
Valor_Tasador
Nombre Dimensiones
SEDE
Descripcion
N:1
OBRA
(1,n)
(1,1)
Emplear
- En una sede, cuntas obras se pueden exponer? Una o ms de una.

TCNICA
Artistas 12: Cardinalidad de la Interrelacin Pertenecer
107
108
Diagrama Entidad-Relacin
Nombre
Valor_Subasta
Valor_Tasador
Nombre Dimensiones
Direccin
N:M
OBRA
(1,n)
(1,n)
SEDE
Exponer
DNI
Apellidos
Fecha_Nac
Cod_Estilo
Descripcion
N:M
Artistas 15: Cardinalidad de la Interrelacin Exponer

(1,n)
ARTISTA
(1,n)
Trabajar
ESTILO
(1,1)
(1,1)
Adems, nos indican que Una obra puede haber sido expuesta en una
Cod_Tcnica
(1,n)
misma sede varias veces, por lo que es importante almacenar la fecha en la obra
Descripcion
N:M
1:N
(1,1)
se expuso en la sede.
Crear
Trabajar
(1,n)
TCNICA
Como vemos, nos encontramos con un atributo Fecha de exposicin que

no depende ni de la entidad obra, ni de la entidad Sede sino que depende de la
(1,n)
Valor_Subasta
Dimensiones
Valor_Tasador
Nombre
relacin Exponer: Fecha en la obra se expuso en la sede
OBRA
Valor_Subasta
Valor_Tasador
Nombre Dimensiones
Nombre Direccin
Fecha_Exposicin
N:M
(1,n)
(1,n)
Exponer
Nombre
Direccin
Fecha_Exposicin
N:M
(1,n)
(1,n)
OBRA
(1,n)
(1,n)
Exponer
SEDE
N:1
Artistas 15: Cardinalidad de la Interrelacin Exponer
Emplear
N:1
Pertenecer
109
110
SEDE
El modelo E/R, como todos los modelos, consiste en un conjunto de

conceptos, reglas y notaciones que permiten formalizar la semntica del
mundo real que se pretende modelar (tambin denominada Universo del
Discurso) en una representacin grfica o diagrama que denominamos
esquema de la Base de Datos.
Los elementos bsicos del modelo Entidad/Relacin son:

- Entidades: representan conjuntos de elementos con existencia propia
y que se caracterizan por las mismas propiedades
- Interrelaciones: representan asociaciones del mundo real entre una o
ms entidades
- Atributos: Caractersticas o cualidades propias de las entidades que
queremos recoger dentro de nuestro diseo.
- Dominios: Conjunto de valores sobre los que se definen los atributos
Los pasos que se deben seguir para obtener el modelo Entidad/Relacin

son los siguientes:
- Identificar y enumerar las posibles entidades
- Identificar y enumerar las posibles interrelaciones
- Dibujar las interrelaciones y los tipos de entidad con los atributos
correspondientes.
111
MDULO B
OBJETIVOS
Modelo Relacional
x
x
x
UNIDAD DIDCTICA 2
1. Introduccin
2. Elementos Bsicos del Modelo Relacional
3. Esttica del Modelo Relacional
4. Reglas bsicas para la transformacin del modelo E/R
al modelo relacional
- Modelo Relacional - Caso Prctico Mentor
- Modelo Relacional - Caso Prctico Historia
- Modelo Relacional - Caso Prctico Constructora
- Modelo Relacional - Caso Prctico Arte
5. Introduccin a las formas normales
6. Formas Normales
- Normalizacin Caso Prctico Mentor
x
x
Cules son los elementos bsicos del modelo relacional.

A conocer la parte esttica y dinmica del modelo relacional.
En qu consiste la integridad referencial.
Cules son las reglas bsicas de transformacin del modelo E/R al
modelo relacional.
Conocer las formas normales y aplicar las reglas de normalizacin.
Modelo Relacional
1.
2.
Introduccin
Elementos bsicos del Modelo Relacional

Los elementos bsicos del modelo relacional son las relaciones, cuya
El modelo relacional fue propuesto en 1970 como alternativa a los modelos
representacin grfica se realiza en forma de tabla. En las relaciones se pueden
existentes hasta ese momento por el investigador Edgar Codd, tomando como
distinguir varios tipos de elementos: su nombre, los atributos que contiene y que
base la teora matemtica de las relaciones. Este modelo persegua la sencillez
representan las columnas de la tabla, y las tuplas o filas de la tabla. Adems
de comprensin y de manipulacin de la base de datos por parte del usuario
tambin podemos incluir los dominios que son aquellos conjuntos de donde los
final.
atributos toman los valores.
En un principio el modelo era simplemente un modelo terico objeto de
Supongamos que queremos modelar una base de datos para mantener
investigacin por parte de diversos centros, pero a medida que la tecnologa fue
informacin a cerca de los museos de la Comunidad de Madrid y las exposiciones
evolucionando fueron surgiendo los primeros SGBD que lo soportaban y hoy en
que en ellos se pueden visitar, a travs del modelo de datos relacional. De cada
da el modelo relacional es el ms conocido y difundido por los sistemas
museo se desea almacenar su nombre, la direccin, la zona (Madrid, El Escorial,
comerciales (ORACLE, INFORMIX,... ).
etc) y el nmero de salas que contiene. Tendramos la relacin que se muestra

en la figura 2.43.
La parte esttica del modelo relacional consiste en la definicin de los

objetos permitidos. En la parte dinmica se definen las operaciones que se
pueden realizar con estos objetos y sobre la base de datos.
MUSEO
Para que un SGBD pueda implementar un modelo de datos necesita

apoyarse en un lenguaje de programacin que gestione dicho modelo. El
Nombre
lenguaje aceptado por todos los sistemas de bases de datos comerciales es el
Direccin
Zona
Salas
SQL1, lenguaje estructurado de consulta que permite crear, manipular y obtener

datos de todos los objetos que constituyen la base de datos. Este lenguaje fue
Arqueolgico
Serrano, 13
Madrid
43
Centro de Arte Reina
Santa Isabel, 52
Madrid
21
Plaza de San Diego, S/N
Alcal de Henares
normalizado por la Organizacin Internacional de Estndares (ISO) en 19922 y

sufre, como todos los estndares, revisiones peridicas que hacen que
Sofa
continuamente se editen anexos de la norma. No obstante y como casi todas las

normas, no est soportada por ningn producto comercial, es decir, cada SGBD
Universidad de
incorpora su propio SQL que recoge, dependiendo de cada sistema, lo ms
Alcal de Henares
significativo del estndar.

Figura 2.43: Ejemplo de representacin de una relacin
En este captulo nos vamos a centrar en definir los elementos bsicos del
modelo y explicaremos una metodologa de diseo de bases de datos
relacionales mediante la traduccin de los objetos del modelo E/R explicado en
El nombre de la relacin de la figura es MUSEO, los atributos o columnas son
captulo anterior.
Nombre, Direccin, Zona y Sala. Las tuplas o filas son (Arqueolgico;

Serrano, 13; Madrid; 43), (Centro de Arte Reina Sofa; Santa Isabel, 52; Madrid;
21) y (Universidad de Alcal de Henares; Plaza de San Diego, s/n; Alcal de
1
Structured Query Languaje
Se conoce como SQL92
Henares; 7 ). El atributo Zona pertenece a un dominio Zonas = (Madrid, Alcal

de Henares, Torrejn de Ardoz,...).
115
116
Modelo Relacional
Dentro de una relacin podemos distinguir adems dos nociones: el grado y
3.
Esttica del Modelo Relacional
la cardinalidad. El grado es el nmero de atributos (columnas) que posee la

Una relacin, como se dijo en el apartado anterior se compone de un
relacin, en el caso de nuestro ejemplo el grado sera cuatro. La cardinalidad se
nombre, unos atributos (con sus correspondientes dominios) y un conjunto de
refiere al nmero de tuplas (filas) de la relacin, en nuestro caso tres.
tuplas. Es necesario distinguir entre lo que es la relacin en s y su contenido, es

Hasta ahora hemos hablado de los elementos bsicos del modelo, hemos
decir, una relacin se define mediante un nombre y unos atributos de la
dicho que las relaciones son tablas, pero estas tablas tienen sus limitaciones, no
siguiente manera:
son las tablas que normalmente manejamos; por ejemplo, en estas tablas se
prohibe que exista ms de un valor en cada celda, este tipo de prohibiciones
NOMBRE_RELACIN ( Atributo1: dominio1, Atributo2: dominio2,......, AtributoN: dominioN )
pertenecen a las restricciones inherentes al modelo y las comentaremos ms

adelante en la siguiente seccin.
Figura 2.44: Definicin de relacin
A continuacin presentamos la esttica y la dinmica del modelo relacional

Los dominios son opcionales, pues los atributos pueden tomar valores en un
definiendo formalmente todos los objetos y comentando las sentencias bsicas
conjunto acotado definido previamente, o bien y en principio, ser infinitas las
del lenguaje SQL para tratarlas.
posibilidades de un valor determinado.

El cuerpo de una relacin, es decir, su contenido, es el conjunto de tuplas de
la relacin que, por su propia naturaleza vara con el tiempo, pues no tendra
mucho sentido disponer de una base de datos que almacenara en todo momento
la misma informacin, que esta informacin no variara con el tiempo, ya que en
este caso con disponer de ficheros aislados para almacenarla podramos tener
suficiente3. En la figura 2.45 se muestra un ejemplo de las partes de las que se
compone una relacin.
Definicin de relacin:
ARTISTA (Nombre; Nacionalidad: Nacionalidades; Especialidad: Especialidades)
Contenido de la relacin:
ARTISTA
Nombre
Nacionalidad
Especialidad
Agustn Redondella
Dolores Dahlahaus
Mario Scifano
Nacional
Internacional
Internacional
Pintura
Fotografa
Fotografa
Figura 2.45: Definicin y contenido de una relacin

3
Estos son los llamados ficheros histricos, archivos que recopilan informacin que ya no va a variar,
como podran ser las transacciones efectuadas por los clientes de una sucursal bancaria en el ao 1996.
117
118
Modelo Relacional
Dentro de las relaciones existen principalmente dos tipos: relaciones base y
Pues bien, qu ocurrira si en nuestro mundo real existiesen dos
vistas. Las relaciones base son relaciones con existencia propia, las vistas son
artistas con el mismo nombre, nacionalidad y especialidad. No piense el
relaciones que provienen de otras relaciones base. Un ejemplo de relacin base
lector que este supuesto es tan descabellado, por ejemplo podra darse
sera la relacin ARTISTA de la figura 2.45, una vista sera la relacin obtenida
el caso de un artista contemporneo que coincidiera en nombre con otro
de seleccionar en la relacin anterior aquellos artistas cuya especialidad fuera la
clsico (al no almacenarse la fecha de nacimiento no habra forma de
fotografa, a la que podramos llamar FOTGAFO4.
distinguirlos). Podramos actuar de forma negligente y no almacenar uno

de los dos, con lo cual la obra de este autor quedara sin reflejarse. Otra
Las relaciones se crean mediante el lenguaje SQL con las sentencias
posibilidad sera pensar en aadir un nuevo atributo que identificara a
CREATE TABLE o CREATE VIEW dependiendo del tipo de relacin de que se
cada artista unvocamente dando valores distintos a cada tupla, como
trate.
puede ser un Cdigo de Artista. De esta forma cada tupla sera distinta
de las dems.
Hasta este momento nicamente hemos hablado de los objetos del modelo
relacional, pero no hemos hecho mencin de cmo interactan estos objetos en
Este atributo que identifica unvocamente cada tupla de una relacin es
la base de datos, ni de cmo disear realmente una base de datos en dicho
lo que se denomina en el modelo relacional clave primaria y en SQL se
modelo. Para ello debemos previamente comentar las restricciones, tanto las
define como PRIMARY KEY. Para representar la clave primaria de una
inherentes al modelo, como las restricciones de usuario, que son aquellas que
relacin, se suele poner en negrita el o los atributos implicados en dicha
permiten recoger con la mayor fidelidad posible el mundo real objeto de nuestro
clave.
diseo.
Algn lector avispado podra discrepar de la opcin escogida para

identificar a los artistas de nuestra relacin, pues para qu se elige
introducir un atributo cuyo contenido es tan pobre semnticamente
3.1 Restricciones inherentes.
hablando si, habiendo escogido la Fecha de nacimiento, ste, junto con

- Ningn atributo puede tomar ms de un valor para cada tupla.
el atributo Nombre identificaran por completo todas las tuplas. La
Esto es lo mismo que decir que en cada una de las celdas de una tabla
justificacin de nuestra eleccin radica en motivos de eficiencia, es
que represente una relacin no puede haber ms de un valor. As por
mucho ms eficiente a la hora de almacenar nuestra base de datos, una
ejemplo, no sera vlido que en la relacin ARTISTA el artista Mario
clave primaria corta en el sentido de que va a ser numrica o
Scifano tuviera como especialidades Fotografa y Escultura. Otra cosa
alfanumrica de pocos caracteres, mientras que el nombre y la fecha
distinta sera que en nuestro mundo real un artista pudiera tener varias
ocuparan ms.
especialidades, en cuyo caso deberamos modelar la relacin de otra
Hemos justificado la razn de nuestra eleccin de clave primaria, no
manera, por ejemplo creando otra donde se almacenaran todas las
obstante
posibles especialidades y relacionndola con la primera, como veremos
Nombre
Fecha
de
nacimiento
sera
tambin
un
identificador vlido para la relacin. Este identificador se denomina en el
ms adelante en el captulo.
modelo relacional clave alternativa5. Es decir, una clave alternativa es

aquella que aun pudiendo haber sido escogida como clave primaria de
- No importa el orden ni de las tuplas ni de los atributos.
una relacin, no lo ha sido por otros motivos, como pueden ser motivos
- Todas las tuplas de una relacin deben ser distintas.
de eficiencia, etc.
Ntese que hemos dado un nombre a la vista, pues una vista es un tipo de relacin y por tanto debe
constar de los elementos de toda relacin.
119
120
En SQL se define UNIQUE
Modelo Relacional
Es importante aclarar que se ha hablado de clave primaria y clave
La obligatoriedad de valores en un atributo es tambin una propiedad
alternativa y en el ejemplo hemos mencionado a dos atributos, esto es
de la clave primaria, por su propia definicin.
porque la clave puede estar formada por varios atributos pero siempre
- Integridad Referencial.
ser una sola clave. Una clave primaria es aquella que identifica cada
tupla
podramos
Se podra decir que la integridad referencial trata la forma en la que los
encontrarnos por ejemplo, cuatro atributos de una relacin que
de
una
relacin
de
manera
mnima,
es
decir,
datos de dos o ms tablas se deben relacionar para no atentar contra la
identifiquen perfectamente a cada tupla, pero si con solo tres de ellos
integridad de la base de datos, es decir, para evitar que haya
tambin las podemos identificar, la clave estar formada por esos tres.
informacin no necesaria.
- Regla de integridad de la entidad.
La integridad referencial se controla mediante lo que se denomina

clave ajena. Una clave ajena de una tabla es un atributo o un conjunto
Esta regla hace referencia a que ningn atributo que forme parte de la
de atributos, que es clave candidata6 de otra tabla con la cual est
clave primaria puede tomar un valor nulo.
relacionada la primera, en SQL se define como FOREIGN KEY. Para

aclarar conceptos supongamos que se desean almacenar en la base de
datos de nuestro ejemplo los premios que les han sido concedidos a los
3.2 Restricciones de usuario.
artistas por la Real Academia y, teniendo en cuenta que un premio es

otorgado a un nico artista. Esta relacin PREMIO aparece un la figura
- Valores de uno o varios atributos que no pueden repetirse.
2.4. Se puede observar que posee un atributo Artista que almacena el

Supongamos que, aun con todas las aclaraciones hechas en el
artista al que se le ha concedido cada premio, y que coincide con la clave
apartado de restricciones inherentes, el usuario decide que no puede
primaria de la relacin ARTISTA (Cod_artista); Artista es clave ajena
haber dos artistas con el mismo nombre, esto hara que el atributo
de la relacin PREMIO. Se representa mediante una flecha que sale de la
Nombre fuera nico para cada tupla.
clave ajena y apunta hacia la clave primaria de la tabla con la que se

relaciona.
De aqu se deduce que toda clave primaria es nica tambin, pero el

lenguaje SQL mediante su definicin de clave primaria ya lo contempla.
Existen situaciones en los que el control de la integridad referencial no

es tan sencillo como en el caso anterior. Supongamos que se desean
- Atributos que deben tener siempre valores para todas las tuplas de la
almacenar las Escuelas a las que pertenece cada artista
relacin.
y la relacin
que existe entre cada escuela y los artistas de nuestra base de datos,
Por ejemplo, y en el caso que nos ocupa, supongamos que no est
sabiendo que a una misma escuela pueden pertenecer varios artistas y
permitido que un artista no tenga especialidad definida, esto significara
que un artista puede haber pertenecido a escuelas diferentes (en
obligar a que el atributo especialidad tomara siempre valores, y el SQL lo
distintos periodos de tiempo); en primer lugar debemos crear una
reflejara a travs de NOT NULL.
relacin ESCUELA cuyos atributos sern Cod_escuela (que ser la clave

primaria de la relacin) y Nombre. Para relacionar los artistas con las
El hecho de encontrarnos con atributos que no tengan valores es muy
escuelas, en principio podemos pensar en varias soluciones:
frecuente. Supongamos que en la relacin ARTISTA queremos almacenar

tambin la extensin de la obra de cada autor. Es claro que en muchos
Podramos introducir el atributo Cod_artista en la relacin ESCUELA
casos este dato no se conocer, por tanto tendramos entradas en la
como clave ajena que llamara a la relacin ARTISTA, pero pensemos en
tabla cuya celda correspondiente a la obra estara vaca.

6
121
122
Una clave candidata es aquel atributo o conjunto de atributos que pueden ser clave de una relacin.
Modelo Relacional
las filas de la tabla resultante. Por cada escuela solo tendramos un
* Representacin de la clave ajena por extensin de las relaciones:
artista que perteneciera a ella, puesto que el modelo relacional no

ARTISTA
admite ms de un valor en cada celda, lo que no es correcto.
Cod_artista
Podramos pensar en el caso simtrico e introducir el atributo
0010508
0012454
1200004
Cod_escuela en la relacin ARTISTA. Esto significara que cada artista
Nombre
Especialidad
Nacionalidad
Agustn Redondella
Dolores Dahlahaus
Mario Scifano
Nacional
Internacional
Internacional
Pintura
Fotografa
Fotografa
solo puede pertenecer a una escuela, supuesto que va en contra de lo

que se pide en el enunciado.
PREMIO
Cdigo
Qu hacer entonces?
005-4
234-3
123-5
El problema se resuelve introduciendo una nueva relacin PERTENECE

cuyos atributos sean Cod_artista y Cod_escuela. Adems estos
Nombre
Caminos de hierro
Ballantines
Caja Madrid
Cod_artista
1200004
1200004
0010508
atributos formarn en conjunto la clave primaria y de esta forma
* Representacin de la clave ajena por intensin de las relaciones:
tendremos a cada artista con las distintas escuelas a las que pertenece y
cada escuela con todos sus artistas, como se puede ver en la figura 2.5.
ARTISTA (Cod_artista, Nombre, Nacionalidad, Especialidad)
Podemos incluir dos nuevos atributos Fecha inicio y Fecha fin 7, para
PREMIO (Cdigo, Nombre, Cod_artista)
recoger el periodo de tiempo en que cada artista pertenece a una

escuela
determinada.
Por
ltimo,
tanto
Cod_artista
como
Figura 2.46: Ejemplo de utilizacin de clave ajena
Cod_escuela por separado, son claves ajenas de las relaciones

ARTISTA y ESCUELA respectivamente.
Este atributo puede tomar valores nulos pues los artistas de una determinada escuela pueden seguir
perteneciendo a ella en la actualidad.
123
124
Modelo Relacional
caso de nuestros artistas, se desea recoger la relacin que existe entre

un artista y su maestro, en el caso de que exista; un maestro a su vez
es un artista y por tanto tiene todas las cualidades (atributos) de ellos.

Podramos introducir un atributo Cod_artista_maestro en la relacin
ARTISTA
ARTISTA de manera que fuera clave ajena de ARTISTA que referencia a
Cod_artista
0010508
0012454
1200004
Especialidad
Nacionalidad
Nombre
Agustn Redondella
Dolores Dahlahaus
Mario Scifano
la misma relacin ARTISTA, como se muestra en la figura 2.48.
Pintura
Fotografa
Fotografa
Nacional
Internacional
Internacional
PERTENECE
Cod_escuela
123/7
142/8
241/1
123/7
241/6
Cod_artista
Fecha inicio
Fecha
1200004
1200004
0010508
0012454
0010508
12/10/1965
12/4/1986
1/5/1969
16/2/1975
25/7/1991
12/12/1979
--24/16/1987
-----
ARTISTA
Cod_artista
0010508
0012454
1200004
Nombre
Nacionalidad
Agustn Redondella Nacional

Dolores Dahlahaus Internacional
Internacional
Mario Scifano
Especialidad Cod_artista_maestro
Pintura
Fotografa
Fotografa
0125000
1200004
------
ESCUELA
Nombre
Cod_escuela
123/7
142/8
241/1
241/6
Impresionismo fotogrfico
Surrealismo de luz y sombras
Modernismo Ingls
Cubismo
ARTISTA (Cod_artista, Nombre, Nacionalidad, Especialidad, Cod_artista_maestro)

ARTISTA (Cod_artista, Nombre, Nacionalidad,
PERTENECE (Cod_escuela, Cod_artista, Fecha inicio, Fecha fin)
Como consecuencia de la introduccin de la nocin de clave ajena en
ESCUELA Cod_escuela, Nombre)
las relaciones, se pueden definir ciertas operaciones de borrado y

modificacin que permiten mantener la integridad de los datos de
nuestras bases de datos. Estas operaciones son las siguientes:
- Operacin restringida (NO ACTION8).
Hasta el momento hemos visto como se pueden interrelacionar dos

El borrado (DR) o la modificacin (UR) de las filas de la relacin
relaciones distintas mediante la definicin de clave ajena, pero qu
que contiene la clave ajena no se permite mientras existan tuplas
sucede en el caso de que una relacin deba interrelacionarse con ella
en la relacin a la que se referencia. Esta situacin ocurre por
misma, esta situacin, aunque en principio pueda parecer atpica, ocurre

muchas veces en el mundo real. Supongamos por ejemplo, que en el
125
126
Tambin conocida como RESTRICT
Modelo Relacional
ejemplo
en
la
relacin
ARTISTA
con
la
clave
ajena
4.
Cod_artista_maestro. Solamente eliminamos un artista cuando
Reglas bsicas para la transformacin del modelo E/R al
modelo relacional
no tenga ningn maestro, en caso contrario se rechaza la

En la segunda fase del diseo tenemos que transformar el esquema
operacin.
realizado en el modelo Entidad/Interrelacin a un esquema lgico, ya que no

Tambin se podra dar este tipo de operacin en el caso por
existe ningn Sistema Gestor de Bases de Datos que soporte el modelo E/R. Esta
ejemplo de que en nuestra base de datos de artistas se desee
fase es muy importante ya que para pasar de un esquema a otro debemos
mantener siempre el histrico de todos los premios, en este caso
preservar todas las caractersticas recogidas en la primera de fase. De esta
no debemos permitir borrar ningn artista de la relacin ARTISTA
forma nos aseguraremos que la Base de Datos que implementemos se
al que se le haya concedido algn premio, solo podremos eliminar
corresponda con lo que en un principio queramos recoger y almacenar.
a los artistas que no tienen premios.

En este apartado explicaremos las reglas bsicas para transformar un
- Operacin en cascada (CASCADE).
esquema E/R en un esquema relacional. De esta forma iremos cubriendo todas

las fases del diseo de una base de datos.
En este tipo de operacin, cuando se elimina (DC) o modifica

(UC) una tupla de la relacin que es referenciada, los cambios se
La primera de las reglas de transformacin nos dice que toda entidad se
transmiten en cascada a las tuplas de la relacin que contiene la
transforma en una relacin o tabla, y los atributos o caractersticas asociadas a
clave ajena cuyos valores se han modificado. As por ejemplo en
ella pasan a ser atributos de la relacin.
el caso del apartado anterior, utilizando este tipo de operacin, si

Supongamos que queremos transformar la entidad alumno, Figura 2.51:
borramos un artista se borran tambin todos los datos de su

maestro, por lo que no es la mejor opcin. En cambio, si
utilizamos la operacin CASCADE en la relacin PERTENECE,
D.N.I.
cuando eliminemos un artista, se eliminar la relacin que existe
Nombre Direccin
e-mail
Telfono
entre este y la escuela a la que perteneca, pero no los datos

ALUMNO
propios de la escuela.
Nacionalidad
Estos dos tipos de operaciones sobre la clave ajena son los ms

habituales y los que implementan la mayora de los SGBD
Figura 2.51: La entidad ALUMNO y sus atributos
comerciales. Existen otros dos tipos de operaciones (puesta a

nulos SET NULL y valor por defecto SET DEFAULT) que por su
complejidad y falta de uso en los SGBD no se van a definir aqu,
Segn la regla de transformacin esta entidad pasa a ser una relacin cuyo
no obstante hay una amplia bibliografa sobre el tema, la cual
nombre, en general, es el plural del nombre de la entidad. En nuestro ejemplo,
aparece al final del captulo y que desde aqu animamos a que se
por tanto, se llamar ALUMNOS. Esta relacin tendr como clave primaria
consulte.
(PRIMARY KEY) el identificador principal de la entidad, DNI,

ALUMNOS ( Dni )
como clave alternativa (UNIQUE) el E-mail ya que proviene de un
identificador alternativo,
ALUMNOS ( Dni, E-mail )
127
128
Modelo Relacional
como atributos que no admiten valores (NOT NULL) tenemos Nombre,
CURSO (Nombre, Libro_Consulta*, WWW)
Direccin y Nacionalidad ya que en el esquema E/R son atributos obligatorios,
Donde en la relacin CURSO tenemos como clave primaria el Nombre, como
ALUMNOS ( Dni, E-mail, Nombre, Direccin, Nacionalidad)
alternativa WWW y como atributo que admite valores nulos Libro_Consulta.
Y por ltimo, tenemos un atributo que puede admitir valores nulos, Telfono
Como la interrelacin Matricular tiene correspondencia N:M crearemos una
que proviene de un atributo opcional en el esquema E/R.
nueva relacin compuesta de dos atributos, el DNI del Alumno y el Nombre del
curso donde ambos formarn la clave primaria:
ALUMNOS ( Dni, E-mail, Nombre, Direccin, Nacionalidad, Telfono*)
MATRICULAR (DNI, Nombre)
Como podemos observar la primera regla de transformacin se centra en

uno de los elementos bsicos del modelo E/R, las reglas que nos faltan nos
Cada uno de los atributos de la relacin MATRICULAR sern adems, claves
guiarn para realizar la transformacin del otro elemento importante de este
ajenas que referencian a las relaciones ALUMNOS y CURSO respectivamente, de
modelo: la interrelacin.
esta
forma
nos
aseguramos
que
los
valores
de
estos
atributos
estn
almacenados previamente en las relaciones CURSO y ALUMNOS. Esto significa
La segunda regla de transformacin nos indica que las interrelaciones
que un alumno no puede realizar un curso o lo que es lo mismo, que exista una
cuyo tipo de correspondencia es N:M se transforman en una nueva relacin cuyo
tupla en la relacin MATRICULAR, sin que el alumno o el curso se hallan
nombre se corresponde con el nombre de la interrelacin y donde la clave
registrado como tal.
primaria se compone de los atributos identificadores de las dos entidades que

relaciona.
ALUMNOS ( DNI, Nombre, Direccin, Nacionalidad, E-mail, Telfono*)
Veamos con el ejemplo de la relacin que existe entre ALUMNO y CURSO

cmo se transforma la interrelacin N:M (Figura 2.52).
MATRICULAR ( DNI, Nombre )

Libro de
Nombre
consulta

e-mail
WWW
Figura 2.53: Transformacin de una interrelacin N:M
Telfono
N:M
ALUMNO
Matricular
CURSO
En el esquema relacional de la Figura 2.53 nos faltara representar las
Nacionalidad
opciones de borrado y modificacin que en este caso slo pueden ser o

restringidas o en cascada ya que, tanto el DNI como el Nombre al pertenecer a
la clave primaria de la relacin MATRICULAR no pueden tomar valores nulos ni
Figura 2.52: Interrelacin con correspondencia N:M
valores por defecto.

Si borramos un alumno borraramos todos los cursos que ha realizado?.
El primer paso a realizar es convertir las entidades y sus atributos en las
Para recoger esta caracterstica deberamos tomar la opcin de borrado en
relaciones correspondientes:
cascada al igual que si quisiramos que las modificaciones en la relacin

ALUMNO se propagaran a la relacin MATRICULAR. Por el contrario, si no
queremos borrar a los alumnos que tengan cursos asociados en MATRICULAR

129
130
Modelo Relacional
escogeramos la opcin de borrado restringida. Tomamos la primera alternativa

explicada y razonamos de la misma forma para la clave ajena Nombre.
EMPLEADOS (Cdigo, DNI, Nombre, Direccin, NSS, Telfono, Nombre_D)
DEPARTAMENTO (Nombre , Localizacin, Telfono)
BC:MC
MATRICULAR ( DNI, Nombre )

Figura 2.56: Transformacin de la Interrelacin Trabajar
BC:MC
De
Figura 2.54: Transformacin de una interrelacin N:M con las opciones de borrado y modificacin
esta
departamento
manera
y
que
recogemos
un
que un
departamento
empleado
puede
tener
trabaja
en
asociados
un
solo
distintos
empleados, o lo que es lo mismo, representamos la semntica de una

interrelacin del tipo 1:N aunque perdemos el nombre de la interrelacin.
La
tercera
ltima
regla
nos
indica
que
la
transformacin
de
interrelaciones cuyo tipo de correspondencia es 1:N se traduce en una

propagacin de clave o en una nueva relacin si la interrelacin posee atributos.
Veamos en que consiste el fenmeno de propagacin de clave mediante el
siguiente ejemplo.
Cdigo
DNI Nombre Direccin
Nombre LocalizacinTelfono
N:1
NSS
EMPLEADO
Trabajar
DEPARTAMENTO
Telfono
Figura 2.55: Interrelacin Trabajar con correspondencia 1:N
Transformamos las entidades en relaciones:

EMPLEADOS (Cdigo, DNI, Nombre, Direccin, NSS, Telfono)
DEPARTAMENTO (Nombre, Localizacin, Telfono)
Y para representar el tipo de interrelacin 1:N aadimos un nuevo atributo
en la relacin EMPLEADO, Nombre_D, que ser clave ajena que referencia a la
relacin DEPARTAMENTO.
131
132
Modelo Relacional
Objetos en el modelo E/R
Transformacin al modelo
Entidad: ALUMNO
relacional - Relacin: ALUMNOS
telfono
Para afianzar los conocimientos sobre la aplicacin de las reglas de
ALUMNO
transformacin vamos a retomar retomamos el ejemplo que diseamos el caso
nacionalidad
e-mail
DNI nombre direccin
prctico expuesto en la seccin 1 de esta segunda parte, acerca de una base de
Clave primaria: DNI
Identificador principal: DNI

Atributos
Obligatorios:
Nombre,
Direccin y Nacionalidad
Atributos
NOT
NULL:
Nombre,
Direccin y Nacionalidad
datos para el proyecto MENTOR.

El esquema E/R correspondiente al diseo de la base de datos se muestra
a continuacin:
Nombre
DNI completo e-mail
Entidad:AULAS
nombre
WWW
libro
AULA
N:M
TUTOR
(1, n)
Asociar
(0, n)
cdigo_aula
CURSO
F_Comienzo
Coordinador
relacional - Relacin: AULAS
nombre
direccin
Identificadorprincipal: Cdigo_Aula
Clave primaria: Cdigo_Aula
Atributos Obligatorios: Descripcin,
Atributos NOT NULL: Descripcin,
Direccin
Direccin
(1, n)
F_Finalizacin
Matricular
N:M
Una vez transformadas las entidades, veamos que tipo de interrelacin las
1:N
(1, n)
(1,n)
(1,1)
Pertenecer
AULA
ALUMNO
asocia. Pertenecer tienen un tipo de correspondencia 1:N y adems no contiene
telfono
ningn atributo, por lo que aplicando la tercera regla de transformacin
nacionalidad
propagamos la clave de la relacin AULAS a la relacin ALUMNOS, quedando de

esta manera.
direccin
cdigo_aula
DNI
descripcion
e-mail
nombre direccin
ALUMNOS (DNI. Nombre, Direccin, Telfono*, Nacionalidad, e-mail, aula)
(1,1)
1:N
Mantener
(1,n)
AULAS(Cdigo_Aula, Descripcin, Direccin)
ADMINISTRADOR
e-mail
DNI
nombre
Figura 2.57: Esquema E/R completo
Observar que el nuevo atributo de la relacin ALUMNOS, Aula, no se llama

igual que la clave primaria de la relacin a la que referencia ya que no es
La transformacin la haremos interrelacin a interrelacin, por lo que
necesario que tengan el mismo nombre.Al aadir un nuevo atributo debemos
primero transformaremos las entidades asociadas a estas. Empezaremos por la
pensar en las propiedades del mismo, es decir, si el atributo admite nulos o no, y
interrelacin PERTENECER y las entidades ALUMNO y AULA que asocia.
las opciones de borrado y modificacin de esta, ya que es clave ajena.

133
134
Modelo Relacional
Si obligamos a que el atributo Aula tenga un valor (NOT NULL), estaremos
Si quisiramos borrar la fila o tupla correspondiente al Cdigo_Aula = 01,
recogiendo que un alumno siempre ha de tener un aula asignada. En caso
qu haramos con los alumnos, Juan Lpez y Olga Calle, asignados a esta aula?
contrario, admitiramos que existan alumnos en nuestra Base de Datos que no

Si eligiramos el borrado en cascada se eliminaran de forma automtica las
pertenezcan a ningn aula. Segn se muestra en la siguiente figura, debemos
dos filas en la relacin ALUMNOS correspondientes a estos alumnos. Si no
adoptar la primera propuesta, para no perder informacin recogida en el
queremos perder esta informacin, tendremos que elegir la opcin de borrado
esquema conceptual.
restringuido.
La opcin de modificacin ser en cascada.
Un alumno pertenece a un
y solo un aula
La
1:N
(1,1)
Pertenecer
AULA
(1,n)
DNI
cdigo_aula descripcdireccin
ALUMNO
interrelacin
MANTENER
asocia
la
entidad
AULA
con
la
entidad
telfono
ADMINISTRADOR. Transformaremos esta ltima a una nueva relacin para
nacionalidad
comentar la transformacin de la interrelacin.
e-mail
nombre direccin

Entidad:ADMINISTRADORES
Transformacin al modelo relacional

Relacin: ADMINISTRADORES
Ahora vamos a estudiar las opciones de borrado y modificacin asociadas a

la clave ajena, Aula.
ADMINISTRADOR
Identificador Principal: DNI
Clave Primaria: DNI
Identificador Alternativo: e-mail
Clave Alternativa: e-mail
Atributos Obligatorios: Nombre y
Atributos NOT NULL: Nombre y e-mail
e-mail
DNI
Nombre
Direccin
Telfono
Nacionalidad
e-mail
Aula
Pez,15
4674039
Espaola
Jl@mec.es
01
56321411 Andrea Sols Bronce,25
4801325
Espaola
as@mec.es
03
36952144 Olga Calle
Principe,18
7771482
Espaola
85669900 Jos Prez
La Cruz,1
4671482
No_espaola
07545658 Juan Lpez
oc@mec.es
JP@mec.es
DNI
nombre
e-mail
01
02
Como la interrelacin MANTENER es del tipo 1:N tendremos que aumentar

con un nuevo atributo la relacin ADMINISTRADORES, que nos dar informacin
Cdigo_Aula
Descripcin
Direccin
01
02
03
Los
Carrascales
El Hayedo
La Nogalera
Avd. de Espaa 3,
Cercedilla
Gran Va 10, Coslada
Irn 49,
acerca del cdigo del aula a la que esta asignado un determinado administrador.
ADMINISTRADORES ( DNI, Nombre, e-mail, Aula )

(
AREAS (Cdigo_Aula, Nombre, Direccin)
La interrelacin MATRICULAR es del tipo N:M y asocia las entidades CURSO y

ALUMNO. En la tabla se muestra la transformacin de la entidad Curso.
135
136
Modelo Relacional
ALUMNO
relacional - Relacin: CURSOS
DNI
Nombre
Direccin
Telfono
Nacionalidad
e-mail
Aula
07545658
Juan Lpez
Pez,15
4674039
Espaola
Jl@mec.es
01
Entidad: CURSO
Identificador Principal: Nombre
Clave primaria: nombre
56321411
Andrea Sols
Bronce,25
4801325
Espaola
as@mec.es 03
Identificador Alternativo: WWW
Clave alternativa: WWW
36952144
Olga Calle
Principe,18
7771482
Espaola
oc@mec.es 01
Atributos Obligatorios: WWW
Atributos NOT NULL: WWW
85669900
Jos Prez
La Cruz,1
4671482
No_espaola
JP@mec.es 02
Atributos Opcionales: Libro
Atributos NULL: libro
CURSO
nombre WWW
libro
Aplicando directamente la regla de transformacin para interrelaciones N:M,
MATRICULAR
crearamos una nueva relacin donde incluiramos los atributos asociados a la

interrelacin MATRICULAR, F_Comienzo y F_Finalizacin.
Alumno
Curso
F_Comienzo
F_Finalizacin
07545658
Access 97
23-05-2000
19-12-2000
07545658
Access 2000
23-05-2000
30-01-2001
ALUMNOS (DNI, Nombre, Direccin, Telfono*, Nacionalidad, e-mail, aula)
MATRICULAR ( Alumno, Curso, F_Comienzo, F_Finalizacin)
CURSO
CURSOS ( Nombre, WWW, Libro*)
La clave primaria de la relacin MATRICULAR se compone de dos atributos,
Curso
WWW
Access 97
www.mentor.es/access97.html
Access 2000
www.mentor.es/accss2000.html
Libro
Alumno, que contiene valores de DNIs correspondientes a tuplas que aparecen

en la relacin ALUMNOS y Curso que almacena valores de los nombres de los
cursos que se imparten en el Mentor. Esta clave primaria identifica cada una de
En este caso la clave primaria de MATRICULAR identificara cada una de las
las tuplas pertenecientes a la relacin MATRICULAR?
tuplas, adems de esta forma controlaramos que el mismo alumno no este

matriculado en el mismo curso dos veces.
Supongamos que el alumno Juan Lpez cuyo DNI es 07545658 se matricul

en dos cursos: Access 97 y Access 2000, el 23-05-2000, y finaliz el 19-12-
Discutamos ahora las opciones de borrado y modificacin de las claves
2000 y el 30-1-2001, respectivamente.
ajenas de esta relacin.
137
138
Modelo Relacional
Si borramos una fila de la relacin alumno y este est matriculado en algn
ALUMNOS (DNI, Nombre, Direccin, Telfono*, Nacionalidad, e-mail, aula)
curso. Borraramos las tuplas en las que aparece su DNI en la relacin
BC:MC
MATRICULAR?
MATRICULAR ( Alumno, Curso, F_Comienzo, F_Finalizacin)
Pues parece normal que asi sea, ya que si el alumno se da de baja es mejor
BR:MC
que no aparezca como matriculado en ningn curso del Mentor.
CURSOS ( Nombre, WWW, Libro*)
Qu pasara si diramos de baja un curso? Si borrramos una fila de la

tabla CURSO y en la relacin MATRICULAR aparecen tuplas con el cdigo de este
La ltima interrelacin que nos falta por transformar es ASOCIAR, pero
curso, la opcin de borrar en Cascada hara desaparecer estas filas lo que
primeramente transformaremos la entidad TUTOR, la cual participa en dicha
conllevara que los alumnos que estaban matriculados en este curso no
interrelacin.
aparezcan matriculados en ningn curso.

Eso hara que la base de datos no cumpliera los requisitos especificados en
el modelo Conceptual.
DNI
D.N.I.
Nombre
Direccin
e-mail
Nombre
completo
e-mail
Entidad: TUTOR
relacional - Relacin:TUTORES
TUTOR
Libro
Nombre
F_Comienzo
Telfono
WWW
(1,n)
Matricular
Identificador Principal: DNII
Clave primaria: DNI
Identificador Alternativo: e-mail
Clave alternativa: e-mail
Atributos Obligatorios: Nombre
Atributos NOT NULL: Nombre
completo
completo
F_Finalizacin
M:N
ALUMNO
(1,n)
CURSO
Nacionalidad
Un curso tiene al menos

un alumno matriculado
La interrelacin ASOCIAR es del tipo N:M por lo que tendremos que crear
una nueva relacin.
La mejor opcin de borrado en ese caso sera la restringida, de esta forma
TUTORES (DNI, Nombre_completo, e-mail)
primero avisaramos a los alumnos matriculados en el curso que se pretende

anular para indicarles si quieren matricularse en otro de los cursos del mentor y
de esta forma asignarles al nuevo curso que elijan, para luego proceder a la
ASOCIAR (Tutor, Curso, Es_Coordinador)
eliminacin.
Para las opciones de modificacin en ambas claves ajenas sern en cascada.
CURSOS (Nombre, Libro, WWW)
La clave primaria estar formada por dos atributos, Tutor y Curso, que a su
vez sern claves ajenas que referenciarn a las relaciones TUTORES y CURSOS,
respectivamente.
139
140
Modelo Relacional
Si borramos un curso de la tabla CURSOS borraremos todas aquellas filas en
TUTORES (DNI, Nombre_completo, e-mail)
la tabla ASOCIAR que se relacionen con l y no nos importar que existan
BR/MC
tutores que no se relacionen con cursos porque cumplimos las especificaciones

del modelo conceptual por lo tanto el borrado es en cascada.
ASOCIAR (Tutor, Curso, Es_Coordinador)

BC/MC
DNI
CURSOS (Nombre, Libro, WWW)
Nombre
completo e-mail
Nombre
Libro
WWW
N:M
(1,n)
El esquema relacional definitivo sera el siguiente:

(0,n)
CURSO
Asociar
TUTOR
ADMINISTRADORES (
DNI , Nombre, e-mail, Aula)
BR/MC
AULAS ( Cdigo_Aula , Descripcin, Direccin)
BR/MC
Un tutor puede estar

asignado a 0 o n cursos
ALUMNOS ( DNI , Nombre, Direccin, Telfono*, Nacionalidad, e-mail, aula)

BC:MC
MATRICULAR ( Alumno , Curso , F_Comienzo, F_Finalizacin)
Sin embargo, la opcin de borrado para la clave ajena tutor ser restringida,
BR:MC
de esta forma nos aseguramos que al dar de baja a un tutor en la relacin
CURSOS ( Nombre , WWW , Libro*)
TUTORES dejemos a algn curso sin tutor, esto producira una inconsistencia con
BC/MC
los requisitos especificados.
ASOCIAR ( Tutor, Curso , Es_coordinador)

BR/MC
TUTORES ( DNI , Nombre,_completo,
DNI
Nombre
completo
Nombre
e-mail
Libro
WWW
N:M
(1,n)
TUTOR
(0,n)
Asociar
CURSO
Un curso tiene al menos

un tutor
La opciones de modificacin en ambos casos sera en cascada.
141
142
e-mail)
Modelo Relacional
Analizaremos interrelacin a interrelacin. La primera que analizaremos ser

la interrelacin GOBERNAR, con sus entidades CABALLERO y PROVINCIA.
Recordaremos su representacin en el modelo entidad-relacin:
Veamos a continuacin la transformacin al modelo relacional a partir del

diagrama entidad-relacin que obtuvimos para crear la base de datos de los
Apodo Nombre
Apellido
.
Fecha_Nac
estudiantes universitarios de Historia.
Ao_inicio
Denominacin Num_Hab
Num_Aos
M:N
CABALLERO
Apodo Nombre
.
Fecha_Nac
Ao_inicio
Denominacin
Num_Aos
(1,n)
(0,n)
Gobernar
PROVINCIA
Num_Hab
M:N
CABALLERO
(1,n)
(0,n)
PROVINCIA
Gobernar
(1,n)
M:N
Nombre
(1,n)
Apodo Nombre
Apellido
.
Fecha_Nac
F_Retirada
F_Incorpor
Resultado
Participar
Fecha_Inicio
relacional - Relacin:
Entidad: CABALLERO
M:N
CABALLEROS
CABALLERO
Reinar
Fecha_Fin
Identificador principal: Apodo
Clave primaria: Apodo
Atributos Obligatorios: Nombre,
Atributos NOT NULL:
Apellido, Fecha_Nac
Nombre, Apellido, Fecha_Nac
(1,n)
CRUZADA
Nombre Fecha_Nac
Completo
Corona
(1,n)
REY
relacional
Entidad: PROVINCIA
(1,n)
Denominacin Num_Hab
(1,n)
Relacin: PROVINCIAS
PROVINCIA
Ascender
Identificador principal:
N:M
Clave primaria: Denominacin
Denominacin
Atributos NOT NULL:
Atributos Obligatorios:
Num_Habitantes
143
144
Num_Habitantes
Modelo Relacional
Lo primero que haremos ser transformar las entidades y sus atributos en
CABALLEROS ( Apodo, Nombre, Apellido, Fecha_Nac)
relaciones:
BR:MC
GOBERNAR ( Apodo, Denominacin, Ao_Inicio, Num_Aos)
BR:MC
PROVINCIAS ( Denominacin, Num_Habitantes)
Interrelacin N:M con atributos de la interrelacin y opciones de borrado y actualizacin
Una vez transformadas las entidades, vemos que las cardinalidades entre
ambas en N:M, por lo que aplicando la regla de transformacin para esta
Veamos a continuacin la interrelacin PARTICIPAR en la que intervienen las
interrelacin, crearamos una nueva relacin GOBERNAR donde la clave primaria
entidades CABALLERO y CRUZADA. Recordaremos su representacin en el
se compone de los dos atributos que son clave primaria en las entidades:
modelo entidad-relacin:
GOBERNAR (Apodo, Denominacin)
Nombre
CABALLERO
Segn el diagrama entidad-relacin existen dos atributos que pertenecen a
(1,n)
Nombre
F_Retirada
F_Incorpor
Resultado
N:M
(1,n)
Participar
Fecha_Inicio
Fecha_Fin
CRUZADA
la interrelacin Gobernar: Ao de Inicio, Nmero de Aos, por lo que debemos

representarlos
dentro
de
la
relacin
GOBERNAR
(Apodo,
Denominacin,
Ao_Inicio,Num_Aos).
Lo primero que haremos ser transformar la entidad CRUZADA:
relacional
CABALLEROS ( Apodo, Nom bre, Apellido, Fecha_Nac)
Nombre
Fecha_Inicio
Fecha_Fin
Entidad: CRUZADA
Relacin: CRUZADAS
GOBERNAR ( Apodo, Denominacin, Ao_Inicio, Num_Aos)

CRUZADA
Identificador principal: Nombre
Clave primaria: Nombre
Atributos NOT NULL:
Fecha_Inicio, Fecha_Fin
Fecha_Inicio, Fecha_Fin
Discutiremos a continuacin las opciones de borrado y modificacin de las

claves ajenas de esta relacin.
La interrelacin PARTICIPAR es del tipo N:M por lo que crearemos una nueva
relacin donde la clave primaria ser la unin de las claves primarias de las
Como se desea guardar la relacin existente entre los caballeros y las
relaciones CABALLERO y CRUZADA.
provincias que gobernaron, no debemos permitir el borrado en cascada en la

relacin GOBERNAR. El borrado debe ser restringido y la modificacin en
cascada.
145
146
Modelo Relacional
CABALLEROS ( Apodo, Nom bre, Apellido, Fecha_Nac)

BR:MC
PARTICIPAR ( Nombre_Cruzada, Apodo )
PARTICIPAR ( Nombre_Cruzada, Apodo, Fecha_Incorporacin, Fecha_Retirada, Resultado )

BR:MC
CRUZADAS (Nombre_Cruzada, Fecha_Inicio, Fecha_Fin)

Transformacin de una interrelacin N:M con atributos de la interrelacin y opciones de borrado y
actualizacin
A continuacin analizaremos la interrelacin REINAR. Lo primero que
A la relacin PARTICIPAR debemos aadir los atributos propios de la
haremos ser recordar su representacin en el modelo entidad-relacin.
interrelacin:
Nombre
BR:MC
Fecha_Nac
Corona
M:N
PARTICIPAR ( Nombre_Cruzada, Apodo, Fecha_Incorporacin, Fecha_Retirada, Resultado )

PROVINCIA
(1,n)
(1,n)
REY
Reinar
BR:MC
De esta forma, podremos almacenar la informacin de los caballeros que

Transformaremos
participaron en las distintas cruzadas, con la fecha en la que se incorpor cada
centraremos
uno, su fecha de retirada y el resultado en su cruzada.
las
las
entidad
entidades
REY
ya
que
que
intervienen.
la
entidad
En
este
PROVINCIA
caso,
la
nos
vimos
anteriormente.
Analizaremos por ltimo para esta interrelacin las opciones de borrado y
modificacin. Como no debemos perder la informacin de las cruzadas en las
que participaron los caballeros, el borrado en la relacin PARTICIPAR debe ser
restringido, mientras que la actualizacin sobre la relacin PARTICIPAR ser en

Nombre
cascada, de tal forma que si se actualiza la informacin de las tablas
Fecha_Nac
Corona
relacional
Entidad: REY
Relacin: REYES
CABALLEROS o CRUZADAS, se propague dicha actualizacin sobre la relacin

PARTICIPAR.
REY
147
148
Clave primaria: Nombre
Atributos NOT NULL:
Fecha_Nac, Corona
Fecha_Nac, Corona
Modelo Relacional
Nombre Fecha_Nac
Completo
Vemos que la interrelacin Reinar tiene una cardinalidad M:N, por lo que la
Corona
representacin en el modelo relacional ser la siguiente:
REY
(1,n)
PROVINCIAS ( Denominacin , Num_Habitantes )
(1,n)
REINAR ( Nombre_Rey, Denominacin_Provincia )

Ascender
N:M
REY ( Nombre_Rey, Fecha_Nac, Corona )
Transformacin de una interrelacin M:N
Vemos que la cardinalidad en este caso es N:M. Recodemos que este tipo de
cardinalidades
No debemos permitir el borrado en cascada en la relacin REINAR, ya que
se
resuelven
en
el
modelo
relacional
interesa conservar la informacin de los reyes que reinaron en las diferentes
de las claves primarias de las relaciones a las que asocia.
provincias. Por lo tanto, el borrado ser restringido. La actualizacin, s debe

realizarse en cascada, de tal forma que si actualizamos alguna tupla de las
relaciones PROVINCIAS o REY, se propaque la actualizacin sobre la relacin
REINAR.
PROVINCIAS ( Denominacin , Num_Habitantes )
transformando
la
interrelacin Ascender en un nueva relacin donde la clave primaria es la unin
ASCENDER ( Nombre_Rey, Nombre_Rey_Asc)

BR:MC
REINAR ( Nombre_Rey, Denominacin_Provincia )

BR:MC
Transformacin de una interrelacin M:N con opciones de borrado y modificacin
Por ltimo y para terminar con el modelo relacional, analizaremos la

interrelacin ASCENDER. La relacin REY ya la analizamos en el punto anterior
por lo que recordaremos su representacin en el modelo entidad-relacin:
149
150
Modelo Relacional
MODELO RELACIONAL FINAL

Para obtener el modelo relacional del proyecto de la Constructora, partiremos del
diagrama entidad-relacin, analizaremos cada interrelacin y en funcin de las
cardinalidades,
aplicaremos
la
correspondiente
regla
transformacin.
N:1
Depender
BR:MC
(1,n)
GOBERNAR (Apodo, Denominacin, Ao_Inicio, Num_Aos)
(1,1
BR:MC
Cod_Postal
Direccin.
Num_Baos
Importe_Alquiler

Cod_Suc.
Cod_Postal
BR:MC
1:N
(1,1)
PARTICIPAR (Nombre_Cruzada, Apodo, Fecha_incorporacin, Fecha_Retirada, Resultado)
SUCURSAL
BR:MC
(1,n)
INMUEBLE
Gestionar
(1,1)
(1,n)
Importe_Max
Fecha_Fin
Fecha_Ini
Trabajar
Alquilar
1:N
REY (Nombre_Rey, Fecha_Nac, Corona)
N:M
BR:MC
(1,n)
BR:MC
REINAR( Nombre_Rey, Denominacin_Provincia)
DNI.
Nombre
Apellido
(1,n)
COMERCIAL
CLIENTE
DNI
ASCENDER (Nombre_Rey, Nombre_Rey_Ascendente)
Fecha_Contrato
Nombre
Apellidos
(1,1)
BR:MC
DNI
1:N
Atender
151
152
Apellidos
Nombre
Telfono
(1,n)
CLIENTE
POTENCIAL
Telfono
de
Modelo Relacional
En primer lugar analizaremos ser la interrelacin TRABAJAR, en la que

intervienen
las
entidades
SUCURSAL
COMERCIAL.
Recordaremos
A continuacin, transformaremos las entidades y sus atributos en relaciones:
su
SUCURSAL ( Cod_Suc, Direccin, Cod_Postal, Poblacin, Telfono)
representacin en el modelo entidad-relacin:
COMERCIAL ( DNI, Apellidos, Fecha_Contrato)

Una vez transformadas las entidades, vemos que la interrelacin es del tipo
1:N por lo que aplicando la regla de transformacin, aadiremos un nuevo
Cod_Suc.
Cod_Postal
Nombre
atributo en la relacin COMERCIAL
DNI
SUCURSAL
(1,1)
(1,n)
Trabajar
que
nos
dar
informacin
sobre
la
sucursal en la que estn trabajando los comerciales.
1:N
COMERCIAL
SUCUSAL (Cod_Suc, Direccin, Cod_Postal, Poblacin,_Telfono)
COMERCIAL ( DNI, Apellidos, Fecha_Contrato, Cod_Suc)
Cod_Suc.
Cod_Postal
Transformacin de una interrelacin 1:N
relacional
Entidad: SUCURSAL
Relacin: SUCURSALES
Estudiaremos las opciones de borrado y modificacin de las tuplas. En este
SUCURSAL
Identificador principal: Cod_Suc
Clave primaria: Cod_Suc
Atributos Obligatorios: Direccin,
Atributos NOT NULL: Direccin,
Cod_Postal, Poblacin, Telfono
Cod_Postal, Poblacin, Telfono
caso, no debemos permitir eliminar los comerciales de una sucursal cuando sta
se elimine de la base de datos, por lo que el borrado ser restringido; sin
embargo la modificacin de una sucursal debe propagarse a los comerciales que
trabajan en ella, por lo que la actualizacin debe realizarse en cascada.

Nombre
DNI
COMERCIAL
MC:BR
Entidad: COMERCIAL
COMERCIALES
Clave primaria: DNI
Atributos NOT NULL: Nombre,
Apellidos, Fecha_Contrato
Apellidos, Fecha_Contrato
Transformacin de una interrelacin 1:N con opciones de Modificacin y Borrado
La segunda interrelacin que transformaremos al modelo relacional ser la

denominada
GESTIONAR,
que
relaciona
las
entidades
INMUEBLE
COMERCIAL. Recordemos su representacin en el diagrama entidad-relacin:
153
154
Modelo Relacional
Veremos ahora las acciones en caso de modificacin y borrado. No se debe

eliminar los inmuebles de una determinada sucursal, si dicha sucursal se da de
Cod_Postal
Direccin.
Num_Baos
Cod Inmueble. Num Habitaciones.
Importe_ Alquiler
Cod_Suc.
Cod_Postal
Direccion Poblacin T elfono
baja en la base de datos, por lo que el borrado ser restringido. Ahora bien, si
una Sucursal cambiara de cdigo, la actualizacin se propagara en cascada a
1 :N
(1,n)
(1,1)
SUCURSAL
todos sus registros relacionados en la tabla Inmueble.
INMUEBLE
Gestionar
Nombre
DNI
COMERCIAL
BR:MC
INMUEBLE ( Cod_Inmueble, Direccin, Cod_Postal, Num_Habitaciones, Num_Baos, Importe_Alquiler, Cod_Suc)
Entidad: INMUEBLE
Transformacin de una interrelacin 1:N con opciones de modificacin y borrado
INMUEBLES
Clave primaria: Cod_Inmueble
Pasaremos a transformar la interrelacin Alquilar que relaciona las entidades
Cod_Inmueble
CLIENTE e INMUEBLE. Su representacin en el diagrama e-r es la siguiente:
Atributos NOT NULL: :

Atributos Obligatorios: Direccin,
Direccin, Cod_Postal,
Cod_Postal, Num_Habitaciones,
Num_Habitaciones, Num_Baos,
Num_Baos, Importe_Alquiler
Importe_Alquiler
DNI.
Nombre
Apellidos
T elfono
Cod_Postal
Direccin.
Num_Baos
Cod Inmueble. Num Habitaciones.
Fecha_InicFecha_Fin
Importe_ Alquiler
Importe_Max
N:M
(1,n)
CLIENTE (real)
(1,n)
Alquilar
INMUEBLE
Igual que en la interrelacin anterior (Trabajar), la interrelacin Gestionar

presenta una cardinalidad 1:N, por lo que aplicaremos la misma regla de
transformacin para pasar al modelo relacional. Aadiremos un nuevo atributo
La tabla que se muestra a continuacin presenta la transformacin de las
en la relacin INMUEBLE que nos dar informacin sobre la sucursal en la que se
entidades en relaciones:
est gestionando su alquiler.
DNI.
Nombre
Apellidos
Telfo
relacional - Relacin: CLIENTES
Entidad: CLIENTE
INMUEBLE ( Cod_Inmueble, Direccin, Cod_Postal, Num_Habitaciones, Num_Baos, Importe_Alquiler, Cod_Suc)
CLIENTE (real)
Transformacin de una interrelacin 1:N
155
156
Clave primaria: DNI
Atributos NOT NULL Nombre,
Apellidos y Telfono
Apellidos y Telfono
Modelo Relacional
La interrelacin ALQUILAR es del tipo N:M por lo que crearemos una nueva
CLIENTE ( DNI, Nombre, Apellidos, Telfono)
relacin donde la clave primaria ser la unin de las claves primarias de las
BR:MC
relaciones CLIENTE e INMUEBLE.
ALQUILAR ( DNI, Cod_Inmueble, Fecha_Inicio, Fecha_Fin, Importe_Max )

BR:MC
INMUEBLE ( Cod_Inmueble, Direccin, Cod_Postal, Num_Habitaciones, Num_Baos, Importe_Alquiler)

Transformacin de una interrelacin N:M con atributos de la interrelacin y opciones de
ALQUILAR ( DNI, Cod_Inmueble )
borrado y actualizacin
La siguiente interrelacin que vamos a transformar al modelo relacional es la

interrelacin Atender que relaciona las entidades CLIENTE POTENCIAL y
COMERCIAL. Su representacin en el diagrama e-r es la siguiente:
Debemos aadir los atributos propios de la interrelacin ALQUILAR: Fecha

de inicio, fecha de fin e importe mximo mensual del alquiler.
DNI
Apellidos
Precio_Max
Nombre
Telfono
Nombre
N:1
ALQUILAR ( DNI, Cod_Inmueble, Fecha_Inicio, Fecha_Fin, Importe_Max )
CLIENTE
POTENCIAL
(1,n)
DNI
(1,1)
Atender
COMERCIAL
Una vez aadidos estos atributos a la interrelacin, podremos conocer la

informacin de la fecha de inicio, la fecha de fin y el importe mximo que pag
cada cliente por el alquiler del inmueble.
DNI.
Analizaremos por ltimo para esta interrelacin las opciones de borrado y

modificacin. Como en nuestra base de datos interesa almacenar la relacin
Apellidos
Nombre Telfono Precio_Max
CLIENTE
POTENCIAL
existente entre los clientes y los inmuebles, no se debe permitir el borrado en

cascada en la relacin ALQUILAR, por lo que el borrado debe ser restringido.
La modificacin se realizar en cascada, de tal forma que si se modifica el

cgido de un cliente o el cdigo de un inmueble, dichas modificaciones se
propaguen en sus tuplas correspondientes de la relacin ALQUILAR.
157
158
relacional - Relacin: CLIENTES
Entidad: CLIENTE POTENCIAL
POTENCIALES
Clave primaria: DNI
Apellidos, Telfono, Precio_Max
Apellidos, Telfono, Precio_Max
Modelo Relacional
Direccin Poblacin
Cod_Postal Telfono
Cod_Sucural
CLIENTE POTENCIAL (DNI, Nombre, Apellidos, Telfono, Precio_Max DNI_Comercial)
SUCURSAL
1:N
1:1
Igual que en las interrelaciones Gestionar y Trabajar vistas anteriormente, la

Depender
interrelacin Atender presenta una cardinalidad 1:N. En este caso, aadiremos
N:1
un nuevo atributo en la relacin CLIENTE POTENCIAL que nos dar informacin

sobre el COMERCIAL que le atiende en la bsqueda de un alquiler.
Aplicando la regla de transformacin para cardinalidad 1:N, aadiremos en la tabla

Sucursal un nuevo atributo:
permitir eliminar un COMERCIAL de nuestra base de datos mientras existan
Clientes Potenciales asociados al comercial, por lo que el borrado ser
SUCURSAL (Cod_Suc, Direccin, Cod_Postal, Poblacin, Telfono, Cod_Suc)
restringido. Sin embargo, la actualizacin debe realizarse en cascada.
Transformacin de una interrelacin N:1 con opciones de borrado y actualizacin

BR:MC
CLIENTE POTENCIAL (DNI, Nombre, Apellidos, Telfono, Precio_Max DNI_Comercial)
Por ltimo analizaremos la interrelacin Depender, donde la entidad Sucursal

se relaciona consigo misma. Recordemos la representacin en el diagrama
entidad-relacin.
159
160
Modelo Relacional
SUCURSAL ( Cod_Suc, Direccin, Cod_Postal, Poblacin, Telfono, Cod_Suc)

A partir del
diagrama entidad-relacin que obtuvimos en nuestro ejemplo
de las Obras y Artistas, crearemos el modelo relacional. Para ello, iremos
BR:MC
analizando cada una de las interrelaciones tal y como hemos hecho hasta ahora.
COMERCIAL (Dni, Apellidos, Fecha_Contrato, Cod_Suc)

BR:MC
CLIENTE_POTENCIAL (DNI, Nombre, Apellidos, Telfono, Precio_Max, DNI_Comercial)
DNI
Apellidos
Fecha_Nac
Cod_Estilo
Descripcion
N:M
INMUEBLE (Cod_Inmueble, Direccin, Cod_Postal, Num_Habitaciones, Num_Baos, Importe_Alquiler, Cod_Suc)

(1,n)
ARTISTA
(1,n)
Trabajar
BR:MC
ALQUILAR (DNI, Cod_Inmueble, Fecha_Inicio, Fecha_Fin, Importe_Max)
ESTILO
(1,1)
BR:MC
(1,1)
BR:MC
Cod_Tcnica
(1,n)
CLIENTE (DNI, Nombre, Apellidos, Telfono)
Descripcion
N:M
1:N
(1,1)
Crear
Trabajar
(1,n)
TCNICA
(1,n)
Valor_Subasta
Valor_Tasador
Nombre Dimensiones
OBRA
Nombre Direccin
Fecha_Exposicin
N:M
(1,n)
(1,n)
Exponer
(1,n)
(1,n)
N:1
Emplear
N:1
Pertenecer
161
162
SEDE
Modelo Relacional
Analizaremos en primer lugar la interrelacin Trabajar en la que intervienen

las entidades ARTISTA y ESTILO.
La interrelacin TRABAJAR presenta una cardinalidad del tipo N:M por lo que
crearemos una nueva relacin donde la clave primaria ser la unin de las claves
DNI
primarias de las relaciones ARTISTA y ESTILO.
Cod_Estilo
Fecha_Nac
Apellidos
Descripcion
N:M
ARTISTA
(1,n)
(1,n)
Trabajar
ARTISTA ( DNI, Nombre, Apellidos, Sexo, Fecha_Nac, Apodo, E-mail)
ESTILO
TRABAJAR ( DNI, Cod_Estilo)
ESTILO (Cod_Estilo, Descripcin)
DNI
Fecha_Nac
Apellidos
Una
relacional - Relacin: ARTISTAS
vez
obtenido
este
modelo
relacional,
analizaremos
para
esta
interrelacin las opciones de borrado y modificacin. Como se desea guardar la
Entidad: ARTISTA
relacin existente entre los artistas y sus estilos, no debemos permitir el borrado
ARTISTA
Clave primaria: DNI
Apellidos, Sexo, Fecha_Nac,
Apellidos, Sexo, Fecha_Nac,
Apodo, E- Mail
Apodo, E- Mail
en cascada sobre la relacin TRABAJAR, por lo que el borrado debe realizarse de

forma restringida. La modificacin, sin embargo, se realizar en cascada.

BR:MC
TRABAJAR ( DNI, Cod_Estilo)

Cod_Estilo
Descripcion
BR:MC
relacional- Relacin: ESTILOS
Entidad: ESTILOS
ESTILO
Transformacin de una interrelacin N:M con opciones de borrado y actualizacin
Clave Primaria: Cod_Estilo
Cod_Estilo
Atributos NOT NULL:
Cod_Estilo, Descripcin
Veremos a continuacin la interrelacin Trabajar (2), en la que intervienen
Cod_Estilo, Descripcin
las entidades ARTISTA y TCNICA.
163
164
Modelo Relacional
Las opciones de modificacin y borrado sern la mismas que las vistas en la

interrelacin TRABAJAR (Artista y Estilo): Borrado restringido y modificacin en
DNI
Cod_Tcnica
Fecha_Nac
Apellidos
cascada.
Descripcion
N:M
ARTISTA
(1,n)
(1,n)
Trabajar
TCNICA

BR:MC
TRABAJAR ( DNI, Cod_Tcnica)

BR:MC
TCNICA (Cod_Tcnica, Descripcin)

relacional
Entidad: TCNICA
Cod_Tcnica
Descripcion
TCNICA
Relacin: TCNICAS
A continuacin transformaremos la interrelacin Crear:
Clave Primaria: Cod_Tcnica
Cod_Tcnica
DNI
Atributos NOT NULL:
Fecha_Nac
Apellidos
1:N
Cod_Tcnica, Descripcin
Valor_Subasta
Valor_Tasador
Nombre Dimensiones
Cod_Tcnica, Descripcin
ARTISTA
(1,1)
(1,n)
Crear
OBRA
La interrelacin TRABAJAR(2) presenta, al igual que la interrelacin vista

anteriormente, una cardinalidad del tipo N:M. Aplicaremos la misma regla de
transformacin, creando una nueva relacin donde la clave primaria ser la
Objetos en el modelo
E/R
relacional
unin de las claves primarias de las relaciones ARTISTA y TCNICA.

Valor_Subasta
Valor_Tasador
Nombre Dimensiones

OBRA
Entidad: OBRA
Relacin: OBRAS
Clave Primaria: Nombre
Nombre
Atributos NOT NULL:
TRABAJAR ( DNI, Cod_Tcnica)

Dimensiones, ValorSubasta,
Dimensiones,
ValorTasador
ValorSubasta, ValorTasador
165
166
Modelo Relacional
Esta vez, la interrelacin CREAR, presenta una cardinalidad del tipo 1:N.
Para su transformacin al modelo relacional, aadiremos un nuevo atributo en la
Cod_Estilo
Valor_Subasta
Valor_Tasador
Nombre Dimensiones
relacin OBRA que nos dar informacin sobre el ARTISTA que la cre.
Descripcion
N:1
OBRA
(1,n)
(1,1)
Pertenecer
ESTILO
ARTISTA (DNI, Nombre, Apellidos, Telfono, Sexo, Fecha_Nacimiento, Apodo, E-mail)
De nuevo nos encontramos con una cardinalidad del tipo 1:N. Para su
transformacin al modelo relacional, aadiremos un nuevo atributo en la relacin
OBRA ( Nombre, Dimensiones, Valor_Subasta, Valor_Tasador, DNI)
OBRA que nos dar informacin sobre el ESTILO al que pertenece.

permitir eliminar las obras pertenecientes a un artista, cuando este se borre de
la base de datos, por lo que el borrado ser restringido. En cambio la
modificacin de un artista debe realizar la modificacin en cascada de sus obras.
OBRA ( Nombre, Dimensiones, Valor_Subasta, Valor_Tasador, Cod_Estilo)

ARTISTA (DNI, Nombre, Apellidos, Telfono, Sexo, Fecha_Nacimiento, Apodo, E-mail)
BR:MC
OBRA ( Nombre, Dimensiones, Valor_Subasta, Valor_Tasador, DNI)
En cuanto a las opciones de modificacin y borrado, no se permitir eliminar

un estilo miestras existan obras que pertenezcan a dicho estilo. En cambio, si
modificamos los datos del estilo se modificarn en cascada todas las obras de
dicho estilo.
El siguiente paso ser analizar la interrelacin PERTENECER, donde

intervienen dos entidades ya vistas anteriormente: OBRA y ESTILO.

BR:MC
OBRA ( Nombre, Dimensiones, Valor_Subasta, Valor_Tasador, Cod_Estilo)
167
168
Modelo Relacional
Una de las ltimas interrelaciones de nuestro modelo entidad-relacin es

EMPLEAR, en la que participan dos entidades ya vistas anteriormente:
Cod_Tcnica
Valor_Subasta
Valor_Tasador
Nombre Dimensiones
Descripcion
Por ltimo analizaremos la interrelacin EXPONER, donde intervienen dos
N:1
OBRA
(1,n)
(1,1)
Emplear
entidades: OBRA y SEDE.

TCNICA
Nombre
Valor_Subasta
Valor_Tasador
Nombre Dimensiones
OBRA
Aplicando la regla correspondiente de transformacin para cardinalidades del
Direccin
Fecha_Exposicin
N:M
(1,n)
(1,n)
Exponer
SEDE
tipo N:1, aadiremos un nuevo atributo en la relacin OBRA que nos dar
informacin sobre la tcnica empleada.

Transformacin al
modelo relacional
OBRA ( Nombre, Dimensiones, Valor_Subasta, Valor_Tasador, Cod_Estilo, Cod_Tcnica)
Entidad: SEDE
Nombre
Direccin
En cuanto a las opciones de borrado y actualizacin, no eliminaremos una

SEDE
tcnica de nuestra base de datos mientras tenga obras realizadas con dicha
tcinica. Si una Tcnica cambiara de cdigo, la actualizacin se propagara en
Relacin: SEDES
Clave Primaria: Nombre
Atributos Obligatorios: Direccin
Atributos NOT NULL:

Direccin
cascada a sus registros relacionados en la tabla OBRA.
La cardinalidad de la interrelacin es del tipo N:M. Aplicaremos la regla de
transformacin, por lo que crearemos una nueva relacin donde la clave primaria
BR:MC
ser la unin de las claves primarias de las relaciones SEDE y OBRA.
OBRA ( Nombre, Dimensiones, Valor_Subasta, Valor_Tasador, Cod_Estilo, Cod_Tcnica)
169
170
Modelo Relacional

SEDE (Nombre, Direccin)
EXPONER ( Nombre_Sede, Nombre_Obra)

BC:MC
OBRA (Nombre, Dimensiones, Valor Subasta, Valor Tasador, Cod_Estilo, Cod_Tcnica )
TRABAJAR_ESTILO (DNI, Cod_Estilo)

Para poder conocer la fecha de exposicin de las obras en las distintas
BC:MC
sedes, ser necesario aadir un atributo ms: Fecha de Exposicin.
BC:MC
BC:MC
TRABAJAR_TECNICA (DNI, Cod_Tcnica)

BC:MC
EXPONER ( Nombre_Sede, Nombre_Obra, Fecha_Exposicin)
TECNICA (Cod_Tcnica, Descripcin)

BC:MC
OBRA (Nombre, Dimensiones, Valor Subasta, Valor Tasador, Cod_Estilo, Cod_Tcnica )
Analizaremos a continuacin las opciones de Modificiacin y Borrado.
OBRA (Nombre, Dimensiones, Valor_Subasta, Valor_Tasador, DNI, Cod_Estilo, Cod_Tcnica)

Como nos interesa almacenar la informacin de las obras expuestas en las
BC:MC
distintas sedes, no se permitir el borrado en cascada sobre la relacin

EXPONER. El borrado debe ser restringido. Sin embargo, la actualizacin se
EXPONER(Nombre_Sede, Nombre_Obra, Fecha_Exposicion)
realizar en cascada.
BC:MC
BC:MC
EXPONER ( Nombre_Sede, Nombre_Obra, Fecha_Exposicin)

BC:MC
OBRA (Nombre, Dimensiones, Valor Subasta, Valor Tasador , Cod_Estilo, Cod_Tcnica)

171
172
Modelo Relacional
5. Introduccin a las Formas Normales

6. Formas Normales
Dada una relacin y un conjunto de dependencias funcionales. Si la relacin

no tiene un buen nivel de diseo, la normalizacin propone una descomposicin
1FN
de la relacin teniendo en cuenta que:
M La descomposicin debe ser sin prdida de informacin.
Se dice que una relacin est en 1FN cuando no existen tuplas repetidas.
Todas las relaciones tienen que estar, al menos en 1FN.
N Si es posible, deben mantenerse las dependencias funcionales originales.
Ejemplo: Supongamos la siguiente relacin:
Dependencia funcional es la relacin existente entre atributos.

Las dependencias funcionales se representan con una flecha de la
forma AJB y la lectura sera la siguiente, el atributo A determina a
B o el atributo B es dependiente del atributo A.
TRABAJADORES (NOMBRE, TITULACIN)
TRABAJADORES (NOMBRE, TITULACIN)
NOMBRE
TITULACIN
NOMBRE
Miguel
Pintor
Miguel
TITULACIN
Pintor
Isabel
Industrial
Isabel
Industrial
Por qu se normalizan las bases de datos relacionales?
Felipe
Felipe
Felipe
Felipe
Para:
Felipe
Agrnomo
Felipe
Agrnomo
Miguel
Pintor
x Evitar la redundancia de los datos.
x Evitar problemas de actualizacin de los datos en las tablas.
x Proteger la integridad de los datos.
No cumple la 1FN ya que hay

tuplas repetidas
Cumple la 1FN ya que no hay

tuplas repetidas
Existen seis niveles de normalizacin de una relacin (1FN, 2FN, 3FN, FNBC,
2FN
4FN y 5FN). Una relacin se encuentra en uno u otro grado de normalizacin si

cumple una serie de propiedades (restricciones).
Se dice que una relacin se encuentra en 2FN si:
Las tres primeras formas normales la defini Codd y se basan en las
- Se encuentra en 1FN
dependencias funcionales que existen entre los atributos de la relacin. Ms
- Cada atributo de la relacin, que no es clave primaria, tiene dependencia

funcional completa respecto del atributo que es clave, siempre que esta
clave est compuesta por ms de un atributo. Si la clave primaria est
compuesta por un nico atributo, ya estara en 2FN.
tarde y debido a que todava existan anomalas, redefini la 3FN y la denomin

Forma Normal de Boyce Codd (FNBC). Posteriormente, basndose en las
dependencias multivaluadas y en combinacin se definieron dos niveles ms de
normalizacin, la 4FN y 5FN respectivamente. La 5FN es el grado mximo de
normalizacin que puede alcanzar una relacin.
MATRCULA
DNI, ASIGNATURA, APELLIDOS, NOMBRE, NOTA, CURSO)
y Clave primaria compuesta por los atributos:
Las relaciones en 1FN tienen ms redundancia de datos que los niveles
y Dependencias funcionales:
superiores, y por lo tanto, ms anomalas a la hora de actualizar los datos.
DNI
DNI
determinan el
ASIGNATURA
ASIGNATURA
173
174
determinan una
NOMBRE
determinan
NOTA
APELLIDOS
CURSO
DNI, ASIGNATURA
(DNI,ASIGNATURAJNOTA)
(DNIJ NOMBRE y DNIJ APELLIDOS)
(ASIGNATURA J CURSO)
Modelo Relacional
La relacin no se encuentra en 2FN ya que existe una dependencia

funcional no completa entre atributos de la relacin que no forman parte
de la clave primaria y la clave primaria:
DNIJ NOMBRE
DNIJ APELLIDOS
ASIGNATURA
3FN
Se dice que una relacin est en 3FN si satisface la 2FN y cada atributo no
J CURSO
primario no depende de forma transitiva de la clave primaria, es decir,

dependern directamente de la clave primaria.
El DNI determina, por s slo al NOMBRE y al APELLIDOS, en este caso el

campo ASIGNATURA no es imprescindible para la obtencin de los atributos
NOMBRE y APELLIDOS.

MATRCULA
Solucin:
(ASIGNATURA, AULA, LUGAR)
y Clave primaria:
Para eliminar estos inconvenientes es necesario realizar un proceso

de descomposicin de la relacin MATRCULA en dos relaciones que
satisfagan la 2FN. La estructura de estas relaciones seran las
siguientes:
ASIGNATURA
ASIGNATURA
J AULA
AULA
J LUGAR
ASIGNATURA
J LUGAR
Esta relacin no est en 2FN ya que en la dependencia funcional

IMPARTE
(ASIGNATURA,
MATRCULA
(DNI,
La relacin
CURSO)
no se cumple que el atributo
ASIGNATURA, NOMBRE, APELLIDOS, NOTA)
primaria
se encuentra en 2FN. La clave de esta relacin es

ASIGNATURA y el nico atributo que no es clave primaria tiene una
dependencia completa de la clave primaria (ASIGNATURAJ CURSO).
AULA
LUGAR
tenga una dependencia completa de la clave
y adems existe una dependencia transitiva entre la clave

LUGAR.
Solucin:
La relacin matrcula no se encuentra en 2FN ya que an se
Descomposicin de la relacin
mantiene las dependencias funcionales no completas:

DNIJ NOMBRE
ASIGNATURA
primaria y el atributo
IMPARTE
LUGAR
MATRCULA (ASIGNATURA, AULA, LUGAR)
en:
UBICACIONES (AULA, LUGAR)
DNIJ APELLIDOS
CLASES (ASIGNATURA, AULA)
Solucin:
Descomponer la relacin MATRCULA (DNI,
en:
ALUMNOS
(DNI,
MATRICULACIN
Forma Normal de Boyce Codd (FNBC)
ASIGNATURA, NOMBRE, APELLIDOS, NOTA)
El antecedente de cada dependencia funcional debe ser clave.
NOMBRE, APELLIDOS)
(DNI,
ASIGNATURA, NOTA)
ALUMNOS
De la relacin de partida hemos obtenido la siguiente descomposicin:

MATRCULA
(ASIGNATURA,
MATRCULA
ALUMNOS
(DNI,
(DNI,
NOMBRE_APELLIDOS, DIRECCIN, LOCALIDAD, PROVINCIA)

DNI
DNI, ASIGNATURA, APELLIDOS, NOMBRE, NOTA, CURSO)
IMPARTE
(DNI,
y Clave primaria:
Conclusin:
DNI
J NOMBRE_APELLIDOS
DNIJLOCALIDAD
LOCALIDADJPROVINCIA
CURSO)
ASIGNATURA, NOTA)
NOMBRE, APELLIDOS)
DNI
JDIRECCIN
DNIJPROVINCIA
Todas las dependencias funcionales cumplen que el antecedente es

clave excepto la dependencia funcional: LOCALIDADJPROVINCIA
Solucin:
Descomposicin de la relacin
LOCALIDAD, PROVINCIA) en:
175
176
ALUMNOS
(DNI,
NOMBRE_APELLIDOS, DIRECCIN,
Modelo Relacional
ALUMNOS
(DNI,
LOCALIDADES
NOMBRE_APELLIDOS, DIRECCIN, LOCALIDAD)
PERSONAL
PROFESOR, MATERIA, CENTRO)
(LOCALIDAD, PROVINCIA)
La 4FN y 5FN tienen que ver con atributos multivaluados
4FN
PROFESOR
MATERIA
CENTRO
Juan Juanas
Informtica
C1
Juan Juanas
Informtica
C2
Susana Lus
Biologa
C1
Susana Lus
Geologa
C2
Susana Lus
Biologa
C1
Es posible que existan anomalas de insercin, borrado y modificacin en una

relacin provocados por motivos distintos a las dependencias funcionales que
hemos
visto
hasta
ahora.
El
principal
motivo
son
las
Un profesor puede dar clase de distintas materias en centros distintos.
dependencias
multivaluadas. Este tipo de dependencias surgen al normalizar estructuras
El diseo de esta tabla sera correcto si no se realizaran ningn tipo de
que no estn en 1FN presentando valores repetidos.
restriccin ms.
Supongamos que en el enunciado para crear la base de datos nos piden

que tengamos en cuenta la siguiente consideracin:
PERSONAL
DNI, NOMBRE, APELLIDOS, PROFESIN, DIRECCIN, TLF)
Cuando un profesor est autorizado para trabajar en un centro

DNI
NOMBRE
APELLIDOS
PROFESIN
DIRECCIN
TLF
000000
Juan
Prez
Juez, Pintor
Margarita,1
666666666
111111
Ana
Juanas
Fiscal, Pianista
Geranio,2
555555555
222222
Raquel
Martn
Profesora
Jacinto, 44
777777777
Observamos que existe una redundancia de datos en la tabla de
para impartir Informtica, el profesor puede trabajar en dicho

centro.
PROFESORES-MATERIAS
PERSONAL
PROFESOR, MATERIA)
PROFESOR
MATERIA
Juan Juanas
Informtica
Juan Juanas
Informtica
Susana Lus
Biologa
Separar en dos tablas, en una de ellas quedaran reflejadas las
Susana Lus
Geologa
profesiones del personal y en la otra sus datos personales.
Susana Lus
Biologa
ya que por cada una de las titulaciones de cada persona se repiten todos
sus datos personales.
Solucin:
PERSONAL
PROFESORES-CENTROS
PERSONAL
MATERIAS-CENTROS
DNI, PROFESIN)
PROFESOR
MATERIA
C1
Juan Juanas
C2
Susana Lus
C1
Susana Lus
C2
Susana Lus
C1
MATERIA, CENTRO)
PROFESOR
MATERIA
Informtica
C1
DNI, NOMBRE, APELLIDOS, DIRECCIN, TLF)
5FN
Informtica
C2
Biologa
C1
Para que una relacin est en 5FN, deber estar en 4FN y la relacin no podr
Geologa
C2
ser descompuesta en otras, adems se debe cumplir que toda dependencia
Biologa
C1
multivaluada es consecuencia de la clave primaria.

177
178
PROFESOR, CENTRO)
Juan Juanas
DNI, NOMBRE, APELLIDOS, PROFESIN, DIRECCIN, TLF)
PROFESIONES
Modelo Relacional
Relacin ADMINISTRADORES (DNI, NOMBRE, E-MAIL, AULA)

(1) Dependencias funcionales obtenidas:
DNI nombre
Veamos a continuacin si el modelo relacional obtenido en el Caso Prctico
DNI e-mail
DNI aula
(2) comprobar el estado de Normalizacin de la relacin
Mentor se encuentra en forma normal de Boice-Codd.
1 FN
El modelo relacional obtenido del caso prctico Mentor fue el siguiente:
Se dice que una relacin est en 1FN cuando no existen tuplas o registros
repetidos.
ADMINISTRADORES (
La relacin est en primera forma normal ya que al tener una clave

primaria definida, el sistema no permitir registros repetidos.
DNI , Nombre, e-mail, Aula)
2FN
BR/MC
AULAS ( Cdigo_Aula , Descripcin, Direccin)
BR/MC
Se dice que una relacin se encuentra en 2FN si:
ALUMNOS ( DNI , Nombre, Direccin, Telfono*, Nacionalidad, e-mail, aula)
- Se encuentra en 1FN
BC:MC
- Cada atributo de la relacin, que no es clave primaria, tiene dependencia
MATRICULAR ( Alumno , Curso , F_Comienzo, F_Finalizacin)
funcional completa respecto del atributo que es clave, siempre que esta
clave est compuesta por ms de un atributo. Si la clave primaria est
BR:MC
compuesta por un nico atributo, ya estara en 2FN.
CURSOS ( Nombre , WWW , Libro*)

BC/MC
La relacin est en 2FN ya que la clave primaria est compuesta por un

nico atributo.
ASOCIAR ( Tutor, Curso , Es_coordinador)

BR/MC
TUTORES ( DNI , Nombre,_completo,
3FN
e-mail)
Se dice que una relacin est en 3FN si satisface la 2FN y cada atributo no
primario no depende de forma transitiva de la clave primaria, es decir,
dependern directamente de la clave primaria.
Pasamos a estudiar cada una de las relaciones
La relacin est en 3FN ya que todos los atributos dependen directamente

de la clave primaria, no habiendo dependencias funcionales donde el
antecedente no es clave primaria.
FNBC
El antecedente de cada dependencia funcional debe ser clave primaria.
Observamos que en todas las dependencias funcionales el antecedente es
clave primaria luego la relacin est en FNBC.
179
180
Modelo Relacional
Relacin AULAS (CDIGO_AULA, DESCRIPCION, DIRECCIN )

CDIGO_AULADESCRIPCIN
Relacin MATRICULA (ALUMNO, CURSO, F_COMIENZO, F_FINALIZACIN )
CDIGO_AULA DIRECCIN

ALUMNO, CURSO F_COMIENZO

1 FN
La relacin est en primera forma normal ya que al tener una
clave primaria definida, el sistema no permitir registros

repetidos.
2FN
3FN
FNBC
En
ALUMNO,CURSO->F_FINALIZACIN
1 FN
La relacin est en 2FN ya que la clave primaria est
compuesta por un nico atributo.
repetidos.
2FN
La relacin est en 3FN ya que todos los atributos dependen
Comprobamos que los atributos F_Comienzo y F_Finalizacin
directamente de la clave primaria, no habiendo dependencias
dependen de la totalidad de la clave, es decir, dependen tanto
funcionales entre atributos que no son clave primaria *
del alumno como del curso.*

3FN
Observamos que en todas las dependencias funcionales el
antecedente es clave primaria luego la relacin est en FNBC.

este
caso
no
existe
ninguna
dependencia
dependencia
DESCRIPCION DIRECCIN, por lo que la relacin est en 3 FN

funcionales entre atributos que no son clave primaria**
entre
FNBC

antecedente es clave primaria luego la relacin est en FNBC.
Relacin ALUMNOS (DNI, NOMBRE, DIRECCIN, TELFONO, NACIONALIDAD, E-MAIL, AULA )

* Recordemos que un alumno de mentor puede realizar diferentes cursos y

DNI NOMBRE
DNI E-MAIL
DNI DIRECCIN
DNI AULA
DNI TELFONO
comenzar y finalizar cada uno de ellos en una determinada fecha, por lo
DNI NACIONALIDAD
que dicha relacin se encuentra en 2FN.
DNI NOMBRE
** No exite ninguna dependencia entre los atributos F_Comienzo y

F_Finalizacin, ya que la fecha de comienzo no determina la fecha de
finalizacin, ya que un alumno puede comenzar en una fecha determinada.

1 FN
No podremos saber la fecha de finalizacin, ya que es en los cursos mentor
cada alumno lleva su propio ritmo de trabajo.
repetidos.
2FN

Relacin CURSOS ( NOMBRE, WWW, LIBRO )

3FN
CURSOS NOMBRE

funcionales entre atributos que no son clave primaria
CURSOSWWW
CURSOSLIBRO

FNBC
antecedente es clave primaria luego la relacin est en

FNBC.
181
182
Modelo Relacional
1 FN
La relacin est en primera forma normal ya que al tener

una clave primaria definida, el sistema no permitir registros
Relacin TUTOR ( DNI, NOMBRE_COMPLETO, E-MAIL )
repetidos.
2FN
DNINOMBRE_COMPLETO

3FN

directamente
de
la
clave
primaria,
no
habiendo
1 FN
dependencias funcionales entre atributos que no son clave

primaria *
repetidos.

FNBC
DNIE-MAIL
2FN

FNBC.
3FN
* No existe ninguna dependencia entre funcional entre los atributos www y
directamente
libro
dependencias funcionales entre atributos que no son clave
de
la
clave
primaria,
no
habiendo
primaria *
Relacin ASOCIAR ( TUTOR, CURSO, ES_COORDINADOR )

FNBC

FNBC.
TUTOR, CURSO ES_COORDINADOR
* En principio pudiera parecer que existe una dependencia funcional entre
atributos que no son clave primaria, de la forma: NOBRE_COMPLETOEMAIL.
1 FN

Sin embargo, esta dependencia no es real, ya que el nombre completo podra
repetidos.
repetirse en nuestra base de datos, en el caso de que existan dos personas

con el mismo nombre y cada una de ellas tendr un e-mail distinto:
2FN
Igualmente, comprobamos si el atributo Es_coordinador

depende de la totalidad de la clave primaria, es decir,
DNI
NOMBRE_COMPLETO
E-MAIL
depende de Tutor y de Curso.*

3FN
La relacin est en 3FN ya que en la relacin hay un nico
54258652
LUIS PEREZ PEREZ
lperez@gmail.com
42568745
MARIA FERNANDEZ RUIZ
Mfernandez@gmail.com
41203657
CARMEN PRIETO PEREZ
cprieto@gmail.com
41875964
LUIS PEREZ PEREZ
luisperez@gmail.com
atributo y por lo tanto no podr haber dependencias que

incumplan la 3 FN.
FNBC

FNBC.
* En este caso, la dependencia es correcta, ya que el hecho de ser

coordinador vendr determinado por el tutor y el curso. Es decir, un
Por lo tanto, podemos ver que nuestra relacin se encuentra en 3 FN
determinado tutor coordinar uno o ms cursos.

183
184
Modelo Relacional
El modelo relacional para la gestin de una base de datos es el modelo

ms utilizado en la actualidad para modelar problemas reales y administrar
datos dinmicamente.
Su idea fundamental es el uso de relaciones, cuya representacin
grfica se realiza en forma de tabla. En las relaciones se pueden distinguir
varios tipos de elementos: su nombre, los atributos que contiene y que
representan las columnas de la tabla, y las tuplas o filas de la tabla.
Adems tambin podemos incluir los dominios que son aquellos conjuntos
de donde los atributos toman los valores.
Reglas bsicas para la transformacin del modelo entidad/relacin al

modelo relacional:
- La primera de las reglas de transformacin nos dice que toda entidad se

transforma en una relacin o tabla, y los atributos o caractersticas
asociadas a ella pasan a ser atributos de la relacin.
- La segunda regla de transformacin nos indica que las interrelaciones

cuyo tipo de correspondencia es N:M se transforman en una nueva relacin
cuyo nombre se corresponde con el nombre de la interrelacin y donde la
clave primaria se compone de los atributos identificadores de las dos
entidades que relaciona.
- La tercera y ltima regla nos indica que la transformacin de

interrelaciones cuyo tipo de correspondencia es 1:N se traduce en una
propagacin de clave o en una nueva relacin si la interrelacin posee
atributos
185
MDULO C
UNIDADES DIDCTICAS:
1. Algebra Relacional
2. SQL Lenguaje de Consulta Estructurado
MDULO C
OBJETIVOS
lgebra Relacional
x
x
A conocer el lgebra relacional y sus operadores algebraicos y

relacionales.
A realizar las siguientes operaciones:
- Unin, interseccin, diferencia y producto cartesiano (operadores

algebraicos)
UNIDAD DIDCTICA 1
ndice de la unidad:
1. Qu es el lgebra relacional
2. Para qu sirve el lgebra relacional
- Operadores algebraicos o bolanos
- Operadores relacionales
- Seleccin, proyeccin, concatenacin y divisin (operadores

relacionales)
TTULO DE MDULO O BLOQUE
Algebra Relacional
1. Algebra Relacional
586
401
586
690
586
690
333
1.1 Qu es lgebra relacional?
401
Se llama lgebra relacional a un conjunto de operaciones que pueden ser

aplicadas sobre tablas relacionales y definen un pequeo lenguaje de
- Interseccin ()
manipulacin de datos que permite a los usuarios llevar a cabo tareas de
La relacin resultante est compuesta por las tuplas que
consulta o manipulacin de los datos.
aparecen en las dos relaciones de origen.
1.2 Para qu sirve el lgebra relacional?

Ejemplo: Dados dos esquemas de relacin R (A B C) y S
(E F H), obtener la interseccin de R y S.
Para crear una relacin o tabla a partir de una o varias relaciones utilizando
para ello operadores relacionales. La nueva relacin o tabla de salida
contendr solamente la informacin que hemos demandado a travs de
R ( A B C)
operadores del lgebra relacional.

Los operadores se dividen en dos grupos:
R ( E F H)
179
333
179
345
179
586
586
401
690
586
- Diferencia (-)
Los que estn en la primera relacin y no estn en la segunda
1.2.1 Operadores algebraicos o booleanos

Para aplicar las operaciones de Unin, Interseccin y diferencia, los
esquemas de la relacin deben ser compatibles, es decir, deben tener
(E F H), obtener la diferencia de R y S.
el mismo nmero de atributos y los dominios de los atributos de las

relaciones deben coincidir uno a uno.
R ( A B C)
Para el producto cartesiano los esquemas no tienen por qu ser

compatibles
- Unin (U)
La relacin resultante est compuesta por cada una de las
tuplas de las relaciones de origen. En la relacin resultante no
R ( E F H)
179
333
345
179
586
401
690
586
-S
345
690
aparecen tuplas repetidas.

- Producto cartesiano (x)
La relacin resultante se formar por el producto de cada una
de las tuplas de la primera relacin por todas las tuplas de la
(E F H), obtener la unin de R y S.
segunda relacin.
R ( A B C)
R ( E F H)
Si coincide algn atributo en ambas relaciones, se pondr,
RUS
179
333
179
345
179
345
delante del atributo, el nombre de la relacin correspondiente.
191
192
Algebra Relacional
756984B
Elena
(E F H), obtener el producto cartesiano de R y S.
R ( A B C)
R ( E F H)
179
333
345
179
586
401
x S (A B C E F H)
Operadores unarios
179333
179179
- Seleccin ()
179401
586
Obtiene tuplas de una relacin que cumplan una determinada
179586
condicin.
345333
Ejemplo: Obtener los alumnos matriculados en el curso
345179
1.
curso=1(ALUMNOS)
345401
345586
586333
D resultado
687698 P
Ana Huete
La condicin podra ser mltiple. La seleccin se podra hacer
586179
sobre una tabla o sobre otra expresin.
586401
586586
- Proyeccin ()
Utilizado
Si coincide el nombre de un atributo en ambas relaciones, se

pondr,
delante
del
atributo,
el
nombre
de
la
para
obtener
columnas
de
una
relacin
obtenido.
correspondiente.
Ejemplo: Obtener los nombre de la tabla alumnos.
nombre=1(ALUMNOS) D

(A F C), obtener el producto cartesiano de R X S (R.A B R.C
S.A F S.C)
resultado
Juan M. Kimla
Antonio Prez
Ana Huete
1.2.2 Operadores Relacionales
Elena
Los operadores relacionales pueden ser unarios o binarios. Es unario

cuando se aplica sobre una relacin o tabla y binario si se aplica sobre
dos.
Los ejemplos se realizarn sobre la siguiente tabla:
ALUMNOS (DNI, NOMBRE, CURSO)
DNI
NOMBRE
CURSO
120546M
Juan M. Kimla
478965J
Antonio Prez
687698P
Ana Huete
relacin.
Automticamente se eliminan las repeticiones del resultado
193
194
Algebra Relacional
Operadores binarios
Ejemplo: Dados los siguientes esquemas de relacin
Obtener los pilotos capaces de manejar todos los aviones
- Concatenacin (ZY) (Natural Join)
disponibles.
La concatenacin equivale a un producto cartesiano ms una

seleccin
Se queda con aquellas tuplas que en los atributos comunes a
PILOTOS (PILOTO, AVIN)
ambas tablas toman el mismo valor. En la relacin de salida los
PILOTO
atributos comunes no aparecen duplicados.

Cuando no hay atributos comunes en las
tablas donde se
Una combinacin de dos relaciones es equivalente a:

R ZYF S = F (R S)
- Divisin (/)
PILOTO
ZGT-090
Paula Parla
ZGT-090
ZGT-099
Gonzalo vila
ZGT-099
ZGT-190
Paula Parla
ZGT-190
Juan Toledo
ZGT-099
Paula Parla
ZGT-099
Paula Parla
ZGT-090
Gonzalo vila
ZGT-099
Paula Parla
ZGT-190
Juan Toledo
ZGT-099
Paula Parla
ZGT-099
PILOTOS
AVIONES(AVIN)
AVIN
ZGT-090
ZGT-099
ZGT-190
realiza la concatenacin equivaldra a un producto cartesiano.
PILOTOS (PILOTO, AVIN)
AVIONES(AVIN)
AVIN
AVIONES
PILOTOS
Paula Parla
Para poder realizar la divisin, debe darse que los datos de

avin tienen que estar incluidos como atributos en la relacin de
pilotos.
Suponiendo que tenemos los esquemas de relacin R y S y

deseamos realizar la operacin R / S. La cabecera de la relacin
siempre ser R-S
195
196
Algebra Relacional
Se llama lgebra relacional a un conjunto de operaciones que pueden

ser aplicadas sobre tablas relacionales y definen un pequeo lenguaje de
manipulacin de datos que permite a los usuarios llevar a cabo tareas de
consulta o manipulacin de los datos.
Los operadores se dividen en dos grupos:

- Unin (U)
- Diferencia (-)
- Interseccin
- Producto cartesiano (x)
- Seleccin ()
- Proyeccin ()
- Concatenacin (ZY) (Natural Join)
- Divisin (/)
197
MDULO C
OBJETIVOS
SQL Lenguaje de Consulta

Estructurado
UNIDAD DIDCTICA 2
ndice de la unidad:
1. Operaciones sobre las bases de datos

- Operaciones de recuperacin de datos
- Operaciones de actualizacin de datos
2. Caso Prctico Recetas
3. Repaso de Consultas SQL
x
x
La sintaxis de las sentencias de insercin, borrado y actualizacin de

los datos
La sintaxis de las consultas en SQL que nos permitirn acceder a los
datos de una o ms tablas (join).
SQL Lenguaje de Consulta Estructurado
Las operaciones que se pueden hacer sobre la base de datos son las
1. Operaciones sobre la Base de Datos
siguientes:
La parte dinmica del Modelo Relacional, al igual que la dinmica de

cualquier modelo de datos, define las operaciones que se pueden hacer con la
base de datos. Estas operaciones pueden ser de varios tipos:
- Operaciones de recuperacin de datos de la base de datos (consultas).
- Altas
INSERT INTO (Figura 2.50.)
- Operaciones de actualizacin de datos de la base de datos. Estas
- Bajas
DELETE FROM (Figura 2.51.)
operaciones son:
- Modificaciones
1. Insercin de tuplas en la base de datos.
UPDATE (Figura 2.52.)
- Consultas
SELECT
2. Modificacin de tuplas (de algunos de sus valores)

3. Borrado de tuplas.
Estas
operaciones
se
expresan
mediante
lenguajes
de
manipulacin
relacionales. Los lenguajes de manipulacin pueden dividirse en lenguajes

navegacionales, en los que se debe indicar el camino para llegar al dato, y
lenguajes de especificacin, en los cuales se recupera la informacin mediante la
INSERT INTO PELCULA

VALUES (1, Entrevista con un Vampiro, 1/5/1997)
imposicin de condiciones y no indicando el camino. El lenguaje de manipulacin

de datos del SQL (LMD) es un lenguaje de especificacin, que consiste en un
conjunto de sentencias que nos permiten manipular la base de datos.
PELCULA
Cod_pelcula
En este apartado vamos, a travs de un ejemplo, a introducir las sentencias
bsicas del SQL para la manipulacin de una base de datos.
Ttulo
Entrevista con un Vampiro
Fecha_estreno
1/5/1997
Supongamos una base de datos de un videoclub, en la que entre otros

objetos se almacenan las pelculas y los actores que intervienen en ellas (Figura
2.49.).
Figura 2.50: Ejemplo de insercin de tuplas
ACTOR(Cod_actor, Nombre, Nacionalidad)

PARTICIPA (Cod_pelcula, Cod_actor, Fecha_inicio, Fecha_fin)
PELCULA Cod_pelcula, Ttulo, Fecha_estreno)
Figura 2.49: Subesquema de la base de datos de un videoclub

201
202
Mencin especial debe hacerse a las consultas. El formato general de las

consultas es:
Supongamos que tenemos la tabla PELCULA con las siguientes filas:
SELECT-FROM-WHERE, donde la clusula WHERE es opcional, depender de

si imponemos alguna condicin sobre las tuplas a seleccionar o bien de si
PELCULA
Cod_pelcula
Ttulo
1/5/1997
Abre los Ojos
7/3/1998
necesitamos unir varias tablas para obtener un resultado. Las consultas las
Fecha_estreno
podemos dividir en consultas sobre una tabla y consultas sobre varias tablas.
Supongamos que tenemos la ejemplar del esquema relacional del videoclub
que aparece en la Figura 2.53:
DELETE FROM PELCULA

VALUES (1, Entrevista con un Vampiro, 1/5/1997)
Cod_pelcula
2
PARTICIPA
ACTOR
PELCULA
Ttulo
Abre los Ojos
Fecha_estreno
7/3/1998
Figura 2.51 : Ejemplo de borrado de tuplas
Cod_actor Cod_pelcula Fecha_inicio
Fecha_fin
Cod_actor
Nombre
Nacionalidad
TomCruise
Norteamericana
1/1/1996
1/3/1996
BradPitt
Norteamericana
4/3/1996
30/12/1996
PenlopeCruz
Espaola
1/5/1997
31/10/1997
JavierBardem
Espaola
1/5/1997
31/12/1997
PELCULA
Cod_pelcula
Supongamos que queremos modificar la fecha de la pelcula Abre los

Ojos:
Ttulo
Fecha_estreno
EntrevistaconunVampiro
1/5/1997
AbrelosOjos
7/3/1998
UPDATE PELCULA
SET Fecha_estreno=25/3/1998
WHERE Ttulo =Abre los Ojos
Figura 2.53: Ejemplar del videoclub
PELCULA
Cod_pelcula
Ttulo
Fecha_estreno
1/5/1997
Abre los Ojos
25/3/1998
- Consultas sobre una sola tabla:

En este caso la condicin WHERE nicamente se utiliza en el caso de
que queramos restringir el conjunto de filas que se recupere.
Como se puede apreciar en la Figura 2.54. la recuperacin de las
Figura 2.52.: Ejemplo de modificacin de tuplas
puede hacerse por el total de las columnas (atributos) de la tabla

203
204
implicada en la consulta, o bien seleccionando aquellos atributos que

queramos obtener en la consulta.
Seleccin de los actores y las pelculas en las que intervienen:

SELECT Nombre
Seleccin de todos los atributos de una tabla:
Seleccin de ciertos los atributos de una tabla:
SELECT *
FROM PELCULA
SELECT Ttulo, Fecha_estreno

FROM PELCULA
Cod _pelcula
Ttulo
Fecha_estreno
Ttulo
FROM PELICULA, ACTOR, PARTICIPA

WHERE PELICULA.Cod_pelicula = PARTICIPA.Cod_pelicula
AND ACTOR.Cod_actor = PARTICIPA.Cod_actor
Fecha_estreno
1/5/1997
1/5/1997
Abre los Ojos
7/3/1998
Abre los Ojos
7/3/1998
Nombre
Titulo
Tom Cruise
Brad Pitt
Penlope Cruz
Abre los Ojos
Javier Bardem
Abre los Ojos
Seleccin de ciertos los atributos de una tabla que cumplen una determinada condicin:
SELECT Nombre
FROM ACTOR
WHERE Nacionalidad = Espaola
Nombre
Penlope Cruz
Javier Bardem
Figura 2.54: Consultas sobre una nica tabla
Seleccin de los actores que intervienen en la pelcula Entrevista con un

Vampiro:
- Consultas sobre varias tablas:
SELECT Nombre
En este caso la condicin WHERE no es opcional. Se debe utilizar para
FROM PELICULA, ACTOR, PARTICIPA
unir las tablas1 que intervienen en la consulta. Esta unin se realiza por
WHERE PELICULA.Cod_pelicula = PARTICIPA.Cod_pelicula
la clave ajena de una tabla y la clave primaria de la tabla a la que

referencia, como se muestra en la figura 2.55.
AND ACTOR.Cod_actor = PARTICIPA.Cod_actor

AND Titulo = Entrevista con un Vampiro
Esta unin es lo que se denomina JOIN.

205
206
Nombre
Tom Cruise
Brad Pitt
Para fijar los conocimientos del modelo relacional asimilados hasta el

momento, vamos a disear una base de datos completa y a hacer ciertas
Penlope Cruz
consultas sobre ella.

Antonio es uno de tantos trabajadores que llega a casa cansado y
Javier Bardem
estresado. Desde hace algn tiempo alivia su estrs elaborando

recetas de cocina que luego prueban sus familiares y amigos. Para
ello se apoya en los mltiples manuales de cocina que ha ido
Figura 2.55.: Ejemplo de consultas en las que intervienen varias tablas
coleccionando e incluyendo en su biblioteca desde que se inici en el

arte culinario, y luego confecciona sus propias recetas. Tanto ha sido
su inters que en la actualidad posee un gran nmero de recetas
Con lo explicado hasta ahora de la parte dinmica del Modelo Relacional
nuevas a modo de apuntes, imposible de organizar de una manera
hemos pretendido dar una visin general de las operaciones que se pueden
efectiva.
realizar sobre una base de datos, no obstante existen otras muchas funciones
que se pueden aplicar sobre los atributos de una o varias tablas para recuperar
Los amigos de Antonio, en agradecimiento a tantas veladas de buena
informacin y que pueden ser consultadas en la bibliografa que aparece en el
comida, vino y compaa han decidido agradarle con una base de
curso.
datos que le gestione su maravilloso gran hobbie. Para ello deben

controlar todas las recetas que posee, teniendo en cuenta que:
Cada receta proviene de una idea original de un libro de cocina de la
biblioteca de Antonio, y se desea almacenar su origen.
Cada receta tiene un tipo (Sopas, Verduras, Carnes,...) e incorpora
unos ingredientes de los que se desea saber su nombre y cantidad.
Adems cada receta contiene una breve explicacin de cmo mezclar
los ingredientes y obtener el producto final y el ttulo de la receta
original de la que proviene. Es bien sabido por los amigos de Antonio
que de cada receta que l prueba, incorporando ciertos cambios,
consigue nuevas recetas, por lo que sera interesante almacenar si
cada receta es idea surgida de una receta original, o si por el
contrario, proviene de una receta elaborada alguna vez ya por
Antonio.
207
208
Lo que los amigos de Antonio quieren es que cuando l quiera pueda
2. SOLUCIN AL CASO PRCTICO
consultar las recetas por tipo y por ingrediente adems de poder

En primer lugar debemos detectar cules son las relaciones base que
localizar el libro que le dio la idea de cada una de sus recetas.
aparecen en el enunciado y qu atributos contienen (Figura 2. 56.). Estos son:
Tambin sera interesante saber qu receta proviene de alguna otra y

cual no.
LIBRO. Esta relacin debe contener al menos el Ttulo de la obra y el autor.

Como clave primaria podemos suponer el ISBN, que como todos sabemos es
nico por cada libro editado.
- RECETA. De cada receta deberemos incluir el tipo , la descripcin, el
ttulo original (ttulo de la receta en la que se basa) y la fecha de creacin.
Adems supondremos el atributo Cod_receta como clave primaria.
- INGREDIENTE. En principio, de los ingredientes se desea almacenar
el nombre y la cantidad que de l se ha empleado en cada receta, pero
como un mismo ingrediente puede ser usado en distintas cantidades para
varias recetas, de momento solo introduciremos el nombre como atributo
de la relacin INGREDIENTE y veremos posteriormente como reflejar la
cantidad. Al igual que ocurria en el caso de las recetas, consideraremos el
atributo Cod_ingrediente como clave primaria.
LIBRO (ISBN, Ttulo, Autor)
RECETA (Cod_receta, Descripcin, Fecha_creacin,Ttulo_original )
INGREDIENTE (Cod_ingrediente, Nombre)
Figura 2. 56: Relaciones elementales de las base de datos de Antonio

Una vez encontradas las relaciones base hay que analizar como se
intrrelacionan en funcin de los supuestos realizados en el enunciado:
De cada receta se desea saber de donde (de qu libro se ha sacado).
Por lo tanto deberemos introducir en la relacin RECETA el ISBN del
libro.
209
210
Parece claro que no pueda ser de otra manera pues si penssemos en
variacin, puede hacerse en cascada pues no va a afectar a la receta padre
introducir el cdigo de receta en LIBRO, lo que significara es que por cada libro
(Figura 2. 58).
Antonio slo sac una receta (recurdese que en el modelo relacional no puede
haber ms de un valor en cada celda de una tabla). El ISBN introducido en la
relacin RECETA es clave ajena de sta y referencia a la relacin LIBRO.
RECETA(Cod_receta, Descripcin, Fecha_creacin,Ttulo_original, ISBN, Cod_receta_padre)

DR/UC
En cuanto a las opciones de borrado y modificacin, el borrado debe ser

restringido (DR), pues si eliminamos un libro no se debe permitir que se eliminen
todas las recetas que Antonio sac de l; la modificacin puede ser en cascada
(UC) para que los cambios se actualicen automticamente (Figura 2. 57).
Figura 2. 58: Asociacin entre RECETA original y no original

DR/UC
RECETA (Cod_receta, Descripcin, Fecha_creacin,Ttulo_original, ISBN)
Cada receta est compuesta por ciertos ingredientes (uno o varios) y

adems un mismo ingrediente, sin tener en cuenta las cantidades del
mismo, puede utilizarse en serlo de varias recetas.
Por tanto debemos introducir una nueva relacin COMPUESTA cuyos
Figura 2.57: Asociacin entre LIBRO y RECETA
atributos sern Cod_receta, Cod_ingrediente y Cantidad. La clave primaria

Cada receta puede ser original, es decir sacada directamente de un
estar formada por los dos primeros atributos y de esta forma tendremos qu
libro de cocina, o bien ser una variacin de una ya creada y este
cantidad de un mismo ingrediente se ha utilizado en cada receta y todas las
aspecto se desea recoger en la base de datos.
cantidades de cada uno de los ingredientes que intervienen en una misma

receta, como puede verse en la Figura 2. 59.
Independientemente de que la receta sea original o variacin, es una receta

y
por
tanto
contendr
los
mismos
atributos
que
cualquier
receta;
si
Cod_receta y Cod_ingrediente son, respectivamente, claves ajenas de
duplicsemos la relacin RECETA y mantuvisemos una para las recetas
las relaciones RECETA e INGREDIENTE. Los borrados y modificaciones de ambas
originales y otra para las varaciones, provocaramos redundancia, pues la
claves ajenas pueden hacerse en cascada, pues a lo nico que afectara sera a
definicin de la relacin RECETA se hara dos veces. Lo mejor en estos casos es
la relacin existente entre la receta y sus ingredientes, pero no a la receta o al
aadir un atributo Cod_receta_padre en RECETA, que, en el caso de contener
ingrediente en s.
valor, nos dir de qu otra receta proviene (si no contiene ningn valor es
porque la receta correspondiente a la fila en la que este atributo no tiene valor
es una receta original).
Cod_receta_padre es una clave ajena de la relacin RECETA que se
referencia a s misma. Si eliminamos una receta que es una variacin de otra, no
debemos permitir que se borre la receta padre, por lo que el borrado debemos
considerarlo restringido (DR), en cambio la modificacin de una receta
211
212
LIBRO
84-404-9666-4
84-324-8776-3
84-403-6999-5
DC/UC
COMPUESTA ( Cod_ingrediente, Cod_receta, Cantidad)
DC/UC
Autor
Ttulo
ISBN
RECETA (Cod_receta, Descripcin, Fecha_creacin,Ttulo_original, ISBN, Cod_receta_padre)
Gua Prctica de Cocina Oriental

La Cocina Para Estar en Forma
La Cocina Prctica
K.C.Chin
Karlos Arguiano
Karlos Arguiano
RECETA
Cod_receta
INGREDIENTE Cod_ingrediente, Nombre)

(
Tipo
Fecha creacin
Ttulo original
ISBN
Cod_receta_padre
Pasta
La pasta se cuece y se saltea con un poco de aceite.

Mezclar la nata con las yemas de huevo batidas e
incoporar a la pasta (a fuego lento). Fuera del fuego
se le aade queso rellado y se gratina (2 min.)
8/3/1999
Cintas a la Crema
84-324-8776-3
Pasta
Rehogar mantequilla, anchoas y aceitunas. Aadir la

pasta cocida y el brecol. Lonchas de queso por
encima y gratinar (1,5 min.).
13/6/1999
Cintas con Brecol
84-324-8776-3
Pasta
Rehogar la verdura con el ajo. Incorporar la pasta

cocida con las anchoas y las aceitunas. Colocar las
lonchas de queso y gratinar (3 min.)
26/6/1999
Cintas con Brecol
84-403-6999-5
10
Verduras
Freir los aros de pimiento y colocar encima los

puedrros cocidos. Cubrir con salsa bechamel.
Espolvorear con queso rallado y gratinar (5 min.)
30/6/1999
Puerros con
bechamel
84-324-8776-3
Figura 2. 59: Asociacin entre RECETA e INGREDIENTE

Tras haber analizado todos los supuestos del enunciado el esquema
relacional correspondiente a la base de datos de recetas de cocina, queda como
Descripcin
se refleja en la Figura 2. 60.
-------
------
COMPUESTA
DR/UC
Cod_receta
RECETA (Cod_receta, Descripcin, Fecha_creacin,Ttulo_original, ISBN, Cod_receta_padre)

DR/UC
INGREDIENTE
Cod_ingrediente
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
DC/UC
COMPUESTA (Cod_ingrediente, Cod_receta, Cantidad)
DC/UC
INGREDIENTE Cod_ingrediente, Nombre)
(
Figura 2.50: Esquema relacional de las Recetas de Cocina
Una vez realizado el diseo de la base de datos hay que gestionarla, es

decir, insertar datos, modificar datos, y realizar consultas a la base de datos.
Supongamos la siguiente ejemplar del esquema:
213
214
Nombre
Cintas
Yemas de huevo
Queso rallado
Nata lquida
Brecol
Anchoas
Aceitunas negras
Lonchas de queso
Coliflor
Espinacas
Puerros
Zanahorias
Judas verdes
Ajos
Pimientos
Bechamel
7
7
7
7
8
8
8
8
8
9
9
9
9
9
9
9
9
9
9
9
10
10
10
10
Cod_ingrediente
4
5
6
7
4
8
9
10
11
4
8
9
10
11
12
13
14
15
16
17
14
18
19
6
Cantidad
300 grs.
4
---1 vasito
200 grs.
250 grs.
8
1 puado
4
200 grs.
250 grs.
8
1 puado
4
200 grs.
200 grs.
100 grs.
100 grs.
100 grs.
1 diente
6
6 medianos
1/2 litro
50 grs.
Supongamos que queremos realizar las siguientes consultas;
- Consultas de unin:
1. Recetas en las que intervienen las Lonchas de queso
- Consultas de seleccin
2. Ttulo de los libros , descripcin y ttulo original de las recetas de

tipo Verduras
1. Libros de cocina de la biblioteca de Antonio.
3. Ingredientes y cantidad de los mismos utilizados en las recetas
2. Nombre y descripcin de las recetas del tipo pasta realizadas en
anteriores a junio de 1999.
junio de 1999.
Ejemplo 1. Recetas en las que intervienen las Lonchas
Ejemplo 1. Libros de cocina de la biblioteca de Antonio
de queso
SELECT *
FROM LIBRO
SELECT Tipo, Descripcin, Fecha_creacin, Ttulo_original,
Cantidad
FROM RECETA, COMPUESTA, INGREDIENTE
WHERE Nombre = Lonchas de queso AND
INGREDIENTE.Cod_ingrediente = COMPUESTA. Cod_ingrediente
AND COMPUESTA.Cod_receta = RECETA.Cod_receta
Resultado:
LIBRO
Autor
Ttulo
ISBN
84-404-9666-4
84-324-8776-3
84-403-6999-5
Gua Prctica de Cocina Oriental

La Cocina Prctica
K.C.Chin
Karlos Arguiano
Karlos Arguiano
Resultado:
13/6/1999 Cintas con Brecol
Cantida
d
4
Pasta
26/6/1999 Cintas con Brecol
Descripcin
Tipo
Ejemplo 2. Nombre y descripcin de las recetas del tipo

pasta realizadas en
junio de 1999
SELECT Descripcin, Ttulo_original

FROM RECETA
WHERE Tipo = Pasta AND Fecha_ creacin >= 1/6/1999
Resultado:
Fecha creacin Ttulo original
Pasta Rehogar mantequilla, anchoas y aceitunas. Aadir

pl asta cocida y el brecol. Lonchas de queso
encima y gratinar (1,5min.).
cocida con las anchoas y las aceitunas. Colocar
llonchas de queso y gratinar (3 min.)
Ejemplo 2. Ttulo de los libros , descripcin y ttulo

original de las recetas de tipo Verduras
RECETA
Descripcin
Ttulo_original
Rehogar mantequilla, anchoas y aceitunas. Aadir la Cintas con Brecol

pasta cocida y elbrecol. Lonchas de queso por
encima y gratinar (1,5min.).
cocida con las anchoas y las aceitunas. Colocar las
lonchas de queso y gratinar (3min.)
SELECT Ttulo, Descripcin, Ttulo_original

FROM RECETA, LIBRO
WHERE Tipo = Verduras AND RECETA.ISBN = LIBRO.ISBN
Cintas con Brecol
Resultado:
215
216
Ttulo
Descripcin
Freir los aros de pimiento y colocar encima los

puedrros cocidos. Cubrir con salsa bechamel.
Espolvorear con queso rallado y gratinar (5 min.)
3.
Repaso de Consultas en SQL
Ttulo original
Puerros con
bechamel
La sintaxis de las consultas en SQL es:

SELECT [(*|ALL|DISTINCT| <columna [, columna]...>)| <expresin de
funcin>]
FROM <nombre_tabla> [[, nombre_tabla]...]
Ejemplo 3. Ingredientes y cantidad de los mismos
WHERE <condicin de bsqueda> |
utilizados en las recetas anteriores a junio de 1999

[GROUP BY <condicin de bsqueda>]
HAVING <condicin de bsqueda> |
SELECT Ingrediente, Cantidad
FROM RECETA, COMPUESTA, INGREDIENTE
WHERE Fecha_creacin < 1/6/1999 AND
IGREDIENTE.Cod_ingrediente = COMPUESTA. Cod_ingrediente
AND COMPUESTA.Cod_receta = RECETA.Cod_receta
ORDER BY <lista de atributos> [ASC|DESC] |

<columna> <operador> <sentencia de consulta>
Resultado:
Nombre
Cintas
Yemas de huevo
Queso rallado
Nata lquida
donde:
ALL: selecciona todas las columnas
Cantidad
300 grs .
4
---1 vasito
DISTINCT: suprime filas duplicadas

Operadores para la condicin de bsqueda: <, >, =, >=, <=, between, like,
in,...
y tambin los operadores lgicos: NOT, AND, OR.
Presentaremos en este apartado varios ejemplos de bases de datos con las

tablas y sus valores. En estos ejemplos iremos aplicando distintas consultas de
menor a mayor dificultad con el fin de que mediante estos ejemplos se aprenda
las distintas posibilidades que ofrece SQL para realizar consultas a una base de
datos.
217
218
3.1 BD sobre las que se muestran las consultas

En esta base de datos contemplamos la informacin de una empresa con
datos de los empleados y los departamentos a los que pertenecen dichos
UNIVERSIDAD
empleados.
Tablas:
3.2 Valores para las tablas de las BD que nos servirn de ejemplo
Alumno(cod_matricula, nombre, ciudad, cod_grupo)

Grupo(cod_grupo, curso, turno)
UNIVERSIDAD
Profesor(cod_profesor, nombre, ciudad, categora, salario)

Impartir(cod_grupo, cod_profesor, asignatura, horas)
Alumno
cod_matricula
101
102
202
300
103
Base de datos en la que almacenamos los alumnos, los grupos donde se

han matriculado estos, los profesores y los grupos donde imparten clase
indicando la asignatura que imparten.
Nombre
Juan Montero
Alicia Cristobal
Ana Vallejo
Ignacio Lpez
Leticia Martnez
Grupo
Cod_grupo
BIBLIOTECA
Ciudad
Alcorcn
Legans
Legans
Mstoles
Alcorcn
cod_grupo
11
11
21
31
--
Turno
Curso
Tablas:
11
12
21
22
31
Autor(nombre, fecha_nac, nacionalidad)

Escribe(nombre, cod_documento)
Documento(cod_documento, titulo, tipo_documento, precio,
num_copias)
Profesor
Cod_profesor
1p
2p
3p
4p
5p
6p
7p
Almacenaremos la informacin relativa a documentos con los autores que

los han escrito.
EMPRESA
Tablas:
Empleado(nombre, numero_dept, salario, fecha_nac, ext_telefnica)
Departamento(numero_dept, nombre)
219
220
1
1
2
2
3
Nombre
D. Cuadra
E. Nieto
P. Martnez
C. Nieto
A. Sierra
C. Garca
J. Montero
M
T
M
T
T
Ciudad
Madrid
Las Rozas
Alcorcn
Madrid
Madrid
Madrid
Madrid
Categora
T1
T2
T1
T2
T3
T1
T3
Salario
200.000
250.000
225.000
150.000
120.000
135.000
125.000
Impartir
Cod_grupo
11
11
21
31
Cod_profesor
1p
2p
1p
2p
Asignatura
Intr. Informtica
SGBD
Ficheros y BD
Diseo de BD
Escribe
Nombre
Miguel de Cervantes
Emily Bronte
Isaac Asimov
Christian Jacq
Christian Jacq
Ken Follet
Paloma Martnez
P. Isasi
D. Borrajo
Horas
20
15
12
20
BIBLIOTECA
Autor
Nombre
Miguel de Cervantes
Emily Bronte
Isaac Asimov
Christian Jacq
Ken Follet
Paloma Martnez
P. Isasi
D. Borrajo
Fecha_nac
9-10-1547
2-9-1818
23-4-1930
30-6-1947
5-8-1949
2-9-68
3-4- 66
23-8-65
Documento
Cod_documento Ttulo
11
El Quijote
12
Cumbres Borrascosas
Nacionalidad
Espaola
Inglesa
Americana
Francesa
Inglesa
Espaola
Espaola
Espaola
Tipo_documento
Novela
Novela
EMPRESA
Empleado
Nombre
Pablo Montero
Beatriz Cristobal
J.Luis Martn
Almudena Lpez
Angel Vallejo
Pedro Garca
Precio Num_copias
5000
22
4000
12
13
14
La Pirmide Asesinada Novela

La Ley del Desierto
Novela
2000
2000
15
10
15
Introduccin a la
Divulgativo
ciencia
Los Pilares de la Tierra Novela
Gramticas, Lenguajes Tcnico
y Autmatas
4500
13
6000
3500
7
6
16
17
Cod_documento
11
12
15
13
14
16
17
17
17
Departamento
Numero_dept
11
13
14
221
222
Numero_dept
14
13
11
13
14
11
Salario
220.000
300.000
150.000
350.000
400.000
200.000
Fecha_nac
10-11-67
20-9-68
25-6-77
4-5-60
15-4-72
12-3-70
Nombre
Contabilidad
Marketing
Informtica
Ext_telefnica
6543
6577
6433
6422
6321
6323
Ejemplo 2: seleccionar el nombre, la nacionalidad y la
3.3 Consultas sencillas (Sobre una sola tabla)
fecha de nacimiento de todos los autores ordenada por

nacionalidad.
3.3.1 Seleccin de columnas
SELECT (<columna [, columna]...>|*)

FROM <nombre_tabla>
SELECT nombre, nacionalidad, fecha_nac

FROM autor
ORDER BY nacionalidad
En la expresin del SELECT tambin pueden aparecer expresiones

aritmticas (que dan lugar a columnas derivadas) con suma, resta,
multiplicacin y divisin con las prioridades habituales de la
aritmtica (izquierda a derecha, parntesis, etc.)
Resultado:
Nombre
Isaac Asimov
Miguel de Cervantes
Paloma Martnez
P. Isasi
D. Borrajo
Christian Jacq
Emily Bronte
Ken Follet
Ejemplo 1: calcular la subida en un 15% en el precio de

los documentos.
SELECT titulo, tipo_documento, precio* 1,15
FROM documento
Nacionalidad
Fecha_nac
Americana
Espaola
Espaola
Espaola
Espaola
Francesa
Inglesa
Inglesa
23-4-1930
9-10-1547
2-9-68
3-4- 66
23-8-65
30-6-1947
2-9-1818
5-8-1949
Resultado:
Ttulo
El Quijote
Cumbres Borrascosas
La Pirmide Asesinada
La Ley del Desierto
Tipo_documento
Novela
Novela
Novela
Novela
Precio *1,15
5750
4600
2300
2300
Introduccin a la ciencia
Los Pilares de la Tierra
Gramticas, Lenguajes y
Autmatas
Divulgativo
Novela
Tcnico
5175
6900
4025
3.3.3
Con restriccin (seleccionando filas, WHERE)

Hasta ahora se recuperaban todas las filas. Si se quiere restringir
las filas seleccionadas se utiliza WHERE con las condiciones que
deben cumplir las filas para ser visualizadas.
Consulta simple: La condicin est compuesta por un operador <, >,
=, >=, <= , <>, que unen:
- Dos columnas de la tabla
Tambin pueden utilizarse expresiones alfanumricas: lower (para

poner los valores en minsculas), upper (para ponerlos en
maysculas), substr (extraer una subcadena de una cadena de
caracteres), + (operador de concatenacin), length (calcula la
longitud de una cadena de caracteres), etc.
3.3.2
- Una columna y una constante (numrica, carcter, fecha)

Las columnas que se referencian en la condicin no tienen porque
ser seleccionadas en el SELECT.
Ordenando Filas (ORDER BY)
Ejemplo 3: seleccionar los autores cuya nacionalidad

sea espaola.
Las filas se almacenan en el mismo orden en que han sido

insertadas. Para obtenerlas ordenadas se aplica ORDER BY. Se
puede especificar ASC o DESC (por omisin es ASC).
SELECT nombre, nacionalidad, fecha_nac

FROM autor
WHERE nacionalidad = espaola
223
224
Resultado:
Ejemplo 6: alumnos cuyos nmeros de matricula estn

entre 200 y 400 (ambos inclusive).
Nombre
Miguel de Cervantes
Paloma Martnez
P. Isasi
D. Borrajo
Nacionalidad
Espaola
Espaola
Espaola
Espaola
Fecha_nac
9-10-1547
2-9-68
3-4- 66
23-8-65
SELECT *
FROM alumno
WHERE cod_matricula BETWEEN 200 AND 400
Resultado:
Consulta compleja: con operadores lgicos: NOT, AND, OR, IN,

BETWEEN AND, LIKE, NULL, NOT NULL. Cuidado con las
prioridades!!
cod_matricula
202
300
nombre
Ana Vallejo
Ignacio Lpez
ciudad
Legans
Mstoles
cod_grupo
21
31
Ejemplo 4: seleccionar aquellos autores que no sean

alemanes nacidos despus de la segunda guerra mundial.
Ejemplo 7: alumnos que no estn asignados a un grupo
SELECT *
FROM alumno
WHERE cod_grupo IS NULL
SELECT nombre
FROM autor
WHERE nacionalidad <> alemana AND fecha_nac> 02/09/1945
Resultado:
Resultado:
Nombre
Christian Jacq
Ken Follet
Paloma Martnez
P. Isasi
D. Borrajo
cod_matricula
103
SELECT nombre
FROM autor
WHERE nacionalidad IS NOT NULL
Resultado:
SELECT *
FROM alumno
WHERE ciudad IN (Getafe, Legans)
Nombre
Miguel de Cervantes
Emily Bronte
Isaac Asimov
Christian Jacq
Ken Follet
Paloma Martnez
P. Isasi
D. Borrajo
Resultado:
nombre
Alicia Cristobal
Ana Vallejo
ciudad
Alcorcn
Ejemplo 8: autores que tienen nacionalidad
Ejemplo 5: alumnos que viven en Getafe o Legans
cod_matricula
102
202
nombre
Leticia Martnez
ciudad
Legans
Legans
cod_grupo
11
21
225
226
cod_grupo
--
funciones son los valores pertenecientes a una o ms columnas.

Se pueden aplicar a uno o ms grupos de filas de tabla
(dependiendo de si se utiliza el GROUP BY o no).
Cuando no conocemos el conjunto exacto de caracteres que forman

la constante para indicar la restriccin se utiliza LIKE con unos
caracteres especiales _ (un carcter) y % (cualquier nmero de
caracteres)
Todas las funciones excluyen los valores nulos excepto COUNT(*)

- AVG: calcula la media de los valores de la coleccin
Ejemplo 9: autores cuyo nombre empiece por I
- MAX: calcula el mximo.

- MIN: calcula el mnimo
SELECT *
FROM autor
WHERE nombre LIKE I%
- SUM: calcula la suma de los valores de la coleccin

- COUNT(*): halla cuntos valores hay en la coleccin incluyendo
las nulas
Resultado:
Nombre
Isaac Asimov
Fecha_nac
23-4-1930
- COUNT(columna): cuenta el nmero de filas que tienen valor

distinto de nulo en la columna de cada grupo
Nacionalidad
Americana
- COUNT(DISTINCT columna): cuenta el nmero de filas distintas

que tienen valor distinto de nulo en la columna de cada grupo.
Se utilizar DISTINCT si no se quiere que aparezcan filas

recuperadas iguales.
Ejemplo 10: seleccionar las distintas nacionalidades que
Ejemplo 11: hallar el nmero de empleados de la
existen en la tabla autores.
empresa.
SELECT DISTINCT nacionalidad

FROM autor
SELECT COUNT (*) "Nmero de Empleados"

FROM empleado
Resultado:
Resultado:
Nacionalidad
Espaola
Inglesa
Americana
Francesa
Nmero de Empleados
6
Ejemplo 12: hallar el salario medio, el mnimo, el
3.3.4
mximo de todos los empleados
Agrupando filas (GROUP BY y HAVING)

Hasta ahora todas las consultas vistas devolvan un conjunto de
filas que cumplan una serie de condiciones. Es posible agrupar
las filas por determinados grupos de valores y aplicar funciones a
cada grupo.
SELECT AVG(salario) "Media", MIN(salario) "Mnimo MAX(salario)

"Mximo"
FROM empleado
Resultado:
A las funciones que en vez de actuar sobre una solo fila actan
sobre un grupo de filas se las denomina funciones de grupo y
devuelven un solo valor por cada grupo. El argumento de estas
227
228
Media
270.000
Mnimo
150.000
Resultado:
Mximo
400.000
Tipo_documento
Novela
Divulgativo
Tcnico
Ejemplo 13: hallar el nmero de empleados y de

extensiones telefnicas del departamento 14.
SUM(precio)
19.000
4500
3500
AVG(precio)
3800
4500
3500
Es posible indicar en el SELECT nombres de columnas con

funciones de agregacin siempre y cuando se utilicen esos
nombres de columnas en el GROUP BY.
SELECT COUNT(*), COUNT(DISTINCT ext_telefonica)

FROM empleado
WHERE numero_dept=14.
Resultado:
Ejemplo 16: calcular la suma de los precios y el precio
2
2
medio de los documentos agrupados por tipo de documento

(novela, tcnico, ...)
Ejemplo 14: cuntos empleados que han nacido antes
de 1970?
SELECT SUM(precio), AVG(precio), tipo_documento
FROM documento
GROUP BY tipo_documento
SELECT COUNT(*) "Nmero de Empleados"

FROM empleado
WHERE fecha_nac< 01/01/1970
Resultado:
Resultado:
Tipo_documento
Novela
Divulgativo
Tcnico
Nmero de Empleados
3
El grupo por defecto es la tabla entera. Si se quiere dividir la tabla
en grupos se utiliza GROUP BY con la que se especifican la(s)
columna(s) por las que se quiere agrupar.
SUM(precio)
19.000
4500
3500
AVG(precio)
3800
4500
3500
Si se quiere restringir los grupos de salida se utiliza la clusula

HAVING seguida de las condiciones que debe cumplir. El proceso
que se sigue es el siguiente: la clusula WHERE restringe las filas
de la tabla, despus se agrupan y slo se seleccionan aquellas
que cumplas las condiciones de la clusula HAVING.
Ejemplo 15: calcular la suma de los precios y el precio

medio de los documentos agrupados por tipo de documento
(novela, divulgacin, ...)
Ejemplo 17: nmero de grupos que existen en cada

SELECT SUM(precio), AVG(precio)
FROM documento
curso
SELECT curso, COUNT(*)

FROM grupo
229
230
GROUP BY curso
Ejemplo 20: Hallar para cada categora de profesorado
Resultado:
de
Madrid
el
sueldo
mximo
mnimo
ordenado
por
categora, pero slo de aquellas categoras que tengan
Curso
1
2
3
COUNT(*)
asociados ms de dos profesores
2
2
1
SELECT categora, MAX(salario), MIN(salario)

FROM profesor
WHERE ciudad=Madrid
GROUP BY categora
HAVING COUNT(categora) > =2
ORDER BY categora
Ejemplo 18: cursos que tienen un nico grupo y que

adems es de tarde
SELECT curso
FROM grupo
GROUP BY curso
HAVING COUNT(*)=1 AND turno=T
Resultado:
Categora
T1
T3
Resultado:
MAX(salario)
200.000
125.000
MIN(salario)
135.000
120.000
Curso
3
3.4 Consultas basadas en ms de una tabla
Ejemplo 19: media del nmero de copias de los
3.4.1 Combinando tablas: Join
documentos agrupados por tipo de documento y que la media

sea mayor que 10.
Hasta ahora slo hemos seleccionado datos de una nica tabla. Por
medio de la combinacin de tablas se pueden seleccionar datos
de tablas diferentes.
SELECT AVG(num_copias), tipo_documento

FROM documento
HAVING AVG(num_copias)>10
La unin de dos tablas es otra tabla que tiene por columnas la unin
de las columnas de las dos y por filas el producto cartesiano (cada
fila de la primera tabla se concatena con todas y cada una de las
filas de la otra). Tendr que haber una condicin de combinacin
para restringir las filas del producto cartesiano que realmente nos
interesan.
Resultado:
Tipo_documento AVG(num_copias)
Novela
13,2
Divulgativo
13
Tipos de combinacin:
x - Producto cartesiano: sin restricciones
El orden de ejecucin es: FROM, WHERE, GROUP BY, HAVING,

SELECT, ORDER BY.
231
232
x - Combinacin comn: la condicin de combinacin tiene un

operado de igualdad.
SELECT nombre, nacionalidad, cod_documento

FROM autor, escribe
WHERE autor.nombre=escribe.nombre AND
autor.nacionalidad='espaola'
x - Combinacin no comn: la condicin tiene un operador que no

es el de igualdad.
x - Autocombinacin: se combina una tabla consigo misma.
Resultado:
x - Combinacin exterior: selecciona las filas de una tabla que no

tienen correspondencia con alguna de la otra.
Nombre
Miguel de Cervantes
Paloma Martnez
P. Isasi
D. Borrajo
No influye el orden en que se especifican las columnas en el

SELECT y las tablas en el FROM.
Nacionalidad
Espaola
Espaola
Espaola
Espaola
Cod_documento
11
17
17
17
Para las combinaciones no comunes se puede utilizar >, <, >=, <>,
BETWEEN AND. Se pueden unir tantas tablas como se quiera
pero siempre deber haber n-1 condiciones de combinacin para
que la informacin sea coherente (n= nmero de tablas).
Ejemplo 21: Considerando las tablas AUTOR y ESCRIBE

(un autor escribe varios documentos y un documento puede
estar escrito por varios autores). Seleccionar el nombre de
autor, nacionalidad y el cdigo de los documentos escritos por
l.
Ejemplo 22: Considerando las tablas AUTOR, ESCRIBE,
SELECT nombre, nacionalidad, cod_documento

FROM autor, escribe
WHERE autor.nombre=escribe.nombre
DOCUMENTO (un autor escribe varios documentos y un

documento
puede
estar
escrito
por
varios
autores).
Seleccionar el nombre del autor, su fecha de nacimiento y

Resultado:
nacionalidad, el cdigo y el tipo de documento escritos por el

autor as como el ttulo de los mismos.
Nombre
Miguel de Cervantes
Emily Bronte
Isaac Asimov
Christian Jacq
Christian Jacq
Ken Follet
Paloma Martnez
P. Isasi
D. Borrajo
Nacionalidad
Espaola
Inglesa
Americana
Francesa
Francesa
Inglesa
Espaola
Espaola
Espaola
Cod_documento
11
12
15
13
14
16
17
17
17
SELECT nombre, fecha_nac, nacionalidad, cod_documento, ttulo,

tipo_documento
FROM autor a, escribe b, documento c
WHERE a.nombre=b.nombre AND
b.cod_documento=c.cod_documento
Resultado:
Nombre
Miguel de Cervantes
Emily Bronte
Puede darse otra condicin aparte de la de combinacin, por

ejemplo:
Isaac Asimov
Christian Jacq
Christian Jacq
233
234
Fecha_nac Nacionalidad Cod_documen Ttulo

to
9-10-1547 Espaola
11
El Quijote
2-9-1818
Inglesa
12
Cumbres
Borrascosas
23-4-1930 Americana
15
Introduccin a la
ciencia
30-6-1947 Francesa
13
La Pirmide
Asesinada
30-6-1947 Francesa
14
La Ley del
Desierto
Tipo_documento
Novela
Novela
Divulgativo
Novela
Novela
Ken Follet
5-8-1949
Inglesa
16
Paloma Martnez
2-9-68
Espaola
17
P. Isasi
3-4- 66
Espaola
17
D. Borrajo
23-8-65
Espaola
17
Los Pilares de la
Tierra
Gramticas,
Lenguajes y
Autmatas
Gramticas,
Lenguajes y
Autmatas
Gramticas,
Lenguajes y
Autmatas
Novela
Pedro Garca
200.000 6321
Angel Vallejo
Tcnico
La combinacin exterior selecciona aquellas tuplas que no tienen

correspondencia (en ingls se denomina OUTER JOIN), que
puede ser LEFT OUTER JOIN, RIGHT OUTER JOIN Y FULL
OUTER JOIN.
Tcnico
Tcnico
Ejemplo 24: seleccionar los autores con los documentos

que han escrito. Se deben incluir tambin los autores que no
La autocombinacin se realiza por medio de columnas que

contienen la misma informacin. El resultado es otra tabla que
tendr por columnas dos veces las columnas de la tabla original y
por filas el producto cartesiano de la tabla por s misma.
hayan escrito documento alguno
SELECT nombre, cod_documento

FROM autor, escribe
WHERE autor.nombre=escribe.nombre(+)
Ejemplo 23: seleccionar para cada empleado de la

empresa su nombre, salario y el nombre y la extensin
Resultado:
telefnica de su jefe. Supongamos la siguiente relacin

empleado extendida con la informacin de los jefes:
No existe ningn autor que no haya escrito documento, luego el

resultado es el mismo que sin (+)
Empleado
Nombre
Pablo Montero
Beatriz Cristobal
J.Luis Martn
Almudena Lpez
Angel Vallejo
Pedro Garca
Numero_dept
14
13
11
13
14
11
Salario
220.000
300.000
150.000
350.000
400.000
200.000
Fecha_nac
10-11-67
20-9-68
25-6-77
4-5-60
15-4-72
12-3-70
Ext_telefnica
6543
6577
6433
6422
6321
6323
3.4.2 Operadores de conjunto (UNION, INTERSECT, EXPECT)
Jefe
Beatriz Cristobal
-Beatriz Cristobal
Angel Vallejo
-Angel Vallejo
Son los mismos que los de la Teora de Conjuntos y combinan dos o

ms consultas en un mismo resultado. Los SELECT debe tener el
mismo nmero de columnas y deben corresponderse en tipo. En
estos operadores est implcita la clusula DISTINCT y son
incompatibles con ORDER BY.
SELECT emp.nombre, emp.salario, superior.nombre,

superior.ext_telefnica
FROM empleado emp, empleado superior
WHERE emp.jefe=superior.nombre
7 - UNION: recupera todas las filas que han sido seleccionadas en

los dos SELECT
8 - INTERSECT: devuelve las filas comunes que han sido
seleccionadas por los mandatos SELECT
Resultado:
Nombre
Pablo Montero
Beatriz Cristobal
J.Luis Martn
Almudena Lpez
Angel Vallejo
Salario
220.000
300.000
150.000
350.000
400.000
Ext_telefnica
6577
-6577
6321
--
9 - EXCEPT (MINUS): devuelve las filas que han sido

seleccionadas por el primer mandato SELECT y no lo han sido
por el segundo
Jefe
Beatriz Cristobal
-Beatriz Cristobal
Angel Vallejo
-235
236
Ejemplo 25: Nombre de los autores de nacionalidad

Resultado:
espaola e inglesa (obsrvese que si la UNION se realiza

sobre la misma tabla, bastara una condicin OR).
Nombre
D. Cuadra
E. Nieto
P. Martnez
SELECT nombre, nacionalidad

FROM autor
WHERE nacionalidad='espaola'
UNION
SELECT nombre, nacionalidad
FROM autor
WHERE nacionalidad='inglesa'
Ejemplo 27 : Seleccionar los nombres de de los

profesores que no son coordinadores
SELECT nombre
FROM profesor
MINUS
SELECT nombre
FROM coordinador
Resultado:
Nombre
Miguel de Cervantes
Paloma Martnez
P. Isasi
D. Borrajo
Emily Bronte
Ken Follet
Nacionalidad
Espaola
Espaola
Espaola
Espaola
Inglesa
Inglesa
Resultado:
Nombre
C. Nieto
A. Sierra
C. Garca
J. Montero
Supongamos que en el enunciado de la Universidad tenemos otra

tabla denominada Coordinador de la siguiente forma:
Coordinador
Cod_coord
1p
2p
3p
Nombre
D. Cuadra
E. Nieto
P. Martnez
Ciudad
Madrid
Las Rozas
Alcorcn
Categora
T1
T2
T1
Salario
200.000
250.000
225.000
Ejemplo 26 : Seleccionar los nombres de las personas

que sean profesores y coordinadores.
SELECT nombre
FROM profesor
INTERSECT
SELECT nombre
FROM coordinador
237
238
El lenguaje de manipulacin de datos del SQL (LMD) es un lenguaje de

especificacin, que consiste en un conjunto de sentencias que nos
permiten manipular la base de datos.
Las operaciones que se pueden hacer sobre la base de datos son: Altas,
bajas, modificaciones y consultas.
La sintaxis de las consultas en SQL es:
SELECT [(*|ALL|DISTINCT| <columna [, columna]...>)| <expresin de

funcin>]
FROM <nombre_tabla> [[, nombre_tabla]...]
WHERE <condicin de bsqueda> |
[GROUP BY <condicin de bsqueda>]
HAVING <condicin de bsqueda> |
ORDER BY <lista de atributos> [ASC|DESC] |
<columna> <operador> <sentencia de consulta>
donde:
ALL: selecciona todas las columnas
DISTINCT: suprime filas duplicadas
Operadores para la condicin de bsqueda: <, >, =, >=, <=, between,
like, in,...
y tambin los operadores lgicos: NOT, AND, OR.
239

Bases de Datos Relacionales

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bases de Datos Relacionales

Uploaded by

Copyright:

Available Formats

ndice

Unidad didctica 1: lgebra relacional

1. Introduccin a las Bases de Datos

En esta unidad aprenders:

Introduccin a las Bases de Datos

1. La Base de Datos como un componente de los

Qu es una base de datos y sus principales ventajas

Introduccin a las Bases de Datos

El componente que nos interesa en este libro, la Base de Datos, se

encuentra en el software del sistema de informacin. A continuacin, vamos a

La Base de Datos como un componente de los Sistemas de

dar una definicin ms precisa de este componente que desglosaremos en todos

sus aspectos. Posteriormente, estudiaremos la necesidad de las Bases de Datos

en los sistemas de informacin actuales en contraposicin a los sistemas de

cinco grandes componentes:

El Contenido, es decir, los datos con su correspondiente descripcin,

Equipo fsico (hardware) formado por la unidad central de proceso y los

Equipo lgico (software) compuesto por los programas, documentacin,

comunicaciones y dar soporte a tratamientos especficos (por ejemplo,

El Administrador, encargado de asegurar la calidad de los datos

administrador o administradores debe controlar la disponibilidad, la

Un conjunto de Usuarios formado por las personas que acceden al

Introduccin a las Bases de Datos

partes de la BD y no se controlara: puede ocurrir que si un cliente

cambia de direccin postal y slo se actualiza esta informacin en uno de

Definicin de Base de Datos

los sitios, entonces la BD quedara en estado inconsistente (el cliente

datos integrados, almacenados en soporte secundario (no voltil) y con

Posteriormente, se volver al tema de la redundancia cuando se estudien

redundancia controlada. Los datos, que han de ser compartidos por

los modelos de datos como herramientas de diseo de Bases de Datos.

diferentes usuarios y aplicaciones, deben mantenerse independientes de

Por otro lado, las BD han de atender a mltiples usuarios de la organizacin

ellos y su definicin (estructura de la BD), nica y almacenada junto con

(informticos que desarrollan programas de acceso a la BD, administrativos

los datos, se ha de apoyar en un modelo de datos, el cual ha de permitir

usuarios de las aplicaciones, etc.) as como a distintas aplicaciones (por ejemplo,

captar las interrelaciones y restricciones existentes en el mundo real.

aplicaciones de contabilidad, de facturacin, etc., todas ellas accediendo a los

Los procedimientos de actualizacin y recuperacin, comunes y bien

datos contenidos en la BD de la empresa).

determinados, facilitarn la seguridad del conjunto de los datos. De

Miguel et. al (1999)

tradicionales de ficheros. Aunque no entraremos aqu en detalles de en qu

consisten los sistemas de ficheros que se utilizaban con anterioridad a la

definicin de Base de Datos que no son ms que distintas definiciones segn

aparicin de las BD s indicaremos algunos aspectos relevantes que los

diferencian de las BD; estos aspectos son:

La Base de Datos es un conjunto de datos relativos a una determinada

Independencia de datos y procesos: es el objetivo fundamental de las

petroqumica, una universidad, etc.,) que se almacenan en un soporte

En los sistemas basados en ficheros cada fichero se diseaba para

informtico no voltil (es decir, dispositivos de memoria secundaria como

responder a las necesidades de una aplicacin determinada y apenas

en un nico almacn y son accedidos por todas las aplicaciones.

Adems, no debe existir redundancia (el trmino redundancia es

Descripcin de los datos junto con los datos: la definicin y descripcin2

sinnimo de datos repetidos), es decir, no deben existir duplicidades

del conjunto de datos contenidos en la BD deben ser nicas y estar

perjudiciales ni innecesarias (a ser posible un determinado tipo de dato,

por ejemplo, los datos de un cliente de una empresa, slo deben

estn interrelacionados y estructurados de acuerdo a un modelo capaz

aparecer en un sitio en la BD). En ocasiones, es necesaria cierta