Mise en place d'un système d'information sous Oracle basé sur une architecture trois tiers

cHAPITRE 06

1. Introduction

A la déférence des autres SGBD où il y a seulement le développeur de la base de données, ORACLE possède aussi un administrateur qui est responsable de l'installation, la gestion et la maintenance de la base de donnée. Alors au moment du développement, le développeur doit mis en considération les tâches d'administration. Pour cela il faut qu'il exploite toutes les notions que nous avons déjà vu tel que les tablespaces, les utilisateurs, les schémas, et d'autres que oracle a construit (voir le chapitre de la sécurité).

2. L'architecture OFA (Optimal flexible architecture)

OFA est l'architecture standard qu'el est recommandé d'utiliser dans une base de données Oracle. C'est un ensemble des règles d'installation et de configuration qui donnent des bases oracle rapides, fiables, faciles à faire évoluer et nécessitant peu de maintenance. Les trois règles importantes pour respecter cette architecture sont :

1. Etablir une structure de répertoires, où n'importe quel fichier de base de données peut être enregistré sur n'importe quel espace disque.

2. Séparer les objets avec un comportement différent sur différents tablespaces.

3. Augmenter les performances de la base de données en séparant les composants de la base de données sur des disques différents.

OFA organise donc la base de données en fonction des types de fichiers et de leurs utilisations. Les fichiers binaires, de contrôles, de logs et administratifs peuvent être séparés sur des disques différents.

Figure 01 : Schéma d'installation des fichiers oracle

3. Description de la de données

Création de la base de donnée :

La création de la base de données est la première étape. Lors de la création d'une nouvelle base, il faut tenir compte du jeu de caractères que la base de données utilisera (dans notre cas les langues arabe et français). Une fois que la base de données est crées, le jeu de caractères spécifié ne peut plus être changé, sauf si la base de données est reconstituée (voir l'annexe).

Création des Schémas et des utilisateurs :

Les Schémas et les utilisateurs : Un schéma est un ensemble nommé d'objets tels que: tables, vues, clusters, procédure et packages associés à un utilisateur précis. Quand un utilisateur de base de données crée des objets, son schéma est automatiquement crée. Un utilisateur ne pourra alors être associé qu'à un seul schéma et réciproquement.

Les privilèges : Un privilège est un droit d'exécuter un type particulier d'ordre SQL. Un utilisateur doit avoir un privilège de type système pour accéder à la base de donnée et ses objets et un privilège de type objet pour exécuter une action sur le contenue des objets de la base.

Les rôles : sont des groupes de privilèges qui sont accordé à des utilisateurs ou d'autres rôles. Ils sont conçus pour faciliter l'administration des privilèges.

Ces notions sont équivalentes au monde réel, en les résume dans l'exemple suivant :

Organisation

Utilisateur chef
Service 1

Utilisateur chef
Service 2

Utilisateur chef
Service 3

Utilisateur 3.1 Utilisateur 3.2

Utilisateur3.2. 1

Ressources

Tâches

Figure 02 : Exemple de modélisation d'une organisation

Dans une organisation on ne peut pas recruter un utilisateur seulement si on lui affecte des ressource et des tâches sur ces ressources (les ressources dans notre système sont des

tables, vues ..., les tâches sont des privilèges et rôles associés à un utilisateur).Chaque utilisateur est responsable de la sécurité de leurs ressources, un autre utilisateur ne peut pas utiliser ces ressources qu'après l'autorisation de l'utilisateur propriétaire. Chaque utilisateur a un rôle dans l'organisation selon leur niveau hiérarchique.

Par analogie on résume l'arborescence de l'université dans ce graphe.

Chef université :
Administrateur

Chef de faculté 1 Chef de faculté 2 Chef de faculté 3

Chef de département
1

Agent de saisie

Etudiant

Chef de département
3

Chef de département
2

Figure 03 : Modélisation de l'université de Batna.

Ce graphe sera nous accompagnons pour crée l'annuaire LDAP.

Alors nous avons trois types d'utilisateurs dans notre système :

1. Chef université Administrateur : responsables de :

- toutes les opérations sur l'université,

- ajouté les type de congé, les diplômes ... etc.

- créer les utilisateurs " Chef de faculté".

2. Chef de faculté : il travail sur les tables du schéma"AD_Faculte". Responsable d'administrer la faculté. Et la création des utilisateurs " Chef de département ".

3. l'agent de saisie : il travail sur les tables du schéma 'AD_Departement'. Responsables de toutes opérations concernant les Etudiants :

- création des utilisateurs étudiant

- inscription.

- orientation et transfère.

Schéma : AD_Faculte

Tables: Département

Procédures :

Mise a jours de table : Département

Schéma : AD_Departement

Tables :

-

specialite

options

Etudiant

fiche _etude

dossier_bloque

dossier_retirer

dossier_Transferer VIEW fiche _etudiant

Procédures :

Mise a jours des tables : specialite, options ,Etudiant fiche_etude, dossier_bloque

Schéma : AD_Universite Tables:

Nationalité Bac

Wilaya

Commune Université Faculté

type_conge Diplôme

annee_univ

Procédures :

Mise a jours des tables :

Nationalité, Bac, Wilaya,

Commune, Université, Faculté type_conge, Diplôme, annee_univ

Schéma : Etudiant

Tables:

Crée selon les fonctions a ajoutées

Procédures :

- génération des états de sorties.

4. Chef de département : il travail sur les tables du schéma 'département'.

- créer les utilisateurs "agent de saisie".

- ajouté les spécialités et les options.

5. Etudiant:

- Consultation de la fiche d'étude.

- réinscription.

Les schémas: AD_Faculte, AD_Universite, AD_Departement, Etudiant, représentent Dans notre système Des schémas partagées (voir chapitre de sécurité), et les utilisateurs sera crées séparément a chaque création d'une faculté, d'un département et chaque inscription d'un étudiant.

Par exemple l'utilisateur informatique sera crée au moment de la création du département informatique. Cet utilisateur sera connecté et travaillé sur le schéma département.

La création des tablespaces :

On peut voir les tablespaces comme les partitions logiques de disque dur ou les répertoires qui aident à l'organisation de l'information selon son type.

Par les tablespaces on peut séparer entre les données de système (on parlent des données de l'utilisateur SYS "dictionnaire de données, ....") et les données de l'utilisateur.

pour contrôler l'espace disque efficacement, il est recommandé d'utiliser plusieurs tablespaces.

L'université est constituée de trois éléments: l'enseignent, l'étudiant, et l'administration pour cela nous avons crée trois tablespaces :

1. Administration: c'est l'espaces disque qui sera alloué aux l'utilisateur AD_Universite, AD_Faculte, AD_Departement.

2. Etudiant : pour sauvegarder les données associées a l'étudiant,

3. Usertemp ( tablespace temporaire) :

Lorsque une base de données est crée sans tablespace temporaire par défaut, le tablespaces qui est assigné aux utilisateurs créés sans la clause TEMPORARY TABLESPACE est le tablespaces SYSTEM.

Pour éviter que le tablespace système soit utilisé comme tablespace temporaire, il est nécessaire de créer un tablespace temporaire par défaut autre que SYSTEM. Un segment temporaire permet d'avoir un gain de performance lorsque, par exemple, plusieurs tris occupent trop de place pour la mémoire et doivent être stockés sur le disque dur temporairement.

CREATE TABLESPACE administration LOGGING

DATAFILE C:\ORACLE\ORADATA\BASE\ADMIN.ora' SIZE 5M AUTOEXTEND ON NEXT 5M MAXSIZE UNLIMITED

EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO online ;

CREATE TABLESPACE etudiant LOGGING

DATAFILE C:\ORACLE\ORADATA\BASE\etudiant.ora' SIZE 5M AUTOEXTEND ON NEXT 5M MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO online;

CREATE TEMPORARY TABLESPA CE USER TEMP TEMPFILE 'C: \ORACLE\ORADATA\BASE \USERTEMP.ora' SIZE 10M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 5M;

ALTER DATABASE DEFAULT TEMPORARY TABLESPACE USERTEMP;

il est préférable de stocker les datafile sur plusieurs disques (répartition des charges disque).

Script de création des schémas :

CREATE USER AD_Universite PROFILE "DEFAULT" IDENTIFIED by universite

DEFAULT TABLESPACE administration

TEMPORARY TABLESPACE "USERTEMP" ACCOUNT UNLOCK;

CREATE USER AD_Faculte PROFILE "DEFAULT" IDENTIFIED by faculte DEFAULT TABLESPACE administration

TEMPORARY TABLESPACE "USERTEMP" ACCOUNT UNLOCK;

CREATE USER AD_Departement PROFILE "DEFAULT" IDENTIFIED by Departement

DEFAULT TABLESPACE administration

TEMPORARY TABLESPACE "USERTEMP" ACCOUNT UNLOCK;

CREATE USER Etudiant PROFILE "DEFAULT" IDENTIFIED by Etudiant DEFAULT TABLESPACE etudiant

TEMPORARY TABLESPACE "USERTEMP" ACCOUNT UNLOCK;

Création des rôles :

A l'exception de l'utilisateur Ad_universite (l'administrateur de l'universite qui possède leur propre schéma) les utilisateurs sont crées dynamiquement et ils ne peuvent rien faire initialement même pas la connexion à la base de données, touts les privilèges nécessaires sera donnés par l'utilisateur créateur.

C'est pourquoi l'administrateur de l'université (ad_université) doit avoir touts les rôles au départ.

1. Description des rôles:

admin_role: c'est le rôle qui regroupe tout les privilèges nécessaire à la création des schémas partagés.

inst_role: c'est le rôle qui permet au tout nouvel utilisateur de connecté et de crée des utilisateur.

user_fac: il permet aux chefs des facultés de manipuler leurs tables.

user_dept: : il permet aux chefs des départements de manipuler leurs tables. select_univ: il permet aux utilisateurs de consulter les tables du schéma ad_université. select_fac: : il permet aux utilisateurs de consulter les tables du schéma ad_faculté.

user_dept_ag: un rôle qui sera donné à l'agent de saisie pour lui permet d'accomplir ses taches.

user_etud: un rôle spécifique aux étudiants.

1.1 Rôles agent département : c'est le rôle qui sera assigné à l'utilisateur agent de saisie. Le script de la création est le suivant :

create role user_dept_ag ;

grant select, insert, update, delete on etudiant to user_dept_ag;

grant select, insert, update, delete on fiche_etude to user_dept_ag;

grant select, insert, update, delete on fiche_etudiant to user_dept_ag;

grant select, insert, update, delete on dossier_retirer to user_dept_ag;

grant select, insert, update, delete on dossier_bloque to user_dept_ag;

grant select, insert, update, delete on dossier_transferer to user_dept_ag;

grant select on specialite to user_dept_ag;

grant select on options to user_dept_ag;

1.2. Rôles chef de département : c'est le rôle qui sera assigné à l'utilisateur Chef département. Le script de la création est le suivant :

create role user_dept;

grant select, insert, update, delete on specialite to user_dept;

grant select, insert, update, delete on options to user_dept;

1.3. Rôles select_fac: c'est le rôle qui sera assigné à l'utilisateur Chef de departement. Le script de la création est le suivant :

create role select_fac;

grant select on departement to select_fac;

1.4. Rôles select_univ : c'est le rôle qui sera assigné aux utilisateurs sauf l'étudiant. Le scripte de la création est le suivant :

Create role select_univ;

grant select on faculte to select_univ;

grant select on nationalite to select_univ;

grant select on bac to select_univ;

grant select on wilaya to select_univ;

grant select on commune to select_univ;

grant select on universite to select_univ;

grant select on deplome to select_univ;

grant select on type_conge to select_univ;

grant select on annee_univ to select_univ;

Création des tables des schémas:

2.1 Schéma Ad_université :

Le schéma Ad_université inclut les tables : Nationalité, Bac, Wilaya, Commune Université, Faculté, type_conge, Diplôme, annee_univ. Le scripte est le suivant : Table N° :01 Nationalité :

CREATE TABLE nationalite (

code NUMBER(3) ,

nationa lite_fr VARCHAR2(40) NOT NULL CONSTRAI NT nationalite_fr_UK UNIQUE, nationa lite_ar VARCHAR2(40) NOT NULL CONSTRAI NT nationa lite_ar_UK UNIQUE, CONSTRAINT nationalite_PK PRIMARY KEY (code) );

Table N°:02 Bac:

CREATE TABLE Bac(

code VARCHAR2(2),

bac_fr VARCHAR2(40) not null constraint bac_fr_UK unique, bac_ar VARCHAR2(40) not null constraint bac_ar_UK unique, CONSTRAINT Bac_PK PRIMARY KEY (code) );

Table N°:03 Wilaya:

CREATE TABLE wilaya (

code varchar2(2),

wilaya_fr VARCHAR2(30) NOT NULL CONSTRAINT wil_fr_UK UNIQUE, wilaya_ar VARCHAR2(30) NOT NULL CONSTRAINT wil_ar_UK UNIQUE, constraint wil_pk PRIMARY KEY (code) );

Table N°:04 Communes:

CREATE TABLE commune (

code varchar2(5) NOT NULL CONSTRAINT commune_code_Uk UNIQUE, commune_fr VARCHAR2(40) NOT NULL,

commune_ar VARCHAR2(40) NOT NULL,

code_wil varchar2(2),

CONSTRAINT commune_fk FOREIGN KEY (code_wil) REFERENCES wilaya(code), constraint commune_UK unique(commune_fr,commune_ar,code_wil) );

Table N°:05 Université:

CREATE TABLE universite (

code VARCHAR2(2) ,

univ_fr VARCHAR2(40) NOT NULL CONSTRAINT univ_fr_UK UNIQUE, univ_ar VARCHAR2(40) NOT NULL CONSTRAINT univ_ar_UK UNIQUE, sigle blob,

date_ouverture date,

adresse_fr varchar2(60), adresse_ar varchar2(60), wilaya varchar2(2),

telephone1 varchar2(12),
telephone2 varchar2(12),

fax1 varchar2(12),

fax2 varchar2(12),

CONSTRAINT universite_fk FOREIGN KEY (wilaya) REFERENCES wilaya(code),

CONSTRAINT universite_pk PRIMARY KEY (code) );

Table N°:06 Faculté:

CREATE TABLE faculte ( code VARCHAR2(4) ,

fac_fr VARCHAR2(40) not null , fac_ar VARCHAR2(40) not null , code_univ varchar2(2), telephone1 varchar2(12), telephone2 varchar2(12),

fax1 varchar2(12),

fax2 varchar2(12),

CONSTRAINT faculte_fk FOREIGN KEY (code_univ) REFERENCES universite(code),

constraint faculte_U K u nique(code_univ,fac_fr,fac_ar),

CONSTRAINT faculte_pk PRIMARY KEY(code) );

Table N°:07 type_conge:

CREATE TABLE type_conge (

type_conge VARCHAR2(2) ,

title_conge_fr VARCHAR2(40) NOT NULL CONSTRAINT type_fr_conge_title_UK UNIQUE, title_conge_ar VARCHAR2(40) NOT NULL CONSTRAI NT type_ar_conge_title_UK UNIQUE, CONSTRAINT type_conge_PK PRIMARY KEY (type_conge) );

Table N°:08 Diplôme:

CREATE TABLE deplome (

code VARCHAR2(1) ,

depl_fr VARCHAR2(30) NOT NULL CONSTRAINT deplome_fr_UK UNIQUE, depl_ar VARCHAR2(30) NOT NULL CONSTRAINT deplome_ar_UK UNIQUE, fin_cycle number(1) NOT NULL,

CONSTRAINT deplome_PK PRIMARY KEY (code) );

Table N°:09 annee_univ:

CREATE TABLE annee_univ (

annee VARCHAR2(4),

title varchar2(9),

CONSTRAINT annee_univ_PK PRIMARY KEY (annee) );

Après la création de ces tables, un utilisateur sera assignée au schémas ad_universite ce utilisateur prend le même nom du schéma. Pour nous c'est l'utilisateur Chef université (voir la liste des utilisateurs).

Ces objets sont à la responsabilité de ad_universite, et sans leur permettion, aucun utilisateur peut référencer a ces objets .l'utilisateur ad_universite peut attribuer des privilèges aux utilisateurs pour les autorisé de crées des tables fait référence à ces objets,

grant references on faculte to role_faculte, role_Departement;

grant references on nationalite to role_faculte, role_Departement;

grant references on bac to role_faculte, role_Departement;

grant references on wilaya to role_faculte, role_Departement;

grant references on commune to role_faculte, role_Departement; grant references on universite to role_faculte, role_Departement; grant references on deplome to role_faculte, role_Departement; grant references on type_conge to role_faculte, role_Departement; grant references on annee_univ to role_faculte, role_Departement;

Mais pour que les utilisateurs ad_faculte, ad_departement peut accéder a ces objets il faut toujours prévenir de nom de la propriétaire, exemple : " AD_Universite. annee_univ". Pour fait une abstraction sur les noms des objets du schémas, on a crée des synonymes :

create public synonym nationalite for ad_universite.nationalite;

create public synonym bac for ad_universite.bac;

create public synonym wilaya for ad_universite.wilaya;

create public synonym commune for ad_universite.commune;

create public synonym universite for ad_universite.universite;

create public synonym faculte for ad_universite.faculte;

create public synonym deplome for ad_universite.deplome;

create public synonym type_conge for ad_universite.type_conge; create public synonym annee_univ for ad_universite.annee_univ;

Création des tables de schéma Ad_ faculté:

Table N°:01 department:

CREATE TABLE departement (

code VARCHAR2(6) ,

depart_fr VARCHAR2(30) NOT NULL , depart_ar VARCHAR2(30) NOT NULL , code_fac VARCHAR2(4),

date_ouverture date,

telephone1 varchar2(12),

telephone2 varchar2(12),

fax1 varchar2(12),

fax2 varchar2(12),

CONSTRAINT departement_fk FOREIGN KEY (code_fac) REFERENCES faculte(code),

constraint departement_UK unique(depa rt_fr,depart_ar,code_fac),

CONSTRAINT departement_pk PRIMARY KEY (code) );

Le script qui permet attribuer des privilèges aux utilisateurs autorisés de référencer à la table "département"est le suivant :

grant references on departement to ad_departement;

Création des synonymes :

create public synonym departement for ad_faculte.departement;

Création des tables de schéma Ad_département: Table N°:01 spécialité:

CREATE TABLE specialite (

code VARCHAR2(9) ,

speciat_fr VARCHAR2(40) NOT NULL ,

speciat_ar VARCHAR2(40) NOT NULL ,

code_depl varchar2(1),

code_depart VARCHAR2(6),

CONSTRAINT specialite_depart_fk FOREIGN KEY(code_depart) REFERENCES departement

(code),

CONSTRAINT specialite_deplome_fk FOREIGN KEY(code_depl) REFERENCES deplome (code), constraint specialite_UK u nique(speciat_fr,speciat_a r,code_depart),

CONSTRAINT specialite_pk PRIMARY KEY (code) );

Table N°:02 options:

CREATE TABLE options (

code VARCHAR2( 10) CONSTRAINT options_code_UK unique,

option_fr VARCHAR2(40) NOT NULL ,

option_ar VARCHAR2(40) NOT NULL ,

code_speciat VARCHAR2(9),

annee_debut number(1),

CONSTRAINT options_FK FOREIGN KEY (code_speciat) REFERENCES specialite(code), constraint options_UK unique(option_fr,option_ar,code_speciat) );

Table N°:03 Etudiant:

CREATE TABLE Etudiant (

ident VARCHAR2(20),

nom_fr VARCHAR2(30) NOT NULL,

nom_ar VARCHAR2(30) NOT NULL,

prenom_fr VARCHAR2(30) NOT NULL,

prenom_ar VARCHAR2(30) NOT NULL,

sexe VARCHAR2(1),

date_naiss DATE NOT NULL,

lieu_naiss VARCHAR2(20),

nationa lite NUMBER(3),

commune varchar2(5),

adresse_fr VARCHAR2(40) NOT NULL,

adresse_ar VARCHAR2(40) NOT NULL,

bac varchar2(2),

pays_bac NUMBER(3),

moyenne_bac NUMBER(4,2) not null,

photo Blob,

prenomp_fr VARCHAR2(30) ,

prenomp_ar VARCHAR2(30) ,

prenomm_fr VARCHAR2(30) ,

prenomm_ar VARCHAR2(30) ,

nom m_fr VARCHAR2(30) ,

nom m_ar VARCHAR2(30) ,

CONSTRAINT Etudiant_nationalite_FK FOREIGN KEY (nationalite) REFERENCES

nationalite(code),

CONSTRAINT Etudiant_pays_bac_FK FOREIGN KEY (pays_bac) REFERENCES nationalite(code), CONSTRAINT Etudiant_bac_FK FOREIGN KEY (bac) REFERENCES Bac(code),

CONSTRAINT Etudiant_lieu_naiss_FK FOREIGN KEY (lieu_naiss) REFERENCES com mune(code), CONSTRAINT Etudiant_commune_FK FOREIGN KEY (commune) REFERENCES commune(code), CONSTRAINT Etudiant_sexe_CK CHECK (upper(sexe)='F' or upper(sexe)='M' ),

CONSTRAINT Etudiant_PK PRIMARY KEY (ident) );

Table N°:04 fiche_etude:

CREATE TABLE fiche_etude (

annee_univ VARCHAR2(4),

ident VARCHAR2(20),

code_speciat VARCHAR2(9),

code_option VARCHAR2(9),

niveau NUMBER(1),

matricule VARCHAR2(20) NOT NULL,

CONSTRAINT fiche_etudiant_FK FOREIGN KEY (ident) REFERENCES Etudiant(ident), CONSTRAINT fiche_speciat_FK FOREIGN KEY (code_speciat) REFERENCES specialite(code),

CONSTRAINT fiche_options_FK FOREIGN KEY (code_option) REFERENCES options(code), CONSTRAINT fiche_annee_univ_FK FOREIGN KEY (a nnee_univ) REFERENCES

annee_univ(annee),

CONSTRAINT fiche_niveau_CK CHECK (niveau >=1 and niveau<=7 ), CONSTRAINT fiche_PK PRIMARY KEY (annee_univ,ident) );

Table N°:05 dossier_bloque:

CREATE TABLE dossier_bloque (

annee_univ VARCHAR2(4),

ident VARCHAR2(20),

type_conge VARCHAR2(2),

CONSTRAINT dossier_bloque_ident_FK FOREIGN KEY (annee_univ,ident) REFERENCES fiche_etude(annee_univ,ident),

CONSTRAINT dossier_bloque_conge_FK FOREIGN KEY (type_conge) REFERENCES type_conge(type_conge),

CONSTRAI NT dossier_bloque_PK PRIMARY KEY (annee_univ,ident) );

Table N°:06 dossier_retirer:

CREATE TABLE dossier_retirer (

annee_univ VARCHAR2(4) ,

ident VARCHAR2(20),

CONSTRAINT dossier_retirer_id_fk FOREIGN KEY (annee_univ,ident) REFERENCES fiche_etude(annee_univ,ident),

CONSTRAINT dossier_retirer_PK PRIMARY KEY (annee_univ,ident) );

Table N°:07 dossier_Transferer:

CREATE TABLE dossier_Transferer( annee_univ VARCHAR2(4) , ident VARCHAR2(20),

speciat_dest VARCHAR2(9) ,

options_dest VARCHAR2(10) ,

CONSTRAINT dossier_tra nsferer_id_fk FOREIGN KEY (annee_univ,ident) REFERENCES fiche_etude(annee_univ,ident),

CONSTRAINT dossier_trf_speciat_FK FOREIGN KEY (speciat_dest) REFERENCES specialite

(code),

CONSTRAINT dossier_trf_options_FK FOREIGN KEY (options_dest) REFERENCES options

(code),

CONSTRAINT dossier_trfr_PK PRIMARY KEY (annee_univ,ident) );

Table N°:08 fiche_etudiant:

CREATE or replace VIEW fiche_etudiant

AS SELECT etudiant.ident ,nom_fr , nom_ar , prenom_fr , prenom_ar , sexe ,date_naiss , lieu_naiss ,nationalite ,commune , adresse_fr , adresse_ar , bac ,pays_bac ,moyenne_bac ,photo,

prenomp_fr ,prenomp_ar ,prenomm_fr ,prenomm_ar ,

nomm_fr , nomm_ar , user_name ,psw ,annee_univ ,

code_speciat ,code_option ,niveau , matricule

FROM etudiant,fiche_etude

WHERE fiche_etude.ident=Etudiant.ident;

Création des synonymes :

create public synonym specialite for ad_departement.specialite;

create public synonym options for ad_departement.options;

create public synonym etudiant for ad_departement.etudiant;

create public synonym fiche_etude for ad_departement.fiche_etude;
create public synonym dossier_retirer for ad_departement.dossier_retirer;

create public synonym dossier_bloque for ad_departement.dossier_bloque;
create public synonym dossier_transferer for ad_departement.dossier_tra nsferer; create public synonym dossier_transferer for ad_departement.fiche_etudiant;

3. description des interfaces :

Le côté applicatif de notre projet consiste de réaliser un ensemble d'interfaces. Et pour cela on a utilisé l'outil de développement oracle forms qui été apparut bien adapter aux nos besoins.

On peut groupé les interfaces réalisées en deux types les quelles:

· interfaces des administrateurs, comme il est expliqué précédemment on a trois types d'administrateurs: chef université, chef faculté et chef département, pour chacun d'ils on a associé à une interface qui lui permet de faire leurs propres opérations.

· un autre type est constitué d'un ensemble d'interfaces qui étaient orienté vers les opérations désignées aux étudiants tel que l'inscription, la consultation... etc. Et aussi pour les étudiants bloquant ses études, transférant et retirant leurs dossiers on a réalisé une interface qui permet les mises à jour sur les tables associées.

L'accès aux ces interfaces est sécurisé de tel manière à permettre seul au propriétaire de

les utilisé (voir Chapitre de sécurité).

L'interface UNIVERSITE:

L'administrateur d'université utilise cette interface pour effectuer les opérations de mis à jours sur leur propre table tel que l'insertion des wilayas, des universités, des facultés... etc.

L'interface FACULTE:

Elle est désignée à l'administrateur de faculté pour que elle lui permette d'effectuer les opérations de mis à jours sur la seule table qui est département.

L'interface DEPARTEMENT:

Elle est désignée pour qu'elle permette à l'administrateur de département d'effectuer les opérations de mis à jours sur leurs propres tables telles que l'insertion des spécialités, des options.

L'interface ETUDIANT:

L'agent de saisie dans le département utilise cette interface pour rempli les informations d'inscriptions des étudiants.

Génération des cartes des étudiants:

Pour générer les cartes des étudiants on a utilisé l'outil de développement Oracle Report, et on a implémenté deux possibilités à l'exécution des rapports qui sont:

1. Centraliser la génération des cartes des étudiants dans un serveur d'impression, et pour cela on a utilisé la fonction RUN_REPORT_OBJECT.

La fonction SET_REPORT_OBJECT_PROPERTY est utilisée pour exécuter le rapport dynamiquement. Et on a encore utilisé pour le passages des paramètres.

declare

rep varchar2(200);

begin

set_report_object_property('rep', REPORT_OTHER, 'ident='||:ident || 'paramform =no' ); rep:=run_report_object('rep');

end;

2. Alternativement au run_report_object, nous avons utilisé le Web.show_document pour appeler le rapport par le web vers le poste client.

L'interface METTRE A JOURS:

Cette interface est pour rempli les informations des étudiant faisons les transfères, les retraits ou bloquons leurs dossiers.

Ces interface sont réalisées d'une manière très simples on évitant les animations et les Roundtrips (va et vient) dans le réseaux que le plus possible en raison d'augmenté les performances.