Dados mestres e identidade

🌐 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)

Imagem gerada com IA

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

Guia de estudo do capítulo 6 do curso Data Architect. Leia primeiro os seis módulos, incluindo o passo a passo do Checkpoint 1; esta página ajuda você a verificar o que ficou.

Sobre este guia de estudo. Ele foi construído apenas a partir do conteúdo deste curso e da lista de objetivos publicada no guia do exame da Salesforce. Ele nunca se baseia em questões reais do exame e não afirma saber o que cai na prova. Se você já fez o exame, por favor não me envie as questões: o contrato de certificação proíbe compartilhá-las, e decorar respostas é, de qualquer forma, o jeito errado de se tornar arquiteto.

Este capítulo carrega a seção de Gerenciamento de Dados Mestres do exame (5%) e a visão única do cliente de Gerenciamento de Dados Salesforce. É uma seção pequena em peso, mas suas ideias (autoridade, correspondência, sobrevivência) aparecem dentro de muitos outros cenários. Os números da plataforma mudam, então confira os atuais antes de contar com eles.

Para o exame

Marque conforme avança. Cada item tem um link para onde é ensinado.

MDM-2: um golden record e um sistema da verdade

• Sei que a autoridade é atribuída por atributo, não por registro: uma conta pode ter campos mestres no ERP e campos mestres no Salesforce. (A verdade pertence a um atributo)
• Pergunto onde cada atributo é criado, editado e referenciado, e qual é a latência das mudanças dele. (Criado, editado, referenciado, e com que rapidez?)
• Consigo construir um mapa de autoridade, e sei que o dono do negócio e o sistema com autoridade não são a mesma coisa. (Construa um mapa de autoridade)
• Sei que a autoridade pode mudar ao longo do ciclo de vida (um prospect no Salesforce vira um cliente governado pelo ERP), e que uma cópia não é autoridade. (A autoridade muda ao longo do ciclo de vida, Uma cópia não é autoridade)

MDM-1: técnicas de MDM

• Conhecimento para o exame: conheço os quatro estilos de implementação de MDM, registry, consolidação, coexistência e centralizado: o que cada um centraliza e se ele devolve valores às fontes. (Os quatro lado a lado)
• Consigo distinguir os quatro estilos de MDM: registry, consolidação, coexistência e centralizado, e escolher o mais leve que resolve o problema. (Os quatro lado a lado)
• Sei que um modelo de dados canônico harmoniza a estrutura, mas não decide a autoridade. (Um modelo comum não é uma verdade comum)
• Conheço a ordem: harmonizar, depois corresponder, depois consolidar. (Harmonize, depois corresponda, depois consolide)
• Sei que os limiares refletem a tolerância ao erro, e que o enriquecimento precisa de procedência. (Limiares, revisão e enriquecimento)
• Conhecimento para o exame: conheço o gerenciamento de hierarquias: a Conta pai constrói a hierarquia (a visualização do Lightning mostra até 2.000 contas, sem contas pessoais), as hierarquias muitas vezes têm autoridade dividida, e uma empresa pode ter várias hierarquias válidas. (Hierarquias também são dados mestres, Uma hierarquia, vários mestres)

MDM-3: escolher os atributos vencedores

• Mantenho correspondência, mesclagem e sobrevivência separadas. (Correspondência, mesclagem e sobrevivência)
• Conheço as regras de sobrevivência: o mais recente, o mais frequente, a prioridade da fonte, e que cada regra precisa de um dono. (Sobrevivência: qual valor vence?)
• Sei que uma correspondência não exige uma mesclagem, e só mesclo quando há um vencedor claro, decidindo antes o que acontece com os filhos. (Uma correspondência não exige uma mesclagem, Minha regra de mesclagem: um vencedor claro)
• Conhecimento para o exame: sei o que faz uma mesclagem de contas no Salesforce: até três registros, um principal, mantidos o Criado por e a Data de criação mais antigos, os outros para a Lixeira, e os objetos de ponto de contato não mesclados em contas pessoais. (O que uma mesclagem no Salesforce realmente faz)

SDM-3: uma visão única do cliente

• Sei que a resolução de identidade do Data 360 vincula perfis de origem num perfil unificado e mantém os vínculos de volta: o mais próximo de um registry. (A resolução de identidade responde “quem?”)
• Conhecimento para o exame: conheço as regras de correspondência do Data 360: todos os critérios de uma regra precisam corresponder, e qualquer regra pode corresponder; mais critérios para precisão, menos para consolidação. (Regras de correspondência)
• Conheço os métodos de correspondência (Exact, Exact Normalized, Fuzzy com três níveis de precisão): um método menos preciso aumenta a consolidação, e o risco de correspondências falsas. (Regras de correspondência)
• Conhecimento para o exame: sei que as regras de reconciliação (Last Updated, Most Frequent, Source Priority) decidem o que o perfil unificado mostra, mas não alteram as fontes; os pontos de contato não são reconciliados. (Reconciliação ainda não é gerenciamento de dados mestres)
• Consigo escolher entre gerenciamento de duplicatas, resolução de identidade e uma plataforma de MDM dedicada conforme o trabalho. (Três ferramentas para três trabalhos)

MDM-4 e dados de mão dupla

• Sei que dados de mão dupla não significam dois mestres: uma edição no Salesforce de um campo de que o ERP é dono é uma solicitação, então projete solicitar → validar → aceitar → publicar, com um estado pendente. (Dados de mão dupla não significam dois mestres, Quando o mestre diz não)
• Sei como evitar loops e colisões: distinguir uma mudança de origem do eco dela, e decidir quais campos viajam juntos como uma única transação. (Loops e colisões)
• Para um cliente em dois ERPs, consigo escolher entre uma hierarquia, contas pares ou uma conta com um filho por ERP, conforme o quanto o cliente mantém os ERPs dele sincronizados. (Um cliente, dois ERPs, Pergunte como eles mantêm os ERPs sincronizados)

Checkpoint 1: juntando a Parte 1

• Conhecimento para o exame: sei quais licenças externas trazem compartilhamento padrão: Customer Community Plus e Partner Community, que precisam de papéis para os usuários externos; a Customer Community usa conjuntos de compartilhamento. (Quem vê o quê, e quem precisa de licença)

Além do exame

O exame é o piso, não o teto. Estes são os hábitos deste capítulo de que um arquiteto precisa, quer alguma pergunta trate deles ou não.

• “Fonte única da verdade”: qual verdade? É uma arquitetura da verdade, não um registro.
• Torne a autoridade visível no esquema: um prefixo para os campos de que outro sistema é dono.
• A confiança precisa de mais do que um valor: origem, última confirmação, quem alterou.
• Comece pelo problema, não pelo produto de MDM. MDM é uma decisão de negócio sobre autoridade.
• Vincular não é gerenciar dados mestres.
• Onde as correspondências falsas custam caro, corresponda de menos de propósito.
• Mantenha as duplicatas de cargas externas quando você puder precisar rastrear a origem.
• Um perfil unificado é um mapa. Um golden record é uma decisão.
• Apresentação não é autoridade.
• Unificar a identidade não apaga as fronteiras de segurança.
• O mais difícil são os bidirecionais. A autoridade compartilhada não é o problema; a autoridade ambígua é.
• Nunca deixe uma solicitação rejeitada virar uma verdade concorrente.
• Um campo que diz que isto é dado mestre é o que define a editabilidade, não um tipo de registro.
• Nós não controlamos os ERPs. Controlamos como os representamos no Salesforce.

Palavras para conhecer

Termo	Em uma linha
Gerenciamento de dados mestres (MDM)	Estabelecer e governar a identidade e os valores com autoridade dos dados-chave entre sistemas
Mapa de autoridade	Para cada atributo: quem o cria, quem é dono da decisão, qual sistema tem autoridade, quem pode alterá-lo
Golden record	Uma decisão governada sobre quais valores têm autoridade
Golden record híbrido	Um registro com alguns atributos mestres em outro lugar e copiados para dentro, e outros de propriedade local
Registry	MDM que vincula registros como a mesma entidade sem alterar as fontes
Consolidação	MDM que combina os dados de forma central, normalmente para análise, sem devolvê-los
Coexistência	MDM que decide o valor mestre e o publica de volta nas fontes
MDM centralizado	MDM em que os dados governados são criados no mestre e distribuídos
Modelo de dados canônico	Uma forma corporativa acordada para um conceito, usada para mapear os sistemas entre si
Harmonização	Tornar os valores comparáveis: formatos, códigos e abreviações padrão
Correspondência	Decidir se registros representam a mesma coisa
Sobrevivência (survivorship)	Regras sobre qual valor vence quando as fontes discordam
Registro principal	Numa mesclagem do Salesforce, o registro que sobrevive e mantém seus campos ocultos e somente leitura
Método de correspondência	Como um critério de correspondência do Data 360 compara valores: exact, exact normalized ou fuzzy
Resolução de identidade	A correspondência de perfis de origem em perfis unificados, no Data 360
Perfil unificado	Um conjunto de chaves que vincula os registros de origem que representam uma pessoa ou empresa
Regras de reconciliação	Regras do Data 360 sobre qual valor um perfil unificado mostra
Hierarquia com autoridade dividida	Uma hierarquia cujos ramos pertencem a sistemas diferentes

Teste-se

Cenários curtos no estilo do curso. Decida sua resposta antes de abrir.

1. “O Salesforce é a nossa fonte única da verdade sobre o cliente.” O que você pergunta?

Qual verdade? A autoridade é por atributo: o ERP pode ser dono da razão social, do endereço de cobrança e do limite de crédito, enquanto o Salesforce é dono do executivo de contas e do nível de sucesso. Construa um mapa de autoridade. Releia A verdade pertence a um atributo.

2. Os atendentes precisam ver que um contato do Salesforce é a mesma pessoa que comprou on-line. Ninguém precisa que os sistemas mudem. Qual estilo de MDM?

Um registry: vincule os registros como uma identidade sem alterar as fontes, que é o que faz a resolução de identidade do Data 360. Escolha o padrão mais leve que resolve o problema. Releia Registry: me diga quem é quem.

3. A sobrevivência está configurada como “o mais recente vence” para todos os campos. Alguém altera a cópia no Salesforce da razão social de que o ERP é dono. O que acontece, e o que está errado?

O valor mais novo vence, e a cópia passa por cima da autoridade. “O mais recente” é uma afirmação sobre confiança que serve para alguns atributos (um celular) e não para outros. Onde o mapa de autoridade diz que o ERP é dono do campo, o ERP vence. Releia Sobrevivência: qual valor vence?.

4. Registros de clientes legados são importados e correspondem a contas existentes. Mesclar?

Cuidado. Uma correspondência não exige uma mesclagem, e mesclar destrói os IDs legados e os valores mais antigos que você pode precisar rastrear. Vincule-os, a menos que haja um vencedor claro e a duplicata não acrescente nada de que você precise. Releia Minha regra de mesclagem: um vencedor claro.

5. O perfil unificado no Data 360 mostra Dallas. A equipe diz que Dallas agora é o valor de ouro para todos os sistemas. É?

Não. A reconciliação decide o que o perfil unificado mostra; ela não altera as fontes nem toma uma decisão de dados mestres. Se todo sistema precisa usar um valor governado, isso é coexistência ou MDM centralizado, com um dono. Releia Reconciliação ainda não é gerenciamento de dados mestres.

6. Correspondência de registros médicos versus registros de marketing: as mesmas regras?

Não. Uma correspondência falsa no marketing manda a oferta errada; em dados médicos, combina os históricos de duas pessoas. Defina o rigor pelo custo de errar, e corresponda de menos onde misturar custa caro. Releia O custo de errar.

7. Os vendedores querem atualizar no Salesforce um endereço de cobrança de que o ERP é dono. Como você projeta isso?

Como uma solicitação, não uma edição: o Salesforce envia o valor proposto, o ERP o valida e aceita, e publica de volta o valor com autoridade. Mantenha um estado pendente até lá, e trate rejeição, colisões e ecos. Releia Dados de mão dupla não significam dois mestres.

8. Na Steve Trucking, o mesmo João Silva aparece nos manifestos de dois Parceiros varejistas. Unificá-lo?

Não, de propósito. Um parceiro nunca pode ver os Destinatários de outro, e uma identidade unificada é a ponte por onde isso vaza. Corresponda de menos onde misturar custa caro; se um parceiro quiser o reconhecimento de recorrentes, limite-o só àquele parceiro. Releia Eu unificaria os Destinatários entre parceiros?.

9. Um vendedor envia uma rua nova para um endereço de propriedade do ERP enquanto, no mesmo minuto, alguém no ERP muda a cidade. O que você decide?

Se o endereço viaja como uma única transação. Se viaja, os campos vão todos juntos ou nenhum vai, e a solicitação é rejeitada porque o endereço mudou nesse meio-tempo. Decida isso antes da primeira colisão, e lembre-se de que a solicitação está pedindo para mudar o valor do ERP, não mudando esse valor. Releia Loops e colisões.

10. Um cliente tem um mesmo cliente em dois ERPs, e ninguém mantém os dois registros sincronizados. Vendas quer uma única conta. O que você recomenda?

Não uma única conta. Se eles não conseguem manter os registros sincronizados nos próprios ERPs, o Salesforce não consegue fazer isso por eles: represente-os como contas pares ou como uma hierarquia, e mostre a estrutura que vendas já conhece. Uma conta com um filho por ERP exige um cliente que mantenha os valores compartilhados sincronizados. Releia Pergunte como eles mantêm os ERPs sincronizados.

Para saber mais

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (em inglês, consultado em 2026-09-25): a lista oficial de objetivos e seus pesos. Sempre confira a versão atual antes de agendar o exame.
• A seção Para saber mais de cada módulo lista a documentação da Salesforce por trás dos seus fatos, com a data de consulta.