El libro de Craig Larman "Applying UML with Patterns" describe las 3 soluciones comunes a este problema.
Sus ejemplos no son particularmente útiles:no hay una razón lógica para tener 3 formas diferentes de administrar el nombre de una persona en su base de datos (aunque esto sucede regularmente debido a la rareza de la importación/exportación de datos).
Sin embargo, es muy común que haya una entidad de "persona" que podría ser un empleado (con employee_id), un contacto (con un enlace a la tabla de prospectos) o un cliente (con un customer_id y un enlace a la tabla de pedidos) .
En el libro de Larman, da 3 soluciones.
Una mesa para gobernarlos a todos Aquí, crea una sola tabla con todas las columnas conocidas. Esto crea una tabla desordenada y empuja la responsabilidad de conocer las reglas de persistencia de cada subclase a la capa de la aplicación; la base de datos no impondrá la necesidad de que los clientes tengan un ID_cliente. Sin embargo, hace que las uniones sean mucho más fáciles:cualquier tabla que necesite vincularse a una persona puede, bueno, vincularse a la tabla de personas.
Mesa de superclase Esto limpia las cosas al extraer los atributos comunes en una sola tabla, p. "persona" - y empuja los campos específicos de la subclase a las tablas de la subclase. Por lo tanto, es posible que tenga "persona" como tabla de superclase y tablas de "contacto", "empleado" y "cliente" con los datos de subclase específicos. Las tablas de subclase tienen una columna "person_id" para vincular de nuevo a la tabla de superclase. Esto es más complejo:generalmente requiere una unión adicional al recuperar datos, pero también es mucho menos propenso a errores:no puede corromper accidentalmente el modelo de datos con un error que escribe atributos no válidos para "empleado".
Tabla por subclase - Esto es lo que has descrito. Introduce una buena cantidad de duplicación en el modelo de datos y, a menudo, tiene uniones condicionales:"únase a la tabla x si el tipo de persona =y", lo que puede dificultar el código de acceso a los datos.
