2º Grado en Ingeniería Informática Facultad de Informática

Asignatura: Bases de Datos Curso: 2022/23

PRÁCTICA P1. Diseño lógico de bases de datos

Objetivos
• Obtener un esquema lógico de datos en el modelo relacional, a partir de un esquema conceptual, con la
mínima pérdida de semántica, siguiendo las reglas de transformación del diseño lógico.
• Construir y ejecutar sentencias SQL de definición de datos, es decir, de creación, alteración y eliminación
de elementos componentes de un esquema de bases de datos.
Contenidos
Se desea mantener una base de datos que dé soporte a una aplicación de música online. Para ello, se necesita
almacenar información sobre canciones, álbumes, artistas, listas de canciones (playlists) y usuarios de la
aplicación. Las cuestiones más importantes que hay que tener en cuenta son:
• Cada usuario registrado de la aplicación tiene un nombre (o nick) y es de un tipo (‘GRATUITO’,
‘PREMIUM INDIVIDUAL’, ‘PREMIUM DOS’, ‘PREMIUM FAMILIAR’). En el proceso de registro puede
haber proporcionado su email o bien su teléfono (uno de los dos datos, no ambos a la vez). No hay dos
usuarios con el mismo teléfono ni con el mismo email. A cada usuario se le asigna un identificador
interno y paga una cuota mensual, que en el caso de ser un usuario gratuito es evidentemente 0. Para
cada usuario se almacena la fecha en la que usó la aplicación por última vez.
• Un usuario puede “invitar” a otros que se registren en la aplicación, y así conseguir descuentos en su
cuota mensual, por lo que es necesario anotar qué usuario ha invitado a qué otro (no hay que modelar nada
acerca de los descuentos). Un usuario puede no haber invitado a nadie, ni haber sido invitado. Un usuario
sólo puede ser invitado por otro usuario (sólo por uno).
• La aplicación pone a disposición de sus usuarios información acerca de artistas musicales. Para cada uno
de ellos se necesita conocer su identificador y el país de origen. Un artista puede ser un solista o bien una
banda (o grupo) de música. Para los solistas se desea almacenar además, su nombre y una biografía muy
breve, y para las bandas interesa recoger su nombre y el año de fundación del grupo.
• Una banda está formada por dos o más músicos (no son solistas). Para cada músico se almacena su
nombre y los instrumentos que tocan: ‘GUITARRA’, ‘BAJO’, ‘BATERIA’, ‘VOZ’, ‘PIANO’, ‘OTRO’). Un
mismo músico puede tocar a la vez varios instrumentos, por ejemplo, ser la voz del grupo y tocar la
guitarra, o tocar el bajo, el teclado y la armónica. Para cada banda interesa conocer cuál de sus músicos es
el líder.
• Cada artista ha publicado varios álbumes, al menos uno. Por simplicidad se considera que un álbum sólo
puede haber sido grabado por un artista concreto. Las colaboraciones entre cantantes o entre bandas no
son consideradas; tampoco se consideran los sencillos (con hasta 3 canciones) ni los EPs (hasta 6
canciones).
• Para cada álbum interesa almacenar su identificador, el año en el que fue publicado y su título. Es posible
que haya diferentes álbumes de distintos artistas que tengan el mismo título.
• La aplicación clasifica los álbumes según su género musical. Por eso, para cada álbum se indica a qué
genero pertenece (‘POP’, ‘ROCK’, ‘INDIE’, ‘HIP HOP’, K-POP’, ‘CLÁSICA’, ‘LATINO’, ‘FLAMENCO’, etc.).
• Un álbum contiene 7 o más canciones. Cada canción dentro de cada álbum ocupa cierta posición (la
primera canción, la canción número 8, etc.). Además, se requiere almacenar su título y su duración en
minutos. Lógicamente, cada canción sólo puede pertenecer a un álbum.
• Los usuarios pueden crear sus propias listas de reproducción (playlists). Una lista tiene un nombre, una
descripción (opcional) y sólo puede pertenecer a un usuario. Es posible que haya usuarios que no hayan
creado ninguna lista. Cada lista de cada usuario se numera de forma consecutiva; así el usuario 1 puede
tener las listas 1 y 2, el usuario 2 puede tener sólo la lista 1, ... y el usuario n puede tener listas 1, 2, 3 y 4.
• Una lista consiste en varias canciones que su creador ha ido añadiendo. Interesa almacenar la fecha en la
que cada usuario ha añadido cierta canción a cierta lista. Una misma canción puede aparecer en muchas
listas diferentes o no aparecer en ninguna. Una lista puede no tener ninguna canción asociada, quizá
porque está recién creada o porque el usuario ha borrado su contenido.
• Para cada canción interesa saber en cuantas listas está añadida en cada momento.

A continuación, se muestra un esquema conceptual elaborado a partir del enunciado anterior y

que, por tanto, describe los requisitos de datos del caso de estudio. Se ha empleado la notación del
modelo Entidad-Relación extendido (MERE) que hemos visto en clase.

2º Grado en Ingeniería Informática. Bases de Datos. Práctica P1. Diseño lógico - 1/6
Esquema conceptual de datos “MUSICA”

2º Grado en Ingeniería Informática. Bases de Datos. Práctica P1. Diseño lógico - 2/6
Ejercicios
1. Diseño Lógico Estándar. Aplica los pasos del Diseño Lógico (las reglas de traducción de
elementos del MERE a elementos del Modelo Relacional), en el orden indicado en el tema 5, para
transformar manualmente el esquema conceptual en un esquema lógico correspondiente.

1.1. Relaciones.
Describe cada una de las relaciones del esquema lógico siguiendo el formato empleado en las
diapositivas del tema de Diseño Lógico, es decir utilizando la plantilla disponible en la zona de
Recursos del Aula Virtual (bd-p1-plantilla-diseño-logico.docx).
- Ten en cuenta que irás rellenando las plantillas poco a poco, conforme vayas traduciendo los
distintos elementos del esquema conceptual (tipos de entidad, de relación 1:N, M:N, etc.).
- Al definir cada clave ajena es importante elegir justificadamente las acciones de
mantenimiento de la integridad referencial (ON DELETE acción ON UPDATE acción) que
consideres más adecuadas; acción puede ser NO ACTION, CASCADE, SET NULL o SET DEFAULT.
- Trata de expresar lo más claro posible las fórmulas de cálculo de los atributos derivados,
pero con tus palabras, utilizando lenguaje natural. Ten en cuenta que sólo será posible
definir las fórmulas de cálculo cuando hayas traducido los elementos implicados en la misma
(tipos de entidad, tipos de relación, ...). Quizá dejarlo para el final es buena idea.
- Puedes deducir restricciones de comprobación sencillas (valores posibles de algún atributo,
etc.) a partir del enunciado, e incluirlas en el apartado “Comprobar” de las plantillas de las
relaciones adecuadas. También debes incorporar ahí las restricciones de integridad de
dominio indicadas bajo el esquema conceptual (atributos “genero”, “tipo” e “instrumento”).
- Si al traducir algún tipo de relación o una jerarquía surge la necesidad de redactar un aserto
para expresar correctamente una cardinalidad (mínima o máxima) u otra restricción, entonces
debes incluir el aserto en el ejercicio 1.2.
Nota: Anota toda explicación que consideres conveniente con respecto a las decisiones tomadas
en cada caso, sobre todo si existen varias alternativas de traducción y has elegido una de ellas.
Importante: en el momento de la entrega de la práctica, cada relación debe estar completamente
descrita utilizando una única plantilla. Debes entregar, por tanto, tantas plantillas como
relaciones (tablas) haya en el esquema lógico obtenido.

1.2. Restricciones de Integridad.

Especifica textualmente (con lenguaje claro y conciso, en el formato usado en las diapositivas del
tema 5 Diseño Lógico) las restricciones de integridad que hayan surgido durante la traducción
y no hayas podido incluir en la plantilla de descripción de ninguna relación. Es decir...
- Incluye en este apartado las restricciones de integridad que hayan aparecido durante el
proceso de traducción, por ejemplo para asegurar el cumplimiento de las cardinalidades
mínimas 1 de los tipos de entidad “padre” en tipos de relación 1:N y de los conectados a tipos
de relación M:N. Utiliza asertos similares a los vistos en clase de teoría (tema 5).
- No consideres la regla de integridad general RI1 indicada bajo el Esquema Conceptual. No
redactes ningún aserto para ella (ya lo harás en la práctica P3).
- Ojo: la regla de integridad general RI2 sí es posible incluirla en la plantilla correspondiente a
una de las relaciones obtenidas. Piensa cómo hacerlo. Es sencillo, en realidad.
Importante: debes redactar los asertos en lenguaje natural, con un formato similar al empleado
en el tema 5 de teoría, usando como vocabulario los nombres de los atributos (columnas) y
relaciones (tablas) del Esquema Lógico1 que está creando. No uses el SQL.

1
No utilices nombres de tipos de entidad, de atributos o de tipos de relación del Esquema Conceptual. Ya estamos en el nivel lógico.

2º Grado en Ingeniería Informática. Bases de Datos. Práctica P1. Diseño lógico - 3/6
2. Diseño Lógico Específico. Define (implementa) el esquema lógico utilizando Oracle SQL.
Elabora un script (guión) de bases de datos, con las sentencias SQL de creación de las
diferentes tablas del esquema (CREATE TABLE...).
Debes utilizar el SQL de Oracle, tratando de ajustarte al estándar ANSI SQL (tema 6) tanto
como sea posible y sólo cuando alguna sentencia estándar no sea soportada por Oracle, podrás
usar sentencias propias y específicas del SQL de Oracle.

El código SQL para crear cada tabla se puede redactar a partir de la información incluida en
la plantilla correspondiente, que has elaborado en el ejercicio 1.1 anterior. Para ello hay que...
• Elegir el tipo de datos y longitud apropiados para las columnas de la tabla. El enunciado te
dará pistas acerca de cuáles son los más adecuados. Se recomienda usar cadenas de tamaño fijo de
unos 4 caracteres para códigos/identificadores, y cadenas de longitud variable de máximo 20 o 30 caracteres
para nombres, descripciones o campos de texto similares.
• Expresar las restricciones de integridad de columna y de tabla identificadas y darles un
nombre adecuado:
▪ Atributos con valor obligatorio (NOT NULL) u opcional (NULL).
▪ Valores por defecto (DEFAULT).
▪ Claves primarias (PRIMARY KEY).
▪ Claves alternativas (UNIQUE).
▪ Claves ajenas (FOREIGN KEY).
Para cada clave ajena hay que indicar siempre como COMENTARIOS (o sea, precedidas
de dos guiones ‘--‘) las acciones de mantenimiento de la integridad referencial (ON
DELETE... y ON UPDATE...) que se consideren más adecuadas (NO ACTION, CASCADE, SET NULL, SET
DEFAULT).
Así, al estar comentadas, Oracle siempre asume NO ACTION, pero queda registrado qué
opción se ha elegido en cada caso (para su valoración por el/la profesor/a).
▪ Otras restricciones (CHECK). Define mediante una cláusula CHECK cada restricción de
comprobación (restricción de integridad de dominio). Por ejemplo, verificación de valores
correctos para columnas de la tabla (valores mayores que cero, lista de valores posibles
para cierto atributo, etc.). Debes haberlas incluido anteriormente (ejercicio 1) en el apartado
“Comprobar” de la plantilla de descripción de las relaciones.
• No hay que redactar asertos en Oracle SQL.
Hay restricciones de integridad que no es posible traducir de forma directa al SQL de
Oracle, por ejemplo:
▪ La restricción de integridad general llamada RI1, indicada bajo el Esquema
Conceptual.
▪ Los asertos que han surgido durante la traducción de jerarquías o tipos de relación
excluyentes, o para asegurar el cumplimiento de cardinalidades mínimas 1 de tipos de
entidad padre (asertos que habrás identificado e incluido en el ejercicio 1.2).
Esto significa que en este ejercicio 2 NO hay que redactar código Oracle SQL para
implementar ni la restricción de integridad RI1 adjunta al Esquema Conceptual, ni los asertos
surgidos durante la traducción, e identificados y especificados en el ejercicio 1.2).
Se trabajará con estos asertos en la práctica P3.

2º Grado en Ingeniería Informática. Bases de Datos. Práctica P1. Diseño lógico - 4/6
 Importante:
El script de creación de las tablas del esquema debe ejecutarse de manera completa sin
errores. Para redactarlo, ejecutarlo, y depurarlo puedes utilizar la herramienta Oracle SQL
Developer.
Es imprescindible crear las tablas en el orden más adecuado, que evite errores de
integridad. Por ejemplo, no es posible crear una tabla que incluya una clave ajena que
referencie a otra tabla que aún no ha sido creada. Es decir, una tabla sólo puede hacer
referencia a tablas que ya hayan sido creadas en la BD. Hay que encontrar un orden de
creación que respete esto.
Es imprescindible, por tanto, que el CREATE TABLE de cada tabla incluya todas las
restricciones de integridad propias, incluidas las claves ajenas. ¨Y que sólo cuando esto no
sea posible (ciclos referenciales, por ejemplo), se podrá crear una tabla sin una clave ajena, y
más adelante, cuando ya sea posible, añadir dicha restricción a la tabla (mediante la
sentencia ALTER TABLE T ADD …)2.

2
Más información al respecto en el tema 6 de teoría.

2º Grado en Ingeniería Informática. Bases de Datos. Práctica P1. Diseño lógico - 5/6
Documentación que se debe entregar
La entrega se realizará mediante el Aula Virtual, antes de la fecha límite indicada en la Tarea
correspondiente. Basta con que uno de los miembros de cada equipo realice la entrega.
Se debe proporcionar el informe de realización de la práctica (memoria), así como el guion (script)
SQL elaborado.
Los 2 ficheros deben ser incluidos en un fichero comprimido con el nombre bdxxxx-p1.zip (o
.rar), sustituyendo bdxxxx por el nombre de su equipo de prácticas (cuenta Oracle).
El nombre y formato de cada uno de los ficheros será el siguiente:
(1) Informe de la práctica. Documento llamado (en minúsculas) bdxxxx-p1.pdf.
El informe debe tener las páginas numeradas y debe incluir lo siguiente:
❑ Portada, que muestre estos datos:
- asignatura (Bases de Datos), curso (20nn/mm) y convocatoria (junio, julio, enero).
- identificador (P1) y nombre de la práctica (Diseño Lógico).
- nombre del equipo de prácticas (bdxxxx), nombre y apellidos de cada componente.
❑ Diseño Lógico Estándar. Deberá incluir los dos apartados siguientes:
- 1.1. Relaciones. Las plantillas de descripción de todas las relaciones del esquema lógico, con
el formato indicado en el enunciado del ejercicio (plantilla). Una sola plantilla por relación.
- 1.2. Restricciones de integridad. Los asertos surgidos durante la traducción.
Se puede incluir toda explicación que se considere conveniente con respecto a las decisiones
tomadas en cada caso, sobre todo si existen varias alternativas de traducción.
❑ [opcional] Crítica constructiva y comentarios
En este apartado, de forma voluntaria, se puede incluir comentarios críticos constructivos
(positivos / negativos, qué te ha costado/gustado/disgustado más, etc.) de la práctica. A los
profesores nos vendrá bien este feedback para mejorar la asignatura.

(2) Fichero script SQL Oracle. Un fichero de texto plano, con extensión .sql, que contendrá las
sentencias de creación del esquema lógico específico:
❑ bdxxxx-esquema.sql
Script de definición del esquema de base de datos en SQL de Oracle.
Debe contener sólo las sentencias CREATE TABLE y (sólo si son necesarias) ALTER TABLE.,
en el orden en el que hay que ejecutarlas para crear todas las tablas sin errores de ejecución.

Fecha límite de entrega

La práctica se puede entregar hasta el domingo 12 de marzo a las 23:55h.
Es decir, en el Aula Virtual la Tarea correspondiente, denominada de forma similar a “Entrega
de Practica P1. Diseño Lógico” se cerrará en ese momento.

Criterios de evaluación
- Es indispensable entregar tanto el informe de la práctica como el guion (script) SQL.
No se corregirá la práctica si no se ha entregado la documentación completa.
Es conveniente presentar la solución de todos los ejercicios.
- Se valorará el aspecto de presentación (estilo) del informe de la práctica y, en el caso de que haya
lugar a ello, la inclusión de varias soluciones alternativas y la justificación de la elegida.
- Esta práctica supone un 30% de la nota global de prácticas.

Es imprescindible respetar estrictamente las normas y el formato de presentación

de la práctica, detallados en este documento

2º Grado en Ingeniería Informática. Bases de Datos. Práctica P1. Diseño lógico - 6/6