Cita: 1, si los campos de la tabla rfc los anexo los campos a la tabla cliente entonces creo no seria lo optimo ya que sólo el 5% de los clientes tienen rfc
2. si agrego una llave foranea de la tabla rfc hacia la tabla de cliente necesitaria tener un un rfc inventando que no contenga datos
3. si agrego una llave foranea a la tabla rfc con el id de la tabla cliente no sé si sea correcto
Sin saber qué es un RFC en tu contexto (no todos somos de México), aunque supongo que puede tratarse de alguna condición o documento comercial (recuérdalo para aclarar qué son las cosas cuando son propias de tu país y en otros llevan diferente nombre).
Basándome en la suposición de que se trata de algún tipo de requerimiento comercial o impositivo, lo que surge de esto es simple:
1) Si tener o no un RFC es opcional, pero integra el conjunto de datos
posibles de un cliente, entonces es un atributo
opcional, por lo que o bien lo pones en una tabla distinta o lo pones como campo que admita NULL (relación no identificatoria), manejando la relación programáticamente.
2) Si el RFC se da con clientes que pueden diferenciarse además por otro atributo o conjunto de atributos, entonces lo que tienes son
dos categorías diferentes de clientes. En ese caso se deben crear
tres tablas (Cliente, ClienteComercial, ClienteComún, por ejemplo), donde la tabla Cliente contenga solamente atributos comunes a todos los tipos.
Nota: En el caso de crear una tabla distinta para guardar esas RFC, el esquema es exactamente lo que pones en la tercera opción: La PK del cliente va en la tabla del RFC, ya que en ese caso actúa de PK de la segunda tabla.
Pero en ese caso la existencia de la tabla carece de sentido y es preferible crear el RFC como atributo de Cliente y darle valor por default NULL...
Nota final: El modelo gráfico que pones tiene un defecto grave: Estás creando redundancia de datos en la tabla RFC, por cuanto si la relación entre ambas es 1:1, ¿para qué guardas de vuelta los mismos datos en las dos tablas (calle, colonia, etc...)?
