FR2888018A1 - Procede et systeme de realisation d'une base de donnees virtuelle a partir de sources de donnees presentant des schemas heterogenes - Google Patents

Abstract

La présente invention concerne un procédé et un système pour réaliser une base de données virtuelle, à partir de données contenues dans une pluralité de sources hétérogènes, en particulier du point de vue des schémas représentant leur organisation et leur structure.Pour une telle base de données virtuelle comprenant au moins une table relationnelle, dite table cible, à partir de sources vues comme un ensemble de tables sources relationnelles, le procédé comprend :- pour au moins une desdites sources, un processus, dit de publication, comprenant la création d'au moins une correspondance dite de publication entre au moins une table source de cette source et ladite table cible ;- un processus, dit d'intégration, comprenant la création d'une correspondance dite d'intégration entre ladite table cible et un ensemble desdites correspondances de publication, ainsi que des étapes de détection et de traitement des conflits entre les sources publiées.

Description

Procédé et système de réalisation d'une base de données virtuelle à

partir

de sources de données présentant des schémas hétérogènes La présente invention concerne un procédé et un système pour réaliser une base de données virtuelle, à partir de données contenues dans une pluralité de sources hétérogènes, en particulier du point de vue des schémas représentant leur organisation et leur structure.

Elle concerne en outre un procédé de définition de correspondance entre des données sources et un schéma cible représentant la structure d'une table de données cible à alimenter avec ces données sources.

Elle concerne aussi un procédé de détection et de résolution des conflits pouvant survenir entre différentes tables sources concourrant à cette table cible, ou entre des correspondances représentant leurs différentes contributions.

Le domaine de l'invention est celui des systèmes et procédés de mémorisation, traitement et gestion de bases de données informatiques, en particulier sous la forme de bases de données relationnelles.

De telles bases de données comprennent ou utilisent le plus souvent des moyens de mémoire permanente et de grande capacité qui peuvent stocker des quantités importantes de données. Ces données sont en général gérées par un ou plusieurs ordinateurs utilisant un logiciel constituant un moteur de base de données, par exemple DB2 ou Oracle, qui fournit une interface permettant une consultation rapide et précise. Une consultation se fait le plus souvent par une requête exprimant la nature des informations recherchées, par exemple dans le langage SQL ( Structured Query Language ). Les recherches nécessaires au sein de la masse de données stockées sont alors réalisées ou gérées par le moteur de base de données, et seules les données issues de cette recherche sont transmises au programme ou à l'utilisateur qui a émis cette requête.

Or, il est souvent utile de pouvoir disposer de données provenant de sources différentes sans avoir à en regrouper le stockage ou la gestion.

Il peut s'agir, par exemple, d'étudier un problème sous un angle différent en actualisant régulièrement un tableau de bord au sein d'une entreprise ou d'un groupe d'entreprises. Il peut s'agir aussi de mettre en commun des ressources existant sous la forme de données lors d'une fusion d'entreprises, tout en gardant une certaine souplesse en laissant chaque filiale gérer et actualiser elle-même ses données.

Il est connu pour cela de réaliser une base de données virtuelle , c'est à dire qui puise ses données directement dans d'autres bases de données, sans avoir à les mémoriser par elle-même. Une telle base de données comprend une ou plusieurs tables cibles, qui peuvent être consultées de façon similaire à une base de données classique. De la même façon qu'une table de données au sein d'une base non virtuelle, chacune de ces tables cibles présente un schéma qui lui est propre, c'est à dire une structure et une organisation définissant les types de données qu'elle fournit. Les enregistrements de ces tables cibles ne sont créés, ou instanciés, à partir des données provenant des différentes sources, qu'au fur et à mesure des besoins, le plus souvent au moment même d'une consultation.

Pour une table cible, cette instanciation est alors réalisée par une requête, par exemple de type SQL, dont le code comprend lui même des instructions d'accès consultant les différentes sources impliquées pour obtenir les données nécessaires. Cette requête définit alors une vue qui fournit les données de la base de données virtuelle, et permet leur consultation de façon similaire à une base de données classique.

Or, le code SQL qui constitue la requête de cette vue peut présenter une grande complexité et nécessiter un travail important, en particulier d'analyse, de programmation et de vérification, voire de maintenance.

De plus, lorsque l'on souhaite obtenir de nouvelles catégories de données, en définissant de nouvelles tables cibles à partir de telles sources différentes, le schéma de la base de donnée virtuelle doit être redéfini et de nouvelles requêtes doivent être programmées.

Par ailleurs, les données qui alimentent une base de données sont souvent recueillies ou générées au cours de l'activité d'une organisation ou d'une entité déterminée. La structure et l'organisation de cette base de données est en général prévue en fonction des besoins ou des possibilités de cette entité. Ces données sont alors organisées pour être facilement accessibles et utilisables selon les critères de cette entité, par exemple un des services compris dans une entreprise ou une organisation.

Ainsi, des entités différentes disposent souvent, dans leurs bases de données, d'informations qui ne sont pas directement compatibles ou cohérentes entre elles. Une telle diversité est souvent à l'origine d'une hétérogénéité entre différentes sources de données accessibles par une même personne ou entité, par exemple entre différents services d'une même organisation ou lors d'une fusion ou d'une mise en commun des ressources de plusieurs organisations.

De telles sources peuvent être hétérogènes entre elles du point de vue du matériel ou du logiciel comme du point de vue de la structure ou de l'organisation des données. Cette hétérogénéité peut aussi comprendre des manques de données dans certains domaines, ou des incohérences ou des contradictions entre des données censées représenter la même information.

Pour permettre de disposer d'informations utilisables à partir de sources hétérogènes du point de vue matériel ou logiciel, des outils de compatibilité et de localisation existent ou peuvent être programmés pour faire communiquer des types déterminés de plateformes informatiques ou de bases de données.

Par contre, chaque source de données présente souvent un schéma qui lui est propre, c'est-à-dire la structure et l'organisation des données dont elle dispose. Il est donc difficile de préparer des outils d'interfaces standardisés, et l'utilisation conjointe de plusieurs sources hétérogènes nécessite souvent un important travail de développement sur mesure, en fonction des données que l'on souhaite obtenir.

Ainsi, la réalisation d'une base de données virtuelle, en particulier à partir de sources hétérogènes du point de vue de leurs schémas, représente souvent un travail important et délicat, et nécessitant des compétences élevées.

De plus, pour pouvoir prendre en compte l'ensemble des différents schémas sources, un programmeur risque de devoir commencer par une étude approfondie et complète de toutes ces sources, ce qui constitue également un travail long et difficile et représente un coût important. Pour une telle étude, il est par exemple courant de demander aux différents experts des sources concernées de réunir une documentation détaillée portant sur les spécifications des sources qu'ils connaissent. Cette documentation représente alors un travail important à réaliser, et aussi à étudier.

En outre, la programmation obtenue forme un code volumineux et complexe. Les opérations de test et de validation représentent alors aussi un travail lourd et complexe, aussi bien pour le programmeur que pour les utilisateurs de la base de données virtuelle.

Pour les mêmes raisons, toutes les opérations ultérieures de maintenance ou d'évolution de ce code sont de plus rendues délicates et complexes.

Dans certains documents, il a été proposé d'automatiser une partie de ce type de travail, par des outils logiciels utilisant une approche globale pour fournir automatiquement une relation entre les données sources et un schéma cible.

Ainsi, la demande de brevet US20030217069 propose un logiciel qui, après avoir identifié certaines limites pour les relations possibles, établit une liste complète des relations possibles au sein de ces limites. Par des tests systématiques sur un certain nombre d'exemples, et au vu des résultats obtenus par ces différentes relations, l'utilisateur doit déterminer intuitivement la relation qui réalisera la base de données virtuelle recherchée.

Cependant, une telle technique peut fournir un nombre très important de possibilités. De plus, le fait de choisir à partir de tests sur des données exemples présente le risque que les choix effectués ne soient pas valables de façon assez générale pour toutes les données sources, actuelles ou futures.

Dans une optique similaire, la demande de brevet US20040199905 propose d'effectuer automatiquement une analyse sémantique de la structure interne d'un schéma source à partir de sa modélisation XML. Les résultats de cette analyse sont alors utilisés pour définir une association entre le schéma source et le schéma cible.

Toutefois, cette technique nécessite de disposer d'une modélisation XML des schémas, et n'est pas directement utilisable avec une source modélisée sous la forme d'une table de données relationnelle. De plus, elle ne prévoit pas d'association entre des groupes de sources différentes ou hétérogènes.

Enfin, de telles méthodes ne résolvent pas de façon significative les problèmes difficiles que sont l'importance des connaissances à réunir pour réaliser une telle base de données virtuelle, non plus que le volume et la complexité du code obtenu.

Un but de l'invention est de pallier tout ou partie des inconvénients de l'art antérieur.

L'invention cherche en particulier à permettre l'utilisation de sources hétérogènes sous la forme de tables relationnelles.

Un autre but est de permettre l'utilisation de sources présentant des incohérences ou des contradictions entre elles.

Un autre but est aussi d'obtenir une meilleure fiabilité dans les résultats obtenus, ainsi qu'une plus grande souplesse et simplicité dans la réalisation de la base de données virtuelle.

L'invention propose un procédé pour réaliser une base de données virtuelle comprenant au moins une table relationnelle, dite table cible, à partir de données contenues dans une pluralité de sources hétérogènes.

Lesdites données sont vues comme un ensemble de tables sources, par exemple relationnelles, et le procédé comprend: pour au moins une desdites sources, un processus, dit de publication, comprenant la création d'au moins une correspondance dite de publication entre au moins une table source de cette source et ladite

table cible;

- un processus, dit d'intégration, comprenant la création d'une correspondance dite d'intégration entre ladite table cible et un ensemble desdites correspondances de publication.

De préférence, le processus d'intégration comprend en outre une étape de détection d'au moins un conflit éventuel entre plusieurs correspondances de publication, suivie d'une étape de traitement dudit conflit.

Plus particulièrement, ces étapes de détection et de traitement des conflits éventuels peuvent être répétées de façon itérative, de façon à affiner ou vérifier la résolution de ces conflits ou tester différents choix de solutions.

Chacun de ces processus de publication ou d'intégration peut comprendre des tâches automatisées et des tâches pouvant nécessiter une intervention par un opérateur humain. Ces interventions peuvent comprendre en particulier une saisie de règles ou de formules, ou une sélection parmi des décisions possibles présentées par l'interface et déterminées automatiquement en fonction de caractéristiques mémorisées ou identifiées précédemment.

Pour la publication de chaque source, ces interactions humaines permettent de définir la construction des instances des tables cibles en fonction des instances des tables sources, c'est à dire d'alimenter la ou les tables cibles. Au sein d'un logiciel mettant en oeuvre le procédé, cette définition est alors exprimée à travers un langage symbolique de haut niveau appelé langage de correspondances de schémas , aussi qualifié de règles de mapping .

Le terme table de données employé ici peut recouvrir différentes formes de données, organisées et accessibles sous la forme d'une relation ou schéma de relation au sens standard dans le domaine des bases de données informatisées. Un schéma de base de données relationnelle est défini par un ensemble de schémas de relations.

Une table comprend un ensemble variable d'enregistrements, ou tuples , présentant une structure identique au sein de la table. Cette structure comprend en particulier la définition d'un certain nombre d'attributs, chacun d'un type déterminé, pour lesquels chaque enregistrement comprend une valeur mémorisée. Pour un attribut, la valeur nulle, ou null , correspond à une valeur non définie autrement.

Les données elles-mêmes peuvent être mémorisées sous des formats matériels ou logiciels différents, par exemple dans un format de fichier de base de données tel que les formats .dbf ou .mdb , mais aussi dans d'autres types de fichiers tels que des arborescences, des fichiers texte, ou des feuilles de calcul de programmes de type tableur.

A travers divers outils logiciels de localisation, d'échange ou d'indexation, par exemple au format ODBC , de telles données peuvent alors être accessibles et vues en tant que tables de données, et seront traitées ici comme telles.

Pour chacune des sources concernées, on voit que le processus de publication peut être réalisé indépendamment des autres sources, et sans connaître le fonctionnement ou le schéma de ces autres sources. Il est donc possible que ce travail soit réalisé en parallèle, par des personnes différentes et ne connaissant que certaines des sources concernées.

Cette publication peut en particulier être réalisée, pour chaque source, par une ou des personnes en connaissant bien les caractéristiques, le schéma et le contenu, par exemple un expert du métier ou du contenu concerné, ou un opérateur habituellement chargé de la maintenance ou de l'enrichissement de la base de données concernée.

Le procédé selon l'invention permet ainsi d'utiliser au mieux les compétences et connaissances existantes pour chacune des sources utilisées. Lors de la publication des sources, ces connaissances sont ainsi réunies et exprimées sous une forme explicite et uniforme: les correspondances de publication, également appelées correspondances de schéma. Ce sont ces correspondances de schéma qui seront alors utilisées pour réaliser une intégration fournissant une vue d'intégration permettant la consultation de la table cible.

Une fois les différentes sources publiées, l'intégration peut alors être réalisée par une personne n'ayant pas besoin de connaître le détail ou les particularités de chacune des sources. L'intégration demandera alors beaucoup moins de temps que s'il avait fallu réunir la totalité des spécifications de toutes les sources concernées. Ainsi, l'intégration peut être faite par une personne disposant de connaissances moins détaillées que les publieurs, et son intervention sera facilitée et accélérée par le fait de disposer des correspondances de schémas précises et vérifiées par ces publieurs eux-mêmes.

De plus, l'intégrateur n'aura besoin de se poser que les questions nécessaires à cette phase du travail. Il dépendra moins des experts des sources utilisées et de leurs disponibilités, ce qui limitera aussi le temps que ces derniers devront lui consacrer.

L'invention permet ainsi de décentraliser et assouplir grandement la mise en commun de données de sources disparates. De telles mises en commun peuvent alors être entreprises de façon beaucoup plus large, par exemple entre des disciplines différentes, ou des organisations indépendantes collaborant selon un mode coopératif plus que hiérarchique.

Il devient possible d'envisager une publication de masse permettant des regroupements de données à des échelles importantes, par exemple de l'ordre de centaines ou milliers de sources.

De préférence, le procédé comprend, pour au moins une correspondance de publication, une génération d'une vue, dite de publication, comprenant une requête, dite de publication, portant sur toutes les tables sources utilisées par ladite correspondance de publication.

En particulier, cette génération se fait automatiquement à partir des définitions des correspondances de schéma. Celles-ci sont traduites ou compilées automatiquement par un logiciel, sous la forme d'une ou plusieurs requêtes SQL sur la source publiée.

La définition des instances des tables cibles en fonction des tables sources ne nécessite ainsi aucun développement informatique, ni dans un langage de programmation, ni dans un langage de requêtes de base de données comme SQL.

Une fois qu'une correspondance de schéma est définie, les enregistrements cibles qu'elle fournit peuvent être calculés par une simple exécution de sa requête de publication. Cette requête de publication est mémorisée, par exemple dans un fichier texte, au sein d'un ensemble d'informations appelé base de métadonnées.

Avantageusement, le processus d'intégration comprend au moins une génération d'une vue, dite d'intégration, comprenant au moins une requête portant sur tout ou partie des tables sources utilisées par les correspondances de publication intégrées.

Cette intégration peut en particulier comprendre des interactions avec une interface logicielle, qui mémorise des choix ou des formules ou des règles sous la forme d'un langage symbolique dit langage de correspondance d'intégration . Ce langage est basé sur les mêmes principes que le langage de correspondance de schéma et peut apporter le même type d'avantages, en particulier ne nécessiter que peu ou pas de développement informatique.

La génération de la vue d'intégration peut alors se faire automatiquement à partir de la définition de la correspondance d'intégration. Celle-ci est traduite ou compilée automatiquement par un logiciel, sous forme d'une requête SQL sur les vues de publication des correspondances de publication intégrées.

Une fois l'intégration réalisée, chaque table cible de la base de données virtuelle est accessible en consultation par une simple exécution de sa requête d'intégration. Cette requête d'intégration est mémorisée, par exemple dans un fichier texte, au sein d'un ensemble d'informations appelé base de métadonnées, qui représente la structure de la base de données virtuelle.

De façon optionnelle, le procédé comprend une génération d'une vue, dite symétrique, comprenant un couple de requêtes portant, d'une part sur les tables sources d'une correspondance de publication, et d'autre part sur la table cible.

Cette vue symétrique peut constituer une étape intermédiaire dans la génération de la vue de publication, et être mémorisée au sein des 20 métadonnées.

Au cours des différentes phases de la réalisation de la base de données virtuelle, tout ou partie des informations ou résultats intermédiaires peut être mémorisé dans cette base de métadonnées.

Ainsi, les différentes règles ou sélections définissant les correspondances de schéma et d'intégration peuvent être mémorisées ainsi, de même que les requêtes définissant les différentes vues de publication.

La mémorisation de ces informations intermédiaires permet en particulier de vérifier ou corriger des étapes intermédiaires, ou d'en modifier ou ajouter certaines.

Dans un mode de réalisation particulier de l'invention, une correspondance d'intégration est modifiée de manière incrémentale en prenant en compte au moins une nouvelle correspondance de publication.

- 10 - De façon similaire, une correspondance de publication est modifiée de manière incrémentale en prenant en compte au moins une nouvelle table source.

Il est ainsi possible de réaliser une base de données virtuelle par plusieurs opérations incrémentales, par exemple en fonction de la disponibilité des sources et de leurs publications, ou pour étaler la charge de travail générée. Il est aussi possible de faire évoluer plus facilement et de façon plus souple une telle base de données virtuelle, en intégrant de nouvelles sources sans avoir besoin de recommencer l'intégration des sources déjà utilisées.

Une première opération de publication et d'intégration peut alors être qualifiée de mono-passe ou one-shot , puis se voir adjoindre des correspondances de schéma supplémentaires lors d'une nouvelle intégration alors qualifiée d'incrémentielle.

L'intégration incrémentielle comprendra alors une nouvelle phase de détection et traitement de conflits entre d'une part la ou les nouvelles correspondances de schéma et d'autre part celles précédemment intégrées.

Ces nouvelles phases de détection et traitement de conflits pourront alors utiliser directement des informations mémorisées dans la base de métadonnées au cours de la (ou les) intégration(s) précédente(s). Il est alors possible de tenir compte des règles de mapping précédemment élaborées ou d'en sélectionner certaines, et possiblement de les modifier ou les affiner.

Selon une particularité de l'invention, au moins une table source 25 comprend au moins un attribut composant une clé pour ladite table source ou une clé étrangère pour une autre table source.

L'invention s'applique en particulier à une table cible comprenant au moins un attribut composant une clé pour ladite table cible, ou une clé étrangère pour une autre table cible.

Typiquement la définition du schéma cible comprend un certain nombre de contraintes s'appliquant aux attributs de la table cible, par exemple la table cible peut comprendre un ou plusieurs attributs obligatoires.

- 11 - Un attribut est dit obligatoire lorsqu'il ne doit pas prendre la valeur null pour satisfaire aux contraintes du schéma dans lequel il est défini. En particulier, toute clé au sein d'une table constitue un attribut obligatoire. Ainsi, le schéma cible peut prévoir que certains attributs, possiblement autres que des clés, doivent obligatoirement être renseignés pour tous les enregistrements qui apparaîtront dans la table cible.

Certaines caractéristiques et particularités des correspondances de schéma, ou correspondances de publication, vont maintenant être décrites.

Typiquement, une correspondance de publication porte sur une ou 10 plusieurs tables sources, et comprend les éléments suivants: une partie source, comprenant la ou les tables sources; un ou des liens de composition exprimés entre les tables sources, et qui permettent de définir des enregistrements composites au sein de la partie source, à partir des enregistrements des tables sources; - une partie cible constituée de la table cible visée; - des formules de calcul, pouvant être réduites à une simple égalité, fournissant une valeur pour chaque attribut de la table cible, directement ou à partir d'un ou plusieurs attributs de la partie source; optionnellement, un ou plusieurs filtres sources, exprimés sur les 20 attributs de la partie source; optionnellement, un ou plusieurs filtres cibles, exprimés sur les attributs de la partie cible.

Il est à noter qu'une même source, comprenant une ou plusieurs tables sources, peut être utilisée pour définir plusieurs correspondances de publication différentes. Cette caractéristique peut par exemple permettre de répartir le travail en plusieurs session, ou entre plusieurs publieurs. Elle peut aussi permette de publier une même source sous plusieurs formes différentes destinées à être intégrées en plusieurs tables cibles différentes.

Selon une particularité de l'invention, une ou plusieurs des correspondances de publication utilisent au moins une correspondance d'attribut dans laquelle au moins un attribut de la table cible dépend d'au moins une fonction ou d'au moins une formule de calcul, portant sur au moins un attribut d'au moins une table source.

- 12 - Selon une particularité de l'invention, la totalité des correspondances de publication fonctionnent ainsi par correspondance d'attributs.

Selon différentes particularités de l'invention pouvant être combinées entre elles, au moins une correspondance d'attribut: - fournit une valeur constante, ou - comprend une référence à au moins un nom d'attribut d'une table source, ou comprend au moins une opération binaire arithmétique, ou - utilise au moins une de règle de traitement de cas.

Selon une particularité de l'invention, au moins une correspondance de publication utilise au moins un lien de composition exprimé entre au moins deux tables sources.

Plus particulièrement, au moins un lien de composition entre une première et une deuxième table source utilise un critère d'équivalence ou d'égalité entre la valeur d'au moins un attribut d'au moins un enregistrement de la première table source et la valeur d'au moins un attribut d'au moins un enregistrement de la deuxième table source.

Dans un mode de réalisation préféré, un enregistrement de la partie source, appelé enregistrement composite, est obtenu en composant au moins deux enregistrements pris chacun dans une table source différente, en définissant un critère de composition. Celui-ci s'exprime comme un critère d'égalité de valeurs entre des attributs pris dans le premier enregistrement et le même nombre d'attributs pris dans le deuxième enregistrement. Ce critère d'égalité s'appelle un lien de composition entre les deux tables sources.

On peut aussi enrichir la définition des liens de composition entre deux tables TS1 et TS2 en autorisant les critères d'égalité de la forme formule(TS1) = formule(TS2) où pour toute table U, formule(U) représente - la référence à un attribut de cette table U, ou une expression fonctionnelle, c'est à dire une composition de fonctions, appliquée sur un ou plusieurs attributs de cette table U. Ainsi, la composition d'un enregistrement (a, b, c) d'une table source TS1 d'attributs Al, B et C 2888018 -13- IA11B CI a b c avec un enregistrement (a, d, e) d'une table source TS2 d'attributs A2,DetE: IA2 D I E a d e pourra se faire par un lien de composition comprenant une égalité entre les valeurs des attributs Al et A2.

L'enregistrement composite obtenu sera alors (a, b, c, d, e).

En outre, une correspondance de publication peut utiliser un ou plusieurs filtres exprimés sur un ou plusieurs attributs d'une ou plusieurs tables sources.

En particulier, un filtre peut comprendre une expression conditionnelle, en particulier exprimée sur un ou plusieurs attributs d'une table source.

Les enregistrements des tables sources utilisés dans la partie source d'une correspondance peuvent être filtrés à l'aide de critères de sélection. Seuls les enregistrements des tables sources qui passent ces filtres sont capables de produire des enregistrements composites et donc des enregistrements dans la table cible.

Une expression conditionnelle peut prendre en particulier l'une des formes suivantes: une opération binaire booléenne de la forme: (formule OP valeur) où formule est soit la référence à l'attribut filtré soit une expression fonctionnelle, c'est à dire une composition de fonctions, appliquée sur un ou plusieurs attribut(s) de la partie source et OP est un opérateur de comparaison classique, par exemple: <, >, = ,<=, =>, <>, LIKE, NOT LIKE.

Par exemple: id.client > 999 - une expression d'encadrement de la forme: (valeurl OP formule OP valeur2) où formule a le même sens que dans le cas précédent tandis que OP est restreint à un des opérateurs de 14 - comparaison suivants: <, >, <=, =>. Par exemple: 999 < id.client <9999 une combinaison de

conjonctions et de disjonctions d'opérations binaires booléennes ou d'expressions d'encadrement. Par exemple: (LEFT(id.client; 2) = 12) ET NON(999 < id.client <9999) , où LEFT(id.client; 2) est une fonction renvoyant les deux caractères de gauche du code id.client .

Des formules de calcul sont utilisées pour décrire la méthode de construction d'un enregistrement de la table cible à partir d'un enregistrement composite. Chacune de ces formules décrit comment calculer la valeur d'un attribut de la table cible à partir des valeurs des attributs de l'enregistrement composite Une formule de calcul sur un attribut cible A peut être en particulier: É une constante. Lorsque la formule de calcul F associée à A est une constante, elle peut aussi être interprétée comme une contrainte sur les valeurs des enregistrements de la table cible produits par cette correspondance. Cette contrainte est alors de la forme: A = constante .

É une référence à un nom d'attribut d'une table source.

É une expression fonctionnelle, c'est à dire une fonction ou une composition de fonctions.

É une expression arithmétique entre plusieurs expressions, par exemple de la forme expressionl OP expression2 . Chaque expression expressionl ou expression2 peut être elle-même une expression fonctionnelle, ou une constante, ou une référence à un nom d'attribut d'une table source, ou être elle-même une expression arithmétique.

É une fonction agrégat, c'est-à-dire par exemple une des fonctions sum , max , min , avg ou count qui se conforme à la syntaxe de standard SQL. Traditionnellement, dans la syntaxe SQL, les fonctions agrégat sont utilisées conjointement avec la commande group by de regroupement des enregistrements selon des attributs de groupement.

Dans le cas du langage de correspondance de publication ou d'intégration, la commande group by est implicite. Lorsqu'au moins une - 15 fonction agrégat est présente, les attributs de l'enregistrement qui ne sont référencés dans aucune fonction agrégat sont considérés comme attributs de groupement.

É un ensemble de règles de traitement de cas, tel que détaillé plus loin.

Ainsi, par exemple, si le schéma cible présente les attributs (U, V, W, X, Y, Z), un enregistrement composite: (a, b, c, d, e) tel que cité plus haut pourra fournir un enregistrement cible: (u, v, d, e, 100, nul!) en utilisant les formules de calcul suivantes: - pour l'attribut U: =f(A1, B) - pour l'attribut V: =g(A1, h(B, C)) - pour l'attribut W: =D - pour l'attribut X: =E - pour l'attribut Y: =100 - pour l'attribut Z: =null où f , g et h sont des expressions fonctionnelles.

Des règles de traitement de cas peuvent être utilisées pour définir différentes formules de calcul en fonction des données contenues dans l'enregistrement composite défini par la partie source.

Un traitement de cas se compose d'un ensemble de règles du type: if condition then nom_d'attribut = formule_de_calcul .

Dans une telle règle, nom_d'attribut est le nom de l'attribut cible concerné par le traitement de cas et formule_de_calcul peut être une constante, ou une référence à un attribut d'une table source, ou une expression fonctionnelle, c'est-à-dire une fonction ou une composition de fonctions.

La partie condition est une expression conditionnelle pouvant porter sur un ou plusieurs attributs de l'enregistrement composite défini par la partie source.

Une telle expression conditionnelle peut être une opération binaire booléenne de la forme: ( formule de calcul OP formule de calcul , 16 - où formule de calcul est par exemple une constante, ou une référence à un attribut source, ou une expression fonctionnelle appliquée à un ou plusieurs attributs source, et où OP est un opérateur de comparaison classique, par exemple: 5 < , > , _ , <_ , _> , <> , LIKE , NOTLIKE . Par exemple: clientsl.ville <> clients2.ville Cette expression conditionnelle peut aussi être une expression d'encadrement de la forme: formule de calcul OP formule de calcul OP formule de calcul où formule de calcul est par exemple une constante, ou la référence simple à un attribut source, ou une expression fonctionnelle, c'est-à-dire une composition de fonctions appliquées sur des attributs sources et OP est un des opérateurs de comparaison suivants: < , > , <_ , _> .

Par exemple: date _achat < date_réparation < date_achat + 12mois Une telle expression conditionnelle peut aussi être une suite d'opérations binaires booléenne et/ou d'expressions d'encadrement modifiées ou reliées entre elles par un connecteur logique, par exemple ET , OU ou NON .

Ainsi, un exemple de règle de traitement de cas peut être: If (S1.A1 LIKE 'H%') AND (S1.A2 = S2.A3) AND (S1.A3 LIKE concat(S1.A4, '%') then quantite = S1.A6 Cette règle sera alors interprétée comme suit: Pour un enregistrement source issu de la source S1, dans le cas où la valeur de l'attribut Al est au format pourcentage, et que la valeur de l'attribut A2 est égale à la valeur de l'attribut A3 , et que la valeur de l'attribut A3 est similaire à une concaténation de la valeur de l'attribut A4 avec un caractère % , alors la valeur de l'attribut quantité de l'enregistrement cible obtenu sera égale à la valeur de l'attribut A6 de cet enregistrement source .

Plus particulièrement, une même correspondance d'attribut peut utiliser une pluralité de règles de traitement de cas exécutées dans un ordre déterminé.

- 17 - Les règles qui composent un traitement de cas sont examinées dans l'ordre où elles sont écrites. L'ordre est important car il peut influencer le résultat de la formule de calcul. En effet, si les conditions de deux règles ne sont pas disjointes cela signifie que pour un même enregistrement composite les deux règles sont susceptibles de s'appliquer. Dans ce cas, c'est la valeur calculée par la première règle qui sera utilisée. L'interface logicielle de définition des règles de traitements de cas permet d'ordonnancer les règles.

Si pour un enregistrement composite donné aucune règle n'est applicable, l'enregistrement composite n'est pas utilisé pour produire un enregistrement dans la table métier. Pour éviter cette situation il est possible de définir une règle qui sera appliquée par défaut si aucune des autres règles n'est applicable. La syntaxe de cette règle peut être: If autres cas then formule de calcul Dans cet exemple, le mot clé autres cas indique que la formule intitulée formule_de_calcul sera exécutée sur tout enregistrement ne satisfaisant aucune des autres règles du traitement de cas. Dans une formule de traitement de cas, la règle autres cas est soit inexistante, soit placée en dernière position.

En particulier, un traitement de cas constitué d'un nombre k de règles peut être modélisé par une formule de la forme: IFELSE ((condl, action 1), ..., (condk, actionk)) où condi est la condition de la iieme règle et actioni est la partie then de cette règle.

Dans le cas où la dernière règle est une règle autres cas , le paramètre condk prend la valeur NULL .

Selon une particularité de l'invention, au moins une correspondance de publication utilise au moins un filtre exprimé sur au moins un attribut de la table cible.

On peut ainsi enrichir la définition d'une correspondance au moyen de filtres cibles, portant sur la table cible de cette correspondance. Un filtre cible sur une table cible permet de filtrer les enregistrements produits par l'application des formules de calcul sur les enregistrements des tables source de la correspondance. Ainsi seuls les enregistrements qui passent - 18 - ces filtres sont utilisés pour produire des enregistrements dans la table cible. Les filtres cibles peuvent avoir les mêmes types de formes que les filtres sources.

De préférence, le procédé comprend en outre une vérification d'au moins une correspondance de publication ou d'intégration.

Il s'agit en particulier de vérifier la correction de leurs définitions.

Selon une particularité de l'invention, au moins une correspondance comprend une vérification, dite statique, de la validité de ladite correspondance au regard d'au moins une règle syntaxique ou portant sur la structure des données traitées par ladite correspondance.

Selon une autre particularité, la vérification d'au moins une correspondance de publication comprend une vérification, dite dynamique, portant sur la qualité des données contenues dans au moins un enregistrement cible fourni par ladite correspondance de publication.

Avantageusement, la vérification d'une correspondance comprend à la fois la vérification statique et la vérification dynamique.

La vérification statique concerne la validité de la définition d'une correspondance au regard des règles de mapping. En particulier, elle comprend une vérification de la suffisance des liens de composition, c'est à dire que toutes les tables sources utilisées dans la partie source de la correspondance sont liées entre elles pour la définition d'un enregistrement cible. Selon une autre particularité, la vérification statique comprend une vérification que la correspondance est complète, c'est à dire que tous les attributs obligatoires de la table cible ont été renseignés par des formules de calcul. On vérifie en particulier que les attributs clés de la table cible sont renseignés.

Pour une correspondance de publication, il peut être normal de ne pas être complète, par exemple si ses tables sources ne contiennent pas d'attributs permettant de renseigner certains attributs obligatoires. Dans ce cas, la vérification statique peut signaler une non-complétude qui pourra être considérée comme une erreur non bloquante. Pour pouvoir exécuter correctement la requête de publication d'une correspondance de schéma non complète, par exemple pour permettre la vérification dynamique, on pourra compléter cette correspondance en attribuant artificiellement ou - 19 ponctuellement une valeur aux attributs obligatoires, par exemple la valeur nulle.

Selon une particularité de l'invention, la vérification statique d'une correspondance est entièrement automatique et s'effectue par exemple dans l'ordinateur utilisé pour définir cette correspondance.

La vérification dynamique concerne les enregistrements cibles construits par la correspondance. Il s'agit de tout d'abord de contrôler la qualité de ces enregistrements cibles obtenus, c'est-à-dire contrôler qu'ils sont conformes à des contraintes d'intégrité définies sur la table cible.

Ces contraintes d'intégrité peuvent être en particulier: - la validité du format des valeurs d'un attribut; - la précision des valeurs d'un attribut dans son domaine. La précision des valeurs d'un attribut A est une assertion spécifiée au moyen d'une formule de la logique des prédicats. Les prédicats élémentaires supportés sont de la forme <A comparateur valeur> , où comparateur est de la forme = , > , < , like ; - la complétude d'un attribut. Le fait qu'un attribut A doit vérifier la propriété de complétude signifie qu'aucune de ses instances ne doit avoir la valeur null , c'est à dire sans valeur définie.

les contraintes d'intégrité entre plusieurs attributs. Par exemple si l'attribut sexe a pour valeur M , alors la valeur de l'attribut civilité ne peut être ni Madame ni Mademoiselle ; - l'unicité d'un attribut ou d'un ensemble d'attributs. Par exemple la contrainte d'unicité d'un attribut A dans une table cible signifie que cet attribut ne doit pas prendre deux fois la même valeur dans deux enregistrements de cette table cible. Il peut s'agir par exemple d'une clé qui ne doit pas comporter de doublons dans la table cible.

La vérification dynamique permet d'apporter des corrections de façon à obtenir la qualité désirée au sein des enregistrements cibles obtenus, et 30 comprend une vérification des données obtenues par la correspondance à vérifier.

La vérification des données se fait en interaction avec l'utilisateur. La vérification est itérative, critère par critère, groupe d'attributs par groupe d'attributs. Le processus de validation est basé en particulier sur trois types d'opérations: tester, échantillonner et analyser.

- L'opération de test consiste à calculer les enregistrements cibles erronés.

- L'opération d'échantillonnage consiste à filtrer les enregistrements 5 erronés de façon à les regrouper selon certains critères.

L'opération d'analyse consiste à faire apparaître les enregistrements sources qui sont impliqués dans les enregistrements erronés.

A partir d'une ou plusieurs contraintes d'intégrité définies sur la table cible, les enregistrements cibles ne respectant pas cette ou ces contraintes sont calculés par un algorithme utilisant un certain nombre d'informations en entrée.

Ces informations d'entrée peuvent comprendre en particulier: la correspondance C à vérifier, une contrainte CQ choisie comme critère de test et portant sur les enregistrements de la table cible, et un ensemble A d'un ou plusieurs attributs impliqués dans cette contrainte. A partir de ces éléments, l'algorithme met en oeuvre un filtre F sélectionnant les enregistrements cibles ne satisfaisant pas cette contrainte, et peut comprendre une option Rep portant sur la forme sous laquelle seront fournis les enregistrements sélectionnés.

Au sein d'une vue V associée à la correspondance C à vérifier, l'algorithme de test calcule les enregistrements cible qui ne satisfont pas la contrainte CQ choisie. Avantageusement, cette vue V sera la vue la plus large associée la correspondance à vérifier, et en particulier une vue complète dans le cas d'une correspondance d'intégration.

La forme de la réponse dépend du paramètre Rep . Selon la valeur de Rep , elle peut par exemple fournir ou afficher l'ensemble des enregistrements calculés, ou uniquement le nombre de ces enregistrements.

En langage SQL, l'opération de test calculera les enregistrements 30 erronés par une requête selon la forme suivante: SELECT * FROM V WHERE F L'échantillonnage des enregistrements erronés, calculés lors de l'opération de test, comprend l'utilisation d'un filtre supplémentaire F' choisi de façon à les regrouper selon certains critères.

- 21 - L'opération d'échantillonnage fournit alors un ensemble d'enregistrements cibles calculés qui est un sous-ensemble de l'ensemble des enregistrements calculés par l'algorithme de test cité plus haut.

En langage SQL, l'opération d'échantillonnage calculera les enregistrements erronés choisis par une requête selon la forme suivante: SELECT * FROM V WHERE F AND F' L'opération d'analyse des enregistrements erronés calcule les enregistrements source impliqués dans la production d'enregistrements cibles erronés, ce qui permet à l'utilisateur de cerner les raisons de ces erreurs.

Le calcul des enregistrements sources impliqués utilise une vue portant sur les tables sources de la correspondance à vérifier, et que l'on qualifie de vue source étendue pour cette correspondance. Cette vue étendue porte à la fois: - sur les attributs cibles de la vue simple associée à la correspondance C à vérifier, et - sur les attributs des tables sources de cette correspondance C , dits attributs cachés.

Cette vue source étendue est calculée par une requête dite requête 20 source étendue , et ses enregistrements seront appelés enregistrements sources étendus .

Cette vue source étendue est générée de façon similaire à une vue simple pour cette correspondance, mais en incluant les attributs sources cachés de cette même correspondance, en plus de ses attributs cibles.

A chaque enregistrement cible erroné correspond ainsi un enregistrement source étendu, dont les attributs cachés sont la projection directe des attributs sources utilisés. La lecture des valeurs de ces attributs cachés permet ainsi de connaître la valeur des attributs sources à l'origine de cet enregistrement cible erroné.

A partir d'une liste d'échantillons erronés, complète ou échantillonnée, l'analyse calcule la projection des enregistrements sources étendus sur un ensemble B d'attributs de projection.

- 22 - En langage SQL, pour une liste d'enregistrements cibles erronés obtenue par un filtre F , l'opération d'analyse calcule les enregistrements sources étendus impliqués par une requête selon la forme suivante: SELECT B FROM <Vue source étendue de C> WHERE F La vérification dynamique fournit un outil souple et puissant permettant de réaliser une validation individuelle de chaque correspondance et des données qu'elle fournit.

Pour une correspondance ou un groupe de correspondances, cette validation peut avantageusement se faire de façon itérative.

Pour une contrainte choisie, cette validation comprend un calcul et une mémorisation des enregistrements non satisfaisants.

Un échantillonnage itératif en affinant progressivement le filtre d'échantillonnage F' permet alors d'obtenir les informations suffisantes.

Une analyse de l'échantillon obtenu à partir de ses enregistrements sources permet alors de définir des corrections ou améliorations à apporter à la correspondance étudiée.

Tout au long du processus de publication de chaque source, les informations et définitions de chaque correspondance de schéma sont mémorisées en tout ou partie dans la base de métadonnées.

Ces informations sont alors disponibles par exemple pour les publieurs, s'ils souhaitent vérifier, modifier, améliorer ou compléter la publication de leur source.

Certaines caractéristiques et particularités d'une correspondance d'intégration vont maintenant être décrites.

Une fois qu'un certain nombre de sources sont publiées, et de préférence vérifiées, sous la forme de correspondances de schéma vers une même table cible il est possible de commencer à intégrer les correspondances de publication qui en sont issues. Les informations concernant ces correspondances de publications sont par exemple lues dans la base de métadonnées, et utilisées par un outil logiciel doté d'une interface interagissant avec un opérateur d'intégration.

Typiquement, une correspondance d'intégration porte sur plusieurs correspondances de schéma (ou de publication), et comprend les éléments suivants: - une partie source, comprenant les différentes vues de publication des correspondances de schéma à intégrer; - au moins un lien de composition, auquel peut s'ajouter une formule de composition des domaines des clés pouvant permettre de résoudre certains conflits; - une partie cible constituée de la table cible visée; - des formules de calcul, pouvant être réduites à une simple égalité, fournissant une valeur chaque attribut de la table cible à partir d'un ou plusieurs attributs des vues de publication; De préférence, la correspondance d'intégration utilise au moins un lien de composition exprimé entre au moins deux correspondances de publication et utilisant une égalité des clés au sein de la table cible, en particulier telle qu'elle est renseignée par les différentes correspondances de publication.

Il est à noter que les filtres sources ou cibles précisés plus haut dans le cadre du processus de publication peuvent aussi être appliqués au niveau du processus d'intégration, ou être considérés comme faisant partie de l'intégration, en plus ou en remplacement des filtres appliqués lors de la publication, sans sortir de l'esprit de l'invention. Ils ne seront donc pas détaillés plus avant dans le cadre de l'intégration.

De préférence, la correspondance d'intégration comprend au moins une correspondance d'attribut dans laquelle au moins un attribut de la table cible dépend d'au moins une fonction d'au moins un attribut fourni par une correspondance de publication.

Ces correspondances d'attribut fonctionnent de façon similaire à celles décrites plus haut pour le processus de publication, et ne seront pas détaillées plus avant ici.

Lorsqu'une table cible comprend des enregistrements provenant de plusieurs vues de publication différentes, il peut se produire des conflits, par exemple des incohérences ou des contradictions, qui n'existaient pas au sein de chacune de ces vues ni au sein des tables sources sur lesquelles elles portent.

Selon une particularité de l'invention, le processus d'intégration comprend une détection de conflits de domaines entre deux - 24 correspondances de publication portant sur au moins un même attribut clé de la table cible. Cette détection de conflits de domaines comprend au moins une opération de comparaison portant sur des domaines de valeurs accessibles par ladite clé au sein desdites correspondances.

La méthode de détection des conflits comprend en particulier une recherche de non-conflit de domaines pouvant être démontrés. Les outils de preuve sont des règles basées sur l'analyse syntaxique et/ou des assertions formulées interactivement par l'opérateur d'intégration.

La recherche de non-conflit de domaines entre deux correspondances de publication C et C' portant sur la même table cible comprend, en particulier, une comparaison entre leurs domaines de clé respectifs, pour au moins une clé portant sur un attribut cible commun A . Cette recherche se fait en particulier selon une ou plusieurs des règles suivantes.

Pour une table cible dont le schéma comprend au moins une clé, on considère que des enregistrements différents ne sont pas en conflit si leurs valeurs pour cette clé prennent des valeurs différentes.

Ainsi, selon une règle de non-conflit de domaines, dite de base, pour des enregistrements provenant de plusieurs vues de publication, si le domaine de cette clé, c'est à dire les valeurs de clé possibles pour les enregistrements, d'une première vue de publication est disjoint du domaine de cette clé d'une deuxième vue de publication, on obtient une certitude de non-conflit.

Selon une première règle de non-conflit de domaines, si l'application de filtres cibles F et F' définis respectivement par ces mêmes correspondances sur la table cible rend disjoints les domaines de clés portant l'attribut A (c'est à dire si la conjonction F(A) ET F'(A) ne peut pas être vraie), alors ces deux correspondances de publication C et C' sont considérées comme non-conflictuelles.

Selon une deuxième règle de non-conflit de domaines, si l'attribut A est défini dans ces deux correspondances par deux fonctions constantes de valeurs différentes, alors ces deux correspondances de publication C et C' sont considérées comme non-conflictuelles.

Selon une troisième règle de non-conflit de domaines: - si l'attribut A est défini dans ces deux correspondances par une même formule constituant une fonction injective, et - si cette fonction comprend comme argument à la fois un attribut source B de C et un attribut source B' de C' ,et - si ces attributs sources B et B' sont des arguments de filtres sources respectivement F et F' , de ces deux correspondances C et C' , ne pouvant sélectionner la même valeur (c'est à dire que la conjonction F(X) ET F'(X) ne peut pas être vraie quelque soit X ), alors ces deux correspondances de publication C et C' sont considérées comme non-conflictuelles.

Tant que la détection de conflit (de domaine ou d'attribut) n'a identifié aucune règle de non-conflit applicable entre plusieurs correspondances de publication déterminées, celles-ci sont considérés comme étant conflictuelles.

Selon une particularité de l'invention, le processus d'intégration comprend une détection de conflits dits d'attribut entre plusieurs correspondances de publication portant sur un même attribut, dit commun, au sein de la table cible, cette détection de conflits d'attribut comprenant une opération de test portant sur la façon dont chacune desdites correspondances fournit une valeur pour ledit attribut, pour vérifier si lesdites correspondances sont susceptibles ou non de fournir pour ledit attribut commun des valeurs ne présentant pas entre elles une fonction invariable.

La méthode de détection des conflits comprend en particulier une recherche de non-conflits d'attribut pouvant être démontrés. Les outils de preuve sont des règles basées sur l'analyse syntaxique et/ou des assertions formulées interactivement par l'opérateur d'intégration.

La recherche de non-conflit de domaines entre deux correspondances de publication C et C' portant sur la même table cible comprend, en particulier, une comparaison entre leurs formules de calcul respectives pour un attribut cible commun A , en particulier un attribut non-clé. Cette recherche se fait en particulier selon une ou plusieurs des règles suivantes.

- 26 - Selon une première règle de non-conflit d'attribut, si les formules de calcul de A par C et C' sont des fonctions constantes fournissant la même valeur, alors l'attribut A est considéré comme n'étant pas conflictuel pour ces deux correspondances C et C' .

Selon une deuxième règle de non-conflit d'attribut, si C et C' comprennent toutes deux un filtre cible portant sur l'attribut A et ne sélectionnant que les enregistrements où A présente une valeur constante identique pour C et C' , alors l'attribut A est considéré comme n'étant pas conflictuel pour ces deux correspondances C et C' .

Tant que la détection de conflit n'a identifié aucune règle de nonconflit de domaine, applicable entre plusieurs correspondances de publication déterminées, ni qu'aucun des attributs commun entre elles n'est pas conflictuel pour ces correspondances, celles-ci sont considérés comme étant conflictuelles entre elles à l'issue de la détection de conflits.

On voit que les méthodes de détection et/ou résolution de conflits selon l'invention présentent un aspect systématique qui les rend valables pour toutes les valeurs possibles dans le cadre des schémas de tables (sources ou cibles) considérés.

La base de données virtuelle ainsi obtenue présente ainsi des qualités d'intégrité et de cohérence qui ne dépendent pas du contenu des tables sources, tant que leurs données respectent les contraintes des schémas sources utilisés pour l'intégration.

Cette indépendance par rapport au contenu permet d'obtenir une meilleure fiabilité et stabilité pour la base de données virtuelle obtenue, par exemple par rapport à des méthodes utilisant le contenu des sources pour établir une vue multi-sources.

Selon une particularité de l'invention, le traitement d'un conflit entre plusieurs correspondances de publication comprend une définition d'au moins une formule de composition des domaines d'au moins une clé commune auxdites correspondances, obtenue par une ou plusieurs opérations de type ensembliste portant sur les domaines de valeurs de ladite clé au sein desdites correspondances.

- 27 - Cette formule peut comprendre en particulier une combinaison d'opérations de type union ou intersection des domaines de clés définis dans les correspondances de publication. Ces opérations sont calculées automatiquement ou saisies par l'opérateur d'intégration, et élaborées de façon à constituer de nouveaux domaines de clé réduits visant obtenirqu'ils soient disjoints, vérifiant ainsi la règle de base de non-conflit de domaines. Cette formule de composition des domaines de clés peut en particulier être élaborée de façon récursive avec vérification ou détection intermédiaire des conflits subsistants.

Pour résoudre des conflits entre plusieurs correspondances de de publication (c.a.d. de schéma) utilisées pour définir une table cible, en particulier lorsque aucune formule de composition des domaines de clés ne suffit à les résoudre, l'invention propose en particulier d'élaborer ou de modifier dans ce sens les formules de calcul fournissant la correspondance d'attribut entre les vues de publication et la table cible.

Ces formules de calcul ont un rôle similaire à celles existant au sein des correspondances de publication, et peuvent aussi être qualifiées de règles de mapping , en l'occurrence de mapping d'intégration.

La composition des enregistrements cibles calculés par les différentes vues de publication fournit un enregistrement composite (d'intégration). A partir de cet enregistrement composite, les attributs clé de l'enregistrement cible sont directement fournis par égalité des valeurs de clés. Les attributs non-clé non conflictuels ou qui ne proviennent que d'une seule vue de publication sont fournis directement par l'enregistrement composite d'intégration.

Pour résoudre les conflits portant sur les autres attributs, l'invention propose d'enrichir les formules de calcul par une ou plusieurs règles de traitement de cas, fonctionnant de façon similaire à celles décrites plus haut.

Une fois définie, la correspondance d'intégration est vérifiée de façon similaire à la vérification d'une correspondance de publication. Sa vérification dynamique peut toutefois comprendre en outre une utilisation d'attributs cachés compris dans une vue source étendue. Dans le cas d'une correspondance d'intégration, la vue source étendue peut être obtenue en 28 - associant les vues sources étendues des correspondances de schéma concernées. Ces attributs cachés dérivent directement des différents attributs sources ayant servi au calcul des enregistrements cibles, et sont utilisés lors de la phase d'analyse pour identifier les enregistrements ou attributs sources à l'origine d'enregistrements cibles erronés.

Une fois que la correspondance d'intégration est complètement définie et vérifiée, ses informations et définitions sont mémorisées en tout ou partie dans la base de métadonnées.

Ces informations sont alors disponibles par exemple pour vérifier, modifier, améliorer ou compléter la vue d'intégration de la table cible obtenue.

Au cours du processus d'intégration, une particularité de l'invention comprend une mise en oeuvre, par un opérateur d'intégration, d'une interface graphique informatique pour visualiser au moins une vue de correspondance de publication et pour définir au moins une caractéristique d'une correspondance d'intégration utilisant ladite correspondance de publication.

Selon une autre particularité, le processus d'intégration comprend une mise en oeuvre d'une interface graphique informatique par un opérateur d'intégration pour visualiser un ou plusieurs conflits entre plusieurs correspondances de publication et pour définir au moins une règle de résolution desdits conflits.

Dans le même esprit, l'invention propose un système d'information mettant en oeuvre le procédé décrit plus haut.

Plus particulièrement, ce système comprend un poste de travail dit intégrateur utilisé pour réaliser le processus d'intégration, à partir d'informations sur des correspondances de publication fournies, à l'issue du processus de publication, par une pluralité de poste de travail dit publieurs, chacun des postes publieur étant agencé pour accéder ou gérer des informations d'administration spécifiques à une partie des sources de la base de donnée virtuelle.

D'autres particularités et avantages de l'invention ressortiront de la description détaillée d'un mode de mise en oeuvre nullement limitatif, et des dessins annexés sur lesquels: - 29 - la figure 1 illustre un exemple d'utilisation d'un système réalisant selon l'invention une base de données virtuelle la figure 2 illustre un exemple d'organisation de la réalisation selon l'invention d'une base de données virtuelle; la figure 3 illustre un exemple de déroulement de la réalisation selon l'invention d'une base de données virtuelle; les figure 4 à figure 18 illustrent un exemple de données sources et leur composition au sein d'une base de données virtuelle réalisée selon l'invention; o les figure 4, figure 5 et figure 6 représentent des enregistrements de trois tables sources o les figure 7, figure 8 et figure 9 représentent trois versions d'une première correspondance de schéma définie pour une première table source; o la figure 10 représente une instance de la table cible construite par la vue selon la première correspondance de schéma dans ses trois versions; o la figure 11 représente le résultat d'une requête de vérification dynamique d'attribut absent appliquée à la première correspondance de schéma en version 1 o la figure 12 représente une deuxième correspondance de schéma définie pour une deuxième table source; o la figure 13 représente une troisième correspondance de schéma définie pour une troisième table source; o la figure 14 représente une instance de la table cible construite par la vue selon la deuxième correspondance de schéma; o la figure 15 représente une instance de la table cible construite par la vue selon la troisième correspondance de schéma; o les figure 16a, b et c et représentent des graphes de conflits à trois stades de traitement au sein de l'intégration des trois correspondances de schéma; o les figure 17a et figure 17b représentent la correspondance d'intégration pour les deuxième et troisième correspondances de schéma, et respectivement certaines des formules de - 30 - traitements de cas utilisées par cette correspondance d'intégration; o la figure 18 représente les enregistrements fournis par l'intégration des deuxième, troisième et première correspondances de schéma.

Ainsi qu'illustré en figure 1 et figure 2, l'exemple décrit ici concerne la réalisation d'une base de données virtuelle BDV, destinée à être consultée par un ou plusieurs utilisateurs UT sur un ou plusieurs postes informatiques PUT, par exemple des Responsables Commerciaux ou des Chefs de Vente au sein d'une entreprise.

Comme illustré en figure 1, cette base de données BDV est réalisée à la demande et sur les spécifications d'un expert métier EXM, par exemple un Directeur Commercial ou Marketing. Elle est gérée par un système informatique SYST pouvant présenter différents types d'architectures, et comprend une ou plusieurs tables cibles TC et TC', définies chacune par un schéma cible STC et STC'.

Les données de ces tables cibles sont calculées au fur et à mesure des consultations, à partir de données contenues dans plusieurs systèmes informatiques communiquant avec le système SYST et constituant des sources de données S1, S2 et S3, renseignées et maintenues de façon indépendante par différents services de l'entreprise.

Dans cet exemple, la base de donnée virtuelle BDV est intitulée Cible commerciale , et la table cible TC est intitulée Clients . Cette table cible TC est produite à partir des sources suivantes: - la source S1 est accédée en tant qu'une table source TS1 nommée clientsl et est gérée par le service Ventes ; la source S2 est accédée en tant qu'une table source TS2 nommée clients2 et est gérée par le service Ventes Indirectes ; la source S3 est accédée en tant qu'une table source TS3 nommée clients3 et est gérée par le service Support Clients ; Pour la réalisation de la base de données virtuelle BDV, chaque source est enregistrée puis publiée auprès du système SYST par un opérateur publieur PU1 à PU3 en utilisant un poste informatique PP1 à PP3.

Typiquement, chacun de ces opérateurs PU1 à PU3 est une personne qui - 31 - travaille régulièrement sur la source qu'il publie, pouvant alors être qualifié de expert contenu .

Typiquement, les schémas cibles STC et STC' sont élaborés par un demandeur ou un donneur d'ordre, par exemple l'expert métier EXM, qui n'a besoin d'aucune connaissance particulière en matière de base de données ou d'informatique. Ces schémas cibles sont saisis sur un poste informatique PXM, et mémorisés dans la base de métadonnées BDM du système SYST.

Lors de la publication des sources S1 à S3 auprès du système SYST, celuici mémorise les caractéristiques de ces publications dans une base de métadonnées BDM. Pour réaliser l'intégration, les métadonnées BDM sont alors utilisées par un opérateur intégrateur IT, travaillant sur un poste informatique PIT, par exemple un prestataire de service spécialisé intervenant pour l'occasion.

La figure 2 illustre plus en détail l'obtention d'une table cible TC de schéma STC. Les sources publiées S1 à S3 peuvent contenir des données sous des formes différentes, par exemple une pluralité de feuilles de tableur D11 et D12 pour la source S1, ou une structure D2 de fichiers en arborescence pour la source S2, ou un ensemble de fichiers d'un format réalisant un système D3 de gestion de base de données.

Chacune de ces sources est d'abord enregistrée auprès du système SYST, par exemple par l'opérateur publieur correspondant ou par un administrateur connaissant bien la structure des données et du réseau de communication. Pour chacune de ces sources S1 à S3, cet enregistrement utilise un outil logiciel W1 à W3 appelé connecteur ou wrapper , qui compose et organise les données D11 à D3 des sources S1 à S3 pour qu'elles soient accessibles sous la forme de tables sources TS1 à TS3. Une même source peut être vue comme une ou plusieurs tables sources, selon la façon dont est fait son enregistrement. Ces informations d'enregistrement DE sont mémorisées dans la base de métadonnées BDM, où elles seront accessibles ultérieurement, par exemple pour la publication.

Au cours du processus de publication de chaque source S1 à S3, le publieur concerné PU1 à PU3 lit le schéma cible STC dans la base de métadonnées BDM, et l'utilise pour définir une ou plusieurs correspondances de schéma Cl à C3 pour la source qu'il publie. Ces correspondances de - 32 - schéma génèrent en particulier chacune une vue de publication VC1 à VC3, renseignant une partie du schéma cible STC. Cette vue est exprimée sous la forme d'une requête Q1 à Q3 en langage SQL.

L'ensemble DP des informations définies et calculées au cours de la 5 publication est mémorisé dans la base de métadonnées BDM.

Au cours du processus d'intégration, l'opérateur intégrateur IT lit les informations de publication DP qui l'intéresse dans la base de métadonnées BDM, et les utilise pour intégrer les différentes correspondances de schéma Cl à C3, et définir la correspondance d'intégration C123.

Cette intégration comprend en particulier la génération d'une vue source étendue VSE123, comprenant les différentes vues de publication VC1 à VC3 basées sur le schéma cible STC. Cette vue source étendue peut aussi comprendre des attributs cachés AC1 à AC3 représentant des attributs sources des différentes sources concernées S1 à S3. Ces attributs cachés correspondent à des attributs sources non demandés dans le schéma cible STC, mais utilisés pour calculer les attributs du schéma cible, et sont utilisés pour analyser les origines d'éventuels conflits entre les différentes correspondances Cl à C3.

A l'issue du processus d'intégration, la correspondance d'intégration C123 génère une vue complète, dite vue d'intégration VC123, portant sur les tables sources TS1 à TS3 et renseignant tous les attributs obligatoires du schéma cible STC. Cette vue d'intégration VC123 est exprimée sous la forme d'une requête Q123 en langage SQL.

L'ensemble DI des informations définies et calculées au cours de 25 l'intégration est mémorisé dans la base de métadonnées BDM.

La figure 3 illustre un exemple du déroulement du procédé selon l'invention, pour lequel les données traitées seront détaillées en figure 4 à figure 18.

Un fois le schéma cible STC défini lors d'une étape 30, les différentes 30 tables sources TS1 à TS3 qu'il utilise sont enregistrées 301 à 303 ainsi que précisé plus haut.

Les trois sources utilisées sont alors publiées en trois processus de publication 311 à 313 pouvant être effectués de façon similaire et indépendamment les uns des autres.

- 33 - La publication 311 de la source S1, vue comme une table source TS1, comprend une étape de définition d'une ou plusieurs correspondances de schéma, une seule Cl dans le présent exemple.

Cette correspondance Cl subit alors une étape de vérification statique 341. Cette vérification statique 341 peut être suivie d'une réitération récursive de l'étape de définition 32, par exemple pour corriger des erreurs détectées lors de la vérification statique 341.

A partir de cette correspondance de schéma Cl, optionnellement après la vérification statique 341, sont générées une vue de publication VC1 et une vue source étendue VSE1 exprimée en langage SQL par une requête Q1 portant sur la table source TS1.

Ces vues de publication VC1 et étendue VSE1 sont alors utilisées au sein d'une étape de vérification dynamique 342. Cette vérification dynamique 342 peut être suivie d'une réitération récursive de l'étape de définition 32, par exemple pour corriger des erreurs détectées lors de la vérification statique 342 ou améliorer la qualité des enregistrements cibles produits.

Une fois définies, mises au point et vérifiées, les correspondances de publication Cl à C3 sont intégrées en une étape 314 Cette intégration comprend une succession, pouvant être récursive par parties ou en totalité d'étapes, de: - détection 35 des conflits, puis - traitement systématique 36 des conflits, puis définition 37 de la correspondance d'intégration C123.

Dans l'exemple présenté, la récursivité des étapes de détection 35 et traitement systématique 36 des conflits a laissé subsisté un conflit entre les correspondances de schéma C2 et C3. L'étape de définition 37 comprend alors la définition intermédiaire d'une correspondance d'intégration C23, portant sur les correspondances de schéma C2 et C3 qui sont encore conflictuelles. L'étape de définition 37 de cette correspondance intermédiaire comprend alors la définition de règles ou formules définissant le calcul des enregistrements cible, de façon systématique en fonction du contenu des enregistrements sources, par exemple des règles de traitement de cas.

- 34 - Une fois que les correspondances de schéma C2 et C3 conflictuelles sont intégrées en une correspondance d'intégration C23 capable de traiter systématiquement tous les cas d'enregistrements sources, une correspondance d'intégration C123 complète vient intégrer la correspondance de schéma restante Cl, qui n'était pas conflictuelle.

La définition successive de la correspondance d'intégration C23 intermédiaire puis de la correspondance d'intégration C123 complète peut aussi être considérée ou prévue comme une première intégration entre C2 et C3, suivie d'une intégration incrémentale de C23 avec Cl.

Une fois définie, cette correspondance d'intégration C123 complète subit une étape de vérification statique 391. Cette vérification statique 341 peut être suivie d'une réitération récursive de l'étape de définition 32, par exemple pour corriger des erreurs détectées lors de la vérification statique 341.

A partir de cette correspondance d'intégration C123, optionnellement après la vérification statique 391, sont générées une vue d'intégration VC123 et une vue source étendues VSE123 exprimée en langage SQL par une requête Q123 portant sur les tables sources TS1, TS2 et TS3.

Ces vues d'intégration VC123 et étendue VSE123 sont alors utilisées au sein d'une étape de vérification dynamique 392. Cette vérification dynamique 392 peut être suivie d'une réitération récursive de l'étape de définition 37, par exemple pour corriger des erreurs détectées lors de la vérification statique 392 ou améliorer la qualité des enregistrements cibles produits.

Par définition et vérifications successives, il est ainsi possible d'affiner et d'optimiser la correspondance d'intégration C123 obtenue, et la vue d'intégration VC123 qui lui est associée.

Cette vue d'intégration VC123 et la requête d'intégration Q123 qui l'exprime peuvent alors être utilisées pour traiter à la demande des requêtes 300 de consultation de la table cible TC calculée.

Le présent exemple est uniquement décrit pour la table cible TC intitulée Clients , et dont le schéma cible STC est définit comme suit: (Idcli, Nom, Rue, Localité, Code_Postal, Ville) - 35 - La figure 4 représente la table source TS1 intitulée Clientsl , issue de la source S1, provenant du service Ventes . Cette table source comporte un attribut clé IdCli et contient trois enregistrements de clés valant 100 , 110 et 120 .

La figure 5 représente la table source TS2 intitulée Clients2 issue de la source S2, provenant du service Ventes Indirectes . Cette table source comporte un attribut clé IdCli et contient trois enregistrements de clés valant 1000 , 1010 et 1020 .

La figure 6 représente la table source TS3 intitulée Clients3 issue de la source S3, provenant du service Support Clients . Cette table source comporte un attribut clé IdCli et contient deux enregistrements de clés valant 1010 et 1020 .

Au cours de l'étape de publication 311 de la source S1 par un publieur PU1, une première itération de l'étape de définition 32 aboutit à une première version de la correspondance de schéma Cl, intitulée Clv1 et représentée en figure 7. Les formules de calcul sont simplement des références aux attributs sources.

La figure 8 représente une deuxième version de la correspondance de schéma Cl, définie au cours d'une deuxième itération de l'étape de définition 32. Cette deuxième version inclut une formule de traitement de cas F1 permettant de traiter les enregistrements sources incomplets de façon à fournir une valeur pour l'attribut cible Ville .

Cette formule F1 comprend, dans l'ordre indiqué, les trois règles suivantes: 1- IF clientsl.bureau distributeur <> null THEN ville=clientsl.bureau_distributeur 2- IF clientsl.localité <> null THEN ville=clientsl.localité 3- autres cas ='ville inconnue' Cette formule F1 est affectée au calcul de l'attribut cible Ville .

Elle évalue les règles énoncées dans leur ordre d'écriture jusqu'à ce que la condition énoncée soit vraie.

Cette formule est alors interprétée comme suit: Si l'attribut bureau_distributeur de la table source clientsl n'est pas vide, alors sa valeur est utilisée pour renseigner l'attribut cible ville .

- 36 - Dans le cas contraire, la règle suivante est appliquée, et est interprétée comme suit: Si l'attribut localité de la table source clientsl n'est pas vide, alors sa valeur est utilisée pour renseigner l'attribut cible ville .

Dans le cas contraire, la règle suivante est appliquée, et est interprétée comme suit: Dans touts les autres cas, un enregistrement cible est produit et la valeur de son attribut ville est la chaîne de caractère 'ville inconnue'. Autrement dit, tous les enregistrements sources fourniront un enregistrement cible, dont la valeur indiquée pour la ville sera: - le bureau distributeur s'il est renseigné, sinon la localité si elle est renseignée, - sinon la mention ville inconnue .

La figure 9 représente une troisième version de la correspondance de schéma Cl, définie par exemple au cours d'une itération de l'étape de définition 32. Cette troisième version inclut une formule de traitement de cas F2 permettant de traiter les enregistrements sources incomplets de façon à fournir une valeur pour l'attribut cible Ville . Cette formule F2 est différente de la formule F1 de la deuxième version, et a été élaborée pour que tous les enregistrements cibles produits indiquent un nom pour la ville. Cette modification peut par exemple avoir été décidée lors d'une étape de vérification dynamique 342, en cherchant à affiner la qualité des données produites pour la table cible clients TC.

Cette formule F2 comprend, dans l'ordre indiqué, les trois règles 25 suivantes: 1- IF clientsl.bureau_distributeur <> null THEN ville=clientsl.bureau_distributeur 2- IF clientsl.localité <> null THEN ville=clientsl.localité 3- IF clientsl.code_postal <> null THEN ville ='ville inconnue' Seule la troisième règle est différente de la formule F1 , et n'affecte la valeur ville inconnue que dans le cas où l'attribut code_postal de l'enregistrement source est renseigné.

Selon une particularité de ce mode de réalisation, aucun enregistrement cible n'est produit si aucune des règles n'est satisfaite.

- 37 - Lors de la définition de la troisième version de la correspondance Cl, cette formule F2 a été élaborée pour que tous les enregistrements cibles produits indiquent un nom pour la ville ou fournissent un code postal, permettant ainsi de retrouver un nom de ville. Cette modification peut par exemple avoir été décidée lors d'une étape de vérification dynamique 342, en cherchant à affiner la qualité des données produites pour la table cible clients TC.

La figure 10 représente alors les enregistrements cibles produits par la correspondance de schéma Cl, en trois groupes issus respectivement des 10 versions 1, 2 et 3 de cette correspondance Cl.

On voit que la version 1 fournit trois enregistrements cibles, dont un avec un attribut ville non renseigné (valeur nuit ).

Pour ce même enregistrement, la version 2 permet que cet attribut ville soit intitulé ville inconnue , par exemple pour la lisibilité des données ou pour la compatibilité avec un logiciel recevant ces données.

La version 3 ne produit pas cet enregistrement, puisque son enregistrement source d'origine ne comporte pas non plus de valeur pour le champ code_postal . Ainsi, seuls les clients pouvant être situés géographiquement sont listés par la table cible produite.

La figure 11 représente le résultat d'une opération de test au cours de l'étape de vérification dynamique 342 de la correspondance de schéma Cl version 1. Ce test est définit de façon à lister tous les enregistrements cibles pour lesquels l'attribut ville n'est pas renseigné (valeur nuit ), et utilise la requête SQL suivante: SELECT * FROM Clients WHERE Clients.Ville is Null Cette liste d'enregistrements erronés du point de vue de la ville permet de voir que certains comportent pourtant une valeur pour l'attribut code_postal qui pourrait permettre une localisation géographique du client concerné. Le fait de pouvoir étudier cette liste peut par exemple permettre de définir la formule F2 de la version 3 de la correspondance Cl, qui prend en compte la présence d'une valeur pour le code postal.

Les figure 12 et figure 13 représentent une correspondance de schéma respectivement C2 et C3, définies au cours de l'étape de publication - 38 - respectivement 312 de la source S2 et 313 de la source S3. Les formules de calcul sont simplement des références aux attributs sources.

Les figure 14 et figure 15 représentent alors les enregistrements cibles produits par les correspondances de schéma respectivement C2 et C3.

Au cours du processus d'intégration 314 des correspondances de schéma Cl, C2 et C3, une itération de l'étape 35 de détection des conflits a identifié une possibilité de conflit entre les trois correspondances Cl, C2 et C3 prises deux à deux.

La figure 16a représente ces conflits par des lignes ou arêtes reliant deux à deux trois points qui représentent ces trois mêmes correspondances Cl, C2 et C3.

Au cours d'une itération suivante de l'étape 36 de traitement des conflits, l'opérateur d'intégration saisit interactivement une assertion sémantique venant réduire le domaine des clés des tables sources TS1 et TS2, basée par exemple sur des contraintes des schémas de TS1 et TS2 ou découlant de certaines conditions d'enrichissement de ces mêmes tables sources. Cette assertion sémantique consiste à indiquer que: toutes les clés de TS1 sont inférieures à la valeur 1000 , et que: - toutes les clés de TS2 sont supérieures ou égales à valeur 1000 .

Les domaines des clés des correspondances Cl et C2 sont donc maintenant disjoints, et il est établi que celles-ci ne sont plus conflictuelles entre elles, ainsi qu'illustré en figure 16b.

Au cours d'une nouvelle itération suivante de l'étape 36 de traitement des conflits, l'opérateur d'intégration saisit interactivement une nouvelle assertion sémantique venant réduire le domaine des clés de la table source TS3, en indiquant que toutes les clés de cette table source ont une valeur supérieure ou égale à 1000 .

Les domaines des clés des correspondances Cl et C3 sont donc maintenant eux aussi disjoints, établissant que celles-ci ne sont plus conflictuelles entre elles. Ainsi qu'illustré en figure 16c, seules sont encore conflictuelles entre elles les correspondances C2 et C3.

Ces deux correspondances conflictuelles font l'objet d'une intégration qualifiée plus haut d'intermédiaire, fournissant une correspondance d'intégration C23 représentée en figure 17.

La partie gauche de la figure représente un enregistrement composite réalisé à partir des enregistrements de C2 et C3 reliés par égalité des clés Idcli dans les deux tables sources TS2 et TS3. Cet enregistrement composite est utilisé comme vue de base pour élaborer la correspondance C23, et peut être utilisé comme vue source étendue de cette même correspondance d'intégration C23.

Dans la table cible produite par cette correspondance C23, l'attribut clé est produit par référence directe à l'attribut clé Idcli des tables sources TS2 et TS3. Les autres attributs cibles sont calculés par différentes formules.

L'attribut Nom est calculé par la formule F3 constituée des règles suivantes: IF nom C2=nom C3 THEN nom=nom_C2 IF nom_C2=null THEN nom=nom_C3 IF nom C3=null THEN nom=nom C2 Ainsi, lorsque les noms fournis par C2 et C3 sont identiques, leur valeur renseigne l'enregistrement cible. Lorsque l'un des noms sources est vide, à commencer par C2, la valeur de l'autre nom fourni est utilisée. Dans tous les autres cas, en particulier lorsque les deux noms diffèrent ou qu'aucun nom n'est fourni, aucun enregistrement cible n'est fourni.

L'attribut Villes est fourni par la formule F4 constituée des règles suivantes: IF ville C2=ville C3 THEN ville=ville_C2 IF ville_C2=bull THEN ville=ville_C3 IF ville_C3=bull THEN ville=ville_C2 IF ville C2<>ville C3 AND date intervention C3>date entrée C2 then ville=ville_C3 L'attribut ville est ainsi calculé de manière similaire à l'attribut nom , en ajoutant le cas où les deux villes sont différentes et que la date d'intervention du service Support Client (C3 sur la table TS3) est postérieure à la date d'entrée fournie par le service Ventes Indirectes - 40 - (C2 sur la table TS2). Dans ce cas, la quatrième règle de la formule F4 considère que l'adresse peut avoir changé et qu'il convient de considérer la dernière des deux, c'est à direl'adresse d'intervention issue de C3.

L'attribut Rue est fourni par la formule F5 constituée des règles suivantes: IF rue C2= rue_C3 THEN rue=rue_C2 IF ville_C2<> ville_C3 AND date intervention C3>date entrée C2 THEN rue = rue_C3 autres cas = 'rue inconnue' L'attribut cible localité est fourni par la formule F6 constituée selon les mêmes principes à partir des attributs de la vue source étendue VSE23 fournis par les correspondances C2 et C3.

L'attribut cible code-postal est fourni par la formule F7 constituée des règles suivantes: IF code_postal_C2=code_postal_C3 THEN code_postal=code_postal.C2 IF code_postal_C2 IS null AND ville C2=ville_C3 THEN code_postal=code_postal_C3 IF code_postal_C3 IS null AND ville_C2 = ville_C3 THEN code_postal=code_postal_C2 IF code_postal_C2 <> code_postal_C3 AND ville_C2<>ville_C3 AND date intervention C3>date entrée C2 THEN code_postal=code_postal_C3 autre cas code postal = 'code postal inconnu' L'attribut cible localité est fourni par la formule F6 constituée 25 selon les mêmes principes à partir des attributs de la vue source étendue VSE23 fournis par les correspondances C2 et C3.

Les enregistrements cibles produits par cette correspondance C23 sont alors représentés dans la partie haute de la figure 18. On voit que les trois clients enregistrés par le service Ventes Indirectes sont bien listés, mais que l'adresse du client dont la clé Idcli a la valeur 1020 a été mise à jour lors de l'intégration, à partir de l'adresse d'intervention fournie par le service Support Clients .

Les enregistrements produits par la correspondance Cl sont représentés dans la partie basse de cette même figure 18. Du fait que les - 41 attributs clés de ces enregistrements sont dans des domaines différents, il ne peut y voir de conflit, ce qui peut représenter le fait que les services Ventes et Ventes Indirectes ont des clients différents, ou du moins qui sont saisis avec des codes différents.

La table cible TC produite par la correspondance d'intégration C123 utilisant les trois tables sources TS1 à TS3 est donc simplement constituée d'une réunion des enregistrements cibles fournis par la correspondance Cl et par la correspondance C23.

La figure 18 dans son ensemble représente donc les enregistrements de cette table cible TC produite par la correspondance d'intégration C123, qui peut elle-même être considérée comme une intégration incrémentale de Cl ajoutée à C23.

Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention.

- 42 -

Claims (36)

REVENDICATIONS

1. Procédé pour réaliser une base de données virtuelle comprenant au moins une table relationnelle, dite table cible, à partir de données contenues dans une pluralité de sources hétérogènes, lesdites données étant vues comme un ensemble de tables sources relationnelles, le procédé comprenant: - pour au moins une desdites sources, un processus, dit de publication, comprenant la mémorisation de données calculées ou sélectionnées représentant au moins un ensemble de règles, appelé correspondance de publication, définissant des relations entre au moins une table source de cette source et ladite table cible; un processus, dit d'intégration, comprenant un traitement desdites données de façon à produire des données représentant un ensemble de règles, appelé correspondance d'intégration, définissant des relations entre ladite table cible et un ensemble desdites correspondances de publication.

2. Procédé selon la revendication 1, caractérisé en ce que le processus d'intégration comprend, en outre, une étape de détection d'au moins un conflit éventuel entre plusieurs correspondances de publication, suivie d'une étape de traitement dudit conflit.

3. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend en outre une vérification d'au moins une correspondance de publication ou d'intégration.

4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend en outre, pour au moins une correspondance de publication, une génération d'une vue, dite de publication, comprenant une requête portant sur toutes les tables sources utilisées par ladite correspondance de publication.

- 43 -

5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend une génération d'une vue, dite symétrique, comprenant un couple de requêtes portant, d'une part sur les tables sources d'une correspondance de publication, et d'autre part sur la table cible.

6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le processus d'intégration comprend au moins une génération d'une vue, dite d'intégration, comprenant au moins une requête portant sur tout ou partie des tables sources utilisées par les correspondances de publication intégrées.

7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'une correspondance de publication est modifiée de manière incrémentale en prenant en compte au moins une nouvelle table source.

8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'une correspondance d'intégration est modifiée de manière incrémentale en prenant en compte au moins une nouvelle correspondance de publication.

9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'au moins une correspondance de publication utilise au moins une correspondance d'attribut dans laquelle au moins un attribut de la table cible dépend d'au moins une fonction ou d'au moins une formule de calcul, portant sur au moins un attribut d'au moins une table source.

10. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'au moins une correspondance de publication utilise au 30 moins un lien de composition exprimé entre au moins deux tables sources.

11. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'au moins une correspondance de publication utilise au - 44 - moins un filtre exprimé sur au moins un attribut d'au moins une table source.

12. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'au moins une correspondance de publication utilise au moins un filtre exprimé sur au moins un attribut de la table cible.

13. Procédé selon l'une quelconque des revendications 3 à 12, caractérisé en ce que la vérification d'au moins une correspondance comprend une vérification, dite statique, de la validité de ladite correspondance au regard d'au moins une règle syntaxique ou portant sur la structure des données traitées par ladite correspondance.

14. Procédé selon l'une quelconque des revendications 3 à 14, caractérisé en ce que la vérification d'au moins une correspondance de publication comprend une vérification, dite dynamique, portant sur la qualité des données contenues dans au moins un enregistrement cible fourni par ladite correspondance de publication.

15. Procédé selon l'une quelconque des revendications 9 à 14, caractérisé en ce qu'au moins une correspondance d'attribut fournit une valeur constante.

16. Procédé selon l'une quelconque des revendications 9 à 15, caractérisé 25 en ce qu'au moins une correspondance d'attribut comprend une référence à au moins un nom d'attribut d'une table source.

17. Procédé selon l'une quelconque des revendications 9 à 16, caractérisé en ce qu'au moins une correspondance d'attribut comprend au moins une opération binaire arithmétique.

18. Procédé selon l'une quelconque des revendications 9 à 17, caractérisé en ce qu'au moins une correspondance d'attribut utilise au moins une de règle de traitement de cas.

19. Procédé selon la revendication précédente, caractérisé en ce qu'il utilise une pluralité de règles de traitement de cas exécutées dans un ordre déterminé.

20. Procédé selon l'une quelconque des revendications 10 à 19, caractérisé en ce qu'au moins un lien de composition entre une première et une deuxième table source utilise un critère d'équivalence ou d'égalité entre la valeur d'au moins un attribut d'au moins un enregistrement de la première table source et la valeur d'au moins un attribut d'au moins un enregistrement de la deuxième table source.

21. Procédé selon l'une quelconque des revendications 11 à 20, caractérisé en ce qu'au moins un filtre comprend une expression 15 conditionnelle.

22. Procédé selon l'une quelconque des revendications 11 à 21, caractérisé en ce qu'au moins un filtre comprend une opération booléenne.

23. Procédé selon l'une quelconque des revendications 11 à 22, caractérisé en ce qu'au moins un filtre comprend une expression d'encadrement.

24. Procédé selon l'une quelconque des revendications 11 à 23, caractérisé en ce qu'au moins un filtre comprend une combinaison de conjonctions ou de disjonctions d'opérations booléennes et/ou d'expressions d'encadrement.

25. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la correspondance d'intégration comprend au moins une correspondance d'attribut dans laquelle au moins un attribut de la table cible dépend d'au moins une fonction d'au moins un attribut fourni par une correspondance de publication.

- 46 -

26. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la table cible comprend au moins un attribut composant une clé pour ladite table cible ou une clé étrangère pour une autre table cible.

27. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'au moins une table source comprend au moins un attribut composant une clé pour ladite table source ou une clé étrangère pour une autre table source.

28. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la correspondance d'intégration utilise au moins un lien de composition exprimé entre au moins deux correspondances de publication et utilisant une égalité des clés au sein de la table cible.

29. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la table cible comprend en outre au moins un attribut obligatoire.

30. Procédé selon l'une quelconque des revendications 26 à 29, caractérisé en ce qu'il comprend une détection de conflits dits de domaines entre deux correspondances de publication portant sur au moins un même attribut clé de la table cible, cette détection de conflits de domaines comprenant au moins une opération de comparaison portant sur des domaines de valeurs accessibles par ledit attribut clé au sein desdites correspondances,.

31. Procédé selon l'une quelconque des revendications 2 à 30, caractérisé en ce qu'il comprend une détection de conflits dits d'attribut entre plusieurs correspondances de publication portant sur un même attribut, dit commun, au sein de la table cible, cette détection de conflits d'attribut comprenant une opération de test portant sur la façon dont chacune desdites correspondances fournit une valeur pour ledit attribut, pour vérifier si lesdites correspondances sont susceptibles ou non de fournir pour ledit - 47 - attribut commun des valeurs ne présentant pas entre elles une fonction invariable.

32. Procédé selon l'une quelconque des revendications 26 à 31, caractérisé en ce que le traitement d'un conflit entre plusieurs correspondances de publication comprend une définition d'au moins une formule de composition des domaines d'au moins une clé commune auxdites correspondances, obtenue par une ou plusieurs opérations de type ensembliste portant sur les domaines de valeurs de ladite clé au sein desdites correspondances.

33. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le processus d'intégration comprend une mise en oeuvre, par un opérateur, d'une interface graphique informatique pour visualiser au moins une vue de correspondance de publication et pour définir au moins une caractéristique d'une correspondance d'intégration utilisant ladite correspondance de publication.

34. Procédé selon l'une quelconque des revendications 2 à 33, caractérisé en ce que le processus d'intégration comprend une mise en oeuvre d'une interface graphique informatique par un opérateur pour visualiser un ou plusieurs conflits entre plusieurs correspondances de publication et pour définir au moins une règle de résolution desdits conflits.

35. Système d'information mettant en oeuvre le procédé selon l'une des revendications précédentes.

36. Système selon la revendication précédente, caractérisé en ce qu'il comprend un poste de travail dit intégrateur utilisé pour réaliser le processus d'intégration, à partir d'informations sur des correspondances de publication fournies, à l'issue du processus de publication, par une pluralité de poste de travail dit publieurs, chacun des postes publieur étant agencé pour accéder ou gérer des informations d'administration spécifiques à une partie des sources de la base de donnée virtuelle.