Yo creo que lo mejor que puedes hacer antes de ponerte a armar las tablas, es entender las reglas de negocio del sistema. Es decir: Analizar el sistema.
Si lo meditas lo que tienes es:
- Existen N personas que son miembros de la organización (sea lo que sea esta)
- Cada miembro puede tener cero o muchas relaciones con otros miembros.
- Cada relación es de una cierta categoría: Familiar, Amistad, Social, Comercial.
- Cada relación posee una denominación que la define (hermano/a, cónyuge, socio/a, amigo/a).
- Una la categoría de una relación puede ser considerada como un atributo del tipo.
- Cada relación {A, B}, aunque sea simétricamente idéntica a {B, A}, representa dos relaciones distintas, siendo la primera declarada por A y la segunda por B. Es decir, una relación se expresa desde el punto de vista de uno sólo de los miembros.
Entonces, para hacer un sistema que sea flexible, necesitas cuatro tablas:
Cita: Miembro(miembro_id, nombre, apellido, direccion, localidad, ...)
TipoRelación(tipo_relacion_id, descripcion_tipo, categoria_rel_id)
CategoriaRelacion(categoria_rel_id, cat_descripcion)
Relacion_Miembros(miembro_id, miembro_id_rel, tipo_relacion_id, ...otros datos adicionales)
Te hago notar algunas cosas:
- No necesitas crear un ID para la relación, porque el ID es una clave compuesta por ambos ID de los miembros.
- Sólo se requiere discriminante (no necesariamente un DI numérico), si hay más de una instancia posible del mismo par de miembros.
- Si un miembro puede declarar más de un tipo de relación con otro, entonces la clave debe ser compuesta por tres campos (miembro_id, miembro_id_rel, tipo_relacion_id).
¿Se entiende?