Este documento apresenta uma visão geral da notação e das convenções do diagrama de relacionamento de entidade (ERD) do Salesforce para ajudá-lo a interpretar claramente os modelos de dados de produto disponíveis na galeria de modelos de dados.

Um ERD, também conhecido como modelo de dados, é uma representação gráfica de um sistema de informações. Ele mostra os relacionamentos entre pessoas, objetos, locais, conceitos e eventos nesse sistema. É um modelo lógico que transmite a estrutura funcional dos dados. Em ERDs do Salesforce, as entidades geralmente são mapeadas para um objeto no banco de dados do Salesforce.

Uma entidade é uma coisa ou objeto de significância, seja real ou conceitual, sobre as quais as informações precisam ser conhecidas ou mantidas.

As entidades são representadas nos diagramas como caixas com cantos arredondados. Cada caixa de entidade geralmente fornece dois rótulos (quando aplicável):

• O nome lógico da entidade (por exemplo, "Entidade do Salesforce" no exemplo mostrado aqui). Isso pode corresponder ao rótulo singular do objeto do Salesforce representado, mas nem sempre.
• O Nome de API "físico" ou o Nome do desenvolvedor do objeto na sua organização do Salesforce (por exemplo, "Nome da API" no exemplo). Para objetos de pacote gerenciado, o nome da API listado no diagrama normalmente não inclui o namespace do pacote gerenciado ("vlocity_ins**", por exemplo), a menos que o Salesforce ou o Salesforce Cloud usem vários pacotes gerenciados. O fim do nome da API para objetos de pacote gerenciado denota o tipo de objeto personalizado usado: "**c" para objetos personalizados regulares e configurações personalizadas, "**mdt" para metadados personalizados, "**x" para objetos externos.

As caixas de entidade também podem listar um ou mais atributos que representam os atributos dessa entidade. Um atributo é precedido por um caractere "#" ou "-".

• Um "#" indica um atributo que faz parte da chave exclusiva lógica da entidade. No diagrama de exemplo, "Atributo de chave de usuário" é considerado a chave primária do usuário da entidade.
• Um "•" indica um atributo não-chave.

Cada diagrama de relacionamento de entidade ilustra o modelo de dados do Salesforce da perspectiva de uma nuvem especificada, como Sales Cloud, Service Cloud ou Marketing Cloud. O esquema de cores do diagrama reflete a nuvem em foco. Todas as nuvens do setor, como Financial Service Cloud, Health Cloud e Media Cloud, usam o mesmo esquema de cores do setor.

A cor de uma determinada entidade no diagrama também tem um significado específico. A cor da nuvem de foco é indicada usando a cor da marca do Salesforce, incluindo alguns exemplos abaixo.

A seção a seguir revisará a formatação de entidade diferente referente à legenda de exemplo do Sales Cloud abaixo:

Uma entidade com as cores da nuvem de foco representa um objeto que vem com a licença para essa nuvem.

Uma entidade com preenchimento branco e borda preta representa um objeto que vem com uma licença diferente da nuvem de foco e que não é estendida pela licença de nuvem de foco. As entidades Conta e Contato mostradas em um ERD do Sales ou do Service Cloud, por exemplo, serão exibidas como brancas com uma borda negra, pois esses objetos estão disponíveis com uma licença de plataforma.

Uma entidade com um preenchimento cinza claro e borda negra representa um objeto que vem com uma licença diferente da nuvem de foco, mas a nuvem de foco estende esse objeto. Por exemplo, o Commerce Cloud estende o objeto de base Product2 com campos adicionais. As extensões incluem campos adicionais, relacionamentos e tipos de registro.

Entidades sem fronteiras são virtuais. Quando usadas em um diagrama, essas caixas reconhecem a existência de uma entidade no modelo lógico do domínio, mas a entidade não é implementada como um objeto físico no Salesforce. Os dados dessa entidade devem ser acessados por meio de chamadas à API externas ou Salesforce Connect na solução implantada.

Entidades com uma borda tracejada são modeladas como tipos de registro no Salesforce. No exemplo mostrado aqui, os subtipos Conta comercial, Conta de cobrança, Conta de consumidor e Conta de serviço têm uma borda tracejada porque são mapeados para tipos de registro entregues com o pacote gerenciado do Communications Cloud.

Entidades com borda pontilhada são virtuais. Nenhum tipo de registro ou objeto separado é usado para diferenciar esses subtipos na solução do Salesforce. Esses subtipos representam de modo lógico um conceito do domínio que ajuda a ilustrar a funcionalidade do modelo de dados.

Um subtipo de uma entidade é a definição de um subconjunto de suas ocorrências. Quando um conjunto de subtipos é adicionado em uma entidade de supertype, a entidade de supertype descreve os atributos e relacionamentos comuns, enquanto as entidades de subtipo mostram atributos e relacionamentos específicos do subtipo. Na notação de diagrama, os subtipos são mutuamente exclusivos, o que significa que qualquer registro único deve ser de um único subtipo.

Os subtipos podem ter subtipos aninhados que diferenciam ainda mais as ocorrências. Os subtipos nos diagramas são lógicos, mas podem ser mapeados para uma representação física de uma de três maneiras. A solidez da borda da entidade do subtipo define como o subtipo é implementado no modelo de dados do Salesforce.

As entidades de subtipo com uma borda contínua têm um objeto real que rastreia as ocorrências desse subtipo. No exemplo mostrado aqui, o subtipo Usuário externo de Contato tem uma borda sólida porque os Contatos registrados como Usuários externos são rastreados com um registro no objeto Usuário.

Um relacionamento é uma associação nomeada e significativa entre duas entidades.

As marcações e o texto nas linhas ou ao redor delas descrevem a cardinalidade, a opcionalidade e o significado do relacionamento.

A cardinalidade indica o número relativo de ocorrências em cada lado do relacionamento. Na notação, os extremos de uma linha de relacionamento indicam a cardinalidade do relacionamento naquela extremidade. O rodapé de um corno em uma extremidade indica que muitas ocorrências de entidade nessa extremidade podem se relacionar a cada ocorrência na extremidade oposta. A ausência de um rodapé em uma extremidade indica que, no máximo, uma ocorrência de entidade nessa extremidade pode se relacionar a uma determinada ocorrência na outra extremidade.

O Salesforce oferece suporte a dois tipos de campos de relacionamento: campos de pesquisa e campos pai-filho (aka mestre-detalhes). Os campos Pai e Filho são como pesquisas obrigatórias, mas aplicam acoplamento adicional entre as entidades relacionadas. Os registros no muitos lados do relacionamento são excluídos em cascata quando o registro pai é excluído. Além disso, a visibilidade dos registros de detalhes é controlada pela visibilidade do registro pai.

Para ilustrar a diferença entre um relacionamento de filho e pai e um relacionamento de pesquisa, os ERDs do Salesforce emprestam a notação de diamante da UML. Um diamante no lado singular de um relacionamento significa que a entidade nesse lado desempenha o papel mestre no relacionamento. A entidade no lado múltiplo de um relacionamento desse tipo é a entidade de detalhe ou filha e pode ser considerada como contida na entidade pai.

A opcionalidade indica se o relacionamento é obrigatório ou não para uma ocorrência em cada extremidade. Como um conceito, a opcionalidade está intimamente relacionada à cardinalidade e a notação reflete essa proximidade. A opcionalidade é indicada em cada fim de um relacionamento por meio de um círculo ou de uma barra na linha no outro fim do relacionamento. Por que no outro lado do relacionamento? Para incluir a marcação de opcionalidade no mesmo lado da linha que a cardinalidade.

No lado de muitos (ou seja, o pé do corvo) do relacionamento, há quase sempre um círculo na linha. Isso significa que pode haver ocorrências de zero para muitos no lado de muitos do relacionamento para cada ocorrência no lado singular do relacionamento.

No lado singular do relacionamento, um círculo e uma barra indicam um relacionamento opcional para a entidade no lado do rodapé do relacionamento. O círculo e a barra significam que pode haver zero ou uma ocorrência no lado singular do relacionamento para cada ocorrência no lado de muitos.

Como alternativa, no lado singular do relacionamento, as barras duplas indicam um relacionamento obrigatório para a entidade no lado múltiplo do relacionamento. As barras duplas significam que deve haver uma e apenas uma ocorrência no lado singular do relacionamento para cada ocorrência no lado de muitos.

A opcionalidade de um relacionamento pode ser mostrada conforme necessário, embora o relacionamento físico subjacente no Salesforce seja opcional. Por exemplo, o campo AccountId em Contato é fisicamente um relacionamento opcional, mas, se você ignorar Contatos privados, o relacionamento direto de um Contato com uma Conta será lógicamente obrigatório. O indicador de opcionalidade é usado com moderação. Na maioria dos casos, a opcionalidade mostrada no ERD reflete a opcionalidade subjacente do relacionamento.

Além da cardinalidade e da opcionalidade, cada relacionamento entre duas entidades expressa um certo significado que distingue esse relacionamento de outros relacionamentos entre as mesmas duas entidades. Nomes de término de relacionamento, como "parte de" e "composta de" no diagrama acima, definem a natureza do relacionamento.

Quando você combina a cardinalidade, a opcionalidade e os nomes de término de um relacionamento, eles podem ser usados para formar uma frase que descreve o relacionamento.

Da esquerda para a direita: Cada (pode/deve) é <nome final 1> (um e apenas um / um ou mais) .

Da direita para a esquerda: Cada (pode/deve) é <nome final 2> (um e apenas um / um ou mais) .

Por exemplo,

Da esquerda para a direita: "Cada contato deve ser principalmente um contato para apenas uma conta." Da direita para a esquerda: "Cada conta pode ser representada principalmente por um ou mais Contatos."

As linhas de relacionamento são codificadas por cores. Os relacionamentos adicionados pela nuvem em foco para o diagrama são desenhados em uma cor. As linhas pretas representam um relacionamento que vem com uma licença diferente da nuvem de foco.

Os relacionamentos podem ser entre duas ocorrências da mesma entidade. Isso é chamado de relacionamento recursivo. Uma linha de relacionamento curva é usada para indicar relacionamentos recursivos.

Os ERDs do Salesforce normalmente excluem a maioria das regras de negócios para se concentrar na estrutura do modelo de dados, mas um relacionamento mutuamente exclusivo é uma regra de negócios que é informativa para a estrutura, portanto, é observado. Um relacionamento mutuamente exclusivo indica que apenas um dos vários relacionamentos incluídos no arco será usado para qualquer ocorrência específica. Observe que dois, três ou mais relacionamentos podem participar do mesmo relacionamento mutuamente exclusivo. Uma frase que descreve o relacionamento mutuamente exclusivo mostrado aqui pode ser: "Cada entidade pode ser uma instância de uma e apenas uma Primeira outra entidade ou uma e apenas uma Segunda outra entidade."

Observe que, nos ERDs do Salesforce, uma linha de relacionamento quebrada que passa pelo arco não faz parte do relacionamento mutuamente exclusivo.

Os ERDs de produto oficial do Salesforce seguem convenções de layout para melhorar a legibilidade. Essas convenções de layout incluem o seguinte:

• As linhas de relacionamento sempre devem ser diretas.
• As linhas de relacionamento devem ser desenhadas verticalmente ou horizontalmente. Em raras ocasiões em que isso não é possível, use uma linha reta em uma diagonal.
• Para manter as linhas de relacionamento diretas, as caixas de entidade podem ser redimensionadas (mais altas ou mais largas) para fornecer um ponto de aterrissagem para os relacionamentos entre as duas entidades. As entidades mais importantes (que têm mais relacionamentos disponíveis) são mostradas maiores no diagrama, reforçando sua importância.
• Ao longo de um único ERD, os pés do corno em relacionamentos devem estar consistentemente no lado esquerdo e/ou superior da linha de relacionamento (layout de cima para baixo) ou consistentemente no lado direito e/ou inferior da linha de relacionamento (layout de direita para cima). Essa convenção fornece clareza, pois resulta em entidades semelhantes reunidas na mesma área do diagrama, o que é útil para entender as entidades. Usar o layout de cima para baixo faz com que os diagramas apareçam de cima para baixo com entidades filho caindo acima ou à esquerda das entidades pai. No entanto, isso garante que as entidades mais específicas no diagrama fiquem no canto superior esquerdo do diagrama, o que torna os diagramas mais distinguíveis entre si e reconhecíveis. Usar a convenção de layout no lado direito para cima resulta em que as mesmas entidades comuns estejam no canto superior esquerdo de cada diagrama, mas as entidades filhas estarão abaixo ou à direita das entidades pai.

A estreita adesão a essas convenções de layout resulta em um diagrama limpo e fácil de ler.

Certifique-se de verificar a galeria de modelos de dados para os Modelos de dados do Salesforce mais recentes que seguem esse padrão.