En primer lugar: Según el modelo E-R, toda entidad
debe tener una clave primaria. Esto no es opcional, porque necesariamente necesitas algo que te permita no sólo identificar un único registro dentro de una tabla que puede tener millones, sino que también necesitas un modo de asegurarte que el registro se refiera a una instancia que no esté repetida. Y para eso es la PK.
Te repito: No es opcional. Una tabla sin PK es una "bolsa" no discriminante de cosas, pero no es una tabla relacional.
Cita: El problema es q si en la tabla "Cumplimiento" le agrego una Llave Primaria, esta se le asociará una Llave Foránea a Visitas y esto dejaría como si todas las visitas hubieran sido realizadas, cuando en realidad no siempre es así.
No, no es así.
En tu modelo, la tabla "Visitas" es una tabla relacional, esto es, representa una relación N:N entre Cliente y Pedido. Esta tabla debería tener una PK compuesta por tres atributos: cliente_id, tecnico_id y un discriminante que nos determine qué pedido es. Conforme el paradigma relacional ese discriminante debería ser una fecha y hora, que es la fecha y hora en que se registró el pedido, y no la fecha de realización de la visita, que es un
atributo de la entidad Visita. Esto es porque una visita tiene:
1) Un Cliente que la solicita.
2) Un técnico que la realiza.
3) Una fecha y hora de realización del pedido.
4) Una fecha y hora de la visita, acordados con el cliente.
5) Una fecha efectiva de realización de la visita.
En ese contexto, la tabla relacional "Visita" tiene cinco atributos como mínimo, de los cuales sólo tres son la PK. Los otros dos son atributos no clave, porque no se requieren para identificar el pedido, sino para establecer cuándo se debe hacer y cuándo se hizo.
No tienen nada que ver con la
identidad del registro, y por tanto no es necesaria una tercera tabla (al menos no en tu modelo).
¿Se entiende?
Lo que sí puede existir es un subconjunto adicional de tablas que nos pueda mostrar lo que se hizo efectivamente y qué se requirió en la visita una vez realizada. Cosas como Plan de Visitas, Herramientas Usadas, Desperfectos, Trabajos realizados, etc. Cosas que se desprenden del relevamiento del sistema, pero que no has incluido en tu post.
De todos modos, para lo que preguntas, creo que esto es suficiente.
Cita: Por eso pregunto... todas las tablas necesariamente tienen q tener al menos una Llave Primaria?
Una última aclaración: Una tabla solo puede tener una única clave primaria. Jamás puede tener dos o más. Lo que sí puede tener es lo que se denominan
claves candidatas, y que se expresan en las tablas como índices de tipo UNIQUE.
En MySQL los indices UNIQUE pueden ser usados como referencia para las FK, pero no son PK en el estricto sentido.
UNIQUE es uno de los atributos de una PK, pero no a la inversa, porque un indice UNIQUE puede contener NULL y una PK jamás.