Ces derni`eres ann´ees ont vu un int´erˆet croissant pour l’utilisation des services web comme un support fiable pour l’´edition et le partage des donn´ees entre les organisations. Les entreprises modernes sont orient´ees vers une architecture orient´ee services pour le
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <application xmlns="http://wadl.dev.java.net/2009/02"> <doc xmlns:jersey="http://jersey.java.net/"
jersey:generatedBy="Jersey: 2.0-SNAPSHOT ${buildNumber}"/> <grammars/>
<resources base="http://localhost:9998/"> <resource path="country/15">
<method name="GET" id="getCountry"> <response>
<representation mediaType="application/xml"/> </response>
</method>
<method name="OPTIONS" id="apply"> <request> <representation mediaType="*/*"/> </request> <response> <representation mediaType="application/vnd.sun.wadl+xml"/> </response> </method> </resource> </resources> </application>
Figure 2.2 – Un exemple d’un fichier WADL
partage des donn´ees sur le web, tout en acc´edant `a leurs sources de donn´ees via des services web, ce qui fournit une m´ethode bien document´ee, et interop´erable pour l’interaction avec les diff´erentes sources donn´ees h´et´erog`enes. Ces services sont appel´es les services web d’acc`es aux donn´ees, ou services DaaS (Data-as-a-Service).
Ces services DaaS sont un type particulier des services cloud con¸cus pour la gestion des donn´ees dans les environnements cloud computing. Actuellement, Le cloud computing est la technologie la plus favorable par les entreprises et les organisations notamment celles qui ont un budget informatique tr`es r´eduit, afin de bˆatir une infrastructure physique puissante (traitement, stockage, etc), scalable, auto-reconfigurable et sans avoir besoin d’un investissement initiale. Une plateforme cloud computing peut ˆetre consid´er´ee comme ´etant un ensemble de services regroup´es en quatre couches : IaaS (Infrastructure-as-a-Service), PaaS (Platform-as-a-Service), DaaS (Data-as-a-Service), et SaaS (Sfotware-as-a-Service).
Architecture des services DaaS
La figure 2.3 pr´esente l’architecture des services DaaS [18]. Cette architecture est constitu´ee de trois couches : la couche Donn´ees, la couche Service, et la couche Mapping.
La couche Donn´ees implique toute source de donn´ee qui peut ˆetre acc´ed´ee par un service DaaS, telle que : les bases de donn´ees, les applications orient´ees donn´ees (e.g., CRM, ERP, etc.), d’autres services, etc. Ces sources de donn´ees sont d´ecrites par diff´erents mod`eles de repr´esentation (e.g., Relationnel, XML, HTML, CSV, WSDL, WADL, etc.), et interrog´ees via diff´erents langages et protocoles (e.g., SQL, XPath/XQuery, SOAP, etc.).
Données WS_SOAP WS_REST Service DaaS Base de données RDF\RDFs XML Mapping Mappings déclaratifs Mappings procédurales Fonctions Requêtes Modèle externe CRM/ERP Opérations Données Dans XML/JSON/HTML Données ou Requêtes
Figure 2.3 – Architecture des services DaaS
La couche Service constitue une interface uniforme qui permet aux utilisateurs d’acc´eder aux diff´erentes sources de donn´ees, sans avoir besoins des connaissances li´ees `a l’impl´ementation, et la localisation de celles-ci. Cette couche d´ecrit l’ensemble des op´erations `a travers les-quelles un service DaaS est utilis´e par ses clients. Nous d´efinissons deux types d’op´erations, les op´erations de type fonction, et les op´erations de type requˆete. Les op´erations de type fonction sont similaires aux op´erations d’un service web classique, dans lesquelles les uti-lisateurs sont compl`etement li´es `a la signature de l’op´eration, et `a ce qui est retourn´ee par cette derni`ere. En revanche, les op´erations de type requˆete permettent aux utilisateurs de poser leurs propres requˆetes, et d’interroger les sources de donn´ees de la fa¸con qu’ils
d´esirent. Ces op´erations prennent en param`etre une requˆete utilisateur d´ecrite dans un lan-gage de requˆete classique `a savoir : SQL, XPath/XQuery, ou via un langage propri´etaire, tel que : SOQL de Salesforce.com7, ODate de Microsoft8, etc. Les donn´ees retourn´ees par un service DaaS peuvent ˆetre d´ecrites par plusieurs formats (e.g., HTML, JSON, XML, etc).
Les op´erations d’un service DaaS et les requˆetes utilisateurs (dans le cas des op´erations de type requˆete) sont d´efinies et formul´ees `a travers le mod`ele de service (i.e., sch´ema de service) appel´e : mod`ele externe. Le mod`ele externe est un mod`ele commun qui d´ecrit de fa¸con uniforme et globale les sources de donn´ees encapsul´ees par un service DaaS. Il peut ˆ
etre compar´e au sch´ema global dans un syst`eme d’int´egration de donn´ees classique (e.g., approche m´ediatrice, approche f´ed´eratrice, etc). Le mod`ele externe est d´efini lors de la construction de service en se basant sur les sch´emas des sources encapsul´ees. Il peut ˆetre cr´e´e automatiquement en utilisant un outil con¸cu pour la cr´eation des services DaaS (e.g., Oracle Data Service Integrator9). Le mod`ele externe est fourni aux utilisateurs de service en utilisant des fonctions sp´ecifiques qui retournent sa description (sous forme d’un script SQL LDD, ou via un fichier XML).
Les correspondances entre les mod`eles des donn´ees encapsul´ees et le mod`ele externe du service DaaS sont d´ecrites dans la couche Mapping. Le mapping associci´e `a une source de donn´ees d´efinit comment le service l’acc`ede. Il existe de types de mappings, les mappings d´eclaratifs, et les mappings proc´edurales. Les mappings d´eclaratifs sont souvent similaires aux vues d’une base de donn´ees relationnelle. Ils sont utilis´es pour d´efinir les mappings des sources de donn´ees dont le langage d’interrogation est d´eclaratif (e.g., SQL pour le
rela-tionnel, XQuery pour XML, SPARQL pour RDF/RDFs, etc). Les mappings proc´edurales
sont utilis´es pour les donn´ees qui sont fournies par des applications (e.g., CRM, ERP, etc), ou par des services DaaS.
Notons qu’un service DaaS peut effectuer diff´erentes op´erations (e.g., Interrogation, Suppression, Insertion, etc) sur les donn´ees qu’il les encapsule. Dans notre travail, nous nous int´eressons aux services DaaS qui acc`edent aux sources de donn´ees uniquement en mode lecture (Interrogation), ce que nous entendons par les services sans-´etat (stateless).
7. Salesforce.com, Inc. Salesforce.com Object Query Language (SOQL), 2010. 8. OData. Open Data Protocol, 2010. http ://www.odata.org/.
9. http ://www.oracle.com/technetwork/middleware/data-service-integrator/
2 Base de donn´ees probabiliste
Au cours des derni`eres ann´ees, la gestion des donn´ees incertaines a re¸cu une attention croissante surtout avec l’´emergence de plusieurs nouvelles applications `a savoir : les sensors (capteurs) [97], les r´eseaux RFID [57, 118], les syst`emes de nettoyage et d’extraction des donn´ees, etc. L’incertitude est inh´erente `a ces applications, ce qui m`ene `a une exigence extrˆeme pour la gestion des donn´ees incertaines.
Plusieurs approches ont ´et´e propos´ees pour mod´eliser les donn´ees incertaines (i.e., le degr´e de certitude ou de confiance) `a savoir, les approches `a base de logique floue [12,17], les approches bas´ees sur la th´eorie de Dempster-shafer [21], et les approches probabilistes [11, 24, 26, 36, 97], ou ce que nous entendons par les bases de donn´ees probabilistes. Cependant, la plupart des applications qui produisent des donn´ees incertaines quantifient ces derni`eres dans des bases de donn´ees probabilistes. Par exemple, les syst`emes d’extraction de donn´ees sont bas´es sur des mod`eles probabilistes, i.e. ; les donn´ees qu’ils extraient sont probabilistes [48,66] ; Le nettoyage des flux RFID produisent ´egalement des distributions de probabilit´es [98] ; L’analyse de donn´ees dans la pr´evision financi`ere reposent sur des mod`eles statistiques qui g´en`erent souvent des donn´ees probabilistes [56] ; etc.