Conception et réalisation d'une base de données repartie sous oracle : cas de l'hébergement des résidences universitaires

Chapitre6

Réalisation

6.1 Introduction

Dans ce chapitre, nous entamons la partie pratique, et cela après avoir effectué toute l'étude théorique et préliminaire. Nous essayons au mieux d'utiliser les données, les informations recueillies et les connaissances acquises tout au long des chapitres précédents pour implémenter notre solution.

En première partie, nous expliquons la démarche suivie, et les étapes de création de l'environnement du travail à savoir un réseau Ad-hoc, ainsi que les différentes étapes de configuration du serveur et du client ORACLE.

Dans la seconde partie de ce chapitre, nous allons présenter la solution proposée, et qui devra répondre aux exigences de la gestion de l'hébergement des résidences universitaire en détaillant les étapes qui la composent.

6.2 Structure générale de la solution proposée

Notre solution consiste à créer sur chaque résidence universitaire une base de données interfacée avec notre application de gestion de l'hébergement des résidences universitaires. Chaque serveur de résidence partage ses données avec la DOU. Ainsi, ces différentes bases seront consolider au niveau de la D.O.U pour avoir une base globale qui contiendra toutes les données.

La figure ci-dessous, illustre la structure générale de la solution proposée :

FIG. 6.1 Structure générale de la solution proposée.
58

6.2.1 Justification des choix

1. La création des vues materialisées 'materialized views' au niveau de la D.O.U, nous permet d'avoir une localisation physique des données au niveau de cette dernière et un rafraîchissement complet des données (par exemple, tous les jours à 10 h du matin). Donc, on favorise les accées locaux qui ont pour but de réduire le trafic réseau.

2. En cas de panne d'un site ou d'indisponibilité du réseau, les données seront diponibles, car les accès aux données sont locaux.

3. Comme la direction a besoin de toutes les données de tous les sites, la création de vues 'views' au niveau de cette dernière, nous permet d'avoir accès à toutes les données en toute transparence.

4. Avec cette solution, une grande disponibilité des données est assurée.

5. Les vues materialisées de chaque compte utitisateur au niveau de la D.O.U sont mises à jour quotidiennement à 10h du matin (cette durée peut étre prolongée après la période des inscriptions).

6. Les accès distants aux niveau de la D.O.U permettent à cette dernière d'effectuer la première inscription des résidents et le suivi du résident (réadmission, ...) se fera par la residence d'acceuil.

7. La table chambre est fixe normalement mais comme le nombre de places libres de chaque chambre est mis à jour dynamiquement à chaque inscription, donc, elle devient dynamique. D'où, la necéssité de la répliquer vers la D.O.U.

6.3 Les configurations nécessaires

6.3.1 Configuration du réseau

Les ordinateurs dont nous disposons vont être reliés grâce à un réseau sans fil 'Ad hoc' afin qu'ils puissent se connecter à distance à la base ORACLE.

Pour cela, il faut définir le même domaine de travail pour l'ensemble des ordinateurs (MShome ou autre), désactiver leurs Parfeu et ajouter un nouveau réseau, repéré par un nom unique SSID¹ en cliquant sur le bouton Ajouter dans la fenêtre propriétés de connexion réseau sans fll :

'Service Set IDentifier

FIG. 6.2 - Propriétés de connexion réseau sans fll.

Ensuite, une nouvelle boîte de dialogue s'ouvre, il suffit de saisir sur chacun des ordinateurs le même SSID et de cocher la case 'Ceci est un réseau d'égal à égal' dans la fenêtre propriétés du réseau sans fll. Les autres options servent à renforcer la sécurité. Dès lors, les machines du réseau Ad hoc devraient être en mesure de se connecter ensemble.

FIG. 6.3 - Propriétés du réseau sans fll.

Enfln, il nous reste qu'à déflnir une adresse IP pour chaque poste, en l'occurrence de 192.168.0.1 à 192.168.0.255 et tester la connexion entre les machines.

6.3.2 Configuration ORACLE

Nous installons Oracle 10g 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 que Oracle 10g Client sera installer uniquement sur chaque poste client.

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

6.3.2.1 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.

I 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. [Ale03]

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.

FIG. 6.4 - Le fichier de configuration du Listener Oracle.

I 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 master2base pour la BD Ireyahen. Pour ce faire, il faut saisir dans le Oracle Net Manager :

- Le nom du service : master2base ;

- 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 ;

La figure ci-dessous, résume les différents services de base de données créés, pour lesquels le processus d'écoute accepte les demandes de connexion :

²Transmission Control Protocol /Internet Protocol

FIG. 6.5 - Oracle Net Manager.

Les définitions des services de base de données seront stockées automatiquement dans le fichier listener.ora, comme l'illustre la figure ci-dessous :

FIG. 6.6 - Le fichier Listener Oracle.

6.3.2.2 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.

Voici, à quoi ressemble les fichiers tnsnames.ora et sqlnet.ora, le plus simple est d'utiliser Oracle Net Manager pour les configurer :

FIG. 6.7 - Le fichier de services TNSNAMES.ORA.

FIG. 6.8 - Le fichier SQLNET.ORA.
65

Exemple :

Les différentes étapes de connexion à une base distante sont récapitulées ci-dessous :

FIG. 6.9 - Les étapes de connexion à une BD distante.

- (1) : Le client D.O.U récupère les paramètres de connexion nécessaires pour contacter le listener et l'instance distante à partir du tnsnames.ora.

- (2) : La demande de connexion est transmise au Listener.

- (3) : Le Listener grâce à son fichier de configuration lu au démarrage écoute la demande.

- (4) : Il transmet la demande au service de l'instance cible en créant un processus fils Oracle. A ce stade, le Listener a terminé son travail pour la connexion de ce Client.

- (5) : Le Client et le Processus Oracle du serveur BD sont maintenant indépendants par rapport au Listener et sont en mesure de dialoguer.

6.4 Aspect pratique

6.4.1 Création de la base de données répartie

6.4.1.1 Outils utilisés

I Serveur ORACLE 10g

Nous avons choisi le SGBD ORACLE 10g. Ce choix est justifié par sa puissance et son efficacité. Il utilise un ensemble de processus et de ressources afin d'assurer : [Gil08]

- La définition et la manipulation des données. - La cohérence des données.

- La confidentialité des données.

- L'intégrité des données.

- La sauvegarde et la restauration des données. - La gestion des accès concurrents.

. Réseau local

Un environnement réseau, commun entre les résidences universitaires est indispensable. En d'autre terme, un réseau LAN³ est mis en place pour partger les données et relier les serveurs et les clients situés dans chaque résidence.

. PL/SQL

C'est une extension du langage SQL offerte par le SGBD Oracle et permettant d'écrire des procédures stockées (sorte de sous programme). Ce langage est utilisé pour effectuer des traitements complexes. [Boi06]

6.4.1.2 Implémentation de la BDR

. Au nivau de la résidence TARGA OUZAMOUR

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

Create user targa_ouzamour identified by targa_ouzamour; Grant all privileges to targa_ouzamour;

- Création du lien de BD entre la résidence targa ouzamour 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 TARGA OUZAMOUR. . Au niveau de la résidence IREYAHEN

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

Create user ireyahen identified by ireyahen; Grant all privileges to ireyahen;

- Création du lien de BD entre la résidence ireyahen et la direction générale D.O.U :

³Local Area Network

Create database link LienBD_DOU connect to DOU identified by DOU Using 'service DOU';

- Création des tables de la base de données IREYAHEN. . Au niveau de la D.O.U

- Création de 3 comptes utilisateurs nommés respectivements DOU, targa_ouzamour et ireyehen :

Create user DOU identified by DOU; Grant all privileges to DOU;

Create user targa_ouzamour identified by targa_ouzamour; Grant all privileges to targa_ouzamour;

Create user ireyahen identified by ireyahen; Grant all privileges to ireyahen;

- Création des liens de BD entre la D.O.U et les résidences targa_ouzamour et ireyahen :

Create database link LienBD_targa_ouzamour connect to targa_ouzamour identified by targa_ouzamour using 'service targa_ouzamour';

Create database link LienBD_ireyahen connect to ireyahen identified by ireyahen using 'service ireyahen';

- Création des vues matéralisées dans les comptes targa_ouzamour et ireyehen respectivement pour chaque residence:

Afin d'illustrer celles-ci, nous allons donner un exemple de création de deux vues materalisées; une pour la table résident_targa_ouzamour et l'autre pour résident_ireyahen qui se trouvent respectivement dans les bases de données des résidences targa_ouzamour et ireyahen (la procedure de création est la même pour toutes les tables) :

Create materailized view resident_targa_ouzamour

Refresh start with sysdate

Next ( sysdate+1)/10/24

As select * from targa_ouzamour@LienBD_targa_ouzamour;

Create materailized view resident_ireyahen Refresh start with sysdate

Next ( sysdate+1)/10/24

As select * from ireyahen@LienBD_ireyahen;

- Création des vues pour chaque paire de vues matérialisées dans le compte D.O.U :

Ces vues ont pour but de nous donner une vue globale sur toutes les résidences en toutes transparence. Pour illustrer celles-ci, nous allons créer une vue pour tous les résidents en utilisant les vues matérialisées resident_targa_ouzamour et résident-ireyahen :

Create view all_residents as

Select * From targa_ouzamour.resident_targa_ouzamour Union

Select * From ireyahen.resident_ireyahen;

La fugure ci-dessous, illustre la réplication de données vers la D.O.U basée sur les vues matérialisées :

FIG. 6.10 Illustration de la réplication de données.

6.4.2 Le développement de l'application

Afin de mieux gérer le fonctionnement des résidences universitaires, ainsi que la D.O.U, nous avons implémenté une application de gestion de l'hébergement universitaire manipulant la base de données répartie créée ci-dessous.

6.4.2.1 Outils utilisés I ORACLE Forms

Oracle Forms est un générateur d'applications transactionnelles basé sur le language PL/SQL⁴. Ce produit fonctionne aujourd'hui exclusivement en mode WEB. La forme est exécutée sur le serveur d'applications, le client gérant uniquement l'affichage graphique sous la forme d'une applet java. [Cha01]

I ORACLE Report

Oracle Report est un module de développement des états d'impression sous Oracle, il est suffisamment complet en terme de fonctionnalités pour répondre aux différents besoins d'édition.

6.4.2.2 Interfaces graphiques

La figure ci-dessous présente la structure graphique de notre application de gestion de l'hébergement universitaire :

⁴Procedural Language / Structured Query Language

FIG. 6.11 - Structure générale de l'application.

Pour éviter tout accès illicite, notre application est protégée par deux niveaux de sécurité; le premier s'agit de s'authentifier au niveau de la base de données concernée et le second au niveau de l'application de gestion de l'hébergement.

FIG. 6.12 - Vue de l'authentification 'Base de données' .

FIG. 6.13 - Vue de l'authentification 'Application' .

I Application D.O.U

L'accès à l'application D.O.U se fait à partir du menu principal de l'interface suivante :

FIG. 6.14 Menu application DOU.

L'interface ci-dessous permet à la D.O.U d'avoir toutes les doonées des résidences :

FIG. 6.15 - Vue de la gestion de l'hébergement DOU.

L'inscription d'un nouveau bachelier, s'effectue au niveau de la DOU, en utilisant la fenêtre illustrée par la figure ci-dessous :

FIG. 6.16 - Inscription des nouveaux bacheliers - DOU.

I Au niveau des résidences universitaires

Chaque résidence universitaire possède une interface illustrée par la figure ci-dessous :

FIG. 6.17 - Vue de l'interface Targa Ouzemour.

FIG. 6.18 - Vue de la carte du résident.

6.5 Conclusion

Dans ce dernier chapitre, nous avons présenté les aspects pratiques liés à la réalisation de l'application de gestion de l'hébergement des résidences universitaires à savoir l'environnement du travail réseau, la création de la base de données et les différentes configurations des outils nécessaires au fonctionnement de notre système.