Transforme o modelo em Salesforce

🌐 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

Módulo 6 de 6 do capítulo Modelar dados pelo significado, capítulo 2 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Projete até a 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 um modelo de dados lógico se torna um modelo de dados físico no Salesforce?

Finalmente vamos falar de Salesforce. Se você vinha resistindo à vontade de transformar cada caixa num objeto, agora pode. Mas repare na ordem em que chegamos aqui: entendemos o negócio, descrevemos os dados, colocamos cada fato onde ele pertence e decidimos onde iríamos dobrar isso de propósito. Só agora estou perguntando como o Salesforce deve implementar isso. Essa é a progressão que quero que você lembre: 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 vamos realmente construí-lo.

Senta, fica, modelo

O passo físico é mais fácil de ver em algo pequeno, então os pets vão primeiro.

Quem são as empresas e as pessoas? O criador é uma empresa, então vira uma Conta com o tipo de registro Criador. O dono também é uma Conta, ou uma Conta pessoal, com o tipo de registro 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 viram objetos personalizados. E lembra da espécie que copiamos para o pet no módulo 5? Aqui ela ganha seu trabalho: vira o tipo de registro do Pet, Cachorro ou Gato. Um objeto com dois tipos de registro, cada um com seu próprio layout de página e seus valores de lista de opções, em vez de um objeto Cachorro e um objeto Gato.

Quais relacionamentos são mestre-detalhes? Uso mestre-detalhes só onde o filho nunca vai trocar de pai. Um Truque do pet pertence ao seu pet a vida inteira, e cada Avaliação do truque pertence ao seu Truque do pet, então os dois são mestre-detalhes. Isso compensa na hora: é o mestre-detalhes 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 fique em sincronia sozinha. Mas os pets mudam de casa, então o Dono é um relacionamento de pesquisa.

Quais são relacionamentos 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 passariam disso facilmente, então o Truque do pet aponta para o seu Truque com um relacionamento de pesquisa, e o pet aponta para a sua Raça e o seu Criador do mesmo jeito. E evite relacionamentos polimórficos quando puder, aqueles 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 precisa lê-los depois: relatórios, integrações e, agora, agentes.

O que fica fora da plataforma? Se o pet usa uma coleira com GPS que informa onde ele está, essa localização não precisa ser copiada para dentro. Ela pode ser um objeto externo, lido ao vivo do sistema de rastreamento da coleira.

Click to enlarge

Cada decisão nesse diagrama remonta a algo que decidimos antes, e esse é o ponto. Agora o mesmo passo para a Steve Trucking.

Comece pelo modelo lógico

Nosso modelo lógico da Steve Trucking agora contém Parceiro varejista, Centro de distribuição, Manifesto, Entrega, Item de entrega, Destinatário, Rota, Parada, Equipe, Caminhão e Atribuição de equipe. Esses são conceitos de negócio, e agora posso começar a mapeá-los para o Salesforce.

Um Parceiro varejista talvez seja uma Conta. Uma entrega talvez corresponda a algo que o Salesforce já tem para trabalho agendado em campo, ou talvez vire um objeto personalizado. Um manifesto não tem nada padrão que sirva, então provavelmente vira personalizado. E o Destinatário é uma pergunta realmente difícil: uma Conta pessoal, um Contato, ou simplesmente informação na entrega? Vamos responder a essa direito no próximo capítulo.

A palavra importante continua sendo talvez. Não presuma a implementação só porque um conceito de negócio soa como um objeto Salesforce. Foi por isso que construímos o modelo lógico primeiro: ele nos dá algo contra o qual testar o design no Salesforce.

Uma entidade de negócio não significa automaticamente um objeto personalizado

Eis uma armadilha que quero que os administradores evitem: “Identificamos onze entidades, então precisamos de onze objetos personalizados.” Não. Uma entidade lógica nos diz que o conceito de negócio importa. Ela não dita como o Salesforce deve armazená-lo. Um conceito pode virar um objeto padrão, um objeto personalizado, um relacionamento entre objetos, um campo ou alguns campos, um valor gerenciado na configuração, ou dados que vivem totalmente fora do Salesforce (as fotos 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.

Atributos viram campos físicos

A mesma transição acontece com os atributos. Nosso Caminhão lógico tem número da unidade, chassi (VIN), marca, modelo, ano do modelo, placa e status. Agora decidimos como eles existem fisicamente: qual objeto é dono deles, que tipos de campo usam, quais são obrigatórios, quais precisam 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 Caminhão significa. No nível físico perguntamos como o Salesforce vai representar o Caminhão. Perguntas diferentes.

Click to enlarge

Relacionamentos viram decisões de plataforma

Todo o tempo que gastamos com relacionamentos compensa aqui. Já sabemos se cada um é um-para-um, um-para-muitos ou muitos-para-muitos, obrigatório ou opcional, e se o histórico dele importa. Agora decidimos como o Salesforce o implementa: um relacionamento de pesquisa, um mestre-detalhes ou um objeto de junção do Salesforce (Salesforce Junction Object), e talvez uma junção com atributos próprios, porque, como descobrimos, o próprio relacionamento pode ter significado de negócio.

Pense de novo na Atribuição de equipe. Poderíamos ter começado este capítulo dizendo: “Vamos criar um objeto de junção do Salesforce entre equipe e caminhão.” Veja o que teríamos pulado: por que o relacionamento existe, se ele precisa de uma data e de uma rota, se tem um status, e se uma reclamação de avaria semanas depois precisa do histórico dele. Essas perguntas de negócio nos dizem o que uma Atribuição de equipe é. 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

O diagrama muda de novo. O modelo conceitual mostrava conceitos de negócio e linhas simples. O modelo lógico acrescentou atributos, chaves, cardinalidade e as entidades escondidas nos relacionamentos. Agora o modelo físico começa a parecer Salesforce: objetos padrão, objetos personalizados, campos, tipos de relacionamento, e o que vive fora da plataforma.

Click to enlarge

Quero que você consiga colocar esses 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 esses diagramas, porque o layout faz parte da mensagem. Coloco o objeto principal no meio, um pouco abaixo. Se ele tem objetos pais, coloco-os um pouco acima, para que você leia o modelo de cima para baixo, da esquerda para a direita, do jeito que o negócio pensa nele. Os dados de referência vão para o lado. A cor também significa algo: sempre faço o Salesforce em azul, e escolho uma cor para os sistemas da própria empresa, normalmente verde, porque verde é uma cor simpática. Não uso vermelho, e os amarelos são um pouco agressivos. Quando um modelo é organizado assim, ele canta para mim. Muitos dos diagramas que você vai encontrar são, na verdade, gestão de espaço: como estaciono todos os meus carros na minha garagem lotada? Prefiro pintar um quadro lógico que a mente consiga captar.

O modelo físico precisa respeitar a plataforma

O Salesforce não é um banco de dados relacional genérico. Ele tem opiniões sobre relacionamentos, propriedade, segurança e relatórios. Tem limites, comportamento de consulta e automação, e uma arquitetura que afeta como um modelo se comporta em escala. Então um modelo lógico que parece perfeito num quadro branco pode precisar mudar quando se torna físico. Isso não é o Salesforce atrapalhando. Significa que a plataforma tem uma forma, e 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 tomamos no módulo 5. Tudo bem, desde que consigamos explicar por quê.

Não projete a partir do Setup

Há um hábito que quero que você abandone, se o tiver: começar sua arquitetura de dados em Setup → Gerenciador 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 modelos de dados fracos surgem tão rápido. Alguns cliques e você tem um objeto, mais alguns e tem campos e um relacionamento. Aí os dados chegam, os flows são construídos, os relatórios são criados, as integrações passam a depender dele, e o objeto que você criou em cinco minutos fica muito caro de mudar. É o Teste de Reversibilidade do capítulo 1. Então, antes de clicar em Novo objeto personalizado, desenhe o modelo.

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 de sua própria representação. A arquitetura física pode mudar, enquanto os conceitos de negócio continuam notavelmente estáveis: Parceiros varejistas, entregas e Destinatários continuam existindo. É isso que dá valor ao modelo lógico. Ele é uma descrição durável do negócio que não está presa à implementação de hoje.

O que um arquiteto decide aqui

Quando transformo um modelo lógico num modelo físico do Salesforce, estou decidindo:

• Quais 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 viram campos físicos, e como os relacionamentos são implementados na plataforma.
• Onde a desnormalização deliberada entra no design físico.
• Quais dados pertencem ao Salesforce, e quais pertencem a outro lugar.
• Quais 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 frente. Se você apontar para algo no meu modelo físico e perguntar “Por que isso está aí?”, devo conseguir levar você 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 agora consegue levar um documento de requisitos até objetos e campos do Salesforce num salto só. Isso torna a sequência mais importante, não menos: se ela pula dos requisitos para a configuração, peça que mostre o que aconteceu no meio: o que ela decidiu que era uma entidade, que chaves escolheu, que relacionamentos presumiu e onde desnormalizou. Essas são decisões de arquitetura, e o arquiteto ainda precisa vê-las.

Começamos este capítulo numa primeira conversa, ouvindo substantivos, e o terminamos com um modelo físico que conseguimos rastrear até o negócio. Agora que escolhemos construir no Salesforce, a próxima pergunta vai mais fundo: sobre que tipo de plataforma de dados estamos realmente construindo?

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 relacionamentos pai-filho com no máximo 10 mil filhos por registro pai). Uma orientação sobre desequilíbrio de dados, não um limite rígido; o capítulo 7 se aprofunda.
• 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 registros de detalhe por meio de um relacionamento mestre-detalhes.