WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Mise en oeuvre d'un système distribué pour l'identification et le suivi du casier judiciaire

( Télécharger le fichier original )
par Juslin TSHIAMUA MUDIKOLELE
Université pédagogique nationale - Licence 2016
  

Disponible en mode multipage

    UNIVERSITE PEDAGOGIQUE NATIONALE

    B.P 8815 KINSHASA

    FACULTE DES SCIENCES

    ANNEE ACADEMIQUE 2015 - 2016

    TSHIAMUA MUDIKOLELE Juslin

    Assistant

    RAPPORTEUR : Armel MBENZA

    Dr Professeur

    DIRECTEUR  : Pierre KAFUNDA KATALAY

    ORIENTATION : CONCEPTION DES SYSTEMES D'INFORMATIONS

    MEMOIRE DE FIN DE D'ETUDES PRESENTE ET DEFENDU EN VUE DE L'OBTENTION DU TITRE DE LICENCIE EN SCIENCES

    L2 CONCEPTION DES SYSTEMES D'INFORMATION

    MISE EN OEUVRE D'UN SYSTEME DISTRIBUE POUR L'IDENTIFICATION ET SUIVI DU CASIER JUDICIAIRE

    « Cas du Service de casier judiciaire de Kinshasa »

    DEPARTEMENT DES MATHEMATIQUES ET INFORMATIQUE

    Epigraphe

    En informatique, laminiaturisation augmente la puissance de calcul. On peut être plus petit et plus intelligent.

    Bernard Weber

    Dédicace

    A Toi Eternel Dieu, source intarissable ; Toi qui nous as rendus complètement, complètement et absolument complets en Christ Jésus. Gloire et honneur sont à Toi pour Ton amour incommensurable envers nous depuis Ta préscience.

    A nos parents : Marie Léonie MILOLO TSHIAMUA et Jean Oscar NYEMBUE TSHIMANGA, qui nous ont soutenu, fortifié et encouragé, sur tous les plans, durant notre parcourt académique.

    A vous nos frères et soeurs : Suzanne KALANGA MUAMBADIMUE et votre époux Christian KANKU, Jean Pierre NGANDU MULUMBA MUPANGA, Marguerite NGALULA TSHIENAMUILA et votre époux Henri MUABILA, Pauline MILOLO DIKEBELE, Petit Jean NYEMBUE TSHIMANGA, Xavier KENATSHIANDI BIPENDU et Madeleine YUWANGA KAKUMESA.

    A vous oncles : Jean Pierre BADIBANGA TSHIPAMBA et Albertine KABENA, Jean François BUTEKA.

    A vous tous nos cousins et cousines ;

    A vous nos frères et soeurs en Christ ;

    A vous nos très chers, vous avec qui l'estime est partagée : Christian LUKETA KANYINDA Browser, Aaron NTUMBA NGINDU et Goshen MULANGA TSHIVUILA, Rebecca MULUNDA MUIMPE.

    A tous ceux que nous aimons et qui nous aiment ;

    A tous ceux, de loin ou de près, ont participé à l'élaboration de ce travail ;

    Je dédie ce travail.

    Avant-propos

    Au terme du cycle de licence, et selon des dispositions réglementaires régissant l'organisation de l'Enseignement Supérieur et Universitaire en République Démocratique du Congo, un travail scientifique doit être présenté par tout finaliste en vue de sanctionner la fin de sa formation.

    C'est à ce titre que ce travail, le fruit de multiples sacrifices et durs labeurs, a été rédigé. Puisse-t-il dore et déjà constituer une documentation pour le monde scientifique en général et pour quiconque serait passionné d'abonder dans ce même domaine en particulier.

    Sur ce, saisissons-nous cette ultime opportunité en vue de nous acquitter d'un noble devoir, celui d'exprimer notre gratitude au regard de tous ceux qui ont contribué d'une manière ou d'une autre à sa complète réalisation.

    Nous remercions avec vivacité les Corps Académique et scientifique de la Faculté des Sciences en général et celui du Département de Mathématique et Informatique en particulier, d'avoir mis à notre disposition d'aussi un personnel qualifié pour notre formation.

    A vous Monsieur le Professeur Docteur KAFUNDA KATALAY Pierre, nonobstant la charge de votre calendrier, avez fait montre d'une preuve d'éducateur au style rare et dont nous rendons témoignage. L'élève étant le meilleur inspecteur de son maître ! Vos remarques et suggestions ainsi que vos conseils si stratégiques ont pu marquer notre coeur.

    A nos parents : Maman Marie Léonie MILOLO TSHIAMUA et Papa Jean Oscar NYEMBUE TSHIMANGA, ce travail est le fruit de votre amour et le souci de notre avenir.

    A toi notre frère Jean Pierre NGANDU MULUMBA MUPANGA, tu es dans nos accolades pour aussi bien tes conseils, ta morale que ton soutien. Nos cordiales gratitudes !

    A vous camarades, vous qui avez tenu ensemble d'avec nous durant tous les cinq ans durant : NGALULA MULUMBA Dyna, TSHIPAMBA KAPUKU Thierry, MUAMBAYI KALONJI Arnold, MAWETE MALONGO Lovecia, KABAMBA NGOLO Marcel, MUAKA NTELA Difi, LIKOTELO BINENECamile, MUAMBA MUKENDI Emmanuel ;

    Nos cordiales gratitudes à vous tous qui nous avez aidé d'une façon ou d'une autre, nous pensons à l'assistant Eddy KIOMBA KAMBILO, à mon frère Sébastien KASONGA KAYASA.

    Notre particulière gratitude s'adresse également à nos collègues de services, Alain MITEU MUAMBA, Basile MUAMBA NDUBA, Ange KULUTU NGIMI et à toute la famille AMISTECH.

    Nous ne saurons terminer sans remercier de tout coeur toutes les personnes, membres des familles, toutes comprises, amis et connaissances qui ont cru à cet aboutissement, qu'ils veuillent bien se reconnaître dans ce travail.

    A vous tous enfin, dont l'anonymat n'affecte en rien cet attachement indélébile qui nous lie, trouvez ici l'expression de notre gratitude ainsi que notre sympathie de reconnaissance. Merci !

    Liste des abréviations

    ACID : Atomicité-Cohérence-Isolation-Durabilité

    ADN : Acide Désoxyribonucléique

    BD : Base de Données

    BOT : Begin Of Transaction

    BP : Bordereau de Paiement

    CJ : Casier Judiciaire

    CN : Certificat de Naissance

    DAF : Division Administrative et Financière

    DFC : Division du Fichier Central

    DI : Division Informatique

    DIJ : Direction de l'Identité Judiciaire

    ECJ : Extrait du Casier Judiciaire

    ED : Empreinte Digitale

    EOT : End Of Transaction

    FD : Fiche Décadactylaire

    OLAP :OnLineAnalyticalProcessing

    OLTP : OnLine Transaction Processing

    P2P : Peer-to-peer

    PID : Pièce d'Identité

    RMI : Remote Method Invocation

    SGBD : Système de Gestion de Bases de Données Réparties

    SQL : StructuredQueryLanguage

    UML : UnifiedModelingLanguage

    VSAT : Very SamllAparture Terminal

    Liste des figures

    Figure I.1 : Représentation d'un Système Distribué

    Figure I.2 : Exemple d'un Système Distribué

    Figure I.3 : Fonctionnement du modèle Client-Serveur

    Figure I.4 : Architecture pair à pair

    Figure II.5 : Exemple de Base de données répartie

    Figure II.6 : Types de Base de données répartie

    Figure II.7 : Représentation de la conception ascendante

    Figure II.8 : Représentation de la conception descendante

    Figure II.9 : Représentation asymétrique synchrone

    Figure II. 10 : Représentation asymétrique asynchrone

    Figure II.11 : Représentation symétrique synchrone

    Figure II.12 : Représentation symétrique asynchrone

    Figure II.13 : Représentation d'une transaction

    Figure II.14: Architecture peer-to-peer

    Figure II.15: Architecture Client Serveur de SGBD Répartie

    Figure II.16 : Architecture répartie avec SGBD répartie homogène

    Figure II.17 : Architecture avec Multi SGBD

    Figure II.18 : Architecture répartie avec SGBD fédérée

    Figure III.19 : Représentation d'une architecture d'un système biométrique

    Figure III.20 : Capture d'une empreinte digitale

    Figure III.21 : Exemple des catégories des empreintes digitales

    Figure III.22 : Différentes formes des minuties

    Figure III.23 : Points singuliers d'une empreinte digitale

    Figure III.24 : Squelettisation des empreintes digitales

    Figure III.25 : Exemple de repérage des minuties

    Figure III.26 : Extraction des minuties d'une empreinte digitale

    Figure III.27 : Authentification par empreinte digitale

    Figure VI.28 : Représentation du diagramme de cas d'utilisation

    Figure VI.29 : Représentation du diagramme d'activité

    Figure VI.30 : Représentation du diagramme de classe

    Figure VI.31 : Représentation du schéma global

    Figure VI.32 : Représentation du schéma local

    0. INTRODUCTION

    Actuellement, toute organisation se veut d'un fonctionnement approprié dans le cadre d'une gestion optimale des informations dont elle engage. Etant donné qu'il y ait une masse d'informations devant être gérée, un besoin de base de données bien-maintenue s'impose pour assumer cette gestion.

    Certes, au jour le jour, la course à la productivité se fait sentir et le besoin d'innover se fait voir dans le but de faire avancer de plus en plus des nouvelles technologies de sorte que les ressources que dispose chaque entité soient partagées en toute facilité au sein d'une organisation.

    La même problématique se pose dans le secteur judiciaire, lorsqu'il y a des crimes qui se commettent d'une façon ou d'une autre et aussi d'un coin à un autre. En effet, l'on ne parvient pas à maitriser l'état d'une personne ayant été détenue pour un délit à un endroit lorsqu'elle a eu à en commettre à un autre.

    De ce fait, la maitrise de ce mécanisme serait quasi-impossible aussi longtemps que ce système s'opère manuellement dans toute l'étendue de la République Démocratique du Congo et principalement dans la ville province de Kinshasa.

    Or, l'informatique a apparu pour faciliter le traitement automatique des processus dans le monde actuel en faisant naitre différentes technologies pour parvenir à tout contrôler et à bien développer beaucoup de secteurs là où le traitement manuel semblait encore inefficace.

    De nos jours, nos établissements ou institutions contiennent des informations importantes à gérer tout en étant géographiquement dispersées dans toute l'étendue du pays alors qu'elles ne cessent d'accroitre au jour le jour aussi.De ce fait, il devient de plus en plus important de mettre en place des systèmes tendant à gérer dans des environnements complexes.

    Ceci étant, nos organisations judiciaires,aujourd'hui, fonctionnent sous une mission stratégique pour laquelle les informations de chaque individu ayant un dossier judiciaire devraient êtredisponibles partout dans le but d'un suivi permanent de ceux-ci quelque soit leur position géographique.

    C'est ainsi que le recours à la technique de système distribué est très nécessaire pour arriver à prendre en compte tout ce processus en vue d'arriver à un fonctionnement approprié. Ce concept reste un aspect plus motivant dans l'amélioration des performancesdans le cadre du partage des ressources d'une organisation.

    C'est dans ce cadre que notre travail émet son importance au travers ce concept de système distribué dans le processus de suivi du casier judiciaire.

    0.1. PROBLEMATIQUE

    Le service du casier judiciaire est le seul en charge de sceller le passé et de suivre la conduite de chaque individu en République Démocratique du Congo. Ceci étant, le grand problème s'enregistre dans le cadre de traitement des informations relatives à chaque individu aussi longtemps que ce travail, demeurant encore manuel, s'effectue de façon centralisée.

    De ce fait, toutes les données de chaque province sont compilées et envoyées à la direction centrale à Kinshasa pour être traitées afin d'identifier chaque individu et de ficher ses informations s'il est condamné afin de le suivre. Ce qui est théoriquement faisable mais pratiquement de la mer à boire.

    Par-dessus tout, ce travail ne pourra arriver à satisfaire de façon optimale le pays en matière de suivi permanent, vu sa complexité, alors que chaque institution judiciaire, quelque soit son cercle géographique, doit avoir en temps réel, les données de chaque individu de la république concerné afin de garantir son suivi.

    En effet, l'objectif poursuivi dans ce travail est de développer une application informatique distribuée, après une bonne étude sur les systèmes distribués, qui permettra à nos institutions judiciaires de coopérer facilement grâce à la disponibilité des données et au partage des informations afin de suivre en temps réel le casier judiciaire de chaque citoyen congolais concerné par le cas.

    Eu égard à ce qui précède, nous nous sommes posé des questions suivantes dans le but de mettre en oeuvre un système distribué de suivi de casier judiciaire :

    · Comment arriver à garantir la disponibilité des services dans des institutions judiciaires pour un suivi permanent des individus aussi longtemps que ces premières sont dispersées géographiquement dans toute la République ?

    · Le traitement éventuel des informations relatives à chaque individu peut-il être facilité par la distribution ?

    · Lors d'un crime ou délit commis par un prévenu, le système pourrait-il être à mesure de fournir des informations fiables à son propos?

    · L'instauration du casier judiciaire informatisé pourrait-il occasionner une réduction de taux de crimes ou de délits en République Démocratique du Congo ?

    0.2. HYPOTHESE

    La disponibilité des services reste une caractéristique évidente au sein des organisations actuelles voulant des grandes performances dans le traitement de leurs informations. Pour ce faire, la grande solution à mettre en oeuvre reste l'implantation des systèmes distribués lorsqu'il y a augmentation de la globalité en vue de permettredavantage le partage des ressources en vue d'un fonctionnement approprié.

    0.3. CHOIX ET INTERET DU SUJET

    L'intérêt de ce travail est d'ordre scientifique parce qu'il présente le cas pratique de l'application concret du concept de système distribué.

    D'une part, il nous permet d'enrichir les connaissances acquises en matière des systèmes d'objet répartis, de bases de données réparties à travers les réplications en vue de montrer à des institutions qui ont des succursales éloignées géographiquement et qui sont ignorantes à la connaissance des systèmes distribués, les avantages que peut apporter cette notion.

    D'autre part, une fois accepté par le jury, ce travail nous permettra d'obtenir notre diplôme de licence en conception des Systèmes d'informations.

    0.4. DELIMITATION DU SUJET

    En vue d'être précis et d'éviter de faire une étude généralisée, nous délimitons notre travail dans le temps et dans l'espace.

    0.4.1. Dans le temps

    Nos recherches ont été menées dans la période allant de décembre 2015 à Juin 2016.

    0.4.2. Dans l'espace

    Le cadre spatial de notre travail se limite sur l'étude et la mise en oeuvre d'un système distribué pour apporter une solution aux problèmes que traverse notre pays dans le cadre de suivi du casier judiciaire. Nous allons considérer trois provinces pour ce travail dont la ville province de Kinshasa, la province de Congo central ainsi que celle du Kasaï central.

    0.5. METHODES ET TECHNIQUES UTILISEES

    0.5.1. METHODES

    Pour l'élaboration de notre travail, nous avons utilisées les méthodes suivantes :

    0.5.1.1. Méthode Structuro-fonctionnelle

    Cette méthode permet à un chercheur de comprendre et de découvrir un fait à travers la structure et le fonctionnement d'une institution.

    Elle nous a permis de comprendre la structure et le fonctionnement du service du casier judiciaire de la Gombe.

    0.5.1.2. Méthode Comparative

    Elle consiste à observer les faits dans deux ou plusieurs institutions afin de pouvoir être en mesure de comprendre et d'expliquer un problème d'une organisation.

    Cette méthode nous a permis de faire une étude comparative de suivi du casier judiciaire d'une institution judiciaire à une autre.

    0.5.2. TECHNIQUES

    Les techniques sont des moyens permettant à un chercheur de recueillir les informations dont il a besoin pour atteindre ses objectifs. Ainsi, pour la récolte des informations relatives à notre travail, nous avons utilisé les techniques suivantes :

    0.5.2.1. Technique d'interview

    Cette technique permet une entrevue entre les personnes intéressées et le chercheur lors de la récolte des informations.

    C'est elle qui nous a beaucoup aidé à atteindre nos objectifs en nous entretenant avec le personnel du servicedu casier judiciaire de la Gombepour des éventuelles précisions et réponses à toutes nos difficultés.

    0.5.2.2. Technique documentaire

    Elle consiste à consulter les documents susceptibles en rapport avec une étude afin de récolter les données dont on a besoin.

    Cette technique nous a servi à la réalisation de ce travailen faisant recours aux bibliothèques, aux recherches sur Internet ainsi qu'à d'autres documents qui se rapportent à notre étude.

    0.6. SUBDIVISION DU TRAVAIL

    Hormis l'introduction et la conclusion, le présent travail comporte cinq chapitres que voici :

    · Le premier chapitre parle des généralités sur le système distribué.

    · Le deuxième chapitre s'intéresse aux bases de données réparties.

    · Le troisième chapitre parle de l'authentification par empreintes digitales

    · Le quatrième chapitre traite de l'analyse préalable

    · Le cinquième chapitre s'intéresse à la conception et implémentation du système

    CHAPITRE Ière : GENERALITES SUR LES SYSTEMES DISTRIBUES [1] [6] [4]

    Vue l'augmentation de leurs ressources, les entreprises multi-sites doivent pouvoir compter sur une infrastructure informatique hautes performances, à même d'assurer l'exécution transparente de leurs processus informatiques et une communication fiable, en interne (entre les différents sites) comme en externe (avec les partenaires et clients). Cela exige une surveillance continue de la disponibilité des ressources et de l'utilisation de la bande passante des réseaux localement distribués.

    Les systèmes distribués proposent des solutions d'améliorer l'agilité globale du système d'information au travers des architectures orientées services (SOA). Ces systèmes permettent aussi de mettre en place des architectures informatiques permettant d'améliorer les performances ainsi que la disponibilité des systèmes informatiques.

    Dans ce chapitre, nous décrivons l'architecture et le fonctionnement des systèmes distribués, tout en présentant leurs caractéristiques, avantages ainsi que leur mode de communication.

    I.1. Définitions

    Un système distribué est un système disposant d'un ensemble d'entités communicantes, installées sur une architecture d'ordinateurs indépendants reliés par un réseau de communication, dans le but de résoudre en coopération une fonctionnalité applicative commune.

    Autrement dit, un système distribué est défini comme étant un ensemble des ressources physiques et logiques géographiquement dispersées et reliées par un réseau de communication dans le but de réaliser une tâche commune. Cet ensemble donne aux utilisateurs une vue unique des données du point de vue logique.

    Un système distribué est un ensemble d'entités autonomes de calcul (ordinateurs, PDA, processeurs, processus, processus léger etc.) interconnectées et qui peuvent communiquer.

    Figure 1: Représentation d'un Système distribué

    I.2. Intérêt des systèmes distribués

    Les systèmes distribués ont plusieurs raisonsde leur existence.

    · Partage des ressources (données, programme, services) qui permet un travail collaboratif ;

    · Accès distant, c'est-à-dire qu'un même service peut être utilisé par plusieurs acteurs situés à des endroits différents ;

    · Amélioration des performances : la mise en commun de plusieurs unités de calcul permet d'effectuer des calculs parallélisables en des temps plus courts ;

    · Confidentialité : les données brutes ne sont pas disponibles partout au même moment, seules certaines vues sont exportées ;

    · Disponibilité des données en raison de l'existence de plusieurs copies ;

    · Maintien d'une vision unique de la base de données malgré la distribution ;

    · Réalisation des systèmes à grande capacité d'évolution ;

    · Augmentation de la fiabilité grâce à la duplication de machines ou de données,ce qui induit à une réalisation des systèmes à haute disponibilité.

    I.3. Quelques domaines d'application des systèmes distribués

    Les systèmes distribués sont rencontrés dans notre vie quotidienne :

    · La gestion intégrée des informations d'une entreprise (guichet de banque, agence de voyage,..) ;

    · Internet : l'internet, aujourd'hui, constitue un grand exemple d'un système distribué le plus large au monde contenant de nombreux sous-systèmes selon le protocole considéré. Exemple : Web (http), bittorrent (peer-to-peer). Des nombreux utilisateurs partout dans le monde peuvent utiliser des services offerts par l'internet comme le WWW, le FTP (File Transfert Protocol) et tant d'autres applications. On remarque ici une collection deréseaux d'ordinateurs interconnectés. Et les programmes s'y exécutant interagissent grâce aux échanges de messages en utilisant un moyen de communication ou un autre ;

    · Le WWW représente un système distribué logique consistant en un nombre considérable de ressources (pages web, fichiers de données et services) référencées par des URL (Uniform Ressource Locator) ;

    · Les téléphones portables ;

    · Le contrôle et organisation d'activités en temps réel (télévision interactive)

    I.4. Difficulté de mise en oeuvre

    La mise en oeuvre des systèmes distribués engendre un certain nombre de difficultés dont voici quelques-unes :

    · Gestion de l'hétérogénéité et Cohérence des données

    Lors de la mise en place d'un système distribué, il est nécessaire que l'ensemble des composants travaillent avec des données cohérentes.Cette cohérence des données est d'autant plus problématique lorsque l'on commence à redonder certains composants pour augmenter la capacité de traitement et/ou la disponibilité du système.

    En effet, les données comme le cache applicatif, le contenu d'une base de données ou bien les variables de session des utilisateurs Web doivent être synchronisées entre les différentes instances d'un composant afin d'assurer une cohérence dans les traitements réalisés.

    · Gestion des composants

    Un système distribué étant composé d'un ensemble de composants logiciels répartis sur plusieurs serveurs physiques. Il est nécessaire pour assurer la maintenance corrective et évolutive du système de dresser une cartographie complète de ce système.

    · Disponibilité et détection d'arrêts

    Dans un système distribué, l'indisponibilité d'un seul composant du système (serveur, base de données, ...) peut rendre indisponible le système complet. On mesure alors la disponibilité de ce type de système à celle de son maillon le plus faible.

    Pour couvrir ce risque, il est nécessaire de mettre en place en amont une architecture permettant d'assurer la disponibilité cible pour tous les composants. Une fois que cette architecture est en production, des opérateurs doivent à l'aide de logiciels s'assurer de la détection au plus tôt d'une défaillance de l'un des composants de l'architecture.

    · Gestion de la séquentialité

    La mise en place d'un cluster de type actif/actif provoque la création de deux points d'entrée au système. Dans le cas d'un système distribué d'échange de données par exemple, il est alors possible que deux modifications successives du même objet soient dirigées vers deux noeuds différents du cluster, ce qui dans l'absolu peut aboutir à une situation où le message le plus récent est diffusé en premier vers l'application destinataire.

    Si aucune gestion de la séquentialité des messages n'est faite, le message le plus ancien viendra écraser dans les applications destinataires le message le plus récent.

    I.5. Caractéristiques des systèmes distribués

    La performance d'un système distribué se révèle dans ces caractéristiques. Ces caractéristiques ci-dessous devraient être prises en compte lors de la conception d'un système distribué.

    I.5.1. Interopérabilité

    Dans un système distribué, ilse pose un vrai problème de coopération entre différents composants du système. En effet, ce problème peut être vu au niveau de la couche matériel (différents réseaux physiques et plateforme matérielle), de la couche système d'exploitation (divers OS utilisés(UNIX, Windows, Mac OS, Solaris)), de la couche application (langages de programmation différents) et de la couche middleware (.NET pour Microsoft, Corba pour le Consortium OMG). On parle de l'hétérogénéité, un problème dans le partage des ressources dans un système distribué.

    L'interopérabilité est une caractéristique importante qui désigne la capacité à rendre compatibles deux systèmes quelconques. A son tour, la compatibilité est la capacité qu'ont deux systèmes à communiquer sans ambiguïté.

    En effet, l'interopérabilité vise à réduire le vrai problème de l'hétérogénéité en la masquant par l'utilisation d'un protocole unique de communication (exemple de TCP/IP pour l'Internet). Pour les échanges des messages, il faut utiliser des standards qui cachent les différences entre les différentes plateformes.

    Actuellement, il existe deux approches principales de standardisation pour masquer l'hétérogénéité : les middlewares et les machines virtuelles.

    Concrètement, un middleware est représenté par des processus et des ressources d'un ensemble d'ordinateurs, qui interagissent les uns avec les autres. Ils middlewares améliorent la communication en offrant des abstractions telles que :

    · Le RMI (Remote Method Invocation)  qui est la possibilité, pour un objet, d'invoquer la méthode d'un autre objet situé sur une plateforme distante ;

    · La notification d'événement pour la propagation d'informations d'une plateforme vers une autre ou plusieurs autres plateformes ou composants d'une application distribuée ;

    · La communication entre groupe de processus ;

    · La gestion de la duplication des données partagées ;

    · La transmission de données multimédia en temps réel.

    Les machines virtuelles permettent de supporter le code mobile désignant la possibilité de transfert de code d'une machine source à une machine de destination et son exécution sur cette machine. Au cas des différentes plateformes, le code produit sur l'une ne peut fonctionner sur l'autre. Pour éviter ce problème, le code mobile est généré d'un langage source pour une machine virtuelle donnée (exemple de la JVM). En effet, chaque plateforme doit disposer d'une couche logicielle qui implémente la machine virtuelle car cette dernière représente une généralisation des middlewares offrant les mêmes services.

    Figure 2: exemple d'un système distribué

    I.5.2. Partage des ressources

    Le partage des ressources est le facteur principal de motivation pour construire les systèmes répartis. Des ressources telles que des imprimantes, des dossiers, des pages Web ou des disques de base de données sont contrôlées par des serveurs du type approprié. Par exemple, les serveurs Web contrôlent des pages Web et d'autres ressources d'enchaînement. Des ressources sont consultées par des clients - par exemple, les clients du web des serveurs s'appellent généralement les browsers (navigateurs) ;

    I.5.3. Ouverture

    Cette caractéristique fait mention de l'extensibilité dans la mesure où des composants peuvent être ajoutés, remplacés ou supprimésdans un système distribué sans en affecter les autres. Et lorsque nous parlons des composants, nous voyons les matériels (les périphériques, mémoires, interfaces, etc.) et les logiciels (protocoles, pilote, etc.). L'ouverture nécessite que les interfaces logicielles soient documentées et accessibles aux développeurs d'applications.

    Il se pose un vrai problème avec l'ouverture au sens que les composants d'un système distribué sont hétérogènes. Alors, cette qualité d'ouverture est accordée aux systèmes supportant sans ambages :

    a) L'ajout de l'ordinateur au niveau de la couche matérielle ;

    b) L'ajout de nouveaux services au niveau application, middleware et système d'exploitation ;

    c) La réimplantation des services anciens.

    I.5.4. Expansible

    Nous disons qu'un système distribué est expansible lorsque les modifications du système et des applications ne sont pas nécessaires quant à l'augmentation de la taille de ce système.

    I.5.5. Performance

    Dans ce cas, le système doit s'adapter à bien fonctionner même quand le nombre d'utilisateurs ou de ressources augmentent.

    I.5.6. Transparence

    « To the user, a distributed system should look exactly like a nondistributed system. »

    La transparence cache aux utilisateurs l'architecture, la distribution des ressources, le fonctionnement de l'application ou du système distribué pour apparaître comme une application unique cohérente.

    La norme ISO (1995) définit différents niveaux de transparences telle que la transparence d'accès, de localisation, de concurrence, de réplication, de mobilité, de panne, de performance, d'échelle).

    o Transparence d'accès :il s'agit d'utiliser les mêmes opérations pour l'accès aux ressources distantes que pour les celles locales ;

    o Transparence à la localisation : l'accès aux ressources indépendamment de leur emplacement doit être inconnue à l'utilisateur ;

    o Transparence à la concurrence : il s'agit de cacherà l'utilisateur l'exécution possible de plusieurs processus en parallèle avec l'utilisation des ressources partagées en évitant des interférences ;

    o Transparence à la réplication : la possibilité de dupliquer certains éléments/ressources (fichiers de base de données) pour augmenter la fiabilité et améliorer les performances doit être cachée à l'utilisateur ;

    o Transparence de mobilité : il s'agit de permettre la migration des ressources et des clients à l'intérieur d'un système sans influencer le déroulement des applications ;

    o Transparence de panne : il s'agit de permettre aux applications des utilisateurs d'achever leurs exécutions malgré les pannes qui peuvent affecter les composants d'un système (composants physiques ou logiques) ;

    o Transparence à la modification de l'échelle : il s'agit de la possibilité d'une extension importante d'un système sans influence notable sur les performances des applications.

    o Transparence à la reconfiguration: il s'agit de cacher à l'utilisateur la possibilité de reconfigurer le système pour en augmenter les performances en fonction de la charge ;

    En effet, la transparence n'est pas toujours possible dans certains cas. Notons le cas de la duplication d'une imprimante des caractéristiques différentes pour besoin des performances dans le système. Cependant, l'utilisateur doit toutefois avoir la possibilité de spécifier concrètement sur quelle imprimante il souhaite imprimer ses documents.

    I.5.7. Sécurité

    Le problème de sécurité se pose dans tout système informatique. Dans un système distribué, les ressources doivent être protégées contre des utilisations abusives et malveillantes. En particulier, le problème de piratage des données sur le réseau de communication. En ces raisons, il est préférable d'utiliser des périphériques ou logiciels licenciés. Outre, les connexions doivent être sécurisées par authentification avec les éléments distants ainsi que les messages circulant sur ce réseau doivent être cryptés en vue d'éviter des conséquences graves.

    Le concept de sécurité des systèmes d'information recouvre un ensemble de méthodes, techniques et outils chargés de protéger les ressources d'un système d'information afin d'assurer :

    · la disponibilité des services : les services (ordinateurs, réseaux, périphériques, applications...) et les informations (données, fichiers...) doivent être accessibles aux personnes autorisées quand elles en ont besoin ;

    · la confidentialité des informations : les informations n'appartiennent pas à tout le monde ; seuls peuvent y accéder ceux qui en ont le droit ;

    · l'intégrité des systèmes : les services et les informations (fichiers, messages...) ne peuvent être modifiés que par les personnes autorisées (administrateurs, propriétaires...).

    I.5.8. Concurrence

    Le problème de la concurrence permet l'accès simultané à des ressources par plusieurs processus. Ce problème se pose pour les systèmes distribués comme pour les systèmes centralisés. En effet, il y a bien d'autres ressources dont l'accès simultané n'est pas possible. Dans ce cas, leur manipulation ne peut se faire que par un processus à la fois. Le cas des ressources physiques telles que l'imprimante mais aussi des ressources logiques telles que les fichiers, les tables des bases de données, etc. Dans ce cas, les applications distribuées (reparties)actuelles autorisent l'exécution de plusieurs services en concurrence (cas de l'accès à une base de données). Chaque demande est prise en compte par un processus simple appelé thread ; et la gestion de la concurrence fait appel aux mécanismes de synchronisation classiques.

    I.5.9. Tolérance aux pannes

    Une panne peut être comprise comme une faille au sein du système pouvant conduire à des résultats erronés comme aussi engendrer l'arrêt de toute ou partie d'un système distribué.Les pannes peuvent résulter des différentes couches et se propager éventuellement aux autres. Peut-être, c'est une raison matérielle ou logique liée à la conception des applications, des middlewares et des systèmes d'exploitation.

    Ainsi, un système distribué doit être conçu pour masquer ce genre des pannes aux utilisateurs. La panne de certains serveurs (ou leur réintégration dans le système après la réparation) ne doit pas perturber l'utilisation du système en terme de fonctionnalité.

    I.5.10. Disponibilité

    Dans un système distribué, l'indisponibilité d'un seul composant du système (serveur, base de données, ...) peut rendre indisponible le système complet alors qu'il doit rendre en permanence des services et d'une façon correcte. On mesure alors la disponibilité de ce type de système à celle de son maillon le plus faible.

    Ces risques d'indisponibilité du système peuvent être dus :

    · aux pannes empêchant le système ou à ses composants de fonctionner correctement ;

    · aux surcharges dues à des sollicitations excessives d'une ressource ;

    · aux attaques de sécurité pouvant causer, d'une façon ou d'une autre, des dysfonctionnements, les incohérences et pertes de données et même l'arrêt du système.

    Pour couvrir ce risque, plusieurs solutions peuvent être envisageables :

    · mettre en place en amont une architecture permettant d'assurer la disponibilité cible pour tous les composants. Une fois que cette architecture est en production, des opérateurs doivent à l'aide de logiciels s'assurer de la détection au plus tôt d'une défaillance de l'un des composants de l'architecture.

    · veiller à la réplication des données au sein de ce système (c'est la solution que nous avons choisi dans le cadre de notre travail).

    I.6. Architecture distribuée

    L'architecture d'un environnement informatique ou d'un réseau est distribuée lorsque toutes les ressources ne se trouvent pas au même endroit ou sur la même machine. Ce concept s'oppose à celui d'architecture centralisée dont une version est l'architecture client-serveur que nous allons aussi voir dans cette partie.

    En effet, la programmation orientée objet a permis le développement des architectures distribuées en fournissant des bibliothèques de haut-niveau pour faire dialoguer des objets répartis sur des machines différentes entre eux. Les objets distribués sur le réseau communiquent par messages en s'appuyant sur l'une des technologies telles que CORBA, RMI, les services web XML, .Net Remoting, Windows Communication Foundatation, etc.

    Les architectures distribuées reposent sur la possibilité d'utiliser des objets qui s'exécutent sur des machines réparties sur le réseau et communiquent par messages au travers du réseau.

    I.6.1. Avantages des architectures distribuées

    · Augmentation des ressources : la distribution des traitements sur les ordinateurs d'un réseau augmente les ressources disponibles;

    · Répartition des données et des services : (cas de l'architecture 3-tiers à la base de la plupart des applications distribuées de commerce électronique permettant d'interroger et de mettre à jour des sources de données réparties) ;

    I.6.2. Types d'architecture distribuée

    I.6.2.1. Architecture client-serveur

    Le client server est avant tout un mode de dialogue entre deux processus. Le premier appelé client, demande l'exécution de services au second appelé serveur. Le serveur accomplit les services et envoi en retour des réponses. En général, un serveur est capable de traiter les requêtes de plusieurs clients. Un serveur permet donc de partager des ressources entre plusieurs clients qui s'adressent à lui par des requêtes envoyées sous forme de messages.

    Par extension, le client désigne également l'ordinateur sur lequel est exécuté le logiciel client, et le serveur, l'ordinateur sur lequel est exécuté le logiciel serveur.

    Le client serveur étant un mode de dialogue, il peut être utilisé pour réaliser de multiples fonctions.

    Figure 3:Fonctionnement du mode client-serveur

    Parlant de l'architecture client-serveur, nous distinguons trois types d'acteurs principaux:

    1) Client

    Un client est un processus demandant l'exécution d'une opération à un autre processus (fournisseur des services) par l'envoi d'un message contenant le descriptif de l'opération à exécuter et attendant la réponse à cette opération par un message en retour.

    Caractéristiques d'un client :

    · Il est actif le premier (ou maître) ;

    · Il envoie des requêtes au serveur ;

    · Il attend et reçoit les réponses du serveur.

    Parlant aussi de client, nous en distinguons trois types :

    Ø Client léger : est une application accessible via une interface web consultable à l'aide d'un navigateur web.

    Ø Client lourd : est une application cliente graphique exécuté sur le système d'exploitation de l'utilisateur possédant les capacités de traitement évoluées.

    Ø Client riche : est une combinaison du client léger et client lourd dans lequel l'interface graphique est décrite avec une grammaire basée sur la syntaxe XML.

    2) Serveur

    On appelle serveur un processus accomplissant une opération sur demande d'un client et lui transmettant le résultat. Il est la partie de l'application qui offre un service, il reste à l'écoute des requêtes du client et répond au service demandé par lui.

    En effet, un serveur est généralement capable de servir plusieurs clients simultanément.

    Caractéristiques d'un serveur :

    · Il est initialement passif (ou esclave, en attente d'une requête) ;

    · Il est à l'écoute, prêt à répondre aux requêtes envoyées par des clients ;

    · Dès qu'une requête lui parvient, il la traite et envoie une réponse.

    Nous distinguons plusieurs types de serveur en fonction des services rendus : Serveur d'application, serveur de base de données, serveur des fichiers, etc.

    3) Middleware

    Le middleware est l'ensemble des services logiciels qui assurent l'intermédiaire entre les applications et le transport de données dans le réseau afin de permettre les échanges des requêtes et des réponses entre client et serveur de manière transparente.

    Le client serveur étant un mode de dialogue, il peut être utilisé pour réaliser de multiples fonctions. Il existe donc différents types de client-serveur qui ont été définis : le client serveur de présentation, le client serveur de données et le client serveur de procédures.

    I.6.2.2. Architecture pair-à-pair (peer-to-peer ou P2P)

    Le pair-à-pair est un modèle de réseau informatique proche du modèle client-serveur mais où chaque ordinateur connecté au réseau est susceptible de jouer tour à tour le rôle de client et celui de serveur.

    P2P est une architecture pouvant être centralisée (les connexions passant par un serveur central intermédiaire) ou décentralisée (les connexions se faisant directement). Le pair-à-pair peut servir au partage de fichiers en pair à pair, au calcul distribué ou à la communication entre noeuds ayant la même responsabilité dans le système.

    La particularité des architectures pair-à-pair réside dans le fait que les données peuvent être transférées directement entre deux postes connectés au réseau, sans transiter par un serveur central. Cela permet ainsi à chaque ordinateur d'être à la fois serveur de données et client des autres. On appelle souvent noeud les postes connectés par un protocole réseau pair-à-pair.

    Outre, les systèmes de partage de fichiers pair-à-pair permettent de rendre les ressources d'autant disponibles qu'elles sont populaires, et donc répliquées sur un grand nombre de noeuds. Cela permet alors de diminuer la charge (en nombre de requêtes) imposée aux noeuds partageant les fichiers dans le réseau. C'est ce qu'on appelle le passage à l'échelle. Cette architecture permet donc de faciliter le partage des ressources. Elle rend aussi la censure ou les attaques légales ou pirates plus difficiles.

    Figure 4: Architecture pair-à-pair

    Ces atouts font des systèmes pair-à-pair des outils de choix pour décentraliser des services qui doivent assurer une haute disponibilité tout en permettant de faibles coûts d'entretien. Toutefois, ces systèmes sont plus complexes à concevoir que les systèmes client-serveur.

    Dans ce chapitre, nous nous sommes focalisé sur les conceptsde base des systèmes distribués. Nous avons donné en détail les caractéristiques des systèmes distribués, leurs architectures ainsi que les domaines concrets de leur application. Dans le prochain chapitre, nous abordons le concept Base de données répartie.

    CHAPITRE IIème : LES BASE DE DONNEES REPARTIE[3][5][7][9]

    L'évolution technologique actuelle depuis quelques décennies permet d'adapter les outils informatiques à l'ensemble d'activités au sein des entreprises du point de vue organisationnel.

    La puissance des micro-ordinateurs et la croissance des stations de travail, la fiabilité et la souplesse des systèmes informatiques répartis et de leurs architectures, les performances des réseaux permettent d'envisager une répartition des ressources informatiques tout en préservant l'intégrité et la cohérence des bases de données.

    En effet, les bases de données restent totalement indispensables dans notre vie courante du fait qu'elles sont un des moteurs fondamentaux du progrès économique des entreprises actuelles. Aujourd'hui même, l'information stockée dans une base de données de l'entreprise peut l'aider à une prise de décision en vue de veiller sur les objectifs.

    II.1. Définitions

    Une base de données distribuée est un ensemble des différentes bases de données stockées sur des sites (géographiquement distants), reliés par un réseau. La réunion de ces différentes bases forme la base de données repartie.

    Figure 5: Exemple de bases de données réparties

    II.2. Caractéristiques

    Une base de données répartie doit répondre aux caractéristiques suivantes :

    § La distribution de données : les données n'appartiennent pas à un seul processus ;

    § La corrélation logique des données: les données possèdent les propriétés qui les tiennent ensemble ;

    § Une structure de contrôle hiérarchique basée sur un administrateur des bases de données globales qui est le responsable central sur les bases de données réparties entières et sur les administrateurs des bases de données locales, qui ont la responsabilité de leur base de données respective ;

    § L'indépendance des données et la transparence de répartition.

    § La redondance des données, une grande caractéristique permettant l'accroissement de l'autonomie des applications et la disponibilité des informations en cas de panne d'un site ;

    § Un plan d'accès réparti écrit soit par le programmeur ou produit automatiquement par un optimiseur ;

    II.3. Types de bases de données réparties

    Des bases de données réparties peuvent être largement classifiées dans les environnements homogènes et hétérogènes de base de données répartie, chacun avec d'autres subdivisions, comme montré dans l'illustration suivante.

    Figure 6: Types de base de données répartie

    II.3.1. Base de données répartie homogène

    Dans une base de données répartie homogène, tous les sitesutilisent le système de gestion de bases de données identique et les systèmes d'exploitation.Ses propriétés sont :

    · Les sites utilisent les mêmes logiciels ;

    · Les sites utilisent le même SGBD;

    · Chaque site se rend compte de tous autres et coopère entre eux pour traiter des requêtes d'utilisateur ;

    · L'accès à la base de données se fait par une interface simple comme si c'est une seule base de données.

    II.3.1.1. Types de base de données répartie homogène

    Il y a deux types de ces bases de données

    a) Autonome : chaque base de données est indépendante que des fonctions. Elles sont intégrées par une application de contrôle et utilisent le message passant pour le partage des mises à jour de données.

    b) Non autonome : des données sont distribuées à travers les noeuds homogènes et un système de gestion de bases de données central ou maître coordonne des mises à jour de données à travers les sites.

    II.3.2. Base de données hétérogène

    Dans une base de données répartie hétérogène, les différents sites ont différents systèmes d'exploitation, différents systèmes de gestion de bases de données et différents modèles de données.Ses propriétés sont :

    a) Les différents sites utilisent les schémas et le logiciel différents ;

    b) Le système peut se composer de variété de SGBD répartis, relationnel, réseau, hiérarchique ou orienté objet ;

    c) Le traitement de requêtes est complexe dû aux schémas différents ;

    d) Le traitement transactionnel est complexe dû au logiciel différent ;

    e) Une coopération limitée dans le traitement de requêtes de clients due aux transparences des sites.

    II.3.2.1. Types de base de données répartie hétérogène

    · Fédérée : Les systèmes de base de données hétérogène sont indépendants en nature et sont intégrés ensemble de sorte qu'ils fonctionnent comme système simple de base de données.

    · Non fédérée : Les systèmes de base de données utilisent un module central coordonné par lequel les bases de données sont consultées.

    II.4. Conception d'une base de données

    Une base de données répartie doit être gérée par plusieurs processeurs ou SGBD. Elle est aussi donc stockée sur différents ordinateurs situés dans un même endroit ou étant dispersées sur un réseau d'ordinateurs interconnectés. Chaque ordinateur de ce réseau constitue un noeud. La question importante consiste à savoir comment ces noeuds vont interagir et communiquer entre eux.

    En effet, la mise en place d'une base de données répartie se résume par la conception du schéma global, la conception de la base de données physique locale dans chaque site, la conception de la fragmentation ainsi que la conception de l'allocation des fragments.

    II.4.1. Conception du schéma global

    Le schéma global se subdivise en trois schémas dont :

    II.4.1.1. Schéma Interne

    Ce schéma décrit l'accès physique aux occurrences des relations, il est constitué de l'ensemble des descriptions des fichiers et/ou par un ensemble des schémas de relations internes.

    II.4.1.2. Schéma conceptuel

    C'est l'ensemble des schémas des relations de base et l'ensemble des contraintes d'intégrités, c'est la vue globale de la base de données. Le schéma conceptuel est composé de relations fragmentées ou d'une relation composée d'une ou de plusieurs sous-relations, la distinction de deux approches dans sa mise en oeuvre.

    II.4.1.3. Schéma externe

    Le schéma conceptuel est un sous-ensemble du schéma conceptuel composé de l'ensemble des schémas de relations abstraites définies sur la relation de base du schéma conceptuel.

    II.4.2. Conception de la base de données physique locale dans chaque site 

    Nous distinguons deux façons de concevoir une base de données répartie dont la conception ascendante et la conception descendante.

    II.4.2.1. Conception ascendante (bottom up design)

    L'approche se base sur le fait que la répartition est déjà faite, mais il faut réussir à intégrer les différentes bases des données locales existantes en un seul schéma global. En d'autres termes, les schémas conceptuels locaux existent et il faut réussir à les unifier dans un schéma conceptuel global.

    Figure 7: Représentation de la conception ascendante

    Cette démarche s'avère la plus difficile puisqu'en plus des problèmes techniques identiques à ceux inhérent à une conception descendante, il faudra résoudre des problèmes d'hétérogénéité du système ou même de la sémantique de l'information.

    II.4.2.2. Conception descendante (top down design)

    La conception descendante se fait par la définition d'un schéma conceptuel global de la base de données répartie. Ensuite, on distribue sur les différents sites en des schémas conceptuels locaux.

    L'approche top down est intéressante parce que l'on part du néant en définissant un schéma global qu'on subdivisera en différentes bases locales. Si les bases des données existent déjà la méthode bottom up design est utilisée.

    Figure 8: Représentation de la conception descendante

    Outre, il faut ensuite définir la répartition des données qui s'effectue en trois étapes dont la partition ou la fragmentation, la réplication et l'hybride.

    La répartition se fait donc en deux étapes : la première étant la fragmentation, et la deuxième, l'allocation de ces fragments aux sites.

    II.4.3. Conception de la fragmentation

    II.4.3.1. Fragmentation

    La fragmentation est la tâche de diviser une table en ensemble de plus petites tables. Cette division doit se faire sans perte d'informations. Les sous-ensembles de la table s'appellent les fragments.La fragmentation peut être de trois types :horizontal, vertical, et hybride (combinaison d'horizontal et de vertical).

    II.4.3.1.1. Avantages de la fragmentation

    · Puisque des données sont stockées près du site de l'utilisation, l'efficacité du système de base de données est augmentée ;

    · Les techniques locales d'optimisation de requêtes sont suffisantes pour la plupart des requêtes puisque les données sont localement disponibles ;

    · Puisque les données non pertinentes ne sont pas disponibles aux sites, la sécurité et l'intimité du système de base de données peuvent être maintenues.

    II.4.3.1.2. Limites de la fragmentation

    · Lorsque l'on a besoindes données de différents fragments, les vitesses d'accès peuvent être très hautes ;

    · En cas de fragmentations récursifs, le travail de la reconstruction aura besoin de techniques chères ;

    · Le manque de copies de secours des données dans différents emplacements peut rendre la base de données inefficace en cas d'échec d'un emplacement.

    II.4.3.1.3. Types de fragmentation

    a) Fragmentation Horizontale (Répartition des occurrences)

    Elle consiste à partitionner ou à découper une table en sous tables par l'utilisation des prédicats permettant de sélectionner les lignes appartenant à chaque fragment selonun ou plusieurscritères de sélection suivant les valeurs d'un ou plusieurs champs.La fragmentation se fait par sélection, et la reconstitution de la table (relation) initiale se fait grâce à l'union de sous tables.

    Ce type de fragmentation est adapté à la régionalisation ou départementalisation dans une entreprise. Par exemple, considérons qu'une base de données du casier judiciaire contient tous les enregistrements des individus condamnés dans une table individu ayant le schéma suivant.

    Id

    Nom

    Prenom

    Genre

    Mention

    Province

    Crime

    1

    TSHIAMUA

    Juslin

    M

    Avec antécédent judiciaire

    Kinshasa

    Viol

    2

    LUKETA

    Christian

    M

    Avec antécédent judiciaire

    Kinshasa

    Vol

    3

    MULANGA

    Goshen

    F

    Avec antécédent judiciaire

    Congo central

    xxx

    4

    LIKOTELO

    Camile

    M

    Avec antécédent judiciaire

    Congo central

    yyy

    5

    NTUMBA

    Aaron

    M

    Avec antécédent judiciaire

    Kasaï central

    zzz

    Tableau 1: Illustration de la fragmentation

    Au cas où le détail de tous les individus de la province de Congo central doit être envoyé dans la province du Kasaï central, alors le concepteur réduira horizontalement la base de données comme suit :

    CREATE TABLE IND_CONGO_CENTRALAS SELECT * FROM INDIVIDU WHERE PROVINCE IN(«CONGO CENTRAL»);

    Résultat:

    Id

    Nom

    Prenom

    Genre

    Mention

    Province

    Crime

    3

    MULANGA

    Goshen

    F

    Avec antécédent judiciaire

    Congo central

    xxx

    4

    LIKOTELO

    Camile

    M

    Avec antécédent judiciaire

    Congo central

    yyy

    Tableau 2: Exemple d'une fragmentation horizontale

    b) Fragmentation Verticale (Répartition des attributs)

    Elle se fait non au niveau des données mais de la structure même de la base où certains champs sont envoyés dans un fragment et d'autres ailleurs.

    La fragmentation verticale consiste à partitionner une relation en groupes d'attributs et une clé doit apparaitre dans tous les groupes. Toutes les valeurs des occurrences pour un même attribut se trouvent dans le même fragment.

    Une fragmentation verticale est utile pour distribuer les parties des données sur le site où chacune de ces parties est utilisée.Elle se fait par projection et la reconstruction de la relation initiale se fait grâce à des jointures en vue d'éviter les pertes d'informations.

    Par exemple, dans le schéma individu, on veut juste savoir le crime de chaque individu, le concepteur réduira la base comme suit :

    CREATE TABLEIND_MENTION AS SELECT ID, CONCAT(NOM,' ',PRENOM) AS NOMS, CRIME FROM INDIVIDU;

    Résultat :

    Id

    Noms

    Crime

    1

    Juslin TSHIAMUA

    Viol

    2

    Christian LUKETA

    Vol

    3

    Goshen MULANGA

    Xxx

    4

    Camile LIKOTELO

    Yyy

    5

    Aaron NTUMBA

    Zzz

    Tableau 3: Exemple d'une fragmentation verticale

    c) Fragmentation hybride (Répartition des valeurs)

    C'est la combinaison des deux techniques de fragmentation précédentes, horizontale et verticale. Les occurrences et les attributs peuvent donc être répartis dans des partitions différentes.C'est la technique de fragmentation la plus flexible puisqu'elle produit des fragments avec l'information étrangère minimale.Cependant, la reconstruction de la table originale est souvent une tâche ardue.

    La fragmentation hybride peut être faite de deux manières alternatives :

    · Au début, produire d'un ensemble de fragments horizontaux ; produire alors des fragments verticaux d'un ou plusieurs des fragments horizontaux.

    · Au début, produire d'un ensemble de fragments verticaux ;produire alors des fragments horizontaux d'un ou plusieurs des fragments verticaux.

    L'opération de partitionnement est une combinaison de projections et de sélections et celle de recomposition est une combinaison de jointures et d'unions.

    CREATE TABLEIND_MENTIONASSELECT ID, CONCAT(NOM,' ',PRENOM) AS NOMS, CRIME FROM INDIVIDU WHERE PROVINCE IN(`KINSHASA');

    Résultat :

    Id

    Noms

    Crime

    1

    Juslin TSHIAMUA

    Viol

    2

    Christian LUKETA

    Vol

    Tableau 4: Exemple de fragmentation hybride

    II.4.3.1.4. Règles de fragmentation

    La fragmentation doit tenir aux trois règles suivantes :

    a) La complétude : pour toute donnée d'une relation R, il existe un fragment Ri de la relation R qui possède cette donnée.

    b) La reconstruction : pour toute relation R décomposée en un ensemble de fragments Ri, il existe une opération inverse de reconstruction : la jointure pour les fragmentations verticales et l'union pour celles horizontales.

    a) La disjonction : aucune donnée ne doit se trouver dans plus d'un fragment sauf dans le cas d'une fragmentation verticale où la clé primaire doit être présente dans l'ensemble des fragments issus d'une relation.

    II.4.4.Conception de l'allocation des fragments

    Ayant mis en oeuvre la fragmentation de la base, le problème réside sur la localisation du fragment. En effet, un schéma d'allocation doit être élaboré afin de déterminer la localisation de chaque fragment et sa position dans le schéma global : c'est l'allocation.

    II.4.4.1. Schéma d'allocation

    L'affectation des fragments sur le site est décidée en fonction de l'origine prévue des requêtes qui ont servi à la fragmentation. Le but est de placer les fragments sur les sites où ils sont le plus utilisés, dans le but de minimiser les transferts de données entre différents sites.

    II.4.4.2. Techniques de répartition avancée

    D'une part, la méthode classique d'allocation des fragments est appliquée et d'autre part, si cette méthode ne s'avère pas satisfaisante, des techniques plus puissantes mais aussi complexes à mettre en oeuvre doivent être envisagées :

    II.4.4.1.1. Allocation avec duplication

    Au travers cette technique, certains fragments sont dupliqués sur un site ou sur l'ensemble de sites selon les besoins. Une technique très importante car elle offre une amélioration considérable des performances du système en termes de temps d'exécution des requêtes étant donné que l'accès aux données est local grâce aux fragments qui sont un peu partout dupliqués.

    Cependant, la difficulté des mises à jour de tous les fragments dupliqués reste un inconvénient majeur pour cette technique.

    II.4.4.1.2. Allocation dynamique

    Avec cette technique, l'allocation d'un fragment peut changer en cours d'utilisation d'une base de données répartie. Ce qui fait qu'un fragment se trouvant sur un site A à l'instant T, peut être retrouvé sur un autre site B à l'instant T+1. Néanmoins, elle reste une technique très efficace lorsqu'il y a le maintien et la mise à jour du schéma d'allocation ainsi que des schémas locaux.

    II.4.4.1.3. Fragmentation dynamique

    Cette technique consiste au changement d'allocation dynamique des fragments ; ce qui peut rendre possible deux fragments complémentaires (verticalement ou horizontalement) de se retrouver sur un même site. C'est alors qu'intervient la fusion de ces fragments.

    A l'inverse, si une partie est appelée sur un autre site, il peut être intéressant de décomposer ces fragments et de ne faire migrer que la partie concernée. Ces modifications du schéma de fragmentation se répercutent sur le schéma d'allocation et sur les schémas locaux.

    II.4.4.1.4. clichés (snapshots)

    Un cliché est une copie figée d'un fragment. Il représente l'état du fragment à un instant donné et n'est jamais mis à jour contrairement aux vues et aux copies qui répercutent toutes les modifications qui ont lieu sur le fragment original.

    L'intérêt d'un cliché diminue donc au fur et à mesure que le temps passe car toutefois, l'information contenue dans la base de données peut ne pas rester figée (cas d'un changement d'adresse non signalé, par exemple). Dans ce cas, l'utilisation des clichés est intéressante lorsque l'on juge que la gestion des copies multiples se révélerait trop lourde pour la base de données considérée alors que des copies même peu anciennes et non à jours seraient largement suffisantes.

    Néanmoins, les deux critères qui sont à prendre en compte pour définir l'intérêt d'un cliché sont d'une part l'ancienneté du cliché, et d'autre part le temps d'attente qui serait nécessaire avant d'obtenir l'information originale (à jour).

    II.5.Réplication des données

    Toute application de base de données repose sur un modèle client-serveur. Suivant ce modèle, le client se connecte au SGBD pour passer des ordres. Ces ordres sont de deux natures : lecture (on parle alors de requêtes) ou mise à jour (on parle alors de transactions).

    Pour les transactions il y a une modification des données sur le serveur, mais cela reste des ordres de courte durée. A l'inverse, dans le cas d'une lecture, il n'y a pas de modification des données mais les traitements peuvent être longs et porter sur une grande masse de données ; ce qui se passe dans le cadre d'une application web par exemple, où un nombre important de requêtes peut surcharger partiellement (ou complètement) le serveur.

    De ce fait, il existe plusieurs solutions pour palier à ce genre de problèmes et, la réplication en est une.

    II.5.1. Définition

    La réplication est un processus qui consiste à copier l'ensemble d'une base de données (la structure et les données) sur chaque noeud. Elle implique aussi la redondance des informations dans différents sites.

    II.5.2. Objectifs la réplication

    L'objectif principal de la réplication est d'assurer la fiabilité du système et de faciliter l'accès aux données en augmentant la disponibilité. Ceci soit parce que les données sont copiées sur différents sites permettant de répartir les requêtes, soit parce qu'un site peut prendre la relève lorsque le serveur principal s'écroule.

    Une autre application tout aussi importante est la synchronisation des systèmes embarqués non connectés en permanence. Ce qui permet d'éviter les transferts de données et d'assurer la croissance de la résistance aux pannes.

    Grâce à la réplication, les utilisateurs ne s'en aperçoivent pas lorsqu'un site est momentanément inaccessible car un autre peut correctement le remplacer.

    II.5.3. Technique de la réplication

    La technique de la réplication, qui met en jeu au minimum deux SGBD, est assez simple et se déroule en trois étapes :

    · La base maître reçoit un ordre de mise à jour (INSERT, UPDATE ou DELETE).

    · Les modifications faites sur les données sont détectées et stockées dans un fichier ou une file d'attente en vue de leur propagation.

    · Le processus de réplication prend en charge la propagation des modifications à faire sur une seconde base dite esclave. Il peut bien entendu y avoir plus d'une base esclave.

    Bien entendu, il est tout à fait possible d'appliquer la réplication dans les deux sens (de l'esclave vers le maître et inversement). On parlera dans ce cas-là de réplication bidirectionnelle ou symétrique. Dans le cas contraire où elle se fait du maitre vers l'esclave, on parle d'une réplication unidirectionnelle ou en lecture seule ou encore asymétrique. Outre ceci, la réplication peut être faite de manière synchrone ou asynchrone.

    II.5.4. Avantages de la réplication

    L'intérêt majeur de la réplication réside dans l'amélioration des performances et l'augmentation de la disponibilité des données. Les avantages sont les suivants :

    · Fiabilité: en cas d'échec de n'importe quel site, le système de base de données continue à fonctionner puisqu'une copie est disponible à un autre site ;

    · Réduction de charge de réseau : puisque les copies locales des données sont disponibles, le traitement de requêtes peut être fait avec l'utilisation réduite de réseau, en particulier pendant des heures de grand travail.La mise à jour de données peut être faite aux heures non-principales ;

    · Une réponse plus rapide : la disponibilité des copies locales des données assure le traitement rapide de la requête et par conséquent le temps de réponse rapide ;

    · Des transactions plus simples :les transactions exigent moins de nombre de jointures des tables situées à différents sites et à coordination minimale à travers le réseau.Ainsi, elles deviennent plus simples en nature.

    II.5.5. Limites de réplication

    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.

    · Conditions de stockage accrues : Le maintien des copies multiples des données est associé aux coûts accrus de stockage. L'espace mémoire exigé est dans les multiples du stockage exigé pour un système centralisé ;

    · Plus grands coût et complexité des données mises à jour : Chaque fois qu'une donnée élémentaire est mise à jour, la mise à jour doit être reflétée dans toutes les copies des données aux différents emplacements.Ceci exige des techniques et des protocoles complexes de synchronisation.

    · Application indésirable - accouplement de base de données :Si des mécanismes complexes de mise à jour ne sont pas employés, le déplacement des données d'inconsistance exige la coordination complexe au niveau d'application. Ceci a comme conséquence l'application indésirable - accouplement de base de données.

    II.5.6. Techniques de diffusion des mises à 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 distinguera 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 en tous les sites afin d'éviter les pertes de mises à jour.

    Ces mises à jour peuvent de faire d'une manière synchrone ou asynchrone.

    II.5.6.1. Mise à 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.

    Lors de l'exécution d'une requête en lecture, la base de données répartie va décomposer la requête globale en sous requêtes locales à l'aide des métadonnées de distribution.

    a) Avantages

    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 quel que soit la copie accédée.

    De ce fait, ce mode de distribution est très utile, lors des copies, lorsque les mises à jour effectuées sur un site doivent être prises en compte immédiatement sur les autres sites ; ce qui garantit l'absence des conflits entre les différents sites en permettant le maintien de toutes les copies en cohérence.

    b) Limites

    Ce mode de distribution présente des multiples limites. Ceci conduit beaucoup d'application à éviter la gestion des copies synchrones.

    En effet, ces limites sont d'une part la nécessité de gérer les transactions multi listes coûteuses en ressources ; ce qui demande plus de ressources réseaux et matérielles, et d'autres parts la complexité des algorithmes de gestion de concurrence et de panne d'un site. Raison pour laquelle l'on préfère souvent le mode de mise à jour asynchrone (encore appelé mise à jour différée). On notera aussi la perte des performances du fait de la mise en oeuvre de la validation en deux phases (préparation de l'écriture des résultats de mises à jour et la validation).

    II.5.6.2. Mise à jour asynchrone (asynchronous update)

    Mode de distribution dans le quel 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é ; c'est-à-dire que les transactions de report peuvent être lancées dès que possible où à des instants fixés, par exemple le soir ou en fin de semaine.

    a) Avantages

    Les avantages sont la possibilité de mettre à jour en temps choisi des données, tout en autorisant l'accès aux versions anciennes avant la mise à niveau. Il demande moins de ressources réseau et matériel que le mode synchrone, ce qui implique une meilleure disponibilité et une meilleure performance.

    b) Limites

    L'accès à la dernière version n'est pas garanti, ce qui limite les possibilités de mise à jour à cause de certains conflits avec les données.

    En effet, il y a possibilité d'avoir des conflits avec les données, dont voici les trois types :

    1. conflit de mise à jour : deux ou plusieurs sites réalisent de transaction de modification sur la même ligne pratiquement en même temps.

    2. conflit d'unicité : Il provient d'une transaction d'insertion réalisée par deux ou plusieurs sites différents tentant d'insérer dans une table une donnée comportant la clé primaire. Autrement dit quand la réplication d'une ligne tente de violer l'intégrité d'une entité.

    3. conflit de suppression : lorsqu'une transaction tente de modifier ou de supprimer une ligne qui n'existe plus du fait de sa suppression par un autre site quelque temps plutôt. Cette ligne ne peut donc être modifiée ou supprimer.

    II.5.7. Types de réplication

    II.5.7.1. Réplication asymétrique

    Au-delà des techniques de diffusion des mises à jour se pose le problème du choix de la copie sur laquelle appliquer les mises à jour. La réplication asymétrique rompt la symétrie entre les copies en distinguant un site maître appelé site primaire, chargé de centraliser les mises à jour. Il est le seul autorisé à mettre à jour les données, et chargé de diffuser les mises à jour aux copies dites secondaires.

    Le grand défi dans cette gestion asymétrique est la panne du site primaire. Dans ce cas, il importe à l'administrateur de choisir un remplaçant si l'on veut continuer les mises à jour, ce qui nous amène alors à une technique asymétrique mobile dans laquelle le site primaire change dynamiquement.

    On peut donc distinguer l'asymétrique synchrone et l'asymétrique asynchrone :

    a) Réplication asymétrique synchrone

    Figure 9: Représentation asymétrique synchrone

    Elle utilise un site primaire qui pousse les mises à jour en temps réel vers un ou plusieurs sites secondaires. La table répliquée est immédiatement mise à jour pour chaque modification par utilisation de trigger sur la table dite maître.

    b) Réplication asymétrique asynchrone

    Dans ce cas, le site primaire pousse les mises à jour en temps différé via une file persistante. Les mises à jour seront exécutées ultérieurement, à partir d'un déclencheur externe, l'horloge par exemple.

    Figure 10: Représentation asymétrique asynchrone

    II.5.7.2. Réplication symétrique

    A l'opposé de la réplication asymétrique, la réplication symétrique ne privilégie aucune copie ; c'est-à-dire chaque copie peut être mise à jour à tout instant et assure la diffusion des mises à jour aux autres copies. C'est une technique de gestion de copies permettant les mises à jour simultanées de toutes les copies par les transactions différées.

    En effet, cette technique pose un problème de la concurrence d'accès risquant de faire diverger les copies. Sur ce, une technique globale de résolution de conflits doit être mise en oeuvre (exemple : mise à jour d'une copie maitre qui est ensuite propagée).

    On distingue pour ce cas, la réplication symétrique synchrone et la réplication symétrique asynchrone.

    a) Réplication symétrique synchrone

    Lors de la réplication symétrique synchrone, les mises à jour s'effectuent à partir de n'importe quel site maitre et sont diffusées en temps réel.

    Figure 11: représentation symétriques synchrone

    b) Réplication symétrique asynchrone

    Lors de cette réplication, les mises à jour sur des tables répliquées sonteffectuées par n'importe quel site en différées. Cette technique risque de provoquer des incohérences de données car il est tout à fait impossible de défaire une transaction validée.

    Figure 12: Représentation symétriques asynchrone

    II.6. Gestion des transactions réparties

    II.6.1. Définitions d'une transaction

    Une transaction est un ensemble des opérations menées sur une BD, la transformant d'un état stable cohérent en un autre état stable cohérent. En cas d'interruption pour une raison quelconque, la transaction garantit de laisser la base de données dans l'état dans lequel elle l'avait trouvée.

    Figure 13: Représentation d'une transaction

    Une transaction est soit validée par un commit, soit annulée par un rollback, soit interrompue par un abort. Elle a une marque de début (Begin Of Transaction BOT) ainsi qu'une marque de fin (End Of Transaction EOT).

    Autrement, Une transaction est un traitement cohérent et fiable. La cohérence et la fiabilité d'une transaction sont garanties par 4 propriétés : l'Atomicité, la Cohérence, l'Isolation, la Durabilité qui font l'ACIDité d'une transaction.

    Parlant d'opérations d'une transaction, nous en comptons quatre types dont : le début de la transaction,la lecture, l'écriture et la terminaison.

    II.6.2. Condition de terminaison

    Une transaction n'échoue pas, elle est interrompue pour diverses raisons, ou arrive à son terme prévu. Pour assurer la cohérence de la base de données, en cas d'interruption de la transaction, un mécanisme se charge de défaire toutes les actions qui ont déjà été effectuées, c'est le rollback. Si la transaction n'est pas interrompue, elle se définit correctement et la base de données peut prendre en compte les changements. On appelle généralement ce signal que donne la transaction : commit ou validation.

    II.6.3. Propriétés des transactions

    Une transaction est composée d'une suite de requêtes dépendantes de la base qui doivent vérifier les propriétés d'atomicité, de cohérence, d'isolation et de durabilité, résumées par le vocable ACID.

    · Atomicité : cette propriété signifie qu'une transaction est traitée comme une seule opération. Toutes les actions sont toutes menées à bien ou aucune d'entre elles. C'est-à-dire qu'une transaction doit effectuer toutes ses mises à jour ou ne rien faire du tout. En cas d'échec, une transaction doit annuler toutes les modifications qu'elle a engagées.

    · Cohérence : une transaction est un programme qui amène la BD d'un état cohérent à un autre état cohérent, tel que toutes les contraintes d'intégrité restent vérifiées. En cas d'échec, l'état cohérent initial doit être restauré.

    · Isolation : c'est la propriété qui impose à chaque transaction de voir la BD cohérente. Une transaction en exécution ne peut révéler ses résultats à d'autres transactions concurrentes (simultanées) avant d'effectuer le commit.

    · Durabilité: c'est la propriété qui garantit lorsqu'une transaction a effectué son commit, le résultat en permanence, et ne pourra être effacé de la BD quelques soient les pannes du système rencontrées.

    II.7. Système de Gestion de Bases de Données Réparties

    II.7.1. Définitions

    Un système de gestion de bases de données réparties (SGBDR) est une application centrale qui administre une base de données répartie comme si toutes les données étaient stockées sur le même ordinateur.

    Il est donc un ensemble des logiciels qui gère des collections de bases des données logiquement reliées et distribuées sur un réseau, en fournissant un mécanisme d'accès qui rend la répartition transparente aux utilisateurs. Il cache de ce fait aux applications l'existence de multiples bases. C'est à dire, il contrôle la base de données répartie de sorte qu'il apparaisse en tant qu'une base de données simple aux utilisateurs.

    Ce système synchronise toutes les données à des moments donnés et lorsque plusieurs utilisateurs souhaitent accéder à la même donnée, il s'assure que les mises à jour, les modifications et suppressions opérées sur la donnée à un endroit, sont automatiquement répliquées aux autres endroits de stockage.

    A la différence, un SGBD est dit centralisé lorsque le logiciel contrôle l'accès à une base de données placée sur un ordinateur unique. Il est dit distribué lorsqu'il contrôle l'accès à des données qui sont dispersées entre plusieurs ordinateurs.

    Dans cette construction, un logiciel est placé sur chacun de différents sites, et ces sites utilisent des moyens de communication pour coordonner les opérations. Le fait que les informations sont dispersées est caché à l'utilisateur, et celles-ci sont présentées comme si elles se trouvaient à une seule place.

    En effet, une base de données centralisée est gérée par un seul SGBD et est stockée dans sa totalité à un emplacement physique unique. Ses divers traitements sont confiés à une seule et même unité de traitement. Par opposition, une base de données distribuée est gérée par plusieurs processeurs, sites ou SGBD.

    Le SGBD réparti doit offrir une gestion des priorités, verrous, concurrence de la même façon qu'un SGBD centralisé. Pour ce faire, il doit disposer de :

    · Dictionnaire des données reparties ;

    · Communication des données inter site ;

    · Gestion de la cohérence et de la sécurité ;

    · Traitement des requêtes reparties ;

    · Gestion des transactions reparties ;

    Un SGBDR est composé en plusieurs couches :

    · Le SGBD externe (user interface handler) : sa tâche est d'interpréter les commandes utilisateurs ;

    · Le système de gestion des fichiers (run-time support processor) : il gère le stockage physique de l'information. Il est dépendant du matériel utilisé.

    · Le contrôleur sémantique des données (semantec data controler) : il utilise les différentes contraintes définies sur la base de données afin de vérifier qu'une requête d'un utilisateur peut être effectuée.

    · Le gestionnaire de reprise (recovery manager) : il s'occupe d'assurer la cohérence des données lorsque des pannes surviennent.

    · Le processeur de requêtes (query processor) : il détermine une stratégie afin de minimiser le temps d'exécution d'une requête.

    II.7.2. Les caractéristiques d'un SGBD réparti

    Ces caractéristiquesd'un SGBD réparti sont reprises comme suit :

    · Un SGBD réparti est utilisé pour créer, rechercher, mettre à jour et supprimer les bases de données réparties ;

    · Il synchronise la base de données périodiquement et fournit des mécanismes d'accès par la vertu de laquelle la distribution devient transparente aux utilisateurs ;

    · Il s'assure que les données modifiées à n'importe quel emplacement sont universellement mises à jour ;

    · Il est utilisé dans des domaines d'application où des grands volumes de données sont traités et consultés par de nombreux utilisateurs simultanément ;

    · Il est conçu pour les plateformes ou environnements hétérogènes de base de données ;

    · Il maintient la confidentialité et l'intégrité des données des bases de données.

    II.7.3. Intérêt d'un SGBD réparti

    Les facteurs suivants encouragent la migration vers un SGBD réparti :

    II.7.3.1. Nature distribuée des unités d'organisation :

    La plupart des organismes dans les temps courants sont subdivisés en unités multiples qui sont physiquement réparties sur le globe. Chaque unité exige son propre ensemble de données locales. Ainsi, la base de données globale de l'organisation devient distribuée.

    II.7.3.2. Besoin de partage des données :

    Les unités d'organisation multiples doivent souvent communiquer entre eux et partager leurs données et ressources.Ceci exige les bases de données communes ou les bases de données repliées qui devraient être employées d'une façon synchronisée.

    II.7.3.3. Support d'OLTP et d'OLAP :

    Traitement transactionnel en ligne (OLTP) et le traitement analytique en ligne (OLAP) travaillent sur les systèmes diversifiés qui peuvent avoir des données communes.Les systèmes de base de données répartie facilitent ces deux traitements en fournissant des données synchronisées.

    II.7.3.4. Rétablissement de Base de données :

    Une des techniques communes utilisées dans un SGBD réparti est la réplication des données à travers différents sites. Cette technique aide automatiquement dans le rétablissement de données si la base de données dans n'importe quel site est endommagée.Les utilisateurs peuvent accéder à des données d'autres sites tandis que le site endommagé est reconstruit.Ainsi, l'échec de base de données peut devenir presque inaperçu aux utilisateurs.

    II.7.3.5. Support de multiple logiciel d'application :

    La plupart des organismes emploient une variété de logiciel d'application chacune avec son appui spécifique de base de données.Le SGBD réparti fournit une fonctionnalité uniforme pour l'usage des mêmes données parmi différentes plateformes.

    II.7.4. Architecture d'un SGBD réparti

    Des architectures des SGBD répartis sont généralement développées selon trois paramètres :

    · Distribution : elle énonce la distribution physique des données à travers les différents sites.

    · Autonomie : elle indique la distribution de contrôle du système de base de données et du degré auquel chaque composant du système de gestion de bases de données peut fonctionner indépendamment.

    · Hétérogénéité : elle se rapporte à l'uniformité ou à la dissimilitude des modèles de données, des composants de système et des bases de données.

    II.7.4.1. Modèles d'architecture des SGBD répartis

    Certains des modèles architecturaux communs sont :

    II.7.4.1.1. Architecture peer-to-peer

    Dans ces systèmes, chaque pair agit à la fois comme un client et un serveur pour donner des services de base de données.Les pairs partagent leur ressource avec d'autres pairs et coordonnent leurs activités.

    Cette architecture a généralement quatre niveaux des schémas :

    § Schéma Conceptuel Global : Dépeint la vue des données logique globale.

    § Schéma Conceptuel Local :Dépeint l'organisation logique de données à chaque emplacement.

    § Schéma Interne Local :Dépeint l'organisation physique de données à chaque emplacement.

    § Schéma Externe :Dépeint la vue d'utilisateur des données.

    Figure 14: Architecture peer-to-peer

    II.7.4.1.2. Architecture Client server

    C'est une architecture à deux niveaux où la fonctionnalité est divisée en serveurs et clients.Les fonctions de serveur entourent principalement la gestion des données, de traitement de requête, d'optimisation et de transaction. Les fonctions de client incluent principalement l'interface utilisateur. Cependant, elles ont certaines fonctions comme la vérification de l'uniformité et la gestion de transaction.

    Figure 15: Architecture client-serveur de SGBD Réparti

    Un client de SGBDR est une application qui accède aux informations distribuées par les interfaces du SGBDR tandis qu'un serveur de SGBDR est un SGBD gérant une base de données locale intégrée dans une base de données répartie.

    Au-delà des notions de client et de serveur SGBDR, on a un calculateur dans le réseau gérant la base appelé noeud ou site.

    II.7.4.2. SGBDR homogène

    Toutes les BD suivent un même schéma et utilisent la même technologie (ex: Oracle). L'accès aux données ainsi quela gestion des transactions réparties sont souvent faits de manière centralisée. En plus, cette architecture présente une plus grande fiabilité et performance dû à un meilleur couplage entre les sites.

    Figure 16: Architecture répartie avec SGBD répartis homogènes

    II.7.4.3. Multi-SGBD réparti

    Dans cette architecture, chaque site est autonome et peut avoir un SGBD de type différent. Ce qui conduit à l'utilisation des interfaces (ex: schéma conceptuel) différentes et cela peut devenir très complexe à gérer.

    Le Multi-Système de gestion de bases de données peut être exprimé par six niveaux des schémas :

    § Niveau De Vue Multi-base de données : Dépeint des vues multiples d'utilisateur comportant des sous-ensembles de la base de données répartie intégrée.

    § Niveau Conceptuel Multi-base de données :Dépeint la multi-base de données intégrée qui comporte des définitions logiques globales de structure de multi-base de données.

    § Niveau Interne Multi-base de données :Dépeint la distribution de données à travers différents emplacements et la multi-base de données aux données locales traçant.

    § Niveau local de vue de base de données :Dépeint la vue publique des données locales.

    § Niveau conceptuel de base de données locale :Dépeint l'organisation locale de données à chaque emplacement.

    § Niveau interne de base de données locale :Dépeint l'organisation physique de données à chaque emplacement.

    Figure 17: Architecture répartie avec multi-SGBD

    II.7.4.4. SGBD Fédérés

    L'architecture fédérée intègre plusieurs SGBD autonomes et potentiellement hétérogènes en une seule BD virtuelle dont l'interface d'accès commun doit être implémentée pour masquer l'hétérogénéité des BD et la répartition des données.

    L'inconvénient de cette architecture reste l'intégration du schéma, la réécriture des requêtes complexes ainsi que les performances limitées.

    Figure 18: Architecture répartie avec SGBD fédérés

    II.7.5. Objectifs du SGBDR

    Les objectifs d'un SGBDR se résument en ces aspects suivants :

    II.7.5.1. Multi client-serveur

    Dans le contexte du client serveur, un client peut demander l'exécution d'une requête à un serveur. La requête, appelée requête distante peut par exemple être exprimée en SQL. Pour assurer l'objectif multi clients, le SGBDR doit fournir des mécanismes de contrôle de concurrence adapté, garantissant que l'effet de l'exécution simultanée des transactions est le même que celui d'une exécution séquentielle : cette propriété est appelée la sérialisabilité des transactions.

    II.7.5.2. Transparence à la localisation des données

    Un des objectifs clés de SGBDR est de permettre l'écriture des programmes d'application sans connaître la localisation physique des données. Dans ce but, les noms des objets (par exemple le nom des tables) doivent être indépendants de leurs localisations. Les requêtes seront en général exprimées en SQL de manière similaire aux requêtes locales. Elles référenceront des vues de la base repartie ; ces vues porteront un nom ne concernant pas la localisation des données.

    La transparence à la localisation simplifie la vue utilisateur et l'écriture de requête, moins surtout d'introduire la possibilité de déplacer les objets (par exemple les tables) sans modifier les requêtes.

    II.7.5.3. Meilleure disponibilité des données

    L'apport en matière de disponibilité des données reste sans doute une des justifications essentielles d'un SGBDR. Tout d'abord, la répartition permet de ne plus dépendre d'un site central unique et en suite, elle permet de gérer des copies, de se replier sur une copie lorsqu'une autre est indisponible (site en panne), et même mettre à jour de manière indépendante les copies.

    Les copies deviennent alors des reliquats qui peuvent évoluer indépendamment pour converger ultérieurement. Cette fonctionnalité appelée réplication.

    Notons aussi que : assurer une meilleure disponibilité des données, c'est aussi garantir l'atomicité des transactions.

    II.7.5.4. Autonomie locale des sites

    Un autre objectif des SGBDR est d'éviter la nécessité d'une administration centralisée des bases. L'autonomie locale vise à garder une administration locale séparée et indépendante pour chaque serveur participant à la BD répartie.

    Ainsi, les reprises après panne doivent être accomplies localement et ne pas impacter les autres sites. Les mises à niveau de logiciel sur un site doivent être possible sans impacter les autres les autres sites. Bien que chaque base puisse travailler avec les autres, les gestions de schéma doivent rester indépendantes.

    II.7.5.5. Support d'hétérogénéité

    Un SGBDR hétérogène doit être capable d'unifier modèles et langage comme représenté Figure suivante. Ceci afin de gérer des bases fédérées. L'unification s'effectue en général par un langage pivot afin de limiter le nombre de conversion de modèle à réaliser.

    Nous avons vu tout au long de ce chapitre, ce qu'on appelle SGBDR, ses avantages et ses limites, ses caractéristiques, ses objectifset ses différentes sortes existantes. Dans le chapitre que nous allons aborder ici-bas, nous parlons de l'authentification par mesure biométrique en utilisant la technique d'empreinte digitale.

    CHAPITRE IIIème : AUTHENTIFICATION PAR EMPREINTES DIGITALES [2] [8] [11]

    De nos jours, toute organisation se veut, en son sein, d'une sécurité en vue de s'échapper à des fraudes, tricherie, espionnage et autre forme de menace pouvant nuire à son bien-être. C'est ainsi que tout commence par un processus pouvant permettre de déterminer qui a fait quoi, où, pourquoi, avec quoi et sur quoi. Ce processus n'est rien d'autre que l'authentification.

    En effet, l'authentificationprend la tête au niveau de la sécurité en ensemble et aussi dans les contrôles d'accès au sein de nos sociétés. Cette mesure est basée sur deux composantes :

    · L'identification dont le rôle est de définir les identités d'un utilisateur.

    · L'authentification permettant de vérifier les identités présumées des utilisateurs.

    Pour ce faire, nous devons recourir à des techniques permettant de répondre à ces conditions.L'une d'entre elles est celle de la biométrie et plus particulièrement la reconnaissance par empreintes digitales.

    III.1. Authentification

    III.1.1. Définition

    L'authentification est la procédure qui consiste, pour un système informatique, à vérifier l'identité d'une entité (individu ou ordinateur) afin d'autoriser son accès à des ressources (systèmes, réseaux, applications, ...).

    En effet, l'authentification permet de valider l'authenticité de l'entité en question.

    L'authentification par biométrie consiste à utiliser un système de reconnaissance basé sur les caractéristiques physiques ou comportementales d'un individu pour vérifier son identité.

    III.1.2. Type d'authentification

    Nous en distinguons trois types que voici :

    III.1.2.1. Authentification simple

    On parle de l'authentification simple lorsqu'il existe une seule preuve de l'identité. (Mot de passe par exemple).

    III.1.2.2. Authentification forte

    L'authentification forte est une procédure d'identification qui requiert plusieurs facteurs pour prouver l'identité de l'utilisateur (mot de passe et empreinte digitale par exemple). C'est la concaténation d'au moins deux facteurs d'authentification.

    III.1.2.3. Authentification unique

    C'est une méthode permettant à un utilisateur de ne procéder qu'à une seule authentification pour accéder à plusieurs applications informatiques (ou sites internet sécurisés).

    Outre, la notion d'authentification s'oppose à celle de l'identification d'une personne physique ou morale. Généralement, dans le cas d'un individu, l'authentification consiste à vérifier que celui-ci possède une preuve de son identité ou de son statut sous l'une de bases (éventuellement combinées) suivantes :

    · ce qu'il connait (mot de passe, PIN, phrase secrète ...) ;

    · ce qu'il possède (carte à puce, clé USB, un PDA, ...) ;

    · ce qu'il est : une caractéristique physique propre à un individu, on parle de la biométrie (empreinte digitale, ADN, empreinte oculaire, ...) ;

    · ce qu'il sait faire ou fait en faisant allusion à la biométrie comportementale (signature manuscrite, reconnaissance vocale, geste, un comportement quelconque...)

    Source: [ https://fr.m.wikipedia.org/wiki/Fichier:Auth-Forte-b.pnge]

    Dans la majeure partie, c'est l'individu qui s'authentifie. Mais cela peut être aussi fait par un objet comme une application web, par exemple, utilisant le protocole SSL, un serveur SSH, une marchandise, un animal, etc.

    On peut considérer que l'authentification forte est une des fondations essentielles pour garantir les éléments suivants dans un système informatique :

    · l'autorisation ou contrôle d'accès (qui a accès au système) ;

    · la confidentialité (qui peut le voir) ;

    · l'intégrité (qui peut le modifier) ;

    · la traçabilité (qui l'a fait) ;

    · l'irrévocabilité (qui peut le prouver).

    Sou forme pyramidale, l'authentification se présente de manière suivante :

    Source: [ https://fr.m.wikipedia.org/wiki/Fichier:Pyramide-auth.png]

    III.1.3. Les enjeux de l'authentification

    L'authentification constitue le socle de la traçabilité des transactions dans un système informatique. Elle permet :

    · la protection des intérêts supérieurs de l'Etat et du patrimoine informatique des entreprises consistant à la réduction des coûts qui résulte d'attaques, de la perte de temps, de la perte d'informations, de l'espionnage ou des fuites involontaires d'informations ;

    · le développement du commerce et des échanges électroniques. Elle bâtit la confiance dans l'économie numérique, ce qui est une vive condition indispensable du développement économique en favorisant la facturation des services ;

    · la protection de la vie privée aussi longtemps que les données personnelles véhiculant dans des systèmes d'information sont des données sensibles à protéger.

    III.2.Biométrie

    III.2.1. Définition

    La biométrie est l'étude mathématique des variations biologiques à l'intérieur d'un groupe déterminé ; alors que le système de contrôle biométrique est un système automatique de mesure basé sur la reconnaissance de caractéristiques propres à un individu.

    La biométrie recouvre l'ensemble des procédés tendant à identifier un individu à partir de la « mesure » de l'une ou de plusieurs de ses caractéristiques physiques, physiologiques ou comportementales. Il peut s'agir des empreintes digitales, de l'iris de l'oeil, du contour de la main, de l'ADN ou d'éléments comportementaux (la signature, la démarche) etc.

    A la différence de toute autre donnée d'identité, et à plus forte raison de toute autre donnée à caractère personnel, la donnée biométrique n'est pas attribuée par un tiers ou choisie par la personne : elle est produite par le corps lui-même et le désigne ou le représente, lui et nul autre, de façon immuable. Elle appartient donc à la personne qui l'a générée.

    En effet, elle recense nos caractères physiques (et comportementaux) les plus uniques, qui peuvent être captés par des instruments et interprétés par des ordinateurs de façon à être utilisés comme des représentants de nos personnes physiques dans le monde numérique. Ainsi, nous pouvons associer à notre identité des données numériques permanentes, régulières et dénuées de toute ambiguïté, et récupérer ces données rapidement et automatiquement à l'aide d'un ordinateur.

    III.2.2. Propriétés de la biométrie

    Nous décrivons dans ce cas les propriétés souhaitables d'une caractéristique biométrique. Cette caractéristique doit être :

    1) universelle : c'est-à-dire que toutes les personnes de la population à identifier doivent la posséder ;

    2) à la fois facilement et quantitativement mesurable ;

    3) unique : c'est-à-dire que deux personnes ne peuvent posséder exactement la même caractéristique. Même les jumeaux, par exemple, venant de la même cellule, auront des empreintes très proches mais pas semblables.

    4) immuable : cette caractéristique ne peut donc se modifier au cours de temps (sauf en cas de brûlure ou accident par exemple) ;

    5) permanente : ce qui signifie qu'elle ne doit pas varier au cours du temps ;

    6) performante : c'est-à-dire que l'identification doit être précise et rapide ;

    7) bien acceptée par les utilisateurs du système ;

    8) impossible à dupliquer par un imposteur.

    III.2.3. Architecture d'un système biométrique

    Un système biométrique comporte au moins deux modules, l'un pour l'apprentissage et l'autre pour la reconnaissance ainsi que l'autre facultatif pour une adaptation.

    Figure 19: Représentation d'une architecture d'un système biométrique

    III.2.3.1. Module d'apprentissage (enrôlement)

    Au cours de ce module, il est question de l'acquisition ou la capture de la caractéristique. Cette capture n'est stockée dans la base de données qu'après des certaines transformations lui appliquées.

    En effet, le signal contient de l'information inutile à la reconnaissance et seuls les paramètres pertinents sont extraits. Le modèle ou gabarit est une représentation compacte du signal qui permet de faciliter la phase de reconnaissance, mais aussi de diminuer la quantité de données à stocker. Il est à noter que la qualité du capteur peut grandement influencer les performances du système. Meilleure est la qualité du système d'acquisition, moins il y aura de prétraitements à effectuer pour extraire les paramètres du signal.

    III.2.3.2. Module de reconnaissance

    Au cours de la reconnaissance, la caractéristique biométrique est mesurée et un ensemble de paramètres est extrait comme lors de l'apprentissage. Le capteur utilisé doit avoir des propriétés aussi proches que possibles du capteur utilisé durant la phase d'apprentissage. Si les deux capteurs ont des propriétés trop différentes, il faudra en général appliquer une série de prétraitements supplémentaires pour limiter la dégradation des performances.

    III.2.3.3. Module d'adaptation

    Pendant la phase d'apprentissage, le système biométrique ne capture souvent que quelques instances d'un même attribut afin de limiter la gêne pour l'utilisateur. Il est donc difficile de construire un modèle assez général capable de décrire toutes les variations possibles de cet attribut. De plus, les caractéristiques de cette biométrie ainsi que ses conditions d'acquisition peuvent varier.

    L'adaptation est donc nécessaire pour maintenir ou améliorer la performance d'un système utilisation après utilisation. Elle est quasi indispensable pour les caractéristiques non permanentes comme la voix.

    III.2.4. Applications de la biométrie

    Nous pouvons distinguer quatre grands types d'applications de la biométrie : le contrôle d'accès (access control), l'authentification des transactions (transaction authentication), la répression (lawenforcement) et la personnalisation (personalization).

    a) Contrôle d'accès

    Le contrôle d'accès peut être lui-même subdivisé en deux sous catégories : le contrôle d'accès physique et le contrôle d'accès virtuel. On parle de contrôle d'accès physique lorsqu'un utilisateur cherche à accéder à un lieu sécurisé. On parle de contrôle d'accès virtuel dans le cas où un utilisateur cherche à accéder à une ressource ou un service.

    b) Authentification des transactions

    L'authentification des transactions représente un marché gigantesque puisqu'il englobe aussi bien le retrait d'argent au guichet des banques, les paiements par cartes bancaires, les transferts de fond, les paiements effectués à distance par téléphone ou sur internet, etc.

    c) Répression

    Une des applications les plus immédiates de la biométrie à la répression est la criminologie. La reconnaissance d'empreintes digitales en est l'exemple le plus connu. Elle fut acceptée dès le début du XXe siècle comme moyen d'identifier formellement un individu, et son utilisation s'est rapidement répandue. Il existe aussi des applications dans le domaine judiciaire. T-Netixpropose ainsi des solutions pour le suivi des individus en liberté surveillée en combinant les technologies de l'internet et de reconnaissance du locuteur.

    d) Personnalisation

    Les technologies biométriques peuvent être aussi utilisées afin de personnaliser les appareils que nous utilisons tous les jours. Cette application de la biométrie apporte un plus grand confort d'utilisation.

    Afin de personnaliser les réglages de sa voiture, Siemens propose par exemple d'utiliser la reconnaissance des empreintes digitales. Une fois l'utilisateur identifié, la voiture ajuste automatiquement les sièges, les rétroviseurs, la climatisation, etc.

    III.2.5. Panorama des différentes biométries

    Il existe plusieurs différentes techniques biométries utilisées actuellement pour prouver l'identité d'un individu.

    · Pour les caractéristiques physiques, nous avons la reconnaissance de visage, de thermo-gramme facial, d'empreintes digitales, de géométrie de la main, de rétine et d'iris.

    · Pour les caractéristiques comportementales, nous avons les systèmes basés sur la voix et la signature.

    Il existe d'autres méthodes biométriques basées sur les veines de la main, l'A.D.N. (acide désoxyribonucléique), l'odeur corporelle, la forme de l'oreille, la forme des lèvres, le rythme de frappe sur un clavier, la démarche, etc.

    Il est important de noter qu'il n'existe aucune caractéristique biométrique idéale. À chaque application correspond une ou plusieurs mesures biométriques appropriées.Cependant, concernant notre étude, nous allons nous concentrer sur une des technologies biométriques qu'est la reconnaissance des empreintes digitales.

    III.2.5.1. Empreinte digitale

    La technique des empreintes digitales est une des techniques les plus anciennes. Sur ce, elle a été développée à la fin du 19è siècle par Alphonse Bertillon, fondateur de la police scientifique en France.

    Par définition, une empreinte digitale est un dessin formé par les lignes de la peau des doigts, des paumes des mains, des orteils ou de la plante des pieds pendant la période foetale.

    Appelée aussi dermatoglyphe,une empreinte digitale est une signature que nous laissons derrière nous à chaque fois que nous touchons un objet. Les motifs dessinés par les crêtes et plis de la peau sont différents pour chaque individu ; c'est ce qui motive leur utilisation par la police criminelle depuis le 19è siècle.

    Figure 20: Capture d'une empreinte digitale

    On estime que les empreintes digitales commencent à se former entre la 10è et la 16è semaine de vie du foetus, par un plissement des couches cellulaires.

    Les circonvolutions des crêtes leur donnant leur dessin caractéristique vont dépendre de nombreux facteurs, comme la vitesse de croissance des doigts, l'alimentation du foetus, sa pression sanguine, etc. Ce qui fait que non seulement chaque individu, mais aussi chaque doigt, a son empreinte propre.

    Alors si deux vrais jumeaux ont des empreintes digitales ressemblantes, elles sont pourtant différentes. Elles seront considérées comme identiques lors d'une recherche sur une scène de crime parce que le nombre de points de comparaison utilisé est limité.

    Une empreinte complète contient en moyenne une centaine de points caractéristiques mais les contrôles ne sont effectués qu'àpartir de 14 points. Statistiquement, il est impossible de trouver 2 individus présentant 14 points caractéristiquesidentiques, même dans une population de plusieurs millions de personnes.

    En effet, les empreintes digitales sont uniques et caractéristiques d'un individu ; même les vrais jumeaux présentent des empreintes digitales différentes.

    III.2.5.1.1. Caractéristiques d'une empreinte digitale

    Une empreinte digitale est une marque laissée par les crêtes des doigts, des mains, des orteils ou des pieds lorsqu'elles touchent un objet.

    Il en existe deux types :

    · L'empreinte directe (qui laisse une marque visible) et

    · L'empreinte latente (saleté, sueur ou autre résidu déposé sur un objet).

    Les empreintes digitales sont regroupées en trois catégories principales regroupant à elles seules 95% des doigts humains: l'arche ou l'arc (arch), le tourbillon (whorl) et la boucle (loop). À l'intérieur de chacune de ces catégories, il y a un très grand nombre d'éléments qui nous différencient les uns des autres. En plus des cicatrices, il y a les fourches, les îlots et les espaces qui donnent un caractère unique aux empreintes latentes.

    Les« boucles » constituent les motifs les plus répandus qui représentent 60% des doigts humains : dans ce type d'empreinte se replient sur elles même soit vers la droite, soit vers la gauche. Viennent ensuite les « tourbillons », qui correspondent à 30% des doigts humains : cette empreinte, dite en verticille, comprend des lignes qui viennent s'enrouler autour d'un point, formant un genre de tourbillon. Pour finir, les motifs les moins répandus sont « les arches » qui regroupent seulement 5% des doigts humains : cette empreinte, en arc, contient des lignes disposées les unes au-dessus des autres qui forment des A.

    Figure 21: Exemple des catégories principales des empreintes digitales

    On différencie les motifs entre eux à l'aide de "points singuliers" appelés "minuties" sur les boucles, tourbillons ou arcs :

    a) points singuliers globaux :

    · noyau ou centre : lieu de convergences de stries ;

    · delta : lieu de divergences de stries ;

    b) points singuliers locaux (appelés aussi minuties) : ce sont les points d'irrégularité se trouvant sur les lignes papillaires (terminaisons, bifurcations, ilots assimilés à deux terminaisons, lacs).

    Quelle que soit sa forme, une empreinte digitale possède des points précis différents appelés minuties.

    On estime qu'il y a plus de cent points de convergence entre deux empreintes identiques relevées. Souvent, ces points de convergence sont des irrégularités sur les lignes papillaires. Les points les plus fréquemment utilisés dans les algorithmes lors de la comparaison sont de quatre types : les lacs, les terminaisons (à droite et à gauche), les bifurcations (à droite et à gauche) et les îles.

    Plus précisément, une minutie est un point qui se situe sur le changement de continuité des lignes papillaires. Ce sont grâce à elles que les empreintes digitales peuvent être différenciées.

    Figure 22: Différentes formes de minuties

    Figure 23: Les points singuliers d'une empreinte

    La validation d'une identification peut mettre en évidence jusqu'à quatorze points de comparaison (autrement appelés points caractéristiques ou minutie).

    Selon Francis Galton, la probabilité que deux personnes aient la même empreinte digitale est de 1 sur 64 milliard, ce qui est très faible à l'échelle de la population humaine et donc quasiment impossible.

    L'utilisation de l'empreinte digitale comme moyen d'identification d'une personne n'est pas nouvelle. En fait, la police scientifique utilise cette technique depuis plus de 100 ans. Aujourd'hui, les empreintes digitales sont recueillies sur une scène de crime et sont ensuite comparées à celles contenues dans un serveur central.

    III.2.5.1.2. Principe de fonctionnement

    Une empreinte digitale étant une des techniques du système biométrique, repose aussi sur deux modes de fonctionnement : l'enrôlement et l'authentification en vue de déterminer l'identité d'un individu.

    L'authentification par empreinte digitale repose sur la concordance entre le fichier d'enregistrement ou signature obtenu lors de l'enrôlement et le fichier obtenu lors de l'authentification.

    Le principe de fonctionnement d'une empreinte digitale se décompose en deux étapes suivantes :

    a) Enrôlement

    L'enrôlement d'un individu se réalise comme suit :

    · capture de l'image ;

    · numérisation de l'image afin d'en extraire les minuties ;

    · enregistrement sur un support (carte à puce, disque dur, ...).

    b) Authentification

    À son tour, l'authentification se fait de la manière suivante :

    · capture de l'image ;

    · numérisation de l'image afin d'en extraire les minuties ;

    · comparaison entre échantillon et le gabarit (signature) ;

    · prise de décision.

    III.2.5.1.3. Etapes de traitement informatique de l'empreinte digitale

    Plusieurs méthodes sont utilisées pour reconnaitre les empreintes digitales dont : la localisation des minuties, le traitement des textures ainsi que d'autres beaucoup d'autres techniques non encore divulguées dans un but de confidentialité.

    Pour ce travail, nous nous intéresserons à la technique de localisation de minuties. Le traitement de l'empreinte digitale par cette technique se base sur trois principales étapes : la numérisation de l'image, l'extraction des minuties et la comparaison des gabarits.

    a) Numérisation de l'image

    Cette technique consiste à numériser l'empreinte digitale et la filtrer de façon à la nettoyer des caractéristiques inutiles telles que des cicatrices (segmentation). L'image à numériser peut bien être de format BITMAP pour le traitement ainsi que l'échange des images avec les applications sous Windows. L'origine des images n'a pas d'importance (scanner, fichier, caméra, code barre...).

    L'image ainsi numérisée en noir et blanc doit être filtrée dans le but de supprimer toute ambiguïté en détectant des zones de bruit et en faisant ressortir la plus grande partie possible d'information utile au système. Cette étape se chargera bien également de détecter l'absence d'empreinte, un niveau élevé de bruit dans l'image (image sale ou lecteur défectueux), un positionnement incorrect du doigt.

    Une fois l'image filtrée, les lignes se voient clairement mais elles ont des tailles différentes. Pour pouvoir détecter rapidement les minuties (terminaisons, bifurcations), on crée un squelette de chaque empreinte grâce aux algorithmes complexes en vue de rendre chaque ligne (crête) de l'empreinte de 5 à 8 pixels à une épaisseur égale d'un pixel.

    Figure 24: Squelettisation d'une empreinte digitale

    Chaque minutie est repérée et répertoriée grâce à son type (bifurcation B ou terminaison T), à sa position dans l'image (coordonnées x et y) et à sa direction ).

    Figure 25: Exemple de repérage des minuties

    b) Extraction des minuties

    L'extraction des minuties est un processus final qui complète l'obtention de la signature de l'empreinte grâce à différents algorithmes.

    Le gabarit retenu pour caractériser l'empreinte est basé sur un nombre minimum allant de douze à quatorze minuties, ou encore plus, nécessaires pour pouvoir établir des comparaisons fiables, c'est-à-dire des comparaisons non influencées par certains défauts lors l'acquisition de l'image ou par l'altération temporaire (blessure, ....), entre empreintes. Ce qui fait qu'avec ce minimum de minuties correctement relevées et localisées, il est possible d'identifier une empreinte parmi plusieurs millions d'exemplaires.

    Figure 26: Extraction des minuties d'une empreinte

    c) Comparaison des gabarits

    La comparaison de deux ensembles de minuties (fichier "gabarit"), correspondants respectivement à deux doigts à comparer constitue le système de vérification d'identité.

    Pour déterminer si deux ensembles de minuties extraits de deux images correspondent à des empreintes du même doigt, il est nécessaire d'adopter un système de comparaison qui soit insensible à d'éventuelles translations, rotations et déformations qui affectent systématiquement les empreintes digitales.

    Normalement, à partir de deux ensembles de minuties extraites, le système doit être capable de donner un indice de similitude ou de correspondance qui vaut :

    · 0 % si les empreintes sont totalement différentes ;

    · 100 % si les empreintes viennent de la même image.

    Par ailleurs, deux fichiers " gabarit " calculées à partir de la même empreinte ne donneront jamais 100 % de ressemblance du fait des différences qui existent lors de l'acquisition de deux images (petites déformations ou déplacements), ils donneront cependant toujours un niveau élevé de similitude.

    Figure 27: Authentification par empreinte digitale

    La décision à partir de cet indice de similitude de savoir si deux empreintes sont issues du même doigt est une question purement statistique. Pour décider d'accepter la similitude entre deux " gabarit ", il faut établir un seuil d'acceptation.

    III.2.4.4. Avantages et inconvénients d'une empreinte digitale informatisée

    a) Avantages

    Chaque être humain a sa propre empreinte unique. A cet effet, les empreintes digitales peuvent servir à l'identification des personnes à de nombreuses fins :

    · Prévention des fraudes pour résoudre des crimes.

    · Economie de l'espace avec chaque dossier numérisé ;

    · Temps optimisé pour l'accès au dossier d'un individu, ce qui peut aider les forces policières à résoudre des crimes plus rapidement et efficacement ;

    · Quasi-impossible d'être craquée ;

    · Moins salissant que la méthode de l'encre ;

    · Pas de vol, d'oubli, de copie ni de perte d'identité ;

    b) Limites

    · Les empreintes digitales informatisées peuvent être utilisées pour une fausse identification des personnes au cas où le système d'empreinte digitale est mal paramétré ou ne fonctionne pas correctement;

    · Elles peuvent être déformées, ce qui conduit à des erreurs d'identification ;

    · Impossible d'être changée lorsqu'elle est compromise ;

    · Difficulté de reconnaissance d'empreintes lorsque le doigt est crémé, humide, blessé, ...

    · L'utilisation des faux doigts peut tromper la machine, mais ceci demande beaucoup de compétences ;

    Nous avons abordé dans ce chapitre, les concepts de base concernant l'authentification en utilisant la technique d'empreintes digitale. Nous avons passé la main sur les différents avantages et limites de cette authentification et avons aussi relevé le point sur le processus d'authentification par empreinte digitale.

    Dans le chapitre suivant, nous parlerons de l'entité pour laquelle nous avons mené nos études correspondant au suivi du casier judiciaire. Nous verrons comment notre domaine d'étude exploite ce point d'identification et de suivi du casier judiciaire de citoyens congolais.

    CHAPITRE IVème : ANALYSE PREALABLE

    IV.1. Présentation de la direction du casier judiciaire

    IV.1.1. Historique

    En 1934, le service du casier judiciaire (CJ) est organisé au parquet général de Léopoldville (actuellement Kinshasa) avec comme compétence sur toutes les colonies (Congo, Rwanda et Burundi).

    A l'époque coloniale, il n'existait pas une cours suprême de justice, et c'est la cours de cassation belge qui remplissait cette tâche jusqu'au 6 novembre 1956. Il y a eu l'article 3 bisde l'ordonnance 121365 du 6 novembre 1956 qui donne compétence au procureur général près de la cours pénale de Léopoldville ou à son délégué de divulguer les extraits du casier judiciaire.

    En 1969, il y a eu création de la cours suprême de justice. Cette compétence revient de plein droit au procureur général de la République Démocratique du Congo.

    IV.1.2. Mission

    Adoptées par la police du monde entier, les empreintes digitales sont une des clés des investigations criminelles.

    La direction de l'identité judiciaire (DIJ) est un service purement technique au sein de la direction générale de la police judiciaire de parquet ayant pour mission d'une part, l'identification des personnes afin de sceller leurs passés judiciaires plus des antécédents des individus et d'autre part, un service général des recettes pour le compte du trésor public.

    Elle est l'une des directions la plus importantes de la police judiciaire du parquet parce qu'elle couvre tous le territoire national. Elle s'occupe du prélèvement des empreintes digitales, de la codification, des recherches des antécédents judiciaires dans le fichier central, de la vérification avant de délivrer l'extrait du casier judiciaire comportant la formule dactyloscopique et ses subdivisions.

    L'inspecteur judiciaire en chef, le directeur chef des services du casier judiciaire signent les extraits du casier judiciaire par délégation du pouvoir du procureur général de la République.

    IV.1.3. Situation géographique

    Géographiquement parlant, la Direction du casier judiciaire se situe au numéro 30 de l'avenue KALEMIE, sise au croisement des avenues KALEMIE et MISSION, dans la commune de la Gombe et dans la ville province de Kinshasa.

    IV.1.4. Structure organisationnelle et fonctionnelle

    IV.1.4.1. Structure organisationnelle

    La direction du casier judiciaire est une direction de la police judiciaire comme tant d'autres. L'organisation interne se fait sous une structure d'échelle suivante :

    · La division de l'identité judiciaire (DIJ)

    · La division administrative et financière (DAF)

    · La division du fichier central (DFC)

    · La division informatique (DI)

    Source: [Direction du casier judiciaire]

    Chaque division contient des sections qui sont représentées par chacune des provinces de la République Démocratique du Congo. C'est-à-dire qu'actuellement, chaque division compte vingt-six (26) sections.

    Dans des sections, nous retrouvons des brigades ou commissariats où sont identifiés les assujettis et ce fichier est envoyé à la division du fichier central pour être centralisé.

    La direction du casier judiciaire reste le service spécialisé du parquet général de la République. Elle a son siège dans le chef-lieu de chaque province et elle est attachée au parquet général dans chaque province.

    IV.1.4.2. Structure fonctionnelle

    IV.1.4.2.1. Scénario

    Ce scénario présente le déroulement des activités de la Direction du Casier Judiciaire dans le but d'avoir son extrait du casier judiciaire.

    a) Aspect administratif

    Le postulant (assujetti ou requérant) arrive à la réception du service du casier judiciaire et y dépose sa carte d'identité pour être identifié. Il passe acheter la fiche décadactylaire qu'il remplit lui-même muni des copies de ses pièces d'identité (carte d'électeur, passeport, diplôme, ...).

    Il passe à la DIJ où on vérifiera l'authenticité des renseignements fournis sur la fiche décadactylaire. Après là, il est orienté chez le responsable des empreintes digitales qui le confie à son tour à l'empreintiste pour le prélèvement des empreintes.

    Une fois ceci fait, le postulant se rendra à la DGRAD pour l'établissement de la note de perception avec laquelle il ira payer à la banque pour le retrait de son extrait du casier judiciaire.

    b) Aspect technique

    Ensuite, on procède à la codification des empreintes digitales pour sortir la formule dactyloscopique (exploitation des empreintes digitales ou analyse des figures).

    Après cette phase de codification, vient celle de recherche au niveau du fichier central pour vérifier si le requérant a des antécédents judiciaire.

    En effet, il y a antécédents judiciaires lorsqu'il y a condamnation c'est-à-dire, quand le tribunal dit le droit ou demande l'arrestation immédiate de la personne par le parquet.

    Cette technique de recherche se base sur deux méthodes nommée alphanumérique, c'est-à-dire que la recherche peut se faire suivant le classement alphabétique ou numérique.

    IV.1.5. Etude des documents

    IV.1.5.1. Répertoire des documents internes

    Ce sont ces documents produits dans les différents postes de notre domaine et par rapport avec notre processus, nous n'avons que les documents internes. Nous les avons consultés dans le but de récolter les données dont nous avions besoin dans l'élaboration de ce travail.

    DESIGNATION

    CODE DOCUMENTS

    EMETTEUR

    DESTINATAIRE

    FREQUENCE

    1

    Fiche décadactylaire

    FD

    DIJ

    Postulant

    Journalière

    2

    Extrait du casier judiciaire

    ECJ

    DIJ

    Postulant

    Journalière

    Tableau 5 :Description des documents internes

    IV.1.5.2.1. Description des documents

    a) Fiche décadactylaire

    La fiche décadactylaire est une fiche que le postulant remplit lui-même son identité et elle contient aussi les empreintes digitales de celui-ci.

    Source: [Direction du casier judiciaire]

    b) Extrait du casier judiciaire

    L'extrait du casier judiciaire est un document qui sert à connaitre le passé judiciaire (antécédent judiciaire) de quelqu'un.

    Source: [Direction du casier judiciaire]

    1) Catégories d'un extrait de casier judiciaire

    1. Extrait du CJ avec ED

    a) Si le postulant ou l'assujetti n'a jamais été arrêté ou condamné, soit arrêté mais son jugement n'a pas encore acquis la force des chosées jugées (c'est-à-dire, son jugement n'a pas encore épuisé toutes les voies de recourt), l'extrait de son casier judiciaire portera la mention "PAS D'ANTECEDENT JUDICIAIRE CONNU" ;

    b) Si le postulant a fait l'objet de l'amnistie ou de la réhabilitation suite à une condamnation, il bénéficie d'un extrait du CJ avec mention : "PAS D'ANTECEDENT JUDICIAIRE : NEANT". Toutefois, les effets de la condamnation ne sont pas effacés que par un arrêt de a réhabilitation d'une cour d'appel ou par une loi d'amnistie internationale. La prescription des peines ne joue qu'en ce qui concerne leur exécution mais la condamnation demeure.

    2. Extrait du CJ sans ED

    a) Si le postulant est âgé entre 0 et 12 ans, il sera exempté des empreintes digitales et il produira une attestation ou certificat de naissance. L'extrait du casier judiciaire portera la mention : « ENFANT A BAS AGE ». On écrira dans l'extrait le nom, le post nom, et le prénom de l'enfant, le lieu et date de naissance, les noms des parents (fille ou fils de ...). Et on écrira aussi autre mention : "ANTECEDENT : NEANT".

    b) Pour une quelconque indisponibilité, le postulant ne peut se présenter au service du casier judiciaire pour se faire prélever les empreintes digitales. Il obtiendra un extrait avec mention :"SOUS RESERVE DE L'IDENTIFICATION ULTERIEURE", "ANTECEDENT JUDICIAIRE : NEANT"

    IV.1.5.2. Répertoire des documents externes

    Ce sont ces documents que le postulant détient et qui lui sont demandé par le service pour parvenir à l'obtention d'un extrait du casier.

    DESIGNATION

    CODE DOCUMENTS

    EMETTEUR

    DESTINATAIRE

    FREQUENCE

    1

    Pièce d'identité

    PID

    Postulant

    Réception

    Journalière

    2

    Bordereau de paiement

    BP

    Banque

    DGRAD

    Journalière

    3

    Certificat de naissance

    CN

    Postulant

    DCJ

    Journalière

    Tableau 6 : Description des documents externes

    IV.1.5.2.1. Description des documents externes

    1. Pièce d'identité

    C'est un document qui identifie la personne. Parlant de la pièce d'identité, nous citons : la carte d'électeur, le passeport, le diplôme, ...

    2. Bordereau de payement

    Ce document est la preuve que l'assujetti a payé les frais d'obtention d'un extrait du casier judiciaire.

    3. Certificat de naissance

    Le certificat de naissance est un document porté par le postulant lors de l'obtention d'un extrait du casier judiciaire lorsque celui-ci est mineur.

    IV.6. Critiques de l'existant

    IV.6.1. Aspects positif

    La direction du casier judiciaire dans son service d'identification judiciaire et fichier central est l'unique service habileté à faire ce service au niveau national. Sa maitrise en termes de processus est sa spécialité. Grâce à elle, la conduite de chaqueindividu sur le plan national et international est suivie et fichée.

    Elle dispose des agents très compétents en matière et capable de rendre complètement le service malgré que toutes les techniques utilisées sont manuelles.

    IV.6.2. Aspect négatif

    Bien que ce service rende bien son service dans le processus de l'identification des individus en vue de connaitre leur passé par une mesure de délivrance d'un document appelé "casier judiciaire", une question de performance et de disponibilité se pose.

    En ces qualités, le service devient faillible en rapport avec les mécanismes mis en place compte tenu d'un grand nombre d'informations qui doit être traité. En effet,le travail effectué au sein de ce service est totalement centralisé à tel point que toutes les données provenant de toutes les provinces de la République sont compilées et envoyées par différentes voies pouvant présenter des énormes possibilités d'insécurité (agences, main à main, ...), afin d'être toutes traitées sur place à la direction générale à Kinshasa.

    Les provinces ne sont pas autonomes car elles dépendent toutes de la direction générale à Kinshasa, ce qui veut dire que si un individu est condamné dans une province, son dossier est envoyé à Kinshasa pour être traité et fiché. Disons que le temps que ça peut prendre est important lorsque l'on veut savoir les antécédents judiciaires de cet homme afin de s'assurer de son passé judiciaire !

    D'une façon globale, disons que ce service vit encore dans le passé car le suivi manuel du casier judiciaire ne donne pas image de ce qui devrait être fait pour garantir ce secteur partout dans toute l'étendue de la république.

    Autrement, la Direction du Casier Judiciaire ne compte que quelques outils de travail,actuellement, pour pouvoir traiter toutes les données de toute la République. Tous ces détails donnent un aperçu désagréable des services au sein de la Direction du Casier Judiciaire bien que les techniques d'identification pour avoir une formule dactyloscopique sont néanmoins efficaces.

    IV.6.3. Proposition des solutions

    En vue de promouvoir une meilleure qualité du travail en termes des performances et un traitement en temps réel au sein de la direction du casier judiciaire, et vu toute cette masse de données à traiter dans chaque coin du pays, une architecture distribuée conviendrait le mieux pour résoudre ce problème.

    De ce fait, toute les provinces seront des sites interconnectés grâce à un réseau informatique et partageant les ressources en vue de permettre la fiabilité dans ce système, ce qui est traduit par la disponibilité des données, au lieu que tous les traitements soient centralisés.

    En effet, le but de ce système est de pouvoir suivre en continu le casier judiciaire de chaque individu, partout où il peut se retrouver et de lutter aussi contre les récidivistes quelques soient les fonctions pour lesquelles ils sont élevés en dignité.

    Certes, dans tous les domaines où le casier judiciaire est fortement demandé, notre système interviendra pour pouvoir identifier les individus en vue de savoir leurs passés (antécédents judiciaires) dans le but de décider sur leur sort. Nos institutions judiciaires sont privilégiées dans ce cadre pour améliorer leur façon de travailler.

    Ce système substituera de toute manière la centralisation des données des individus par la décentralisation où chaque province deviendrait un site autonome. Il évitera aussi les déplacements des individus ou de leurs dossiers vers la Direction du Casier Judiciaire de Kinshasa pour le prélèvement des empreintes ou l'obtention de leurs extraits de casier judiciaire.

    Eu égard à ce chapitre, nous avons abordé l'analyse de notre système d'étude en parcourant certains documents utilisés pour pouvoir identifier les individus. Toutefois, nous avons abordé le processus d'identification des individus ainsi que les techniques utilisées pour se faire, ce qui nous a aidé à déceler certaines défaillances dans ce système pour lesquelles nous avons apporté des solutions au travers ce travail.

    Dans le prochain chapitre, nous nous penchons à la conception et implémentationd'un nouveau système informatisé pour le suivi du casier judiciaire.

    CHAPITRE Vème : CONCEPTION ET IMPLEMENTATION DU SYSTEME

    V.1. Etude de l'application

    Nous venons d'aborder la matière concernantles systèmes distribués, les bases de données et leur réplication ainsi que l'authentification par empreinte digitale. C'est dans ce chapitre que nous allons réellement rendre pratique toute cette théorie réalisée tout au long de notre étude.

    En effet, nous allons réaliser une application informatique pour aider le service du casier judiciaire dans le processus de son métier d'identification et de fichage de données de condamnés, dans le but de rendre facile le traitement de données pour un bon suivi de ceux-ci.

    Sur ce, nous allons développer cette application sous un environnement intégré de développement nomméNetBeans, en utilisant le langage Java pour la programmation. Le SGBD utilisé est le SQL Server 2008 R2 pour la conception de notre base des données, le développement même, la configuration ainsi que la réplication des données.

    V.1.1. Architecture réseau

    La mise en oeuvre de ce système ne sera possible que s'il existe une architecture réseau grâce à laquelle les données/ressources seront partagées entre sites. Bien entendu, cette architecture est proportionnelle à l'importance du système à mettre en oeuvre.

    Dans notre cas, vu l'importance des publications en continue et l'importance de données à répliquer, nous avons opté pour la technologie Vsat pour interconnecter tous nos sites.

    V.1.1.1. VSAT

    Le VSAT, pour Very Small Aperture Terminal (`terminal à très petite ouverture') désigne une technique de communication par satellite bidirectionnelle qui utilise des antennes paraboliques dont le diamètre est inférieur à 3 mètres.

    Le VSAT est constitué de trois parties principales à savoir :

    § Le hub : il s'agit du coeur du réseau. Le hubdispose d'une antenne ayant un diamètre compris entre 7m et 9m, ayant le même principe de fonctionnement qu'une station terrienne ;

    § Le satellite : c'est un relais hertzien ;

    § Les stations distantes (ou remote) en anglais.

    Source: [ http://www.google.com/vsat]

    Cette technique de communication nécessite donc un peu de moyens au sol. Le VSAT peut donc être utile pour relier un site aux réseaux de communication, que ce soit pour la téléphonie ou pour l'accès à Internet.

    La plupart des réseaux VSAT sont généralement configurés selon une de ces topologies :

    · Une topologie en étoile (star topology), utilise un point central, tel qu'un HUB ou NOC (Networks Operations Center), pour relier les VSAT entre eux à travers le satellite ;

    · Une topologie en mesh (meshtopology), où chaque VSAT est directement connecté à un autre VSAT en passant par le satellite mais pas par le HUB/NOC. Il n'existe pas, dans ce cas, de point central ;

    · Une combinaison de deux topologies précédentes (étoile et mesh).

    En effet, les VSAT utilisent des plateformes différentes pour transmettre et recevoir des données via des satellites.

    a) Avantages

    · Gestion facile réseau ;

    · Provision de Bande passante garantie avec engagement de livraison ;

    · Service à distance indépendante ;

    · Couverture globale immédiate ;

    · Installation rapide et facile dans des zones difficiles d'accès ;

    · Possibilité d'adaptation aux besoins de chaque entreprise ;

    · Extension et reconfiguration du réseau facile ;

    · Accès avec n'importe quel point dans la zone de couverture grâce à satellite ;

    · Stabilité des coûts d'exploitation du réseau pendant une longue période ;

    · Installation et mise en route rapide ;

    · Service fiable : disponibilité minimum garantie de 99.5% en réception et 99.5% en transmission pour le lien satellite (données) ;

    · Couverture omniprésente sans restriction de zone géographique ;

    · Etc.

    b) Inconvénient

    · Coût élevé ;

    · Couverture fixe ;

    c) Exemple d'utilisations fréquentes de VSAT configuré pour recevoir et envoyerdes informations

    · Formation à distance par téléconférences ;

    · Transactions bancaires ;

    · Internet ;

    · Surveillance et contrôle ;

    · Etc.

    V.2. Modélisation en UML du domaine

    La modélisation est une étape fondamentale lorsque l'on veut donner une solution informatique à un problème posé. Elle couvre des grands concepts parmi lesquels l'analyse et conception restent une garantie pour un concepteur d'arriver aux bonnes fins dans le processus de ses activités.

    L'approche objet est incontournable dans le cadre du développement de systèmes logiciels complexes, capables de suivre les évolutions incessantes des technologies et des besoins applicatifs. En effet, l'approche objet requiert une modélisation.Donc on analyse avant de concevoir.

    La modélisation apporte une grande rigueur, offre une meilleure compréhension des logiciels, et facilite la comparaison des solutions de conception avant leur développement. Cette démarche se fonde sur des langages de modélisation, qui permettent de s'affranchir des contraintes des langages d'implémentation.

    Pour se faire, nous avons fait recourt au langage UML, dans sa version 2, dans le cadre de notre étude. UML est une notation graphique conçue pour représenter, spécifier, construire et documenter les systèmes logiciels. Ses deux principaux objectifs sont la modélisation de systèmes utilisant les techniques orientées objet, depuis la conception jusqu'à la maintenance, et la création d'un langage abstrait compréhensible par l'homme et interprétable par les machines.

    Il permet de construire plusieurs modèles d'un système, chacun mettant en valeur des aspects différents : fonctionnels, statiques, dynamiques et organisationnels. UML est devenu un langage incontournable dans les projets de développement.

    Une méthode de développement définit à la fois un langage de modélisation et la marche à suivre lors de la conception. Par ailleurs, le langage UML propose uniquement une notation dont l'interprétation est définie par un standard, mais pas une méthodologie complète. C'est à ce titre qu'il ne faut pas confondre UML comme une méthode de développement.

    V.2.1. Objectif dela modélisation

    Un modèle est une représentation simplifiée d'une réalité. Il permet de capturer des aspects pertinents pour répondre à un objectif défini a priori. Par exemple, un astronaute modélisera la Lune comme un corps céleste ayant une certaine masse et se trouvant à une certaine distance de la Terre, alors qu'un poète la modélisera comme une dame avec laquelle il peut avoir une conversation.

    Quand le modèle devient compliqué, il est souhaitable de le décomposer en plusieurs modèles simples et manipulables.

    L'expression d'un modèle se fait dans un langage compatible avec le système modélisé et les objectifs attendus. Ainsi, le physicien qui modélise la lune utilisera les mathématiques comme langage de modélisation. Dans le cas du logiciel, l'un des langages utilisés pour la modélisation est le langage UML. Il possède une sémantique propre et une syntaxe composée de graphique et de texte et peut prendre plusieurs formes (diagrammes).

    Parlant des diagrammes, UML 2 en possède plus d'une dizaine. Et concernant notre étude, nous allons juste présenter quatre diagrammes dont : le diagramme de cas d'utilisation, le diagramme de séquence, le diagramme d'activité et le diagramme de classe.

    V.2.2. Diagramme de cas d'utilisation

    Ce diagramme montre les interactions fonctionnelles entre les acteurs et le système à l'étude.Autrement, les cas d'utilisations décrivent sous la forme d'actions et des réactions le comportement d'un système du point de vue d'un utilisateur.

    · Intérêt : Les cas d'utilisations recentrent l'expression des besoins sur les utilisateurs, en partant du point de vue qui veut qu'un système soit avant tout construit pour les utilisateurs.

    Nous présentons ici le diagramme de cas d'utilisation comme suit :

    Figure 28: Représentation du diagramme de cas d'utilisation

    V.2.3. Diagramme d'activité

    Le diagramme d'activité permet d'explorer la totalité de branches du processus. Il permet de mettre l'accent sur les traitements et sa représentation graphique façonne le comportement d'une méthode ou le déroulement d'un cas d'utilisation. D'une façon particulière, ce diagramme est adapté à la modélisation du cheminement de flots de contrôle et de flots de données.

    Nous représentons notre diagramme d'activité comme suit :

    Figure 29: Représentation du diagramme d'activités

    V.2.4. Diagramme de classe

    Le diagramme de classes est le point central dans un développement orienté objet. En analyse, il a pour objet de décrire la structure des entités manipulées par les utilisateurs.

    Figure 30: Présentation du diagramme de classe

    V.2.5. Conception du schéma global

    Le schéma global correspondant à notre système se traduit par le modèle relationnel de la base de données qui est une traduction du diagramme de classe montré ci-haut. Notons que chacune des tables du modèle relationnel bénéficiera d'un identifiant. Ce schéma est représenté comme suivant :

    Figure 31: Représentation du schéma global

    V.2.6. Schémas locaux

    Etant donné l'impact du système à mettre en place, nous avons jugé bon garder le même schéma global comme schéma dans chaque site local. Donc c'est le modèle relationnel correspondant à notre schéma global qui serait bien sûr le schémalocal dans chaque site.

    Figure 32: Représentation du schéma local

    V.2.7. Script de création de la base de données

    USE[master]

    GO

    -- =============================================

    -- Author: Juslin TSHIAMUA

    -- Script Date: 09/30/2016 06:50:40

    -- Object: Database [CasierDB]

    -- =============================================

    CREATEDATABASE[BD_Casier]ONPRIMARY

    (NAME=N'BD_Casier',FILENAME=N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\BD_Casier.mdf',SIZE= 3072KB,MAXSIZE=UNLIMITED,FILEGROWTH= 1024KB)

    LOGON

    (NAME=N'BD_Casier_log',FILENAME=N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\BD_Casier_log.ldf',SIZE= 1024KB,MAXSIZE= 2048GB,FILEGROWTH= 10%)

    GO

    USE[BD_Casier]

    GO

    CREATETABLE[dbo].[Dossier](

    [Code_dos][int]IDENTITY(1,1)NOTNULL,

    [Crime][varchar](30)NOTNULL,

    [Peine][varchar](25)NOTNULL,

    [Juridict][varchar](25)NOTNULL,

    [Date_condam][char](10)NOTNULL,

    CONSTRAINT[PK_Dossier]PRIMARYKEYCLUSTERED

    (

    [Code_dos]ASC

    )WITH (PAD_INDEX=OFF,STATISTICS_NORECOMPUTE=OFF,IGNORE_DUP_KEY=OFF,ALLOW_ROW_LOCKS=ON,ALLOW_PAGE_LOCKS=ON)ON[PRIMARY]

    )ON[PRIMARY]

    GO

    CREATETABLE[dbo].[Province](

    [Id_prov][int]IDENTITY(1,1)NOTNULL,

    [Nom_prov][varchar](25)NOTNULL,

    CONSTRAINT[PK_Province]PRIMARYKEYCLUSTERED

    (

    [Id_prov]ASC

    )WITH (PAD_INDEX=OFF,STATISTICS_NORECOMPUTE=OFF,IGNORE_DUP_KEY=OFF,ALLOW_ROW_LOCKS=ON,ALLOW_PAGE_LOCKS=ON)ON[PRIMARY]

    )ON[PRIMARY]

    GO

    CREATETABLE[dbo].[Civil](

    [NumeroId][int]IDENTITY(1,1)NOTNULL,

    [Detail_sup][varchar](50)NULL,

    [Code_dos][int]NULL,

    CONSTRAINT[PK_Civil]PRIMARYKEYCLUSTERED

    (

    [NumeroId]ASC

    )WITH (PAD_INDEX=OFF,STATISTICS_NORECOMPUTE=OFF,IGNORE_DUP_KEY=OFF,ALLOW_ROW_LOCKS=ON,ALLOW_PAGE_LOCKS=ON)ON[PRIMARY]

    )ON[PRIMARY]

    GO

    CREATETABLE[dbo].[Ville](

    [Id_vil][int]IDENTITY(1,1)NOTNULL,

    [Nom_vil][varchar](25)NOTNULL,

    [Id_prov][int]NOTNULL,

    CONSTRAINT[PK_Ville]PRIMARYKEYCLUSTERED

    (

    [Id_vil]ASC

    )WITH (PAD_INDEX=OFF,STATISTICS_NORECOMPUTE=OFF,IGNORE_DUP_KEY=OFF,ALLOW_ROW_LOCKS=ON,ALLOW_PAGE_LOCKS=ON)ON[PRIMARY]

    )ON[PRIMARY]

    GO

    CREATETABLE[dbo].[Militare](

    [Matricule][varchar](10)NOTNULL,

    [Unite][varchar](15)NOTNULL,

    [Code_dos][int]NULL,

    CONSTRAINT[PK_Militaire]PRIMARYKEYCLUSTERED

    (

    [Matricule]ASC

    )WITH (PAD_INDEX=OFF,STATISTICS_NORECOMPUTE=OFF,IGNORE_DUP_KEY=OFF,ALLOW_ROW_LOCKS=ON,ALLOW_PAGE_LOCKS=ON)ON[PRIMARY]

    )ON[PRIMARY]

    GO

    CREATETABLE[dbo].[Commune](

    [Id_com][int]IDENTITY(1,1)NOTNULL,

    [Nom_com][varchar](25)NOTNULL,

    [Id_vil][int]NOTNULL,

    CONSTRAINT[PK_Commune]PRIMARYKEYCLUSTERED

    (

    [Id_com]ASC

    )WITH (PAD_INDEX=OFF,STATISTICS_NORECOMPUTE=OFF,IGNORE_DUP_KEY=OFF,ALLOW_ROW_LOCKS=ON,ALLOW_PAGE_LOCKS=ON)ON[PRIMARY]

    )ON[PRIMARY]

    GO

    CREATETABLE[dbo].[Quartier](

    [Id_quart][int]IDENTITY(1,1)NOTNULL,

    [Nom_quart][varchar](25)NOTNULL,

    [Id_com][int]NOTNULL,

    CONSTRAINT[PK_Quartier]PRIMARYKEYCLUSTERED

    (

    [Id_quart]ASC

    )WITH (PAD_INDEX=OFF,STATISTICS_NORECOMPUTE=OFF,IGNORE_DUP_KEY=OFF,ALLOW_ROW_LOCKS=ON,ALLOW_PAGE_LOCKS=ON)ON[PRIMARY]

    )ON[PRIMARY]

    GO

    CREATETABLE[dbo].[Avenue](

    [Id_av][int]IDENTITY(1,1)NOTNULL,

    [Nom_avenue][varchar](25)NOTNULL,

    [Id_quart][int]NOTNULL,

    CONSTRAINT[PK_Avenue]PRIMARYKEYCLUSTERED

    (

    [Id_av]ASC

    )WITH (PAD_INDEX=OFF,STATISTICS_NORECOMPUTE=OFF,IGNORE_DUP_KEY=OFF,ALLOW_ROW_LOCKS=ON,ALLOW_PAGE_LOCKS=ON)ON[PRIMARY]

    )ON[PRIMARY]

    GO

    CREATETABLE[dbo].[Individu](

    [Id_ind][int]IDENTITY(1,1)NOTNULL,

    [Nom][varchar](15)NOTNULL,

    [Postnom][varchar](15)NOTNULL,

    [Prenom][varchar](20)NULL,

    [Genre][char](1)NOTNULL,

    [Etatcivl][varchar](12)NOTNULL,

    [Lieunais][varchar](25)NOTNULL,

    [Datenais][char](10)NOTNULL,

    [Profession][varchar](20)NOTNULL,

    [Nationalite][varchar](15)NOTNULL,

    [Nom_pere][varchar](15)NOTNULL,

    [Nom_mere][varchar](15)NOTNULL,

    [Nom_conj][varchar](15)NOTNULL,

    [Nbre_enf][int]NULL,

    [Prov_orig][varchar](20)NOTNULL,

    [Photo][image]NOTNULL,

    [Code_dos][int]NULL,

    [Id_prov][int]NULL,

    CONSTRAINT[PK_Individu]PRIMARYKEYCLUSTERED

    (

    [Id_ind]ASC

    )WITH (PAD_INDEX=OFF,STATISTICS_NORECOMPUTE=OFF,IGNORE_DUP_KEY=OFF,ALLOW_ROW_LOCKS=ON,ALLOW_PAGE_LOCKS=ON)ON[PRIMARY]

    )ON[PRIMARY]TEXTIMAGE_ON[PRIMARY]

    GO

    SETANSI_PADDINGOFF

    GO

    /****** Object: ForeignKey [FK_Civil] ******/

    ALTERTABLE[dbo].[Civil]WITHCHECKADDCONSTRAINT[FK_Civil]FOREIGNKEY([Code_dos])

    REFERENCES[dbo].[Dossier]([Code_dos])

    ONUPDATECASCADE

    ONDELETECASCADE

    GO

    ALTERTABLE[dbo].[Civil]CHECKCONSTRAINT[FK_Civil]

    GO

    /****** Object: ForeignKey [FK_Ville] ******/

    ALTERTABLE[dbo].[Ville]WITHCHECKADDCONSTRAINT[FK_Ville]FOREIGNKEY([Id_prov])

    REFERENCES[dbo].[Province]([Id_prov])

    GO

    ALTERTABLE[dbo].[Ville]CHECKCONSTRAINT[FK_Ville]

    GO

    /****** Object: ForeignKey [FK_Militaire] ******/

    ALTERTABLE[dbo].[Militare]WITHCHECKADDCONSTRAINT[FK_Militaire]FOREIGNKEY([Code_dos])

    REFERENCES[dbo].[Dossier]([Code_dos])

    ONUPDATECASCADE

    ONDELETECASCADE

    GO

    ALTERTABLE[dbo].[Militare]CHECKCONSTRAINT[FK_Militaire]

    GO

    /****** Object: ForeignKey [FK_Commune] ******/

    ALTERTABLE[dbo].[Commune]WITHCHECKADDCONSTRAINT[FK_Commune]FOREIGNKEY([Id_vil])

    REFERENCES[dbo].[Ville]([Id_vil])

    GO

    ALTERTABLE[dbo].[Commune]CHECKCONSTRAINT[FK_Commune]

    GO

    /****** Object: ForeignKey [FK_Quartier] ******/

    ALTERTABLE[dbo].[Quartier]WITHCHECKADDCONSTRAINT[FK_Quartier]FOREIGNKEY([Id_com])

    REFERENCES[dbo].[Commune]([Id_com])

    GO

    ALTERTABLE[dbo].[Quartier]CHECKCONSTRAINT[FK_Quartier]

    GO

    /****** Object: ForeignKey [FK_Avenue] ******/

    ALTERTABLE[dbo].[Avenue]WITHCHECKADDCONSTRAINT[FK_Avenue]FOREIGNKEY([Id_quart])

    REFERENCES[dbo].[Quartier]([Id_quart])

    GO

    ALTERTABLE[dbo].[Avenue]CHECKCONSTRAINT[FK_Avenue]

    GO

    /****** Object: ForeignKey [FK_Individu] ******/

    ALTERTABLE[dbo].[Individu]WITHCHECKADDCONSTRAINT[FK_Individu]FOREIGNKEY([Code_dos])

    REFERENCES[dbo].[Dossier]([Code_dos])

    ONUPDATECASCADE

    ONDELETECASCADE

    GO

    ALTERTABLE[dbo].[Individu]CHECKCONSTRAINT[FK_Individu]

    GO

    /****** Object: ForeignKey [FK_Individu2] ******/

    ALTERTABLE[dbo].[Individu]WITHCHECKADDCONSTRAINT[FK_Individu2]FOREIGNKEY([Id_prov])

    REFERENCES[dbo].[Province]([Id_prov])

    ONUPDATECASCADE

    ONDELETECASCADE

    GO

    ALTERTABLE[dbo].[Individu]CHECKCONSTRAINT[FK_Individu2]

    GO

    V.3. Configuration de la réplication

    Dans la théorie, nous avons signifié l'importance de la réplication. De ce fait, nous allons ici configurer la réplication par la configuration d'un serveur de publication et d'un autre d'abonnement.

    La base de données étant déjà mise en place, il est question de spécifier le type de réplication à configurer. Pour notre cas, nous avons choisi d'appliquer une réplication symétrique synchrone. Le choix est porté sur ce type de réplication vu l'importance du service qui doit être rendu en vue d'assumer le suivi du casier judiciaire en continu. Le fait est que les données pour chaque individu devront être mises à jour dans différents sites une fois celles-ci publiées.

    V.3.1. Publication

    Pour se faire, nous avons, parmi les quatre types de publication présents dans SQL Serveur 2008 R2, choisi le mode de publication de fusion pour lequel le serveur de publication et les Abonnés peuvent mettre à jour les données publiées de manière indépendante, une fois que les Abonnées ont reçu le cliché instantané initial des données à publier.

    Figure 33: Assistant d'une nouvelle publication

    Figure 34: Finalisation de la publication

    V.3.2. Abonnement

    Nous allons créer un nouvel abonnement après avoir créé une publication. Cet abonnement se fait en mode pull ; celui-ci permet aux esclaves d'être actifs en demandant chaque fois au maitre s'il y a des mises à jour disponibles. Ci-dessous, le choix de la publication à répliquer et le mode de réplication est en continu.

    Nous voyons sur la figure suivante, un récapitulatif du processus de la création de notre abonnement.

    Figure 35: Finalisation de l'abonnement

    V.4. Extrait de code source

    V.4.1. Interface Metier

    packagemetier;

    importgui.People;

    importjava.util.List;

    /**

    *

    * @author Jusciamua

    */

    public interface AllActivities

    {

    public voidaddPeople(People pp);

    public void identPeople();

    public void compareGararits();

    public List<People>listPeople();

    public List<People>peopleMC(String mc);

    public List<Adresses>listeProvince();

    public List<Adresses>provVille(String mc);

    public List<Adresses>listeVille();

    public List<Adresses>villeRech(String mc);

    public List<Adresses>listeCommune();

    public List<Adresses>listeQuartier();

    public List<Adresses>listeAvenue();

    }

    V.4.2. Class Activité Implémentant l'interface métier

    packagemetier;

    importgui.People;

    importjava.sql.PreparedStatement;

    importjava.sql.ResultSet;

    importjava.sql.SQLException;

    importjava.util.ArrayList;

    importjava.util.List;

    importjavax.swing.JOptionPane;

    importstaticmetier.ConnexionServeur.cnx;

    /**

    *

    * @author Jusciamua

    */

    public class AllActivitiesImplimplementsAllActivities

    {

    @Override

    public void addPeople(People pp) {

    throw new UnsupportedOperationException("Not supported yet."); //To change body of generated methods, choose Tools | Templates.

    }

    @Override

    public List<People>listPeople() {

    throw new UnsupportedOperationException("Not supported yet."); //To change body of generated methods, choose Tools | Templates.

    }

    @Override

    public List<People>peopleMC(String mc) {

    throw new UnsupportedOperationException("Not supported yet."); //To change body of generated methods, choose Tools | Templates.

    }

    @Override

    public List<Adresses>listeProvince()

    {

    List<Adresses> province=new ArrayList<>(); //diamond inference

    try

    {

    try (PreparedStatementps = cnx.prepareStatement("select * from province")) {

    ResultSet res=ps.executeQuery();

    while(res.next()){

    Adressesprov=new Adresses();

    prov.setProv(res.getString(2));

    province.add(prov);

    }

    ps.close();

    }

    }catch(SQLException e){JOptionPane.showMessageDialog(null, e.getMessage());}

    return province;

    }

    @Override

    public List<Adresses>villeRech(String mc)

    {

    List<Adresses>ville=new ArrayList<>(); //diamond inference

    try

    {

    try (PreparedStatementps = cnx.prepareStatement("select * from ville where id_prov like ?"))

    {

    ps.setString(1, "%"+mc+"%");

    ResultSet res=ps.executeQuery();

    while(res.next())

    {

    Adressesvil=new Adresses();

    vil.setVille(res.getString(2));

    ville.add(vil);

    }

    ps.close();

    }

    }catch(SQLException e){JOptionPane.showMessageDialog(null, e.getMessage());}

    return ville;

    }

    @Override

    public List<Adresses>listeCommune()

    {

    List<Adresses> commune=new ArrayList<>(); //diamond inference

    try

    {

    try (PreparedStatementps = cnx.prepareStatement("select * from commune")) {

    ResultSet res=ps.executeQuery();

    while(res.next()){

    Adresses com=new Adresses();

    com.setComm(res.getString(2));

    commune.add(com);

    }

    ps.close();

    }

    }catch(SQLException e){JOptionPane.showMessageDialog(null, e.getMessage());}

    return commune;

    }

    @Override

    public List<Adresses>listeQuartier() {

    List<Adresses> quartier=new ArrayList<>(); //diamond inference

    try

    {

    try (PreparedStatementps = cnx.prepareStatement("select * from quartier"))

    {

    ResultSet res=ps.executeQuery();

    while(res.next())

    {

    Adresses quart=new Adresses();

    quart.setQuart(res.getString(2));

    quartier.add(quart);

    }

    ps.close();

    }

    }catch(SQLException e){JOptionPane.showMessageDialog(null, e.getMessage());}

    return quartier;

    }

    @Override

    public List<Adresses>provVille(String mc)

    {

    List<Adresses>ville=new ArrayList<>(); //diamond inference

    try

    {

    try (PreparedStatementps = cnx.prepareStatement("select * from ville where id_prov like ?"))

    {

    ps.setString(1, "%"+mc+"%");

    ResultSet res=ps.executeQuery();

    while(res.next())

    {

    Adressesvil=new Adresses();

    vil.setVille(res.getString(2));

    ville.add(vil);

    }

    ps.close();

    }

    }catch(SQLException e){JOptionPane.showMessageDialog(null, e.getMessage());}

    returnville;

    }

    @Override

    public List<Adresses>listeVille()

    {

    List<Adresses>ville=new ArrayList<>(); //diamond inference

    try

    {

    try (PreparedStatementps = cnx.prepareStatement("select * from Ville")) {

    ResultSet res=ps.executeQuery();

    while(res.next()){

    Adresses vil=new Adresses();

    vil.setVille(res.getString(2));

    ville.add(vil);

    }

    ps.close();

    }

    }catch(SQLException e){JOptionPane.showMessageDialog(null, e.getMessage());}

    returnville;

    }

    @Override

    public List<Adresses>listeAvenue()

    {

    List<Adresses> avenue=new ArrayList<>(); //diamond inference

    try

    {

    try (PreparedStatementps = cnx.prepareStatement("select * from avenue")) {

    ResultSet res=ps.executeQuery();

    while(res.next()){

    Adressesav=new Adresses();

    av.setAven(res.getString(2));

    avenue.add(av);

    }

    ps.close();

    }

    }catch(SQLException e){JOptionPane.showMessageDialog(null, e.getMessage());}

    return avenue;

    }

    @Override

    public void identPeople() {

    throw new UnsupportedOperationException("Not supported yet."); //To change body of generated methods, choose Tools | Templates.

    }

    @Override

    public void compareGararits() {

    throw new UnsupportedOperationException("Not supported yet."); //To change body of generated methods, choose Tools | Templates.

    }

    }

    V.5. Présentation de l'application

    Nous présentons quelques interfaces pour notre projet.

    CONCLUSION

    Nous voici pleinement au terme de notre travail de dur labeur qui a porté sur la mise en oeuvre d'un système distribué pour l'identification et suivi du casier judiciaire.

    A la lumière de ce qui précède, nous avons présenté des notions de base cadrant avec les systèmes distribués afin de résoudre le problème d'identification judiciaire grâce à un lecteur d'empreinte digital dans le but de suivre continuellement les individus ayant un dossier judiciaire partout où ils se retrouvent dans en République Démocratique du Congo ; cette pratique étant aussi un moyen pour lutter contre le récidivisme dans toutes ses formes.

    Pour se faire, nous avons développé une application distribuée comprenant toutes les tâches possibles pour faciliter le processus d'identification judiciaire des individus, laquelle, permettra un suivi permanent grâce à un accès multiutilisateur.

    En effet, la diffusion des mises à jour de chaque copie d'informations aux autres copies se fait de manière continue pour assurer la disponibilité des informations en rapport avec les individus concernés dans tous les sites interconnectés.

    L'application réalisée dans notre travail est une solution aux problèmes que court le service du casier judiciaire dans le processus d'identification judiciaire et suivi de leur casier judiciaire. Cette solution est effective par le fait qu'elle permet une optimisation du processus et garantit un suivi permanent du dossier judiciaire de chaque individu identifié.

    Grâce à ce travail, le service du casier judiciaire peut bénéficier en temps réel des informations de chaque individu ayant un dossier judiciaire quelque soit sa situation géographique.

    Outre ceci, notre application est une des contributions au développement de notre pays qui a besoin d'assurer ce secteur pour réduire le nombre de crimes qui se commettent au jour le jour.

    Nous n'avons aucune prétention d'avoir tout abordé dans ce travail étant donné que le champ est très vaste pour être développé. Néanmoins, nous sommes ouvert à toutes vos remarques et suggestions en vue d'améliorer ce travail dans les jours à venir lors de nos prochaines publications, étant donné qu'une oeuvre humaine ne manque d'imperfections.

    REFERENCES BIBLIOGRAPHIQUES

    I. OUVRAGES

    [1] A.K. Jain, L. Hong, S. Pankantiet R. Bolle. An identityauthenfication system using fingerprints. Proceedings of the IEEE, Vol. 85, n° 9, Septembre 1997.

    [2] A.K. Jain, S. Shaoyun, K. Karu, N.K. Ratha. A real-time matching system for large fingerprint databases. IEEE Trans. on pattern analysis and machine intelligence, Vol.18, n° 8, Août 1996 ;

    [3] Eddy MEYLAN. Réplication de données. Bachelor of science en informatique de gestion, Haute Ecole de Gestion ARC Neuchâtel Suisse, Février 2005.

    [4] G. Coulouris, J. Dollimore, TimKindBerg, G. Blair. Distributed systems : concepts and design, 5ème éd.;

    [5] LadjelBellatreche (Ensma) : Bases de données réparties ;

    [6] N.MAHAMOUD, S. ATELLY, Tolérance aux fautes dans les systèmes informatiques, Paris 2005 ;

    [7] S. SCHILDKNECHT and G. LEJEUNE. Introduction à la réplication de bases de données, Février 2006 ;

    [8] Y. Belgnaoui, J-C. Guézel et T. Mahé. La biométrie, sésame absolu. Industries et techniques, Juillet 2000 ;

    II. NOTES DE COURS

    [9] KAFUNDA KATALAY Pierre, Base de données répartie, notes de cours de 1ère licence conception des systèmes d'informations, Facultés des sciences, Université Pédagogique Nationale, 2015-2016 ;

    III. ARTICLES ET AUTRES

    [10] http://www.labo-microsoft.org/articles/SQL_Serveur_Replication/8/Default.asp

    [11] http://www.biometrie-online.net/technologies/empreintes-digitales

    TABLE DE MATIERES

    Epigraphe

    Dédicace ii

    Avant-propos iii

    Liste des abréviations v

    Liste des figures vi

    0. INTRODUCTION 1

    0.1. PROBLEMATIQUE 2

    0.2. HYPOTHESE 2

    0.3. CHOIX ET INTERET DU SUJET 3

    0.4. DELIMITATION DU SUJET 3

    0.4.1. Dans le temps 3

    0.4.2. Dans l'espace 3

    0.5. METHODES ET TECHNIQUES UTILISEES 3

    0.5.1. METHODES 3

    0.5.2. TECHNIQUES 4

    0.6. SUBDIVISION DU TRAVAIL 4

    CHAPITRE Ière : GENERALITES SUR LES SYSTEMES DISTRIBUES [1] [6] [4] 5

    I.1. Définitions 5

    I.2. Intérêt des systèmes distribués 6

    I.3. Quelques domaines d'application des systèmes distribués 6

    I.4. Difficulté de mise en oeuvre 6

    I.5. Caractéristiques des systèmes distribués 7

    I.5.1. Interopérabilité 7

    I.5.2. Partage des ressources 9

    I.5.3. Ouverture 9

    I.5.4. Expansible 9

    I.5.5. Performance 9

    I.5.6. Transparence 10

    I.5.7. Sécurité 11

    I.5.8. Concurrence 11

    I.5.9. Tolérance aux pannes 11

    I.5.10. Disponibilité 12

    I.6. Architecture distribuée 12

    I.6.1. Avantages des architectures distribuées 12

    I.6.2. Types d'architecture distribuée 13

    CHAPITRE IIème : LES BASE DE DONNEES REPARTIE [3][5][7][9] 16

    II.1. Définitions 16

    II.2. Caractéristiques 17

    II.3. Types de bases de données réparties 17

    II.3.1. Base de données répartie homogène 17

    II.3.2. Base de données hétérogène 18

    II.4. Conception d'une base de données 18

    II.4.1. Conception du schéma global 19

    II.4.2. Conception de la base de données physique locale dans chaque site 19

    II.4.3. Conception de la fragmentation 20

    II.4.4. Conception de l'allocation des fragments 24

    II.5. Réplication des données 25

    II.5.1. Définition 25

    II.5.2. Objectifs la réplication 25

    II.5.3. Technique de la réplication 26

    II.5.4. Avantages de la réplication 26

    II.5.5. Limites de réplication 26

    II.5.6. Techniques de diffusion des mises à jour 27

    II.5.7. Types de réplication 28

    II.6. Gestion des transactions réparties 31

    II.6.1. Définitions d'une transaction 31

    II.6.2. Condition de terminaison 32

    II.6.3. Propriétés des transactions 32

    II.7. Système de Gestion de Bases de Données Réparties 32

    II.7.1. Définitions 32

    II.7.2. Les caractéristiques d'un SGBD réparti 33

    II.7.3. Intérêt d'un SGBD réparti 34

    II.7.4. Architecture d'un SGBD réparti 34

    II.7.5. Objectifs du SGBDR 38

    CHAPITRE IIIème : AUTHENTIFICATION PAR EMPREINTES DIGITALES [2] [8] [11] 40

    III.1. Authentification 40

    III.1.1. Définition 40

    III.1.2. Type d'authentification 40

    III.1.3. Les enjeux de l'authentification 42

    III.2. Biométrie 43

    III.2.1. Définition 43

    III.2.2. Propriétés de la biométrie 43

    III.2.3. Architecture d'un système biométrique 44

    III.2.4. Applications de la biométrie 45

    III.2.5. Panorama des différentes biométries 46

    CHAPITRE IVème : ANALYSE PREALABLE 55

    IV.1. Présentation de la direction du casier judiciaire 55

    IV.1.1. Historique 55

    IV.1.2. Mission 55

    IV.1.3. Situation géographique 55

    IV.1.4. Structure organisationnelle et fonctionnelle 56

    IV.1.5. Etude des documents 57

    IV.6. Critiques de l'existant 60

    IV.6.1. Aspects positif 60

    IV.6.2. Aspect négatif 60

    IV.6.3. Proposition des solutions 61

    CHAPITRE Vème : CONCEPTION ET IMPLEMENTATION DU SYSTEME 62

    V.1. Etude de l'application 62

    V.1.1. Architecture réseau 62

    V.2. Modélisation en UML du domaine 64

    V.2.1. Objectif de la modélisation 65

    V.2.2. Diagramme de cas d'utilisation 65

    V.2.3. Diagramme d'activité 66

    V.2.4. Diagramme de classe 67

    V.2.5. Conception du schéma global 68

    V.2.6. Schémas locaux 69

    V.2.7. Script de création de la base de données 70

    V.3. Configuration de la réplication 74

    V.3.1. Publication 74

    V.4. Extrait de code source 81

    V.4.1. Interface Metier 81

    V.4.2. Class Activité Implémentant l'interface métier 82

    V.5. Présentation de l'application 86

    CONCLUSION 87

    REFERENCES BIBLIOGRAPHIQUES 88

    TABLE DE MATIERES 89






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy