Arquitetura de dados Salesforce

🌐 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 3 do curso Data Architect. Leia primeiro os dez módulos; 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 é o capítulo em que o modelo encontra a plataforma, e carrega boa parte do exame. Alimenta as duas maiores secções, Modelação de Dados e Design de Bases de Dados, e Gestão de Dados Salesforce, cada uma com um quarto do exame. Os números da plataforma mudam: a lista traz os que os módulos citam, com a data em que foram consultados. Aprenda para que serve cada limite, e confira o número atual antes de contar com ele.

Para o exame

Marque à medida que avança. Cada item tem um link para onde é ensinado.

DM-1: projetar o modelo de dados na plataforma

• Sei que o Salesforce é uma plataforma orientada por metadados e multitenant: um objeto são metadados, não uma tabela nova, e cada objeto ganha as suas APIs a partir do momento em que existe. (Os metadados são a planta, A sua API veio com o objeto)
• Sei que os limites do governador existem para que um inquilino não se apodere dos recursos partilhados. (Não se pode apoderar do elevador)
• Consigo ler os modelos de dados padrão: a conversão de Lead em Conta, Contacto e Oportunidade; um produto da oportunidade (Opportunity Product) aponta para uma entrada do catálogo de preços (Price Book Entry), que aponta para o Product2; e Caso, Ativo e direito (Entitlement) do lado do serviço. (O modelo de vendas (Sales), O modelo de serviço (Service))
• Sei o que decide o ecrã New Custom Object (novo objeto personalizado): um nome de registo do tipo Texto ou numeração automática; a Object Classification (classificação do objeto: com partilha, Bulk API e Streaming API ligados, é um objeto Enterprise Application; com eles desligados, um objeto Light Application); e Allow Search (permitir pesquisa), desligado por defeito. (O ecrã New Custom Object)
• Consigo ler um nome de API: objetos e campos padrão não têm prefixo nem sufixo; objetos e campos personalizados terminam em __c; um pacote gerido acrescenta o seu prefixo de namespace (abc__); e um campo que acrescenta ao objeto de um pacote ganha __c, mas nunca o prefixo do fornecedor. (Prefixos e sufixos)
• Consigo aplicar o teste do encaixe limpo para um objeto padrão, e sei quando o significado ou o peso apontam para um objeto personalizado. (O teste do encaixe limpo)
• Sei para que servem o Ativo e as contas pessoais, que uma conta pessoal ocupa cerca do dobro do armazenamento de uma conta empresarial, e que, depois de ativadas, as contas pessoais não podem ser desativadas. (O Ativo é um bom exemplo, Contas pessoais, Quando a pessoa é a conta?)
• Escolho um tipo de campo pelo comportamento de que preciso (um número de frota não é um Número), e sei que a data/hora é armazenada em GMT e mostrada no fuso horário de cada leitor, por isso é comparada com intervalos, não com igualdade. (Um número nem sempre é um número, Data, Data/Hora e Hora)
• Sei que o texto vem em dois tipos: até 255 caracteres no registo (indexável, utilizável como único ou como ID externo), e texto Longo ou Rich acima disso, sem índice, sem filtro no WHERE e sem fórmulas. (A família do texto)
• Sei quando usar um Nome com numeração automática, e que não é o ID de registo. (Um humano precisa de o identificar?)
• Sei como um ID externo permite a uma integração fazer upsert, e carregar filhos pelo ID externo do pai. (IDs externos)
• Sei quando um valor deve ser derivado por uma fórmula, e quando é um facto histórico que tem de ser armazenado. (Armazenado ou derivado?)
• Sei a diferença entre um objeto de junção lógico (a ideia de modelação: um objeto que liga dois outros num muitos-para-muitos, com atributos próprios) e um objeto de junção do Salesforce (Salesforce Junction Object: um objeto personalizado com duas relações mestre-detalhe), e que a Salesforce quer dizer o segundo. (Dois pais de largura)
• Conheço a relação hierárquica: uma relação de pesquisa especial, só no objeto Utilizador, como o campo padrão Gestor (Manager), que não pode voltar ao mesmo utilizador, direta ou indiretamente, e que não é a hierarquia de funções. (Hierárquico)
• Sei a diferença entre uma relação de pesquisa e uma mestre-detalhe: propriedade, partilha, pai obrigatório, eliminação em cascata, resumos de totalização. (Relação de pesquisa, Mestre-detalhe)
• Sei que a mestre-detalhe não pode ser criada num objeto que já tem dados (crie uma relação de pesquisa, preencha, converta), só volta a ser relação de pesquisa sem resumos de totalização no mestre, e precisa de Permitir reatribuição de pai para mover um filho. (O filho pode mudar de pai?)
• Conheço a forma da plataforma para a mestre-detalhe: até três níveis de detalhe personalizados de profundidade (uma relação de pesquisa pode quebrar a cadeia em qualquer ponto), e dois pais mestre-detalhe de largura. Num objeto de junção do Salesforce, a mestre-detalhe criada primeiro é a principal (proprietário, aparência, divisão), a segunda é a secundária, e o acesso precisa dos dois pais: o mais restritivo ganha. (Três níveis de profundidade, Dois pais de largura)
• Conheço as três escolhas de uma relação de pesquisa quando o pai é eliminado: limpar o campo (o comportamento por defeito), bloquear a eliminação, ou eliminar em cascata, que fica desligada até a Salesforce a ativar e ignora a partilha. (Relação de pesquisa)
• Sei que uma autorrelação tem de ser uma relação de pesquisa, e conheço as duas que já vêm prontas: a Conta principal da Conta e o Caso principal (Parent Case) do Caso. (Autorrelações)
• Sei que o recálculo de totalizações pode levar tempo, que um resumo de totalização não pode usar uma fórmula com NOW(), TODAY() ou uma referência entre objetos, e que não se escolhe mestre-detalhe só para ganhar um resumo de totalização: um campo armazenado, mantido atualizado por um flow ou trigger, é a alternativa. (Os resumos de totalização são úteis, mas não são de graça)
• Conheço os limites de relações que o módulo cita: duas mestre-detalhe por objeto; 40 campos de relação por defeito (no máximo 50); 25 resumos de totalização por defeito (no máximo 40). (As relações também têm limites)

DM-2: um modelo que respeita a partilha e escala

• Sei que um filho mestre-detalhe não tem proprietário nem tabela de partilha próprios: o acesso segue o mestre. (A propriedade vem por arrasto)
• Conheço o desequilíbrio pai-filho: a orientação da Salesforce é de no máximo cerca de 10 mil filhos num único pai. (A pergunta dos 10 mil filhos)
• Conheço o desequilíbrio de propriedade (um utilizador dono de mais de 10 mil registos de um objeto) e a orientação: espalhar a propriedade, ou manter esse utilizador fora da hierarquia de funções ou sozinho no topo, e fora dos grupos públicos usados por regras de partilha. (A propriedade pode tornar-se um problema de escala)
• Conheço a tabela de partilha: o objeto de partilha de um objeto personalizado é Object__Share; um objeto de detalhe não tem nenhum, o seu acesso vem do mestre; e uma mudança de proprietário remove as partilhas manuais, mas mantém a partilha Apex com o seu próprio motivo. (A tabela de partilha)
• Consigo decidir quem é dono dos registos que integrações e agentes criam, conforme a propriedade determine ou não a partilha. (Quem é dono dos registos que os sistemas criam?)

DM-4: big objects versus objetos padrão e personalizados

• Conheço as três casas dos dados: no núcleo (on core: sObjects, trabalhados todos os dias), referenciados (outro sistema é a fonte da verdade: os objetos externos do Salesforce Connect, __x, ou chamadas personalizadas) e arquivados (no núcleo em big objects, __b, ou fora do núcleo num data warehouse). (No núcleo e fora do núcleo)
• Sei que os objetos externos fazem uma chamada externa sempre que são tocados, por isso a latência e a disponibilidade do sistema de origem importam. (Referenciados)
• Conheço os big objects: volumes enormes, consultados pelo índice por correspondência exata ou intervalo, sem interface nem relatórios padrão, só permissões de objeto e de campo, sem automação. (Arquivados)
• Sei que a maioria dos registos conta como cerca de 2 KB de armazenamento de dados, independentemente dos campos, e que os ficheiros são medidos à parte, no armazenamento de ficheiros. (Duas colunas ou duzentas, Ficheiros e anexos)

SDM-1: as licenças e os objetos que as pessoas podem usar

• Conheço as três licenças internas, Sales Cloud, Service Cloud e Platform, e o que cada uma pode usar. (Três licenças internas)
• Sei que as licenças fazem parte do modelo de dados: os utilizadores Salesforce Platform não têm Leads, Campanhas, Oportunidades nem Previsões, e os utilizadores Customer Community não podem usar a Oportunidade. (Agora deixe-me complicar tudo: licenciamento)
• Conheço os níveis de licença externa: Customer Community, Customer Community Plus (relatórios, dashboards, partilha padrão), Partner Community (objetos de vendas); e que a Partner Community não pode ser usada com contas pessoais. (O estádio)
• Conheço o licenciamento por membro versus por login, e a que população serve cada um. (Como pagam muda o design)
• Sei que algumas licenças de plataforma limitam os utilizadores a uma aplicação com até dez objetos personalizados, e conheço o padrão de tipos de registo para trabalhar dentro disso. (Quando a licença molda o modelo)
• Sei que a licença Salesforce Integration é para utilizadores entre sistemas, só de API. (As pessoas já não são os únicos utilizadores)
• Sei que relatórios de SLA precisam de direitos e marcos (entitlements e milestones), que exigem licenças de Serviço. (Agora deixe-me complicar tudo: licenciamento)

SDM-2: manter os dados consistentes

• Consigo colocar uma regra no degrau certo da escada da consistência: tipo de campo e vocabulário, obrigatório e único, regras de validação, regras de duplicados, automação. (Manter os dados consistentes)
• Sei que uma lista de opções restrita rejeita valores que não estão na lista, até pela API, e que um conjunto de valores global partilha uma lista entre campos (até 1.000 valores). (Degrau um)
• Sei que um requisito no layout de página protege só aquele ecrã, não os dados, e que as regras de validação correm em todas as gravações. (A validação na interface não é validação de dados, Degrau três)
• Consigo limitar uma regra de validação com ISNEW() e ISCHANGED(), uma permissão personalizada ou uma data de entrada em produção, sabendo que gravações (incluindo as que não controlo, como uma mudança de proprietário em lote ou um resumo de totalização) cada escolha ainda verifica. (O problema dos registos antigos)
• Conheço as regras de correspondência e as regras de duplicados, os limites que o módulo cita (cinco regras de duplicados ativas por objeto, três regras de correspondência em cada), e que não resolvem a identificação entre sistemas. (Degrau quatro: regras de duplicados)
• Sei que as regras de duplicados não comparam entre si registos guardados no mesmo momento, que as gravações por API e importação são bloqueadas sem alerta, e que uma gravação e tudo o que ela desencadeia são revertidos como uma só transação. (Degrau quatro, Tudo ou nada)
• Sei que as Workflow Rules e o Process Builder já não têm suporte; automação significa Flow ou Apex. (Degrau cinco: automação)

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.

• A plataforma tem uma forma. Projete para a plataforma em que está, não para uma base de dados genérica.
• Olhe para a nave-mãe. Veja como a Salesforce modela um conceito antes de inventar um.
• Cada objeto é um compromisso: armazenamento, limites, um modelo de partilha, licenças e dependências.
• Pergunte onde vivem os dados antes de escolher um objeto: no núcleo (on core), referenciados ou arquivados.
• Leia qualquer nome de API e sabe quem o fez, e o que pode mudar.
• Se não arquiva hoje, alguma vez vai arquivar?
• Faça um protótipo de big objects antes de sugeri-los.
• Nomes de negócio diferentes não significam automaticamente objetos diferentes.
• Pergunte que identidades precisam dos dados: pessoas, clientes, parceiros, integrações e agentes.
• Cada campo ganha uma descrição, e classificação onde importa.
• Descreva primeiro o comportamento da relação; a configuração implementa-o. Não distorça o modelo para ganhar uma funcionalidade.
• A pergunta da eliminação: o que deveria acontecer aos filhos se alguém eliminar o pai?
• Escolha que elo quebra a cadeia: crie a relação de pesquisa onde o filho tem de facto vida própria.
• A propriedade vem do principal, o acesso vem dos dois: o mais restritivo ganha.
• Separe inativo de desaparecido, e faça da retenção uma regra de negócio.
• Empurre a regra até onde corretamente pertence, e dê ao histórico legítimo um desvio em vez de o reescrever.
• O diagrama não é a arquitetura. Saiba rastrear cada estrutura até um motivo de negócio.

Palavras a conhecer

Termo	Numa linha
Orientado por metadados	Objetos e campos são definições que a plataforma lê em tempo de execução, não novas tabelas físicas
Multitenancy (multilocação)	Muitas orgs partilham a infraestrutura, cada uma isolada, como apartamentos num prédio
Limites do governador	Limites que impedem um inquilino de monopolizar os recursos partilhados
Objeto externo	Dados apresentados no Salesforce através do Salesforce Connect, obtidos na origem a cada acesso
Big object	Armazenamento para dados muito grandes e pouco usados, consultados pelo índice
Conta pessoal	Um indivíduo representado como uma conta, para modelos business-to-consumer
Encaixe limpo	Um conceito de negócio que corresponde ao propósito pretendido de um objeto padrão
ID externo	Um campo com o identificador de outro sistema, usado para upserts e correspondência
Upsert	Atualizar o registo se existe, criá-lo se não existe
Relação de pesquisa	Uma relação em que o filho mantém o seu próprio proprietário e a sua própria vida
Mestre-detalhe	Uma relação em que o filho pertence ao pai: proprietário e partilha herdados, eliminação em cascata, resumos de totalização
Objeto de junção lógico	A ideia de modelação: um objeto que liga dois outros num muitos-para-muitos e carrega atributos próprios, seja qual for a forma como é construído
Objeto de junção do Salesforce (Salesforce Junction Object)	O que a Salesforce quer dizer com «objeto de junção»: um objeto personalizado com duas relações mestre-detalhe
Mestre principal e secundário	A mestre-detalhe criada primeiro num objeto de junção do Salesforce (proprietário, aparência, divisão) e a segunda (âmbito de relatório; passa a principal se a primeira for removida)
Relação hierárquica	Uma relação de pesquisa especial, só no objeto Utilizador, como Gestor (Manager), que não pode voltar ao mesmo utilizador
Prefixo de namespace	O prefixo do fornecedor nos objetos e campos de um pacote gerido, como abc__Inspection__c
Tabela de partilha	O objeto de partilha (AccountShare, Truck__Share) que guarda a maior parte da partilha de um registo, uma linha por utilizador ou grupo, com o seu motivo
Resumo de totalização	Um campo no mestre que conta, soma ou encontra o mínimo ou o máximo dos seus detalhes
Desequilíbrio de dados (data skew)	Registos a mais sob um pai ou um proprietário, causando bloqueios e recálculos de partilha demorados
Por membro / por login	Pagar por utilizador externo, ou por login em cada mês
Escada da consistência	As camadas que aplicam as regras de dados, do tipo de campo até a automação
Lista de opções restrita	Uma lista de opções que rejeita qualquer valor fora da lista, venha de onde vier
Classificação de dados	Metadados do campo para proprietário, uso, sensibilidade e categoria de conformidade

Teste-se

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

1. Os utilizadores precisam de ver pormenores de encomendas de que o ERP é dono e que atualiza o dia todo. Não os editam no Salesforce. Copiar para dentro, ou não?

Referencie-os: os objetos externos através do Salesforce Connect mantêm o ERP como fonte da verdade, sem cópia para sincronizar. Aceite que cada visualização faz uma chamada externa, por isso a latência e a disponibilidade do ERP importam, e que isto serve melhor para leitura do que para muita edição ou muitos relatórios. Releia Referenciados.

2. O negócio quer acompanhar distribuidores, fornecedores e parceiros retalhistas. Três objetos personalizados?

Não. São todos empresas, por isso a Conta é um encaixe limpo; os nomes diferentes são papéis, carregados por um tipo, um tipo de registo ou uma relação. Releia O teste do encaixe limpo.

3. Um design usa a Oportunidade, mas a maioria das pessoas que precisam dos dados tem licenças Salesforce Platform ou Customer Community. E agora?

Essas licenças não podem usar a Oportunidade, por isso a licença é uma restrição de arquitetura: comprar outras licenças, mudar a experiência ou reprojetar, normalmente na direção de um objeto personalizado. Releia Agora deixe-me complicar tudo: licenciamento.

4. O ERP envia atualizações noturnas de contas. Como deve a integração encontrar o registo certo sem consultar IDs do Salesforce?

Guarde o número de cliente do ERP num campo de ID externo e faça upsert por ele: atualiza se encontrar, cria se não encontrar. Os registos filhos também podem apontar para o pai pelo ID externo dele. Releia IDs externos.

5. Um Item de entrega não pode existir sem a sua entrega, nunca se move e não precisa de proprietário próprio. Uma Entrega existe antes de ter rota e pode passar para outra rota. Que relação para cada um?

Item de entrega para Entrega: mestre-detalhe (pertence ao pai a vida inteira, herda o acesso, elimina em cascata). Entrega para Rota: relação de pesquisa (vida própria, opcional no início, móvel, e eliminar uma rota nunca pode eliminar entregas). Releia Comece pela relação de negócio.

6. Uma integração cria 3.300 entregas por dia, todas propriedade do utilizador de integração, que tem uma função a meio da hierarquia. Qual é o risco, e a correção?

Desequilíbrio de propriedade: passados os 10 mil registos, mover esse utilizador ou mudar os seus grupos desencadeia recálculos de partilha demorados. Espalhe a propriedade se ela importar para o acesso; caso contrário, mantenha o utilizador de integração fora da hierarquia de funções, ou sozinho numa função no topo, e fora dos grupos usados por regras de partilha. Releia A propriedade pode tornar-se um problema de escala.

7. Acrescenta uma regra de validação, e 20 mil registos antigos violam-na. Um utilizador edita um telefone num deles e a gravação falha. O que deveria a regra ter feito?

Dizer quando se aplica, não só o que tem de ser verdade: limitá-la com ISNEW() ou ISCHANGED() nos campos relevantes, e dar aos registos anteriores à regra um desvio deliberado em vez de reescrever o seu histórico. Releia O problema dos registos antigos.

8. O negócio quer todas as fotografias de entrega «no Salesforce»: quatro a cinco milhões por ano, a crescer 30%. O que propõe?

Separe acesso de armazenamento. Guarde os ficheiros num armazenamento feito para esse volume, fora da org do núcleo, e mantenha no Salesforce uma referência, uma contagem ou um registo de índice para que os utilizadores as possam encontrar e ver. Releia Fotografias.

9. Uma Atribuição de equipa (Crew Assignment) tem relações mestre-detalhe com Equipa (criada primeiro) e Camião. Um expedidor consegue ver a equipa, mas não o camião. Consegue ver a Atribuição de equipa?

Não. A Equipa é a principal, por isso dá à atribuição o proprietário e a aparência, mas o acesso precisa dos dois pais: o expedidor precisa de acesso à equipa e ao camião, ao nível que a Sharing Setting (definição de partilha) de cada campo mestre-detalhe pede. O mais restritivo ganha. Releia Dois pais de largura.

10. Um parceiro reenvia um ficheiro de manifesto, e o mesmo cliente aparece nele duas vezes. Tem uma regra de duplicados na Conta configurada para bloquear. Está seguro?

Não só com a regra de duplicados. Os registos guardados no mesmo momento não são comparados entre si, só com registos que já estão no Salesforce, por isso as duas linhas podem passar. Empurre a unicidade para baixo, até ao campo: um ID externo único, que a plataforma verifica em todas as gravações, por isso só um ganha. Releia Degrau quatro: regras de duplicados e Tudo ou nada.

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 de plataforma, com a data em que foi consultada.