Associar não é gerir dados mestres

🌐 Também em 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · 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 com IA. Ainda não revisto pela comunidade. Ler em inglês

Capítulo 6 de Data Architect, Parte 1: Tornar-se arquiteto de dados. Anterior: Qualidade e governação de dados.

«Precisamos de uma fonte única da verdade.» É uma das frases mais repetidas em arquitetura, e uma das menos examinadas. Da verdade sobre quê? Pegue numa conta. O ERP pode ser dono da sua denominação social, da morada de faturação e do limite de crédito; o Salesforce, do gestor de conta e do nível de suporte; uma plataforma de consentimento, das preferências de marketing. Três autoridades num registo, e isso é normal. Por isso, quando alguém diz «o Salesforce é a nossa fonte única da verdade sobre o cliente», a minha pergunta seguinte é sempre: que verdade?

Este capítulo trata de responder a essa pergunta de propósito. A autoridade é atribuída atributo a atributo. Associar registos não é geri-los como dados mestres. E o Salesforce dá-lhe ferramentas diferentes para trabalhos diferentes: gestão de duplicados e fusão 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 têm de ser decididos uma vez e devolvidos a todo o lado. 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_.
• Os prospects são diferentes. Vivem no Salesforce antes de o ERP os conhecer; a autoridade do ERP vale depois da conversão.
• O registry é a norma em projetos Salesforce, seguido da consolidação e da coexistência; o MDM centralizado puro é raro.
• Funda só quando houver um vencedor claro. Mantenha os duplicados de cargas externas quando puder precisar de rastrear a origem; a fusão destrói esse histórico. E decida o que acontece aos filhos: movê-los, não os carregar ou mantê-los num registo inativo.
• Um perfil unificado é um mapa; um golden record é uma decisão. Isto 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, faça correspondências a menos de propósito.
• Três ferramentas para três trabalhos: fusão, resolução de identidade, MDM.
• As hierarquias têm autoridade dividida. Decida a autoridade ramo a ramo.
• «O mais difícil são os bidirecionais.» Uma integração nos dois sentidos não cria dois mestres. Decida que 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 registo.
• Nós não controlamos os ERPs. Controlamos a forma como os representamos no Salesforce: um cliente em dois ERPs torna-se uma hierarquia, pares, ou uma conta com um filho por ERP, conforme o cliente mantenha os seus ERPs mais ou menos sincronizados.

Três ferramentas para três trabalhos

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

O percurso deste capítulo

Seis módulos e um desafio, cada um a sustentar-se 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 gerir dados mestres. Registry, consolidação, coexistência e centralizado, e porque é que um modelo comum não é uma verdade comum.
3. Correspondência, fusão e sobrevivência (survivorship). O custo de uma correspondência falsa, o que faz realmente uma fusão no Salesforce (e o que acontece aos 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 porque é que um perfil unificado não é um golden record.
5. Quando a autoridade é partilhada. Pedidos versus atualizações, ciclos 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 primeiro o desafio: desenhe e defenda o design da Parte 1, depois compare-o 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 a 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

• Que sistema tem autoridade sobre cada atributo importante, e como isso aparece no modelo.
• Que estilo de gestão de dados mestres serve cada domínio de dados, e quanta autoridade recebe a camada de dados mestres.
• Quando fundir, quando associar, 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 nos dois sentidos e as hierarquias partilhadas 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. Fazer corresponder demais torna-se um incidente de privacidade, e um agente que «atualiza o cliente» tem de gravar no sistema de registo 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).