Bueno, mi idea es un esquema que apunta hacia redes sociales, no a arboles genealógicos (no debo haber leído correctamente tu problema); en ese sentido tu idea está más cercana a lo que necesitas.
De todos modos, la declaración del tipo de relación y/o su categoría, pueden no ser mandatorios, ya que se los puede perfectamente hacer nulables en cierto caso, o bien hacer lo que se hace normalmente: crear un registro de tipo de relación "No Declarada" o "No definido", que se resuelve en la implementación.
Eso evita problemas de obligatoriedad.
Pero sí veo una posibilidad que te ahorraría necesidades de sistema y en realidad es bastante simple: Una sola tabla.
Siendo que un miembro sólo puede tener un padre y una madre,´y que a partir de este hecho puede definirse todo el resto de los parentescos, lo único que se necesita para cumplir con eso es que la propia tabla Miembros posea dos FK nulables apuntando a si misma.
Nada más.
La lógica es la misma que se aplica para el caso de los empleados de un departamento: Todo empleado tiene un jefe, y el jefe no tiene jefes (es NULL).
Siguiendo ese esquema, todo miembro tiene padres, aunque puede darse que alguno de ellos, o los dos, no se hada indicado, caso en que es NULL. Así, determinar quienes son hermanos es simple: tods aquellos que comparten padre y madre, o al menos uno de ambos. Los primos son aquellos que comparten generacionalmente los están en el nivel anterior a los padres, etc.
Creo que esa sería la solución más simple de todas, y es una solución muy habitual en las bases de datos.
Cita: En cuanto a lo de que no necesito una ID cuando las relaciones son únicas efectivamente tienes razón pero me he acostumbrado a trabajar dandole un número id a cada tabla, me resulta mas fácil de ver. Supongo que es una manía mia.
Personalmente, te recomiendo que dejes de lado ese método, porque tarde o temprano puede generar problemas. Al crear una ID propia abres la puerta a la posibilidad de que se puedan duplicar los datos en un alta erróneo, porque la PK siempre sería única aunque se produzca la duplicación.
Y si declaras un indice UNIQUE sobre los otros campos... Eso es una CC, entonces ¿qué sentido tendría crear ese ID incremental? Ninguno, sería redundante. Sólo ocuparía espacio.
En general, el uso de ID incrementales es una costumbre de programadores, y no es aconsejable en BBDD que pueden evolucionar, o negocios, ya que tarde o temprano se tienen problemas al consolidar bases de datos o en la administración de backups históricos, por ejemplo.
Es mejor siempre usar lo que propone el modelo E-R: Uno o más atributos propios de la entidad, y sólo recurrir a IDs numéricos (u otros) si llegados a la 3FN aún no se vislumbra una CC.
Pero.. como siempre, es una decisión del desarrollador.
