wikiserver - Contribucions de l’usuari [ca]

M2 - Bases de dades / UF1NF3: Solucions exercicis Normalitzacio

2026-04-24T15:39:16Z

Rsort: /* Normalització 2 */

==Normalització 1==
L’objectiu d’aquesta activitat és obtenir un disseny correcte a partir d’una relació universal tot aplicant els processos de normalització.

Considereu la relació universal formada pels atributs Assig (assignatura), Aula, Alum (alumne), Prof (professor), Hora i Nota (qualificació).

Se sap que cada assignatura té un únic professor; una aula, en un moment determinat, només pot estar ocupada per una única assignatura, i per cada assignatura hi ha una qualificació.

A partir de la relació universal, dissenyeu l’esquema de dependències funcionals i apliqueu el procés de normalització fins a assolir les relacions en cinquena forma normal. Indiqueu en quin moment s’assoleixen les diferents formes normals.

'''Solució:'''

Definició de la relació universal:

UNIVERSAL (Assig, Aula, Alum, Prof, Hora, Nota)

La relació universal està en primera forma normal, ja que tots els atributs són indivisibles o atòmics.

L’esquema de dependències funcionals, tenint en compte les observacions de l’enunciat, és aquest:

[[Imatge:uf1nf3_sol_normalitzacio1.png |500px|center| Solució normalització exercici 1]]

Com a clau primària de la relació universal, podem considerar la formada pels atributs Assig, Aula, Hora i Alum, ja que aquests atributs identifiquen els diferents tuples de la relació. Així, podem escriure:

UNIVERSAL ('''''Assig, Aula, Hora, Alum''''', Prof, Nota)

Aquesta relació no es troba en 2FN, ja que té atributs que no formen part de la clau primària i que tenen dependència funcional no total de la clau.

En efecte, l’atribut Prof depèn d’Assig, i no pas de Nota. També, l’atribut Nota depèn dels atributs Assig i Alum. Per tant, aquestes dependències ens indiquen com hem de trencar la relació universal en relacions de manera que es mantinguin les dependències funcionals i es trobin en 2FN:

ESPAIS ('''''Aula, Hora''''', Assig)

DOCÈNCIA ('''''Assig''''', Prof)

QUALIFICACIONS ('''''Assig, Alum''''', Nota)

Fixem-nos que les tres relacions es troben en 2FN.

També es troben en 3FN, ja que cap d’elles conté atributs no clau amb dependències transitives de la clau.

Les tres relacions es troben en FNBC, ja que no hi ha determinants que no siguin claus candidates.

Les tres relacions es troben 4FN, ja que cap d’elles no té dependències multivalents.

Les tres relacions es troben en 5FN, ja que cap d’elles no té dependències de reunió.

==Normalització 2==

L’objectiu d’aquesta activitat és obtenir un disseny correcte a partir d’una relació universal tot aplicant els processos de normalització.

Una federació esportiva vol informatitzar les dades dels esportistes federats, els quals han de ser, obligatòriament, membres d’algun club esportiu. A aquest efecte, es considera que els esportistes estan identificats per un número de federat i poden haver estat en diferents clubs, identificats per un codi, diverses vegades. A part, cada esportista ha passat, al llarg de la seva història, per diferents categories.

Evidentment, també interessa el nom, l’adreça i la ciutat de residència de l’esportista i del club. Ah! les ciutats estan codificades i tenen un nom que no les identifica.

Davant d’aquesta situació, el responsable informàtic de la federació, que no coneix el model Entitat-Relació, ha decidit considerar la relació universal:

<hr>
UNIVERSAL (NúmEsp, NomEsp, DirEsp, CodCiuEsp, NomCiuEsp, DataIniClub, DataFiClub, CodClub, NomClub, DirClub, CodCiuClub, NomCiuClub, DataIniCat, DataFiCat, Categoria)
<hr>

i normalitzar-la, però necessita ajuda.

El podeu ajudar a dissenyar l’esquema de dependències funcionals i aplicar el procés de normalització fins a assolir les relacions en cinquena forma normal. Indiqueu en quin moment s’assoleixen les diferents formes normals.

Abreviatures: Esp (esportista); Dir (direcció); Ciu (ciutat); Cat (categoria)

'''Solució:'''

La relació universal està en primera forma normal, ja que tots els atributs són indivisibles o atòmics.

L’esquema de dependències funcionals, tenint en compte les observacions, és el següent:

[[Imatge:uf1nf3_sol_normalitzacio2.png |600px|center| Solució normalització exercici 2]]

Fixem-nos que un esportista no tindrà dues vegades la mateixa categoria, és a dir, en passar d’aleví a infantil, ja no tornarà a ser aleví mai, per la qual cosa, donat un esportista i una categoria, només ens podem trobar amb una data d’inici a la categoria (DataIniCat) i una data final de la categoria (DataFiCat). No passa el mateix en el cas del club al qual pertany un esportista, ja que com es dedueix de l’enunciat, un esportista pot passar per un club diverses vegades. Per tant, la data de finalització en un club (DataFiClub) depèn funcionalment de l’esportista, el club i la data d’inici en el club (DataIniClub).

Com a clau primària de la relació universal, podem considerar NúmEsp, CodClub, DataIniClub i Categoria, ja que aquests atributs identifiquen els diferents tuples de la relació. Així, podem escriure el següent:

UNIVERSAL (NúmEsp, NomEsp, DirEsp, CodCiuEsp, NomCiuEsp, DataIniClub, DataFiClub, CodClub, NomClub, DirClub, CodCiuClub, NomCiuClub, DataIniCat, DataFiCat, Categoria)

Aquesta relació no es troba en 2FN, ja que té atributs (com es veu en l’esquema de dependències funcionals) que no formen part de la clau primària i que tenen dependència funcional no total de la clau. Per tant, aquestes dependències ens indiquen com hem de trencar la relació universal en relacions de manera que es mantinguin les dependències funcionals i es trobin en 2FN:

ESPORTISTES (_NúmEsp_, NomEsp, DirEsp, CodCiuEsp, NomCiu)

CLUBS (_CodClub_, NomClub, DirClub, CodCiuClub, NomCiu)

ESPORTISTES_CLUBS (_NumEsp, CodClub, DataIniClub_, DataFiClub)

ESPORTISTES_CATEGORIES (_NúmEsp, Categoria_, DataIniCat, DataFiCat)

Fixem-nos que les quatre relacions es troben en 2FN.

ESPORTISTES i CLUBS no es troben en 3FN donat que existeix dependència funcional transitiva:

NumEsp -- > CodCiuEsp -- > NomCiu i

CodClub -- > CodCiuClub -- > NomCiu

Per tal de posar les relacions en 3FN creem una relació nova:

CIUTATS (_CodCiu_, NomCiu)

i eliminem el NomCiu de les relacions ESPORTISTES i CLUBS:

ESPORTISTES (_NúmEsp_, NomEsp, DirEsp, CodCiuEsp)

CLUBS (_CodClub_, NomClub, DirClub, CodCiuClub)

Ara totes les relacions es troben en 3FN, ja que cap d’elles conté atributs no clau amb dependències transitives de la clau.

Les cinc relacions es troben en FNBC, ja que no hi ha determinants que no siguin claus candidates.

Les cinc relacions es troben 4FN, ja que cap d’elles té dependències multivalents.

Les cinc relacions es troben en 5FN, ja que cap d’elles té dependències de reunió.

M2 - Bases de dades / UF1NF3: Solucions Model relacional casos pràctics

2026-04-24T15:27:06Z

Rsort: /* Empresa de comidas */

==Biblioteca v1==

L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional.

Donat el model ER següent, feu-ne la traducció al model relacional:

[[Imatge:uf1nf2_sol_biblioteca_v1.png |700px|center| Solució Biblioteca v1]]

AUTOR ('''''Id_autor''''', Nom, Any_neix, Nacionalitat)

SOCI ('''''Codi''''', DNI, Nom, Cognoms, Telefon)

LLIBRE ('''''ISBN''''', Titol, Editorial, Any)

EXEMPLAR ('''''ISBN, Num_ex''''', Estat) ON {ISBN} REFERENCIA LLIBRE

ESCRIURE ('''''Id_autor, ISBN''''') ON {Id_autor} REFERENCIA AUTOR I {ISBN} REFERENCIA LLIBRE

RESERVAR ('''''Codi_soci, ISBN, Num_ex''''', Data_reserva, Data_real, Data_tornar) ON {Codi_soci} REFERENCIA SOCI I {ISBN, Num_ex} REFERENCIA EXEMPLAR



==Academia==

L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional.

Donat el model ER següent, feu-ne la traducció al model relacional:

[[Imatge:uf1nf2_sol_academia.png |700px|center| Solució Academia]]

1. Mantenint supertipus i subtipus.

PERSONA ('''''DNI''''', Nom, Adreça, Telefon)

ALUMNE ('''''DNI''''', Anys, Estudis) ON {DNI} REFERENCIA PERSONA

PROFESSOR ('''''DNI''''', Especialitat) ON {DNI} REFERENCIA PERSONA

EMPLEAT ('''''DNI''''', Anys_emp, Carreg, CIF_empresa) ON {DNI} REFERENCIA ALUMNE i {CIF_empresa} REFERENCIA EMPRESA

DESEMPLEAT ('''''DNI''''', Anys_desemp, Darrera_feina) ON {DNI} REFERENCIA ALUMNE

EMPRESA ('''''CIF''''', Nom, Telefon, Adreça)

TIPUS_CURS ('''''Codi_curs''''', Nom, Programa, Hores)

CURS ('''''Id_curs''''', Data_inici, Data_final, Codi_curs, DNI_professor) ON {Codi_curs} REFERENCIA TIPUS_CURS i {DNI_professor} REFERENCIA PROFESSOR

CURSAR ('''''Id_curs, DNI_alumne''''', Nota) ON {Id_curs} REFERENCIA CURS i {DNI_alumne} REFERENCIA ALUMNE

2. Eliminant els subtipus empleat i desempleat.

Tot igual, amb els següents canvis:
- eliminem les relacions empleat i desempleat
- i:

ALUMNE ('''''DNI''''', Anys, Estudis, Anys_emp, Carreg, Anys_desemp, Darrera_feina, Tipus_alumne, CIF_empresa) ON {DNI} REFERENCIA PERSONA i {CIF_empresa} REFERENCIA EMPRESA



==Perrera municipal==

L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional.

Donat el model ER següent, feu-ne la traducció al model relacional:

[[Imatge:uf1nf2_sol_perrera.png |700px|center| Solució Perrera]]


==Alquiler automóviles==

L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional.

Donat el model ER següent, feu-ne la traducció al model relacional:

[[Imatge:uf1nf2_sol_alquiler_coches.png |800px|center| Solució Alquiler coches]]

CLIENT ('''''DNI''''', Nom, Cognoms, Telefon, DNI_avalador) ON {DNI_avalador} REFERENCIA CLIENT ADMET VALORS NULS

AGENCIA ('''''Id_agencia''''', Adreça, Telefon)

COTXE ('''''Matricula''''', Marca, Modelo, Color, Id_garatge) ON {Id_garatge} REFERENCIA GARATGE

GARATGE ('''''Id_garatge''''', Adreça, Metres_quadrats)

RESERVA ('''''Id_agencia, Num_reserva'''', Data_ini, Data_fin, DNI_CLI) ON {DNI_CLI} REFERENCIA CLIENT I {Id_agencia} REFERENCIA AGENCIA

COTXES_RESERVA ('''''Id_agencia, Num_reserva, Matricula''''', Km_ini, Km_fin) ON {Id_agencia, Num_reserva} REFERENCIA RESERVA I {Matricula} REFERENCIA COTXE

SENSE ADMETRE VALORS NULS



==Empresa de comidas==

L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional.

Donat el model ER següent, feu-ne la traducció al model relacional:

[[Imatge:uf1nf2_sol_empresa_comidas.png |800px|center| Solució Empresa comidas]]

1. Mantenint supertipus i subtipus.

TREBALLADOR ('''''DNI''''', Nom, Cognoms, Telefon_fixe, Telefon_mobil, NSS)

CUINER ('''''DNI''''', Anys_servei) ON {DNI} REFERENCIA TREBALLADOR

AJUDANT ('''''DNI''''', Data_neix, DNI_cuiner) ON {DNI} REFERENCIA TREBALLADOR i {DNI_cuiner} REFERENCIA CUINER

PLAT ('''''Id_plat''''', Nom, Tipus, Preu)

INGREDIENT ('''''Id_ingredient''''', Nom)

MAGATZEM ('''''Num_magatzem''''', Nom, Descripcio, Adreça)

PRESTATGE ('''''Num_magatzem, Lletres''''', Mida) ON {Num_magatzem} REFERENCIA MAGATZEM

CUINER_PLAT ('''''DNI_cuiner, Id_plat''''') ON {DNI_cuiner} REFERENCIA CUINER i {Id_plat} REFERENCIA PLAT

INGREDIENT_PLAT ('''''Id_ingredient, Id_plat''''', Quantitat) ON {Id_ingredient} REFERENCIA INGREDIENT i {Id_plat} REFERENCIA PLAT

INGREDIENT_PRESTATGE ('''''Id_ingredient, Num_magatzem, Lletres''''', Quantitat) ON {Id_ingredient} REFERENCIA INGREDIENT i {Num_magatzem, Lletres} REFERENCIA PRESTATGE

2. Eliminant el supertipus i mantenenint els subtipus.

Tot igual, amb els següents canvis:
- eliminem la relació TREBALLADOR
- i modifiquem CUINER i AJUDANT afegint-lis els atributs de TREBALLADOR

CUINER ('''''DNI''''', , Nom, Cognoms, Telefon_fixe, Telefon_mobil, NSS, Anys_servei)

AJUDANT ('''''DNI''''', , Nom, Cognoms, Telefon_fixe, Telefon_mobil, NSS, Data_neix, DNI_cuiner) ON {DNI_cuiner} REFERENCIA CUINER



==Spots==

L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional.

Donat el model ER següent, feu-ne la traducció al model relacional:

[[Imatge:uf1nf2_sol_spots.png |700px|center| Solució Spots]]

M2 - Bases de dades / UF1NF2: Solucions casos pràctics Model E/R

2026-04-24T14:54:29Z

Rsort: /* Empresa de comidas */

==Gabinete abogados==

Se quiere diseñar una base de datos relacional para almacenar la información sobre los asuntos que lleva un gabinete de abogados. Cada asunto tiene un número de expediente que lo identifica y corresponde a un solo cliente. Del asunto se debe almacenar la fecha de inicio, fecha de archivo (finalización), su estado (en trámite, archivado, etc.), así como los datos personales del cliente al que pertenece (DNI, nombre, dirección, teléfono, etc.) Algunos asuntos son llevados por uno o varios procuradores y viceversa, de los que nos interesa también los datos personales.

[[Imatge:uf1nf2_sol_gabinete_abogados.png |700px|center| Solució Gabinete abogados]]

==Zoo==

Se quiere diseñar una base de datos relacional para almacenar información relativa a los zoos existentes en el mundo, así como las especies animales que éstos albergan. De cada zoo se conoce el nombre, la ciudad y país donde se encuentra, tamaño (m2) y presupuesto anual. De cada especie animal se almacena el nombre vulgar, el nombre científico, familia a la que pertenece y si se encuentra en peligro de extinción. Además, se debe guardar información sobre cada animal que los zoos poseen, como su número de identificación, especies, sexo, año de nacimiento, país de origen y continente. La identificación es propia de cada zoo.

[[Imatge:uf1nf2_sol_zoo.png |700px|center| Solució Zoo]]

==Club náutico==

Se quiere diseñar una base de datos relacional para gestionar un club náutico. Interesa guardar información sobre socios y patrones, pudiendo ser que haya socios que también sean patrones. De socios y patrones se guardan los datos personales. De los socios, la fecha de alta como socio y los datos del barco o barcos que posee: número de matrícula, nombre, número del amarre y cuota que paga por el mismo. Además, se quiere mantener información sobre las salidas realizadas por cada barco, como la fecha y hora de salida, el destino y el patrón responsable de la salida, que no tiene por qué ser el propietario del barco, ni es necesario que sea socio del club. Además de los patrones nos interesa conocer el año en el que obtuvieron la titulación y su categoría (A, B o C).

[[Imatge:uf1nf2_sol_club_nautic.png |500px|center| Solució Club náutic]]

==Departamentos de una empresa==

Representad los departamentos de una empresa con las siguientes características: Un departamento tiene varios empleados, pudiendo estos estar asignados a un sólo departamento; los empleados tienen un único director. De todos los empleados nos interesa su DNI, nombre, apellidos i teléfono y de los departamentos su identificador, nombre y ubicación.

[[Imatge:uf1nf2_sol_departaments_empresa.png |350px|center| Solució Departaments empresa]]

==Biblioteca v1==

Diseñad un esquema E/R para gestionar los datos de una biblioteca:

:*Las personas socias de la biblioteca disponen de un código de socio y se precisa su dni, teléfono, nombre y apellidos.
:*La biblioteca almacena libros que presta a los socio, de ellos se almacena su título, su editorial, el año en el que se escribió el libro, el nombre completo del autor (o autores), el año en que se editó y en qué editorial fue y el ISBN. De los autores interesa además su año de nacimiento y su nacionalidad.
:*La biblioteca también dispone de algunos libros reconocidos de autores anònimos.
:*De cada libro se tienen uno o varios ejemplares de los que debemos conocer su estado: deteriorado o no.
:*Queremos controlar cada préstamo que se realiza almacenando la fecha en la que se realiza, la fecha tope para devolver (que son 15 días más que la fecha en la que se realiza el préstamo) y la fecha real en la que se devuelve el libro.

[[Imatge:uf1nf2_sol_biblioteca_v1.png |700px|center| Solució Biblioteca v1]]

==Academia==

Diseñad un esquema E/R para gestionar los datos de una academia:

:*Se dan clases a trabajadores y desempleados. Los datos que se almacenan de los alumnos son el DNI, dirección, nombre, teléfono, edad y estudios.
:*Además de los que trabajan necesitamos saber el CIF, nombre, teléfono, dirección de la empresa en la que trabajan, el cargo que tienen y los años que llevan en la misma. De los desempleados el tiempo que llevan desempleados y el último trabajo que desempeñaron.
:*Los cursos que imparte la academia se identifican con un código de curso. Además se almacena el nombre, programa,las horas de duración del curso, y cada vez que se imparte se anotará las fechas de inicio y fin del curso junto con un número concreto de curso (distinto del código) y los datos del profesor o profesora (sólo uno por curso) que son: dni, nombre, dirección, teléfono y especialidad.
:*Se almacena la nota obtenida por cada alumno en cada curso teniendo en cuenta que un mismo alumno o alumna puede realizar varios cursos.


==Perrera municipal==

Tenemos una perrera municipal que, además de acoger perros sin dueño, acoge a perros con dueño. Se ha de diseñar un esquema E/R teniendo en cuenta que:

:*Un perro puede ser de una raza dterminada o no. A los perros se les asigna una identificación propia de la perrera y debemos conocer su sexo, la data d'entrada en la perrera y en que estado se encuentra. De las razas nos interesa la altura, la medida, el caracter y la esperanza de vida.

:*Un perro puede tener dueño o no. De los dueños nos interesa sus datos personales: DNI, nombre, apellidos y teléfono.

:*Una persona puede tener más de un perro.

:*Un perro se encuentra albergado en una jaula determinada. Las jaulas se identifican por código interno de la perrera y precisamos conocer la capacidad de cada jaula.

:*En las jaulas pueden haber n perros.

[[Imatge:uf1nf2_sol_perrera.png |700px|center| Solució Perrera]]


==Alquiler automóviles==

Se desea diseñar una base de datos sobre la información de las reservas de una empresa dedicada al alquiler de automóviles. Los supuestos son los siguientes:

:*Un determinado cliente puede tener en un momento dado varias reservas

:*De cada cliente se desea almacenar su DNI, nombre, dirección y teléfono.

:*Una reserva la realiza un único cliente, pero puede involucrar a varios coches.

:*Es importante registrar la fecha de comienzo de la reserva y la de terminación.

:*Todo coche tiene siempre asignado un determinado garaje, que no puede cambiar. Del coche, interesa su matrícula, marca, modelo i color. Del garaje su dirección i metros cuadrados. Las diferentes plazas de cada garaje se asignan a los coches en función de la ocupación del mismo.

:*Cada reserva se realiza en una agencia determinada y la codificación de las mismas es propia de cada agencia. De estas, se quire tener constancia de su dirección y teléfono.

:*En la base de datos pueden existir clientes que no hayan hecho ninguna reserva.

:*Las entidades cliente, coche, agencia y garaje tienen una clave alfanumérica que las identifica unívocamente.

:*Interesa conocer los km de inicio y km finales que ha realizado cada coche en cada reserva.

:*Cada cliente puede ser avalado por otro cliente de la empresa.

[[Imatge:uf1nf2_sol_alquiler_coches.png |800px|center| Solució Alquiler coches]]


==Empresa de comidas==

Diseñad un esquema E/R par un empresa de comidas, teniendo en cuenta que:

:*El nombre y apellidos de cada empleado, su dni y su número de SS además del teléfono fijo y el móvil
:*Algunos empleados/as son cocineros/as. De los cocineros y cocineras anotamos (además de los datos propios de cada empleado) sus años de servicio en la empresa.
:*Hay empleados/as que son pinches. De los y las pinches anotamos su fecha de nacimiento.
:*La mayoría de trabajadores no son ni pinches ni cocineros/as
:*En la base de datos figura cada plato (su nombre como “pollo a la carloteña”, “bacalo al pil-pil”,…), el precio del plato junto con los ingredientes que lleva. Anotamos también si cada plato es un entrante, un primer plato, segundo plato o postre
:*De los ingredientes necesitamos la cantidad que necesitamos de él en cada plato y en qué almacén y estantería del mismo le tenemos.
:*Cada almacén se tiene un nombre (despensa principal, cámara frigorífica A, cámara frigorífica B…), un número de almacén y una descripción del mismo.
:*Cada estante en el almacén se identifica con dos letras y un tamaño en centímetros. Dos almacenes distintos pueden tener dos estantes con las mismas letras.
:*Necesitamos también saber qué cocineros son capaces de preparar cada plato.
:*Cada pinche está a cargo de un cocinero o cocinera.
:*La cantidad de ingredientes en cada estantería de un almacén se actualiza en la base de datos al instante. SI cogemos dos ajos de un estante, figurará al instante que tenemos dos ajos menos en ese estante. Es necesario por lo tanto saber los ingredientes (cuáles y en qué número) que tenemos en cada estante.

[[Imatge:uf1nf2_sol_empresa_comidas.png |800px|center| Solució Empresa comidas]]



==líneas de metro==

Construir el esquema conceptual en el modelo E/R que refleje toda la información necesaria para la gestión de las líneas de metro de una determinada ciudad. Los supuestos considerados son:

Cada línea de metro está compuesta de un conjunto de estaciones en un orden determinado. Es importante recoger la información del orden de cada estación en la línea (cuál es la 1a estación de la línea, la 2a, ...). En cada estación interesa almacenar, para cada línea, el número estimado de segundos que se tarda en llegar desde la estación anterior de la línea y los que se tarda en alcanzar la siguiente estación de la línea.

Cada línea tiene un identificador numérico (línea 1, línea 2, ...) y otro mediante un color (la línea azul, la línea roja, ...). Esto quiere decir que no hay dos líneas con el mismo número ni dos con el mismo color. También se quiere almacenar la hora de salida del primer tren de la línea y la del último.

Las estaciones tienen un código numérico que las distingue de las demás. También tienen un nombre diferente para cada una. Se guardan los horarios de apertura y cierre de cada estación. Una estación pertenece al menos a una línea, aunque puede pertenecer a varias líneas.

Cada estación tiene uno o varios accesos desde el exterior. Cada uno de dichos accesos pertenece a una única estación. Los accesos de una misma estación están numerados de forma correlativa (el primer acceso de la estación 7, el segundo acceso de la estación 7, ...). Por cada acceso se guarda la calle y número de portal más cercano a donde está situado.

Cada tren tiene un número diferente al del resto de trenes. Se necesita guardar la fecha de compra, el modelo y la capacidad en número de vagones.

Se guardan los trenes que están o han estado en servicio y qué línea. Un tren puede prestar o haber prestado servicio en varias líneas diferentes. Incluso puede haber prestado diferentes servicios en la misma línea (en periodos de tiempo diferentes). Se guarda la fecha de inicio del servicio del tren en la línea y la de finalización. No puede haber dos servicios diferentes del mismo tren en la misma línea y en periodos que se solapen.

En algunas estaciones hay cocheras para aparcar los trenes cuando no están de servicio. Cada tren tiene asignada una de estas cocheras. Se puede cambiar la cochera asignada a un tren, pero no se puede quedar sin ninguna asignada. Cada cochera se distingue de las demás por la estación donde está situada (en una misma estación sólo puede haber una cochera). Además se almacena el número de trenes (máquinas) y el de vagones que puede alojar.

Cada llegada de un tren a un andén es almacenada y se le asigna un número diferente para cada una. Se almacena a qué estación y línea corresponde la llegada y en qué sentido de la marcha (ascendente según el número de orden de la estación en la línea o descendente). También se guarda el tren que ha llegado y el número de llegada que corresponde al tren. Este último número se asigna así: la primera llegada a un andén de este tren se numeró con un uno, la segunda con un dos, etc. Teniendo esto en cuenta, no puede haber dos llegadas que contengan el mismo par (tren, número de llegada). Además se guarda la fecha y hora de
llegada del tren al andén y la fecha y hora de salida.



==Libreria OnLine==

Un cliente le ha contratado para diseñar una web que permita comprar libros por Internet. Tenga en cuenta las siguientes indicaciones para modelar cómo sería la base de datos del proyecto:

:*De cada libro guardaremos su título, isbn, año de publicación y descripción. También es interesante almacenar los datos del autor/es y de la editorial que ha publicado el libro.

:*Los libros que se podrán comprar en la web pueden ser libros de papel o libros electrónicos (ebooks). En el caso de los libros de papel interesa guardar donde ha sido impreso y la fecha de impresión. En el caso de un ebook guardaremos el tamaño del archivo. Hay que tener en cuenta que un mismo libro tiene precios diferentes en papel y en formato ebook.

:*De los autores nos interesa almacenar el nombre, apellidos, dirección, localidad, provincia, url de su página web y un identificador único de autor.

:*Para las editoriales guardaremos un identificador, nombre, dirección, localidad, provincia, número de teléfono y la url de su página web.

:*La tienda dispondrá de varios almacenes, de cada uno guardaremos un identificador, una dirección, localidad, provincia y un teléfono de contacto.

:*Un almacén puede almacenar diferentes libros. Un mismo libro puede estar almacenado en diferentes almacenes. Nos interesa saber el número de copias de cada libro que hay en cada almacén.

:*La base de datos debe almacenar los datos de los clientes. De cada cliente guardamos su NIF, nombre, apellidos, dirección, localidad, provincia, email y teléfono.

:*Un cliente puede tener varias cestas de la compra en el sitio web. Cada cesta de la compra está identificada por un identificador único, contiene la fecha de la compra y puede contener varios libros. Algunas cestas de la compra pueden tener más de una copia del mismo libro, por lo que será necesario almacenar la cantidad de copias que se han comprado de cada libro en cada cesta de la compra.

:*Por motivos estadísticos interesa conocer el número de habitantes de cada localidad y la densidad (hab./km2) de las provincias, ambas se identificaran por un código.




==Spots==

Se propone diseñar una Base de Datos para mejorar el control de los anuncios publicitarios para la televisión, y de todo su entorno, como los canales de TV, franjas horarias, agencias de publicidad, tipos de productos que se anuncian, etc.

En el país hay diversas entidades de televisión. Se quiere reflejar que unas son de titularidad pública, por ejemplo CCRTV (Corporació Catalana de Ràdio i Televisió), RTVE (Radiotelevisión Española), etc. Y otras que son de titularidad privada. Todas estas entidades disponen de uno o más canales de emisión (por ejemplo, CCRTV dispone de TV3 y del Canal 33, RTVE dispone de TV1 y TV2, etc.) que se identifican siempre por un nombre.

Todos los anuncios suponemos que se identifican por un código asignado por una supuesta “Oficina de Medios de Comunicación”. Debe considerarse la existencia de los anuncios que llamaremos equivalentes, como podrían ser aquellos que, con las mismas imágenes tienen diferente idioma, o por otras causas que no interesa precisar.

Cada anuncio hace referencia a uno (lo más habitual) o más (excepcionalmente) tipos de producto (por ejemplo, lavadoras y detergentes), y se quiere tener constancia de estas referencias. Incluso debe pensarse que hay tipificados ciertos tipos de productos independientemente de que hayan o no, en este momento, anuncios que se refieran a ellos. Los anuncios son siempre propiedad de una única firma comercial, que es la que las paga, incluso en el caso de anunciar más de un tipo de producto. Los anuncios son filmados, normalmente, por una agencia de publicidad aunque, en algunos casos, es la misma firma comercial que, con medios propios, los produce sin intervención de ninguna agencia publicitaria.

De las agencias de publicidad interesa conocer el nombre del director artístico. De las firmas comerciales interesa conocer el nombre del jefe de marketing. Pero de unas y otras, que podríamos considerar bajo una nueva entidad que denominaremos empresas, interesa conocer el CIF (código de identificación fiscal), nombre, dirección y teléfono.

Las agencias de publicidad disponen de directores cinematográficos para filmar los anuncios. Interesa conocer el historial de la contratación por parte de las diferentes agencias de estos directores. Un director trabaja, en un momento dado, para una sola agencia. Las agencias quieren conocer de cada anuncio que director lo ha dirigido. De los anuncios producidos directamente por las firmas comerciales, no interesa ni se quiere tener constancia de su director.

Tal como se ha indicado al principio, interesa también conocer la emisión de los anuncios en los diversos canales televisivos. A efectos de audiencia, las 24 horas del día no se entienden como tales horas, sino como “franjas horarias” (como puede ser: mañana, mediodía, tarde, noche…) perfectamente diferenciados. Es más, el precio vigente (único que interesa) de la emisión en cada canal, depende de la franja horaria. Para simplificar el caso, haremos la hipótesis de que el precio no depende del día de la semana. Se quiere tener constancia del número de veces que cada anuncio se ha emitido en los diferentes canales, su fecha de emisión y su correspondiente franja horaria.

Finalmente, hay un aspecto legal muy importante a considerar. Existen algunos tipos de productos (menos de los necesarios) que no están permitidos anunciar en ciertas franjas horarias. El incumplimiento será penalizado con multas de gravedad de 1 a 3. Interesará tener constancia de las prohibiciones legales anteriores.

Se pide diseñar la base de datos con el modelo relacional, establecer el grado y cardinalidad de cada relación. También se deben explicar las entidades, relaciones, cardinalidades y atributos.

==La Facultad==

Se ha de diseñar una base de datos para gestionar la docencia de un curso académico en una Facultad universitaria (curiosamente bastante parecida a la FIB), para controlar cuestiones como notas, horarios, matriculaciones, profesores, alumnos, etc.

La Facultad la supondremos estructurada en Departamentos. Cada uno de estos departamentos imparten la docencia de varias asignaturas. No se da el caso de que una misma asignatura sea impartida por más de un departamento.

De las asignaturas interesa saber las siglas, nombre, créditos, nivel, etc. También se desea tener constancia de que asignaturas son pre-requisitos de otras.

Cada asignatura tiene uno o más grupos (por ejemplo: grupos 10, 20, 30 y 40 de las asignatura DUABD; grupos 10, 20 y 30 de la asignatura DT, etc.). De cada grupo interesa saber las aulas y horarios correspondientes al curso actual (entendiendo el horario por el día de la semana y el horario de inicio). Se ha de tener en cuenta que un mismo grupo puede darse en aulas diferentes siempre que sea en horario diferente. De las aulas se desea conocer cual es su capacidad.

De los profesores interesa saber la categoría laboral y su dedicación (a tiempo parcial, o a tiempo completo). Y de los alumnos interesa conocer el número de matrícula y el año de ingreso a la Facultad. Tanto de los profesores como de los alumnos, que podríamos considerarlos como una entidad general que se podría denominar “personas”; interesa el DNI, nombre, apellido, dirección, teléfono, etc.

Todos los profesores están adscritos a uno y sólo un departamento. En general están encargado de uno o más grupos, pero es posible que haya profesores que no tengan asignado ningún grupo (en el curso actual), y se dediquen a tareas de búsqueda o tareas administrativas. También es posible que un grupo tenga más de un profesor encargado, es decir, que cada profesor se responsabiliza de una parte de la asignatura. Se desea tener constancia de todos los hechos anteriormente esmentados e incluso de la parte de la que se encarga o se responsabiliza cada profesor.

Al iniciar el curso, los alumnos se matriculan en varios grupos y naturalmente se desea tener información de este hecho. La base de datos debería guardar información de las notas que los alumnos han obtenido en las diferentes convocatorias de examen (febrero, junio y septiembre) de cada asignatura.

La biblioteca de esta Facultad dispone de una gran cantidad de textos (libros, revistas, apuntes, etc.). Estos textos se identifican por un código que asigna la propia biblioteca. En los diferentes grupos de cada asignatura se recomienda uno o más textos, teniendo en cuenta un orden de preferencia o prioridad. A menudo se da el caso de que un mismo texto se recomiende a más de un grupo (especialmente si son grupos de una misma asignatura). Se desea almacenar qué textos se recomienda y cual es su prioridad en cada uno de los grupos.

Como ya se deduce de los párrafos anteriores, sólo se desea almacenar la información del curso actual y no la información de cursos anteriores.
-->

M2 - Bases de dades / UF1NF3: Solucions exercicis Normalitzacio

2026-04-24T14:07:09Z

Rsort: /* Normalització 2 */

==Normalització 1==
L’objectiu d’aquesta activitat és obtenir un disseny correcte a partir d’una relació universal tot aplicant els processos de normalització.

Considereu la relació universal formada pels atributs Assig (assignatura), Aula, Alum (alumne), Prof (professor), Hora i Nota (qualificació).

Se sap que cada assignatura té un únic professor; una aula, en un moment determinat, només pot estar ocupada per una única assignatura, i per cada assignatura hi ha una qualificació.

A partir de la relació universal, dissenyeu l’esquema de dependències funcionals i apliqueu el procés de normalització fins a assolir les relacions en cinquena forma normal. Indiqueu en quin moment s’assoleixen les diferents formes normals.

'''Solució:'''

Definició de la relació universal:

UNIVERSAL (Assig, Aula, Alum, Prof, Hora, Nota)

La relació universal està en primera forma normal, ja que tots els atributs són indivisibles o atòmics.

L’esquema de dependències funcionals, tenint en compte les observacions de l’enunciat, és aquest:

[[Imatge:uf1nf3_sol_normalitzacio1.png |500px|center| Solució normalització exercici 1]]

Com a clau primària de la relació universal, podem considerar la formada pels atributs Assig, Aula, Hora i Alum, ja que aquests atributs identifiquen els diferents tuples de la relació. Així, podem escriure:

UNIVERSAL ('''''Assig, Aula, Hora, Alum''''', Prof, Nota)

Aquesta relació no es troba en 2FN, ja que té atributs que no formen part de la clau primària i que tenen dependència funcional no total de la clau.

En efecte, l’atribut Prof depèn d’Assig, i no pas de Nota. També, l’atribut Nota depèn dels atributs Assig i Alum. Per tant, aquestes dependències ens indiquen com hem de trencar la relació universal en relacions de manera que es mantinguin les dependències funcionals i es trobin en 2FN:

ESPAIS ('''''Aula, Hora''''', Assig)

DOCÈNCIA ('''''Assig''''', Prof)

QUALIFICACIONS ('''''Assig, Alum''''', Nota)

Fixem-nos que les tres relacions es troben en 2FN.

També es troben en 3FN, ja que cap d’elles conté atributs no clau amb dependències transitives de la clau.

Les tres relacions es troben en FNBC, ja que no hi ha determinants que no siguin claus candidates.

Les tres relacions es troben 4FN, ja que cap d’elles no té dependències multivalents.

Les tres relacions es troben en 5FN, ja que cap d’elles no té dependències de reunió.

==Normalització 2==

L’objectiu d’aquesta activitat és obtenir un disseny correcte a partir d’una relació universal tot aplicant els processos de normalització.

Una federació esportiva vol informatitzar les dades dels esportistes federats, els quals han de ser, obligatòriament, membres d’algun club esportiu. A aquest efecte, es considera que els esportistes estan identificats per un número de federat i poden haver estat en diferents clubs, identificats per un codi, diverses vegades. A part, cada esportista ha passat, al llarg de la seva història, per diferents categories.

Evidentment, també interessa el nom, l’adreça i la ciutat de residència de l’esportista i del club. Ah! les ciutats estan codificades i tenen un nom que no les identifica.

Davant d’aquesta situació, el responsable informàtic de la federació, que no coneix el model Entitat-Relació, ha decidit considerar la relació universal:

<hr>
UNIVERSAL (NúmEsp, NomEsp, DirEsp, CodCiuEsp, NomCiuEsp, DataIniClub, DataFiClub, CodClub, NomClub, DirClub, CodCiuClub, NomCiuClub, DataIniCat, DataFiCat, Categoria)
<hr>

i normalitzar-la, però necessita ajuda.

El podeu ajudar a dissenyar l’esquema de dependències funcionals i aplicar el procés de normalització fins a assolir les relacions en cinquena forma normal. Indiqueu en quin moment s’assoleixen les diferents formes normals.

Abreviatures: Esp (esportista); Dir (direcció); Ciu (ciutat); Cat (categoria)

M2 - Bases de dades / UF1NF2: Solucions casos pràctics Model E/R

2026-04-24T14:06:37Z

Rsort: /* Empresa de comidas */

==Gabinete abogados==

Se quiere diseñar una base de datos relacional para almacenar la información sobre los asuntos que lleva un gabinete de abogados. Cada asunto tiene un número de expediente que lo identifica y corresponde a un solo cliente. Del asunto se debe almacenar la fecha de inicio, fecha de archivo (finalización), su estado (en trámite, archivado, etc.), así como los datos personales del cliente al que pertenece (DNI, nombre, dirección, teléfono, etc.) Algunos asuntos son llevados por uno o varios procuradores y viceversa, de los que nos interesa también los datos personales.

[[Imatge:uf1nf2_sol_gabinete_abogados.png |700px|center| Solució Gabinete abogados]]

==Zoo==

Se quiere diseñar una base de datos relacional para almacenar información relativa a los zoos existentes en el mundo, así como las especies animales que éstos albergan. De cada zoo se conoce el nombre, la ciudad y país donde se encuentra, tamaño (m2) y presupuesto anual. De cada especie animal se almacena el nombre vulgar, el nombre científico, familia a la que pertenece y si se encuentra en peligro de extinción. Además, se debe guardar información sobre cada animal que los zoos poseen, como su número de identificación, especies, sexo, año de nacimiento, país de origen y continente. La identificación es propia de cada zoo.

[[Imatge:uf1nf2_sol_zoo.png |700px|center| Solució Zoo]]

==Club náutico==

Se quiere diseñar una base de datos relacional para gestionar un club náutico. Interesa guardar información sobre socios y patrones, pudiendo ser que haya socios que también sean patrones. De socios y patrones se guardan los datos personales. De los socios, la fecha de alta como socio y los datos del barco o barcos que posee: número de matrícula, nombre, número del amarre y cuota que paga por el mismo. Además, se quiere mantener información sobre las salidas realizadas por cada barco, como la fecha y hora de salida, el destino y el patrón responsable de la salida, que no tiene por qué ser el propietario del barco, ni es necesario que sea socio del club. Además de los patrones nos interesa conocer el año en el que obtuvieron la titulación y su categoría (A, B o C).

[[Imatge:uf1nf2_sol_club_nautic.png |500px|center| Solució Club náutic]]

==Departamentos de una empresa==

Representad los departamentos de una empresa con las siguientes características: Un departamento tiene varios empleados, pudiendo estos estar asignados a un sólo departamento; los empleados tienen un único director. De todos los empleados nos interesa su DNI, nombre, apellidos i teléfono y de los departamentos su identificador, nombre y ubicación.

[[Imatge:uf1nf2_sol_departaments_empresa.png |350px|center| Solució Departaments empresa]]

==Biblioteca v1==

Diseñad un esquema E/R para gestionar los datos de una biblioteca:

:*Las personas socias de la biblioteca disponen de un código de socio y se precisa su dni, teléfono, nombre y apellidos.
:*La biblioteca almacena libros que presta a los socio, de ellos se almacena su título, su editorial, el año en el que se escribió el libro, el nombre completo del autor (o autores), el año en que se editó y en qué editorial fue y el ISBN. De los autores interesa además su año de nacimiento y su nacionalidad.
:*La biblioteca también dispone de algunos libros reconocidos de autores anònimos.
:*De cada libro se tienen uno o varios ejemplares de los que debemos conocer su estado: deteriorado o no.
:*Queremos controlar cada préstamo que se realiza almacenando la fecha en la que se realiza, la fecha tope para devolver (que son 15 días más que la fecha en la que se realiza el préstamo) y la fecha real en la que se devuelve el libro.

[[Imatge:uf1nf2_sol_biblioteca_v1.png |700px|center| Solució Biblioteca v1]]

==Academia==

Diseñad un esquema E/R para gestionar los datos de una academia:

:*Se dan clases a trabajadores y desempleados. Los datos que se almacenan de los alumnos son el DNI, dirección, nombre, teléfono, edad y estudios.
:*Además de los que trabajan necesitamos saber el CIF, nombre, teléfono, dirección de la empresa en la que trabajan, el cargo que tienen y los años que llevan en la misma. De los desempleados el tiempo que llevan desempleados y el último trabajo que desempeñaron.
:*Los cursos que imparte la academia se identifican con un código de curso. Además se almacena el nombre, programa,las horas de duración del curso, y cada vez que se imparte se anotará las fechas de inicio y fin del curso junto con un número concreto de curso (distinto del código) y los datos del profesor o profesora (sólo uno por curso) que son: dni, nombre, dirección, teléfono y especialidad.
:*Se almacena la nota obtenida por cada alumno en cada curso teniendo en cuenta que un mismo alumno o alumna puede realizar varios cursos.


==Perrera municipal==

Tenemos una perrera municipal que, además de acoger perros sin dueño, acoge a perros con dueño. Se ha de diseñar un esquema E/R teniendo en cuenta que:

:*Un perro puede ser de una raza dterminada o no. A los perros se les asigna una identificación propia de la perrera y debemos conocer su sexo, la data d'entrada en la perrera y en que estado se encuentra. De las razas nos interesa la altura, la medida, el caracter y la esperanza de vida.

:*Un perro puede tener dueño o no. De los dueños nos interesa sus datos personales: DNI, nombre, apellidos y teléfono.

:*Una persona puede tener más de un perro.

:*Un perro se encuentra albergado en una jaula determinada. Las jaulas se identifican por código interno de la perrera y precisamos conocer la capacidad de cada jaula.

:*En las jaulas pueden haber n perros.

[[Imatge:uf1nf2_sol_perrera.png |700px|center| Solució Perrera]]


==Alquiler automóviles==

Se desea diseñar una base de datos sobre la información de las reservas de una empresa dedicada al alquiler de automóviles. Los supuestos son los siguientes:

:*Un determinado cliente puede tener en un momento dado varias reservas

:*De cada cliente se desea almacenar su DNI, nombre, dirección y teléfono.

:*Una reserva la realiza un único cliente, pero puede involucrar a varios coches.

:*Es importante registrar la fecha de comienzo de la reserva y la de terminación.

:*Todo coche tiene siempre asignado un determinado garaje, que no puede cambiar. Del coche, interesa su matrícula, marca, modelo i color. Del garaje su dirección i metros cuadrados. Las diferentes plazas de cada garaje se asignan a los coches en función de la ocupación del mismo.

:*Cada reserva se realiza en una agencia determinada y la codificación de las mismas es propia de cada agencia. De estas, se quire tener constancia de su dirección y teléfono.

:*En la base de datos pueden existir clientes que no hayan hecho ninguna reserva.

:*Las entidades cliente, coche, agencia y garaje tienen una clave alfanumérica que las identifica unívocamente.

:*Interesa conocer los km de inicio y km finales que ha realizado cada coche en cada reserva.

:*Cada cliente puede ser avalado por otro cliente de la empresa.

[[Imatge:uf1nf2_sol_alquiler_coches.png |800px|center| Solució Alquiler coches]]


==Empresa de comidas==

Diseñad un esquema E/R par un empresa de comidas, teniendo en cuenta que:

:*El nombre y apellidos de cada empleado, su dni y su número de SS además del teléfono fijo y el móvil
:*Algunos empleados/as son cocineros/as. De los cocineros y cocineras anotamos (además de los datos propios de cada empleado) sus años de servicio en la empresa.
:*Hay empleados/as que son pinches. De los y las pinches anotamos su fecha de nacimiento.
:*La mayoría de trabajadores no son ni pinches ni cocineros/as
:*En la base de datos figura cada plato (su nombre como “pollo a la carloteña”, “bacalo al pil-pil”,…), el precio del plato junto con los ingredientes que lleva. Anotamos también si cada plato es un entrante, un primer plato, segundo plato o postre
:*De los ingredientes necesitamos la cantidad que necesitamos de él en cada plato y en qué almacén y estantería del mismo le tenemos.
:*Cada almacén se tiene un nombre (despensa principal, cámara frigorífica A, cámara frigorífica B…), un número de almacén y una descripción del mismo.
:*Cada estante en el almacén se identifica con dos letras y un tamaño en centímetros. Dos almacenes distintos pueden tener dos estantes con las mismas letras.
:*Necesitamos también saber qué cocineros son capaces de preparar cada plato.
:*Cada pinche está a cargo de un cocinero o cocinera.
:*La cantidad de ingredientes en cada estantería de un almacén se actualiza en la base de datos al instante. SI cogemos dos ajos de un estante, figurará al instante que tenemos dos ajos menos en ese estante. Es necesario por lo tanto saber los ingredientes (cuáles y en qué número) que tenemos en cada estante.



==líneas de metro==

Construir el esquema conceptual en el modelo E/R que refleje toda la información necesaria para la gestión de las líneas de metro de una determinada ciudad. Los supuestos considerados son:

Cada línea de metro está compuesta de un conjunto de estaciones en un orden determinado. Es importante recoger la información del orden de cada estación en la línea (cuál es la 1a estación de la línea, la 2a, ...). En cada estación interesa almacenar, para cada línea, el número estimado de segundos que se tarda en llegar desde la estación anterior de la línea y los que se tarda en alcanzar la siguiente estación de la línea.

Cada línea tiene un identificador numérico (línea 1, línea 2, ...) y otro mediante un color (la línea azul, la línea roja, ...). Esto quiere decir que no hay dos líneas con el mismo número ni dos con el mismo color. También se quiere almacenar la hora de salida del primer tren de la línea y la del último.

Las estaciones tienen un código numérico que las distingue de las demás. También tienen un nombre diferente para cada una. Se guardan los horarios de apertura y cierre de cada estación. Una estación pertenece al menos a una línea, aunque puede pertenecer a varias líneas.

Cada estación tiene uno o varios accesos desde el exterior. Cada uno de dichos accesos pertenece a una única estación. Los accesos de una misma estación están numerados de forma correlativa (el primer acceso de la estación 7, el segundo acceso de la estación 7, ...). Por cada acceso se guarda la calle y número de portal más cercano a donde está situado.

Cada tren tiene un número diferente al del resto de trenes. Se necesita guardar la fecha de compra, el modelo y la capacidad en número de vagones.

Se guardan los trenes que están o han estado en servicio y qué línea. Un tren puede prestar o haber prestado servicio en varias líneas diferentes. Incluso puede haber prestado diferentes servicios en la misma línea (en periodos de tiempo diferentes). Se guarda la fecha de inicio del servicio del tren en la línea y la de finalización. No puede haber dos servicios diferentes del mismo tren en la misma línea y en periodos que se solapen.

En algunas estaciones hay cocheras para aparcar los trenes cuando no están de servicio. Cada tren tiene asignada una de estas cocheras. Se puede cambiar la cochera asignada a un tren, pero no se puede quedar sin ninguna asignada. Cada cochera se distingue de las demás por la estación donde está situada (en una misma estación sólo puede haber una cochera). Además se almacena el número de trenes (máquinas) y el de vagones que puede alojar.

Cada llegada de un tren a un andén es almacenada y se le asigna un número diferente para cada una. Se almacena a qué estación y línea corresponde la llegada y en qué sentido de la marcha (ascendente según el número de orden de la estación en la línea o descendente). También se guarda el tren que ha llegado y el número de llegada que corresponde al tren. Este último número se asigna así: la primera llegada a un andén de este tren se numeró con un uno, la segunda con un dos, etc. Teniendo esto en cuenta, no puede haber dos llegadas que contengan el mismo par (tren, número de llegada). Además se guarda la fecha y hora de
llegada del tren al andén y la fecha y hora de salida.



==Libreria OnLine==

Un cliente le ha contratado para diseñar una web que permita comprar libros por Internet. Tenga en cuenta las siguientes indicaciones para modelar cómo sería la base de datos del proyecto:

:*De cada libro guardaremos su título, isbn, año de publicación y descripción. También es interesante almacenar los datos del autor/es y de la editorial que ha publicado el libro.

:*Los libros que se podrán comprar en la web pueden ser libros de papel o libros electrónicos (ebooks). En el caso de los libros de papel interesa guardar donde ha sido impreso y la fecha de impresión. En el caso de un ebook guardaremos el tamaño del archivo. Hay que tener en cuenta que un mismo libro tiene precios diferentes en papel y en formato ebook.

:*De los autores nos interesa almacenar el nombre, apellidos, dirección, localidad, provincia, url de su página web y un identificador único de autor.

:*Para las editoriales guardaremos un identificador, nombre, dirección, localidad, provincia, número de teléfono y la url de su página web.

:*La tienda dispondrá de varios almacenes, de cada uno guardaremos un identificador, una dirección, localidad, provincia y un teléfono de contacto.

:*Un almacén puede almacenar diferentes libros. Un mismo libro puede estar almacenado en diferentes almacenes. Nos interesa saber el número de copias de cada libro que hay en cada almacén.

:*La base de datos debe almacenar los datos de los clientes. De cada cliente guardamos su NIF, nombre, apellidos, dirección, localidad, provincia, email y teléfono.

:*Un cliente puede tener varias cestas de la compra en el sitio web. Cada cesta de la compra está identificada por un identificador único, contiene la fecha de la compra y puede contener varios libros. Algunas cestas de la compra pueden tener más de una copia del mismo libro, por lo que será necesario almacenar la cantidad de copias que se han comprado de cada libro en cada cesta de la compra.

:*Por motivos estadísticos interesa conocer el número de habitantes de cada localidad y la densidad (hab./km2) de las provincias, ambas se identificaran por un código.




==Spots==

Se propone diseñar una Base de Datos para mejorar el control de los anuncios publicitarios para la televisión, y de todo su entorno, como los canales de TV, franjas horarias, agencias de publicidad, tipos de productos que se anuncian, etc.

En el país hay diversas entidades de televisión. Se quiere reflejar que unas son de titularidad pública, por ejemplo CCRTV (Corporació Catalana de Ràdio i Televisió), RTVE (Radiotelevisión Española), etc. Y otras que son de titularidad privada. Todas estas entidades disponen de uno o más canales de emisión (por ejemplo, CCRTV dispone de TV3 y del Canal 33, RTVE dispone de TV1 y TV2, etc.) que se identifican siempre por un nombre.

Todos los anuncios suponemos que se identifican por un código asignado por una supuesta “Oficina de Medios de Comunicación”. Debe considerarse la existencia de los anuncios que llamaremos equivalentes, como podrían ser aquellos que, con las mismas imágenes tienen diferente idioma, o por otras causas que no interesa precisar.

Cada anuncio hace referencia a uno (lo más habitual) o más (excepcionalmente) tipos de producto (por ejemplo, lavadoras y detergentes), y se quiere tener constancia de estas referencias. Incluso debe pensarse que hay tipificados ciertos tipos de productos independientemente de que hayan o no, en este momento, anuncios que se refieran a ellos. Los anuncios son siempre propiedad de una única firma comercial, que es la que las paga, incluso en el caso de anunciar más de un tipo de producto. Los anuncios son filmados, normalmente, por una agencia de publicidad aunque, en algunos casos, es la misma firma comercial que, con medios propios, los produce sin intervención de ninguna agencia publicitaria.

De las agencias de publicidad interesa conocer el nombre del director artístico. De las firmas comerciales interesa conocer el nombre del jefe de marketing. Pero de unas y otras, que podríamos considerar bajo una nueva entidad que denominaremos empresas, interesa conocer el CIF (código de identificación fiscal), nombre, dirección y teléfono.

Las agencias de publicidad disponen de directores cinematográficos para filmar los anuncios. Interesa conocer el historial de la contratación por parte de las diferentes agencias de estos directores. Un director trabaja, en un momento dado, para una sola agencia. Las agencias quieren conocer de cada anuncio que director lo ha dirigido. De los anuncios producidos directamente por las firmas comerciales, no interesa ni se quiere tener constancia de su director.

Tal como se ha indicado al principio, interesa también conocer la emisión de los anuncios en los diversos canales televisivos. A efectos de audiencia, las 24 horas del día no se entienden como tales horas, sino como “franjas horarias” (como puede ser: mañana, mediodía, tarde, noche…) perfectamente diferenciados. Es más, el precio vigente (único que interesa) de la emisión en cada canal, depende de la franja horaria. Para simplificar el caso, haremos la hipótesis de que el precio no depende del día de la semana. Se quiere tener constancia del número de veces que cada anuncio se ha emitido en los diferentes canales, su fecha de emisión y su correspondiente franja horaria.

Finalmente, hay un aspecto legal muy importante a considerar. Existen algunos tipos de productos (menos de los necesarios) que no están permitidos anunciar en ciertas franjas horarias. El incumplimiento será penalizado con multas de gravedad de 1 a 3. Interesará tener constancia de las prohibiciones legales anteriores.

Se pide diseñar la base de datos con el modelo relacional, establecer el grado y cardinalidad de cada relación. También se deben explicar las entidades, relaciones, cardinalidades y atributos.

==La Facultad==

Se ha de diseñar una base de datos para gestionar la docencia de un curso académico en una Facultad universitaria (curiosamente bastante parecida a la FIB), para controlar cuestiones como notas, horarios, matriculaciones, profesores, alumnos, etc.

La Facultad la supondremos estructurada en Departamentos. Cada uno de estos departamentos imparten la docencia de varias asignaturas. No se da el caso de que una misma asignatura sea impartida por más de un departamento.

De las asignaturas interesa saber las siglas, nombre, créditos, nivel, etc. También se desea tener constancia de que asignaturas son pre-requisitos de otras.

Cada asignatura tiene uno o más grupos (por ejemplo: grupos 10, 20, 30 y 40 de las asignatura DUABD; grupos 10, 20 y 30 de la asignatura DT, etc.). De cada grupo interesa saber las aulas y horarios correspondientes al curso actual (entendiendo el horario por el día de la semana y el horario de inicio). Se ha de tener en cuenta que un mismo grupo puede darse en aulas diferentes siempre que sea en horario diferente. De las aulas se desea conocer cual es su capacidad.

De los profesores interesa saber la categoría laboral y su dedicación (a tiempo parcial, o a tiempo completo). Y de los alumnos interesa conocer el número de matrícula y el año de ingreso a la Facultad. Tanto de los profesores como de los alumnos, que podríamos considerarlos como una entidad general que se podría denominar “personas”; interesa el DNI, nombre, apellido, dirección, teléfono, etc.

Todos los profesores están adscritos a uno y sólo un departamento. En general están encargado de uno o más grupos, pero es posible que haya profesores que no tengan asignado ningún grupo (en el curso actual), y se dediquen a tareas de búsqueda o tareas administrativas. También es posible que un grupo tenga más de un profesor encargado, es decir, que cada profesor se responsabiliza de una parte de la asignatura. Se desea tener constancia de todos los hechos anteriormente esmentados e incluso de la parte de la que se encarga o se responsabiliza cada profesor.

Al iniciar el curso, los alumnos se matriculan en varios grupos y naturalmente se desea tener información de este hecho. La base de datos debería guardar información de las notas que los alumnos han obtenido en las diferentes convocatorias de examen (febrero, junio y septiembre) de cada asignatura.

La biblioteca de esta Facultad dispone de una gran cantidad de textos (libros, revistas, apuntes, etc.). Estos textos se identifican por un código que asigna la propia biblioteca. En los diferentes grupos de cada asignatura se recomienda uno o más textos, teniendo en cuenta un orden de preferencia o prioridad. A menudo se da el caso de que un mismo texto se recomiende a más de un grupo (especialmente si son grupos de una misma asignatura). Se desea almacenar qué textos se recomienda y cual es su prioridad en cada uno de los grupos.

Como ya se deduce de los párrafos anteriores, sólo se desea almacenar la información del curso actual y no la información de cursos anteriores.
-->

M2 - Bases de dades / UF1NF3: Solucions Model relacional casos pràctics

2026-04-20T18:08:41Z

Rsort: /* Alquiler automóviles */

==Biblioteca v1==

L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional.

Donat el model ER següent, feu-ne la traducció al model relacional:

[[Imatge:uf1nf2_sol_biblioteca_v1.png |700px|center| Solució Biblioteca v1]]

AUTOR ('''''Id_autor''''', Nom, Any_neix, Nacionalitat)

SOCI ('''''Codi''''', DNI, Nom, Cognoms, Telefon)

LLIBRE ('''''ISBN''''', Titol, Editorial, Any)

EXEMPLAR ('''''ISBN, Num_ex''''', Estat) ON {ISBN} REFERENCIA LLIBRE

ESCRIURE ('''''Id_autor, ISBN''''') ON {Id_autor} REFERENCIA AUTOR I {ISBN} REFERENCIA LLIBRE

RESERVAR ('''''Codi_soci, ISBN, Num_ex''''', Data_reserva, Data_real, Data_tornar) ON {Codi_soci} REFERENCIA SOCI I {ISBN, Num_ex} REFERENCIA EXEMPLAR



==Academia==

L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional.

Donat el model ER següent, feu-ne la traducció al model relacional:

[[Imatge:uf1nf2_sol_academia.png |700px|center| Solució Academia]]

1. Mantenint supertipus i subtipus.

PERSONA ('''''DNI''''', Nom, Adreça, Telefon)

ALUMNE ('''''DNI''''', Anys, Estudis) ON {DNI} REFERENCIA PERSONA

PROFESSOR ('''''DNI''''', Especialitat) ON {DNI} REFERENCIA PERSONA

EMPLEAT ('''''DNI''''', Anys_emp, Carreg, CIF_empresa) ON {DNI} REFERENCIA ALUMNE i {CIF_empresa} REFERENCIA EMPRESA

DESEMPLEAT ('''''DNI''''', Anys_desemp, Darrera_feina) ON {DNI} REFERENCIA ALUMNE

EMPRESA ('''''CIF''''', Nom, Telefon, Adreça)

TIPUS_CURS ('''''Codi_curs''''', Nom, Programa, Hores)

CURS ('''''Id_curs''''', Data_inici, Data_final, Codi_curs, DNI_professor) ON {Codi_curs} REFERENCIA TIPUS_CURS i {DNI_professor} REFERENCIA PROFESSOR

CURSAR ('''''Id_curs, DNI_alumne''''', Nota) ON {Id_curs} REFERENCIA CURS i {DNI_alumne} REFERENCIA ALUMNE

2. Eliminant els subtipus empleat i desempleat.

Tot igual, amb els següents canvis:
- eliminem les relacions empleat i desempleat
- i:

ALUMNE ('''''DNI''''', Anys, Estudis, Anys_emp, Carreg, Anys_desemp, Darrera_feina, Tipus_alumne, CIF_empresa) ON {DNI} REFERENCIA PERSONA i {CIF_empresa} REFERENCIA EMPRESA



==Perrera municipal==

L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional.

Donat el model ER següent, feu-ne la traducció al model relacional:

[[Imatge:uf1nf2_sol_perrera.png |700px|center| Solució Perrera]]


==Alquiler automóviles==

L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional.

Donat el model ER següent, feu-ne la traducció al model relacional:

[[Imatge:uf1nf2_sol_alquiler_coches.png |800px|center| Solució Alquiler coches]]

CLIENT ('''''DNI''''', Nom, Cognoms, Telefon, DNI_avalador) ON {DNI_avalador} REFERENCIA CLIENT ADMET VALORS NULS

AGENCIA ('''''Id_agencia''''', Adreça, Telefon)

COTXE ('''''Matricula''''', Marca, Modelo, Color, Id_garatge) ON {Id_garatge} REFERENCIA GARATGE

GARATGE ('''''Id_garatge''''', Adreça, Metres_quadrats)

RESERVA ('''''Id_agencia, Num_reserva'''', Data_ini, Data_fin, DNI_CLI) ON {DNI_CLI} REFERENCIA CLIENT I {Id_agencia} REFERENCIA AGENCIA

COTXES_RESERVA ('''''Id_agencia, Num_reserva, Matricula''''', Km_ini, Km_fin) ON {Id_agencia, Num_reserva} REFERENCIA RESERVA I {Matricula} REFERENCIA COTXE

SENSE ADMETRE VALORS NULS



==Empresa de comidas==

L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional.

Donat el model ER següent, feu-ne la traducció al model relacional:

[[Imatge:uf1nf2_sol_empresa_comidas.png |800px|center| Solució Empresa comidas]]



==Spots==

L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional.

Donat el model ER següent, feu-ne la traducció al model relacional:

[[Imatge:uf1nf2_sol_spots.png |700px|center| Solució Spots]]

2026-03-16T16:52:20Z

Rsort: /* AEA4: Model relacional */

==AEA1: Llenguatge de consulta SQL==



===Continguts===

:*[http://www.w3schools.com/sql/default.asp Tutorial SQL]

:*[[M2 - Bases de dades / Continguts UF2: Ampliacio SQL |Ampliació SQL]]

:*[https://www.youtube.com/watch?v=64eIJ9ZPhhw Optimització de consultes]

===Activitats===

:*[[M2 - Bases de dades / Exercicis UF2 BD HR: Llenguatges SQL |Exercicis SELECT BD HR]]


:*[[M2 - Bases de dades / Solucions UF2 BD HR: Llenguatges SQL |Solucions Exercicis SELECT BD HR]]

:*[[M2 - Bases de dades / Practiques UF2: Llenguatges SQL |Pràctiques]]


:*[[M2 - Bases de dades / Exercicis UF2: Llenguatges SQL |Exercicis BD SCOTT]]







==AEA2: Llenguatges SQL: DDL, DML i DCL==

===Continguts DCL===

El material per a elaborar aquests apunts s'ha obtingut de [http://epnbdd-oracle.blogspot.com.es/ epnbdd]

:*[[M2 - Bases de dades / Continguts UF3: Diccionari de dades |El Diccionari de dades]]

:*[[M2 - Bases de dades / Continguts RA2: Administració bàsica i seguretat |Administració bàsica i seguretat]]

'''Per si voleu aprendre més sobre DCL:'''

:*[[M2 - Bases de dades / Continguts UF3: Emmagatzemament |Conceptes d'emmagatzemament]]

:*[[M2 - Bases de dades / Continguts UF3: Components de les BD |Components de les bases de dades]]

:*[[M2 - Bases de dades / Continguts UF3: Privilegis i usuaris |Privilegis i usuaris]]

:*[[M2 - Bases de dades / Continguts UF3: Administració d'usuaris |Administració d'usuaris]]

:*[[M2 - Bases de dades / Continguts UF3: Administració bàsica i seguretat |Administració bàsica i seguretat]]

:*[[M2 - Bases de dades / Continguts UF3: Perfils |Gestió de perfils]]

:*[[M2 - Bases de dades / Apunts UF3: DCL |Enllaços]]


===Activitats===

:*[[M2 - Bases de dades / Exercicis DDL-DML-DCL BD HR: Llenguatges SQL |Exercicis DCL, DDL i DML BD HR]]


:*[[M2 - Bases de dades / Solucions UF2 BD HR: Llenguatges SQL: DDL, DML i DCL |Solucions Exercicis DDL, DML i DCL BD HR]]

:*[[M2 - Bases de dades / Exercicis UF2: Exercici Resum |Exercici Resum DDL-DML]]

:*[[M2 - Bases de dades / Exercicis UF2: Solucio Exercici Resum |Solució exercici resum DDL-DML]]

==AEA3: Llenguatge SQL: extensió procedimental==

===Continguts===

:*[[M2 - Bases de dades / Apunts UF3: PL-SQL |Apunts PL/SQL]]

===Activitats===

:*[[M2 - Bases de dades / Exercicis UF3: PL-SQL |Exercicis PL/SQL: Conceptes fonamentals]]

:*[[M2 - Bases de dades / Exercicis conceptes fundamentals UF3: PL-SQL |Exercicis repàs PL/SQL]]

:*[[M2 - Bases de dades / Exercicis UF3: PL-SQL-2 |Exercicis PL/SQL: Desenvolupament d'unitats de programa]]

:*[[M2 - Bases de dades / Exercicis consolidació UF3: PL-SQL |Exercicis consolidació PL/SQL]]


==AEA4: Model relacional==

===Continguts===

====Bases de dades i Sistemes gestors de bases de dades====

:*[[M2 - Bases de dades / UF1NF1: Mapa conceptual |Mapa conceptual]]
:*[[M2 - Bases de dades / UF1NF1: Big Data i Intel·ligència de negocis |Big Data i Intel·ligència de negocis]]

====LOPD==== 







====Model lògic relacional====

:*[[M2 - Bases de dades / UF1NF2: Disseny de bases de dades |Disseny de bases de dades]]

:*[[M2 - Bases de dades / UF1NF2: Conceptes del model entitat-relació |Conceptes del model entitat-relació]]

:*[[M2 - Bases de dades / UF1NF2: Diagrames entitat-relació |Exemples diagrames entitat-relació]]

:*[[M2 - Bases de dades / UF1NF2: Annex: Decisions de disseny |Annex: Decisions de disseny]]

:*[[M2 - Bases de dades / UF1NF3: Model relacional |Model relacional]] / [[M2 - Bases de dades / UF1NF3: Resum model relacional | Resum model relacional]]

:*[[M2 - Bases de dades / UF1NF3: Normalització |Normalització]]

===Activitats===

:*[[M2 - Bases de dades / UF1NF2: Exercicis Model E/R |Exercicis Model E/R]]









==AEA5: Bases de dades no relacionals==




==Crear user en ORACLE 21.c==
<pre>
ALTER SESSION SET "_ORACLE_SCRIPT"=true;
CREATE USER iduser IDENTIFIED BY passuser
DEFAULT TABLESPACE USERS
TEMPORARY TABLESPACE TEMP
QUOTA 10M ON USERS;
GRANT CONNECT TO iduser;
GRANT resource TO iduser;
GRANT CREATE VIEW TO iduser;
</pre>

M2 - Bases de dades

2026-03-16T16:40:08Z

Rsort: /* Activitats */

==AEA1: Llenguatge de consulta SQL==



===Continguts===

:*[http://www.w3schools.com/sql/default.asp Tutorial SQL]

:*[[M2 - Bases de dades / Continguts UF2: Ampliacio SQL |Ampliació SQL]]

:*[https://www.youtube.com/watch?v=64eIJ9ZPhhw Optimització de consultes]

===Activitats===

:*[[M2 - Bases de dades / Exercicis UF2 BD HR: Llenguatges SQL |Exercicis SELECT BD HR]]


:*[[M2 - Bases de dades / Solucions UF2 BD HR: Llenguatges SQL |Solucions Exercicis SELECT BD HR]]

:*[[M2 - Bases de dades / Practiques UF2: Llenguatges SQL |Pràctiques]]


:*[[M2 - Bases de dades / Exercicis UF2: Llenguatges SQL |Exercicis BD SCOTT]]







==AEA2: Llenguatges SQL: DDL, DML i DCL==

===Continguts DCL===

El material per a elaborar aquests apunts s'ha obtingut de [http://epnbdd-oracle.blogspot.com.es/ epnbdd]

:*[[M2 - Bases de dades / Continguts UF3: Diccionari de dades |El Diccionari de dades]]

:*[[M2 - Bases de dades / Continguts RA2: Administració bàsica i seguretat |Administració bàsica i seguretat]]

'''Per si voleu aprendre més sobre DCL:'''

:*[[M2 - Bases de dades / Continguts UF3: Emmagatzemament |Conceptes d'emmagatzemament]]

:*[[M2 - Bases de dades / Continguts UF3: Components de les BD |Components de les bases de dades]]

:*[[M2 - Bases de dades / Continguts UF3: Privilegis i usuaris |Privilegis i usuaris]]

:*[[M2 - Bases de dades / Continguts UF3: Administració d'usuaris |Administració d'usuaris]]

:*[[M2 - Bases de dades / Continguts UF3: Administració bàsica i seguretat |Administració bàsica i seguretat]]

:*[[M2 - Bases de dades / Continguts UF3: Perfils |Gestió de perfils]]

:*[[M2 - Bases de dades / Apunts UF3: DCL |Enllaços]]


===Activitats===

:*[[M2 - Bases de dades / Exercicis DDL-DML-DCL BD HR: Llenguatges SQL |Exercicis DCL, DDL i DML BD HR]]


:*[[M2 - Bases de dades / Solucions UF2 BD HR: Llenguatges SQL: DDL, DML i DCL |Solucions Exercicis DDL, DML i DCL BD HR]]

:*[[M2 - Bases de dades / Exercicis UF2: Exercici Resum |Exercici Resum DDL-DML]]

:*[[M2 - Bases de dades / Exercicis UF2: Solucio Exercici Resum |Solució exercici resum DDL-DML]]

==AEA3: Llenguatge SQL: extensió procedimental==

===Continguts===

:*[[M2 - Bases de dades / Apunts UF3: PL-SQL |Apunts PL/SQL]]

===Activitats===

:*[[M2 - Bases de dades / Exercicis UF3: PL-SQL |Exercicis PL/SQL: Conceptes fonamentals]]

:*[[M2 - Bases de dades / Exercicis conceptes fundamentals UF3: PL-SQL |Exercicis repàs PL/SQL]]

:*[[M2 - Bases de dades / Exercicis UF3: PL-SQL-2 |Exercicis PL/SQL: Desenvolupament d'unitats de programa]]

:*[[M2 - Bases de dades / Exercicis consolidació UF3: PL-SQL |Exercicis consolidació PL/SQL]]


==AEA4: Model relacional==








====Model lògic relacional====

:*[[M2 - Bases de dades / UF1NF2: Disseny de bases de dades |Disseny de bases de dades]]

:*[[M2 - Bases de dades / UF1NF2: Conceptes del model entitat-relació |Conceptes del model entitat-relació]]

:*[[M2 - Bases de dades / UF1NF2: Diagrames entitat-relació |Exemples diagrames entitat-relació]]

:*[[M2 - Bases de dades / UF1NF2: Annex: Decisions de disseny |Annex: Decisions de disseny]]

:*[[M2 - Bases de dades / UF1NF3: Model relacional |Model relacional]] / [[M2 - Bases de dades / UF1NF3: Resum model relacional | Resum model relacional]]

:*[[M2 - Bases de dades / UF1NF3: Normalització |Normalització]]

===Activitats===

:*[[M2 - Bases de dades / UF1NF2: Exercicis Model E/R |Exercicis Model E/R]]









==AEA5: Bases de dades no relacionals==




==Crear user en ORACLE 21.c==
<pre>
ALTER SESSION SET "_ORACLE_SCRIPT"=true;
CREATE USER iduser IDENTIFIED BY passuser
DEFAULT TABLESPACE USERS
TEMPORARY TABLESPACE TEMP
QUOTA 10M ON USERS;
GRANT CONNECT TO iduser;
GRANT resource TO iduser;
GRANT CREATE VIEW TO iduser;
</pre>