Clause entité

6.1.3 Contraintes d’attributs . . . 133 6.1.4 Contraintes sémantiques . . . 138 6.1.5 Propriétés algébriques du langage . . . 146

6.2 Rappels sur les langages formels . . . 152

6.2.1 Alphabet et mots . . . 152 6.2.2 Langages . . . 154 6.2.3 Grammaire . . . 155 6.3 La grammaire G_ . . . 158 6.3.1 Le grammaire réduite GÏ  . . . 158 6.3.2 G, l’intégrale . . . 162 6.4 Implémentation . . . 165 6.4.1 Le générateur . . . 165 6.4.2 Exploitation du parseur . . . 166

Le Modèle Logique de Données (MLD) décrit dans la section 5.1 ainsi que sa « traduction » au sein de l’environnement NoSQL (section 5.2) permet non seulement de stocker tout type d’informations sans altération structurelle du modèle de données mais aussi et surtout de maî-triser la vision conceptuelle que l’on souhaite donner à cette information. Ce dernier permet de préserver et de rendre exploitable l’information de santé sous forme d’un réseau sémantique d’information1 représentable à l’aide d’un formalisme entité–association et, de manière plus générique, assimilable à un graphe de données reliant de multiples entités par des relations sé-mantiques. Ce stockage et cette modélisation générique de l’information ne fournit cependant, en soit, pas de fonctionnalités de RI. Le rôle du travail décrit dans ce mémoire est précisément de tirer partie de l’expressivité sémantique permise par le modèle de données du dans le cadre de la RI. L’idée de base étant en effet de bénéficier de la structure de graphe de données en adoptant une « philosophie » d’interrogation calquée sur cette sémantique et cette généricité. Comme évoqué précédemment dans ce mémoire, la sémantique des données de santé fait intervenir de multiples notions, représentées conceptuellement par des entités/objets (e.g. des patients, des séjours, des unités médicales, des analyses biologiques, etc.). D’un point de 1. La notion de réseau sémantique est ici employée de manière générique. Elle ne se réfère pas uniquement et spécifiquement à la notion de sémantique classiquement assimilée à l’exploitation de TOs. Ici, l’expression « réseau sémantique d’information » désigne plus largement un ensemble d’unités d’informations porteuses de sens et reliées entre elles de manière cohérente d’un point de vue humain. Cette vision structurée de l’information se traduit notoirement par une représentation de l’information en terme d’entités reliées par des relations qui forment ainsi un réseau.

vue médical ou clinique, ces entités ne prennent bien souvent pleinement leurs sens et/ou leurs utilités que lorsqu’elles sont vues de manière interconnectées (e.g. une analyse biologique n’a en soit que peu de valeur informative si l’on ne la rattache pas au patient auquel elle appartient).

La fusion « tout-en-un » des informations relatives à ces diverses entités reste cependant diffi-cile compte tenu de la diversité des cas d’usage d’un EDS qui impose potentiellement des besoins de séparations structurelles de l’information incompatibles. L’hétérogénéité même des types d’in-formation présents rend leurs agrégations techniquement parfois incohérentes et opérationnelle-ment inexploitables. L’emploi soutenu de modèles de données de type Entity–Attribute–Value (EAV)2, que ce soit dans le cadre de la recherche clinique ou de l’amélioration de la prise en charge des patients, est par ailleurs symptomatique de cette incapacité à modéliser l’information de santé de manière « figée ».

Dans ce contexte, les bénéfices potentiels d’un SRI basé sur un EDS dépendent donc de la capacité de ce système à s’accorder avec cette réalité. En d’autres termes, un tel système doit être en mesure de répondre à des besoins d’information complexes formulés en terme d’atomes d’information qui doivent néanmoins pouvoir être mise en relation.

Lorsqu’il s’agit de requêter les données d’un SGBDR la norme en terme de langage de requête est le SQL. Bien que le SQL soit un langage de requête puissant, offrant de nombreuses possibilités de sélections avancées des données et facile d’utilisation dans l’absolu, il n’en reste pas moins que ce langage de requête a été conçu pour des utilisateurs ayant des connaissances informatiques. Il est donc peu pragmatique d’envisager le SQL comme langage de requête pour l’accès aux données d’un SI. La plupart des SRIs basés sur un EDS reposant sur un SGBDR sont alors couplés à des interfaces graphiques fournissant des fonctionnalités prédéfinies. Clas-siquement, l’accès à ces dernières se fait à travers des formulaires générant des requêtes SQL préconçues et paramétrables. Ce sont alors principalement ces requêtes prédéfinies qui ont la charge d’effectuer les jointures adéquates entre les différentes entités composant l’information de santé à cibler. Parmi les SRIs existants dans la littérature, on retrouve notamment cette stratégie avec des niveaux de spécificité variables. SMEYEDAT [80] par exemple fournit une interface extrêmement spécialisée permettant de répondre à des cas d’usage ophtalmologiques. STRIDE [1], quant à lui, propose une recherche plus générique permettant, par exemple, de gé-rer la concomitance de certains événements mais propose néanmoins plusieurs interfaces suivant le cas d’usage (e.g. extraction de patient, extraction d’information clinique, etc.). Enfin [68, 69], et l’outil qui lui est dédié (le Workbench Query Tool), proposent un niveau de géné-ricité plus étendu en permettant à l’utilisateur d’influer sur l’étendue des données accessibles via les fonctionnalités de RI de l’outil en structurant de manière adéquate les méta-données. Ces outils restent cependant, malgré tout, globalement centrés autour de la notion de patient. Il sont d’ailleurs majoritairement conçus pour fournir des données agrégées (e.g. moyennes, écarts type, graphiques, etc.) relatives à la liste de patients extraite (cf. chapitre 2). De plus, l’étendue des données sujettes à de la RI est tributaire de la structuration de ces données dans la base de données imposant parfois une modification de la structure conceptuelle des données afin d’en permettre l’intégration et la recherche (e.g. [71])

En somme, le langage SQL permet la mise en place d’une RI efficace mais reste néanmoins un langage technique, muni d’un formalisme faisant intervenir les notions du modèle relationnel. Ce langage ne peut être exploité par les professionnels de santé qu’à travers des interfaces répondant à des problématiques spécifiques qui peuvent être générisées mais qui s’articulent néanmoins au-tour de la notion de patient. Un des objectifs de mes travaux est de permettre une expression des besoins d’information plus globale et plus générique, ne considérant plus le patient comme le concept central de l’information de santé d’un EDS mais comme une entité parmi d’autres reliée au sein d’un réseau d’information complexe. Cette vision permet notamment de s’accorder avec davantage de cas d’usage et de répondre à divers besoins d’information. Ceci requiert un langage intermédiaire permettant de s’abstraire de la vision structurelle des données au profit d’une vision conceptuelle, en fonction du formalisme entité-association des données, et non basé

directement sur un formalisme technique hérité de la structuration physique des données. Enfin, un tel langage s’avère essentiel techniquement lorsque le stockage des données est effectué au sein d’un In Memory Data Grid (IMDG)3 tel qu’ qui n’offre, lui, pas la totalité des fonctionnalités requises pour effectuer pleinement une RI efficace (comme vu dans le chapitre précédent) et impose la modélisation et l’implémentation annexe de ces fonctionnalités.

 Notation 4 :

Une partie non négligeable du travail effectué dans le cadre de cette thèse est la conception d’un langage de requête spécifique. Dans ce mémoire, on notera L ce langage, G la grammaire formelle qui engendre ce langage et enfin L_–requête les requêtes écrites dans le langage L_.

6.1 Description de la syntaxe

En pratique, un langage de requêtes joue le rôle d’un langage de communication entre un humain et une source de données telle qu’une base de données ou un SI quelconque. Plus préci-sément, il fournit une syntaxe permettant à un utilisateur humain d’exprimer au travers d’une requête textuelle la nature et les caractéristiques des données qu’il souhaite obtenir du SI.

La syntaxe du SQL s’articule autour de la structure de la base de données. La création de requêtes à l’aide de ce langage nécessite une parfaite connaissance du modèle de la base de données (i.e. tables, colonnes, etc.) ainsi que la maîtrise de certaines notions techniques telle que la notion de jointure par exemple. Ce langage est donc dépendant de la structure concrète des données et permet de constituer des requêtes dont la philosophie de syntaxe est orientée sur la structure des données.

Le langage de requête que je propose possède lui, a contrario, une syntaxe orientée en-tités. Celle-ci permet de formuler des requêtes indépendamment de la structure physique des données ciblées par ces dernières. Les éléments de base manipulés par ce langage sont en réalité les diverses entités conceptuelles que représentent implicitement les données et non les données elles mêmes. Ces entités correspondent à celles du MCD. Dans une modélisation relationnelle classique, le MCD correspond approximativement au MLD et peut en être déduit4. Dans le contexte de cette thèse, la déduction du MCD est en revanche immédiate (Figure 6.1). En effet, le MLD du SI du généralise le formalisme de représentation entité–association lui-même et non un MCD particulier qui lui, n’en est qu’une instance.

SGBDR Modèle Physique de Données Modèle Logique de Données Modèle Conceptuel de Données SQL Langage de Requête Humain ou Interface NINJAC Langage de Requête Humain ou Interface ⇔ traduction exécution requêtage déduction déduction déduction SSE S QL requêtage exploitation accès basique SSE N oS QL

Figure 6.1 –Positionnement et rôle du langage de requête dans la chaîne d’interrogation des données de l’EDSS. Les deux preuves de concept exploitant respectivement une base de données relationnelle et une base de données NoSQL sont représentées.

Cette section s’attache à décrire de manière pragmatique le langage de requête L_du SSESQL et du SSEN oSQL. Ayant été initialement imaginé dans un cadre du projet RAVEL [ANR–11– TECS–012] et de la problématique de RI au sein du DPI, ce cas d’usage sera repris comme exemple support à la description de la syntaxe ainsi que de la logique syntaxique du langage de requête. Une partie du MCD exploité durant la modélisation et le développement du langage est donnée Figure 6.2.

Ce dernier se présente sous forme d’un graphe orienté, étiqueté et attribué (i.e. chaque entité peut être muni d’attributs, les arcs sont orientés et possèdent une étiquette).

La syntaxe de base du langage s’articule autour ces notions d’entités, d’attributs d’entités et d’arcs (i.e. de relations) entre ces entités. Bien que le moteur de recherche SSEN oSQLrepose

sur ce langage aujourd’hui, ce dernier a été initialement conçu comme un langage intermédiaire entre le SQL et l’humain ou une quelconque interface graphique (Figure 6.1).

Je décris dans cette section le langage L imaginé, modélisé et implémenté comme langage d’interaction avec les moteurs de recherche SSESQL et SSEN oSQL. Les deux sections suivantes (viz. section 6.2, section 6.3) permettent de définir de manière complète et rigoureuse ce langage L. Les exemples donnés dans cette section font tous référence au graphe de données de la Figure 6.2. patient id nom prenom date_naissance sexe sejour id date_entree date_sortie compte_rendu id fichier date type unite_medicale id label code_CIM10 id label analyse_biologique id date valeur borneInf borneSup code_EXE id label acte_medicale id date code_CCAM id label Légende : libellé de l’entité

attributs de l’entité ^entité

relation entre entités

a_sejour indexe indexe dans_UM est_cr est_cr

contient_analyse _{contient_acte} dans_UM

indexe

Figure6.2 –Extrait du MCD représenté sous forme d’un graphe de données orienté, étiqueté et attribué. Dans ce graphe, une simplification d’une partie des données de l’EDSS est représentée conceptuellement. L’entité patient est liée à des séjours au sein desquels peuvent être pratiqués des examens biologiques et des actes médicaux. Les actes médicaux et les séjours peuvent être effectués dans des unités médicales distinctes. Les actes sont rattachés à des codes de la CCAM.

6.1.1 Clause entité

Les clauses entité sont les « éléments syntaxiques de base » à partir desquels le langage de requête est construit. Elles constituent, d’ailleurs, l’élément minimal requis pour former une requête dans ce langage. Comme il le sera précisé dans la suite, c’est ce formalisme syntaxique de base qui permet, par imbrication récursive, de former des requêtes plus complexes permettant de naviguer au sein du réseau sémantique des données. Une clause entité suit une syntaxe de la forme :

 Syntaxe 1 (Clause entité) :

Une clause entité d’entité ENTITY est une expression de la forme : ENTITY(CONSTRAINT)

où :

ENTITY désigne un libellé d’entité ;

CONSTRAINT désigne une expression composée de contraintes atomiques.

Formellement, une clause entité exprime, désigne ou cible un ensemble d’entités respectant certaines contraintes. La sous-clause ENTITY spécifie le (ou les types) d’entité(s) ciblée(s) tandis que la sous-clause CONSTRAINT définit un certain nombre de contraintes respectées par cette (ces) entité(s). Plus précisément :

La sous-clause ENTITY se matérialise syntaxiquement par un libellé d’entité. Elle a pour but de définir « les entités à requêter » ou plus généralement les entités « ciblées » ou « désignées » par la clause entité dans son ensemble. Dans le cadre de notre exemple (Figure 6.2), ENTITY pourrait par exemple correspondre aux types patient ou sejour. Dans l’absolu, la grammaire du langage de requête accepte qu’une sous-clause ENTITYd’une clause entité ENTITY(CONSTRAINT) fasse intervenir plusieurs libellés d’entités séparés par des virgules (« , ») (cf. exemple 7). La clause entité dans son ensemble cible alors plusieurs entités à la fois. Cependant, l’utilisation de clauses entités désignant plusieurs entités n’est, en pratique, pertinente que dans des cas bien particulier relativement anecdotiques.

> Remarque 5 :

Dans un souci de simplicité, si aucune indication n’est fournie, toute clause entité ENTITY(CONSTRAINT) pourra par la suite être considérée comme ne ciblant qu’une seule et même entité.

La sous-clause CONSTRAINT définit les contraintes qui devront être vérifiées par l’entité ciblée. Cette contrainte est une expression logique construite à l’aide d’une part des opérateurs Booléens AND et OR et de contraintes de deux types qui seront détaillés par la suite : les contraintes d’attributs et les contraintes sémantiques.

Dans sa forme la plus simple, une clause entité peut ne pas avoir de contrainte et donc se limiter à une syntaxe de la forme ENTITY(). Un moteur de requête implémentant le langage de requête pourra alors interpréter la requête en renvoyant la totalité des entités de type ENTITY (cf. exemple 6).

¸ Exemple 6 :

la requête patient() désigne l’ensemble de tous les patients contenus dans la source de données.

¸ Exemple 7 :

la requête analyse_biologique,acte_medical() désigne l’ensemble de tous les actes mé-dicaux et toutes les analyses biologiques contenus dans la source de données.