Funcionário pode ser papel de Pessoa Física?

Foi recomendado, nesta pergunta, manter a relação entre Pessoa Física e Funcionário como generalização (Funcionário estende Pessoa Física). Não entendi por que não cabe nesse caso fazer uma relação de papel (Funcionário é papel de Pessoa Física), pelo menos da forma como entendo que papéis funcionam.

Foi recomendado na pergunta, não na resposta. Eu acho um erro e disse que Funcionario é um papel de PessoaFisica. Até porque se essa pessoa também for um cliente e for uma especialização, portanto herança, a única solução é ter duas instâncias da mesma pessoa, o que é uma maluquice conceitual, ou guardar espaço na pessoa para ser tudo o que ela puder ser.

Pegando esse segundo caso tem duas formas de fazer: uma é manter tudo junto e a outra é ter referências externas.

Mantendo junto em memória só dá com enorme desperdício, e em DB, ou tem esse problema também, ou precisa de uma formato sem esquema, o que pode trazer outros problemas.

Mantendo separado em memória isso não é lá muito complicado, em um banco de dados é exatamente o que o modelo de papéis faz. É muito mais óbvio fazer assim, então não é herança de verdade, inclusive porque é algo dinâmico que o programador não tem controle.

A solução que as pessoas fazem é ter mais de uma pessoa entre os dados representando a pessoa pessoa real. É um erro crasso óbvio que "ninguém" vê.

Não pode fazer assim nunca? Pode, como otimização ou se realmente fizer sentido. Proibido nunca é.

Como otimização de acesso você pode manter nos papéis todos os dados da Pessoa para não ter que olhar mais de uma tabela, mas passa ter um custo de escrita (que pode ser vantajoso) já que qualquer alteração de dados na Pessoa tem que obrigatoriamente e de preferência atomicamente atualizar todos os papéis que aquela pessoa terá.

Um detalhe de implementação de papéis é que geralmente é mais interessante você ter uma mecanismo que indique quais papéis aquela pessoa possui ativamente. Isso pode ser algumas colunas (aí só com alteração programática para adicionar algum novo, e pode ter algum desperdício de espaço), pode ser schemaless com um "array" de papéis (nem todos DBs permitem facilmente), ou pode ter uma tabela extra que faça a amarração (custo muito caro de acesso). Na memória não é muito diferente, exceto que ela tem mais dificuldade de ser sem esquema sem uma tabela auxiliar, mas em compensação uma tabela extra custa barato neste dispositivo.

Papel é só uma simples composição, assim como você pode ter N vendas de um produto, você terá N papéis de uma pessoa. De fato o normal será N bem baixo, na maioria dos casos deve ser 1. É de se pensar o que compensa mais.

Uma justificativa pode ser que daí fica estranho a entidade Vendendor ser "papel de um papel", isto é, Vendedor ser papel do Funcionário, que por sua vez é papel de Pessoa Física. Mas gostaria de um esclarecimento maior.

Exatamente, um papel ser ligado a um papel não faz sentido, quem tem o papel de Vendedor? A Pessoa. No caso pode ser física ou jurídica (mesmo que seu modelo nunca aceite isso quem garante que no futuro não aceitará?), já quebrou o modelo de Vendedor estar vinculado ao Funcionario. Mas se alguém disser que é diferente, ok, cada situação real pode pedir algo diferente.

Nos comentários tem um modelo de roles que não me agrada, não sei se é bem isso que eu chamo de papel. Mas pode ser só que esteja confuso para o que eu já sei. De qualquer forma tem exemplos bem ruins, cheio de coisas aparentemente desnecessários.

Não vejo mal em Pessoa Física ter um papel

Eu também não.

O que eu disse foi que uma PessoaFisica não deveria ser uma papel de Pessoa. Mas fiz a ressalva que esta visão é válida em algum cenário.

Concretamente você, ou tem uma PessoaFisica, ou tem uma PessoaJuridica. Pessoa é naturalmente um conceito abstrato, que pode dar a impressão de não ser porque a gente tende acreditar que pessoa é um ser humano. Estamos falando de personalidade segundo a legislação. Não existe só Pessoa, do ponto de vista legal não tem esse objeto, ninguém é só isso, não tem descrições para o que seria esse objeto. Para física ou jurídica tem: relaciona os documentos necessários, um nome, endereço, sexo ou atividade, tem data de nascimento/fundação, etc.

Não cabe ter um papel em algo que sequer existe. Cabe ter um conceito concreto baseado em algo que pode ser generalizado. Na verdade em banco de dados relacionais é normal que Pessoa evapore quando se modela o físico. No máximo você terá uma view que permite acessar PessoaFisica ou PessoaJuridica sem distinção.

Mas está dito lá que não é o fim do mundo que tenha Pessoa concreta, só acho ineficiente para pouco ou nenhum benefício, você teria sempre que acessar duas tabelas para pegar tudo o que precisa na maioria dos casos. Esse é um caso que não tem o risco de ter uma mesma entidade sendo representada por dois objetos no roll dados manipulado. Papéis não são só bons, são necessários para não virar bagunça. O simples sempre deve ser preferível e nesse caso o simples é não ter papel. Quem quer complicar que deve justificar que problema ele quer resolver com a complicação.

Eu sei justificar o uso de papéis entre as pessoas concretas. Em parte é o que está aí em cima.

Eu tendo a não usar relações 1:1 no modelo (não confundir 1:1 nos dados), acho elas desnecessárias na maior parte dos casos, e onde costuma ser é pra resolver outro problema criado equivocadamente. Novamente, se acha que deve usar algo assim, tem que justificar.

Já viu a pergunta Qual a vantagem de um relacionamento 1:1?? Lá fala de 1:1 de dados e não de modelo, e se analisar bem, exceto pelo primeiro, todos os outros são por necessidades de mecanismos, não tem a ver com o modelo conceitual. Eu falo qual é o modelo ideal, se o mecanismo exige outra coisa faz parte de outro escopo.

Eu só me preocupo com isso porque sei a dificuldade que é mudar algo quando foi mal conceituado (e sempre fazemos isto, não tem como fazer perfeito sempre), e gosto de fazer otimizado. Se puder deixar de lado uma dessas coisas já importa menos, se puder deixar de lado ambos, aí tudo vale.

Como o Bacco disse nos comentários, modelagem tem que ser baseada em fatos. O problema é que muitos modelos são feitos em suposições, e visões da realidade que não são reais. E é fácil cair nessa armadilha. Eu vivo caindo em domínios que ainda não trabalhei, e mesmo nos que trabalhei geram alguns erros.