Como Definir Uma Pessoa

Definir uma pessoa em sistema vai muito além de colocar nome e CPF

A maioria das pessoas começa errado. Pega os campos óbvios e pronto, modelo criado. Nome, sobrenome, data de nascimento, documento. Isso funciona na superfície, até o momento em que o sistema precisa lidar com realidade. E a realidade nunca entra cleanly. como definir uma pessoa envolve decidir no mínimo três camadas: identidade, atributos e relacionamentos. Se você pular alguma, vai passar horas consertando depois.

A camada de identidade

Todo cadastro começa com um identificador único. O erro clássico é usar o CPF como chave primária. CPF tem exceções. Tem cpf de não-naturalizado brasileiro que é válido mas não segue o padrão esperado. Tem estrangeiro sem CPF. Tem pessoa jurídica que precisa ser tratada de forma diferente. No meu caso, trabalhando em um sistema de cadastro para uma operadora de saúde, nos anos 2010, nos deparamos com um problema específico: pacientes com CPF inválido devido a erros de digitação no DATASUS. A solução foi criar um identificador interno auto gerado, uma UUID, e tratar o CPF como dado adicional validável, não como chave de identidade. A validação ficou a cargo de um serviço externo que consultava a receita federal em tempo real. Isso reduziu em cerca de 40% os cadastros duplicados que tínhamos antes.

A camada de atributos

Aqui é onde a maior parte do trabalho acontece. Atributos são tudo que descreve a pessoa. Mas a divisão mais útil que eu aprendi na prática é entre atributos estruturais e atributos semânticos. Atributos estruturais são aqueles que mudam raramente: nome completo, data de nascimento, nacionalidade, estado civil. Eles precisam de tipagem forte. Uma data de nascimento deve ser tipo date, não string. Isso evita que alguém coloque 31/13/1990 e o sistema aceite. Atributos semânticos são os que carregam significado de negócio: perfil do paciente, nível de risco, categoria de cliente. Esses mudam com frequência e precisam de versionamento. Se um atributo semântico é alterado, você precisa saber quem alterou, quando e por quê. Sem isso, você não consegue auditar nada.

Um ponto que poucos mencionam: atributos compostos. Endereço é o exemplo mais óbvio. Rua, número, complemento, bairro, cidade, estado, CEP. Não quebre isso em colunas separadas na mesma tabela se puder evitar. Use uma subestrutura JSON ou uma tabela filho. Do contrário, quando o usuário mudar de cidade, você precisa atualizar seis campos individualmente e a consistência vira um problema constante.

A camada de relacionamentos

Pessoas não existem isoladamente. Em qualquer sistema, uma pessoa é definida também pelas relações que mantém. Parentesco, vínculo empregatício, responsável financeiro, contato de emergência. Essas relações precisam ser mapeadas explicitamente. O que eu vejo sempre acontecendo é alguém definir relacionamentos como campos binários dentro do registro da pessoa. Tem responsável_sim/não, tem parentesco_id. Isso escala mal. Quando o mesmo responsável aparece em dez registros diferentes, você tem dez pontos de atualização. Uma mudança de nome do responsável vira uma manutenção distribuída. A abordagem correta é modelar relações como entidades próprias. Uma tabela de vínculos com pessoa_origem, pessoa_destino, tipo_vínculo, data_inicio, data_fim e status. Isso resolve problemas de histórico e permite perguntas como "quem era o responsável desta pessoa em janeiro de 2023".

O problema que ninguém avisa

A definição de pessoa que você fizer vai encontrar resistência no mundo real. Existe uma divergência persistente entre como a lei define pessoa física e como o cotidiano as trata. Pessoas transgênero alteram nome e gênero no registro civil, mas o sistema pode ter sido construído sobre gênero biológico. Pessoas com nomes compostos raros quebram validações de regex. Crianças sem documento formal precisam existir no sistema. Idosos com múltiplos nomes sociais vivem entre dois registros porque o sistema não suporta aliases. A solução prática que encontrei foi separar nome legal de nome social e tratar ambos como campos first class. O nome legal é o que vai para documentos e conformidade regulatória. O nome social é o que o sistema usa para interface. Ambos coexistem. Quando precisei implementair isso em um prontuário eletrônico, levei duas semanas ajustando permissões de acesso, porque o nome social não deveria ser visível para todos os usuários do sistema. Isso virou regra: nome social só para perfis autorizados.

Um insight que não está em lugar nenhum

O maior erro é tratar a definição de pessoa como problema resolvido na fase de modelagem. Ela nunca é. Sistemas reais descobrem gaps após meses de operação. O que funciona bem é manter a estrutura aberta para extensão. Use um schema flexível para atributos customizados que o negócio possa adicionar sem alterar a tabela principal. Um par chave-valor é suficiente para isso. Chave como "risco_clínico", valor como JSON com subcampos. Também é fundamental decidir desde o início se seu sistema é monádico ou descentralizado na definição de pessoa. Monádico significa que existe uma única fonte da verdade. Descentralizado significa que diferentes módulos podem manter suas próprias versões. A maioria dos sistemas começa monádico evolve para descentralizado por necessidade, sem planejamento. O resultado são inconsistências que levam meses para serem percebidas e corrigidas.

Onde esse modelo falha

Não tente aplicar essa abordagem para definições simples demais. Se você está construindo um formulário de newsletter que pede apenas nome e email, a modelagem em três camadas é overengineering. Para esses casos, uma tabela plana com quatro campos já é tudo que você precisa. O modelo também exige governança. Sem um time responsável por aprovar novas relações e atributos customizados, a estrutura flexível vira bagunça em poucas semanas. Cada novo campo sem supervisão adiciona complexidade que ninguém quer manter. Se o seu cenário envolve mais de 50 milhões de registros, considere separar dados estáticos de dados transacionais. Person_data estático é legível por leitura, atualizado raramente. Person_activity é alto write volume. Juntar tudo numa mesma tabela gera fragmentação e degradamento de performance perceptível após 18 meses de operação.

O que fazer antes de codificar

Liste os tipos de pessoa que o sistema precisa representar. Pessoa física comum, criança, estrangeiro, falecido, paciente, dependente. Cada tipo tem regras diferentes. Não tenta unificar tudo num único registro genérico. Defina quem pode modificar cada campo. Nome legal só pode ser alterado por processos auditados. Nome social pode ser atualizado pelo próprio usuário logado. Data de nascimento precisa de comprovação documentada para alterações. Estabeleça a política de retenção. Dados de pessoas falecidas devem permanecer no sistema? Por quanto tempo? Quais campos podem ser anonimizados? Isso não é opcional, é requisito legal em praticamente qualquer jurisdição.

A definição de pessoa é um trabalho contínuo, não um artefato final. Comece com a estrutura mínima viável, monitore onde o sistema encontra atrito no uso real, e ajuste conforme necessário. O modelo que você implementar no mês um não será o modelo do mês doze, e isso é esperado.