You are on page 1of 122

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

Introduccin a las Bases de Datos

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.

Introduccin a las Bases de Datos

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.

Introduccin a las Bases de Datos

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

Introduccin a las Bases de Datos

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

Introduccin a las Bases de Datos

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

Introduccin a las Bases de Datos

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

Introduccin a las Bases de Datos

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

En esta unidad aprenders:

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

Metodologas de Desarrollo de Bases de Datos

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

Metodologas de Desarrollo de Bases de Datos

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

Metodologas de Desarrollo de Bases de Datos

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

Metodologas de Desarrollo de Bases de Datos

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

En esta unidad aprenders:

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

Fase de Anlisis de Requisitos : Modelo E/R

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

Fase de Anlisis de Requisitos : Modelo E/R

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

Fase de Anlisis de Requisitos : Modelo E/R

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.

D.N.I. Nombre Direccin


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

Fase de Anlisis de Requisitos : Modelo E/R

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

Fase de Anlisis de Requisitos : Modelo E/R

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

Fase de Anlisis de Requisitos : Modelo E/R

Cdigo

Nombre Localizacin Telfono

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

Nombre Localizacin Telfono

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

Figura 2.18: Interrelacin Trabajar

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

Fase de Anlisis de Requisitos : Modelo E/R

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

Fase de Anlisis de Requisitos : Modelo E/R

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

Nombre Localizacin Telfono

Figura 2.21: Notacin grfica de una entidad dbil

Figura 2.20: Interrelacin Trabajar

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

Fase de Anlisis de Requisitos : Modelo E/R

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

Fase de Anlisis de Requisitos : Modelo E/R

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

Fase de Anlisis de Requisitos : Modelo E/R

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

Fase de Anlisis de Requisitos : Modelo E/R

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.


El proyecto MENTOR, adems, tiene en cuenta que ha de facilitar a los

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

todos los servicios necesarios para el pleno desarrollo de los cursos.

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.

ordenadores como de los programas se lleva a cabo por los


administradores de aula. Aula va cogiendo peso como posible entidad

De los alumnos se desea saber el DNI, nombre completo, direccin,


telfono, nacionalidad, pero slo interesa saber si la nacionalidad es

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

espaola o no, y la direccin de correo electrnico. La direccin de

direccin.

correo electrnico es imprescindible para poder realizar los cursos y

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

La informacin que se necesita de cada administrador es su DNI,

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

Fase de Anlisis de Requisitos : Modelo E/R

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.
El proyecto MENTOR, adems, tiene en cuenta que ha de facilitar a los

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.

todos los servicios necesarios para el pleno desarrollo de los cursos.


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

ordenadores como de los programas se lleva a cabo por los

un alumno.

administradores de aula. Aula va cogiendo peso como posible entidad


De los alumnos se desea saber el DNI, nombre completo, direccin,
Cada aula tiene asignado un cdigo nico, una descripcin y una

telfono, nacionalidad, pero slo interesa saber si la nacionalidad es


espaola o no, y la direccin de correo electrnico. La direccin de

direccin.

correo electrnico es imprescindible para poder realizar los cursos y

especificado sus atributos

adems nica para cada alumno. Observamos que del nico

Definitivamente

aula

es

una

entidad,

ya

nos

han

La informacin que se necesita de cada administrador es su DNI,

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

Fase de Anlisis de Requisitos : Modelo E/R

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

Fase de Anlisis de Requisitos : Modelo E/R

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

Fase de Anlisis de Requisitos : Modelo E/R

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

Fase de Anlisis de Requisitos : Modelo E/R

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

Fase de Anlisis de Requisitos : Modelo E/R

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

nacionalidad = (espaola, no_espaola)

(1, n)

N:M

(1, n)

F_Finalizacin

nacionalidad = (espaola, no_espaola)

Matricular

N:M

coordinador = (SI, NO)

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

Fase de Anlisis de Requisitos : Modelo E/R

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

Fase de Anlisis de Requisitos : Modelo E/R

Por ltimo, interesa conocer para cada rey la informacin de su

5. DISEO PROPUESTO AL CASO PRCTICO - HISTORIA

ascendente. En aquella poca ya se sabe que su ascendiente sera


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.
2 paso: Identificar y enumerar las posibles interrelaciones, teniendo en
cuenta la siguiente heurstica: en general, una interrelacin viene reflejada por
1 paso: Identificar y enumerar las posibles entidades teniendo en

un verbo dentro de una oracin que relaciona dos objetos.

cuenta la siguiente heurstica: en general, un tipo de entidad es un


sustantivo dentro de una oracin con una seria de propiedades o
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.

En el texto presentamos en negrita y subrayado los tipos de entidad que

Interesa conocer la informacin de los caballeros ms importantes de

hemos detectado.

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


nacimiento y apodo.

Interesa conocer la informacin de los caballeros ms importantes de


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

Tambin ser importante conocer las provincias de aquella poca, de

nacimiento y apodo.

las que guardaremos la informacin de su denominacin, nmero de


habitantes y los caballeros que las gobernaron, teniendo en cuenta

Tambin ser importante conocer las provincias de aquella poca, de

que un caballero pudo gobernar1 ms de una provincia y que una

las que guardaremos la informacin de su denominacin, nmero de

provincia estuvo gobernada por diferentes caballeros en distintas

habitantes y los caballeros que las gobernaron, teniendo en cuenta

fechas. Interesar conocer el ao de inicio y el nmero de aos que

que un caballero pudo gobernar ms de una provincia y que una

estuvo gobernada por cada caballero.

provincia estuvo gobernada por diferentes caballeros en distintas


fechas. Interesar conocer el ao de inicio y el nmero de aos que

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

En esta poca tambin fueron muy importantes los reyes, de los que

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

En esta poca tambin fueron muy importantes los reyes, de los que

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.

Por ltimo, interesa conocer para cada rey la informacin de su


ascendente. En aquella poca ya se sabe que su ascendiente sera
otro rey.
75

76

Fase de Anlisis de Requisitos : Modelo E/R

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

Fase de Anlisis de Requisitos : Modelo E/R

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
Apodo completo Fecha_Nac

Nombre

Fecha_Inicio

Fecha_Fin
Nombre
Apodo completo Fecha_Nac

(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

Fase de Anlisis de Requisitos : Modelo E/R

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

Denominacin Num_Habitantes

Corona

N:1
PROVINCIA
Nombre

Denominacin Num_Habitantes

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

Fase de Anlisis de Requisitos : Modelo E/R

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

Fase de Anlisis de Requisitos : Modelo E/R

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
1 paso: Identificar y enumerar las posibles entidades teniendo en

continuacin los requisitos para la creacin de la base de datos:

cuenta la siguiente heurstica: en general, un tipo de entidad es un


sustantivo dentro de una oracin con una seria de propiedades o

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

En el texto presentamos en negrita y subrayado los tipos de entidad que

sucursales. De ellos se quiere conocer su Dni, nombre, apellidos y la

hemos detectado.

fecha de contratacin.

Cada sucursal se identifica por un cdigo y se requiere la informacin

De los inmuebles que gestiona cada sucursal interesa conocer el

de su direccin, cdigo postal, poblacin y telfono.

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

sucursales. De ellos se quiere conocer su Dni, nombre, apellidos y la

sucursal.

fecha de contratacin.

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

Cdigo del inmueble, su direccin, cdigo_postal, poblacin, n de

telfono. Tendremos en cuenta que un inmueble puede ser alquilado

habitaciones, n de baos, y el importe de su alquiler mensual. Se

por diferentes clientes a lo largo del tiempo y nos interesar conocer

tendr en cuenta que un inmueble ser gestionado por una nica

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

Nos interesa conocer la informacin de su DNI, nombre, apellidos, y

inmueble. Nos interesa conocer la informacin de su DNI, nombre,

telfono. Tendremos en cuenta que un inmueble puede ser alquilado

apellidos, telfono, y precio mximo que est dispuesto a pagar por

por diferentes clientes a lo largo del tiempo y nos interesar conocer

el alquiler. Un cliente potencial ser atendido por un nico comercial.

la fecha de inicio, la fecha de fin y el importe mximo mensual que


un cliente pag por ese alquiler.

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


enviar mensualmente todos sus informes de alquileres. La sucursal

Sus clientes potenciales son aquellos que buscan el alquilar de un

principal tendr a su cargo varias sucursales.

inmueble. Nos interesa conocer la informacin de su DNI, nombre,


85

86

Fase de Anlisis de Requisitos : Modelo E/R

apellidos, telfono, y precio mximo que est dispuesto a pagar por

la fecha de inicio, la fecha de fin y el importe mximo mensual que

el alquiler. Un cliente potencial ser atendido por un nico comercial.

un cliente pag por ese alquiler.

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

Sus clientes potenciales son aquellos que buscan el alquilar de un

enviar mensualmente todos sus informes de alquileres. La sucursal

inmueble. Nos interesa conocer la informacin de su DNI, nombre,

principal tendr a su cargo varias sucursales.

apellidos, telfono, y precio mximo que est dispuesto a pagar por


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,

enviar mensualmente todos sus informes de alquileres. La sucursal

INMUEBLE, CLIENTE REAL y CLIENTE POTENCIAL.

principal tendr a su cargo varias sucursales.

2 paso: Identificar y enumerar las posibles interrelaciones, teniendo en


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

reflejada por un verbo dentro de una oracin que relaciona dos objetos.

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

Cada sucursal se identifica por un cdigo y se requiere la informacin


de su direccin, cdigo postal, poblacin y telfono.
Se desea conocer los comerciales que trabajan1 en las distintas
sucursales. De ellos se quiere conocer su Dni, nombre, apellidos y la
fecha de contratacin.

SUCURSAL

Depender 5

COMERCIAL

Trabajar 1

INMUEBLE

Gestionar 2

CLIENTE

Cdigo del inmueble, su direccin, cdigo_postal, poblacin, n de

CLIENTE

REAL

POTENCIAL

Alquilar 3

CLIENTE REAL
De los inmuebles que gestiona2 cada sucursal interesa conocer el

CLIENTE

Atender 4

POTENCIAL

habitaciones, n de baos, y el importe de su alquiler mensual. Se


tendr en cuenta que un inmueble ser gestionado por una nica
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

Nos interesa conocer la informacin de su DNI, nombre, apellidos, y

semnticas.

telfono. Tendremos en cuenta que un inmueble puede ser alquilado


por diferentes clientes a lo largo del tiempo y nos interesar conocer
87

88

Fase de Anlisis de Requisitos : Modelo E/R

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::

Interrelacin Trabajar

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
Direccion Poblacin Telfono
Cod_Suc.
Cod_Postal
Direccion Poblacin Telfono

Nombre
Apellidos Fecha_Contrato
DNI

Nombre
Apellidos Fecha_Contrato
DNI

1:N
SUCURSAL

(1,1)

(1,n)

Trabajar
SUCURSAL

Trabajar

Constructora 3::
Constructora 1::

COMERCIAL

COMERCIAL
Interrelacin Trabajar

Interrelacin Trabajar

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

Fase de Anlisis de Requisitos : Modelo E/R

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
Direccion Poblacin Telfono
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
Cod_Inmueble. Num_Habitaciones.
Importe_Alquiler

Cod_Suc.
Cod_Postal
Direccion Poblacin Telfono

(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

Fase de Anlisis de Requisitos : Modelo E/R

- 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
Cod_Inmueble. Num_Habitaciones.
Fecha_InicFecha_Fin
Importe_Alquiler
Importe_Max
N:M

(1,n)
CLIENTE (real)

DNI.

Nombre

Apellidos

Cod_Postal
Direccin.
Num_Baos
Cod_Inmueble. Num_Habitaciones.
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
Cod_Inmueble. Num_Habitaciones.
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

Fase de Anlisis de Requisitos : Modelo E/R

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
Apellidos Fecha_Contrato
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
Apellidos Fecha_Contrato
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

Fase de Anlisis de Requisitos : Modelo E/R

Diagrama Entidad-Relacin
Direccin Poblacin
Cod_Postal Telfono
Cod_Sucural

SUCURSAL

N:1
1:1

Depender
(1,n)

(1,1

Depender

Constructora 15: Interrelacin Depender

Cod_Postal
Direccin.
Num_Baos
Cod_Inmueble. Num_Habitaciones.
Importe_Alquiler

Cod_Suc.
Cod_Postal
Direccion Poblacin Telfono
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
Constructora 16: Interrelacin Depender

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

Fase de Anlisis de Requisitos : Modelo E/R

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

1 paso: Identificar y enumerar las posibles entidades teniendo en

han permanecido expuestas. Se presenta a continuacin la

cuenta la siguiente heurstica: en general, un tipo de entidad es un

especificacin de los requisitos de forma detallada:

sustantivo dentro de una oracin con una seria de propiedades o


caractersticas tales como, DNI del alumno, nombre del curso, etc.

De los artistas se requiere: DNI, nombre, apellidos, sexo, apodo


En el texto presentamos en negrita y subrayado los tipos de entidad que

(quienes lo tengan), fecha de nacimiento y su direccin de correo

hemos detectado.

electrnico.
surrealista,

De los artistas se requiere: DNI, nombre, apellidos, sexo, apodo

impresionista,...) y diferentes tcnicas (leo, escultura, acuarela, .)

(quienes lo tengan), fecha de nacimiento y su direccin de correo

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

impresionista,...) y diferentes tcnicas (leo, escultura, acuarela, .)

(alto, largo, ancho), valor de la ltima subasta (si es que ha sido

Cada estilo y cada tcnica vendrn identificadas por un cdigo y se

subastada), valor estimado por el tasador, as como el artista que la

almacenar la informacin de su descripcin.

cre. Tambin se recoger informacin del estilo al que pertenece y

De las obras es necesario recoger el nombre de la obra, dimensiones

de la tcnica empleada.

(alto, largo, ancho), valor de la ltima subasta (si es que ha sido

Adems si la obra ha estado expuesta en alguna sede, se necesita

subastada), valor estimado por el tasador, as como el artista que la

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.

saber el nombre y la direccin de la sede, as como la exposicin en


la que tuvo cabida. Una obra puede haber sido expuesta en varias
sedes y en una misma sede varias veces, por lo que es importante
almacenar la fecha en la que se realizo la exposicin.

99

100

Fase de Anlisis de Requisitos : Modelo E/R

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
reflejada por un verbo dentro de una oracin que relaciona dos objetos.

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

De los artistas se requiere: DNI, nombre, apellidos, sexo, apodo

atributos correspondientes.

(quienes lo tengan), fecha de nacimiento y su direccin de correo


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

Interrelacin Trabajar 1

impresionista,...) y diferentes tcnicas (leo, escultura, acuarela, .)


Las entidades participantes de esta interrelacin son ARTISTA y ESTILO. La

Cada estilo y cada tcnica vendrn identificadas por un cdigo y se

entidad ARTISTA presenta los atributos DNI, nombre, apellidos, sexo, apodo

almacenar la informacin de su descripcin.

(quienes lo tengan), fecha de nacimiento y su direccin de correo electrnico.


De las obras es necesario recoger el nombre de la obra, dimensiones

Como IP se elige el atributo DNI ya que permite identificar de forma nica a

(alto, largo, ancho), valor de la ltima subasta (si es que ha sido

cada uno de los artistas. La entidad ESTILO contar con los atributos Cdigo de

subastada), valor estimado por el tasador, as como el artista que la

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
saber el nombre y la direccin de la sede, as como la exposicin en

La figura 1: Interrelacin Trabajar muestra el esquema parcial E/R:

la que tuvo cabida. Una obra puede haber sido expuesta en varias
sedes y en una misma sede varias veces, por lo que es importante
almacenar la fecha en la que se realizo la exposicin.

101

102

Fase de Anlisis de Requisitos : Modelo E/R

DNI

DNI

Cod_Estilo

Fecha_Nac
Apellidos
Nombre Sexo Apodo E-mail

Descripcion

Cod_Estilo

Fecha_Nac
Apellidos
Nombre Sexo Apodo E-mail

Descripcion
N:M

ARTISTA

Artistas 1:

ARTISTA

ESTILO

Trabajar

Trabajar.

Para

ver

Interrelacin Trabajar

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
Nombre Sexo Apodo E-mail

Descripcion
DNI

ARTISTA

(1,n)

Trabajar

Cod_Tcnica

Fecha_Nac
Apellidos
Nombre Sexo Apodo E-mail

Descripcion

ESTILO
ARTISTA

Trabajar

Artistas 2: Cardinalidad de Artista en la interrelacin Trabajar

Artistas 4:

TCNICA

Interrelacin Trabajar

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

Fase de Anlisis de Requisitos : Modelo E/R

La interrelacin Crear presenta un tipo de cardinalidad de uno a muchos,


DNI

Fecha_Nac
Apellidos
Nombre Sexo Apodo E-mail

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
Nombre Sexo Apodo E-mail

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
Nombre Sexo Apodo E-mail

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

Fase de Anlisis de Requisitos : Modelo E/R

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

Fase de Anlisis de Requisitos : Modelo E/R

Diagrama Entidad-Relacin

Nombre

Valor_Subasta
Valor_Tasador
Nombre Dimensiones

Direccin
N:M

OBRA

(1,n)

(1,n)

SEDE

Exponer

DNI

Apellidos
Fecha_Nac
Nombre Sexo Apodo E-mail

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

Fase de Anlisis de Requisitos : Modelo E/R

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

En esta unidad aprenders:

Modelo Relacional

x
x
x

UNIDAD DIDCTICA 2
En esta unidad aprenders:

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

* Representacin de la clave ajena por extensin de las relaciones:

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

* Representacin de la clave ajena por extensin de las relaciones:

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

* Representacin de la clave ajena por intensin de las relaciones:

ARTISTA (Cod_artista, Nombre, Nacionalidad, Especialidad, Cod_artista_maestro)

* Representacin de la clave ajena por intensin de las relaciones:


ARTISTA (Cod_artista, Nombre, Nacionalidad,
Figura 2.48: Ejemplo de utilizacin de clave ajena

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:
Figura 2.47: Ejemplo de utilizacin de clave ajena

- 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 )

CURSO (Nombre, Libro_Consulta*, WWW)


Libro de
Nombre
consulta

D.N.I. Nombre Direccin


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

ALUMNOS ( DNI, Nombre, Direccin, Nacionalidad, E-mail, Telfono*)

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)
ALUMNOS ( DNI, Nombre, Direccin, Nacionalidad, E-mail, Telfono*)

DEPARTAMENTO (Nombre , Localizacin, Telfono)

BC:MC

MATRICULAR ( DNI, Nombre )


Figura 2.56: Transformacin de la Interrelacin Trabajar

BC:MC

CURSO (Nombre, Libro_Consulta*, WWW)

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:
Objetos en el modelo E/R

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

Transformacin al modelo
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

nacionalidad = (espaola, no_espaola)

Matricular

N:M

Una vez transformadas las entidades, veamos que tipo de interrelacin las
coordinador = (SI, NO)
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

Objetos en el modelo E/R


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
Objetos en el modelo E/R

Transformacin al modelo
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

Transformacin al modelo

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

Objetos en el modelo E/R

(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

Objetos en el modelo E/R

Transformacin al modelo
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)
Objetos en el modelo E/R

REY

Transformacin al modelo
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)

CABALLEROS ( Apodo, Nombre, Apellido, Fecha_Nac)

BR:MC

PROVINCIAS ( Denominacin, Num_Habitantes)

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
Apodo completo Fecha_Nac

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:

Objetos en el modelo E/R

Transformacin al modelo
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

PROVINCIAS ( Denominacin, Num_Habitantes)

Identificador principal: Nombre

Clave primaria: Nombre

Atributos Obligatorios:

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)

CABALLEROS ( Apodo, Nombre, 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)

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:

CABALLEROS ( Apodo, Nombre, Apellido, Fecha_Nac)

Nombre

Denominacin Num_Habitantes

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
CRUZADAS (Nombre_Cruzada, Fecha_Inicio, Fecha_Fin)

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
Objetos en el modelo E/R

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

Transformacin al modelo
relacional

Entidad: REY
Relacin: REYES

CABALLEROS o CRUZADAS, se propague dicha actualizacin sobre la relacin


PARTICIPAR.

REY

147

148

Identificador principal: Nombre

Clave primaria: Nombre

Atributos Obligatorios:

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

REY ( Nombre_Rey, Fecha_Nac, Corona )

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

REY ( Nombre_Rey, Fecha_Nac, Corona )

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.

CABALLEROS ( Apodo, Nombre, Apellido, Fecha_Nac)

N:1
Depender

BR:MC
(1,n)

GOBERNAR (Apodo, Denominacin, Ao_Inicio, Num_Aos)

(1,1

BR:MC
Cod_Postal
Direccin.
Num_Baos
Cod_Inmueble. Num_Habitaciones.
Importe_Alquiler

PROVINCIAS ( Denominacin, Num_Habitantes)


Cod_Suc.
Cod_Postal
Direccion Poblacin Telfono
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)

CRUZADAS (Nombre_Cruzada, Fecha_Inicio, Fecha_Fin)

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
Direccion Poblacin Telfono

Nombre
Apellidos Fecha_Contrato

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)

Objetos en el modelo E/R

Cod_Suc.
Cod_Postal
Direccion Poblacin Telfono

Transformacin al modelo
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.

SUCUSAL (Cod_Suc, Direccin, Cod_Postal, Poblacin,_Telfono)


Objetos en el modelo E/R

Nombre
Apellidos Fecha_Contrato
DNI

COMERCIAL

MC:BR

Transformacin al modelo

COMERCIAL ( DNI, Apellidos, Fecha_Contrato, Cod_Suc)

relacional - Relacin:
Entidad: COMERCIAL

COMERCIALES

Identificador principal: DNI

Clave primaria: DNI

Atributos Obligatorios: Nombre,

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

SUCUSAL (Cod_Suc, Direccin, Cod_Postal, Poblacin,_Telfono)

Objetos en el modelo E/R

Nombre
Apellidos Fecha_Contrato
DNI

COMERCIAL

BR:MC

INMUEBLE ( Cod_Inmueble, Direccin, Cod_Postal, Num_Habitaciones, Num_Baos, Importe_Alquiler, Cod_Suc)

Transformacin al modelo
relacional - Relacin:

Entidad: INMUEBLE

Identificador principal:

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.

Objetos en el modelo E/R

DNI.

Nombre

Apellidos

SUCUSAL (Cod_Suc, Direccin, Cod_Postal, Poblacin,_Telfono)

Telfo

Transformacin al modelo
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

Identificador principal: DNI

Clave primaria: DNI

Atributos Obligatorios: Nombre,

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)

CLIENTE ( DNI, Nombre, Apellidos, Telfono)


Transformacin de una interrelacin N:M con atributos de la interrelacin y opciones de

ALQUILAR ( DNI, Cod_Inmueble )

borrado y actualizacin

INMUEBLE ( Cod_Inmueble, Direccin, Cod_Postal, Num_Habitaciones, Num_Baos, Importe_Alquiler)

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

CLIENTE ( DNI, Nombre, Apellidos, Telfono)

Apellidos
Precio_Max
Nombre
Telfono

Nombre
Apellidos Fecha_Contrato
N:1

ALQUILAR ( DNI, Cod_Inmueble, Fecha_Inicio, Fecha_Fin, Importe_Max )

CLIENTE
POTENCIAL

(1,n)

DNI
(1,1)

Atender

COMERCIAL

INMUEBLE ( Cod_Inmueble, Direccin, Cod_Postal, Num_Habitaciones, Num_Baos, Importe_Alquiler)

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.
Objetos en el modelo E/R

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

Transformacin al modelo
relacional - Relacin: CLIENTES

Entidad: CLIENTE POTENCIAL

POTENCIALES

Identificador principal: DNI

Clave primaria: DNI

Atributos Obligatorios: Nombre,

Atributos NOT NULL Nombre,

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
COMERCIAL ( DNI, Apellidos, Fecha_Contrato, Cod_Suc)

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:
Veremos ahora las acciones en caso de modificacin y borrado. No se debe
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)

COMERCIAL ( DNI, Apellidos, Fecha_Contrato, Cod_Suc)

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

MODELO RELACIONAL FINAL

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
Nombre Sexo Apodo E-mail

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
Nombre Sexo Apodo E-mail

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)

Objetos en el modelo E/R

DNI

Fecha_Nac
Apellidos
Nombre Sexo Apodo E-mail

Transformacin al modelo

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

Identificador principal: DNI

Clave primaria: DNI

Atributos Obligatorios: Nombre,

Atributos NOT NULL Nombre,

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.

ARTISTA ( DNI, Nombre, Apellidos, Sexo, Fecha_Nac, Apodo, E-mail)


BR:MC

TRABAJAR ( DNI, Cod_Estilo)


Cod_Estilo

Objetos en el modelo E/R

Descripcion

Transformacin al modelo

BR:MC

relacional- Relacin: ESTILOS

ESTILO (Cod_Estilo, Descripcin)

Entidad: ESTILOS

ESTILO
Identificador principal:

Transformacin de una interrelacin N:M con opciones de borrado y actualizacin

Clave Primaria: Cod_Estilo

Cod_Estilo
Atributos NOT NULL:
Atributos Obligatorios:

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
Nombre Sexo Apodo E-mail

cascada.

Descripcion
N:M

ARTISTA

(1,n)

(1,n)
Trabajar

TCNICA

ARTISTA ( DNI, Nombre, Apellidos, Sexo, Fecha_Nac, Apodo, E-mail)


BR:MC

TRABAJAR ( DNI, Cod_Tcnica)


BR:MC

TCNICA (Cod_Tcnica, Descripcin)

Transformacin de una interrelacin N:M con opciones de borrado y actualizacin


Objetos en el modelo E/R

Transformacin al modelo
relacional

Entidad: TCNICA

Cod_Tcnica
Descripcion

TCNICA

Relacin: TCNICAS

Identificador principal:

A continuacin transformaremos la interrelacin Crear:

Clave Primaria: Cod_Tcnica

Cod_Tcnica

DNI
Atributos NOT NULL:

Atributos Obligatorios:

Fecha_Nac
Apellidos
Nombre Sexo Apodo E-mail
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

Transformacin al modelo

E/R

relacional

unin de las claves primarias de las relaciones ARTISTA y TCNICA.


Valor_Subasta
Valor_Tasador
Nombre Dimensiones

ARTISTA ( DNI, Nombre, Apellidos, Sexo, Fecha_Nac, Apodo, E-mail)


OBRA

Entidad: OBRA

Identificador principal:

Relacin: OBRAS

Clave Primaria: Nombre

Nombre
Atributos NOT NULL:

TRABAJAR ( DNI, Cod_Tcnica)


Atributos Obligatorios:

Dimensiones, ValorSubasta,

Dimensiones,

ValorTasador

ValorSubasta, ValorTasador

TCNICA (Cod_Tcnica, Descripcin)

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.


Veremos ahora las acciones en caso de modificacin y borrado. No se debe
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

ESTILO (Cod_Estilo, Descripcin)

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

Transformacin de una interrelacin N:1 con opciones de borrado y actualizacin

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.

ESTILO (Cod_Estilo, Descripcin)


BR:MC

OBRA ( Nombre, Dimensiones, Valor_Subasta, Valor_Tasador, Cod_Estilo)

Transformacin de una interrelacin N:1 con opciones de borrado y actualizacin

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.

TCNICA (Cod_Tcnica, Descripcin)


Objetos en el modelo E/R

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

Identificador principal: Nombre

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

TCNICA (Cod_Tcnica, Descripcin)

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

MODELO RELACIONAL FINAL


SEDE (Nombre, Direccin)

EXPONER ( Nombre_Sede, Nombre_Obra)

ARTISTA ( DNI, Nombre, Apellidos, Sexo, Fecha_Nac, Apodo, E-mail)


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.

ESTILO (Cod_Estilo, Descripcin)

BC:MC

SEDE (Nombre, Direccin)

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
SEDE (Nombre, Direccin)
SEDE (Nombre, Direccin)
BC:MC

EXPONER ( Nombre_Sede, Nombre_Obra, Fecha_Exposicin)


BC:MC

OBRA (Nombre, Dimensiones, Valor Subasta, Valor Tasador , Cod_Estilo, Cod_Tcnica)


Transformacin de una interrelacin N:M con opciones de borrado y actualizacin

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

Ejemplo: Supongamos la siguiente relacin:

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.

Ejemplo: Supongamos la siguiente relacin:


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

y Dependencias funcionales:
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,

Ejemplo: Supongamos la siguiente relacin:

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

y Dependencias funcionales:

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.

Ejemplo: Supongamos la siguiente relacin:

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.


Ejemplo: Supongamos la siguiente relacin:

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 )


(1) Dependencias funcionales obtenidas:
CDIGO_AULADESCRIPCIN

Relacin MATRICULA (ALUMNO, CURSO, F_COMIENZO, F_FINALIZACIN )

CDIGO_AULA DIRECCIN

(1) Dependencias funcionales obtenidas:


ALUMNO, CURSO F_COMIENZO

(2) comprobar el estado de Normalizacin de la relacin


1 FN

La relacin est en primera forma normal ya que al tener una

(2) comprobar el estado de Normalizacin de la relacin

clave primaria definida, el sistema no permitir registros


repetidos.
2FN

3FN

FNBC

En

ALUMNO,CURSO->F_FINALIZACIN

1 FN

La relacin est en primera forma normal ya que al tener una

La relacin est en 2FN ya que la clave primaria est

clave primaria definida, el sistema no permitir registros

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

directamente de la clave primaria, no habiendo dependencias

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

La relacin est en 3FN ya que todos los atributos dependen


funcionales entre atributos que no son clave primaria**

entre
FNBC

Observamos que en todas las dependencias funcionales el


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

(1) Dependencias funcionales obtenidas:


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

(2) comprobar el estado de Normalizacin de la relacin

finalizacin, ya que un alumno puede comenzar en una fecha determinada.


1 FN

La relacin est en primera forma normal ya que al tener una

No podremos saber la fecha de finalizacin, ya que es en los cursos mentor

clave primaria definida, el sistema no permitir registros

cada alumno lleva su propio ritmo de trabajo.

repetidos.
2FN

La relacin est en 2FN ya que la clave primaria est


Relacin CURSOS ( NOMBRE, WWW, LIBRO )

compuesta por un nico atributo.


3FN

(1) Dependencias funcionales obtenidas:

La relacin est en 3FN ya que todos los atributos dependen

CURSOS NOMBRE

directamente de la clave primaria, no habiendo dependencias


funcionales entre atributos que no son clave primaria

CURSOSWWW

CURSOSLIBRO

(2) comprobar el estado de Normalizacin de la relacin


Observamos que en todas las dependencias funcionales el
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.
(1) Dependencias funcionales obtenidas:
2FN

DNINOMBRE_COMPLETO

La relacin est en 2FN ya que la clave primaria est


compuesta por un nico atributo.

3FN

(2) comprobar el estado de Normalizacin de la relacin

La relacin est en 3FN ya que todos los atributos dependen


directamente

de

la

clave

primaria,

no

habiendo

1 FN

dependencias funcionales entre atributos que no son clave

La relacin est en primera forma normal ya que al tener


una clave primaria definida, el sistema no permitir registros

primaria *

repetidos.

Observamos que en todas las dependencias funcionales el


FNBC

DNIE-MAIL

2FN

antecedente es clave primaria luego la relacin est en

La relacin est en 2FN ya que la clave primaria est


compuesta por un nico atributo.

FNBC.
3FN

La relacin est en 3FN ya que todos los atributos dependen

* 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 *
Observamos que en todas las dependencias funcionales el

Relacin ASOCIAR ( TUTOR, CURSO, ES_COORDINADOR )


FNBC

(1) Dependencias funcionales obtenidas:

antecedente es clave primaria luego la relacin est en


FNBC.

TUTOR, CURSO ES_COORDINADOR

* En principio pudiera parecer que existe una dependencia funcional entre

(2) comprobar el estado de Normalizacin de la relacin

atributos que no son clave primaria, de la forma: NOBRE_COMPLETOEMAIL.

1 FN

La relacin est en primera forma normal ya que al tener


una clave primaria definida, el sistema no permitir registros

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.
Observamos que en todas las dependencias funcionales el
FNBC

antecedente es clave primaria luego la relacin est en


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

En esta unidad aprenders:

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:
- Operadores algebraicos o bolanos
- Operadores relacionales

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

Ejemplo: Dados dos esquemas de relacin R (A B C) y S

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

Ejemplo: Dados dos esquemas de relacin R (A B C) y S

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

TTULO DE MDULO O BLOQUE

Algebra Relacional

Ejemplo: Dados dos esquemas de relacin R (A B C) y S

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

Ejemplo: Dados dos esquemas de relacin R (A B C) y S


(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

TTULO DE MDULO O BLOQUE

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:


- Operadores algebraicos o bolanos
- Unin (U)
- Diferencia (-)
- Interseccin
- Producto cartesiano (x)

- Operadores relacionales
- Seleccin ()
- Proyeccin ()
- Concatenacin (ZY) (Natural Join)
- Divisin (/)

197

MDULO C
OBJETIVOS

En esta unidad aprenders:

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

SQL Lenguaje de Consulta Estructurado

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

Entrevista con un Vampiro

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

Entrevista con un Vampiro

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

SQL Lenguaje de Consulta Estructurado

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

Entrevista con un Vampiro

1/5/1997

Entrevista con un Vampiro

1/5/1997

Abre los Ojos

7/3/1998

Abre los Ojos

7/3/1998

Nombre

Titulo

Tom Cruise

Entrevista con un Vampiro

Brad Pitt

Entrevista con un Vampiro

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

SQL Lenguaje de Consulta Estructurado

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

SQL Lenguaje de Consulta Estructurado

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

SQL Lenguaje de Consulta Estructurado

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

LIBRO (ISBN, Ttulo, Autor)


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

SQL Lenguaje de Consulta Estructurado

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.

LIBRO (ISBN, Ttulo, Autor)

-------

------

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.

SQL Lenguaje de Consulta Estructurado

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 Para Estar en Forma
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.).
Rehogar la verdura con el ajo. Incorporar la pasta
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.).
Rehogar la verdura con el ajo. Incorporar la pasta
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

SQL Lenguaje de Consulta Estructurado

Ttulo

Descripcin

La Cocina Para Estar en Forma

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

SQL Lenguaje de Consulta Estructurado

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

SQL Lenguaje de Consulta Estructurado

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

SQL Lenguaje de Consulta Estructurado

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

SQL Lenguaje de Consulta Estructurado

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
--

SQL Lenguaje de Consulta Estructurado

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

SQL Lenguaje de Consulta Estructurado

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
GROUP BY tipo_documento

curso

SELECT curso, COUNT(*)


FROM grupo
229

230

SQL Lenguaje de Consulta Estructurado

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
GROUP BY tipo_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

SQL Lenguaje de Consulta Estructurado

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

SQL Lenguaje de Consulta Estructurado

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

SQL Lenguaje de Consulta Estructurado

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

SQL Lenguaje de Consulta Estructurado

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