Problèmes et état de l’art de l’intégration des données dans le cadre d’une fusion Conseil Scientifique Inno.com 25 septembre 2007 Yann Pollet

Plan Besoins et problèmes de l’intégration de données Les approches classiques de l’intégration des bases de données D’autres approches en cours de développement Conclusion

Les S.I. dans le contexte d’une fusion Processus métiers S.I. Entreprise fusionnée ? ? S.I. Entreprise 1S.I. Entreprise 2 Applications Données Applications Données communes Domaines métier Modèle des échanges internes Modèle des échanges B to B Ingénierie « itérative »

Besoin d’intégration de données Mutualisation des données (modernisation d’applications), exploitation des données du patrimoine (« legacy data ») Modèle d’échanges pour la « consolidation » des Systèmes d’Information d’origine dans le futur SI d’entreprise Bases de données pour les systèmes décisionnels Nouvelles applications. Ex : veille technologique, intelligence économique, gestion des connaissances, commerce électronique, CRM

Différents Application Intégration, migration Nouvel environnement Environnements « légués » Application requêtes résultats Intégration de bases de données Schéma d’intégration Base de données « virtuelle » Echange de donnéesEntrepôt de données Application Applications Application entrepôt Legacy applications vue ETL

Problèmes liés à l’ intégration des données Problème de méthodes : ingénierie progressive d’un S.I. Architectures à mettre en œuvre Génération et exécution des requêtes : migration de données, alimentation au fil de l’eau, consultations, … « Intégration » de schémas de données

Intégration de systèmes de bases de données : les approches Au niveau des Systèmes de Gestion de Bases de Données (passerelles,...) Au niveau haut : système de gestion intégré placé au dessus de SGBD locaux –SGBD « Réparti » –Systèmes de bases de données fédérées Au niveau intermédiaire : Multi bases de Données, Médiation Chaque application a sa « vue » sur un ensemble de bases de données, mais pas de gestion de la cohérence d’ensemble des bases Communication à travers les applications SGBD 1 SGBD 2 SGBD SGBDR SGBD 1SGBD 2 Médiateur Application

Intégration de schémas de données 1ere génération ( -> 1990) : génération d’un schéma unificateur par exploitation de correspondances entre les bases de données 2eme génération (1990->2000) : prise en compte de correspondances plus complexes, médiation de sources de données 3eme génération (2000->) : travaux sur les approches logiques, les ontologies, les transformations de modèles,

Le « triangle sémiotique » Signifiant Signifié le terme employé Le « concept » désigné, ainsi que ses propriétés Référent L’ « entité » du monde réel modèle Base de données Lien de communication Finalité, point de vue identifiant Méta-modèle

Les étapes d’un processus d’intégration Préparation des modèles Transformations des modèles pour les rendre plus homogènes, ajout de connaissance  parler le même langage Analyse des modèles Recherche et énoncés de correspondances de liens inter-modèles Elaboration du modèle intégré Transformation des données Unification des données dans un modèle unique, requêtes de transformation Exécution des requêtes Modèles en entrée Modèle intégré Méta modèle commun Quel méta modèle commun? extensions propriétés

Intégration de schémas Intégration Schéma 1 Schéma 2 Correspondances Intégration Assertions de correspondances Schéma Entité- Association Connaissances additionnelles sur S1 et S2 Méta- modèle relationnel Schéma 1 Schéma 2 Schéma Entité- Association Rétro- conception (éventuelle) Schéma intégré ? règles Schéma E.A. intégré Schéma intégré Schéma intégré : - Union des entités et de leurs propriétés - Union des extensions Schéma intégré : - Union des entités et de leurs propriétés - Union des extensions Requêtes Requêtes de passage

Identification des correspondances Q1 : Quels sont les éléments en correspondance? –S2.Auteur ≡ S1.Auteur ; S1.(auteurArticle) ≡ S2.(auteurArticle) –σ [type publication = « Conférence »] S1.Article ≡ S2.Article Q2 :Quels sont les liens entre les extensions potentielles? –S2.Article InclusDans S1.Article ; S1.Conférence ≡ S2.Conférence Q3 : Comment les instances correspondantes sont-elles identifiées? –S2.Article InclusDans S1.Article AvecIdentifiant titre Q4 : Comment leurs représentations sont-elles liées? –S1.Conférence ≡ S2.Conférence AvecIdentifiant ISN AvecAttributs année, numéro Publication ISN Nom année Revue volume numéro numéroOrdre éditeur lieu Conférence S1 Article titre Mots-clés Auteur nom affiliation 1..* nom domaine Conférence Actes ISN année 1..1 S2 Auteur nom prénom Article titre Mots-clés 1..* * « Extensions »

Validation de la cohérence L’ensemble d’assertion est-il cohérent et minimum? –Certains sous-ensembles d’assertion peuvent être incohérents (Ex : incohérences des correspondances avec les spécialisations) –Certaines assertions peuvent être déductibles d’autres Génération de requêtes Correspondances S1 – S2 1.S2.auteur InclusDans S1.auteur AIC nom 2.S2.Article InclusDans S2.Articles AIC ISN AAC mots-clés 3.S1.Conference ≡ S2.Actes AIC ISN AAC année, numéro 4.S2.Conference InclusDans S1.Publication.nom AIC nom 5.S2.AuteurArticle ≡ S1.AuteurArticle 6.S2.ActesArticles.Article ≡ Conference-Publication-Article 7.S2.ConferenceActes ≡ S1.Publication.nom-Publication-Conference BD1BD2 S1 S2 S Req BD Req

Des résultats limités… Résultats déjà très anciens Méthodes pour l’analyse (détection de conflits), et la définition de schémas globaux, mais toujours pensés comme une « union » de deux bases de données Démarche d’application de règles, rien de véritablement automatisable Conduit à des contenus avec de nombreuses valeurs non remplies (« nulles ») De nombreuses limites conceptuelles et pratiques : à une entité doit correspondre une entité!! Pas de création de produits

La seconde génération Des extensions aux précédentes approches : –Meilleure prise en compte des hiérarchies de spécialisation –Les éléments en correspondance sont des ERA (Entités, Relations, Attributs) –Correspondances entre chemins dans le graphe de données –Problématique toujours centrée sur la notion de schéma unique intégré –Toujours d’importantes limites conceptuelles et pratiques Aide à la recherche de correspondance Médiation de sources de données –Accès à différentes bases de données à travers un modèle unique –Modèles « semi-structurés », langages de requêtes –génération de requêtes médiateur-sources

Application Principe de la médiation Source 1 Source 2 Source n …… Schéma de source 2 Schéma de source 1 Schéma de source n MEDIATEUR Adaptateur 1 Adaptateur 2 Adaptateur n Moteur de requêtes Plan de requêtes RequêteRéponse Schéma de médiation : spécifique domaine Module de réécriture / reformulation de requêtes Adaptateur (Wrapper) : Interface entre les sources et le médiateur Schéma global Application [Wiederhold, 92] Deux approches de liaison schéma global schémas locaux : GAV ou LAV

Retour sur le « triangle sémiotique » Signifiants Signifiés les termes employés Le « concept » désigné, ainsi que ses propriétés Référents Les entités » du monde réel modèle Base de données Lien de communication Finalité, point de vue identifiant Méta-modèle Fusionner? interroger? échanger? … Que veut-on pouvoir représenter ? A travers quelle vision?

Couverture S1 S2 S3 Monde réel S1 S2 S3 Granularité Monde réel S3S2 Perspective « Hétérogénéité conceptuelle » S = Schéma conceptuel Dimensions de l’hétérogénéité conceptuelle… Monde réel

Questions ouvertes Problème plus général que la fusion de deux bases de données : fusionner, échanger, consulter, … Déterminer le modèle adapté à la finalité requise Correspondances plus complexes. Ex : granularité de la modélisation Définir comment s’intègrent les extensions dans le nouveau modèle Prise en compte du but : qu’est ce qu’on veut faire?

Exemple de besoins : Etablissement hospitalier Cabinet de spécialité Administratif Patient admin médical admin Gestion de soins dossiers infirmiers Gestion des ressources planification UrgencesBase réseau ville hôpital Laboratoires d’analyse Résultats analyse Extraits des dossiers Éléments dmp facturations dossiers d’urgence

De nouvelles approches… Utilisation de logiques de description –Coder un schéma de données comme un ensemble de prédicats, raisonnements sur les modèles Réflexions sur les ontologies –Langages de descriptions d’ontologies. Ex : OWL (Ontology Web Language) du W3C Analyse Formelle de Concepts –Aide à l’ amélioration /réorganisation de modèles Transformations de modèles

Exemple : une approche de transformations de modèles basée sur la logique Travaux et thèse en cours au Cnam (depuis 2004) Expression logique d’un modèle –Ensemble d’assertions qui expriment la structure d’un modèle sous forme logique –Comparable à une description d’ontologie en OWL Définition de modèle : …. Définition de modèle : …. ….. ….. Ressource SalariéSous-traitant matricule nom catégorie SociétéService origine

Seconde forme logique Seconde forme : codage sous forme d’implications logiques → … Idée de base : tout élément (classe, attribut, contrainte sur les valeurs) est interprété comme une propriété présente ou non sur une instance nom catégorie matricule origine x1 x2 x3 x4 Quelques résultats : Le codage logique permet de définir un ensemble de modèles possibles Cet ensemble est un treillis (s-model) Le modèle d’origine est le supremum de ce treillis Salarié Ss-trait

Operations sur les modèles Définition sous forme d’implications logiques –de connaissances additionnelles –d’assertions de correspondance entre modèles  cohérence à valider Relation d’ordre partielle sur les s-models :S1 ≤ S2  Tout élément de S1 peut être interprété comme une instance de S2 L’ensemble des s-modèles est un treillis –Le « maximum » de S1 et S2 est le schéma fusionnant S1 et S2 –Le « minimum » de S1 et S2 représente les instances qui peuvent être représentées sans ambigüité à la fois dans S1 et dans S2 S1S2 Max(S1, S2) Min(S1, S2) correspondances connaissances S1S2 Modèle fusionné Modèle de communication S3 Max(S2, S3)

Passage à des modèles concrets Correspondances S1 – S2 S1 S2 S2 vu par S1 S1 vu par S2 Schemas de communication S2->1 S1->2 S1->2 : sous schema de S1 S2->1 : sous schema de S2 Approche en cours de développement Nombreux problèmes encore à l’étude –Relations quelconques entre classes –Cohérence « transitive » S1 – S2 – S3 –Algorithmes

Conclusion But : définition de schéma d’intégration et/ou d’échanges de données Problème multi facettes qui présente de nombreux aspects Pratiques encore « artisanales » Actuellement, pas d’approche ni de produit qui puisse réellement automatiser une partie des tâches Utilité des approches pour suggérer voire supporter certains aspects méthodologiques (traces, justifications, …)