286
Chapitre 11 • Production du schéma de la base de données
d’associations. On retravaillera également les noms de manière à les rendre plus
représentatifs des concepts qu’ils désignent.
Sur le terrain cependant, la rétro-ingénierie est loin de se présenter de manière
aussi simpliste. Des contraintes techniques que nous avons ignorées jusqu’ici, ainsi
que certaines pratiques de développement et de programmation viennent compliquer le processus. Nous allons évoquer brièvement ces problèmes ainsi que les
solutions qui peuvent y être apportées.
Figure 11.14 - La simple analyse du code DDL ne suffit pas toujours à retrouver le
véritable schéma de tables
b) Le problème de l’extraction des structures de données
Souvent, le code DDL n’exprime qu’une partie seulement des objets du schéma de
tables, et parfois d’une manière obscure. Le texte DDL de la figure 11.14 décrit une
base de données de même contenu que celle du schéma 11.12. Cependant, le schéma
de tables est à la fois plus pauvre et malaisé à interpréter, notamment en raison de
conventions de dénomination peu expressives ("TBL_P" = "table PAYS", "IDX" =
"identifiant de la table EXPORT", etc.). On observe que les identifiants n’ont pas été
déclarés en tant que tels, mais via des index (unique). En outre, l’un d’eux, celui de
TBL_S n’a pas été déclaré. Il en est de même des clés étrangères, dont le texte ne
contient aucune trace. Enfin, les deux colonnes de EXPORT ont été fusionnées en
une seule.
Il est probable que cette base de données est relativement ancienne, datant d’une
époque où les concepts d’identifiants primaires et de clés étrangères n’étaient pas
pris en charge par les SGBD. Il se peut aussi qu’elle résulte de la conversion
d’anciens fichiers, soumis à des règles de dénomination drastiques (par exemple,
noms des champs de 8 caractères maximum) et imposant qu’un index soit défini sur
un seul champ (contrainte des fichiers COBOL). Il semble aussi que le programmeur ait cherché à optimiser le schéma, notamment en ne déclarant pas l’identifiant
de TBL_S (= SECTEUR) qui comporte sans doute trop peu de lignes pour mériter un
index, et donc un identifiant.
Retrouver le véritable schéma de la base de données, c’est-à-dire celui de la
figure 11.12 (droite), est l’objectif du processus nommé extraction des structures de
données. Le premier schéma issu de l’analyse du code DDL est progressivement
enrichi des découvertes qu’on fera grâce à l’analyse des informations complécreate table TBL_P (
IDP char(24) not null,
COL_2 numeric(12) not null);
create table TBL_X (
IDX char(42) not null);
create table TBL_S (
IDS char(18) not null,
COL_2 numeric(14) not null);
create unique index ID_P on TBL_P(IDP);
create unique index ID_X on TBL_X(IDX);
⇒
TBL_X
IDX
id': IDX
acc
TBL_S
IDS
COL_2
TBL_P
IDP
COL_2
id': IDP
acc
Chapitre 11 • Production du schéma de la base de données
d’associations. On retravaillera également les noms de manière à les rendre plus
représentatifs des concepts qu’ils désignent.
Sur le terrain cependant, la rétro-ingénierie est loin de se présenter de manière
aussi simpliste. Des contraintes techniques que nous avons ignorées jusqu’ici, ainsi
que certaines pratiques de développement et de programmation viennent compliquer le processus. Nous allons évoquer brièvement ces problèmes ainsi que les
solutions qui peuvent y être apportées.
Figure 11.14 - La simple analyse du code DDL ne suffit pas toujours à retrouver le
véritable schéma de tables
b) Le problème de l’extraction des structures de données
Souvent, le code DDL n’exprime qu’une partie seulement des objets du schéma de
tables, et parfois d’une manière obscure. Le texte DDL de la figure 11.14 décrit une
base de données de même contenu que celle du schéma 11.12. Cependant, le schéma
de tables est à la fois plus pauvre et malaisé à interpréter, notamment en raison de
conventions de dénomination peu expressives ("TBL_P" = "table PAYS", "IDX" =
"identifiant de la table EXPORT", etc.). On observe que les identifiants n’ont pas été
déclarés en tant que tels, mais via des index (unique). En outre, l’un d’eux, celui de
TBL_S n’a pas été déclaré. Il en est de même des clés étrangères, dont le texte ne
contient aucune trace. Enfin, les deux colonnes de EXPORT ont été fusionnées en
une seule.
Il est probable que cette base de données est relativement ancienne, datant d’une
époque où les concepts d’identifiants primaires et de clés étrangères n’étaient pas
pris en charge par les SGBD. Il se peut aussi qu’elle résulte de la conversion
d’anciens fichiers, soumis à des règles de dénomination drastiques (par exemple,
noms des champs de 8 caractères maximum) et imposant qu’un index soit défini sur
un seul champ (contrainte des fichiers COBOL). Il semble aussi que le programmeur ait cherché à optimiser le schéma, notamment en ne déclarant pas l’identifiant
de TBL_S (= SECTEUR) qui comporte sans doute trop peu de lignes pour mériter un
index, et donc un identifiant.
Retrouver le véritable schéma de la base de données, c’est-à-dire celui de la
figure 11.12 (droite), est l’objectif du processus nommé extraction des structures de
données. Le premier schéma issu de l’analyse du code DDL est progressivement
enrichi des découvertes qu’on fera grâce à l’analyse des informations complécreate table TBL_P (
IDP char(24) not null,
COL_2 numeric(12) not null);
create table TBL_X (
IDX char(42) not null);
create table TBL_S (
IDS char(18) not null,
COL_2 numeric(14) not null);
create unique index ID_P on TBL_P(IDP);
create unique index ID_X on TBL_X(IDX);
⇒
TBL_X
IDX
id': IDX
acc
TBL_S
IDS
COL_2
TBL_P
IDP
COL_2
id': IDP
acc