LIBD:RAPPORTS

Affichages
De LIBD.
(Différences entre les versions)
m
m
Ligne 14 : Ligne 14 :
 
:'''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.
 
:'''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.
 
: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, [http://www.info.fundp.ac.be/~dbm/Documents/Publications-LIBD/Technical-Reports/CODASYL.pdf [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.
  
  
 
[[LIBD:Publications|<''Return to Publications page''>]]
 
[[LIBD:Publications|<''Return to Publications page''>]]

Version du 14 novembre 2010 à 18:17

Page en développement


TECHNICAL REPORTS / RAPPORTS TECHNIQUES


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

Outils personnels