Cours4 Base de Données

Université de Bordj Bou Arréridj
Faculté des Mathématiques et d'Informatique
Cours
Bases de données relationnelles et réparties :

avec étude de cas
Par
Dr. Bouziane Abderraouf
SOMMAIRE
Partie I : Bases de données relationnelles

Chapitre I : Introduction aux Bases de Données ................................................1
chapitre II: Modèles de données ..........................................................................6
chapitre III: Les dépendances fonctionnelles et les formes normales ................24
chapitre IV: Les opérateurs relationnels ....... .....................................................29
chapitre V: Le langage SQL ....... .......................................................................35
Partie II : Bases de donnée réparties

chapitre VI: CORBA .........................................................................................80
chapitre VII: CORBA et les bases de données ..................................................87
Partie III : Etude de cas : La GMAO répartie

chapitre VIII: La GMAO répartie.......................................................................97
chapitre IX: GMAO* net, un LMD réparti orienté objet ................................119
Préface :
Ce cours couvre les chapitres de la matière Bases de données du 2eme

semestre de la 2eme année licence en Informatique et traite une partie de la
matière Bases de données répartie du Master 1 Réseaux et Multimédia.
Ainsi, il est destiné en premier lieu aux étudiants de la deuxième année

Informatique et constitue pour les étudiants de Master une concrétisation des
notions théoriques à travers l’étude de cas d’un système de gestion de
maintenance assistées par ordinateur (GMAO) répartie.
Ce cours récapitule mon expérience d’enseignement de cette matière depuis

l’année 2005 et présente le système de GMAO réparti que j’ai développé en
2003.
Le cours est enrichi des examens et des TD que j’espère permettrons aux
étudiants de mieux assimiler les notions théoriques développées dans ce cours.
Bonne lecture
Abderraouf Bouziane
Partie I :
Bases de données relationnelles
PARTIE I; Bases de données relationnelles Bouziane abderraouf
CHAPITRE I : Introduction aux Bases de Données
1. Introduction
Le stockage des données d’une entreprise joue un rôle capital dans son efficacité générale.
Avant l’avènement de l’informatique, les données étaient conservées dans un système
d’archivage manuel (classeurs…). Une organisation a besoin de conserver de larges volumes
de données, en particulier des données historiques.
2. Archivage manuel
Chaque tiroir d’un classeur contient des fichiers dans lesquels sont rangés différents types de
données. Ces fichiers sont généralement classés par ordre alphabétique ou numérique.
Les inconvénients associés aux systèmes d’archivage manuels sont les suivants :
 Enclins aux erreurs.

 Difficulté de partage des données
 Fichiers facilement endommagés, perdus ou mal rangés
 Manque de sécurité
 Redondance des données
 Lenteur de l’accès et de la mise à jour.
3. Archivage informatisé
Dans un tel système, les informations sont conservées dans un fichier composé d’un ensemble
d’enregistrements (une ligne). Chaque enregistrement est composée de plusieurs champs
(une colonne).
L’utilisation de fichiers impose d'une part, à l'utilisateur de connaître l'organisation

(séquentielle, indexée, ...) des fichiers qu'il utilise afin de pouvoir accéder aux informations
dont il a besoin et, d'autre part, d'écrire des programmes pour pouvoir effectivement
manipuler ces informations. Pour des applications nouvelles, l'utilisateur devra
obligatoirement écrire de nouveaux programmes et il pourra être amené à créer de nouveaux
fichiers qui contiendront peut-être des informations déjà présentes dans d'autres fichiers.
De telles applications sont :
 rigides,
 contraignantes,
 longues et coûteuses à mettre en oeuvre.
Les données associées sont :
 mal définies et mal désignées,

 redondantes,
 peu accessibles de manière ponctuelle,
 peu fiables.
1
Les systèmes de fichiers informatisés ont un certain nombre de problèmes en commun avec
les systèmes manuels :
1. Redondance des données : La duplication des données identiques dans différents

endroits rend leur mise à jour très difficile où chaque modification doit être répercutée
sur toutes les occurrences de l'objet concerné. Par exemple, le changement de l'adresse
d'un étudiant doit être effectué aussi bien au service des bourses qu'à la scolarité, etc.
Les effets de la redondance :

 Les coûts de stockage sont augmentés.
 De multiples mises à jour doivent être effectuées pour actualiser les différents
fichiers.
 Peut mener à une incohérence des données.
 Rend les normes difficiles à appliquer
2. Incohérences des données : La gestion des liens sémantiques qui existent entre les
données est d'une importance capitale. Par exemple dans la cas de la gestion des
stocks, la quantité réceptionnée d'un article donnée doit être toujours inférieure ou
égale à la quantité commandée. Des incohérences peuvent facilement apparaître si ces
"contraintes d'intégrité" liant les données entre elles ne seraient pas prise en
considération.
3. Problèmes de sécurité : Assurer la sécurité des données est un point très important
aussi. En plus da la sécurité physique de l'information, il faut définir une politique de
reprise après panne (le cas où, par exemple, une panne interrompt un programme
manipulant les données) etc.
4. Dépendance des données : dans un système de fichiers, les données dépendent des
applications qui les utilisent.
6. Partage limité des données : Dans un système de fichiers, chaque application possède
ses propres données enregistrées dans des fichiers séparés, ce qui rend le partage de
données difficiles.
4. Systèmes de base de données
Dans un système de base de données les données sont indépendantes des applications. Elles
peuvent plus facilement (que précédemment) être modifiées et mises à jour, sans demander
aux programmeurs d’effectuer des travaux supplémentaires de maintenance. Il est possible de
réduire la redondance en obligeant les applications à partager les données, au lieu de
conserver chacune sa propre copie.
Définition :
Une base de données est un ensemble de données à la fois intégré et partagé conçu pour
répondre aux besoins de plusieurs utilisateurs dans une entreprise.
Un environnement de base de données se compose de quatre éléments :
a) Données : les données d’une base de données sont à la fois intégrées et partagées.
2
L’intégration des données indique que la base de données est composée de données
reliées entre elles au lieu de fichiers de données séparés pour chaque application, ce
qui permet d’éviter les redondances.
Comme les données sont partagées, toutes les applications accèdent aux mêmes
données dans la base.
Les bases de données doivent permettre un partage concourant (contribuant

participant,…) de l’information. Le partage concourant signifie que plusieurs
utilisateurs peuvent accéder en même temps aux données.
b) Utilisateurs : ils peuvent être divisés en trois catégories générales.
Développeurs d’applications : Ils développent les programmes d’application se

chargent de traiter les données de la base
Utilisateurs finals : Ils dialoguent avec la base de données au moyen de programmes
d’application.
Administrateurs de base de données : Ils coordonnent les activités de tous les
utilisateurs de la base de données et possèdent aussi le contrôle de celle-ci
c) Matériel : une base de données peut être exploitée sur un ordinateur conventionnel
(gros sys, mini, pc). Elle peut être aussi exploitée sur un serveur de base de données
dédiée.
d) Logiciels : le logiciel de contrôle de base de données est appelé SGBD. Système de

Gestion de Bases de Données.
Le SGBD sert de couche intermédiaire entre les données physiques mémorisées sur
les périphériques de stockage et les programmes utilisateur.
Le SGBD permet de créer, de gérer et d’accéder à la base de données.
Tous les accès à la base de données se font par le SGBD.

Le SGBD permet également de s’assurer que les données sont définies conformément
à certaines normes. Ces normes sont implantées en utilisant un dictionnaire de
données.
Plus formellement, un SGBD doit permettre d'atteindre les objectifs suivants :
4.1. Offrir différents niveaux d'abstraction
Niveau physique :
C'est le niveau le plus bas des données où est géré le stockage et l'accès aux
données.
Niveau logique:
Il est appelé également le niveau conceptuel. A ce niveau on parle de modèle

conceptuel de données où on y décrit l'ensemble des données du champs de
l'étude.
3
Niveau externe :
A ce niveau, seulement une vue partielle de l'ensemble des données est

autorisée à un utilisateur ou à un groupe d'utilisateurs. Cette vue correspond
aux données qui intéressent leur service. Il peut y avoir plusieurs vues d'une
même base de données.
4.2. Assurer l'indépendance physique des données
Détacher l'utilisateur du niveau conceptuel des détails de la structure du niveau

physique permet aux programmeurs d'écrire des applications simples en ignorant, par
exemple, les détails des structures d'enregistrement, méthodes d'accès, etc. Ainsi, ces
applications ne seront pas réécrites dans le cas d'une modification des caractéristiques
du niveau physique.
4.3. Contrôler la redondance des données
La suppression de la redondance des données permet de maintenir la cohérence de

l'information et de minimiser les mises à jour. Cependant, la redondance est parfois
nécessaire pour assurer la disponibilité des données augmenter les performances des
application notamment dans le cas des données qui sont réparties sur plusieurs sites
reliés par un réseau.
4.4. Permettre à tout type d'utilisateur de manipuler des données
Les utilisateurs d'une base de données ont des rôles et besoins différents suivant la
nature de leurs tâches. Parmi lesquels, on distingue, les administrateurs, les
développeurs d'application et les utilisateurs finals. Ainsi, on doit offrir à ces
différents d'utilisateurs des moyens d'accès adaptés à leurs besoins.
4.5. Assurer l'intégrité des données
Confier la tâche de vérification de l'intégrité logique de l'information aux développeurs

d'applications rend leur tâche encore plus difficile et peut engendrer, dans certains cas,
des incohérence de l'information dans la cas où le développeur ne connait pas la
structure logique de la base de données ou simplement s'il oublie les règles qui relient
4
les données entre elles. Ainsi, pour garantir la fiabilité des données, l'ensemble des
contraintes d'intégrité doivent être gérées par le SGBD.
4.6. Assurer la sécurité des données
Un SGBD doit garantir la disponibilité des données en particulier après la survenue

d'une panne. Il doit aussi protéger les données contre les accès non autorisées en
offrant des outils de vérification des droits d'accès à la base.
4.8. Optimiser l'accès aux données
Le schéma interne de la base de données étant géré par le SGBD. Ce dernier doit
optimiser l'accès aux donnée en utilisant les meilleurs chemins d'accès et en supportant
l'accès simultané aux objets de la base de données. Cela dans le but de minimiser le
temps d'exécution des requêtes.
5
CHAPITRE II : Modèles de données
1. Introduction
Une base de données est un ensemble de connaissances sur un domaine d’application

particulier. Les propriétés et les relations sémantiques entre ces données peuvent être
représentées en utilisant les concepts proposés par un modèle de données sous-jacent.
2. Modèle de données
Un modèle de données est une représentation abstraite des données et des relations qui les
unissent. Il permet de simplifier la complexité du domaine réel en offrant différents points de
vue et des niveaux d'abstractions personnalisés.
Pour un cas d'étude donné, il peut y avoir plusieurs modèles. Le modèle le plus adéquat est
celui qui permet de saisir les aspects nécessaires et négliger les autres en fonction du but
recherché. Ainsi, il permet de délimiter le champs de l'étude aux entités et aux interactions qui
concernent la situation donnée.
Parmi les modèles de données existant, il y a le modèle relationnel, le modèle hiérarchique,

le modèle réseau, etc. Dans la suite de ce cours, nous allons étudier le modèle relationnel dans
le détail. Pour éliminer les risque d'ambiguïté du langage naturel, nous allons utilisé un
langage graphique qui est le schéma entités-associations qui permet, en plus, un passage facile
vers le modèle relationnel.
3. Schéma entités-associations1
3.1 Entités et associations
Une entité est une population d’individus homogènes. Par exemple, les produits ou les articles
vendus par une entreprise peuvent être regroupés dans une même entité articles (figure 1), car
d’un articles à l’autre, les informations ne changent pas de nature (à chaque fois, il s’agit de la
désignation, du prix unitaire, etc.).
Clients Articles Fournisseurs
Figure 1 : Entités
Par contre, les articles et les clients ne peuvent pas être regroupés : leurs informations ne sont
pas homogènes (un article ne possède pas d’adresse et un client ne possède pas de prix
unitaire). Il faut donc leur réserver deux entités distinctes : l’entité articles et l’entité clients.
1
De la page 6 jusqu'à la page 18, extrait de : http://cyril-gruau.developpez.com/merise/
6
Une association est une liaison qui a une signification précise entre plusieurs entités. Dans
notre exemple, l’association acheter est une liaison évidente entre les entités articles et clients,
tandis que l’association livrer établit le lien sémantique entre les entités articles et
fournisseurs.

Commander Livrer
Figure 2 : Associations
Remarquons que dans ce schéma, les entités clients et fournisseurs ne sont pas liées
directement, mais indirectement, via l’entité articles, ce qui est assez naturel.
3.2 Attributs et identifiants

Commander Livrer
Num_client Num_article Num_fourniseur
Nom client Quantité Désignation Qt livrée Nom
commandée Date de
Prénom Prix de vente livraison Tel
Date de
Adresse Nom livreur
commande
Figure 3 : Attributs
Un attribut est une propriété d’une entité ou d’une association. Toujours dans notre exemple
(figure 3), le prix unitaire est un attribut de l’entité articles, le nom de famille est un attribut
de l’entité clients, la quantité commandée est un attribut de l’association acheter et la date de
livraison est un attribut de l’association livrer.
Une entité et ses attributs ne doivent traiter que d’un seul sujet afin d’assurer une certaine
cohérence au modèle. Dans notre exemple, il est donc préférable de ne pas mettre les
informations relatives aux fournisseurs dans l’entité des articles mais plutôt dans une entité
fournisseurs séparées (et liée à l’entité articles via l’association livrer).
Ensuite, chaque individu d’une entité doit être identifiable de manière unique. C’est pourquoi
toutes les entités doivent posséder un attribut sans doublon (c’est-à-dire ne prenant pas deux
fois la même valeur). Il s’agit de l’identifiant que l’on souligne sur le schéma, par convention.
Le numéro de client constitue un identifiant classique pour l’entité clients (figure 4).
Remarques :
– une entité possède au moins un attribut (son identifiant) ;

– une association peut ne pas posséder d’attribut.
3.3 Cardinalités
La cardinalité d’un lien entre une entité et une association précise le minimum et le maximum
de fois qu’un individu de l’entité peut être concerné par l’association.
Exemple : un client a au moins acheté un article et peut acheter n articles (n étant

indéterminé), tandis qu’un article peut avoir été acheté entre 0 et n fois (même si ce n’est pas
le même n que précédemment). On obtient alors le schéma entités-associations complet
(figure 5).
Une cardinalité minimale de 1 doit se justifier par le fait que les individus de l’entité en
question ont besoin de l’association pour exister (un client n’existe pas avant d’avoir acheté
quoique ce soit, donc la cardinalité minimale de l’entité clients dans l’association acheter est
1). Dans tous les autres cas, la cardinalité minimale vaut 0 (c’est le cas pour une liste pré-
établie d’articles par exemple).
Ceci dit, la discussion autour d’une cardinalité minimale 0 ou 1 n’est vraiment intéressante
que lorsque la cardinalité maximale est 1. Nous verrons en effet lors de la traduction vers un
schéma relationnel, que lorsque la cardinalité maximale est n, nous ne pouvons pas faire la
différence entre une cardinalité minimale de 0 et une cardinalité minimale de 1.
.
Notons que sur notre exemple, un article peut être acheté par plusieurs clients. Cela provient
du fait que tous les crayons rouges ne sont pas numérotés individuellement, mais portent un
numéro d’article collectif. En toute rigueur, notre entité articles aurait s’appeler types
d’article. Ainsi, un crayon rouge peut être acheté par plusieurs clients, ce n’est simplement
8
pas le même crayon à chaque fois. Il s’agit d’un choix de modélisation, vous pouvez très
légitimement faire le choix inverse qui consiste à numéroter individuellement chaque crayon
rouge.
La seule difficulté pour établir correctement les cardinalités est de se poser les questions dans
le bon sens. Autour de l’association commander, par exemple :
– côté clients, la question est « un client peut commander combien d’articles? « et la réponse
est « entre 1 et plusieurs » » ;
– côté articles, la question est « un article peut être commandé par combien de client? « et
cette fois-ci, la réponse est « entre 0 et plusieurs ».
3.4 Associations plurielles
Deux mêmes entités peuvent être plusieurs fois en association (c’est le cas sur la figure 6).
Dans cet exemple issu d’une agence immobilière, une personne peut être propriétaire, résider
principalement ou résider secondairement dans un logement géré par l’agence.
Les logements qui ne sont pas gérés par l’agence ne figurent pas dans l’entité des logements,
ce qui explique certaines cardinalités 0 du schéma. Nous supposons également qu’un
logement n’est détenu que par une seule personne et que ce propriétaire figure
obligatoirement dans l’entité des personnes.
3.5 Association réflexive
Il est permis à une association d’être branchée plusieurs fois à la même entité, comme par
exemple l’association binaire réflexive de la figure 7.
Dans cet exemple, tout employé est dirigé par un autre employé (sauf le directeur général) et
un employé peut diriger plusieurs autres employés, ce qui explique les cardinalités sur le
schéma.
9
3.6 Associations non binaires
Lorsque autour d’une entité, toutes les associations ont pour cardinalités maximales 1 au
centre et n à l’extérieur, cette entité peut être remplacée par une association branchée à toutes
les entités voisines avec des cardinalités identiques 0,n. Cette règle conduit parfois à
l’apparition d’associations qui établissent un lien sémantique entre 3 entités ou plus.
Sur l’exemple de la figure 8 issu d’un cinéma, l’entité projections est uniquement entourée
d’associations dont les cardinalités maximales sont 1 côté projections et n de l’autre côté. On
peut donc la remplacer par une association projeter branchée aux trois entités salles, créneaux
horaires et films. On parle alors d’association ternaire.
10
La difficulté de concevoir une association ternaire (ou plus) directement est d’établir les
bonnes cardinalités. Il est donc conseillé d’en passer par un schéma entités-associations dans
lequel on ne trouve que des associations binaires, puis de repérer les entités remplaçables par
des associations, comme sur la figure 8 à gauche. Cette règle de conduite permet d’éviter
d’introduire une association ternaire abusive, par exemple entre les avions, les pilotes et les
vols (figure 9), car le concepteur peut s’apercevoir que l’une des cardinalités maximales ne
convient pas.
11
Par ailleurs, une association peut être branchée à plus de trois entités, comme sur la figure 10.
Là encore, le conseil pour être sûr de la légitimité de cette association 4-aire, est de vérifier les
cardinalités sur un schéma intermédiaire faisant apparaître à la place, une entité occupations et
quatre associations binaires.
12
4. Règles de normalisation
1) Normalisation des entités (importante) : toutes les entités qui sont remplaçables par une
association doivent être remplacées (comme sur la figure 8).
2) Normalisation des noms :
Le nom d’une entité, d’une association ou d’un attribut doit être unique.
Conseils :
– pour les entités, utiliser un nom commun au pluriel (par exemple : clients) ;
– pour les associations, utiliser un verbe à l’infinitif (par exemple : effectuer, concerner)
éventuellement à la forme passive (être acheté) et accompagné d’un adverbe (avoir lieu dans,
pendant, à) ;
– pour les attributs, utiliser un nom commun singulier (par exemple : nom, numéro, libellé,
description) éventuellement accompagné du nom de l’entité ou de l’association dans laquelle
il se trouve (par exemple : nom de client, numéro d’article).
Remarque : lorsqu’il reste plusieurs fois le même nom, c’est parfois symptomatique d’une
modélisation qui n’est pas terminée (figure 11(a)) ou le signe d’une redondance (figure
11(b)).
13
3) Normalisation des identifiants :
Chaque entité doit posséder un identifiant.
Conseils :
– éviter les identifiants composés de plusieurs attributs (comme par exemple un identifiant
formé par les attributs nom et prénom), car d’une part c’est mauvais pour les performances et
d’autres part, l’unicité supposée par une telle démarche finit tôt ou tard par être démentie ;
– préférer un identifiant court pour rendre la recherche la plus rapide possible (éviter
notamment les chaînes de caractères comme un numéro de plaque d’immatriculation, un
numéro de sécurité sociale ou un code postal) ;
– éviter également les identifiants susceptibles de changer au cours du temps (comme les
plaques d’immatriculation ou les numéros de sécurité sociale provisoires).
Conclusion : l’identifiant sur un schéma entités-associations (et donc la future clé primaire
dans le schéma relationnel) doit être un entier, de préférence incrémenté automatiquement.
4) Normalisation des attributs (importante) :
Remplacer les attributs en plusieurs exemplaires en une association supplémentaire de

cardinalités maximales n et ne pas ajouter d’attribut calculable à partir d’autres attributs.
En effet, d’une part, les attributs en plusieurs exemplaires posent des problèmes d’évolutivité
du modèle (sur la figure 12(a) à gauche, comment faire si un employé a deux adresses
secondaires ?) et d’autre part, les attributs calculables induisent un risque d’incohérence entre
les valeurs des attributs de base et celles des attributs calculés, comme sur la figure 12(b).
D’autres d’attributs calculables classiques sont à éviter, comme l’ˆage (qui est calculable à
partir de la date de naissance) ou encore la wilaya (calculable à partir d’une sous-chaîne du
code postal).
14
5) Normalisation des attributs des associations (importante) :
Les attributs d’une association doivent dépendre directement des identifiants de toutes les
entités en association. Par exemple, sur la figure 5 la quantité commandée dépend à la fois du
numéro de client et du numéro d’article, par contre la date de commande non. Il faut donc
faire une entité commandes à part, idem pour les livraisons (figure 13).
15
L’inconvénient de cette règle de normalisation est qu’elle est difficile à appliquer pour les
associations qui ne possèdent pas d’attribut. Pour vérifier malgré tout qu’une association sans
attribut est bien normalisée, on peut donner temporairement à cette association un attribut
imaginaire (mais pertinent) qui permet de vérifier la règle. Par exemple, entre les entités livres
et auteurs de la figure 16, l’association écrire ne possède pas d’attribut. Imaginons que nous
ajoutions un attribut pourcentage qui contient le pourcentage du livre écrit par chaque auteur
(du même livre). Comme cet attribut pourcentage dépend à la fois du numéro de livre et du
numéro d’auteur, l’association écrire est bien normalisée. Autre conséquence de la
normalisation des attributs des associations : une entité avec une cardinalité de 1,1 ou 0,1
aspire les attributs de l’association (figure 14).
6) Normalisation des associations (importante) :
Il faut éliminer les associations fantômes (figure 15(a)), redondantes (figure 15(b)) ou en
plusieurs exemplaires (figure 15(c))
16
17
En ce qui concerne les associations redondantes, cela signifie que s’il existe deux chemins
pour se rendre d’une entité à une autre, alors ils doivent avoir deux significations ou deux
durées de vie différentes. Sinon, il faut supprimer le chemin le plus court, car il est déductible
à partir de l’autre chemin. Dans notre exemple de la figure 15(b), si on supprime l’association
payer, on peut retrouver le client qui a payé le règlement en passant par la facture qui
correspond.
Remarque : une autre solution pour le problème de la figure 15(b) consiste à retirer l’entité
règlements et d’ajouter une association régler avec les mêmes attributs (sauf l’identifiant)
entre les entités clients et factures.
7) Normalisation des cardinalités :
Une cardinalité minimale est toujours 0 ou 1 (et pas 2, 3 ou n) et une cardinalité maximale est
toujours 1 ou n (et pas 2, 3, ...). Cela signifie que si une cardinalité maximale est connue et
vaut 2, 3 ou plus (comme sur la figure 15(c) à droite, ou pour un nombre limité d’emprunts
dans une bibliothèque), alors nous considérons quand même qu’elle est indéterminée et vaut
n. Cela se justifie par le fait que même si nous connaissons n au moment de la conception, il
se peut que cette valeur évolue au cours du temps. Il vaut donc mieux considérer n comme
une inconnue dès le départ.
Cela signifie également qu’on ne modélise pas les cardinalités minimales qui valent plus de 1
car ce genre de valeur est aussi amené à évoluer. Par ailleurs, avec une cardinalité maximale
de 0, l’association n’aurait aucune signification.
18
5. Le modèle relationnel
5.1. Introduction
L'objectif clé de la conception relationnelle est de développer et de supporter un schéma

de base de données qui pourra facilement évoluer au fil du temps en fonction des besoin
de l'organisation.
Le modèle relationnel de gestion de base de données a été proposé par E F Codd en 1970. Les
bases de données relationnelles s'appuient sur des modèles mathématiques : la théorie des
ensembles qui repose sur l'utilisation d'un ensemble d'opérateurs formels sur les relations. Les
opérations relationnelles (union, intersection, projection, etc.) permettent de générer de
nouvelles relations (tables) à partir d'opérations élémentaires sur d'autres tables.
La théorie des ensembles met en oeuvre deux notions:

 La notion de domaine
 La notion de produit cartésien
5.1.1. La notion de domaine
Un domaine est un ensemble fini ou infini de valeurs qui peut être représenté par
l'énumération de ces éléments ou bien par une condition nécessaire et suffisante
d'appartenance :
 le domaine des booléens: {0,1}

 le domaine des valeurs entières paires.
 etc.
5.1.2. La notion de produit cartésien
Le produit cartésien d'un ensemble de domaines Di, noté D1*D2*D3*...*Dn , est l'ensemble des
n-uplets (appelés aussi tuples) <V1,V2,...,Vn> tels que Vi appartient à Di
5.2. La modélisation relationnelle
Le but est de représenter les relations à l'aide de tables (à deux dimensions) dont chaque
colonne a un nom qui représente un domaine. Une ligne du tableau représente donc une
occurrence.
On appelle attribut le nom des colonnes (domaine). On appelle tuple (ou n-uplet) une ligne de
la table (une occurrence).
L'utilisation des attributs pour décrire une relation est appelé schéma d'une relation. Par
exemple, l'entité Fournisseurs pourra par exemple être représentée par le schéma de la relation
suivante :
 Fournisseurs (Le code fournisseur ; raison sociale ; pays).
qui peut avoir les tuples (occurrences) suivants :
19
Ainsi, le schéma d'une base de données relationnelle est l'ensemble des relations qui la
composent.
5.3. Les avantages du modèle relationnel
Les bases de données relationnelles sont plus efficaces que les bases de données non
relationnelles pour les raisons suivantes :
1. structures simples s’accompagnant des règles simples : il est plus facile de représenter
les données sous formes de table à deux dimensions que sous forme de structures
hiérarchique ou en réseau par exemple.
2. facile à restructurer : il est possible de modifier le format d’attributs existants et
d’ajouter d’autres attributs aux relation sans grande difficulté.
3. langage d’interrogation simple et puissant.
4. bases théoriques bien fondées (une théorie mathématique)
5. plus grandes indépendances des données.
6. lignes logiquement liées.
5.4. Les principes relationnels
1. l'ordre des attributs des tuples n’est pas significatif.

2. un tuple ne doit pas être dupliqué dans une relation, cela signifie que chaque ligne
d’une table doit être unique, deux lignes ne doivent jamais comporter des données
identiques dans toutes leurs colonnes.
3. chaque attribut d’une relation doit avoir un nom unique.
4. il ne doit y avoir qu’une seule valeur pour chaque attribut d’un tuple.
5. chaque valeur doit être atomique.
6. s’il manque un élément de données ou que la valeur de celui-ci ne convient pas,
l’attribut correspondant contiendra alors la valeur nulle.
7. une ligne doit toujours contenir au moins une valeur, mais les colonnes individuelles
peuvent être vides.
8. un élément de données peut être obligatoire, au quel cas une valeur doit être insérée.
Lorsque un élément de données est obligatoire, on dit qu’il n’est pas nul (is not nul)
Le domaine
7. la valeur d’un attribut vient d’un domaine, un domaine est un ensemble de valeurs
atomiques, le terme atomique signifie que les valeurs ne peuvent être décomposées.
Les clés
8. un attribut (ou un ensemble d’attributs possédant des valeurs distinctes) utilisés

uniquement pour identifier des tuples est appelé clé ou identifiant.
20
9. une clé primaire est un ensemble d’attributs qui possèdent toujours un ensemble
valeurs uniques à chaque tuple.
10. une relation peut avoir plusieurs attributs susceptibles de servir de clés primaires, on
dit alors qu’il s’agit de clés candidates.
11. une clé primaires est celle choisit parmi les clés candidates pour servir d’identifiant
unique à la relation.
12. les lés candidates qui ne sont pas choisies pour servir de clés primaires sont appelées
clés secondaires ou alternatives.
13. aucun attribut d’une clé primaire ne doit avoir la valeur nulle.
14. il se peut qu’aucun attribut d’une relation ne soit unique, dans ce cas, la clé primaire
est formée d’une combinaison de plusieurs attributs.
15. une clé concaténé est une clé primaire contenant plus d’un attribut.
16. les relations entre les donnes dans un modèle relationnel sont représentées par des
pointeurs logiques
17. les relations entre deux tables sont représentées par des données communes aux deux
tables.
18. des fois pour représenter une relation entre deux table X et Y on copie la clé primaire
de X dans la table Y, dans ce cas on dit que la clé primaire de X est de devenue une
clé étrangère dans Y.
5.5. Evaluation du caractère relationnel d'un SGBD : les règles de Codd
En 1985 E.Codd a proposé un ensemble de douze règles permettant de déterminer

le caractère relationnel d’une BDD. Ces 12 règles constituent un modèle utile pour
évaluer le caractère relationnel d’un SGBD
Ces douze règles s’appuient sur la règle de base suivante :
0. une base de données véritablement relationnelle gère les données par ces capacités
relationnelles. En d’autres termes le SGBD ne doit pas se fier à des méthodes non
relationnelles pour gérer ses données.
1. les données ne peuvent être présentés que sous forme de tables à deux dimensions.
2. une donnée (valeur atomique) est accessible par la combinaison du nom
de la table, de la clé primaire et du nom de la colonne.
3. les valeurs nulles doivent être prises en charge pour représenter les valeurs
absentes.
4. il doit y avoir un dictionnaire de données que les utilisateurs pourront consulter au
moyen du même langage d’interrogation que pour les données normales.
5. il doit y avoir un sous langage pour la définition de données le contrôle
de manipulation et d’intégrité, la gestion des transactions et le contrôle d’accès.
6. le système doit être en mesure de mettre à jour les données qui, théoriquement,
peuvent l’être.
7. les opérations de haut niveau, comme les mises à jour, l’insertion et l’effacement
de données, doivent être possibles tout comme les opérations de recherche
de données.
8. le SGBD doit assurer l’indépendance physique des données.
9. le SGBD doit assurer l’indépendance logique des données.
10. les contraintes d’intégrités doivent être intégrés à la base plutôt qu’aux
applications.
11. un SGBD réparti doit posséder une indépendance répartie.
21
12. si un langage relationnel possède un langage de bas niveau, celui-ci ne peut être
utilisé pour contourner le langage de haut niveau.
5.6. Traduction d'un schéma entités/associations en un schéma relationnel 2
Pour traduire un schéma E/A en un schéma relationnel, il suffit d’appliquer cinq règles.
Notations : on dit qu’une association binaire (entre deux entités ou réflexive) est de type :
 1 : 1 (un à un) si aucune des deux cardinalités maximales n’est n ;

 1 : n (un à plusieurs) si une des deux cardinalités maximales est n ;
 n : m (plusieurs à plusieurs) si les deux cardinalités maximales sont n.
Règle 1 : toute entité devient une relation. Les attributs de l'entité deviennent les attributs de
la relation. L’identifiant de l’entité constitue alors la clé primaire de la relation.
Règle 2 : un association binaire de type 1 : n disparaît, au profit d’une clé étrangère dans la
relation côté 0,1 ou 1,1 qui référence la clé primaire de l’autre relation. Cette clé étrangère ne
peut pas recevoir la valeur vide si la cardinalité est 1,1.
Par exemple, l’association livrer de la figure 13 est traduite par :
Fournisseurs (n◦ fournisseur, nom contact, n◦ tèlèphone contact)

Livraisons (n◦ livraison, date de livraison, nom livreur, #n◦ fournisseur (non vide))
Il ne devrait pas y avoir d’attribut dans une association de type 1 : n, mais s’il en reste, alors
ils glissent vers la relation côté 1.
Règle 3 : une association binaire de type n : m devient une relation supplémentaire (parfois
appelée relation de jonction, relation de jointure ou relation d’association) dont la clé primaire
est composée de deux clés étrangères (qui référencent les deux clés primaires des deux
relation en association). Les attributs de l’association deviennent des attributs de cette
nouvelle relation.
Par exemple, l’association concerner(1) de la figure 13 est traduite par la relation

supplémentaire lignes de commande :
Lignes de commande (#n◦ commande, #n◦ article, quantité commandée)
Règle 4 : une association binaire de type 1 : 1 est traduite comme une association binaire de
type 1 : n sauf que la clé étrangère se voit imposer une contrainte d’unicité en plus d’une
éventuelle contrainte de non vacuité (cette contrainte d’unicité impose à la colonne
correspondante de ne prendre que des valeurs distinctes).
Si les associations fantômes ont été éliminées, il devrait y avoir au moins un côté de
cardinalité 0,1. C’est alors dans la table du côté opposé que doit aller la clé étrangère. Si les
deux côtés sont de cardinalité 0,1 alors la clé étrangère peut être placée indifféremment dans
l’une des deux relations.
En réalité, la règle 4 proposée ici considère qu’une association binaire de type 1 : 1

correspond à une association binaire de type 1 : n particulière.
2
extrait de : http://cyril-gruau.developpez.com/merise/
22
Remarque : d’autres techniques sont parfois proposées pour cette règle 4 (fusionner les
tables, utiliser une clé primaire identique, utiliser deux clés étrangères réflexives) mais elles
ne sont pas exploitables dans le cas général.
Règle 5 : une association non binaire est traduite par une relation supplémentaire dont la clé
primaire est composée d’autant de clés étrangères que d’entités en association. Les attributs
de l’association deviennent des attributs de cette nouvelle relation.
Par exemple, l’association projeter de la figure 8 devient la table :

Projections (#n◦ film, #n◦ salle, #n◦ cr èneau, tarif)
23
CHAPITRE III : Les dépendances fonctionnelles et les formes normales
1. Introduction
Afin de justifier l'utilisation des règles de bonne conception d'une base de données
relationnelle, nous allons étudier dans ce chapitre, à travers un fragment d'un exemple de
tenue de stock, deux choix d'organisation des informations sous forme relationnelle où nous
allons en montrer les qualités et les défauts.
1.1 Premier choix :
STOCK (no-pièce, description, étagère, unité, coût, quantité_stock, no_projet,

date_début, date_fin, quantité_sortie, date_sortie)
1.2. Deuxième choix :
ARTICLES (no-pièce, description, étagère, unité, coût, quantité_stock)
PROJETS (no_projet, date_début, date_fin)
SORTIES (no-pièce, no_projet, quantité_sortie, date_sortie)
Dans ce qui suit, nous allons voir des exemples des problèmes les plus courants rencontrés
dans des bases de données mal conçues et ce sur les deux choix d'organisation précédents :
1.3. Redondance des données
Dans la première organisation, une nouvelle insertion dans la base de données peut
entrainer des répétitions des données qui est souvent la cause d'anomalies.
Par exemple, dès qu'un article est utilisé par un projet, on doit non seulement répéter
son numéro qui, normalement, doit suffire à le déterminer, mais aussi toutes les
informations liées à ce numéro (description, étagère, unité, coût, quantité_stock , …).
Au contraire, dans le deuxième choix, seul le numéro indispensable à la distinction
d'un article est répété (la relation SORTIES).
1.4. Incohérence en modification
Une information répétée dans plusieurs endroits (redondance) peut entrainer des
risques d'incohérence en cas de modification car, souvent, on oublie de modifier toutes
ses occurrences.
Par exemple, dans la première organisation proposée, si un article est utilisé, il faut
changer la quantité en stock dans tous les tuples où apparaissent ses coordonnées.
Dans la deuxième organisation, un seul tuple est modifié.
24
1.5. Anomalie d'insertion
Dans le premier schéma proposé, créer une fiche (insérer) pour un nouveau article
impossible car, pour ce faire, on doit insérer aussi des valeurs pour un projet et une
sortie de stock, or que ces dernières informations ne sont pas nécessaires et, de plus,
ne sont pas disponibles.
1.6. Anomalie de suppression
La suppression d'une information particulière peut entrainer la suppression définitive

d'autres informations de la base de données.
Par exemple dans la première organisation, la suppression d'un article entraîne la

suppression de la trace de tous les projets qui n'ont utilisé que cet article.
2. La théorie de la normalisation
Les anomalies précédentes se sont produites parce que des informations qui sont
sémantiquement distinctes sont regroupées au sein d'un même schéma. La solution à ces
problèmes est de considérer les "dépendances fonctionnelles" qui traduisent les contraintes sur
les données (par exemple, on décide que deux projets différents peuvent avoir les mêmes date
de début et de fin mais jamais le même numéro no_projet).
A partir des dépendances fonctionnelles on définit un ensemble de formes normales qui

permettent de décomposer l'ensemble des informations en plusieurs relations. Ces formes
normales obéissent un structure hiérarchique où chaque étape de normalisation génère des
relations présentant de moins en moins de redondance.
Le point de départ de la normalisation de la base de données est la relation universelle qui

regroupe toutes les informations à stocker (le premier choix d'organisation représente la
relation universelle).
2.1. Les dépendances fonctionnelles
Un attribut Y dépend fonctionnellement d'un attribut X si, étant donné une valeur de X, il lui
correspond une unique valeur de Y, et on note : X  Y
Exemple :
La dépendance fonctionnelle no-pièce  description, signifie qu'à un numéro
d'un article est associé un nom. Il est à noter qu'une dépendance fonctionnelle
n'est pas obligatoirement symétrique, c'est-à-dire que no-pièce  description
n'interdit pas que deux articles différents (correspondant à deux no-pièce
distincts) peuvent avoir la même description.
Il faut noter aussi, qu'une dépendance fonctionnelle est une propriété définie sur tous les
tuples d'une relation et pas seulement sur un tuple particulier. Elle correspond à une contrainte
qui doit être vérifiée toujours. Dans notre exemple, les dépendances fonctionnelles qui
doivent être vérifiées sont les suivantes :
no-pièce  description, étagère, unité, coût, quantité_stock
no_projet  date_début, date_fin
no-pièce, no_projet  quantité_sortie, date_sortie)
25
2.1.1 Propriétés des dépendances fonctionnelles
Les dépendances fonctionnelles obéissent à certaines propriétés connues sous le nom

d'axiomes d'Armstrong.
Réflexivité :
YXXY
Augmentation :
X  Y  XZ  Y et/ou XZ  YZ
Transitivité :
X  Y et Y  Z  X  Z
D'autres propriétés se déduisent de ces axiomes :
Union :
X  Y et X  Z  X  YZ
Pseudo-transitivité :
X  Y et YW  Z  XW  Z
Décomposition :
X  Y et Z  Y  X  Z ou (X  YZ  X  Y et X  Z)
D'autre part, la notation X¬Y s'emploie pour indiquer q'un ensemble d'attributs X ne
détermine pas fonctionnellement un ensemble d'attributs Y.
En utilisant ces définitions, nous pouvons construire, à partir d'un premier ensemble de
dépendances fonctionnelles (dépendance fonctionnelle élémentaire), l'ensemble de toutes les
dépendances fonctionnelles qu'elles génèrent.
2.1.2. Dépendance fonctionnelle élémentaire
Une dépendance fonctionnelle X  A est élémentaire si
- A n'est pas inclus dans X ;

- il n'existe pas X' inclus dans X tel que X'  A.
Les dépendances fonctionnelles élémentaires constituent la couverture minimale (une famille

génératrice minimale) qui permet de générer les dépendances fonctionnelles utiles pour
structurer le schéma de la base de données.
26
2.1.3. Fermeture transitive
On appelle fermeture transitive d'un ensemble de dépendances fonctionnelles, ce même

ensemble enrichi de toutes les dépendances fonctionnelles déduites par transitivité.
2.1.4. Couverture minimale
On appelle couverture minimale d'un ensemble de dépendances fonctionnelles, un sous

ensemble minimum de dépendances fonctionnelles élémentaires permettant de générer toutes
les autres. IL est à noter que tout ensemble de dépendances fonctionnelles admet une
couverture minimale. La couverture minimale d'un ensemble de dépendances fonctionnelles
permet décomposer une relation en plusieurs relations plus petites et est, donc, une étape
importante dans le processus de normalisation.
2.1.5. Clé d'une relation
Définition :
Soit R(A1, A2, ..., AN) un schéma de relation, soit X un sous-ensemble de A1, A2, ..., AN, on
dit que X est une clé de R si et seulement si
- X A1, A2, ..., AN ;
- il n'existe pas de sous ensemble Y inclus dans X tel que Y  A1, A2, ..., AN.
Une clé d'une relation est un ensemble minimum d'attributs qui détermine tous les autres.
Dans l'écriture des schémas de relations, on indique les clés en soulignant les attributs
constitutifs.
2.2. Les trois premières formes normales
La normalisation a été développée pour convertir les données brutes en modèles convenant
aux bases de données relationnelles. C'est une approche ascendante qui commence au
niveau éléments de données et se termine par les tables à deux dimensions.
Il s'agit d'une procédure en trois étapes pour éliminer les anomalies de mise à jour et
l'incohérence des données.
La normalisation exige une connaissance détaillée des données pour pouvoir être utilisée
efficacement. Elle doit être donc pratiquée dans les étapes ultérieures de l'analyse lorsque les
principaux détails des données utilisateurs et les caractéristiques fonctionnelles ont été définis.
Pour commencer le processus de normalisation il faut convertir la source de données en un
format qui facilite la normalisation. Pour ce faire, on doit:
 Lister les attributs

 Identifier la ou les clés primaires.
Le but de la normalisation d'un schéma universelle d'une base de données, est d'obtenir une
représentation qui minimise la redondance et les risques d'anomalies lors des mises à jour et
des suppressions.
27
2.2.1. La première forme normale 1FN
Une relation est en première forme normale si tout attribut est atomique. En d'autres mots, un
attribut ne peut représenter ni une donnée composée d'entités de nature quelconque ni une
liste de données de même nature.
Cette première forme normale permet d'éviter d'avoir des attributs qui soient eux même des
relations (hiérarchie dans une relation) et cela en interdisant les domaines composés de
plusieurs valeurs.
2.2.2. La deuxième forme normale 2FN
Une relation est en deuxième forme normale si et seulement si :
- elle est en première forme normale ;
- tout attribut n'appartenant pas à une clé ne dépend pas que d'une partie de
cette clé.
2.2.3. La troisième forme normale 3FN
Une relation est en troisième forme normale si :
- elle est en deuxième forme normale ;
- tout attribut n'appartenant pas à une clé ne dépend pas d'un attribut non clé.
L'objectif de la troisième forme normale est l'élimination des redondances dues aux
dépendances fonctionnelles déduites par transitivité.
28
CHAPITRE IV : Les opérateurs relationnels
1. Introduction
Dans un modèle relationnel, les opérateurs permettent de manipuler des données. Ils traitent
des ensembles de données plutôt que des enregistrements.
Les opérateurs agissent sur une ou plusieurs relations à la fois et ont toujours pour résultat une
nouvelle relation. La relation résultante est nommée relation dérivée. Les relations d’origines
sont appelées relations de base.
Les opérateurs relationnels sont similaires aux opérateurs ensemblistes mathématiques. Le

fait que les opérateurs relationnels produisent des tables résultantes est en soi important. En
effet, on peut demander à chaque opérateur d’agir sur les résultats d’autres opérateurs.
Lorsque plusieurs opérateurs sont utilisés ensemble, on dit qu’ils sont imbriqués.
A l’origine on a défini huit opérateurs : product, union, intersect, difference et restrict, project,
divide, join.
Les quatre premiers opérateurs agissent sur deux tables. Chacun d’entre eux, à l’exception de
product, exige que les tables utilisées soient compatibles en union. Autrement dit, chaque
colonne d’une table doit avoir le même domaine que la colonne équivalente dans l’autre
table.
2. Opérateur union 
Cet opérateur agit sur deux ou plusieurs relations ayant le même schéma. Il consiste à
regrouper l'ensemble des tuples de chacune des relations de base pour en créer une nouvelle
relation où ses tuples sont l'ensemble des tuples appartenant aux relations initiales. Les
doublons éventuels seront supprimés.
R1
R2
29
R3 = UNION (R1, R2)
3. Opérateur intersection 
Cet opérateur agit sur deux ou plusieurs relations ayant le même schéma. Il consiste à ne
garder, dans une nouvelle relation, que les tuples communs aux relations initiales, les
doublons éventuels seront supprimés.
R1
R2
R3 = Intersection (R1,R2)
4. Opérateur différence /
La différence entre deux relations de même schéma est une nouvelle relation qui comprend
l'ensemble des tuples appartenant à la première relation, et pas à la seconde.
R3
30
R4
R5 = DIFFERENCE (R3, R4)
5. Opérateur Product (produit cartésien X)
Cet opérateur agit sur deux ou plusieurs relations de schéma quelconque. La relation
résultante contient toutes les concaténations possibles (combinaisons) entre les tuples des
relations initiales.
Exemple :
R= étudiant (nom, prenom)

S= études (bac, filière)
R nom prenom
Miloudi Lahcene
Babouche Kamel
Mebarki Fouad
S
bac filière
A littéraire
B économie
C sciences
D sciences
31
T=R*S
nom prenom bac filière

Miloudi Lahcene A littéraire
Miloudi Lahcene B économie
Miloudi Lahcene C sciences
Miloudi Lahcene D sciences
Babouche Kamel A littéraire
Babouche Kamel B économie
Babouche Kamel C sciences
Babouche Kamel D sciences
Mebarki Fouad A littéraire
Mebarki Fouad B économie
Mebarki Fouad C sciences
Mebarki Fouad D sciences
6. Opérateur Restrict 
L'opération restriction (ou sélection) est un opérateur unaire qui produit en sortie une
nouvelle relation (de même schéma que la relation de base) où ses tuples satisfaisant la
condition de sélection qui utilise les opérateurs de comparaison ( <; <=; >; =>; =; != ), les
connecteurs logiques (et ou non) et les parenthèses.
Syntaxe
 < condition > (Relation)
Soit la relation SORTIES (no_pièce, no_projet, date_s, quantité)
SORTIES
Qu'elles sont les sorties dont la quantité est supérieure à 3?
R quantité > 2 ( SORTIES )
32
R1
7. Opérateur Projection 
Cet opérateur agit sur une seule relation. Il produit en sortie une nouvelle relation ayant
comme enregistrements ceux de la relation de base restreints aux attributs choisis dans la
condition de projection (un sous-schéma inclus dans le schéma de la relation de base)
Syntaxe
 A1; A2; ...; An ( < relation > )
R1 ((no_pièce, no_projet) (SORTIES)
R1
8. Opérateur Join
L'opération de jointure sur plusieurs relations est le produit cartésien de ces qui vérifie des
conditions spécifiées par l'utilisateur. Ces condition portent sur des attributs de mêmes
domaines appartenant aux relations de base.
Remarque: On peut aussi ajouter une condition de restriction à l'opération jointure.
Requête : Quelles sont les pièces dont la quantité en stock = 0 et qui ont fait l'objet de
sorties?
ARTICLES
SORTIES
33
R =  quantité = 0 ( Jointure(ARTICLES, SORTIES ((no_pièce de ARTICLES = no_pièce de

SORTIES)))
34
CHAPITRE V : Le langage SQL
1. Introduction
SQL est un langage non procédural qui manipule des ensembles. Il se présente sous forme de
requêtes qui sont constituées, d'une façon générale, de trois éléments essentiels :
• Une clause SELECT : elle permet de déterminer les attributs qui vont constituer le schéma
de la future relation.
• Une clause FROM : elle permet de déterminer les relations de base (là où on va chercher
l'information)
• Une clause WHERE : elle permet de spécifier les conditions de recherche.
1.1. Structure générale du langage
Les instructions essentielles SQL se regroupent en trois familles qui sont :
• LMD (Langage de Manipulation de Données) : permet la manipulation des tables et

des vues à travers:
- Select : Pour la recherche de données.
- Insert : Pour l'insertion des tuples dans une table.
- Delete : Pour la suppression des tuples dans une table.
- Update : Pour la modification des tuples dans une table
• LDD (Langage de Définition de Donnée) : permet la création et la définition des

tables, vues, index, attributs, à travers:
- Déclaration de tables.
- Déclaration des vues
- Déclaration de contraintes d'intégrités
• LCD (Langage de Contrôle de Données) : permet de définir des droits aux utilisateurs
de la base de données.
2. Le langage de manipulation des données (LMD)
Pour illustrer les différents commandes du langage SQL, nous allons utiliser dans ce qui suit,
une base de données composée des tables suivantes :
INVENT (no-pièce, descr, étagère, unité, coût, quantité, classe)
PROJET (no_projet, date_début, date_fin, id_chef)
SORTIE (no_sortie, no-pièce, no_projet, quantité_sortie, date_sortie)
CLASSE (classe, nom, taxable)
CHEF (id_chef, nom, date_nais)
35
2.1. Les requêtes simples
Une requête simple, ou une projection, permet de sélectionner un ensemble d'attribut dans une
table. Elle a la syntaxe suivante :
Select < liste des attributs (colonnes) >

From < liste des tables > ;
Par exemple :
Select no_pièce, descr

From INVENT ;
Le résultat de cette requête donne une liste de tous les numéros de pièces (no_pièce) et leur
description de la table INVENT.
INVENT
Le résultat de la requête:
Pour sélectionner tous les attributs de la table on peut utiliser le caractère '*' :
Exemple :
Select *
From INVENT ;
Pour ne pas avoir de redondance (de doubles) dans la sélection on utilise l'expression
'distinct'
36
Exemple :
Select distinct descr

From INVENT ;
2.2. Requêtes avec la clause "WHERE"
La clause WHERE permet d'inclure une condition à la sélection (restriction). Sa syntaxe est
la suivante :
Select < liste des attributs (colonnes) >
From < liste des tables >
Where < expression logique > ;
Exemple : Donnez la liste des projets (no_projet, id_chef) dirigés par le chef de projet dont le
numéro est "105".
Select no_projet, id_chef

From Projet
Where id_chef = "105"
PROJET
On obtient donc la restriction suivante:
Remarque :
La condition dans la clause Where est une expression logique qui peut être exprimée en
utilisant une combinaison des connecteurs logiques (AND, OR, NOR), des opérateurs
arithmétiques (+, -, *, /, ^), des comparateurs arithmétiques (=, != ou <>, <, >, <=, >=),
des comparateurs ensemblistes (Between …. And, Not between … and, In, Not in), des
Comparateurs de chaînes de caractères (Like, Not like), des restriction sur les valeurs
37
manquantes (IS NULL, IS NOT NULL) et/ou des fonctions numériques prédéfinies
(ABS, GREATEST, LEAST).
Exemples :
Trouvez les projets dirigés par les chefs de projet dont l’identification est “104”, “108” ou
“111”.
Select no_projet
From Projet
Where id_chef IN ("104", "108", "111");
Quels sont les projets qui ont débuté entre le 1er janvier 1989 et le 15 mars 1991?
Select no_projet
From Projet
Where date_début >= #1989-01-01#
AND date_début <= #1991-03-15#;
cette requête peut s'écrire :
Select no_projet
From Projet
Where date_début BETWEEN #1989-01-01# AND #1991-03-15#;
Quelles sont les pièces dont la classe débute par la lettre “Z”?
Select *
From Invent
Where classe LIKE "Z*";
2.3. Requêtes avec la clause "ORDER BY"
Cette clause permet de classer par ordre croissant ou décroissant le résultat d'une requête.
Par défaut, une requête tri la relation résultat par ordre croissant. Les extensions asc et desc
indiquent respectivement si le tri est croissant ou décroissant.
Exemple :
Donnez la liste des sorties d'inventaire (no_pièce, no_sortie, no_projet) du projet "P1259",
présentée par ordre de numéro de pièce.
Select no_pièce, no_sortie, no_projet

From Sortie
Where no_projet = "P1259"
Order By no_pièce ASC
38
(À noter que le asc n'est pas obligatoire ici car il est mis par défaut)
Le résultat:
le même résultat en ordre décroissant :
Select no_pièce, no_sortie, no_projet

From Sortie
Where no_projet = "P1259"
Order By no_pièce DESC
On pourra aussi trier avec plusieurs critères. Par exemple, quelles sont les sorties
d'inventaire (no_projet, date, no_sortie) dont le numéro de projet débute par "P128" et la
quantité de pièces sorties est supérieure à 10? La liste doit être présentée par ordre croissant
de numéro de projet et par ordre chronologique.
Select no_projet, date_s, no_sortie

From Sortie
Where no_projet LIKE "P128*"
And quantité > 10
Order By no_projet ASC, date_s ASC
Le résultat:
2.4. Requêtes multi-relations
Les requêtes multi-relations représentent les jointures. Il faut que les champs servant à la
jointure soient du même type (même domaine).
39
Exemple :
Select no_pièce, Invent.classe ,descr, Classe.classe ,nom

From Invent, Classe
Where Invent.classe = Classe.classe
And unité = "SAC/25"
Remarque : On peut donner des alias aux noms de tables pour éviter de taper à chaque fois le
nom de la table entièrement dans la requête.
Select no_pièce, Invent.classe ,descr, Classe.classe ,nom

From Invent I, Classe C
Where I.classe = C.classe
And unité = "SAC/25
2.5. Requêtes avec fonction d'agrégats
Les fonctions agrégats permettent de faire du dénombrement, déterminer un maximum, un
minimum, faire des. Voici la liste de ces fonctions :
COUNT permet de compter le nombres de valeurs d'un ensemble.
SUM permet de faire la somme des valeurs d'un ensemble.
AVG permet de calculer la moyenne des valeurs d'un ensemble.
MAX permet de calculer la valeur maximale d'un ensemble.
MIN permet de calculer la valeur minimale d'un ensemble.
Exemple :
Quel est le coût unitaire moyen de toutes les pièces en inventaire?
Select AVG(coût)
From Invent
Calculez la valeur totale de l'inventaire.
Select SUM(quantité * coût)
From Invent
2.6. La clause "GROUP BY"
Cette clause permet de grouper les résultats d'une requête par rapport à un attribut spécifié et
cela pour une meilleure lisibilité.
Exemple :
40
Quel est le coût unitaire moyen par classe de pièces?
Select classe, AVG(coût)

From Invent
Group By classe
Calculer le nombre de classes taxables et de classes non taxables.
Select taxable, COUNT(*)

From Classe
Group By taxable
2.7. La clause HAVING
La clause HAVING permet de faire des restrictions sur les regroupements ORDER BY.
Syntaxe :
Select liste des colonnes, fonction(s) prédéfinie(s)

From Table
Where condition de ligne
Group By liste des colonnes
Having condition de groupe;
Exemple:
Quels sont les projets qui ont donné lieu à plus de 10 sorties d’inventaire?
Select no_projet
From Sortie
Group By no_projet
Having COUNT(*) > 10;
41
2.8. Requêtes imbriquées
Des requêtes imbriquées sont celles qui comprennent une requête dans la clause "where" ou
"having" (une requête à l'intérieur d'une requête). On utilise le résultat de la requête
imbriquée pour réaliser la requête appelante.
Exemple :
Quels sont les pièces qui appartiennent à des classes taxables?
Select no_pièce
From Invent
Where classe IN (Select classe
From Classe
Where taxable = "OUI");
Cas particuliers : les requêtes imbriquées et corrélées
Ce cas se produit quand on a besoin des informations de la requête principale dans la sous
requête.
Exemple :
Quelles sont les sorties d’inventaire dont la quantité de pièces sorties est supérieure à la
quantité moyenne de toutes les sorties effectuées sur le compte du même projet?
Select no_sortie
From Sortie AS S1
Where quantité > (Select AVG(quantité)
From Sortie AS S2
Where S2.no_projet = S1.no_projet);
42
3. La modification des données
3.1. Insertion de tuples (lignes)
Il existe deux cas d'insertions de valeurs dans une base de données :
1. Pour insérer les données dans une ligne d'une table on utilise INSERT avec la clause
VALUES.
2. Pour insérer des données à partir d'une autre table, on utilise la clause SELECT.
Voici la syntaxe pour Insert avec la clause Values :
Insert Into < Nom de table > [ <nom des attributs > ]
Values ( < valeur attribut1>, < valeur attribut 2>, … )
Exemple :
Ajoutez un chef de projet nommé Kamel Dahmani dont l’identification est “357”.
Insert Into Chef
Values ("357", " Kamel Dahmani");
Voici la syntaxe pour Insert avec la clause Select:
Insert Into < Nom de table > [ <nom des attributs > ]
Select < nom des attributs >
From < nom de table2>
Where < condition >
3.2. Mise à jour de tuples
Pour la mise à jour des données, on utilise la commande UPDATE.
Voici sa syntaxe :
Update < nom de table >
Set { < nom attribut > = valeur }

Where < condition de recherche >
Exemple :
Majorer de 10% le coût de la pièce “384R”.
Update Invent
Set coût = coût * 1.1
Where no_pièce = "384R";
43
3.3. Suppression de tuples
Pour supprimer un tuple dans une table on utilise la commande DELETE.
Voici sa syntaxe :
Delete From < nom table >
Where < condition de recherché >
Exemple :
Effacez les pièces en inventaire qui appartiennent à la classe “W67”.
Delete
From Invent
Where classe = "W67";
44
4. Le langage de définition des données (LDD)
4.1. La déclaration de tables
Pour créer une table, on utilise la commande CREATE TABLE. et il faut respecter les
règles suivantes :
1. Chaque table de la base de donnée possède un nom unique.

2. Une table est composée d'au moins un attribut.
3. Chaque attribut au sein d'une table possède un nom unique.
4. Des contraintes sur les attributs peuvent être définies lors de la création de table.
Voici sa syntaxe :
Create table < nom de table >
(< nom_attribut1 > < type attribut1 > < contrainte attribut1 >,
< nom_attribut2 > < type attribut2 > < contrainte attribut >,….. )
< contrainte de table > ;
Exemple :
1. Créez une table qui permet d’enregistrer des factures.
Create Table Facture
(no_facture CHAR(10) NOT NULL,
date_facture DATE NOT NULL,
nom_client CHAR(40),
montant DOUBLE);
2. Créer la table des commandes comportant 3 attributs : le numéro de commande qui

doit être unique et non nul, la date de commande.
Create table COMMANDE

(numcom NUMERIC (5) PRIMARY KEY,
Datecom DATE);
4.2. La suppression d'une table
La syntaxe de la requête de suppression d'une table est la suivante:
Drop Table < nom de table >
45
TRAVAUX DIRIGES
46
Cours de Bases de données relationnelles Bouziane abderraouf
CHAPITRE I
Question 1 :
Quand est ce que se produit une redondance des données ?
Question 2 :
Lorsque plusieurs fichiers contiennent des champs de données du même nom dont les données
ne concordent pas, on dit qu’il y a …………..
Question 3 :
De quels avantages bénéficiera une organisation en mettant en place un système de fichiers

informatique ?
Question 4 :
Récapitulez les effets de la redondance des données :
Les coûts de stockage (augmentent ou diminuent)
De multiples mises à jour doivent être effectuées pour actualiser les différents ………..
Peut mener à une ………………… des données
Rend les ………… difficiles à appliquer
Question 5 :
Voici la liste des fichiers, enregistrement et champs utilisés dans une banque. Indiquez si
chaque élément est un « fichier », un « enregistrement » ou un « champ ».
Comptes courants …………………
Numéro de compte ………………….
Renseignements sur le client ………………
Solde du compte ……………..
Comptes d’emprunt ……………
Date d’ouverture ……………..
Renseignement sur l’emprunteur ……………
Nom du compte …………..
47
Question 6:
Quelle catégorie d’utilisateurs aura le plus souvent besoin d’exécuter les manipulations
suivantes :
Création de nouveaux fichiers, insertion de nouveaux enregistrements, extraction des données,

mise à jour des données, suppression des données et génération de rapports.
Question 7 :
Quel logiciel permet de contrôler la base ? …………………
Question 8 :
Le SGBD élimine-t-il toutes les redondances de données ?
Question 9 :
Quels sont les trois types de modèles de base de données pris en charge par les systèmes
réels ?
48
CHAPITRE II
TP 1
Congrès International en Informatique Appliquée 20XX (CIIA xx).
Avant la tenue d'un congrès, les organisateurs font parvenir aux universités, aux entreprises
et aux administrations des affiches de publicité. Les personnes désirant participer envoient
leurs articles au secrétariat du congrès avant une certaine date. (Date limite de dépôts
des articles ou deadline).
Chaque article (identifié par un numéro) est revu par un ou plusieurs membres du comté
de lecture (les reviewers). Les articles jugés intéressants seront retenus pour la présentation
lors du congrès et leurs auteurs sont contactés pour la confirmation de participation.
La fiche de confirmation de participation indique :

 Les nom, prénom, adresse du congressiste et téléphone (s'il a un téléphone).
 Les nuitées (dates) que le congressiste souhaite passer à l'hôtel. (pour réservation)
Le congrès se déroule sur 3 jours et il comporte différents sessions d'une demi journée
chacune consacrées à la présentation des articles. A noter qu'un congressiste peut soumettre
plusieurs articles.
A tout moment (avant, pendant et après) on désire connaître la liste des sessions se déroulant
telle demi-journée avec toutes les informations les concernant (numéro de la session,
président de la session (un des membre du comité de lecture), les articles inscrits dans
la session, nom ou numéro de salle). Plusieurs sessions peuvent se dérouler simultanément
dans la même demi-journée.
Une semaine avant le début du congrès, on désire imprimer :

 La liste générale des congressistes (numéro d'inscription, nom, adresse…)
 La liste des participants par session.
Questions :
1. Constituer le dictionnaire de données.

2. Etablir un modèle entité association relatif à cette description.
3. En déduire le MLD relationnel.
4. Implanter la base de données associée en utilisant MS-Access.
49
TP 2
Le LMD
Dans le système LMD les formations sont organisées en semestres : La licence 6 semestres, le
Master 4 semestres et le doctorat minimum 6 semestres. Ces formations sont regroupées par
grands domaines (MI, ST…) qui recouvrent plusieurs disciplines (Maths, Informatique,
Médecine…)
Au cours de la licence, l'étudiant choisit une des mentions proposées. Exemple : Licence MI,
mention Informatique de gestion. Au cours du Master, il choisit une mention et
éventuellement une spécialité qui peut être déclinée en voie "recherche" ou "professionnelle".
Exemple : Master Sciences et technologie (ST), mention Sciences et technologie de
l'information et de la communication, spécialité réseau communication, voie recherche.
Chaque formation est constituée d'une combinaison d'Unités d'Enseignement (UE)

fondamentales, méthodologiques ou de découverte. Ces combinaisons sont définies par
l'Université en fonction du domaine, de la mention et pour les masters de la spécialité.
L’Unité d’Enseignement peut associer plusieurs matières (modules) et comprendre différentes

formes d’enseignement (cours, TD, TP, travail personnel etc.). Chaque UE a une valeur
définie en crédits. Un semestre est composé de plusieurs unités. La valeur totale des UE qui
composent un semestre est fixée à 30 crédits.
Questions :

50
TP 3
Le cirque
Les organisateurs d’un cirque veulent monter une base de données pour gérer les réservations
des spectateurs, le choix des numéros et l’organisation des différents spectacles.
Le cirque dure sept jours et chaque demi-journée est consacrée à un spectacle qui regroupe
des numéros portant sur le même thème (magie, acrobaties, dressage d’animaux ...).
L'espace réservé aux spectateurs est divisé en plusieurs zones regroupant des places
numérotées. Le tarif de la réservation dépend de l'endroit de la place et du spectacle choisi.
Chaque numéro proposé est caractérisé par un code, son nom, son thème et sa durée moyenne
en minutes (de 20 à 25 minutes). De plus on souhaite savoir l’instrument utilisé pour les
numéros musicaux, l’animal concerné par les numéros de dressage et le type des acrobaties
(équilibrisme, trapèze volant, …), etc. On maintient aussi le nombre des artistes présents sur
scène
Chaque artiste possède un numéro (en général son numéro de carte d’identité), son nom,
son prénom, sa date de naissance, son adresse, le ou les numéros qu’il propose puisque les
artistes sont susceptibles de présenter plusieurs numéros.
Pour chaque spectacle, on garde le code, le thème, le jour, l’heure de début, l’heure de fin,
le président (celui qui anime le spectacle, présente les artistes, etc., c’est un artiste d’un autre
numéro), la liste des numéros du spectacle, avec leur heure de passage et le coût d'entrée
pour le spectacle (tous les spectacles n’ont pas le même coût d’entrée).
Questions :

51
TP 4
La fiche de prêt
Questions :

4. Implanter la base de données associée en utilisant MS-Access
NUMÉRO : 1233
NOM : BENAHMED PRÉNOM : Salim
ADRESSE :
54 rue de Belleville
34000 BelleWilaya
EMPRUNT ANNEE ETAT NUMERO DATE RENDU PEN.

vinyl 33t 2000 3 14561-V 17/11 24/11 0
K7 2000 4 00232-K 22/12 03/01/2001 10
total pénalités 2000 10DA
CD 2001 1 08742-C 01/02 21/02 20

Vinyl 45t 2001 3 00768-V 02/05 09/05 0
K7 2001 2 05647-K 10/11 17/11 0
total pénalités 2001 20DA
52
TP 5
Implémentation d’un service de messagerie électronique
Dans ce système de messagerie électronique les utilisateurs ont des adresses de 30 caractères
maximum selon le format xxxx@univ-bba.dz, et un mot de passe personnel. Avant son
enregistrement, l’utilisateur doit nous fournir certaines informations (nom, prénom, date de
naissance, adresse, fonction, institut de rattachement).
Ce système doit permettre aux utilisateurs d’envoyer et de recevoir des mails (du texte) avec
éventuellement des pièces jointes (des pdf, des jpg, Etc.) créées par d’autres logiciels. Chaque
utilisateur à 2 dossiers : Boite de réception, Boite des éléments envoyés.
Quelques fonctions à implémenter :
 Le système doit permettre aux utilisateurs d’avoir un carnet d’adresses.
 Un utilisateur peut envoyer un mail à un groupe d’utilisateurs.

Exemple : 2eme-lmd@univ-bba.dz ou {a, b,..}@univ-bba.dz
 Le système doit permettre aux utilisateurs de répondre aux emails
Le système doit permettre aux utilisateurs de créer des alias aux adresses électronique.
Questions :

53
CHAPITRE III
Exercice 1 :
Soit la relation R ci-dessous. Établissez si les dépendances fonctionnelles suivantes sont

satisfaites ou non par R.
Exercice 2 :
Soit la relation R (A, B, C, D, E).
A B C D E
a1 b1 c1 d1 e1
a1 b2 c2 d2 e1
a2 b1 c3 d3 e1
a2 b1 c4 d3 e1
a3 b2 c5 d1 e1
Question : quelles sont les dépendances fonctionnelles satisfaites par R ?
Exercice 3 :
Soit la relation R (P, X, Y, Z, W).
54
P X Z Y W
1 7 5 9 6
3 8 3 3 7
3 5 2 4 7
9 5 2 0 4
Question : les dépendances fonctionnelles ci-dessous sont-elles élémentaires?
1)XYZ. 2)XYW. 3)XYP
Exercice 4 :
Soit F = {AB • C ; B • D ; CD • E ; CE • GH ; G • A}.
Question : montrer que
1) AB • E. 2) BG • C. 3) AB • G.
Exercice 5 :
Soit R une relation qui satisfait les dépendances fonctionnelles suivantes :
XYZ. YT. TY
Question : trouvez les clés candidates de la relation R.
Exercice 6 :
Soit R une relation ayant 5 attributs X, Y, Z, P et W et qui satisfait les dépendances
fonctionnelles suivantes :
YZ. ZY. ZW et YP
Question : trouvez les clés candidates de la relation R.
55
EXERCICES CORRIGES
Exercice 1 :
Soit la relation suivante r de schéma R (A, B, C, D, E).
A B C D E
a1 b1 c1 d1 e1
a1 b2 c2 d2 e1
a2 b1 c3 d3 e1
a2 b1 c4 d3 e1
a3 b2 c5 d1 e1
Question : quelles sont les dépendances fonctionnelles satisfaites par R ?
Réponse : les dépendances fonctionnelles satisfaites par R sont les suivantes :
A -> E ; B -> E ; C -> ABDE ; D -> E ; AB -> D ; AD -> B ; BD -> A.
Exercice 2 :
Soit F = { A -> D ; AB -> E ; BI -> E ; CD -> I ; E -> C }.
Question : calculer la fermeture, sous F, de AE.
Solution : au départ, (AE)+ = AE,
A -> D permet d'ajouter D : (AE)+ = AED,
E -> C permet d'ajouter C : (AE)+ = AEDC,
CD -> I permet d'ajouter I : (AE)+ = AEDCI.
Question : calculer la fermeture, sous F, de BE.
Solution : au départ, (BE)+ = BE,
E -> C permet d'ajouter C : (BE)+ = BEC.
Exercice 3 :
Soit F = { AB -> C ; B -> D ; CD -> E ; CE -> GH ; G -> A }.
Question : en utilisant la notion de fermeture d'un ensemble d'attributs, montrer que AB -> E,
Solution : B -> D |= AB -> D par augmentation,
56
AB -> C et AB -> D |= AB -> CD par union,
AB -> CD et CD -> E |= AB -> E par transitivité.
Question : en utilisant la notion de fermeture d'un ensemble d'attributs, montrer que BG -> C,
Solution : G -> A |= BG -> A par augmentation,
BG -> BG |= BG -> B par projection,
BG -> A et BG -> B |= BG -> AB par union,
BG -> AB et AB -> C |= BG -> C par transitivité.
Question : en utilisant la notion de fermeture d'un ensemble d'attributs, montrer que AB -> G.
Solution : AB -> E et AB -> C |= AB -> CE par additivité,
AB -> CE et CE -> GH |= AB -> GH par transitivité,
AB -> GH |= AB -> G par projection.
57
CHAPITRE II
Exercices :
Transformer les MCD suivants en MLDR.
1)
2 )
58
3 )
4 )
59
5)
6)
7 )
60
8)
61
CHAPITRE IV
Exercice 1:
Soit les schémas de relation suivants :
Fournisseurs (NomF, adresseF)

Prix (NomF, NomP, Coûts)
Commandes (N°Com, NomC, NomP, Qte)
Clients (NomC, AdresseC, Solde)
Et les extensions :
Fournisseurs NomF AdresseF

Bouna 23000 Annaba
Cima 25000 Constantine
Perblocs 16000 Alger
Samaco 34000 BBA
Prix NomF NomP Coûts

Bouna Sable 300
Bouna Briques 1500
Bouna Parpaing 1150
Perblocs Tuiles 1150
Perblocs Parpaing 1200
Samaco Parpaing 1150
Samaco Ciment 125
Samaco Briques 1200
Commandes N°Com NomC NomP Qte

1 Kamel Briques 5
2 Kamel Ciment 10
3 Amine Briques 3
4 Amine Parpaing 9
5 Morad Parpaing 7
Clients NomC AdresseC Solde

Kamel 19000 Setif -12000
Amine 18000 Jijel 0
Morad 30000 Ouargla 3000
Samir 34000 BBA 7000
Réaliser les opérations suivantes et dégager leur sémantique :

1. Prix  Clients
62
2. Fournisseurs X Prix
3.  NomC= "Kamel" (Commandes)
4.  NomP, Coûts (Prix)
5.  NomF(Fournisseurs) ∩  NomF(Prix)
6. Clients  Commandes
7.  NomP (  NomC= "Kamel" (Commandes))
8.  NomC= "Kamel" (Prix  Commandes)
9.  NomC= "Kamel" (Commandes )  Prix
10.  NomP, NomF, Coûts (  NomC= "Kamel" (Commandes )  Prix)
11. Fournisseurs  Prix
Formuler les requêtes suivantes en langage algébrique
1. Quels sont les noms des produits commandés par Kamel?

2. Quels sont les noms des fournisseurs qui fournissent les produits qui figurent dans les
commandes de Amine?
3. Quels est l'adresse des fournisseurs qui fournissent des parpaings à un coût strictement
inférieur à 1200?
4. Quels sont les noms et adresses des clients et des fournisseurs tels que le produit
commandé lors d'une commande soit des briques?
5. Quels sont les fournisseurs qui fournissent tous les produits que commande Kamel?
Exercice 2:
Soit le schéma suivant :
Servir (Restaurant, Plat)

Fréquenter (Client, Restaurant)
Aimer (Client, Plat)
Questions : formuler les requêtes suivantes en langage algébrique
1. Les Restaurants qui servent un Plat apprécié par 'Amine'.

2. Les Clients qui vont dans les mêmes Restaurants que Amine.
3. Les Clients qui fréquentent au moins un Restaurant où l'on sert une Plat qu'ils aiment.
4. Les Clients qui ne fréquentent aucun Restaurant où l'ont sert un Plat qu'ils aiment.
5. Les Clients qui fréquentent tous les Restaurants.
6. Les Clients qui fréquentent tous les Restaurants qui servent au moins un Plat qu'ils
aiment.
7. Les Clients qui ne fréquentent que les Restaurants qui servent un Plat qu'ils aiment.
8. Donner pour chaque Client, le nombre de Restaurants servant un Plat qu'ils aiment.
9. Les Clients qui fréquentent au moins 2 Restaurants où l'on sert un Plat qu'ils aiment.
63
CHAPITRE V
SQL
Interrogation de la base de données INVENTAIRE3
Formulez en SQL les requêtes suivantes :
1. Donnez la liste des projets (no_projet, id_chef) dirigés par le chef de projet dont le
numéro est "105".
2. Donnez la liste des sorties dont la quantité est inférieure à 3.
3. Donnez la liste des sorties d'inventaire (no_pièce, no_sortie, no_projet) du projet
"P1259", présentée par ordre de numéro de pièce.
4. Donnez la liste des pièces (no_pièce, description, coût) dont le coût unitaire est au
moins 120.00 DA, triée par ordre décroissant de coût.
5. Donnez la liste des pièces (no_pièce, description, coût) comportant le mot "turbine" au
sein de leur description.
6. Quelles sont les sorties d'inventaire (no_projet, date, no_sortie) dont le numéro de
projet débute par "P128" et la quantité de pièces sorties est supérieure à 10? Votre liste
doit être présentée par ordre croissant de numéro de projet et par ordre chronologique.
7. Identifiez les pièces (no_pièce, description, classe, étagère) qui appartiennent à la
classe "C10", qui sont localisées dans une étagère débutant par le numéro "11", et dont
la quantité en inventaire dépasse 25.
8. Trouvez les pièces (no_pièce, description) fondamentales de l'inventaire. Le chef-
magasinier considère comme fondamentale: toute pièce dont le coût est d'au moins
500DA et l'unité est "UN"; ou toute pièce dont la classe est "D30" et est conservée
dans une étagère dont le numéro débute par "00".
9. Quels sont les projets (no_projet seulement) qui ont été imputés d'au moins une sortie
d'inventaire?
10. Qui sont les chefs de projets ayant été assignés au moins une fois à la direction d'un
projet (présentez seulement l'identification du chef de projet)?
11. Produisez la liste complète des classes de pièces en ordre alphabétique du nom.
12. Produisez la liste complète des chefs de projet (id_chef, nom).
13. Produisez la liste contenant le numéro, la description et la quantité, des pièces en
inventaire qui valent au moins 50.00DA l'unité.
14. Produisez la liste, triée par numéro de pièce, des sorties d'inventaire portées sur le
15. Produisez la liste des sorties d'inventaire où la quantité sortie est supérieure à un (1)
mais inférieure à dix (10).
16. Présentez la liste de tous les projets qui ont duré moins de 18 mois (Assumez que tous
les mois ont trente jours).
17. Présentez la liste des sorties d'inventaire qui ont été effectuées entre le 10 mai 1989 et
le 25 février 1990.
18. La liste (no_pièce, description et quantité) des pièces qui ont au moins 15 unités en
inventaire.
19. La liste (no_pièce, description et classe), triée par numéro de pièce, des pièces qui
appartiennent à la classe "A10".
20. La liste des sorties d'inventaire du projet "P1206" où la quantité sortie est supérieure à
un (1).
3
Questions tirées de : http://neumann.hec.ca/pages/eric.forthomme/
Base de données Inventaire.mdb disponible sur le site du document.
64
21. La liste de tous les projets qui ont terminé avant le 25 mars 1990, triés dans l'ordre
décroissant des numéros de projet.
22. Quel est le numéro des chefs de projet qui ont moins de 45 ans? Access vous permet
d'obtenir la date du jour en utilisant la fonction DATE().
23. La liste des pièces, numéro et description seulement, que l'on retrouve dans une
étagère débutant par "21" ou "11", triées par ordre alphabétique de description.
24. La liste des pièces (classe, no_pièce, description et étagère) que l'on retrouve dans la
section d'étagère "S" (ex: "99S99") et qui n'ont pas de quantité en inventaire, triées par
numéro de pièces.
25. La liste des sorties d'inventaire (no_sortie, no_pièce, no_projet et quantité) qui ont été
effectuées avec la pièce "BXM100", ou qui ont été effectuées pour le projet "P1259".
26. Présentez la liste des pièces par ordre de classe et de numéro, et majorez leur coût de
20%.
27. Quel est le coût unitaire moyen de toutes les pièces en inventaire (sans égard à la
quantité possédée)?
28. Quel est le coût unitaire moyen par classe de pièces (encore une fois sans égard à la
quantité)?
29. Calculer le nombre de classes taxables et de classes non taxables.
30. Quelle est la somme des quantités de pièces sorties par projet, pour les projets dont les
31. Combien y a-t-il de chefs de projet ayant été assignés au moins une fois à la direction
d'un projet?
32. Calculez la valeur totale de l'inventaire.
33. Quel est le coût unitaire moyen (sans égard à la quantité) par classe de pièces pour les
classes comportant 20 pièces ou plus?
34. Quel est le nombre total de sorties d'inventaire enregistrées dans la table SORTIE?
35. Quel est le nombre total de sorties d'inventaire enregistrées pour chaque projet?
36. Présentez le total des quantités des pièces en inventaire.
37. Présentez le total des quantités des pièces en inventaire, pour chacune des classes de
pièces.
38. Présentez le total des quantités des pièces en inventaire, pour chacune des classes de
pièces, mais seulement pour les classes qui regroupent 5 sortes de pièces ou plus.
39. Quel est le coût unitaire moyen des pièces?
40. Combien y a-t-il de sorties imputées aux projets "P1206" et "P1271"? (la réponse est
un nombre unique)
41. Pour chaque pièce, présentez la quantité totale d'unités sortie de l'inventaire, triée par
numéro de pièce.
42. Fournissez la liste des pièces qui ont fait l'objet de deux sorties ou plus.
43. Fournissez la liste des numéros des projets ayant débuté entre le 24 mai 1987 et le 4
mars 1990 inclusivement.
44. Quelles sont les sorties d'inventaire ayant été effectuées pour le compte de l'un des
projets suivants: "P1150", "P1151", "P1156", "P1167" et "P1198"?
45. Quelles sont les sorties d'inventaire (no_sortie, date) effectuées pour un projet dont
l'identification du chef de projet se situe entre "111" et "121" inclusivement?
46. Quelle sont les classes de pièces auxquelles aucun numéro de pièce contenu en
inventaire n'appartient?
47. Quelles sont les pièces (no_pièce, description, unité) qui n'ont jamais fait l'objet d'une
sortie d'inventaire d'une quantité de 2?
48. Quelles sont les sorties d'inventaire effectuées avec la pièce la plus dispendieuse?
49. Quels sont les numéros de pièce dont le coût unitaire est supérieur au coût unitaire
moyen de toutes les pièces de la même classe à laquelle elles appartiennent?
50. Fournissez une liste de prix (no_pièce, description, prix) pour les pièces. Le prix de
vente correspond au coût de la pièce majoré de 28%, sauf dans le cas des pièces de la
65
classe "V08" qui, elles, doivent être majorées de 21%. Note: la liste doit apparaître par
numéro de pièce.
51. Quelles sont les pièces qui ont un coût unitaire plus élevé que la moyenne?
52. Fournissez la liste des pièces, incluant leur description, qui ont fait l'objet d'au moins
une sortie sur le compte du projet "P1288".
53. Quelles sont les pièces qui n'ont jamais fait l'objet de sortie.
54. Quel est le nom du chef de projet le(la) plus jeune?
55. Présentez la liste des sorties d'inventaire, par ordre chronologique, effectuées par le
chef de projet le plus vieux (vieille).
56. Produisez la liste de toutes les pièces (no_pièce, description, unité et coût) par ordre de
numéro de pièce, mais en majorant de 7% le coût des pièce dont l'unité est "UN" et de
12% les autres pièces.
57. Effacez les sorties effectuées pour le compte du projet le plus ancien.
58. Donnez le nom et l'âge (en années) des chefs de projet qui ont dirigé des projets dont
la durée fut de deux mois ou moins.
59. Présentez la liste des sorties d'inventaire (no_sortie, date, quantité) effectuées avec la
pièce la plus coûteuse.
60. Quelles sont les pièces (no_pièce, description, nom de la classe) dont l'unité de mesure
est le "SAC/25"?
61. Donnez la liste des projets en incluant le nom du chef de projet (id_chef, nom,
no_projet), triée par l'identification du chef.
62. Fournissez une liste des sorties d'inventaire en affichant la description de la pièce et le
nom du chef de projet, au lieu du numéro de la pièce et du numéro du projet,
respectivement.
63. Calculez le montant dépensé en pièces pour chaque projet.
64. Calculez le montant dépensé en pièces pour chacun des chefs de projet (faire
apparaître le nom du chef de projet).
65. Quelles sont les pièces taxables qui ont été sorties de l'inventaire au moins une fois par
des chefs de projet nés avant le 1er janvier 1940? (On vous demande seulement le
numéro des pièces, mais celui-ci ne doit apparaître qu'une seule fois dans la liste.)
66. Fournissez une liste qui présente le numéro de la pièce, sa description et le nom de la
classe à laquelle elle appartient. Présentez votre liste de sorte que toutes les pièces
appartenant à une même classe apparaissent les unes à la suite des autres.
67. La liste des pièces (nom de classe, no_pièce, unité, coût) taxables, présentée par ordre
de nom de classe et par ordre de no_pièce.
68. Pour chacune des sorties d'inventaire impliquant une quantité égale ou supérieure à 10
unités, fournissez le nom de la classe de la pièce et le nom du chef de projet (No
sortie, nom de la classe, nom du chef de projet).
69. Pour chacune des sorties d'inventaire effectuées par le chef de projet "Marc Cadame",
fournissez une liste indiquant le numéro de la sortie, la description de la pièce et sa
mention taxable.
70. Vous devez présentez le coût total en pièces de chacun des projets. Votre liste doit être
présentée en ordre de numéro de projet. Le coût total s'obtient en calculant la valeur de
chacune des sorties (quantité de pièces x coût de la pièce) et en faisant la somme de
toutes les sorties pour chacun des projets. Pour les pièces taxables, ajoutez 7% de TPS
et 8% de TVQ.
71. Fournissez la liste des pièces qui ont été utilisées pour le compte d'un des projets
suivants: "P1288", "P1259" ou "P1210". Si, et seulement si, la description de la pièce
ne comprend pas le mot "acier".
72. Fournissez une liste des chefs de projet avec le nombre de projets auxquels chacun est
associé. Vous devez fournir le nom du chef et n'oubliez pas que certains chefs ne
dirigent aucun projet.
66
73. Fournissez la liste des noms des chefs de projet avec, à côté de leur nom, la mention
"expérimenté" s'ils ont dirigés 2 projets ou plus, ou la mention "débutant", le cas
échéant.
74. Fournissez la liste des numéros de projets dont le montant total dépensé en pièces est
supérieur à 1 000DA.
75. Quelle est la valeur en dollars que représente chacune des sorties d'inventaires, en
sachant qu'une majoration de 7% doit être appliquée pour les frais généraux?
76. Quelle est la valeur en dollars que représente le total des sorties imputées à chacun des
projets, en sachant qu'une majoration de 7% doit être appliquée pour les frais
généraux? (Assumez que tous les projets ont eu des sorties).
77. Quelle est la valeur en dollars que représente le total des sorties imputées à chacun des
chefs de projets, en sachant qu'une majoration de 7% doit être appliquée pour les frais
généraux? (Assumez que tous les chefs ont dirigé des projets, et que tous les projets
ont eu des sorties).
78. On vous demande la même question, mais cette fois votre réponse doit inclure les
chefs n'ayant pas dirigé de projets et les projets n'ayant pas eu de sorties (Votre
réponse doit donc présenter 15 lignes, car il y a 15 chefs de projets).
67
TP récapitulatif : réalisation d'une application
Sujet : Tenue de stock.
Dans une démarche simplifiée de tenue de stock, des produits (N° Produit, Désignation) sont
fournis par des fournisseurs (N° Fournisseur, Raison sociale, Téléphone). Des bons de
livraisons (N° BonLiv, Date) indiquent les quantités fournies.
Des clients (N° Client, Raison sociale, Téléphone) peuvent commander différentes quantités
de différents produits. Pour ce faire, ils doivent établir des bons de commandes (N° BonCmd,
Date)
Questions :
 Etablir le MCD.
 Etablir le MLD.
 Implémenter la base de données en utilisant MS access.
 Réaliser une application qui comporte :
o Masques de saisie :
 Un masque de saisie des fournisseurs (+ recherche par nom et par
numéro).
 Un masque de saisie des produits (+ recherche par désignation et par
numéro).
 Un masque de saisie des clients (+ recherche par nom et par numéro).
 Un masque de saisie des commandes.
o Etats de sortie (impressions) :
 Liste des clients.
 Liste des fournisseurs.
 Liste des produits ayant atteint un seuil donné.
 Edition d'une commande d'un client donné.
 Liste des commandes d'un client entre 2 dates données.
68
EXAMENS
69
Centre Universitaire de BBA 3eme année Ingénieur 2005/2006
Institut d’Informatique Module Bases de données
Examen de rattrapage (durée 1H 30)

Cours non autorisé
Exercice 1 : 3 Pts
Soit la relation VEHICULES (N°_véhicule, Type_Véhicule, Kilométrage, Révision).
Traduire en SQL les requêtes suivantes :

1- L’utilisateur a besoin de la liste des véhicules dont le type-véhicule est ‘tracteur’.
Les véhicules doivent être classés en ordre croissant des kilométrages. 1Pts
2-Supposons que l’utilisateur ait besoin des mêmes informations en ordre décroissant. 1Pts
3- L’utilisateur a besoin de toutes les colonnes dans lesquelles le type_véhicule est ‘camion’
ou ‘tracteur’ et dont le kilométrage est supérieur à 1600. 1Pts
Exercice 2 : 6 Pts
Dans la base de données contenant la relation EMPLOYE (Nom, Lieu, Salaire, Chef),
Ecrire les requêtes suivantes :

1. Quels employés gagnent plus cher que leur chef ? 2Pts
2. Quels employés gagnent plus cher que n’importe quel chef ? 2Pts
3. Quels chefs ont des employés situés dans plusieurs lieux ? 2Pts
Exercice 3 : 8Pts
Soit la relation: COURS_ETUD(etudiant, age, cours, jour_semaine) avec les dépendances

fonctionnelles suivantes :
F = {etudiant  age, cours  jour_semaine }
1 Donnez un exemple concret de cette relation (avec au moins 6 tuples). 3Pts

2 Quelles sont les clés candidates de cette relation ? 1Pt
3 En quelle forme normale cette relation est-elle? Sur votre exemple concret, mettez en
évidence les problèmes qui peuvent survenir lors de la manipulation de cette table. 4Pts
Exercice 4 : (6 * 0.5)Pts
 Quand est ce que se produit une redondance des données ?

 Combien de parents, un enregistrement peut il avoir dans un modèle hiérarchique ?
 Combien de parents, un enregistrement peut il avoir dans un modèle réseau ?
 Un SGBD identifie un utilisateur autorisé par son…………. et son…………
 Qu’est ce qu’une transaction ?
 Quels sont les trois types de problèmes de concurrence susceptibles de se produire lors
de la manipulation d’une BD ?
70
1er Examen (durée 1H 30)

Documents non autorisés
Exercice 1 : le LMD (10 pts)
Dans le système LMD les formations sont organisées en semestres : La licence 6 semestres, le
Master 4 semestres et le doctorat minimum 6 semestres. Ces formations sont regroupées par
grands domaines (MI, ST…) qui recouvrent plusieurs disciplines (Maths, Informatique,
Médecine…)
Au cours de la licence, l'étudiant choisit une des mentions proposées. Exemple : Licence MI,
mention Informatique de gestion. Au cours du Master, il choisit une mention et
éventuellement une spécialité qui peut être déclinée en voie "recherche" ou "professionnelle".
Exemple : Master Sciences et technologie (ST), mention Sciences et technologie de
l'information et de la communication, spécialité réseau communication, voie recherche.
Chaque formation est constituée d'une combinaison d'Unités d'Enseignement (UE)

fondamentales, méthodologiques ou de découverte. Ces combinaisons sont définies par
l'Université en fonction du domaine, de la mention et pour les masters de la spécialité.
L’Unité d’Enseignement peut associer plusieurs matières (modules) et comprendre différentes

formes d’enseignement (cours, TD, TP, travail personnel etc.). Chaque UE a une valeur
définie en crédits. Un semestre est composé de plusieurs unités. La valeur totale des UE qui
composent un semestre est fixée à 30 crédits.
Questions :
13. Etablir un modèle entité association pour le système LMD.

Exercice 2 : le fournisseur, la commande et le produit (10 pts)
Soit la relation R (Fournisseur, Adresse, Raison-Sociale, no-Produit, Libellé-Produit,

Quantité, Prix, no-Commande, Délai, Date) et les dépendances fonctionnelles suivantes :
– no-Commande → Fournisseur, Délai, Date
– Fournisseur → Raison-Sociale, Adresse
– no-Commande, no-Produit → Quantité
– no-Produit, Fournisseur → Prix
– no-Produit → Libellé-Produit
Questions :
1) Donner quelques exemples de tuples correspondant à la relation R. (4 exemples)
2) Indiquer les clés candidates de la relation R. Justifier.
3) Citer les anomalies (par des exemples) qui se trouvent dans la relation R.
4) Décomposer la relation R afin de supprimer les anomalies.
5) En quelles formes normales sont les relations de 4? Justifier.
71
Bases de données : 2eme Examen

2eme Examen (durée 1H 30)

Exercice 1 :
On considère le schéma relationnel suivant qui modélise une application pour la gestion de
livres et de disques dans une médiathèque :
DISQUE (CodeOuv, Titre, Style, Pays, Année, Producteur)
Exemplaire_DISQUE (CodeOuv, NumExemplaire, DateAchat, Etat)
LIVRE (CodeOuv, Titre, Genre, Editeur, Collection)
Exemplaire _LIVRE (CodeOuv, NumExemplaire, DateAchat, Etat)
AUTEUR (CodeOuv, Identité)
ABONNE (NumAbo, Nom, Prénom, Rue, Ville, CodeP, Téléphone)
PRET (CodeOuv, NumEx, NumAbo, DatePrêt)
PERSONNEL (NumEmp, Nom, Prénom, Adresse, Fonction, SalaireMensuel)
Questions : 1+2+1+2+3+1+2+2
Q1 : Quel est le contenu de la relation LIVRE ?
Q2 : Liste des titres que l’on retrouve à la fois comme titre de disque et titre de livre ?
Q3 : Quels sont les différents styles de disques proposés ?
Q4 : Quel est le salaire annuel des membres du personnel gagnant plus de 150 000 DA en
ordonnant le résultat par salaire descendant et nom croissant ?

Q5 : Donnez le nombre de prêts en cours pour chaque famille en considérant qu’une famille
regroupe des personnes de même nom et possédant le même numéro de téléphone ?
Q6 : Quels sont les salaires minimum, maximum et moyen des employés exerçant une
fonction de bibliothécaire ?
Q7 : Quel est le nombre de disques achetés en 1998 ?
Q8 : Quels sont les titres des livres et des disques actuellement empruntés par
(Nom, Prénom) = (MAHMOUDI, Brahim) ?
Exercice 2 :
Soient les schémas relationnels R1, R2, R3 et R4 définis comme suit :
R1 (A: D1, B: D2)

R2 (C: D1, D: D2)
R3 (A: D1, E: D3)
R4 (B: D2)
Bases de données : 2eme Examen
Questions : 6 Pts
Donner l'équivalent SQL des expressions algébriques suivantes :
1. Projection :  A (R1)
2. Sélection :  < condition > (R1)
3. Produit cartésien : R1 X R2
4. Jointure: R1 * R3
5. Union: R1 U R2
6. Intersection: R1  R2
Support de cours de Bases de données Bouziane Abderraouf

Examen de synthèse (durée 1H 30)

Exercice 1 : 1+1+2.5+2.5+3 Attribut Désignation

Ancien Ancienneté dans le grade
Soit le schéma relationnel suivant : CdSexe Code sexe
Coeff Coefficient de la matière
ETUDIANTS (NumEtu, NomEtu, DateNais,
CdSexe)
Datenais Date de naissance
MATIERS (NuMat, NoMat, Coeff, NumEns)
Grade Grade de l'enseignant
ENSEIGNANTS (NumEns, NomEns, Grade,
LbSexe Libellé du sexe
Ancien)
NoMat Nom de la matière
NOTES (NumEtu, NuMat, Note)
NomEns Nom de l'enseignant
SEXE (CdsSexe, LbSexe)
NomTtu Nom de l'étudiant
Questions : Note Note obtenue à la matière

NuMat N° de la matière
A partir de la Base de données ETUDES, définie
NuMens N° de l'enseignant
ci-dessus, écrire les requêtes SQL permettant
NuMetu N° de l'étudiant
de répondre aux questions suivantes :
1. Afficher le nom et le grade des enseignants d'histoire.
2. Afficher le nom et le coefficient des matières qui sont enseignées par des maîtres de
conférences ou des assistants.
3. Afficher le nom et le sexe des étudiants qui ont eu une note d'informatique supérieure
à la moyenne générale de la classe.
4. Afficher, les matières pour lesquelles la moyenne des notes est inférieure à 10.
Afficher le nom de l'enseignant correspondant.
5. Afficher, pour chaque matière, qu'elle est la meilleure note et quel est l'étudiant qui l'a
obtenue.
Exercice 2 : 10 Pts
Une agence de location de maisons et d’appartements désire gérer sa liste de logements. Elle
voudrait en effet connaître l’implantation de chaque logement (nom de la commune et du
quartier) ainsi que les personnes qui les occupent (les signataires uniquement).
Le loyer dépend d’un logement, mais en fonction de son type (maison, studio, F3, F4...)
l’agence facturera toujours en plus du loyer la même somme forfaitaire à ses clients. Par
exemple, le prix d’un studio sera toujours égal au prix du loyer + 2000 DA de charges
forfaitaires par mois.
Pour chaque logement, on veut disposer également de l’adresse, de la superficie ainsi que du
loyer.
Quant aux individus qui occupent les logements (les signataires du contrat uniquement), on se
contentera de leurs noms, prénoms, date de naissance et numéro de téléphone.
74
Pour chaque commune, on désire connaître le nombre d’habitants ainsi que la distance
séparant la commune de l’agence.
NB : on ne gérera pas l’historique de l’occupation des logements par les individus. On

considèrera de plus qu’un individu ne peut être signataire que d’un seul contrat.
Questions :
Etablir le modèle conceptuel des données correspondant puis le modèle logique associé.
75

Département d’Informatique Module Bases de données
1er Examen (durée 1H 30)

Exercice 1 : le cirque (12 pts)
Les organisateurs d’un cirque veulent monter une base de données pour gérer les réservations
des spectateurs, le choix des numéros et l’organisation des différents spectacles.
Le cirque dure sept jours et chaque demi-journée est consacrée à un spectacle qui regroupe
des numéros portant sur le même thème (magie, acrobaties, dressage d’animaux ...).
L'espace réservé aux spectateurs est divisé en plusieurs zones regroupant des places numérotées.
Le tarif de la réservation dépend de l'endroit de la place et du spectacle choisi.
Chaque numéro proposé est caractérisé par un code, son nom, son thème et sa durée moyenne
en minutes (de 20 à 25 minutes). De plus on souhaite savoir l’instrument utilisé pour les numéros
musicaux, l’animal concerné par les numéros de dressage et le type des acrobaties (équilibrisme,
trapèze volant, …), etc. On maintient aussi le nombre des artistes présents sur scène
Chaque artiste possède un numéro (en général son numéro de carte d’identité), son nom,
son prénom, sa date de naissance, son adresse, le ou les numéros qu’il propose puisque les artistes
sont susceptibles de présenter plusieurs numéros.
Pour chaque spectacle, on garde le code, le thème, le jour, l’heure de début, l’heure de fin,
le président (celui qui anime le spectacle, présente les artistes, etc., c’est un artiste d’un autre
numéro), la liste des numéros du spectacle, avec leur heure de passage et le coût d'entrée
pour le spectacle (tous les spectacles n’ont pas le même coût d’entrée).
Questions :

Exercice 2 : (8 pts)
On considère le schéma relationnel R défini sur les attributs suivants :

(C : cours ; P : professeur ; H : heure ; S : salle ; E : étudiant ; N : note)
Un n-uplet (c, p, h, s, e, n) a pour signification que le cours c est fait par le professeur p à l'heure h
dans la salle s pour l'étudiant e qui a reçu la note n.
L'ensemble E des dépendances fonctionnelles initiales est le suivant :
E = {C• P, (H, S) • C, (H, P)• S, (C, E)• N, (H, E) • S}
Questions :
6) Donner quelques exemples de tuples correspondant à la relation R. (4 exemples)
7) Donner l'ensemble des dépendances fonctionnelles élémentaires engendrées par E.
8) Quelle est la clé de la relation R ? Montrer qu'elle est unique.
9) Quelle est la forme normale de la relation R ? Si elle n'est pas en 3FN proposer une
décomposition en 3FN.
76
Centre universitaire de BBA 2eme année Licence Informatique

Département d’Informatique Matière : BDD
Année universitaire : 2007/2008
Examen (durée 1h30)

Exercice 1 :
Soit la fiche de stock suivante.
Fiche de valorisation des stocks

Désignation du produit : cartouche d'encre pour imprimante HP 2500CM
Réf. Produit : EncreHP2500CM
Entrée Sortie Stock
Date Bon N° Service
Qt P.U. Montant Qt P.U. Montant Qt P.U.M.P* Montant
demandeur
……. 17 2300 39100
12/06/08 1208 3 2300 6900 MGX 14 2300 32200
15/06/08 108 2 2400 4800 16 2312,5 37000
…….
*
: PUMP (Prix Unitaire Moyen Pondéré) = (Valeur du stock la veille de l'entrée + Valeur de
l'entrée) / Quantité totale en stock après l'entrée.
Questions:
1. Etablir un MCD correspondant à cette fiche de stock.

2. Faut-il prévoir un champ dans la base de données pour sauvegarder la quantité en
stock? (Discuter)
3. Ecrire une requête qui affiche, pour chaque produit, le total des quantités sorties
réparti par service demandeur.
Exercice 2 :
Dans une démarche simplifiée de tenue de stock, des produits (N° Produit, Désignation) sont
fournis par des fournisseurs (N° Fournisseur, Raison sociale, Téléphone). Des bons de
livraisons (N° BonLiv, Date) indiquent les quantités fournies pour chaque produit fourni.
Des clients (N° Client, Raison sociale, Téléphone) peuvent commander différentes quantités
de différents produits. Pour ce faire, ils doivent établir des bons de commandes (N° BonCmd,
Date) indiquant les quantités commandées.
Question :
Quelle(s) est (sont) la (les) dépendance(s) fonctionnelle(s) qu'on peut dégager de cette
description?
Exercice 3 :
77
Soit le MCD suivant.
Exprimer en SQL les requêtes suivantes :
1. De quel pays est originaire un coureur ?

2. Quels sont les coureurs d'une équipe donnée ?
3. Combien de kilomètres vont parcourir au total les coureurs qui font toutes les étapes ?
4. Quel est le meilleur temps réalisé pour une étape ?
5. Bon courage.
78
Centre universitaire de BBA 2eme année Licence Informatique

Département d’Informatique Matière : BDD
Année universitaire : 2007/2008
Examen de rattrapage (durée 1h30)

Exercice 1:
Soit R une relation composée des attributs (A, B, C, D, E, G, H)
et F l'ensemble des dépendances fonctionnelles satisfaites par cette relation
F = {AB  C ; B  D ; CD  E ; CE  GH ; G  A}.
Question :
 Montrer que :
1) AB  E. 2) BG  C. 3) AB  G.
 Quelles sont les clés candidates de cette relation ?
Exercice 2:
Soit la base de données suivante :
DEPARTEMENT (nodep, nomdep, ville)

EMPLOYES (noemp, nomemp, fonction, noresp, datemb, sala, comm, nodep )
PRIMES ( noemp, fonction, sala, comm )
GRADE ( grade, salmin, salmax )
Exprimez les requêtes suivantes en SQL
1) Donnez la liste des employés ayant une commission.

2) Donnez les noms, emplois (fonctions) et salaires des employés par emploi croissant, et
pour chaque emploi, par salaire décroissant
3) Donnez le salaire moyen du département Production
4) Donnez les noms des employés ayant le salaire maximum dans chaque département
5) Donnez les différentes professions et leur salaire moyen
Exercice 3:
Soit la relation VEHICULES (N°_véhicule, Type_Véhicule, Kilométrage, Révision).
Traduire en SQL les requêtes suivantes :

1. L’utilisateur a besoin de la liste des véhicules dont le type-véhicule est ‘tracteur’.
Les véhicules doivent être classés en ordre croissant des kilométrages.
2. Supposons que l’utilisateur ait besoin des mêmes informations en ordre décroissant.
3. L’utilisateur a besoin de toutes les colonnes dans lesquelles le type_véhicule est
‘camion’ ou ‘tracteur’ et dont le kilométrage est supérieur à 1600.
79
Partie II :
Bases de donnée réparties
PARTIE II : Bases de donnée réparties Bouziane Abderraouf
Chapitre VI
Common Object Request Broker Architecture:
CORBA [GEI 99][ACR 99][HEN 99][BOR]…
VI.1. Introduction
Dans une application distribuée, plusieurs éléments logiciels et matériels sont impliqués, entre
autres, les ordinateurs, les réseaux, les protocoles de communication, etc.
Cela fait que la conception et le déploiement de telles applications sont une tâche difficile,
du moment qu’on doit tenir compte des hétérogénéités des protocoles de communication, des
systèmes d’exploitation, des machines et des langages de programmation.
Plusieurs architectures ont été proposées afin de permettre aux logiciels de coopérer malgré
la différence de langages, d’interfaces et d’environnements d’exécution.
La norme CORBA constitue l’aboutissement actuel de telles architectures. En plus, CORBA
permet la préservation des applications existantes en gardant le noyau (partie critique)
de ces applications et les faire migrer progressivement.
Il est certain que cela va contribuer considérablement dans un investissement visant
la réécriture des applications d’une entreprise en vue d’accéder aux nouvelles technologies
VI.2. CORBA, une plate forme répartie orientée objet

La réalisation des applications distribuées nécessite la prise en compte de deux facteurs
essentiels, à savoir : gestion de la communication entre parties éloignées et la gestion
de l’hétérogénéité de tous les éléments intervenants dans cette distribution.
Plusieurs approches de programmations distribuées existent à nos jours tels que les sockets
TCP/IP, l’appel de procédure à distance (RPC) ou encore l’invocation de méthode à distance
(RMI).
Contrairement aux sockets, qui ne gèrent pas l’hétérogénéité des paquets d’octet transmis,
l’appel de procédure à distance le fait. Il reste restreint à des environnements non-objets.
Quant à l’invocation des méthodes à distance (RMI), bien qu’elle soit orientée objet,
elle est restreinte au langage Java.
CORBA, normalisée suite à un consensus international, vient apporter une solution à la fois
orientée objet et inter opérable. Ce middleware propose des normes à respecter pour
que les utilisateurs puissent bénéficier d’une :
Indépendance entre l’application et l’environnement d’exécution : Etant donnée

que chaque système à ses spécificités quant à la mise en œuvre de la communication
et l’accès au matériel, CORBA propose l’utilisation des objets mandataires situés entre
80
l’objet réel et l’environnement d’exécution masquant les spécificités

de cet environnement.
Portabilité des applications : Etant séparé de l’environnement d’exécution, le code
de l’application distribuée peut être facilement utilisé dans un autre système grâce
à une seule une re-compilation de ce code.
Programmation répartie plus aisée : Etant orienté objet et offrant des mécanismes
de connexion transparents, l’accès à un objet distant se fait de la même façon
que l’accès à un objet local.
Utilisation des services partagés distribués : CORBA offre une gamme de services
standardisés parmi les quels on trouve le service de localisation des objets distants,
le service sécurité, etc.
Pour pouvoir fournir les avantages cités ci-dessus, CORBA utilise un bus logiciel
qui :
Interconnecte les applications d’une façon transparente.

Permet l’interopérabilité des environnements d’exécution sous-jacents (langages,
systèmes d’exploitation, machines et protocoles de communication).
La définition de CORBA sera alors : [ACR 99]

‘CORBA est un middleware objet. Il permet à des systèmes hétérogènes de communiquer via
un langage commun et un ensemble d’outils standardisés. Il repose sur la notion de bus
logiciel appelé : ORB’.
VI.3. CORBA, les concepts

VI.3.1. Le modèle objet CORBA
La communication dans la norme CORBA se fait selon l’architecture client/serveur objet,
où des clients émettent leurs requêtes à destination d’objets s’exécutant au niveau
des serveurs où ils sont localisés. Les résultats seront transmis aux clients demandeurs.
Pour rendre cette communication transparente et opérable dans des milieux hétérogènes,
CORBA s’appuie principalement sur le langage IDL et l’ORB.
VI.3.1.1. IDL
Le langage IDL permet une séparation entre les services fournis et l’environnement de leurs
implémentations. Pour ce faire, ce langage orienté objet :
Est basé sur notion d’interface, où n’est décrite que la partie visible de l’objet serveur.
En plus cette interface constitue un contrat, englobant méthodes et données,
que le serveur s’engage à fournir à ces éventuels clients.
Permet une séparation entre la description de l’interface de l’objet
et de son implémentation.
Est indépendant des langages de programmation. La traduction de cette interface
en un langage particulier est faite en utilisant le compilateur adéquat.
Ainsi, le client qui veut utiliser un objet CORBA se contente de récupérer son interface
(sur une disquette, un bout de papier..) et de se renseigner sur les modalités de son utilisation
(exemple : Objet fournissant la somme de deux nombres ne sera disponible qu’entre 18h
et 20h…..). Hormis cela, il est libre de choisir le langage d’implémentation, le système
d’exploitation d’hébergement, …etc.
81
VI.3.1.2. L’ORB
Il constitue le 2eme pole de CORBA. Il complémente le langage IDL dans le processus
d’interopérabilité et fournit, également, les mécanismes permettant aux objets d’inter changer
les messages d’une manière transparente.
Il permet aussi de : [DEV 02]

Trouver l’implémentation de l’objet serveur.
Préparer cette implémentation à recevoir la requête.
Communiquer les données constituant la requêtes ainsi que le résultat de cette
exécution.
L’ORB est défini par un ensemble d’interfaces, plutôt qu’un seul objet. Du point de vue
programmation, il se présente sous la forme d’un fichier que le développeur doit intégrer
à son application (en C++ c’est « CORBA.h »). On distingue deux composants quant
à la macrostructure de l’ORB à savoir :
VI.3.1.2.1. Noyau de L’ORB
A la base des interfaces de l’ORB se trouve son noyau. Il assure le transport des requêtes inter
objet en prenant en charge la couche de communication, les protocoles et les outils
de communication nécessaires.
L’accès à ce noyau se fait à travers des interfaces standard fournies par l’ORB
VI.3.1.2.2. Interfaces de l’ORB
Situées au-dessus du noyau de l’ORB, ces interfaces permettent aux objets clients et serveurs
d’accéder aux fonctionnalités de l’ORB. L’accès à ces interfaces se fait via des APIs
communes aux ensembles des langages de programmation et des systèmes d’exploitation.
Ainsi, pour pouvoir utiliser les services de l’ORB, le développeur doit :
1- se connecter à l’ORB, pour s’ouvrir la porte à ces interfaces

Exemple: CORBA ::ORB_var MyOrb = CORBA ::ORB_int (argc, argv )
2- Connaître le contexte et les scénarios d’utilisation des APIs de ces interfaces.
VI.3.2. Les composants de l’ORB CORBA

La figure suivante illustre les interfaces (composants) du BUS CORBA.
Application Client Application Serveur
SII DII Interface Interface SSI DSI Interface

de L’ORB de L’ORB du BOA
Noyau de L’ORB (protocole IIOP)
Référentiel Référentiel
d’interfaces d’implémentations
Fig II-6. Les composants de l’ORB CORBA 82

VI.3.2.1. STUB (SSI)

Utilisée coté client, l’interface d’invocation statique (stub) est le résultat de la compilation
de l’interface IDL de l’objet. Son rôle consiste à :
• Accepter les requêtes des clients
• Les emballer (marshalling) pour être transportables sous réseau.
• Les passer à l’ORB
• Déballer (un-marshalling) les résultats de leurs exécutions.
• Renvoyer les résultats à l’objet demandeur.
A noter que le client aura besoin d’autant de stubs que d’interfaces IDL utilisées.
VI.3.2.2. L’interface d’invocation dynamique (DVI)
C’est une alternative du SVI. Contrairement au stub, le DVI ne nécessite pas une connaissance
Compile–Time du type d’objet à invoquer. Son type sera identifié au moment de l’exécution
du client. Le gain apporté par la flexibilité de ce mécanisme nécessite une mise en œuvre
complexe.
VI.3.2.3. Le référentiel d’interface
C’est une base de données qui permet un stockage permanent des interfaces IDL.
Ce référentiel peut être utilisé, à volonté, par le serveur ou le client pour plusieurs raisons,
parmi les quelles : La vérification des signatures des méthodes invoquées.
VI.3.2.4. L’interface de l’ORB
C’est un ensemble d’APIs qui permet la configuration des bus CORBA pour pouvoir accéder,
par la suite, à ses déférentes fonctionnalités.
VI.3.2.5. Le Skelton (SSI)
Utilisée coté serveur, l’interface, de squelette statique, est générée automatiquement à partir
de la définition IDL de l’objet serveur. Elle offre les mêmes fonctionnalités du stub
(à l’exception de celles qui sont propres à une exécution serveur) ce qui permet à la partie
implémentation de l’objet de se dégager des aspects propres à la communication.
VI.3.2.6. L’interface de squelettes dynamique
Par symétrie à la DVI, la SVI permet à l’objet serveur d’accepter des requêtes, en provenance
des clients, sans avoir au préalable une couche de communication permettant le déballage
de la requête (i.e. le Skelton).
VI.3.2.7. L’adaptateur d’objet
C’est un outil coté serveur qui permet l’accès à différents types d’objets
(processus, bases de données, etc.). Il permet, aussi, l’interaction entre l’objet serveur
et l’ORB et autres : [ACR 99]
D’appeler des méthodes standards pour créer et détruire les d’objets.

De déterminer l’état d’objet.
De transmettre à l’objet les demandes émises par les différents clients
D’activer un objet lorsqu’une requête lui en est destinée.
VI.3.2.8. Le référentiel des implémentations
C’est une base de données persistante qui contient des informations permettant
à l’ORB de localiser et activer l’objet. Parmi les informations qui peuvent y figurer
on trouve : [GEI 99]
Le nom de l’exécutable du code de l’objet.
Le mode d’activation de l’objet.
Etc.
83
Plusieurs services ont été proposés pour l’exploitation de ce référentiel parmi les quels l’OAD
de VISIBROKER et le démon d’ORBIX (ils sont incorporés à leurs ORB respectifs)
VI.3.2.9. Le noyau de communication
Pour permettre l’interopérabilité, CORBA se base sur le langage IDL et le bus ORB.
Le langage IDL permet, l’interopérabilité au niveau langage de programmation alors
que l’ORB permet l’interopérabilité au niveau protocole de communication.
Plusieurs solutions ont été proposées pour permettre la communication dans un milieu
hétérogène parmi les quelles : [GEI 99]
La communication par un pont de conversion de protocoles.

La communication par des semi-ponts génériques.
L’aboutissement actuel est l’utilisation du protocole VIOP qui est basé sur le protocole
TCP/IP et adapté à la norme CORBA.
La figure suivante illustre le déroulement d’une exécution « à la CORBA » :
VI.3.3. Le modèle de communication CORBA
Application client Application serveur
Interface de l’objet
IOR
1
Stub
2 3 8
client
13 7 9
12
Skelton
6
10
Adaptateur
d’objet
11
Fig II-7. Déroulement d’une exécution CORBA
D’abord, pour pouvoir communiquer avec le serveur, le client doit avoir une interface IDL
décrivant les fonctionnalités exposées par l’objet serveur. Cette interface contient, entre
84
autres, des descriptions des méthodes, des attributs, types d'attributs et des signatures
des méthodes.
La compilation de cette interface donnera naissance à deux modules stub (client) et Skelton
(serveur) qui seront chargés de la partie communication, des applications client et serveur.
Une fois cette infrastructure préparée, le client, à travers l’ORB, récupère une référence
sur l’objet serveur (1) contenant les données nécessaires à l’ORB pour localiser cet objet
distant. Cette référence sera mise à jour automatiquement et implicitement si l’objet change
de site.
Ensuite, le client invoque une méthode disponible dans l’interface de l’objet (2). Une fois
l’invocation faite, la référence de l’objet, l’opération à réaliser ainsi que les arguments
en entrées sont emballés dans une requête par le stub (3) et transmis via l’ORB au serveur
(4).
Une fois la requête arrivée à l’adaptateur d’objet, ce dernier active l’objet en question (5)
selon l’une des stratégies suivantes : [ACR 99]
Activation partagée : un seul serveur est activé par une implémentation donnée,
et ce, quel que soit le nombre de clients.
Activation par client : un serveur est activé par client et est désactivé dès que
le client se déconnecte.
Activation par méthode : un serveur est activé à chaque appel de méthode
et est désactivé à la fin de la méthode.
Une fois l’objet activé, le Skelton reçoit la requête, déballe les informations qui y sont
contenues (6) puis invoque l’objet réel (7). Les informations seront traitées par cet objet (8)
et renvoyées au Skelton (9) qui emballe les résultats (10) et les transfert au client via le bus
CORBA (11). A ce stade le stub déballe ces résultats et les retourne à l’objet appelant.
Si cet appel n’aboutit pas, une exception sera retournée au client. Toute cette panoplie
de transactions se déroule sans que le client s’aperçoive de ces détails.
VI.4. Autres solutions réparties orientées objet

Pour remédier aux problèmes liés à la distribution, plusieurs solutions ont été proposées. Nous
décrivons sommairement dans ce qui suit les solutions DCOM et Java RMI.
VI.4.1. DCOM
A l’origine de cette norme se trouvent les objets OLE qui ont donné, par la suite, naissance
aux objets COM. Pour ne pas remettre en cause le modèle COM, DCOM constitue son
extension dans le milieu distribué.
Malgré sa conception pour être utilisé sous différentes plates formes, DCOM est, fortement,
lié à l’environnement Windows ce qui diminue de son efficacité dans le domaine
d’interopérabilité
VI.4.2. Java RMI

RMI est aussi un standard pour la programmation distribuée. Il tire sa puissance du langage
Java qui est indépendant des systèmes d’exploitation. Il présente plusieurs avantages
[RUI 02], entre autres, l’extension du « garbage collector » pour un environnement distribué.
Cependant, Java peut être à l'origine de la faiblesse du RMI car ce dernier en est totalement
dépendant. Dès qu’un élément non Java entre dans une conception basée sur RMI, ce modèle
ne fonctionne pas.
85
VI.5. La mise en place d’une application CORBA

L’OMG n’impose pas de processus de conception et de développement d’applications
distribuées. La norme CORBA laisse une entière liberté sur le choix des outils à mettre
en oeuvre.
Néanmoins, la mise en place d’une application CORBA suit toujours à peu près le même
scénario :
1. La définition du contrat IDL : à partir du cahier des charges, il faut définir les objets
composant l’application à l’aide d’une méthodologie orientée objet (e.g. UML). Cette
modélisation est ensuite traduite sous la forme de contrats IDL composés
des interfaces des objets et des types de données utiles aux échanges d’informations
entre les objets.
2. La pré-compilation du contrat IDL : les interfaces des objets sont décrites dans des
fichiers texte. Le pré-compilateur prend en entrée un tel fichier et opère un contrôle
syntaxique et sémantique des définitions OMG-IDL contenues dans ce fichier. Le pré-
compilateur peut aussi charger ces définitions dans le référentiel des interfaces. C'est
la partie frontale commune à tous les pré-compilateurs IDL.
3. La projection vers les langages de programmation : le pré-compilateur IDL génère
le code des souches, qui sera utilisé par les applications clientes des interfaces décrites
dans le fichier IDL, ainsi que le code des squelettes pour les programmes serveurs
implantant ces types. Cette projection est spécifique à chaque langage
de programmation. Un environnement CORBA fournit un pré-compilateur IDL pour
chacun des langages supportés.
4. L'implantation des interfaces IDL : en complétant et/ou en réutilisant le code généré
pour les squelettes, le développeur implante les objets dans le langage de son choix.
Il doit tout de même se plier aux règles de projection vers ce langage.
5. L'implantation des serveurs d'objets : le développeur doit écrire les programmes
serveurs qui incluent l'implantation des objets et les squelettes pré-générés.
Ces programmes contiennent le code pour se connecter au bus, instancier les objets
racines du serveur, rendre publiques les références sur ces objets à l'aide par exemple
du service "Nommage" et se mettre en attente de requêtes pour ces objets. Le nombre
de programmes serveurs est tout de même souvent limité.
6. L'implantation des applications clientes des objets : le développeur écrit un ensemble
de programmes clients qui agissent sur les objets en les parcourant et en invoquant des
opérations sur ceux-ci. Ces programmes incluent le code des souches, le code pour
l'interface Homme-Machine et le code spécifique à l'application. Les clients
obtiennent les références des objets serveurs en consultant le service Nommage. Il faut
tout de même souvent développer une multitude de programmes clients des objets
en fonction des rôles et des activités de chacun des utilisateurs de l’application
répartie.
7. L'installation et la configuration des serveurs : cette phase consiste à installer dans
le référentiel des implantations les serveurs pour automatiser leur activation lorsque
des requêtes arrivent pour leurs objets.
8. La diffusion et la configuration des clients : une fois les programmes clients mis au
point, il est nécessaire de diffuser les exécutables sur les sites de leur future utilisation
et de configurer les sites clients pour qu'ils sachent où se trouvent les serveurs utilisés.
9. L'exécution répartie de l’application : enfin, l'exploitation de l’application peut
commencer. Le bus d'objets répartis CORBA assure alors les communications entre
les programmes clients et les objets via le protocole VIOP.
86
Chapitre VII
CORBA et les bases de données
VII.1. Introduction
Les bases de données sont un moyen efficace pour l’enregistrement de l’information.
Elles constituent un environnement capable de recevoir des données structurées selon
des conceptions définies par l’utilisateur et sont exploitées par un système offrant, entre
autres, un LDD et un LMD.
Plusieurs types de bases de données sont utilisés, parmi elles, les bases de données
relationnelles et les bases de données orientées objet.
Néanmoins, la mise en place des bases de données, dans un milieu réparti, nécessite la prise
en charge des problèmes liés à la distribution. Notamment ceux de l’hétérogénéité des plates
formes utilisées et la transparence de traitement.
Une fois la base de données conçue pour un contexte réparti, CORBA, apporte des solutions
aux problèmes déjà cités, tout en offrant les apports du paradigme orienté objet.
Dans ce qui suit, nous allons définir les bases de données relationnelles. Nous allons détailler
le mapping de l’orienté objet VIIers le relationnel. Nous VIIerrons, enfin, le concept de
systèmes multi-bases de données et quelques concepts liés aux bases de données réparties.
VII.2. Les bases de données relationnelles

Dans ce modèle, les données sont représentées par le concept de relation. Une relation
est une table à deux dimensions permettant de dégager l’utilisateur des détails
d’implémentation. L’état cohérent de la base de données est défini par un ensemble
de contraintes d’intégrité.
Les objectifs du modèle relationnel sont : [YOL 02]

Proposer des schémas de données faciles à utiliser.
Améliorer l'indépendance logique et physique.
Mettre à la disposition des utilisateurs, des langages de haut niveau pouvant
éventuellement être utilisés par des non informaticiens.
Optimiser les accès à la base de données.
Améliorer l'intégrité et la confidentialité.
Basé sur des théories mathématiques, le modèle relationnel fournit des opérateurs de l'algèbre
relationnelle permettant la manipulation des données, et qui se résument en : [YOL 02]
87
Projection : Opération qui consiste à supprimer des attributs d'une relation

et à éliminer les tuples en double apparaissant dans la nouvelle relation.
Restriction : Opération qui consiste à supprimer les tuples d'une relation
ne satisfaisant pas la condition précisée.
Jointure : Opération qui consiste à faire le produit cartésien de deux relations, puis
à supprimer les tuples ne satisfaisant pas une condition portant sur un attribut
de la première relation et sur un attribut de la seconde.
Union : Opération portant sur deux relations ayant le même schéma et construisant
une troisième relation constituée des tuples appartenant à chaque relation. Les tuples
en double sont éliminés.
Différence relationnelle : Opération portant sur deux relations ayant le même schéma
et construisant une troisième relation dont les tuples sont constitués de ceux
ne se trouvant que dans une seule relation.
Intersection : Opération portant sur deux relations ayant le même schéma
et construisant une troisième relation dont les tuples sont constitués de ceux
appartenant aux deux relations.
Ces opérateurs sont exploités par des langages spécifiques incorporables dans les langages
de programmation de haut niVIIeau. Parmi ces langages, on retrouve le SQL (Structured
Query Language) qui est à la fois :
Un langage d'interrogation de données (LID) : SELECT.

Un langage de manipulation de données (LMD) : UPDATE, INSERT, DELETE.
Un langage de définition de données (LDD) : ALTER, CREATE, DROP.
Un langage de contrôle de données et des utilisateurs (LCD) : GRANT, REVIIOKE.
Pour conclure ce paragraphe, certaines remarques sont à considérer quant à l’appréciation

d’un outil relationnel, notamment : [YOL 02]
Un système est dit minimalement relationnel s'il satisfait aux conditions suivantes :
• Toute information dans la base est représentée par des valeurs dans des tables.
• Il n'y a pas de pointeurs visibles, par l'utilisateur, entre les tables.
• Le système doit supporter, au moins, les opérateurs relationnels de restriction
et de projection.
Un système est dit complètement relationnel s'il satisfait, en plus, aux conditions
suivantes :
• Il supporte tous les opérateurs de l'algèbre relationnelle.
• Il supporte la contrainte d'unicité de clé d'une relation.
• Il supporte les contraintes référentielles qui permettent de s'assurer que la valeur
d'une donnée d'une relation existe dans une autre relation (notion de foreign key).
VII.3. Mapping de l’orienté objet vers le modèle relationnel [RUM 94]

Chaque classe se représente par une ou plusieurs tables. (Une table peut également
correspondre à plusieurs classes) les objets dans une classe peuvent être découpés
horizontalement et/ou verticalement.
88
Par exemple, si une classe possède beaucoup d’instances, parmi lesquelles peu sont souvent
référencées, le découpage horizontal peut améliorer l’efficacité en plaçant les objets aux quels
on accède fréquemment dans une table et le reste dans une autre table.
De la même façon, si une classe possède des attributs avec des configurations d’accès
différentes, il peut être utile de partitionner les objets verticalement
Code_mach Désignation Section
721 boutonneuse sacherie

525 Auto-platine boite
Partition
horizontale
Code_mach Désignation Section
432 Offset sacherie
Code_mach Désignation
721 Boutonneuse
525 Auto-platine
Partition 432 Offset
verticale
Code_mach Section
721 sacherie
525 boite
432 boite
Fig V-19. Découpages horizontaux et verticaux de la table équipement
VII.3.1. traduction d’une association binaire en table
Modèle Equipement
Objet
Code _mach
Désignation
Section
Table Code_mach Désignation Section

Modèle
De Equipement
Table
Clé : Code_mach
Fig V-20. Représentation d’une classe en une table
89
Dans la figure 2, un objet d’une classe se convertit en une table. La classe équipement
possède les attributs(Code_mach, Désignation, Section ). Le modèle de table liste
ces attributs.
Exemple :
contient
Modèle Equipement Article
Objet 1..* 1..*
Code_mach Code_Art
Design Design
section stock
Table :Equipement Table :Article Contient
Modèle Code_mach Code_Art Code_mach

Design Design Code_Art
De stock
section
Table
Fig V-21. Traduction d’une association binaire en tables
VII.3.2. Traduction des associations binaires avec classe d’association, en table

Si l’association est représentée par une classe d’association, on ajoute les attributs
de cette classe dans la nouvelle relation
Modèle Article 1..* contient 1..* BRG

Objet Code_Art
Design NumBRG
Stock Date
R7
Qt
Table :Article Table :BRG Table :R7

Code_Art NumBRG NumBRG
Design Date Code_Art
Modèle Stock Qt
De
Table
Fig V-22. Traduction des associations binaire avec classe association en tables
90
VII.3.3. Traduction d’une association de degré >2

• On doit créer une relation pour traduire l’association
• La clé de cette relation est formée d’un ensemble formé des clés des tables
qui traduisent les classes intervenant dans l’association
1..* 1..*
Modèle Intervention Operation
objet
N°BT Code_op
Instance Design
D_émission Mode_op
1..*
Intervenant
Code_intrv
nom
Table :intervention Table :intervenant Table :operation Table :R6

Modèle N°BT Code_op N°BT
Code_intrv
De Instance Design Code_intrv
nom
Table D_emmission Mode_op Code_op
Fig V-23. Traduction d’une association de degré >2
VII.3.3. Traduction de l’héritage en table

Plusieurs solutions :
• Une table pour la super-classe et pour chaque sous- classe,
• Des tables, uniquement, pour les sous- classes.
• Pour les classes non abstraites avec sous-classes : à chaque classe (mère ou fille)
correspond une table dans la base de données.
Table :BON
BON
Date
Date enregistré
Enregistré
Modèle Objet Modèle Table
Table :BRG Table :BSM
BRG BSM Clé :NumBRG Clé :NumBSM

Date Date
enregistré enregistré
NumBSM
NumBRG
Fig V-24. Traduction de l’héritage pour une classe non abstraite
91
Dans l’application GMAO, les super-classes sont abstraites. Nous avons dupliqué leurs
attributs dans chaque table de sous-classe.
Exemple :
Table :BRG
BON
Clé :NumBRG
Date
Date
enregistré
Enregistré
Modèle Objet Modèle Table
Table :BSM
BRG BSM Clé :NumBSM

Date
enregistré
NumBSM
NumBRG
Fig V-25. Traduction de l’héritage pour une classe abstraite
VII.4. Mapping du relationnel vers l’orienté objet [BOR]

Pour la traduction d’une table vers le modèle objet, nous avons utilisé des objets médiateurs
dotés de fonctions spéciales. Leur rôle consiste en la manipulation directe de la table
physique (extraction des informations selon un critère, enregistrement de l’information,
exécution des codes SQL, etc.), et la fourniture d’une interface incorporable dans le modèle
objet.
Chaque classe de notre modèle objet utilise un objet médiateur ayant comme attributs,
ceux de la classe correspondante.
Exemple : l’objet médiateur de la classe intervention.
92
VII.5. Systèmes multi-bases de données

Un SMBD est une fédération de systèmes de bases de données préexistants, autonomes,
et éventuellement hétérogènes. Les SGBDs participant à cette fédération sont appelés SGBD
locaux.
A ces SGBDs est rajoutée une couche logicielle permettant un accès uniforme à toutes
les bases de données locales. Les utilisateurs accèdent à la base de données répartie comme
s’il s’agissait d’une base de données locale.
VII.5.1. Caractéristiques des systèmes multi-bases de données

Les SMBD sont caractérisés essentiellement par : [BUK 96]
Autonomie : conséquence directe de l’indépendance des sites. Elle est nette dans
les aspects suivants :
• Conception : aucun changement ne peut être fait sur la conception initiale
des SGBD locaux.
• Exécution : les SGBD locaux gardent un contrôle total sur tout ce qui s’exécutent
sur leurs sites sans interférence avec les opérations provenant de l’extérieur.
Hétérogénéité : conséquence de la diversification des outils utilisés, exemple :
les SGBD locaux, les systèmes d’exploitation, les systèmes de communication,
le matériel, etc.
Distribution : due à la préexistence des bases de données situées dans des sites
distants.
93
VII.5.2. Approches de conception des bases de données réparties

Il existe deux approches de conception des bases de données réparties, l’approche ascendante
et l’approche descendante :
VII.5.2.1. L’approche ascendante
A partir des bases de données existantes, le concepteur constitue une base de données répartie,
cependant il doit prendre en compte les éventuelles hétérogénéités sémantiques ( exemple :
des attributs ayant le même nom et des significations différentes), et syntaxiques (le même
format de requête est interprété différemment par les SGBD locaux).
BD Globale
BD BD BD
Locale1 Locale2 Locale n
Fig V-26. Approche ascendante de conception des bases de données réparties
VII.5.2.2. L’approche descendante

A partir d’un schéma conceptuel global, le concepteur décompose la base de données relative,
suivant des schémas conceptuels spécifiques à chaque site destiné à contenir une partie
de cette base. Des stratégies de duplication et de fragmentation des données doivent être
définies
BD Globale
BD BD BD
Locale1 Locale2 Locale n
Fig V-27. Approche ascendante de conception des bases de données réparties
94
Dans l’étude du cas GMAO, nous avons adopté l’approche descendante. Nous avons fait,
d’abord, une conception globale du système, permettant de maintenir une vision unique
de la base de données. Ensuite nous avons élaboré pour chaque site, le schéma conceptuel
local correspondant.
Les figures suivantes illustrent l’aspect logique global du système GMAO et ses aspects
locaux.
Pièce de rechange Maintenance
Diag V-39. Aspect logique global du système GMAO
LANCEMENT PREPARATION
EXECUTION MAGASIN
Diag V-40. Aspects logiques locaux du système GMAO
95
VII.6. Intégration de CORBA dans le domaine des bases de données

réparties
L’un des plus gros obstacles des bases de données réparties, est l’hétérogénéité
de l’environnement sous-jacent (les systèmes d’exploitation, les systèmes de communication,
les plates formes matériels, etc.). La solution à ce problème peut être apportée par CORBA.
Intégrée aux bases de données réparties, CORBA joue le rôle de composante

de communication. Elle est responsable de l’interconnexion des machines coopérantes
et garantit la délivrance des messages, entre les parties de la base de données, sans perte
d’information, tout en ayant l’impression d’être sur une seule machine.
Pour ce faire, le concepteur doit envelopper ses opérations distantes par une couche CORBA,
fournissant, ainsi, un SGBD réparti.
96
Partie III :
Etude de cas : La GMAO
répartie
PARTIE III : Etude de cas : La GMAO répartie Bouziane Abderraouf
PARTIE III
La GMAO répartie
D ans cette 2eme partie nous verrons l’étude d’un système GMAO réparti.
La conception orientée objet de ce système est faite selon une approche descendante
en utilisant UML.
D’abord, au chapitre VIII et après avoir cerné le champ d’étude par le diagramme de flux
de données, nous entamerons une conception détaillée de ce système, comme s’il était utilisé
dans un seul site, cela permet de cerner d’avantage le champ d’étude, et permet aussi
de recenser les contraintes d’intégrité et de cohérence du système, nous verrons entre autres :
l’aspect logique du système via le modèle de paquetage, et nous verrons aussi, le diagramme
de classes, le détail de ces classes, un modèle dynamique, et enfin, la traduction du modèle
statique en modèle de tables.
Ensuite, au chapitre V, nous entamerons une conception détaillée du système pour chaque
poste de travail. Pour ce faire, nous le restructurons d’abord en paquetages correspondants
à ces postes, puis, pour chaque poste, nous établirons le schéma conceptuel local, ainsi que
quelques diagrammes de séquences importants.
Enfin, et après avoir passé en revue quelques concepts liés aux bases de données objets,
relationnelles et réparties, nous détaillerons, dans le chapitre VI, le GMAO* net et nous
verrons, entre autres, les paramètres qui nous ont permis l’optimisation de cet outil.
L’intégration de CORBA est faite à ce stade, après identification des aspects répartition
du système GMAO, nous donnerons le code IDL correspondant aux fonctions
du GMAO* net, ainsi qu’un exemple d’implémentation d’une de ses fonctions.
Mots-clefs
CORBA, GMAO répartie, GMAO* net, UML, approche descendante de conception de bases
de données réparties, schéma conceptuel global, schéma conceptuel local.
97
Chapitre VIII
Conception de l’application par UML
VIII.1. Introduction
En 1985 M.Gabriel et Y.Pimor définissent la gestion de la maintenance assistée par ordinateur
en ces termes :
Un système informatique de management de la maintenance est un logiciel organisé autour
d’une base de données permettant de programmer et de suivre sous les trois aspects
techniques, budgétaire et organisationnel, toutes les activités d’un service de maintenance
et les objets de cette activité (Service, ligne, atelier, machine, équipement, sous-ensemble,
pièce, …etc.), à partir de terminaux disséminés dans les bureaux techniques, atelier,
magasins et bureaux d’approvisionnement.
VIII.1.1. Pourquoi une GMAO?

Une GMAO est nécessaire pour la vie d’une entreprise et cela pour les raisons suivantes :
Permet une meilleure maîtrise de la gestion des ressources humaines, Matérielles

et budgétaires.
Permet la déduction des coûts du service maintenance et l’augmentation de la fiabilité
des équipements avec une disponibilité maximale.
Permet d’aboutir à des gains de productivité et d’efficacité et donc une meilleure
compétitivité, grâce à :
• Un minimum de dépenses (Optimiser le budget maintenance).
• Un minimum de pannes (réduire au maximum les interventions urgentes).
• Une haute disponibilité (avoir le rendement maximum).
• Une meilleure qualité de service (répondre aux besoins).
• Une diminution de la fréquence et gravité des pannes.
• Une augmentation de la disponibilité des installations.
• Une augmentation du taux de satisfaction.
• Une augmentation de la productivité de la maintenance.
• Une diminution des délais d’intervention.
• Une gestion optimisée des stocks.
VIII.1.2. Types de maintenance

Il existe deux sortes de maintenances, qui sont :
Maintenance corrective : maintenance effectuée après la défaillance.

Maintenance préventive : maintenance préventive effectuée selon un échéancier établi
selon le temps ou le nombre d’unités d’usage.
98
VIII.1.3. La GMAO que nous avons étudiée

L’objet de notre mémoire n’est pas de choisir l’une ou l’autre des types de maintenance
ou des politiques de maintenance mais de mettre en place une plate forme répartie aussi
complète et aussi transparente que possible pour mieux gérer la maintenance dans
un environnement réparti. La GMAO nécessite l’intervention de plusieurs acteurs repartis
sur les niveaux d’action suivant :
Fonction méthodes.
Fonction ordonnancement.
Fonction préparation.
Fonction exécution.
Gestion des stocks et magasinage.
Gestion des coûts.
Comptabilité analytique.
Documentation de la maintenance.
La répartition de ces fonctions sur les postes de travail peut différer d’une entreprise
à une autre et cela selon leurs organisations. Dans notre cas, nous avons fait l’étude
de la fonction maintenance d’une entreprise locale où :
Les fonctions méthodes, ordonnancement, et lancement sont confiées à un agent

du service bureau étude et méthodes.
La Préparation et la documentation de la maintenance sont confiées à un autre agent
du service précédent.
La fonction exécution est confiée au service exécution.
La fonction gestion de stocks et magasinage est confiée au service gestion des stocks.
La fonction gestion des coûts et comptabilité analytique sont confiées au département
finance.
VIII.1.4. Répartition de notre logiciel sur les postes de travail

Le logiciel que nous avons réalisé, ne prend pas en charge les deux dernières fonctions,
gestion des coûts, et comptabilité analytique. Par ailleurs, il permet d’automatiser le reste
des fonctions ci- dessus annoncées.
La répartition des postes de travail sur l’enceinte de l’entreprise et la sérialisation
des fonctions de la GMAO nous ont permis de concevoir pour chaque intervenant une vue
locale de la totalité des fonctionnalités de notre système, la cohérence du système globale est
assurée par une coopération de ces différentes vues et cela en utilisant une architecture
client/serveur.
VIII.1.5. Diagramme de flux de l’information

Le flux d’information entre les différents intervenants dans le système GMAO est schématisé
par le diagramme suivant.
Le déclenchement du processus de maintenance se fait, soit par un agent du site de production
(maintenance corrective) ou selon un programme défini par l’agent du service lancement
et ordonnancement (maintenance préventive).
Dans tous les cas, le déclenchement du processus de maintenance est conditionné par
l’établissement d’un BT (Bon de Travail), et il suit le même chemin.
Dans le diagramme suivant, l’ordre de passage du BT par les différents postes est caractérisé
par un numéro, éventuellement, des documents accompagnant le BT, y figurent aussi.
99
Poste préparation
Poste Lancement et
ordonnancement BT à préparer (2) Préparation des
Poste de BT (1) travaux.
Création d’un Etablissement des
Production nouveau BT. BSM.
Lancement des BT. BT préparé Consultation Stock.
Archivage.
+ BSM (3) Initialisation des
données
BT à exécuter
+
BSM (4)
Poste Magasinier Poste Exécution
Enregistrement des BSM + Intervention sur site. BT réalisé (6)

BSM. Sortir la PDR.
Enregistrement des BRG(5) Intégration de la
BRG. PDR
Gestion de la PDR
Fig IV-17. Processus de GMAO étudié
VIII.2. La GMAO réparti, conception descendante par UML

Dans ce qui suit, nous allons procéder avec une conception descendante de l’application,
et dans laquelle nous utiliserons différents diagrammes UML permettant de couvrir l’aspect
fonctionnel, statique et dynamique de l’application.
D’abord, nous développerons une conception représentant l’aspect global de l’application.
Autrement dit, nous considérerons que l’application sera destinée à un usage mono-poste,
ce qui nous permettra de maintenir, par la suite, une vision globale sur le système.
En second lieu, nous considérerons l’application sous l’angle de vue de chaque poste
de travail impliqué par le processus de maintenance (poste lancement et ordonnancement,
poste préparation, poste exécution et le poste magasinier), et nous donnerons pour chacun
de ces postes une conception de l’application représentant son aspect local.
VIII.2.1. Aspect global du système GMAO

VIII.2.1.1. Le diagramme des cas d’utilisation
Dans ce diagramme, le système GMAO est décomposé en quatre cas d’utilisation représentant
les quatre intervenants (les postes de travail), plus loin dans ce chapitre, nous verrons
que chaque cas d’utilisation donnera naissance à un autre diagramme des cas d’utilisation.
(cf. Aspects locaux du système GMAO)
100
GMAO
Poste lancement
et
ordonnancement
Poste
préparation
<<Actor>>
utilisateur
Poste exécution
Poste
magasinier
Diag IV-13. Diagramme des cas d’utilisation pour l’aspect global du système GMAO
VIII.2.1.2. Modèle de composants

L’analyse de l’existant nous a révélé l’existence de deux domaines de l’application, à savoir :
Le domaine PDR (Pièces De Rechange) et le Domaine Maintenance.
Pièces de Maintenance
rechange
Diag IV-14. Diagramme de composant pour l’aspect global du système GMAO
Paquetage maintenance : contient les classes modélisant la maintenance

Paquetage pièce de rechange : contient les classes correspondant aux différents
mécanismes permettant la gestion de la pièce de rechange.
Avant de détailler ces 2 paquetages, nous allons voir, d’abord le diagramme classes
associations suivant qui donne une vue d’ensemble de l’architecture du système GMAO.
101
VIII.2.1.3. Diagramme classes-Associations
Faite sur
Intervenant
Opération Intervention
R6
R1
BON
ARTICLE
R2
Est Est
un un
R7/R8
BRG BSM
Contient
Contient Envoie
Fournisseur
Organe Equipement Article BON
Contient
Est Est
un un
R9/R10/R11
Livraison Facture Commande
Diag IV-15. Diagramme classe-Association du système GMAO
Ce diagramme de Classe-Association représente l’aspect statique et global de l’application

GMAO. Il présente les différentes classes, et les relations qui les relient, avec une description
de la nature de ces relations.
Dans ce qui suit nous présentons les diagrammes de classes correspondants aux paquetages
Maintenance et Pièces de rechange.
102
VIII.2.1.4. Diagramme de classes pour le paquetage PDR
Maintenance :: 1 0..1
Intervention
BON Article
1..* {Abstract}
1..*
R7/R8
Maintenance ::Article BRG BSM
1..*
1..* 1..*
Fournisseur
BON
R9/R10/R11 {Abstract}
1 1 1 1
Diag IV-16. Diagramme de classes pour le paquetage PDR
VIII.2.1.5. Diagramme de classes pour le paquetage Maintenance
R6
1..* 1..* 1..*

Intervention Opération 1..* Intervenant
1..* 1..* 1..* 1..*
R2
R1
0..1
PDR ::Bon Article 1..*
{Abstract} PDR ::
R9/R10/R11
1..*
PDR ::R7/R8
1..* 1..* 1..* 1..*
1..*
1..*
1..* 1..* PDR ::BON
Organe Equipement Article
1..* {Abstract}
1..*
1
Diag IV-17. Diagramme de classe pour le paquetage Maintenance
103
VIII.2.1.6. Détail des classes
Equipement Commande
Code_mach : String {id} NumCMD: String {id}
Facturée: BOOL
Design : String
Date_miseser :Date Enregistrercmd(Numbon : String,date: Date, Code_four: String )
Section: String Enregistrerbon(Numbon : String )
Listemachine()
EnregistrerMach(Code_mach: String, Design: String)
Intervenant
Code_int: String {id}
Organe
Nom : String
Code_org: String {id} Prenom: String
Design: String
EnregistrerIntrv(Code_int : String, Nom:String ,Prenom : String)
Listeorgane()
EnregistrerOrg(Code_org: String, Design: String)
Article
Code_Art : String {id}
Fournisseur Design : String
Stock : double
Code_Four : String {id} Stock_fict: double
Nom : String
Tel: String Afficherlisteart()
EnregisterArt(Code_Art: String,Design: String)
EnregistrerFour(Code_Four : String, Nom : String,tel : String) SoustraireArtBSM(Code_Art: String,Qt: double)
AddArtBRG(Code_Art: String,Qt: double)
Operation
BRG
Code_op: String {id}
Design: String
Mode_op: String
EnregistrerBon(Numbon : String, date : Date)
EnregistrerBon (Numbon : String)
Afficherop()
Affichermodeop(Code_op: String)
Enregistrerop-( Code_op: String, Design: String Mode_op: String)
Facture Bon
NumFACT: String {id} {Abstract}

Livrée: BOOL Numbon : String {id}
date : Date
EnregistrerFACT (NumFact : String,date: Date,Code_four: String,Numbon: String )
Enregistrerbon(NumFact : String) EnregistrerBon (Numbon : String)
Reception BSM
EnregistrerBL (Numbon : String ,date: Date, NumFACT: String) EnregistrerBon(Numbon: String, date: Date)
Enregistrerbon(Numbon: String) EnregistrerBon(Numbon: string)
104
Bon article
{Abstract}
Numbon:string {id}
date: Date
Enregistre : BOOL
EnregistrerBon(Numbon: String, date: Date)

EnregistrerBon(Numbon: string)
Intervention
NumBT : String {id}

D_emiss : Date
H_emiss: String
Priorite: String
Nature: String
Trv_dmd: String
Instance: String
Trv_Hors_BT: String
EnregistrerBT(NumBT:string, Code_mach: String, D_emiss: Date,H_emiss: Date, Nature: String, Priorite: String Trv_dmd: String)
AfficherBT(Instance: String )
AfficherBT(Instance: String , Priorite : String)
ModifieinstanceBT(NumBT: String, Instanc: String)
EnregisterBSM(NumBT: String, Numbon: String)
BSMFromBT(NumBT: String)
AfficherBTrealiser(Code_mach: String)
Afficher Trv_Hors_BT(NumBT: String)
EnregistrerBT(NumBT: String, Trv_Hors_BT: String, Instance: String)
VIII.2.1.7. L’implémentation des associations
R1 R3
NumBT : String {id} Code_mach: String {id}
Code_op: String {id} Code_org: String {id}
Code_org: String {id}
LierequipOrg(Code_mach: String,Code_org: String)
Enregistrer(NumBT:String,Code_op:String,Code_org:String)
R2
R4
NumBT: String {id}
Code_op: String {id} Code_mach: String {id}
Code_Art: String {id} Code_Art: String {id}
Enregistrer(NumBT: String,Code_op: String,Code_Art: String) LierequipArt(Code_mach: String ,Code_Art: String)
105
R6
NumBT : String {id}
Code_op: String {id}
Code_intrv: String {id}
EnregistrerBT(NumBT:string,Code_op:string,Design_op:string,Code_intrv:string)
Avoirlisteop(NumBT:string)
EnregistreropBT(NumBT:string,Codeop:string,Realiser: BOOL,Hdebut:Date,Hfin:Date)
R7 R8
Numbon : String {id} Numbon: String {id}
Code_Art : String {id} Code_Art: String {id}
Qt : double Qt: double
AjouterArtTemp(Code_Art: String,Qt: double ) AjouterArtTemp(Code_Art:String ,Qt : double)

SuppArtTemp(Code_Art: String ,Qt: double)
SuppArtTemp(Code_Art: String,Qt: double)
EnregistrerBRG(Numbon:String, Code_Art: String,Qt: double)
EnregistrerBSM(Numbon:String,Code_Art:String,Qt :double)
AfficherArtBRG(Numbon:String)
AfficherArtBSM(Numbon : String)
R9
Numbon : String {id}
Code_Art: String {id}
Qt: double
AjouterArtTemp(Code_Art : String,Qt : double, Prix_u : double )

SuppArtTemp(Code_Art : String,Qt:double, Prix_u : double )
Enregistrerartrecept(Numbon:String,Code_Art :String,Qt: double, Prix_u:double)
R10
Numbon : String {id}
Qt : double
AjouterArticletempcmd(Code_Art: String,Qt : double)

SuppArticletempcmd(Code_Art:String,Qt : double)
EnregistrerArtcom(Numbon:String, Code_Art: String,Qt : double)
R11
Num_Fact: String {id} R5
Qt: double Code_org: String {id}
AjouterArttempfact(Code_Art: String,Qt: double, Prix_u : double)
SuppArttempfact(Code_Art : String,Qt: double, Prix_u : double) Lierorgart(Code_org: String,Code_art: String)
EnregistrerArtFact(Num_Fact,Code_Art:String,Qt:double,Prix_u: double)
106
VIII.2.1.8. Les associations implémentées comme références
Bon article
Intervention
NumBon
Code_Mach
Equipement
Commande
Facture
NumBon
Code_Four Fournisseur
Réception
Facture
NumFact
VIII.2.1.9. Modèle de tables

Les tables qui serviront à la création de la base de données GMAO sont déduites directement
du modèle de classes et cela en éliminant la partie méthodes de chacune des classes.
Exemple :
Modèle de classes Modèle de tables
Article
Design : String
Article
Stock : double
Stock_fict: double Code_Art : String {id}
Design : String
Stock : double
Afficherlisteart()
Stock_fict: double
EnregisterArt(Code_Art: String,Design: String)
SoustraireArtBSM(Code_Art: String,Qt: double)
AddArtBRG(Code_Art: String,Qt: double)
Fig IV-18. Exemple de traduction du modèle de classes vers le modèle de tables
107
VIII.2.1.10. Diagramme état transition pour l’objet intervention

Ce diagramme décrit la durée de vie de l’objet intervention qui change d’états durant son
existence. Dans un état donné, l’objet intervention peut exécuter un sous-ensemble de ses
méthodes et ne peut exécuter les autres que dans d’autres états.
Création( )
Instance préparation
Enrichissement( )
[Quantité non
suffisante]
En cours [nécessite Article] Bon en attente
d’enrichissement
[ SI ne nécessite pas d’article]

Envoie au lancement( )
[Quantité suffisante]
Envoie au lancement( )
Instance lancement
Lancement( )
[Article à réintégrer]
Instance exécution Instance BRG
[ SI ne nécessite pas d’article

à réintégrer ]
BT réalisé( ) Etablissement BRG( )
Diag IV-18. Diagramme état transition pour l’objet intervention
VIII.2.2. Aspects locaux du système GMAO

L’application GMAO sera répartie sur plusieurs postes, donc, pour que le résultat attendu de
cette application soit optimal, une étude détaillée par poste est nécessaire.
Allant du modèle de paquetages, où sont identifiés les différents intervenants dans notre
application GMAO, nous verrons au fur et à mesure l’application telle que vue dans chaque
poste.
108
VIII.2.2.1. Aspect logique de la répartition du système GMAO
PREPARATION
LANCEMENT
REMOTE PERSISTANCE
IHM
EXECUTION MAGASIN
Diag IV-19. Diagramme de composant pour les aspects locaux du système GMAO
Le diagramme ci –dessus, montre que le système GMAO est décomposé en sept domaines :
Domaine REMOTE : Les classe contenues dans ce domaine, définissent les outils
permettant l’exécution des fonctions distantes tout en garantissant la transparence du
système de communication sous-jacent et en palliant au problème d’hétérogénéité des
systèmes distribués utilisés.
Domaine PERSISTANCE : Ce domaine regroupe les classes permettant la
sauvegarde des informations sur une base de données persistante.
Domaine IHM : Les classes de ce domaine permettent de donner un aspect de
convivialité au logiciel GMAO, que nous avons réalisé
Les domaines EXECUTION, PREPARATION, LANCEMENT et MAGASIN
contiennent les classes permettant l’exploitation du système GMAO dans les différents
postes de travail correspondants.
VIII.2.2.2. Etude détaillée par poste

Dans ce qui suit, nous allons détailler le système GMAO selon les différentes vues des
intervenants, à savoir : Poste préparation, poste lancement, poste exécution et le poste
magasin, et dans chaque poste nous donnerons le diagramme des cas d’utilisation, le
diagramme de classe équivalant ainsi que quelques diagrammes de séquences importants.
VIII.2.2.2.1. Poste Préparation
Ce poste est chargé de :
Préparation des travaux
109
Etablissement des BSM

ArchVIIIage
Initialisation des données prédéfinies.
Diagrammes des cas d’utilisation
Enrichissement Intervenant
Des BT(s)
Equipement
Etablissement
BSM Lien
équipement/organe
Consultation Organe
stock <Actor>
<<Actor>> Préparation
Préparation Consultation Article
BSM
opération
Envoi BT à l’agent Lien
de lancement équipement/article
Lien
Historique Organe/article
machine
Diag IV-20. Diagramme des cas d’utilisation poste Diag IV-21. Diag des cas d’utilisation poste préparation
préparation (Initialisation des données)
Diagramme de classes-associations
Faite sur
intervenant
opération intervention
R6
R1 BON ARTICLE
R2
{Abstract}
R7
Contient Est
un
Organe Equipement Article BSM

Contient Contient
Diag IV-22. Diagramme classe-Association ‘Poste préparation’
110
Diagrammes de séquences
IHM :BSM :Intervention :R7
click
EnregistrerBon (Numbon, date)
BSM enregistré
EnregistrerBSM(Numbon, Code_Art, Qt)
Prendre l’élément suivant Article BSM

[liste des article à enregistrer non vide]
EnregistrerBSM(NumBT, Numbon)
BSM enregistré
Diag IV-23. Diagramme de séquence établissement BSM
IHM : R7 :Article
: Intervention
click
BSMFromBT(NumBT)
Retour Numbon
AfficherArtBSM(Numbon)
Retour liste Art de

Afficherlisteart ()
Retour liste Art

Vérifier satisfaction du BSM
Retour : BSM satisfiable (Oui / NON)
[BSM satisfiable ] soustraireArtBSM(CodeArt,Qt)
Prend l’élément suivant
[liste Art du BT non vide] Article soustrait
[BSM satisfiable ]
modifierinstance(NumBT,instance) liste BT non vide
Prend BT suivant]
instance modifiée
Diag IV-24. Diagramme de séquence pour affectation automatique de la PDR
111
IHM :Equipement :Intervention :R6
Click
Listemachine( )
Liste affichée
Liste affichée
AfficherBTréaliser(Code_mach)
Liste des BT(s) affichée
Avoirlisteop(NumBT)
Liste opération affichée
Afficher Trav_Hors_BT(NumBT)
Information affichée
Diag IV-25. Diagramme de séquence pour historique machine
IHM : : Organe : R3
Equipement :
Click
listemachine( )
Liste équipements affichée
listeorgane( )
Liste organes affichée
LierequipOrg(Code_mach,Code_org)
Lien établi
Diag IV-26. Diagramme de séquence pour lien équipement organe
112
IHM : Equipement : Article : R4
Click
listemachine( )
Liste équipements affichée
Afficherlisteart( )
Liste articles affichée
LierequipArt( Code_mach,Code_Art)
Lien établi
Diag IV-27. Diagramme de séquence pour lien équipement article
IHM :Organe :Article : R5
Click
listeorgane( )
Liste organes affichée
Afficherlisteart( )
Liste articles affichée
Lierorgart(Code_org,Code_Art)
Lien établi
Diag IV-28. Diagramme de séquence pour lien organe article
113
VIII.2.2.2.2. Poste lancement et ordonnancement

Créer un nouveau BT
Lancer des BT
Diagrammes des cas d’utilisation
Lancement BT
<<Actor>>
agent de
lancement
Création BT
Diag IV-29. Diagramme des cas d’utilisation ‘Poste lancement’
Description des cas d’utilisation

Les cas d’utilisation du diagramme si-dessus seront décrits dans ce que suit en utilisant des
diagrammes de séquences à deux niveaux.
agent sys agent sys
afficher BT et attendre priorité

Attendre ( N°BT, code machin - D_emiss h_emiss
nature de trav – Priorité - Trav demandé)
Donner la priorité
Donner ( N°BT, code machine - D_emiss –

h_emiss - nature de trav- Priorite - Trav demandé)
Afficher la liste selon priorité
Enregistrer BT(s)
Choisir les BT(s) à lancer
Diag IV-30. Description des cas d’utilisation ‘Poste lancement’
114
Intervention Faite sur un

Equipement
Diag IV-31. Diagramme de classes-associations ‘Poste lancement’
VIII.2.2.2.3. Poste exécution

• L’intervention sur site
• Sortie de la PDR
• Réintégration de la PDR
Diagramme des cas d’utilisation
Enrichissement
des BT(s)
<<Actor>>
Exécution
Etablissement
BRG
Diag IV-32. Diagramme des cas d’utilisation ‘Poste exécution’
R6
opération intervention
BON ARTICLE
Article {Abstract} BRG
Est un
R6
Diag IV-33. Diagramme de classes-associations ‘Poste exécution’
115
Diagramme de séquences
IHM : Intervention : R6
Click
enregistrerBT(NumBT, Trv_Hors_BT,Instance)
BT enregistré
EnregistreropBT(NumBT,Code_op,Realiser,H_debut , H_fin)
Opération enregistrée
Diag IV-34. Diagramme de séquence pour enrichissement BT
VIII.2.2.2.4. Poste magasinier

L’enregistrement des BSM
L’enregistrement des BRG
La gestion de la PDR
Diagramme des cas d’utilisation
Etablissement bon
de commande
Etablissement bon
de réception
<<Actor>> Etablissement
magasinier facture
Enregistrement
BSM
Enregistrement
BRG
Diag IV-35. Diag cas d’utilisation ‘Poste magasinier’
116
BON ARTICLE
{Abstract}
Est Est
un un
R7/R8
BRG BSM
Envoie
Fournisseur
Article BON
{Abstract}
Est Est
un un
R9/R10/R11
Diag IV-36. Diagramme classe-Association ‘Poste magasinier’
Diagrammes de séquences
IHM : Facture : Commande : R11
Click
EnregistrerFACT(NumFact, date,CodeFour,Numbon)
Facture enregistrée
Enregistrerbon(Numbon)
Commande enregistrée
EnregistrerArtFact (Num Fact, Code_Art,Qt,Prix_U)
ligne facture enregistrée
[ Liste des lignes de la facture non vide ]
Diag IV-37. Diagramme de séquence pour enregistrement de facture
117
IHM : Commande : R10
Click
Enregistrercmd(Numbon, date, Code_Four)

Enregistrercmd(Numbon, date, Code_Four)
Commande enregistrée
EnregistrerArtcom (Numbon, Code_ Art, Qt)
Ligne Commande enregistrée
[liste des lignes de la Cmmande non vide]
Diag IV-38. Diagramme de séquences pour enregistrement de commande
118
Chapitre IX
GMAO* net, un LMD réparti orienté objet
IX.1. Introduction
Dans ce qui suit nous allons présenter l’outil qui permet l’exploitation de l’architecture
détaillée dans le chapitre IV, cet outil, baptisé GMAO* net, comprend les fonctions
invocables à distance par les intervenants dans le système GMAO.
Il peut être assimilé à un LMD d’un SGBD. De plus le GMAO* net, est un LMD à la fois
réparti et orienté objet du moment que ses fonctions sont réparties sur plusieurs postes,
invocables à partir des méthodes appartenants à des classes d’objets et, aussi, traitant des
objets.
Avant de présenter les fonctions du GMAO* net, il est commode de décrire les étapes
qui nous ont menées à leur réalisation, pour ce faire nous allons, d’abord, identifié les aspects
répartition du système GMAO, ensuite nous allons optimiser le rendement des fonctions
distantes utilisées en se référant aux critères de performances des algorithmes répartis, déjà
énoncés dans la première partie de ce mémoire
IX.2. Identification des aspects répartition

L’élément clé qui nous a permet d’identifier les aspects répartition est bien « les tables
de la base de données GMAO », puisque, finalement, les fonctions du système GMAO
ont affaire avec la base de données.
Ainsi, chaque utilisation multiple d’une table signifie l’existence d’au moins une fonction
distante, parce que la table en question sera logée, pour des raisons de cohérence et intégrité
des informations, exclusivement dans un seul poste.
La traduction des différents schémas conceptuels locaux vers le modèle relationnel, a présenté
l’existence de plusieurs tables communes entre les différents postes du système GMAO,
ce qui a donné une première vue sur les fonctions qui seront utilisées à distance.
Le tableau suivant récapitule l’utilisation des tables dans les différents postes :
119
Poste Lancement Préparateur Exécution Magasinier

Table
Intervention + + +
Opération +
Equipement + +
Organe +
Article + + +
R1 +
R2 +
R3 +
R4 +
R5 +
R6 + +
R7 + +
R8 + +
R9 +
R10 +
R11 +
BSM + +
BRG + +
Facture +
Réception +
Commande +
Fournisseur +
Intervenant +
IX.3. Positionnement définitif des tables

Afin d’avoir une meilleure répartition des tables de notre base de données, nous avons adopté
une politique qui s’appuie sur le nombre de consultations et de mises à jour, effectuées par
chacun des opérateurs de notre système de GMAO, nous avons privilégié les mises à jour sur
120
les consultations, car nous pensons qu’une mise à jour est plus importante qu’une
consultation.
Pour ce faire nous avons défini les tables à utiliser dans chaque poste ainsi que le nombre de
consultations et de mises à jour à effectuer.
IX.3.1. Poste Lancement et Ordonnancement

Le nombre de mises à jour et des consultations
Fonction Nombre de Nombre de

Table consultations mises à jour
Intervention 1 2
Equipement 1 0
IX.3.2. Poste Préparateur

Le nombre de mises à jour et de consultations
Fonction Consultation Mise a jour

Table
Intervention 5 3
Article 2 1
R1 0 1
R2 0 1
R3 1 1
R4 1 0
R6 1 0
R7 1 1
BSM 0 1
Operation 1 0
Intervenant 1 0
Famille 1 0
Equipment 1 0
IX.3.3. Poste Exécution

Fonction Consultation Mise à jour
Les tables
Intervention 2 2
Article 1 0
R8 0 1
BRG 0 1
R6 1 1
121
IX.3.4. Poste Magasinier


Table
Commande 1 2
Facture 1 2
Réception 0 1
Article 3 3
R7 1 0
R8 1 0
R9 0 1
R10 0 1
R11 0 1
Fournisseur 2 1
BSM 1 0
BRG 1 0
IX.3.5. Initialisation de données (préparation)


Table
Intervenant 0 1
Equipement 2 1
Organe 2 1
Article 2 1
Opération 0 1
R3 0 1
R4 0 1
R5 0 1
IX.3.6. Stratégie de positionnement

Dans un souci de cohérence et d’intégrité des données, nous avons opté pour une
implémentation unique de chaque table, alors une table ne sera implémentée que dans un seul
site, et elle constituera la référence pour toute éventuelle copie. Pour positionner une table
dans un site donné, nous avons adopté le nombre de transactions (consultation et/ou màj) a
effectué, alors une table sera positionnée dans un site X, si ce site effectue le plus de
transactions.
122
Exemple : la Table intervention
Préparateur Exécution Lancement

Consultation m à j Total Consultation m à j Total Consultation m à j Total
5 3 8 2 2 4 1 2 3
Donc, la table intervention sera implémentée dans le site « préparateur ». Le tableau

ci-dessous décrit l’implémentation définitive de chacune des tables utilisées dans notre
système.
Poste Lancement Préparateur Exécution Magasinier

Table
Intervention +
Opération +
Equipement +
Organe +
Article +
R1 +
R2 +
R3 +
R4 +
R5 +
R6 +
R7 +
R8 +
R9 +
R10 +
R11 +
BSM +
BRG +
Facture +
Réception +
Commande +
Fournisseur +
Intervenant +
123
IX.4. Identification des aspects distribution des données

La stratégie de positionnement adoptée précédemment permet de minimiser le nombre de
messages trafiquant le réseau, en effet, placer une table dans le site où elle est le plus utilisée,
fait que les messages émanant de ce site et évoquant cette table, y soient concentrés.
Pour minimiser davantage le nombre de messages circulant dans le réseau, nous avons opter
pour la duplication des tables (ou parties des tables) à changement lent, ce qui réduit le
nombre de messages invoquant ces tables, car ces duplicata sont mis à jour très rarement.
Les tables dupliquées que nous avons utilisées sont issues par fragmentation des tables
originales. Dans la section « Identification des clients et leurs besoins », nous trouverons les
tables dupliquées et les attributs en question.
IX.5. Identification des clients et leurs besoins

Les tableaux suivants décrivent pour chaque poste et pour chaque cas d’utilisation, la (les)
table(s) distante(s) requise(s), la fonction à réaliser, la nature de la table (originale ou
dupliquée) cible, ainsi que les éventuels attributs dupliqués.
IX.5.1. Client Lancement

Cas Table distance Nature de la Champ à
Fonction a réaliser
d’utilisation Requise table cible dupliquer
Nouveau BT
Avoir le code machine

Equipement
dans la table équipement Code+désignation
Dupliquée
Enregistrer les attributs

du nouveau BT dans la
Intervention table Intervention Originale
Lancement des BT
Avoir la liste des BT en

instance lancement Dupliquée N°BT+Priorité
Intervention
Mise à jour du instance
Originale
dans la table intervention
IX.5.2. Client magasinier

Table distance Nature de la
Cas d’utilisation Fonction a réalisé Champ à dupliquée
Requise table cible
Avoir (consultation) la liste
Enregistrement
des article de BSM Code Art+QT
BSM R7 Dupliquée
correspond dans la table R7
Avoir (consultation) la liste
Enregistrement
des article de BRG
BRG R8 Dupliquée Code Art+QT
correspond dans la table R8
124
IX.5.3. Client préparateur
Table distance Nature de la

Cas d’utilisation Fonction à réaliser Champ à dupliquer
Requise table cible
Vérification si le code à
BSM enregistrer n’existe pas puis
l’enregistrer dans la table Originale
BSM
Article
Etablissement Consultation (avoir) le code Code + désignation
article + design dans la table Dupliquée +stock fictif
BSM Article
Consultation (avoir) le code

article + design dans la table Code + désignation
Consultation Article
Article +stock fictif
Stock Dupliquée
Envoi des BT
A l’agent Mise à jour du stock fictif
Lancement dans la table article si le
Article Originale
BSM est satisfaisable
IX.5.4. Client exécution
Table distance Nature de la Champ à

Cas d’utilisation Fonction a réaliser
Requise table cible dupliquer
-Avoir de la liste BT en
instance exécution et le code Dupliquée N° BT+code
machine équivalent machine +
Instance + travail
hors BT
Intervention -enregistrer les attributs de

BT (instance +travail hors
Originale
BT)
-avoir la liste des opérations

Enrichissement Dupliquée Code opération
par BT en instance exécution
+ Design
Des BT(s)
R6
-mise à jours dans la table R6

Originale
Etablissement article Avoir la code art+design Dupliquée Code Art+design
BRG BRG Vérifier si le code de BRG
n’existe pas puis l’enregistrer Originale
125
Avoir la liste BT en instance N° BT+code

BRG Dupliquée machine + Instance
Etablissement + travail hors BT
BRG Intervention Mise à jour du champ
instance BRG
Originale
Réalise
IX.6. Identification des serveurs et leurs services

Les tableaux suivants décrivent pour chaque poste et pour chaque table invocable par des
fonctions distantes, les services qu’ils doit fournir ainsi que le poste demandeur.
IX.6.1. Serveur Préparateur
Table
Les services fournis Poste demandeur
servante
Mise à jour des attributs d’un BT (Priorité, N°BT, code machine,

Date émission, heur démission, nature de travail, travail demandé)
IN : Priorité, N°BT, code machine, Date émission, heur démission,
I nature de travail, travail demandé Lancement
N OUT : /
T
E
R En donnant l’instance (lancement) On reçoit : N°BT, priorité
IN : instance(Lancement)
V Lancement
OUT : N°BT , Priorities
E
N Mise à jour du champ instance du N°BT spécifié
T IN : N°BT , instance
Lancement
I OUT : /
O
En donnant l’instance (Exécution) ,On reçoit : N°BT, Code
N machine
IN : instance (Exécution)
Exécution
OUT : N°BT, Code machine
En donnant le N°BT, on enregistre le travail hors BT et on mise à

jour le champ instance
IN : N°BT , Travail hors BT , Instance Execution
OUT : /
Avoir le code Machine + design

Equipement IN : / Lancement
OUT : Code Mach, design
En donnant le N°BT, on reçoit les opérations

R6 IN : N°BT Execution
OUT : Code_ op , design
126
Suivant le N°BT, on enregistre les attributs

R6 (réalisée (o/n), H_ Début, H_ Fin)
IN : N°BT, réalisée (o/n), H _ Début, H _ Fin Exécution
OUT : /
En donnant N°BSM en reçoit la liste (Code article, Qt)

IN: N°BSM
R7 Magasinier
OUT : Code_ Art , Qt
IX.6.2. Serveur Exécution
Table servante Les services fournis Poste demandeur

En donnant le N°BRG, on reçoit la liste (code machine, Qt)
IN : N°BRG
R8 OUT : Code_ Art , Qt
Magasinier
IX.6.3. Serveur Magasinier
Table Les services qu’elle doit fournir Poste demandeur
Avoir la liste (code_ art, design, stock_ fictif)

IN : / Préparateur
OUT : code _art , design , stock_ fictif
Article En donnant le Code _Art, on mise à jour le stock _fictif

IN : Code _Art , stock_ fict Préparateur
OUT : /
Avoir la liste (Code_ Art, Design)

IN : / Exécution
OUT : Code_Art , Design
Envoi du N°BSM, s’il existe Enregistrer

Sinon
Message adéquat
BSM
Fin Si Préparateur
IN : N°BSM, Date
OUT : Message adéquat
Envoi du N°BRG, s’il existe Enregistrer

Sinon
Message adéquat
BRG Fin Si Exécution
IN : N°BRG , Date
OUT : Message adéquat
127
IX.7. Intégration de CORBA dans l’application

Après avoir identifié les fonctions invocables à distance, nous présentons dans cette section
les interfaces IDL permettant d’envelopper ces fonctions pour qu’elles soient utilisables dans
des milieux distribués et hétérogènes. Les fonctions décrites par le code IDL suivant,
constituent : Le LMD GMAO* net.
IX.7.1. Poste préparateur
// ce module est destiné pour le lancement

module lancementprep
{
// structure d’un BT
struct BT
{
string numBT;
string priorite;
};
typedef sequence<BT> sequencebt;

// structure d’une machine
struct machine
{
string codemach;
string design;
};
typedef sequence<machine> sequencemachine;
Interface maj
{
// enregistrer un new BT
string newBT (in string numBT, in string priorite, in string codemach, in string demiss, in
string hemiss, in string naturtrv, in string trvdmd);
// lancer un BT pour exécution , il faut changer l'instance lors d'implementation

string lancerBT (in string numBT);
};
Interface consultation
{
// les 2 fonctions de réception des infos
sequencebt recevoirBT ( );
sequencemachine recevoirmach ();
};
};
128
// ce module est destiné pour le magasinier

module magasinierprep
{
// structure d’un BSM
struct BSM
{
string codeart;
double qt;
};
typedef sequence<BSM> sequencebsm;
interface consultation
{
// la fonctions de réception des infos
sequencebsm recevoirBSM (in string numBSM);
};
};
// ce module est destiné pour l'exécution

module executionprep
{
// structure d’un BT
struct BT
{
string numBT;
string codemach;
};
typedef sequence<BT>sequence1;
// structure d’une opération
struct operation
{
string codeop;
string design;
string numBT;
};
typedef sequence<operation>sequenceop;
struct opbt
{
string numBT;
string trvhorsBT;
string instance;
boolean realise;
string codeop;
string hdebut;
string hfin;
};
typedef sequence<opbt>sequence3;
129
Interface maj
{
// enrichir BT , table intervention
void enrichirBT (in string numBT );
// enrigister les attributs d'un BT, table R6

string saveopBT (in string numBT,in string codeop , in boolean realise, in string hdebut, in
string hfin);
void enrichopbt(in sequence3 opbt );
};
{
// les 2 fonctions de réception des infos
sequence1 recevoirBT (in string instance);
sequence2 recevoirmach ( );
};
};
List VI-8. Interfaces IDL du serveur Préparation
IX.7.2. Poste Magasinier
// ce module est destiné pour l'execution

module executionmag
{
// La structure a pour but : avoir stock fictif des articles
struct article
{
string codeart;
string design;
};
typedef sequence<article> sequencearticle;
Iinterface maj
{// enregistrer BRG, table BRG
void saveBRG (in string numBRG, in string dBRG);
}
{
// la fect de reception des infos
sequencearticle recevoirart ();
};};
List VI-9. Interfaces IDL du serveur Magasinier
130
IX.7.3. Poste Exécution
// ce module est destiné pour le magasinier

module magasinierexe
{ // cette structure a pour but :avoir renseignement BRG, table R8
struct BRG
{
string codeart;
double qt;
};
typedef sequence<BRG> sequencebrg;
interface consultation
{
// la fect de reception des infos
sequencebrg recevoirBRG (in string numBRG);
};
};
List VI-10. Interfaces IDL du serveur exécution
IX.8. Implantation du LMD GMAO* net

Pour pouvoir implanter les fonctions du GMAO* net, il faut d’abord compiler le code IDL
ci-dessus, dériver les classes d’implémentation à partir des classes abstraites contenues dans
les Skelton et stub correspondants aux modules IDL, ensuite définir le code des fonctions
distantes.
A titre d’exemple, le module IDL « lancementprep » donnera naissance au skelton

« _Sk_ lancementprep » qui contient, entre autres, les classes abstraites suivantes : _Sk_maj et
Sk_consultation.
Après dérivation de ces classes, nous aurons les classes Impl_maj et Impl_consultation, qui
contiendront des fonctions à corps vides parmi lesquelles, la fonction
« sequencebt recevoirBT ( ) » .
La définition de la fonction « sequencebt recevoirBT ( ) » sera :
sequencebt recevoirBT ( )
{
sequencebt Intervention :: recevoirBT ( ) ;
}
où Intervention :: recevoirBT ( ) ; est une fonction locale de la classe Intervention.
131
IX.9. les types de données manipulées par le LMD GMAO* net

Les données manipulées par le GMAO*net sont de types différents, composées de types
simples (integer, double, etc.). Ces types complexes ont la forme d’une collection
d’enregistrements d’un fichier de base de données. Ainsi le GMAO*net peut manipuler des
tables toutes entières en une seule fois.
Ces types sont :

typedef sequence<machine> sequencemachine;
typedef sequence<BSM> sequencebsm;
typedef sequence<operation>sequenceop;
typedef sequence<article> sequencearticle;
typedef sequence<BRG> sequencebrg;
Exemple : le type sequencebt est composé de la façon suivante
struct BT
{
string numBT;
string priorite;
};
Une occurrence de ce type peut être la suivante :
Num BT Priorité
00001 1
000002 2
005552 2
….. …..
8888 3
6588 5
6999 4
Les types de données manipulées par le LMD GMAO* net
IX.10. Architecture fonctionnelle du système GMAO

Le système GMAO que nous avons conçu est réparti sur 4 postes, un utilisateur donné accède
à ce système selon un point de vue guidé par le schéma conceptuel local correspondant.
Cependant, deux cas peuvent se présenter :
132
1. La fonction à invoquer est locale : Dans ce cas le système GMAO interroge le SGBD
local qui, à son tour accède à la base de données locale et fournit le résultat demandé.
2. La fonction à invoquer est distante : Dans ce cas le système GMAO interroge
le GMAO* net qui, à son tour accède à la base de données distante et fournit
le résultat demandé. L’accès à la base de données distante se fait via l’ORB CORBA
et en se référant à la localisation de la table distante.
La figure suivante illustre ce principe de fonctionnement.
User X User Y
Schéma Schéma
conceptuel CORBA CORBA conceptuel
local X local Y
GMAO GMAO
GMAO* net
SGBD SGBD
local x local y
Localisation Localisation
des tables des tables
distantes distantes
BDL X BDL Y
Fig VI-28. Architecture fonctionnelle du système GMAO
133
IX.11. Quelques fenêtres du logiciel GMAO
Les fenêtres ci après montrent le chemin emprunté par un BT, depuis sa création jusqu’à
sa réalisation.
IX.11.1. Etape1,"site Lancement" : création d’un BT

Dans la fenêtre ci-dessous, l’utilisateur est invité à remplir les informations d’un nouveau BT.
Après sa création, le BT passe au stade préparation.
VI.11.2. Etape2, "Site préparation" : préparation de BT

A ce stade, le BT est augmenté des opérations à réaliser, les articles et les organes à réparer et
les noms des intervenants.
134
Une fois préparé, le BT revient au site"lancement" pour une éventuelle sélection

au lancement, et passe du stade préparation au stade lancement
IX.11.3. Etape3,"site Lancement" : sélection des BT à exécuter

La fenêtre ci-dessous permet à l’agent du site "lancement" de sélectionner un BT
et de l’envoyer au site "Exécution".
Le BT passe alors, du stade lancement au stade Exécution.
IX.11.4. Etape4,"Site Exécution" : Enrichissement d’un BT

Une fois exécuté, le BT est enrichi par des informations propres tel que l’heure de début
d’intervention et l’heure de fin, etc.
135
Le BT passe finalement de l’état exécution à l’état réalisé et il sera disponible pour une
éventuelle consultation.
IX.11.5. Etape5,"Site Préparation" : Historique machine

La fenêtre ci-dessous, permet d’avoir, pour une machine donnée, l’ensemble des BT, qui ont
été réalisés.
136
Conclusion
A travers cette partie nous avons vu que l’introduction de CORBA vient après la conception
de l’application.
Malgré les facilités offertes par CORBA en matière d’interopérabilité, il est évident que cette
dernière ne peut, en aucune manière, résoudre les problèmes relevant du niveau conceptuel.
Alors, pour utiliser CORBA, il faut d’abord arranger l’infrastructure conceptuelle pour
une utilisation répartie. En plus, cette conception doit être adéquate à une configuration
client/serveur.
Dans le domaine des bases de données réparties, CORBA joue le rôle de composante
de communication. Cette dernière est indispensable pour envelopper les fonctions du SGBDR
(Système de Gestion de Bases de données Réparties).
Ainsi, une bonne conception répartie associée à CORBA tirera, davantage, profit
des systèmes distribués.
137

Cours4 Base de Données

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours4 Base de Données

Transféré par

Droits d'auteur :

Formats disponibles

Université de Bordj Bou Arréridj

Faculté des Mathématiques et d'Informatique

Bases de données relationnelles et réparties :

Partie I : Bases de données relationnelles

Partie II : Bases de donnée réparties

Partie III : Etude de cas : La GMAO répartie

Ce cours couvre les chapitres de la matière Bases de données du 2eme

Ainsi, il est destiné en premier lieu aux étudiants de la deuxième année

Ce cours récapitule mon expérience d’enseignement de cette matière depuis

CHAPITRE I : Introduction aux Bases de Données

 Enclins aux erreurs.

L’utilisation de fichiers impose d'une part, à l'utilisateur de connaître l'organisation

De telles applications sont :

Les données associées sont :

 mal définies et mal désignées,

1. Redondance des données : La duplication des données identiques dans différents

Les effets de la redondance :

4. Systèmes de base de données

Un environnement de base de données se compose de quatre éléments :

Les bases de données doivent permettre un partage concourant (contribuant

b) Utilisateurs : ils peuvent être divisés en trois catégories générales.

Développeurs d’applications : Ils développent les programmes d’application se

d) Logiciels : le logiciel de contrôle de base de données est appelé SGBD. Système de

Le SGBD permet de créer, de gérer et d’accéder à la base de données.

Tous les accès à la base de données se font par le SGBD.

Plus formellement, un SGBD doit permettre d'atteindre les objectifs suivants :

4.1. Offrir différents niveaux d'abstraction

Il est appelé également le niveau conceptuel. A ce niveau on parle de modèle

A ce niveau, seulement une vue partielle de l'ensemble des données est

4.2. Assurer l'indépendance physique des données

Détacher l'utilisateur du niveau conceptuel des détails de la structure du niveau

4.3. Contrôler la redondance des données

La suppression de la redondance des données permet de maintenir la cohérence de

4.4. Permettre à tout type d'utilisateur de manipuler des données

4.5. Assurer l'intégrité des données

Confier la tâche de vérification de l'intégrité logique de l'information aux développeurs

4.6. Assurer la sécurité des données

Un SGBD doit garantir la disponibilité des données en particulier après la survenue

4.8. Optimiser l'accès aux données

CHAPITRE II : Modèles de données

Une base de données est un ensemble de connaissances sur un domaine d’application

Parmi les modèles de données existant, il y a le modèle relationnel, le modèle hiérarchique,

3.1 Entités et associations

Clients Articles Fournisseurs

Clients Articles Fournisseurs

3.2 Attributs et identifiants

Clients Articles Fournisseurs

PARTIE I; Bases de données relationnelles Bouziane abderraouf

– une entité possède au moins un attribut (son identifiant) ;

Exemple : un client a au moins acheté un article et peut acheter n articles (n étant

3.4 Associations plurielles

3.5 Association réflexive

3.6 Associations non binaires

PARTIE I; Bases de données relationnelles Bouziane abderraouf

2) Normalisation des noms :

3) Normalisation des identifiants :

Chaque entité doit posséder un identifiant.

4) Normalisation des attributs (importante) :

Remplacer les attributs en plusieurs exemplaires en une association supplémentaire de

5) Normalisation des attributs des associations (importante) :

PARTIE I; Bases de données relationnelles Bouziane abderraouf

6) Normalisation des associations (importante) :

PARTIE I; Bases de données relationnelles Bouziane abderraouf

7) Normalisation des cardinalités :