11.11
Rétro-ingénierie d’une base de données
287
© Dunod – La photocopie non autorisée est un délit.
mentaires : examen du code des programmes d’application, analyse des données
elles-mêmes (voir exercice 11.12), analyse des états imprimés et des écrans et pages
web présentant les données, etc. Dans le cas de notre dernier exemple, le code des
programmes nous apprendra que la colonne IDX est découpée en deux fragments,
dont le premier est utilisé comme clé d’accès à la table TBL_P, suggérant ainsi un
rôle de clé étrangère :
select IDX into :P from TBL_X where substring(IDX from 25 for 18)=:S
select COL_2 from TBL_P where IDP=substring(:P from 1 for 24);
L’examen des écrans de saisie et d’interrogation des données nous en apprendra plus
sur la signification de chaque table et chaque colonne, et nous suggérera des noms
plus explicites. Enfin, une analyse des données de la table TBL_S vérifiera qu’il n’y
existe pas de lignes se partageant la même valeur de IDS. La requête ci-dessous
devrait renvoyer un résultat vide :
select IDS,count(*) from TBL_S group by IDS having count(*) > 1;
c) Le problème de la conceptualisation des structures de données
Si l’interprétation du schéma enrichi s’est avéré très simple dans le cas de la figure
11.13, il n’en va malheureusement pas de même dans la réalité. D’une part, les
modèles utilisés sont plus riches que ceux que nous avons utilisés dans cet ouvrage
(relire la section 9.9), et d’autre part, les développeurs appliquent des règles de
production de structures de données beaucoup plus variées et complexes que celles
que nous avons suggérées dans ce chapitre. Pour compliquer les choses, les bases de
données réelles ont le plus souvent été fortement restructurées pour des raisons
d’optimisation, et comportent des tables non normalisées (pour limiter la fragmentation des données résultant de la décomposition des structures, comme décrit dans les
sections 3.9.2 et 10.10), des redondances (colonnes et tables dont le contenu est
calculé à partir d’autres données de la base) et autres astuces techniques parfois
douteuses qui peuvent compliquer la compréhension des structures de données et la
reconstruction du schéma conceptuel. Enfin, le schéma d’une grande base de
données comporte souvent des structures erronées et des zones mortes, laissées en
place par manque de temps de la part des développeurs successifs.
A titre d’exemple, une propriété multiple (attribut multivalué) sera tout autant
représentée par les techniques de la figure 10.11, qu’on déconseille, que par celles
de la figure 10.12. Le processus de reconstruction du schéma conceptuel, dit de
conceptualisation, repose sur une connaissance approfondie des différentes techniques de traduction de schémas conceptuels effectivement utilisées sur le terrain.
On conseillera au lecteur qui désire approfondir la question la référence [Hainaut,
2002] en guise de point de départ.
Rétro-ingénierie d’une base de données
287
© Dunod – La photocopie non autorisée est un délit.
mentaires : examen du code des programmes d’application, analyse des données
elles-mêmes (voir exercice 11.12), analyse des états imprimés et des écrans et pages
web présentant les données, etc. Dans le cas de notre dernier exemple, le code des
programmes nous apprendra que la colonne IDX est découpée en deux fragments,
dont le premier est utilisé comme clé d’accès à la table TBL_P, suggérant ainsi un
rôle de clé étrangère :
select IDX into :P from TBL_X where substring(IDX from 25 for 18)=:S
select COL_2 from TBL_P where IDP=substring(:P from 1 for 24);
L’examen des écrans de saisie et d’interrogation des données nous en apprendra plus
sur la signification de chaque table et chaque colonne, et nous suggérera des noms
plus explicites. Enfin, une analyse des données de la table TBL_S vérifiera qu’il n’y
existe pas de lignes se partageant la même valeur de IDS. La requête ci-dessous
devrait renvoyer un résultat vide :
select IDS,count(*) from TBL_S group by IDS having count(*) > 1;
c) Le problème de la conceptualisation des structures de données
Si l’interprétation du schéma enrichi s’est avéré très simple dans le cas de la figure
11.13, il n’en va malheureusement pas de même dans la réalité. D’une part, les
modèles utilisés sont plus riches que ceux que nous avons utilisés dans cet ouvrage
(relire la section 9.9), et d’autre part, les développeurs appliquent des règles de
production de structures de données beaucoup plus variées et complexes que celles
que nous avons suggérées dans ce chapitre. Pour compliquer les choses, les bases de
données réelles ont le plus souvent été fortement restructurées pour des raisons
d’optimisation, et comportent des tables non normalisées (pour limiter la fragmentation des données résultant de la décomposition des structures, comme décrit dans les
sections 3.9.2 et 10.10), des redondances (colonnes et tables dont le contenu est
calculé à partir d’autres données de la base) et autres astuces techniques parfois
douteuses qui peuvent compliquer la compréhension des structures de données et la
reconstruction du schéma conceptuel. Enfin, le schéma d’une grande base de
données comporte souvent des structures erronées et des zones mortes, laissées en
place par manque de temps de la part des développeurs successifs.
A titre d’exemple, une propriété multiple (attribut multivalué) sera tout autant
représentée par les techniques de la figure 10.11, qu’on déconseille, que par celles
de la figure 10.12. Le processus de reconstruction du schéma conceptuel, dit de
conceptualisation, repose sur une connaissance approfondie des différentes techniques de traduction de schémas conceptuels effectivement utilisées sur le terrain.
On conseillera au lecteur qui désire approfondir la question la référence [Hainaut,
2002] en guise de point de départ.