Evry - M2 MIAGE Entrepôt de données

Transcription

1 Evry - M2 MIAGE Entrepôt de données Intégration de données multi-sources D. Ploix - M2 Miage - EDD - IDMS 1

2 Intégration de données L intégration de données désigne l ensemble des opérations aboutissant à l alimentation de l entrepôt de données à partir des données du SI de l entreprise. Les étapes sont : Identification des données sources, Préparation des données, Intégration dans les faits et dimensions. D. Ploix - M2 Miage - EDD - IDMS 2

3 Intégration de données multi-sources Données sources Fonctions d intégration Intégration par étapes Intégration de la fonction MDM D. Ploix - M2 Miage - EDD - IDMS 3

4 Données sources Acquisition de données multisource : du transactionnel vers le décisionnel D. Ploix - M2 Miage - EDD - IDMS 4

5 Données sources Activités Informations en sortie Données Processus Informations en entrée Métiers Les données instanciation de l activité au sein des processus (métier) D. Ploix - M2 Miage - EDD - IDMS 5 5

6 Données de référence? Parmi toutes les données en circulation dans le système d information, certaines sont plus critiques pour l activité métier car structurantes et largement partagées (disséminées) entre plusieurs applications. Ce sont les données de référence. Elles sont particulièrement structurantes pour les EDD : constitutives des dimensions instanciation des faits Elles sont partagées entre plusieurs applications transactionnelles, chacune en responsabilité d une partie selon sa position dans le processus métier attenant. D. Ploix - M2 Miage - EDD - IDMS 6

7 Référentiel client Contractuel (CRM) Commande Facturation Quelques exemples Référentiel de localisation géographique Adresses Référentiel des fournisseurs Centralisation des achats pour un groupe, Référentiel des données de marcher D. Ploix - M2 Miage - EDD - IDMS 7

8 Caractéristiques des DR : typologie Elles peuvent être classifiées en types : «DR Maître» : objets métiers principaux («cœur de métier») d un domaine fonctionnel et structurante pour l ensemble des applications du domaine. «DR Constitutives» : entrent dans la composition de plusieurs données maître (par ex. adresses). «DR Paramètre» : tables de valeurs ou nomenclature (code postaux, code devises, taux des taxes, ) partagées. Cet analyse des données et de leur constitution est particulièrement important dans l intégration de données dans un EDD : Les objets métiers (et par extension les données de référence) sont les sources autant des dimensions (ex. client) que des faits (ex. vente). La distinction fait / dimension est une vue décisionnelle sur les objets métiers en circulation. D. Ploix - M2 Miage - EDD - IDMS 8

9 DR : positionnement D. Ploix - M2 Miage - EDD - IDMS 9

10 Exemple des l EDD Transport Dans l analyse relative à l EDD de Transport, un certain nombre de dimensions adresses des données «de référence» : Les aéroports, Les passagers, Les vols Elles sont positionnées en tant que telles du fait de leur transversalité au métier du transport aérien : de la réservation, à l organisation des vols, à la facturation, chacun des systèmes manipulera les caractéristiques de ces informations qui le concerne. On les traitera en tant qu objet métier de référence. D. Ploix - M2 Miage - EDD - IDMS 10

11 Données sources Le multi-source (non urbanisé) est à la source des problèmes : Conflit sémantiques Conflit de modèle Conflit de l âge Conflit de mode opératoire sur le cycle de vie Conflit de modalité de diffusion Conflit de niveau de sécurité D. Ploix - M2 Miage - EDD - IDMS 11

12 Données sources L enjeu est donc d obtenir l assurance sur : Cohérence globale Unicité Visibilité / disponibilité Productivité / agilité Contraintes réglementaires Qualité Sécurité D. Ploix - M2 Miage - EDD - IDMS 12

13 Données sources Rappels sur la qualité des données Critères intrinsèques : Unicité Quelles données sont en doublons? Complétude Quel attribut manque ou est inutilisable? Exactitude Quelle donnée est incorrecte? Conformité Quelle donnée est dans un format non prévu? Cohérence Quelles données fournissent des informations conflicutelles? Intégrité Quelle relation manque? D. Ploix - M2 Miage - EDD - IDMS 13

14 Données sources Rappels sur la qualité des données Critères de service Actualité Impact la modalité de transmission et d acquisition dans les contextes transactionnel / décisionnel. Accessibilité Pertinence Compréhensibilité Critères de sécurité Disponibilité Intégrité Confidentialité Traçabilité D. Ploix - M2 Miage - EDD - IDMS 14

15 Données sources Rappels sur le cycle de vie des données Création Mise à jour Technique Fusion (rapprochement de données) Historisation Consommation Archivage Suppression logique Suppression physique Métier Étude / prospect Saisie / pré-validation Validation Commercialisation Arrêt de com. En Extinction D. Ploix - M2 Miage - EDD - IDMS 15

16 Données sources Comment réussir l intégration des données : Mettre en place une démarche d urbanisation des données (objets métier, formats pivots, ) Gérer le processus d intégration (ou de circulation) des données comme une activité à part entière Utiliser les fonctions issues de la gestion de données de référence (Master Data Managment) qui définit : La notion de données de référence, objet principal de la démarche d urbanisation et source des données en entrée de l entrepôt. L ensemble des fonctions qui devront apparaître dans le processus d intégration des données. D. Ploix - M2 Miage - EDD - IDMS 16

17 Intégration de données multi-sources Données sources Fonctions d intégration Intégration par étapes Intégration de la fonction MDM D. Ploix - M2 Miage - EDD - IDMS 17

18 Fonctions du MDM et intégration ED Les fonctions (re)définies dans le cadre du MDM peuvent servir d ossature au processus d intégration des données sources dans l entrepôt. D. Ploix - M2 Miage - EDD - IDMS 18

19 MDM et ED Exemple construction d un ED pour l analyse de sinistres pour une compagnie d assurance. Deux applications sont sources de données : Une de gestion des contrats d assurance Une de gestion des sinistres Particularité : La compagnie à racheté une petite compagnie d assurance locale et doit traiter des sinistres pour des contrats dont elle n a pas la gestion. Le système de gestion de sinistres a été adapté afin de pouvoir intégrer des liens vers le nouveau système et intégrer les données quelle ne gère pas. D. Ploix - M2 Miage - EDD - IDMS 19

20 Modèle de données gestion contrat D. Ploix - M2 Miage - EDD - IDMS 20

21 Modèle de données gestion sinistre D. Ploix - M2 Miage - EDD - IDMS 21

22 Objet de l ED Pour les biens, on va étudier le montant de la prime et des remboursement du fait de sinistres, La localisation des clients assurés Afin de construire des tableaux de bord par type de risque de sinistre avec le total payé dans le mois et le total reçu dans le mois en fonction des biens et des régions. D. Ploix - M2 Miage - EDD - IDMS 22

23 Analyse de l objet de l ED pour la partie étude Les données nécessaires à l étude sont : montant de la prime : correspond à la prime d'assurance par rapport à un risque remboursement du fait de sinistres : correspond à des opérations de remboursement lié à un sinistre localisation des clients assurés : correspond à l'adresse des clients Les caractéristiques des faits nécessaires à l'étude seront alors : risque : désignation Prime clients (pour le risque considéré) : Nom Prénom Adresse Opération de nature "remboursement" (pour un sinistre sur le risque et le client considéré) : Date Montant Possibilité d'agrégation : somme des opérations de remboursement et de collecte de prime par désignation de risque par jour par région des clients D. Ploix - M2 Miage - EDD - IDMS 23

24 Analyse de l objet de l ED pour la partie TDB Les données nécessaires au tableau de bord sont : type de risque de sinistre : désignation des risques total payé dans le mois : somme des montant des opérations de remboursements par sinistre correspondant aux type de risque par mois mois : date des opérations biens : désignation des biens régions : localisation des clients / des biens? choix des clients en cohérence avec la partie étude. Les caractéristiques des faits nécessaires au tableau de bord sont : risque : Désignation clients (pour le risque considéré) : Nom prénom Adresse biens (pour le client et le risque considéré) : désignation opération de nature "remboursement" (pour un sinistre sur le risque et le client considéré) : Date Montant Possibilité d'agrégation : somme des opérations de remboursement Par mois par région des clients par désignation de bien par désignation de risque D. Ploix - M2 Miage - EDD - IDMS 24

25 Construction de l entrepôt de données Décision d'agrégation : somme des opérations de remboursement et de collecte de prime par jours par région des clients par désignation de bien par désignation de risque effet : la caractéristique «client» devient la caractéristique «région des clients» la caractéristique «date des opérations» deviens «jour des opérations» (plus d'heure...) Fait : flux financiers par jour par région par type de bien et par type de risque FluxFinanciers Risque Région des client Bien Date des opérations Désignation Code postal Désignation Jour Désignation région Mois Année Montant Prime collectée Montant remboursement effectué D. Ploix - M2 Miage - EDD - IDMS 25

26 Chaîne de traitement d intégration des données Intégration des données Utilisation de l entrepôt D. Ploix - M2 Miage - EDD - IDMS 26

27 Rôle de l ODS «staging area» Le rôle du staging area qui sert à stocker les données extraites des systèmes sources. On y effectue aussi les différentes transformations à savoir : Le nettoyage des données, le merge, la standardisation, le déduplication... des données. Par contre les données dans l'ods ne sont détruites qu'après la durée de vie des données dans l'ods, facteur définit par l'organisation et dépend de plusieurs critères. La durée de vie d une données dans l ODS en tant que MDM est fonction de son usage par les systèmes opérationnels (transactionnels). Les données historiques sont conservées dans l ED. En résumé : Sources ODS DSA DW Selon la multiplicité des sources et les transformations il peut y a voir une fusion des étapes ODS et DSA (mais pas leur disparition). D. Ploix - M2 Miage - EDD - IDMS 27

28 Schémas ODS et sources Structures de données de l ODS (staging aréa) : en fonction de l espace disponible car la multiplication de la copie des données peut-être très coûteuse. 1) ODS/DSA Phase 1 le modèle est proche des sources (transactionnelles) : permet de récupérer une image des données source selon un pas de temps fixé et de travailler à l intégration dans le DW sans impacter le fonctionnement du système opérationnel. 2) ODS/DSA Phase 2 fusionne les modèles sources dans un modèle unique pour y effectuer les étapes d intégration décrites par la suite. Il est possible de se passer de l étape 1 mais la seconde reste nécessaire car les données injectées dans le DW doivent avoir été nettoyées D. Ploix - M2 Miage - EDD - IDMS 28

29 Proposition : positionnement du MDM en point de vérité pour les données de référence D. Ploix - M2 Miage - EDD - IDMS 29

30 Fonctions d intégration modèles et méta-données D. Ploix - M2 Miage - EDD - IDMS 30

31 Fonctions d intégration modèles et méta-données Identification des données de référence nécessaires : taux, clients et des autres données sinistres, Pour les données de référence : si possible, mettre en œuvre une démarche de normalisation. Mais, impact sur les applications sources Pour les autres données : attention aux données intégrant dans leur composition des données de référence. Cette fonction d intégration sera utilisée pour la construction des modèles de données ODS et DSA D. Ploix - M2 Miage - EDD - IDMS 31

32 Construction du schéma de l ODS Identification des données «de référence» dont la modélisation provient du processus d urbanisation des données Identification des données «des sources» qui représentent le même objet fonctionnel hors données de référence Construction des modèles ODS (Operationnal Data Store) proches des sources limités aux données nécessaires à l entrepôt Construction du modèle DSA qui «fusionne» les différents modèles de données sources dans un modèle de données relationnel unique. D. Ploix - M2 Miage - EDD - IDMS 32

33 Analyse et identification des DR Les objets métiers (risque, bien, client) sont des données de référence maître par rapport à notre besoin. Les DR constitutives sont les adresses Les DR paramètres sont les taux, mais également les types d opération, (Ces données ne sont pas «utiles» directement dans l EDD) D. Ploix - M2 Miage - EDD - IDMS 33

34 MDM source D. Ploix - M2 Miage - EDD - IDMS 34

35 ODS intégration des données gestion de contrat D. Ploix - M2 Miage - EDD - IDMS 35

36 ODS intégration des données gestion sinistre D. Ploix - M2 Miage - EDD - IDMS 36

37 DSA : fusion des modèles ODS_C et ODS_S Tables fusionnées : -Client -Adresse -Risque -Bien -Opération Toutes les relations ne sont pas valuées D. Ploix - M2 Miage - EDD - IDMS 37

38 Fonctions d intégration acquisition La fonction acquisition MDM clarifie la source d une donnée de référence et l outille. Dans le cas présent, il s agit d identifier l application source principale pour chacune des données de référence. L autre «source» de donnée devra se conformer au valeurs présentes dans la première. Permet de spécifier le processus de passage des ODS vers le DSA D. Ploix - M2 Miage - EDD - IDMS 38

39 Fonctions d intégration acquisition Donnée de référence Application (ODS) source Nouveaux Clients MDM > Contrat Clients «externes» MDM > Sinistre Adresses MDM > Contrat > Sinistre OM : Risques, Biens, Contrat > Sinistre Opérations Contrat + Sinistre D. Ploix - M2 Miage - EDD - IDMS 39

40 Fonctions d intégration validation La fonction validation décrit les règles permettant de valider une donnée. Ce sont les Règles syntaxiques, Règles de gestion, Règles de cohérence (par exemple, pour un objet métier intégrant une donnée de référence paramètre). Règle d identification unique d une donnée Règles de transcodification Via des tables de correspondance entre les valeurs des deux applications Via des mises en correspondance entre les ID des données entre deux applications D. Ploix - M2 Miage - EDD - IDMS 40

41 Règles de gestion syntaxique / métier Exemple de normalisation syntaxique : Normalisation des dates Normalisation des valeurs «nulles» Le processus de normalisation des données d une part et validation métier d autre part est critique pour les entrepôts de données car des données non correctes peuvent biaiser le résultat des analyses. Il est préférable de ne pas intégrer des données plutôt que des données fausses. Le MDM prend là toute sa valeur par le travail en amont de normalisation, de validation et de centralisation des règles de gestion. Attention, en terme d architecture, les outils d intermédiation ne sont pas conçus pour des règles de gestions métier complexes mais pour des règles syntaxiques les validations métiers doivent être réalisées en amont (par les applications propriétaires) ou en aval. D. Ploix - M2 Miage - EDD - IDMS 41

42 Règles de gestion / syntaxique Dans notre cas, l analyse devra préciser les formats techniques des données (particulièrement les dates) et s assurer que les règles de gestion sont bien les mêmes dans les deux applications. D. Ploix - M2 Miage - EDD - IDMS 42

43 Exemple de règle de gestion syntaxique Dans l exemple des données de gestion d assurance, les éléments à vérifier sont les dates mais également les taux si les systèmes reposent sur des technologies différentes. Par exemple, Oracle définit les règles syntaxiques de format (date, nombre, ) au niveau de la base, au niveau de la connexion du client vers la base et au niveau des requêtes. D. Ploix - M2 Miage - EDD - IDMS 43

44 Cohérence des données Les schémas incluent des références croisées : sur les adresses, sur les clients et les polices. Pour autant, les règles et mécanismes de synchronisations ne sont pas décrits / connus. Le processus d intégration directe / via un MDM, doit intégrer la notion d application «maître» de la données (faisant référence). Mais, dans notre cas en cas de conflit, seule l analyse des tables des opérations permettra de savoir quelle donnée utiliser. D. Ploix - M2 Miage - EDD - IDMS 44

45 Key mapping : transcodification d ID Données historisées Instance / occurrence de données ID d instance Données actuelles Identifiant UID ID Application A PKI1123 PKI1123 ID Application B Civilité M. M. Nom Jean Jean Prénom Dupuis Dupuis Type voie Rue Avenue Adresse Rue des chaumes Avenue du moulin Code Postal Localité Aix en Provence Marseille La transcodification de l ID peut alors être réalisé par l intermédiation ou par l outils de MDM. D. Ploix - M2 Miage - EDD - IDMS 45

46 Tables de transcodification de valeurs Application A Application B Attribut A Attribut 1 Attribut 2 FRA France Euro CAD Canada Dollar Lors de la transmission des données de A vers B, la valeurs des Attributs 1 et 2 de l application B seront fixés selon la valeur de l attribut A de l application A (et inversement). D. Ploix - M2 Miage - EDD - IDMS 46

47 Fonctions d intégration validation Dans notre cas, la table «Client» de l application Sinistre fait office de source de transcodification pour les ID des clients de l application de gestion de contrats. Son utilisation permet de garantir que deux clients dans le dataware n auront pas le même ID. Par contre, si un client était déjà client de l entreprise «externe», il apparaîtra deux fois. Le risque est alors de faire apparaître des incohérence sur la couverture contractuelle des biens. Il doit être identifié et tracé pour permettre l analyse des incohérences / rejets potentiels. D. Ploix - M2 Miage - EDD - IDMS 47

48 Fonctions d intégration Pilotage La fonction pilotage est assurée par des outils (tableaux de bords, ) basés sur la mise en place d indicateurs, d audits (historisation/journalisation) et d analyse d impacts. Dans le cas d intégration de données dans un ED, cette fonction de pilotage se traduira principalement par la mise en place d indicateurs sur la mesure du taux de rejet des donnée différenciée par les causes : obsolescence (une adresse pas vérifiée depuis plus d un an à 10% de chance d être fausse), transcodification, format technique, cohérence, règle de gestion Du fait du volume, une analyse sur les causes possible doit être réalisée préalablement. D. Ploix - M2 Miage - EDD - IDMS 48

49 Fonctions d intégration Pilotage Dans notre cas, les indicateurs se focaliseront sur la mesure de : La cohérence : «taux» partagé entre les applications, L obsolescence : identification des objets métiers «anciens», n ayant pas fait l objet d opération depuis 1 an (cf pb adresse), Ce pilotage en amont (des analyses) a comme fonction de préparer un ED «propre». S il fait partie de la phase d acquisition des données et doit également traiter les données de l ED lui-même (fait comme dimensions). D. Ploix - M2 Miage - EDD - IDMS 49

50 Fonctions d intégration stockage et journalisation Mise en œuvre de la base MDM sur les données identifiées : Via un modèle normalisé intégrant, au besoin, les ID multiples (correspondant à leur instanciation dans les applications sources/consommatrices), Il peut également intégrer des dimension de contextualisation (cf transcodification). Intégrant une journalisation de l historique des données afin de pouvoir porter les fonctions d audit et de pilotage. Un modèle dépendant du contexte de partage (dans sa richesse fonctionnelle) mais, par exemple, qui simplifie le processus de mise à jours des ED via l historisation. D. Ploix - M2 Miage - EDD - IDMS 50

51 Fonctions d intégration stockage et journalisation Dans notre exemple, des données sont placées dans une base MDM : les biens, les risques, les clients, les adresses. Le reste est construit directement à partir des bases sources. La phase MDM met en place d UID et la date de màj. D. Ploix - M2 Miage - EDD - IDMS 51

52 Fonctions d intégration accès et diffusion Le MDM ne se positionne pas uniquement en tant que base de stockage d un certain nombre de données mais également en source et doit, de ce fait, être interfacé via une IHM de gestion et des composants d intermédiation vers/depuis les applications destinatrices/sources. Dans notre cas, l application finale intègrera deux composants : une intégration des sources vers l ED et une base MDM destination et source des données de références. D. Ploix - M2 Miage - EDD - IDMS 52

53 Fonctions d intégration administration et maintenance Le positionnement du MDM comme «point de vérité» lui impose les contraintes des applications les plus strictes En terme de gestion des droits d accès En terme de niveau disponibilité Ce problème se retrouve également en point central des difficultés rencontrées par le SOA : Problème de coût induit Problème de délégation de responsabilité Problème de niveau de disponibilité quasi impossible à atteindre D. Ploix - M2 Miage - EDD - IDMS 53

54 Intégration de données multi-sources Données sources Fonctions d intégration Intégration par étapes Intégration de la fonction MDM D. Ploix - M2 Miage - EDD - IDMS 54

55 Intégration par étapes Contexte Contexte : intégration de données de ventes en provenance de plusieurs chaînes de magasin. Les chaînes utilisent le même logiciel de gestion. Un entrepôt de données des ventes doit être construit pour la réalisation de différents types d analyses. D. Ploix - M2 Miage - EDD - IDMS 55

56 Intégration par étapes Schéma source Le logiciel source a comme schéma : D. Ploix - M2 Miage - EDD - IDMS 56

57 Intégration par étapes Schéma cible La modélisation décisionnelle aboutie au schéma suivant : D. Ploix - M2 Miage - EDD - IDMS 57

58 Intégration par étapes identification des données de référence Les données de référence maître sont : Les clients Les produits Les magasins Les fournisseurs Les données de référence constitutives sont : Les adresses Les données de référence paramètre sont : Les dates D. Ploix - M2 Miage - EDD - IDMS 58

59 Intégration par étapes Schéma des données de référence Les données de références seront (dans notre exemple) stockées dans l ODS d intégration des données sources. Leur schéma sera : Tables de liaison entre les identifiants des applications sources et le référentiel D. Ploix - M2 Miage - EDD - IDMS 59

60 Intégration par étapes Contraintes d intégration Les étapes de l intégration des données seront : 1. Mise à jour des données de références 2. Mise à jour des dimensions de l entrepôt 3. Mise à jour des faits de vente avec complétion de la dimension date D. Ploix - M2 Miage - EDD - IDMS 60

61 Intégration par étapes Fonction acquisition Ordre Table Cible Table Source A.1 ReferenceClient Client, téléphone, carte_fidelite A.2 ClientMagasin ReferenceClient, Client A.1 ReferenceAdresse Fournisseur, Magasin, téléphone A.2 ReferenceMagasin Magasin, ReferenceAdresse A.2 ReferenceFournisseur Fournisseur, ReferenceAdresse A.3 ReferenceProduit Produit, ReferenceFournisseur A.4 ProduitMagasin Stock, Produit, Magasin, ReferenceProduit, ReferenceMagasin B.1 DimClient ReferenceClient B.1 DimMagasin ReferenceMagasin + ReferenceAdresse B.1 DimProduit ReferenceProduit + ReferenceAdresse B.2 DimDate Vente + fonctions base de données B.2 FaitVente Vente + ClientMagasin + ProduitMagasin D. Ploix - M2 Miage - EDD - IDMS 61

62 Intégration par étapes Fonction Validation et Qualité Table Règle Description ReferenceProduit PK fonctionnelle EAN+Fournisseur+Designation ReferenceProduit PK Référence PK source Table ProduitMagasin ReferenceClient PK fonctionnelle Nom, prenom, adresse ReferenceClient PK Référence PK source Table ClientMagasin D. Ploix - M2 Miage - EDD - IDMS 62

63 Intégration par étapes Fonction modèles de données méta données Table DimDate Attribut cible Attribut source Fonction d intégration DimDate.date Vente.date DimDate.num_jour_mois Vente.date datepart(month, date) D. Ploix - M2 Miage - EDD - IDMS 63

64 Intégration par étapes Fonction pilotage En cas de rejets sur l intégration des produits du fait de la désignation, un filtrage par EAN + Fournisseur sera réalisé afin de détecter les modifications de désignations. En cas de rejets sur l intégration des fournisseurs du fait de l adresse, un filtrage par historique du fournisseur sera réalisé afin de détecter les modifications d adresse, D. Ploix - M2 Miage - EDD - IDMS 64

65 Intégration par étapes Fonction stockage et historisation Les tables de références sont intégrées à la base de données ODS et ne sont pas purgées entre deux intégrations. La question d une table d audit référençant l historique des intégrations se pose. Les modifications de désignations des produits et d adresse des fournisseurs est gérée par écrasement de l ancienne valeur (attention aux incohérences entre les magasins ). D. Ploix - M2 Miage - EDD - IDMS 65

66 Intégration par étapes Accès, diffusion et administration Question à résoudre : Quelle interface pour gérer les rejets des produits et des fournisseurs? Question à préciser : Ordonnancement de l intégration des données selon les sources et de mise à jour des données de l entrepôt une fois les données de références intégrées. D. Ploix - M2 Miage - EDD - IDMS 66

67 Gestion de Données de Référence Données sources Fonctions d intégration Intégration par étapes Intégration de la fonction MDM D. Ploix - M2 Miage - EDD - IDMS 67

68 Des DR à la Gestion des DR (MDM) D. Ploix - M2 Miage - EDD - IDMS 68

69 Fonctions du MDM dans l intégration des données D. Ploix - M2 Miage - EDD - IDMS 69

70 Situation des données de référence dans le SI Processus amont : Point d acquisition d une donnée Source(s), états transitoires de validation, contrôles de gestion, Point de vérité (MDM) Processus aval : Consommation de la donnée Journalisation, diffusion (ETL, EAI, ) Données Valides. D. Ploix - M2 Miage - EDD - IDMS 70

71 Situation des GDR dans le SI Situation dans la chaîne de l information Référentiel en début de chaîne : Unique point de saisie de la donnée Passerelle entre un fournisseur de donnée externe Point de vérité = point d acquisition Meilleurs situation possible Référentiel en milieu de chaîne : Récupère et réconcilie la donnée issue de points d acquisition multiples Assure la redistribution des données et son contrôle qualitatif Référentiel en fin de chaine Assure les traitements qualitatifs de redressement et de rapprochement. Souvent très complexes et coûteux à mettre en œuvre. D. Ploix - M2 Miage - EDD - IDMS 71

72 Typologies d architectures MDM Consolidation Consolidation : plusieurs sources alimentent le référentiel et les points d acquisition sont distincts du point de vérité. D. Ploix - M2 Miage - EDD - IDMS 72

73 Typologies d architectures MDM Répertoire Virtuel Répertoire Virtuel : comparable à de la consolidation avec une intermédiation de type EAI/ESB ou EII (BD virtuelle). D. Ploix - M2 Miage - EDD - IDMS 73

74 Typologies d architectures MDM Coopération Coopération : consolidation avec un couplage fort entre les applications source et la solution de référentiel (font parties ou dépendent de) D. Ploix - M2 Miage - EDD - IDMS 74

75 Typologies d architectures MDM Centralisation Centralisation : fusion du point d acquisition et du point de vérité. D. Ploix - M2 Miage - EDD - IDMS 75

76 Typologie d architecture La réalité est souvent une composition des patterns selon les données (voir les parties de données). D. Ploix - M2 Miage - EDD - IDMS 76

77 Critères de choix d une architecture D. Ploix - M2 Miage - EDD - IDMS 77

78 Outillage du MDM : quelle solution? Le MDM est souvent répartis entre plusieurs outils couvrant tout ou partie des fonctions qu il requière : DQM (Data Quality Managment) EII (Entreprise Information Integration) Annuaires CRM (Customer Relationship Managment) PLM (Product Lifecycle Managment) D. Ploix - M2 Miage - EDD - IDMS 78

79 Relation DQM / MDM Fonctions principales portées par le DQM : Nettoyage des données (normalisation, consolidation, enrichissement, surveillance, analyse, profilage) en fonction de règles spécifiques de gestion de la qualité. Périmètre de données plus large que les données de références Brique essentielle du MDM Mais il manque : La persistance (stockage) : fonction de point de vérité À l inverse, un MDM peu exister sans DQM mais il ne garanti plus la qualité des données. D. Ploix - M2 Miage - EDD - IDMS 79

80 Relation EII / MDM L EII et le MDM ont des fonctions séparées et complémentaires, le MDM référence les données alors que l EII les restitues sans harmonisation ni réconciliation ni correspondance à une vérité unique. D. Ploix - M2 Miage - EDD - IDMS 80

81 Annuaire et MDM Les annuaires (LDAP principalement) permettent de stocker des données hiérarchisées «spécialisées» dans la gestion de l identification Même s ils imposent une structure de données, ils ne peuvent que servir de conteneur technique de données au sein d un MDM spécialisé sur ces sujets. Pas constituer un MDM (couverture fonctionnelle trop faible). D. Ploix - M2 Miage - EDD - IDMS 81

82 Progiciel métier comme MDM L utilisation de progiciel métier (CRM, ERP, ) s adapte mal à porter la fonction de MDM car ils : Imposent le schéma de données Contraignent fortement les règles de gestion sur la qualité Ne couvrent pas une partie importante des fonctionnalités attendues (key maping, pilotage, ). Imposent un rythme de mise à jour Mais : adaptés si la couverture fonctionnelle est suffisante, peu ou pas de besoin de pilotage ou de gouvernance des données, intègre les processus métier prioritaires. D. Ploix - M2 Miage - EDD - IDMS 82

83 Solutions pour le MDM D. Ploix - M2 Miage - EDD - IDMS 83

84 Modes d intermediation D. Ploix - M2 Miage - EDD - IDMS 84

85 MDM et phases d un projet D. Ploix - M2 Miage - EDD - IDMS 85

86 Migration de données D. Ploix - M2 Miage - EDD - IDMS 86