Hola Francisco, van las observaciones
Para las relaciones con cardinalidad N:M toma las claves principales de las tablas que relaciona, si éstas pasan a conformar una clave principal combinada, ambas deben llevar un único subrayado ya que es una única clave que se considera al concatenarlas, lo mismo pasa que si no garantizaran unicidad y se toma un atributo existente que permita garantizarla, entonces los tres atributos pasan a conformar la clave principal y llevan un único subrayado, ahora bien si no garantizaran unicidad entonces es necesario agregar un nuevo atributo que sí lo garantice que pase a ser la clave principal de la relación dejando entonces las otras dos claves recién ahí como foráneas.
Caso 1
Relación Producto-Venta
En esta relación la concatenación entre Codprod y Numfact si te garantizarían unicidad por lo que ambas serían clave primaria en esa relación ya que un mismo producto no podría estar 2 veces en una misma factura.
Existe un error en la cardinalidad entre Cliente y Venta, de acuerdo al enunciado un cliente puede tener muchas ventas pero una venta (factura) sólo le pertenece a un cliente. la cardinalidad está al revés en la gráfica
Para las relaciones con cardinalidad N:M toma las claves principales de las tablas que relaciona, si éstas pasan a conformar una clave principal combinada, ambas deben llevar un único subrayado ya que es una única clave que se considera al concatenarlas, lo mismo pasa que si no garantizaran unicidad y se toma un atributo existente que permita garantizarla, entonces los tres atributos pasan a conformar la clave principal y llevan un único subrayado, ahora bien si no garantizaran unicidad entonces es necesario agregar un nuevo atributo que sí lo garantice que pase a ser la clave principal de la relación dejando entonces las otras dos claves recién ahí como foráneas.
Caso 1
Relación Producto-Venta
En esta relación la concatenación entre Codprod y Numfact si te garantizarían unicidad por lo que ambas serían clave primaria en esa relación ya que un mismo producto no podría estar 2 veces en una misma factura.
Existe un error en la cardinalidad entre Cliente y Venta, de acuerdo al enunciado un cliente puede tener muchas ventas pero una venta (factura) sólo le pertenece a un cliente. la cardinalidad está al revés en la gráfica
Caso 2
En el DER la cardinalidad entre cliente y tarjeta es de 1:N ya que un cliente puede tener muchas tarjetas pero una tarjeta sólo le pertenecerá a un cliente
La relación Empleado-Sucursal debería tener como clave principal combinada a legajo, número y días de acuerdo al enunciado, una que por ejemplo el empleado 101 puede trabajar en la sucursal 10 los días lunes y martes, entonces no se garantizaría la unicidad sólo con las claves indicadas
En la Relación Sucursal-Cliente la clave combinada no garantiza unicidad, sería conveniente agregar un atributo que funcione como clave principal dejando a las que indica como foráneas
La Relación (tabla) Cliente-Tarjeta no corresponde por que la cardinalidad no es la correcta
En la relación Sucursal-Producto deberían quedar como clave principal combinada, es decir con un sólo subrayado
caso 3
En la tabla Ciudad la clave principal estaría dada por la combinación de nombre y provincia de acuerdo al enunciado
En la tabla farmacia no puede tener 2 atributos con el mismo nombre, debe identificar de manera única cada columna
En la narración indica que una farmacia puede no tener un propietario lo que modifica la cardinalidad indicando que propietario es una entidad débil ya que para ser propietario la farmacia debería existir por lo que lo conveniente es llevar el código de farmacia a propietario
Para Medicamento se realiza una sola tabla en la que se tiene ID como principal y ID_med como foránea que hace referencia a algún medicamento de la misma tabla (símil a la tabla employees vista en SQL)
caso 4
la tabla Libro-Autor debe cambiar el nombre de alguno de los código, no puede tener dos atributos con el mismo nombre, en este caso pasan a ser clave principales combinada
La tabla Libro-socio debería considerar fecha de préstamo como parte de la clave principal combinada ya que las otras dos no garantizan unicidad porque un socio puede sacar el mismo libro varias veces, o bien se puede agregar un atributo nro préstamo y dejar como foráneas las otras
Ejercicio 2:
ítem b: la relación Equipo Informático-Proveedor debe indicar la clave principal sea combinada o simple, en este caso figura como foráneas ambas, esto lo debe considerar en todas las relaciones siempre se debe tener la clave principal ya sea simple porque se agrega una para garantizar unicidad o bien se cuenta con 2 claves de otras tablas que pasan a concatenarse para garantizar unicidad
En la tabla Equipo Informático-Mantenimiento no corresponde que fecha sea clave principal ya que en una misma fecha se podrían llevar varios equipos, aquí se podría en todo caso agregar nro de servicio o bien tener una clave principal combinada entre cod equipo, nro registro y fecha.
ítem d: en la relación Hardware-Mantenimiento no se coloca la clave principal, si se considera una clave combinada debe indicar un sólo subrayado en ambas, sin embargo en este planteo no garantiza unicidad, debería agregar fecha a la clave o bien generar un atributo extra como principal y dejar las otra como foráneas.
saludos