Duda sobre relaciones 1-1, n-1, n-n, 1-n

[arts]

Tengo dudas que no alcanzo a entender según algunos ejemplos.
Por ejemplo si hacemos una relación 1-1 se refiere por ejemplo a que solo 1 empleado puede hacer uso por ejemplo de 1 solo coche en el trabajo no ?. Y ese coche solo puede pertenecer a ese empleado no ?, haciendo imposible que otro empleado use ese coche no ?. Traduciendo esas dos tablas en 1 sola por ejemplo en la que el empleado tiene un campo mas llamado coche no ?. ¿ O se puede tener dos tablas también pasando el id del lado 1 ( en este caso da igual ) por ejemplo el id del empleado a la tabla coche ?.

Si quisiera hacerlo 1 - N tendría 1 empleado que haría uso de varios coches no? y que ese coche puede tener solo a 1 empleado no ?. puede tener esos coches asociados ?, dando lugar a dos tablas una con empleados que pasa su id a la tabla coches, pero... ¿ y si digo que un empleado solo puede tener acceso 3 coches durante toda su vida en la empresa y que no pueden hacer uso otros empleados de esos coches que ya están asociados a un empleado ?. ¿ Cambiarían las tablas ?.

N:N Entiendo que se crea una tercera tabla donde se le pasan los id de coches y empleados a esta, pudiendo tener un empleado repetido con los mismos coches y además entiendo que esa relación debería estar mal en este ejemplo ya que no se diferenciaría que empleado tiene que coche ya que podría repetirse empleado y coche varias veces, como si quisiera tener un histórico de que empleado ha cogido que coche y a que fecha y hora para hacer viable la relación coche - empleado.

[gnzsoloyo]

Por ejemplo si hacemos una relación 1-1 se refiere por ejemplo a que solo 1 empleado puede hacer uso por ejemplo de 1 solo coche en el trabajo no ?

Exacto. Existe una dependencia directa del coche con el empleado. Lo que debes tener en cuenta es que el coche depende del empelado y no a la inversa, por lo que la FK va en Coche.

Si quisiera hacerlo 1 - N tendría 1 empleado que haría uso de varios coches no? y que ese coche puede tener solo a 1 empleado no ?. puede tener esos coches asociados ?, dando lugar a dos tablas una con empleados que pasa su id a la tabla coches,

Correcto.

¿ y si digo que un empleado solo puede tener acceso 3 coches durante toda su vida en la empresa y que no pueden hacer uso otros empleados de esos coches que ya están asociados a un empleado ?. ¿ Cambiarían las tablas ?.

No cambian las tablas. Esa no es una restricción de la base de datos sino una regla de negocio. Las reglas de negocio se implementan por SP o TRIGGER, según las capaciades del DBMS, o bien se pueden definir en la aplicación. Pero el límite de la cardinalidad NO modifica el diseño de la base.

N:N Entiendo que se crea una tercera tabla donde se le pasan los id de coches y empleados a esta, pudiendo tener un empleado repetido con los mismos coches y además entiendo que esa relación debería estar mal en este ejemplo ya que no se diferenciaría que empleado tiene que coche ya que podría repetirse empleado y coche varias veces, como si quisiera tener un histórico de que empleado ha cogido que coche y a que fecha y hora para hacer viable la relación coche - empleado.

La tabla que relaciona ambos elementos tiene como PK el par de claves, por ejemplo: (empleado_id, coche_id). Con eso en principio sería suficiente. No podrías poner dos veces el mismo empelado con el mismo coche.
Ahora bien, si la tabla representa el uso o asignación del coche al empleado en el transcurso del tiempo, puede aparecer más de una vez el mismo par, y por tanto ambas claves agrupadas son insuficientes para identificar los registros. En esos casos y sólo en esos casos, se agrega un campo a la clave que actúe como discriminante. Usualmente en tablas de evolución histórica como la que describes ese campo es un datetime que suele denominarse como "fecha_inicio", como para que quede claro cual es el discriminador del registro.
Asi, la clave estaría compuesta de al menos tres campos: (empleado_id, coche_id, fecha_inicio).
¿Se entiende?

Cuando digo "suele", me refiero a que el mismo caso se produce en el detalle de una factura, o en una lista de gastos, por ejemplo, imputados a una X persona. El mismo item puede aparecer N veces relacionado con X.
¿Como se soluciona?
Bueno, cuando son listados relacionado con Z concepto, el discriminante es un numerador por lista, es decir, el numero de posición en que el item se ingresó en la lista... Igual que en los items de una factura.

¿Eso se entiende?

Como nota adicional, las tablas históricas donde ciertas relaciones se activan y desactivan suelen tener dos campos adicionales: el del inicio y el de baja. El segundo (baja) se suele usar como nulable (NULL) y no forma parte de la clave, pero se usa para facilitar las validaciones

[arts]

Me surgen dos dudas ahora en la relacion N:N con la tabla empleado_id y coche_id que no se pueden repetir, es decir, no puedo tener repetido un usuario con un mismo coche varias veces. Necesitaría restringir la tabla para que no permitiera añadir varias veces a un empleado con mismo coche no ?.

Respecto al ejemplo 1-1 creo haber entendido que es necesario tener 2 tablas aparte de la dependencia donde tendría que pasar el id del coche al empleado, así si borro el empleado el coche sigue existiendo en su tabla. ¿ Es esto a lo que te referías con la dependencia ?, mientras que si lo hiciera al revés al borrar un empleado se me quedaría la tabla coches con un id de ese empleado que no pertenecería a nadie ya que la acabo de borrar. ¿ Es esto así ?.

[gnzsoloyo]

Me surgen dos dudas ahora en la relacion N:N con la tabla empleado_id y coche_id que no se pueden repetir, es decir, no puedo tener repetido un usuario con un mismo coche varias veces. Necesitaría restringir la tabla para que no permitiera añadir varias veces a un empleado con mismo coche no ?.

Eso se restringe en forma automática cuando declaras la PK como compuesta por las dos FK... Es decir, supongamos: (empleado_id, coche_id).
Por definición, una PK es UNICA...

Respecto al ejemplo 1-1 creo haber entendido que es necesario tener 2 tablas aparte de la dependencia donde tendría que pasar el id del coche al empleado, así si borro el empleado el coche sigue existiendo en su tabla. ¿ Es esto a lo que te referías con la dependencia ?, mientras que si lo hiciera al revés al borrar un empleado se me quedaría la tabla coches con un id de ese empleado que no pertenecería a nadie ya que la acabo de borrar. ¿ Es esto así ?.

Cuando se habla de "dependencia" en base de datos, estamos hablando a que existe una dependencia funcional entre dos entidades. es decir, la EXISTENCIA de una entidad depende de la existencia de otra.
El caso más ejemplificador es el de las cargas sociales de un empleado. Los registros correspondientes a las cargas sociales (hijos, conyuges, etc), sólo existen en su tabla , si existe el empleado. De lo contrario no existen. ESO es dependencia funcional.
Si los empleados de la empresa pueden existir como tales, aunque no se les asigne un vehículo, y los vehículos existen aunque no tengan empelados asignados, entonces NO EXISTE dependencia.
Ene se caso lo que existe es una RELACION entre ambas entidades que se representa por medio de una TABLA que la administra. Eso es un concepto diferente en el análisis del sistema.

Ahora bien, suponiendo que Empleado y Coche son tablas base (sus entidades representadas existen aún si no se las relaciona), hay un vínculo que podemos denominar "Tiene _asignado_un_coche", y esa relación determina la existencia de la tabla "Asignado_A", la cual a su vez sólo posee dos campos principales: Los de la PK que te mencionaba antes

TIENE_ASIGNADO(empelado_id, coche_id).

En ese diseño, ni Empelado ni Coche requieren la fk de la otra tabla, ya que la relación la hace la tercera tabla.
Ahora bien, ¿como haces en ese diseño para que un mismo vehículo y un mismo empelado aparezcan una sola vez?
Fácil: declaras UNIQUE a cada campo...

Código MySQL:

CREATE TABLE(
empleado_id INT NOT NULL
coche_id INT NOT NULL,
PRIMARY KEY(empelado_id, coche_id),
CONSTRAINT  empleado_fk FOREIGN KEY(empleado_id) REFERENCES EMPLEADO(empelado_id),
CONSTRAINT  coche_fk FOREIGN KEY(coche_id) REFERENCES COCHE(coche_id));
 
CREATE UNIQUE INDEX asigna_empelado_uk ON tiene_asignado(emeplado_id);
CREATE UNIQUE INDEX asigna_coche_uk ON tiene_asignado(coche_id);
 

ATENCION: Lo estoy escribiendo de memoria, este breve script puede contener errores porque no estoy mirando el manual de referencia.

[arts]

¡¡¡ Gracias, ahora si me he enterado bien !!!.