Dados mestres e identidade

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

Imagem gerada com IA

Traduzido com IA. Ainda não revisto pela comunidade. Ler em inglês

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

Sobre este guia de estudo. Foi construído apenas a partir do conteúdo deste curso e da lista de objetivos publicada no guia do exame da Salesforce. Nunca se baseia em perguntas reais do exame e não afirma saber o que sai na prova. Se já fez o exame, por favor não me envie as perguntas: o contrato de certificação proíbe partilhá-las, e decorar respostas é, de qualquer forma, a maneira errada de se tornar arquiteto.

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

Para o exame

Marque à medida que 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 registo: 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 suas mudanças. (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 torna-se 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 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 fazer corresponder, depois consolidar. (Harmonize, depois corresponda, depois consolide)
• Sei que os limiares refletem a tolerância ao erro, e que o enriquecimento precisa de proveniência. (Limiares, revisão e enriquecimento)
• Conhecimento para o exame: conheço a gestão de hierarquias: a Conta principal constrói a hierarquia (a vista 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, fusão e sobrevivência separadas. (Correspondência, fusão 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: que valor ganha?)
• Sei que uma correspondência não exige uma fusão, e só fundo quando há um vencedor claro, decidindo antes o que acontece aos filhos. (Uma correspondência não exige uma fusão, A minha regra de fusão: um vencedor claro)
• Conhecimento para o exame: sei o que faz uma fusão de contas no Salesforce: até três registos, um principal, mantidos o Criado por e a Data de criação mais antigos, os outros para a Reciclagem, e os objetos de ponto de contacto não fundidos em contas pessoais. (O que faz realmente uma fusão no Salesforce)

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

• Sei que a resolução de identidade do Data 360 associa perfis de origem num perfil unificado e mantém as ligações às fontes: o mais próximo de um registry. (A resolução de identidade responde a «quem?»)
• Conhecimento para o exame: conheço as regras de correspondência do Data 360: todos os critérios de uma regra têm de 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 contacto não são reconciliados. (A reconciliação continua a não ser gestão de dados mestres)
• Consigo escolher entre gestão de duplicados, resolução de identidade e uma plataforma de MDM dedicada conforme o trabalho. (Três ferramentas para três trabalhos)

MDM-4 e dados nos dois sentidos

• Sei que dados nos dois sentidos não significam dois mestres: uma edição no Salesforce de um campo de que o ERP é dono é um pedido, por isso projete pedir → validar → aceitar → publicar, com um estado pendente. (Dados nos dois sentidos não significam dois mestres, Quando o mestre diz não)
• Sei como evitar ciclos e colisões: distinguir uma mudança de origem do seu eco, e decidir que campos viajam juntos como uma única transação. (Ciclos 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 cliente mantenha os seus ERPs mais ou menos sincronizados. (Um cliente, dois ERPs, Pergunte como mantêm os ERPs sincronizados)

Checkpoint 1: juntar a Parte 1

• Conhecimento para o exame: sei que licenças externas trazem partilha padrão: Customer Community Plus e Partner Community, que precisam de funções para os utilizadores externos; a Customer Community usa conjuntos de partilha. (Quem vê o quê, e quem precisa de licença)

Além do exame

O exame é o chão, 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»: que verdade? É uma arquitetura da verdade, não um registo.
• 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. O MDM é uma decisão de negócio sobre autoridade.
• Associar não é gerir dados mestres.
• Onde as correspondências falsas custam caro, faça correspondências a menos de propósito.
• Mantenha os duplicados de cargas externas quando puder precisar de 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 partilhada não é o problema; a autoridade ambígua é.
• Nunca deixe um pedido rejeitado tornar-se uma verdade concorrente.
• Um campo que diz que isto é dado mestre é 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.

Palavras a conhecer

Termo	Numa linha
Gestão 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, que sistema tem autoridade, quem o pode alterar
Golden record	Uma decisão governada sobre que valores têm autoridade
Golden record híbrido	Um registo com alguns atributos mestres noutro lugar e copiados para dentro, e outros de propriedade local
Registry	MDM que associa registos como a mesma entidade sem alterar as fontes
Consolidação	MDM que combina os dados de forma central, normalmente para análise, sem os devolver
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 empresarial acordada para um conceito, usada para mapear os sistemas entre si
Harmonização	Tornar os valores comparáveis: formatos, códigos e abreviaturas padrão
Correspondência	Decidir se registos representam a mesma coisa
Sobrevivência (survivorship)	Regras sobre que valor ganha quando as fontes discordam
Registo principal	Numa fusão do Salesforce, o registo que sobrevive e mantém os seus campos ocultos e só de 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 associa os registos de origem que representam uma pessoa ou empresa
Regras de reconciliação	Regras do Data 360 sobre que valor mostra um perfil unificado
Hierarquia com autoridade dividida	Uma hierarquia cujos ramos pertencem a sistemas diferentes

Teste-se

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

1. «O Salesforce é a nossa fonte única da verdade sobre o cliente.» O que pergunta?

Que verdade? A autoridade é por atributo: o ERP pode ser dono da denominação social, da morada de faturação e do limite de crédito, enquanto o Salesforce é dono do gestor de conta e do nível de sucesso. Construa um mapa de autoridade. Releia A verdade pertence a um atributo.

2. Os agentes de atendimento precisam de ver que um contacto do Salesforce é a mesma pessoa que comprou online. Ninguém precisa que os sistemas mudem. Que estilo de MDM?

Um registry: associe os registos 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: diga-me quem é quem.

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

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

4. Registos de clientes legados são importados e correspondem a contas existentes. Fundir?

Cuidado. Uma correspondência não exige uma fusão, e fundir destrói os IDs legados e os valores mais antigos que pode precisar de rastrear. Associe-os, a menos que haja um vencedor claro e o duplicado não acrescente nada de que precise. Releia A minha regra de fusão: um vencedor claro.

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

Não. A reconciliação decide o que o perfil unificado mostra; não altera as fontes nem toma uma decisão de dados mestres. Se todos os sistemas têm de usar um valor governado, isso é coexistência ou MDM centralizado, com um dono. Releia A reconciliação continua a não ser gestão de dados mestres.

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

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

7. Os comerciais querem atualizar no Salesforce uma morada de faturação de que o ERP é dono. Como projeta isto?

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

8. Na Steve Trucking, o mesmo João Silva aparece nos manifestos de dois Parceiros retalhistas. 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 escaparia. Faça correspondências a menos onde misturar custa caro; se um parceiro quiser o reconhecimento de recorrentes, limite-o só a esse parceiro. Releia Eu unificaria os Destinatários entre parceiros?.

9. Um comercial envia uma rua nova para uma morada que pertence ao ERP enquanto, no mesmo minuto, alguém no ERP muda a cidade. O que decide?

Se a morada viaja como uma única transação. Se viaja, os campos vão todos juntos ou nenhum vai, e o pedido é rejeitado porque a morada mudou entretanto. Decida isso antes da primeira colisão, e lembre-se de que o pedido está a pedir para mudar o valor do ERP, não a mudá-lo. Releia Ciclos e colisões.

10. Um cliente tem um mesmo cliente em dois ERPs, e ninguém mantém os dois registos sincronizados. As vendas querem uma única conta. O que recomenda?

Não uma única conta. Se não conseguem manter os registos sincronizados nos seus próprios ERPs, o Salesforce não o consegue fazer por eles: represente-os como contas pares ou como uma hierarquia, e mostre a estrutura que as vendas já conhecem. Uma conta com um filho por ERP exige um cliente que mantenha os valores partilhados sincronizados. Releia Pergunte como 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 os seus pesos. Confira sempre a versão atual antes de marcar o exame.
• A secção Para saber mais de cada módulo lista a documentação da Salesforce por trás dos seus factos, com a data de consulta.