Chapitre 3:

Réingénierie des données

II3-GL
Motivations
Toutes les entreprises se trouvent confrontées à la nécessité de mettre
en place de nouvelles applications ou de transférer des données vers
d’autres systèmes,
La consolidation de données issues de systèmes informatiques
hétérogènes constitue un défi majeur, puisque les structures source et
cible sont souvent très différentes.
Le changement continu des besoins du client ( les techniques Agiles)
La mauvaise qualité des données existantes (présence de doublons,
d’erreurs ou de structures de données différentes entre les systèmes
source et cible, par exemple) complique considérablement la
transformation de données.

→ Le besoin des projets de la Réingénierie des

Données
1. Définition
La ré-ingénierie des données a pour objectif la re-
conception et la ré-implémentation d’une collection
de (fichiers) de données provenant de sources
anciennes (legacy/hérité), vers une autre forme de
données.
Elle vise à :
– améliorer de manière significative la qualité et l’accessibilité
des données,
– fournir des données ou des bases de données qui répondent
à des nouvelles exigences des entreprises
en se basant sur
▪ La migration des données
▪ Database Refactoring
2. Database Refactoring
Qu’est ce que c’est?

Database Refactoring est une technique qui permet la livraison

continue (Continuous Delivery).
Database Refactoring est une technique qui prend en charge
les processus de développement évolutifs.
Database Refactoring est une simple modification d'un schéma
de base de données qui améliore sa conception tout en
conservant sa dimension comportementale et informationnelle.
En d'autres termes, vous ne pouvez pas ajouter de nouvelles
fonctionnalités ou casser des fonctionnalités, vous ne pouvez
pas non plus ajouter de nouvelles données ou modifier la
signification des données.
2. Database Refactoring
Qu’est ce que c’est?

Database Refactorings sont conceptuellement plus difficiles que

les code Refactorings : Code refactoring n‘a besoin que de
maintenir la sémantique comportementale, alors que Database
Refactorings doivent également maintenir une sémantique
informationnelle.
2. Database Refactoring
Qu’est ce que c’est?
2. Database Refactoring
Database Smells
De la même manière que code smells, il existe des database
Smells courantes qui indiquent le besoin potentiel de la
database refactoring:

➢ Multipurpose column (Colonne polyvalente): Si une colonne est utilisée à

plusieurs fins, il est probable qu'un code supplémentaire existe pour
garantir que les données source sont utilisées de la « bonne manière »,
souvent en vérifiant les valeurs d'une ou plusieurs autres colonnes.

Par exemple, une colonne peut être utilisée pour stocker la date de naissance
d'une personne si elle est un client ou la date de début si cette personne est un
employé. Pire encore, vous êtes probablement limité dans les fonctionnalités
que vous pouvez désormais prendre en charge. Par exemple, comment
stockeriez-vous la date de naissance d'un employé ?
2. Database Refactoring
Database Smells
➢ Multipurpose table (Table polyvalente): De même, lorsqu'une table est
utilisée pour stocker plusieurs types d'entités, il y a probablement un défaut
de conception.

Par exemple, une table Customer générique qui est utilisée pour stocker des
informations sur les personnes et les sociétés. Le problème avec cette
approche est que les structures de données pour les personnes et les
entreprises diffèrent: les personnes ont un prénom, un deuxième nom et un
nom de famille, par exemple ; alors qu'une société a simplement un nom légal.
Une table Customer générique aurait des colonnes NULL pour certains types
de clients mais pas pour d'autres.
2. Database Refactoring
Database Smells
➢ Redundant data (Redondance des données): Les données redondantes
sont un problème sérieux dans les bases de données opérationnelles car
lorsque les données sont stockées à plusieurs endroits, le risque
d'incohérence se produit. Par exemple, il est assez courant de découvrir
que les informations sur les clients sont stockées dans de nombreux
endroits différents au sein de votre organisation. En fait, de nombreuses
entreprises sont incapables de dresser une liste précise de qui sont
réellement leurs clients. Le problème est que dans une table, John Smith
habite au 123 Main Street, et dans une autre table au 456 Elm Street. Dans
ce cas, il s'agit en fait d'une personne qui habitait au 123, rue Main mais qui
a déménagé l'an dernier; Malheureusement, John n'a pas soumis deux
formulaires de changement d'adresse à votre entreprise, un pour chaque
demande qui le connaît
2. Database Refactoring
Database Smells
➢ Tables with too many columns (Tables avec trop de colonnes): Lorsqu'une
table a plusieurs colonnes, cela indique qu'elle manque de cohésion, qu'elle
essaie de stocker des données de plusieurs entités. Peut-être que votre
table Client contient des colonnes pour stocker trois adresses différentes
(expédition, facturation, saisonnière) ou plusieurs numéros de téléphone
(domicile, travail, portable, etc.). Vous devrez probablement normaliser
cette structure en ajoutant des tables Address et PhoneNumber.
2. Database Refactoring
Database Smells
➢ Tables with too many rows (Tables avec trop de lignes): Les grandes tables
indiquent des problèmes de performances.

Par exemple, la recherche d'une table avec des millions de lignes prend du
temps. Vous souhaiterez peut-être diviser le tableau verticalement en
déplaçant certaines colonnes dans un autre tableau, ou le diviser
horizontalement en déplaçant certaines lignes dans un autre tableau. Les deux
stratégies réduisent la taille de la table, améliorant potentiellement les
performances
2. Database Refactoring
Database Smells
➢ “Smart” column (Colonnes « intelligentes » ): Une colonne intelligente est
une colonne dans laquelle différentes positions dans les données
représentent différents concepts.
Par exemple, si les quatre premiers chiffres de l'ID client indiquent la branche
d'origine du client, l'ID du client est une colonne intelligente car vous pouvez
l'analyser pour découvrir des informations plus détaillées (par exemple, l'ID de
la branche d'origine). Un autre exemple inclut une colonne de texte utilisée
pour stocker des structures de données XML, clairement, vous pouvez
analyser la structure de données XML pour des champs de données plus
petits. Les colonnes intelligentes doivent souvent être réorganisées dans leurs
champs de données constitutifs à un moment donné afin que la base de
données puisse facilement les traiter en tant qu'éléments séparés.
2. Database Refactoring
Database Smells
➢ Fear of change (Avoir Peur du changement): Si vous avez peur de changer
votre schéma de base de données parce que vous avez peur de casser
quelque chose, par exemple les 50 applications qui y accèdent, c'est le
signe le plus sûr que vous devez refactoriser votre schéma. La peur du
changement est une bonne indication que vous avez un risque technique
sérieux sur vos mains, un risque qui ne fera qu'empirer avec le temps.
2. Database Refactoring
Database Refactoring Categories
Database Description Example(s)
Refactoring
Category
Structurelle Une modification de la Déplacer une colonne d'une
définition d'une ou table à une autre ou diviser
plusieurs tables ou une colonne polyvalente en
vues plusieurs colonnes distinctes,
une pour chaque objectif.
Qualité des Un changement qui Rendre une colonne non
données améliore la qualité nullable pour s'assurer qu'elle
des informations contient toujours une valeur ou
contenues dans une appliquer un format commun à
base de données une colonne pour assurer la
cohérence
Intégrité Une modification qui ajout d'un trigger pour permettre
référentielle garantit qu'une ligne une suppression en cascade entre
2. Database Refactoring
référencée existe dans une
autre table et/ou qui garantit
deux entités, code qui était
auparavant implémenté en dehors
qu'une ligne qui n'est plus de la base de données.
D tabase Refactoring Categories
nécessaire est supprimée
de manière appropriée

Architecturale Un changement qui améliore remplacement d'une opération Java

la manière globale dont les
programmes externes
interagissent avec une base
de données.
existante dans une bibliothèque de
code partagé avec une procédure
stockée dans la base de données.
L'avoir en tant que procédure stockée
le rend disponible pour les
applications non Java

Méthode Modification d'une méthode Renommer une procédure stockée

(une procédure stockée, une pour la rendre plus facile à
fonction stockée ou un comprendre.
déclencheur) qui améliore sa
qualité. De nombreuses
refactorisations de code sont
applicables aux méthodes de
base de données.
2. Database Refactoring
Comment rendre plus facile le database refactoring?

Databases are highly coupled to external programs.

2. Database Refactoring
Comment rendre plus facile le database refactoring?

Reducing coupling via encapsulating access..

2. Database Refactoring
Database refactoring process

TDDD: Test Driven Database Development

2. Database Refactoring
Comment rendre plus facile le database refactoring?

Reducing coupling via encapsulating access.

2. Database Refactoring
Exemple: A banking application

The initial database schema for Customer and Account

2. Database Refactoring
Exemple: A banking application

1. Vérifier la nécessité de refactoring.

2. Choisir la technique de refactoring à appliquer (Move Column
refactoring)
3. la paire exécute d'abord tous les tests pour voir qu'ils réussissent
4. Ensuite, ils écrivent un test car ils adoptent une approche de
développement piloté par les tests (TDD). Un test probable consiste à
accéder à une valeur dans la colonne Account.Balance.
5. Après avoir exécuté les tests et les avoir vus échouer, ils introduisent
la colonne Account.Balance,
6. ils réexécutent les tests et voient que les tests réussissent maintenant.
Ils refactorisent ensuite les tests existants, qui vérifient que les dépôts
des clients fonctionnent correctement avec la colonne
Account.Balance plutôt que la colonne Customer.Balance.
2. Database Refactoring
Exemple: A banking application
7.Ils constatent que ces tests échouent et retravaillent donc la fonctionnalité
de dépôt pour qu'elle fonctionne avec Account.Balance. Ils apportent des
modifications similaires à d'autres codes de la suite de tests et de
l'application, tels que la logique de retrait, qui fonctionne actuellement avec
Customer.Balance.
8.une fois l'application exécutée à nouveau, ils sauvegardent les données
dans Customer.Balance, à des fins de sécurité, puis copient les données de
Customer.Balance dans la ligne appropriée de Account.Balance.
9.Ils réexécutent leurs tests pour vérifier que la migration des données s'est
bien déroulée. Pour terminer les modifications du schéma, la dernière étape
consiste à supprimer la colonne Customer.Balance, puis à réexécuter tous
les tests et à corriger tout ce qui est nécessaire. Quand ils ont fini de le faire,
ils promeuvent leurs changements dans l'environnement d'intégration du
projet comme décrit précédemment.
2. Database Refactoring
Exemple: A banking application

The final database schema for Customer and Account

2. Database Refactoring
Exemple: A banking application

The database schema during the transition period

 2. Database Refactoring
Exemple: Drop column
Supprimer une colonne dans une
table existance

Risques majeurs :
- La colonne à supprimer peut
contenir des données
- La table contient plusieurs lignes
2. Database
Refactoring
Exemple: Drop
column
2. Database
Refactoring
Exemple: Drop
column
2. Database
Refactoring
Exemple: Drop table