Modelar dados pelo significado

🌐 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 2 do curso Data Architect. Leia primeiro os seis módulos; 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 é a base da seção de Modelagem de Dados e Design de Banco de Dados do exame, que vale um quarto do exame. Ele cobre o raciocínio; o próximo capítulo, Arquitetura de dados Salesforce, cobre como a plataforma o constrói. Por isso a maior parte do que é cobrado sobre objetos, campos e relacionamentos precisa dos dois capítulos.

Para o exame

Os pontos deste capítulo com mais chance de importar no exame. Cada um está ligado ao seu objetivo do exame e tem um link para onde é ensinado. Marque conforme avança.

DM-1: comparar técnicas para projetar um modelo de dados Salesforce

• Consigo explicar a diferença entre um modelo de dados conceitual, um lógico e um físico, e para que serve cada um. (Transforme o modelo em Salesforce)
• Consigo encontrar possíveis entidades num requisito, e distinguir uma pessoa fazendo um trabalho de um dado. (Substantivos dão possíveis entidades)
• Consigo ler e desenhar a notação pé de galinha (crow’s foot): um, muitos, e a segunda marca para opcional ou obrigatório. (Leia as linhas, A opcionalidade também importa)
• Consigo nomear a cardinalidade de um relacionamento: um-para-um, um-para-muitos, muitos-para-muitos. (Pergunte “um ou muitos?”)
• Sei que um relacionamento muitos-para-muitos vira uma entidade própria e, no Salesforce, normalmente um objeto de junção com dois pais. (Relacionamentos podem virar coisas)
• Sei quando um relacionamento precisa de histórico (um registro com datas de início e de fim) em vez de um campo que é sobrescrito. (O tempo muda os relacionamentos)
• Consigo escolher um bom ID único, e sei por que uma chave natural ou qualquer coisa com informação pessoal é uma escolha arriscada. (Depois precisamos falar de IDs únicos)
• Sei a diferença entre uma chave natural e uma chave substituta, e que um registro pode carregar vários identificadores externos. (Chaves naturais e chaves substitutas)
• Sei que um campo de numeração automática é um número legível, não o ID Salesforce do registro. (Os relacionamentos dependem de IDs únicos)
• Consigo aplicar a primeira, a segunda e a terceira forma normal, e identificar um campo que guarda vários valores ou repete um fato sobre outra coisa. (Uma forma simples de pensar em 1FN, 2FN e 3FN)
• Consigo explicar quando desnormalizar de propósito (usuários, relatórios, escala), e quanto isso custa. (Projete até a terceira forma normal, depois recue)
• Consigo decidir entre uma lista de opções e um relacionamento de pesquisa com um objeto para uma lista de valores. (Relacionamento de pesquisa ou lista de opções?)
• Sei que um tipo de relatório personalizado permite no máximo quatro relacionamentos entre objetos, e por que isso importa para modelos profundos. (Relacionamento de pesquisa ou lista de opções?)
• Sei quando o mestre-detalhes serve (o filho nunca troca de pai) e quando um relacionamento de pesquisa é mais seguro, incluindo a orientação da Salesforce de no máximo 10 mil filhos num único pai. (Relacionamentos viram decisões de plataforma)
• Sei por que evitar relacionamentos polimórficos quando posso. (Relacionamentos viram decisões de plataforma)
• Sei que uma entidade de negócio não significa automaticamente um objeto personalizado: ela pode ser um objeto padrão, um campo, configuração, ou dados que vivem fora do Salesforce. (Uma entidade de negócio não significa automaticamente um objeto personalizado)

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.

• Esqueça o Salesforce por um minuto. Modele o negócio antes de mapeá-lo para Conta e Contato.
• Ouça a palavra que esconde duas coisas. Na Steve Trucking, “cliente” era um Parceiro varejista e um Destinatário.
• O modelo faz parte da conversa. Seu primeiro modelo não existe para estar certo; existe para mostrar onde você está errado.
• Dê nome às linhas. Dois modelos com as mesmas caixas podem significar coisas diferentes.
• Pergunte “agora, ou ao longo do tempo?” sobre cada relacionamento.
• Único, imutável, sem significado, nunca dado pessoal.
• Coloque um fato onde ele pertence, depois recue de propósito, e registre por quê.
• A desnormalização não remove a complexidade; ela a move. Saiba quem é dono da verdade.
• Uma fonte da verdade, muitas formas: telas, relatórios, o data warehouse e a IA.
• Não projete a partir do Setup. Desenhe o modelo antes de clicar em Novo objeto personalizado.
• Rastreie cada decisão física de volta até algo de que o negócio precisa.

Palavras para conhecer

Termo	Em uma linha
Entidade	Uma coisa com que o negócio se importa e sobre a qual guarda dados
Possível entidade	Um substantivo que pode virar uma entidade, depois que você perguntar sobre ele
Atributo	Um fato que descreve uma entidade
Relacionamento	Como duas entidades estão conectadas, nomeado na linguagem do negócio
Cardinalidade	Quantos de um se relacionam com quantos do outro
Opcionalidade	Se o relacionamento é obrigatório, ou pode ser zero
Pé de galinha	A marca de “muitos” na ponta de uma linha
Objeto de junção	A forma do Salesforce de construir um relacionamento muitos-para-muitos: um filho dos dois pais
Modelo conceitual	O que existe no negócio e como se relaciona; sem Salesforce
Modelo lógico	Os dados: atributos, IDs únicos e relacionamentos, ainda sem ligação com uma plataforma
Modelo físico	Como a plataforma vai construí-lo: objetos, campos e tipos de relacionamento
Chave natural	Um identificador que já existe no negócio, como o chassi (VIN) de um caminhão
Chave substituta	Um identificador criado só para identificar o registro
Identificador externo	O ID de outro sistema para o mesmo registro, guardado e mapeado
Normalização (1FN, 2FN, 3FN)	Colocar cada fato onde ele pertence: um valor por campo, fatos sobre a chave inteira, nenhum fato sobre outros fatos
Desnormalização	Copiar ou achatar dados de propósito, por um motivo que você consegue nomear
Anomalia de atualização	O mesmo fato guardado em muitos lugares, de modo que uma mudança deixa algumas cópias erradas

Teste-se

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

1. O negócio lhe diz que uma equipe dirige um caminhão. Seis semanas depois, alguém pergunta qual equipe estava com o caminhão 117 num certo dia. O que o modelo deveria ter tido?

Uma Atribuição de equipe: o relacionamento entre equipe e caminhão como um registro próprio, com data de início, data de fim e a rota. Equipes e caminhões são muitos-para-muitos ao longo do tempo, e o negócio se importa com o histórico. Um campo no caminhão teria sido sobrescrito. Releia O tempo muda os relacionamentos.

2. Uma equipe propõe usar o número de telefone de cada Destinatário como ID único, “porque é único”. O que você diz?

Ele reprova nos testes: números de telefone mudam e são compartilhados, então não é imutável nem confiavelmente único, e é informação pessoal que seria copiada para todo sistema que se liga ao registro. Use um ID gerado e sem significado, e mantenha o telefone como atributo. Releia Depois precisamos falar de IDs únicos.

3. Uma Entrega tem os campos Item 1, Item 2 e Item 3. Chega uma entrega com quatro itens. Qual é o problema real, e a correção?

O modelo escondeu uma estrutura que se repete dentro de campos (um problema de primeira forma normal). A correção não é um campo Item 4; é uma entidade Item de entrega, filha de Entrega, para que cada item seja um registro. Releia Primeira forma normal.

4. Cada entrega guarda o nome do gerente do centro de distribuição. O gerente muda. O que deu errado?

Um fato sobre outra coisa (o centro de distribuição) foi guardado na entrega: um problema de terceira forma normal, e agora uma anomalia de atualização em centenas de registros. O gerente pertence ao centro de distribuição; a entrega aponta para o centro de distribuição. Releia Terceira forma normal.

5. O tipo de parada (só entrega, com instalação, com recolhimento) precisa de uma duração, das habilidades da equipe e de um checklist. Lista de opções ou objeto?

Um objeto. Ele tem mais de uma coluna de informação, é gerenciado pelo negócio e muda no seu próprio ritmo. O status de uma entrega, uma lista curta e estável de rótulos, continua uma lista de opções. Releia Relacionamento de pesquisa ou lista de opções?.

6. Os parceiros querem um scorecard de pontualidade por região, e a região vive no centro de distribuição. Você copia a região para cada entrega. O que precisa decidir?

Quem é dono da verdade, como a cópia continua sincronizada, e se as entregas antigas devem manter a região que era verdade quando aconteceram ou seguir o centro de distribuição se ele mudar. Desnormalizar moveu a complexidade; não a removeu. Releia Às vezes os relatórios vencem.

7. Um truque como Senta poderia estar ligado a centenas de milhares de pets. Mestre-detalhes ou relacionamento de pesquisa de Truque do pet para Truque?

Um relacionamento de pesquisa. A orientação da Salesforce é de no máximo 10 mil filhos num único pai, e um truque popular passaria disso. Mestre-detalhes serve de Truque do pet para Pet, porque o truque de um pet nunca troca de pai e um pet sabe só alguns truques; é também o que permite ao pet totalizar sua contagem de Truques conhecidos. Releia Senta, fica, modelo.

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.