Mais do que uma base de dados

🌐 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

Módulo 1 de 10 do capítulo Arquitetura de dados Salesforce, capítulo 3 do curso Data Architect. Cada módulo sustenta-se sozinho. Próximo: Olhe para a nave-mãe: os modelos de dados padrão

A pergunta que este módulo responde: O que torna o Salesforce diferente de uma base de dados tradicional?

Se é administrador Salesforce há algum tempo, já sabe criar um objeto. Setup, Gestor de objetos, Novo objeto personalizado. Dê-lhe um nome, acrescente alguns campos, monte um layout de página, e dez minutos depois os utilizadores conseguem trabalhar com ele.

Mas o que aconteceu realmente quando clicou em Guardar?

Se vem das bases de dados, provavelmente imagina que o Salesforce foi lá e criou uma tabela nova. Não criou. E entender porquê é um dos pontos em que começa a passar de pensar como administrador ou programador para pensar como arquiteto.

O Salesforce armazena dados, claro; há bases de dados por baixo. Mas o Salesforce não é uma base de dados com um ecrã bonito por cima. É uma plataforma de aplicações orientada por metadados, e essa distinção molda quase todas as decisões deste curso.

A plataforma tem uma forma

No capítulo 2 construímos o modelo sem nos preocuparmos nada com o Salesforce. Foi de propósito: ouvimos os substantivos, construímos o modelo conceitual, acrescentámos atributos, chaves e relações, e só então perguntámos como o Salesforce o deveria implementar. Agora precisamos de entender a coisa sobre a qual o estamos a implementar.

Uso uma frase simples para isto: a plataforma tem uma forma. O Salesforce dá-nos objetos, campos, relações, segurança, automação, APIs, transações, relatórios e pesquisa, e está tudo ligado. Quando crio um objeto, não estou só a criar um sítio para pôr linhas. Estou a criar algo que participa no modelo de segurança, sobre o qual a automação pode agir, que as APIs expõem, que os relatórios podem usar, com que outros objetos se podem relacionar, e de que utilizadores, integrações e, cada vez mais, agentes vão depender. Isso é muito mais do que uma tabela.

Os metadados são a planta

Pense num edifício. Há o edifício em si, e há a planta que o descreve: onde ficam as paredes, onde vão as portas, como se ligam as divisões. O Salesforce funciona da mesma forma. A definição de um objeto são metadados. A definição de um campo são metadados. Uma relação são metadados. A maior parte do que configuramos no Setup são metadados, e a plataforma lê-os em tempo de execução para dar à nossa org a sua estrutura e o seu comportamento.

A Salesforce descreve o coração da plataforma como multitenant e orientado por metadados: quando definimos um objeto ou um campo, a definição é armazenada como metadados, não como uma nova tabela ou coluna física para a nossa org (Platform Multitenant Architecture (opens in a new tab), em inglês).

Quando ensino isto, abro o capô. O Salesforce não lhe cria uma base de dados nova sempre que acrescenta um objeto. Acrescenta um registo às suas próprias tabelas: uma tabela de objetos, uma tabela de campos, uma tabela de dados, e tabelas auxiliares para índices e relações, tudo com a chave de um identificador de org que mantém os dados da sua org separados dos de todos os outros. Por isso acrescentar um campo é só acrescentar uma entrada. É por isso que consegue criar um num instante, à hora de almoço, em produção.

Isto também explica algo em que as pessoas tropeçam. Quando escreve SELECT Id, Name, Special__c FROM Account, parece uma só tabela. Por baixo, está a ler o objeto padrão e o seu campo personalizado de estruturas diferentes, por isso a plataforma está a fazer um join que nunca escreveu. Os índices existem, mas não funcionam como o índice de uma base de dados tradicional. Não precisa de conhecer os pormenores internos para o exame. Precisa de saber que o que vê no Gestor de objetos não é um retrato um-para-um de tabelas físicas, e que a abstração é ao mesmo tempo o poder da plataforma e o motivo pelo qual se comporta como se comporta.

Click to enlarge

Olhe para a nave-mãe

Uma das coisas que digo às pessoas nas aulas é para olharem para a nave-mãe. Antes de inventar uma forma complicada de fazer algo no Salesforce, veja como o próprio Salesforce o faz.

Pegue na Conta. Não foi o leitor que a criou; foi a Salesforce. Mas pode acrescentar-lhe campos, automatizar à volta dela, mudar os seus layouts, expô-la pelas APIs e relacionar outros objetos com ela. Os objetos personalizados correm na mesma maquinaria, e é por isso que objetos padrão e personalizados parecem tão semelhantes quando construímos sobre eles. No Apex, até partilham uma classe base, o sObject.

É esse o hábito sobre o qual este capítulo se constrói, e no próximo módulo olhamos a sério: para os modelos de dados padrão que a Salesforce já construiu por si.

Não estamos a construir ao lado do Salesforce. Estamos a estendê-lo.

A sua API veio com o objeto

Crie uma tabela numa base de dados tradicional e tem uma tabela. Se outra aplicação precisa de trabalhar com ela, alguém tem mais trabalho pela frente. Crie um objeto no Salesforce, e a plataforma já o entende através das suas camadas de aplicação e de integração: usa os mesmos metadados para oferecer as suas APIs REST e SOAP, por isso os registos do objeto podem ser criados, lidos, atualizados e eliminados através delas a partir do momento em que o objeto existe (Platform Multitenant Architecture (opens in a new tab), em inglês).

Não projetei uma API por ter criado um objeto. A plataforma conhece o objeto, os seus campos, os seus tipos, as suas relações e a sua segurança. Esse é um dos motivos pelos quais o desenvolvimento em Salesforce anda tão depressa. É também por isso que criar um objeto é uma decisão maior do que parece: está a ligar uma estrutura a uma plataforma de aplicações inteira. E vale também para o outro lado. Pessoas que vêm do SQL Server ou do Oracle às vezes perguntam-me como carregar dados diretamente na base de dados. Não dá. Tudo entra pelas APIs.

O prédio de apartamentos

Agora a palavra que ouve a toda a hora: multitenancy, ou multilocação. Penso nisto como um prédio de apartamentos.

Tem o seu apartamento. Os seus móveis são seus, e a sua chave não devia abrir a minha porta. Mas partilhamos o prédio: a eletricidade, a água, os elevadores, a entrada. A sua org parece um ambiente só seu, com os seus dados, os seus objetos, a sua automação. Por baixo, a Salesforce descreve cada org como um inquilino (tenant), isolando os dados, os metadados e a lógica de cada inquilino enquanto a infraestrutura e os serviços são partilhados (Platform Multitenant Architecture (opens in a new tab), em inglês). É assim que consegue dar a cada cliente uma plataforma tão personalizável sem correr uma pilha separada para cada um.

Mas partilhar o prédio tem consequências. Se um inquilino compra um ar condicionado enorme e liga o secador de cabelo e o forno ao mesmo tempo, faz disparar o disjuntor, e o andar inteiro fica às escuras.

Não se pode apoderar do elevador

Fique no prédio mais um minuto. Imagine que um morador anuncia: «Preciso do elevador das oito ao meio-dia. Mais ninguém o pode usar.» Isso não funciona num prédio partilhado, e também não funciona no Salesforce. Não se pode permitir que um inquilino consuma recursos partilhados sem limite e degrade a plataforma para todos os outros.

É daí que vêm os limites do governador (governor limits). Se já desenvolveu no Salesforce, provavelmente conheceu-os como uma lista de números para decorar. Não quero que pense neles assim. A Salesforce aplica limites ao nível da transação e da org para que a carga de trabalho de um inquilino não monopolize a computação partilhada (Architecture Basics (opens in a new tab), em inglês). Essa é a arquitetura; cada limite individual é só a sua implementação. Mais adiante no curso vamos importar-nos com limites específicos porque mudam um design. Por agora, lembre-se do prédio: tem uma liberdade enorme para remodelar o seu apartamento. Não se pode apoderar do elevador.

Os IDs do Salesforce fazem parte da abstração

Cada registo Salesforce tem uma identificação que a plataforma entende, o ID de registo, e funciona em todas as capacidades: a interface, as APIs, os relatórios, a automação.

No capítulo 2 dissemos que uma boa chave é única, imutável, sem significado e nunca dado pessoal. O ID do Salesforce cumpre isso para o Salesforce. Mas não é o mesmo que uma chave de negócio. A sua empresa pode continuar a ter um número de cliente do ERP, um número de colaborador ou o número de encomenda de um parceiro que significa algo entre sistemas. Não confunda «o Salesforce sabe que registo é este» com «a empresa sabe que coisa de negócio é esta». São problemas de identificação diferentes, e o segundo volta na integração e nos dados mestres.

Os objetos são mais do que armazenamento

Eis a viragem que quero que faça antes do resto deste capítulo. Um objeto não é só um sítio para guardar dados. Um campo não é só uma coluna, e uma relação não é só uma chave estrangeira. Uso as comparações com bases de dados quando ensino, porque se ligam ao que as pessoas já sabem. Mas se pararmos aí, perdemos a arquitetura.

O objeto que escolhemos decide que capacidades vêm com ele. O tipo de campo afeta validação, integração, pesquisa, relatórios e como outros sistemas leem os dados. A relação decide ciclo de vida, propriedade, partilha e eliminação. Onde pomos os dados afeta armazenamento, desempenho e escala. E, como tudo isto corre numa plataforma partilhada, uma escolha inofensiva com cem registos pode comportar-se de forma muito diferente com cem milhões. Vamos tomar estas decisões uma de cada vez.

Além do exame: o que a IA muda. Durante anos, bons nomes e boas descrições ajudaram o administrador ou programador seguinte a entender o que construímos. Agora as máquinas também leem esse contexto. Um sistema de IA a trabalhar com um campo chamado Flag2__c tem o mesmo problema que um programador novo: o que significa esta coisa? Os metadados já não são decoração; fazem parte de como as máquinas entendem a aplicação.

O que um arquiteto decide aqui

• Estou a projetar para a plataforma em que realmente estou, ou a tratar o Salesforce como uma base de dados genérica?
• Que partes do meu design são conceitos de negócio, e quais são escolhas de implementação do Salesforce?
• Que comportamento da plataforma vem junto com a estrutura que estou prestes a criar?
• Que limites são expressões da arquitetura partilhada, e quais deles vão moldar este design?
• Se esta estrutura vai ser difícil de mudar depois, estou a tratá-la como uma decisão de arquitetura?

No capítulo 2 dissemos: não projete a partir do Setup. Agora conhece outro motivo. Clicar em Novo objeto personalizado não lhe dá só uma tabela; liga mais uma peça da sua arquitetura a uma plataforma multitenant orientada por metadados. Mas antes de decidir que objeto criar, há uma pergunta mais básica: estes dados deveriam sequer viver aqui? É o próximo módulo.

Para saber mais

• Salesforce Architects, Platform Multitenant Architecture (opens in a new tab) (em inglês, consultado em 2026-10-02; consultado novamente em 2026-10-12): as definições de objetos e campos são guardadas como metadados, não como tabelas novas; tabelas partilhadas (MT_Objects, MT_Fields, MT_Data, MT_Indexes) indexadas pelo OrgID; os mesmos metadados oferecem as APIs REST e SOAP.
• Salesforce Architects, Architecture Basics (opens in a new tab) (em inglês, consultado em 2026-10-02; consultado novamente em 2026-10-12): limites do governador e de execução para que o código e as transações «não monopolizem recursos de computação partilhados».