Evitar la dependencia circular

Estoy desarrollando una aplicación de gestión de viajes. El diseño en cuestión es algo como lo siguiente:

Cada persona en un tour es designada como un Viajero. Cada viajero tiene un pasaporte. Ahora, un Viajero puede ser Miembro Principal o Miembro Secundario, dependiendo de si es el jefe de la familia o no. Un Miembro Principal decide cosas como TourPackage, la cantidad total para su familia que viaja, etc. Un Miembro Secundario depende del Miembro Principal mientras viaja. Por lo tanto, si se elimina un MainMember, también se deben eliminar todos sus Submembers.

Por lo tanto, un viajero tiene un pasaporte. (Relación uno a uno) Un Viajero es un Miembro Principal o Miembro Secundario. (uno a cero / uno entre Traveler-MainMember y Traveler-SubMember) Un MainMember puede tener varios Submiembros. (uno a muchos) Un miembro secundario tiene solo un miembro principal. (muchos a uno)

Mi ERD actual es algo como lo siguiente.

Como puede ver, las tres tablas, Traveler, MainMember y SubMember, han formado una dependencia circular. Sin embargo, no estoy seguro de si afectará mi aplicación. Si elimino un Traveler que es un miembro principal, entonces 1. Se elimina un registro de Traveler. 2. Se elimina su registro MainMember relevante. 3. Los registros de Submember dependientes de MainMember se eliminan. 4. Se eliminan los registros de Viajeros de los Submiembros.

Aunque no parece ser un problema, como una eliminación de Traveler-MainMember siempre eliminará solo Traveler-SubMember (s). Aún así, tengo un mal presentimiento sobre esto.

¿Alguien puede guiarme a un mejor diseño?

ACTUALIZACIÓN -

Mientras esperaba las respuestas, se me ocurrió otro diseño, basado en la respuesta de @Daveo. Básicamente, Traveler contiene una clave externa autorreferencial. Sería utilizado por los registros de Submiembros para identificar a sus padres.

Aquí está el ERD para eso.

Ahora, como no había ningún problema de dependencia circular en mi diseño anterior, como señaló @Branko, me gustaría saber qué diseño es mejor.

Además, ¿qué diseño sería mejor implementar a través de Hibernate? Creo que el segundo enfoque podría llevar a la complejidad al implementar a través de Hibernate.

También agradecería algunos consejos sobre los patrones de implementación (herencia en entidades de Hibernate, etc.) para el diseño que prefiera.

Respuestas a la pregunta(2)

Su respuesta a la pregunta