Resposta direta
A resposta é construir uma chave de ligação própria, em vez de supor que os sistemas já compartilham um identificador. A definição começa pela entidade de negócio, como cliente, produto ou contrato, e pelos atributos que podem indicar que dois registros tratam do mesmo objeto. A correspondência pode ser exata, por documento ou código, ou aproximada, por nome, endereço e outros sinais. Cada vínculo precisa de dono, critério de aceite, origem, data e versão da regra. Relações de um para muitos devem ser preservadas, não forçadas em um único registro. Sem esse controle, o cruzamento cria uma aparência de integração que não resiste à operação.
- Objetivo
- Organizar um processo
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata da construção e da manutenção de uma chave de ligação própria, inclusive em relações um-para-muitos.
A entidade antes do campo
A chave ausente costuma aparecer como problema técnico, mas começa na definição de negócio. O mesmo cliente pode ser uma unidade de cobrança, uma conta de serviço ou um grupo de compra. O mesmo produto pode ter códigos diferentes no catálogo, no estoque e no faturamento. Antes de escolher campos de comparação, é preciso definir qual entidade será ligada e qual relação a ligação representa. Sem essa definição, o cruzamento aproxima registros que apenas parecem iguais.
A relação também tem cardinalidade. Um cliente pode ter vários contatos, endereços e contratos; um produto pode ter várias apresentações e códigos de fornecedor. A chave de ligação não deve forçar tudo em um registro único. Ela pode ser uma tabela de correspondência que guarda pares, o tipo de relação e o contexto em que o vínculo vale. Essa estrutura preserva a operação real e evita que a integração trate exceções legítimas como erro.
Regra, exceção e responsável
A primeira separação é entre correspondência exata e aproximada. Documento, código interno ou combinação de campos com regra estável permitem uma ligação direta. Quando esses sinais não existem, a comparação por nome, endereço e outros atributos exige normalização e um critério claro de aceite. Um campo isolado raramente serve, porque pode ser compartilhado, reutilizado ou estar incompleto. A regra aplicada precisa ficar registrada com versão.
Os casos duvidosos não devem ser resolvidos por conveniência. Eles vão para uma fila de exceções, com responsável e critério de decisão: ligar, não ligar ou pedir mais informação. O vínculo aprovado guarda origem, data e regra. A operação também precisa medir quantos vínculos são revertidos e quantas exceções envelhecem sem decisão. Esses indicadores mostram se a chave continua confiável ou se a regra perdeu aderência ao cadastro real.
O que a chave não resolve
A chave de ligação não corrige o cadastro de origem. Se o mesmo cliente entra com nomes diferentes, se o endereço muda sem histórico ou se o código do produto é reutilizado, a ligação herda esse problema. Também não decide qual registro está certo. Essa decisão continua com o responsável pelo dado e com a área que usa o cadastro. Em alguns casos, os atributos disponíveis não permitem uma ligação segura. Forçar o vínculo nessas situações cria uma associação falsa que a operação não consegue explicar.
A correspondência aproximada tem erro. Nenhum critério de semelhança elimina esse risco, e áreas reguladas ou financeiras podem exigir confirmação manual antes de usar o vínculo. A chave também não substitui a validação na entrada: se o processo continua criando registros sem identificação, a lacuna volta na próxima carga. O que a abordagem organiza é a ligação entre bases existentes, com regra, exceção e responsabilidade. Ela não resolve a qualidade do dado como um todo, nem elimina a necessidade de manutenção.
Recurso prático
Chave de ligação: decisões e registros mínimos
- Entidade de negócio definida: cliente, produto, contrato ou ativo, com o significado usado na operação.
- Fonte de verdade indicada para cada atributo que participa da correspondência.
- Regra de normalização para nome, documento, endereço e contato, aplicada antes da comparação.
- Tipo de relação permitido: um para um, um para muitos ou muitos para muitos.
- Critério de aceite e de rejeição para correspondência exata e aproximada.
- Responsável por aprovar vínculos e resolver os casos sem correspondência.
- Registro de origem, data, regra aplicada e versão em cada vínculo.
- Rotina de revisão quando o cadastro de origem muda ou a regra é substituída.
- Fila de exceções com dono e critério de encerramento, sem vínculo automático forçado.
O erro mais comum é tratar a chave como campo técnico e não como decisão de negócio; sem responsável e versão da regra, ninguém consegue explicar por que dois registros foram ligados.
Sobre o que está escrito aqui
Conceitos relacionados: chave de ligação · regra de correspondência · entidade de negócio · relação um-para-muitos · tabela de correspondência. 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
- Sincronização entre sistemas: o que decidir a… — sistemas desconectados
- Falhas silenciosas em integrações: como perce… — falhas silenciosas
Páginas relacionadas
O mesmo problema em outro objetivo
- Cadastros sem chave em comum: onde a ligação se perde — Diagnosticar
- 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: como construir a ponte — Orientar implementaçã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
- Fonte da verdade: qual sistema responde por cada dado — Como definir, para cada campo crítico, qual sistema é a fonte da verdade, quem pode escrever e quem responde pela correção.
- 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.
- Relatório sem validação cruzada: como fechar a conferência — Rotina de validação cruzada em relatórios: fonte de referência, chave de ligação, tolerância por campo, registro de divergência e responsável pela conferência.
- Cliente duplicado entre áreas: como medir a sobreposição — Define o que conta como cliente duplicado, qual base serve de referência e como acompanhar a sobreposição entre áreas ao longo do tempo
- Sistemas isolados: o que checar antes de comprar outro — Critérios operacionais para avaliar contratos de software quando a arquitetura atual opera sem comunicação direta entre áreas.