PARTAGER L’ARTICLE SUR
Un modèle logique de données, MLD, est un modèle de base de données non spécifique qui décrit les objets sur lesquels une entreprise souhaite collecter des données et observer les relations entre ces éléments.
Un module racine contient toujours des objets du modèle logique. Il n’y a généralement qu’un seul paquet racine, mais nous pouvons ajouter des paquets supplémentaires sous le paquet racine pour regrouper des objets similaires.
Un modèle logique de données définit la structure des éléments de données ainsi que les relations entre eux. Elle est distincte de la base de données physique, qui spécifie comment les données seront mises en œuvre. Le modèle logique de données agit comme un plan pour les données utilisées. Le modèle logique de données développe les concepts de modélisation conceptuelle des données en incluant plus d’informations.
Le modèle logique de données combine toutes les informations essentielles au fonctionnement quotidien de l’entreprise.
Mener des recherches exploratoires semble délicat, mais un guide efficace peut aider.
Un modèle logique de données est composé de trois composants principaux :
Une personne, un lieu, un objet, un événement ou une notion d’intérêt pour un détaillant est représenté par un type d’entité. Clients, article, magasin de vente au détail, site Web, bon de commande, transaction de vente au détail et des centaines d’autres noms sont des exemples d’entités. Chaque type d’entité du modèle de données ARTS est spécifié en termes commerciaux. Les types d’entités sont représentés par des rectangles dans un diagramme d’entités.
Chaque type d’entité est doté d’une expression nominale distincte et singulière en guise de nom. Chaque instance de type d’entité au sein d’une architecture de données relationnelle est identifiable de manière unique par une clé primaire. Une clé primaire est constituée d’une ou plusieurs propriétés dont les valeurs sont utilisées pour identifier et différencier de manière unique une instance de type d’entité de toutes les autres.
Un attribut identifie, étiquette et spécifie une caractéristique ou une propriété d’un type d’entité. Un type d’entité Objet, par exemple, comprendra un attribut ObjetID pour l’identifier de manière unique. Il contiendra une propriété Nom, qui sera utilisée dans les catalogues et les étiquettes. Il contiendra une propriété Description, entre autres choses. Les attributs sont les composants les plus fondamentaux d’un modèle de données. Ils ne peuvent pas être décomposés en composants de niveau inférieur. Dans un modèle de données relationnel, un attribut ne peut exister indépendamment d’un type d’entité. Par conséquent, toutes les caractéristiques sont toujours identifiées et présentées comme faisant partie intégrante des types d’entités.
Une clé primaire, comme expliqué dans la section « Type d’entité », est composée d’une ou de plusieurs propriétés et sert d’identifiant unique pour une instance de type d’entité.
Une relation identifie, étiquette et spécifie un lien entre deux types d’entités. Une relation relie toujours deux et seulement deux types d’entités. Les expressions verbales sont utilisées pour indiquer les noms des relations. Les expressions verbales de relation peuvent être définies pour les deux sens d’une relation entre deux choses. Les types d’entités liés par une relation remplissent deux fonctions. Une entité de type parent est une entité unique. Une entité de type enfant est la seconde entité. L’entité parent et l’entité enfant partagent la même identité. Le type d’entité enfant est appelé type d’entité dépendant, car il hérite de la clé principale du type d’entité parent. Une clé étrangère est un attribut partagé par un type d’entité parent et un type d’entité enfant. Un nom d’attribut dans un diagramme d’entités est une clé étrangère désignée par le suffixe FK, Foreign Key.
Un type d’entité parent et enfant peut être associé de deux manières dans une architecture de données relationnelles. La première méthode consiste à établir une relation d’identification. Une connexion d’identification indique que la clé principale de l’entité enfant est héritée de son type d’entité parente. Autrement dit, l’existence du type d’entité enfant dépend de la présence de son type d’entité parente.
Si le type d’entité parent est détruit, dans ce cas, l’entité enfant est également supprimé. En revanche, un type d’entité enfant ne peut pas être entré tant que le parent auquel il fait référence n’est pas inséré. Une connexion d’identification est représentée dans un diagramme d’entité par une ligne continue reliant les types d’entités parent et enfant.
Une connexion non identifiante est la seconde méthode à laquelle les types d’entités parent et enfant peuvent être associés. Dans une connexion non identifiante, la clé primaire de l’entité parente est héritée en tant que propriété de clé non primaire par l’objet enfant. Cela signifie que l’entité enfant fait référence à son type d’entité parente, mais ne dépend pas de l’existence de son parent. Du point de vue d’une base de données relationnelle, cela signifie que la propriété héritée peut être nulle, c’est-à-dire qu’elle peut ne pointer vers rien. Une connexion non identifiante est représentée dans un diagramme d’entité par une ligne pointillée reliant les types d’entités parent et enfant.
La cardinalité est une caractéristique supplémentaire entre les types d’entités parent et enfant, qui se trouve incluse dans les relations. La cardinalité représente le nombre d’occurrences d’un type d’entité enfant qui peuvent exister pour un type d’entité parent. Une marque, par exemple, peut s’appliquer à zéro, une ou plusieurs instances de type d’entité Objet. En revanche, un article peut être désigné par zéro ou une marque. Un graphique peut facilement illustrer ces cardinalités. La cardinalité peut être exprimée de diverses façons pour transmettre le nombre relatif des types d’entités parentes aux types d’entités enfants.
Un autre type de graphique peut aisément illustrer un lien NON IDENTIFIANT entre l’article et la marque. Il peut également montrer comment présenter les clés étrangères, et la cardinalité, dans un diagramme d’entités. Il ajoute des attributs possédés, qui sont des attributs qui ne sont PAS hérités d’un autre type d’entité, et ne font pas partie de la clé principale d’un type d’entité.
Outre la cardinalité, il existe une connexion de sous-type qui permet à de nombreux types d’entités enfants d’hériter des attributs d’un type d’entité parent commun. Ceci est illustré dans le diagramme suivant. Le bloc jaune représente une définition de transaction de détail. Un RetailTransaction, tel que illustré ici, peut être associé à zéro, un ou plusieurs objets d’entité RetailTransactionLineItem. Étant donné qu’un élément de ligne ne peut pas exister sans en-tête de transaction de vente au détail, les entités RetailTransactionLineItem sont dépendantes.
Le type d’entité RetailTransactionLineItem peut être développé pour enregistrer les données de vente d’articles en tant que SaleReturnLineItem, les données de remise ou de rabais pour une transaction de vente au détail, en tant que DiscountLineItem, les données fiscales en tant que TaxLineItem ou les données de paiement en tant que TenderLineItem.
Un poste de transaction de détail possède un ensemble de propriétés (y compris le numéro de poste) qui sont partagées par tous les sous-types (c’est-à-dire possiblement à ériter par les enfants de sous-type).
Une instance de type d’entité RetailTransactionLineItem ne peut avoir qu’un seul sous-type. Cette idée relationnelle de sous-type est liée à l’héritage, dans la conception orientée objet, qui est utilisée pour décrire les classes et les objets. Les types d’entités enfants de sous-type décrivent efficacement une transaction de détail et les nombreux types d’éléments de ligne qui sont requis pour collecter les données d’article, de remise, de taxe et d’appel d’offres dans cet exemple. L’exemple de reçu montre comment chaque sous-type de RetailTransactionLineItem reflète différents postes de reçu de vente.
Un domaine est une sorte de représentation des données, qui est nommé et peut s’appliquer à une ou plusieurs caractéristiques. La représentation des données spécifie un type de données, tel qu’un entier, un texte, une virgule flottante, une date, une heure ou un autre type de données standard, ou une définition étendue qui ajoute des fonctionnalités et des restrictions spécifiques à un type de données de base.
Les domaines permettent ainsi la création de types de données spécifiques à la vente au détail, à partir de types de données SQL de base. Par exemple, ARTS a un type de domaine IdentityGTIN décrit comme suit : une identification pour l’article au point de vente – UCC/EAN définit le numéro d’article commercial international (GTIN). IdentityGTIN repose sur un type de données de base VARCHAR(14), qui est pris en charge par la grande majorité des bases de données standard SQL. Les domaines peuvent également être utilisés pour limiter les valeurs qui peuvent être affectées à un attribut à un domaine. Par exemple, les domaines Flag sont limités à deux valeurs « OUI » ou « NON ».
Étant donné que les données constituent la partie la plus importante de toute application, programme ou système, les systèmes de traitement et de stockage de données de haute qualité doivent être basés sur une structure de données sous-jacente parfaitement solide et fiable. Une structure de données solide permet aux développeurs d’applications de créer la meilleure interface utilisateur, le système de traitement ou la configuration d’analyse statistique et de reporting possible.
Peu importe à quel point votre système est sophistiqué ou complexe, il doit remplir des critères, obéir aux règlements et servir les objectifs de l’entreprise pour laquelle il a été conçu, sinon il sera inutile. Par conséquent, la modélisation logique des données combine les deux principes fondamentaux les plus importants du développement d’applications :
Voici les caractéristiques les plus importantes d’un modèle logique de données :
Découvrez le logiciel de sondage Voxco en action avec une démonstration gratuite.
La sémantique est l’étude du sens dans les langages et la logique. En plus de définir des entités, des propriétés, des connexions et des domaines, les modèles logiques clarifient ce que chaque instance de ces objets implique. Ces définitions offrent la substance sémantique d’un modèle de données et sont essentielles à la pertinence commerciale d’un modèle relationnel.
Le graphique ci-dessous illustre l’affectation d’une définition à l’attribut ItemID d’Objet/Item. Les définitions doivent être rédigées dans un langage métier et refléter les idées métier représentées par une entité de modèle de données, un attribut, une relation, un domaine ou d’autres objets de modèle.
Les modèles logiques de données ne sont pas réservés aux professionnels de l’informatique. Dans l’environnement commercial actuel, des modèles logiques de données sont nécessaires pour gérer une entreprise de vente au détail.
Au XXIe siècle, le commerce de détail consiste autant à gérer l’information qu’à gérer les genres, les produits, les clients, les magasins, les fournisseurs et autres actifs d’entreprise du « monde réel ». Parce qu’ils ne peuvent pas visiter et surveiller physiquement chaque point de vente au détail, la plupart des décideurs du commerce de détail se fient à l’information pour tirer des conclusions et faire leurs sélections. Pour être utile, l’information doit être reconnue, étiquetée, caractérisée et organisée dans une structure logique que les décideurs peuvent comprendre. La modélisation des données fournit un ensemble rigoureux d’outils et de techniques pour transformer l’information en information significative.
La formalité et la discipline de la modélisation des données sont donc essentielles pour déterminer quels rapports de vente au détail éclairent réellement les décideurs. Jetez un coup d’œil aux expressions objet, article, produit, SKU, Stock Keeping Unit et marchandise. Ils ont chacun des connotations différentes pour différentes personnes. En spécifiant chaque type d’entité, le modèle logique de données spécifie ce que chaque mot implique. Lorsque certains mots sont utilisés comme synonymes, ils sont clairement énoncés comme tels. C’est ce que nous appelons un vocabulaire réglementé, et c’est un aspect à valeur ajoutée important de la modélisation des données. Il crée un langage standard permettant aux entreprises de détaillants et aux individus de communiquer en utilisant une terminologie spécifiquement spécifiée.
Les détaillants doivent gérer un ensemble complexe de relations, y compris les consommateurs, les vendeurs, les autorités fiscales, les régulateurs, les travailleurs et une variété d’autres parties. Les détaillants qui n’ont pas un seul moyen standard d’identifier, de nommer, de définir et de décrire les choses, les types d’appels d’offres, les lois fiscales, les promotions, les offres des fournisseurs, etc. peuvent avoir des erreurs coûteuses de traitement des transactions. L’exactitude des données a une influence claire et indubitable sur le résultat net.
Si un article commandé n’est pas correctement aligné avec le code produit du catalogue du vendeur et que la commande est passée, quelqu’un (le consommateur, le détaillant, le vendeur, etc.) sera facturé pour cela.
En exigeant un troisième modèle relationnel de forme normale, le modèle de données réduit ce danger en insistant sur une représentation cohérente de chaque élément de données à un seul endroit du modèle logique de données.
Le problème similaire se pose lors de la création de rapports. Les détaillants qui ne disposent pas d’une méthode standard pour identifier, nommer et décrire les entités, les caractéristiques et les relations, perdent beaucoup de temps et d’argent à concilier des rapports de synthèse incohérents. Les cadres intermédiaires et supérieurs de certaines entreprises passent un temps excessif à rapprocher manuellement les données spécifiées de manière incohérente. L’une des raisons sous-jacentes de l’incohérence des données est éliminée par les modèles logiques de données qui fournissent un vocabulaire réglementé à l’échelle de l’entreprise.
D’importantes hypothèses et limites du commerce de détail sont reflétées dans les modèles logiques de données. Le lien entre la fiscalité, les produits et les services fournis par les détaillants, par exemple, est clairement exprimé dans la façon dont les choses, les taxes, les autorités fiscales, les transactions de détail, les documents de gestion des stocks, etc. sont associés dans un modèle de données. Les lignes directrices régissant la façon dont les remises au point de balance sont traitées par un détaillant, se reflètent également dans la façon dont les règles de modification des prix sont liées aux articles de retour ainsi qu’aux promotions de vente au détail. Le réseau complexe de relations qui définissent les règles métier des détaillants est explicitement présenté par le biais de modèles de relation d’entité.
Les modèles de données sont nécessaires pour que les détaillants puissent naviguer dans l’environnement complexe de reporting réglementaire d’aujourd’hui. Pour citer un exemple, la loi Sarbanes-Oxley, aux États-Unis, datant de 2002, exige des rapports rigoureux et un suivi des contrôles opérationnels et financiers dans les entreprises. Ce type de surveillance nécessite que les commerçants comprennent comment les données sont organisées, remplies, conservées et protégées. Les systèmes d’entreprise pour les finances, les ventes, le marketing, les stocks, les achats et les systèmes opérationnels associés créent des données pour répondre à la conformité.
Selon la taille et la complexité de l’entreprise, ces systèmes font partie d’un ensemble d’applications dont les données doivent être converties en informations, puis distillées en connaissances, pour les cadres supérieurs via des rapports. Les données sont donc collectées et stockées dans des structures de données telles que des tables et des fichiers, puis converties et transportées pour devenir des connaissances dans des rapports, qui doivent être signés par les dirigeants. Les métadonnées commerciales et techniques de ces données système créent une architecture d’information qui peut, à la fois stimuler la création de contrôles internes et également fournir aux dirigeants d’entreprise l’assurance que les rapports qu’ils signent sont exacts. Les principes du modèle logique de données abordés dans cet article fournissent le type d’assistance nécessaire pour faciliter la conformité aux rapports réglementaires. Des capacités supplémentaires de transport et de transformation des données sont également nécessaires. L’extraction, la conversion et le mappage de charge ARTS ODM V7.0/7.1 vers ARTS DWM V3.0 répondent partiellement aux exigences réglementaires en matière de mobilité des données.
La conformité PCI, Payment Card Industry, qui spécifie les processus que les magasins doivent adopter pour sécuriser les comptes de cartes de crédit de leurs clients, nécessite que les détaillants cartographient et comprennent les types de données qu’ils collectent. La conformité PCI, bien que axée sur l’identification des comptes liés aux paiements, ouvre la voie à de nouvelles restrictions sur l’identité des clients et les données personnelles. Tous ces régimes nécessitent que les commerçants inventorient et comprennent leurs actifs de données.
En termes simples, il peut y avoir des problèmes. Les utilisateurs pourraient être absorbés par les procédures et les activités si on ne leur rappelle pas que les données, et non la technologie, sont le facteur le plus important à prendre en compte lors de la création d’un nouveau système. Un modèle de données qui se concentre uniquement sur le flux de travail physique ne tient pas compte des besoins critiques de l’entreprise.
Les tables et les fichiers créés par les concepteurs, sans que les éléments de données ne soient décrits en fonction des besoins de l’entreprise, sont souvent désorganisés et manquent d’une structure sous-jacente solide.
La découverte et la tentative d’inclure des éléments de données supplémentaires, à partir de mises en page d’écran, ou de rapport, pendant le processus de codage, de test ou même de déploiement, encouragent les développeurs à être réactifs plutôt que proactifs. Le résultat est un organisme disjoint qui est difficile à gérer et à entretenir et qui est criblé de défauts ou d’excès de texte, sans documentation système, chronophage et peut-être totalement inutilisable.
Étant donné que le modèle logique de données établit la structure des éléments de données, en fonction des exigences métier de base, ainsi que des liens entre eux, ne pas en avoir un en place signifie beaucoup d’occasions manquées d’optimiser les processus métier. Les développeurs finissent par simplement automatiser les opérations actuelles, ou bien répliquer les systèmes existants sur une plate-forme technique, plus récente qui peut devenir obsolète, à l’avenir.
L’utilisation de la modélisation logique des données aide les analystes de données à penser indépendamment des dernières technologies et à se concentrer sur l’amélioration des processus métier.
Par conséquent, un modèle logique de données doit devenir une composante essentielle et irréversible de tout effort de développement d’applications. Il s’agit d’une étape critique qui devrait idéalement avoir lieu avant la conception de la base de données.
Net Promoter®, NPS, NPS Prism® et les émoticônes associées au NPS sont des marques déposées de Bain & Company, Inc., Satmetrix Systems,® Inc. et Fred Reichheld. Net Promoter Score℠ et Net Promoter System℠ sont des marques de service de Bain & Company, Inc., Satmetrix Systems, Inc. et Fred Reichheld.
English
French