|
|
| (147 revisions intermèdies per 3 usuaris que no es mostren) |
| Línia 1: |
Línia 1: |
| | + | <!-- |
| | ==Gabinete abogados== | | ==Gabinete abogados== |
| | | | |
| Línia 6: |
Línia 7: |
| | | | |
| | [[Imatge:uf1nf2_sol_gabinete_abogados.png |700px|center| Solució Gabinete abogados]] | | [[Imatge:uf1nf2_sol_gabinete_abogados.png |700px|center| Solució Gabinete abogados]] |
| − | <!--
| + | |
| − | -->
| + | CLIENT ('''''DNI''''', Nom, Cognoms, Telefon) |
| | + | |
| | + | ASSUMPTE ('''''Num_exp''''', Data_ini, Data_fin, Estat, DNI) ON {DNI} REFERENCIA CLIENT |
| | + | |
| | + | PROCURADOR ('''''DNI''''', Nom, Cognom, Adreça, Telefon) |
| | + | |
| | + | PORTAR ('''''DNI, Num_exp''''') ON {DNI} REFERENCIA PROCURADOR I {Num_exp} REFERENCIA ASSUMPTE |
| | + | |
| | | | |
| | ==Zoo== | | ==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.
| + | 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_zoo.png |700px|center| Solució Zoo]] | | [[Imatge:uf1nf2_sol_zoo.png |700px|center| Solució Zoo]] |
| − | <!--
| + | |
| − | -->
| + | ZOO ('''''Nom''''', Ciutat, Pais, Tamany, Presupost) |
| | + | |
| | + | ANIMAL ('''''Nom_zoo, Num_ident''''', Sexe, Any_neix, Pais, Continent, Nom_vulgar) ON {Nom_zoo} REFERENCIA ZOO I {Nom_vulgar} REFERENCIA ESPECIE |
| | + | |
| | + | ESPECIE ('''''Nom_vulgar''''', Nom_cientific, Familia, Perill_extincio) |
| | + | |
| | + | |
| | ==Club náutico== | | ==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).
| + | 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_club_nautic.png |500px|center| Solució Club náutic]] | | [[Imatge:uf1nf2_sol_club_nautic.png |500px|center| Solució Club náutic]] |
| − | <!--
| + | |
| − | -->
| + | 1. Mantenint supertipus i subtipus |
| | + | |
| | + | PERSONA ('''''DNI''''', Nom, Cognoms, Telefon) |
| | + | |
| | + | SOCI ('''''DNI''''', Data_alta) |
| | + | |
| | + | PATRO ('''''DNI''''', Any_titulacio, Categoria) |
| | + | |
| | + | VAIXELL ('''''Num_matric''''', Nom, Num_amarre, Quota, DNI_soci) ON {DNI_soci} REFERENCIA SOCI |
| | + | |
| | + | SORTIDA ('''''Num_matric, Data, Hora''''', Desti, DNI_patro) ON {Num_matric} REFERENCIA VAIXELL I {DNI_Patro} REFERENCIA PATRO |
| | + | |
| | + | 2. Eliminant subtipus |
| | + | |
| | + | Eliminem SOCI i PATRO. |
| | + | |
| | + | PERSONA ('''''DNI''''', Nom, Cognoms, Telefon, Data_alta_soci, Any_titulacio_patro, Categoria_patro, Tipus) |
| | + | |
| | + | VAIXELL ('''''Num_matric''''', Nom, Num_amarre, Quota, DNI_soci) ON {DNI_soci} REFERENCIA PERSONA |
| | + | |
| | + | SORTIDA ('''''Num_matric, Data, Hora''''', Desti, DNI_patro) ON {Num_matric} REFERENCIA VAIXELL I {DNI_Patro} REFERENCIA PERSONA |
| | + | |
| | + | 3. Eliminant supertipus |
| | + | |
| | + | Eliminem PERSONA i passem els seus atributs a SOCI i PATRO. La resta queda igual. |
| | + | |
| | + | SOCI ('''''DNI''''', Nom, Cognoms, Telefon, Data_alta) |
| | + | |
| | + | PATRO ('''''DNI''''', Nom, Cognoms, Telefon, Any_titulacio, Categoria) |
| | + | |
| | + | |
| | ==Departamentos de una empresa== | | ==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.
| + | 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_departaments_empresa.png |350px|center| Solució Departaments empresa]] | | [[Imatge:uf1nf2_sol_departaments_empresa.png |350px|center| Solució Departaments empresa]] |
| − | <!--
| + | |
| − | -->
| + | DEPARTAMENT ('''''Id_dept''''', Nom, Ubicacio) |
| | + | |
| | + | EMPLEAT ('''''DNI''''', Nom, Cognoms, Telefon, Id_dept, DNI_Director) ON {Id_dept} REFERENCIA DEPARTAMENT I {DNI_Director} REFERENCIA EMPLEAT |
| | + | |
| | + | |
| | ==Biblioteca v1== | | ==Biblioteca v1== |
| | | | |
| − | Diseñad un esquema E/R para gestionar los datos de una biblioteca:
| + | L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional. |
| | | | |
| − | :*Las personas socias de la biblioteca disponen de un código de socio y se precisa su dni, teléfono, nombre y apellidos.
| + | Donat el model ER següent, feu-ne la traducció al model relacional: |
| − | :*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]] | | [[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== | | ==Academia== |
| | | | |
| − | Diseñad un esquema E/R para gestionar los datos de una academia:
| + | L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional. |
| | | | |
| − | :*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.
| + | Donat el model ER següent, feu-ne la traducció al model relacional: |
| − | :*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.
| |
| | | | |
| | [[Imatge:uf1nf2_sol_academia.png |700px|center| Solució Academia]] | | [[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 ('''''Codi_curs, Id_curs''''', Data_inici, Data_final, DNI_professor) ON {Codi_curs} REFERENCIA TIPUS_CURS i {DNI_professor} REFERENCIA PROFESSOR |
| | + | |
| | + | CURSAR ('''''Codi_curs, Id_curs, DNI_alumne''''', Nota) ON {Codi_curs, 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== | | ==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:
| + | L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional. |
| | | | |
| − | :*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.
| + | Donat el model ER següent, feu-ne la traducció al model relacional: |
| | | | |
| − | :*Un perro puede tener dueño o no. De los dueños nos interesa sus datos personales: DNI, nombre, apellidos y teléfono. | + | [[Imatge:uf1nf2_sol_perrera.png |700px|center| Solució Perrera]] |
| | | | |
| − | :*Una persona puede tener más de un perro.
| + | 1. Admeten valors nuls en les claus foranes |
| | | | |
| − | :*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.
| + | PERSONA ('''''DNI''''', Nom, Cognoms, Telefon) |
| | | | |
| − | :*En las jaulas pueden haber n perros.
| + | GABIA ('''''Id_gabia''''', Capacitat) |
| | + | |
| | + | GOS ('''''Id_gos''''', Sexe, Data_entrada, Estat, DNI, Id_gabia, Raça) ON {DNI} REFERENCIA PERSONA, {Id_gabia} REFERENCIA GABIA i {Raça} REFERENCIA RAÇA |
| | + | |
| | + | RAÇA ('''''Raça''''', Alçada, Mida, Caracter, Esperança_vida) |
| | + | |
| | + | |
| | + | 2. Sense admetre valors nuls en les claus foranes |
| | + | |
| | + | PERSONA ('''''DNI''''', Nom, Cognoms, Telefon) |
| | + | |
| | + | GABIA ('''''Id_gabia''''', Capacitat) |
| | + | |
| | + | GOS ('''''Id_gos''''', Sexe, Data_entrada, Estat, DNI, Id_gabia) ON {DNI} REFERENCIA PERSONA, {Id_gabia} REFERENCIA GABIA i {Raça} REFERENCIA RAÇA |
| | + | |
| | + | RAÇA ('''''Raça''''', Alçada, Mida, Caracter, Esperança_vida) |
| | + | |
| | + | RAÇA_GOS ('''''Id_gos''''', Raça) ON {Id_gos} REFERENCIA GOS I {Raça} REFERENCIA RAÇA |
| | + | |
| | + | PROPIETAT_GOS ('''''Id_gos''''', DNI) ON {Id_gos} REFERENCIA GOS I {DNI} REFERENCIA PERSONA |
| | | | |
| − | [[Imatge:uf1nf2_sol_perrera.png |700px|center| Solució Perrera]]
| |
| − | <!--
| |
| | --> | | --> |
| | + | ==Alquiler automóviles== |
| | | | |
| − | ==Alquiler automóviles==
| + | L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional. |
| | | | |
| − | 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:
| + | Donat el model ER següent, feu-ne la traducció al model relacional: |
| | | | |
| − | :*Un determinado cliente puede tener en un momento dado varias reservas | + | [[Imatge:uf1nf2_sol_alquiler_coches.png |800px|center| Solució Alquiler coches]] |
| | | | |
| − | :*De cada cliente se desea almacenar su DNI, nombre, dirección y teléfono.
| + | CLIENT ('''''DNI''''', Nom, Cognoms, Telefon, DNI_avalador) ON {DNI_avalador} REFERENCIA CLIENT ADMET VALORS NULS |
| | | | |
| − | :*Una reserva la realiza un único cliente, pero puede involucrar a varios coches.
| + | AGENCIA ('''''Id_agencia''''', Adreça, Telefon) |
| | | | |
| − | :*Es importante registrar la fecha de comienzo de la reserva y la de terminación.
| + | COTXE ('''''Matricula''''', Marca, Modelo, Color, Id_garatge) ON {Id_garatge} REFERENCIA GARATGE |
| | | | |
| − | :*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.
| + | GARATGE ('''''Id_garatge''''', Adreça, Metres_quadrats) |
| | | | |
| − | :*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.
| + | RESERVA ('''''Id_agencia, Num_reserva'''', Data_ini, Data_fin, DNI_CLI) ON {DNI_CLI} REFERENCIA CLIENT I {Id_agencia} REFERENCIA AGENCIA |
| | | | |
| − | :*En la base de datos pueden existir clientes que no hayan hecho ninguna reserva.
| + | COTXES_RESERVA ('''''Id_agencia, Num_reserva, Matricula''''', Km_ini, Km_fin) ON {Id_agencia, Num_reserva} REFERENCIA RESERVA I {Matricula} REFERENCIA COTXE |
| | | | |
| − | :*Las entidades cliente, coche, agencia y garaje tienen una clave alfanumérica que las identifica unívocamente.
| + | SENSE ADMETRE VALORS NULS |
| | | | |
| − | :*Interesa conocer los km de inicio y km finales que ha realizado cada coche en cada reserva. | + | Tot igual, excepte: |
| | | | |
| − | :*Cada cliente puede ser avalado por otro cliente de la empresa.
| + | CLIENT ('''''DNI''''', Nom, Cognoms, Telefon) |
| | | | |
| − | [[Imatge:uf1nf2_sol_alquiler_coches.png |800px|center| Solució Alquiler coches]]
| + | AVALADOR ('''''DNI_CLI''''', DNI_AVAL) ON {DNI_CLI} REFERENCIA CLIENT I ON {DNI_AVAL} REFERENCIA CLIENT |
| | <!----> | | <!----> |
| | | | |
| | ==Empresa de comidas== | | ==Empresa de comidas== |
| | | | |
| − | Diseñad un esquema E/R par un empresa de comidas, teniendo en cuenta que:
| + | L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional. |
| | | | |
| − | :*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
| + | Donat el model ER següent, feu-ne la traducció al model relacional: |
| − | :*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]] | | [[Imatge:uf1nf2_sol_empresa_comidas.png |800px|center| Solució Empresa comidas]] |
| − | <!---->
| |
| | | | |
| − | ==Colegio==
| + | 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 |
| | + | |
| | | | |
| − | Diseñar una Base de Datos para representar la información docente de un colegio, sabiendo que:
| + | 2. Eliminant el supertipus i mantenenint els subtipus. |
| | | | |
| − | La formación abarca ocho cursos (1º, 2º, 3º .. 8º) en los que se imparten diversas asignaturas, tales como Matemáticas, Física, Ciencias Naturales, Sociales, Dibujo, etc., dándose el caso de algunas asignaturas de distintos cursos que tienen el mismo nombre.
| + | Tot igual, amb els següents canvis: |
| | + | - eliminem la relació TREBALLADOR |
| | + | - i modifiquem CUINER i AJUDANT afegint-lis els atributs de TREBALLADOR |
| | | | |
| − | Cada curso se reparte en varios grupos de alumnos a los que se asigna una letra: p.e. 3ºA, 2ºD, 5ºC, 1ºB, y se ubican en un aula fija para todo el curso. Las aulas, identificadas por un número, tienen una determinada capacidad de número de alumnos. De ellas interesa conocer, además, si disponen o no de conexión a la red de computadores del centro, y de pantalla para la proyección de transparencias.
| + | CUINER ('''''DNI''''', , Nom, Cognoms, Telefon_fixe, Telefon_mobil, NSS, Anys_servei) |
| | | | |
| − | Los profesores del centro, de los que se dispone de su nombre y apellidos, DNI, dirección y teléfono, pueden impartir varias asignaturas distintas a grupos distintos. No se da el caso de que una asignatura se imparta por más de un profesor al mismo grupo. Además, cada curso tiene un profesor coordinador y cada grupo un profesor tutor.
| + | AJUDANT ('''''DNI''''', , Nom, Cognoms, Telefon_fixe, Telefon_mobil, NSS, Data_neix, DNI_cuiner) ON {DNI_cuiner} REFERENCIA CUINER |
| | | | |
| − | Acerca de los alumnos, además de su nombre y apellidos, dirección y teléfono, se desea reflejar el curso en que están matriculados y el grupo al que están asignados. También se desea representar qué alumno es el delegado de cada grupo. Como puede darse el caso, de alumnos con el mismo nombre y apellidos, cada alumno tiene asociado un (único) número de matrícula que facilita su identificación.
| |
| | <!-- | | <!-- |
| | + | ==Colegio== |
| | + | |
| | + | 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_colegio.png |800px|center| Solució Colegio]] | | [[Imatge:uf1nf2_sol_colegio.png |800px|center| Solució Colegio]] |
| − | --> | + | |
| | + | Curs ('''''Num_curs''''', Dni_coordinador) ON {Dni_coordinador} REFERENCIA Professor. |
| | + | |
| | + | Professor ('''''DNI''''', Nom, Cognom, Adreça). |
| | + | |
| | + | Assignatura ('''''Nom_assig, Num_curs''''') ON {Num_curs} REFERENCIA Curs. |
| | + | |
| | + | Grup ('''Lletra, Id_curs''', DNI_tutor, Num_aula, Num_matric) ON {Num_curs} REFERENCIA Curs i {DNI_tutor} REFERENCIA Professor i {Num_aula} REFERENCIA Aula i {Num_matric} REFERENCIA Alumne. |
| | + | |
| | + | Impartir ('''Nom_assig, Num_curs, Lletra, Id_curs''', Dni_prof) ON {Nom_assig, Num_curs} REFERENCIA Assignatura i {Lletra, Id_curs} REFERENCIA Grup i {Dni_Prof} REFERENCIA Professor. |
| | + | |
| | + | Aula ('''Num_aula''', Capacitat, ConnexioPC, Projector) |
| | + | |
| | + | Alumne ('''Num_matricula''', Nom, Cognoms, Adreça, Lletra_Grup, Id_curs) ON {Lletra_Grup, Id_curs} REFERENCIA Grup. |
| | + | |
| | + | |
| | + | |
| | + | ==Banco== |
| | + | |
| | + | 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_banco.png |800px|center| Solució Banco]] |
| | + | |
| | | | |
| | ==Catastro municipal== | | ==Catastro municipal== |
| | | | |
| − | Diseñad un esquema E/R que recoja la información correspondiente al catastro de viviendas de un determinado municipio. En el municipio existen una serie de zonas urbanas en las cuales se ha edificado un conjunto de viviendas, las cuales pueden ser:
| + | 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_catastro_municipal.png |800px|center| Solució Catastro municipal]] |
| | + | |
| | + | Zona_Urbana: Nom_zona, Ubicacio; |
| | + | |
| | + | |
| | + | Vivenda: Codi_postal, Carrer Numero Nom_Zona on {Nom_zona} referencia Zona_Urbana; |
| | | | |
| − | ::*'''Viviendas unifamiliares''' o casas en las que sólo habita una familia y,
| |
| | | | |
| − | ::*'''Bloques de pisos''' en los cuales existe un conjunto de viviendas, indeterminado a priori, en cada una de las cuales habita una familia. | + | Bloc: Garatge, Carrer, Numero ,Nom_Zona on {Carrer,Numero,Nom_Zona} referencia Vivenda ; |
| | | | |
| − | Es preciso mantener la información correspondiente a las personas que viven en cada una de las viviendas, así como el cabeza de familila de las personas que habitan o son propietarias de las viviendas. Para cada vivienda, además de la información correspondiente a las características de las mismas, es necesario conocer al propietario.
| |
| | | | |
| − | Deben considerarse los siguientes supuestos:
| + | UniFamiliar: Jardi , Metres , Carrer ,Numero Nom_Zona , Dni on {Carrer,Numero,Nom_zona} referencia Vivenda on {dni} referencia Persona; |
| | | | |
| − | :*Toda persona habita en una y sólo una vivienda, la cual es considerada como su vivienda residencia principal. Nos interesa su DNI, nombre, apellidos y teléfono.
| |
| | | | |
| − | :*Cada vivienda tiene uno y sólo un propietario. | + | Pis: Metres , Escala ,Planta ,Puerta ,Carrer Numero ,Nom_Zona ,Dni on {Carrer Numero Nom_Zona} referencia Bloc y {Dni } referencia Persona |
| | | | |
| − | :*Las viviendas se encuentran en una única zona urbana correspondiente al municipio, de las cuales nos interesan los metros cuadrados que tienen. De las unifamiliares, también si tienen o no jardin y si hay o no garage en los bloques de piso.
| |
| | | | |
| − | :*Las zonas urbanas en las que está dividido geográficamente el municipio tienen nombres diferentes y nos interesa su ubicación. | + | Tel_Persona: Dni, Telefon on {Dni} referencia Persona; |
| | | | |
| − | :*En cada zona urbana del municipio existen una serie de calles en las que se construyen las viviendas. Los nombres de las calles son únicos para el municipio con independencia de la zona urbana en la que se encuentren (para simplicar el problema no se considerará información sobre las calles).
| |
| | | | |
| − | :*En el contexto del problema, una familia es un conjunto de personas que tienen relación familiar directa y que habita, o no, en una misma vivienda. Este conjunto podrá ser unario. | + | Persona:Nom, Cognoms, Dni ,Dni_cap , Carrer Numero, Nom_Zona, Escala ,Planta, Puerta on{ Carrer, Numero, Nom_Zona} ref UniFamiliar on { Escala, Planta, Porta }ref Pis |
| | + | |
| | | | |
| − | :*Como se indica en el enunciado del problema las viviendas pueden ser casas unifamiliaris o bloques de pisos en los cuales existen una serie de viviendas unifamiliares.
| |
| − | <!--
| |
| − | [[Imatge:uf1nf2_sol_catastro_municipal.png |800px|center| Solució Catastro municipal]]
| |
| − | -->
| |
| | ==líneas de metro== | | ==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:
| + | 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_linias_metro.png |800px|center| Solució Línies metro]] |
| | | | |
| − | 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.
| + | LINIA ('''''Id_linia''''', Color, Hora_primer, Hora_darrer) |
| | | | |
| − | 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.
| + | ESTACIO ('''''Id_estacio''''', Nom, Hora_obrir, Hora_tancar) |
| | | | |
| − | 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.
| + | ACCES ('''''Id_estacio, Num_acces''''', Carrer, Portal) ON {Id_estacio} REFERENCIA ESTACIO |
| | | | |
| − | 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.
| + | COTXERA ('''''Id_estacio''''', Num_trens, Num_vagons) ON {Id_estacio} REFERENCIA ESTACIO |
| | | | |
| − | 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.
| + | TREN ('''''Id_tren''''', Model, Data_compra, Max_vagons, Id_estacio) ON {Id_estacio} REFERENCIA ESTACIO |
| | + | |
| | + | ARRIBADA ('''''Id_arribada''''', Sentit, Numero, Data_hora_arr, Data_hora_sor, Id_tren) ON {Id_tren} REFERENCIA TREN |
| | + | |
| | + | CONSTAR ('''''Id_linia, Id_estacio''''', Ordre, Segons_ant, Segons_seg) ON {Id_linia} REFERENCIA LINIA I {Id_estacio} REFERENCIA ESTACIO |
| | + | |
| | + | PASSAR ('''''Id_linia, Id_estacio''''', Id_arribada) ON {Id_linia} REFERENCIA LINIA I {Id_estacio} REFERENCIA ESTACIO I {Id_arribada} REFERENCIA {ARRIBADA} |
| | + | |
| | + | SERVIR ('''''Id_tren, Data_inici''''', Id_linia, Data_final) ON {Id_tren} REFERENCIA TREN I {Id_linia} REFERENCIA LINIA |
| | | | |
| − | 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.
| |
| − | <!--
| |
| − | [[Imatge:uf1nf2_sol_linias_metro.png |800px|center| Solució Línies metro]]
| |
| − | -->
| |
| | ==Empresa de material informático== | | ==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:
| + | 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_material_informatico.png |800px|center| Solució Material informático]] |
| | | | |
| − | :*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.
| + | EQUIP ('''''Codi''''', Descripcio, Preu, Stock) |
| | | | |
| − | :*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.
| + | COMPONENT ('''''Codi''''', Descripcio, Preu, Stock) |
| | | | |
| − | :*Cada equipo está etiquetado con un código de equipo, una descripción, un precio y el stock disponible.
| + | CLIENT ('''''NIF''''', Nom, Cognoms, Telefon, Adreça) |
| | | | |
| − | :*Cada componente está etiquetado con un código de componente, una descripción, un precio y el stock disponible.
| + | SECCIO ('''''Id_seccio''''', Nom) |
| | | | |
| − | :*Los datos que almacenamos los clientes son el NIF, nombre, apellidos, domicilio y teléfono.
| + | EMPLEAT ('''''Id_Emp''''', DNI, Nom, Cognoms, Id_seccio) ON {Id_seccio} REFERENCIA SECCIO |
| | | | |
| − | :*Los datos que almacenamos de los empleados son el DNI, nombre, apellidos y la sección donde trabaja. Para su identificación dentro de la empresa se les asigna un Id.
| + | COMPOSAR ('''''Codi_equip, Codi_component''''', Quantitat) ON {Codi_equip} REFERENCIA EQUIP I {Codi_component} REFERENCIA COMPONENT |
| | | | |
| − | :*Un empleado trabaja en una única sección.
| + | COMPRAR_EQ ('''''Codi_equip, NIF, Data''''', Id_Emp, Quantitat) ON {Codi_equip} REFERENCIA EQUIP , {NIF} REFERENCIA CLIENT I {Id_Emp} REFERENCIA EMPLEAT |
| | | | |
| − | :*Una sección se identifica por un id y un nombre de sección.
| + | COMPRAR_CP ('''''Codi_component, NIF, Data''''', Id_Emp, Quantitat) ON {Codi_component} REFERENCIA COMPONENT , {NIF} REFERENCIA CLIENT I {Id_Emp} REFERENCIA EMPLEAT |
| | | | |
| − | :*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.
| |
| − | <!--
| |
| − | [[Imatge:uf1nf2_sol_material_informatico.png |600px|center| Solució Material informático]]
| |
| − | -->
| |
| | | | |
| | ==Libreria OnLine== | | ==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:
| + | L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional. |
| | | | |
| − | :*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.
| + | Donat el model ER següent, feu-ne la traducció al model relacional: |
| | | | |
| − | :*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. | + | [[Imatge:uf1nf2_sol_libreria_online.png |800px|center| Solució Libreria Online]] |
| | | | |
| − | :*Para las editoriales guardaremos un identificador, nombre, dirección, localidad, provincia, número de teléfono y la url de su página web.
| + | LLIBRE ( ''''''ISBN'''''' , Titol, descripcio, Any_public) |
| | | | |
| − | :*La tienda dispondrá de varios almacenes, de cada uno guardaremos un identificador, una dirección, localidad, provincia y un teléfono de contacto.
| + | AUTOR ( ''''''Id_autor'''''' , Nom, Cognoms, Adreça, url,CodiLocalitatl) ON { CodiLocalitat } REFERENCIA LOCALITAT |
| | | | |
| − | :*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.
| + | Escriure ( ''''''ISBN, id_autor'''''') ON { ISBN } REFERENCIA LLIBRE i { id_autor } REFERENCIA AUTOR |
| | | | |
| − | :*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.
| + | EDITORIAL ( ''''''Id _editorial'''''' , Nom, Adreça, Telefon, url,CodiLocalitat) ON { CodiLocalitat } REFERENCIA LOCALITAT |
| | | | |
| − | :*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.
| + | Publicar ( ''''''ISBN, Id_editorial'''''' ) ON { ISBN } REFERENCIA LLIBRE i { id_editorial } REFERENCIA EDITORIAL |
| | | | |
| − | :*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.
| + | PAPER( ''''''ISBN'''''' , Data_imp, Lloc_imp, Preu) ON { ISBN } REFERENCIA LLIBRE |
| | | | |
| − | <!--
| + | EBOOK( ''''''ISBN'''''' , Mida, Preu) ON { ISBN } REFERENCIA LLIBRE |
| − | [[Imatge:uf1nf2_sol_libreria_online.png |800px|center| Solució Libreria Online]]
| + | |
| − | -->
| + | MAGATZEM( ''''''Id_magatzem'''''' , Telefon, Adreça,CodiLocalitat) ON { CodiLocalitat } REFERENCIA LOCALITAT |
| | | | |
| − | ==Banco==
| + | Emmagatzemar( ''''''ISBN, Id_magatzem'''''' , Stock,) ON { ISBN } REFERENCIA PAPER i { id_magatzem } REFERENCIA EDITORIAL |
| | | | |
| − | Se desea informatizar parcialmente un banco determinado con los siguientes supuestos:
| + | LOCALITAT( ''''''Codi'''''' , Nom, Habitants, CodiProvincia) ON { CodiProvincia } REFERENCIA PROVINCIA |
| | | | |
| − | :*El banco tiene distintas sucursales que se identifican por un código.
| + | PROVINCIA( ''''''Codi'''''', Nom, Densitat) |
| | | | |
| − | :*Cada sucursal tienen una serie de cuentas corrientes asignadas a ella que se identifican por un código distinto para cada cuenta. Una cuenta corriente pertenece a uno o varios clientes. Es posible, sin embargo, que las operaciones que puede realizar cada uno de estos clientes con la cuenta no sean las mismas. Por ejemplo, si la cuenta 110245 pertenece a los clientes Pablo López y Paula Suárez, es posible que el privilegio de cerrar la cuenta sólo la tenga Pablo López y no Paula Suárez.
| + | CLIENT( ''''''NIF'''''' , Nom, Cognoms, Telefon, Adreça, email, CodiLocalitat) ON { CodiLocalitat } REFERENCIA LOCALITAT |
| | | | |
| − | :*Por otra parte, cada cliente, que se identifica por su DNI, puede tener varias cuentas y, por supuesto, unos privilegios distintos en cada una de ellas.
| + | CISTELLA( ''''''Id_cistella'''''' , Data_compra, NIF) ON { NIF } REFERENCIA CLIENT |
| | | | |
| − | :*Cada cuenta puede tener domiciliaciones asociadas con ella.
| + | contenir( ''''''Id_cistella , ISBN'''''' , Quantitat) ON { ISBN } REFERENCIA LLIBRE i { id_cistella } REFERENCIA CISTELLA |
| | | | |
| − | :*Los clientes pueden tener otorgados préstamos sin que estos préstamos estén asociados con ninguna de las cuentas corrientes. Cada préstamo se otorga a nombre de un solo cliente, y a un cliente se le pueden otorgar más de un préstamo.
| |
| | | | |
| | ==Agencia de viajes== | | ==Agencia de viajes== |
| | | | |
| − | Realice, en el modelo E/R, el diseño de una base de datos para una agencia de viajes que, para ofrecer mejor servicio a sus clientes, considera de interés tener registrada la información referente a los diferentes tours que se pueden ofrecer. Tenga en cuenta lo siguiente:
| + | L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional. |
| | | | |
| − | :*Un tour, según su finalidad: cultural, histórica, deportiva… tiene unos determinados puntos de ruta y pueden repetirse varias veces al año.
| + | Donat el model ER següent, feu-ne la traducció al model relacional: |
| | | | |
| − | :*Definimos por viaje un tour concreto a realizar a partir de una fecha determinada.
| + | ==Centro educativo== |
| | | | |
| − | :*Los puntos de ruta de un tour pueden ser ciudades, monumentos, zonas geográficas, etc. y se consideran de visita solamente o de visita y estancia. En este último caso, el punto de ruta tiene asignado un hotel o varios.
| + | L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional. |
| | | | |
| − | :*Entendemos por cliente de un viaje la persona que ha decidido hacerlo y ha hecho efectiva una señal. | + | Donat el model ER següent, feu-ne la traducció al model relacional: |
| | | | |
| − | :*Un cliente puede confirmar su participación en más de un viaje (se sobreentiende que las fechas son diferentes)
| + | --> |
| | | | |
| − | :*Las personas que participan en un viaje pueden ser alojadas en los mismos o en diferentes hoteles
| + | ==Spots== |
| | | | |
| − | ==Centro educativo==
| + | 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]] |
| | + | |
| | + | <!-- |
| | + | '''1.''' Mantenint el supertipus, els subtipus i admetent valors nuls. |
| | + | |
| | + | |
| | + | ENTITAT_TV('''''Nom''''', Titularitat) |
| | + | |
| | + | CANALS('''''Nom_canal''''', Ambit, Nom_TV) |
| | + | on {Nom_TV} REFERENCIA A ENTITAT_TV |
| | + | |
| | + | SPOTS('''''Codi''''', Idioma, Duracio, CIF_FC_PR,CIF_FC_FL) |
| | + | on {CIF_FC_PR} REFERENCIA A FIRMA_COMERCIAL i |
| | + | {CIF_FC_FL} REFERENCIA A FIRMA_COMERCIAL |
| | + | |
| | + | TIPUS_PRODUCTE('''''Tipus''''') |
| | + | |
| | + | DIRECTORS('''''Id_Director''''', Nom, Cognoms, Data_Neix) |
| | + | |
| | + | EMPRESES('''''CIF''''', Nom, Cognom, Adreça, Telefon) |
| | + | |
| | + | FIRMA_COMERCIAL('''''CIF''''', Cap_Marketing) |
| | + | on {CIF} REFERENCIA A EMPRESES |
| | + | |
| | + | AGENCIES_PUBLICITARIES('''''CIF''''', Director_Artistic) |
| | + | on {CIF} REFERENCIA A EMPRESES |
| | + | |
| | + | COST_SPOT('''''Nom_canal, Hora_Inici, Hora_Final''''', Preu_Spot) |
| | + | on {Nom_canal} REFERENCIA A CANALS i |
| | + | {Hora_Inici, Hora_Final} REFERENCIA A FRANJA_HORARIA |
| | | | |
| − | Se tiene que diseñar una base de datos para gestionar la '''docencia de un curso académico en un centro educativo''' para controlar las notas, matriculaciones, profesores, alumnos, etc. El centro educativo está estructurado en departamentos. De los departamentos se quiere conocer el nombre y su código. Cada uno de los departamentos imparte la docencia de diversas materias. No se da el caso que una misma materia sea impartida por más de un departamento. También se quiere saber qué materias son previas a otras (por ejemplo no se puede cursar el crédito Sistemas Gestores de Bases de Datos Relacionales sin haber hecho el crédito Análisis y Diseño de Bases de Datos) Cada asignatura tiene uno o más grupos (por ejemplo, el grupo A de Análisis y Diseño de Bases de Datos, el grupo A, B, C, D del crédito de Estadística de cuarto ESO, que son 36 horas) Se tiene que dejar constancia de las siglas, nombre y horas de cualquiera de estas materias.
| + | SPOT_EQ('''''Codi, Codi_eq''''', Grau) |
| | + | on {Codi} REFERENCIA A SPOT i |
| | + | {Codi_eq} REFERENCIA A SPOT |
| | | | |
| − | Todos los profesores están adscritos a uno y sólo uno de los departamentos, y los departamentos están formados por uno o más profesores. En general, los profesores están encargados de uno o más grupos, pero es posible que haya profesores que no estén encargados de ningún grupo durante el curso actual. Es posible también, que un grupo tenga más de un profesor encargado (una asignatura compartida por varios profesores) Se quiere tener constancia de todos los hechos anteriores, incluso cual es la parte del curso que está encargada a cada profesor.
| |
| | | | |
| − | Al inicio del curso, los alumnos se matriculan y quedan asignados a los diversos grupos, se quiere información de este hecho. Profesores y alumnos se quieren agrupar en una sola entidad llamada “PERSONAS”, que podría tener en común los atributos comunes de las otras entidades anteriores como: DNI, nombre, dirección, teléfono, etc. Se ha de tener en cuenta que las personas del centro no son sólo las anteriores, también están los P.A.S. Sólo se quiere dejar información sobre el curso actual y no el histórico de los cursos anteriores, excepto un caso, se quiere dejar información de las notas que todos los alumnos han obtenido en las diferentes materias y en las diferentes convocatorias de examen (junio, septiembre y extraordinarias) en toda la vida del centro educativo.
| + | EMISSIONS('''''Codi_Sp, Nom_Canal, Hora_Inici, Hora_Final''''', Num_Vegades) |
| | + | on {Codi_Sp} REFERENCIA A SPOT i |
| | + | {Nom_canal} REFERENCIA A CANALS i |
| | + | {Hora_Inici, Hora_Final} REFERNCIA A FRANJA_HORARIA |
| | | | |
| − | ==Spots==
| + | SPOT_PRODUTE('''''Codi_Sp, Tipus_p''''') |
| | + | on {Codi_Sp} REFERENCIA A SPOT i |
| | + | {Tipus_p} REFERENCIA A TIPUS_PRODUCTES |
| | + | |
| | + | PROHIBICIONS('''''Tipus, Hora_i, Hora_f, Data_i''''', Data_f, Grau_M) |
| | + | on {Tipus_p} REFERENCIA A TIPUS_PRODUCTES i |
| | + | {Hora_Inici, Hora_Final} REFERENCIA A FRANJA_HORARIA |
| | | | |
| − | 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.
| + | FILMAR_AG('''''Codi_Sp, ID_Director''''', CIF_AG) |
| − |
| + | on {Codi_Sp} REFERENCIA A SPOT i |
| − | 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.
| + | {ID_Director} REFERENCIA A DIRECTORS |
| | | | |
| − | 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.
| + | o |
| | | | |
| − | 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.
| + | FILMAR_AG('''''Codi_Sp, CIF_AG''''', ID_Director) |
| | + | on {Codi_Sp} REFERENCIA A SPOT i |
| | + | {CIF_AG} REFERENCIA A AGENCIAS_PUBLICITARIES |
| | | | |
| − | 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.
| + | CONTRATAR('''''Id_Director, Data_Alta''''', CIF_AG) |
| | + | on {Id_Director} REFERENCIA A DIRECTORES i |
| | | | |
| − | 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.
| + | '''2.''' Eliminant el supertipus i sense admetre valors nuls. |
| | | | |
| − | 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.
| + | S'elimina la relació Empreses i els seus atributs passen als subtipus: |
| | | | |
| − | ==La Facultad==
| + | FIRMA_COMERCIAL('''''CIF''''', Nom, Cognom, Adreça, Telefon, Cap_Marketing) |
| | | | |
| − | 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.
| + | AGENCIES_PUBLICITARIES('''''CIF''''', Nom, Cognom, Adreça, Telefon, Director_Artistic) |
| | | | |
| − | 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.
| + | Eliminem l'atribut CIF_FC_FL de SPOTS |
| | | | |
| − | 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.
| + | SPOTS('''''Codi''''', Idioma, Duracio, CIF_FC_PR) |
| | | | |
| − | 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.
| + | i Creem una RELACIÓ NOVA: |
| | | | |
| − | 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.
| + | SP_FC('''''Codi_Sp''''', CIF_FC) |
| | | | |
| − | 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 Facultad== |
| | | | |
| − | 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.
| + | L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional. |
| | | | |
| − | 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.
| + | Donat el model ER següent, feu-ne la traducció al model relacional: |
| | + | --> |
L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional.
L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional.
1. Mantenint supertipus i subtipus.
Tot igual, amb els següents canvis:
- eliminem la relació TREBALLADOR
- i modifiquem CUINER i AJUDANT afegint-lis els atributs de TREBALLADOR
L’objectiu d’aquesta activitat és el d’aplicar els processos de traducció del model ER al model relacional.
