Práticas recomendadas para o Dataverse

5 minutos

A modelagem de dados é uma ciência. Existem profissionais e padrões estabelecidos de modelagem de dados. Para trabalhar com a modelagem de dados do Dataverse de forma eficiente, você não precisa ser profissional nem usar ferramentas especiais. Ferramentas conhecidas, como o Microsoft Visio, podem ser usadas para criar rapidamente um ERD (diagrama de relacionamento entre entidades) básico que visualize os relacionamentos e o fluxo de dados entre tabelas.

Esta unidade se concentra em práticas recomendadas gerais para a modelagem de dados de implantações do Dataverse, incluindo:

Os modelos de dados devem ser atualizados continuamente durante uma implantação. Normalmente, um modelo de dados é criado no início de um projeto, mas é importante que o processo de design não pare nesse ponto. À medida que você realiza a implantação, novas colunas e tabelas são adicionadas. Você precisa capturar essas novas colunas e tabelas no modelo de dados e, depois, torná-las um modelo de dados dinâmico. Além disso, você deve recomendar aos clientes que continuem a atualizar o modelo de dados à medida que aperfeiçoam o sistema.
Use as ferramentas estabelecidas para ajudá-lo a iniciar. As ferramentas de comunidade estão disponíveis com o XrmToolBox que facilita a geração rápida de diagramas ERD de configuração do Dataverse. Essas ferramentas incluem o gerador de diagrama UML e o criador de diagrama de relação de entidades. Após concluir as atualizações de configuração, você poderá gerar um diagrama ERD atualizado.
Não inclua todas as tabelas. Algumas tabelas principais, como Atividades, Anotações e Usuários (proprietários de registros), estão relacionadas a quase todas as tabelas no Dataverse. Se você incluir cada relacionamento com essas tabelas no modelo de dados, o resultado será ilegível. A prática recomendada é incluir somente as tabelas principais usadas na configuração no diagrama de modelo de dados e incluir apenas relacionamentos personalizados com as tabelas Usuário e Atividade para maximizar a legibilidade.
Os modelos de dados devem incluir tabelas externas ao Dataverse. Se você estiver integrando-se a outros sistemas por meio de conectores de dados ou tabelas virtuais do Dataverse, ou a fluxos de dados fora do Dataverse por meio de uma integração, esses dados também deverão ser representados no diagrama de modelo de dados.
Comece com as tabelas padrão e adicione relacionamentos de tabela personalizados ao modelo de dados.
A experiência deve influenciar o modelo de dados. Às vezes, pode ser fácil normalizar demais os dados, mas no processo, você pode complicar o uso do aplicativo.

Comece com o que você precisa agora, mas crie o modelo de dados de forma adaptável ao que será feito no futuro. Por exemplo, se você sabe que precisará armazenar mais detalhes sobre regiões de vendas, pode usar uma coluna de texto para a região agora, o que dificultará a implementação do que se você usar o relacionamento da tabela de regiões. Planeje o futuro desde já.

Tabelas prontas para uso ou personalizadas

Este tópico identifica as tabelas padrão, prontas para uso, que são usadas na configuração, junto com as tabelas personalizadas e a finalidade de uso delas. Essas informações são importantes porque o Microsoft Dataverse tem várias tabelas comuns e, como regra geral, uma tabela personalizada não deverá ser criada se já existir uma tabela padrão que atenda à finalidade desejada. O motivo é que, se você sobrecarregar a configuração com várias tabelas redundantes, o desempenho do sistema será prejudicado, e você dificultará o uso do sistema (ter várias tabelas de teste redundantes na Localização Avançada confunde os usuários). Cada tabela personalizada deve ter uma finalidade específica.

Além disso, este tópico ajudará a identificar as tabelas que são mais usadas e se você corre o risco de ter excesso de tabelas.

Reconsiderar a substituição de tabelas padrão por tabelas personalizadas

Em alguns casos, os criadores consideram a substituição da funcionalidade padrão por tabelas personalizadas. O motivo dessa consideração é que, se os criadores precisarem de uma oportunidade de vendas, mas com um formulário mais simples do que o formulário de oportunidade padrão, talvez seja mais fácil criar uma tabela personalizada. Entretanto, você deve considerar o que tem a perder ao usar uma tabela personalizada em vez de uma tabela padrão. O uso de uma tabela pronta para uso garante um maior alinhamento com os principais recursos da plataforma. Como mais recursos são regularmente adicionados às tabelas padrão, você pode aproveitar os novos recursos logo que são lançados. Por exemplo, se você decidiu substituir a tabela de oportunidade padrão por uma personalizada, não pode usar o suplemento do Sales Insights para o Microsoft Dynamics 365 Sales e outros recursos de IA.

Evitar a recriação de contas e contatos

Ao implantar soluções Microsoft Power Platform, você costuma rastrear vários tipos de empresas, organizações e contatos no sistema. Algumas dessas entidades representam clientes/organizações de clientes, enquanto outras podem ser empresas de suporte e consultoria, como contadores e escritórios de advocacia. Algumas entidades podem ser tipos diversos de organizações, como associações comerciais.

A abordagem mais comum do gerenciamento de várias categorias de relacionamentos da empresa é usar a tabela Conta para todos os tipos de empresa e usar uma coluna, como Tipo de relacionamento, ou um conjunto de opções personalizadas para sinalizar empresas por tipo ou categoria. Você pode filtrar exibições com base no tipo de empresa. As regras de negócios podem mostrar ou ocultar condicionalmente os componentes de coluna e formulário com base no tipo.

Para se beneficiar de uma integração padrão com os aplicativos de finanças e operações do Dynamics 365 usando a infraestrutura de gravação dupla, é melhor usar as tabelas e colunas padrão adicionadas pela solução principal de gravação dupla a seu ambiente Dataverse.

Outra abordagem é criar tabelas personalizadas para cada tipo de empresa. Um motivo muito citado é: "Talvez as contas sejam necessárias por outro motivo no futuro, portanto, não desejo personalizar a tabela Conta".

Antes de recriar a tabela Conta como uma tabela personalizada da empresa, você deve considerar o que perde ao criar uma tabela personalizada. Considere os seguintes fatores:

Vários endereços: a tabela Conta tem uma capacidade de endereço exclusiva compatível com vários endereços. Os dois primeiros endereços são exibidos no formulário da empresa, mas esses registros de endereço residem na tabela Endereço do Cliente relacionada. Embora você possa criar uma tabela de endereços personalizada que esteja vinculada a uma tabela personalizada da empresa, seria necessário um desenvolvimento para recriar a lógica única em que os endereços são armazenados na tabela relacionada e são apresentados nas exibições de formulário e tabela. Se você precisar de vários endereços, use a tabela Conta.
Hierarquia de contatos: as contas são pais de contatos. As atividades relacionadas a contatos são acumuladas no registro da conta primária. Esta hierarquia não pode ser substituída por um registro personalizado da empresa. Você pode criar mais relacionamentos com tabelas personalizadas da empresa, mas o relacionamento conta/contato padrão não pode ser substituído. Se a empresa tiver contatos com os relacionamentos da empresa primária para esse tipo de empresa ou se você desejar acumular atividades de contatos para empresas, use a tabela Contas.
Controle de mapeamento padrão: em aplicativos baseados em modelo, o controle de mapeamento padrão não é compatível com tabelas personalizadas da empresa.
Relacionamentos hierárquicos: relacionamentos hierárquicos entre as contas pai/filho e a visualização de hierarquia padrão, e o acúmulo de atividades da conta filho na conta primária funcionam somente com tabelas de conta padrão.
Colunas de pesquisa polimórfica: o Dataverse inclui um tipo especial de coluna de pesquisa polimórfica denominado coluna de cliente. Essa coluna permite que uma linha seja vinculada a uma empresa/conta ou um contato.
Marketing não funciona: as listas do Marketing só funcionam com contatos, contas e clientes potenciais, mas não com tabelas personalizadas. O Microsoft Dynamics 365 Customer Insights - Journeys pode fazer envios para contas e contatos, mas não para tabelas personalizadas da empresa.

Portanto, em quase todas as situações, a tabela Conta deve ser usada para registros da empresa de todos os tipos, com as seguintes exceções:

Tipos secundários de empresas que não são relacionais e têm atributos mínimos. Considere um tipo de organização sem contatos, sem endereço e que existe somente para fins de pesquisa.
Empresas não qualificadas ou não verificadas que são importadas de cartões de visita ou formulários da Web que você não deseja incluir na tabela Conta. Nessas situações, você pode usar a tabela Cliente potencial.

Redefinir a finalidade das tabelas do sistema

Considere o cenário em que você tem um requisito comercial semelhante a oportunidades, mas que não é uma oportunidade de vendas real. Nessa situação, você pode considerar a redefinição da finalidade das tabelas do sistema ou a criação de novas tabelas.

As seções a seguir explicam os fatores que devem ser considerados antes de redefinir a finalidade das tabelas do sistema.

Considere o futuro

O futuro do Microsoft Power Platform nunca esteve tão próximo. Portanto, o uso de tabelas diferentes do padrão poderá gerar problemas se a Microsoft fizer alterações na tabela utilizada. Além disso, se você redefinir a finalidade de uma tabela do sistema raramente usada, como Contratos, a Microsoft poderá preteri-la no futuro. As tabelas personalizadas não são preteridas. Além disso, se você redefinir a finalidade de uma tabela do sistema, considere o que fará se depois precisar dessa entidade para os fins pretendidos. Os clientes que reaproveitaram um caso eventualmente precisaram do gerenciamento de casos e tiveram que resolvê-lo com tabelas personalizadas, pois a tabela de casos padrão já era usada para fins diferentes.

Considerar a sobrecarga

Muitas tabelas do sistema têm determinadas colunas que não podem ser removidas dos formulários. Por exemplo, algumas colunas em tabelas, como Caso de oportunidade e Campanha, não podem ser removidas do formulário. Embora você possa ocultar essas colunas, ter várias colunas bloqueadas no formulário pode sobrecarregar a configuração do ambiente.

Considere a experiência do usuário

Se seu caso de uso tiver menos de 50% de alinhamento com a funcionalidade da tabela padrão, uma tabela personalizada oferecerá aos usuários uma experiência mais simples do que a redução de uma tabela mais complexa. Também é possível adicionar fluxos de processos empresariais a qualquer tabela, incluindo tabelas personalizadas, o que pode melhorar a experiência do usuário tão ou mais eficazmente do que alterando a finalidade de uma tabela do sistema.

Evitar armadilhas comuns

Veja a seguir alguns problemas comuns da modelagem de dados:

Muitas tabelas: é provável que as tabelas tenham excesso de normalização.
Muitas colunas em uma tabela: é provável que tenha sido criada uma tabela separada.
Usar as ferramentas: formulários de visualização rápida em vez de colunas repetidas.
Evitar tipo de dados Sim/Não: se for possível adicionar mais valores, ou se você precisar armazenar os valores como Desconhecidos.
Armadilhas de formatação: você está limitado à formatação do tipo de dados.
Partes não usadas: evite criar partes do modelo de dados que você não pretende usar.

Prova de conceito

O Dataverse simplifica o desenvolvimento de um ambiente de avaliação e acelera a criação de tabelas e relacionamentos. Você pode criar provas de conceitos para testar o modelo de dados e avaliar a experiência do usuário.

Continuar