Entender os dados empresariais

🌐 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 4 do curso Data Architect. Leia primeiro os seis 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.

O guia do exame diz que não avalia conceitos de bases de dados que não sejam Salesforce, e a maior parte deste capítulo trata da empresa à volta do Salesforce. Por isso, como no capítulo 1, esta lista diz que objetivos cada ponto apoia. Mas não a salte: muitos cenários do exame começam com um ERP, um data warehouse ou uma segunda org, e a resposta depende de quem é dono dos dados.

Para o exame

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

Quem é dono dos dados (apoia SDM-2, SDM-3 e o capítulo de dados mestres)

• Consigo dizer que sistema é o sistema de registo de cada tipo de dado, e termino a frase: sistema de registo de quê? (Muitas vezes o Salesforce não é o sistema de registo, Não comece pelo nome do produto)
• Conheço o padrão comum: clientes, produtos e preços entram vindos do ERP, encomendas saem, e sei que a seta de encomendas depende das outras; depois pergunto pela viagem de volta. (A integração que vejo uma e outra vez, As setas num só sentido deixam-me nervoso)
• Faço três perguntas sobre os dados mestres: onde são criados, onde são editados e onde são referenciados? (As quatro perguntas por trás das categorias)
• Sei que uma cópia não é autoridade: os dados de que o ERP é dono são lidos localmente e gravados sob controlo, com o identificador do ERP guardado como ID externo. (O ERP: o back office tem gravidade, O panorama muda o modelo de dados)

Os tipos de dados e as suas cargas de trabalho (apoia DM-1, LDV-1 e MDM-4)

• Consigo distinguir dados mestres, de referência, transacionais, metadados, analíticos e não estruturados, e o que cada um significa para o sítio onde vivem. (Comece pelo tipo, não pelo objeto)
• Sei que os dados de referência são pequenos mas são onde se escondem os pressupostos de integração (Delivered, Complete, D). (Dados de referência)
• Sei distinguir as cargas de trabalho operacional (OLTP), analítica (OLAP) e de streaming: a org gere o negócio, os data warehouses e os data lakes analisam-no. (O tipo é só metade da pergunta)
• Conheço o síncrono (esperar à porta), o assíncrono (seguir em frente e tratar da resposta quando ela voltar) e o lote (batch) (de hora a hora, de poucas em poucas horas, diariamente), sei quando o lote basta, e que o tempo real tem um custo. (Com que rapidez precisa de se mover?)
• Faço as quatro perguntas sobre cada conjunto de dados: quem é o dono, com que rapidez muda, quão grande fica e qual é o ciclo de vida. (As quatro perguntas por trás das categorias)

Os sistemas à volta do Salesforce (apoia SDM-3, LDV-3 e os capítulos de integração)

• Conheço os quatro papéis de sistema: registo, envolvimento, referência e insights. (Não comece pelo nome do produto)
• Sei que onde vive a análise segue onde vivem os dados: relatórios do núcleo quando está tudo no Salesforce; uma plataforma de análise (o Tableau, incluindo o Tableau Next, ou o CRM Analytics onde já é usado) ou o data warehouse quando entram outros repositórios. (A análise vive onde os dados vivem)
• Sei o que são um data warehouse, um data lake e um lakehouse, e o papel do MDM, de um ESB ou iPaaS e dos eventos. (O data warehouse, o data lake e o lakehouse, A camada de integração e os eventos)
• Ponho o fornecedor de identidade no panorama desde o primeiro dia, e sei que a configuração de SSO é implementada, mas os segredos e os certificados não viajam com ela; no panorama é um certificado partilhado (confiança), não uma chamada, porque o início de sessão passa pelo browser. (O sistema de que os programadores se esquecem: identidade)
• Sei que o Data 360 é próximo do núcleo (near-core) (gerido no núcleo, alojado fora do núcleo), e que o seu zero copy permite consultar dados sem os copiar. (Onde fica o Data 360?, Núcleo, fora do núcleo e Hyperforce)

Orgs e alojamento (apoia SDM-4)

• Começo com uma org e procuro uma fronteira real (residência, regulação, separação legal, um modelo operacional diferente, uma aquisição) antes de acrescentar outra. (Comece com uma org, Procure fronteiras reais)
• Sei quanto custam várias orgs: relatórios globais, dados mestres, integração, identidade e deploys, cada um multiplicado. (Percorra outra vez as setas)
• Sei que o Hyperforce dá a escolha da região onde residem os dados de uma org (não do fornecedor de nuvem), mas não promete que cada serviço lá fique; e que o RGPD (GDPR) por si só não exige uma org separada: estabelece regras para os dados pessoais que saem da UE, e uma empresa pode escolher uma org europeia para as cumprir. (O alojamento faz parte do desenho, Quando a Europa tem a sua própria org)

Desenhar e ler um panorama (apoia todos os cenários)

• Sei desenhar um panorama: as pessoas à esquerda, o Salesforce no centro com as suas comunidades encostadas por baixo, a identidade acima, a integração e o back office à direita, o Data 360 abaixo da camada de integração, os canais em baixo, os dados que entram e saem no canto inferior direito. (O layout de panorama do Steve)
• Num panorama, uma seta começa no sistema que abre a ligação e o seu rótulo diz o que se move e em que sentido; num diagrama de fluxo de dados, as setas seguem os dados. Dois fluxos são duas setas. (Agora desenhe as setas)
• Para cada seta sei o que o cliente trata e o que o servidor define: onde, autenticação, protocolo e contrato, payload, tempo, rastreio, erros. Uma Named Credential (credencial nomeada) e a sua External Credential (credencial externa) quando o Salesforce faz a chamada de saída; uma External Client App (aplicação cliente externa) e um utilizador de integração só de API quando algo chama o Salesforce. (Cada seta precisa de um mecanismo)
• Conto antes de desenhar as setas: o volume vai para o inventário e determina o mecanismo, e pode até mudar para que lado a seta aponta. (Ponha os zeros no inventário)
• Desenho uma raia (swim lane) só quando um processo tem mais do que uma ou duas idas e voltas. (Setas no panorama, conversas numa raia)

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.

• Desenhe o panorama antes de projetar a org. Comece numa folha em branco.
• Afaste a câmara. O Salesforce é um sistema entre muitos.
• A vaga nova raramente faz desaparecer a antiga. Arquitete a empresa que existe, não a do folheto.
• Leia o panorama como responsabilidades, não como logótipos.
• As setas num só sentido deixam-me nervoso. De que depende este fluxo, e o que volta?
• Cada seta precisa de um mecanismo. «Fire and forget» não é resposta.
• Setas no panorama, conversas numa raia.
• Conte antes de desenhar as setas. Os zeros vão para o inventário, e são eles que escolhem o mecanismo.
• Desenhe o estado atual antes de o corrigir: a folha de cálculo, o ficheiro deixado no SFTP, o sistema «que estamos a retirar».
• Marque um estado atual com honestidade: vermelho para um processo mau, tracejado para o que é feito à mão, pontos vermelhos para o que está em falta. Cada linha vermelha é um requisito à espera de ser escrito.
• Dois fluxos, duas setas. Uma seta de duas pontas é só para um conector.
• Não se faça de advogado. Pergunte que requisito específico está a cumprir, e traduza-o com as pessoas que são donas dele.
• Separado não é o mesmo que simples.

Palavras a conhecer

Termo	Numa linha
Panorama de sistemas	Os sistemas à volta do Salesforce, as pessoas que os usam e os fluxos importantes entre eles
Sistema de registo	Onde é guardada a versão com autoridade de um tipo de dado
Sistema de envolvimento	Onde as pessoas fazem o trabalho
Sistema de referência	Onde um sistema consulta informação de que precisa, mas da qual não é dono
Sistema de insights	Onde os dados se juntam para medir, analisar e prever
ERP	O sistema de back office para finanças, produtos, inventário, compras e processamento de encomendas
Dados mestres	As coisas duradouras à volta das quais um negócio funciona: clientes, produtos, locais
Dados de referência	O vocabulário partilhado que classifica outros dados: códigos, estados, categorias
Dados transacionais	Registos do que aconteceu: encomendas, entregas, pagamentos, casos
Dados analíticos	Dados derivados de outros dados para medir e comparar
Dados não estruturados	Documentos, imagens, áudio, vídeo, transcrições
Data warehouse / data lake / lakehouse	Repositório analítico estruturado / repositório em bruto à escala / uma mistura dos dois
ESB / iPaaS	Uma camada de integração que faz a mediação entre sistemas
OLTP / OLAP	Trabalho operacional em poucos registos de cada vez / análise sobre muitos
Próximo do núcleo (near-core)	Gerido no núcleo, alojado fora do núcleo: o Data 360
Named Credential / External Credential	Onde o Salesforce guarda um endpoint de saída / a sua autenticação
External Client App	Como um sistema de fora é autorizado a chamar o Salesforce
Estado atual	O panorama tal como é hoje, antes do design; marcado com o que está errado
Fornecedor de identidade (IdP)	O sistema que autentica os utilizadores e estabelece a identidade em que o Salesforce confia
Síncrono / assíncrono / lote (batch)	Esperar pela resposta / seguir em frente e tratar a resposta quando ela vier / mover os dados em grupo, num horário programado
Hyperforce	O Salesforce em infraestrutura de nuvem pública, com escolha de região
Zero copy	Consultar os dados onde vivem, sem os copiar

Teste-se

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

1. Os comerciais trabalham contas no Salesforce, mas o ERP emite o número oficial de cliente quando compram. O Salesforce envia encomendas ao ERP. O que precisa de projetar?

Quem é dono do cliente em cada etapa; o número do ERP como ID externo na Conta; que campos o Salesforce pode alterar; com que rapidez chegam as mudanças do ERP; e o que volta depois de uma encomenda ser enviada (aceite, rejeitada, expedida, faturada). Releia O panorama muda o modelo de dados.

2. A direção quer cinco anos de pontualidade por região, cruzados com as finanças. Construir como relatórios do Salesforce?

Provavelmente não. É uma carga de trabalho analítica entre vários repositórios, por isso pertence ao lugar onde os dados se juntam: o data warehouse, com CRM Analytics ou Tableau por cima. Onde vive a análise segue onde vivem os dados. Releia A análise vive onde os dados vivem.

3. Uma empresa opera em 30 países e pede uma org por país. O que pergunta?

Que requisito vem com cada país: armazenamento, processamento, transferência internacional, contratos, outro alojamento. Sem uma fronteira real, comece com uma org, porque cada org a mais multiplica relatórios, dados mestres, integração, identidade e deploys. Releia A geografia não é automaticamente uma estratégia de orgs.

4. Os camiões enviam 200 mil leituras de GPS por dia. O Salesforce deve guardá-las todas?

Provavelmente não. São dados de streaming: o expedidor precisa da posição atual, enquanto o histórico e as tendências pertencem a uma plataforma feita para esse volume. Conte os zeros (mais de 70 milhões por ano) e separe «onde está agora?» de «o que aconteceu no último trimestre?». Releia O tipo é só metade da pergunta.

5. As equipas trabalham as suas paragens no Salesforce, mas as rotas são montadas numa ferramenta de expedição legada, e nada liga as duas. Como desenha o hoje?

Tal como é, marcado como estado atual: as rotas reintroduzidas no Salesforce e as paragens concluídas reintroduzidas de volta, tracejadas porque são pessoas que o fazem e a vermelho porque está errado. Não desenhe a integração que gostaria que existisse; cada linha vermelha torna-se um requisito para o design. Releia Marque o que está errado e O RouteDesk continua lá.

6. Alguém diz que a lei de privacidade europeia exige uma org separada. Como responde?

Nem aceite às cegas nem desautorize. O RGPD (GDPR) por si só não exige uma org separada; estabelece regras para os dados pessoais, incluindo transferências para fora da UE. Pergunte que requisito específico isso cumpre (armazenamento, processamento, transferência, acesso de suporte, um contrato, uma política), depois trabalhe com privacidade, jurídico e segurança para o transformar em arquitetura. Releia Não se faça de advogado e Quando a Europa tem a sua própria org.

7. O Salesforce envia encomendas para a API do ERP. Que lado trata das novas tentativas, e onde guarda o Salesforce o segredo?

O Salesforce é o cliente: abre a ligação, vê a viagem de ida e volta inteira e é o único lado que pode tentar de novo. Uma Named Credential (credencial nomeada) guarda o endpoint, e a sua External Credential (credencial externa), a autenticação. O ERP, o servidor, define o contrato e valida o que chega. Releia Cada seta precisa de um mecanismo.

8. Uma integração envia hoje um ou dois registos por minuto, e o negócio espera dezenas de milhares por hora no próximo ano. A seta muda?

Possivelmente o seu mecanismo, e até o sentido. Alguns registos por minuto podem ser uma chamada de saída do Salesforce; muito mais pode significar publicar eventos que o outro sistema subscreve, por isso a seta começa na outra ponta; milhões durante a noite são um lote. Conheça as contagens antes de escolher. Releia Ponha os zeros no inventário.

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.