Présentation

Effectué

Ce module décrit la stratégie de modélisation des données dans Microsoft Dynamics 365 et Microsoft Dataverse, puis explique comment l’atelier Modèle de données vous permet de vérifier qu’un modèle de données complet existe avant le début de la configuration. Les sections suivantes vous présentent brièvement de bonnes pratiques en matière de modélisation des données et leur relation avec un projet Dynamics 365.

Présentation de la modélisation des données

Un modèle de données est un modèle visuel montrant comment les données circulent dans votre système et comment différentes tables sont liées les unes aux autres. Les modèles de données définissent les types de relations entre les tables et synthétisent une base de données en une représentation visuelle simple.

La modélisation des données comporte plusieurs types et normes, notamment Unified Modeling Language (UML) et IDEF1X. Certaines normes de modèle de données sortent du cadre de ce module, mais les modèles de données pour les structures de données Dynamics 365 se répartissent généralement en deux catégories générales : logiques et physiques.

Modèles de données logiques

Les modèles de données logiques sont des diagrammes généraux montrant comment les données circulent dans le système. Ces modèles de données sont fréquemment rassemblés au début du projet lors de la découverte et avant que toutes les colonnes aient été définies. En général, le diagramme de modèle de données logique utilise les noms commerciaux des tables, et non le nom du schéma ou de la base de données.

Capture d’écran d’un exemple de diagramme de modèle de données logique.

Modèles de données physiques

Les modèles de données physiques sont de niveau inférieur aux modèles de données logiques. Ils comprennent généralement des détails au niveau de la colonne et des relations conçues plus précisément. Le modèle de données physique est créé lorsque la conception logique générale est convertie en tables physiques. Le schéma entité/association (ERD) est un type courant de modèle de données physiques.

Capture d’écran d’un exemple de diagramme de modèle de données physique.

Bonnes pratiques en matière de modélisation des données

La modélisation des données est une science, qui compte des professionnels et des normes établies. Pour être efficace avec la modélisation de données Dynamics 365, vous n’avez pas besoin d’être un modélisateur de données professionnel, ni d’utiliser des outils spéciaux. Des outils populaires tels que Microsoft Visio permettent de créer rapidement un schéma ERD de base qui visualise les relations et le flux de données entre les tables. Cette rubrique examine quelques bonnes pratiques générales en matière de modélisation de données pour les déploiements Dynamics 365.

Voici les bonnes pratiques à appliquer :

  • Les modèles de données doivent être mis à jour en permanence pendant un déploiement. En général, un modèle de données est conçu au début d’un projet, mais il est important que les mises à jour ne s’arrêtent pas là. Au fur et à mesure du déploiement, de nouvelles colonnes et tables sont ajoutées. Par conséquent, vous devez capturer ces nouvelles colonnes et tables dans le modèle de données pour en faire un modèle de données vivant. Recommandez aux clients de continuer à mettre à jour le modèle de données au fur et à mesure qu’ils améliorent le système.

  • Les outils communautaires disponibles avec XrmToolBox facilitent la génération rapide de schémas ERD de votre configuration Dynamics 365 et Dataverse. Ces outils sont le générateur UML et le générateur de schémas entité/association (ERD). Une fois les mises à jour de configuration terminées, générez un schéma ERD à jour.

  • N’incluez pas chaque table. Certaines tables principales telles que les tables activité, note et utilisateur (propriétaire d’enregistrement) sont associées à la quasi-totalité des tables dans Dynamics 365. Si vous incluez toutes les relations avec ces tables dans votre modèle de données, le résultat sera illisible. Il est recommandé d’inclure dans votre diagramme de modèle de données uniquement les tables principales exploitées dans la configuration et des relations personnalisées avec les tables utilisateur et activité pour optimiser la lisibilité.

  • Les modèles de données doivent inclure des tables en dehors de Dataverse. Si vous effectuez une intégration dans d’autres systèmes à l’aide des connecteurs de données ou des tables virtuelles Dataverse, ou si les données circulent en dehors de Dataverse à l’aide d’une intégration, ces données doivent également être représentées dans votre diagramme de modèle de données.

  • Commencez simplement, avec les tables standard, puis ajoutez des relations de table personnalisées à votre modèle de données.

  • L’expérience utilisateur doit influencer votre modèle de données. Parfois, il est facile de sur-normaliser vos données, mais cela peut rendre l’application plus lourde à utiliser.

  • Commencez avec ce dont vous avez besoin maintenant, mais concevez le modèle de données de manière à prendre en charge ce que vous prévoyez de faire à l’avenir. Par exemple, si vous savez que vous finirez par devoir stocker d’autres détails sur les secteurs de vente, l’utilisation d’un champ de texte pour le secteur rendra l’implémentation plus difficile que si vous utilisiez la relation de table de secteur. Prévoyez à l’avance vos besoins futurs.

Atelier Modèle de données

L’atelier Modèle de données doit être limité à environ une heure et se déroule souvent dans le cadre d’une réunion Microsoft Teams si tous les participants ne se trouvent pas au même endroit. Les participants doivent comprendre les principales parties prenantes des équipes client et partenaire. En général, la participation des architectes de solution et des responsables fonctionnels et techniques est obligatoire. Cet atelier doit avoir lieu à un moment où vous avez encore le temps et l’occasion de rectifier le tir, le cas échéant.

Les prochaines unités vont décrire les sujets recommandés à couvrir dans l’atelier Modèle de données.