Dbm (discuter | contributions) m (→Miscelleaneous - Divers) |
Dbm (discuter | contributions) |
||
(9 révisions intermédiaires par un utilisateur sont masquées) | |||
Ligne 11 : | Ligne 11 : | ||
=='''Miscelleaneous - Divers'''== | =='''Miscelleaneous - Divers'''== | ||
+ | |||
+ | '''[TR12-01]''' Jean-Luc Hainaut, ''Modelling and Metamodelling'', draft technical report, June 2012, 44 pages [http://www.info.fundp.ac.be/~dbm/Documents/Publications-LIBD/Technical-Reports/40th/40th-02(independent).pdf [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. | ||
+ | |||
+ | <!-- | ||
+ | --> | ||
+ | '''[<span id="TR11-01">TR11-01</span>]''' Anthony Cleve, Jean-Luc Hainaut. <u>Inter-artefact Analysis for Information System Understanding</u>, DB-MAIN Technical report, January 2011, 14 pages. [http://www.fundp.ac.be/recherche/publications/page_view/XXXXX/ [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 | '''[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 | ||
Ligne 27 : | Ligne 36 : | ||
: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. | :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''. | :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''. | ||
− | |||
Ligne 96 : | Ligne 104 : | ||
− | '''[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, [http://www.info.fundp.ac.be/~dbm/Documents/Publications-LIBD/Technical-Reports/ActiveDB-Methodologie.pdf [full text]] | + | '''[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, [http://www.info.fundp.ac.be/~dbm/Documents/Publications-LIBD/Technical-Reports/ActiveDB/ActiveDB-Methodologie.pdf [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. | :'''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. | :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. | :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, [http://www.info.fundp.ac.be/~dbm/Documents/Publications-LIBD/Technical-Reports/ActiveDB-Validation.pdf [full text]] | + | '''[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, [http://www.info.fundp.ac.be/~dbm/Documents/Publications-LIBD/Technical-Reports/ActiveDB/ActiveDB-Validation.pdf [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. | :'''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, [http://www.info.fundp.ac.be/~dbm/Documents/Publications-LIBD/Technical-Reports/ActiveDB-Generateur-SQL.pdf [full text]] | + | '''[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, [http://www.info.fundp.ac.be/~dbm/Documents/Publications-LIBD/Technical-Reports/ActiveDB/ActiveDB-Generateur-SQL.pdf [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. | :'''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. | :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, [http://www.info.fundp.ac.be/~dbm/Documents/Publications-LIBD/Technical-Reports/Gestion-Relations-ISA-en-SQL.pdf [full text]] | + | '''[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, [http://www.info.fundp.ac.be/~dbm/Documents/Publications-LIBD/Technical-Reports/ActiveDB/Gestion-Relations-ISA-en-SQL.pdf [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. | :'''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. | :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. | ||
Ligne 114 : | Ligne 122 : | ||
: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. | :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, [http://www.info.fundp.ac.be/~dbm/Documents/Publications-LIBD/Technical-Reports/ | + | '''[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, [http://www.info.fundp.ac.be/~dbm/Documents/Publications-LIBD/Technical-Reports/ActiveDB/Bergmann-vol-1.pdf [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. | :'''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. | :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, [http://www.info.fundp.ac.be/~dbm/Documents/Publications-LIBD/Technical-Reports/ | + | '''[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, [http://www.info.fundp.ac.be/~dbm/Documents/Publications-LIBD/Technical-Reports/ActiveDB/Bergmann-vol-2.pdf [full text]] |
=='''PHENIX - Database Reverse Engineering (1989-1993)'''== | =='''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 [http://www.info.fundp.ac.be/~dbm/Documents/Publications-LIBD/Technical-Reports/PHENIX/Phenix-Vol1-(2012).pdf [full text]] | ||
+ | :'''Description'''. (TBA). | ||
− | '''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 [http://www.info.fundp.ac.be/~dbm/Documents/Publications-LIBD/Technical-Reports/PHENIX/Phenix-Vol2-(2012).pdf [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 [http://www.info.fundp.ac.be/~dbm/Documents/Publications-LIBD/Technical-Reports/PHENIX/Phenix-Vol3-(2012).pdf [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 [http://www.info.fundp.ac.be/~dbm/Documents/Publications-LIBD/Technical-Reports/PHENIX/Phenix-Symposium.pdf [full text]] | ||
+ | :'''Description'''. (TBA). | ||
=='''The SPHINX DBMS - Le SGBD SPHINX (1971-1978)'''== | =='''The SPHINX DBMS - Le SGBD SPHINX (1971-1978)'''== | ||
Ligne 148 : | Ligne 168 : | ||
'''[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, [http://www.info.fundp.ac.be/~dbm/Documents/Publications-LIBD/Technical-Reports/SPHINX/SPHINX-Volume-5.pdf [full text]] | '''[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, [http://www.info.fundp.ac.be/~dbm/Documents/Publications-LIBD/Technical-Reports/SPHINX/SPHINX-Volume-5.pdf [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 | + | :'''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. |
[[LIBD:Publications|<''Return to Publications page''>]] | [[LIBD:Publications|<''Return to Publications page''>]] |
[TR12-01] Jean-Luc Hainaut, Modelling and Metamodelling, draft technical report, June 2012, 44 pages [full text]
[TR11-01] Anthony Cleve, Jean-Luc Hainaut. Inter-artefact Analysis for Information System Understanding, DB-MAIN Technical report, January 2011, 14 pages. [description]
[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
[TR10-01] Jean-Luc Hainaut, Conceptual interpretation of foreign keys, DB-MAIN Technical report, May 2010, 60 pages, [full text]
[TR03-01] Jean-Luc Hainaut, Introduction aux SGBD CODASYL DBTG 71, DB-MAIN Technical report, September 2003, 60 pages, [full text]
[TR84-01] Jean-Luc Hainaut, Le modèle d'accès généralisé, Technical report, Janvier 1984, 66 pages, [full text]
[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]
[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]
[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]
[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]
TBA soon [ [full text]]
[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]
[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]
[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]
[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]
[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]
[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]
[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]
[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]
[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]
[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]
[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!]
[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]
[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]
[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]
[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]