Download - UNIVERSITE D ’A NTANANARIVO
N°…/ EN / I I / 2001 Année universitaire : 2000/2001
UNIVERSITE D’ANTANANARIVO
ECOLE SUPERIEURE POLYTECHNIQUE
DEPARTEMENT ELECTRONIQUE
MEMOIRE DE FIN D’ETUDES
EN VUE DE L’OBTENTION DU DIPLOME D’INGENIEUR
Spécialité : ELECTRONIQUE
Option : INFORMATIQUE INDUSTRIELLE
Présenté par :
Mlle RAKOTOSOA Solo Mandimbihery
M. ANJARANANTENAINA Zava Falimanana
Soutenu le 13 septembre 2002
IMPLEMENTATION DE « ESPA-DB »
LA BD-R DE L’ESPA
Mémoire d’ingénieur en ELECTRONIQUE
Option : INFORMATIQUE INDUSTRIELLE
Présenté par :
- Mlle RAKOTOSOA Solo Mandimbihery
- M. ANJARANANTENAINA Zava Falimanana
Membres de jury :
- M. RAKOTOMIRAHO Soloniaina .....................................Président
- M. RASTEFANO Elisée........................................................Examinateur
- M. RABESANDRATANA ANDRIAMIHAJA Mamisoa ..Examinateur
- M. RATSIMBA MAMY Nirina ...........................................Examinateur
Rapporteur : Mme RABEHERIMANANA Lyliane Irène
Soutenu le 13 septembre 2002
REMERCIEMENTS
Ce travail n’ayant pu être mené à terme sans l’apport en conseil et soutien aussimoral que matériel des personnes suivantes, nous voudrions leur adresser nos plus vifs etsincères remerciements.
Tout d’abord, nous tenons à exprimer nos sincères remerciements et toutes nosgratitudes à Jésus notre Dieu "car tout vient de Lui, tout existe par Lui et pour Lui" .
Ensuite, nous adressons nos reconnaissances à- M. RAKOTOMIRAHO Soloniaina, Enseignant au Département Electronique,
d’avoir accepté de nous présider durant cette soutenance ;- M. RASTEFANO Elisée, Chef du Département Electronique, qui nous a
prodigué ses bons conseils et pour l’aide précieuse tout au long de notre étude et d’avoirbien voulu accepter de siéger comme membre du jury ;
- Mme RABEHERIMANANA Lyliane Irène, Enseignante au DépartementElectronique, qui nous a apporté son encadrement, son soutien et sa précieusecollaboration pour la réalisation de ce mémoire ;
- Messieurs les membres du jury :- M. RABESANDRATANA ANDRIAMIHAJA Mamisoa- M. RATSIMBA MAMY Nirina
Enseignants au Département Electronique, qui ont accepté de juger notre travail.- Mme RAZANADRAISOA Emilienne, Chef de Service de la Scolarité, qui a
beaucoup œuvré, en nous procurant la documentation nécessaire à l’élaboration decette étude.
Enfin, nous avons une pensée pleine de gratitude à nos chers parents respectifs,ainsi qu’à nos amis et collègues qui nous ont toujours encouragés dans nos études.
MERCI
ii
RESUME
Ce rapport présente l’implémentation d’une Base de Données Relationnelle (BD-R),
nommée « ESPA-DB » pour l’ESPA. Elle sert à l’administration pour mettre à jour les
informations concernant les étudiants (état civil, notes, cursus, mémoire de fin d’études) et
les départements (nom du chef de département, option, matières enseignées et emploi du
temps). En outre les enseignants et les étudiants peuvent l’utiliser comme outil
d’informations.
Cette BD-R est gérée par le Système de Gestion de Base de Données (SGBD)
Oracle. Pour pouvoir manipuler facilement les données avec ce SGBD, une interface a été
réalisée par l’intermédiaire de Oracle Form Builder. Avant d’aboutir à l’implémentation
proprement dite de cette BD-R, nous rappelons des notions de base nécessaires sur les BD
et les SGBD. Nous abordons les BD basées sur le modèle relationnel et le SGBD Oracle. Et
nous terminons par la réalisation de « ESPA-DB », qui est composée d’une BD-R et d’un
programme d’interface.
iii
SOMMAIRE
REMERCIEMENTS........................................................................................ i
RESUME..........................................................................................................ii
SOMMAIRE ...................................................................................................iii
LISTE DES ABREVIATIONS .....................................................................vi
LISTE DES FIGURES..................................................................................vii
INTRODUCTION........................................................................................... 1
CHAPITRE I
BASE DE DONNÉES ET SGBD ................................................ 2
1.1 Base de données........................................................................................ 2
a. Définition............................................................................................................... 2
b. Limites à l’utilisation des fichiers ....................................................................... 2
c. Niveaux de représentation d’une BD .................................................................. 3
c.1. Niveau interne ....................................................................................................................... 4
c.2. Niveau conceptuel ................................................................................................................. 4
c.3. Niveau externe....................................................................................................................... 5
d. Modèle de BD........................................................................................................ 5
d.1. Modèle logique ...................................................................................................................... 5
d.2. Modèle physique.................................................................................................................... 6
1.2 SGBD........................................................................................................... 6
a. Définition............................................................................................................... 6
b. Objectifs de SGBD................................................................................................ 7
c. Langages .............................................................................................................. 7
c.1. Langage de description des données (LDD)........................................................................ 7
c.2. Langage de manipulation des données (LMD) .................................................................... 8
d. Diagramme de flots .............................................................................................. 8
e. Architecture .......................................................................................................... 9
f. Intervenants........................................................................................................ 10
iv
CHAPITRE II
MODÈLE RELATIONNEL ET ORACLE.................................. 13
2.1 Définitions 13
a. Concepts de base............................................................................................... 13
b. Opérateurs relationnels ..................................................................................... 14
c. Modèle conceptuel de données (MCD) ............................................................. 15
2.2 Modèle relationnel .................................................................................... 15
a. BD Relationnelle................................................................................................. 15
b. SGBD Relationnel............................................................................................... 15
2.3 Logiciel et langages utilisés................................................................... 16
a. Logiciel Oracle.................................................................................................... 16
a.1. BD Oracle............................................................................................................................ 16
a.2. Instance Oracle ................................................................................................................... 17
a.3. Objets de base ...................................................................................................................... 17
b. SQL...................................................................................................................... 18
b.1. Types de déclaration SQL ................................................................................................... 19
b.2. Types des donnés................................................................................................................. 20
b.3. Exemple ............................................................................................................................... 20
c. PL/SQL ................................................................................................................ 20
d. Oracle Developer................................................................................................ 22
CHAPITRE III
BASE DE DONNÉES DE L’ESPA........................................... 23
3.1 Utilisateurs de la BD................................................................................. 23
3.2 Analyse et définition des besoins........................................................... 23
a. Besoins ............................................................................................................... 23
a.1. Besoins fonctionnels ........................................................................................................... 24
a.2. Besoins non-fonctionnels.................................................................................................... 24
a.3. Besoins en matière de BD................................................................................................... 24
b. Schéma de la BD ................................................................................................ 25
v
3.3 Interface de « ESPA-DB » ........................................................................ 27
a. Présentation des fenêtres.................................................................................. 27
b. Lecture et Maintenance...................................................................................... 28
b.1. Départements....................................................................................................................... 29
b.2. Première inscription et Fiche d’inscription ....................................................................... 30
b.3. Matières et emploi du temps ............................................................................................... 31
b.4. Notes .................................................................................................................................... 34
c. Recherche........................................................................................................... 35
d. Sécurité ............................................................................................................... 37
d.1. Gestion d’accès et de confidentialité .................................................................................. 38
d.2. Sauvegarde et restauration de la BD.................................................................................. 39
3.4 Installation ................................................................................................ 40
CONCLUSION ............................................................................................... 41
ANNEXES .......................................................................................................... 42
ANNEXE A. ARCHITECTURE D’ORACLE 8 ........................................................................... 43
ANNEXE B. UTILISATEURS D’ORACLE.................................................................................. 49
BIBLIOGRAPHIE
vi
LISTE DES ABREVIATIONS
BD : Base de Données (Database)
BD-R : Base de Données Relationnelle
DD : Data Dictionary (Dictionnaire de Données)
HTML : HyperText Markup Language
LDD : Langage de Définition de Données
LMD : Langage de Manipulation de Données
Mo : Megaoctets
MCD : Modèle Conceptuel de Données
PC : Personal Computer (Ordinateur Personnel)
PDF : Portable Document Format
PGA : Program Global Area
PL/SQL: Procedural Language/ Structured Query Language
RAD : Rapid Application Development (Développement Rapide d’Application)
RAM : Random Access Memory (Mémoire Vive)
SGA : System Global Area
SGBD : Système de Gestion de Base de Données
SGBD-R : Système de Gestion de Base de Données Relationnel
SQL : Structured Query Language ( Langage d’Interrogation Structuré)
vii
LISTE DES FIGURES
Figure 1.1. Différence entre un fichier et une BD ............................................. 3
Figure 1.2. Différents niveaux de représentation d’une BD .............................. 4
Figure 1.3. Modèle hiérarchique ....................................................................... 5
Figure 1.4. Modèle réseau ................................................................................. 6
Figure 1.5. Diagramme de flots ......................................................................... 8
Figure 1.6. Architecture d’un SGBD................................................................. 9
Figure 1.7. Actions des différents intervenants à la BD .................................... 12
Figure 2.1. Structure d’un bloc PL/SQL. .......................................................... 21
Figure 3.1. Modèle simplifié du MCD. ............................................................ 25
Figure 3.2. Schéma de la base de données. ....................................................... 26
Figure 3.3. Connexion à la BD Oracle. ............................................................. 27
Figure 3.4. Fenêtre d’accueil. ........................................................................... 28
Figure 3.5. Onglet Service ................................................................................ 29
Figure 3.6. Saisie des Départements et Chefs de département ......................... 30
Figure 3.7. Fiche d’inscription .......................................................................... 31
Figure 3.8. Saisie des matières .......................................................................... 32
Figure 3.9. Choix des vues sur les emplois du temps ....................................... 33
Figure 3.10. Emploi du temps ............................................................................. 33
Figure 3.11. Notes ............................................................................................... 34
Figure 3.12. Onglet Recherche ........................................................................... 35
Figure 3.13. Recherche d’un étudiant ................................................................. 36
Figure 3.14. Recherche d’un mémoire de fin d’études par mots-clés ................ 36
Figure 3.15. Résultat d’une recherche d’un étudiant .......................................... 37
Figure 3.16. Onglet Sécurité du menu général ................................................... 38
Figure 3.17. Liste des utilisateurs et ajout/suppression de privilèges ................. 39
Figure 3.18. Utilisateurs et Privilèges ................................................................. 39
Figure A.1. Architecture interne d’Oracle ......................................................... 43
Figure A.2. Tablespaces .................................................................................... 46
1
INTRODUCTION
Le système téléinformatique a connu un essor considérable durant ces vingt
dernières années. Le traitement et le stockage de l’information ont été éclatés sur plusieurs
micro-ordinateurs ou sur des terminaux dits intelligents qui peuvent échanger des données
entre eux par l’intermédiaire des moyens de télécommunications alors que ces fonctions ont
été centralisées sur les mainframes auparavant [1].
De ce fait, l’informatique est devenue un outil de production très proche des
utilisateurs, même des non-informaticiens et aussi un outil de communication.
De son coté, la technologie des Bases de Données (BD) met à profit cette
progression. Les Systèmes de Gestion de Bases de Données (SGBD) remplacent les
anciennes organisations où les données, regroupées en fichiers, restaient liées à une
application particulière. Des premiers modèles hiérarchiques au modèle relationnel, du
mainframe au micro, du centralisé au réparti, les ambitions des SGBD augmentent de jour
en jour.
L’objet de ce travail est donc de construire une BD mise au profit d’une part du
Service Scolarité de l’ESPA pour l’amélioration de sa tâche quotidienne et d’autre part des
étudiants et enseignants comme outil d’informations. Il s’intitule :
« Implémentation de ‘ESPA-DB’ la BD-R de l’ESPA »
Pour ce faire, nous avons décomposé cet ouvrage en trois chapitres. Les théories sur
la BD avec les différents modèles et le SGBD sont traités dans le premier chapitre. Dans le
second chapitre, nous détaillons le modèle relationnel et le SGBD-R Oracle. Et le dernier
chapitre présentera l’étude et l’implémentation de cette BD-R ainsi que l’interface
conviviale permettant d’accéder à cette base.
Base de Données et SGBD
Chapitre I
BASE DE DONNEES ET SGBD
Les bases de données sont actuellement au cœur du système d’information des
entreprises. Les systèmes de gestion de base de données, initialement disponibles
uniquement sur des ‘mainframes’, peuvent maintenant être installés sur tous les types
d’ordinateurs y compris les ordinateurs personnels. Le but de ce chapitre est de présenter
ces deux concepts qui font partie désormais du vocabulaire au quotidien.
1.1 BASE DE DONNEES
a. Définition
Une base de données (BD) est une grande quantité de données structurées qui sont
stockées avec le moins de répétition pour satisfaire simultanément plusieurs utilisateurs de
façon sélective et en un temps opportun [2].
Une BD est gérée par un logiciel de Système de Gestion de Base de Données
(SGBD). Les données doivent être fiables, cohérentes et interrogeables.
b. Limites à l’utilisation des fichiers
Une BD, contrairement aux fichiers, est une façon différente d’enregistrer les
informations. En effet, pour les fichiers, les données font partie des programmes qui les
utilisent. Ainsi, si on veut modifier la structure de données, il faut réécrire totalement tous
les programmes qui utilisent ces données [3].
Pour les bases de données, la structuration des données est unifiée et séparée des
programmes d’application. Il appartient au SGBD de fournir cette description unique des
données. D’où l’indépendance entre les données et les applications, qui peuvent être
modifiées indépendamment.
Base de Données et SGBD
3
La figure 1.1. illustre clairement cette différence.
Dans le modèle fichier, les fichiers sont définis pour un ou plusieurs programmes de
traitement.
Dans le modèle base de données, les programmes d’applications ne se
communiquent avec les données que par l’intermédiaire du SGBD.
Figure 1.1. Différence entre un fichier et une BD [2].
c. Niveaux de représentation d’une BD
Il existe trois niveaux d’appréhension d’une BD [2] [4] [5].
• Le niveau interne,
• Le niveau conceptuel,
• Le niveau externe correspondant aux différents groupes d’utilisateurs.
La figure 1.2 montre ces différents niveaux avec leur schéma de représentation.
Programme d’application 1
Programme Données
Programme Données
Offline
t
fichier
a. Modèle fichier
BDSGBD
Programme 1
Programme 2
b. Modèle base de données
Base de Données et SGBD
4
Figure 1.2. Différents niveaux de représentation d’une BD [2].
c.1. Niveau interne
Le schéma physique détermine comment les données sont enregistrées sur les
mémoires secondaires (disques, bandes, …) de l’ordinateur.
Seule la BD physique a une existence matérielle. Elle peut être perçue à différents
niveaux d’abstractions (enregistrement, article, fichier, octet, bit).
c.2. Niveau conceptuel
Le schéma conceptuel est décrit en termes abstraits mais fidèles à une certaine
réalité d’une organisation et à ses processus de gestion. C’est le résultat d’une action de
modélisation du monde réel qui respecte un modèle de données.
Schéma
Externe-1
Schéma
Externe-2
Schéma
Externe-n
Schéma
conceptuel
Monde réel
Schéma
physique
BD
physique
Niveau conceptuel
Processus de
modélisation
Groupe
Utilisateurs
Niveau externe Niveau interne
GU-1
GU-2
GU-3
Base de Données et SGBD
5
c.3. Niveau externe
C’est la description, à l’aide d’un schéma externe appelé vue, de la perception des
données par un programme d’application.
Une vue est une représentation abstraite d’une partie de la BD conceptuelle, elle
reflète un sous-schéma du schéma conceptuel. Ainsi, en général, une vue est un sous-
ensemble de la base conceptuelle de données. Cependant, dans certains cas, une vue peut
être « plus abstraite » que la base conceptuelle de données. Cela veut dire que les données
utilisées se déduisent de la base conceptuelle mais ne sont pas présentes dans cette base.
d. Modèle de BD
La BD unifie la structuration des données par un «modèle» unique et cohérent, pour
une facilité d’adaptation à toutes les éventualités Il existe deux modèles de BD : modèle
logique et modèle physique.
d.1. Modèle logique
Modèle logique [4] [5] [6] décrit l’organisation des données au niveau conceptuel
indépendamment de leur implantation physique. Trois types principaux de modèles
logiques de BD existent: les modèles hiérarchiques, les modèles réseaux et les modèles
relationnels.
( i ) Modèles hiérarchiques
Les modèles hiérarchiques (Fig. 1.3) sont les plus anciens (1965). Les informations
y sont organisées sous forme d'arborescence et ne sont accessibles que par un point d'entrée
unique. Le modèle hiérarchique oblige la redondance de certaines informations; le maintien
de sa cohérence est donc très difficile.
Figure 1.3. Modèle hiérarchique
Base de Données et SGBD
6
( ii ) Modèles réseaux
Dans les modèles réseaux (Fig. 1.4.), les données sont organisées sous forme d'un
graphe circulaire, et chaque information peut être associée à d’autres. L’inconvénient de ces
modèles est qu’ils sont très difficiles à gérer.
Figure 1.4. Modèle réseau
( iii ) Modèles relationnels
Le modèle relationnel, fondé sur la théorie des ensembles, a été défini de manière
théorique par E. CODD en 1970 [7]. Dans ce modèle, les données sont représentées sous
forme de valeurs dans des tables et l’accent est mis sur les relations entre les données. Ce
modèle ne dépend pas de l’implantation physique des données et en plus il est simple à
concevoir. C’est le modèle que nous avons choisi pour ce travail et les détails sont fournis
dans le chapitre suivant.
d.2. Modèle physique
Le modèle physique [8] décrit l’organisation physique des données sur les supports
physiques. Cette organisation physique ne peut se contenter d'une simple organisation
séquentielle des informations mais chaque SGBD a sa propre méthode [6].
De ce fait, un modèle logique donné peut donc être associé à différents modèles
physiques.
1.2 SGBD
a. Définition
Le Système de Gestion de Base de Données (SGBD) est un logiciel qui permet à
l’utilisateur d’interagir avec une BD. Il permet principalement d’organiser les données sur
Base de Données et SGBD
7
les supports périphériques et il fournit les procédures de recherche et de sélection de ces
mêmes données [2].
Pour aboutir à ce résultat, l’utilisateur décrit en termes abstraits ce qu’il veut faire
sur les données, laissant le soin au SGBD d’effectuer les tâches de recherche en fonction de
la représentation et de l’organisation des données sur les supports physiques [5].
b. Objectifs de SGBD
Les SGBD sont nécessaires pour la gestion des données stockées dans la BD (accès
à la base, modification dans la base…). Cependant, pour y parvenir certains critères doivent
être observés [2] [3] [4] :
• Indépendance physique du mode de définition des données et des structures de
stockages,
• Rapidité dans la réponse aux requêtes formulées,
• Cohérence des données pour qu’elles ne soient pas contradictoires,
• Partageabilité des données pour différents utilisateurs simultanément,
• Sécurité des données à l’aide de dispositifs adéquats,
• Langage de manipulation accessible même pour les non informaticiens.
c. Langages
Une nette différence de procédés, existe entre le langage de programmation
classique, et celui du SGBD. Dans le premier, les déclarations et les instructions
exécutables appartiennent au même langage, dans le second un langage est utilisé pour la
description des données et un autre pour leur manipulation [5] [9] [10].
c.1. Langage de description des données (LDD)
Ce langage spécifie le schéma conceptuel. C’est un langage descriptif des types
d’entités, de leurs attributs et domaines et des associations (ou relations) entre ces entités.
Il est utilisé lors de la définition des données, lors des modifications de schéma.
Base de Données et SGBD
8
c.2. Langage de manipulation des données (LMD)
Le langage de manipulation de données, appelé aussi langage d’interrogation (query
language) permet d’interroger la base, mettre à jour les données (ajout, suppression,
modification). Contrairement au LDD, ce langage a une similitude avec les langages de
programmation classique : structures conditionnelles, structures itératives et affectations.
Toutefois, il comporte des instructions spécifiques lui permettant de référencer les données
à manipuler et d’exprimer le type de manipulation à effectuer : insertion, mise à jour,
suppression, recherche et interrogation.
Généralement, le programme d’application est écrit dans un langage hôte ( C, Basic,
COBOL, …) mais par contre, la communication avec la BD s’effectue par des instructions
du LMD, activées à partir du langage hôte.
d. Diagramme de flots
Le programme d’application sert d’interface entre le SGBD et l’utilisateur. Pour
l’écrire, le programmeur utilise le schéma externe. Et, c’est au SGBD d’interpréter les
instructions exprimées en terme de schéma externe, pour les convertir en terme de schéma
conceptuel. Le SGBD transforme le résultat en ordre sur la BD physique [5].
Nous avons donc deux flots différents : d’une part le flot des ordres qui démarre du
niveau externe vers le niveau physique et d’autre part, le flot des données qui va dans le
sens contraire (Fig.1.5.).
Figure 1.5. Diagramme de flots [5].
Programme
d’applicationUtilisateurNiveau
externe
Niveau
conceptuel
Niveau
physique
flot des ordres
flot des données
Légende :
Base de Données et SGBD
9
e. Architecture
L’architecture du SGBD [5] garantit la circulation du flot des ordres et du flot de
données. Nous présentons l’architecture de base d’un SGBD sur la Fig.1.6. Elle comporte
le noyau, le système d’exploitation ainsi que les différents schémas nécessaires.
Légende : flot des données
Informations provenant des schémas
Flot d’instruction
Figure 1.6. Architecture d’un SGBD [5].
Données Logiciels Schémas
Niveau
externe
Niveau
conceptuel
Niveau
physique
7
Tampon du
programme
d’application
Programme
d’application
Schéma
externe1
Schéma
externe2
Tampon
système
Noyau du
SGBD
Système
d’exploitation
Schéma
conceptuel
Base de
données
physiques Contrôleur
d’entrée/sortie
Schéma
physique
1
9
10
8
2
3
5
6
47
Base de Données et SGBD
10
Supposons que le programme d’application lance un ordre de lecture d’un groupe de
données. L’exécution de ce programme passe par un certain nombre d’étapes :
1. envoi de la demande de lecture au noyau,
2. analyse de la demande à l’aide du schéma externe (vérification du droit d’accès et
des données),
3. consultation du schéma conceptuel par le noyau et déduction du type logique des
données à extraire,
4. consultation du schéma physique qui donne l’enregistrement physique à lire,
5. envoi d’un ordre de lecture au système d’exploitation,
6. analyse des paramètres du schéma physique et envoi de l’ordre de lecture au
contrôleur des unités d’entrée/sortie qui gèrent la BD,
7. transfert des données dans le tampon système,
8. envoi des données nécessaires au tampon du programme d’application sous le
contrôle du SGBD,
9. opération terminée,
10. information des échecs éventuels par le SGBD.
Ce principe qui concerne une demande de lecture est analogue à celui d’une
demande d’écriture ou de mise à jour. Plus précisément, une demande de mise à jour
commence par une opération de lecture, puis d’écriture.
Le cas que nous venons de décrire concerne un seul programme d’application. En
général, plusieurs programmes d’application sont exécutés en parallèle, il appartiendra alors
au SGBD de les gérer et plus particulièrement de détecter le cas où différents programmes
souhaitent accéder à la même donnée.
f. Intervenants
Plusieurs intervenants [2][9] peuvent se servir le SGBD (Fig. 1.7).
• L’administrateur de la BD a la responsabilité de la gestion du système dans son
ensemble :
o définition du schéma original de la base,
o choix des structures de données et des méthodes d’accès au niveau physique,
Base de Données et SGBD
11
o modification du schéma et de l’organisation physique en fonction de l’évolution
de la base,
o gestion des droits d’accès et des privilèges des utilisateurs,
o spécification des contraintes d’intégrité,
o sauvegardes et restaurations.
• Les programmeurs (ou l’acquisition) d’application développent des interfaces
entre le SGBD et les utilisateurs habituels.
• Les utilisateurs habituels utilisent des programmes d’applications prédéfinis et
permanents.
• Les utilisateurs occasionnels interagissent avec le système sans écrire de
programme mais en formulant leurs requêtes avec le LMD.
Base de Données et SGBD
12
Figure 1.7. Actions des différents intervenants à la BD [2].
Notons que le module gestionnaire de données s’occupe de :
- l’interaction avec le gestionnaire de fichier du système hôte,
- l’intégrité de la base,
- la sécurité,
- les sauvegardes et restaurations,
- Contrôle des accès concurrents.
Utilisateurs
habituels
Programmeurs
d’applications
Utilisateurs
occasionnels
Administrateur
de la BD
Programmes
d’application
Appels
système
Requêtes
(LMD)
Schéma de la
BD (LDD)
Précompilateur
du LMD
Processeur de
requêtes
Compilateur de
LDD
Programmes
d’application
code objet
Gestionnaire
de données
Fichiers de
données
Dictionnaire
de données
S
G
B
D
Gestion de
fichiers et
système
hôte
Modèle Relationnel et Oracle
13
Chapitre II
MODELE RELATIONNEL ET ORACLE
La première génération de BD, liée aux modèles hiérarchiques et en réseaux est
pratiquement abandonnée actuellement. La deuxième génération liée aux modèles
relationnels est alors devenue la norme pour tout système de BD. Ce chapitre est consacré à
ce modèle et au SGBD Oracle.
��2.1 DEFINITIONS
a. Concepts de base
Un certain nombre de concepts de base [10] [11] [12] [13] est utile pour établir le
modèle relationnel.
• Domaine : ensemble de valeurs.
• Relation : sous-ensemble du produit cartésien de domaines, chaque relation est caractérisée
par un nom.
• Attribut : colonne d’une relation.
• Entité ( tuple ou n-uplet ) : ligne d’une relation, soit une des valeurs possibles d'une relation.
• Schéma de relation : constitué par le nom de la relation, suivi de la liste des attributs
avec leur domaine
Exemple de schéma de relation :
Nom de la relation
ETUDIANT
Attributs Domaines
- Nom .................................................... caractère(75)
- Prénom .............................................. caractère (75)
- Date de naissance .............................. date
- Lieu de naissance ............................... caractère (50)
Modèle Relationnel et Oracle
14
• Clé primaire : Identifiant unique permettant de repérer une entité.
• Clé étrangère : Clé primaire dans une autre relation.
• Clé secondaire : Clé supplémentaire identifiant une entité en plus de sa clé primaire.
b. Opérateurs relationnels
Les opérateurs relationnels [3] sont les suivants:
• Projection
C’est une opération qui consiste à supprimer des attributs d’une relation et élimine
éventuellement les tuples identiques.
• Restriction ou Sélection
C’est une opération qui consiste à supprimer les tuples d’une relation ne satisfaisant pas
la condition précisée.
• Jointure
C’est une opération qui consiste à faire le produit cartésien de deux relations et garde les
tuples qui vérifient la condition de rapprochement.
En outre, en considérant deux relations ayant le même schéma, d’autres opérateurs
relationnels existent,
• Union
La relation obtenue est constituée des tuples appartenant à chaque relation en
éliminant les éventuels doublons.
• Différence relationnelle
La relation obtenue est constituée de tuples qui ne se trouvent que dans une seule
relation.
• Intersection
La relation obtenue est constituée de tuples appartenant aux deux relations.
Modèle Relationnel et Oracle
15
c. Modèle conceptuel de données (MCD)
Un MCD [14] [15] est la représentation de l’ensemble des données mémorisables du
domaine, sans tenir compte des aspects techniques et économiques, du stockage et de
l’accès, sans se référer aux conditions d’utilisation par tel ou tel traitement
Il doit être indépendant de toute contrainte technique telle que logiciel ou matériel.
En outre, il doit fournir une description de la sémantique des données.
2.2 MODELE RELATIONNEL
Le modèle relationnel [16] [17] est bâti sur une structure simple : les relations. Ces
relations sont indépendantes les unes des autres et chacune d’elles est représentée sous
forme d’une table relationnelle à deux dimensions où :
- Les lignes représentent des entités ( n-uplets ou tuple) indépendantes les unes
des autres ;
- Les colonnes représentent les attributs et relations concernant chaque entité.
a. BD Relationnelle
Une BD relationnelle s’appuie sur un ensemble de schémas de relations réalisées au
niveau des tuples [2].
Les tuples des tables sont manipulés par des opérateurs algébriques.
b. SGBD Relationnel
Un SGBD est dit minimalement relationnel [2] si :
- Les informations de la base sont représentées par des tables,
- Il n’y a pas de pointeurs visibles sur les tables,
- Le système supporte les opérateurs relationnels : Restriction (sélection),
Projection et Jointure.
Modèle Relationnel et Oracle
16
Un SGBD est complètement relationnel si de plus :
- Il réalise tous les opérateurs de l’algèbre relationnelle,
- Il y a unicité des clés (pas de doublons),
- Il assure la contrainte référentielle.
2.3 LOGICIEL ET LANGAGES UTILISES
De nombreux SGBD sont aujourd’hui disponibles sur micro-ordinateur tels Access
(Microsoft), SQL Server (Microsoft), Interbase (Borland), Oracle (Oracle Corporation)…
Notre étude s’est basée sur Oracle du fait que parmi les SGBD adoptant
l’environnement Client/Serveur, la capacité d’une BD Oracle est très étendue (de l’ordre de
terabytes) et elle soutient de grands nombres d’utilisateurs simultanés exécutant une variété
d’applications sur les mêmes données.
a. Logiciel Oracle
Oracle est un SGBD relationnel développé par Oracle Corporation depuis 1970. Pour
notre BD, nous avons utilisé la version 8. ( l’architecture de Oracle 8 est détaillé à l’annexe
A).
Un serveur de BD Oracle est constitué de la BD Oracle et de l’instance Oracle [18] [19].
a.1. BD Oracle
La BD associée à Oracle a à la fois une structure physique et une structure logique
[20].
( i ) Structure Physique
La structure physique d’une BD Oracle reflète l’organisation des fichiers du
système d'exploitation. Chaque BD Oracle est composée de trois types de fichiers :
- un ou plusieurs fichiers de données (database files),
- deux ou plusieurs fichiers de journalisations (redolog files),
- un ou plusieurs fichiers de contrôle (control files).
Modèle Relationnel et Oracle
17
( ii ) Structure Logique
La structure logique d’une BD Oracle est constituée par :
• Un ou plusieurs tablespaces : un tablespace est un secteur logique de stockage.
• Le schéma de la BD : les objets du schéma sont les structures logiques qui se
réfèrent directement aux données de la BD. Les objets du schéma incluent des
structures telles que des tables, des vues, des ordres, des procédures stockées, des
synonymes, des index, des groupes et des liaisons de BD.
a.2. Instance Oracle
A chaque démarrage d’une BD Oracle, une zone mémoire nommée SGA (System
Global Area) est allouée et des processus sont lancés en tâche de fond. Une instance Oracle
est donc la combinaison des processus de fond et de l’allocation du SGA [19].
On distingue généralement deux types de processus :
! Processus utilisateur (User Process ou Noyau Oracle) qui est chargé
d'interpréter et d'exécuter les requêtes SQL, ainsi que de gérer la mémoire et
les fichiers de données,
! Processus système (Oracle Processes) qui exécute le travail pour les
processus utilisateurs et le travail de maintenance pour le serveur Oracle.
a.3. Objets de base
Les objets de base manipulés par Oracle sont :
- les tables,
- les vues,
- les noms des utilisateurs et leurs privilèges sur les tables et/ou sur les vues,
- les accélérateurs (index, clusters) sur les tables [20][21].
( i ) Tables
Une table est identifiée par un nom. Le nom d’une table doit être unique pour un
utilisateur donné. Pour désigner une table appartenant à un autre utilisateur, il faut préfixer
son nom par celui de l’utilisateur. Une table est composée d’un ensemble de colonnes et de
lignes.
Modèle Relationnel et Oracle
18
( ii ) Vues
Une vue est une table virtuelle, c’est à dire une collection qui n’a pas d’existence
physique. Une vue peut être considérée comme l’évaluation d’une requête de la base
(différents opérateurs de l’algèbre relationnelle).
( iii ) Nom d’utilisateurs
Un utilisateur dans Oracle est défini par un nom (identifiant unique), un mot de passe
et un ensemble de privilèges (ou droits). La notion de privilège permet de fixer les règles
d’utilisation des objets définis dans la BD et, par conséquent, d’assurer la confidentialité
des données. Pour effectuer une opération quelconque sur un objet, un utilisateur doit avoir
les privilèges nécessaires.
( iv ) Accélérateurs
Oracle dispose de deux mécanismes pour améliorer les performances au niveau des
accès à la BD : les index et les clusters (ou groupement).
Les index sont des structures facultatives associées à une table pour localiser
rapidement des lignes de la table et (facultativement) pour s'assurer que chacune des lignes
est unique.
Les clusters sont des groupements physiques de deux ou plusieurs tables ayant
toutes au moins une colonne commune.
b. SQL
SQL signifie “Structured Query Language” ou « Langage d’interrogation structuré ».
Il a été introduit par IBM comme le langage d’interface de son prototype de SGBD-R. Le
premier système SQL disponible sur le marché a été introduit en 1979 par Oracle
Corporation. Aujourd’hui, SQL est devenu un standard pour le SGBD-R.
Comme SQL est un langage non-procédural, des ensembles d’enregistrement
peuvent être manipulés à la fois. La syntaxe est naturelle et souple, ce qui permet de se
concentré sur la présentation des données [22].
Modèle Relationnel et Oracle
19
b.1. Types de déclaration SQL
Les types de déclarations SQL sont classés en cinq groupes [9] :
- récupération des données,
- manipulation des données,
- définition des données,
- contrôle de la transaction,
- contrôle des données.
( i ) Langages de récupération de données (Data Retrieval Language)
Ils rapportent les données de la BD avec la déclaration SELECT.
( ii ) Langages de manipulation de données (Data Manipulation Langage)
Ils permettent d’apporter des changements aux données dans la BD :
- INSERT pour entrer de nouvelles lignes,
- UPDATE pour changer des lignes existantes,
- DELETE pour enlever des lignes non désirées d'une table.
( iii ) Langages de définition de données (Data Definition Language) pour
décrire la structure d'une BD :
- CREATE crée une nouvelle table dans la BD,
- RENAME change le nom d'une table,
- ALTER rénove les structures de la table,
- DROP supprime une table entière d'une BD.
( iv ) Langages de contrôle de la transaction (Transaction Control Language)
sont utilisés pour contrôler des changements effectués dans les Langages
de Manipulation de Données :
- COMMIT accepte un changement,
- ROLLBACK annule un changement,
- SAVEPOINT crée un marqueur dans une transaction. Un changement
peut être annulé en revenant au « savepoint ».
Modèle Relationnel et Oracle
20
( v ) Langages de contrôle de données (Data Control Language) contrôlent
l'accès de l'utilisateur à la BD :
GRANT et REVOKE donnent ou enlèvent des droits d'accès à une BD Oracle ou aux
structures dans la BD.
b.2. Types des donnés
Quelques types de données
- Numérique (NUMBER)
- Date (DATE)
- Caractère (CHAR, VARCHAR2, LONG)
- Binaire (RAW, LONGRAW)
b.3. Exemple
Création de la table ETUDIANT
CREATE TABLE Etudiant ( nom varchar2 (200),
Prénom varchar2 (200),
Nine char (12) Primary key,
Date_naiss date,
Lieu_naiss varchar2 (50),
Id_dept number
CONSTRAINT dept_fkey REFERENCES Département ).
c. PL/SQL
En plus du SQL commande, le serveur Oracle a un langage procédurale appelé PL/SQL.
Le langage PL/SQL est un langage de troisième génération, fournissant une
interface procédurale au SGBD Oracle. Le langage PL/SQL intègre parfaitement le
langage SQL en lui apportant une dimension procédurale[21] [23].
On peut utiliser PL/SQL pour améliorer et modifier les fonctionnalités par défaut
qui sont incorporées dans chaque application form builder.
Modèle Relationnel et Oracle
21
L’éditeur PL/SQL intégré est utilisé pour écrire du code PL/SQL dans form builder.
Dans le builder, le code PL/SQL est choisi pour les opérations suivantes :
- Création d’un déclencheur
- Ecriture d’un sous-programme nommé par l’utilisateur
- Ecriture d’un package PL/SQL
- Création d’un élément de menu du type PL/SQL
- Définition d’un code de lancement de menu
PL/SQL offre un moyen d’identifier et de traiter les éventuelles erreurs à l’aide de
mécanisme des exceptions. Lorsqu’une erreur se présente, celle-ci est automatiquement
transmise à un bloc EXCEPTIONS permettant de la traiter.
Le langage PL/SQL permet de définir un ensemble de commandes contenues dans
un bloc appelé bloc PL/SQL. Un bloc PL/SQL qui peut lui-même contenir des sous blocs.
La figure 2.1 montre la structure d’un bloc PL/SQL :
Figure 2.1. Structure d’un bloc PL/SQL.
Les déclarations des variables et des curseurs ont la syntaxe suivante :
Variables : Nom_variable type_de_données ; (Le type de données est le même
que celui de SQL).
Curseurs : CURSOR nom_curseur IS instruction_select;
[ DECLARE
déclaration des variables et curseurs ]
BEGIN
Commandes SQL et PL/SQL
[EXCEPTION
Traitement des erreurs ]
END ;
Modèle Relationnel et Oracle
22
d. Oracle Developer
Oracle Developer est une suite d’outils de RAD (Rapid Application Development)
pour créer des applications qui donnent une interface visuelle à l’utilisateur final de la base
de données [24].
Les trois principaux outils de Oracle Developer permettent de construire des
applications graphiques intégrées.
! Form Builder : crée des interfaces pour rechercher, écrire, modifier et enregistrer
des informations dans une base de données,
! Report Builder : permet de concevoir, d’éditer et de distribuer les rapports dans
une combinaison des modèles et les éditer dans une variété de formats, largement
répandus, y compris HTML et PDF,
! Graphics Builder : établit les applications pour visualiser les données et les
modifier graphiquement.
Oracle Developer inclut d’autres outils additionnels pour générer automatiquement
les tâches de développement d’application utilisant les interfaces visuelles.
! Project Builder gère les composants d’une application,
! Procedure Builder édite, compile , teste et débogue les langages PL/SQL,
! Schema Builder crée, copie, modifie et supprime les objets d’une base de données
et leur relation,
! Query Builder construit les requêtes de base de données à utiliser aux applications,
! Translation Builder traduit les applications vers plus de 40 langages.
Conclusion
Dans ce chapitre, nous avons donné un aperçu des outils dont nous nous
sommes servis pour le développement de notre BD.
Base de Données de l’ESPA
23
Chapitre III
BASE DE DONNEES DE L’ESPA
Notre travail consiste à l’élaboration d’une BD-R pour l’ESPA. Ce chapitre a donc
comme objectif de présenter en détail l’implémentation de cette BD-R. c’est une BD qui
donne des informations sur les étudiants et les départements.
��3.1 UTILISATEURS DE LA BD
Plusieurs catégories d’utilisateurs peuvent consulter notre BD, voire agir la dessus
suivant leur fonction au sein de l’ESPA. Ainsi,
- L’administrateur peut :
Ajouter ou supprimer des utilisateurs
Accéder à tous les objets de la base
Effectuer toutes les opérations de maintenance de toute la base,
- L’administration effectue les opérations de mise à jour de la BD
- Les enseignants et les étudiants peuvent consulter les objets de la BD qui leur
sont permis.
3.2 ANALYSE ET DEFINITION DES BESOINS
a. Besoins
La capture et l’analyse des besoins consistent à déterminer les données et/ou les
fonctionnalités que la BD doit fournir et les contraintes sur lesquelles elle sera soumise [7].
Ces besoins peuvent être regroupés en trois catégories :
• les besoins fonctionnels,
• les besoins non-fonctionnels,
• les besoins en matière de base de données.
Base de Données de l’ESPA
24
a.1. Besoins fonctionnels
Les besoins fonctionnels concernent les services attendus par l’utilisateur. Comme
besoins fonctionnels, nous avons choisi les services suivants :
- accès au cursus universitaire de chaque étudiant,
- emploi du temps de chaque enseignant,
- facilité quant à la mise à jour de la BD, sa sauvegarde, la gestion des utilisateurs.
a.2. Besoins non-fonctionnels
Les besoins non-fonctionnels concernent les contraintes empêchant la liberté sur la
réalisation de la BD.
Des restrictions doivent être imposées sur les matériels et logiciels. En effet, notre
établissement n’a pas à sa disposition des matériels haut de gamme du point de vue rapidité
et capacité de stockage. Mais pour accélérer l’accès aux données, des redondances
s’avèrent nécessaires pour offrir plusieurs chemins de recherche. Or ceci augmente
rapidement l’occupation mémoire. Nous y reviendrons dans la détermination de la
configuration minimale.
a.3. Besoins en matière de BD
C’est la BD proprement dite. Les informations relatives aux enseignants, étudiants
ainsi que leurs départements respectifs y sont stockées.
Ces informations peuvent donc être regroupées en deux grandes parties qui sont
reliées l’une à l’autre :
- les départements,
- et les étudiants.
Pour les départements, nous avons les relations sur :
! les noms des chefs de département,
! les options existantes dans chaque département,
! les matières enseignées,
! les enseignants pour chaque matière,
! les emplois du temps des matières.
Base de Données de l’ESPA
25
Pour les étudiants, nous avons :
! l’état civil des étudiants,
! l’étude suivie par chaque étudiant pendant l’année universitaire
en cours ainsi que son année d’étude,
! les notes obtenues par chaque étudiant tout au long de son cursus,
! les mémoires de fin d’études.
Ainsi, la Fig.3.1 représente un modèle simplifié du MCD
Figure 3.1. Modèle simplifié du MCD.
b. Schéma de la BD
Il s’agit d’adapter le modèle conceptuel de données aux exigences du SGBD Oracle.
Ce dernier permet le stockage de données en tableaux à deux dimensions reliés entre eux
par des relations.
La figure 3.2 représente le schéma de la BD.
DEPARTEMENTS
EMPLOI DU TEMPS
MATIERES ET
ENSEIGNANTSADMISSION
CURSUS DES
ETUDIANTS
ETUDIANTS
MEMOIRES DE FIN
D’ETUDES
ETAT CIVIL NOTES
Base de Données de l’ESPA
26
Figure 3.2. Schéma de la base de données.
Ces tables sont placées dans le tablespace USER de Oracle Server.
Notre BD est constituée de douze tables ( Fig. 3.2), à savoir :
- DEPMT pour les Départements,
- STUD pour les étudiants,
- CHEF_DEPMT pour les noms des chefs de départements,
Base de Données de l’ESPA
27
- ADM pour l’admission des étudiants,
- ET_CIV pour l’état civil,
- NOTES pour les notes obtenues,
- HISTOR pour l’historique ou cursus des étudiants,
- MEM pour les mémoires de fin d’études,
- KEYWORD pour les mots clés,
- MAT et MAT_GRP pour les matières,
- SCHEDULE pour les emplois du temps.
3.3 INTERFACE DE « ESPA-DB »
a. Présentation des fenêtres
L’interface a été développée sous Oracle Form de la suite Oracle Developer. Ce qui
permet de manipuler facilement la BD, même par des non-informaticiens.
Oracle Form Compiler génère un fichier exécutable dont l’extension est .fmx qui
pourra être exécuté à l’aide de Oracle Forms Runtime.
Au lancement du programme, Oracle Forms Runtime affiche la fenêtre qui permet de se
connecter à la BD Oracle (Fig. 3.3). Ceci est indispensable pour vérifier les privilèges de
l’utilisateur.
Figure 3.3. Connexion à la BD Oracle.
Après connexion, la fenêtre d’accueil s’affiche à l’écran. (Fig.3.4). Cette fenêtre
comporte trois boutons, à savoir Démarrer, Documents et Quitter.
Le bouton Démarrer permet d’accéder aux menus. Ces menus sont représentés dans
trois onglets :
Base de Données de l’ESPA
28
- L’onglet Services (Fig. 3.5.) comprend les outils permettant la lecture et la
maintenance des données (insertion, suppression et mise à jour).
- L’onglet Recherche (Fig. 3.12) comprend les outils de recherche tels que
recherche d’un étudiant et recherche de mémoire de fin d’études.
- L’onglet Sécurité (Fig. 3.7) comprend les outils qui permettent de gérer
l’accès à la BD, de sauvegarder la base vers des périphériques de sauvegarde
tel que lecteur de bande,…pour que les données soient en sécurité contre les
utilisateurs non-autorisés et les pannes techniques.
Le bouton Documents affiche une page web concernant cette BD et Quitter permet
de quitter l’application.
Figure 3.4. Fenêtre d’accueil.
b. Lecture et Maintenance
Sept modules sont disponibles pour la lecture et la maintenance des données (onglet
Services, cf. Fig.3.5).
Pour accéder à un module, il suffit de le sélectionner puis de cliquer sur le bouton
Start.
Base de Données de l’ESPA
29
Figure 3.5. Onglet Service
Pour la plupart des modules, un bouton Format HTML est disponible. Ce bouton
permet d’afficher les données de la fenêtre en cours en tant que tableau dans un fichier au
format HTML.
b.1. Départements
La saisie des informations concernant les départements (Fig. 3.6) ne se fera qu’une
seule fois mais la liste contenant le nom des chefs de département sera ajoutée à chaque
élection de nouveau chef. Les données peuvent être mises à jour dans le cas d’une erreur ou
modification mais dans le cas où un nouveau département serait créé, il faut cliquer sur le
bouton Nouveau.
Base de Données de l’ESPA
30
Figure 3.6. Saisie des Départements et Chefs de département
b.2. Première inscription et Fiche d’inscription
La différence entre ces deux modules est que le second ne permet pas l’insertion
d’un nouvel étudiant, ceci se fera dans le premier module. Les deux modules présentent des
zones pour saisir l’état civil, la mémoire de fin d’études et le résumé de celle-ci.
La figure 3.7. illustre la Fiche d’inscription.
Base de Données de l’ESPA
31
Figure 3.7. Fiche d’inscription
b.3. Matières et emploi du temps
La figure 3.8. nous montre la saisie des matières enseignées, les coefficients et les
enseignants pour chaque matière. L’emploi du temps de chaque matière est obtenu en
double-cliquant sur le nom de la matière.
Base de Données de l’ESPA
32
Figure 3.8. Saisie des matières
Pour visualiser les emplois du temps (dans le module Emploi du temps), deux vues
sont créées. L’une donne les emplois du temps des étudiants et l’autre ceux des
enseignants.
Pour commuter entre ces deux vues (Fig.3.9), deux boutons d’option
(Etudiants/Enseignant) peuvent être choisis à la première fenêtre.
Base de Données de l’ESPA
33
Figure 3.9. Choix des vues sur les emplois du temps
Un click sur OK affiche l’emploi du temps (Fig. 3.10).
Figure 3.10. Emploi du temps
Base de Données de l’ESPA
34
b.4. Notes
Les données relatives aux notes obtenues sont l’admissibilité, l’admission, la
mention, l’année d’études dans la prochaine année universitaire.
La figure 3.11. représente la fenêtre de saisie des notes avec ses informations
relatives. Le total des notes et la moyenne sont calculés automatiquement.
Figure 3.11. Notes
Base de Données de l’ESPA
35
c. Recherche
Pour faciliter la recherche dans la BD, trois modules sont disponibles dans l’onglet
Recherche (Fig.3.12) à savoir Rechercher Etudiant, Rechercher mémoire de fin d’études
par titre et Rechercher mémoire de fin d’études par mots-clés.
Figure 3.12. Onglet Recherche
La recherche d’un étudiant (Fig. 3.13.) se fait en tapant ou en sélectionnant un nom
dans la zone de liste déroulante. Le résultat de la recherche se trouvera dans la liste de
sélection ‘Résultat de la recherche’.
La recherche d’un mémoire de fin d’études par titre est similaire à celle d’un
étudiant mais pour rechercher un mémoire de fin d’études par mots-clés (Fig.3.14),
plusieurs zones sont disponibles pour entrer les mots clés.
La figure 3.15 montre le détail du résultat de la recherche d’un étudiant.
Base de Données de l’ESPA
36
Figure 3.13. Recherche d’un étudiant
Figure 3.14. Recherche d’un mémoire de fin d’études par mots-clés
Base de Données de l’ESPA
37
Figure 3.15. Résultat d’une recherche d’un étudiant
d. Sécurité
Pour assurer la sécurité de la BD contre les accès non-autorisés ainsi que les pannes
techniques, trois modules sont présentés dans l’onglet Sécurité (Fig.3.16) ; à savoir la
Gestion des droits d’accès, le Sauvegarde et la Restauration de la BD.
Base de Données de l’ESPA
38
Figure 3.16. Onglet Sécurité du menu général
d.1. Gestion d’accès et de confidentialité
Pour accéder à la BD, il faut que chaque utilisateur possède des droits d’accès ou
privilèges. Les principaux droits sont le droit d’insertion, de suppression, de mise à jour et
de lecture.
La figure 3.17. représente la fenêtre contenant la liste de tous les utilisateurs et ses
privilèges. La table des privilèges (Fig. 3.18.) est obtenue en cliquant sur le bouton Table
des privilèges. Le bouton Nouvel Utilisateur permet de créer un nouvel utilisateur.
Remarque : Seuls les administrateurs ont le droit de modifier ces privilèges ou de
créer de nouveaux utilisateurs (cf. Annexe B).
Base de Données de l’ESPA
39
Figure 3.17. Liste des utilisateurs et ajout/suppression de privilèges
Figure 3.18. Utilisateurs et Privilèges
d.2. Sauvegarde et restauration de la BD
Pour la sauvegarde et la restauration de la BD, l’application doit lancer les outils de
sauvegarde et de restauration fournis par Oracle qui sont :
- Oracle Backup Manager
- Oracle Recovery Manager
Ses outils permettent de sauvegarder la BD Oracle vers les périphériques de
sauvegarde (lecteur de bande ou streamer, lecteur ZIP,…) et de la restaurer en cas de panne
technique ou d’erreurs de manipulation.
Base de Données de l’ESPA
40
3.4 INSTALLATION
L’installation de la BD se fait en trois étapes
1e étape : Installation et configuration du logiciel Oracle
S’il s’agit d’une installation sur un poste de travail autonome, Oracle Server
considère le poste de travail en étant à la fois serveur et client.
S’il s’agit d’une installation sur un réseau, il faut installer Oracle Server sur le
serveur et Oracle Client sur les autres postes.
2e étape : Installation de l’interface
Nous avons développé un programme d’installation nommé ‘setup.exe’. Ce
programme copie automatiquement les fichiers nécessaires pour l’interface dans un
répertoire choisi par l’utilisateur et crée quatre raccourcis dans le groupe de programmes du
menu démarrer, à savoir : Base de Données de l’ESPA, Installer les objets de la BD, Aide et
Désinstaller l’interface.
3e étape : Création des objets de la BD
En cliquant sur « Installer les objets de la BD » dans les groupes de programmes, le
programme d’installation crée automatiquement les objets de la BD. Cette opération n’est
possible que si l’utilisateur ait le rôle d’administrateur (cf. Annexe B).
Configurations matérielles et logicielles requises :
Avec Oracle8, la base de données ainsi que l’interface utilisateur requièrent le
matériel minimum et logiciel suivant :
Matériel :
Un PC basé sur un processeur Pentium
32 Mo de RAM.
Espace disque : 100 Mo et 20 Mo d’espace libre pour la mémoire virtuelle paginée.
Un Scanner
Logiciel :
Microsoft Windows 9x ou Windows NT 4.0
Oracle Server 7 ou 8 et Oracle Form Runtime 6.0
41
CONCLUSION
Dans ce travail, nous avons construit une BD-R pour l’ESPA. C’est une BD basée
sur le modèle relationnel. Elle permet de faciliter non seulement la tâche quotidienne du
service de la scolarité mais aussi la recherche d’informations, comme les emplois du temps
pour les enseignants et les étudiants.
La gestion de cette BD est assurée par le SGBD Oracle et c’est avec ses outils de
développement d’applications que le programme d’interface facilitant la modification, la
consultation et la recherche sur la BD a été créé.
En outre, ce travail nous a permis d’approfondir nos connaissances sur la BD en
particulier la BD Relationnelle ainsi que le SGBD Oracle.
Bien évidemment, notre BD-R n’est pas exhaustive. D’autres informations et
applications peuvent être rajoutées. Ainsi, des améliorations pourraient être réalisées
comme l’établissement automatique du certificat de scolarité, du relevé des notes, du
résultat des examens,…
Comme la BD est installée sur un serveur, elle pourra aussi être liée à un serveur
web pour permettre la consultation et l’inscription sur l’Internet.
Des extensions comme la liaison avec la BD de la Bibliothèque Universitaire et du
Service d’Intendance de la Cité Universitaire (SICU), du Rectorat de l’Université
d’Antananarivo et même du Ministère de l’Enseignement Supérieur peuvent être aussi
envisagées et nous incitons les étudiants en électronique à poursuivre cette étude.
42
ANNEXES
43
ANNEXE A. ARCHITECTURE D’ORACLE 8
L’architecture interne d’Oracle est organisée en trois niveaux, Niveau fichiers, niveau
processus et niveau mémoire [18] [19]. La Fig. A.1 présente ces trois niveaux.
On appelle instance Oracle les processus et la SGA d’une base de données Oracle.
DBWR : Database Writer or Dirty Buffer Writer
LGWR : Log Writer
PMON : Process Monitor
SMON : System Monitor
CKPT : Checkpoint
RECO : Recoverer
ARCH : Archiver
Dnnn : Dispatcher, nnn représente une suite de nombre entier.
Snnn : Server, nnn représente une suite de nombre entier.
LCKn : Lock
Figure A.1. Architecture interne d’Oracle [19].
Memory
Processes
Hardware
System Global Area (SGA)
Database buffer Redo log buffer
User
process
Snnn
Dnnn
DBWR LGWR ARCH RECO
PMON SMON
LCKn
CKPT
Database
files
Redo log
files
Offline
storage
device
Control files
44
Le premier correspond à la structure de la base de données et la façon dont les données
sont stockées. Il comprend la base de données, un ou plusieurs fichiers de pilotage ou de
contrôle, des fichiers de journalisation et des supports d’archivage. Le niveau processus
correspond aux différents processus Oracle assurant la gestion de données. Il comprend un
certain nombre de processus serveurs et des processus utilisateurs. Enfin, le niveau mémoire
correspond à l’organisation de données du côté mémoire centrale. Il est composé d’une zone
mémoire appelée SGA ( System Global Area) contenant les buffers associés aux processus
serveurs et de curseurs associés aux processus utilisateurs.
A.1. Niveau fichier
Les fichiers d’une base de données Oracle sont les suivants :
- Les fichiers de bases (database files)
- Les fichiers de journalisations (redolog files)
- Les fichiers de contrôle ( control files)
Une base de données Oracle nécessite au minimum un fichier de base, deux fichiers
redolog et un fichier de contrôle.
a. Les fichiers de base
Les fichiers de bases contiennent essentiellement des informations de deux types :
- Les données des utilisateurs et du dictionnaire de données (DD) qui constituent le cœur
de la base de données Oracle. Ces données consistent en des tables et des index.
- Les données de travail sont nécessaires pour qu’Oracle puisse fonctionner. Sous
Oracle, un fichier base ne peut être supprimé directement : ceci peut être fait par la
suppression du tablespace auquel il appartient. On détaille la notion de tablespace.
a.1. Notion de segment
• Les segments de données et d’index : Une table d’utilisateur ou du dictionnaire de
donnée occupe un certain nombre de blocs Oracle ( blocs Oracle : la plus petite unité de
transfert mémoire disque formant un fichier de base). Les blocs pris par une table
45
forment ce que l’on appelle un segment de données. Un index occupe un segment
d’index.
• Les segments de travail : Ils représentent une partie des blocs des fichiers bases.
Cette partie est utilisée par Oracle pour ses propres besoins. Il y a quatre types de
segments de travail : les rollback segments, les segments temporaires, les segments
différés et ceux du démarrage (rollback segments, temporary segments, deffered
rollback segments, cache segment)
Le nombre d’extension d’un segment et leur taille dépendant des paramètres de
stockage INITIAL, NEXT, MINEXTENTS, MAXEXTENTS, PCT INCREASE.
a.2. Notion de tablespace
D’un point de vue physique, une base est un ensemble de fichiers au sens système
d’exploitation. Un fichier peut contenir une partie de table ou d’index, une ou plusieurs table,
un ou plusieurs index…
Les fichiers base sont regroupés en unité logique appelée tablespace. Une base de
données a au moins un tablespace qui est le tablespace SYSTEM.
Le tablespace SYSTEM contient la DD et le rollback segment SYSTEM.
Une table, un index ou un rollback segment se trouve dans un tel et un seul tablespace.
Le DBA peut créer plusieurs tablespaces pour
- Répartir les segments de données et de travail sur plusieurs
disques
- Organiser les données en unité logique, chacune contenant les
données d’une application particulière ou d’un utilisateur
particulier.
- Faciliter les opérations de sauvegarde et de restauration
- Contrôler la disponibilité des données puisqu’un DBA ne peut
pas mettre online ou offline, une table directement, il faut qu’il
passe par son tablespace
- Gérer l’espace d’allocation des segments et de travail en
imposant des tablespaces aux créations
La figure A-2 illustre le concept du tablespace
46
Figure A.2. Tablespaces [18].
b. Les fichiers redolog
Les fichiers de journalisation contiennent tous les changements d’état de la base de
données et sont utiles pour la restauration d’une base suite à un incident de l’instance ou du
disque (process LGWR).
Lorsque le fichier redolog courant est plein, Oracle enchaîne sur le suivant ; et ainsi
jusqu’au dernier. Quand celui-ci est plein, Oracle fait le tour et réutilise le premier puis le
second, etc…
Avant la réutilisation d’un fichier redolog, Oracle sauvegarde celui-ci ailleurs dans le
cas où la base tourne avec le mode d’archivage.
c. Les fichiers de contrôle
Les fichiers de contrôle permettent, lors de l’initialisation de la base, de savoir si la
base de données a été arrêtée correctement, ainsi qui de connaître l’emplacement des fichiers
de données et des fichiers redolog. Les fichiers de contrôle sont eux-même repérés par le
fichier d’initialisation. Le fichier de contrôle contient les informations suivantes :
- nom de la base de données,
- date et heure de création de la base
- l’emplacement des fichiers journaux (redolog)
- des informations de synchronisation.
DD
Rollback
segment
“SYSTEM”
Segment
Temporaire
Rollback
segment
Table T1
Table T2
Rollback
segment 1
Table T3
Table T4
Rollback
segment 1
Index I1 sur
table T1
Table T3
Tablespace Tablespace ‘TS1’ Tablespace ‘TS2’
47
3.5 NIVEAU PROCESSUS
Le fonctionnement de la base Oracle est régi par un certain nombre de processus
chargés en mémoire permettant d’assurer la gestion de la base de données.
On distingue généralement deux types de processus :
- Les processus utilisateurs (user process ou noyau Oracle)
Il y a deux types de processus utilisateurs :
o Oracles Server Code, aussi appelé noyau d’Oracle, est chargé d’interpréter et
d’exécuter les requêtes SQL, ainsi que de gérer la mémoire et les fichiers de
données.
o Code spécifique de l’outil, l’implémentation qui exécute réellement les
commandes SQL.
- Les processus systèmes (Oracle process)
Les processus Oracle (processus système) se classent en deux catégories :
o Les processus serveur (process server) gérant les requêtes des utilisateurs
provenant des connections à la base de données générées par des outils tels que
SQL*Plus. Le processus serveur est chargé de la communication entre la SGA
et le processus utilisateur. Il permet ainsi d’analyser et d’exécuter les requêtes
SQL des utilisateurs, de lire les fichiers de données et de placer les blocs de
données correspondants dans la SGA.
o Les processus d’arrière-plan (background process) chargé d’assurer le
fonctionnement interne du SGBD Oracle (gestion de la mémoire, écriture dans
les fichiers,…)
Les quatre principaux processus systèmes sont :
• DBWR : le processus chargé d’écrire le contenu des buffers dans les fichiers de données
• LGWR : le processus chargé d’écrire le contenu des buffers dans les fichiers redolog
• PMON : le processus chargé de nettoyer les ressources, les verrous et les processus
utilisateurs non utilisés
• SMON : le processus chargé de vérifier la cohérence de la base de données et
éventuellement sa restauration lors du démarrage si besoin.
Il existe également d’autres processus d’importation secondaire :
• CKPT : le processus chargé d’écrire le contenu des buffers dans les fichiers de données
48
• RECO : il s’agit d’un processus optionnel permettant de résoudre les transactions
interrompues brutalement dans un système de base de données distribuée (ex : un système
de réplication de base de données)
• ARCH : (optionnel) ce processus n’existe qu’un mode ARCHIVELOG. Il permet de
dupliquer les fichiers redolog dans n espace d’archivage.
• Dnnnn : (optionnel) ce processus permet de router les requêtes des postes Clients-Serveurs
distantes vers les autres serveurs. Il existe au moins un processus Dnnnn pour chaque
protocole de communication.
• Snnnn : ce processus permet de recevoir les demandes de connexions distantes envoyées
par le processus Dnnnn d’un serveur distant.
• LCKn est un processus de verrouillage utilisé lorsque Oracle Parallel Server est installé.
3.6 NIVEAU MEMOIRE
Oracle fait un usage poussé de la mémoire physique (RAM) du serveur afin de fournir
les meilleures performances possibles. Ainsi Oracle utilise la mémoire physique du serveur
pour :
- Accélérer l’accès aux données de la base régulièrement accédées
- Mettre les processus en mémoire
- Optimiser la communication entre les processus et la base de données
Lorsqu’une base de données Oracle est en activité, il y a utilisation de quatre types de zones
mémoires
• Une zone mémoire contenant l’exécutable du noyau et des outils Oracle en cours
d’utilisation et des applications des utilisateurs
• La zone SGA (System Global Area) assurant le partage des données des différents
utilisateurs, c’est à dire qu’il s’agit de la zone contenant les structures de données
accessibles par tous les processus.
• La zone PGA (Program Global Area) permettant le fonctionnement de divers
processus (afin de stocker toutes les données ne nécessitant pas d’être partagées)
• Une zone mémoire pour chaque ordre SQL.
49
ANNEXE B. UTILISATEURS D’ORACLE
Oracle distingue trois catégories d’utilisateurs :
- les utilisateurs du type CONNECT qui ont les privilèges suivants :
! se connecter à la base et changer leur mot de passe
! se manipuler les objets de la base pour lesquels ils ont préalablement le droit de
manipulation
! transmettre des autorisations sur des objets s’ils ont le droit de retransmettre
! créer des vues, des synonymes et des “Database links” sur les objets autorisés
! effectuer un export de leurs propres vues
- les utilisateurs du type RESOURCE qui en plus de ceux du type CONNECT
ont les privilèges suivants :
! créer des tables, des index, des clusters et des séquences
! « auditer » l’accès à leurs objets
! donner des autorisations de manipulation de leurs propres objets à d’autres
utilisateurs
- les utilisateurs de type DBA qui peuvent tout faire, et en particulier :
! créer des utilisateurs
! accéder à tous les objets de la base
! créer des tablespaces et des Rollback segments
! créer des synonymes pour le public
! effectuer toutes les opérations de maintenance de toute la base, ajouter ou
supprimer des fichiers ou redolog,…
BIBLIOGRAPHIE
1. Cours de Téléinformatique, 5e Année, Département Electronique, ESPA,
année universitaire 2000-2001.
2. J. FRUITET, « Bases de Données »,
http://massena.univ-mlv.fr/~jf/POLY/PolyBD.pdf, septembre 1997.
3. Y. BOURDA, « Systèmes de Gestion de Bases de Données Relationnels et Le Langage
SQL », http://wwwsi.supelec.fr/~yb/poly_bd/SGBDR_et_langage_SQL .pdf,
juillet 2000.
4. J. F. PILLOU, « Introduction aux Bases de Données »,
http://www.commentcamarche.net/bdd/bddintro.htm, mai 2000.
5. C. DELOBE, M. ADIBA, « Bases de données et systèmes relationnels »,
Dunod, Paris, 1982.
6. J. CHEINEY, P. PICOUET, J. M. SAGLIO, « Système de gestion de base de
données », http://www.bd.enst.fr/dombd.html, septembre 1998.
7. Cours de Génie Logiciel I, 4e Année, Département Electronique, ESPA, année
universitaire 1999-2000.
8. Données encyclopédiques, « Les bases de données », Hachette Multimédia,
http://fr.encyclopedia.yahoo.com/articles/kh/kh_233_p0.html, 2001.
9. Skill Builder Courseware, « Oracle SQL », National Education Training Group. Inc,
Version 11, 2000.
10. C. CROCHEPEYRE, « Les bases de données relationnelles »,
http://lion.cnam.fr/Cours/an98/IIA8/BD40.pdf , 1997.
11. A. FAUVEAU , « SQL pour MySql & Php3 »,
http://www.mysql.com/documentation/mysql/sql.htm, 2000.
12. O. DAHAN, « Normalisation des Bases de données et SQL »,
http://www.developpez.com/sgbd/Le_Relationnel.show.pdf, 1998.
13. RAZAFIARSON S., « Réalisation d’un logiciel de gestion de la bibliothèque
universitaire de l’ESPA », Mémoire de Fin d’Etudes, Département Télécommunication,
ESPA., 1999.
14. J. RONDEUX, F. LERUTH, F. GHYSEL, « Guide d’utilisation de la base de méta-
données METATER »,
http://lepur03.geo.ulg.ac.be/Download/Guide_Metater_10_2001.pdf, octobre 2001.
15. RAVELONJATO H. O., « Recensement et valorisation de l’information technique
et pédagogique au CFSIGE », DESS Outils, CFSIGE, 2001.
16. J. DENEGRE, F. SALGE, « Les systèmes d'information géographique », Que sais-
je? n°3122, Octobre 1996.
17. AEGIR, « Comprenez les bases de données»,
http://www.linuxfrench.net/article.php3, octobre 2001.
18. H. SMINE, « ORACLE, Architecture, Administration et Optimisation », 2e édition,
Eyrolles, Paris, 1992.
19. Oracle Corporation, « Oracle8 Concepts », Oracle Parkway, Redwood City, 1998.
20. D. AUSTIN, « Using Oracle8 »,
http://gmaster.users.ch/DocTech/DBSQL/Using_Oracle8.pdf, septembre 2000.
21. A. ABDELLATIF, J. Le BIHAN, M. LIMAME, « ORACLE, Le système de gestion
de bases de données relationnel », Eyrolles, Paris, 1990.
22. R. GRIN, « Langage SQL »,
http://deptinfo.unice.fr/~grin/messupports/sql_cours.pdf , mars 1999.
23. J. F. PILLOU, « Langage PL/SQL, Introduction»,
http://www.commentcamarche.com/plsql/plsqlintro.php3, 2001.
24. Oracle Corporation, « Oracle Developer Server Release 6.0 Doc », Oracle Parkway,
Redwood City, 1999.s
Auteurs :
- Mlle RAKOTOSOA Solo Mandimbihery!
- M. ANJARANANTENAINA Zava Falimanana"
Titre : IMPLEMENTATION DE « ESPA-DB »
LA BD-R DE L’ESPA
Nombre de pages : 49
Nombre de figures : 28
RESUME
Les bases de données et les systèmes de gestion de base de données sont
devenus incontournables en informatique puisqu’ils facilitent l’accès aux informations
en un temps opportun.
L’objectif du travail impliqué dans ce rapport est donc d’implémenter la base de
données de l’ESPA. Cette base contient deux entités, l’entité « Etudiant » et l’entité
« Département ». Elle sert d’une part à l’administration pour la mise à jour des données-
étudiants et d’autre part à l’enseignant ou étudiant comme outil d’informations.
Cette base de données a été créée suivant le modèle relationnel le modèle le plus
utilisé parmi ceux qui existent, et pour la gérer, le système de gestion de base de
données Oracle a été utilisé.
Mots clés : Base de Données, Modèle Relationnel, Système de Gestion de Base de
Données, Oracle, SQL, PL/SQL
Rapporteur : Mme RABEHERIMANANA Lyliane Irène
Adresse des auteurs :
- !Logement 44 cité Ampefiloha Antananarivo (101)
- "A.AM 191 Ambatofotsy Antananarivo (102)