Modelar dados pelo significado

🌐 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 2 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.

Este capítulo é a base da secção de Modelação de Dados e Design de Bases de Dados do exame, que vale um quarto do exame. 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 é avaliado sobre objetos, campos e relações precisa dos dois capítulos.

Para o exame

Os pontos deste capítulo com mais probabilidade de importar no exame. Cada um está ligado ao seu objetivo do exame e tem um link para onde é ensinado. Marque à medida que 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 a fazer 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 uma relação: um-para-um, um-para-muitos, muitos-para-muitos. (Pergunte «um ou muitos?»)
• Sei que uma relação muitos-para-muitos se torna uma entidade própria e, no Salesforce, normalmente um objeto de junção com dois pais. (As relações podem tornar-se coisas)
• Sei quando uma relação precisa de histórico (um registo com datas de início e de fim) em vez de um campo que é sobrescrito. (O tempo muda as relações)
• Consigo escolher um bom ID único, e sei porque é que uma chave natural ou qualquer coisa com informação pessoal é uma escolha arriscada. (Depois temos de falar de IDs únicos)
• Sei a diferença entre uma chave natural e uma chave substituta, e que um registo 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 registo. (As relações 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 facto sobre outra coisa. (Uma forma simples de pensar em 1FN, 2FN e 3FN)
• Consigo explicar quando desnormalizar de propósito (utilizadores, relatórios, escala), e quanto isso custa. (Projete até à terceira forma normal, depois recue)
• Consigo decidir entre uma lista de opções e uma relação de pesquisa com um objeto para uma lista de valores. (Relação de pesquisa ou lista de opções?)
• Sei que um tipo de relatório personalizado permite no máximo quatro relações entre objetos, e porque é que isso importa para modelos profundos. (Relação de pesquisa ou lista de opções?)
• Sei quando a mestre-detalhe serve (o filho nunca muda de pai) e quando uma relação de pesquisa é mais segura, incluindo a orientação da Salesforce de no máximo 10 mil filhos num único pai. (As relações tornam-se decisões de plataforma)
• Sei porque devo evitar relações polimórficas sempre que posso. (As relações tornam-se 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 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.

• Esqueça o Salesforce por um minuto. Modele o negócio antes de o mapear para Conta e Contacto.
• Ouça a palavra que esconde duas coisas. Na Steve Trucking, «cliente» era um Parceiro retalhista e um Destinatário.
• O modelo faz parte da conversa. O seu primeiro modelo não existe para estar certo; existe para mostrar onde 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 relação.
• Único, imutável, sem significado, nunca dado pessoal.
• Ponha um facto onde pertence, depois recue de propósito, e registe porquê.
• A desnormalização não remove a complexidade; desloca-a. Saiba quem é dono da verdade.
• Uma fonte da verdade, muitas formas: ecrãs, 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 até algo de que o negócio precisa.

Palavras a conhecer

Termo	Numa linha
Entidade	Uma coisa com que o negócio se importa e sobre a qual guarda dados
Possível entidade	Um substantivo que pode tornar-se uma entidade, depois de perguntar sobre ele
Atributo	Um fato que descreve uma entidade
Relação	Como duas entidades estão ligadas, com nome na linguagem do negócio
Cardinalidade	Quantos de um se relacionam com quantos do outro
Opcionalidade	Se a relação é obrigatória, 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 uma relação 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 relações, ainda sem ligação a uma plataforma
Modelo físico	Como a plataforma o vai construir: objetos, campos e tipos de relação
Chave natural	Um identificador que já existe no negócio, como o número de quadro (VIN) de um camião
Chave substituta	Um identificador criado só para identificar o registo
Identificador externo	O ID de outro sistema para o mesmo registo, guardado e mapeado
Normalização (1FN, 2FN, 3FN)	Pôr cada facto onde pertence: um valor por campo, factos sobre a chave inteira, nenhum facto sobre outros factos
Desnormalização	Copiar ou achatar dados de propósito, por um motivo que consegue nomear
Anomalia de atualização	O mesmo facto guardado em muitos lugares, de modo que uma mudança deixa algumas cópias erradas

Teste-se

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

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

Uma Atribuição de equipa: a relação entre equipa e camião como um registo próprio, com data de início, data de fim e a rota. Equipas e camiões são muitos-para-muitos ao longo do tempo, e o negócio importa-se com o histórico. Um campo no camião teria sido sobrescrito. Releia O tempo muda as relações.

2. Uma equipa propõe usar o número de telefone de cada Destinatário como ID único, «porque é único». O que diz?

Chumba nos testes: os números de telefone mudam e são partilhados, por isso não é imutável nem fiavelmente único, e é informação pessoal que seria copiada para todos os sistemas que se ligam ao registo. Use um ID gerado e sem significado, e mantenha o telefone como atributo. Releia Depois temos de falar de IDs únicos.

3. Uma Entrega tem os campos Artigo 1, Artigo 2 e Artigo 3. Chega uma entrega com quatro artigos. 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 Artigo 4; é uma entidade Item de entrega, filha de Entrega, para que cada artigo seja um registo. Releia Primeira forma normal.

4. Cada entrega guarda o nome do gestor do centro de distribuição. O gestor muda. O que correu mal?

Um facto 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 registos. O gestor pertence ao centro de distribuição; a entrega aponta para o centro de distribuição. Releia Terceira forma normal.

5. O tipo de paragem (só entrega, com instalação, com recolha) precisa de uma duração, das competências da equipa e de uma checklist. Lista de opções ou objeto?

Um objeto. Tem mais do que uma coluna de informação, é gerido pelo negócio e muda ao seu próprio ritmo. O estado de uma entrega, uma lista curta e estável de rótulos, continua a ser uma lista de opções. Releia Relação 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. Copia a região para cada entrega. O que tem de decidir?

Quem é dono da verdade, como a cópia se mantém 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 deslocou a complexidade; não a removeu. Releia Às vezes os relatórios ganham.

7. Um truque como Senta poderia estar ligado a centenas de milhares de pets. Mestre-detalhe ou relação de pesquisa de Truque do pet para Truque?

Uma relação de pesquisa. A orientação da Salesforce é de no máximo 10 mil filhos num único pai, e um truque popular ultrapassaria isso. Mestre-detalhe serve de Truque do pet para Pet, porque o truque de um pet nunca muda de pai e um pet sabe só alguns truques; é também o que permite ao pet totalizar a 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 os seus pesos. Confira sempre a versão atual antes de marcar o exame.