LIBD:RAPPORTS

<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-0] 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.

<Return to Publications page>