Exemple de métadonnées virtuelles

Vous pouvez utiliser cette fonction lorsque vous souhaitez accéder à une grande quantité d'informations client en une seule fois, telles que les données de profil, l'historique des achats et ainsi de suite. Stocker et répliquer toutes ces informations « physiquement » dans un modèle de Data Hub présente des obstacles potentiels :

Le volume de certaines données est trop volumineux ou trop largement distribué pour être contenu dans un hub central.
Les données changent fréquemment et doivent être répliquées dans le hub trop souvent pour être exploitables.
Il existe des problèmes de confidentialité ou commerciaux sur les informations sensibles comme les numéros de sécurité sociale, les informations sur les salaires, les données de tarification, et ainsi de suite.

En stockant des informations en externe puis en y accédant virtuellement, vous êtes toujours en mesure d'obtenir une vision complète de votre client en réduisant les problèmes de duplication des données dans Data Hub.

Le modèle Data Hub

Vous disposez d'un modèle existant contenant deux types d'entités, Client et CustomerMaster, avec une relation de HasMasterRecord.

Les entités Client contient les informations suivantes :

ID de client (unique pour chaque client)
Nom
Date de naissance
Statut Gold Club (indique si le client est un membre du Gold Club)

Les entités CustomerMaster contiennent les informations suivantes :

ID maître (unique pour chaque client)
ID de client
Nom
Date de naissance

L'image ci-dessous présente un modèle créé à l'aide de ces métadonnées. Notez que George et Martha Washington possèdent des entités Client distinctes, mais qu'elles partagent la même entité CustomerMaster, car l'ID maître représente un foyer, pas d'un individu.

Les tables externes

Nous voulons lier des clients à leur historique d'achats, que nous allons créer à l'aide de trois tables externes : une pour les clients, l'autre pour les achats et la dernière pour les produits.

Nous utilisons les mêmes informations pour la table Clients que celles utilisées pour renseigner les entités client :

La table Achats contient des numéros de commande, des ID de produits et des dates d'achat, elle indique également si l'objet a été acheté en ligne. Elle lie ces données à l'ID client, qui est également utilisé dans la table client.

La table Produits table contient des noms de produits, des numéros de modèles et des descriptions. Elle lie ces données à l'ID produit, qui est également utilisé dans la table Achats.

La table Achats sera utilisée comme une table de jointure qui établit des connexions entre les enregistrements dans les tables Clients et Produits. L'image ci-dessous illustre les relations entre les différents champs dans les trois tables externes.

Assimiler toutes ces informations produirait l'enregistrement suivant pour Martha Washington :

Liaison de données physiques et virtuelles

Pour créer des relations entre les entités dans le modèle Data Hub et les enregistrements dans les tables externes, les entités Data Hub doivent avoir des propriétés qui référencent les données externes. Pour créer un lien du modèle Data Hub aux enregistrements dans la table Clients une propriété contenant les mêmes valeurs que celles stockées dans le champ CustomerID de ces entités est nécessaire dans la table externe. Vous pouvez afficher dans l'image suivante que l'entité Martha Washington comporte une propriété appelée CustRef, qui contient la même valeur que le champ CustomerID dans la table Clients.

Pour établir le lien entre l'entité Client et la table externe, nous devons d'abord créer une entité virtuelle pour la table Clients. Pour ce faire, reportez-vous aux instructions qui débutent à l'étape 5 de la rubrique précédente, « Utilisation de métadonnées virtuelles dans des modèles ». L'image suivante présente l'écran complété du nouveau type d'entité. Notez que « CustomerID » est sélectionné comme la clé principale, et représente la propriété utilisée pour créer un lien entre les entités physiques et virtuelles.

Après avoir ajouté l'entité virtuelle, nous devons ajouter une relation de liaison de cette entité à l'entité physique figurant déjà dans le modèle. Les instructions permettant d'effectuer ceci débutent à l'étape 14 dans la rubrique précédente. L'image suivante présente l'écran complété pour le nouveau type de relation. Notez que l'ID de l'entité source fait référence à la propriété CustRef et que l'ID de l'entité cible fait référence à la propriété CustomerID ; il s'agit du lien qui lie l'entité virtuelle à l'entité physique, car les deux propriétés incluent l'ID client.

En outre, dans cet exemple, la relation entre les clients est une relation un-à-un , ce qui signifie que pour chaque entité physique, il doit exister une seule entité virtuelle au maximum et que pour chaque entité virtuelle il doit exister une seule entité physique au maximum. Pour les relations un-à-un, ainsi que pour les relations un-à-plusieurs, il n'est pas nécessaire d'avoir une véritable table de jointure, c'est pourquoi nous sélectionnons la table Clients, qui est la table qui a été utilisée pour définir l'entité virtuelle.

Les métadonnées du modèle incluent désormais un lien vers les données virtuelles. Notez l'étoile bleue en regard de l'entité ERP_Customer ; ceci indique que l'entité est virtuelle.

Relations plusieurs-à-plusieurs

Maintenant que nous avons lié le client virtuel au client physique, nous devons également lier les achats et les produits. L'approche optimale consiste à créer une entité virtuelle pour les produits et créer une relation virtuelle plusieurs-à-plusieurs entre les clients physiques et les produits virtuels à l'aide de la table Achats en tant que table de jointure. Nous devons d'abord créer une entité virtuelle pour la table Produits utilisant ProductID comme clé principale.

Il s'agit ensuite d'ajouter une nouvelle relation qui utilise la table Achats comme une table de jointure pour créer une relation plusieurs-à-plusieurs ; les entités Client sont liées avec les entités Produit en fonction des informations de la table Achats. Notez que la propriété CustomerID est utilisée comme l'ID du lien pour les entités Client et que la propriété ProductID est utilisée comme l'ID du lien pour les entités Produit ; la table Achats contient ces deux propriétés, c'est ainsi qu'il est possible de mapper les informations de Client à produit.

L'ID de l'entité source (CustRef) est la propriété de l'entité Client qui sera mise en correspondance avec la colonne ID du lien source (CustomerID) dans la table Achats. L'ID du lien cible (ProductID) est la colonne de la table Achats correspondant à la propriété ID de l'entité cible (également ProductID) de l'entité Produits. Le schéma suivant illustre la manière dont chaque champ est utilisé pour lier le client au produit.

Lorsqu'une requête passe du client au produit, elle commence par la propriété qui a été sélectionnée comme l'ID de l'entité source, qui est la propriété CustRef dans notre exemple. Pour Martha Washington la valeur de cette propriété est C23 ; cette valeur sera utilisée pour rechercher les lignes dans la table Achats où l'ID de lien source (dans notre cas, CustomerID) a une valeur C23.

La valeur de l'ID du lien cible (dans notre cas, ProductID) sera utilisée pour rechercher la ligne correspondante dans la table Produits. Désormais, pour chaque ligne renvoyée à partir de la table Achats, la valeur du champ ProductID sera mise en correspondance avec la propriété ID de l'entité cible (dans notre cas, ProductID) de la table Produits. Le schéma suivant illustre la manière dont chaque champ est utilisé à travers le flux.

Configuration avancée

Une alternative à l'approche illustrée ici est d'utiliser la table Achats pour créer la relation plusieurs-à-plusieurs entre le client virtuel et les entités produit virtuelles. Cela implique un relais virtuel supplémentaire et inutile du client physique au client virtuel. Data Hub est beaucoup plus efficace à parcourir les relations que les sources de données SQL, car il repose sur une base de données du graphique ; par conséquent, le relais supplémentaire sera évité si possible.

Une autre alternative consiste à créer des entités virtuelles pour la table Achats en plus de celles de la table Produits. Cette approche requiert des relations un-à-plusieurs entre les entités client physiques et les entités achats virtuelles ainsi que des relations un-à-plusieurs entre les achats virtuels et les produits virtuels. Ceci est inefficace car des relais virtuels inutiles sont créés pour aller du client physique au produit virtuel. Il n'y a aucun avantage à représenter un achat en tant qu'entité parce que la relation peut contenir tous les champs Achats en tant que propriétés. La seule raison pour créer une entité pour Achats est si elle connecte plus de deux types d'entité, comme s'il existait une clé étrangère tierce dans la table de liaison des achats dans un magasin.