O modelo de dados é o esqueleto
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)
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 se sustenta sozinho. Anterior: Pensar como um arquiteto · Próximo: O Teste de Reversibilidade
A pergunta que este módulo responde: Por 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 ao redor dele, e é ele que mantém o resto do corpo unido. Você não vê os ossos quando olha para alguém, mas eles decidem a altura dessa pessoa, como ela se move e o que consegue carregar.
Pense em tudo o que construímos em uma implementação Salesforce. Construímos automação em torno do modelo de dados. Escrevemos Apex contra ele, e Flows que o leem e atualizam. Construímos integrações que enviam dados para ele e tiram dados dele. Criamos relatórios e análises sobre ele, e projetamos a segurança em torno dele. E, cada vez mais, construímos agentes de IA que precisam entender esses dados e agir sobre eles. Tudo isso depende da estrutura por baixo.
É por isso que acertar o modelo de dados cedo importa tanto. Você pode mudar o esqueleto depois. Mas provavelmente vai doer.
Comece pelo negócio
Seção intitulada “Comece pelo negócio ”Um bom modelo de dados começa com uma pergunta simples: o que o negócio realmente precisa representar? Não “quais objetos do Salesforce nós temos?”. E definitivamente não “o que eu consigo construir rápido?”.
Estamos tentando entender o negócio primeiro. Quais são as coisas importantes neste negócio? Como elas se relacionam? Quem é dono delas? Como mudam ao longo do tempo? O que precisa ser lembrado, e o que é compartilhado entre processos de negócio? Só depois de entender isso devemos começar a traduzir em objetos, campos e relacionamentos.
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 em torno disso. Às vezes isso está exatamente certo. Às vezes estamos tentando enfiar um pino quadrado num buraco redondo, e quando já se construiu o bastante em torno dessa decisão, tirar o pino de volta fica muito caro.
Aqui está uma pergunta que ouço o tempo todo. 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 você precisaria saber primeiro: o que um local significa para este negócio, e o que acontece com ele. Isso é modelar o negócio antes dos objetos. (Dou a minha resposta no capítulo 3.)
Sustentar. Crescer. Ter desempenho.
Seção intitulada “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 sustentar o que o negócio realmente está tentando alcançar. Há uma grande diferença entre um modelo que tecnicamente consegue armazenar os dados e um que de fato representa bem o negócio. Se estou sempre adicionando campos estranhos, flags especiais, automações complicadas e exceções porque o modelo não se encaixa direito, começo a me perguntar 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 registros. Volume importa: dez mil registros e cem milhões criam problemas muito diferentes. Mas os negócios também crescem em complexidade. Eles adicionam produtos, entram em novos mercados, adquirem empresas, mudam processos, adicionam canais e conectam novos sistemas. Descobrem que algo que achavam ser uma coisa são na verdade cinco coisas diferentes. Um modelo que funciona lindamente hoje pode virar uma armadilha se não houver espaço para amanhã. É por isso que prefiro designs que crescem por adição em vez de designs que ficam mudando o que já existe. Adicionar 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. Nós os gravamos, buscamos, consultamos, compartilhamos, reportamos e integramos, e cada vez mais sistemas de IA os recuperam como contexto antes de agir. Um modelo pode ficar lindo num diagrama e ainda assim ser terrível de operar. Então projetamos para as duas coisas: como os dados são armazenados e como os dados serão usados.
E ele precisa continuar tendo desempenho. Precisa ter desempenho em escala: quando o número de usuários 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 continuar funcionando quando algo inesperado acontece.
Sustentar. Crescer. Ter desempenho. Vamos voltar a esses três testes ao longo de todo o curso.
Plano demais, complicado demais ou simplesmente errado
Seção intitulada “Plano demais, complicado demais ou simplesmente errado ”Já vi modelos de dados darem errado de três formas.
A primeira é escolher a coisa errada desde o início. Usamos um objeto padrão porque parece próximo o bastante, e passamos anos adicionando exceções porque ele nunca serviu de verdade. Esse é o pino quadrado.
A segunda é deixar o modelo plano demais. Tudo vai para um objeto, e no início isso parece maravilhosamente simples. Então o negócio cresce, e descobrimos que algumas dessas coisas têm ciclo de vida próprio, podem ter várias ocorrências, precisam de segurança própria ou têm relacionamentos próprios. De repente estamos representando um relacionamento 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 após objeto, cada conceito perfeitamente separado. Tecnicamente lindo, na prática um sofrimento. Os usuários têm dificuldade para entendê-lo, e os layouts de página e as páginas Lightning, com uma lista relacionada após a outra, começam a parecer infinitamente profundos. As consultas ficam mais complicadas, a automação atravessa mais relacionamentos, os relatórios ficam mais difíceis, e a plataforma trabalha mais para responder perguntas comuns do negócio.
Então qual é o correto, plano ou normalizado? Não existe fórmula. Você guarda na cabeça a imagem do modelo ideal e entende os trade-offs à medida que se afasta 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 enquanto, reconheça que a própria estrutura é uma decisão de arquitetura.
Cuidado ao mudar o esqueleto
Seção intitulada “Cuidado ao mudar o esqueleto ”Quando um sistema está rodando, fico muito cauteloso com mudanças fundamentais no modelo de dados.
Suponha que um campo de texto exista há anos, e alguém diga: “Não usamos mais 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 com os dados históricos? A própria plataforma não deixa você mudar o tipo de um campo enquanto código ou flows ainda o referenciam, o que mostra até onde a mudança alcança.
À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 isso nos metadados: o Field Usage de um campo pode ser definido como DeprecateCandidate, “planejado para descontinuação e não mais em uso”. Isso marca o campo para todos que leem o objeto; não o oculta, então aposentá-lo continua sendo uma decisão que você executa.
Porque, quando outras partes da arquitetura dependem de algo, mudar seu significado pode ser muito mais perigoso do que mudar seu nome. A pior versão é o campo cujo nome continua o mesmo enquanto o conteúdo muda: tudo o que vem depois continua confiando no nome.
Até algo tão simples quanto marcar a caixa Obrigatório em um campo pode virar uma bomba-relógio. Se você já coletou dados, alguns registros não terão esse campo preenchido. Dias, semanas ou meses depois, alguém atualiza um desses registros, e o salvamento 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 atrasadas. Voltaremos ao Obrigatório, e a quando um valor é de fato 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 para construir uma aplicação e ela vai gerar 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; nós as aceleramos, porque cada camada gerada é mais uma coisa dependendo daquela estrutura. É por isso que quero um arquiteto humano revisando um modelo de dados gerado por IA, entendendo-o e respondendo por ele. O módulo 7 aprofunda isso.
O esqueleto vem primeiro
Seção intitulada “O esqueleto vem primeiro ”Ao longo deste curso, vamos falar de muita tecnologia: objetos e relacionamentos, grandes volumes de dados, consultas, integração, migração, transações, segurança, Data 360 e IA. Por baixo de tudo isso 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 forte. Se erramos a base, tudo o que vem depois fica mais difícil.
O modelo de dados é o esqueleto. 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 intitulada “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 se encaixa em um objeto padrão ou é um pino quadrado.
- Quão plano ou quão normalizado fazer o modelo, e por quê.
- 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 lugar.
Para saber mais
Seção intitulada “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): quais mudanças de tipo podem perder dados, e por que você não 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.