thème: web et bases de données

Thème: web et bases de données

ECHANGE D’OBJETS A TRAVERS DES SOURCES

D’INFORMATION HETEROGENE

titre: Object Exchange Across Heterogeneous Information Source de Yannis Papakonstantinou, H. Garcia-Molina, J.

Widomdepartement of computer science Stanford university

Le problème est de fournir un accès à des sources d’informations diverses et variées:

INTRODUCTION

CLIENT

les bd normalisées sql les entrepôts d’objets

les bases de connaissancesles systèmes de fichiers

les systèmes de récupération de documents

des informationsnon enregistrées (on-line) pour faire des requêtes

Description de l’intégration d ’informations hétérogènes par rapport à l'intégration des bases de données conventionnelles

données non-structurées ou structurées, sans schéma régulier pour décrire les données

environnement est dynamique accès et intégration de l'information entrelacés. intégration exigeant une participation plus humaine.

Objectif

Fournir : une structure et des outils d'aide aux humains

Il y a trois catégories d ’outils:

1- TraducteurÉchange de l'information: Avec un format

d'échange convenu, il faut des outils pour traduire

SOURCEINFORMATION

Requête transmise dans le langage de requête de la source d’information

Résultat de la source d’information

CLIENT

TRADUCTEUR

Requête en langage de requête commun

Résultat transmis dans le format commun de l’information

Une fois qu’un format d'échange est convenu, il faut des outils pour traduire entre un émetteur d'informations et le format d'échange.

Les utilisateurs voudront explorer l’information disponible pour:

découvrir des sources, browser (feuilleter) des objets, et étudier la sémantique des objets et leurs

composants.

Les outils (browser) permettent aux humains (et finalement aux logiciels) :

de faire des requêtes pour des sources d'intérêt, de demander des objets à ces sources, de naviguer par/au travers des objets (explorant leurs

composants), et de poser des questions sur la signification des

objets et de leurs composants.

2- Découverte de l'information : browser

3. Médiateurs. Un médiateur est un programme qui rassemble

l'information d'une ou plusieurs sources, et la combine, et exporte l'information résultante.

3. Médiateurs.

médiateur

Rapport annuel des actionnaires d ’IBM sur la vente

Rapport annuel des actionnaires d ’IBMsur la conception

Rapport annuel des actionnaires d ’IBMsur l ’assemblage

Extraction des chiffres clés

Table des résultas annuels

Rapport du cours des actions

médiateur

Analyse des tendances pour

IBMCombinaison des deux sources

SOMMAIRE

Définition d’un modèle d’échange de l’information basé sur l ’objet: OEM

Définition d’un langage d’interrogation correspondant au modèle

Comment le modèle et le langage ont été employés pour intégrer des sources d’informations hétérogènes.

Description des deux bibliothèques polyvalentes mises en place pour échanger des objets entre clients et serveurs.

SOMMAIRE

Définition d’un modèle d’échange de l’information basé sur l ’objet OEM

Définition d’un langage d’interrogation correspondant approprié à l’intégration des sources d’informations diverses



Modèle d‘Echange d‘Objet:OEM

L’OEM est bien approprié à l'échange de l'information dans les environnements hétérogènes et dynamiques.

L'OEM est assez flexible pour inclurent tous les types d'information, et il est assez simple de faciliter l'intégration;

L'OEM inclut des informations sémantiques sur des objets.

L’idée fondamentale de l’OEM

Les valeurs échangées sont indiquée par un label (ou un tag) qui décrit sa signification.

L’objet se décrit lui-même: idée de self-describing Exemple:Echange de la valeur de la température 80 degrés de

Fahrenheit:temperature_in_Fahrenheit, integer 80 la ch. de car. « temp. in Fahrenheit » est lisible par un

humain, « integer » indique le type de la valeur, et 80 est la valeur elle-même.

label type value object-id

Le labelLe label joue deux rôles: identifier un objet, et identifier la signification d'un objet .Le label est relatif à la source qui l’exporte.C’est le client qui est le médiateur et nomme

différemment les objets si le sens pour la source est différent.

Exemple: le label person-name signifie nom du personnel pour une source A et nom du personnel et dirigeants pour une source B.

Alors le client renomme.

OID Chaine de longueur variable qui identifie de

manière unique l ’objet Chez le client, les ensembles et les listes

contiennent des éléments de deux formes. Un tag interne indique la forme de chaque élément.

référence locale d'objet OID à distance

Différences OEM et modèle de données OO

l'OEM est un modèle d'échange d’'informations hétérogènes. L'OEM n'indique pas comment les objets sont stockés à la

source. L'OEM indique comment les objets sont reçus par un client,

mais après réception le client les stocke de la façon qu ’il veut.

L ’OEM est beaucoup plus simple.Un modèle simple mais puissant car: les dispositifs avancés peuvent être ''émulé" quand ils sont

nécessaires.


(personne, set, {o1,o2,o3,o4,o5,o6,o7}) o1 is location of(nom, string, ” DUPOND" )o2 is location of(prenom, string, " Julie")o3 is location of(photo, bitmap, "ph1")o4 is location of(nom_pere, string, " DUPOND")o5 is location of(nom_mere, string, " MOULIN")o6 is location of(prenom_pere, string,"Georges")o7 is location of(prenom_mere, string, "Aline")

incorporation des parents dans les subobjects de l’objet

OID de l’objet: l'id0 (personne), l'id1 (nom), l'id2 (prenom), l'id3 (photo)...

Personne

Nom Prenom…

a pour parent

Modèle OO OEM

La nature flexible de l'OEM peut nous permettre de modéliser les dispositifs complexes d'une source d'une manière simple.


Une différence distincte finale est l'utilisation des labels au lieu d'un schéma.

Dans les modèles traditionnels de données, un client doit se rendre compte du schéma afin de poser une question. Dans le modèle OEM, un client peut découvrir la structure d'information.

SOMMAIRE

Définition d’un modèle d’échange de l’information object-based OEM




le langage d'interrogation (query language): OEMQL

Pour demander des objets OEM d'un émetteur d'informations, un client émet des requêtes en OEMQL.

La construction de base dans OEMQL est une expression de SQLlike SELECT-FROM-WHERE. La syntaxe est:

SELECT FetchExpression FROM objectWHERE Condition

le résultat de cette requête est un objet, avec un label spécial answer:(answer, se, {obj1, obj2,…,objn})obj i est un composant de object indiqué dans la clause FROM, où le

composant est placé près du FetchExpression et satisfait la condition.

le langage d'interrogation (query language)

Query language syntax: Query ::= SELECT FetchExp FROM Object WHERE Condition FetchExp ::= Path | Path.OID Path ::= Label | Label.Path Label ::= string [ (variable) ] | ? [ (variable) ] | * [ (variable) ] Object ::= string /*lexical object identifier */ Condition ::= true | Path | predicate(Value 1 , Value 2 , : : : , Value n )

| Condition1 and Condition 2 Value ::= Path | constant

Exemple: (bibliography, set, {doc 1 , doc 2 , … , doc n }) doc 1 is (document, set, {authors1 , topic1 , callnumber1 })

authors1 is (authorset, set, {author11}) author11 is (authorlastname, string, `Ùllman”)

topic1 is (topic, string, ``Databases'') callnumber1 is (internalcallno, integer, 25)

doc2 is (document, set, {authors 2 , topic 2, callnumber 2}) authors2 is (authorset,set,{author12, author22 ,author32 })

author12 is (authorlastname, string, `Àho'') author22 is (authorlastname, string, ``Hopcroft'') author32 is (authorlastname, string, `Ùllman”) topic2 is (topic, string, `Àlgorithms'')

callnumber2 is (deweydecimal, string,”BR273”) . . . doc n is (document, set, {authors n , topic n , callnumber n })

authors n is (singleauthorfullname, string, ``Michael Crichton”) topic n is (topic, string, ``Dinosaurs'') callnumber n is (fictioncallno, integer, 95)


L'exemple 1: Recherche la matière de chaque document pour laquelle ''Ullman`` est un des auteurs:

SELECT bibliography.document.topic FROM root WHERE bibliography.document.authorset.authorlastname=“Ullman”

(root: racine)

Voici le résultat de la requête:(answer, set, {obj 1, obj 2})

obj 1 is (topic, string, ``Databases'') obj 2 is (topic, string, ``Algorithms'')


l'exemple 2: utilisation d'une clause WHERE existentiel. Cette requete recherche les matières de tous les documents avec des numéros d'appel internes.

SELECT bibliography.?.topic FROM root WHERE bibliography.?.internalcallno Le label "?'' matche avec n'importe quelle label. il n'y a aucun opérateur de comparaison dans la clause Where

de cette requête, juste un chemin.

Réponse:(answer, set, {obj 1})

obj 1 is (topic, string, ``Databases'')


l'exemple 3,3 dans l'exemple 3,2, le symbole de wildcard ? a été employé pour matcher n'importe quelle label. Il est également permis d ’utiliser des “ wildpaths ” indiqué par le symbole ``*``.

Employant le "*", la requete dans l'exemple précédent serait exprimé comme:

SELECT *.topic FROM root WHERE *.internalcallno

Le symbole ``*`` matches n'importe quel chemin de longueur un ou plusieurs.


l'exemple 3,4 variables employées pour indiquer différents chemins avec le même ordre de labels.

Cette requête recherche chaque document pour lequel le ''Aho`` et le ''Hopcroft`` sont des auteurs: SELECT bibliography.document FROM root WHERE bibliography.document.authorset.authorlastname(a1) =“Aho” AND bibliography.document.authorset.authorlastname(a2)=“Hopcroft” réponse:(answer, set, {obj}) obj is (document, set, {authors2 , topic2 , callnumber2 })

authors2 is (authorset,set,{author 12,author 2 2 ,author 3 2 }) author 12 is (authorlastname, string, `Àho'') author 22 is (authorlastname, string, ``Hopcroft'') author 32 is (authorlastname, string, `Ùllman'')

topic 2 is (topic, string, `Àlgorithms'') callno 2 is (deweydecimal, string, ``BR273'')


Cette requete recherche l'OID pour tous les documents avec un numéro d'appel deweydecimal :

SELECT *.OID FROM root WHERE *.deweydecimal

réponse:(oid de la source)(answer, set, {id 1 }) où id1 est l'Oid pour l'objet désigné sous le nom du Doc 2.


L'exemple 3,6 OEMQL permet à n'importe quel prédicat d'être employé dans la condition de la clause WHERE.

Les prédicats, qui peuvent être évalués pour un émetteur d'informations donné, dépendent du traducteur et de la source.

Si l ’émetteur d'informations bibliographique soutient le prédicat:auteur(document, nom_auteur ) vrai si au moins un auteur avec le nom donnéAlors la requête dans l'exemple 3,4 pourrait être écrite comme:

SELECT bibliography.document FROM root WHERE author(bibliography.document, ''Aho'') and author(bibliography.document, ''Hopcroft'')

émetteur d'informations bibliographique appelé Folio

TRADUCTEUR

prédicats

Construit en langage C

Requête oemql

requête dans le langage de récupération booléenne du folio

Évaluation du prédicat

information

réponse

Schéma: traducteur et prédicat


Une prolongation utile pour OEMQL:

la capacité d'exprimer des requêtes au sujet des labels et de la structure d'objet pour permettre d’ `` apprendre'' au sujet des objets exportés par un émetteur d'informations avant que des requêtes significatives puissent être posées.

SOMMAIRE





Mise en œuvre des traducteurs, des browsers, et des médiateurs

Architecture générale: Le browser hétérogène de l'information Traducteurs et médiateurs

browser

SOMMAIRE





5 les bibliothèques d ’OEM Fournissent les fonctionnalités communes

requises pour l’échange d'objet et de requête. Il y a deux composants principaux: la bibliothèque du client (CSL) et la bibliothèque du serveur (SSL) pour le translateur/médiateur.

Conclusions

Cette étude fournit une solution pour intégrer des données hétérogènes: avec le modèle d’échange d ’objet: OEM un langage d ’interrogation OEMql

thème: web et bases de données

Documents