Réplication des base de données pour les institutions financières

IV.4. PRESENTATION ET DISCUSSION DES RESULTATS

IV.4.1. Résultats Obtenus

Tout au début de ce travail de recherche, nous nous sommes fixés l'objectif de concevoir et tester les algorithmes de réplication des données selon la fréquence de demandes des clients d'une institution financière. Voici les résultats que nous avons obtenus :

- Nous avons proposé un algorithme de réplication de données, que nous avons présenté sous forme de diagramme d'état dans le troisième chapitre, qui offre la possibilité de

~ 54 ~

répliquer manuellement les données lorsqu'il y a coupure du courant ou problème de connexion entre les bases de données qui se partagent les informations ;

- Nous avons conçu avec UML des modèles de traitement des données par le Système de Réplication de bases de données, que nous avons décrit sous forme de diagramme d'activité et de séquence système à partir des quels nous avons-nous dégagé les états par lesquels transite la base de données pendant la réplication ;

- Après exécution de ces instructions sur la Machine de Turing, nous avons constaté que ces premières ont produit des Automates Déterministes et des automates non déterministes ;

- Le fait qu'il y a eu des automates non déterministes, nous pouvons prouver les cas possibles d'interruption de la communication entre les sites distants étant donné qu'on ne sait pas avec exactitude si la réplication prendra fin sans qu'il y ait des perturbations.

- Sur un ordinateur physique, après la mise en place de notre environnement de travail, nous testé la réplication entre plusieurs bases de données de taille différente :

- pour les bases de données avec plus de Cinq tables, la réplication se fait rapidement, et il n'y a pas de casse, c'est-à-dire toutes les données sont répliquées sans problème, mais pour des bases de données de plus de cinq tables la réplication dure un moment, mais elle finit par prendre fin ;

- Sous Visual Basic, nous avons essayé d'exécuter un script de réplication qui se déroule bien avec les petites bases de données, c'est-à-dire avec tout au plus cinq tables. mais sous SQL serveur quel que soit le nombre de tables, la réplication se passe correctement malgré le temps que ça dure ;

- Quant aux méthodes de réplication auxquelles nous avons recourues pour les tests, nous avons constaté que la méthode transactionnelle est la meilleure parce qu'elle ne demande pas de faire une mise à jour sur la base cible pour que les modifications soient propagées, mais lorsqu'il s'agit de la méthode par fusion et de capture instantanée, on est obligé de redémarrer l'agent de publication. Mais le désavantage de la méthode transactionnelle, c'est qu'elle n'est pas programmable à partir de VB.Net raison pour laquelle nous avons programmé la méthode par Fusion (Merge Replication).

- Cette difficulté ne se fait sentir que par rapport au nombre des tables, mais par rapport au nombre d'enregistrements dans les tables, le problème ne se pose pas.

~ 55 ~

- Après l'implémentation de deux applications VB : l'une Serveur (My Bank Server) et l'autre client (My Bank Client), nous sommes parvenus à simuler l'environnement souhaité, celui d'une architecture repartie ou distribuée.

- Sur la partie client, nous avons mis en place un système de monitoring qui nous a permis de surveiller toutes les modifications qui sont faites sur les différents sites distants.

- Le système mis en place sera donc capable d'exécuter les tâches suivantes : la saisie des informations dans la base des données (Figure 28), la mise à jour des données après ajout de nouvelles informations (Figure 30), la réplication de la base de données existante avec une nouvelle base de données et afficher les modifications en temps réel des différentes entités (Figure 29), mais aussi le back up des données.