Les mécanismes d’interrogation classiques

Le système LiveFile a été conçu pour répondre aux contraintes des RCSF et des besoins généralement rencontrés au niveau des applications. Le premier objectif a été de réduire la taille des données à la fois pour le stockage et la transmission des données.

Différentes solutions ont été proposées dans les parties précédentes. Le deuxième objectif est la récupération des données et leur transmission soit vers un autre capteur soit vers une station centrale de collecte. Cette fonctionnalité appartient plutôt aux applications d’acquisition de données stockant les différents relevés sous le format de type « RECORD ».

Le système LiveFile a donc été muni d’un moteur d’interrogation pour accéder aux données recherchées. Comme pour les systèmes présentés au paragraphe 3.4.1, la sémantique d’interrogation employée est inspirée de celle du modèle relationnel et du langage SQL associé. De nombreux concepts sont définis au sein du modèle relationnel :

• les relations et les attributs ;

• les clés primaires avec les dépendances fonctionnelles et les différentes formes normales associées ;

• les clés étrangères et les dépendances d’inclusion.

Les relations et les attributs ont déjà été mentionnés pour introduire les métadonnées contextuelles. La plupart des applications d’acquisition s’intéressent à une seule grandeur qui aboutit généralement à l’utilisation d’une unique table ou relation. Les données sont stockées sous forme soit brutes soit d’enregistrements avec utilisation ou non des métadonnées contextuelles. Cette relation, si elle est unique, a le même nom que l’identifiant du capteur qui l’héberge. La clé primaire la plus souvent utilisée est le numéro de l’acquisition ou de l’enregistrement. Celle-ci n’est pas obligatoire sachant que les interrogations ou requêtes portent généralement sur les caractéristiques des données collectées. L’utilisation d’une seule table réduit la possibilité d’employer les autres concepts énoncés. Cependant, une dépendance d’inclusion voire une contrainte de clé étrangère est utile pour établir une hiérarchie ou un ordre entre les données d’une même relation.

De la même manière, différents opérateurs relationnels ont été définis dans le modèle relationnel :

• la sélection ;

• la projection ;

• la jointure ;

• la division.

Ceux-ci sont complétés par des opérateurs ensemblistes :

• le produit cartésien ;

• l’union ;

• la différence ;

• l’intersection.

La traduction de ces opérateurs en langage SQL n’est pas toujours identique d’un SGBD à un autre. La « différence » est représentée, selon les cas, par la clause « MINUS » ou

« EXCEPT ». Quant à l’opérateur « division », il n’a pas de traduction simple en langage SQL. Il est parfois obtenu à l’aide d’une formule composée des opérateurs « projection »,

« sélection » et « produit cartésien ». Considérons deux relations « r » avec deux attributs

« a,b » et « s » avec un attribut « b ». La division de « r » par « s » suivant « b » correspond à

CemOA : archive ouverte d'Irstea / Cemagref

la recherche des valeurs de l’attribut « a » qui, au niveau de la relation « r », sont associées à toutes les valeurs « b » présentes dans la relation « s ».

L’emploi d’une seule table rend les opérateurs ensemblistes inutiles. L’intérêt des opérateurs « jointure » et de « division » est d’une part également limité dans un tel cas.

D’autre part, les traitements associés à ces opérateurs sont complexes et requièrent énormément de ressources (voir Figure 3.31). Ainsi, seuls les opérateurs de « sélection » et de

« projection » sont présents de manière standard dans le système LiveFile, les autres pouvant être rajoutées.

Figure 3.31 – Fonctionnement des opérateurs relationnels Des fonctions mathématiques sont associées à ces 2 opérateurs :

• « count(A) » : pour compter les valeurs de l’attribut « A » considéré ;

• « sum(A) » : pour sommer les valeurs de l’attribut « A » considéré ;

• « avg(A) : pour effectuer la moyenne des valeurs de l’attribut « A » considéré ;

• « min(A) » et « max(A) » : pour donner respectivement le minimum et le maximum des valeurs de l’attribut « A » considéré.

La clause « ORDER BY » est implémentée par l’intermédiaire d’un algorithme de tri sous le système LiveFile. Le tri utilisé par défaut peut être remplacé suivant les contraintes et les caractéristiques de l’application supportée.

Au niveau des RCSF, la clause « GROUP BY » est intéressante. Elle peut être utilisée pour connaître la température moyenne observée dans chacune des zones depuis l’application.

Soit la relation « r » avec comme attributs « temp, zone, numjour », cette interrogation est traduite en langage SQL sous la forme suivante :

SELECT moy(r.temp) FROM r GROUP BY r.zone ;

Cependant, celle-ci, ainsi que la clause « HAVING », n’ont pas encore été implémentées, de manière optimale, pour une utilisation dans le cadre des RCSF. On déconseillera donc son utilisation au niveau du système LiveFile.

Projection(r)

Parcours de l’ensemble des tuples d’une relation r Affichage des valeurs d’attributs recherchés

Sélection(r)

Parcours de l’ensemble des tuples d’une relation r Test sur le (ou les) critère(s) de sélection Affichage des valeurs d’attributs recherchés

Jointure(r, s)

Parcours de l’ensemble des tuples d’une relation r

Recherche de correspondances dans une autre relation s suivant le critère de jointure Affichage des valeurs des attributs des tuples qui sont en correspondance

Division(r, s)

Parcours de l’ensemble des tuples d’une relation s

Liste des valeurs distinctes pour l’attribut du critère de division Parcours de l’ensemble des tuples d’une relation r

Comparaison avec la liste de valeurs distinctes de l’attribut

Affichage des valeurs des attributs des tuples associés à toutes les valeurs de s

CemOA : archive ouverte d'Irstea / Cemagref

Le langage SQL définit également des opérateurs pour insérer, supprimer et mettre à jour les données respectivement :

• « INSERT INTO …VALUES(…) ; » ;

• « DELETE FROM … WHERE … ; » ;

• « UPDATE … SET … WHERE … ; ».

Les deux premiers sont présents dans le système LiveFile. Sachant que, dans un RCSF, les capteurs sont les sources de données, la mise-à-jour d’une donnée n’est pas un fonctionnement logique. Plutôt que de modifier une donnée existante, il est recommandé de la supprimer et d’en insérer une nouvelle corrigée.

Les dernières clauses concernent la création (« CREATE TABLE »), la modification (« ALTER TABLE ») et la suppression (« DROP TABLE ») d’une relation. Quand le format de type « RECORD » est utilisé, le schéma de la table est intégré dans la structure de l’enregistrement où peuvent apparaître ou non les métadonnées contextuelles. L’hypothèse considérée est que la ou les relations d’un capteur sont créées avant le déploiement et ne sont plus modifiées.

Les systèmes TinyDB et Cougar intègrent dans leurs requêtes des commandes pour exécuter différentes actions au niveau de l’acquisition des données. Notre approche est différente et vise à séparer les traitements propres aux systèmes d’exploitation et ceux liés au gestionnaire de données. Plus précisément, les tâches de fonctionnement du système d’exploitation LIMOS ne peuvent pas être programmées à partir du système LiveFile.

Considérons la question suivante : « Quelles sont les températures supérieures au seuil « s » qui vont être acquises à une fréquence « f », à partir de maintenant pendant une durée

« d » ? ».

Sous le système TinyDB, cette question est transformée en la requête suivante :

« SELECT temp FROM sensors WHERE temp > s SAMPLE PERIOD f FOR d ; ». Des appels à des primitives du système d’exploitation se cachent derrière cette requête pour effectuer des relevés périodiques. Dans notre cas, pour répondre à une telle question, le système d’exploitation LIMOS va être configuré avant le système LiveFile. Deux configurations sont possibles. La première est la création d’un événement avec deux processus, l’un pour l’acquisition et, l’autre pour l’accès et le test de la donnée avec utilisation du système LiveFile. La deuxième est la définition de deux événements, l’un pour l’acquisition, l’autre pour l’interrogation (voir Figure 3.32). Un troisième processus ou événement peut être ajouté pour l’étape de communication.

Figure 3.32 – Configuration système pour des interrogations temps réel

Pour diverses raisons et hypothèses, tous les opérateurs et clauses issus du langage SQL ne sont pas définis au sein du système LiveFile. Par conséquent, le système LiveFile est

CemOA : archive ouverte d'Irstea / Cemagref

considéré plus comme un microsystème de fichiers interrogatif dédié au RCSF plutôt qu’un SGBD.