Notre modèle générique

5.1.3 La course « à la perf’ » . . . 118

5.2 Le virage du NoSQL . . . 120

5.2.1 L’In Memory Data Grid qualifié . . . 120 5.2.2 Le changement de paradigme en action . . . 120 5.2.3 La recherche d’information . . . 123

Du fait de la sensibilité des données qu’ils exploitent, les SRIs basés sur les EDSs se doivent de persister leurs données de manière sécurisée et d’en permettre un accès sûr et cohérent. La RI au sein de ces données de structure complexe nécessite en outre des méthodes étendues de requêtage.

Les SGBDRs présentent l’avantage, du fait de leur ancienneté et du modèle relationnel qu’ils implémentent, d’être particulièrement aboutis en terme de requêtage (notamment grâce au lan-gage de requête SQL qu’ils proposent), d’intégrité des données (i.e. respect strict des propriétés ACIDs) et de sécurisation de ces dernières. C’est donc, en premier lieu, sur un SGBDR que s’est porté notre choix pour la modélisation et l’intégration des données de l’EDS du CHU de Rouen. Ces dernières années, de nombreuses solutions NoSQLs ont vu le jour avec, pour principaux objectifs, de pallier aux limitations des SGBDRs en diminuant les temps d’accès aux données (cf. section 4.2). Les performances étant un critère important dans le cadre de la RI au sein des EDSs, je me suis interessé à la question de la modélisation et de l’intégration des données de santé au sein d’une base de données NoSQL.

Comme précisé en introduction, dans ce travail de thèse, deux preuves de concepts de moteur de recherche ont été réalisées. Ces deux derniers ont pour objectif majeur la RI au sein de l’EDS du CHU de Rouen. Ils se distinguent avant tout par les bases de données sous-jacentes qu’ils exploitent et à partir desquelles ils accèdent aux différentes données de santé :

Le SSESQL : Conçu pour accéder aux données directement à partir d’une base de données relationnelle munie d’un modèle de données générique de type EAV.

Le SSEN oSQL : Conçu pour accéder aux données via un cache en mémoire de type IMDG im-plémenté à l’aide de la solution NoSQL . Un SGBDR est néanmoins toujours utilisé pour assurer la persistance des données de façon sûre.

La caractéristique première de l’EDS du CHU de Rouen est son aspect sémantique. Ce der-nier fournit une description sémantique de l’information de santé à laquelle le SSESQL et le

SSEN oSQL permettent d’accéder. Si les SGBDs sur lesquels ces moteurs de recherche diffèrent technologiquement, ils adoptent néanmoins un même modèle de données hérité du paradigme de représentation de l’information du Web Sémantique. Ce dernier a été développé depuis plusieurs années dans le cadre de travaux de thèse [30].

Ce chapitre s’attache à décrire ce paradigme de représentation de l’information ainsi que les modèles de données qui en résultent. Les différents corpus de données utilisés durant ce travail de thèse sont également décrits.

5.1 À l’origine, un SGBDR

Le modèle de données de base du SI de l’équipe du est un modèle générique de type Entity–Attribute–Value (EAV). Ce modèle résulte notamment de travaux antérieurs [30, 145, 146]. Il peut être qualifié de générique dans le sens où il permet une description géné-rique de l’information. Bien que n’ayant pas été développé dans le cadre de cette thèse, ce modèle revêt néanmoins une importance capitale dans le contexte de cette dernière. L’idée de base des moteurs de recherche est de « transférer », au niveau de la RI, cette généricité de des-cription de l’information afin de la rendre utilisable et accessible de manière tout aussi générique. Les modèles de type EAV sont largement exploités notamment pour stocker des données biomédicales. Ils permettent de palier à certains manques de flexibilité du modèle relationnel. Une brève explication de l’idée sous-jacente de ce type de modèle est donnée remarque 3.

> Remarque 3 (Les modèle de type EAV) :

Certaines données complexes et plus particulièrement les données cliniques présentent un nombre conséquent de paramètres et attributs descriptifs. Par exemple, la description d’un séjour d’un patient dans un établissement hospitalier requiert un nombre important d’at-tributs descriptifs tels que : les dates d’entrée et de sortie du séjour, les modes d’entrée et de sortie, le poids du patient lors du séjour, le statut du séjour, etc. Lorsqu’il s’agit de structurer ces données au sein d’un modèle relationnel classique, cette multitude d’attributs se traduit par des tables pourvues d’un nombre de excessif colonnes. Chaque ligne de la table désignant ainsi une entité quelconque (e.g. un séjour) et chaque valeur de colonne de cette ligne correspondant à un paramètre descriptif de ce séjour (e.g. statut du séjour, date d’entrée, etc.). Certains paramètres descriptifs sont parfois non-applicables à certaines en-tités (e.g. le poids du patient n’est pas systématiquement renseigné car non pertinent pour certains séjours). Ceci se traduit par un nombre parfois conséquent d’assignations à une valeur nulle de certaines colonnes. Les modèles de type EAV ont pour objectif principal de pallier à ces inconvénients. Au sein d’un tel modèle, les entités ne sont plus décrites à l’aide d’une seule et même ligne composée de plusieurs valeurs de colonnes mais à l’aide d’une table de faits contenant une ligne par paramètre descriptif. Chaque fait étant ainsi décrit à l’aide de trois paramètres : l’identifiant de l’entité concernée, le type d’attribut (e.g. date d’entrée, etc.) et la valeur de ce paramètre.

Lorsque l’on souhaite stocker et gérer des données au sein d’un SGBDR, on distingue clas-siquement trois modèles de représentation des données :

Le Modèle Conceptuel de Données (MCD) qui donne une vision facilement compréhen-sible des données y compris pour une personne ne possédant pas de compétences tech-niques. Dans un MCD, les données et leur organisation sont décrites à l’aide d’un forma-lisme entité-association. Ils définissent des entités conceptuelles et des relations permettant de décrire les différentes associations entre ces entités. Ils donnent ainsi une vision à la fois intuitive et en adéquation avec la réalité de la situation à laquelle ces données se rap-portent. Le MCD définit en réalité une représentation d’un ensemble d’informations sous forme d’un graphe de données dont les nœuds correspondent aux entités de ce MCD et où les arcs correspondent aux relations qu’il établit entre les entités.

Le Modèle Logique de Données (MLD) qui lui reprend la description abstraite et intui-tive des données caractérisée dans le MCD afin d’en définir une structuration relationnelle. En d’autres termes, il permet décrire le MCD sous forme de tables, de colonnes, de tuples, de clés primaires et étrangères. Il donne donc une structuration relationnelle des données en vue de leur maintenance dans un SGBDR.

Le Modèle Physique de Données (MPD) qui, lui, se distingue du MLD dans le sens où il correspond à une implémentation du MLD au sein d’un SGBDR particulier. Il est

struc-turellement identique mais apporte des informations d’implémentation propres au langage de programmation fournit par ce SGBDR particulier. Il précise notamment le typage de chaque colonnes.

Dans la pratique, le MLD et le MPD peuvent être assimilés de telle sorte que l’on considère, d’une part la vision conceptuelle que l’on a des données (fournie par le MCD), et d’autre part la vision structurelle de celles-ci utilisée pour les stocker (fournie par MLD et/ou le MPD). Bien que ces deux visions peuvent différer dans une modélisation relationnelle classique, la structure du MLD hérite néanmoins souvent de celle du MCD. Par exemple, une table du MLD correspond généralement à une entité ou à une relation du MCD dans la pratique.

Dans une modélisation relationnelle des données, un changement du MCD (i.e. lorsque de nouveaux types d’informations doivent être gérés) impose généralement un changement struc-turel du MLD (e.g. ajout de tables, de colonnes, etc.). Le modèle de données du SI du exploité dans le cadre de ce travail, et plus généralement des modèles de données de type EAV, n’imposent en revanche pas de telles modifications structurelles du modèle de données. Ce der-nier s’attache, en effet, à définir un ensemble de tables permettant de modéliser génériquement le formalisme entité-association lui même. Il ne modélise donc pas un MCD particulier, qui consti-tue lui une instance de ce formalisme, et ne modélise pas des informations spécifiques issues d’une situation réelle et concrète (cf. Figure 5.1) même si il permet des les intégrer.

Situation réelle Formalisme Entité-Association MCD MLD, MPD Formalisme Entité-Association Modèle de données modélisation structurelle Conceptualisation modélisation conceptuelle modélisation structurelle Modélisation Relationnelle Modélisation Relationnelle Classique

Figure 5.1 –Modélisation relationnelle du et modélisation relationnelle classique.

Le modèle de données du est indépendant de la donnée elle même. Il ne requiert pas de modifications structurelles même lorsque de nouvelles données doivent être gérées, à partir du moment où leurs représentations à l’aide du formalisme entité-association est possible. De même, les données insérées dans ce modèle définissent intrinsèquement une information sous forme d’un formalisme entité-association et donc un MCD.

Le MLD du est donné Figure 5.2. Bien qu’il ne s’agisse pas, à proprement parler, d’un MPD, des informations de typage des colonnes sont néanmoins données de manière générique. Ce modèle est composé de 9 tables. Il permet le stockage de n’importe quel type d’information

sans modification structurelle du modèle (i.e. sans ajout de tables, colonnes, etc.). Comme pré-cisé précédemment, ce dernier s’appuie sur une logique de structuration des données basée sur le formalisme entité-association. Plus précisément, il est inspiré du paradigme de représentation de l’information du Web sémantique dans lequel l’information est décrite d’une part, par l’inter-médiaire d’une description des données et d’autre part, à l’aide d’une Ontologie RDFS et/ou OWL dont le rôle est de structurer le vocabulaire exploité par cette description . Á l’image de ce partage, le modèle de données ici décrit se partitionne en deux sous-ensembles de tables :

— Les tables de données. — Les tables de modèles.

Ces deux ensembles sont respectivement assimilables à la partie Donnée et à la partie On-tologique du Web Sémantique. Ils sont décris dans les sections suivantes. La partie donnée du modèle de données peut également être vue comme le pendant de l’ABox de la notion de bases de connaissances issues de la théorie des Logiques de Descriptions [147, 148] tandis que la partie modèle permet d’en définir l’ensemble de axiomes Terminologiques (T Box) [146].

TB_OBJECT RDF_RESOURCE d TYPE_ID [FK] d TB_OBJECT_PROPERTY OBJECT_PROPERTY_ID d RDF_RESOURCE_SOURCE [FK] d TYPE_ID [FK] d RDF_RESOURCE_TARGET [FK] d RDF_RESOURCE_SOURCE_AFF [FK] d RDF_RESOURCE_TARGET_AFF [FK] d TB_DATATYPE_PROPERTY DATATYPE_PROPERTY_ID d RDF_RESOURCE [FK] d TYPE_ID [FK] d XML_LANG d VAL d DATE_VAL ÷ NUM_VAL P TB_INDEXING INDEXING_ID d RDF_RESOURCE_INDEXED [FK] d TYPE_ID [FK] d RDF_RESOURCE_INDEX [FK] d RDF_RESOURCE_INDEX_AFF [FK] d RDF_RESOURCE_INDEX_AFF_TR [FK] d TB_HIERARCHY HIERARCHY_ID d RDF_RESOURCE_BT [FK] d TYPE_ID [FK] d RDF_RESOURCE_NT [FK] d TREE d N_PATH d TB_MODEL_DATATYPE_PROPERTY MODEL_DATATYPE_PROPERTY_ID d TYPE_ID_SOURCE [FK] d TYPE_ID [FK] d XML_LANG d VAL d TB_MODEL_OBJECT_PROPERTY MODEL_OBJECT_PROPERTY_ID d TYPE_ID_SOURCE [FK] d TYPE_ID [FK] d TYPE_ID_TARGET [FK] d TB_MODEL TYPE_ID d XSD_TYPE d TYPE_DOMAIN d TB_MODEL_INHERITANCE MODEL_INHERITANCE_ID d TYPE_ID_BROADER [FK] d TYPE_ID [FK] d TYPE_ID_NARROWER [FK] d T ables de données T ables de mo dèle

Figure5.2 –Modèle logique de donnée du SI. Les clés primaires sont soulignées (e.g. CLE_PRIMAIRE), les clés étrangères sont identifiées par l’annotation [FK], les champs textuels par d, les champs numériques par P et les champs de type date par ÷.

5.1.1.1 Les tables de données

Les tables dites « de données » sont les tables : — TB_OBJECT.

— TB_DATATYPE_PROPERTY. — TB_OBJECT_PROPERTY. — TB_INDEXING.

Ces tables permettent la structuration et le stockage des données concrètes destinées le plus souvent à l’affichage ou à la mise à disposition des utilisateurs par les applications. La struc-ture de ces tables reprend le paradigme de représentation de l’information en triplets (sujet,

predicat, objet) du modèle tout en faisant physiquement la distinction entre les triplets permettant d’associer une valeur littérale à une entité (i.e. (objet, attribut, valeur)) de celles permettant de relier d’autres entités à cette entité (i.e. (objet, relation, objet)). Ces deux types de propriétés sont respectivement nommées les datatype properties et les object properties par le dans le cadre du Web sémantique.

Dans la pratique, la table TB_OBJECT permet de « déclarer » une entité (ou un objet) et la table TB_DATATYPE_PROPERTY permet d’en définir les attributs. Celle-ci permet en réalité de définir des triplets de colonnes équivalents aux triplets de type datatype property :

(RDF_RESOURCE, TYPE_ID, VAL) (RDF_RESOURCE, TYPE_ID, NUM_VAL) (RDF_RESOURCE, TYPE_ID, DATE_VAL)

    

⇔ Triplet de type datatype property (objet, attribut, valeur)

Les tables TB_INDEXING, TB_HIERARCHY et TB_OBJECT_PROPERTY permettent toutes les trois de définir les relations relatives à cette entité. La table TB_INDEXING permet de stocker les rela-tions d’indexation (e.g. indexation d’un compte-rendu avec un concept appartenant à un SOC quelconque), la table TB_HIERARCHY est principalement exploitée pour définir les relations hiérar-chiques entre les concepts des différents SOCs (e.g. le concept « Doctorat » [003912 (TSP)] issu du Thesaurus Santé Publique (TSP) édité par la BDSP est un « fils » du concept « Diplôme » [003832 (TSP)]). Enfin, la table TB_OBJECT_PROPERTY permet de définir toutes les autres re-lations incluant notamment les alignements entre concepts (e.g. « Doctorat » [003912 (TSP)] possède un alignement exact avec le concept « Thèses » [M0359797 (MeSH)]) mais aussi toutes autres sortes de relations structurelles (e.g. relation entre une analyse biologique et un patient, relation entre une ressource bibliographique et un éditeur, etc.). De même, ces trois tables per-mettent de définir des triplets de type object property par l’intermédiaire de triplets de colonnes :

(RDF_RESOURCE_INDEXED, TYPE_ID, RDF_RESOURCE_INDEX) (RDF_RESOURCE_BROADER, TYPE_ID, RDF_RESOURCE_NAROWER) (RDF_RESOURCE_SOURCE, TYPE_ID, RDF_RESOURCE_TARGET)

     ⇔ Triplet de type object property (objet, relation, objet)

> Remarque 4 (Notion d’indexation) :

Dans le cadre du SI du , la notion d’indexation peut néanmoins prendre une forme légè-rement plus complexe qu’une simple association entre une ressource (i.e. colonne RDF_RESOUR-CE_INDEXED) et un concept terminologique (i.e. unique colonne RDF_RESOURCE_INDEX). Cette vision de l’indexation, issue de celle adoptée par la terminologie MeSH, effectue premièrement une distinction entre les indexations majeures et mineures. Une indexation majeure est une indexation pour laquelle le concept indexant correspond au sujet princi-pal de la ressource indexée. Dans le cas contraire l’indexation est mineure. Une indexation peut également être affiliée à deux concepts en plus du concept indexant (i.e. indexation post-coordonnée) :

— un concept dit qualificatif permettant de spécifier le sens ou un aspect particulier que doit prendre le concept indexant (i.e. colonne RDF_RESOURCE_INDEX_AFF) ; — un concept indiquant le type de ressources de la ressource indexée (i.e.

correspon-dant à la colonne RDF_RESOURCE_INDEX_AFF).

5.1.1.2 Les tables de modèle Les tables de modèle sont les tables : — TB_MODEL ;

— TB_MODEL_DATATYPE_PROPERTY ; — TB_MODEL_OBJECT_PROPERTY ; — TB_MODEL_INHERITANCE.

Elles permettent de modéliser la sémantique des objets et relations stockées par les tables de données de manière analogue à la partie ontologique du Web sémantique. Elles permetent donc de définir la sémantique du vocabulaire exploité par les descriptions définies dans la partie donnée. Les données stockées constituent ainsi les méta-données. La table TB_OBJECT permet de définir un type d’objet, d’attribut ou de relation, TB_MODEL_DATATYPE_PROPERTY permet de décrire ces types à l’aide d’attributs (e.g. libellés de relation ou d’attribut) et la table TB_MODEL_OBJECT_PROPERTYpermet de définir des relations entre les types d’objets, de relations et d’attributs (e.g. un objet de type ressource bibliographique possède un attribut de type auteur, un objet de type analyse biologique est rattaché à un objet de type patient par une relation r1, la relation r2 est symétrique, etc.).