O livro de Craig Larman "Applying UML with Patterns" descreve as 3 soluções comuns para este problema.

Seus exemplos não são particularmente úteis - não há razão lógica para ter 3 maneiras diferentes de gerenciar o nome de uma pessoa em seu banco de dados (embora isso aconteça regularmente devido à estranheza de importação/exportação de dados).

No entanto, é muito comum haver uma entidade "pessoa" que pode ser um funcionário (com employee_id), um contato (com um link para a tabela de clientes em potencial) ou um cliente (com um customer_id e um link para a tabela de pedidos) .

No livro de Larman, ele dá 3 soluções.

Uma tabela para governar todos Aqui, você cria uma única tabela com todas as colunas conhecidas. Isso cria uma tabela confusa e empurra a responsabilidade de conhecer as regras de persistência de cada subclasse para a camada de aplicativo - o banco de dados não impõe a necessidade de os clientes terem um customer_id. No entanto, torna as junções muito mais fáceis - qualquer tabela que precise se vincular a uma pessoa pode, bem, vincular à tabela de pessoas.

Tabela de superclasse Isso limpa as coisas extraindo os atributos comuns em uma única tabela - por exemplo "person" - e envia os campos específicos da subclasse para as tabelas de subclasse. Assim, você pode ter "pessoa" como a tabela da superclasse e as tabelas "contato", "funcionário" e "cliente" com os dados específicos da subclasse. As tabelas de subclasses têm uma coluna "person_id" para vincular de volta à tabela de superclasses. Isso é mais complexo - normalmente requer uma junção adicional ao recuperar dados - mas também muito menos propenso a erros - você não pode corromper acidentalmente o modelo de dados com um bug que grava atributos inválidos para "funcionário".

Tabela por subclasse - isso é o que você descreveu. Ele introduz uma quantidade razoável de duplicação no modelo de dados, e muitas vezes você tem junções condicionais - "juntar-se na tabela x se tipo de pessoa =y", o que pode tornar o código de acesso a dados complicado.