Estás planteando cosas que tienen que ver no tanto con el
modelo de datos (que como te lo describo, es universal), sino con el
diseño del sistema para el que ese modelo de datos se crea.
Es decir: Me estás describiendo
cosas que tienen relación con las Reglas de Negocio, no con los datos. En este punto ya me deberías decribir con más precisión en qué consiste el sistema, porque para el modelo descripto en tu segundo post el modelo propuesto es perfectamente aplicable.
Entendamos esto: Un registro de una tabla primaria es siempre reutilizable, porque jamás queda cancelado porque se haya asignado una profesión (o proyecto) a una persona. En todo caso, donde queda restringido (y no cancelado) es en la tabla PROFESION_PERSONA, que es la que controla la unicidad entre una persona determinada y la profesión asignada. Siendo PK la combinación de ambas FK no se puede repetir jamás una combinación de IDs iguales.
Si lo que quieres es restringir desde la tabla misma que una persona peuda tener más de una profesión (o proyecto), eso es simplemente definir un índice UNIQUE sobre el campo persona_id en ESA tabla.
El hecho de que se use menos del 15%& de los registros, o se use el 99% de los registros es irrelevante para el modelo de datos. Eso es problema de implementación, no de la base. La base de datos tiene que ser flexible para cualquier uso presente y futuro.
Cita: realmente no se insertarán cosas como 'medico', sino como 'proyecto x',
Esto también es irrelevante, en tanto creees una tabla PROYECTO_PERSONA, para controlar la relación (con lo que ya estamos hablando de cuatro tablas), y en esa asignación, la tabla PROYECTO debe forzosamente tener una FK con el persona_id del jefe de proyecto.
Con este último punto se refuerza mi hipótesis de que para darte un pantallazo más o menos certero, se requieren detalles de lo que se pretende administrar y así darte sugerencias más precisas.
