Les configurations nécessaires

Configuration Oracle :

Nous installons Oracle 12c Server sur le poste D.O.U qui contient la base globale et sur chaque serveur des résidences qui contient une base locale. Tandis qu’Oracle 12c Client sera installé uniquement sur chaque poste client.

Ensuite, nous configurons la couche réseau grâce au Net Configuration Assistant pour que les serveurs et les clients puissent se communiquer.

Côté Serveur :

Une fois oracle installé, et notre base de données créée et démarrée, elle est prête à l'utilisation, mais elle n'est pas encore prête pour être accessible via le réseau.

Le processus d'écoute Oracle :

Le processus d'écoute Oracle est un service permettant à des clients d'utiliser le protocole TCP pour accéder une base de données distante. Son port d'écoute par défaut est 1521.

Son fichier de paramètre se trouve dans $ORACLE_HOME/Network/Admin/ et se nomme listener.ora. La configuration à partir du fichier listener.ora nécessite une bonne connaissance de la syntaxe de ce dernier (n'est pas recommandée), donc il vaut mieux utiliser Oracle Net Manager.

Création des services de base de données :

Le processus d'écoute autorise uniquement les demandes de connexions des clients pour les noms de services inscrits dans le listener.ora et chaque nom de service référence une base de données.

Nous prenons à titre d'exemple la création du service m2000 pour la BD 2000 lits. Pour ce faire, il faut saisir dans le Oracle Net Manager :

- Le nom du service : m2000 ; : m1000 : m1001

- Le protocole connexion réseau : TCP/IP²;

- Le nom de la machine ou l'adresse IP : 192.168.0.2 ; - Saisir le N°du port : 1521 ;

Côté Client :

Afin de configurer le client, il faut :

- Sélectionner les méthodes de résolution de noms utilisables par le client; - Configurer les méthodes de résolution de noms sélectionnées;

Les méthodes de résolution de noms utilisables par le client sont stockées dans le fichier sqlnet.ora. Si la méthode de résolution de noms locale est utilisée, il faut en plus définir un ou plusieurs noms de services réseau dans le fichier tnsnames.ora.

Aspect pratique :

 Création de la base de données réparties.  Implémentation de la BDR.

- Création d'un compte utilisateur nommé taki :

Create user taki identified by taki; Grant all privileges to taki; - Création du lien de BD entre la résidence 2000 lits et la D.O.U.

Create database link LienBD_DOU connect to DOU identified by DOU Using 'service DOU'; - Création des tables de la base de données 2000 lits.

- Création du lien de BD entre la résidence 1000 lits et la D.O.U.

Create database link LienBD_DOU connect to DOU identified by DOU Using 'service DOU'; - Création des tables de la base de données 1000 lits.

- Création du lien de BD entre la résidence 1001 lits et la D.O.U.

Create database linkLienBD_DOU connect to DOU identified by DOU Using 'service DOU'; - Création des tables de la base de données 1001 lits.

- Création des vues matérialisés.

Create materailized view resident_2000lits

Create materailized view resident_1000lits

Refresh start with sysdate Next( sysdate+1)/10/24 As select * fromtaha2@LienBD_DOU; Create materailized view resident_1001lits

Refresh start with sysdate Next( sysdate+1)/10/24 As select * from taha3@LienBD_DOU; -Création des vues pour chaque paire de vues matérialisées dans le compte D.O.U :

Create viewall_residents as

Select * Fromtaha1.resident2000lits Union Select * Fromtaha2.resident1000lits Union Select * Fromtaha3.resident1001lits;

3. Quelques interfaces de notre application :

Interface d'accueil :

Interface d’authentification :

Cette interface d'authentification permet aux utilisateurs d'accéder au système.

Figure 7.2– Interface d’authentification Interface préinscription :

Interface finaliser inscription :

Figure 7.4– Interface finaliser inscription Interface transfert:

Conclusion :

Dans cette partie nous avons présenté une brève description des différentes choix technologique, technique, et des outils de développement, ainsi nous avons présenté les différentes configurations nécessaire pour réaliser une base de données répartie finalement nous avons inclus quelques interfaces de notre système.

Conclusion

Générale

Conclusion générale :

Dans le cadre de notre projet de fin d’études, nous avons conçu une application ayant pour objectif l’automatisation du processus d’hébergement au sein de la direction des œuvres universitaires Mila.

Nous avons essayé au mieux de développer une application flexible et évolutive permettant son amélioration par la suite afin d’anticiper les éventuels changements des responsabilités et/ ou besoins des utilisateurs.

Le présent manuscrit détaille la logique et les étapes par lesquelles nous sommes passées pour atteindre les objectifs tracés. Le projet s’est déroulé selon trois axes principaux afin de passer par les étapes essentielles de tout projet : l’analyse, la conception et la réalisation en respect au processus 2TUP.

Les difficultés rencontrées tant au niveau de la compréhension et mise en œuvre du processus métier que du processus de développement, sont désormais des gains en connaissance de développement et en savoir-faire au monde professionnel.

Des perspectives à notre travail peuvent être entreprises dans plusieurs cadres, tels que l’étude des procédures pour d’autres opérations de l’hébergement :la restauration, les activités culturelles, scientifique et sportives ….etc. afin de réaliser une application qui suit tous les procédures des services et bureaux de la direction des œuvres universitaires.

Webographie