LIBD:RAPPORTS

<Return to Publications page>

Miscelleaneous - Divers

[TR12-01] Jean-Luc Hainaut, Modelling and Metamodelling, draft technical report, June 2012, 44 pages [full text]

Description. This document is a short report that describes some of the contributions of the Database Engineering research group of the PReCISE research center of the University of Namur (aka called LIBD) during the last four decades. It focuses on the models, metamodels, languages and API that have been developed in various domains of Database Engineering. The detail of these results can be found on the research group website. This version is an incomplete draft of the final version.

[TR11-01] Anthony Cleve, Jean-Luc Hainaut. Inter-artefact Analysis for Information System Understanding, DB-MAIN Technical report, January 2011, 14 pages. [description]

Description. Today's information systems are becoming increasingly large and complex, especially because they are made of various inter-dependent artefacts of different nature, belonging to distinct paradigms and abstraction levels. This complexity makes it difficult to \emph{understand} the system in such contexts as quality analysis, reverse engineering, maintenance and evolution. This exploratory paper identifies the pressing necessity of multi-artefact analysis for information system understanding. It presents a generic conceptual framework where inter-artefact dependencies are exploited in order to improve the effectiveness of comprehension processes. It approaches the problem of system understanding from an integrated perspective, and advocates for more intense cross-fertilization between currently isolated research communities.

[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înements 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 structure 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 organisationnelle. 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-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.

[TR84-01] Jean-Luc Hainaut, Le modèle d'accès généralisé, Technical report, Janvier 1984, 66 pages, [full text]

Description. Ce document décrit en détail le modèle d'accès généralisé (MAG), destiné à la représentation de structures de données au niveau logique, indépendamment de la technologie avec laquelle celles-ci sont implémentées. La première partie décrit les objets du modèle : type d'articles, item, type de chemins d'accès, fichier, base de données, clé d'accès et structure d'ordre. Les parties suivantes étudient respectivement l'utilisation du MAG comme expression de la sémantique des structures de données, le langage de désignation de données, les contraintes d'intégrité et les primitives de manipulation de données. Exemples et bibliographie clôturent le rapport. Ce document a servi de base à l'ouvrage Conception assistée des applications informatiques - 2. Conception de la base de données, Masson, 1986

TimeStamp - Understanding, Developing, Processing Temporal Databases (1997-2002)

[TR02-01] Virginie Detienne, Jean-Luc Hainaut. TimeStamp: Volume 1 - Introduction aux bases de données temporelles, rapport final du projet TimeStamp, janvier 2002, 174 pages, [full text]

Description. Les données temporelles font partie des systèmes d’information de nombreux secteurs industriels et administratifs. Elle décrivent les états passés (données historiques), courants et futurs de l’entreprise. Outre leur gestion classique, elles sont notamment utilisées dans le domaine de l’aide à la décision, leur consultation permettant de livrer les lois d’évolution de certains paramètres de l’organisme, tels que l’évolution des ventes, la rotation des employés,...

Malheureusement, l’introduction de la dimension temporelle dans les bases de données les rendent rapidement très complexes, tant au niveau de la gestion que de l’exploitation. De plus, les technologies des bases de données actuellement utilisées (SQL-2 par exemple) offrent peu de support à la gestion de telles données.

Pour répondre à ces difficultés l’objectif du projet TimeStamp est de présenter une méthodologie et des outils d’aide à la gestion et la consultation des données temporelles.

Le volume d’introduction aux bases de données temporelles décrit les particularités de ce type de données, ainsi que la manière de les structurer et de les gérer. Il démontre également la nécessité d’avoir recours à une méthodologie et à des outils pour faciliter le traitement des données temporelles.

L’article "CASE Tool Support for Temporal Database Design" donne un aperçu de l’utilité des outils de gestion des bases de données temporelles. Les modèles, la méthodologie, et les outils y sont présentés de manière succincte.

Le tutoriel "Introduction pratique aux bases de données temporelles" décrit les caractéristiques des données temporelles et initie le lecteur aux principes des structures de données temporelles et de leur traitement en SQL.

Enfin, les exposés qui ont été présentés à des responsables de bases de données de diverses industries et administrations, décrivent succinctement les particularités des données temporelles et les outils destinés à faciliter leur gestion et leur exploitation.

[TR02-02] Virginie Detienne, Jean-Luc Hainaut. TimeStamp: Volume 2 - Méthodologie et exploitation des bases de données temporelles, rapport final du projet TimeStamp, janvier 2002, 290 pages, [full text]

Description. Le volume de "Méthodologie et exploitation des bases de données temporelles" est destiné aux utilisateurs des outils de gestion et de traitement des données temporelles. Il est composé de manuels comprenant la définition des concepts, et la description précise de l’utilisation des outils. Ces descriptions sont illustrées par des études de cas.

Le volume est composé de deux parties. La première concerne la méthodologie de développement des bases de données temporelles, tandis que la seconde est consacrée au traitement des données temporelles.

Méthodologie de développement d’une base de données temporelles

Les modèles temporels conceptuel, logique et physique, utilisés dans le cadre du projet sont d’abord définis.

Une méthode de génération de bases de données temporelles est ensuite proposée. La création des bases de données s’appuyant sur cette méthodologie peut être réalisée de manière semi-automatique à l’aide d’outils spécifiques de l’Outil CASE DB-Main. L’utilisation de ces outils est décrite en détails et illustrée par un exemple.

Différents index ont été testés lors de la consultation des données temporelles. Il en résulte des recommandations de choix d’index.

Traitement des données temporelles

Une API de type ODBC (T-ODBC) a été réalisée afin de faciliter la consultation des données. Elle permet de manipuler les structures temporelles à l’aide d’un langage dérivé de TSQL2, nommé mini-TSQL, en offrant un cadre similaire à celui offert par ODBC. Un manuel de l’utilisateur décrit l’API et définit le langage mini-TSQL.

[TR02-03] Virginie Detienne, Jean-Luc Hainaut. TimeStamp: Volume 3/1 - Documents techniques - Rapports techniques de recherche, rapport final du projet TimeStamp, janvier 2002, 340 pages, [full text]

Description. Le volume "Documents techniques" analyse diverses matières en profondeur. Il décrit les différentes pistes de réflexion qui ont été abordées, justifie les choix effectués, donne des explications techniques,... Il est destiné aux personnes désireuses d’approfondir certains sujets évoqués dans les Volumes 1 et 2, ainsi que celles qui souhaitent avoir des informations techniques concernant les outils.

Le volume est divisé en deux parties. La première comprend des rapports techniques de recherches, tandis que la seconde offre la documentation technique des outils.

Rapports techniques de recherche

Divers thèmes sont abordés dans la première partie.

Les données bitemporelles sont d’abord étudiées. On analyse la façon de représenter des données bitemporelles non valides, passées, courantes et futures.

La structuration des données est ensuite analysée. Les données temporelles peuvent être localisées dans les tables selon différentes stratégies, de façon à optimiser des critères tels que l’occupation d’espace mémoire, la performance des requêtes,... Différentes structures de données sont analysées et trois d’entre elles sont sélectionnées pour la suite des travaux. Ce sont ces trois structures qui sont gérées par l’outil de génération de bases de données temporelles de DB-Main.

Les propriétés temporelles des éléments d’un schéma conceptuel doivent être conservées lors des transformations. L’héritage du caractère temporel des éléments d’un schéma est analysé pour différentes transformations.

Pour être cohérent, un schéma conceptuel temporel doit répondre à certains critères qui sont, notamment, liés à l’aspect temporel des données. Ces différentes règles sont décrites et justifiées.

Un schéma logique temporel peut comprendre des tables d’entités et des tables d’associations. Les historiques de ces deux types de tables ont des propriétés différentes et ne se gèrent pas de la même manière. Les règles concernant les historiques d’associations sont discutées et définies.

Différents modèles ont été décrits dans le cadre du projet TimeStamp. Ils sont comparés avec d’autres modèles répertoriés dans la littérature.

Les langages classiques n’ont pas été conçus pour accéder aux bases de données temporelles. Dans le cadre du projet TimeStamp, un nouveau langage a été spécifiquement élaboré pour consulter ce type de bases de données (mini-TSQL2). :De plus, de nouvelles fonctions de type ODBC (T-ODBC) ont été implémentées afin de permettre l’exécution des requêtes formulées au moyen de ce langage. Les sémantique et syntaxe de mini-TSQL2 sont définies. L’amélioration d’ODBC en T-ODBC est justifiée et décrite. Des opérateurs temporels sont également spécifiés.

Documentation technique des outils

voir partie suivante.

[TR02-04] Virginie Detienne, Jean-Luc Hainaut. TimeStamp: Volume 3/2 - Documents techniques - Documentation technique des outils, rapport final du projet TimeStamp, janvier 2002, 170 pages, [full text]

Description. Les outils de génération de bases de données temporelles sont d’abord décrits. Des patterns de génération de triggers destinés à la gestion de l’aspect temporel des bases de données sont proposés. Une étude sur les performances de ces bases de données générées est ensuite effectuée.

Les outils d’exploitation des bases de données temporelles sont à leur tour documentés.

On décrit d’abord un générateur de scripts SQL de population d’une base de données temporelles, qui est utilisé dans le but d’effectuer des tests sur des bases de données temporelles volumineuses.

Des tests de performance de requêtes d’exploitation types sont ensuite réalisés.

Enfin, la documentation technique de l’API T-ODBC est fournie. Elle décrit les caractéristiques des différents modules.

InterDB - Integration of Legacy Heterogeneous Databases (1995-2002)

TBA soon [ [full text]]

Active databases - Bases de données actives (2000-2002)

[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.

[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-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.

[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.

[TR96-01] Joël Bergmann. Spécification et génération de SIAD dans l'atelier DB-MAIN - Volume 1, Master Thesis, Institut d'informatique, Université de Namur, juin 1996, 170 pages, [full text]

Description. The Entity-Relationship Model (ER model) is currently one of the most used conceptual models for analysing and modeling information systems. This thesis extend the specification of the ER model by adding means to define derivable information : the ER model is endowed with the ability to modelize the fact that certain information in a schema can be inferred from others. The resulting model is called Deductive ER Model. We also describe how to make a deductive ER schema executable by translating automatically the definition rules of derivable information into SQL statements. The submission of these statements on a operational database enables the calculation of the deduced values. The Deductive ER Model has been implemented into the DB-MAIN CASE tool which is dedicated to database application engineering. The integration of the Deductive ER Model in DB-MAIN allows the specification and the generation of little DSSs. Thanks to these, the managers can query, at a conceptual level, the production data in order to deduce the information they need to make their decisions.

A l'heure actuelle, le modèle Entité-Association (modèle EA) est un des modèles conceptuels le plus utilisé pour l'analyse et la modélisation des systèmes d'information. Ce mémoire étend la spécification du modèle EA pour permettre la modélisation d'informations dérivables : on dote le modèle EA de la possibilité d'exprimer que certaines informations d'un schéma peuvent être inférées à partir d'autres. Le modèle ainsi obtenu est appelé modèle EA déductif. On décrit aussi comment rendre un schéma EA déductif exécutable en transformant automatiquement les règles de définition des informations dérivables en requêtes SQL. La soumission de ces requêtes sur une base de données de production permet le calcul effectif des valeurs déduites. Le modèle EA déductif a été implémenté dans l'atelier d'ingénierie de bases de données DB-MAIN. L'intégration du modèle EA déductif dans DB-MAIN permet de spécifier et de générer des SIAD aux possibilités modestes. Grâce à ceux-ci, les gestionnaires peuvent interroger, à un niveau conceptuel, les données de production afin d'en déduire les informations dont ils ont besoin pour prendre leurs décisions.

[TR96-02] Joël Bergmann. Spécification et génération de SIAD dans l'atelier DB-MAIN - Volume 2, Master Thesis, Institut d'informatique, Université de Namur, juin 1996, 112 pages, [full text]

PHENIX - Database Reverse Engineering (1989-1993)

[TR93-01] M. Chandelon, M. Joris, B. Mignon, C. Tonneau, J-L Hainaut, F. Bodart, E. Cardon, F. Osaer, P. Verscheure, R. Van Hoe, J. Vandamme, M. Vanwormhoudt, DATABASE REVERSE ENGINEERING - Volume I: General concepts and Introduction, Final report of the PHENIX project, April 1993, 138 pages [full text]

Description. (TBA).

[TR93-02] M. Chandelon, M. Joris, B. Mignon, C. Tonneau, J-L Hainaut, F. Bodart, E. Cardon, F. Osaer, P. Verscheure, R. Van Hoe, J. Vandamme, M. Vanwormhoudt, DATABASE REVERSE ENGINEERING - Volume II: Reverse engineering, Final report of the PHENIX project, April 1993, 300 pages [full text]

Description. (TBA).

[TR93-03] M. Chandelon, M. Joris, B. Mignon, C. Tonneau, J-L Hainaut, F. Bodart, E. Cardon, F. Osaer, P. Verscheure, R. Van Hoe, J. Vandamme, M. Vanwormhoudt, DATABASE REVERSE ENGINEERING - Volume III: Technical appendices, Final report of the PHENIX project, April 1993, 100 pages [full text]

Description. (TBA).

[TR93-04] M. Chandelon, M. Joris, B. Mignon, C. Tonneau, J-L Hainaut, F. Bodart, E. Cardon, F. Osaer, P. Verscheure, R. Van Hoe, J. Vandamme, M. Vanwormhoudt, Phenix Symposium on Database Reverse Engineering, Proceedings. June 1992, 275 pages [full text]

Description. (TBA).

The SPHINX DBMS - Le SGBD SPHINX (1971-1978)

[TR78-01] Jean-Luc Hainaut, Baudouin Le Charlier, et al. Système de conception et d'exploitation de bases de données - Volume 1 : Modèles et Langages, Rapport final du projet CIPS I2/15 Grandes banques de données administratives, Institut d'informatique, Université de Namur, janvier 1978, 168 pages, [full text] [Project evaluation (just for the pleasure!]

Description. First volume of the final report of a 6-year research projet (1971-1977) devoted to the development of models, languages and DBMS for administrative applications. This volume describes the Entity-relationship conceptual model, the binary logical access model, the data definition language (DDL), the data manipulation language (DML) and the user query language (N.U.L) of the SPHINX DBMS.

[TR78-02] Jean-Luc Hainaut, Baudouin Le Charlier, et al. Système de conception et d'exploitation de bases de données - Volume 2 : Manuels de référence des langages, Rapport final du projet CIPS I2/15 Grandes banques de données administratives, Institut d'informatique, Université de Namur, janvier 1978, 122 pages, [full text]

Description. Second volume of the final report of a 6-year research projet (1971-1977) devoted to the development of models, languages and DBMS for administrative applications. This volume describes the three languages of the SPHINX DBMS: the data definition language (DDL), the data manipulation language (DML) and the user query language (N.U.L).

[TR78-03] Jean-Luc Hainaut, Baudouin Le Charlier, et al. Système de conception et d'exploitation de bases de données - Volume 3 : Une implémentation du modèle d'accès, Rapport final du projet CIPS I2/15 Grandes banques de données administratives, Institut d'informatique, Université de Namur, janvier 1978, 110 pages, [full text]

Description. Third volume of the final report of a 6-year research projet (1971-1977) devoted to the development of models, languages and DBMS for administrative applications. This volume describes the physical data structures of the database. The binary logical access model is mapped on a low-level DBMS (Siemens's SESAM) used as the physical layer ensuring data storage, indexing, valubased querying, concurrency and recovery.

[TR78-04] Jean-Luc Hainaut, Baudouin Le Charlier, et al. Système de conception et d'exploitation de bases de données - Volume 4 : Le système SPHINX, Rapport final du projet CIPS I2/15 Grandes banques de données administratives, Institut d'informatique, Université de Namur, janvier 1978, 230 pages, [full text]

Description. Fourth volume of the final report of a 6-year research projet (1971-1977) devoted to the development of models, languages and DBMS for administrative applications. This volume describes the internals of the SPHINX DBMS. Its sections describes the DDL compiler, the DML compiler, inter-task communications, the SPHINX API, the SPHINX runtime kernel (the server), the NUL query system, recovery, as well as the main exploitation procedures.

[TR78-05] Jean-Luc Hainaut, Baudouin Le Charlier, et al. Système de conception et d'exploitation de bases de données - Volume 5 : Exemples d'applications, Rapport final du projet CIPS I2/15 Grandes banques de données administratives, Institut d'informatique, Université de Namur, janvier 1978, 102 pages, [full text]

Description. Fourth volume of the final report of a 6-year research projet (1971-1977) devoted to the development of models, languages and DBMS for administrative applications. This volume describes two applications of the SPHINX system. The first one is a data dictionary system through which database schemas can be entered interactively, queried and generated in SPHINX DDL. The second application is a management simulator for a manufacturing enterprise.

<Return to Publications page>