Transforme o modelo em Salesforce
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)
Módulo 6 de 6 do capítulo Modelar dados pelo significado, capítulo 2 do curso Data Architect. Cada módulo sustenta-se sozinho. Anterior: Projete até à terceira forma normal, depois recue · Próximo: o guia de estudo do capítulo, depois o próximo capítulo: Arquitetura de dados Salesforce
A pergunta que este módulo responde: Como é que um modelo de dados lógico se torna um modelo de dados físico no Salesforce?
Finalmente vamos falar de Salesforce. Se tem andado a resistir à vontade de transformar cada caixa num objeto, agora pode. Mas repare na ordem por que aqui chegámos: entendemos o negócio, descrevemos os dados, pusemos cada facto onde pertence e decidimos onde iríamos dobrar isso de propósito. Só agora estou a perguntar como deve o Salesforce implementar isto. Esta é a progressão que quero que recorde: conceitual → lógico → físico. O modelo conceitual descreve o negócio. O modelo lógico descreve os dados. O modelo físico descreve como o vamos realmente construir.
Senta, fica, modelo
Seção intitulada “Senta, fica, modelo ”O passo físico é mais fácil de ver em algo pequeno, por isso os pets vão primeiro.
Quem são as empresas e as pessoas? O criador é uma empresa, por isso torna-se uma Conta com o tipo de registo Criador. O dono também é uma Conta, ou uma Conta pessoal, com o tipo de registo Dono. Dois tipos do mesmo objeto padrão, lado a lado no topo do diagrama, exatamente onde estão desde o módulo 1.
O que não tem uma casa padrão? Pet, Raça, Truque, Truque do pet e Avaliação do truque tornam-se objetos personalizados. E lembra-se da espécie que copiámos para o pet no módulo 5? Aqui ganha o seu trabalho: torna-se o tipo de registo do Pet, Cão ou Gato. Um objeto com dois tipos de registo, cada um com o seu próprio esquema de página e os seus valores de lista de opções, em vez de um objeto Cão e um objeto Gato.
Que relações são mestre-detalhe? Uso mestre-detalhe só onde o filho nunca vai mudar de pai. Um Truque do pet pertence ao seu pet para toda a vida, e cada Avaliação do truque pertence ao seu Truque do pet, por isso as duas são mestre-detalhe. Isso compensa logo: é a mestre-detalhe que permite ao pet manter um resumo de totalização dos seus Truques do pet, para que a contagem de Truques conhecidos do módulo 5 se mantenha sincronizada sozinha. Mas os pets mudam de casa, por isso o Dono é uma relação de pesquisa.
Quais são relações de pesquisa? A Salesforce não recomenda mais de 10 mil filhos num único pai. Um truque popular como Senta, uma raça comum ou um criador grande ultrapassariam isso facilmente, por isso o Truque do pet aponta para o seu Truque com uma relação de pesquisa, e o pet aponta para a sua Raça e o seu Criador da mesma maneira. E evite relações polimórficas sempre que puder, aquelas em que um campo pode apontar para vários tipos de objeto. São convenientes no primeiro dia e mais difíceis para tudo o que tem de as ler depois: relatórios, integrações e, agora, agentes.
O que fica fora da plataforma? Se o pet usa uma coleira com GPS que indica onde está, essa localização não precisa de ser copiada para dentro. Pode ser um objeto externo, lido em direto do sistema de localização da coleira.
Cada decisão nesse diagrama remonta a algo que decidimos antes, e é esse o objetivo. Agora o mesmo passo para a Steve Trucking.
Comece pelo modelo lógico
Seção intitulada “Comece pelo modelo lógico ”O nosso modelo lógico da Steve Trucking contém agora Parceiro retalhista, Centro de distribuição, Manifesto, Entrega, Item de entrega, Destinatário, Rota, Paragem, Equipa, Camião e Atribuição de equipa. São conceitos de negócio, e agora posso começar a mapeá-los para o Salesforce.
Um Parceiro retalhista talvez seja uma Conta. Uma entrega talvez corresponda a algo que o Salesforce já tem para trabalho agendado no terreno, ou talvez passe a ser um objeto personalizado. Um manifesto não tem nada padrão que sirva, por isso provavelmente passa a personalizado. E o Destinatário é uma pergunta realmente difícil: uma Conta pessoal, um Contacto, ou simplesmente informação na entrega? Vamos responder a essa como deve ser no próximo capítulo.
A palavra importante continua a ser talvez. Não presuma a implementação só porque um conceito de negócio soa a objeto Salesforce. Foi por isso que construímos primeiro o modelo lógico: dá-nos algo contra o qual testar o design no Salesforce.
Uma entidade de negócio não significa automaticamente um objeto personalizado
Seção intitulada “Uma entidade de negócio não significa automaticamente um objeto personalizado ”Eis uma armadilha que quero que os administradores evitem: «Identificámos onze entidades, por isso precisamos de onze objetos personalizados.» Não. Uma entidade lógica diz-nos que o conceito de negócio importa. Não dita como o Salesforce o deve armazenar. Um conceito pode passar a ser um objeto padrão, um objeto personalizado, uma relação entre objetos, um campo ou alguns campos, um valor gerido na configuração, ou dados que vivem totalmente fora do Salesforce (as fotografias de entrega da Steve Trucking são boas candidatas a isso). O modelo físico é onde essas escolhas são feitas, e é exatamente por isso que não as fizemos na primeira conversa.
Os atributos tornam-se campos físicos
Seção intitulada “Os atributos tornam-se campos físicos ”A mesma transição acontece com os atributos. O nosso Camião lógico tem número da unidade, número de quadro (VIN), marca, modelo, ano do modelo, matrícula e estado. Agora decidimos como existem fisicamente: que objeto é dono deles, que tipos de campo usam, quais são obrigatórios, quais têm de ser únicos, quais são identificadores externos, quais precisam de validação, quais são derivados em vez de armazenados, e quais são sensíveis. No nível lógico perguntamos o que significa Camião. No nível físico perguntamos como vai o Salesforce representar o Camião. Perguntas diferentes.
As relações tornam-se decisões de plataforma
Seção intitulada “As relações tornam-se decisões de plataforma ”Todo o tempo que gastámos com as relações compensa aqui. Já sabemos se cada uma é um-para-um, um-para-muitos ou muitos-para-muitos, obrigatória ou opcional, e se o seu histórico importa. Agora decidimos como o Salesforce a implementa: uma relação de pesquisa, uma mestre-detalhe ou um objeto de junção do Salesforce (Salesforce Junction Object), e talvez uma junção com atributos próprios, porque, como descobrimos, a própria relação pode ter significado de negócio.
Pense outra vez na Atribuição de equipa. Poderíamos ter começado este capítulo a dizer: «Vamos criar um objeto de junção do Salesforce entre equipa e camião.» Veja o que teríamos saltado: porque existe a relação, se precisa de uma data e de uma rota, se tem um estado, e se uma reclamação por danos semanas depois precisa do seu histórico. Estas perguntas de negócio dizem-nos o que uma Atribuição de equipa é. Só então devemos decidir como o Salesforce a constrói, e se o Salesforce já tem algo que faça o trabalho.
Agora desenhe o modelo físico
Seção intitulada “Agora desenhe o modelo físico ”O diagrama muda outra vez. O modelo conceitual mostrava conceitos de negócio e linhas simples. O modelo lógico acrescentou atributos, chaves, cardinalidade e as entidades escondidas nas relações. Agora o modelo físico começa a parecer Salesforce: objetos padrão, objetos personalizados, campos, tipos de relação, e o que vive fora da plataforma.
Quero que consiga pôr estes três diagramas lado a lado e ver a progressão: não três diagramas sem relação, mas o mesmo negócio em três níveis.
Uma palavra sobre como desenho estes diagramas, porque o layout faz parte da mensagem. Ponho o objeto principal no meio, um pouco abaixo. Se tem objetos pais, ponho-os um pouco acima, para que se leia o modelo de cima para baixo, da esquerda para a direita, da forma como o negócio pensa nele. Os dados de referência vão para o lado. A cor também significa algo: faço sempre o Salesforce a azul, e escolho uma cor para os sistemas da própria empresa, normalmente verde, porque o verde é uma cor simpática. Não uso vermelho, e os amarelos são um pouco agressivos. Quando um modelo está organizado assim, canta para mim. Muitos dos diagramas que vai encontrar são, na verdade, gestão de espaço: como estaciono todos os meus carros na minha garagem cheia? Prefiro pintar um quadro lógico que a mente consiga captar.
O modelo físico tem de respeitar a plataforma
Seção intitulada “O modelo físico tem de respeitar a plataforma ”O Salesforce não é uma base de dados relacional genérica. Tem opiniões sobre relações, propriedade, segurança e relatórios. Tem limites, comportamento de consulta e automação, e uma arquitetura que afeta como um modelo se comporta à escala. Por isso, um modelo lógico que parece perfeito num quadro branco pode ter de mudar quando se torna físico. Isso não é o Salesforce a atrapalhar. Significa que a plataforma tem uma forma, e os bons arquitetos entendem essa forma. O próximo capítulo trata exatamente disso.
Às vezes, também, o modelo físico vai diferir de propósito do modelo lógico limpo por causa das decisões de desnormalização que tomámos no módulo 5. Não há problema, desde que consigamos explicar porquê.
Não projete a partir do Setup
Seção intitulada “Não projete a partir do Setup ”Há um hábito que quero que abandone, se o tiver: começar a sua arquitetura de dados em Setup → Gestor de objetos → Novo objeto personalizado e ir descobrindo o modelo pelo caminho. O Salesforce torna incrivelmente fácil criar coisas; essa é uma das suas forças, e um dos motivos pelos quais os modelos de dados fracos surgem tão depressa. Alguns cliques e tem um objeto, mais alguns e tem campos e uma relação. Depois chegam os dados, são construídos os flows, são criados os relatórios, as integrações passam a depender dele, e o objeto que criou em cinco minutos fica muito caro de mudar. É o Teste de Reversibilidade do capítulo 1. Por isso, antes de clicar em Novo objeto personalizado, desenhe o modelo.
Físico não quer dizer permanente
Seção intitulada “Físico não quer dizer permanente ”Há outro motivo para eu manter os três modelos separados: a tecnologia muda. Hoje parte dos dados da Steve Trucking vive no núcleo do Salesforce. Amanhã parte deles pode viver no Data 360, num data warehouse ou num sistema que ainda nem escolhemos, e o assistente de IA precisa da sua própria representação. A arquitetura física pode mudar, enquanto os conceitos de negócio se mantêm notavelmente estáveis: Parceiros retalhistas, entregas e Destinatários continuam a existir. É isso que dá valor ao modelo lógico. É uma descrição duradoura do negócio que não está presa à implementação de hoje.
O que um arquiteto decide aqui
Seção intitulada “O que um arquiteto decide aqui ”Quando transformo um modelo lógico num modelo físico do Salesforce, estou a decidir:
- Que entidades de negócio correspondem a capacidades padrão do Salesforce, e quais precisam de objetos personalizados ou de outra representação.
- Como os atributos lógicos se tornam campos físicos, e como as relações são implementadas na plataforma.
- Onde a desnormalização deliberada entra no design físico.
- Que dados pertencem ao Salesforce, e quais pertencem a outro lugar.
- Que características da plataforma exigem que o modelo físico seja diferente do lógico.
Acima de tudo, quero conseguir rastrear cada decisão de trás para a frente. Se apontar para algo no meu modelo físico e perguntar «Porque é que isto está aqui?», devo conseguir levá-lo de volta pelo modelo lógico e pelo modelo conceitual até algo de que o negócio realmente precisa: negócio → conceitual → lógico → físico.
Além do exame: o que a IA muda. A IA consegue agora levar um documento de requisitos até objetos e campos do Salesforce num só salto. Isso torna a sequência mais importante, não menos: se salta dos requisitos para a configuração, peça-lhe que mostre o que aconteceu pelo meio: o que decidiu que era uma entidade, que chaves escolheu, que relações presumiu e onde desnormalizou. São decisões de arquitetura, e o arquiteto continua a precisar de as ver.
Começámos este capítulo numa primeira conversa, a ouvir substantivos, e terminamo-lo com um modelo físico que conseguimos rastrear até ao negócio. Agora que escolhemos construir no Salesforce, a pergunta seguinte vai mais a fundo: sobre que tipo de plataforma de dados estamos realmente a construir?
Para saber mais
Seção intitulada “Para saber mais ”- Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab), Salesforce Developers, Winter ‘27 (em inglês, consultado em 2026-10-02): «configure parent-child relationships with no more than 10,000 children to one parent record» (configure relações pai-filho com no máximo 10 mil filhos por registo pai). Uma orientação sobre desequilíbrio de dados, não um limite rígido; o capítulo 7 aprofunda o tema.
- Roll-Up Summary Field (opens in a new tab), Ajuda do Salesforce (em inglês, consultado em 2026-10-12): um resumo de totalização conta ou soma registos de detalhe através de uma relação mestre-detalhe.