O modelo de dados é o esqueleto

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)

An older room opened up mid-renovation: its timber beams exposed, a new beam held on steel props, the furniture waiting under dust sheets. — Imagem gerada com IA

Módulo 2 de 7 do capítulo Pensar como um arquiteto de dados, o primeiro capítulo do curso Data Architect. Cada módulo sustenta-se sozinho. Anterior: Pensar como um arquiteto · Próximo: O Teste de Reversibilidade

A pergunta que este módulo responde: Porque é que o modelo de dados importa mais do que qualquer coisa construída sobre ele, e como se avalia um?

Quando ensino arquitetura de dados, há uma frase à qual volto sempre: o modelo de dados é o esqueleto.

O modelo de dados é o esqueleto do sistema. Todo o resto é construído à volta dele, e é ele que mantém o resto do corpo unido. Não vemos os ossos quando olhamos para alguém, mas são eles que decidem a altura dessa pessoa, como se move e o que consegue carregar.

Pense em tudo o que construímos numa implementação Salesforce. Construímos automação à volta do modelo de dados. Escrevemos Apex contra ele, e Flows que o leem e atualizam. Construímos integrações que lhe enviam dados e que dele tiram dados. Criamos relatórios e análises sobre ele, e projetamos a segurança à volta dele. E, cada vez mais, construímos agentes de IA que precisam de entender estes dados e agir sobre eles. Tudo isto depende da estrutura que está por baixo.

É por isso que acertar o modelo de dados cedo importa tanto. Pode mudar o esqueleto mais tarde. Mas provavelmente vai doer.

Comece pelo negócio

Um bom modelo de dados começa com uma pergunta simples: o que é que o negócio realmente precisa de representar? Não «que objetos do Salesforce temos?». E definitivamente não «o que é que eu consigo construir depressa?».

Estamos a tentar entender primeiro o negócio. Quais são as coisas importantes neste negócio? Como se relacionam? Quem é dono delas? Como mudam ao longo do tempo? O que precisa de ser lembrado, e o que é partilhado entre processos de negócio? Só depois de entender isto devemos começar a traduzi-lo em objetos, campos e relações.

Parece óbvio. Na prática, é muito fácil inverter a ordem. Alguém reconhece algo que parece uma Oportunidade, um Caso ou um Ativo e começa imediatamente a projetar à volta disso. Às vezes isso está exatamente certo. Às vezes estamos a tentar enfiar uma peça quadrada num buraco redondo, e quando já se construiu o bastante à volta dessa decisão, tirar a peça fica muito caro.

Aqui está uma pergunta que ouço constantemente. O negócio de um cliente pode ter muitos locais de entrega. Cada local deve ser uma Conta ou um objeto personalizado? Antes de responder, repare no que precisaria de saber primeiro: o que um local significa para este negócio, e o que lhe acontece. Isso é modelar o negócio antes dos objetos. (Dou a minha resposta no capítulo 3.)

Sustentar. Crescer. Ter desempenho.

Quando olho para um modelo de dados, quero que ele passe em três testes: sustentar o negócio, crescer com o negócio e ter desempenho.

Sustentar. O modelo precisa de sustentar aquilo que o negócio realmente está a tentar alcançar. Há uma grande diferença entre um modelo que tecnicamente consegue armazenar os dados e um que de facto representa bem o negócio. Se estou sempre a adicionar campos estranhos, flags especiais, automações complicadas e exceções porque o modelo não encaixa bem, começo a perguntar-me se o problema é mesmo a automação. Talvez o modelo esteja errado. Um bom modelo deve tornar o negócio mais fácil de entender, não mais difícil.

Crescer. Quando digo crescer, não quero dizer só mais registos. O volume importa: dez mil registos e cem milhões criam problemas muito diferentes. Mas os negócios também crescem em complexidade. Acrescentam produtos, entram em novos mercados, adquirem empresas, mudam processos, acrescentam canais e ligam novos sistemas. Descobrem que algo que julgavam ser uma coisa são, afinal, cinco coisas diferentes. Um modelo que funciona lindamente hoje pode tornar-se uma armadilha se não houver espaço para amanhã. É por isso que prefiro designs que crescem por adição a designs que estão sempre a mudar o que já existe. Acrescentar algo novo costuma ser mais fácil do que redefinir algo de que dezenas de outras coisas dependem.

Ter desempenho. Os dados não ficam parados. Gravamo-los, procuramo-los, consultamo-los, partilhamo-los, fazemos relatórios sobre eles e integramo-los, e cada vez mais sistemas de IA os recuperam como contexto antes de agir. Um modelo pode ficar lindo num diagrama e mesmo assim ser terrível de operar. Por isso projetamos para as duas coisas: como os dados são armazenados e como os dados serão usados.

E precisa de continuar a ter desempenho. Precisa de ter desempenho à escala: quando o número de utilizadores aumenta, quando o volume de dados aumenta, em condições reais e nos picos, no dia mais movimentado do ano e não num dia médio. E precisa de continuar a funcionar quando acontece algo inesperado.

Sustentar. Crescer. Ter desempenho. Vamos voltar a estes três testes ao longo de todo o curso.

Click to enlarge

Plano demais, complicado demais ou simplesmente errado

Já vi modelos de dados correrem mal de três formas.

A primeira é escolher a coisa errada desde o início. Usamos um objeto padrão porque parece suficientemente próximo, e passamos anos a acrescentar exceções porque ele nunca serviu de verdade. É a peça quadrada.

A segunda é deixar o modelo plano demais. Tudo vai para um objeto, e no início isso parece maravilhosamente simples. Depois o negócio cresce, e descobrimos que algumas destas coisas têm ciclo de vida próprio, podem ter várias ocorrências, precisam de segurança própria ou têm relações próprias. De repente estamos a representar uma relação um-para-muitos com Campo 1, Campo 2 e Campo 3, ou com flags e automações cada vez mais complicadas. O modelo não nos deixou espaço para crescer.

A terceira é o erro oposto: normalizamos demais. Criamos um diagrama elegante com objeto atrás de objeto, cada conceito perfeitamente separado. Tecnicamente lindo, na prática um sofrimento. Os utilizadores têm dificuldade em entendê-lo, e os layouts de página e as páginas Lightning, com uma lista relacionada atrás da outra, começam a parecer infinitamente profundos. As consultas ficam mais complicadas, a automação atravessa mais relações, os relatórios ficam mais difíceis, e a plataforma trabalha mais para responder a perguntas comuns do negócio.

Então qual é o correto, plano ou normalizado? Não existe fórmula. Guarda-se na cabeça a imagem do modelo ideal e entendem-se os trade-offs à medida que nos afastamos dele. Essa é a arte da arquitetura, e voltaremos a ela no módulo 4 e no próximo capítulo, onde aprendemos a modelar. Por agora, reconheça que a própria estrutura é uma decisão de arquitetura.

Click to enlarge

Cuidado ao mudar o esqueleto

Quando um sistema está em produção, sou muito cauteloso com mudanças fundamentais no modelo de dados.

Suponha que um campo de texto existe há anos, e alguém diz: «Já não o usamos assim. Vamos transformá-lo em número.» Parece uma mudança de campo. Mas o que depende desse campo? Flows, Apex, relatórios, integrações, pipelines de dados, aplicações externas, agentes de IA. E o que acontece aos dados históricos? A própria plataforma não o deixa mudar o tipo de um campo enquanto código ou flows ainda o referenciam, o que mostra até onde a mudança chega.

Às vezes a resposta certa é não alterar o que já existe. Dependendo da gravidade da mudança, prefiro criar algo novo, migrar de forma deliberada e descontinuar a estrutura antiga:

Adicione em vez de alterar. Descontinue em vez de surpreender.

O Salesforce até lhe dá uma forma de dizer isto nos metadados: o Field Usage de um campo pode ser definido como DeprecateCandidate, «planeado para descontinuação e já não em uso». Isso marca o campo para todos os que leem o objeto; não o oculta, por isso retirá-lo continua a ser uma decisão que é o arquiteto a executar.

Porque, quando outras partes da arquitetura dependem de algo, mudar o seu significado pode ser muito mais perigoso do que mudar o seu nome. A pior versão é o campo cujo nome continua o mesmo enquanto o conteúdo muda: tudo o que vem depois continua a confiar no nome.

Click to enlarge

Até algo tão simples como marcar a caixa Obrigatório num campo pode tornar-se uma bomba-relógio. Se já recolheu dados, alguns registos não terão esse campo preenchido. Dias, semanas ou meses depois, alguém atualiza um desses registos, a gravação falha por causa do campo obrigatório, e ninguém tem esse valor. Uma mudança simples como marcar um campo como obrigatório pode ter consequências não intencionais e retardadas. Voltaremos ao Obrigatório, e a quando um valor é de facto conhecido, no capítulo 3.

Além do exame: a IA também constrói sobre o esqueleto. Peça a uma ferramenta de IA que construa uma aplicação e ela gera os objetos, campos, Flows, Apex, componentes e testes em minutos. Se o modelo de dados original estava errado, não evitamos as consequências de uma má decisão; aceleramo-las, porque cada camada gerada é mais uma coisa a depender daquela estrutura. É por isso que quero um arquiteto humano a rever um modelo de dados gerado por IA, a entendê-lo e a responder por ele. O módulo 7 aprofunda isto.

O esqueleto vem primeiro

Ao longo deste curso, vamos falar de muita tecnologia: objetos e relações, grandes volumes de dados, consultas, integração, migração, transações, segurança, Data 360 e IA. Por baixo de tudo isto está o modelo de dados.

Se o modelo sustenta o negócio, consegue crescer com o negócio e tem desempenho para as formas como vamos usar os dados, construímos uma base sólida. Se erramos a base, tudo o que vem depois fica mais difícil.

O modelo de dados é o esqueleto. Os arquitetos devem ter muito cuidado ao projetar o esqueleto. Mudar estruturas existentes pode ter consequências em cascata.

O que um arquiteto decide aqui

Se o modelo sustenta o negócio, consegue crescer com ele e tem desempenho para as formas como os dados serão usados.
Se um conceito encaixa num objeto padrão ou é uma peça quadrada.
Quão plano ou quão normalizado fazer o modelo, e porquê.
Se uma mudança no esqueleto deve ser uma adição, uma migração ou uma descontinuação, em vez de uma mudança no próprio lugar.

Para saber mais

Considerations for Converting the Field Type of a Custom Field (opens in a new tab), Ajuda do Salesforce (em inglês, consultado em 2026-10-02; reconsultado em 2026-10-12): que mudanças de tipo podem perder dados, e porque é que não se pode mudar o tipo de um campo referenciado por Apex, flows ou processos.
Data Classification Metadata Fields (opens in a new tab), Ajuda do Salesforce (em inglês, consultado em 2026-10-02; reconsultado em 2026-10-12): os valores de Field Usage (Active, DeprecateCandidate, Hidden) e os outros campos de classificação.