LIBD:RAPPORTS

Version du 5 décembre 2010 à 12:39

<Return to Publications page>

[TR10-02] Jean-Luc Hainaut, Anne-France Brogneaux, Anthony Cleve, Base de modèles pour les itinéraires de soins, draft technical report, GISELE project, February 2009

Description. Le projet GISELE est consacré à la modélisation et à la validation d’itinéraires de soins en cancérologie. Ce document est un rapport technique qui propose un schéma conceptuel pour la base de modèles du logiciel Gisele destiné à la gestion et à la vali-dation d’itinéraires de soins. Il décrit les phases successives de l’analyse des besoins avant de procéder à l’intégration des concepts relevés en un schéma conceptuel global. Les choix de modélisation sont justifiés soit par des raisons de qualité du schéma projeté soit pour leur adéquation aux spécificité du domaine modélisé. En particulier, à plusieurs occasions, un arbitrage a dû être fait entre l’expressivité du schéma et sa généricité. Le critère d’évolutivité du schéma, et donc de la base de modèles, a souvent été prédominant.

Ce rapport décrit la modélisation des différents composants d’un itinéraire de soins, notamment les processus et leurs tâches, les points de décision, les enchaîne-ments entre tâches. S’inspirant des modèles publiés dans la littérature (en particulier le standard BPMN), il les simplifie et les généralise de manière à permettre la repré-sentation des situations standard mais aussi des cas de figures plus complexes tels que les workflows dynamiques par exemple.

Les itinéraires de soins sont ensuite inscrits dans leur contexte, celui de la struc-ture organisationnelle pour laquelle (et dans laquelle) ils sont appliqués. Cette structure est constituée d’unités organisationnelles, qui comprennent également les personnes, qu’il s’agisse du personnel soignant ou des patients. On y décrit les hiérarchies et les rôles qui définissent cette structure.

Les processus consomment des ressources qui sont fournies par la structure orga-nisationnelle. Ces ressources sont classées en types et font l’objet de contraintes de disponibilité ou de partageabilité par exemple.

Les processus produisent et utilisent des données. Celles-ci peuvent être locales à un processus ou externes, telle une base de données. Le domaine médical fait usage de données de natures très diverses, y compris sur support non électronique. Il convient de modéliser ces différentes variantes et de définir les informations qu’elles apportent et les propriétés techniques dont la connaissance permet d’y accéder. Les données sont transmises selon diverses modalités. Par exemple, les processus se transmettent des données lors de leur exécution.

La trace des exécutions d’un processus peut constituer une source d’information importante, par exemple pour expliquer ou contrôler certains comportements de l’organisation ou encore pour induire des modification du processus.

L’évolution des besoins de l’organisation et du contexte des processus va entraîner l’évolution conjointe de la définition de ces processus. On modélise ces évolutions ainsi que les états successifs de ces définitions. Un processus en cours d’exécution mais dont la définition est modifiée pose des problèmes spécifiques qui doivent être décrits et modélisés avec précision.

Un processus représentant un mode de résolution d’une classe de problèmes doit pouvoir être spécialisé à un contexte spécifique, voire à un individu. Il faut donc modéliser la spécialisation et la personnalisation d’un processus.

Tous les aspects d’un processus complexe n’intéressent pas chaque intervenant de l’organisation. On définira pour ceux-ci des vues du processus ne reprenant que les concepts pertinents.

La dimension temporelle est omniprésente dans les processus ainsi que dans les concepts de l’environnement de ceux-ci (données, traces, évolution). Le temps doit donc faire l’objet d’une description cohérente au travers de tous ces concepts.

La sensibilité des données et les processus du domaine médical exige un contrôle strict des accès. On analysera plusieurs politiques de sécurité et on proposera pour chacune une modélisation appropriée.

Conformément à l’objectif du projet, la validation d’un itinéraire de soins doit pouvoir être réalisé selon différents critères. Les critères et les procédures de validation ainsi que leurs résultats doivent être modélisés.

Le schéma global intégrera ces aspects de manière cohérente. Il sera validé par l’étude de la représentation sans pertes des itinéraires de soins ayant fait l’objet des études de validation par les autres équipes du projet.

Ce document est suivi d’un second rapport technique consacrés à la base de modèles : 2. Implémentation et utilisation de la base de modèles.

[TR10-01] Jean-Luc Hainaut, Conceptual interpretation of foreign keys, DB-MAIN Technical report, May 2010, 60 pages, [full text]

Description. Foreign keys form a major structuring construct in relational databases and in standard files. In reverse engineering processes, they have long been interpreted as the implementation of many-to-one relationship types. Though one could naively think they are useless, or at least unnecessary, in hierarchical and network models, foreign keys also appear very frequently in IMS, CODASYL, TOTAL/IMAGE and even in OO databases. Besides the standard version of foreign key, according to which a set of columns (fields) in a table (file) is used to designate rows (records) in another table, a careful analysis of existing (both modern and legacy) databases puts into light a surprisingly large variety of non standard forms of foreign keys. Most of them are quite correct, and perfectly fitted to the requirements the developer had in mind. However, their conceptual interpretation can prove much more difficult to formalize than the standard forms.

The aim of this study is to classify, to analyze and to interpret some of the most frequent variants of foreign keys that have been observed in operational files and databases.

[TR03-02] Anne-France Brogneaux, Jean-Luc Hainaut. Une approche complète de représentation des relations ISA en SQL2, rapport final du projet Active Database, mars 2003, 19 pages, [full text]

Description. Les relations is-a sont des constructions de base proposées dans la plupart des modèles conceptuels de systèmes d’information. Mais très peu de systèmes de gestion de bases de données permettent de les représenter complètement. Trois techniques neutres de transformation des relations is-a sont traditionnellement proposées : la matérialisation, où chaque sous-type est représenté par un type d’entités indépendant relié au surtype par un type d’associations un-à-un, l’héritage ascendant, où seul le surtype est représenté, et l’héritage descendant, où seuls les sous-types sont représentés. Chacune de ces techniques a des avantages et des inconvénients. Après l’élimination des relations is-a, il faut encore traduire le schéma conceptuel en structures conformes au modèle relationnel. Enfin, il faut coder ces structures. A chacune de ces étapes, plusieurs écueils peuvent se rencontrer, qui ne sont pas toujours évités, ni même évitables.

Si on prend comme exemple l’atelier logiciel DB-MAIN, on constate que ces écueils sont bien réels. Il propose, comme transformation neutre, la transformation par matérialisation : les types d’entités sont préservés, et la relation is-a est remplacée par autant de types d’associations un-à-un qu’il y a de sous-types. Ensuite, ces types d’associations peuvent être transformés en attributs de référence. Si la relation is-a était soumise à une contrainte de totalité, disjonction ou partition, des attributs indicateurs de sous-types, facultatifs, sont créés dans le surtype afin de supporter la contrainte d’existence (at-least-one, exclusivity, exactly-one) correspondant à la contrainte définie sur les sous-types. A ce stade, la modélisation est incomplète : la sémantique des attributs indicateurs de sous-types n’est pas indiquée, à savoir que l’indicateur de sous-type ne reçoit une valeur (à déterminer) que si l’entité courante appartient au sous-type désigné par cet attribut. Une fois ce schéma logique obtenu, c’est à l’utilisateur de générer le code correspondant. Sans indication de la sémantique complète de la structure résultant de la relation is-a, ce code sera forcément incomplet.

Même dans les cas où les structures proposées pour traduire les relations is-a sont complètes et correctes, on constate que la tâche de l’utilisateur est loin d’être aisée. En effet, quelle que soit la transformation choisie (matérialisation, héritage ascendant ou héritage descendant), l’encodage et la manipulation des données sont fastidieux. Prenons par exemple le cas de la matérialisation, où, dans le meilleur des cas, il faudra insérer une ligne dans deux tables, dans un ordre prédéfini afin de respecter les contraintes référentielles, pour créer une seule entité. De même, dans le cas de l’héritage descendant sans disjonction des sous-types, des données devront être dupliquées dans plusieurs tables afin de décrire une seule et même entité. Sans parler de la complexité des contraintes s’appliquant à de telles structures, transformant souvent en parcours du combattant la simple création d’une entité dans la base de données.

Pour tenter de répondre à toutes ces remarques, nous proposons une démarche qui englobe l’ensemble du processus de conception d’une base de données relationnelle : de la normalisation d’un schéma conceptuel contenant des relations is-a à la génération d’un code opérationnel et complet, prenant en compte toutes les contraintes inhérentes à ces structures, en passant par la conception logique et la conception physique. Notre objectif est double : d’une part, proposer la transformation automatique des relations is-a en structures compatibles avec le modèle relationnel d’Oracle (schémas et code implémentant ces schémas), et d’autre part, fournir à l’utilisateur un système intuitif, demandant peu d’investissement de sa part par rapport à l’utilisation habituelle d’une base de données relationnelle.

[TR03-01] Jean-Luc Hainaut, Introduction aux SGBD CODASYL DBTG 71, DB-MAIN Technical report, September 2003, 60 pages, [full text]

Description. Ce document a pour objectif d'introduire le lecteur aux principes des Systèmes de Gestion de Bases de Données (SGBD) s'inspirant des recommandations de CODASYL qui ont été publiées en 1971 (CODASYL,71). Il n'a pas la prétention de se substituer à ce rapport, ni a fortiori à la documentation accompagnant les SGBD concernés. Ceci d'autant plus que les réalisateurs de SGBD ont souvent pris quelques libertés par rapports aux recommandations CODASYL, et qu'en outre ces dernières pêchent souvent par imprécision, ambiguïté et même contradiction. Signalons encore que si les SGBD installés se réfèrent en général aux recommandations présentées dans ce document, il en existe d'autres qui s'inspirent de recommandations plus récentes, émanant de CODASYL ou de l'ANSI. Le rapport CODASYL 71 restant muet quant à la spécification des paramètres d'implantation physique des données, nous présenterons les principes proposés par le SGBD DBMS-20 de DEC, qui appartient à la famille d'IDMS de CULLINET. Précisons enfin que nous n'aborderons pas le problème de la conception d'une base de données CODASYL ni celui de la programmation sur bases de données.

[TR01-03] Anne-France Brogneaux, Jean-Luc Hainaut. Générateur SQL paramétrique, rapport final du projet Active Database, février 2001, 57 pages, [full text]

Description. Le générateur SQL paramétrique est un module annexe à DB-MAIN exécuté à partir d’un schéma physique d’une base de données relationnelle, afin d’obtenir le code de création de la base de données et de la gestion des contraintes d’intégrités liées à ce schéma. Le générateur est déclaré paramétrique car il permet à l’utilisateur un choix très fin des paramètres de génération : choix du SGBD cible, choix des contraintes à générer, choix des techniques de codage. Il ne s'agira donc pas uniquement de traduire la totalité des contraintes dans le DDL du SGBD cible choisi, qui est en général impuissant à traduire un certain nombre de contraintes complexes, mais à exprimer ces contraintes selon diverses techniques, ce qui donnera des fragments procéduraux additionnels. Les différentes contraintes du schéma pourront donc être codées selon six techniques différentes : les commentaires (qui ne sont pas vraiment une technique d'implémentation, mais qui peuvent être utilisés pour signaler l'existence d'une contrainte), les techniques natives, les checks, les views with check option, les triggers, et les stored procedures.

La structure de ce document est la suivante. Dans cette première partie, nous allons passer en revue les quelques éléments techniques nécessaires à la génération, essentiellement les différents mécanismes offerts par les SGBD pour gérer les contraintes d’intégrité. Ensuite, nous nous attacherons plus précisément au fonctionnement du générateur proprement dit. Dans la seconde partie, nous nous attarderons sur la description des contraintes d’intégrité contenues dans un schéma physique d’une base de données relationnelle, leur conséquence sur les actions sur la base de données, et la façon dont elles sont exprimées dans l’atelier DB-MAIN. Enfin, dans la dernière partie, nous passerons à la génération proprement dite du code SQL pour les contraintes décrites dans la deuxième partie, et pour le SGBD Oracle, le seul a être implémenté pour le moment.

[TR01-02] Anne-France Brogneaux, Jean-Luc Hainaut. Validation de règles actives - Etat de l’art et prototypes d’outils, rapport final du projet Active Database, février 2001, 36 pages, [full text]

Description. La littérature concernant les règles et bases de données actives est extrêmement abondante, contrairement aux outils d’aide à la conception, qui eux, sont très peu nombreux et très ciblés. Le domaine de la validation de réseaux de règles actives est particulièrement délicat. Dans cette première partie, nous ferons une synthèse de ce qui existe dans le domaine des bases de données actives, et plus particulièrement de la validation des règles qui les composent. Après une brève introduction situant les notions de règle et de base de données actives, nous nous attacherons aux questions concernant la représentation et la validation de systèmes de bases de données actives. La seconde partie de ce document présentera les prototypes développés autour de l’atelier DB-MAIN et permettant de représenter une base de données active, de l’analyser et de la valider. La troisième et dernière partie présente une bibliographie détaillée principalement axée sur la validation et la représentation des systèmes actifs.

[TR01-01] Anne-France Brogneaux, Jean-Luc Hainaut. Bases de données actives et règles de comportement - Eléments méthodologiques et étude de cas, rapport final du projet Active Database, février 2001, 152 pages, [full text]

Description. Dans cette étude de cas, nous allons développer un système de bases de données actives permettant de gérer les quelques grandes opérations d’une entreprise de vente par correspondance. Cette entreprise, comme la plupart des entreprises, est soumise à un certain nombre de contraintes. Parmi elles, nous nous attacherons aux règles de comportement.

Une règle de comportement, aussi appelée règle de gestion, détermine la façon dont un objet réagit de lui-même (sans intervention de l’utilisateur) à un événement quelconque survenant lors de l’exécution de l’application dont il fait partie. L’objet est à prendre ici dans un sens très large : du plus abstrait (un objet métier, comme un client, un bon de commande, une facturation, etc.) au plus concret (une table, voire une colonne de table). Les événements, suivant le niveau d’abstraction de l’objet sur lequel ils portent, peuvent aussi être très divers : un événement système, une action d’un utilisateur, une instruction de l’application, un message, un événement sur la base de données, un événement calendrier, etc. Les règles de comportement peuvent être très complexes et influencer d’autres objets, qui se verront à leur tour obligés de réagir selon leurs propres règles de comportement.

L’objectif de cette étude de cas sera donc de partir de la description d’un domaine d’application, d’isoler les règles de comportement s’y rapportant, et de concevoir le système de base de données active implémentant le domaine d’application et les règles.

<Return to Publications page>