Vincular não é gerenciar dados mestres

🌐 Também em 28 idiomas

English · Español · 日本語 · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Traduzido por IA. Ainda não revisado pela comunidade. Ler em inglês

Capítulo 6 de Data Architect, Parte 1: Tornando-se arquiteto de dados. Anterior: Qualidade e governança de dados.

“Precisamos de uma fonte única da verdade.” É uma das frases mais repetidas em arquitetura, e uma das menos examinadas. Da verdade sobre o quê? Pegue uma conta. O ERP pode ser dono da razão social, do endereço de cobrança e do limite de crédito dela; o Salesforce, do executivo de contas e do nível de suporte; uma plataforma de consentimento, das preferências de marketing. Três autoridades num registro, e isso é normal. Então, quando alguém diz “o Salesforce é a nossa fonte única da verdade sobre o cliente”, minha próxima pergunta é sempre: qual verdade?

Este capítulo trata de responder a essa pergunta de propósito. A autoridade é atribuída atributo por atributo. Vincular registros não é gerenciá-los como dados mestres. E o Salesforce lhe dá ferramentas diferentes para trabalhos diferentes: gerenciamento de duplicatas e mesclagem dentro de uma org; a resolução de identidade do Data 360 para uma visão única entre fontes; uma plataforma de MDM dedicada quando os valores precisam ser decididos uma vez e devolvidos a todos os lugares. Ele termina com o Checkpoint 1, em que a Parte 1 se junta na Steve Trucking.

Imagem gerada com IA.

As posições deste capítulo

• Verdade por atributo. Pergunte onde cada dado é criado, editado e referenciado, e com que rapidez muda. Mostre a autoridade externa no esquema com um prefixo de sistema, como sap_ ou erp_.
• Prospects são diferentes. Eles vivem no Salesforce antes de o ERP conhecê-los; a autoridade do ERP vale depois da conversão.
• O registry é a norma em projetos Salesforce, depois a consolidação e a coexistência; o MDM centralizado puro é raro.
• Mescle só quando houver um vencedor claro. Mantenha as duplicatas de cargas externas quando você puder precisar rastrear a origem; a mesclagem destrói esse histórico. E decida o que acontece com os filhos: movê-los, não carregá-los ou mantê-los num registro inativo.
• Um perfil unificado é um mapa; um golden record é uma decisão. Isso pode confundir as pessoas: a resolução de identidade cria um indivíduo unificado, mas não um golden record.
• O rigor da correspondência é uma decisão de risco. Onde misturar custa caro, corresponda de menos de propósito.
• Três ferramentas para três trabalhos: mesclagem, resolução de identidade, MDM.
• As hierarquias têm autoridade dividida. Decida a autoridade ramo por ramo.
• “O mais difícil são os bidirecionais.” Uma integração de mão dupla não cria dois mestres. Decida quais campos viajam juntos como uma única transação antes da primeira colisão.
• Torne os dados mestres visíveis. Um campo que diz que isto é dado mestre (a chave do ERP ou um indicador) é o que define a editabilidade, não um tipo de registro.
• Nós não controlamos os ERPs. Controlamos como os representamos no Salesforce: um cliente em dois ERPs vira uma hierarquia, pares, ou uma conta com um filho por ERP, conforme o quanto o cliente mantém os ERPs dele sincronizados.

Três ferramentas para três trabalhos

O trabalho	A ferramenta	O que ela faz com as fontes
Duplicatas dentro de uma org, com um vencedor claro	Gerenciamento de duplicatas e mesclagem	Mescla até três registros; os outros vão para a Lixeira
Uma identidade e uma visão única entre fontes	Resolução de identidade do Data 360	Vincula-as; não altera nenhuma delas (um registry)
Um valor governado, devolvido a cada sistema	Uma plataforma de MDM dedicada	Decide o valor e o distribui (coexistência ou centralizado)

O caminho por este capítulo

Seis módulos e um desafio, cada um se sustentando sozinho.

1. Uma fonte da verdade por atributo. O mapa de autoridade, o golden record híbrido e os sinais de confiança.
2. As quatro formas de gerenciar dados mestres. Registry, consolidação, coexistência e centralizado, e por que um modelo comum não é uma verdade comum.
3. Correspondência, mesclagem e sobrevivência (survivorship). O custo de uma correspondência falsa, o que uma mesclagem no Salesforce realmente faz (e o que acontece com os filhos), e a sobrevivência como uma afirmação sobre confiança.
4. Um mapa não é uma decisão. Regras de correspondência e métodos de correspondência, regras de reconciliação, e por que um perfil unificado não é um golden record.
5. Quando a autoridade é compartilhada. Solicitações versus atualizações, loops e colisões, hierarquias com autoridade dividida, e um cliente em dois ERPs.
6. O desafio do Checkpoint 1, depois Checkpoint 1: Steve Trucking, o que eu arquitetaria. Tente o desafio primeiro: desenhe e defenda o design da Parte 1, depois compare com o meu e veja o que muda em relação ao panorama do capítulo 4.

Quando terminar, teste-se com o guia de estudo do capítulo: uma lista para o exame, os hábitos que vão além dele, as palavras para conhecer e algumas perguntas. Ele encerra a Parte 1; o guia de estudo da Parte 1 junta os seis capítulos.

O que um arquiteto decide aqui

• Qual sistema tem autoridade sobre cada atributo importante, e como isso aparece no modelo.
• Qual estilo de gerenciamento de dados mestres serve a cada domínio de dados, e quanta autoridade a camada de dados mestres recebe.
• Quando mesclar, quando vincular, e quem é dono de cada regra de sobrevivência.
• Quão rigorosa a correspondência deve ser, com base no custo de uma correspondência falsa.
• Onde os dados de mão dupla e as hierarquias compartilhadas precisam de fronteiras explícitas.

Além do exame: os agentes precisam de uma identidade sobre a qual agir, e isso aumenta o que está em jogo nos dois sentidos. Corresponder demais vira um incidente de privacidade, e um agente que “atualiza o cliente” precisa gravar no sistema de registro de cada atributo, não no perfil unificado. Cada módulo termina com o que a IA muda.

Para saber mais

• Salesforce Architects, Data 360 Architecture (opens in a new tab) (em inglês), consultado em 2026-10-14.
• Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab), Identity Resolution Match Methods (opens in a new tab) e Identity Resolution Reconciliation Rules (opens in a new tab) (em inglês), consultados em 2026-10-14.

Próximo: a Parte 2 começa com Designing for Scale (coming soon).