Cita: 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.
Cita: 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.
Cita: ¿ 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.
Cita: 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