Bonne pratique : Modèle de données MDM
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é.
- 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.
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
<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é.