>>>> Merci de noter toutes remarques concernant ce cours dans le sujet parallèle : [Cours papyturbo]Commentaires, remarques et suggestions
-------------------------------------------------------------------------
Ce cours est la suite
- du [Cours pt-01][Débutants]Analyse structure base de données simple et
- du [Cours pt-02][Débutants]Requête avec plusieurs sommes
- du [Cours pt-03]turbo-formulaire (les bases)
-------------------------------------------------------------------------
Le but de cet exercice est de choisir la meilleure méthode pour mettre à jour une base de données (le fichier .mdb contenant les données dans les tables), alors que nous (développeurs) avons
- développé une nouvelle application,
- modifié la structure des tables, de leurs indexes, leurs champs et des relations entre tables,
et que, pendant ce temps là, les utilisateurs ont continué à ajouter des données dans la version précédente.
Précision : Même si je suis le seul utilisateur d'une application dont je me sers tous les jours, il n'est pas question de modifier l'application avec laquelle je réalise mon travail quotidien : un bug surviendra toujours au pire moment critique, lorsqu'un client t'appelle pour avoir l'info indispensable tout de suite .
Je conseille donc de développer toujours sur des copies de l'application et des copies de la base de données, puis de faire une installation avec mise à jour de la BDD.
Nous allons utiliser les éléments suivants, chacun correspondant à un fichier ".mdb" :
- base de données (tables) à la version 1 : en cours d'utilisation. Nous allons utiliser une copie, pour les tests.
- base de données (tables) à la version 2 : nouvelle structure, à mettre en production.
- application, version 2 : à mettre en production, ici par simple copie.
- le moteur de mise à jour V1 > V2 : une mini-application Access que nous n'utiliserons qu'une seule fois.
J'ignore l'application, version 1, qui sera écrasée par la copie de l'application, version 2, pendant l'installation.
À noter, que, dans le zip ci-joint, l'application a été "splittée" en 2, en utilisant l'assistant d'Access (menu Outils > Utilitaires de base de données > Fractionner une base de données), pour séparer toutes les tables, sauf bien sûr, la table [Affaires_Selection] qui doit impérativement être une table locale, propre à chaque utilisateur (sinon, je te laisse imaginer l'embrouille ! )
Il y a 2 méthodes possibles pour réaliser cette mise à jour :
méthode #1 : reporter dans la base de données active (V1) toutes les modifications que nous avons mises au point et testées dans la base V2.
méthode #2 : créer un modèle de base en vidant les tables de la base V2, et transférer dans ces tables vides toutes les données existantes, depuis la base V1.
Quelle que soit la méthode, il va falloir interrompre les utilisateurs pendant la mise à jour : le moins longtemps possible, of course.
Une mise à jour très complexe, concernant quelques dizaines de tables, chacune ayant de 100 à quelques dizaines de milliers d'enregistrements, ne dépasse jamais quelques minutes : rarement 5 minutes, à moins que certaines opérations exigent une intervention de l'utilisateur pour faire des choix...
Je n'ai jamais utilisé la méthode #1, sauf s'il s'agit d'ajouter un seul nouveau champ dans une table, ou une nouvelle table dans la base.
Le principal argument en faveur de la méthode #2 est que je n'ai jamais été capable de faire une liste exhaustive et complète des modifications apportées à une base de données, dès que ces modifications sont un peu complexes.
Il y a toujours quelque part un index ou une propriété oubliée...
Le fonctionnement de la méthode #2 est par contre assez simple dans son principe :
- nous allons traiter chaque table dans l'ordre des niveaux d'intégrité référentielle (détails ci-dessous),
- pour les tables sans modifications majeures, une requête ajout (INSERT INTO) va transférer toutes les données de la V1 à la V2,
- nous allons contrôler les erreurs : essentiellement en comparant le nombre d'enregistrements transférés dans la V2, avec ceux de la table V1.
S'il en manque, nous ajusterons la requête pour tenir compte de chaque cas, ou nous mettrons en place des transformations plus complexes, avec une table locale intermédiaire, par exemple.
- nous recommencerons jusqu'à ce que toutes les données soient correctement transférées.
- nous passerons alors "en production" : installation de la nouvelle application + mise à jour de la base contenant les dernières données réelles.
Niveaux d'intégrité référentielle :
Cette notion, rarement mentionnée dans l'aide ou les ouvrages sur les bases de données, est primordiale pour tout transfert de données (mise à jour, synchronisation, extraits...) : nous ne pourrons pas, par exemple, copier les Affaires (niveau 1 d'intégrité) dans la base V2 si nous n'avons pas d'abord transféré tous les Clients (niveau 0).
La relation d'intégrité entre les tables Clients et Affaires de la V2 nous empêcherait d'ajouter une affaire avec une IdClients qui ne correspond à aucun client dans la table Clients.
Bien sûr, seules les règles d'intégrité de la base V2 nous concernent : celles de la base dans laquelle nous allons écrire.
Et, bien sûr toujours, il est impératif de ne jamais rien modifier dans la V1, pour pouvoir revenir en arrière, en cas de problème non prévu.
C'est pour clarifier cette notion de niveaux que je conseille toujours très vivement de disposer, dans les schémas de relations (menu Outils > Relations...),
- à gauche, les tables auxquelles n'aboutissent aucune relation, (niveau 0)
- immédiatement à leur droite, en colonne, les tables qui dépendent des premières par une relation, (niveau 1)
- continuer ainsi, de la gauche vers la droite, en alignant autant que possible les tables les unes sous les autres, par niveau.
C'est aussi pour cette raison que j'ai utilisé Excel comme outil de dessin, dans la réponse #31 du cours 01. Ça me permet de mettre clairement en évidence les numéros, comme dans le schéma ci-dessous (qui, attention, ne correspond plus à notre base V2 , mais plutôt à la V1 ) :
La toute première étape qui consiste à
- créer une base vierge pour le moteur de mise à jour (fichier SuiviAffaire_MaJ_V1_V2 2006-11-06.mdb),
- attacher toutes les tables de la V1 et celles de la V2, (Fichier > Données externes > Lier les tables...)
- différencier les tables en ajoutant le n° de version "_1" ou "_2" derrière chaque nom,
est faite, dans le zip ci-joint.
Il va donc falloir pour toi :
1- utiliser le gestionnaire de tables attachées (Outils > Utilitaires de bases de données > Gestionnaire de tables liées...) pour réattacher les tables correctement, en fonction de ton chemin d'accès,
2- me corriger (chacun son tour ) en vérifiant que les fichiers ci-joint correspondent bien aux bases de données de la version 1 (en cours d'utilisation) et 2 (celle que nous avons mise au point).
Note : tu pourras supprimer l'application (fichier SuiviAffaire_App 2006-11-06.mdb) du fichier zip. Elle ne nous intéresse plus, dans le cadre du cours 05. dans les prochains échanges, seul le moteur de mise à jour (fichier SuiviAffaire_MaJ_V1_V2 2006-11-06.mdb) devrait être modifié et zippé.
3- faire une liste complète des tables de la V2, en indiquant, pour chaque table, le niveau d'intégrité référentielle.
Partager