Pregunta 46

Exámenes de las oposiciones, anuncios, etc.
Responder
juanp
Usuario registrado
Mensajes: 18
Registrado: 05 Jun 2019, 10:38
Agradecido: 0
Agradecimiento recibido: 0

Pregunta 46

Mensaje por juanp »

Considere un modelo E/R con un tipo de relación muchos a muchos (N:M) "Trabaja" en el que participan los tipos de entidad "Empleado" y "Proyecto". "Trabaja" tiene además el atributo "fecha". La clave primaria del tipo de entidad "Empleado" es "idEmp" y la clave primaria del tipo de entidad "Proyecto" es "idProy". Por definición del modelo E/R, la clave primaria del tipo de relación "Trabaja":
a) Puede ser (idProy,idEmp) o bien (idProy,idEmp,fecha).
b) Sólo puede ser (idProy, idEmp, fecha).
c) Puede ser (idProy, idEmp), (idProy,idEmp,fecha), (idProy,fecha) o bien (idEmp, fecha).
d) Sólo puede ser (idProy,idEmp).


Respuesta según plantilla: D.
Alternativas: A,C.

A: Si no haces que fecha sea parte de la clave, no vas a poder guardar más que una fecha para cada persona y proyecto
si la fecha es un día, no va a poder trabajar más que ese día.

C: Si un Empleado para un día determinado solo puede trabajar en un proyecto, (idEmp, fecha) también podría ser una clave primaria.

D: La respuesta A no es válida porque el atributo 'fecha' podría estar en blanco, con lo que podrían haber claves duplicadas y no estaría normalizada la tabla.

¿Opiniones?

Avatar de Usuario
OpositorCompulsivo
Usuario registrado
Mensajes: 9
Registrado: 27 Feb 2017, 18:11
Agradecido: 0
Agradecimiento recibido: 0

Re: Pregunta 46

Mensaje por OpositorCompulsivo »

Sacado del libro de técnicas de Métrica 3:
Relaciones M:N, se transforman en una tabla, cuya clave primaria es la concatenación de los identificadores de las clases asociadas, siendo cada uno de ellos clave ajena de la propia tabla. Si la relación tiene atributos, éstos se transforman en columnas de la tabla.
No deja lugar a dudas. La tabla trabajar tendrá como clave primaria las claves primarias de las tablas Empleado y Proyecto y el atributo fecha figurará como una columna más en la tabla. ¿Qué no tiene sentido en el mundo real este tipo de entidad relación? Pues sí, y como bien indicas es imposible guardar varias fechas para aquellos empleados que trabajen en el mismo proyecto, pero eso ya es problema del modelo entidad relación propuesto, que tal vez con una relación ternaria o una relación de agregación se pueda solucionar esas restricciones de meter varias fechas.

Yo esta pregunta, aunque me encantaría que cayera impugnada :twisted:, la veo correcta y bien planteada.

tonit
Usuario registrado
Mensajes: 48
Registrado: 31 May 2017, 13:50
Agradecido: 10 veces
Agradecimiento recibido: 0

Re: Pregunta 46

Mensaje por tonit »

Solo consideraba A, por lo que dices e independientemente de si la fecha es inicio, fin o lo que les parezca. Pero el resto de argumentos para las otras opciones me parecen también válidos. Y no veo que se indique Métrica v3 en ningún momento.
juanp escribió:
22 Oct 2019, 14:16
[...]

A: Si no haces que fecha sea parte de la clave, no vas a poder guardar más que una fecha para cada persona y proyecto
si la fecha es un día, no va a poder trabajar más que ese día.

[...]

Lionel
Usuario registrado
Mensajes: 49
Registrado: 11 Dic 2009, 21:19
Agradecido: 0
Agradecimiento recibido: 0

Re: Pregunta 46

Mensaje por Lionel »

OpositorCompulsivo escribió:
22 Oct 2019, 16:31
Sacado del libro de técnicas de Métrica 3:
Relaciones M:N, se transforman en una tabla, cuya clave primaria es la concatenación de los identificadores de las clases asociadas, siendo cada uno de ellos clave ajena de la propia tabla. Si la relación tiene atributos, éstos se transforman en columnas de la tabla.
No deja lugar a dudas. La tabla trabajar tendrá como clave primaria las claves primarias de las tablas Empleado y Proyecto y el atributo fecha figurará como una columna más en la tabla. ¿Qué no tiene sentido en el mundo real este tipo de entidad relación? Pues sí, y como bien indicas es imposible guardar varias fechas para aquellos empleados que trabajen en el mismo proyecto, pero eso ya es problema del modelo entidad relación propuesto, que tal vez con una relación ternaria o una relación de agregación se pueda solucionar esas restricciones de meter varias fechas.

Yo esta pregunta, aunque me encantaría que cayera impugnada :twisted:, la veo correcta y bien planteada.
No veo que se hable de METRICA en ningún momento en la pregunta. METRICA tiene sus peculiaridades y particularidades, también creo que tenía sus particularidades en como denominaba los distintos tipos de pruebas que no se corresponde con la terminología generalmente asumida, etc, algo había por ahí, no sé si era justo en ese punto, pero tiene sus particularidades.

En este caso no sé para qué necesitas relaciones ternarias ni relaciones de agregación, simplemente la clave primaria es "idProy, idEmp, fecha" y ya soporta cualquiera de las situaciones que proponéis, que sólo haya una fecha, o que haya un ciento, no va a haber problema. Es así como se hace de toda la vida. Prueba con MySQL, Postgress, etc, y verás que si pones "idProy, idEmp" no te va a dejar insertar registros con diferentes fechas, te va a indicar "Duplicated primary key" y de la otra forma puedes cargar lo que quieras.

La correcta es la B de toda la vida y en todo caso se puede decir que es confuso y que se anule.

Avatar de Usuario
VicCV
PreparaTIC26
Mensajes: 51
Registrado: 21 May 2018, 15:14
Agradecido: 0
Agradecimiento recibido: 0

Re: Pregunta 46

Mensaje por VicCV »

Si no tenemos en cuenta lo que dice métrica, yo considero correcta la A. Será una de las dos opciones según lo que se quiera incluir en la tabla.

Si es solo fecha de incorporación y no es un histórico, meter la fecha, aunque se permita, estaría mal hecho, pues podríamos poner dos registros con información incoherente (aparte de que directamente la fecha no pinta nada en la clave).

No se trata de meter la clave que permita cualquier cosa si no la que requiere la situación, y no todas las situaciones requieren la fecha como parte de la clave

Avatar de Usuario
javierbds
Usuario registrado
Mensajes: 125
Registrado: 14 Sep 2017, 10:57
Agradecido: 1 vez
Agradecimiento recibido: 0

Re: Pregunta 46

Mensaje por javierbds »

La clave de esta pregunta es "Por definición del modelo E/R". Si miráis los textos de Chen (creador del modelo) la respuesta solo puede ser D: no puede haber atributos clave en una relación (si los tienes/quieres hay que convertir la relación en entidad).
Ni el paso a tablas ni Metrica ni Modelo ER extendido son el objetivo de la pregunta sino la definición (original) del Modelo ER. La pregunta se las trae ya que como indicáis no guarda relación con el uso y la práctica que se pide conocer para la oposición y el trabajo.
Como alguien comento en otro sitio: si sabes de bases de datos y modelización la fallas y si no la aciertas :wink:
Todo apunta a que el autor es el mismo que la del MER Extendido de TAI 2017: redacción confusa a propósito, una amiga tiene unas velas negras … :mrgreen:
Los ingenieros son también activistas sociales que diseñan sociedades e instituciones que se ajustan a sus máquinas [Callon]

Lionel
Usuario registrado
Mensajes: 49
Registrado: 11 Dic 2009, 21:19
Agradecido: 0
Agradecimiento recibido: 0

Re: Pregunta 46

Mensaje por Lionel »

Pues poner una pregunta para que tengas que contestar la opción incorrecta, no parece muy apropiado. Es cierto que se puede modelar tomando la relación como una entidad independiente con dos relaciones, pero ahí habla sólo de dos entidades y de una relación. El campo fecha sobre el que está hablando no es inicia su contrato en tal fecha, sino que se entiende que trabaja en varias fechas y eso exige sí o sí que vaya la fecha en la clave primaria para que no haya duplicated key sino no se puede representar esa situación y la pregunta es inconsistente. No debería de haber puesto un ejemplo inconsistente con la pregunta.

Avatar de Usuario
javierbds
Usuario registrado
Mensajes: 125
Registrado: 14 Sep 2017, 10:57
Agradecido: 1 vez
Agradecimiento recibido: 0

Re: Pregunta 46

Mensaje por javierbds »

Mi opinión es que para impugnar esta pregunta hay que investigar si "por definición del modelo entidad relación" tiene sentido que una relación tenga clave.

Y leyendo The Entity-Relationship Model - Toward a Unified View of Data (quien me iba a mi a decir que a estas alturas … :oops: ) parece
que si tiene sentido… :cry:

Pag.16
Since a relationship is identified by the involved entities, the primary key of a relationship can be represented by the primary keys of the involved entities.

Pag.24, Tabla II
Update a value (note that a relationship attribute will not be a relationship PK)

Y, por cierto, en el ejemplo de E/R la forma de tener múltiples asignaciones de un empleado a un proyecto es que fecha sea multivaluado 8) {fecha1, … ,fechaN}

De la vela negra no se libra eso sí :lol:
Última edición por javierbds el 24 Oct 2019, 16:19, editado 10 veces en total.
Los ingenieros son también activistas sociales que diseñan sociedades e instituciones que se ajustan a sus máquinas [Callon]

Lionel
Usuario registrado
Mensajes: 49
Registrado: 11 Dic 2009, 21:19
Agradecido: 0
Agradecimiento recibido: 0

Re: Pregunta 46

Mensaje por Lionel »

Yo no le he mirado pero de cuando estudié METRICA hace 20 años si mi memoria no me falla creo que sí que dice lo de poner sólo la clave primaria de las dos entidades y no poner fecha. Pero es que el ejemplo es inconsistente y en la pregunta no dice nada de METRICA y diga lo que diga METRICA yo no voy a contestar mal ante el ejemplo que han puesto porque poner sólo las claves primarias sin fecha, no te permite modelar correctamente el ejemplo. Ya te digo, compruébalo en cualquier motor de base de datos y ya verás lo que te dice.

La pregunta no está bien planteada, es inconsistente.

Avatar de Usuario
OpositorCompulsivo
Usuario registrado
Mensajes: 9
Registrado: 27 Feb 2017, 18:11
Agradecido: 0
Agradecimiento recibido: 0

Re: Pregunta 46

Mensaje por OpositorCompulsivo »

Lionel escribió:
24 Oct 2019, 14:06
Yo no le he mirado pero de cuando estudié METRICA hace 20 años si mi memoria no me falla creo que sí que dice lo de poner sólo la clave primaria de las dos entidades y no poner fecha. Pero es que el ejemplo es inconsistente y en la pregunta no dice nada de METRICA y diga lo que diga METRICA yo no voy a contestar mal ante el ejemplo que han puesto porque poner sólo las claves primarias sin fecha, no te permite modelar correctamente el ejemplo. Ya te digo, compruébalo en cualquier motor de base de datos y ya verás lo que te dice.

La pregunta no está bien planteada, es inconsistente.
Respondo por aludido por lo de "métrica 3", si he mencionado el libro de "técnicas de métrica 3" a sido por donde he estado estudiando las reglas de transformación de modelo E-R a modelo físico y donde he extraído la cita mencionada en el comentario anterior. Además leyendo comentarios de gente como "javierdbs" que utiliza otro materiales de referencia como los libros de Chen, parece que llegamos a la misma conclusión "el atributo fecha no puede pertenecer a la clave".

En mi comentario anterior intentaba señalar que aunque el modelo E-R de la pregunta "presente inconsistencias para almacenar varias fechas" y parezca ilógico e irracional no poner el atributo fecha dentro de la cable primaria; las reglas de transformación no te lo permiten y habría que cambiar el modelo E-R del enunciado para poder solucionar esa inconsistencia.

El profesor que me daba BD-1 nos solía remarcar que "la vida real"® cuando veas una relación "N:M" sospecha de ese E-R es probable que este mal y si ves más de una, definitivamente esta mal hecho.

Responder

Volver a “PROCESO SELECTIVO A2 2018”