Bonne pratique : Modèle de données MDM

Cet article décrit la gouvernance MDM en général. Une liste non-exhaustive de bonnes pratiques relatives à l'utilisation de Talend MDM y est présentée.

Conventions de nommage des modèles de données

Les modèles de données doivent toujours avoir le même nom que leurs conteneurs de données associés.

Entités

Terminologie

Les entités doivent être nommées avec la terminologie la plus générique possible, pour décrire de la meilleure façon le business object qui va être géré. Vous devez vous assurer que toutes les spécifications fonctionnelles doivent être couvertes. Par ailleurs, évitez de nommer via une application/un nom source (SAPEntity par exemple), ou un nom organisationnel (HREntity par exemple).

Conventions de nommage

N'utilisez pas de caractère spécial ou de nombre dans le nom d'une entité.

Évitez d'utiliser plus de 20 caractères dans le nom de l'entité et évitez d'avoir des requêtes XPath trop longues dans les composants MDM par la suite.

Utilisez upper CamelCase pour améliorer la lisibilité des requêtes XPath.
Laissez la valeur du type de l'entité à anonymous.
Essayez de différencier les différents types d'entité en utilisant des préfixes, étant donné que l'éditeur de modèles de données permet de filtrer les entités à partir d'une expression régulière. Voici quelques exemples de types d'entités communs :
- Les entités maître (MST_.*)
- Les entités de référence (REF_.*)
- Les entités de référencement croisé (XREF_.*)

Éléments

Terminologie

Pour les entités, les éléments doivent être nommés de la façon la plus générique possible, afin de répondre à tous les besoins métiers relatifs à cet ensemble de données maître.

Libellés

Définissez toujours le libellé du langage par défaut d'un élément d'une entité, même si la valeur du libellé est la même que celle du nom de l'élément.

Sécurité

Tous les éléments d'un modèle de données doivent au moins avoir l'annotation de sécurité Write Access pour le rôle System_Admin, ce qui permet à l'administrateur d'avoir un accès complet au modèle de données entier.

Facettes

Lorsqu'une facette est définie sur un type d'élément, un message de facette doit toujours être défini pour avertir l’utilisateur en cas d'erreur. Tous les éléments possédant une facette ont une documentation définie, afin que l’utilisateur comprenne quelle contrainte est définie sur l'élément, dans l'interface utilisateur web.

Conventions de nommages

N'utilisez pas de caractère spécial ou de nombre dans le nom d'une entité.

Évitez d'utiliser plus de 20 caractères dans le nom de l'entité et évitez d'avoir des requêtes XPath trop longues dans les composants MDM par la suite.

Ne réécrivez jamais le nom de l'entité dans le nom de l'élément (ProductLabel par exemple). Cette action n'est pas utile et allonge le XPath.

Utilisez upper CamelCase pour améliorer la lisibilité des requêtes XPath.

Clés primaires

Clés primaires composites

Même s'il est possible de définir une clé primaire composite, cette action doit être évitée pour faciliter la gestion des données dans les Jobs. Si la clé primaire est composée de nombreux éléments, utilisez une clé de substitution à sa place.

Types

Pour des raisons de présentation, préférez AUTO_INCREMENT au type UUID.

Clés primaires non contrôlées par MDM

Faites très attention aux clés primaires non contrôlées de MDM. L'utilisation de clés non contrôlées MDM doit être réservée à des entités très statiques, lorsque vous êtes absolument sûr que la valeur de la clé primaire ne changera pas.

Cette action peut faciliter la mise à jour de l'entité en vous évitant de rechercher la valeur de la clé primaire, étant donné que vous la connaissez déjà.

Conventions de nommage

Les clés primaires doivent être nommées selon la convention suivante : Id + nom de l'entité (par exemple, IdPerson). Cette action facilite le retrait du nom d'élément dans la perspective Integration, ce qui permet au développeur de le deviner et de ne pas vérifier constamment le modèle de données.

Remarque : L'utilisation de cette convention de nommage vous permet d'écrire des Jobs particulièrement dynamiques, car vous saurez toujours comment obtenir le nom de la clé primaire.

Clés étrangères

Informations sur les clés étrangères

Une clé étrangère doit toujours avoir des informations de clés étrangères définies. En effet, la valeur de la clé étrangère technique peut ne pas présenter des informations métiers afin de permettre à l’utilisateur de choisir un enregistrement dans le sélecteur de clés étrangères (exceptés pour les entités qui ont des clés primaires importantes).

Filtre de clés étrangères

Lorsqu'il est nécessaire d'utiliser les filtres de clés étrangères, l'élément filtrant doit toujours être situé au-dessus de l'élément fixé, dans le modèle. Cette action augmente les chances d'obtenir un filtre défini, car l'utilisateur génère généralement des champs de haut en bas.

Répartir les entités dans différents onglets

Par défaut, les entités étrangères ne doivent pas être réparties dans différents onglets, excepté lorsque il y a un besoin métier explicite.

Dans la plupart des cas, seules les relations 1-to-many doivent être réparties dans différents onglets.

Conventions de nommage

Les clés étrangères doivent être nommées selon la convention suivante : Fk + nom de l'entité étrangère (par exemple, FkStore).

Cette action facilite le retrait du nom d'élément dans la perspective Integration, ce qui permet au développeur de savoir que MDM.createFK() est nécessaire, sans vérifier le modèle de données.

Types personnalisés simples

Réutilisation

Les types personnalisés simples doivent être créés uniquement lorsque le type est utilisé au moins deux fois dans le modèle. Ils doivent également être utilisés lorsqu'une modification doit être reproduite pour chaque élément les référençant.

Les types réutilisables communs sont email, phone number, par exemple. Pour tout les autres cas, vous devez utiliser les types anonymes.

Conventions de nommage

Les types personnalisés simples doivent être nommés selon la convention suivante : description du type + Type (par exemple, EmailType).

Lorsqu'une facette enumeration est utilisée sur un type simple, la convention de nommage est la suivante : description de l'énumération + Enum (par exemple, GenderEnum).

Types personnalisés complexes

Conventions de nommage

Pour les types complexes répétables (par exemple, 1..many), utilisez la convention de nommage suivante : description du type pluralisé + List (par exemple, ModulesList).

Tous les types personnalisés complexes doivent être nommés.

Héritage

Conventions de nommage

Les supertypes doivent être nommés selon la convention suivante : description du type + Specialization (par exemple, ContactSpecialization).

Les types héritant du supertype doivent ensuite être nommés comme suit : nom du supertype + spécialisation concrète (par exemple, ContactEmailSpecialization).

Cette action permet de comprendre comment le type a été créé dans l'onglet Reusable Data Types, pour le rendre plus lisible (par exemple, ContactEmailSpecialization : ContactSpecialization).

Éléments répétables

Lorsque vous utilisez le rapprochement intégré, l'algorithme Swoosh fonctionne sur des structures de table, et non sur des arborescences (bien que cela ne soit pas spécifique à Swoosh car de nombreux autres algorithmes ne fonctionnent pas sur des arborescences dans ces cas). Cela entraîne les limitations suivantes :

Impossibilité d'utiliser des éléments répétables
Impossibilité d'utiliser un élément lorsqu'au au moins un des éléments parent est un élément répétable.

Encapsulation

Les éléments répétables doivent être encapsulés dans un autre élément, étant que le même nom est pluralisé.

<Person>
   <.../> 
   <Addresses> <!-- [0..1] - Encapsulating element -->
      <Address> <!-- [0..many] - Repeatable element -->
      </Address>
   </Addresses>
</Person>

Imbrication

Pour assurer la compatibilité avec la fonctionnalité Partial Update, il n'est pas recommandé d'avoir plus d'un niveau d'éléments répétables.

Pour rendre votre modèle de données moins complexe, essayez d'éviter d'imbriquer des éléments répétables.

Éléments répétables multiples

Pour faciliter la gestion de données dans la perspective Integration, il n'est pas recommandé d'avoir de nombreux éléments répétables sur la même entité.