La recherche d’information

Comme tous les magasins de données de type clé-valeur, la solution repose sur la structure de données de table de hachage. Cette dernière fournit une API de base qui permet une sélection et une insertion de base des données. Cette API permet l’insertion d’un couple (cl´e, valeur) dans une map (i.e. opération de put) ou bien la récupération d’une valeur à partir de sa clé (i.e. opération de get). Elle est exploitée par le système de gestion de données NINJAC afin d’assurer la robustesse, la maintenance et l’accès de base aux données du SI.

NINJAC ne fournit, en revanche, pas de fonctionnalités de requêtage avancé. Lorsque un SI repose sur un SGBDR, les fonctionnalités de RI sont assurées par l’utilisation du SQL. Ce-pendant, très peu de solutions NoSQL fournissent la possibilité d’utiliser ce langage de requête. De plus, ceux qui le permettent (e.g. Apache Ignite4), n’implémentent pas les fonctionnalités de ce langage sur la partie NoSQL sous-jacente mais sur un SGBDR traditionnel répliquant les données n’assurant ainsi alors pas nécessairement de meilleures performances et impliquant ainsi de plus lourdes contraintes en terme d’espace mémoire.

, offre la possibilité d’indexer les données en utilisant Apache Lucene ( )5[154] et fournit plusieurs APIs de requêtage dépendant du contexte d’utilisation :

Ickle : qui est le langage de requête Booléen propre à . C’est un sous-ensemble léger de JP–QL muni d’une extension pour la recherche plein texte qui peut être utilisée à la fois en mode client ou en mode embarqué sur des données indexées ou non. Ce dernier ne supporte cependant ni le calcul à la volée d’expressions algébriques, ni les jointures entre entités, ni les sous-requêtes.

L’API de requêtage Hibernate : qui permet en mode embarqué de requêter les données indexées en générant des requêtes .

L’« Infinispan Query Domain–Specific Language (DSL)6 » : qui fonctionne lui égale-ment en mode client (en plus du mode embarqué) en créant programmatiqueégale-ment des requêtes mais qui ne permet pas d’effectuer de la recherche plein texte et ne supporte pas davantage les jointures.

Aucune de ces APIs ne fournit à elle seule l’intégralité des fonctionnalités nécessaire à la mise en place d’une RI. Elles reposent, de plus, sur des modes de requêtage différents (i.e. constitution

4. url : https://ignite.apache.org/index.html 5. url : https://lucene.apache.org/

de requêtes sous forme de chaînes de caractères vs. de façon programmatique). Enfin aucune méthode native ne permet de gérer efficacement les jointures entre entités qui reste néanmoins une fonctionnalité essentielle à la RI au sein de données de santé.

Afin de garantir l’implémentation de ces fonctionnalités, deux maps de jointure sont main-tenues par NINJAC. Ces dernières s’ajoutent aux maps de base du SI (Table 5.3) et sont décrites dans la Table 5.5. Elles permettent de garantir la recherche des relations classiques et des re-lations d’indexation relative respectivement aux tables TB_OBJECT_PROPERTY et TB_INDEXING du MLD. La map permettant de requêter les relations d’indexation est basée, notamment en ce qui concerne la structure de ses clés, sur la notion d’indexation adoptée par l’équipe et prenant en compte le caractère majeur ou mineur de cette dernière ainsi que les qualificatifs et types de ressources affiliés (cf. remarque 4). D’une manière générale, ces deux maps permettent de retrouver les identifiants cible (resp.source) d’une relation en spécifiant (au niveau de la clé), le type de relation ainsi que l’identifiant source (resp.cible) de cette dernière. Certaines relations donnent effectivement lieu à deux entrées au sein de ces maps afin que la relation puisse être parcourue de manière symétrique.

L’ensemble des maps composant le modèle de données NoSQL du SI permettent de recher-cher les différents objets ™ en exploitant leurs éléments de structure (i.e. leurs identifiants et les relations qu’ils entretiennent entre eux). Ces dernières jouent le rôle d’index classique permettant de retrouver des entités par l’intermédiaire d’identifiants. En revanche, la recherche des entités par l’intermédiaire de leurs contenus (attribut textuel, numérique ou de type date) n’est pas assurée par ces index. a été utilisé afin de générer des index inversés permettant la recherche des entités portant sur les différents champs composant les entités de type DatatypeProperty. Ces index permettent d’effectuer une recherche plein texte portant sur les attributs de type DatatypeProperty.

Nativement, le SGBD NoSQL orienté Clé-Valeur ne fournit aucun mécanisme de définition d’une quelconque modélisation des données. Celle-ci est en réalité intrinsèquement fixée par la structure des objets ™ employés comme valeurs des entrées des différentes maps contenues par ce SGBD. Afin de préserver la modélisation générique définie par le MLD de la Figure 5.2, les valeurs des maps de NINJAC ont été restreintes à des POJOs simulant la struc-ture des différentes tables de ce modèle. En d’autres termes, la modélisation définie à l’aide de tables et de colonnes au sein du SGBDR a été transposée au niveau du SGBD NoSQL NINJAC à l’aide d’objets ™ possédant une structure équivalente.

Bien que cette modélisation ait pu être réalisée, l’API de base fournie nativement par

ne permet pas de l’exploiter. Certains outils de requêtage visant à pallier à ce problème existent mais n’autorisent pas une sélection suffisamment exhaustive des données pour répondre à la totalité des besoins d’information relatifs aux données cliniques. Nous avons donc créé des maps spécifiques assimilables à des index inversés qui constituent un ensemble de structures dont l’ex-ploitation fournit l’ensemble des fonctionnalités de recherche requis. Néanmoins, si ces structures offrent des possibilités techniques de recherche des données, chaque besoin d’information requiert une utilisation spécifique et organisée de ces maps. Ceci peut être réalisé grâce à un langage de requête qui fournit une syntaxe permettant à la fois d’exprimer et d’identifier les informations désirées.

Dans le cadre de mon travail de thèse, j’ai ainsi définit le langage L_ afin de remplir cet objectif. Ce dernier est décrit dans le chapitre suivant.

Cache de jointures relationnelles

Retrouver les objets liés à un autre par un type de relation défini. “TYPE_ID”

+

“RDF_RESOURCE_SOURCE”

−→ {“RDF_RESOURCE_TARGET”}

Clé composée d’un identifiant (i.e. un type) de rela-tion et d’un identifiant d’un objet.

Ensemble des identifiants des

objets liés à l’objet

d’identi-fiant “RDF_RESOURCE_SOURCE”

par une relation de type

“TYPE_ID_RELATION”.

Cache de jointures d’indexations

Retrouver les objets indexés avec un concept terminologique (ou plus généralement un autre objet).

“TYPE_ID” + “RDF_RESOURCE_INDEX” + “RDF_RESOURCE_INDEX_AFF” + “RDF_RESOURCE_INDEX_AFF_TR” + MAJEUR_0/1 + EXPLOSION_0/1 −→ {“RDF_RESOURCE_INDEXED”}

Clé décrivant permettant de spécifier : — le type de relation d’indexation désiré ;

— l’identifiant du concept terminologique

(ou de l’objet) indexant les ressources re-cherchées (e.g. « maladies de l’animal » [D000820 (MeSH)]) ;

— optionnellement, le qualificatif de l’indexation (e.g. « thérapie » [Q000628 (MeSH)]) ;

— optionnellement, le type de ressources

de l’indexation (e.g. « documents »

[T R39 ( )]) ;

— le caractère majeur/mineur désiré pour l’in-dexation ;

— si les ressources peuvent être indexées avec un fils hiérarchique du concept indexant indiqué (i.e. explosion hiérarchique).

Ensemble des identifiants des ob-jets indexés, par l’intermédiaire

de la relation d’indexation de

type “TYPE_ID”, en majeur ou en mineur (selon la valeur de MAJEUR0/1) avec le concept d’iden-tifiant “RDF_RESOURCE_INDEX” (ou l’un de ses fils si EXPLOSION0/1 est à true) et éventuellement le

qualifica-tif “RDF_RESOURCE_INDEX_AFF”

et le type de ressources

“RDF_RESOURCE_INDEX_AFF_TR”.

Table 5.5 – Les deux maps de jointure utilisées dans le cadre des tâches de RI afin de parcourir les relations classiques et les relations d’indexations. L’utilité globale de chaque map et les rôles pris par la clé et la valeur sont explicités.

Le langage de requête L_

6.1 Description de la syntaxe . . . 130

6.1.1 Clause entité . . . 131