Resposta direta
A implementação exige uma chave de ligação com regra explícita, não a busca pelo campo perfeito. A definição começa pelo uso: qual decisão depende de unir os registros. A escolha recai sobre atributos estáveis e verificáveis, como documento validado, contrato vigente ou código interno. Quando não há candidato confiável, a ligação vira exceção com revisão humana. O vínculo precisa de dono, versão e histórico, pois é um dado operacional. Também importa definir o tratamento quando a fonte muda: registrar a alteração, reavaliar vínculos afetados e preservar a trilha. Sem essas escolhas, a chave existe no sistema, mas a operação continua dependendo de planilha e memória.
- Objetivo
- Orientar implementação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata o vínculo como registro operacional com vigência, dono e exceções, em vez de resumir a solução a um campo comum.
O que a chave precisa provar
Uma chave de ligação não é apenas um campo em comum. É a evidência de que dois registros tratam do mesmo cliente, produto, contrato ou ativo. Essa evidência pode vir de um documento único, de um código interno estável ou de uma combinação de atributos. Quanto mais forte a evidência, menor a dependência de conferência manual. Quando ela é fraca, a ligação precisa ser tratada como hipótese, não como fato.
A escolha da chave exige verificar se o atributo identifica a entidade ou apenas se repete; se permanece estável ao longo do tempo; e se há fonte responsável por validá-lo. Nome e endereço, isolados, não bastam para provar identidade. Documento fiscal, contrato ou código de origem podem servir, desde que tenham regra de normalização e verificação. A chave é tão confiável quanto o processo que a mantém.
Da regra à operação
Na ausência de campo comum, a implementação começa com uma tabela de correspondência, não com uma rotina automática. Essa tabela registra a chave de origem, a chave de destino, a regra aplicada, a data de vigência e o responsável pela ligação. Para bases que já nasceram sem campo comum, a tabela funciona como a ponte durável entre os cadastros. A rotina automática só deve assumir os casos que a regra classifica como inequívocos.
Os casos não inequívocos entram em fila de exceções, com critério de prioridade e de encerramento. A fila precisa de dono, prazo de resposta e registro do motivo da decisão. A conferência manual tem custo e não escala; por isso a prioridade deve seguir o impacto na operação, não a ordem de chegada. Quando um cadastro muda, a ligação afetada é reavaliada e a versão anterior fica no histórico. Sem isso, a chave se torna mais uma verdade paralela, sem relação com a operação.
O que a chave não resolve
A chave não corrige o cadastro de origem. Se o documento está errado, o nome está incompleto ou duas áreas usam critérios diferentes para criar o registro, a ligação apenas torna o problema visível. Também não decide qual versão é a verdadeira. Essa decisão continua sendo de negócio e precisa de dono. Em bases com histórico longo, a chave pode ligar registros que representam a mesma entidade em momentos distintos; nesse caso, o vínculo precisa indicar vigência, não apenas igualdade.
Há situações em que a ligação não compensa. Quando o cruzamento é eventual e não sustenta uma decisão recorrente, a conferência pontual pode ser suficiente. Quando a qualidade da fonte é baixa demais, criar a chave sem antes tratar a origem apenas desloca o esforço para a fila de exceções. Nenhuma chave elimina a necessidade de definir quem responde pelo cadastro. A ligação é um meio de operação, não um substituto para a governança do dado.
Recurso prático
Escolha da chave conforme a evidência disponível
| Evidência disponível | Chave de ligação indicada |
|---|---|
| Documento fiscal único, com dígito verificador e regra de normalização | Documento como chave, com verificação de formato e duplicidade |
| Contrato ou pedido comum às duas bases | Identificador do contrato, com vigência e parte responsável |
| Código interno presente em uma base e ausente na outra | Tabela de correspondência entre códigos, mantida com histórico |
| Sem identificador comum; restam nome, endereço e data | Chave composta, tratada como hipótese e enviada à revisão |
| Mesma entidade com grafias diferentes ao longo do tempo | Chave composta com histórico de versões, sem sobrescrever a ligação anterior |
O erro mais comum é escolher a chave pela facilidade de acesso ao campo, não pela capacidade de provar a identidade. A ligação parece resolvida, mas atende apenas aos casos óbvios.
Sobre o que está escrito aqui
Conceitos relacionados: chave composta · atributo estável · tabela de correspondência · fila de exceções · vigência do vínculo. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Projeto de implementação, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- Integrações, sistemas e qualidade de dados — Página central do tema
- Planilhas divergentes: alternativas para conf… — planilhas divergentes
- Planilhas divergentes: como dimensionar o des… — planilhas divergentes
Páginas relacionadas
O mesmo problema em outro objetivo
- Cadastros sem chave em comum: onde a ligação se perde — Diagnosticar
- Chave ausente: como ligar cadastros sem identificador comum — Organizar um processo
- Cadastros sem chave comum: o que cada ligação exige — Comparar alternativas
- Chave de ligação ausente: o que medir antes de corrigir — Explicar medição
- Chave de ligação ausente: o que exigir do fornecedor — Orientar avaliação e contratação
Outras leituras em Integrações, sistemas e qualidade de dados
- Falhas silenciosas: fluxo para conter e sanar o dado — Critérios para organizar a custódia, triagem e correção retroativa de inconsistências operacionais que passam despercebidas pelos sistemas.
- Cadastro sem regra de deduplicação: o que exigir no contrato — O que negociar, testar e aceitar na regra de deduplicação de um sistema de cadastro, incluindo o que o fornecedor declara e o que fica fora do escopo.
- Cadastro sem chave única: como escolher o identificador — Descreve como definir identificador próprio, regra de correspondência e responsável quando o cadastro existe em sistemas sem chave comum.
- Campo livre no cadastro: fechar o padrão de preenchimento — O que uma regra de preenchimento precisa definir, quem responde por ela e como medir a aderência antes de expandir o padrão para outros campos.
- Sincronização sem janela: como definir o corte — Trata da definição de corte por evento, do controle de versão do lote e da responsabilidade sobre atrasos quando a operação não pode parar.