La gestion des changements de base de données est le processus
consistant à déterminer les changements qui doivent être apportés à une base
de données, à spécifier ces changements, à évaluer leur impact puis à les déployer.
Des modifications de schéma de base de données peuvent être requises pour un certain nombre de raisons, notamment
des nouvelles exigences métier, des fusions, des nouvelles législations et des modifications
d'application. Les changements de schéma peuvent impliquer des changements à la fois
d'objets de base de données logiques (par exemple, des tables, des colonnes,
des clés primaires ou des contraintes), et d'objets de base de données physiques
(par exemple, bases de données, espaces table, pools de mémoire tampon ou index). La modification d'objets de base de données, quel que soit leur type, est loin d'être une opération
insignifiante.
Elle affecte souvent des objets dépendants et parfois même des données
sous-jacentes. En général, l'analyse et la gestion de ces dépendances est un processus de longue haleine
pouvant occasionner des erreurs.
Considérons un environnement de base de données classique, tel que celui
illustré à la figure suivante, dans lequel de nouvelles applications et
changements de conception de base de données ont été initialement introduits
sur un système de développement dédié, puis validés sur un système de test,
pour enfin être déployés sur le système de production de l'organisation.
Figure 1. Environnement de base de données standard
Bien que la conception d'ensemble des systèmes de développement, de test et de production
soit en principe assez similaire, les règles métier régissant chaque système peuvent s'avérer
différentes. La base de données de production fonctionne selon des règles métier strictes
et doit s'exécuter 24 heures sur 24, 7 jours sur 7. La base de données de test
respecte également des règles métier strictes afin de garantir que les éléments testés
s'exécuteront correctement en production.
Toutefois, la base de données de test
ne nécessite pas le même niveau de disponibilité que le système de production. A la différence
des systèmes de production et de test, la base de données de développement n'est pas soumise à autant
de règles métier car les développeurs doivent y effectuer des changements en permanence. Le processus
de gestion de ces systèmes de base de données disparates oblige souvent l'administrateur de base de données
à effectuer les opérations suivantes :
- Synchroniser le système de développement ou le système de teste pour qu'il soit la copie
fidèle du système de production
- Remonter (ou migrer) des changements d'un système à un autre
- Annuler les changements effectués sur un environnement de base de données
- Créer un modèle de base d'historique à utiliser comme référence par la suite
- Contrôler les changements pour en comprendre les effets
- Gérer le cycle de vie des changements structurels des bases de données
- Comparer deux ensembles d'objets pour déterminer leurs différences
- Analyser l'impact des changements proposés sur une base de données
- Gérer le déploiement des changements sur la base de données cible
- Charger et décharger des données lorsque certains changements nécessitent que des objets soient supprimés
et recréés
- Déplacer des données
- Redéfinir les accès des packages devenus inopérants suite aux changements
- Actualiser ou redéfinir les objets dépendants
La gestion des changements est souvent un processus lent et difficile pour un administrateur de
base de données car il est confronté aux défis suivants :
- L'échec de reconnaissance d'un changement de schéma présente un danger pour l'intégrité du système.
- La recherche de tous les éléments liés aux changements de schéma est difficile.
- L'analyse d'impact des changements de schéma prend beaucoup de temps.
- La migration des données nécessite une planification
minutieuse et extensive avant la migration réelle.
- L'application de changements à une base de
données nécessite une connaissance approfondie de la structure de base de
données.
- L'apprentissage de la syntaxe SQL peut s'avérer difficile.
Un logiciel de gestion des changements peut faciliter ce processus
car il augmente la fiabilité et réduit les possibilités d'erreur humaine.