Este uno-a-muchos relación puede ser interpretada en Inglés sencillo como esto ...
una persona tiene una o más responsabilidades,
Y
Cada responsabilidad pertenece a exactamente una persona .
Ahora, dependiendo de qué rdbms está utilizando, implementaría esto como una relación de clave externa.
Primero necesita agregar una columna a RESPS que apunte a la tabla de personas.
Llamemos a esta nueva columna PERSON_ID.
Ahora podemos declarar la relación, el código podría ser algo como esto;
ALTER TABLE [Responsibilities] ADD CONSTRAINT FOREIGN KEY (PERSON_ID)
REFERENCES [Person] (ID)
Y esta declaración de una restricción de clave externa significaría que de ahora en adelante no se puede agregar una responsabilidad sin especificar una persona que posee esa responsabilidad.
Pero aún podría agregar una persona sin responsabilidades (todavía) ya que no hay restricciones en la tabla de personas.
Tenga en cuenta que esto es todo tipo de académicos, ya que en la vida real las responsabilidades se comparten.
En otras palabras, una persona puede tener una o más responsabilidades, pero cada responsabilidad puede pertenecer a una o más personas.
Esto se conoce como una relación muchos a muchos, y es un problema de diseño de bases de datos bien conocido con una solución bien definida, que no entraré ahora ya que es tangencial a su pregunta.
Para una relación de uno a muchos anterior, las responsabilidades tendrán PersonID como clave externa. ¿Puede la tabla Person tener ResponsibilityID como clave foránea también? No me suena bien, pero necesito saber el motivo por el cual es incorrecto tener claves externas en las tablas padre e hijo. – ATHER