Mise en place d'une base des données répartie pour la gestion des transferts des fonds ans une institution de messagerie financière

INTRODUCTION

Le développement des techniques informatiques depuis ces dernières années a permis d'appliquer les outils informatiques dans l'organisation des entreprises. Vu, l'immense volume de données maniées par ces dernières, la puissance des micro-ordinateurs, les performances des réseaux et la baisse considérable des coûts du matériel informatique ont permis l'apparition d'une nouvelle approche afin de remédier aux difficultés causées par la centralisation des données, et ce en répartissant les ressources informatiques tout en préservant leur cohérence. Les bases de données réparties sont un moyen performant pour diminuer les problèmes provoqués par l'approche centralisée, mais ne restent pas sans failles.

1.1.1. BASE DES DONNEES

1.1.1.1. DEFINITON

Selon Laurent Audibert, une base des données informatisées est un ensemble structuré de données enregistrées sur des supports accessibles par l'ordinateur représentant des informations du monde réel et pouvant être interrogées et mises à jour par une communauté d'utilisateurs.^4(*) Selon Mokrane Bouzeghoub, Georges Gardarin et Patrick Valduriz, une base des données est une organisation cohérente de données permanentes et accessibles par des utilisateurs concurrents^5(*)

Selon professeur Mvibudulu, une base des données est définie comme étant un ensemble des données structurées, non redondantes et exhaustives.^6(*) Pour notre part, une base de données est définie comme une entité dans laquelle les données sont structurées et exhaustives en vue d'une éventuelle utilisation.

1.1.1.2. UTILITE D'UNE BASE DES DONNEES

Une base des données permet de mettre des données à la disposition d'utilisateurs pour une consultation, une saisie ou bien une mise à jour, tout en s'assurant des droits accordés à ces derniers. Cela est d'autant plus utile que les données informatiques sont de plus en plus nombreuses. Une base des données peut être locale, c'est-à-dire utilisable sur une machine par un utilisateur, ou bien répartie c'est-à-dire que les informations sont stockées sur des machines distantes et accessibles par réseau. L'avantage majeur de l'utilisation de base des données est la possibilité de pouvoir être accédées par plusieurs utilisateurs simultanément. Toutefois, la mise en place d'une base des données distribuée permet à l'entreprise de devenir plus entreprenante et d'avoir une meilleure connaissance sur ses activités de loin ou de près. Ainsi, ces données doivent être homogènes afin de permettre l'analyse des indicateurs pertinents pour faciliter la prise de décision par les décideurs de l'entreprise.

1.1.1.4. DIFFERENTS TYPES DES BASES DES DONNEES

Les différents types de base des données sont :

ü Les bases des données hiérarchiques ;

ü Les bases des données réseaux ;

ü Les bases des données relationnelles qui sont les plus utilisées. Elles se présentent sous forme d'un tableau constitué des lignes et des colonnes. Les colonnes sont les champs de la table tandis que les lignes en sont les enregistrements.

1.1.2. BASE DES DONNEES DISTRIBUEE

1.1.2.1. HISTORIQUE

Les systèmes de gestion de base des données réparties ont été inventées à la fin des années 1970 afin d'intégrer les bases de données et les réseaux. Le premier grand projet fut SDD1 lancé en 1976 pour gérer les données embarquées sur les bateaux Cyclades qui construisit le premier réseau national, fut lancé le projet Sirius dès 1977. Dans la même période a été lancé le projet Ingres/Star à Berkeley, puis un peu plus tard le projet R* au centre de recherche d'IBM à San José (*signifie N systèmes R interconnectés). Ces projets sont en général aboutis à des produits dont les représentants sont aujourd'hui les versions distribuées d'Oracle, Ingres ou Sybase.

Au milieu des années 1980, l'intérêt des chercheurs s'est déplacé vers les systèmes hétérogènes avec par exemple multi base, ou encore Sabrina Star. Aujourd'hui, une nouvelle génération de systèmes basés sur le modèle objet et une coopération plus lâche est en train de naitre dans les laboratoires. La fédération de base des données existantes est une nécessité pour un grand nombre d'entreprises. En effet, il faut souvent accéder de manière intégrée à des données disséminées sur les différents calculateurs du siège et des usines. Plus précisément, il faut offrir un système de gestion intégrant des sources des données hétérogènes en assurant la transparence à la distribution et à l'hétérogénéité, ceci afin de faciliter les développements pour l'utilisateur. Avec les grands réseaux internationaux tels Internet, le besoin de fédération de données hétérogènes (tables, textes, documents audio-visuel, géométrie, cartes, etc.) est immense. La recherche en base de données réparties(BDR) dont un des aboutissements est déjà le Client-serveur a donc encore un bel avenir.^7(*)

1.1.2.2. DEFINITION

Une base des données répartie (distribuée) est une collection de base des données logiquement reliées, distribuées sur un réseau.^8(*) Une base des données réparties(en anglais Distributed Data Base ou DDB) permet de rassembler des ensembles de données plus ou moins hétérogènes, disséminées dans un réseau d'ordinateurs, sous forme d'une base de données globale, homogène et intégrée.^9(*)

Une base des données réparties est un ensemble structuré et cohérent de données, stocké sur des processeurs distinctes et géré par un SGBD répartie.^10(*) Une base de données distribuée est une base de données gérée par plusieurs processeurs, sites ou SGBD, tout en cachant la complexité des opérations aux utilisateurs qui à leur tour pensent qu'ils accèdent à une base de données centralisée.^11(*)

Figure 1:Base des donnees repartie

Une base des données répartie est un ensemble d'ordinateurs indépendants qui apparait à un utilisateur comme un système unique et cohérent.^12(*)

Figure 2:Base des donnees repartie

1.1.2.3. OBJECTIFS D'UNE BASE DES DONNEES REPARTIE

Les objectifs d'une base des données répartie sont les suivants :

ü Autonomie locale : qui implique que chaque site doit fonctionner indépendamment des autres, même si ces derniers venaient d'avoir des panes ;

ü Ne pas se reposer sur un site unique : cet objectif vise à éviter des arrêts de production lorsqu'un site tombe en panne ;

ü Opération en continu : ici, il est question d'assurer le fonctionnement continu du système réparti par des mises à jour et maintenance effectuées ;

ü Transparence à la localisation des données : ici, l'objectif est de permettre d'écrire des programmes d'applications sans connaitre la localisation physiques des données ;

ü Transparence de la localisation : a pour but de rendre l'accès aux données transparentes sur tout le réseau. En effet, ni les applications, ni les utilisateurs ne doivent savoir la localisation des informations qu'ils utilisent ;

ü Meilleure disponibilité : une des justifications essentielles d'un SGBDR est sans doute l'apport en matière de disponibilité des données. Tout d'abord la répartition permet de ne plus dépendre d'un site central unique. Surtout, elle permet de gérer des copies, de se replier sur une copie lorsqu'une autre est indisponible (site en panne), et même de mettre à jour de manière indépendante des copies. Les copies deviennent alors des réplicats qui peuvent évoluer indépendamment pour converger ultérieurement. Assurer une meilleure disponibilité des données c'est aussi garantir l'atomicité des transactions ;

ü Multi client multi serveurs : dans le contexte du Client Serveur, un client peut demander l'exécution d'une requête distante, peut par exemple être exprimée en SQL ;

ü Indépendance vis-à-vis de la fragmentation : la fragmentation doit être réelle et respectée sur chaque site indépendamment.^13(*)

1.1.2.4. CARACTERISTIQUES DE BASE DES DONNEES DISTRIBUEE

Les caractéristiques de base des données distribuée (répartie) sont les suivantes :

ü Centraliser l'information pour éviter les redondances, garantir l'unicité des saisies et la centralisation des contrôles ;

ü Partage de l'information entre différents utilisateurs ;

ü Préservation de la cohérence des données dans le temps. La fonction de cohérence inclut aussi tous les aspects relatifs à la sécurité en cas de panne matérielle ou logicielle. Enfin, l'archivage est assuré par le SGBD (Back up) de même que la technique de restauration (recovery).^14(*)

1.1.2.5. AVANTAGES DE BDR(Distribuée)

Les principaux avantages d'une BDR sont :

ü Le gain en performance : les traitements se font en parallèles ;

ü La fiabilité : si un site a une panne, un autre peut le remplacer valablement ;

ü La transparence des données : les développeurs et les utilisateurs n'ont pas à se préoccuper de la localisation des données qu'ils utilisent ;

ü Disponibilité des données à chaque instant et à tout lieu.

1.1.2.6. INCONVENIENTS DE BDR

Nous avons :

ü La complexité des mécanismes de décomposition de requêtes ;

ü La synchronisation des traitements et le maintien de la cohérence due à la répartition de la base de données sur plusieurs sites ;

ü Le coût induit par les transmissions des données sur les réseaux locaux ;

ü Les données de chaque serveur sont visibles dans d'autres serveurs, donc pas de secret.

1.1.2.7. REPARTITION DES DONNEES

La localisation d'une donnée peut prendre diverses formes dans le cadre des systèmes répartis. Une donnée X peut être centralisée c'est-à-dire localisée sur un seul site. Si ceci facilite le maintien de sa cohérence, il n'en va pas de même pour les performances et la résistance aux défaillances ; en effet, toute lecture ou écriture doit être sous-traitée au site qui supporte la donnée et la défaillance de ce site rend la donnée inaccessible.

Une autre approche à la distribution d'une donnée consiste à la partitionner (on parle aussi de fragmentation). Certains sites possèdent alors une partie de X et il faut recomposer ces parties pour connaître la valeur de X. Ainsi, pour certaines applications le partitionnement d'un fichier permet de ne placer sur chaque site que la partie du fichier qui le concerne et qu'il va donc lire et écrire. Une autre approche à la distribution des données consiste à les dupliquer. Il existe alors une copie de la donnée X par site concerné par la duplication. Une telle solution d'une part les lectures qui sont alors toutes locales, et d'autre part la résistance aux défaillances des sites : en effet, tant qu'il reste un site possédant une copie de X cette donnée est accessible depuis les autres sites. La difficulté de la duplication réside dans la mise en oeuvre des opérations de lecture et d'écriture ; les différentes copies de X ne doivent en effet pas diverger les unes par rapport aux autres, on parle de « cohérence mutuelle » des copies.^15(*)

1.1.2.8. REPLICATION DANS LES BDR

1°) DEFINITION : La réplication consiste à copier les informations d'une base des données sur une autre, c'est-à-dire la reproduction identique de données d'un site à un autre.

2°) OBJECTIF : L'objectif de la réplication est de faciliter l'accès aux données en augmentant la disponibilité et aussi d'assurer la fiabilité et diminuer les trafics réseaux.

3°) AVANTAGES ET PROBLEMES : On doit se poser cette question : « pourquoi répliquer ? ». A cette question, deux intérêts majeurs se dégagent : améliorer les performances et augmenter la disponibilité des données. Grace à la réplication, les lectures sont exécutées sur le site disposant de la copie la plus proche du client, ce qui peut éviter des transferts inutiles, par exemple si le client dispose d'une copie. Aussi bien pour les lectures que pour les écritures, la réplication permet d'éviter le goulot d'étranglement que constitue le serveur unique en partageant la charge. Du point de vue disponibilité, lors d'une panne d'un serveur, on peut se replier sur un autre disposant d'une copie des données.

Si la réplication présente de nombreux avantages, les problèmes soulevés sont multiples. Tout d'abord, il faut assurer la convergence des copies. Si les copies peuvent être différentes à un instant donné, elles doivent converger vers un même état cohérent où toutes les mises à jour sont exécutées partout dans le même ordre. La convergence peut être longue, mais elle doit survenir si l'on arrête la production de transactions dans le système. En suite, il faut offrir la transparence de gestion aux utilisateurs. Les clients doivent croire à l'existence d'une seule copie ; en conséquence, le SGBD doit assurer la diffusion des mises à jour aux copies et le choix de la meilleure copie lors des accès.^16(*)

4°) TYPES DE REPLICATION

Il existe deux types de réplication : réplication asymétrique et réplication symétrique.

ü Réplication asymétrique : cette réplication rompt la symétrie entre les copies en distinguant un site chargé de centraliser les mises à jour c'est-à-dire dans cette technique de gestion de copies basée sur un site primaire seul autorisé à effectuer des mises à jour et chargé de diffuser les mises à jour aux autres copies dites secondaires. Ce mode de réplication convient bien aux applications à responsabilité centralisée. Il permet la distribution de l'information centralisée, par exemple, la diffusion de catalogues, de listes de prix, etc. Appliqué dans l'autre sens, à partir de copies de fragments horizontaux d'une table, il permet la consolidation d'informations disséminées, par exemple l'état des stocks sera transmis au siège par copie du fragment local désigné comme copie maître. Il permet aussi la diffusion de données vers des entrepôts pour l'aide au décisionnel et l'historisation.

Figure N°3: de mises à jour de copies asymétriques synchrones :

Cours -Devises

Cours -Devises

Cours -Devises

Update

COPIE PRIMAIRE

COPIES SECONDAIRES

Figure N°4: de mise à jour de copies asymétriques asynchrones :

Prix-Produits

Prix-Produits

Prix-Produits

COPIE PRIMAIRE Update

COPIES SECONDAIRES

Ici, toute mise à jour est d'abord appliquée à la copie primaire, puis diffusée en temps différé. Un problème de la gestion de copie asymétrique est donc la panne du site primaire. Dans ce cas, il faut choisir un remplaçant si l'on veut continuer les mises à jour. Celui-ci peut être fixé par l'administrateur ou élu par un protocole spécifique de votre majoritaire. On aboutit alors à une technique asymétrique mobile dans laquelle le site primaire change dynamiquement selon des critères qui peuvent être liés à l'application. Le droit de mise à jour se déplace de site en site, par exemple, au fur et à mesure de l'évolution des données. Ceci va vers des applications de type flots de travaux (work flow) : le site responsable de la mise à jour des commandes change au fur et à mesure du traitement de la commande.

Commandes

Commandes

Commandes

Figure N°5 de l'asymétrie mobile :

Site de saisie site d'expédition site de facturation

ü Réplication symétrique : a l'opposé de la réplication asymétrique, la réplication symétrique ne privilégie aucune copie. Elle permet les mises à jour simultanées de toutes les copies par des transactions différentes c'est-à-dire c'est une technique de gestion de copies où chaque copie peut être mise à jour à tout instant et assure la diffusion des mises à jour aux autres copies. Cette approche convient bien aux applications à responsabilité distribuée telles que la saisie de commandes à de multiples sites, la gestion de clients mobiles, la gestion de comptes par des agences multiples, la mise à jour de documents stratégiques en groupe, etc.

Figure N°6 Exemple de symétrique asynchrone :

Commandes

Commandes

Commandes

Update

COPIE MAITRE

COPIE MAITRE Update COPIE MAITRE Update

N.B : Ici les mises à jour sont appliquées à partir de n'importe quelle copie maitre et diffusées en temps réel.

Figure N°7 Exemple de symétrie asynchrone :

Update

Prix-Produits

COPIE MAITRE

Prix-Produits

Prix-Produits

COPIE MAITRE Update COPIE MAITRE Update

N.B : Ici toute mise à jour est appliquée à une copie maitre, puis diffusée en temps différé.

5°) SECURITE DES DONNEES

Elle recouvre deux aspects à savoir la protection des données et le contrôle des autorisations.

ü La protection des données est assurée par des encryptions, on peut dire aussi qu'il est du ressort du système d'exploitation ;

ü Le contrôle des autorisations doit outre garantir que les utilisateurs, ne peuvent exécuter que les opérations qu'ils ont le droit d'exécuter mais aussi doit restreindre l'accès aux données et les opérations exécutables pour une multitude de groupes d'utilisateurs.

Pour la base des données réparties : Le contrôle des autorisations entraine des nouveaux problèmes à savoir l'authentification d'utilisateurs distants. Pour cela deux solutions sont possibles :

ü Les informations concernant l'authentification des utilisateurs sont répliquées sur chaque site. Lors de l'accès à un programme sur un site distant, l'utilisateur doit indiquer son nom et son mot de passe.

ü Les différents sites s'identifient lors de l'accès à un site distant comme le ferait un utilisateur. Chaque site possède donc son nom d'utilisateur et son mot de passe.

Cette seconde solution a l'avantage de concentrer les informations d'un utilisateur en un seul site. Comme un utilisateur accède à la base des données généralement par le même site, cette solution est adéquate.

1.1.2.9. LES MISES A JOUR DANS LA BDR

Il existe deux types de mise à jour :

ü Mise à jour synchrone ;

ü Mise à jour asynchrone.

1°) MISE A JOUR SYNCHRONE (Synchronous update)

C'est un mode de distribution dans lequel toutes les sous opérations locales effectuées suite à une mise à jour globale sont accomplies pour le compte de la même transaction. Dans le contexte des copies, ce mode de distribution est très utile lorsque les mises à jour effectuées sur un site doivent être prises en compte immédiatement sur les autres sites. L'avantage essentiel de la mise à jour synchrone est de garder toutes les données au dernier niveau de mise à jour. Le système peut alors garantir la fourniture de la dernière version des données quelque soit la copie accédée. Les inconvénients sont cependant multiples, ce qui conduit beaucoup d'applications à éviter la gestion de copies synchrones. Ce sont d'une part la nécessité de gérer des transactions multi sites coûteuses en ressources et d'autres parts la complexité des algorithmes de gestion de concurrence et de panne d'un site. C'est pour cela que l'on préfère souvent le mode de mise à jour asynchrone (encore appelé mise à jour différée).

2°) MISE A JOUR ASYNCHRONE (Asynchronous update)

C'est un mode de distribution dans lequel certaines sous opérations locales effectuées suite à une mise à jour globale sont accomplies dans des transactions indépendantes, en temps différé. Le temps de mise à jour des copies peut être plus ou moins différé : les transactions de report peuvent être lancées dès que possible ou à des instants fixés par exemple le soir ou enfin de semaine.

Les applications qui supportent un tel mode de distribution, avec gestion de copies mises en cohérence seulement périodiquement, on parle de « cohérence lâche », sont nombreuses. Citons par exemple, la modification des prix de catalogues de produits, la diffusion d'informations, etc. les avantages sont la disponibilité de mettre à jour en temps choisi des données, tout en autorisant l'accès aux versions anciennes avant la mise à niveau. Les inconvénients sont bien sûr que l'accès à la dernière version n'est pas garanti, ce qui limite les possibilités de mise à jour.

3°) TECHNIQUES DE DIFFUSION DES MISES A JOUR

La diffusion automatique des mises à jour appliquée à une copie aux autres copies doit être assurée par le SGBD réparti. Plusieurs techniques de diffusion sont possibles, parmi lesquelles on distingue celles basées sur la diffusion de l'opération de mise à jour de celles basées sur la diffusion du résultat de l'opération. Diffuser le résultat présente l'avantage de ne pas devoir ré exécuter l'opération sur le site de la copie, mais l'inconvénient de nécessiter un ordonnancement identique des mises à jour sur tous les sites afin d'éviter les pertes de mise à jour.

Comment diffuser les mises à jour est un autre problème auquel les constructeurs de SGBDR doivent faire face. L'utilisation de déclencheurs du type WHEN<OPERATION> ON <TABLE> THEN FORWARD <OPERATION> ON <COPIE> facilite l'implémentation : un tel déclencheur permet de faire suivre toute mise à jour sur une table vers ses copies. L'utilisation de files persistantes rend praticable le report asynchrone des mises à jour. Une file persistante permet de mémoriser une transaction de report et de la conserver vers même en cas de panne jusqu'à un instant déterminé par l'administrateur. La file doit être scrutée périodiquement par une tache de fond chargé des émissions des transactions de report au moment opportun. Enfin, l'utilisation d'appels périodiques (polling) par les sites gérant les copies vers un site (ou plusieurs sites) chargé de centraliser enregistrées dans le journal depuis le dernier appel au site gérant la copie celui-ci applique alors les mises à jour. Cette technique permet un fonctionnement asynchrone avec mise à niveau périodique.

1.1.2.10. CONCEPTION DES BASES DES DONNEES REPARTIES

Par rapport à la conception de base des données distribuée, les deux démarches deviennent la conception du schéma global et la conception des bases des données physiques locales dans chaque site. La conception des répartitions des données est caractérisée entièrement par l'ajout des deux aspects suivant :

ü Concevoir la fragmentation, c'est-à-dire spécifier comment les relations globales sont subdivisées en fragments horizontaux, verticaux ou mixtes.

ü Concevoir l'allocation des fragments, c'est-à-dire comment les fragments sont liés aux images physiques, de cette manière la duplication des fragments est également spécifié.

Il convient de ce fait de distinguer ces deux dernières conceptions ou la première traite du critère logique qui motive la fragmentation d'une relation globale et la seconde qui traite de l'emplacement physique des données dans divers sites.

* ⁴ Laurent A., Base des données et langage SQL, S.e., Ville Taneuse, 1989, p.9

* ⁵ Mokrane B. et alii, Les Objets, éd.Eyrolles, Paris, 1997, p.282

* ⁶ Mvibudulu K., Technique de base des données, 1^ère Ed. CRIGED, Kinshasa, 2010, P.3

* ⁷ Georges et Olivier Gardarin, Le Client-serveur, éd.Eyrolles, Paris, 1996, p.121

* ⁸ Idem, p.123

* ⁹ Ibidem, p.122

* ¹⁰ Ibidem

* ¹¹ http://www.commentçamarche.net/Accueil/Forum/BD, consulté le 01/01/2016 à 22h25'

* ¹² http://www.jimdo.com/algorithme et système distribué, consulté le 15/12/201 à 22h00'

* ¹³ Georges et Olivier G., Op.cit, p.127

* ¹⁴ Christian Soutou, UML2 pour les bases des données, éd.Eyrolles, Paris, 2000, pp9-10

* ¹⁵ Michel R., Gestion des données réparties : Problèmes et Protocoles (Tome 3), éd.Eyrolles, Paris, 1992, p.64.

* ¹⁶ Georges et Olivier G., Op.cit, p.161