Unidad Didáctica 2.

Diseño de
bases de datos relacionales
José Juan Sánchez Hernández

IES Celia Viñas (Almería) - 2019/2020

1 Ejercicios Modelo Entidad-Relación

1.1 Proveedores
1.1.1 Modelo conceptual
1.1.1.1 Diagrama E/R

1.1.2 Modelo lógico

1.1.2.1 Solución 1. Modelo
relacional
1.1.2.2 Solución 1. Diagrama
relacional
1.1.2.3 Solución 2. Modelo
relacional
1.1.2.4 Solución 2. Diagrama
relacional
1.1.3 Modelo físico
1.1.3.1 Solución 1. Base de datos para
MySQL

1.1.3.2 Solución 2. Base de datos para

MySQL

1.2 Cadena editorial

1.2.1 Modelo conceptual
 1.2.1.1 Solución 1. Diagrama
E/R

1.2.1.2 Solución 2. Diagrama

E/R

1.2.2 Modelo lógico

1.2.2.1 Modelo relacional

1.2.2.2 Diagrama relacional

1.2.3 Modelo físico

1.2.3.1 Base de datos para
MySQL

1.3 Empresa de material

informático
1.3.1 Modelo conceptual
1.3.1.1 Diagrama E/R

1.3.2 Modelo lógico

1.3.2.1 Solución 1. Modelo
relacional
1.3.2.2 Solución 1. Diagrama
relacional
1.3.2.3 Solución 2. Modelo
relacional
1.3.2.4 Solución 2. Diagrama
relacional
1.3.3 Modelo físico
1.3.3.1 Solución 1. Base de datos para
MySQL

1.3.3.2 Solución 2. Base de datos para

MySQL

1.4 Agencia de viajes

 1.4.1 Modelo conceptual
1.4.1.1 Diagrama E/R

1.5 Exámenes
1.5.1 Modelo conceptual
1.5.1.1 Diagrama E/R

1.6 Concesionario de
automóviles 1.6.1 Modelo
conceptual 1.6.1.1 Diagrama E/R

1.7 Club Náutico

1.8 Información policial

1.9 Alumno, Asignatura, Profesor

1.9.1 Modelo conceptual 1.9.1.1
Diagrama E/R

1.10 Gestión de alquileres de

viviendas
1.10.1 Modelo conceptual
1.10.1.1 Diagrama E/R

1.10.2 Modelo lógico

1.10.2.1 Modelo relacional

1.11 Jardinería

2 Créditos

3 Licencia

1 Ejercicios Modelo Entidad-

Relación
Diseña el modelo entidad-relación para cada uno de los siguientes
ejercicios.

1.1
Proveedores

Tenemos que diseñar una base de datos sobre proveedores y disponemos

de la siguiente información:

De cada proveedor conocemos su nombre, dirección, ciudad, provincia y

un código de proveedor que será único para cada uno de ellos.

Nos interesa llevar un control de las piezas que nos suministra cada
proveedor. Es importante conocer la cantidad de las diferentes piezas que
nos suministra y en qué fecha lo hace. Tenga en cuenta que un mismo
proveedor nos puede
suministrar una pieza con el mismo código en diferentes fechas. El diseño
de la base de datos debe permitir almacenar un histórico con todas las
fechas y las cantidades que nos ha proporcionado un proveedor.

Una misma pieza puede ser suministrada por diferentes

proveedores.

De cada pieza conocemos un código que será único, nombre, color,

precio y categoría.

Pueden existir varias categorías y para cada categoría hay un nombre

y un código de categoría único.

Una pieza sólo puede pertenecer a una

categoría.

1.1.1 Modelo
conceptual
1.1.1.1 Diagrama
E/R

1.1.2 Modelo
lógico

Las reglas de transformación de E/R al modelo relacional nos dicen que la

relación Suministra genera una nueva tabla porque es una relación de
cardinalidad N:N. Esta nueva tabla recibe las claves primarias de las dos
entidades que participan en la relación y además participan como clave primaria.
La solución teórica sería la siguiente:

PROVEEDOR_SUMINISTRA_PIEZA(código_proveedor, código_pieza,
fecha, cantidad)
código_proveedor: FK (Foreign Key) de
PROVEEDOR

código_pieza: FK (Foreign Key) de

PIEZA

Con esta solución podemos tener un problema en el caso de que un proveedor

nos suministre piezas con el mismo código en fechas diferentes. En este caso
no podríamos almacenar esta información en la tabla porque se producuría un
error de claves duplicadas.

#código_proveedor #código_pieza fecha cantidad

1 1 1/01/2018 100
 #código_proveedor #código_pieza fecha cantidad

1 1 20/01/2018 100

Para solucionarlo podemos incluir el atributo ḂǴǜḎǀ como parte de la clave

primaria de la tabla, de modo que la clave primaria estaría compuesta por
código_proveedor, código_pieza y fecha. La solución sería la siguiente:

PROVEEDOR_SUMINISTRA_PIEZA(código_proveedor, código_pieza,
fecha, cantidad)
código_proveedor: FK (Foreign Key) de
PROVEEDOR

código_pieza: FK (Foreign Key) de

PIEZA

En este caso ya no habría ningún problema para almacenar que un

proveedor nos suministra piezas con el mismo código en fechas diferentes.

#código_proveedor #código_pieza #fecha cantidad

1 1 1/01/2018 100

1 1 20/01/2018 100

Otra forma de resolver este problema puede ser creando un nuevo atributo id
que sea un valor numérico autoincrementado y que éste sea la única clave
primara de la tabla. La solución sería la siguiente:

PROVEEDOR_SUMINISTRA_PIEZA(id, código_proveedor, código_pieza,

fecha, cantidad)
código_proveedor: FK (Foreign Key) de
PROVEEDOR

código_pieza: FK (Foreign Key) de

PIEZA
En este caso tampoco habría ningún problema para almacenar que un
proveedor nos suministra piezas con el mismo código en fechas diferentes.

#id código_proveedor código_pieza fecha cantidad

1 1 1 1/01/2018 100

2 1 1 20/01/2018 100

1.1.2.1 Solución 1. Modelo

relacional

PROVEEDOR(código, dirección, ciudad,

provincia)

CATEGORÍA(código, nombre)

PIEZA(código, nombre, color, precio,

codigo_categoria)
codigo_categoria: FK (Foreign Key) de
CATEGORÍA(código)

PROVEEDOR_SUMINISTRA_PIEZA(código_proveedor, código_pieza,
fecha, cantidad)
código_proveedor: FK (Foreign Key) de
PROVEEDOR(código)

código_pieza: FK (Foreign Key) de

PIEZA(código)

1.1.2.2 Solución 1. Diagrama

relacional
1.1.2.3 Solución 2. Modelo
relacional

PROVEEDOR(código, dirección, ciudad,

provincia)

CATEGORÍA(código, nombre)

PIEZA(código, nombre, color, precio,

codigo_categoria)
codigo_categoria: FK (Foreign Key) de
CATEGORÍA(código)

PROVEEDOR_SUMINISTRA_PIEZA(id, código_proveedor, código_pieza,

fecha, cantidad)
código_proveedor: FK (Foreign Key) de
PROVEEDOR(código)

código_pieza: FK (Foreign Key) de

PIEZA(código)

1.1.2.4 Solución 2. Diagrama

relacional

1.1.3 Modelo
físico

1.1.3.1 Solución 1. Base de datos para

MySQL
 DROP DATABASE IF EXISTS proveedores; CREATE
DATABASE proveedores CHARSET utf8mb4;; USE
proveedores;

CREATE TABLE categoria (

codigo INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,

nombre VARCHAR(100) NOT NULL UNIQUE );CREATE TABLE

pieza (
codigo INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, nombre
VARCHAR(100) NOT NULL, color VARCHAR(25) NOT NULL, precio FLOAT
UNSIGNED NOT NULL, codigo_categoria INT UNSIGNED NOT NULL,
FOREIGN KEY (codigo_categoria) REFERENCES

categoria(codigo) );CREATE TABLE proveedor (

codigo INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,

direccion VARCHAR(100) NOT NULL, ciudad VARCHAR(50)

NOT NULL, provincia VARCHAR(50) NOT NULL );CREATE

TABLE proveedor_suministra_pieza (
codigo_proveedor INT UNSIGNED, codigo_pieza INT UNSIGNED, cantidad
INT UNSIGNED NOT NULL, fecha DATE NOT NULL, PRIMARY KEY
(codigo_proveedor, codigo_pieza, fecha), FOREIGN KEY
(codigo_proveedor) REFERENCES proveedor(codigo), FOREIGN KEY
(codigo_pieza) REFERENCES pieza(codigo) );1.1.3.2 Solución 2. Base
de datos para MySQL

DROP DATABASE IF EXISTS proveedores; CREATE

DATABASE proveedores CHARSET utf8mb4;; USE
proveedores;

CREATE TABLE categoria (

codigo INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,

nombre VARCHAR(100) NOT NULL UNIQUE );CREATE TABLE

pieza (
codigo INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, nombre
VARCHAR(100) NOT NULL, color VARCHAR(25) NOT NULL, precio FLOAT
UNSIGNED NOT NULL, codigo_categoria INT UNSIGNED NOT NULL,
FOREIGN KEY (codigo_categoria) REFERENCES

categoria(codigo) );CREATE TABLE proveedor (

codigo INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,

 direccion VARCHAR(100) NOT NULL, ciudad VARCHAR(50)
NOT NULL, provincia VARCHAR(50) NOT NULL );
CREATE TABLE proveedor_suministra_pieza (
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, codigo_proveedor INT
UNSIGNED, codigo_pieza INT UNSIGNED, cantidad INT UNSIGNED NOT
NULL, fecha DATE NOT NULL, FOREIGN KEY (codigo_proveedor)
REFERENCES proveedor(codigo), FOREIGN KEY (codigo_pieza)
REFERENCES pieza(codigo) );

1.2 Cadena
editorial

Tenemos esta información sobre una cadena

editorial:

La editorial tiene varias sucursales, con su domicilio, teléfono y un código

de sucursal.

Cada sucursal tiene varios empleados, de los cuales tendremos su

nombre, apellidos, NIF y teléfono. Un empleado trabaja en una única
sucursal.

En cada sucursal se publican varias revistas, de las que

almacenaremos su título, número de registro, periodicidad y tipo.

Una revista puede ser publicada por varias

sucursales.

La editorial tiene periodistas (que no trabajan en las sucursales) que

pueden escribir artículos para varias revistas. Almacenaremos los
mismos datos que para los empleados, añadiendo su especialidad.

También es necesario guardar las secciones fijas que tiene cada revista,
que constan de un título y una extensión.
 Para cada revista, almacenaremos información de cada ejemplar, que
incluirá la fecha, número de páginas y el número de ejemplares vendidos.

1.2.1 Modelo
conceptual

1.2.1.1 Solución 1. Diagrama

E/R

Solución con entidades débiles por

identificación.

1.2.1.2 Solución 2. Diagrama

E/R

Solución sin utilizar entidades débiles por

identificación.
1.2.2 Modelo lógico

1.2.2.1 Modelo relacional

SUCURSAL(código, dirección, teléfono, ciudad,

provincia)

EMPLEADO(id, nif, nombre, apellido1, apellido2, teléfono, ǜṝ Ǩḙḅṙ

ẎẴǜẴẃẎǀ ḵ)
ǜṝ Ǩḙḅṙ ẎẴǜẴẃẎǀ ḵ: FK de
SUCURSAL(código)

REVISTA(número_registro, título, tipo,

periodicidad)

SUCURSAL_PUBLICA_REVISTA(código_sucursal,
número_registro_revista)
PERIODISTA(id, nombre, apellido1, apellido2, teléfono, especialidad)
PERIODISTA_ESCRIBE_REVISTA(id_periodista, número_registro_revista)
SECCIÓN(id, título, extensión, ṎặṊǴẃṙ ẃǴḅḙẎẤẃṙ ẃǴỴḙẎẤǀ )
ṎặṊǴẃṙ ẃǴḅḙẎẤẃṙ ẃǴỴḙẎẤǀ : FK de REVISTA(número_registro)
EJEMPLAR(id, número_ejemplares, número_páginas, fecha, ṎặṊǴẃṙ ẃǴḅḙẎẤẃṙ
ẃǴỴḙẎẤǀ )
ṎặṊǴẃṙ ẃǴḅḙẎẤẃṙ ẃǴỴḙẎẤǀ : FK de REVISTA(número_registro)
1.2.2.2 Diagrama relacional
Sucursal código_sucursal PK dirección ciudad provincia teléfono
Empleado
Periodista id PK
id PK código_sucursal FK
nombre nif
apellido1 nombre
apellido2 apellido1
teléfono apellido2
especialidad teléfono
Vende código_sucursal PK FK número_registro_revista PK FK
Escribe número_registro_revista PK FK id_periodista PK FK
Revista número_registro PK título periodicidad tipo
Sección id PK número_registro_revista FK título extensión
Número id PK número_registro_revista FK fecha número_páginas número_ejemplares

1.2.3 Modelo físico

1.2.3.1 Base de datos para MySQL
DROP DATABASE IF EXISTS cadena_editorial; CREATE DATABASE cadena_editorial
CHARSET utf8mb4; USE cadena_editorial;
CREATE TABLE sucursal (
codigo INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, direccion VARCHAR(100) NOT
NULL, ciudad VARCHAR(50) NOT NULL, provincia VARCHAR(50) NOT NULL, telefono

VARCHAR(9) NOT NULL );CREATE TABLE empleado (

id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, codigo_sucursal INT UNSIGNED NOT
NULL, nif VARCHAR(9) NOT NULL UNIQUE, nombre VARCHAR(50) NOT NULL, apellido1
VARCHAR(50) NOT NULL, apellido2 VARCHAR(50) DEFAULT NULL, telefono VARCHAR(9)
DEFAULT NULL, FOREIGN KEY (codigo_sucursal) REFERENCES

sucursal(codigo) );CREATE TABLE periodista (

id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
nombre VARCHAR(50) NOT NULL, apellido1
VARCHAR(50) NOT NULL, apellido2
VARCHAR(50), telefono VARCHAR(9),
especialidad VARCHAR(50) NOT NULL

);CREATE TABLE revista (

numero_registro INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, titulo

VARCHAR(50) NOT NULL, periodicidad ENUM('semanal', 'mensual', 'anual')

DEFAULT 'semanal', tipo VARCHAR(100) NOT NULL );CREATE TABLE

periodista_escribe_revista (
numero_registro INT UNSIGNED, id_periodista INT UNSIGNED, PRIMARY KEY
(numero_registro, id_periodista), FOREIGN KEY (numero_registro)
REFERENCES revista(numero_registro), FOREIGN KEY (id_periodista)

REFERENCES periodista(id) );CREATE TABLE ejemplar (

id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, numero_registro INT

UNSIGNED NOT NULL, fecha DATE NOT NULL, numero_paginas SMALLINT
UNSIGNED NOT NULL, numero_ejemplares INT UNSIGNED NOT NULL, FOREIGN KEY

(numero_registro) REFERENCES revista(numero_registro) );CREATE TABLE

seccion (
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, numero_registro INT
UNSIGNED NOT NULL, titulo VARCHAR(50) NOT NULL, extension INT UNSIGNED
NOT NULL, FOREIGN KEY (numero_registro) REFERENCES

revista(numero_registro) );CREATE TABLE sucursal_publica_revista (

codigo_sucursal INT UNSIGNED, numero_registro INT UNSIGNED, PRIMARY KEY

(codigo_sucursal, numero_registro), FOREIGN KEY (codigo_sucursal)
REFERENCES sucursal (codigo), FOREIGN KEY (numero_registro) REFERENCES
revista (numero_registro) );

1.3 Empresa de material

informático

Tenemos que diseñar una base de datos para una empresa de material
informático, de la que tenemos esta información:
Un equipo consta de varios componentes. Pueden ser necesarios varios
componentes del mismo tipo para montar un equipo, por lo que será
necesario almacenar la cantidad de componentes que se necesitan en
cada caso.

Un cliente puede comprar equipos completos o componentes sueltos. Habrá

que almacenar la cantidad de equipos o la cantidad de componentes de
cada tipo que compra cada cliente. También habrá que guardar la fecha de la
compra.

Tenga en cuenta que un mismo cliente puede comprar el mismo equipo o

el mismo componente en diferentes fechas. El diseño de la base de datos
debe permitir almacenar un histórico con todas las fechas y las
cantidades de equipos o componentes que ha comprado.

Cada equipo está etiquetado con un código de equipo, una descripción,

un precio y el stock disponible.

Cada componente está etiquetado con un código de componente,

una descripción, un precio y el stock disponible.

Los datos que almacenamos los clientes son el NIF, nombre, apellidos,
domicilio, ciudad, provincia y teléfono.

Los datos que almacenamos de los empleados son el NIF, nombre, apellidos
y la sección donde trabaja.

Un empleado trabaja en una única

sección.

Una sección se identifica por un id y un nombre de

 sección.

En cada compra realizada por un cliente interviene un empleado y será

necesario guardar qué empleado es el que ha atendido a cada cliente para
cada una de las compras.

1.3.1 Modelo
conceptual

1.3.1.1 Diagrama
E/R

1.3.2 Modelo lógico

1.3.2.1 Solución 1. Modelo
relacional

EQUIPO(código, descripción, precio, stock)

COMPONENTE(código, descripción, precio, stock)

EQUIPO_CONSTA_COMPONENTE(código_equipo,
código_componente, cantidad)
código_equipo: FK de
EQUIPO(código)

código_componente: FK de
COMPONENTE(código)

SECCIÓN(id, nombre)

EMPLEADO(id, nif, nombre, apellido1, apellido2, ḙǨ ẎǴǜǜḙṝ

Ṏ)
ḙǨ ẎǴǜǜḙṝ Ṏ: FK de SECCIÓN(id)

CLIENTE(id, nif, nombre, apellido1, apellido2, teléfono, domicilio,

ciudad, provincia)
En esta solución hemos añadido el atributo ḂǴǜḎǀ como parte de la
clave primaria.

CLIENTE_COMPRA_EQUIPO(id_cliente, código_equipo, id_empleado,

fecha, cantidad)
id_cliente: FK de CLIENTE(id)
código_equipo: FK de
EQUIPO(código)

id_empleado: FK de EMPLEADO(id)
CLIENTE_COMPRA_COMPONENTE(id_cliente,
 código_componente, id_empleado, fecha, cantidad)
id_cliente: FK de CLIENTE(id)
código_componente: FK de
COMPONENTE(código)

id_empleado: FK de EMPLEADO(id)

1.3.2.2 Solución 1. Diagrama

relacional

1.3.2.3 Solución 2. Modelo

relacional

EQUIPO(código, descripción, precio, stock)

COMPONENTE(código, descripción, precio, stock)

EQUIPO_CONSTA_COMPONENTE(código_equipo,
código_componente, cantidad)
 código_equipo: FK de
EQUIPO(código)

código_componente: FK de
COMPONENTE(código)

SECCIÓN(id, nombre)
EMPLEADO(id, nif, nombre, apellido1, apellido2, ḙǨ ẎǴǜǜḙṝ
Ṏ)
ḙǨ ẎǴǜǜḙṝ Ṏ: FK de SECCIÓN(id)

CLIENTE(id, nif, nombre, apellido1, apellido2, teléfono, domicilio,

ciudad, provincia)

En esta solución hemos añadido un nuevo atributo autonumérico

incrementado llamado ḙǨ que será la clave primaria.

CLIENTE_COMPRA_EQUIPO(id, ḙǨ ǜḵḙǴṎẤǴ, ǜṝ Ǩḙḅṙ ǴẂẴḙṿṙ , ḙǨ ǴṊṿḵǴǀ Ǩṙ ,

fecha, cantidad)
ḙǨ ǜḵḙǴṎẤǴ: FK de
CLIENTE(id)

ǜṝ Ǩḙḅṙ ǴẂẴḙṿṙ : FK de EQUIPO(código)

ḙǨ ǴṊṿḵǴǀ Ǩṙ : FK de EMPLEADO(id)

CLIENTE_COMPRA_COMPONENTE(id, ḙǨ ǜḵḙǴṎẤǴ, ǜṝ Ǩḙḅṙ ǜṙ Ṋṿṙ

ṎǴṎẤǴ, ḙǨ ǴṊṿḵǴǀ Ǩṙ , fecha, cantidad)
ḙǨ ǜḵḙǴṎẤǴ: FK de
CLIENTE(id)

ǜṝ Ǩḙḅṙ ǜṙ Ṋṿṙ ṎǴṎẤǴ: FK de COMPONENTE(código)

ḙǨ ǴṊṿḵǴǀ Ǩṙ : FK de EMPLEADO(id)

1.3.2.4 Solución 2. Diagrama

relacional
1.3.3 Modelo físico

1.3.3.1 Solución 1. Base de datos para

MySQL

DROP DATABASE IF EXISTS empresa_material_informatico; CREATE

DATABASE empresa_material_informatico CHARSET utf8mb4;
USE empresa_material_informatico;

CREATE TABLE equipo (

codigo INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
descripcion VARCHAR(128) NOT NULL, precio FLOAT
UNSIGNED NOT NULL, stock INT UNSIGNED NOT NULL

);CREATE TABLE componente (

codigo INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, descripcion

VARCHAR(128) NOT NULL, precio FLOAT UNSIGNED NOT NUL, stock INT

UNSIGNED NOT NULL );CREATE TABLE equipo_consta_componente (

codigo_equipo INT UNSIGNED NOT NULL, codigo_componente INT UNSIGNED
NOT NULL, cantidad INT UNSIGNED NOT NULL, PRIMARY KEY
(codigo_equipo, codigo_componente), FOREIGN KEY (codigo_equipo)
REFERENCES equipo(codigo), FOREIGN KEY (codigo_componente)

REFERENCES componente(codigo) );CREATE TABLE cliente (

id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, nif

VARCHAR(9) NOT NULL UNIQUE, nombre VARCHAR(50)
NOT NULL, apellido1 VARCHAR(50) NOT NULL,
apellido2 VARCHAR(50), telefono VARCHAR(9) NOT
NULL, domicilio VARCHAR(100) NOT NULL, ciudad
VARCHAR(50) NOT NULL, provincia VARCHAR(50) NOT

NULL );CREATE TABLE seccion (

id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,

nombre VARCHAR(100) NOT NULL UNIQUE );CREATE

TABLE empleado (
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
id_seccion INT UNSIGNED NOT NULL, nif VARCHAR(9) NOT
NULL UNIQUE, nombre VARCHAR(50) NOT NULL, apellido1
VARCHAR(50) NOT NULL, apellido2 VARCHAR(50) NOT NULL,
FOREIGN KEY (id_seccion) REFERENCES

seccion(id) );CREATE TABLE cliente_compra_equipo (

 codigo_equipo INT UNSIGNED NOT NULL,
id_cliente INT UNSIGNED NOT NULL, id_empleado INT UNSIGNED NOT
NULL, fecha DATE NOT NULL, cantidad INT UNSIGNED NOT NULL, PRIMARY
KEY (codigo_equipo, id_cliente, id_empleado, fecha), FOREIGN KEY
(codigo_equipo) REFERENCES equipo(codigo), FOREIGN KEY
(id_cliente) REFERENCES cliente(id), FOREIGN KEY (id_empleado)

REFERENCES empleado(id) );CREATE TABLE cliente_compra_componente (

codigo_componente INT UNSIGNED NOT NULL, id_cliente INT UNSIGNED NOT

NULL, id_empleado INT UNSIGNED NOT NULL, fecha DATE NOT NULL, cantidad
INT UNSIGNED NOT NULL, PRIMARY KEY (codigo_componente, id_cliente,
id_empleado, fecha), FOREIGN KEY (codigo_componente) REFERENCES
componente(codigo), FOREIGN KEY (id_cliente) REFERENCES cliente(id),
FOREIGN KEY (id_empleado) REFERENCES empleado(id) );1.3.3.2 Solución 2.
Base de datos para MySQL

DROP DATABASE IF EXISTS empresa_material_informatico; CREATE

DATABASE empresa_material_informatico CHARSET utf8mb4; USE
empresa_material_informatico;

CREATE TABLE equipo (

codigo INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
descripcion VARCHAR(128) NOT NULL, precio FLOAT
UNSIGNED NOT NULL, stock INT UNSIGNED NOT NULL

);CREATE TABLE componente (

codigo INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, descripcion

VARCHAR(128) NOT NULL, precio FLOAT UNSIGNED NOT NUL, stock INT

UNSIGNED NOT NULL );CREATE TABLE equipo_consta_componente (

codigo_equipo INT UNSIGNED NOT NULL, codigo_componente INT UNSIGNED
NOT NULL, cantidad INT UNSIGNED NOT NULL, PRIMARY KEY
(codigo_equipo, codigo_componente), FOREIGN KEY (codigo_equipo)
REFERENCES equipo(codigo), FOREIGN KEY (codigo_componente)

REFERENCES componente(codigo) );CREATE TABLE cliente (

id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, nif
VARCHAR(9) NOT NULL UNIQUE, nombre VARCHAR(50)
NOT NULL, apellido1 VARCHAR(50) NOT NULL,
apellido2 VARCHAR(50), telefono VARCHAR(9) NOT
NULL, domicilio VARCHAR(100) NOT NULL, ciudad
VARCHAR(50) NOT NULL, provincia VARCHAR(50) NOT

NULL );CREATE TABLE seccion (

id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,

 nombre VARCHAR(100) NOT NULL UNIQUE );CREATE

TABLE empleado (
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
id_seccion INT UNSIGNED NOT NULL, nif VARCHAR(9) NOT
NULL UNIQUE, nombre VARCHAR(50) NOT NULL, apellido1
VARCHAR(50) NOT NULL, apellido2 VARCHAR(50) NOT NULL,
FOREIGN KEY (id_seccion) REFERENCES

seccion(id) );CREATE TABLE cliente_compra_equipo (

id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, codigo_equipo

INT UNSIGNED NOT NULL, id_cliente INT UNSIGNED NOT NULL,
id_empleado INT UNSIGNED NOT NULL, fecha DATE NOT NULL,
cantidad INT UNSIGNED NOT NULL, FOREIGN KEY (codigo_equipo)
REFERENCES equipo(codigo), FOREIGN KEY (id_cliente)
REFERENCES cliente(id), FOREIGN KEY (id_empleado) REFERENCES

empleado(id) );CREATE TABLE cliente_compra_componente (

id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, codigo_componente INT

UNSIGNED NOT NULL, id_cliente INT UNSIGNED NOT NULL, id_empleado INT
UNSIGNED NOT NULL, fecha DATE NOT NULL, cantidad INT UNSIGNED NOT
NULL, FOREIGN KEY (codigo_componente) REFERENCES componente(codigo),
FOREIGN KEY (id_cliente) REFERENCES cliente(id), FOREIGN KEY
(id_empleado) REFERENCES empleado(id) );

1.4 Agencia de
viajes
Tenemos que diseñar una base de datos para gestionar las reservas de
hoteles y vuelos que realizan los clientes de una agencia de viajes:

La agencia de viajes está compuesta por un conjunto de sucursales.

Cada sucursal está definida por el identificador de sucursal, dirección,
ciudad, provincia y teléfono.

Un cliente puede contratar vuelos y estancias en hoteles a través de

alguna de las sucursales que tiene la agencia de viajes.

Cada vuelo está definido por un identificador, fecha/hora de salida,

fecha/hora de llegada, origen, destino y número de plazas totales.
 Cada hotel está definido por el identificador del hotel, nombre,
dirección, ciudad, provincia, teléfono y número de estrellas.

La información que se desea almacenar para cada cliente es un nif,

nombre, apellidos, teléfono y email.

También habrá que tener en cuenta la siguiente

información:

A la agencia de viajes le interesa conocer a través de qué sucursal

ha contratado cada cliente los servicios de vuelo y alojamiento.

A la hora de reservar un vuelo el cliente puede elegir cualquiera de los

vuelos que ofrece la agencia y en qué clase (turista o primera) desea
viajar.

El cliente se puede hospedar en cualquiera de los hoteles que ofrece la

agencia, y elegir el régimen de hospedaje (media pensión o pensión
completa). Siendo significativa la fecha de entrada y de salida.

1.4.1 Modelo
conceptual

1.4.1.1 Diagrama
E/R
1.5
Exámenes

Los profesores del módulo de Bases de Datos deciden crear una base datos que
contenga la información de los resultados de las pruebas realizadas por los
alumnos:

Los alumnos están definidos por un identificador único, NIF, nombre,

apellidos y el grupo al que asisten a clase. Los grupos se identifican con una
letra mayúscula que puede estar entre la A y la Z .

Dichos alumnos realizan dos tipos de pruebas a lo largo del curso

académico:

Exámenes teóricos. Cada alumno realiza varios a lo largo del curso y se

definen por un identificador único, un título, el número de preguntas y la
fecha de realización (será la misma para todos los alumnos que realizan
el mismo examen). Habrá que almacenar la nota de cada alumno por
examen.

Prácticas. Se realiza un número indeterminado de prácticas durante

el curso académico. Se definen por un identificador, un título y el
grado de dificultad. Los posibles grados de dificultad que pueden
aparecer son:
Baja , Media y Alta . En este caso los alumnos pueden examinarse de
cualquier práctica cuando lo deseen, debiéndose almacenar la fecha
y la nota obtenida.

De los profesores vamos a almacenar un identificador, NIF, nombre y

apellidos.

Nos interesa saber qué profesor o profesores han participado en el diseño

de una práctica. Tenga en cuenta que en el diseño de una práctica puede
colaborar más de un profesor y que un profesor puede diseñar más de una
 práctica. También interesa almacenar la fecha en la que cada profesor ha
participado en el diseño de la práctica. En el caso de que un profesor
participe en el diseño de
una misma práctica en fechas distintas sólo guardaremos la última fecha
en la que participó.

Los exámenes teóricos son diseñados por un solo profesor y un profesor

puede diseñar varios exámenes teóricos a lo largo del curso.

1.5.1 Modelo
conceptual

1.5.1.1 Diagrama
E/R

1.6 Concesionario de
automóviles

Un concesionario de automóviles desea informatizar su gestión de ventas de

vehículos. En particular, se quiere tener almacenada la información referente
a los clientes que compran en el concesionario, los vehículos vendidos, así
como los vendedores que realizan las distintas ventas. Para ello se tendrá en
cuenta que:

Existen diferentes marcas de automóviles, para cada marca se almacena

un identificador único y un nombre. Por ejemplo, pueden existir las
marcas Audi, BMW, Volkswagen, etc.
Una marca puede tener muchos modelos diferentes pero un modelo sólo
puede pertenecer a una marca. De cada modelo se almacena un
identificador único y un nombre. Por ejemplo, para la marca Audi, podemos
tener los modelos A1, A3, A4, etc.
Para cada modelo pueden existir diferentes versiones. De cada versión se
almacena un identificador único, un nombre de versión, la potencia, un
precio base y el tipo de combustible que puede ser Gasolina o Diesel. Por
ejemplo, para la marca Audi, modelo A3, pueden existir las versiones
AUDI A3 1.0 TFSI 85kW (116CV), AUDI A3 1.6 TDI 85kW (116CV), etc.

Cada una de las versiones dispondrá de unos extras adicionales (aire

acondicionado, pintura metalizada, etc). Los extras vienen definidos por un
identificador, nombre y una descripción. Hay que tener en cuenta que un
extra puede ser común para varias versiones variando sólo el precio en
cada caso.
En cuanto a los clientes, la información de interés es el nombre, apellidos,
NIF, dirección y teléfono, lo mismo que para los vendedores.

Los clientes pueden ceder su coche usado al comprar un vehículo nuevo. El

coche usado vendrá definido por su marca, modelo, matrícula y precio de
tasación. Es importante conocer la fecha en la que el cliente realiza esta
cesión.

Se desea saber qué vendedor ha vendido qué modelo a qué cliente.

También la fecha de la venta y la matrícula del nuevo vehículo.

1.6.1 Modelo
conceptual

1.6.1.1 Diagrama
E/R

1.7 Club
Náutico

Un club náutico desea tener informatizados los datos correspondientes a sus

instalaciones, empleados, socios y embarcaciones que se encuentran en dicho
club. El club está organizado de la siguiente forma:

Los socios pertenecientes al club vienen definidos por su nombre,

dirección, NIF, teléfono y fecha de ingreso en el club.

Las embarcaciones vienen definidas por matrícula, nombre, tipo y

dimensiones.

Los amarres tienen como datos de interés el número de amarre, la lectura

del contador de agua y luz, y si tienen o no servicios de mantenimiento
contratados.

Hay que tener en cuenta que una embarcación pertenece a un socio aunque
un socio puede tener varias embarcaciones. Una embarcación ocupará un
amarre y un amarre está ocupado por una sola embarcación. Es importante
 la fecha en la que una embarcación es asignada a un amarre.

Los socios pueden ser propietarios de amarres, siendo importante la fecha

de compra del amarre. Hay que tener en cuenta que un amarre pertenece a
un solo
socio y que no hay ninguna relación directa entre la fecha en la que se
compra un amarre y en la que una embarcación se asigna a un amarre.

El club náutico está dividido en varias zonas definidas por una letra, el tipo
de barcos que tiene, el número de barcos que contiene, la profundidad y el
ancho de los amarres. Una zona tendrá varios amarres y un amarre
pertenece a una sola zona.
En cuanto a los empleados, estos vienen definidos por su código, nombre,
dirección, teléfono y especialidad. Un empleado está asignado a varias
zonas y en una zona puede haber más de un empleado, siendo de interés
el número de barcos de los que se encarga en cada zona. Hay que tener
en cuenta que un empleado puede no encargarse de todos los barcos de
una zona.

1.8 Información
policial

La policía quiere crear una base de datos sobre la seguridad en algunas

entidades bancarias. Para ello tiene en cuenta que:

Cada entidad bancaria se caracteriza por un código y por el domicilio de

su central.
Cada entidad bancaria tiene más de una sucursal que también se
caracteriza por un código y por el domicilio, así como por el número de
empleados de dicha sucursal.

Cada sucursal puede contratar a varios vigilantes jurados, que se

caracterizan por su código de vigilante y su edad. Un vigilante puede ser
contratado por diferentes sucursales (incluso de diferentes entidades) en
diferentes fechas. También es necesario almacenar si se ha contratado
 con arma o no.

La policía está interesada en controlar las personas que han sido detenidas
por atracar sucursales. Estas personas se identifican por un NIF y su
nombre completo.
Algunos de estos atracadores están integrados en algunas bandas
organizadas y por ello se desea saber a qué banda pertenecen, sin ser de
interés si la banda ha participado en el delito o no. Las bandas se definen
por un código de banda y por el número de miembros.
Es necesario saber qué juez ha estado encargado de cada caso, sabiendo
que un atracador puede ser juzgado por diferentes jueces en diferentes
delitos. Es necesario almacenar si en cada delito la persona detenida ha
sido condenada o no, y de haberlo sido cuánto tiempo pasará en la cárcel.
Un juez se caracteriza por una clave interna del juzgado, su nombre y los
años de servicio.

En ningún caso interesa saber si un vigilante ha participado en la

detención de un atracador.

1.9 Alumno, Asignatura,

Profesor
Diseña el diagrama E/R con las siguientes
entidades:

Alumno: número de matrícula, nombre, apellidos, fecha de

nacimiento y teléfono.
Asignatura: código de asignatura, nombre y número de
horas.

Profesor: id de profesor, NIF, nombre, apellidos, especialidad y

teléfono.
Curso Escolar: id de curso escolar, año de inicio y año de
fin.
Teniendo en cuenta que:

Un alumno puede estar matriculado de una o varias

asignaturas.

Además puede estar matriculado en la misma asignatura más de un

curso escolar (si repite).

Se quiere saber el curso escolar en el que cada alumno está

matriculado de cada asignatura.
En una asignatura habrá como mínimo 10 y como máximo 20
alumnos.

Una asignatura es impartida por un único

profesor.
Un profesor podrá impartir varias
asignaturas.

1.9.1 Modelo
conceptual

1.9.1.1 Diagrama
E/R
1.10 Gestión de alquileres de
viviendas
La Sociedad Pública de Alquiler dependiente del Ministerio de la Vivienda
necesita una base de datos para gestionar los alquileres de las viviendas de
particulares. Los requisitos de esta base de datos son los que se detallan a
continuación.

Es necesario almacenar información sobre la duración de cada uno de

los alquileres de una vivienda con el fin de conocer el histórico de
alquileres.

La información que se guarda de cada alquiler es un identificador único

de alquiler, fecha de inicio, fecha de fin, importe mensual, fianza y fecha
de la firma.

Se quiere almacenar información sobre la renovación de un alquiler de una

vivienda. Es necesario saber si un alquiler es una renovación de otro
alquiler anterior o no, con el fin de poder seguir fácilmente la secuencia de
alquileres de una vivienda con la misma persona.

Un alquiler es realizado por un inquilino y de cada inquilino se alamacena

un identificador único, NIF, nombre, apellidos, fecha de nacimiento y
teléfono de contacto.

Es necesario almacenar información sobre las agencias inmobiliarias

que gestionan los alquileres de las viviendas.

De cada agencia inmobiliaria se almacena un identificador de agencia,

CIF, dirección y teléfono.

Una vivienda sólo se oferta en una única agencia inmobiliaria. Una

agencia sólo puede gestionar los alquileres de las viviendas ofertadas
por ella.

De cada vivienda se almacena un identificador de vivienda, calle, número,

 piso, código postal, población y una descripción.

Una vivienda pertenece a un único propietario y un propietario puede

tener muchas viviendas.

De cada propietario se almacena un identificador único, NIF, nombre,

apellidos, teléfono, dirección y email.

1.10.1 Modelo
conceptual

1.10.1.1 Diagrama
E/R

1.10.2 Modelo
lógico
1.10.2.1 Modelo
relacional

AGENCIA(id, cif, dirección, teléfono)

PROPIETARIO(id, nif, nombre, apellido1, apellido2, teléfono, dirección,

email)

VIVIENDA(id, calle, número, código_postal, piso, población,

descipción, ḙǨ ǀ ḅǴṎǜḙǀ , ḙǨ ṿẃṙ ṿḙǴẤǀ ẃḙṙ )
ḙǨ ǀ ḅǴṎǜḙǀ : FOREIGN KEY de
AGENCIA(id)

ḙǨ ṿẃṙ ṿḙǴẤǀ ẃḙṙ : FOREIGN KEY de

PROPIETARIO(id)

INQUILINO(id, nif, nombre, apellido1, apellido2, teléfono,

fecha_nacimiento)

ALQUILER(id, fecha_inicio, fecha_fin, importe, fianza, fecha_firma, ḙǨ

ḙṎẂẴḙḵḙṎṙ , ḙǨ ỴḙỴḙǴṎǨǀ , ḙǨ ǀ ḵẂẴḙḵǴẃ ẃǴṎṙ Ỵǀ Ǩṙ )
ḙǨ ḙṎẂẴḙḵḙṎṙ : FOREIGN KEY de
INQUILINO(id)

ḙǨ ỴḙỴḙǴṎǨǀ : FOREIGN KEY de

VIVIENDA(id)

ḙǨ ǀ ḵẂẴḙḵǴẃ ẃǴṎṙ Ỵǀ Ǩṙ : FOREIGN KEY de

ALQUILER(id)

1.11
Jardinería
Una empresa que vende productos para jardinería necesita una base de datos
para gestionar los pedidos que realizan sus clientes. Los requisitos de esta base
de datos son los que se detallan a continuación.
Es necesario almacenar información de los empleados que trabajan en la
empresa. La información que se guarda de cada empleado es un
identificador único, nombre, apellidos, email, teléfono y el puesto que
desempeña dentro de la empresa.

Los empleados trabajan en oficinas y las oficinas están repartidas por

todo el país. De cada oficina se almacena un identificador único,
dirección, teléfono, ciudad y provincia.

Un empleado sólo puede trabajar en una única oficina, pero en una

oficina pueden trabajar varios empleados.

Es necesario almacenar quién es el jefe de cada empleado. Tenga en cuenta

que un empleado puede ser jefe de varios empleados, pero un empleado
sólo puede tener un único jefe.

La información que se almacena de cada cliente es un identificador

único, nombre, apellidos, teléfono y dirección.

Un cliente tendrá asociado un único empleado que será su

representante de ventas. Sin embargo un empleado puede ser el
representante de ventas de muchos clientes.

A la empresa le interesa almacenar los pedidos que realizan los clientes. De

cada pedido se almacena un identificador único, fecha de pedido, fecha
prevista de entrega, fecha de entrega, estado del pedido y comentarios.

Cada pedido consta de varias líneas de pedido, donde cada línea de

pedido se corresponde con cada uno de los diferentes productos que ha
comprado el cliente. Cada línea de pedido incluye el producto que se ha
comprado, el número de unidades que ha comprado y el precio de cada
unidad.

La información que se quiere almacenar de cada producto es un

identificador único, una imagen del producto, nombre, descripción, el
precio de venta, el número de unidades que hay en stock y la gama del
 producto.

De cada gama se almacena un identifiador único, un nombre y una

descripción.

2 Créditos
Muchos de los ejercicios y diagramas que aparecen en este texto han
sido extraídos de las siguientes referencias:
Diseño de Bases de Datos. Problemas resueltos. Ra-Ma. Adoración de
Miguel. Paloma Martínez. Elena Castro.

Desarrollo de Bases de Datos. Casos prácticos desde el análisis a la

implementación. Ra-Ma. Dolores Cuadra. Elena Castro. Ana Ma Iglesias.
Paloma Martínez. Fco. Javier Calle. César de Pablo. Harith Al-Jumaily.
Lourdes Moreno. Sonia García Manzano. José Luis Martínez. Jesica Rivero.
Isabel Segura.

Introducción a la Informática. Licenciado en ADE. UPV. Miguel Rebollo,

Javier Martín, Álvaro Hermida y Mario González.

Gestión de Bases de Datos. José Antonio Muñoz

Jiménez.

¡Gracias por compartir vuestro trabajo! :)

3 Licencia

El contenido de esta web está bajo una licencia de Creative

Commons Reconocimiento-NoComercial-CompartirIgual 4.0
Internacional.