284
Chapitre 11 • Production du schéma de la base de données
concerne l’enregistrement des données. En revanche, il est possible de construire
une procédure SQL (section 6.5) qui reçoit en argument les données décrivant
l’accident et les références des véhicules impliqués, puis crée la ligne d’ACCIDENT
et une ou plusieurs lignes d’IMPLICATION à partir de ces données. Si celles-ci ne
sont pas correctes, la procédure n’effectue aucune opération. Il faut encore obliger
l’utilisateur à utiliser cette procédure lorsqu’il désire enregistrer un accident, et lui
interdire d’agir directement sur les tables concernée (et de risquer d’enregistrer un
accident sans véhicules), ce qui est du ressort du contrôle d’accès (section 6.1).
Dans les programmes d’application, le programmeur définira une transaction, qui
est une suite d’instructions qui doit être exécutée complétement ou pas du tout, quoi
qu’il arrive. Au sein d’une transaction, des situations d’incohérence de données
peuvent se produire (p. ex. on insère une ligne d’IMPLICATION sans ligne d’ACCIDENT cible, ou l’inverse), pour autant que tout rentre dans l’ordre lorsque la
transaction se termine.
11.11 RÉTRO-INGÉNIERIE D’UNE BASE DE DONNÉES
Les matériaux étudiés dans ce chapitre nous permettent d’aborder un problème
d’importance croissante : la redocumentation, ou plus généralement, la rétro-ingénierie, d’une base de données existante. Il s’agit en résumé de reconstruire le
schéma de tables et le schéma conceptuel d’une base de données dont on a perdu
toute documentation. En caricaturant, on pourrait dire qu’on inverse les techniques
proposées dans ce chapitre, ce qui est en grande partie correct.
Les objectifs d’un tel processus sont variés : maintenance (correction des
programmes utilisant la base de données), évolution (prise en compte de nouveaux
concepts), intégration (d’applications ou de bases de données), portage dans un
autre environnement (MS Access vers SQL Server par exemple), évaluation de la
qualité d’une application (que peut valoir un programme si sa base de données a été
mal conçue ?) ou tout simplement remise en ordre des composants d’une application
(de la part du propriétaire des données avant son départ).
L’idée de base est qu’on ne peut utiliser une base de données que si une documentation correcte et complète est disponible, à défaut de quoi il est nécessaire de
reconstruire celle-ci. A cela s’ajoute l’observation qu’on ne peut comprendre un
programme existant (en vue de sa maintenance par exemple) que si on dispose
d’une documentation de la base de données sur laquelle il travaille.
En pratique, la reconstruction des schémas s’appuie sur des sources d’information qui sont principalement le code DDL (ou le contenu des tables du catalogue), le
code des programmes d’application, les écrans des programmes, les pages web
générées (voir exercice 10.15) et les données elles-mêmes.
a) Première approche
Dans le cas des bases de données que nous avons rencontrées dans cet ouvrage, et
qui résultent de l’application systématique de règles de production rigoureuses, la
reconstruction des deux schémas ne pose guère de problèmes. Il suffit en effet
Chapitre 11 • Production du schéma de la base de données
concerne l’enregistrement des données. En revanche, il est possible de construire
une procédure SQL (section 6.5) qui reçoit en argument les données décrivant
l’accident et les références des véhicules impliqués, puis crée la ligne d’ACCIDENT
et une ou plusieurs lignes d’IMPLICATION à partir de ces données. Si celles-ci ne
sont pas correctes, la procédure n’effectue aucune opération. Il faut encore obliger
l’utilisateur à utiliser cette procédure lorsqu’il désire enregistrer un accident, et lui
interdire d’agir directement sur les tables concernée (et de risquer d’enregistrer un
accident sans véhicules), ce qui est du ressort du contrôle d’accès (section 6.1).
Dans les programmes d’application, le programmeur définira une transaction, qui
est une suite d’instructions qui doit être exécutée complétement ou pas du tout, quoi
qu’il arrive. Au sein d’une transaction, des situations d’incohérence de données
peuvent se produire (p. ex. on insère une ligne d’IMPLICATION sans ligne d’ACCIDENT cible, ou l’inverse), pour autant que tout rentre dans l’ordre lorsque la
transaction se termine.
11.11 RÉTRO-INGÉNIERIE D’UNE BASE DE DONNÉES
Les matériaux étudiés dans ce chapitre nous permettent d’aborder un problème
d’importance croissante : la redocumentation, ou plus généralement, la rétro-ingénierie, d’une base de données existante. Il s’agit en résumé de reconstruire le
schéma de tables et le schéma conceptuel d’une base de données dont on a perdu
toute documentation. En caricaturant, on pourrait dire qu’on inverse les techniques
proposées dans ce chapitre, ce qui est en grande partie correct.
Les objectifs d’un tel processus sont variés : maintenance (correction des
programmes utilisant la base de données), évolution (prise en compte de nouveaux
concepts), intégration (d’applications ou de bases de données), portage dans un
autre environnement (MS Access vers SQL Server par exemple), évaluation de la
qualité d’une application (que peut valoir un programme si sa base de données a été
mal conçue ?) ou tout simplement remise en ordre des composants d’une application
(de la part du propriétaire des données avant son départ).
L’idée de base est qu’on ne peut utiliser une base de données que si une documentation correcte et complète est disponible, à défaut de quoi il est nécessaire de
reconstruire celle-ci. A cela s’ajoute l’observation qu’on ne peut comprendre un
programme existant (en vue de sa maintenance par exemple) que si on dispose
d’une documentation de la base de données sur laquelle il travaille.
En pratique, la reconstruction des schémas s’appuie sur des sources d’information qui sont principalement le code DDL (ou le contenu des tables du catalogue), le
code des programmes d’application, les écrans des programmes, les pages web
générées (voir exercice 10.15) et les données elles-mêmes.
a) Première approche
Dans le cas des bases de données que nous avons rencontrées dans cet ouvrage, et
qui résultent de l’application systématique de règles de production rigoureuses, la
reconstruction des deux schémas ne pose guère de problèmes. Il suffit en effet