LIBD:RAPPORTS

Version du 4 décembre 2010 à 21:24

<Return to Publications page>

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