Vous êtes sur la page 1sur 163

Architectures, modèles et langages de

données

Ingénierie des
bases de données

Hypercube c,d

OLAP

Volume I

Fascicule 1
 

Architecture fonctionnelle du logiciel SGBD et


diagramme de classe UML

André Gamache 2005

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
2

Architectures, Modèles et Langages de Données

Volume 1
Fascicule 1

1- Introduction 1

2- Architecture fonctionnelle du SGBD 21

3- Modèle conceptuel des données 79

INDEX
Fascicule 2

4- Modèle relationnel : théorie et contraintes d’intégrité 1

5- Algèbre relationnelle 57

6- Transposition du MCD au MRD 137

INDEX
Volume 2
Fascicule 3

7- Langage de données SQL 1

8- Indexation, vue relationnelle et base réactive 123


INDEX
Fascicule 4

9- Langage de programmation et SQL 1

10- Théorie de la normalisation relationnelle FN1 à FN5 45

11- Optimisation des requêtes relationnelles 117

Annexes :
A- SQLoader
B- Projet ALU-Nord : Script de chargement

INDEX

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
3

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
4

Chapitre 1 
Introduction générale à l’exploitation des données

Introduction 
Le domaine des bases de données est maintenant quasi un lieu commun pour une vaste clientèle 
des  systèmes  informatiques,  allant  de  l’utilisateur  occasionnel  de  la  micro‐informatique  au 
spécialiste chargé par les organisations de concevoir, de mettre en oeuvre et de gérer les grands 
systèmes de gestion de données qui sont essentiels à leurs activités. Les bases de données sont 
désormais un élément incontournable de tout système de traitement de lʹinformation qui se doit 
dʹêtre  performant  et  évolutif.  La  terminologie  du  domaine  des  bases  de  données  est  parfois 
ambiguë  et  polysémique,  surtout  si  elle  est  prise  hors  contexte.  Nous  commencerons  donc  par 
présenter quelques concepts clés du domaine avec un certain niveau de généralité parce quʹune 
seule définition ne peut pas rendre compte facilement de toute la complexité et des nuances qui 
prévalent dans différents contextes technologiques. 
1.1 Base de données 
Une  base  de  données  (BD)  est  un  ensemble  de  structures  créées  à  l’image  d’un  modèle  de 
données  et  gérées  pour  stocker  des  informations  (représentées  par  les  données)  dans  le  but 
dʹeffectuer  subséquemment  des  recherches  et  des  mises  à  jour.  Cʹest  en  quelque  sorte  la 
représentation  structurée  et  codée  de  lʹinterprétation  (par  le  concepteur)  dʹune  réalité 
organisationnelle  qui  est  en  constante  évolution  dans  le  temps.  La  base  de  données  peut  être 
centralisée ou répartie (distributed) et elle est accessible aux concepteurs dʹapplications et à leurs 
utilisateurs par lʹintermédiaire dʹune gamme de moyens informatiques soit du simple terminal à 
la station de travail, et cela pour manipuler les objets ou les structures les plus simples jusquʹaux 
objets graphiques implémentés avec des structures de données beaucoup plus complexes.  
Logiciel de gestion de base de données (SGBD) 
Le  logiciel  SGBD  est  un  ensemble  de  procédures  partagées  par  tous  les  utilisateurs  pour  la 
création et la manipulation des données (1) avec une garantie de cohérence, de consistance dans 
les  opérations  et  de  persistance  des  ajouts  ou  des  modifications  transactionnelles.  Les 
procédures  du  moteur  SGBD  coopèrent  pour  exploiter  et  gérer  les  structures  de  données 
complexes qui utilisent le chaînage, l’adressage calculé (Hashing), le B‐arbre et le regroupement 
(clustering) des données, à la fois pour le stockage et la recherche. 
Conception dʹune base de données  
La  conception  dʹune  base  de  données  sʹinscrit  dans  l’ensemble  des  opérations  d’analyse 
informatique  concernant  la  définition  des  données,  des  types  (structures)  et  des  associations 
entre  les  données  et  la  spécification  des  contraintes.  Pour  effectuer  ce  travail,  les  concepteurs 
utilisent  une  méthodologie  dʹanalyse  qui  peut  privilégier  soit  une  approche  globale  de 
l’organisation, soit une autre qui exige lʹintégration des données exploitées pas les applications 
existantes. Une fois la conception terminée, il faut dresser en quelque sorte les plans et les devis 
des  traitements  et  des  données  qui  sont  notamment  représentés  sous  forme  de  modèles 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 2

documentés  avec  le  diagramme  de  flux  de  données  (DFD),  le  modèle  conceptuel  de  données 
(MCD) et le modèle logique de données (MLD) qui deviendra celui de lʹimplantation.  
Ces  documents  de  base  sont  essentiels  aux  concepteurs  pour  favoriser  une  bonne 
communication avec les utilisateurs et donner au système cible le niveau de maintenabilité exigé 
par  tout  système  complexe  qui  doit  évoluer  en  fonction  des  besoins  de  l’organisation.  Ils 
permettent  aussi  d’expliciter  et  de  délimiter  le  rôle  et  les  fonctions  du  système  de  gestion  des 
données  et  de  conscientiser  les  concepteurs  et  les  utilisateurs  quant  aux  limites  de  celui‐ci.  De 
nos  jours,  la  modélisation  tend  à  incorporer  une  vision  plus  dynamique  des  données  en  y 
incluant  les  traitements  et  les  événements  qui  en  sont  les  déclencheurs.  Ces  activités  sont 
représentées par un modèle de traitement et par un autre dit transactionnel.  
1.2 Rôle central du SGBD 
Le  logiciel  SGBD  doit  fournir  un  environnement  riche  et  efficace  pour  stocker,  retrouver  et 
modifier les données dans une base tout en respectant leurs propriétés structurales ainsi que les 
contraintes de sécurité qui sʹimposent dans un contexte multiposte où le partage des données et 
l’accès  à  celles‐ci  sont  des  privilèges  accordés  aux  utilisateurs  dʹaprès  leurs  fonctions  dans 
lʹorganisation. Le logiciel est en exécution sur une machine serveur ou sur une machine centrale 
et  répond  aux  requêtes  de  service  en  provenance  de  clients  répartis  en  différents  endroits  et 
reliés par lʹentremise dʹun réseau. La communication entre le client et le serveur est assurée par 
le logiciel qui implémente la couche transport TCP/IP de Ethernet. 
  
 
 
Utilisateur  
SGBD
TCP   TCP
Application  -IP -IP BD 
 
 
Côté Client  
Côté serveur
 
Architecture client‐serveur                     
Figure 1.1
 
En  dʹautres  termes,  le  logiciel  SGBD  se  comporte  comme  un  logiciel  serveur  sur  la  machine 
attendant des requêtes des clients sur un port particulier pour ensuite déclencher le calcul de la 
réponse  à  partir  des  données  de  la  base.  Les  structures  de  données  de  la  base  sont  très  riches 
(listes,  B‐arbres,  adressage  calculé,  fichier  Heap  etc.).  La  structuration  détaillée  des  données  
devient  rapidement  impossible  à  saisir  tant  la  structure  est  complexe.  Il  a  fallu  inventer  une 
représentation  générique  de  ces  structures  de  données  pour  masquer  leur  complexité,  tout  en 
offrant  aux  utilisateurs  une  vision  simple    leur  permettant  de  représenter  les  données  et  leurs 
associations pour pouvoir par la suite les exploiter efficacement.  Le rôle de l’application client 
est de traiter localement les données obtenues selon une logique propre à chaque application et 
d’en afficher les résultats en faisant appel à un sous‐système de gestion de fenêtres.  
Importance du volume des bases de données 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 3

La nécessité de gérer efficacement de plus grands ensembles et de nouveaux types de données 
s’impose  principalement  en  raison  de  l’importance  croissante  des  données  dans  les  processus 
décisionnels.  Ce  volume  de  données  exorbitant  entraîne  son  lot  de  problèmes.  Il  y  a  déjà 
longtemps, T. Tomita (2), estimait quʹen 1960  le volume de lʹinformation publique transmise par 
les journaux était de 0,66 x 1020  bits et quʹil triplerait en 1972. Sa prévision faite à lʹaube de lʹère 
informatique nous apparaît maintenant bien en dessous de la réalité. La croissance du volume 
des données se fait sentir particulièrement dans les pays industrialisés où le fonctionnement et 
la gestion sont tributaires dʹun accès sûr et universel aux données de lʹorganisation (3). Le mot 
d’ordre  dans  le  fonctionnement  des  organisations  est  de  fournir  directement  les  données 
nécessaires aux utilisateurs afin de rapprocher la décision de l’action. Cʹest dʹailleurs la base du 
concept  de  lʹentrepôt  de  données  (data  warehouse)  qui  constitue  un  immense  réservoir  de 
données  cumulées  dont  l’exploitation  fine  permet  d’extraire  de  nouvelles  informations  au 
moyen d’outils d’analyse et de synthèse (data mining). La généralisation des accès à lʹInternet et  
la mise en place de bibliothèques électroniques (digital library) accessibles de par le monde sous‐
tendent leur gestion à partir des supports informatiques.  
 
La  capacité  des  disques  et  la  vitesse  de  transmission  des  données  ont  atteint  des  niveaux  que 
lʹon  pouvait  difficilement  prévoir  il  y  a  dix  ans.  Le  volume  des  données  est  devenu  très 
important. Il suffit de songer à la taille de la base de données nécessaire pour gérer les données 
de type multimédia acheminées sur l’inforoute de l’Internet. Combien de millions dʹoctets faut‐il 
pour stocker 60 secondes de son ou une séquence vidéo de deux minutes ? Quel espace faut‐il 
pour stocker un catalogue de pièces mécaniques pour l’industrie de l’automobile? Quelle est la 
valeur  utilitaire  de  cette  masse  de  données ?  Quels  sont  les  mécanismes  d’accès  les  plus 
appropriés pour retrouver ces données ? Comment découvrir un ensemble de pièces musicales 
sur  la  base  de  leur  contenu?  Des  centaines  voire  des  millions  de  mégas  octets  sont  nécessaires 
pour  stocker  ces  nouvelles  informations  gérées  par  ordinateur.    Ces  quelques  faits  révèlent 
lʹimportance du volume des données et laissent entrevoir le rôle des  bases de données avec leur 
environnement  technologique  pour  stocker  ces  données  complexes  et  en  permettre 
subséquemment le rappel et l’affichage. Sans un logiciel spécialisé, des disques rapides RAID et 
un  processeur  de  grande  puissance,  l’accès  à  une  base  de  données  de  grande  taille  ayant  des 
objets de types très divers peut devenir un cauchemar pour qui en est le gestionnaire. Déjà les 
besoins se faisaient sentir dans les années 80 lorsque le développement économique se profilait 
au développement du secteur des services et à l’informatisation des moyens de production. En 
1979, Williams (4) publia une courbe de croissance des bases de données textuelles, qui laissait 
voir  un  rythme  qui  doublait  sur  une  période  de  quatre  ans.  A  titre  dʹexemple,  considérons  la 
croissance estimée du volume des données par Williams4, Bien que  la réalité des années 2000 
rende ces données largement caduques, elles ont le méritent dʹillustrer la croissance des données 
depuis la première phase du cycle d’informatisation des organisations.  
 
Description  1975  1977  1979 
Nombre de bases de données textuelles (USA)  177  208  259 
Nombre d’enregistrements (en millions) 46 58 94
Nombre base de données (autres pays développés) 124 154 269
Nombre d’enregistrements (en millions) 301 362 528

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 4

Figure 1.2
Ces  repères  de  plusieurs  années  permettent  dʹapprécier  les  volumes  importants  de  données  à 
stocker  et  ultérieurement  à  recouvrer,  ce  qui  ne  peut  pas  se faire  sans  une  augmentation  de  la 
puissance des machines, de la capacité de stockage des systèmes et de la puissance des logiciels 
de  gestion  des  bases  de  données.  Pour  terminer,  plusieurs  auteurs  soulignent  que  seulement 
10%  des  informations  sont  gérées  par  des  systèmes  informatiques  et  que  inévitablement  les 
volumes de données vont augmenter avec la généralisation de la saisie des données à la source! 
La charge qui sera soumise aux bases de données s’annonce colossale. 
 
Plus  récemment,  Lyman  et  Varian  (5)  de  l’Université  de  Californie  à  Berkeley  estimait  que 
l’augmentation du volume d’information avait augmenté de 30% depuis 1999 pour atteindre en 
2002 un sommet de 5,4 pecaoctets (1018 octets). Très approximativement, 40% de cette nouvelle 
information  serait  produite  par  les  USA  dont  la  moitié  serait  enregistrée  sur  un  support 
permettant  une  lecture  digitale.  Pour  ne  pas  sombrer  dans  la  pollution  ou  hégémonie 
informationnelle aigue, de bons outils de stockage et de recherche pointue voire discriminante 
seront nécessaires pour répondre aux besoins du marché. 
 
Dans une enquête centrée sur les bases de données réalisée par lʹInternational Oracle User Week 
(IOUW)  (6)  auprès  des  DBA  (Database  Administrator)  participant  aux  conférences  annuelles  de 
1993 et 1994, il appert que la taille la plus fréquente de la base opérationnelle soit de 2,2 Go et 
que la moyenne se situe autour de 14 Go. En 1994, la taille moyenne est passée à 17 Go, tandis 
que  la  taille  médiane  de  la  base  a  augmenté  de  38  %  par  rapport  à  celle  de  1993.  Le  nombre 
moyen  dʹutilisateurs  de  bases  de  données  va  aussi  quadrupler  dans  cette  seule  année,    pour 
atteindre près de 210 utilisateurs par base Oracle. Au Québec, la Régie de lʹAssurance Maladie 
(RAMQ)  gère  en  ligne  les  trois  dernières  années  de  prestations  médicales.  Par  exemple,  pour 
1993 à 1996, cela représente une base de plus de deux milliards dʹenregistrements. Le volume est 
tel  quʹune  réorganisation  impliquant  un  rechargement  est  une  opération  lourde  puisquʹil  faut 
près  de  deux  mois  pour  le  réaliser  et  cela,  avec  des  ordinateurs  puissants  dotés  d’une 
technologie de pointe.  
 
Lʹimagination  est  mise  au  défi  lorsquʹil  sʹagit  dʹestimer  les  volumes  de  données  qui  seront 
générés  par  le  commerce  électronique  dont  les  spécialistes  prédisent  une  généralisation 
progressive peu après lʹentrée dans le troisième millénaire! Lʹévolution des bases de données est 
donc marquée par lʹaugmentation prévisible des volumes de données caractérisés par une plus 
grande diversité des types de données, notamment pour y inclure les images et le son.  
 
Pour  mieux  illustrer  lʹévolution  des  bases  de  données,  nous  les  classerons  en  cinq  groupes 
distincts  sur  la  base  de  leur  volume.  Chaque  catégorie  a  ses  caractéristiques  et  ses  logiciels  de 
gestion.  Il  est  aussi  à  prévoir  que  les  grandes  bases  seront  pour  les  prochaines  années  une 
préoccupation majeure pour les grandes organisations tant les investissements en personnel, en 
matériel et en logiciel seront importants. 
1.3 Typologie des bases de données 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 5

Le classement des bases de données par leur volume donne les catégories relatives suivantes qui 
mettent en perspective leur importance relative dans le fonctionnement des organisations :  
La  base  de  données  individuelle  renferme  des  données  personnelles  avec  quelques  milliers  de 
données  utilisant  quelques  centaines  d’octets  pour  leur  stockage.  Tout  va  pour  le  mieux!    Son 
exploitation  est  souvent  locale  et  l’accès  aux  données  réalisé  avec  une  bonne  performance.  Il 
existe de bons outils sur des ordinateurs de bureau, disponibles à des prix intéressants ou à titre 
de logiciel libre (Open Source) et qui permettent de gérer ces ensembles de données personnelles 
relativement importants. Dans les années à venir, certaines de ces bases pourront être davantage 
individualisées  et  acquérir  le  statut  de  portable  sur  une  carte  à  puce  dotée  d’un  ordinateur 
embarqué (smart card avec flash memory) ou stockées dans des ordinateurs portables (laptop, palm 
computer). Ces bases portables deviendront accessibles à des agents intelligents mandatés pour 
propager ou collecter des données à partir de bornes Internet de données.   
 
La  base  de  données  dʹavant  1985:  Une  base  type  comprend  moins  de  200  000  données 
essentiellement numériques et nécessite près de 2 Mo de mémoire de stockage. Avec cette base, 
il y a des problèmes de partage de données assorti de performance que le DBA doit surveiller et 
résoudre.  Comme  ces  données  sont  souvent  jugées  essentielles  au  fonctionnement  d’une 
organisation,  il  faut  un  accès  relativement  rapide    avec  des  outils  puissants  qui  nécessitent  un 
investissement  moyen  pour  le  logiciel  et  le  matériel.  Ces  bases  sont  souvent  associées  à  des 
fonctions  spécialisées  et  vitales  dʹune  organisation  comme  par  exemple  lʹinventaire  dʹune 
entreprise manufacturière, le système des ventes ou le système de facturation.  
 
La base de données après les années 1995 :  La mega base de données (x106) peut comporter  autour 
de  100  000  000  données,  ce  qui  suppose  quelques  dizaines  de  gigas  octets  de  stockage.  À  ce 
niveau,  le  volume  des  données,  leur  complexité,  les  problèmes  de  gestion  des  structures  de 
stockage, de performance et d’accès apparaissent avec plus dʹacuité. Les logiciels dʹexploitation 
sont  maintenant  de  type  multiposte,  plus  coûteux  et  exigeants  en  termes  de  ressources 
informatiques: matériel, logiciel et ressources humaines spécialisées. Les problèmes d’archivage 
deviennent  encore  plus  évidents  et  les  solutions  plus  complexes  et  coûteuses.  Le  stockage  des 
données multimédias apparaît comme un nouvelle exigence pour les systèmes ce qui accentue le  
problème de vitesse dʹaccès et dʹespace disque. Lʹinfrastructure de réseau est heureusement en 
place  et  les  disques  rapides  de  type  RAID  sont  maintenant  un  atout.  Le  poste  budgétaire  de 
l’informatique est devenu très important pour un grand nombre d’organisations. 
 
La  base de données des années 2000 : La giga (x109)  voire même la térabase de données (x 1012), 
plus de 1 000 000 000 000 données disponibles en ligne qui occupent un espace de plus de 1 To. 
Les problèmes critiques sont ceux du stockage, de la performance, de lʹaffichage, de lʹarchivage 
et  de  la  vitesse  du  réseau.  Les  logiciels  sont  encore  plus  coûteux  et  souvent  spécialisés.  Les 
disques  RAID  sont  nécessaires,  sous‐tendant  souvent  lʹutilisation  des  architectures 
multiprocesseurs  pour  avoir  une  performance  appréciable.  Les  données  acquièrent  de  plus  en 
plus leur lettre de noblesse pour nourrir  l’intelligence économique mise  à jour par les logiciels 
de  data  mining.  Une  entreprise  peut  alors  mieux  connaître  ses  concurrents  et  d’anticiper  les 
besoins de ses marchés. C’est le début de l’ère de l’entrepôt de données. 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 6

 
La base de données du futur:  La térabase (x1012) ou l’exabase (x1018) base s’impose graduellement 
comme  une  réalité;  avec  autant  de  données,  tout  est  ou  devient  problème!  Quelques  grandes 
organisations privées ou gouvernementales commencent à ressentir ces difficultés associées aux 
volumes de cette importance, particulièrement depuis l’avènement des documents multimédias 
dans  les  bases  de  données  et  la  généralisation  planétaire  du  courrier  électronique  et  des 
documents digitaux. Pour stocker des images animées couleurs et muettes, il faudra stocker 15 
Mo à la seconde! La tendance à fusionner tous les types de données entraîne alors des problèmes 
d’espace,  de  vitesse  de  communication  sur  réseau  (100  Mbps)  Les  interfaces  complexes  et 
robustes  pour  stocker  et  surtout  rechercher  rapidement  les  données  historiques  des 
organisations  (data  warehouse).  A  ce  niveau  de volume,  la  centralisation  des  données  n’est  plus 
un préalable ; la répartition et l’hétérogénéité des données deviennent des alliés et non des faux 
amis! 
 
catégorie volume de données (approx.) taille
Débutant 5 000 Plus de 250 Ko
Avant 1985 200 000 2 Mo
1995 et ... 1000 000 000 000 1 000 000 Mo
Années 2000 1000 000 000 000 000 400 Go (109)
BD du futur 10 000 000 000 000 000 000 4000 To (1012)
Figure 1.3
Cette  plus  grande  disponibilité  des  données  sʹaccompagne  aussi  dʹune  croissance  importante 
des  coûts  dʹexploitation  et  des  investissements  dans  la  mise  en  oeuvre  des  infrastructures.  La 
figure  1.3  présente  les  différentes  bases  de  données  et  leurs  volumes  repères.  Ces  chiffres  sont 
des approximations pour illustrer lʹévolution de la taille des bases de données. La réalité risque 
dʹêtre plus exigeante en matière dʹespace de stockage, ainsi quʹen puissance de traitement et de 
vitesse des réseaux. Il est évident que les bases de données sont en pleine croissance et cela, en 
nombre et en volume. Les espaces de stockage et les moteurs SGBD devront être adaptés à ces 
nouveaux  défis  en  offrant  des  disques  de  plus  de  500  Go/disque  gérés  par  des  contrôleurs 
multidisques  et  des  systèmes  multiprocesseurs  dotés  de  mémoires  communes.  Les  systèmes 
dʹexploitation  sont  déjà  prévus  pour  gérer  ces  types  dʹordinateurs  et  intégrer  davantage  les 
fonctionnalités des réseaux. 
  
En résumé, lʹévolution rapide des besoins en matière de stockage et de traitement des données a 
créé  des  attentes  qui  imposent  de  nouvelles  fonctionnalités  aux  SGBD  et  des  conditions 
dʹexploitation  beaucoup plus exigeantes : 
a)  La transparence des données transmises aux applications : formats différents variant du type 
primitif au type abstrait, cette dernière structure étant nécessaire pour les documents graphiques 
et sonores, etc. 
b) La confidentialité des données : gestion de la visibilité des données, des droits d’accès et du 
suivi de l’usage des données pour les usagers distants utilisant une vue partielle de la base. Le 
chiffrement par les algorithmes spécialisés bien connus ‐ DES, RSA ou Telepass ‐ et compaction 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 7

des données multimédias sont maintenant des exigences courantes de la gestion des données et 
de leur exploitation dans les systèmes de commerce électronique. 
c)  Le  renforcement  des  contraintes  de  cohérence  plus  complexes  définies  dans  le  modèle  de 
données.  Par  exemple,  une  contrainte  peut  être  formulée  ainsi :  un  employé  ne  peut  pas  avoir  un 
salaire annuel supérieur à celui de la moyenne des salaires consentis aux cadres de niveau 2, ou encore  
un  solde  d’inventaire  ne  peut  pas  franchir  la    barre    inférieure  de  20  articles  lorsque  le  carnet  de 
commandes  est  rempli  aux  deux  tiers  de  sa  capacité.  Ces  contraintes  seront  implémentées  par  le 
SGBD et non par les applications et ce, pour garantir l’uniformité de leur implémentation. Elles 
sont vérifiées automatiquement par des déclencheurs ou des procédures internes à la BD afin de 
mieux  garantir  lʹintégrité  des  données  et  cela  au  regard  des  règles  qui  prévalent  dans  le 
fonctionnement de l’organisation.  
d) Lʹaccès multiposte et concurrent aux données s’impose de plus en plus avec un grand volume 
de transactions peu importe si l’approche est centralisée ou client‐serveur. Les grands systèmes 
transactionnels doivent maintenant pouvoir traiter des volumes de transactions qui dépassent le 
cap des 1000 transactions à la minute. L’horizon des débits de transactions de l’ordre de 2000 à 
la  seconde  est  déjà  perceptible!  La  puissance  des  processeurs  utilisée  par  les  serveurs  et  la 
rapidité  des  disques  permettent  de  répondre  à  ces  exigences  d’exploitation.  Les  organisations 
doivent cependant y investir des sommes importantes.  
1.4 Évolution des logiciels pour la gestion de données
Les logiciels SGBD multitâches et parallèles présentement en service sont l’aboutissement d’une 
évolution  technologique  des  logiciels  pour  la  gestion  des  données  dont  les  premières  versions 
exploitaient essentiellement le gestionnaire de fichiers du système dʹexploitation hôte (OS‐SGF) 
comme par exemple, RMS (Record Management Storage) de l’ancienne société Digital Equipment 
Corporation et VSAM (Virtual Storage Access Method) de la société IBM. Par la suite, les logiciels 
SGBD    ont  évolué  vers  une  plus  grande  autonomie  par  rapport  au  système  dʹexploitation  en 
prenant à leur charge la lecture et lʹécriture des records et des pages sur les disques, en plus de  
gérer les transactions et de leur recouvrement en cas de panne. 
Fonctionnalités courantes du logiciel SGBD 
Ce  logiciel  spécialisé  et  complexe  intègre  donc  les  services  de  base  offerts  par  les  systèmes  de 
gestion de fichiers et offre en sus une gamme étendue de fonctionnalités nouvelles.  
 
Parmi celles‐ci, mentionnons  les suivantes : 
a)  La  description  des  données  (appelée  couramment  les  métadonnées)  est  ajoutée  au 
dictionnaire et  devient incontournable pour accéder au contenu de la base. 
b)  Lʹindépendance  des  données  et  des  applications  est  renforcée  en  reconnaissant  plusieurs 
niveaux  de  métadonnées.  Cette  vision  multiniveau    permet  de  séparer  les  aspects  logiques  et 
physiques des structures de données. Ainsi, les changements de structure de la base de données 
nʹont plus dʹimpacts majeurs sur les applications et inversement. 
c)  Lʹusage  d’un  outil  de  gestion  de  l’abstraction  des  données  (l’usage  d’un  modèle  de 
représentation  générique  des  données  et  de  leurs  associations)  permet  de  visualiser  plus 
facilement    la  complexité  des  structures  de  données  et  de  les  spécifier  par  un  langage  de 
description  compatible  avec  le  logiciel  SGBD.  Les  structures  logique  et  physique  des  données 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 8

peuvent être alors obtenues à partir dʹun modèle de haut niveau dit conceptuel qui ne tient pas 
compte des particularités tributaires de l’implémentation de chaque SGBD.  
d)  Le  partage  contrôlé  et  sécurisé  des  données  est  généralisé  pour  toutes  les  applications 
développées par une organisation centralisée ou répartie. 
1.5 Abstraction des données
La notion dʹabstraction des données concerne la représentation générique des données (souvent 
par un modèle graphique) et des associations qui leur donnent un sens plus riche. De plus, les 
traitements  essentiels  sur  le  modèle  sont  pris  en  compte  dès  l’étape  de  la  spécification  du 
modèle. Plusieurs genres de modèles sont proposés, tous caractérisés par leur indépendance au 
regard du logiciel SGBD. Ces modèles dits conceptuels sont de plus en plus riches sur le plan de 
la représentation et visent à décrire les données et leurs traitements pour coller le plus possible à 
la  réalité  opérationnelle  des  organisations.  Le  processus  d’abstraction  des  données  permet 
essentiellement  de  spécifier  les  structures  des  données  à  plusieurs  niveaux  et  dʹesquisser  la 
logique  de  traitement  par  les  applications.  Le  produit  de  cette  abstraction  est  le  modèle 
conceptuel de données (MCD). 
Niveaux de représentation des données 
Il  y  a  trois  niveaux  d’abstraction  reconnus  dans  la  modélisation  des  données  lesquels 
correspondent respectivement aux besoins des utilisateurs, des développeurs et à ceux du DBA : 
a) Le niveau conceptuel : Cʹest le niveau supérieur où les structures physiques et les fichiers sont 
ignorés pour accentuer la description sémantique des données vue par rapport à la réalité d’une 
organisation. On tente de décrire les données de lʹorganisation en conservant le plus possible les 
liens entre elles. On met aussi lʹaccent sur l’homogénéité et le partage du nom des éléments de 
données et de leur type ou structure logique. Le modèle conceptuel est stocké dans le catalogue 
(dictionnaire) du  logiciel SGBD.  
                       
Exemple  :  Le  fait  contraignant  quʹun  employé  travaille  obligatoirement  dans  une  ou  plusieurs 
usines  et  cet  autre  fait  que  dans  une  usine  travaillent  obligatoirement  de  un  à  plusieurs 
employés doivent être représentés le plus fidèlement possible par le modèle conceptuel. 
 
 
Application-1 Application-2 Application-3
(vue-1) (vue-2) (vue-3)

Modèle conceptuel des données Mapping: Externe-Conceptuel

Détails croissants
Modèle logique
Mapping: Conceptuel-Interne

Modèle physique

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 9

Figure 1.4
b)  Le  niveau  physique :  Cʹest  la  description  physique  des  données  faite  par  le  DBA  (Database 
Administrator).  Cʹest  à  ce  niveau  quʹil  faut  spécifier  lʹorganisation  physique,  les  structures  de 
stockage et les modes d’accès possibles. Ces métadonnées de niveau 2 sont  essentielles pour que 
le SGBD  réalise lʹaccès physique aux données.   
                         
c) Le niveau externe : C'est la vue de la base de données sous l'angle d’une application
particulière. Les données doivent être dans un format compatibles avec celui du langage de
programmation, sinon le SGBD devrait en assurer la conversion.

Les divers niveaux de description seront formalisés par un Langage de Définition des Données
(le LDD ou en anglais le DDL) propre à chaque logiciel SGBD. Ce langage doté d’une syntaxe
relativement simple permet de définir les données visibles et accessibles à chaque application.
Vues logiques de la structure de la base de données  
Chaque application utilise un sous‐ensemble de données, c’est‐à‐dire une vue particulière de la 
base  selon  les  besoins  de  la  logique  de  son  traitement  (figure  1.5).  La  vue  est  bien  sûr  définie 
différemment selon les modèles de données, mais son rôle demeure le même soit de contraindre 
une  application  à  exploiter  que  certaines  données,  soit  en  mode  mise  à  jour,  soit  en  mode 
lecture. Elle est aussi dynamique dans le sens quʹelle donne une vision des données qui reflète 
toujours le dernier état de la base de données. Elle peut être illustrée approximativement par les 
parties tramées encadrées par une ligne pointillée. 
                                      
Vue ClientIndustriel  
  Produit
 
 
 
 
Matériau  
 
 
 
Les parties encadrées sont des vues.
 
 
 
Modèle conceptuel et les vues  
Figure 1.5

Par exemple, une application nommé ClientIndustriel est autorisée à exploiter qu’une partie des
données Client et une autre partie des données Matériau. Les autres attributs lui sont alos
interdits d’accès via le modèle externe.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 10

Description des entités (instances) de la classe Client  
Considérons une base de données très simple avec quelques classes (connues sous l’appellation
Entités ou Entity Type) dont une nommée Client. Celle-ci est définie par son schéma, c'est-à-dire
par sa structure spécifiée par un langage de description qui est particulier à chaque système
SGBD. Ce langage (DDL pour Data Definition Language) permet de décrire la structure logique
de la classe et le type de chaque élément qui la compose sans cependant faire mention des
implémentations et des traitements possibles. Le schéma de la base de données comportera donc
autant de définitions qu'il y a de classes. Par exemple, la structure de la classe Client est spécifiée
différemment selon le niveau de représentation :
a) Au niveau conceptuel, la structure logique du dossier Client pourrait être la suivante :  
           
Client = record,
patronyme: string 30,
adresse: string 20,
ville: string 15,
noCompte: integer;
 
 
Les libellés et les types de données peuvent être ceux implémentés et rendus disponibles par le 
logiciel  SGBD.  Ils  sont  utilisés  pour  la  description  de  la  classe  Client.  En  principe,  une 
application peut accéder à la classe Client à travers une vue particulière définie avec des types 
qui correspondent plus précisément aux données dont elle a besoin pour ses traitements et qui 
de préférence devraient être ceux du langage utilisé pour le traitement. Dans le cas contraire, il y 
aura une conversion (casting) des données à la charge de l’application ou du logiciel SGBD selon 
le cas. La structure qui est visible par la vue est dite externe.  
                  
b)  Au  niveau  externe,  la  structure  exploitée  par  lʹapplication  est  généralement  légèrement 
différente  en  termes  de  libellés,  de  types  et  dʹattributs.  Ainsi,  la  partie  du  Client  visible  à  une 
application nommée ClientRegion a une structure définie ainsi : 
 
ClientRegion = record based on Client
nom: string 20,
null, /*attribut adresse n'est pas utile à l'application*/
municipalite: string 15,
compteBancaire: string 5 ;
 
Les éléments de la vue externe peuvent être différents en nombre, en dénomination et en type 
au  regard  de  ceux  utilisés  par  le  modèle  conceptuel.  Dans  lʹexemple  ci‐dessus,  la  vue 
ClientRegion  représente  les  clients  de  Québec.  Les  applications  qui  utilisent  cette  vue 
nʹexploitent  pas  lʹélément  adresse  de  sorte  que  celui‐ci  nʹest  pas  spécifié  dans  la  vue  et  son 
gommage virtuel est signalé à l’interne par un indicateur d’absence appelé le null.   
c) Le niveau physique   
Au niveau 3, le physique, les éléments de la structure de Client sont définis par rapport aux
caractéristiques des structures de stockage disponibles et mises en oeuvre. Voici un exemple
hypothétique du schéma physique :

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 11

Elément rang position type longueur volume


patronyme 1 1 1 30 rd40 
adresse 2 31 1 35 rd40
ville 3 66 1 20 rd40
pointeur de suite 4 86 7 4 rd40
Figure 1.6
                                           
Le passage (mapping) d’un niveau de représentation à l’autre est assuré par le SGBD, notamment 
par des procédures internes qui permettent la consultation et l’utilisation des métadonnées du 
dictionnaire  du  SGBD.  Ce  dernier  est  stocké  dans  la  base  elle‐même  en  utilisant  les  même 
structures que celles des données. Comme il s’agit de données qui décrivent les données de la 
base, elles sont libellées métadonnées. 
                     
  Application
DD

SGBD

BD

Système de fichiers

Figure 1.7
Dictionnaire de données 
Le  dictionnaire  de  données  (DD)  est  donc  souvent  une  métabase  qui  contient  les  informations 
pour  réaliser  les  diverses  transpositions  de  schémas,  pour  exploiter  au  plus  bas  niveau 
d’implémentation les structures des fichiers et pour vérifier les droits dʹaccès, les  formats et les 
contraintes imposées aux données. Le dictionnaire de données est donc un dépôt d’informations 
essentielles à lʹexploitation de la base. Tout ordre DML de manipulation des données exige un 
accès au dictionnaire par le noyau du SGBD et cela, afin de trouver le nom interne des éléments 
de  données  du  schéma  et  les  adresses  nécessaires  pour  accéder  aux  structures  de  données  sur 
disque. En cours de traitement, les métadonnées sont généralement chargées à demeure dans la 
RAM, et cela afin de minimiser les  accès aux disques qui ralentissent le temps de réponse aux 
requêtes des applications.  
Opérations de mise en oeuvre de la base de données 
La mise en oeuvre dʹune base de données comporte de nombreuses activités qui appartiennent à 
des phases différentes dʹun projet, et qui sont réalisées lors de lʹanalyse informatique : 
a)  Conception:  Mise  au  point  du  modèle  conceptuel,  définition  des  tables,  des  domaines,  des 
types de données et des contraintes. C’est la création des métadonnées et leur stockage dans le 
dictionnaire. 
b) Création : Allocation des espaces physiques et chargement des données de la base. 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 12

c) Exploitation: Insertion, suppression, modification et indexation des données en toute sécurité 
tout en garantissant intégralement la cohérence de la base. 
d)  Gestion  de  la  BD  :  Définition  des  droits  dʹaccès,  de  la  stratégie  de  reprise  après  une  panne, 
gestion des copies de sûreté et indexation des données. 
 
Le  SGBD  fournit  un  langage  de  manipulation  des  données   (appelé  LMD  ou  DML  pour  Data 
Manipulation Language) composé de clauses dont la syntaxe est relativement simple. Ces clauses 
DML permettent de spécifier ce qui doit être recherché, mis à jour, supprimé ou ajouté dans la 
base.  Les  ordres  DML  types  sont  le  SELECT,  INSERT,  le  UPDATE  et  le  DELETE.  Souvent,  la 
clause  SELECT  est  considérée  à  part,  comme  une  requête  qui  est  de  loin  la  clause  la  plus 
complexe.  Depuis  quelques  années,  le  langage  SQL  et  le  DML  proposés  par  le  comité  de 
normalisation ISO sont de plus en plus adoptés par les grands éditeurs de SGBD.  
 
Il y a essentiellement trois modes d’implémentation du SQL et du DML : 
a‐ Langage de requête autonome  
Le langage autonome peut être utilisé directement pour manipuler la base de données sans avoir 
nécessairement besoin de lʹenvironnement dʹun langage hôte. Il permet essentiellement la mise 
au point des clauses de requête,  mais ne permet pas le traitement des données obtenues dans la 
réponse,  sauf  s’il  est  intégré  dans  un  langage  de  programmation  de  troisième  (L3G)  ou  de 
quatrième génération. Voici, par exemple, une question simple à traiter par le système :  
 
«Lister éditeur et le titre du livre répertorié avec le ISBN 4578 »

Cette requête traduite en pseudo langage DML serait alors la suivante :

LIST editeur, titre FROM Livre WHERE ISBN = 4578 ;


 
Pour  exécuter  cette  requête  et  afficher  la  réponse,  l’interpréteur  du  DML  devra  lancer  une 
procédure  interne  LIST  dont  les  paramètres  sont  le  nom  de  lʹEntité  (Livre)  et  le  prédicat  de 
recherche (Where).  
b‐ DML  intégré  dans une application 3ème génération (L3G)  
Les  ordres  DML  sont  placés  dans  un  programme  L3G  (Pascal,  PL/1,  ADA,  C,  C++,  Java)  et 
chaque ordre est exécuté séparément.  Il y a deux façons de traiter les ordres DML imbriqués : 
a)  Par  traduction  :  le  précompilateur  reconnaît  les  ordres  DML  identifiés  par  un  délimiteur 
particulier comme le # ou le EXEC SQL, et les transforme en appel de procédure du langage hôte 
pour ensuite passer à la phase compilation. 
  
Par exemple: Le système VAX/DBMS utilise le délimiteur # pour annoncer un ordre DML  :   
# FIND FIRST editeur FROM Livre USING ISBN = 4578;
# FIND FIRST titre FROM CollectionDeLivre USING ISBN = 4578;
 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 13

b)  Par  compilation  avec  un  compilateur  étendu  :  le  compilateur  reconnaît  les  ordres  DML 
identifiés  par  un  marqueur  spécial  et  les  traduit  directement  en  code  du  langage  de  3e 
génération (par exemple en C ou en COBOL).  
Exemple  : 
{
int no_isbn;
...
gets (no_isbn); -- 4578
editeur_v = dbmslist ('editeur','Publication',
'ISBN = no_isbn');
titre_v = dbmslist ('titre','CollectionDElivre',
'ISBN= no_isbn');
printf('editeur = %s titre = %s \n',&editeur_v,&titre_v);
}
Figure 1.8

La  fonction  dbmslist()  permet  de  transmettre  les  arguments  au  processus  SGBD  avec  une 
adresse de retour utilisée pour récupérer les données de la réponse. 
c‐ Langage de quatrième génération (L4G) 
Le langage de 4e génération est de type autonome auquel on a ajouté les structures de contrôle 
pour  lʹitération  et  lʹalternative.  Lʹenvironnement  dʹun  L4G  inclut  généralement  une  interface 
graphique  pour  faciliter  la  composition  des  modules  et  des  panoramas  :  NOMAD,  FOCUS,  
PROC,  Developer/Forms  (Oracle),  PowerHouse,  etc.  Un  programme  complet  peut  alors  être 
élaboré et inclure les ordres DML et cela, avant sa traduction par un compilateur spécialisé.  
d‐ Interface d’application (API) 
Une  API  est  une  bibliothèque  de  fonctions  utilisées  par  les  applications  pour  communiquer 
directement  avec  un  SGBD.  Ces  fonctions  dotées  généralement  de  plusieurs  paramètres   
réfèrent  aux  procédures  des  DML  développées  par  chaque  SGBD,  dont  l’une  gère  la 
communication  par  les  sockets.  Une  telle  bibliothèque  peut  être  normalisée  afin  de  fournir  une 
interface commune pour lʹaccès aux données, peu importe le SGBD et cela, par lʹentremise dʹun 
pilote (driver) particulier. Cela renforce l’indépendance de l’application à lʹégard du SGBD. Les 
interfaces ODBC (Open Data Base Connectivity) et SAG (SQL Access Group) sont des propositions 
pour une API normalisée. Ces efforts de normalisation visent à pérenniser les applications en les 
rendant encore plus indépendantes du SGBD. 
1.6 Administrateur de la base de données
L’administrateur  de  la  base  (DBA)  est  devenu  un  acteur  incontournable  dans  la  gestion  des 
données corporatives. Sa fonction est de gérer la création et le fonctionnement général de la base 
de données en surveillant particulièrement le placement des données, la performance des accès 
et  les  autorisations  consenties  aux  utilisateurs.  Il  est  aussi  souvent  responsable  du 
fonctionnement  du  réseau,  de  la  prise  des  copies  de  sûreté  et  du  fonctionnement  des 
ordinateurs‐serveurs. 
 
Voici quelques  tâches qui incombent généralement au DBA :  

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 14

 
a) Le contrôle du logiciel et des métadonnées. 
b) La gestion de la base : localisation, indexation, allocation des espaces sur disque, stratégie de 
reprise et de sauvegarde (Backup). 
c) La  coordination  du  développement  modèle  conceptuel :  arbitrage  et  médiation  entre  les 
concepteurs de systèmes et les usagers. 
d) Lʹautorisation des vues et des droits d’accès. 
e) Le contrôle  de l’évolution du MCD ainsi que de la réorganisation de la BD qui en découle. 
f) La surveillance de la performance du SGBD et la réalisation des mises au point (fine tuning). 
g) Le choix du matériel au regard des exigences du SGBD et des traitements escomptés. 
h) La définition des déclencheurs (triggers) et des procédures internes (packages) stockés dans 
le  dictionnaire  de  la  base  de  données.  Ces  dernières  permettent  dʹimplémenter  les  règles 
dʹintégrité et de validité. 
La diversité et la spécialisation des tâches exigent une vaste connaissance de la part du BDA.  
Typologie des utilisateurs 
De  nombreux  utilisateurs  participent  à  l’exploitation  des  données  et  en  utilisent  les  résultats 
pour  les  fins  de  gestion  organisationnelle.  Dans  certaines  organisations,  ils  participent 
activement à la conception de la base de données.  
 
Il est possible de regrouper approximativement les utilisateurs en trois catégories : 
a)  Les  utilisateurs  occasionnels  :  Ils  privilégient  le  langage  de  requête  en  mode  interrogation 
pour obtenir des réponses courtes du genre factuel ou agrégé. Souvent, les requêtes sont de type 
décisionnel. Pour les cadres moyens et supérieurs, les requêtes ont un caractère de synthèse sou‐
tendant  l’agrégation  des  données :  tableau  de  bord,  applications  avec  menus,  OLAP...  Ces 
utilisateurs  ont  besoin  d’un  langage  de  requête  performant  imbriqué  dans  une  interface  très 
conviviale. 
b) Les utilisateurs réguliers de niveau opérationnel : Ils utilisent des programmes spécialisés et 
encapsulés  dont  les  fonctionnalités  sont  fixées  à  l’avance  pour  offrir  une  gamme  limitée  de 
services. Ils génèrent des requêtes transactionnelles.  
c)  Les  utilisateurs  spécialistes  :  les  concepteurs  sont  les  artisans  des  applications  au  nom  des 
utilisateurs. Leur travail est caractérisé par les facettes suivantes :  
‐ Usage de L3G, L4G, DML et API. 
‐  Traitements  complexes pour  implémenter  une  logique  d’application  et  mettre  en  œuvre 
des types complexes. 
‐ Intervention critique dans les processus d’affaires d’une organisation. 
‐ Bonne connaissance du SGBD et des autres environnements. 
‐ Implémentation du mode transactionnel et la gestion des données multimédias. 
Impacts du logiciel SGBD pour les organisations 
L’intégration  du  logiciel  SGBD  dans  le  système  dʹinformation  dʹune  organisation  a  des  effets 
positifs et parfois négatifs sur l’organisation du travail des concepteurs.   
 
Voici quelques uns des effets positifs : 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 15

1. Les  applications  nʹont  plus  à  gérer  la  redondance  de  données,  celle‐ci  est  contrôlée  par  le 
SGBD. 
2. Chaque application est, par définition, en concurrence pour le partage des données. La
concurrence des accès est prise en charge par le SGBD quelle que soit l’architecture de
l’environnement : centralisée, répartie, client-serveur ou web.
3. Lʹaccès aux données par une application est validé afin de renforcer la sécurité. 
4. Lʹapplication  client  dispose  de  plusieurs  interfaces  spécialisées  qui  sont  adaptées  aux 
usagers (technologie GUI ou générateur dʹinterfaces). Il en découle une réduction du temps 
de  développement  des  applications  (estimé  à  30  %)   et  une  plus  grande  réutilisation  des 
procédures développées avec ou sans un langage L4G. 
5. Le renforcement des contraintes d’intégrité est assuré par le logiciel SGBD. Cela simplifie les 
applications et garantit la vérification uniforme des règles d’intégrité. Il y a donc au départ 
une incitation pour établir des standards dans la gestion et le traitement des données dʹune 
organisation.  
6. En cas de panne, le recouvrement est pris en charge par le SGBD  grâce à des utilitaires de 
reprise et de sauvegarde.  
7. Le  rôle  de  DBA  est  exigeant  à  plusieurs  égards.  Son  titulaire  doit  manifester  à  la  fois  une 
maîtrise des techniques et avoir des qualités du chef de projet. 
Effets négatifs découlant de l’exploitation du SGBD 
Le  logiciel  SGBD  est  parfois  vu    comme  un  super‐mécanisme  d’accès  aux  données.  Les 
ressources mises en oeuvre dans ce logiciel sont importantes et, de ce fait, un SGBD demeure un 
outil  particulier  quʹil  faut  utiliser  seulement  lorsque  lʹimportance  des  besoins  de  traitement 
lʹimpose. Malgré lʹusage répandue des SGBD, le concepteur doit être averti de certaines limites 
inhérentes à lʹintégration du SGBD dans un environnement dʹexploitation de données : 
 
a) Les  frais  dʹacquisition  et  dʹexploitation  (matériel,  logiciel,  sécurité,  personnel)  sont 
relativement  élevés  et  récurrents.  Ils  peuvent  être  bas  pour  un  monoposte,  mais  ils 
augmentent rapidement avec le nombre de stations autorisées à accéder aux données. 
 
b) Les  applications  en  temps  réel  sont  difficiles  à  réaliser  avec  un  logiciel  SGBD.  En  effet,  un 
temps de réponse inférieur à 0,5 seconde avec un volume élevé de transactions est  difficile à 
respecter, sauf si le SGBD est conçu pour un environnement temps réel.  
 
c) Le  temps  de  réponse  est  souvent  inacceptable  pour  un  nombre  de  requêtes  (transactions) 
supérieurs  à  1000  Transactions  Par  Seconde  (TPS).  Le  traitement  est  cependant  excellent 
pour  un  TPS    qui  se  situe  autour  de  400.  Toutefois,  des  machines  dotées  d’architectures 
particulières permettent de briser cette barrière et traiter des charges de plus de 1500 TPS. 
 
d) En  mode  monoposte,  l’accès  aux  données  qui  sont  peu  structurées  ne  nécessite  pas 
obligatoirement  un  SGBD :  un  gestionnaire  de  fichiers  suffirait  largement.  L’exploitation 
d’une SGBD pour un tel besoin n’est pas appropriée. 
 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 16

e) La  gestion  des  données  multimédias  (son,  couleur,  animation)  est  encore  difficile,  mais 
devient possible. Le stockage et le repérage posent problème pour ce qui est des structures 
de données, leur gestion, leur mise à jour et la gestion des versions. À ces difficultés, il faut 
ajouter  des  temps  de  réponse  encore  trop  lents  en  raison  de  la  vitesse  (largeur  de  bande) 
encore insuffisante des réseaux.   
 
f) Le  potentiel  de  déduction  logique  à  partir  des  données  de  la  base  est  encore  une 
fonctionnalité théorique peu ou pas implémentée dans les systèmes commerciaux courants. 
 
Toutefois,  la  tendance  est  telle  qu’il  est  maintenant  difficile  de  stocker  des  données  sans  avoir 
recours à un SGBD. En effet, le service de fichiers est de plus en plus absent dans les systèmes 
qui se limitent souvent à offrir un fichier séquentiel élémentaire. Tout autre accès plus complexe 
tel le direct ou le séquentiel indexé doit être mise en oeuvre par le client.  
                   
1.7 Architecture générale du système de gestion de bases de données (SGBD)
Lorsqu’une  requête  parvient  au  SGBD,  par  lʹentremise  du  logiciel  de  communication  ou  du 
réseau,  l’enchaînement  des  opérations  pour  calculer  la  réponse  sʹappuie  sur  un  ensemble  de 
modules  fonctionnels  du  noyau  du  SGBD  qui  sont  regroupés  sous  les  appellations 
fonctionnelles suivantes :  EXECUTEUR et ACCESSEUR. Voici le rôle général de chaque module 
d’un SGBD :                                        

Analyse syntaxique
Analyseur
Analyse sémantique

Traduction Génération du plan d'exécution


Métabase Contrôle d'intégrité
Contrôle des autorisations

Optimisation Modification du plan d'exécution


selon les coûts et les règles

Sous-système
d'affichage
Calcul Contrôle de la concurrence
Atomicité de la transaction
Exécution des opérateurs

Base de
données
Accesseur

Figure 1.9

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 17

Analyseur  :  Le  traitement  de  la  requête  reçue  de  l’application  débute  par  une  analyse 
syntaxique pour vérifier sa conformité avec la grammaire du langage de requête (ou du DML). 
Par la suite, une analyse sémantique vérifie  que seuls les objets connus par la  vue  sont référés 
par la clause. 

Traducteur  :  Lorsque  la  requête  utilise  une  vue  (sous‐schéma),  le  passage  des  références  des 
objets  de  la  vue  et  à  ceux  du  schéma  est  effectué  par  le  module  de  traduction.  De  plus,  ce 
module vérifie si la requête a les droits d’accès aux données pour le type de traitement spécifié. 
Finalement, lorsqu’il s’agit d’une modification ou d’un ajout de données, le module vérifie si les 
contraintes d’intégrité seront respectées suite aux actions demandées. 
 
Optimiseur : Le rôle de ce module est de transformer la requête initiale en une autre équivalente 
dont  le  plan  d’exécution  (la  séquence  des  opérateurs  élémentaires)  est  de  nature  à  fournir  un 
calcul plus rapide de la réponse. Ce plan est une véritable feuille de route pour la réalisation du 
calcul  :  lecture  de  l’index  Y,  accès  aux  enregistrements  du  fichier  Z  par  une  méthode  d’accès. 
Ensuite,  l’optimiseur  établit  le  coût  du  calcul  de  la  réponse  selon  un  modèle  de  performance 
(temps  en  fonction  du  volume  de  données) et construit  le  plan  d’accès  optimisé.  Le  lancement 
du calcul de cette requête est maintenant prêt.  
 
Calcul : Le plan optimisé est exécuté par ce module conjointement avec le module transactionnel 
et le répartiteur pour  implémenter lʹatomicité de lʹexécution et le multithreading pour assurer un 
certain  parallélisme  dans  lʹexécution  des  requêtes  concurrentes.  C’est  le  module  EXECUTEUR 
qui  implémente  la  concurrence  et  assure  l’atomicité  via  un  module  de  Gestion  Transactionnel. 
L’exécuteur est une tâche qui exploite les primitives du système d’exploitation nécessaires pour 
lʹimplémentation des fonctionnalités du SGBD. 
 
Accesseur : C’est le module chargé de trouver et de placer dans la RAM  les pages demandées 
par  l’exécuteur.  Il  est  aussi  chargé  sur  demande  de  les  écrire  sur  disque  et  dʹen  faire  la 
journalisation  externe.  Cette  dernière  opération  consiste  à  écrire  sur  une  mémoire  stable  (le 
disque  par  exemple)  les  données  avant  les  modifications  et  celles  après  les  modifications 
effectuées. Il gère les listes de pages (avec une politique de placement LRU) placées dans la ZMP 
tout  en  prenant  en  compte  le  statut  de  celles‐ci.  Ce  module  exécute  les  procédures  suivantes : 
INPUT (no‐page) et OUTPUT (no‐page). 
Sommaire 
La gestion des données occupe une place importante dans le fonctionnement des organisations. 
Elle  est  largement  tributaire  des  systèmes  de  gestion  de  base  de  données  et  des  réseaux. 
L’évolution  des  logiciels  SGBD  est  marquée  par  la  généralisation  de  cet  outil  qui  assume  des 
fonctions  capitales  de  stockage,  de  recherche,  de  partage  et  de  cohérence  des  données.  Les 
utilisateurs  de  ces  systèmes  sont  l’ensemble  des  acteurs  d’une  organisation  et  cela,  à  tous  les 
niveaux  de  responsabilité.  Le  volume  des  données  à  gérer  est  souvent  astronomique  et  leurs 
types de plus en plus variés. Le rôle essentiel du SGBD consiste à assurer une continuité dans les 
services  dʹaccès  aux  données    des  transactions,  ce  qui  sous‐tend  un  support  efficace  du 
personnel  technique  dont  la  spécialisation  et  la  compétence  sont  critiques  dans  le 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 18

fonctionnement  de  la  base  de  données.  Les  nouvelles  architectures,  notamment  celles  de  type 
client/serveur,  le  traitement  distribué  (avec  une  base  de  données  réparties)  et  le  browswer  de 
l’internet favorisent le redéploiement des ressources informatiques selon un mode qui privilégie 
la décentralisation des traitements et éventuellement celle des données. La prochaine génération 
sera  probablement  celle  des  bases  de  données  via  l’Internet  conjugée  avec  une  architecture 
multi‐niveau.  
                           
 
Exercices
1‐ Quelles sont les fonctions propres à un système de gestion de bases de données (SGBD) ? 
2‐ Quel rôle particulier peut avoir une vue au regard dʹune application ? 
3‐ Lʹaccès aux données est assuré par un SGBD et cela, pour chaque application autorisée. Quel 
est  lʹapport  des  index  dans  cet  accès  aux  données  ?  Est‐ce  que  les  index  sont  essentiels  pour 
assurer lʹexploitation des données? 
4‐  Décrire  une  situation  fictive  qui  exigerait  une  réorganisation  de  la  base  de  données  par 
l’administrateur de la base (DBA) ?  
5‐ En vous référant à lʹarchitecture à trois niveaux, expliquer comment une partie de la base peut 
être déplacée sur un autre disque, sans que les applications en production soient perturbées ou 
rendues non opérationnelles. 
6‐  Formuler  une  question  en  langage  naturel  qui  pourrait  facilement  être  reformulée  par  le 
module optimiseur afin de fournir plus rapidement la même réponse. 
7‐ Commenter la notion de métadonnées et expliquer pourquoi celles‐ci doivent être gardées de 
préférence en RAM de l’ordinateur et non sur disque lorsque le SGBD est en exploitation. 
8‐  Expliquer  comment  les  modifications  aux  métadonnées  peuvent  invalider  l’accès  aux 
données. 
9‐  Quel  est  le  rôle  du  dictionnaire  de  données  dans  le  traitement  d’une  requête  à  la  base  de 
données ? Expliquer simplement les étapes qui vous apparaissent évidentes pour son traitement. 
10‐  Pour  un  environnement  de  travail  multiusager,  donner  deux  fonctionnalités  importantes   
du logiciel SGBD et commenter leur rôle respectif.  

Références Chapitre 1

1  GARDARIN,  G.,  Maîtriser  les  bases  de  données;  modèles  et  langages,  Paris,  Eyrolles,  1993,  
ISBN 2‐212‐08727‐6. 
2  TOMITA,  T.,  The  Volume  of  Information  Flow  and  the  Quantum  of  Media,  ITU 
Telecommunications Journal, v. 42, no 6, 1975, p. 339‐349. 
3 NORA, S., MINC, A., L’informatisation de la société, Paris, La Documentation française, 1978. 
4 WILLIAMS, M. E., Data Bases and On‐line Statistics for 1979, ASIS Journal, December, 1980, p. 
123‐135. 
5  How Much Information 2003, Peter Lyman, Hal Varian, School of Information Management 
and Systems, University of California at Berkeley, 2003.  
6 IOUW, How Big Is Your Database?,  Oracle Magazine, May‐June 1995, p.113‐116.    

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
19

Chapitre 2
Architecture fonctionnelle du logiciel SGBD

2.1 Système de gestion de base de données 
Un  système  SGBD  est  un  progiciel  capable  de  gérer  adéquatement  au  moins  un  modèle  de 
données et de faire des mises à jour, des suppressions et des ajouts dans une base de données. Il 
assure aussi la persistance des données pour les applications. Il est un composant essentiel dans 
lʹarchitecture plus générale que sous‐tend un Système à Base de Données (SBD). 
 
SBD = (n x BD = (données + dictionnaire)) + SGBD avec n >= 1

La  complexité  du  SGBD  dépend  des  fonctionnalités  implémentées  dans  lʹenvironnement 
informatique.  Le  Système  de  Gestion  de  Base  de  Données  (SGBD)  peut  être  exploité  dans 
lʹenvironnement  de  la  micro  ou  de  l’informatique  des  grands  systèmes  avec  une  architecture 
centralisée, Client/Serveur ou répartie. Quelle que soit l’approche, le moteur SGBD joue un rôle 
central dont l’essentiel est presque toujours le même peut importe l’éditeur du système. 
Modèle de données 
C’est  un  outil  externe  de  représentation  générique  des  données,  c’est‐à‐dire  qui  ne  retient  que 
l’essentiel  dans  la  spécification  des  données  et  cela,  au  moyen  des  éléments  de  modélisation 
suivants :  
a) Types de données        b) Associations     
c) Contraintes syntaxiques et sémantiques  d) Méthodes des classes 
 
Le  modèle  de  données  est  exploité  par  un  jeu  d’opérateurs  primitifs  capables  de  réaliser  les 
manipulations sur les données conformément aux contraintes et aux possibilités imposées par la 
structure du modèle. Il est très souvent représenté par un graphe connexe, cʹest‐à‐dire dont les 
éléments sont tous reliés. 
Modèles conceptuels de données 
Plusieurs modèles (1) sont proposés pour l'organisation et la représentation générique des
données. Seuls quelques-uns marqués par un astérisque s’imposent dans la pratique :

a) Modèle E/R* d) Modèle à objets*


b) Modèle relationnel* e) Modèle UML*
c) Modèle relationnel-objet* f) Modèle logique ou déductif
 
Avec le développement des systèmes hypertextes, de nouveaux modèles de données  intègrent 
non  seulement  les  données,  le  son  et  les  images,  mais  aussi  les  mécanismes  de  navigation 
possibles  prévus  pour  une  application  (2,3).  Par  exemple,  le  modèle  RMDM2  propose  une 
démarche  intégrée  pour  le  développement  des  applications  hypertextes:  lʹanalyse  de  besoins 
concernant les données et la navigation, la modélisation des classes, des facettes et des chemins 
de  navigation,  la  conception  des  interfaces,  la  traduction  du  modèle  RMDM  vers  le  modèle 
© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 20

dʹimplantation  et finalement, lʹévaluation de lʹapplication hypertexte. La modélisation des bases 
de hypertextes  fait lʹobjet de plusieurs travaux articulés autour des systèmes DEXTER(3), HB(4) 
et TREILLIS(5).  
Schéma de la base de données 
Le schéma de la base de données est la description complète du modèle logique de données au 
moyen  d’un  langage  spécialisé  de  définition,  appelé  le  DDL  (Data  Definition  Language).  Cette 
description change relativement peu en cours d’exploitation de la base. La problématique de la 
répartition  des  données  pourrait  entraîner  des  modifications  de  l’emplacement  des  données, 
mais  pas  nécessairement  des  changements  au  modèle  conceptuel.  Dans  le  contexte  du 
relationnel, le schéma de la base de données est lʹensemble formé avec le schéma de chaque table 
relationnelle. 
Instance de la base de données  
L’instance de la base de données est  lʹensemble de données stockées dans la base au moment t. 
Plusieurs  auteurs  décrivent  les  données  comme  des  objets.  Lʹinstance  de  la  base  de  données 
devient alors un ensemble dʹobjets. Ils supposent que chaque donnée est atomique et qu’elle est 
associée à un ensemble de méthodes ou de procédures communes pour la recherche, la mise à 
jour  et  la  suppression.  Ces  méthodes  sont  en  quelque  sorte  factorisées  au  niveau  de  chaque 
classe et implémentées par des fonctions.  Elles ne sont pas toujours incluses dans le modèle.  
 
  Création du schéma logique

  2 1 4
  Création des Création des schémas
  schémas internes externes
(physiques) Dictionnaire
  3 5

 
8
 
 
  Transformation des clauses d’accès 7 Transformation des clauses d’accès
conceptuels en code d’accès interne externe vers le conceptuel
 
  9
6
 
  Transformation des clauses d’accès
externe vers le conceptuel Application 
 
  10
 
BD
 
Figure 2.1 
Architecture ANSI/SPARC 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 21

On  peut  voir  les  données  dʹun  point  de  vue  différent  selon  que  lʹon  est  DBA  ou  développeur 
d’applications. Une architecture avec plusieurs niveaux favorise une meilleure séparation entre 
les  applications  et  la  structure  physique  des  données  de  la  base.  Lʹarchitecture  ANSI/SPARC 
propose trois niveaux de modélisation des données : 
a)  Niveau  conceptuel :  Description  logique  de  toutes  les  données  selon  la  réalité  perçue  par  le 
concepteur. 
b)  Niveau  externe :  Description  des  données  utilisées  par  une  application  selon  les 
caractéristiques imposées par les traitements de chaque application. Il correspond à la notion de  
vue. 
c)  Niveau  interne :  Description  des  structures  physiques  nécessaires  ou  disponibles  pour  la 
représentation des données sur un ou plusieurs disques. 
 
La  figure  2.1  illustre  le  rôle  de  chaque  processeur  de  schéma  et  illustre  les  différentes  étapes 
dans la transformation des ordres du DML. 
Indépendance logique 
L’indépendance  logique  est  la  possibilité  de  modifier  le  schéma  conceptuel  en  perturbant  le 
moins  possible  le  fonctionnement  des  applications,  c’est‐à‐dire  la  vue  (ou  modèle  externe).  En 
d’autres  mots,  une  modification  au  modèle  conceptuel  n’a  pas  d’impacts  sur  les  éléments  du 
modèle utilisés par une application. En cours d’exploitation, elle favorise la productivité et une 
continuité de l’exploitation.  
Indépendance physique 
L’indépendance  physique  est  la  possibilité  de  modifier  le  schéma  interne  des  données  sans 
modifier le schéma conceptuel. Par exemple, le gestionnaire de la base de données peut déplacer 
les données sur d’autres disques ou définir des structures  de données plus adéquates pour les 
accès à la base de données sans perturber le fonctionnement des applications. 
Langage de données 
Les niveaux du langage de données correspondent à ceux du modèle exploité, à savoir le
conceptuel, l'externe et l'interne. La tendance actuelle est de spécifier ces trois niveaux avec le
même langage de données dont certains ordres sont particuliers à chaque niveau. En principe,
les quatre facettes sont les suivantes :

a) DDL (Data Definition Language ou Langage de Définition de Données): Pour la spécification


du schéma conceptuel ou du modèle d’implantation qui en découle (MCD) et des vues.

b) VDL  (View  Definition  Language):  Pour  définir  les  vues  ou  les  modèles externes  (similaire  au 
DDL du modèle conceptuel avec quelques restrictions en sus). 
 
c) SDL (Storage Definition Language): Pour spécifier les paramètres de stockage physique. 
 
d) DML (Data Manipulation Language ou Langage de Manipulation des Données): Pour mettre à 
jour et supprimer les données de la base en fonction des structures définies au préalable par 
le langage de définition de données.  

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 22

Caractéristiques des langages de données  
Chaque SGBD peut avoir son langage de données qui lui est propre et même cohabiter avec un 
autre  plus  universel.  Les  fonctionnalités  d’un  langage  de  données  sont  caractérisées  par  les 
propriétés suivantes : 

1. Déclaratoire : La requête formule ce qui est recherché dans la base. 
2. Procédural : La requête précise comment rechercher les données dans la base. 
3. Intégré dans un langage hôte : Insertion du DML dans une application L3G. 
4. Langage de requête : Limité souvent à la recherche. 
5.  Convivial :  Les  interfaces  conviviales  du  langage  facilitent  la  construction  des  requêtes  par 
lʹentremise des interfaces graphiques (GUI). 
Manipulations des données 
Les ordres DML pour l’insertion, la modification et la suppression des données sont disponibles 
dans  tous  les  systèmes  avec  une  syntaxe  propre  à  chacun.  Il  en  résulte  souvent  des  formes  de 
différentes de DML d’un SGBD à l’autre. 

Ajout : INSERT INTO ADD TO STORE


Suppression : DELETE FROM DROP, ERASE,
Mise à jour : UPDATE, CHANGE MODIFY

La recherche est formulée par un langage de requête propre au SGBD ou  de type SQL. 
Exemples de requêtes formulées dans divers langages: 
 
Voici  comment  peut  être  formulée  dans  différents  langages,  une  requête  pour  trouver  les 
matricules des employés dont le nom contient les lettres ‘tion’. 
Recherche : 
 
a) Oracle : SQL 
SELECT nom FROM Employe
WHERE nom LIKE '%tion%';

b) INTERBASE : requête en gdml


PRINT nom OF Employe
WITH nom matching '*tion*';

c) Vax/DBMS : requête pour le modèle de données réseau


FIND ANY Employe WHERE nom .CONTAINS. '*tion*'
PRINT Employe.nom
Langage de définition des données (DDL) 
Le  langage  DDL  permet  de  décrire  le  schéma  conceptuel  (et  souvent  le  schéma  externe)  de  la 
base de données. Le schéma est préparé avec un éditeur sous forme d’un fichier de texte qui est 
par la suite traduit par un compilateur propre à chaque SGBD. Ou encore, il est sous la forme de 
commandes interactives, lesquelles sont lʹobjet dʹune interprétation et dʹune exécution en ligne. 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 23

Dictionnaire 
Le dictionnaire des métadonnées (data dictionary) est en quelque sorte le dépôt de toutes les
informations concernant la base de données incluant les procédures stockées et les déclencheurs
(triggers) définis sur la base. Le dictionnaire est dit passif lorsqu'il est en différé relativement
aux opérations sur la base. Il sert davantage pour les phases d’analyse et permet de renforcer
d'uniformiser les libellés et la sémantique des données lors d'une réingénierie des processus. Le
dictionnaire actif est, de par sa fonction, essentiel au fonctionnement du SGBD; il est en ligne
avec le noyau du logiciel. L’ensemble des dictionnaires d’une organisation est désigné
maintenant comme une encyclopédie des données, un concept sous-tendu par le Data
Warehousing.
Évolution des modèles et des langages de définition 
Le dictionnaire de métadonnées est souvent différent d’un système à l’autre. Avec les diverses
générations des SGBD, la séparation entre la définition logique et la spécification physique est
plus marquée et le langage de définition des modèles plus riche dans sa capacité à capturer la
sémantique des données. Cette évolution a marqué sensiblement les caractéristiques des
premiers systèmes SGBD. Dans les exemples suivants, cette évolution au niveau du schéma
graphique est illustrée à l'aide d'un fragment de modèle conceptuel spécifié au moyen du
langage DDL de quelques SGBD, dont certains ne sont plus des logiciels vedettes, bien que
toujours opérationnels.
Schéma source d’une base de données de commandes (SGBD IDMS) 
Voici  un  fragment  du  schéma  source  de  la  figure  2.3  qui  est  une  partie  dʹun  modèle  réseau 
spécifié avec IDMS (version 1980). Les liens sont de type 0‐n et représentés par la notion de set. 
 

Commande
noCommande*
montant
dateCommande
Aera: region-commande
CommandeArticle
LigneArticle
noArticle
qte: (comp)
qteCom;
qteLiv
prix
remarques (mv)

Figure 2.3
record name is LIGNEARTICLE
record id is 621
location mode is via commandeArticle set
within regionCommande area
03 noArticle pic X(8),
03 qte
05 qteCom pic 9(7),

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 24

05 qteLiv pic 9(7),


03 prix pic 9(4).
03 remarques occurs 0 to 10 times
depending on nb-rem.

Après la compilation, le schéma transformé est rangé dans le dictionnaire. Ce schéma exécutable  
contient  certaines  informations,  non  pertinentes  au  niveau  conceptuel,  lesquelles  concernent 
l’identification des enregistrements (records), le placement des données et leur mode d’accès.  

Schéma TOTAL : base de données sur les Ressources humaines 
Ce  schéma  TOTAL  (version1978)  illustré  ci‐dessous  comporte  peu  d’indépendance  logique  et 
physique en raison de son architecture à un seul niveau, intégrant  le conceptuel, le logique et le 
physique.  Ce  schéma  confond  dans  son  langage  les  trois  niveaux  en  incluant  les  informations 
descriptives du niveau physique avec celles du niveau conceptuel. De plus, l’obligation inutile 
de  fournir  la  longueur  des  champs  alourdit  les  modifications  subséquentes  au  schéma  du 
modèle. 
 
Employe
nom *  
adresse  
telephone
 
 
 
Departement
noDep* Fichier-maître
 
site
 
 
Figure 2.4 
.
begin-data-base-generation emplnom = 30
data-base-name= PERSONNEL empladr = 50
share-io empltel = 10
ioarea = mas1 end-data
ioarea = mas2 drive = 12, 48, mt32
... total-logical-records = 200
end-io logical record-length = 104
begin-master-data-set logical-records-per-block = 9
data-set-name = Dep end-master-data-set
... ...
data-set-name = empl end-variable-entry-data-set
ioarea = mas1 end-data-base-generation
master-data
emplroot = 8 --8 octets
emplctrl = 6

Dans ce schéma, il faut noter la présence d’un fichier indexé qui


implémente le fichier-maître Dep (master-data-set). Chaque élément du
modèle est nommé en le préfixant du nom du data-set.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 25

Schéma  ADABAS (version 1983)  de la base de données dʹune société de distribution  
--- Schéma ADABAS (version 1983) ----
clients (001)
01, nc, 5,u,DE -- u indique attribut numérique
01, nm, 15, a,DE -- a un attribut alphabétique
01, pc, 15, a -- DE indique un attribut indexé
01, ac nu -- supprime des blancs dans un champ alpha
02, no,4,u
02, ru,15,a 01, np, 4, u, DE
02, vi, 15,a,de 01, qp, 5, u
02, te, 7, u 01, al
01, es, 3, a, nu 02, ci. 4, u
02, ru, 15,a
commandes (002) produits (003)
01, nc, 7, u, de 01, np, 6,u
...

Clients
Produits 001
003
n n
n
1 m

Entrepots Commandes
04 002

n 1 n

n 1 1

ComEntrepot Vendeurs
006 006

Figure 2.5

Cette partie de schéma  ADABAS des années 80 est un exemple de langage de description peu 
significatif  pour  les  développeurs  d’applications.  Néanmoins,  ce  logiciel  permet  de  gérer  une 
base  de  données  avec  des  structures  directement  adaptées  aux  liens  complexes  de  plusieurs  à 
plusieurs  (n‐m)  et  réciproques,  sans  la  création  de  classes  logiques  supplémentaires.  Ce  lien 
complexe  est  créé  au  besoin  par  une  table  de  couplage  (Table  Coupling)  implémentée  par  une 
structure  de  données  inversée.  Cette  caractéristique  en  faisait  un  logiciel  fort  intéressant  parce 
qu’il est capable de gérer un modèle physique similaire au modèle conceptuel.   
Modèle de Vax/DBMS 
Le  schéma  d’une  base  de  données  réseau  gérée  par  ce  système  se  rapproche  de  celui 
recommandé par CODASYL. Les informations ayant trait au niveau conceptuel sont séparées du 
niveau physique voire même de celles régissant les accès aux données (6). Ce système gère les 
modèles conceptuel, externe, interne et de sécurité. 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 26

Schéma DDL/ Vax DBMS


*Scénario 2 - Base de données académique
schéma name is BD_SC2
*Description de l'entité FACULTE
record name is FACULTE within FACDEPT
item CODEFAC type signed longword
item NOMFAC type character 30
*Description de l'entité DEPARTEMENT
record name is DEPARTEMENT within FAC_DEPT
item CODE_DEPT type signed longword
item NOM_DEPT type character 30
* Description de l'entité PROFESSEUR
record name is PROFESSEUR within DEPT
item NASPROF type signed longword
item NOMPROF type character 20
item ADRESSEPROF type character 15 occurs 3 times
item TITRE type character 20
... * Description du groupement INSCRIT
set name is INSCRIT
owner is DEPARTEMENT
member is ETUDIANT
set selection is current of set
insertion is manual
retention is optional order is sorted by
ascending MATRICULE duplicates are not allowed
. . .

Faculte
codeFac
nomFac

Compose_de

Departement
codeDep
nomDep

Emploie Inscrit Dispense

Professeur Etudiant Cours


nasProf matricule titreCours
nomProf nomEtud nbCredit
adresseProf prenomEtud
titre adresseEtud
adressPerm
dateNaisEtud
dateInscr
Modèle conceptuel réseau DBMS  Figure 2.6 
 
 
Le  langage  de  schéma  de  ce  SGBD  est  plus  riche  en  types  de  données  que  les  précédents 
permettant  ainsi  de  représenter  quelques  types  complexes  comme  les  groupes  et  les  vecteurs.  

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 27

En outre, la description demeure au niveau logique des données et ne fait aucune référence aux 
aspects physiques. Ces derniers font l’objet d’un schéma interne complètement séparé. 
Environnement de traitement centralisé 
Ce système est encore utilisé dans les grandes organisations. Il est installé sur une seule machine 
dite centrale cohabitant avec plusieurs autres logiciels étrangers à la base de données. De plus, 
cet  ordinateur  gère  souvent  un  grand  nombre  de  terminaux  au  moyen  dʹun  logiciel  de 
communication  de  type  moniteur  de  transactions  (TP  pour  Transaction  Processing  monitor).  Ce 
dernier permet de fournir et de recevoir des données en transit vers une application particulière 
qui tourne sur la machine centrale. Dans le cas le plus simple, le SGBD ne répond quʹà une seule 
requête  à  la  fois    (single  thread).  Les  requêtes  simultanées  qui  proviennent  de  différentes 
applications sont mises alors en file dʹattente par le moniteur de transactions. Dans le cas d’une 
configuration  dite  d’entrelacement  d’exécution  (multithreading),  plusieurs  requêtes  en 
provenance  d’autant  d’applications  (terminaux)  peuvent  être  traitées  en  concurrence.  Un  tel 
service exige un OS multitâche et une gestion fine du partage des données.  
Multithreading avec un processeur de transactions sur machine centrale 
Chaque  écran  transmet  les  données  nécessaires  pour  effectuer  une  transaction  (en  mode 
autonome)  au  processeur  de  transactions  (PT)  qui  les  gère  en  tenant  compte  des  priorités 
respectives.  Le  module  de  traitement  des  transactions  crée  un  processus  pour  chaque  requête. 
Ce nouveau processus concurrence les autres processus actifs pour les accès à la BD. Le système 
de  répartition  de  l’OS  se  charge  de  gérer  les  différentes  tâches  associées  à  l’application  pour 
réaliser ainsi l’entrelacement des traitements. Lorsquʹune tâche fait, par exemple, une lecture sur 
un disque pour une application, une autre tâche peut alors prendre le contrôle du processeur et 
poursuivre son  exécution. Pour une meilleure performance, le processus du moniteur TP de la 
figure  2.7a  une  très  grande  priorité  pour  le  système  d’exploitation  (OS)  de  manière  à  obtenir 
rapidement le contrôle du CPU.  Deux cas sont possibles : 

Cas 1 : exécution séquentielle (single-thread)


Un seul DML d’une application est exécuté à la fois (pas de concurrence entre les applications).
C'est une approche non performante, maintenant caduque.
file des requêtes

Moniteur Ecran 8
Ecran 1 TP

Application-1
Une seule transaction traitée à BD
la fois et entièrement par SGBD
l’application.

Figure 2.7
 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 28

Le processeur transactionnel de transactions (TP) couplé au moteur SGBD améliore quelque peu 
le traitement en partageant le même moteur SGBD avec les terminaux actifs.  
Cas  2  :  interclassement  des  transactions  en  provenance  de  plusieurs  terminaux  pour  le 
traitement de données (multithreading). Ces transactions sont exécutées en concurrence et gérées 
par  le  répartiteur  du  système  dʹexploitation  (OS)  tel  qu’illustré  à  la  figure  2.8.  Chaque 
transaction  est  exécutée  par  un  processus  dupliqué  pour  exécuter  le  code  correspondant  à 
l’application. Il y a aura donc autant de processus concurrents que d’écrans actifs. 

Cette  récupération  des  cycles  du  CPU  par  les  processus  chargés  de  traiter  un  ordre  DML  sera 
aussi  nécessaire  dans  une  architecture  client/serveur  en  mode  connecté  où  le  nombre  de 
processus  est  susceptible  d’être    encore  plus  important.  De  plus,  chaque  application  sʹexécute 
sur  la  station‐client  et,  seul  lʹordre  DML  est  transmis  au  serveur.  Il  est  donc  capital  d’avoir  un 
système  d’exploitation  multitâche  performant  pour  la  gestion  du  serveur  de  bases  de  données 
avec une machine capable de répondre à la charge créée par les clients.  
Transaction :
ecran-1 no-transaction id-application valeur-1 valeur-2 valeur-3
 
Les  système  OS/2,  Unix,  Windows  NT  et  XP  Pro  sont  les  plus  utilisés  sur  les  plates‐formes 
micro,  tandis  que  les  systèmes  propriétaires  IBM‐MVS,  IBM‐AIX,  Sun‐Solaris  et  Sun‐OS 
dominent le matériel de niveau station de travail ou celui des ordinateurs centraux.  
 
 
station 1 Moniteur
de TP station 4

Table des
proc‐3
applications
proc-2
proc-1 proc-1
proc‐3 
proc‐2

BD

SGBD

Entrelacement d'exécution (Multithreading)


Figure 2.8
Les  environnements  client‐serveur  et  les  architectures  fédérées  ne  changent  pas 
fondamentalement le fonctionnement général du moteur SGBD, mais le situent dans un contexte 
opérationnel plus diversifié qui permet notamment une meilleure performance et des ressources 
matérielles plus adaptées à lʹenvironnement de traitement (scalability). Il faudra une architecture 
parallèle  pour  escompter  encore  des  gains  importants  de  performance.  L’approche  client‐

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 29

serveur  est  bien  adaptée  à  l’exploitation  par  réseau.  Dans  un  tel  cadre,  les  applications  sont 
développées  au  niveau  de  chaque  station  en  utilisant  les  ressources  logicielles  disponibles 
localement.  L’accès  à  la  base  de  données  se  fait  par  lʹentremise  dʹun  ou  de  plusieurs  réseaux 
hétérogènes qui véhiculent chaque requête au serveur lequel agit comme une ressource centrale. 
Plusieurs  auteurs  préconisent  l’approche  fédérée  dans  l’exploitation  des  données.  Cette 
approche  met  aussi  en  oeuvre  l’architecture  client‐serveur  mais  en  y  ajoutant  la  possibilité  de 
répartir  la  base  de  données  sur  plusieurs  serveurs  hétérogènes.  Bien  sûr,  une  telle  base  de 
données  doit  être  gérée  de  façon  à  maintenir  la  cohérence,  l’intégrité  et  la  transparence  des 
données peu importe la provenance de la requête.  
Modèle fonctionnel du logiciel 
Nous  reprendrons  le  modèle  fonctionnel  présenté  schématiquement  au  chapitre  1.  On  peut 
décrire  un  logiciel  SGBD  sous  un  angle  fonctionnel,  car  les  aspects  d’implémentation  varient 
largement selon la plate‐forme, voire même selon les différentes versions du même logiciel. En 
outre,  le  développement  de  nouveaux  systèmes  d’exploitation  offrira  sans  doute  des  moyens 
d’implantation encore plus puissants. Cette description schématique comprendra : 
a) Les fonctions présentes dans un SGBD;  
b)  La  coopération  entre  les  fonctions  internes  du  système  pour  la  gestion  efficace  et  cohérente 
des données. 
2. 2 Architecture générale dʹun SGBD 
Voici l’architecture fonctionnelle vue auparavant : 
 
 
Analyse syntaxique
 
Analyseur Analyse sémantique
 
 
Traduction  Génération du plan d'exécution
Métabase   Contrôle d'intégrité
Contrôle des autorisations
 
 
Optimisation Modification du plan d'exécution
  selon les coûts et les règles
 
Sous-système  
d'affichage
Calcul  Contrôle de la concurrence
  Atomicité de la transaction
  Exécution des opérateurs
 
Base de  
données
 
Accesseur
 
 
Figure 2.9 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 30

Le  SGBD  est  composé  de  plusieurs  modules  agissant  en  coopération  dans  l’enchaînement  des 
opérations  pour  calculer  la    réponse.  Il  comprend  deux  composants  majeurs  :  lʹExécuteur  et 
lʹAccesseur. 
 
Voici le rôle général de chaque module d’un SGBD : 
Analyseur  :  Le  traitement  de  la  requête  débute  par  une  analyse  syntaxique  pour  en  établir  la 
conformité  avec  la  grammaire.  Puis,  une  analyse  sémantique  vérifie  que  seuls  les  objets  typés 
connus par la vue sont utilisés. 
Traducteur  :  Lorsque  la  requête  utilise  une  vue  (sous‐schéma),  le  passage  des  références  aux 
objets de la vue à ceux du schéma est effectué par le module de traduction. De plus, ce module 
vérifie si la requête a les droits d’accès aux données pour les opérations quʹelle compte effectuer. 
La  dernière  phase  de  la  traduction  consiste  à  générer  un  arbre  de  requête  formé  avec  les 
opérateurs  de  l’algèbre  relationnelle.  Finalement,  lorsqu’il  s’agit  d’une  modification  ou  d’un 
ajout de données, le module vérifie si les contraintes d’intégrité sont respectées par les actions à 
faire sur la base de données.  
Optimiseur : Le rôle de ce module est de transformer la requête initiale en une autre équivalente 
dont le plan d’exécution  est de nature à fournir un calcul plus rapide. Ce plan est une véritable 
feuille  de  route  pour  la  réalisation  du  calcul  :  lecture  de  l’index  Y,  accès  aux  enregistrements 
dʹun fichier par une méthode d’accès. Ensuite, l’optimiseur établit le coût du calcul de la réponse 
selon un modèle de performance (relatif au temps en fonction du volume de données), qui sert 
de base dans le développement du plan d’accès optimisé. 
Calcul : Le plan optimisé est exécuté par le module du Calcul du SGBD qui effectue le calcul de 
la  réponse  pour  lʹopérateur  en  utilisant  au  besoin  les  index  et  les  tables  de  la  base.  Il  est  aussi 
chargé de la gestion de la concurrence et assure l’atomicité et le recouvrement des transactions. 
Ce  module  est  notamment  composé  dʹune  fonction  de  gestion  transactionnelle  et  dʹune  autre 
chargée de la répartition des actions de lecture et dʹécriture. L’exécuteur dédié ou partagé est un 
processus  qui  exploite  aussi  les  primitives  disponibles  dans  le  contexte  d’un  système 
d’exploitation particulier. 
Accesseur  :  C’est  le  module  chargé  de  trouver  et  de  placer  en  zone  de  mémoire  partagée  les 
pages  demandées  par  l’exécuteur.  Il  est  aussi  chargé  de  les  écrire  sur  disque.  Il  gère  aussi  les 
listes de pages de données (LRU) placées dans la zone commune, la ZMP. Ce module exécute les 
procédures Input(no‐page) et Output(no‐page). Lʹadresse dʹune page est formée essentiellement 
dʹun  numéro  de  page  et  de  lʹindice  dʹune  entrée  dans  le  répertoire  de  la  page.  Ce  couple  est 
appelé un rid ou un rowid. 

Dans les pages suivantes, nous ferons un rappel des notions de base implémentées dans les
SGBD complexes.
Rôle des processus dans les architectures SGBD 
Définition du processus 
Un processus est une unité (segment de code) d’exécution gérée par le système dʹexploitation; il 
est  doté  dʹun  espace  mémoire  propre  (RAM),  de  son  code  (segment  de  texte),  d’un  espace  de 
données  (segment  de  données),  d’une  pile  d’exécution  (segment  de  pile,  le  contexte)  et  d’un 
compteur  ordinal.  Il  a  aussi  sa  propre  table  de  descripteurs,  sa  table  des  signaux  et  ses  trois 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 31

ʺtimersʺ maintenus en son nom par lʹOS. C’est donc un programme en exécution géré par l’OS au 
moyen  de  la  table  de  processus  Unix  proc[].  Toutefois,  plusieurs  processus  différents  peuvent 
exécuter  le  même  programme.  Le  noyau  dʹun  SGBD    met  en  oeuvre  plusieurs  processus 
coopérants pour stocker et retrouver les données. 
États dʹun processus 
Un  processus  géré  par  le  système  d’exploitation  peut  avoir  plusieurs  états  mutuellement 
exclusifs : 
a)  Prêt  à  l’exécution  (ready) :  il  a  toutes  les  ressources  nécessaires  sauf  celle  du  processeur;  il 
attend le feu vert du répartiteur de lʹOS pour être lancé. 
b) En attente bloquée (blocked) : attend la fin d’une autre activité pour poursuivre la sienne; il a 
déjà démarré son exécution, mais il est suspendu en attente de la libération dʹune ressource qu’il 
a perdue momentanément. 
c) En exécution (running) : le processus est actif et effectue sa tâche. 
Répartition (scheduling) des tâches 
Le  répartiteur  (scheduler)  du  système  dʹexploitation  choisit  le  processus  à  exécuter  parmi  ceux 
qui  sont    prêts.  Cette  répartition  tient  compte  du  niveau  de  priorité  spécifié  pour  chacun  des 
processus. Dans le contexte dʹun SGBD, les processus qui font lʹobjet dʹune répartition par lʹOS 
seront ceux du noyau du SGBD. Le rôle d’un système d’exploitation n’est donc pas neutre dans 
le fonctionnement du SGBD. 
Alternance de processus (swapping) 
Un  processus  en  attente  ou  prêt  peut  être  évacué  au  besoin  (swapped)  par  l’OS  pour  faciliter 
l’exécution d’un autre qui exige de la mémoire RAM supplémentaire. Cette vidange (swapping) 
est réalisée par l’OS et ces pages sont rangées temporairement dans un fichier spécialisé à cette 
fin  sur  un  disque.  Cette  opération  suppose  l’exécution  d’un  appel  au superviseur  accompagné 
d’une sauvegarde du contexte du processus courant.  
Conséquence négative de l’alternance 
La présence de nombreux processus en mémoire accroît l’activité I/O qui affecte directement la 
performance  du  SGBD.  L’alternance  se  manifeste  par  des  temps  de  réponse  variables.  La 
première stratégie consistait à évacuer toutes les pages d’un processus afin de libérer la mémoire 
pour un processus en phase de démarrage. Dans le système SYSTEM V (Unix) une évacuation 
graduée, à la page (demand paging), a éliminé l’échange inutile de pages (swapping). 
Processus sous‐jacents au fonctionnement SGBD 
Le fonctionnement du SGBD suppose la mise en oeuvre de plusieurs modules coopérant entre 
eux : 
1. Un Exécuteur, éventuellement plusieurs, est créé pour le service aux requêtes. Leur nombre 
dépendra de celui des clients actifs. La décision de lancer plusieurs Exécuteurs est prise par 
le DBA en faisant au démarrage un choix de paramètres appropriés. 
 
2. Plusieurs  autres  processus  pour  implanter  le  noyau  du  SGBD.  Leur  taille  est  souvent 
supérieure à 1 Mo. Ils sont la propriété du compte spécial SYSTEM. Leur rôle consiste à gérer 
la mémoire, le journal des requêtes (transactions), le calcul de la réponse et le lancement de 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 32

reprise. Ces processus occupent un espace important dans la RAM. En règle générale, pour 
maintenir  une  bonne  performance  en  cours  d’exploitation  d’une  base,  il  faut  maintenir  au 
plus bas lʹactivité de la pagination et cela, en agrandissant au besoin la ZMP et faire appel à 
des disques RAID.     
Appel au Superviseur (SVC‐SuperVisor Call)   
La gestion des différents processus a un effet négatif sur la performance du noyau d’un SGBD.  
Parmi  les  facteurs  de  ralentissement,  il  y  a  le  nombre  d’appels  au  superviseur  (SVC)  pour 
obtenir des services du système d’exploitation comme les opérations de I/O sur disque, certaines 
communications  entre  processus  (IPC)  et  leur  synchronisation.  De  plus,  la  commutation  du 
contexte  système  demandé  à  chaque  SVC  constitue  une  charge  pour  le  processeur  notamment 
au début et à la fin de chaque SVC, puisque la sauvegarde des registres, des piles et des caches 
exige  une  activité  I/O  relativement  importante.  La  fréquence  de  la  sauvegarde  du  contexte  est 
variable selon la machine. Elle peut varier de 1500 bascules/sec pour un micro‐ordinateur à plus 
de 100 000 bascules/sec pour les ordinateurs de grande puissance. 
Multiplication des processus 
Un processus peut en créer d’autres par une fonction système [comme la fonction C fork()] pour 
diviser,  au  profit  des  utilisateurs,  le  travail  global  à  effectuer  par  le  processus  parent.  Cette 
multiplication des processus n’est pas neutre et accroît la charge de travail de lʹOS : 
a) Augmentation du nombre de commutations de contexte. 
b) Accroissement de la charge pour le répartiteur qui doit gérer plus de processus. 
 
Un processus ainsi créé est dit processus enfant et hérite du descripteur du processus parent lui 
permettant dʹavoir accès aux mêmes fichiers et aux mêmes sockets qui appartiennent au premier 
(le  parent).  Pour  un  SGBD,  lʹutilisation  de  ce  mécanisme  exige  quʹun  premier  processus  soit 
lancé par le compte DBA et quʹensuite, les autres soient créés par la primitive fork(). Cʹest ainsi 
que  le  nombre  de  processus  Exécuteurs  pourrait  être  augmenté  lorsque  le  nombre  de  clients 
atteint une certaine limite.  
Thread ( comportant un compteur ordinal + pile +  code) 
Un processus peut avoir plusieurs threads pour exécuter en parallèle divers traitements. Le thread
se distingue du processus par le fait qu'il a le même espace d'adressage que celui du processus
qui l'a lancé. Il a donc accès aux mêmes données en mémoire et aux mêmes ressources de
fichiers et de sockets que ceux du parent. Cependant, il a une pile propre, son propre code et son
compteur ordinal. Si un même ordre DML est exécuté par plusieurs threads, la performance sera
d'autant plus grande si chacun est exécuté par un processeur distinct tout en utilisant une
partition différente des données. À terme, la réunion des résultats de chaque thread fournira la
réponse à la requête DML. Ce parallélisme dans le calcul de la réponse à une requête permet
d’avoir des performances sensiblement meilleures avec les bases de grande taille.
Mécanismes de communication interprocessus 
La communication avec et entre les processus du noyau (IPC) pour échanger un ordre DML (ex.
SQL) ou d'autres données de contrôle ou pour retourner les données de la réponse calculée sous-
tend l'exécution de fonctions de système par l'OS afin d'implanter les diverses fonctionnalités à
savoir le stockage, le recouvrement et la cohérence de la base de données au niveau du serveur.
Deux cas de figure sont importants :

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 33

a) Communication interprocessus sur une seule machine au moyen des mécanismes suivants :
tube, queue et mémoire partagée (ZMP).
b) Communication interprocessus sur plusieurs machines par sockets et RPC (pour les bases de
données réparties et l'architecture client/serveur).

En gros, un SGBD est un ensemble de programmes, donc autant de processus appartenant au


même groupe de processus (groupid). Ces processus coopèrent entre eux, se mettent en attente et
se réveillent périodiquement pour effectuer des actions de lectures ou de mises à jour sur la base
de données, notamment par l'accession à une page de données, la vidange des données de la
RAM ou la réalisation d'un point de reprise (checkpoint).

Mécanismes IPC sur une seule machine


Le tube (pipe) avec le modèle lecteur/écrivain est un mécanisme implémenté directement
comme une primitive du système Unix.

tube 1 
Processus 1 Processus 2

tube 2

OS
Buffer géré par le noyau
OS table 
table descripteur 
descripteur
Le buffer est créé dans l'espace géré par 0 stdin
0 stdin l'OS 1 stdout
1 stdout

Figure 2.10
C’est un mécanisme simple unidirectionnel qui s'apparente aux fichiers et qui est applicable
entre processus appartenant au même groupe de processus et ayant le même parent (process
group), car c'est par l'héritage d'une table de descripteurs d'un ancêtre commun que les deux
processus vont pouvoir communiquer. La fonction pipe(fd) génère deux descripteurs de fichier
et alloue un buffer interne, lequel est géré par le noyau du système OS . Par exemple, pour
communiquer à un processus 1024 caractères rangés dans un tableau nommé tabA, le
processus2 utilisera la fonction write(fd,tabA,1024). 

Les étapes sont les suivantes :


a) création du tube : int pipe(p)
Cette fonction de système est exécutée avant le fork(). L'argument p est un tableau p[2] de type
entier. Un premier descripteur doit remplacer celui en position 0 (stdin) et le deuxième celui en
position 1 (stdout) de la table des descripteurs de l'autre processus qui est identique à celle du
premier. Le tampon interne est généralement limité à une taille de 4 Ko.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 34

b) les fonctions read et write sont utilisées pour lire et écrire sur un tube comme dans un fichier.
Ces fonctions font un appel SVC (appel au système), donc amorcent une commutation de
contexte avec un effet négatif sur la performance. L'écrire de 1024 caractères rangés dans le
tableau tabA au moyen du stdout dont le descripteur est 1, est fait par la fonction suivante :

write ( 1, tabA, 1024); -- écrire 1024 car. dans le tube 1

La lecture de 1024 caractères dans le stdin dont le descripteur est 0, est faite par la fonction
suivante :
read(0, buf , 1024); ‐‐ lecture du buffer interne 

Le tube a l'inconvénient d'implémenter un échange sur une même machine et d'avoir un tampon
limité à 4096 octets. Si deux processus doivent échanger des données simultanément dans les
deux sens, ils doivent avoir un parent commun afin de pouvoir établir deux tubes entre les
processus en question. Finalement, le tube est bloquant dans ce sens que si la lecture est moins
rapide que l'écriture, le processus écrivain sera suspendu.
Mémoire partagée (ZMP) 
Ce mécanisme permet à deux processus d'échanger des données en partageant l'accès à une
même zone de mémoire RAM par la même adresse du début de la dite zone.

Processus 1 Processus 2

Espace géré par l'OS Pages de données

Zone non structurée explicitement

Figure 2.11
En créant cette zone de mémoire commune, l’OS assigne une clé d’accès à cette zone figée qui
reste généralement en mémoire principale et qui est accessible sans appel au superviseur (SVC).
Cette clé d'accès est rendue accessible aux applications par une fonction système shmat(cle,0,0).
Cette zone ZMP est logiquement constituée d'un seul espace, mais selon les OS, elle peut être
constituée de plusieurs segments partagés de mémoire RAM, alloués par le système. La zone de
mémoire partagée est créée par l'OS qui fournit aussi une clé d'accès à cette même zone.

La mise en oeuvre d'une ZMP peut se faire de la façon suivante :


a) Création d'une ZMP de 4Ko avec la fonction:
cleZ = shmget(cleU, 4096);

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 35

La clé reçue, cleZ est la donnée essentielle pour le rattachement à la ZMP. Elle est calculée à
partir de la cléU (un très grand entier) fournie par le processus ou l'utilisateur au moment de la
création de cette zone.

b) Un processus serveur, SP, s'attache la ZMP par la fonction: char *shmat(cleZ).


Le processus obtient la clé dans la liste de paramètres transmise par un module temporaire
chargé du lancement du processus pour ensuite disparaître. L'adresse d'attachement est fournie
comme valeur de retour de la fonction.

c) Le processus peut alors accéder à la ZMP comme si c'était une mémoire locale, c'est-à-dire
comme étant une partie de son espace adressable. Dans le contexte d'un moteur SGBD, c'est un
module spécialisé (Accesseur) qui sera chargé d'accéder aux pages de cette zone.

d) Chaque processus doit contrôler l'accès à la ZMP et plus particulièrement aux pages par des
sémaphores mis en oeuvre par la fonction système shmctl() ou par la définition d'un sémaphore
pour chaque page de la ZMP. Il est aussi possible de déléguer à un autre processus la mission
de contrôler les accès aux données des pages en gérant une liste de verrous attribués à chaque
transaction.

Avantage de la zone de mémoire partagée (ZMP)


Par cette technique efficace, un processus accède à la ZMP dont il se doit de connaître la
structure et cela, afin de pouvoir accéder aux données rangées dans cette zone. L’échange de
données est possible sans faire de nombreux appels répétitifs au système (SVC). Lorsqu’un
processus réalise son attachement par un premier SVC, il peut par la suite y accéder directement
sans autre SVC et sans changement de contexte, puisqu’il utilise la même clé d’accès obtenue
lors du premier SVC. Ayant accès à la ZMP, un processus peut accéder aux différentes
structures internes au moyen d'une structure de répertoire créée au préalable par le processus
qui a créé la ZMP.

La ZMP est généralement paginée au cours de sa création de sorte que le processus qui accède
aux pages en connaît la structure de page et peut accéder à son contenu par l'entremise d'un
répertoire créé pour chaque page. S’il devait y avoir une ZMP pour chaque processus
Exécuteur/Accesseur, la ZMP bloquerait une bonne partie de la RAM, avec l'apparition de
problèmes concernant la synchronisation des accès. Finalement, bien que cette zone puisse être
l’objet d’un échange (swap), il est préférable de la fixer (pin down) pour obtenir une meilleure
performance. Une activité de pagination croissante est un indicateur pour le DBA que la
mémoire RAM est insuffisante et que le SGBD peut manifester des symptômes de sous-
performance.

Queue de messages
Cette technique permet l'échange de messages entre deux processus en les plaçant dans une
queue.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 36

écrire msg( SVC)

OS Processus 3
Processus -7 (pid = 3)
(pid = 7)
queue 4

Échange d'un message entre deux processus de la même machine


Figure 2.12
Chaque message est ensuite repris par un des processus (modèle de la boîte postale). Les
primitives SEND() et RECEIVE() utilisent les appels SVC de l'OS (System Supervisor Call) pour
lire ou déposer des messages. Il y a donc à chaque écriture, une commutation de contexte. La
queue est gérée par le noyau de l’OS (Unix SYSTEM V).

Une fois paramétrée correctement, la queue peut accepter un tas de messages de longueur
variable. Le processus qui transmet et celui qui reçoit n'ont pas nécessairement un parent
commun. La figure 2.12 illustre la communication interprocessus utilisant la queue de messages.
Le processus 3 place une requête SQL dans une queue particulière, par exemple la 4. Elle sera
reprise par le processus 7 pour être exécutée et fournir les tuples de la BD. À chaque
communication, il y a un appel SVC et un changement de contexte afin d’assurer la reprise et la
poursuite correcte du programme courant. Cette méthode permet d'échanger des données après
que le processus émetteur soit inactif ou disparu. L'utilisation d'une queue de messages fait
appel aux fonctions suivantes :
a) Création d'une queue et son ouverture par la fonction : wid = msget().
b) Envoi ou réception d'un message : retour = msgsnd(0) et retour = msgrcv().
c) Contrôle et suppression de la queue par la fonction système msgctl().
Caractéristiques de la queue de messages 
L’usage d’un appel système SVC pour lire/écrire un message dans une queue génère un
changement de contexte donc une charge I/O pour l’échange (swapping). La queue de messages
demeure en RAM tant qu'elle n'est pas détruite par le processus qui l'a créée. En cas
d'annulation de ce processus, la mémoire doit être libérée par un processus de service de l'OS.
La taille d’un message doit être raisonnable, car elle est limitée par l’espace alloué à la queue.
Prise (socket) 
Cette technique a été implémentée en premier dans Unix BSD 4.x pour être ensuite
graduellement adoptée par plusieurs systèmes d'exploitation.

Espace OS
sd = 4 sd = 9

Application Socket client Socket


serveur
réseau
(no-machine, no-port) (no-machine, no-port)
Couche TCP du logiciel de communication

Figure 2.12a

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 37

La particularité de cet IPC est la possibilité d’avoir une communication entre processus d’une
même machine (famille AF_UNIX) ou de différentes machines distantes (famille de protocole
PF_UNIX) pour l'IPC au moyen d'une communication basée sur la technologie TCP/IP.
Association des deux extrémités identifiées par le couple (machine, port) mise en œuvre par le
système d'exploitation ou par un logiciel de communication. Une prise (socket) est créée par un
processus client au moyen de la fonction socket(): un numéro de prise (sd) et deux tampons
internes à l'OS sont créés pour la lecture et l'écriture des messages. Le processus émetteur écrit
dans une prise par une primitive write() comme il le fait pour un fichier. D'un autre point de vue
du logiciel, la prise ou la socket est en quelque sorte une interface de programmation avec les
fonctions de la librairie système de TCP/IP. Le descripteur d'une prise est inscrit dans la table
des descripteurs du processus de l'application qui l'a créée. Du côté serveur, une prise est aussi
créée et l'association technologique entre ces deux prises est établie en utilisant l'adresse Internet
des machines et le numéro de port.

La prise ou socket peut donc être vue comme un ensemble de primitives - socket(), listen(),
bind(), ... d'interface avec l'OS pour implémenter l’échange les données entre deux machines
distantes en masquant la couche transport qui sera implémentée par le noyau de l'OS via une
technologie de communication appropriée. La communication distante entre deux processus est
présumée implémentée par une technologie matérielle et se manifeste au niveau des clients et
du serveur par une communication entre deux extrémités logiques appelées extrémités de
connexion où chaque processus a accès à une socket. Le mécanisme de communication
schématisé ci-dessous fait appel à des tampons-systèmes (buffer) créés de chaque côté par les
primitives socket().
Port 
Un port est identifié par un numéro et associé à une queue de messages gérée par l'OS. Par
exemple, une queue de messages associée au port 5 selon lue par un processus en référant au
port numéro 5. Les fonctions disponibles pour l’implémentation d’une prise par un appel au
système d'exploitation sont les suivantes (7).

RAM-OS RAM-OS
out socket 6

out port 80
In

In
TCP-IP socket 9

read()
socket 7
write()
Client  accept()
read() Serveur 
write()

Figure 2.12b

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 38

a) Création d’une prise côté client :  
Le système OS construit une prise dans la table des descripteurs de l'application et retourne le
numéro de la prise (fd_sock_c), i.e. du descripteur au client. Deux  tampons  systèmes  y  sont 
associés, un premier pour la sortie et lʹautre pour lʹentrée. 
fd_sock_c = socket (domaine, type_de_socket, protocole);
Exemple :  
fd_sock_c = socket (AF_UNIX, TCP, AF_INET);
où fd_sock_c  est le descripteur (un entier) de la socket dans la table du processus client et qui 
est aussi gérée par lʹOS du client. Du côté serveur, la fonction exécutée pourrait être la suivante : 
fd_sock_s = socket(domaine, type_de_socket, protocole);

Dans le cas du serveur c'est une prise dite passive, car il ignore encore l'adresse IP du prochain
client. Le processus serveur est à l'affût de tout message écrit dans une prise associée à un port
particulier que le serveur va surveiller attentivement.

b) Association de l’adresse du descripteur d’une prise, i.e. de point de communication cible (IP,
port).
• ‐ Pour le processus client 
• Lʹadresse IP et le port de la machine cible (soit  celle du serveur ciblé)  doivent être connus, 
car ils  sont fournis comme arguments dans lʹappel du connect() lancé par le client: 
•  
res_c = connect(fd_sock_c,&sock_c,&sock_s,sizeof(sock_s))

où sock_s fournit le IP et le port du serveur et sock_c fournit le IP et le port local. La fonction


peut aussi utiliser la struct prédéfinie sockaddr_in qui contient ces mêmes données. A ce
moment, le client a fait connaître à son module local de TCP, le IP et le no du port qu'il entend
utiliser pour transmettre et recevoir des informations à distance à partir du client au moyen
d'appels read() et write().

• ‐ Pour le processus serveur   
Le serveur a créé une socket dès son lancement; il a utilisé la fonction socket(). Le point de
communication (IP et no de port) est inscrit subséquemment par la fonction bind() lancée par
le serveur
Res = bind(fd_sock_s, &adres_sock_s, sizeof(&sock_s))
A ce moment, le serveur a 2 tampons-systèmes: un pour recevoir (IN) et un autre pour
transmettre (OUT).

c) Envoi d’un message par le client au moyen de sa socket locale et en utilisant son descripteur
de socket, c'est-à-dire l'indice de son entrée dans la table du processus :
sf = fdopen(fd_sock_c, "w"); --ouverture de la socket client
write(sf, tamponout, 1024);

Si le client ferme la socket, il ne pourra pas recevoir de réponse du serveur, mais son message de
sortie sera quand même transmis au point de communication cible, soit le serveur.
d) Réception d’un message par un serveur: Listen () et Accept ()

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 39

La fonction Listen() place la prise du serveur dans son état passif et informe l'OS du serveur
de mettre en file les x prochains messages reçus par la socket :

res = Listen(fd_sock_s,5); - 5 messages en queue

La fonction Accept() extrait le prochain message de la socket (via son tampon IN) de la
manière suivante : création d'une nouvelle socket (fd_sock_ns) où l'OS placera le message
trouvé dans le tampon IN. En ce faisant, le serveur garde en disponibilité la socket initiale pour
recevoir sans délai un autre message éventuellement d'un client différent. Il pourrait aussi faire
un fork()pour traiter le message reçu.

rf = accept(fd_sock_s, NULL, NULL);

processus client  processus serveur
sfd = socket() sfd = socket() Création de la socket serveur

res = bind() Association de l'adresse IP du


serveur à la socket

connect() La socket devient passive et


res = listen() à l'écoute

Socket devient active


Lecture du message d'une socket
res = accept() particulière et création d'une
nouvelle pour le serveur

Acquisition des données de la


write() read()
nouvelle socket

read() write()
Transmission des données par le
serveur

close() close()
Figure 2.12c

Le serveur logiciel boucle à l'infini :


do {
if ((sd = accept()) == -1) exit(0); -- boucle
do
{ ch = getc(sd);
. . .
close (fd_sock_ns);-- socket créée par le serveur pour avoir accès
-- au contenu de la socket d'origine
}; . . .
} while (TRUE);

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 40

e) Fermeture d’une prise avec suppression et libération des tampons-


systèmes :
result = close(fd_sock_ns)

La socket fd_sock_ns est fermée. Le serveur continue toujours à recevoir des messages par
l'entremise de la socket d'origine (fd_socket_s) qui est toujours active. Ce mécanisme IPC est
mis en oeuvre dans certaines composantes d’un SGBD, notamment dans le module de gestion
du réseau qui est présent sur chaque station client (module d'écoute). La prise créée par le client
utilise l'adresse IP du serveur distant pour établir la connexion. Le serveur connaîtra la
provenance de la communication parce que la trame TCP comprend l'adresse IP du client ainsi
que le numéro de port du client.

Table des descripteurs


( 1 par processus)
Structure de données d'une socket

IN
famille : PF_INET
OUT service: SOCK_STREAM
local IP
remote IP

socket local port


remote port

Structure de socket gérée par l'OS-Unix


Figure 2.12d
Un module d'écoute au niveau du serveur permet de détecter une connexion TCP spécifiée par
une adresse et un numéro de port prédéterminée. Comme nous l’avons décrit, à l'arrivée d’un
message, le serveur en attente accepte immédiatement le message et effectue la création d'une
nouvelle socket pour y copier le message reçu et cela, pour permettre au serveur de continuer à
recevoir des messages (concurrence) sur la socket d'origine. Ce mécanisme fait appel à des
fonctions de système pour établir la connexion, mais l'échange peut se faire directement par
l'intermédiaire des fonctions TCP de la bibliothèque du logiciel de communication. Cette
opération n'est pas très lourde en termes de commutations de contexte pour le serveur et le
client.

La connexion nécessaire pour la communication entre deux processus distants est considérée
comme réalisée au plan technologique dès lors que le quintuplet suivant est déterminé et connu
sur chaque site-client et serveur - voulant établir une communication :
{protocole, adresse_serveur, port_site_serveur, adresse_site_client, port_site_client} 
 
Communication RPC entre deux processus (GABASSI, 1992) 
Le mécanisme de communication RPC (Remote Procedure Call) entre les processus distants est
synchrone en mode connecté ou non.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 41

Serveur :
Application-RPC (désencapsulage de l'appel rpc)
... exécution de l'ordre
sqlrpc('select nas, nom FROM Ouvrier') (encapsulage du résultat)
retour des données par le serveur
au processus appelant)
suite de l'application :
récupération de la réponse et calcul.
...

Figure 2.12d
Il permet de transmettre une information à un autre processus distant de façon similaire à un
appel de procédure standard. Le processus appelant émet le RPC() et attend le résultat avant de
poursuivre son activité au niveau de la station client. Le serveur reçoit l’appel et les arguments
de la procédure, exécute la tâche sous-tendue par cet appel et retourne les résultats.
La gestion de la synchronisation et du rendez-vous est prise en charge par les procédures du
RPC. Cette technique se prête bien à l’exécution de l'ordre DML d’une application client, car cet
ordre doit être exécuté entièrement avant que l’application poursuivre son traitement local. Le
RPC est une couche par dessus la socket et constitue de ce fait une interface plus conviviale pour
le développement des applications.
Appel dʹune procédure distante dans une architecture client‐serveur 
Ce mécanisme d'échange de données entre deux processus est de plus en plus utilisé. Le schéma
de la figure 2.12d inspiré par celui présenté par Gray et Reuter (8) illustre les étapes d'exécution
d'un appel RPC entre deux processus distants.

L'encapsulage (packaging) peut être fait par un langage spécialisé comme le IDL (Interface
Description Language) qui, une fois compilé donne un code que le serveur cible peut compiler
pour générer un code exécutable. Chaque RPC est associé à un point de communication
différent (IP, port) de sorte que le retour de l'appel RPC se fait sans ambiguïté. Avec tous ces
mécanismes pour la communication, chaque appel à une fonction système génère une
commutation de contexte qui n'est pas neutre en terme de charge sur le CPU. C'est souvent un
facteur limitatif pour la performance d'un SGBD.
Architecture fonctionnelle générale du SGBD 
L’architecture générale (9) d’un SGBD a plusieurs variantes entre les deux configurations
extrêmes ci-dessous. Le choix d’une variante dépend entre autres choses des ressources du
serveur, du nombre de clients sur le réseau et de la nature des traitements effectués par les
applications.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 42

Usager 1 Usager 2 Usager 3

TCP-IP TCP-IP TCP-IP

Réseau

Serveur TCP-IP

Exécuteur Exécuteur Exécuteur

BD
Accesseur
Zone Mémoire Partagée

Figure 2.13
Exécuteurs dédiés et un Accesseur 
Avec cette configuration, chaque client est associé à un serveur de processus dédié (Exécuteur)
qui est chargé d'exécuter chaque ordre DML reçu de son client. Si aucun client ne transmet un
ordre, le serveur est en attente dans la RAM. Les processus d'arrière plan du noyau du SGBD
ont le même parent soit le compte DBA. Ils peuvent communiquer entre eux au moyen de
tubes, de sockets et par une mémoire partagée. La socket a l'avantage de rendre le noyau
portable dans un environnement réparti, tandis que la mémoire partagée privilégie la
performance dans l'accès aux données. Avec l’architecture de la figure 2.13, les ordres qui
arrivent d’une même station sont traités par le même serveur de processus (SP) dédié à ce client.
Il pourra y avoir plusieurs Exécuteurs tant que leur nombre ne dépasse pas celui autorisé par le
DBA via le paramètre système approprié.

Une fois la réponse calculée, les tuples sont retournés à la station client par lʹexécuteur dédié via 
le lien TCP/IP entre le serveur Oracle et le client en question. Ce lien reste ouvert tant et aussi 
longtemps  que  lʹapplication  ne  ferme  pas  la  base  par  un  ordre  Close.    Cette  architecture  est 
caractérisée  par  un  usager  connecté  servi  par  un  exécuteur  dédié.    Si  le  nombre  dʹusagers 
dépasse  le  nombre  dʹexécuteurs  autorisés,  la  connexion  ne  sera  pas  établie  immédiatement. 
Cette  configuration  est  pratique  lorsque  le  nombre  de  clients  est  raisonnable  et  que  les 
ressources informatiques sont  largement disponibles. De plus, cette configuration ne comprend 
quʹun seul Accesseur chargé des accès aux pages, au service de tous les Exécuteurs. 
Avantage  
Le  serveur  de  processus  est  dédié  à  un  client;    il  est  en  attente  lorsque  ce  dernier  effectue  des 
calculs  locaux.  Il  est  mis  en  veilleuse  après  la  fermeture  de  la  communication  avec  le  client.  Il 
demeure inactif tant que le client l’est aussi. 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 43

Inconvénients  
Le  nombre  dʹExécuteurs  concurrents  croît  avec  celui  des  usagers.  La  charge  du  répartiteur 
sʹaccroît  dʹautant  et  cela  peut  se  traduire  par  une  diminution  de  la  performance  du  SGBD, 
accompagnée  dʹun  encombrement  plus  important  de  la  RAM.  Cette  architecture  exige  un 
ordinateur puissant, des disques rapides de préférence de type RAID et une mémoire RAM très 
importante, afin de réduire au minimum la pagination. En effet, la multiplication des Exécuteurs 
accapare la mémoire nécessaire pour assurer une bonne performance et minimiser les échanges 
de  pages.  Finalement,  le  partage  des  données  par  plusieurs  Exécuteurs  nécessite  un  contrôle 
centralisé des accès à la ZMP qui demeure unique.   
                 
Exécuteurs partagés avec un seul Accesseur 
Une autre configuration met en oeuvre une plus grande coopération entre quelques exécuteurs
qui traitent les requêtes en provenance de plusieurs clients. Pour réaliser cette architecture, il
faut un module de réponse pour chaque communication établie avec un poste client. C'est le
module Dispatcher (le Di) qui joue ce rôle de prendre en note l'adresse du client, de recevoir la
requête et de la formater correctement avant de l'insérer dans la queue associée à un Exécuteur.
Ce dernier est aussi partagé entre plusieurs clients. Le rôle du répartiteur de l'OS sera de voir au
partage du processeur entre les deux Exécuteurs en tenant compte de leur priorité respective.
Bien entendu, un système à deux processeurs serait plus performant, car chacun aurait son
propre Exécuteur.

Usager 1 Usager 2 Usager 3 Usager 3

TCP-IP TCP-IP TCP-IP TCP-IP

Réseau

Serveur TCP-IP
module D2 module D1

OUT IN 
OUT IN
Exécuteur
Exécuteur
BD

Accesseur  Zone Mémoire Partagée


Figure 2.14

Dans ce cas de figure, un seul Accesseur gère le transfert des pages de la zone ZMP. En effet, le
travail de l’Accesseur est plus léger que celui de l’Exécuteur; il peut donc être partagé avec
profit entre plusieurs Exécuteurs et cela, sans perte significative de performance. Pour isoler le
client de l'Exécuteur, un processus intermédiaire (Di) est créé avec la mission de recevoir la
requête d'un client et d'agir en son nom au niveau du serveur.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 44

L'OS doit être multitâche et préemptif. Les Exécuteurs de même priorité obtiennent à tour de
rôle le processeur pour faire progresser leur traitement jusqu’à l’épuisement de leur quanta de
temps CPU. À ce moment, le répartiteur de l'OS passe le contrôle du CPU à un autre processus
Exécuteur qui retire une requête dans une file d'entrée d'un client.
Avantages de cette architecture multiexécuteur partagé 
Le nombre d'Exécuteurs est plus petit que celui des clients puisqu'ils sont partagés. Ceci se
traduit par un encombrement moindre de la RAM et donc une charge de swapping plus faible.
Comme il y a moins de processus actifs, il y a aussi moins de commutations de contexte.
Finalement, cette configuration se prête naturellement à l'exécution parallèle lorsqu'il y a
plusieurs processeurs partageant la même mémoire RAM. L'inconvénient a trait au temps de
réponse avec un système monoprocesseur. En effet, comme le client n'a pas d'Exécuteur dédié, le
temps de réponse risque d'être parfois plus long si la transaction précédente ou concurrente est
longue.
Ressources du logiciel client 
Chaque client doit avoir les ressources en logiciels nécessaires pour établir la communication et
gérer les échanges. Avec plusieurs versions du système Oracle, il y a notamment le module
SQLNET, le module SQLPlus et le Developer/2000. La gestion des échanges avec le serveur est
faite par le module SQLNET de la station qui gère la communication réseau, notamment les
couches inférieures du modèle OSI. L’exécution d'un ordre DML est sous la responsabilité du
serveur de processus (Exécuteur) et, pour certains logiciels clients, le caractère procédural dans
une requête complexe peut être pris en charge par un module du serveur capable d'exécuter un
bloc PL/SQL.
Communication client‐SGBD avec Oracle 
L’architecture générale du système Oracle, (version 7.x) comporte plusieurs processus distincts
pour le noyau, un processus de communication et une zone de mémoire partagée pour la
communication interprocessus au sein de la machine serveur. Nous utiliserons cette architecture
comme exemple de référence en précisant que d’autres sont toutefois possibles.

client 1  client 2 Réseau

SQLNET
Serveur de processus (SP)
SGA OUT IN
D3

Processus de service DBWR

Serveur
Configuration avec entrelacement de l’exécution (multithreading)
Figure 2.15

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 45

Voici une vue plus détaillée de deux des modules :

Serveur de Processus (SP)

Processus de service:  

RECO CKPT PMON ARCH LGWR SMON

BD + DD
Journal

Figure 2.16

La communication entre les processus est assurée par les mécanismes IPC connus : zone de
mémoire commune (ZMP = SGA) et le RPC, soit l’appel de procédure distante. Du côté de
l’usager, le processus client gère les échanges de données avec le noyau du SGBD qui s'exécute
sur le serveur.
Connexion dʹun client 
La procédure générale est la suivante :
a) Le client signale sa présence au Module d’Écoute du Réseau (MER ou Listener de SQLNET)
au moyen de son adresse (IP, no-port). Après la connexion sur semande du client, ce dernier est
averti de l’établissement de la connexion.
b) Du côté du MER, il y a un répartiteur (dispatcher) qui reconnaît détecte la requête de
connexion. Il y a retour de l’adresse d’écoute (adresse Ethernet) qui est valide pour la session en
cours.
c) Le client transmet la requête SQL au répartiteur qui la met, s'il y a lieu, en file d’attente avant
son traitement par un serveur de processus (Exécuteur).
d) En mode entrelacement d’exécution (multithreading), la queue est servie par un nombre limité
de serveurs de processus (SP).

S’il n’y a pas de serveur de processus disponible (Exécuteur) et si un autre peut être ou est
autorisé par le DBA, il y aura création automatique d’un serveur de processus (SP) pour le client
concerné. Le nombre de SP ne peut cependant pas dépasser une limite fixée par le DBA.
Fonctionnement schématique d’un SGBD  
Le fonctionnement général d’un SGBD est représenté à la figure 2.17. Le schéma illustre les
principales fonctions généralement implémentées par un moteur de SGBD qui tourne sur un
serveur dans une approche client/serveur.
Séquences des traitements 
Le traitement d'un ordre DML est réalisé complètement avant le passage à l'exécution d'un autre
ordre DML du même programme client. La figure 2.18 présente schématiquement les
enchaînements dans le traitement d'une requête ou d'un DML :

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 46

1)Réception  de  lʹordre  DML  par  lʹExécuteur  en  vue  dʹune  première  étape  dʹanalyse 
lexicographique. La transaction est ensuite dirigée vers le module dʹanalyse.  
 
2) Vérification syntaxique et sémantique de l’ordre en se référant au dictionnaire de données
(DD) afin de valider les attributs. Dans le cas du DDL, il peut y avoir de nouvelles entrées dans
le dictionnaire.

Analyse lexicographique

Analyse syntaxique et
Dictionnaire sémantique
de données

Traduction DML ou requête

Vérification des droits ZMP


d'accès
page 2 Journal
interne

copie arbre schémas :conceptuel


Mapping de la requête réutilisable externe et interne

Optimiseur

Accesseur BD
Exécution de l'ordre :
gestion de la transaction

RAM Zone de travail

Retour de la réponse au
client via le dispatcher de
processus

Journal
Journalisation
externe

Figure 2.17

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 47

3) L’ordre est ensuite traduit pour construire un arbre d’exécution non optimisé qui est rangé 
dans la ZMP afin de pouvoir être réutilisé au besoin par dʹautres clients (cas des requêtes 
OLTP). Pour un SGBD relationnel, lʹarbre est constitué avec les opérateurs algébriques et les 
relations de base qui sont font l’objet de références au niveau des feuilles seulement. 
 
4) Le module de contrôle des accès vérifie les droits d'accès de l’utilisateur pour les données
requises par le calcul de la réponse. Il y a aussi accès au dictionnaire.

5) Chargement dans la ZMP des schémas de relation stockés dans le dictionnaire et de la liste
des droits d'accès.

6) Pour une requête d’interrogation : remplacement des attributs de la vue par ceux du schéma
conceptuel et référence au schéma actuel.

7) L'arbre de requête est optimisé afin d'obtenir une requête arborescente équivalente qui
permet un calcul plus rapide de la réponse.

Pour la mise à jour : Augmentation de l’arbre par une vérification des contraintes spécifiées dans
le schéma. Les procédures sont chargées par le module de vérification de l’intégrité de la BD.

8) Génération du plan d’exécution optimisé, lequel est rangé dans la ZMP.

9) Exécution de chaque plan par le module de calcul. Il y a alors intervention du module de


gestion transactionnelle incluant le répartiteur de transactions. L'Exécuteur doit à ce moment
avoir toutes les informations nécessaires au calcul de la requête ou à l’exécution du DML.

10) Journalisation interne (redo log buffer) des seules transactions d’écriture et de mise à jour.

11) Lecture ou écriture des pages demandées. L’adresse de la 1re page est lue dans le dictionnaire
de données.

12) Au besoin, le recouvrement de la base de données est fait avec le journal des transactions
internes pour reconstituer la base de données dans un état cohérent antérieur.

13) La réponse est placée dans la queue de sortie et l'ouverture d'une socket permet le transfert
des tuples au client.

A l'exécution d'un COMMIT, les écritures de la transaction sont transférées du journal interne
vers le journal externe (log file) créé sur le disque dur. Au contraire, avec le ROLLBACK, les
modifications et les écritures effectuées sont défaites pour revenir à l'état de la base
correspondant à celui du début de la transaction. Cette opération sous-tend l’écriture des
anciennes valeurs.
Exemple d’un traitement d’un ordre de requête simple 
Le MRD de la base utilisée correspond à un MCD fort simple composé d'une seule relation
appelée aussi une table et qui décrit les attributs des employés. La clé de cette table est le nas
identifiée par un astérisque .
© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 48

Employe (nas*, nom, ville, salaire, noProjet)


Schéma externe (vue de la BD)  
La vue relationnelle est définie sur la relation de base Employe comme étant une autre vision de
la table, soit un sous-ensemble de ses attributs, au besoin différemment nommés :

Employev (matricule*,cite, noProjet)

Cette vue Employev définit un mapping entre la table de base et la table virtuelle représentée
par la vue.

Attributs de la table Attributs de la vue


nas ----> matricule (nom différent)
nom ----> (attribut absent)
ville ----> cite (nom différent)
salaire ----> (attribut absent)
noProjet ----> noProjet (idem)

La vue correspond à une projection relationnelle des attributs de Employe sur ceux de la vue.
Cet opérateur sera étudié au chapitre de l’algèbre relationnelle. Cette vue est associée à
l'application lors de l'ouverture de la base de données.
Approche ensembliste 
Le traitement de la requête ci-dessous n’est présenté qu'à titre d'illustration pour décrire le
travail effectuée par le SGBD.

La question : Trouver le matricule et la cité des employés assignés au projet 'P9' ?


Sous forme d’un DML fictif, cette question pourrait s’écrire :

TROUVER Employev.matricule, Employev.cite AVEC Employev.noProjet = 'P9'

Analyse lexicale et syntaxique : validation des mots clés et de la syntaxe de la requête :

TROUVER <liste-attributs> AVEC <prédicat>


 
Traduction de la requête par l’intégration d’un appel de procédure dans le langage hôte :

CALL DMLSGBD
(dml, `matricule, cite’,’Employev’,noProjet = 'P9', reponse, codeRetour)

où l'argument dml = 1 correspond à l'ordre TROUVER. La fonction DMLSGBD() assure


notamment la communication avec le SGBD via une socket ou un RPC.
Au niveau du serveur, il y aura consultation du dictionnaire de données (DD) pour vérifier si la
vue utilisée par l’application autorise l’accès aux données (étape 3).

Ensuite, il y a génération d'un arbre de requête par le SGBD intégrant la transposition des
éléments de la vue pour tenir compte du schéma de la base (étape 4). Pour une requête

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 49

d’interrogation, il y a optimisation de l’arbre de requête pour privilégier l'usage de l'index


existant sur l’attribut noProjet de la table Employe. Un plan d'exécution est préparé pour l'étape
suivante.

Génération du plan d’exécution de la mise à jour. 
Les adresses de la première page de l'index et des données sont dans le dictionnaire du SGBD.
Ainsi, le système peut savoir quel index utiliser et où le trouver sur le disque :
...
WHILE code_succes = SUCCES
read index Employe avec noProjet = 'P9'— trouve no de page
read page Employe avec l'adresse de la page (no de page)
write Employe.nas, Employe.ville (+ mapping des noms d’attributs)
Fin while.

8) Exécution du plan : l’accès aux fichiers sur disque est fait par l'Accesseur.

9) Dans le cas d'une modification de la table, il y a écriture dans le journal interne et


éventuellement dans le journal externe (à la validation) des données avant et après
modification.

10) La page est placée dans le tampon du moteur SGBD (la ZMP) avec un verrou approprié
demandé par l'Exécuteur. Ce dernier garantit l'intégrité en refusant ou en autorisant le partage
des données avec les autres utilisateurs.

(4) Affichage de la réponse

(3) Transposition : nas devient matricule et ville devient cite

(2) Extraction de nas et ville

(1) Recherche du projet P9


Début

Employe
Figure 2.18

11) Le module de recouvrement demeure inactif, car l’opération est présumée avoir été
complétée correctement.

12) L'Exécuteur accède à la ZMP pour calculer la réponse et retourner les données à l’application
conformément au schéma externe (s'il y a lieu, transposition des noms d'attribut).
Remarque : Cette exécution sert seulement d’illustration générale et n’est pas nécessairement
typique ni de l’interface entre une application et le SGBD, ni des techniques d’implémentation
des SGBD qui varient d'un système à l'autre.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 50

Gestion et répartition transactionnelle par lʹExécuteur 
Le module Calcul est responsable de construire la réponse et comprend, notamment dans les
sous-modules de Gestion Transactionnelle (GT) et de Répartition Transactionnelle (RT) des
actions de lecture et d'écriture sur le disque. On peut représenter ces deux derniers modules par
le schéma général ci-dessous. Lors du traitement de deux ordres distincts en provenance de
deux applications différentes, l'Exécuteur peut les traiter en concurrence par un métissage du
traitement des deux transactions. Ainsi l'ordre r1 est une lecture de page appartenant à la
transaction T1 et r2 une autre lecture associée à la transaction T2.

Train de lectures et écritures de pages :

Répartiteur c1, r1, c2, r2, e1, r1, e2, r2


c1, r1, e1, r1 c2, r2, e2, r2
Transactionnel
RT
T1 T2 séquence modifiée 

Figure 2.18a
Le rôle du module GT est de voir à ce que chaque transaction se termine correctement, sinon la
transaction en cause est défaite entièrement. Il prend note du début de chaque transaction et
lancera au besoin le processus de recouvrement transactionnel (en utilisant le journal interne ou
la trace transactionnelle) qui se traduit par défaire toutes les modifications effectuées par une
transaction sur la BD, sans perturber les autres transactions en cours.

Le rôle du Répartiteur Transactionnel (RT) est plus complexe; il est important pour assurer un
meilleur temps de réponse pour l'exécution des diverses requêtes. En effet, l'exécution de
chaque ordre SQL correspond à une séquence d'écritures et de lectures qui peut être exécutée
intégralement pour fournir un temps de réponse qui pénalise les autres usagers, notamment
lorsque la requête en cours est longue. La figure ci-dessus illustre ce problème avec deux
transactions {r1, e1, r1,} et {r2, e2, r2}. La première correspond à une suite d'actions sur la base de
données composée d’une lecture r1, suivie d'une écriture e1 et qui se termine par une simple
lecture r1.

Le répartiteur a pour mission d'intercaler les actions de lecture et d'écriture en provenance de


différentes requêtes de manière à ce que leur exécution respective progresse en parallèle pour
fournir plus rapidement une réponse partielle aux clients. Cet entrelacement des lectures et des
écritures ne se fait pas arbitrairement. Il est créé par le répartiteur transactionnel de telle sorte
que le résultat final soit identique à celui qu'il serait si l'exécution avait été séquentielle. Il faut
remarquer que le SGBD fournit ainsi son propre répartiteur différent de celui de l'OS. Ce
répartiteur transactionnel (RT) permet d'avoir une exécution multithreading plus fine des
requêtes. De plus, l'accès aux données doit se faire tout en préservant l'intégrité de la base. Si les
requêtes étaient exécutées de façon séquentielle, aucun verrouillage sur les données ne serait
nécessaire, mais la performance serait médiocre. Par contre, avec l'action du RT, il devient
parfois essentiel d'utiliser les verrous sur les données sous le contrôle exclusif du SGBD. Le
système d'exploitation hôte n'intervient pas directement, sinon pour donner le contrôle au SGBD
qui devrait normalement avoir une plus grande priorité que celle des autres processus qui
cohabitent et se concurrencent pour le même CPU.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 51

Contenu général de la zone de mémoire partagée 
L’espace  global  de  la  ZMP    sert  au  rangement  de  données  de  la  base,  des  métadonnées  du 
dictionnaire,  des    schémas  de  table  et  de  certaines  données  concernant  lʹexécution  de  chaque 
ordre DML ou de chaque requête.   

ZMP
pages importées pages validées journal interne reprise transactionnelle (LRT)

transactions actives (TA) liste DIRTY


liste LRU

no-trans. 5

fin
MRU Table des pages
m
modifiées (TPM)

Zone partagée : Zones privées :


Schéma conceptuel, externes, interne r : page en lecture PGA pour chaque application : P1 et P2
Packages et triggers m : page modifiée Processus P1
c : page cloué Processus P2
Plans d'exécution code re retour code retour
réutilisables

Figure 2.19

Ces diverses listes sont au cœur du fonctionnement du moteur SGBD :


a) Les pages de données de la base qui sont demandées (pages importées) par les requêtes et
obtenues par le travail de l'Accesseur sur demande de l'Exécuteur. Au niveau de
l'implémentation, cette zone peut être constituée de plusieurs segments physiques dont le
contenu varie avec les activités en cours de réalisation par le SGBD. La ZMP est gérée
dynamiquement; chaque liste occupe l'espace dont elle a besoin à un instant donné. L’espace
ZMP logique est entièrement découpé en pages, lesquelles sont enchaînées pour former
différentes listes de la ZMP. Cela est illustré sommairement par la figure 2.19 .

b) Les pages où sont rangées les entrées du journal interne comprennent les images avant (AV)
et après (AP), le numéro de transaction, l'adresse de la donnée (rowid) et le type de transaction.

c) Les pages de métadonnées (dictionnaire) : schéma conceptuel (liste des Entitiés, des
attributs,…), schéma interne et les schémas externes.

d) Les pages de recouvrement (Rollback Segment) formant la liste LRT permettant de ranger la
valeur avant (AV) de chaque donnée modifiée par une même transaction. Ces pages
représentent une information aussi inscrite dans le journal interne (JI). Ces pages LRT
permettent de recouvrer plus rapidement une transaction particulière sur l'ordre ROLLBACK.
Le recouvrement est plus rapide avec le LRT qu'à partir du journal interne et surtout, ne
perturbe pas l’exécution des autres transactions.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 52

e) Un espace PGA pour chaque application en cours de traitement par un processus serveur
(SP). Cet espace contient une référence à l'ordre DML source, une référence à son plan
d'exécution dans la cache partageable et le ou les premiers tuples de la réponse et une référence
à la queue ou à la liste des tuples de la réponse constituée des tuples calculés par le module
Exécuteur. Cette zone de la ZMP permet de poursuivre l'exécution du traitement d'une requête
interrompue.

f) Un espace pour stocker les triggers et les packages dont les pages peuvent être au besoin
clouées dans la ZMP.

g) Un espace partagé pour ranger l'arbre de requête source et sa version optimisée de manière à
pouvoir le partager ou le réutiliser avec d'autres transactions.

h) Dans certains cas, les files de sortie et la file d'entrée des réponses aux requêtes sont
implantées dans la ZMP.
i) Les pages de la table des transactions actives (TA) : avec le no de transaction et la dernière
entrée dans le JI.

Les pages rangées dans la ZMP sont insérées dans diverses listes leur conférant un statut
particulier :
• Page modifiée (m : liste LRU) : Page de la BD lue par lʹAccesseur et éventuellement modifiée 
(incluant  les  ajouts)  après  leur  transfert  dans  la  ZMP.  Ces  pages  modifiées  sont  validées 
lorsque toutes les transactions qui ont  effectué des modifications ont exécuté un COMMIT. 
Elles  sont  non  validées  si   au  moins  un  COMMIT  reste  à  faire  pour  confirmer  un  ou 
plusieurs  changements  dans  la  page.  Ces  pages  seront  transférées  éventuellement    dans  la 
liste DIRTY en cours de recherche.  
• Page clouée (c ) : une page de la base de données et qui est en cours dʹaccès en modification 
ou en écriture.  
• Page libre  (∗) : une page de la base de données entièrement validée ou libérée après lecture. 

En cas de besoin d'espace dans la ZMP, les pages de la liste Dirty sont en premier transférées sur
le disque. Au besoin, les pages de la liste LRU peuvent aussi être stockées temporairement sur
disque.
Lecture dʹune page de données de la base   
a) Lors du calcul d'une réponse, l'Exécuteur accède aux pages de données pour lire les tuples.
Cette opération comprend les étapes suivantes :
b) Le serveur de processus, i.e. l'Exécuteur, cherche la page en premier dans la liste LRU et
ensuite dans la liste DIRTY de la ZMP.
c) Dès que la page est trouvée, elle est normalement enchaînée vers la partie MRU de la liste
LRU, sauf si le traitement sous-tend un balayage complet d'une table. Dans ce cas, la page
pourrait être gardée dans sa position courante dans la liste (LRU).
d) Si la page n’est pas trouvée dans la ZMP, l’exécuteur remplace une page de la liste LRU
(partie LRU) par une autre obtenue de l'Accesseur. Si nécessaire, une page de la liste DIRTY
sera écrite par l'Accesseur sur disque afin de faire de la place pour ranger de nouvelles
pages. Dans le cas limite correspondant à une liste DIRTY vide et à une liste de pages

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 53

entièrement validées tout aussi vide, alors une page de la partie LRU sera placée sur disque
même si elle n'est pas marquée r de manière à pouvoir importer la page demandée.
Modification dʹune page de données de la base   
Cette opération de mise à jour d'une donnée sous-tend les étapes suivantes :
a) Recherche de la page dans les listes LRU; en cours de recherche, transfert des pages
modifiées antérieurement et validées par toutes les transactions : de la liste LRU vers la liste
des pages DIRTY.
b) Si la page n’est pas trouvée, il y a un défaut de page. Il s'en suit une lecture de la page
demandée sur le disque, suivie de son placement dans la liste LRU (généralement dans la
partie MRU de la liste).
c) La page importée dans la ZMP en vue d'une modification est marquée comme étant clouée
(pinned page). Après modification, elle sera marquée modifiée jusqu'au COMMIT. Si elle
n'est que lue, la page est marquée r pour en permettre le remplacement éventuel.
d) Si la page demandée est trouvée dans la ZMP, elle est marquée clouée en mémoire (pinned
page) et l'accès aux données est rendu possible. Par contre, si une page recherchée n'est pas
trouvée dans la ZMP et que toutes les pages sont marquées clouées, l'Accesseur évacuera
une page clouée pour la remplacer par la page demandée en provenance du disque. Cette
page exportée demeure clouée. En cas de panne, le module de recouvrement utilisera les
images AV pour défaire les modifications qui n'ont pas été validées par un COMMIT. Ces
pages clouées exportées sur disque seront au besoin importées à nouveau dans la cache, dès
lors qu'un Accesseur y réfère dans le calcul d'une requête. Pour éviter autant que possible
cette évacuation d'une page clouée, il faut favoriser les transactions courtes dont la fin est
marquée par l'exécution d'un ordre COMMIT.
Écriture de pages modifiées et validées sur disque par lʹAccesseur 
L'écriture d'une page de données sur disque est réalisée par l'Accesseur lorsqu’un des
événements suivants est activé :

‐  Sur  demande  de  lʹExécuteur  ou  lorsque  la  longueur  de  la  liste  DIRTY  a  atteint  une  valeur 
critique (lw). 
 
- Sur demande de l'Exécuteur, lorsque l'espace disponible est insuffisant et introuvable dans
la ZMP.

- Sur un dépassement du temps alloué (time-out), par exemple toutes les 2 secondes, l’écriture
est demandée par l’Accesseur.

- Lors d'un point de reprise (checkpoint), amorcé par le DBA ou par un changement de journal
externe.

- L’Accesseur peut écrire au besoin un bloc de pages de la liste des pages modifiées (DIRTY)
dans une seule opération I/O. Cette écriture en vrac (pipeline) est plus rapide que celle d’une
suite de pages exigeant une suite d’opérations consécutives. Les pages écrites en bloc doivent
avoir des numéros de page contigus

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 54

2.3 Journalisation transactionnelle 
Après chaque modification d'un tuple dans une page de la ZMP, l'Exécuteur (avec Oracle, c'est
le Serveur de processus (SP)) écrit certaines informations dans le journal interne (JI) : le numéro
de transaction, la nature du DML, l'adresse de la donnée sous forme d'un rid (row identifier),
l'heure, l'image avant de la donnée (AV) et l'image après (AP) en plus d'autres informations
nécessaires pour gérer les listes du journal interne, notamment un numéro de séquence, JSN, qui
identifie chaque entrée dans le journal. La structure du journal des transactions est propre à
chaque SGBD. Les entrées du JI peuvent être écrites au besoin dans le JE de manière à libérer de
l'espace dans le journal JI.

Ex. Entrée type dans le journal interne :

numéro numéro de la type de page_id offset Image Image


JSN précédent transaction transaction (no de slot) AV AP

Chaque entrée a son numéro de journal (JSN) et les entrées d'une même transaction sont chaînées.
Figure 2.19a
Les entrées d'une même transaction peuvent être chaînées les unes aux autres par un pointeur
arrière, le JSN_précédent. Ce pointeur permet de parcourir rapidement les entrées d'une
transaction lorsque celle-ci fait une opération rollback transactionnelle. Le journal interne est
organisé en une liste circulaire de sorte que les entrées finissent par être réutilisées par de
nouvelles entrées après l'atteinte de la fin de la liste. Par conséquent, les entrées du JI n'ont pas
besoin d'être effacées lors d'un COMMIT ou d'un CHECKPOINT. A titre indicatif, voici le
contenu partiel et lisible d’un journal interne. En pratique, les entrées font l’objet d’un codage de
sorte à compacter le journal interne.

no : JSN précédent no transaction type page_id offset AV AP


1 nil Tr13 U 2 32 24 28
2 nil Tr24 U 6 34 23 9
3 2 Tr24 U 2 3 23 8
4 nil Tr2 D 8 29 4 12

page_id premier JSN compteur no_trans. dernier JSN


2 1 2 Tr13 1
6 1 Tr24 3
8 4 1 Tr2 5
Table des pages modifiées (TPM) Table des transactions actives
avec compteur des modifications (TA)
Journal interne et quelques tables de contrôle du SGBD
Figure 2.19b

Chaque page modifiée par une transaction est inscrite dans la Table des Pages Modifiées (TPM)
de la figure 2.19b comportant aussi un compteur cpt qui est augmenté après chaque mise à jour.
Lors du commit de la transaction t124, les entrées du JI associées à cette transaction sont copiées
dans le JE et le compteur cpt est décrémenté. Ainsi, lorsque le compteur est à 0, cela signifie que
toutes les modifications de cette page sont validées et que la page pourrait être transférée dans
la liste DIRTY, qui est celle qui fournit en priorité les pages à évacuer en cas de manque d'espace

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 55

dans la ZMP (Défaut de page). La table TPM comprend la première entrée du journal interne
correspondant à la modification de cette page; elle fournit le numéro de cette première
transaction dans le journal interne à partir de laquelle il faudra refaire les mises à jour en cas de
panne de système.

N.B. chaque page peut aussi avoir dans son en-tête une petite liste de numéros uniques de
transaction qui ont modifié les données de la page ou encore la dernière entrée du journal, soit le
dernier_JSN qui a modifié cette page.
Calcul dʹune réponse 
L'Exécuteur chargé du calcul de la réponse a souvent à manipuler plusieurs tables de base, et
parfois autant d'index, pour obtenir tous les tuples de la réponse (active set ou result set).

ZMP (SGA) PGA de l'utilisateur U2

curseur C1
Pages
temporaires
pour les
tuples de la
réponse
curseur C2

Queue de
sortie
1er tuple de la
réponse

Figure 2.20
Ce calcul peut être fait en mémoire en rangeant les tuples dans des pages temporaires allouées
en dehors de la ZMP ou encore en utilisant des fichiers de travail pour y loger les tuples
intermédiaires.
Au terme du calcul, l'Exécuteur connaît le nombre de tuples de la réponse. Il place un ou
plusieurs tuples de celle-ci (1 par défaut) dans un CURSEUR implicite créé et associé au PGA de
l'application. Il peut y avoir plusieurs curseurs implicites ouverts en même temps pour une
même application. À l'exécution d'un ordre CLOSE, implicite ou explicite, cet espace de
rangement temporaire est libéré et le curseur associé est supprimé.

Le premier tuple est retourné immédiatement à l'application, tandis que les autres sont transmis
seulement par l'exécution d'un ordre FETCH inséré dans l'application. La queue de sortie (et
d'entrée) est implémentée dans la ZMP, elle pourrait être constituée d'une liste de pages
contenant les tuples de la réponse. En sortie, une entrée dans la queue est constituée d'un
pointeur, éventuellement en indirection par l'entremise du PGA, sur la liste des pages contenant
la réponse
Validation dʹune transaction 
La validation d'une transaction T1 est lancée par l'ordre COMMIT. Tous les changements
effectués par T1 deviennent alors visibles aux autres transactions concurrentes qui n'ont pas lu
ces tuples auparavant et qui débuteront après la validation.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 56

Les effets d’un COMMIT sont les suivants :


a) La persistance des modifications réalisées par la transaction est assurée grâce à lʹécriture des 
entrées du journal interne vers le journal  externe, et cela depuis le dernier commit inscrit dans le 
journal interne pour cette transaction. 

b) Les données modifiées deviennent  visibles pour les autres transactions qui débutent après le 
temps  t  du  Commit.  Les  modifications  restent  cependant  invisibles  aux  transactions  qui  ont 
débuté avant le temps du Commit (cohérence de lectures répétitives) et qui ont peut être lu les 
mêmes tuples sans voir leurs modification ultérieures. Par contre, si ces mêmes tuples nʹont pas 
été lus par dʹautres transactions, ils deviennent alors visibles immédiatement.  
c)  Le  Commit  termine  une  transaction  et  en  débute  une  autre  avec  un  numéro  différent  et 
toujours  unique.  Après  un  Commit,  il  devient  impossible  de  faire  un  retour  arrière  par  un 
Rollback. Les données validées sont rendues persistantes. 
Journalisation et reprise 
Une transaction est définie comme une unité logique de traitement sur la BD, définie par le
traitement entre deux validations. Elle doit se réaliser entièrement ou pas du tout lorsque
survient une panne ou une erreur en cours d’exécution. La panne peut être un arrêt de
l'application client, la perte de l'instance du SGBD ou une défaillance sur un média.

Actions sur BD Entrées dans le JI Sémantique


T1 Début 13:45;T1;Début; début de T1 (V = 25)
T1: Lire X->50
T1: Ecrire X->75 13:46;T1;E;X,50,75; modification de X par T1
T2 Début 13:48;T2;Début; début de T2
T2: Lire V-> 25
T2: Ecrire V->10 13:50;T2;E;V,25,10; modification de V par T2
T1: Lire V-> 25 valeur V au début de T1
T1: Lire Z-> 35
T2: COMMIT 13:52;COMMIT; copie JI-> JE; nouvelle
(msg de confirmation) transaction T2
T1: Ecrire Z-> 10 13:53;T1;E,35,10; modification de V par T1
T2: Lire V–>10 lecture de V par T2
T2: Ecrire V->15 13 :55;T2;E,10,15; écriture de V par T2
***panne d'instance ***********
Figure 2.20a

Pour recouvrer un état stable et cohérent de la BD, il faut défaire une ou plusieurs transactions.
Lorsqu'il s'agit de l'exécution d'un Rollback, la reprise transactionnelle n’implique que cette
transaction. Pour une transaction particulière non encore validée, il faut défaire toutes les
modifications qu'elle a effectuées depuis son début. Le rollback d'une transaction peut être fait à
partir du journal interne, mais il est de préférence fait à partir des segments de rollback (liste
LRT) implémentés dans certains SGBD avec les images AV d'une transaction. Le journal interne
fournit l'image avant (AV) et après (AP) des données modifiées par chaque ordre DML des
transactions. Il est donc possible de revenir en arrière avec les images avant et d'annuler toutes

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 57

les actions effectuées par une ou plusieurs transactions non validées avant que les applications
transactionnelles soient relancées.

Dans cet exemple, il y a lecture et ensuite écriture du tuple avec un champ X modifié pour avoir
50 comme nouvelle valeur. Deux transactions (T1 et T2) sont actives au moment de la panne
générale.

Après la panne du SGBD, la reprise est lancée en défaisant les modifications des deux
transactions jusqu'à leur dernier Commit. Dans l'exemple de la figure 2.20a toutes les
modifications effectuées par T1 seront annulées, tandis que seule la 2e transaction de T2 sera
annulée. La reprise des applications avec de nouvelles données lues après le Commit permet de
poursuivre les traitements sans perte de données et d'éviter les incohérences dans la base.
Une autre propriété importante de la transaction est son isolement par rapport aux autres
transactions. Dès qu'une transaction T1 débute, l'état de la base de données à cet instant
apparaîtra à T1 comme étant invariant ou isolé par rapport aux actions des autres transactions
concurrentes. En fait, une autre transaction T2 peut lire les données modifiées par T1, mais elle
obtiendra la valeur validée au moment du début T2. En effet, le système peut toujours remettre
temporairement une donnée dans son état antérieur stable (par exemple, avec les segments de
rollback transactionnel) et cela, tant que la donnée n'est pas validée. Après la validation, la
donnée devient visible aux autres transactions. En se comportant ainsi, le SGBD satisfait en cela
l'isolement transactionnel des transactions.

L'exemple de la figure 2.20a du journal interne hypothétique dont les entrées sont celles des
deux transactions T1 et T2. Lorsque T1 effectue la lecture de V, elle obtient la valeur qui était
validée au moment du début de la transaction T1 et non pas la valeur mise à jour par T2.
Lorsque survient une panne d'instance suivie de la perte de la ZMP, les seules données
disponibles pour récupérer sont celles du JE. Il faut donc défaire les modifications (UNDO)
effectuées par les transactions non validées au moment de la panne, et faire en sorte, s'il y a lieu,
que les modifications des transactions validées soient nécessairement toutes reconstituées et
écrites sur disque (REDO). Les opérations d'insertion et de suppression sont traitées de façon
similaire.
Procédure générale pour le recouvrement après une panne  
Il y a plusieurs phases dans le recouvrement ou reprise après une panne ou un arrêt imprévu du
SGBD :
1‐  Le module de recouvrement fait une lecture inverse des entrées du JE (qui est généralement 
un fichier séquentiel sur disque) pour faire une liste des transactions non validées TNV et une 
autre TV des transactions validées. Toutes les entrées du JE sont traitées jusquʹà la première, 
i.e.  la  plus  ancienne.  Sans  une  borne  dʹarrêt  spéciale,  le  retour  sera  fait  jusquʹau  début  du 
journal externe! 
2‐  Le  ROLLBACK:  Avec  la  liste  TNV,  les  entrées  du  JE  sont  lues  de  la  plus  récente  à  la  plus 
ancienne et cela,  pour défaire avec lʹimage AV les modifications sur la base de données. 
3‐  Le  ROLL  FORWARD  :  Avec  la  liste  TV,  le  module  refait  en  ordre  chronologique  les 
modifications sur la base de données avec lʹimage AP. Lʹopération REDO débute  avec la plus 
ancienne entrée du JE.  

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 58

Cette opération devient longue si le nombre d'entrées dans le JE est très important. Pour
accélérer les recouvrements, il faudra notamment raccourcir le JE en posant une borne d'arrêt
par l'exécution périodique d'un point de reprise générale (nommé CHECKPOINT) . Ce dernier
consiste à établir à un moment approprié et sur disque un état cohérent de la BD. En ce faisant,
une entrée de point de reprise générale est inscrite dans le JE et joue le rôle d'un butoir dans le
retour arrière. La procédure de recouvrement traite les entrées du JE jusqu'au point de reprise
générale ou à proximité de celui-ci dépendant de la procédure de checkpoint utilisée. En effet, si
le checkpoint est du type synchronisé avec la ZMP, il pourrait être nécessaire de dépasser le
checkpoint général pour défaire certaines transactions actives au moment où a eu lieu
l'opération de CHECKPOINT.
Point de sauvegarde (PS) 
Il est possible pour une application de contrôler seulement la reprise de ses actions
transactionnelles, particulièrement utile avec une transaction longue, en insérant des points de
sauvegarde dans celle-ci. Un point de sauvegarde transactionnel B est généré par la clause
SAVEPOINT B. Un point de sauvegarde (PS) d'une transaction est inscrit dans le JI et
correspond à un point de retour en arrière d'une transaction contrôlé par l'application.

SET TRANSACTION READ WRITE;


USE ROLLBACK SEGMENT rbk_seg1;
-- recouvrement transactionnel
while code = not OK
Update Empl set salaire = 20 0000
where nom = 'Gagnon';
SAVEPOINT A;
while code = not OK
Insert Into Usine set capital = capital *2;
SAVEPOINT B;

If Total_Cap > 100 000 then ROLLBACK TO SAVEPOINT
A; else … end if;
Commit T;

Figure 2.21
Si une transaction doit être défaite, elle pourrait l'être jusqu'à un de ses points de sauvegarde ou
jusqu'au début de sa transaction. et cela, par la commande ROLLBACK TO B. Lors de cette
opération, les modifications défaites sont autant d'actions sur la BD qui sont aussi inscrites dans
le journal interne, pour éventuellement reprendre les opérations en cas de panne qui
surviendrait durant ce retour arrière (Rollback).

L’annulation des modifications faites par une transaction (figure 2.21) ne perturbe pas le
fonctionnement des autres transactions, puisque celles-ci n’ont pas accès aux données modifiées
par la première en raison de l'isolement des transactions. Dans plusieurs systèmes, le point de
sauvegarde est inscrit dans le JI et en plus dans une page de la liste LRT de recouvrement
propre à chaque transaction (Rollback Segment de Oracle) . Avec la commande ROLLBACK, les
tuples modifiés avant le point de sauvegarde A sont conservés verrouillés, tandis que ceux
insérés après ce point A sont annulés. Ces dernières données sont aussi déverrouillées et
deviennent dès lors visibles aux autres transactions. Les données modifiées avant le point de

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 59

sauvegarde A demeurent encore invisibles aux autres transactions. Elles sont toutefois toujours
disponibles pour la transaction en cours. Si la transaction est relativement courte, le retour en
arrière pourra être fait à partir de la liste LRT (segment de rollback). Cette opération est donc
rapide.
2.4 Procédure de checkpoint   
En cas de défaillance, le système doit être capable de recouvrer un état cohérent de la base de
données et cela, après le redémarrage du SGBD. Il existe plusieurs approches de checkpoint,
chacune ayant une procédure particulière de recouvrement qui se manifeste par un arrêt plus ou
moins long des activités transactionnelles sur la BD. Nous en verrons deux : le checkpoint avec
une cohérence au regard du Commit et un autre avec une cohérence par rapport à la ZMP.
Checkpoint synchronisé avec le Commit 
Cette procédure est définie pour synchroniser toutes les validations de transaction et cela afin
d'assurer qu'au moment de la réalisation du checkpoint, aucune transaction n'était active et que
la base de données était reconnue comme intègre à ce moment (figure 2.22).
CHKPT

T1

commit

T2 commit

panne
T3

temps

Figure 2.22

Les étapes sont les suivantes:


1‐  Après le lancement du checkpoint par le DBA, aucune nouvelle transaction ne peut démarrer. 
Le système attend la fin des transactions actives. 
 
2‐  Les opérations transactionnelles en cours sur la base de données se poursuivent tant quʹil y a 
une transaction non validée par un COMMIT. 
 
3‐  Lors  du  checkpoint,  les entrées  du  JI  sont  copiées  dans  le  JE  et  toutes  les  pages  de  données 
(LRU  et  celles  de  lʹextrémité  MRU)  modifiées  sont  aussi  écrites  sur  disque.  A  ce  moment 
toutes les pages ont été validées par un Commit puisque toutes les transactions sont validées. 
 
4‐  A  la  fin  de  lʹécriture  des  pages  modifiées  par  le  module  chargé  du  checkpoint,  il  y  a 
inscription  dʹune  entrée  de  checkpoint  dans  le  JE  et  la  procédure  se  termine.  Les  activités 
transactionnelles peuvent alors reprendre. 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 60

Recouvrement  
La procédure de recouvrement de base avec cette approche permet de revenir au dernier
checkpoint pour avoir un état cohérent de la base. Ensuite, il suffit d'appliquer la procédure de
reprise.
Checkpoint cohérent avec les données de la ZMP 
Ce type de checkpoint évite d'attendre celui des transactions actives en leur interdisant
cependant, toute nouvelle opération sur la base de données pour la durée du checkpoint (figure
2.23). L'avantage de cette approche est d'affranchir le SGBD des transactions longues.

Les étapes de cette approche sont les suivantes :


1‐  Après  le  début  du  checkpoint  lancé  par  le  DBA,  aucune  autre  nouvelle  transaction  ne  peut 
démarrer. 
2‐  Les  transactions  actives  ne  sont  ni  arrêtées,  ni  en  attente,  mais  elles  ne  peuvent  plus 
temporairement  effectuer  des  modifications  sur  la  base. Lʹexécution  dʹune  transaction  est  donc 
interrompue momentanément. 
Checkpoint

Panne

T1

T2

T3

T4

temps

Figure 2.23
 
3‐  Les entrées du journal JI sont copiées dans le JE et toutes les pages de données modifiées de la 
ZMP sont aussi écrites sur disque pour en assurer la persistance. 
 
4‐  À  la  fin  du  checkpoint,  une  entrée  spéciale  est  faite  dans  le  JE  pour  y  inclure  la  liste  des 
transactions  actives (TA)  au début de la procédure de checkpoint. 
Recouvrement   
La procédure de recouvrement débute par un ROLLBACK des transactions actives (TA) suivie
par un ROLL FORWARD des transactions actives non validées. Les entrées du journal
fournissent pour chaque donnée, la valeur avant (AV) et la valeur après (AP) :

1‐  Le journal est lu dans le lʹordre inverse pour détecter le plus récent checkpoint et obtenir la 
liste des transactions actives (TA). 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 61

2‐  Au  cours  de  cette  lecture  à  rebours  des  entrées  du  JE,  les  transactions  validées  rencontrées 
sont notées dans une nouvelle liste temporaire TV. 
3‐  Lorsque la lecture du JE atteint le CHECKPOINT, la liste TA est alors modifiée pour y enlever 
les transactions validées. 
4‐  Toutes  les  transactions  sont  défaites  par  un  ROLLBACK.  Ce  retour  en  arrière  peut  aller  en 
amont du checkpoint et sʹarrête avec le début de la plus ancienne transaction parmi celles de 
la liste TA. 
5‐  Il  faut  refaire  les  transactions  de  la  liste  TV  à  partir  du  checkpoint  et  cela,  en  ordre 
chronologique.  

Voici un cas simple illustrant cette procédure de checkpoint avec cohérence des données :

Traitements Entrée dans le JI Sémantique :


T1: début 18:00;T1;D début de T1
T1: lire X -> 50
T1: écrire X-> 60 18:01;T1;E;X,50,60;
T1: Commit 18:02;T1;COMMIT; fin de T1 et JI-> JE et
TA vide
T2: début 18:03;T2;D; début de T2
T2: lire Z-> 5
T3: début 18:06;T3;D; début de T3
T3: lire G -> 20
T2: écrire Z->8 18:07;T2;E;Z,5,8;
T4: début 18:09;T4;D; début de T4
T4: lire M-> 100
CKPT <--- 18:12;CKPT; tr.actives: T2, T3, T4
T3: écrire G -> 25 18:14;T3;E;G,20,25;
T3: Commit 18:15;T3;COMMIT; fin de T3 et JI -> JE
T4: lire G->25
T4: écrire G->35 18:16;T4;E;G,25,35;
** panne ** panne : T2,T4 actives

D : début CKPT : checkpoint


E : écrire TA : liste des transactions actives
S : supprimer

Les entrées du journal externe (JE) sont les suivantes :

Entrées du JE phase ROLLBACK(1) phase ROLL FORWARD(2)


18:00;t1-D TA : vide
18:01;T1;E;X,50,60;
18:02;T1;COMMIT;
18:03;T2;D;**
18:06;T3;D;** Début avec T3
18:07;T2;E;Z,5,8;** T2: défaire Z->5
18:09;T4;D;** TA - TV = ( T2, T4)
18:12;CKPT;(T2,T3,T4) TA : T2, T3, T4
18:14;T3;E;G,20,25; T3: refaire G-> 25
18:15;T3;COMMIT; TV: T3 TV : T3
(début du rollback) (début du rollback) (début du roll forward)

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 62

Pour la procédure du ROLL FORWARD, il suffit, à partir du checkpoint, de refaire les


transactions de la liste TV établie lors du rollback. Le retour en arrière est prolongé au delà du
point de reprise pour défaire ainsi la transaction active la plus ancienne au moment du
lancement du checkpoint. Cette procédure de point de reprise n'arrête pas les traitements locaux
des applications. Si le recouvrement est fait avec un journal léger, le temps de reprise pourrait
être à peine perceptible par les utilisateurs des applications.

Avec l'une ou l'autre des deux procédures, une panne d'instance ou d'application peut être
traitée sans l'intervention du DBA. Il en sera autrement pour une panne de média comme un
disque. Dans ce cas, le DBA aura un rôle important dans la procédure de recouvrement pour
identifier la copie de sécurité à réutiliser pour reconstruire la partie de la base qui était sur le
disque en panne.

2.5 Architecture client/serveur 
L'architecture client/serveur (10) est un environnement qui localise les traitements de
l'application sur les données du côté des utilisateurs. Cette architecture vient donc enrichir le
fonctionnement général du SGBD en ajoutant des fonctions de traitement au niveau du client
qui travaille désormais en coopération avec les fonctionnalités du SGBD. Le serveur offre, pour
l’essentiel, les mêmes fonctionnalités que celles implémentées sur une machine centrale à savoir
le traitement et l'exécution des ordres DML..

Temps de réponse
architecture
architecture client-
centralisée
serveur

Avec le même CPU

Nombre d'utilisateurs
Figure 2.24
La répartition du traitement, et éventuellement des données, tend à maintenir la performance
totale même lorsque le nombre de clients augmente. Le point d'inflexion dans la décroissance de
la performance (figure 2.24) est reporté vers la droite par rapport à une configuration de
traitement centralisé.

Avec une approche centralisée, l’augmentation du nombre des terminaux se traduit à partir d'un
certain point par une baisse de performance qui peut être compensée par le remplacement de la
machine par une autre plus puissante ou par une deuxième machine centrale

Une deuxième machine centrale apporte cependant sa propre charge au niveau de la gestion des
processus qui annule en partie les effets escomptés au niveau de la performance générale pour
les clients. Le traitement est cependant toujours effectué au niveau de la machine centrale.
L'architecture client/serveur permet de maintenir plus facilement le niveau de performance en

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 63

dépit de l'augmentation de la charge générale parce que les traitements sont transférés vers les
clients. Le protocole de communication entre les machines du réseau est organisé en couches
autonomes. Il devient donc possible de concevoir la communication simplement comme un
échange entre deux couches de même niveau. Ceci permet de masquer toute modification des
couches inférieures aux autres couches de l'architecture.

Le modèle OSI favorise l’interopérabilité des systèmes en isolant les caractéristiques des diverses
technologies dans des couches spécifiques et en normalisant les interfaces entre celles-ci. Ce
modèle normalisé par l’ISO (figure 2.25)

Site 1 Site 2

Application (7) Application (7) Désassemblage de la structure


du message reçu

Présentation (6) Présentation (6) Encodage spécifique

Session (5) Session (5) Échange de transactions

Protocole de transport

Transport (4) Transport (4) Échange de messages ou fichiers


circuit virtuel (connecté)

Échange de paquets
Réseau (3) Réseau (3)

Liaison (2) Liaison (2) Échange de trames

Physique (1) Physique (1) Échange des impulsions

Figure 2.25
se généralise chez les constructeurs et facilite grandement l’intégration des ressources
informatiques du monde entier. Il est une des pierres d’assise des inforoutes qui visent à mailler
la planète avec des nœuds de communication implémentés par des ordinateurs très divers et
utilisant des environnements fort variés.

Une configuration en réseau relie les stations par un bus Ethernet utilisant un lien de
communication rapide. Ce lien permet des vitesses de l'ordre de 100 mégabits par seconde. Ce
type de réseau est diffusant (broadcasting) et donc fait référence à une technologie multipoint.
Chaque machine reçoit les messages, mais ne retient que ceux qui la concerne. Ce type de
configuration est conforme au modèle ISO/OSI.

À titre de rappel, voici les fonctions générales des différentes couches du modèle OSI :

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 64

Couche physique  (1) 
La couche physique transmet des bits sur le canal physique de transmission conformément à un
standard reconnu (Exemples : RS-232C, RS-449). A ce niveau, la technologie utilisée prend à sa
charge la transmission des impulsions électriques ou photoniques, la gestion des pertes de
signaux et les reprises inévitables. La couche gère le protocole utilisé pour la transmission
physique des bits.
Couche liaison de données (data link) (2) 
Le paquet d'octets reçu de la couche 3 est divisé en trames (frames). Chaque trame est complétée
par une adresse d’origine et une adresse de destination et elle est encadrée par des marqueurs
de début et de fin. Ce travail d'établissement de la liaison est réalisé par deux sous-couches : la
sous-couche MAC pour s’assurer, par une écoute, que le réseau est libre et, au besoin, gérer les
collisions, et la sous-couche LLC pour réguler le flux de transmission des trames et vérifier que
la réception d’une trame soit sans parasite. Au besoin, la retransmission des trames est assurée
par le LLC. En mode réception, les opérations inverses sont effectuées.
Couche réseau (3) 
La couche réseau achemine les paquets obtenus par division du message reçu de la couche 4
vers un noeud du même réseau, incluant la passerelle. A l'inverse, les trames par la couche data
link sont regroupées en paquets. Le rôle principal de cette couche est d'établir le routage
(routing) selon un algorithme parmi les suivants : prédéterminé, calculé, par répertoire statique,
par répertoire dynamique ou routage adapté. Dans un réseau commuté de lignes (ex. service
avec connexion), le chemin complet de la source à la destination est déterminé et figé pour toute
la session (Dans le cas d'un incident, un nouveau chemin est établi par reconfiguration du
routage) . Cette approche connectée est souvent utilisé par les grands réseaux où le trafic justifie
la monopolisation des circuits. La couche réseau mise au point dans le réseau ARPANET ,
appelée protocole Internet (IP), utilise une approche connectée. Dans cette couche, il y a
contrôle de flux (avec lecture/écriture bloquantes).

Par contre, dans un réseau commuté non connecté et par paquet (ou datagrammes), le chemin
est déterminé pour chaque paquet de données (approche sans connexion). Le circuit virtuel est
refait à chaque transmission d'un paquet. Cette couche prend donc à sa charge la conversion
d'adresses et le routage entre réseaux. Dans un réseau de diffusion comme celui de l'Ethernet,
toutes les trames sont diffusées et le rôle de cette couche réseau est plutôt limité.
Couche transport (4) 
La couche transport communique des messages (en provenanc de la couche 5) entre deux
nœuds en utilisant, pour les couches inférieures, la technologie propre au réseau sur lequel sont
connectées les machines source et cible. Pour ce faire, le message est divisé en paquets (packets)
qui sont réassemblés à destination par la machine réceptrice pour reconstituer le message
d'origine. C’est la couche TCP de ARPANET (Transport Control Protocol). Cette couche est
généralement utilisée en conjonction avec le protocole IP pour obtenir le protocole appelé
TCP/IP. Cette couche prend la relève de l'écriture des octets dans une socket de l'OS, pour
générer plusieurs appels de transport sur le réseau. Ces opérations sont effectuées par le logiciel
TCP/IP et sont donc masquées à l'application.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 65

Couche session (5)


La couche session gère l'échange intensif et bi-directionnel entre deux applications. Ce qui est
échangé est une transaction composée de données en volume plus ou moins grand selon la
nature de l'application. C'est le cas typique des divers services aux utilisateurs, notamment la
connexion à distance (remote login), le transfert de fichier (ftp), le Telnet, le Gopher et le fureteur
du web (browser). Ces utilitaires sont développés en utilisant les procédures d'interface de la
couche session dont les paramètres réfèrent à la notion de transactions. Par exemple, la
transaction avec ftp est une transaction longue constituée avec les données du fichier.
Couche présentation (6) 
Cette couche présente l’information transmise après transcodage approprié (Unicode vers ASCII
vers EBCDIC ou vers ISO Latin-1), suivi du déchiffrement et du décompactage des données des
transactions. La couche aura aussi un rôle important lorsque l'usage de l'UNICODE sera
répandu ou deviendra un standard de facto (les caractères Unicode sont codés sur 16 bits).
Couche application  (7) 
La couche application traite les protocoles particuliers comme la messagerie électronique, le
protocole d’échange des données de laboratoire HL-7 (11) l’échange des données commerciales
EDI et bientôt le commerce électronique. Ces protocoles définissent la structure des messages
échangés en associant une sémantique à chaque champ ou élément du message. Entre deux
stations, l'échange est réalisé par un circuit virtuel en ce sens qu'il s'appuie sur les
fonctionnalités des couches inférieures.
Vue schématique du protocole IP 
Par définition, un protocole désigne un ensemble bien défini de règles et de conventions pour 
assurer la communication entre deux logiciels en exécution. Le protocole IP comporte une trame 
universelle (couche liaison) qui est indépendante des technologies des divers réseaux.

message 1
message 2 paquet 1 Suite de bits
… paquet 2 trame 1 transformée
message i … trame 2 en impulsions
paquet j trame 3
Transaction

Éclatement d'un message lors de l'échange entre deux ordinateurs Figure 2.25a
Structure dʹune trame technologique (frame) 
Les données structurées échangées entre deux points identifiés du réseau au moyen du
protocole de liaison de données (data link) sont représentées par une trame contigue de bits.
Cette trame est encapsulée conformément au protocole Internet. Le schéma général de la trame
est donné ci-dessous.

en-tête de trame IPsource IP cible données de la trame Internet

Figure 2.25b

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 66

La trame technologique est transmise d'une adresse IP source à une adresse IP cible (la
destination). Chaque adresse IP ( appartenant à une des classes A, B, C) comporte une partie
client (machine) et une partie réseau. Selon la classe de l'adresse (identifiée par les deux
premiers bits), le nombre de bits alloués pour coder le réseau et la machine varie. Il devient
possible de représenter quelques réseaux et de nombreuses machines jusqu'au cas de figure
composé d'un grand nombre de réseaux et d'un petit nombre de machines.

Cette trame de données peut être transmise à travers les réseaux hétérogènes à la condition
qu'un GATEWAY puisse prendre en charge la transposition successive du format de la trame
technologique d'origine vers celui des destinations du réseau auquel est connecté le GATEWAY.
Chaque adresse dans une trame comporte deux parties spécifiées sur 32 bits : partie numéro du
réseau et partie numéro de machine. Par contre, si le lien se fait entre deux réseaux de même
nature, un BRIDGE ou un ROUTER (avec plus d'intelligence) est utilisé pour acheminer les
paquets. Lorsque qu'une trame est destinée à une site au sein d'un même réseau, la couche IP du
logiciel de télécommunication de la station demande à toutes les machines de ce réseau de faire
connaître leur adresse physique (adresse de liaison). Une fois l'adresse physique connue et
'cachée' par la station émettrice, le message est transmis en utilisant la trame propre au réseau
permettant ainsi de l'acheminer directement sans autre transposition. Si un message doit être
transmis à une adresse IP hors du réseau d'origine, il est alors transmis en premier à sa
passerelle (gateway) qui l'encapsule avec une trame technologique adéquate avant de l'acheminer
à la passerelle ou au router suivant, dit de proximité.
segment réseau 1
50 ohms
réseau 2 (autre
répéteur gateway1 technologie)
transceiver

Router 2

machine 1
machine 2 réseau 3

Schéma général d’un réseau incluant différentes technologies


Figure 2.25c
Sur réception de la trame par la passerelle suivante, celle-ci peut détecter si le message est arrivé
au réseau de destination ou s'il doit être relayé à une autre passerelle. Les passerelles sont de
véritables ordinateurs, donc des nœuds essentiels dans un réseau de communication à grande
vitesse. Leur vitesse est critique, notamment lorsqu'il s'agit de réseaux ATM ou à bande large.

Présentement, les vitesses de communication courantes sont de l'ordre de 100 mégabits par
seconde. Une nouvelle technologie de Nortel-Canada (OC-192) offre des possibilités encore plus
grande, soit de l'ordre du 10 gigabits par seconde. La technologie des communications se
développe donc avec une vitesse effarante. Il est question de vitesse frôlant les Pétabits par
seconde, soit un quadrillion de bits par seconde. Avec de telles vitesses, la téléphonie et la

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 67

télévision Internet sont maintenant des réalités. Il ne peut pas y avoir plus de 2.5 km entre deux
points de segments différents sans faire intervenir un répétiteur. Le protocole IP est nécessaire
puisque le transfert de la machine 1 à la machine 2 est effectué à travers des réseaux de
technologie différente.
Fonctions générales du client dans lʹexploitation dʹune base de données 
La station cliente a une certaine puissance de traitement qui est mise à contribution pour des
opérations locales (12 ):

a) Gestion  de  l’interface  et  du  traitement  local  des  données  transmises  par  le  serveur.  La 
puissance de traitement local est alors exploitée adéquatement. 
 
b) Le  client  transmet  chaque  requête  (ordre  DML)  au  serveur  pour  des  fins  d’analyse  et 
d’exécution.  
 
c) Les  fonctions  d’un  client  sont  exécutées  sur  un  ordinateur  qui  est  différent  de  celui  du 
serveur  et  plus  adapté  aux  besoins  locaux  tout  en  assurant  une  meilleure  extensibilité  de 
l’architecture (scalabitlity).  
 
2.6 SGBD ORACLE 
Le SGBD Oracle a une architecture générale constituée d'un ensemble de processus (tâches) et
de structures de données complexes gérées en mémoire. Ces ressources partagées permettent
l'accès concurrent aux données de la base avec une bonne performance pour le service aux
clients. La mémoire partagée utilisée par le SGBD ORACLE est représentée sommairement par
les entités SGA (System Global Area) et PGA (Program Global Area). L'espace PGA est utilisé par le
serveur pour y loger les données propres à l'état de chaque processus client en cours de
traitement. Le SGA est accessible à tous les processus de l'instance ORACLE. Cet espace doit
être le plus grand possible (>500Mo) et comprend plusieurs zones structurées en listes de pages :

a)La zone des pages de données et des pages temporaires pour loger les résultats intermédiaires. 
 
b)  La zone des pages du journal interne (redo log buffers). 
                                                                                                

LGWR
Serveur de
station processus
client Dx (Accesseur)
réseau

Serveur de DBWR
processus
Dx : processus créé pour gérer les (Accesseur)
échanges avec le client.

Figure 2.30
 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 68

c) La zone contenant les packages et les triggers, sous forme de code exécutable et optimisé. Un  
package est chargé lors du premier appel d’une de ses procédures.  
 
d)  La  zone  des  pages  pour  les  données  privées  des  applications  dites  PGA.  Par  exemple,  les 
constantes d’un ordre DML sont stockées dans une zone PGA privée qui est associée au curseur, 
tandis que l’ordre DML source et son plan dʹexécution sont placés dans un autre espace du SGA 
et dont lʹadresse est placée dans le  curseur. Le curseur d’un ordre contient le nom de cet espace 
dans le SGA. 
Coopération entre les processus du SGBD Oracle en mode multithreading ( MTS) 

Le système Oracle utilise deux catégories de processus, qualifiés respectivement d’utilisateur et


de système. La première est créée lors d’une connexion établie avec le SGBD et cela à travers un
réseau.
Cette connexion est concrétisée, dans le cas d'une configuration avec des Exécuteurs partagés,
par la création d'un processus Dx, créé du côté du serveur et particulier à un protocole de réseau
(figure 2.30), dont le rôle est de voir aux échanges avec les clients incluant celui d'acheminer
l’ordre DML au serveur de processus (SP). C'est aussi le processus Dx qui retourne la réponse à
l'utilisateur. Ces processus Dx jouent en quelque sorte le rôle du client du côté du serveur. Si la
connexion entre le serveur de processus et le client est rompue, alors le module Dx pour ce client
devient orphelin et le module du SGBD chargé de libérer les ressources (PMON) pourra
identifier le processus orphelin et le supprimer. Normalement, la connexion reste ouverte et
active tant que l’application n’exécute pas un CLOSE (bd). Cette façon de faire est différente du
WEB dont la communication est ouverte et fermée pour chaque requête GET ou POST.

La deuxième catégorie comprend plusieurs processus qui coopèrent pour effectuer le calcul de
la réponse de la requête :DBWR, LGWR, CKPT, SMON, PMON, ARCH, Dx et LCKx. Ces
modules sont associés à un même processus Parent, soit celui correspondant au compte SYS.
Nous discuterons brièvement du rôle de chacun.
Serveur de processus  (SP)  
Ce serveur-logiciel est chargé de la communication avec les utilisateurs représentés au niveau
du serveur par les processus Dxxx. C'est essentiellement un serveur multi-threads de requêtes en
provenance des clients. Ce serveur-logiciel spécialisé est chargé de traduire l’ordre DML, de
créer l’espace curseur privé et public pour loger les tuples de la réponse, de demander la lecture
des pages de la BD au DBWR. Il a accès au SGA pour extraire les tuples et construire
graduellement la réponse. Le client communique avec le SP via un ordre FETCH pour obtenir
un ou plusieurs tuples placés au préalable dans un curseur. Généralement, la communication est
maintenue jusqu'à la fermeture explicite de la connexion par le client.

Instance du noyau du SGBD Oracle


La notion d’instance Oracle est associée aux processus du logiciel et non à la base de données.
Le couplage entre l'instance et la base donne lieu à un système de BD. Au démarrage du SGBD,
un espace SGA est alloué et les processus d'arrière-plan sont lancés.

 
 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 69

page page page ZMP


i 1+ 1 1+2

Sur requête d'un autre module (ex. le DBWR


SP)
fichiers

Figure 2.31 
Cette combinaison espace mémoire et processus, appelée instance, est identifiée par un suffixe
fourni par la variable système SID ou par le nom de la base de données rangé dans le fichier de
paramètres INITsid.ORA. Dans un environnement réparti, chaque instance doit avoir un
identificateur unique.  
 
 
page page page
i i+ 1 i+2
Journal externe
no 1

LGWR

ARCH

Fichier Journal externe


archive no 2

En cas de saturation, réécriture circulaire dans le JE

Figure 2.33
Une même base de données peut être rendue accessible à plusieurs instances, mais une instance 
n’a  accès  qu’à  une  seule  base  de  données  à  la  fois.  Les  techniques  d’implémentation  peuvent 
changer selon les versions afin de tirer profit des nouvelles architectures matérielles disponibles. 
Récemment,  la  commercialisation  des  serveurs  multiprocesseurs  a  permis  de  mieux  exploiter 
lʹarchitecture  multiserveur  du  SGBD,  qui  peuvent  utiliser  le  parallélisme  dans  le  calcul  des 
requêtes et offrir de meilleures performances.   
                
Les processus du SGBD Oracle exécutés en arrière-plan constituent l'instance du SGBD :

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 70

DBWR (Database Writer) Ce processus effectue la lecture et lʹécriture des pages dans le SGA. Lors 
dʹune  recherche  amorcée  par  le  serveur  de  processus  (SP),  un  premier  accès  au  dictionnaire 
fournit  lʹadresse  de  la  première  page  de  chaque  table  et  de  chaque  index  disponible  pour  le 
calcul.  
A partir de ces index, lʹaccès aux pages de données est possible par la fonction INPUT(no‐page). 
La  recherche  dʹun  emplacement  pour  lʹinsertion  dʹune  page  de  données  dans  le  SGA  par 
lʹAccesseur débute par le parcours de la liste LRU sur une certaine longueur (lw) après quoi, le 
DBWR  évacue  les  pages  DIRTY  pour  obtenir  lʹespace  nécessaire.  La  longueur  de  la  liste  à 
parcourir  est  déterminée  par  un  paramètre  système  initialisé  dans  le  fichier  ORA.INIT.  
L’écriture dʹune page modifiée sur disque peut être nécessaire lorsque l’espace manque dans le 
SGA. Lʹopération peut se dérouler selon une politique LRU de remplacement des pages. 
 
Après  la  validation  d’une  transaction  (par  lʹordre  COMMIT)  les  pages  modifiées  ne  sont  pas 
écrites  immédiatement  sur  disque,  tandis  que  les  entrées  du  journal  de  la  transaction  validée 
sont  transférées    obligatoirement  sur  disque  externe  par  le  module  LGWR.  Lors  de  la  création 
dʹune table il est possible de spécifier que chaque page lue de la table soit plutôt placée dans la 
partie  LRU  de  la  liste  des  pages  (option  CACHE  de  lʹordre  CREATE  TABLE).  Ce  placement 
favorise les balayages séquentiels successifs dʹune même table.  
 
Lʹécriture des pages sur disque par le DBWR est lancée sur les événements suivants : 
 
a‐ Activation dʹun checkpoint par le DBA ou par le changement du journal; 
b‐ La liste des pages modifiées présentes dans le SGA devient saturée; 
c‐ La recherche infructueuse dʹune page disponible pour une évacuation, i.e. marquée r; 
d‐ d-Un time‐out de x sec dʹinactivité du DBWR, i.e. au terme duquel  le DBWR ( ex::  x = 3 sec) 
amorcera lʹécriture des pages validées. 

2‐ Le processus de journalisation, le LGWR (Log Writer) voit à transférer les entrées du journal 
interne  appartement  à  une  transaction  sur  le  disque  renfermant  le  journal  externe  (JE).  Cette 
écriture est faite lors de la validation d’une transaction ou si l’espace du SGA alloué au journal 
interne vient à manquer. Lors dʹune validation transactionnelle, seules les entrées de celle‐ci sont 
écrites sur le journal externe. 

3‐ CKPT (Checkpoint) À des intervalles réguliers ou lors de la saturation dʹun journal externe ou 
lors de la bascule vers le deuxième journal externe, le contenu du SGA est écrit sur disque,  ce 
qui  assure  que  les  pages  les  plus  actives  (MRU)  finissent  par  y  être  placées.  En  effet,  avec  une 
politique LRU, ces pages MRU pourraient demeurer indéfiniment dans le SGA. Pour éviter cette 
situation, le module CKPT signale au DBWR de vidanger périodiquement la liste LRU du SGA. 
Lors  de  cette  opération,  une  estampille  est  écrite  dans  le  journal  externe  et  dans  lʹen‐tête  des 
fichiers modifiés suite à lʹécriture des pages transférées. Le module de checkpoint permet donc 
de  vidanger  toute  la  zone  ZMP  des  données  validées  afin  dʹobtenir  une  base  de  données 
cohérente.  

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 71

 
  page i page page page JI
i+ 1 i+2 …
 
 
 
CKPT
 
 
 
fichiers fichiers
 
 
 
Figure 2.34 
 
4‐ SMON (System Monitor) et le recouvrement transactionnel. Processus chargé de recouvrer une 
instance Oracle au moment du démarrage par récupération et libération des segments (espaces) 
temporaires  et  les  ressources  du  système  OS  .  Cʹest  aussi  le  module  chargé  de  faire  la  reprise 
dʹune transaction avortée et cela à partir des segments de reprise (ROLLBACK SEGMENT). Lors 
de  périodes  de  faibles  activités,  SMON  réorganise  lʹespace  des  tablespaces  en  défragmentant 
celui‐ci pour créer des extents de plus grande taille.  
 
5  ‐PMON  (Process  Monitor)  Processus  chargé  de  surveiller  les  divers  autres  processus  (du 
système  et  des  usagers)  et  en  cas  dʹarrêt,  de  libérer  les  ressources  acquises  et,  au  besoin,  les 
relancer.  Si  une  application‐client  est  annulée,  le  module  PMON  est  capable  de  détecter  la 
disparition  dʹun  usager  (processus  orphelin)  via  celle  du  processus  Dxxx  et  dʹeffectuer  un 
rollback de la transaction en cours qui appartiendrait à ce client. 
 
6‐ ARCH (Archiver) Processus chargé de copier le journal externe saturé vers un espace disque 
d’archivage. Cʹest la seule façon de garantir la base contre toute défaillance du média du journal 
externe  ou  dʹassurer  la  garde  des  pages  du  journal  externe,  qui  seraient  écrasées  par  la 
réutilisation cyclique de lʹespace du journal externe ( JE). 
 
7‐ Dx (Dispatcher) Ce processus léger est créé lors de l’établissement de la communication d’un 
client  avec  le  serveur  de  processus  non  dédié  (SP).  Il  y  aura  autant  de  Dx  que  de  stations 
connectées. Ce processus est chargé d’acheminer les ordres DML reçus de la station vers le SP et 
de retourner la réponse calculée par le serveur SP. 
Journalisation et segment de recouvrement 
Lorsqu’un ordre DML d’une transaction est exécuté, les modifications qu’il effectue peuvent
être d’abord placées dans un segment de rollback du SGA (image avant seulement). La
modification est aussi placée dans un journal interne (JI) qui enregistre toutes les modifications
faites par la transaction (images AV et AP) ainsi que celles des autres transactions. Si l’ordre
DML ne peut pas être complété correctement ou si l'utilisateur effectue volontairement un
retour en arrière (Rollback), le retour en arrière se fait à partir de ces segments de reprise
(segment Rollback) piloté par le processus SMON. C'est ainsi que le système garantit l’atomicité

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 72

de chaque ordre DML. Ce retour est plus rapide parce que les segments de rollback d'une
transaction ne contiennent que les modifications d'une transaction.
Fichiers de contrôle 
L'instance SGBD utilise deux fichiers de contrôle pour accéder aux différents espaces de données
critiques gérés par le noyau SGBD. Au lancement, l'instance n'a pas accès au dictionnaire, car
elle ne connaît pas l'emplacement physique de la métabase (dictionnaire). C'est grâce aux
fichiers de contrôle que le SGBD peut connaître la localisation physique des divers fichiers,
notamment ceux du dictionnaire et des journaux de recouvrement. Tout changement aux
ressources physiques de la base de données comme l'ajout d'un fichier, est noté dans le fichier de
contrôle par le SGBD. Ces fichiers de contrôle sont essentiels pour lancer et réussir une
opération de reprise et ils sont répliqués sur plusieurs disques et tous sont maintenus à jour
automatiquement par le SGBD.
2.7 Performance des logiciels SGBD 
La mesure de la performance du traitement des transactions par un SGBD (en mode OLTP) est
complexe en raison des nombreux échanges qui interviennent entre les processus et des diverses
technologies qui sont mises en oeuvre dans l'implémentation d'un tel logiciel. Avec une telle
complexité, il devient pratiquement impossible d'évaluer la performance du logiciel par la seule
analyse des différentes techniques mises en oeuvre. Il faut faire appel aux bancs d'essai. Ces
mesures empiriques sont significatives dans la mesure où les bancs d'essai ont des structures
équivalentes, qu'un même protocole de test est utilisé et que l'environnement matériel est
comparable.

Pour les bases de données relationnelles, le groupe Transaction Processing Performance Council
(composé de près de 40 sociétés et institutions, TPC) a élaboré un banc d'essai connu sous le
nom de TPC-A destiné à mesurer la performance des SGBD relationnels (OLTP) capables de
fournir un rendement de l'ordre de 100 transactions par seconde (TPS). Les résultats de ces
mesures sont publiées et doivent être utilisés selon un code d'éthique formulé par les membres
du TPC. En effet, la concurrence entre les manufacturiers de SGBD est telle que les résultats du
TPC-A peuvent devenir un argument de vente pour gagner de nouveaux marchés. Les écarts de
conduites sont dénoncés et les délinquants parfois sanctionnés par des rappels à l'ordre
(sanction en 3 étapes) et éventuellement par des pénalités financières.
Structure de la base de données du test TPC‐A 
La base de données est composée de 4 tables relationnelles exploitées par un grand nombre de 
transactions (1000) concurrentes dont chacune comprend 3 mises à jour et une insertion. Voici la 
composition de la base de données et de la transaction type utilisée pour les mesures.   
 
Table nb tuples taille du tuple clé primaire
Compte 1 000 000 100 octets noCompte
Guichet 1000 100 octets noGuichet
Succursale 100 100 octets noSuc
Journal variable 50 octets noCompte, estampille
 
Figure 2.35 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 73

Transaction type
La transaction ci-dessous est exécutée sans erreur par 1000 transactions concurrentes :
Les valeurs lues par les transactions ont été générées aléatoirement de sorte que la probabilité de
mise à jour d'un tuple quelconque soit constante pour le test.

/* read au guichet no-cpt, noSuc, noGuic, montant */


Set Transaction READ WRITE—début de la transaction
UPDATE Compte set solde = solde + montant
WHERE no-compte = noCpt
INSERT into Journal values
(noCpt, noGuichet, noSuc, montant, estampille
UPDATE Guichet set Guichet.solde = Guichet.solde + montant
UPDATE Succursale set Succursale.solde = Succursale.solde + montant
COMMIT
/* write 200 octets au guichet */

Contraintes opérationnelles 
Le temps d'un cycle (TC) est composé du temps de réponse (TR) plus le temps de réflexion de
l'utilisateur (TU).
‐‐‐      TC = TR + TU 
Le TC doit être en moyenne d'environ 10 sec. En outre, 90% des transactions doivent avoir un
TR <= 2 sec, et le TU en moyenne égale ou plus grand que 8 sec. Voici un exemple de résultats
du banc d'essai TPC-A pour quelques SGBD relationnel.

SGBD Matériel TPS Coût/TPS $ date


ORACLE7 Vax cluster 425 16 326 5-92
Unify 2000 Pyramid Server 468 5 971 3-92
Informix 4.1.0 IBM RISC 6000/970 110 2789 7-92
SYBASE Symmetry 2000/250 173 2770 3-92

La mesure de la performance est exprimée par le nombre de transactions par seconde (TPS) qui
traduit une puissance transactionnelle brute sans égard aux coûts du matériel. Le facteur coût
regroupe les investissements, notamment pour la machine et les disques.
Il existe une certaine relation proportionnelle entre le TPS et le ratio Coût/TPS. L'augmentation
de la performance TPS entraîne celle du coût par transaction. Ainsi, un même SGBD pourrait
avoir une performance bonifiée avec un facteur Coût/TPS. Pour un même ratio coût/TPS, les
différences de rendement peuvent être dues à l'implémentation des fonctionnalités du SGBD ou
à la configuration matérielle utilisée.
Évolution des bancs dʹessai du TPC 
Les bancs TPC-A et TPC-B ont été abandonnés en décembre 95 et remplacés par le TPC-C et
TPC-E. Le TPC-D a été développé pour mesurer la performance relative des SGBD relationnels
en mode décisionnel (Data Warehouse ou Entrepôt de données) et cela pour des tailles de base
de données différentes (scaling factor).

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 74

TPC-D Paramètres @100GB IBM DB2 Teradata delta


Throughput 207 217 5%
QphD 133 192 44%
prix/QphD 33 640 28 272 16%

De nouveaux paramètres sont utilisés (ex.: QphD@100GB, Query per hour qui est calculé en
utilisant une moyenne géométrique) et un nouvel ensemble de questions et de transactions a été
formulé. On peut consulter les résultats des tests en consultant le site http: //www.tpc.org/.
Sommaire
L’évolution des modèles gérés par les SGBD renforce l’indépendance logique et physique des
applications et des données. L’importance grandissante des architectures client/serveur modifie
la répartition des tâches de traitement en laissant une plus grande place au site client qui pourra
maintenant mettre à profit sa capacité locale de traitement et de stockage. En dépit de ce
changement d’architecture, le rôle critique dans la gestion des données est toujours assuré par
un processeur principal appelé le serveur qui doit gérer adéquatement le multitâche
incontournable, l’entrelacement de données (multithreading) devenu essentiel, l’écoute du réseau,
synchroniser des actions sur la base de données et assurer la transmission des résultats vers le
client.

En allégeant la charge du SGBD par l'approche client/serveur, on obtient un gain intéressant


dans le rapport performance/prix. Toutefois, cette approche engendre de nouvelles activités à
savoir une gestion de réseau et une autre pour la base de données qui deviennent plus
importantes lorsque les clients sont distants.

Le serveur multiprocesseur augmentera la puissance nette des traitements en divisant la tâche et 
en  la  répartissant  parmi  deux  ou  quatre  processeurs.  Avec  de  bons  algorithmes  de 
synchronisation  des  traitements  parallèles,  des  mémoires  RAM  et  cache  de  taille  inégalée 
jusqu’ici  et  des  disques  RAID,    les  nouveaux  serveurs  s’attaquent  au  défi  d’atteindre  des 
performances transactionnelles de l’ordre de plus de 800 TPS (voire même 1000 TPS). Ce niveau 
de performance exigeant une fraction de l’investissement jusqu’ici nécessaire pour  les machines 
centrales  de  grande  puissance.  L’ère  des  base  de  données  sur  les  grosses  machines  n’est  pas 
nécessairement  terminée,  mais  son  marché  a  été  modifié  considérablement  et  ramené 
principalement  aux  bases  de  données  de  très  grande  taille  pour  des  applications  dont  les 
contraintes  temporelles  et  la  charge  de  traitement  imposées  dépassent  encore  de  beaucoup  le 
potentiel  des  stations  de  travail.  Lʹévolution  de  la  technologie  viendra  encore  certainement 
modifier ces configurations.   

Exercices
 
1‐  Supposez  que  la  contrainte  ci‐dessous  soit  définie  sur  la  base  de  données.  Identifiez  les 
transactions  qui  se  termineront    toujours  correctement  et  celles  qui  peuvent  se  terminer 
incorrectement en entourant le commit dʹune transaction qui se termine correctement. Justifiez 
chaque réponse pour chaque transaction. Les transactions débutent et se terminent dans lʹordre 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 75

croissant de leur numéro : T1< T2 < T3. Une transaction est  exécutée entièrement avant que la 
suivante débute.  
 
La contrainte définie sur les données :   0 < X < Y. Au début la base de données est cohérente. 

set transaction t1 set transaction T2 set transaction t3


lire X lire X lire X
lire Y lire Y lire Y
X=X+Y X=Y+1 Y=X+Y
update X update X update Y
Y=X+Y Y=X+1 X=X+Y
update Y update Y update X
commit commit commit

2‐ Complétez  le  journal  interne  ci‐dessous  pour  lʹexécution  de  la  transaction  t4.  Chaque 
SAVEPOINT  donne  lieu  à  une  entrée  SVPT  dans  le  JI  et  chaque  ROLLBACK  à  un  ou 
plusieurs changements sur la BD. La valeur initiale de X est 5 et celle de Y est 7. 
 
Transaction sur client Journal - Interne
ordre-DML AV AP
set transaction t4
lire X
lire Y
X=X+Y
SAVEPOINT S1
update X
ROLLBACK TO S1
Y=X+Y
update Y
commit

Références Chapitre 2

1 CODD, E. F., Data Models in Database Management, Proceedings Workshop on Data Abstraction, 
Databases and Conceptual Modeling, ACM SIGMOD v. 11, no 2, 1981. 
2  GARZOTTO,  F.,  PAOLINI,  P.,  SCHWABE,  D.,  HDM:  A  model‐based  approach  to  hypertext 
application design , ACM Transactions of Office Information System, v. 11, no 1, 1993, p. 1‐26. 
3 HALASZ, F. G., SCHWARTZ, M., The DEXTER hypertext reference model, Communications of 
the ACM, v. 37, no 2, 1994, p. 30‐39.  
4  SCHNASE,  J.  L.,  LEGGETT,  J.  J.,  HICKS,  D.  L.,  SZABO,  D.  L.,  Semantic  data  modeling  of 
hypermedia associations , ACM Transactions of Information System, v. 11, no 1, 1993, p. 27‐50.  
5  STOTTS,  P.  D.,  FURUTA,  R.,  Programmable  Browsing  Semantics  in  TREILLIS,  In  Hypertext 
ʹ89 Proceedings, ACM Press, NY, 1989, p. 27‐42. 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 2 Architecture fonctionnelle du SGBD 76

6 GAMACHE, A., Base de données réseau VAX/DBMS, Librairie des Presses de l’Université Laval, 
Québec, 1993, 100 p. 
7  COMER  D.E.,  STEVENS  D.  L.,  Internet  Working  with  TCP/IP,  Client/Server  Programming 
and Applications, volume 3, p.53 
8 GRAY, J. REUTER A., Transaction Processing : Concepts and Techniques, Morgan Kaufmann 
Publishers, 1993, ISBN 1‐55860‐190‐2 
9  ULKA,  R.,  Unix  Database  Management  Systems,  Yourdon  Press,  Computing  Series,1990,  ISBN 
0‐13‐945593‐0. 
10 SMINE, Hatem, ORACLE Architecture, Administration et Optimisation, Eyrolles, 1993, ISBN 2‐
212‐68016. 
11 HL‐7, Health Level Seven, version 2.1, Chicago, Illinois, Heath Level Seven Inc, 1990. 
12  MIRANDA,  S.,  RUOLS,  A.,  Client‐serveur :  concepts,  moteurs  SQL  et  architectures 
parallèles, Eyrolles, 1994, ISBN 2‐212‐08816‐7.     

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Architecture générale du logiciel SGBD

Chapitre 3
Modèle conceptuel de données
Dans ce chapitre nous allons étudier la modélisation des données et le modèle conceptuel qui en 
découle  en  excluant  les  opérations  sur  les  données  qui  ne  seront  pas  incluses  à  ce  stade  du 
design.  Le  formalisme  Entité/Association  est  principalement  utilisé  pour  les  exemples.  Par 
contre, les notions de UML pour le diagramme des classes seront brièvement présentées et  mis 
en application dans plusieurs exemples.  

3.1 Modélisation Entité/Association  (E/A) et UML 
Le  modèle  Entité/Association  (E/A  ou  E/R)  est  un  modèle  de  représentation  à  caractère 
 
sémantique1 2 permettant de spécifier une partie de la réalité au moyen dʹentités et dʹassociations 
décrites  par  les  données.  Le  modèle  de  données  doit  donc  représenter  le  mieux  possible  la 
réalité, se concentrant sur l’essentiel afin de faciliter la conception (design) de la base de données. 
Un  modèle  est  aussi  un  outil  de  communication  avec  les  utilisateurs  engagés,  comme 
spécialistes du domaine de lʹapplication, dans le processus de conception.  Cette notation est de 
plus  en  plus  remplacée  par  celle  du  diagramme  de  classe  de  UML  qui  est  un  composant  du 
Unified Modeling Language pour le développement des systèmes orientés objets.   

Rôle essentiel du modèle conceptuel (MCD) 
Le MCD spécifie la structure de la base de données indépendamment du logiciel  SGBD utilisé 
pour  l’exploitation  des  données3  tout  en  étant  la  représentation  la  plus  fidèle  possible  de  la 
réalité  organisationnelle  telle  que  perçue  à  travers  les  données.    Il  y  a  plusieurs  modèles 
conceptuels  de  données  qui  ont  été  développés  au  cours  des  années.  Nous  allons  au  début 
étudier  très  brièvement  le  modèle  Entité/Association  (E/A)  et  par  la  suite  nous  verrons  une 
variante enrichie de cette approche qui ouvre la voie à la modélisation orientée objet4. En guise 
d’introduction,  considérons  un  exemple  simple  avec  les  comptes  bancaires  et  leurs  clients 
propriétaires. Chaque instance est définie par des attributs et est caractérisée par une  clé ou un 
identifiant : le noCompte pour lʹEntité CompteBancaire et le matricule pour celle de Client. Cet 
identifiant caractérise par sa valeur une seule entité parmi toutes celles présentes dans la BD. Il 
existe  des  associations  entre  les  entités  qui  représentent  des  informations  qui  sont  aussi  à 
modéliser.  Par  exemple,  la  propriété  de  chaque  compte  bancaire  est  représentée  par  une 
association.  Dans notre exemple, les associations particulières sont illustrées par une ligne dans 
la figure 3.1. 

Instances (objets) de CompteBancaire :


Instances (objets) de Client : c-100, montcalm, 250.00
a1
n10, Bérubé, des-roses, Québec
a2
c-200, desjardins, 350.00
n20, Cousin, des-lilas, Lévis
c-300, plateau, 450.00
n30, Vézina, des-saules, Montréal a3
c‐400, laurier, 550.00 

Instances de l’association et des classes Figure 3.1

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 78

Avec cet exemple, nous avons donc : 
‐ Un ensemble de comptes bancaires (les instances) : {c‐100, c‐200, c‐300, c‐400} où c‐100 est une 
valeur de la clé, c’est‐à‐dire une valeur dʹattribut qui identifie chaque compte bancaire de façon 
non  ambiguë.  Lʹobjet  est  défini  complètement  par  plusieurs  attributs  comme  le  montre  la 
première  instance  de  CompteBancaire.  L’ensemble  des  instances  actuelles  et  futures  est 
représenté  par  la  classe  CompteBancaire.  La  structure  logique  de  l’Entité  CompteBancaire  est 
définie  par  3  attributs :  noCompte,  succursale  et  solde  du  compte.  On  appelle  cette  structure 
logique le type de l’Entité. 
‐ Un ensemble de personnes inscrites comme des clients : chacune est distincte des autres par la 
valeur de sa clé : n10 désigne un seul client dans l’ensemble. La structure de la classe Client  ou 
son type comprend quatre attributs : matricule, nom, rue, ville.   
‐ Un ensemble dʹassociations : {a1, a2, a3} où chaque association particulière entre les entités est 
identifiée  par  un  libellé  pour  distinguer  les  unes  des  autres.  Il  est  à  remarquer  que  certaines 
associations mettent en liaison un objet seulement de chaque sorte, tandis que dʹautres en font 
intervenir plusieurs. 
Exemple : Lʹassociation a3 est définie avec l’objet n30 en association avec 2 comptes bancaire,  
c300 et c‐400. 
 
Différence entre entité, Entité, objet et classe 
Le concept d'entité (avec un 'e' minuscule) correspond en E/A à la représentation par les données d'un
objet concret ou abstrait du monde réel. Une entité est dotée d’une existence autonome et est modélisée
par des attributs valués. Une entité a plusieurs synonymes selon la méthodologie utilisée : occurrence
d'Individu ou d'instance de classe ou encore mieux par la notion d’objet conceptuel. Ce terme est
privilégié dans la modélisation UML. Si l'on désire modéliser plusieurs occurrences en soulignant leur
caractère générique basé sur le partage d’une même structure, nous utiliserons la notion d'Entité (avec un
'E' majuscule). Toutefois, comme le langage parlé ne peut pas distinguer entre Entité et entité, nous les
remplacerons respectivement par les notions de classe et d’objet sans inclure pour l’instant aucune
méthode ou opération. Cependant avec UML, la classe inclura la structure et l’interface pour représenter
les objets de même structure.
 
Attribut  
La  description  d’une  Entité  (devenant  par  la  suite  une  classe  dans  la  méthodologie  objet)  est 
faite par ses propriétés appelées maintenant <attribut>. Chaque attribut est associé à une valeur 
faisant  partie  d’un  ensemble  particulier  de  valeurs  appelé  domaine  de  cet  attribut.  Voici  un 
exemple dʹune Entité Ouvrier (classe)  dont la structure est défini par ses attributs typés : 
Classe Ouvrier Type de la donnée Une entité (instance/objet)
matricule char(4) ....................................... 123B
nom varchar(40).................................. Boucher
ville varchar(50).................................. Montréal
dateEmbauche Date.............................................. 12-10-2000
Figure 3.2

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 79

 Modéliser avec une Classe ou un attribut ? 
La première difficulté rencontrée lors de la conception du modèle est d’établir ce qui est
représenté respectivement par une Entité et par un attribut. En gros, le bon sens et l’expérience
viennent à la rescousse de l’absence de critères formels pour faire ce choix.

L’existence autonome d’une valeur peut aider :


Soit un attribut A qui définit une classe C ou un attribut rattaché à une association R. Le
domaine de l'attribut A correspondant à dom(A). Si toutes les entités ou tous les objets qui
utilisent une valeur ai du dom(A) sont supprimés de la classe C, alors la valeur ai n’existe plus
dans la structure du système d’information5 :
¾ si ce ai∈ dom(A) ne présente plus d’intérêt pour l’entreprise, alors A n’est qu’un attribut;
¾ si ce ai ∈ dom(A) a toujours un sens pour l’organisation, même après la suppression du
dernier objet où ai était utilisé, alors ai devrait être traitée comme un objet de classe.

Si ai est une valeur de l’attribut A de type multivalué ou composé et que le SGBD n'offre pas ce
type au niveau de l'implémentation, il faut transformer l'attribut A en une classe et créer une
nouvelle association avec la classe source de A.

Par  exemple,  la  modélisation  d’une  œuvre  d’art  est  faite  par  diverses  caractéristiques  comme 
l’année, le style, le numéro de l’œuvre, le thème, … Qu’en est‐il du peintre ? Est‐il un attribut de 
l’œuvre  ou  doit‐il  être  représenté  comme  un  objet  associé  à  l’œuvre.  S’il  est  représenté  par  un 
attribut,  l’information  fournie  est  limitée  à  celle  de  son  nom.  Par  contre,  s’il  est  représenté 
comme un objet il devient possible de fournir une information plus complète sur le peintre : date 
et  lieu  de  naissance,  adresse  de  son  atelier,  âge  au  moment  de  la  réalisation  de  l’œuvre,  … 
Toutes  ces  informations  ne  peuvent  pas  être  incluses  dans  celle  de  l’œuvre  parce  qu’elles  sont 
pertinentes au peintre et non à l’œuvre.  
 
En outre, si ces informations sont incluses dans la représentation d’une œuvre, il y a insertion de 
redondance  en  plus  de  perdre  éventuellement  ces  informations  sur  le  peintre  si  toutes  les 
œuvres de ce dernier sont vendues.  
Formalisme  
L’utilisation du modèle conceptuel repose sur le besoin de raisonner au niveau générique plutôt 
qu’au niveau des instances et de leurs associations qui sont souvent très nombreuses. Plusieurs 
formalismes  sont  proposés,  tous  sont  des  variantes  du  formalisme  Entité/Association  de 
lʹaméricain  Peter  CHEN.    Chaque  variante  (Merise,  UML,  OMT,  …)  repose  sur  à  peu  près  les 
mêmes notions, mais utilise une représentation graphique particulière.  

Le  premier  modèle  de  la  figure  3.3  est  un  MCD  fort  simple  pour  modéliser  les  comptes 
bancaires. Les attributs sont listés en dehors (souvent avec un ovale pour chacun) du rectangle 
utilisé  pour  représenter  l’Entité.  Juste  en  dessous,  le  même  modèle  est  représenté  avec  le 
formalisme de Merise. Les deux représentent la même information. 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 80

Si l’on veut modéliser complètement les faits de la figure 3.1, il faut aussi contraindre le client à 
avoir obligatoirement un ou plusieurs comptes bancaires. D’autre part, il faut aussi représenter 
que  seuls  les  comptes  bancaires  ayant  un  propriétaire  unique  sont  représentés.  Ces  deux 
informations  sont  des  limites  à  la  représentation  du  modèle  conceptuel  qu’il  faut  établir;  elles 
sont des contraintes qui sont rendues selon le formalisme adopté par les notions de cardinalité 
ou de multiplicité (UML).   
 
Le  premier  modèle  utilise  le  formalisme  initial  proposé  par  Chen  dans  lequel  le  losange 
représente l’association. Le deuxième exploite le langage de Merise. L’association est représentée 
par un ovale et les attributs qui définissent le type de l’Entité sont insérés dans le rectangle. Les 
contraintes  de  l’association  sont  représentées  par  le  couple  (min,  max)  qui  sera  étudié  un  peu 
plus loin.  

Formalismes de la modélisation  
Le formalisme de représentation des modèles a évolué pour donner naissance à une panoplie de
langages graphiques de modélisation.

(Chen : E/A) 
  matricule* noCompte*
nom succursale
  Client 1  Possede n CompteBancaire
rue solde
  ville
 
  verbe
 
(Merise) 
 
Client CompteBancaire
matricule* noCompte*
(1,n)  (1,1)
nom Possede succursale
rue solde
(UML)  ville

Client CompteBancaire
matricule* 1 Possede noCompte*
nom 1..* succursale
rue EstPossedePar solde
ville

Figure 3.3
Le formalisme de Merise représente le même modèle avec peu de différence lorsqu’il s’agit d’un 
modèle simple. A part le symbole pour représenter l’association, il y a la façon de représenter les 
contraintes de l’association avec un positionnement différent de celui des contraintes proposées 
par  Chen.  Finalement,  le  diagramme  de  classe UML  correspondant à  ce  modèle  est  similaire  à 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 81

celui  de  Chen,  mais  utilise  la  notion  de  multiplicité  pour  représenter  la  cardinalité  n  par  1..*. 
Avec  UML,  il  s’agit  d’une  classe  au  lieu  de  l’Entité,  mais  dans  les  deux  cas  c’est  une 
représentation  générique  pour  représenter  des  objets  et  des  entités  qui  partagent  la  même 
structure.  Le  nom  de  la  classe  est  parfois  écrit  au  pluriel  pour  souligner  son  caractère 
ensembliste ou générique, tandis que dʹautres préfèrent le singulier pour accentuer sa généricité.  
Entité (classe) 
Une  Entité  est  une  structure  logique  générique  dont  le  type  global  est  défini  par  ses  attributs. 
Chaque  objet  (synonyme  d’entité)  est  défini  par  une  suite  de  valeurs.  L’ensemble  des  attributs 
d’une classe dʹentités est appelé son schéma. Le classement des objets est fait sur la base qu’ils 
partagent la même structure ou le même type.  
Lorsque nous utiliserons la notion d’instance, elle signifie un objet selon que le contexte est celui 
du formalisme E/A ou celui de UML. Une instance est une notion qui peut s’appliquer à tous les 
formalismes. Par exemple, l’instance Airbus 320 est une entité de l’Entité Avion ou un objet de la 
classe Avion. Par la suite et pour simplifier, la notion d’objet sera utilisée indifféremment du formalisme. 
Elle signifie à la fois la notion d’entité et d’instance. Au niveau générique, nous utiliserons de préférence 
la  notion  de  classe.  Dans  ce  dernier  cas,  il  s’agit  seulement  de  la  structure  sans  les  opérations.  Ces 
dernières seront ajoutées subséquemment dans un contexte de développement objet. 
Aspect fonctionnel dʹun attribut  
Un  attribut  est  en  quelque  sorte  une  fonction  définie  entre  l’ensemble  de  départ  composé  des 
objets d’une classe et l’ensemble des parties de son domaine de valeurs, le dom(attribut). 

L’attribut a est une fonction attribut V définie ainsi :  
E -V-> Σpi(dom(a))
où Σpi(dom(a) est l'ensemble des parties du domaine de a .

Caractéristiques de lʹattribut 
Chaque  attribut  du  schéma  d’une  Classe  est  considéré  comme  une  fonction  qui  peut  avoir 
plusieurs caractéristiques ou propriétés spécifiées au moment de l’implantation de la base avec 
le Langage de Définition des Données (LDD ou DDL) du SGBD utilisé :  
 
a) Complexité de l’attribut 
Il existe deux sortes dʹattribut quant à la complexité de sa structure informationnelle :    
‐ Simple : un attribut simple est atomique et représente une seule propriété accessible comme un 
tout indécomposable.  
Par exemple :   nom dont la valeur sera une chaîne et l’âge dont la valeur sera un entier.  
 
‐ Composé (ou arborescent) : cʹest un attribut constitué de plusieurs attributs simples en relation 
hiérarchique. De par sa structure, un attribut composé offre un accès au tout ou à une partie de 
la valeur dʹattribut. 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 82

Exemple d’un attribut composé : nom et le prénom comme un seul attribut.  

nom

nomFamille prenom

Figure 3.4 
Ainsi,  la  valeur  de  lʹattribut  nom  est  obtenue  par  une  fonction  V(nom)  =>  ʹLassonde  Claireʹ, 
tandis que la valeur du nomFamille est obtenue par la notation pointée: V(nom.nomFamille) => 
ʹLassondeʹ. La hiérarchie peut avoir plusieurs niveaux. Ainsi, un tel attribut facilite lʹaffectation 
avec une  variable de type struct du langage C. Il est aussi  possible de  représenter les attributs 
hiérarchiques  par  un  indice  de  niveau  placé  entre  parenthèses.  Lʹattribut  composé  nom  est  alors 
représenté  ainsi  dans  un  formalisme  logique  dans  lequel  le  chiffre  indique  le  niveau  de  la 
hiérarchie.  Dans  l’exemple  ci‐dessous  la  classe  Client  est  définie  avec  deux  attributs  dont  le 
premier est composé avec ses deux niveaux.  
 
Client
 
nom (1) 
  nomFamille (2)
  prenom (2)
  ville (1)
 
 
Si la même information devait être représentée par un attribut simple, elle serait de type chaîne 
de caractères comprenant le nom et le prénom concaténés et délimités par un symbole adéquat. 
Pour  obtenir  seulement  le  nom  de  famille,  une  application  devra  donc  lire  toute  la  chaîne  et 
l’extraire de celle‐ci au moyen du délimiteur et dʹune fonction de chaîne. 
Exemple :  
Le nom et le prénom combinés en un seul attribut  nomPrenom valué avec la chaîne suivante :  ʹ 
Lassonde$Claireʹ      (où  le  $  agit  comme  délimiteur  dans  la  chaîne).  Pour  accéder  au  prénom, 
l’application  devra  donc  programmer  une  recherche  dans  la  chaîne  complète  pour  extraire  le 
prénom en se servant du délimiteur. Notons que l’utilisation d’une expression régulière dans un 
langage  d’interrogation  permettrait  de  faire  cette  sélection  automatiquement.  Les  versions 
récentes de plusieurs SGBD offrent cette fonctionnalité (voir Oracle 10g). 
                                    
b) Attribut monovaleur ou multivaleur 
Lʹattribut  peut être valué (néologisme provenant du mot anglais valued) par  une ou des valeurs 
selon le cas : 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 83

‐ Monovaleur : cʹest un attribut valué par une seule valeur pour chaque entité, cʹest‐à‐dire que la 
mise en correspondance est limitée avec un élément d’ensemble p(d2) dont la cardinalité est 1. 
Lʹattribut  est  aussi  nommé  atomique  ou  scalaire.  Par  exemple,  les  attributs  noCompte  et  solde 
sont des scalaires. 
 
‐  Multivaleur  (mv) :  cʹest  un  attribut  associé  éventuellement  à  plusieurs  valeurs  pour  chaque 
entité. Un tel attribut correspond à une mise en correspondance avec un  élément de lʹensemble 
p(d2) dont la cardinalité est supérieure à 1. Lʹattribut multivaleur est codé (mv) et sa valeur est 
un ensemble de données. Ce type d’attribut est rarement présent dans les SGBD relationnels. 
 
c) Mode de l’attribut 
Il y  a deux modes possibles pour lʹattribut : 
Direct :  la  valeur  associée  à  l’attribut  de  la  classe  est  stockée  explicitement  dans  la  base  de 
données; 
 
Dérivé : la fonction est alors une composition de fonctions et la valeur obtenue n’est pas stockée 
directement avec l’attribut; 
 
Exemple : Lʹâge dʹune personne est une fonction (gʹ) qui assigne une année à chaque objet de la 
classe Personne: 
age : E −> anneeNaissance ‐‐> entier, i.e. l’âge calculé (entier) 
  gʹ       gʹʹ     
Les deux fonctions g’ et gʺ sont composées pour donner la fonction g:  
g :   g’ * gʺ : E −> entier 
 
g(E) =  [dateCourante] ‐ g’(E) =  âge de E. 
 
d) Attribut autorisé à ne pas avoir une valeur : indicateur NULL 
C’est un attribut qui au chargement de l’entité peut ne pas avoir une valeur du domaine. Il en 
découle  parfois  une  ambiguïté  sémantique  pour  l’utilisateur.  Son  interprétation  est  variable : 
une absence de valeur peut signifier qu’elle est non disponible, mais existante ou que c’est une 
valeur non disponible, car non existante, ou une valeur inconnue (existe ou non), ou une valeur 
impossible,  etc.  A  cause  de  cette  polysémie  possible  de  l’absence  d’une  valeur,  il  faut  de 
préférence  éviter  cette  situation  dans  une  base.  Elle  peut  générer  aussi  des  résultats  faux  avec 
certains traitements. Cette possibilité pour un attribut de ne pas avoir une valeur correspond à 
un  indicateur  de  valeur  nulle  (NULL)  ou  son  contraire  qui  est  un  indicateur  obligeant  un 
attribut à avoir une valeur (NOT NULL). 

Exemple : Si pour des villes témoins, on enregistre à chaque jour la pression (p), la température 
(t) et la vitesse du vent (v), on obtient des objets de la classe appelée FicheMétéo. Supposons que 
suite à un accident, le baromètre soit en panne et que la pression ne soit pas disponible pour la 
ville  inuit  de  ʹKuujjuaqʹ.  Comment  représenter  la  valeur  manquante?  En  optant  pour  le  0  ? 
(pression plus quʹimprobable en kPa!), il y a possibilité d’effets de bord. Par exemple, le calcul 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 84

de la moyenne de la pression à ʹKuujjuaqʹ avec la fonction AVG() donnera un résultat faux! En 
effet, la valeur 0  étant une valeur du domaine de la pression p, la moyenne en tiendra compte 
dans la sommation et aussi dans la division nécessaire pour obtenir la moyenne. 
 
Lʹutilisation dʹune valeur hors domaine pour représenter la valeur nulle pose aussi problème. En 
effet, en interrogeant la base pour lister toutes les villes repères avec comme critère composé une   
pression > 100 ou une pression <100 ou une pression = 100, la réponse exclut alors les villes dont 
la pression est absente ou inconnue puisque le null  pour p est hors domaine et par conséquent 
ne vérifiera jamais le critère de sélection de la requête. Le fait d’autoriser l’absence d’une valeur 
est signalée par un indicateur d’absence de valeur, le NULL. Il faudra donc utiliser un prédicat 
spécial  pour  faire  une  sélection  avec  cet  indicateur  et  prendre  ainsi  en  compte  l’absence  de 
valeur. Cet indicateur n’étant pas une valeur du domaine ne peut donc pas être comparé à une 
autre valeur. 
 
e) Clé d’une classe 
Un  ensemble  de  un  ou  plusieurs  attributs  est  appelé  la  clé  de  la  classe parce que  sa  valeur  est 
différente pour chaque objet. Si la clé est assignée, elle est connue comme un identifiant externe 
et son sens pour un utilisateur du système n’est pas toujours évident et peut poser problème en 
cours  d’exploitation.  Dans  le  modèle  relationnel,  une  autre  condition  sera  imposée  à  la  clé,  à 
savoir que le nombre dʹattributs soit minimal tout en gardant son rôle de distinguer les tuples 
(i.e. les objets relationnels) les uns des autres. 
 
Il y a essentiellement deux sortes de clé : 
La clé simple construite avec un seul attribut. Par exemple : nas ou  matricule ou  noVignette. La 
clé  composée obtenue  par  juxtaposition  d’au  moins  deux  attributs  simples.  Par  exemple, 
{matricule, noCours} dans la classe BulletinAcademique est une clé composée de deux attributs 
permettant  à  un  étudiant  de  suivre  plusieurs  cours,  et  un  même  cours  pouvant  être  suivi  par 
plusieurs  étudiants.  Pour  éviter  une  clé  composée,  il  faudrait  la  remplacer  par  un  identifiant 
dont la valeur est atomique, mais dont la sémantique est très souvent arbitraire en regard de la 
réalité. Un tel identifiant peut constituer un ajout étranger au système d’information en usage. 
 
a) Clé choisie et clé candidate 
Une classe dʹentités (i.e. une Entité) peut avoir plusieurs clés : 
 
‐ Clé choisie ou principale (primary key ‐ à ne pas confondre avec l’attribut primaire) : s’il existe 
plusieurs clés possibles pour une classe, une (de préférence simple) est sélectionnée et marquée 
comme choisie ou principale. Les contraintes sur cette clé sont généralement renforcées par un 
index défini implicitement par le SGBD à partir de la spécification du schéma. Cet index ne peut 
pas  être supprimé  par  le  DBA.  Le  ou  les  attributs  de  la  clé principale  sont  qualifiés  d’attributs 
primaires.  
                           
‐  Clé  candidate :  toute  clé,  simple  ou  composée,  non  choisie  comme  primaire  est  une  clé 
candidate pour sa classe. Tout comme la clé primaire, la clé candidate ne peut pas être nulle. Par 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 85

exemple,  en  supposant  quʹun  seul  exemplaire  existe  pour  un  livre  dans  une  bibliothèque,  la 
classe Livre peut être définie de la façon suivante :   
Livre (cote, titre, auteurs, noLocal, editeur, annee, ISBN, prix) 
 
Les clés possibles dans Livre sont les suivantes :  
‐ clés simples (ou monoattribut) : {cote} ; {ISBN}; {noLocal};  
‐ clé dite composée  (ou formée avec plusieurs attributs) : {annee, titre} ; 
‐ clés candidates : toutes les clés ci‐dessus. 
 
b)  Superclé  
La notion de superclé est utile dans la recherche dʹune clé. Elle est formée par l’ajout d’un ou de 
plusieurs attributs à une clé (primaire ou candidate). Dans le modèle relationnel, cette superclé 
n’est pas une clé primaire, mais un ensemble de plusieurs attributs qui contient obligatoirement 
une  clé.  Les  attributs  non  essentiels  dans  la  superclé  sont  dits  étrangers.  La  superclé  n’a  pas 
toutes  les  caractéristiques  d’une  clé.  Elle  est  très  souvent  composée,  mais  elle  nʹest  pas 
nécessairement minimale. Certains modèles, comme le modèle relationnel, ont obligatoirement 
une superclé formée par définition  de tous les attributs d’une classe. Enfin, si une superclé est 
réputée présente  dans une classe du modèle, il y a donc forcément une clé qui est incluse dans 
chaque classe du modèle.  
 
Domaine d’un attribut  
Le  domaine  dʹun  attribut  est  un  ensemble  nommé  formé  de  toutes  les  valeurs  non  nulles 
admissibles pour donner une valeur à une propriété (attribut). Le domaine sert à la validation 
sémantique  que  devrait  pouvoir  effectuer  un  SGBD  indépendamment  des  applications.  Le 
domaine  est  spécifié  lors  de  la  conception  d’une  base  de  données  et  sa  définition  est  stockée 
dans  le  dictionnaire  afin  d’être  accessible  à  toutes  les  applications.  L’absence  d’une  valeur 
correspondant à la présence de l’indicateur NULL  qui n’est pas une valeur du domaine. 
 
Remarque sur la syntaxe des libellés : Le libellé dʹun attribut ne comporte généralement pas de 
signes  orthographiques  sauf  ceux  admis  par  le  langage  de  définition  de  données  (DDL).  Par 
exemple,  les  attributs  âge  et  no‐Compte  s’écrivent  respectivement  age  et  noCompte  à  titre 
dʹattributs dʹune table, car lʹaccent circonflexe et le trait dʹunion ne sont pas admissibles par la 
syntaxe du langage DDL. 
 
Exemples de domaines : 
Dom (attribut)  Nom du domaine  Définition du domaine N.B.les crochets : ] et [ 
dom(age)  d_age_actif     18<= age <= 65 ou [18...65] 
dom(age)  d_age_actif     [0...100[ (inclusion du 0 et exclusion de 100 ) 
dom(name)  d1_nom   chaîne de 35 caractères 
dom(nom)  d2_nom   {‘Audy’, ‘Bilodeau’, ‘Gagnon’} 
dom(salaire)  d3_sal   [23000.50 …50000.00] 
Figure 3.5 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 86

Définition formelle  de lʹinstance ou objet 
Une  instance  e  de  la  classe  E,  est  un  obligatoirement  un  élément  du  produit  cartésien  des 
domaines d’attribut de E : 
e ∈ {dom(A1) x dom (A2) x ... dom(An)} 
 
Notons  aussi  qu’une  fonction  n’est  pas  nécessairement  définie  partout  dans  l’ensemble  de 
départ contrairement à la notion mathématique d’application et que, par conséquent, un attribut 
peut ne pas avoir de valeur comme cʹest le cas pour une fonction injective.  
 
Définition  formelle d’une classe  
Une classe Ct est un sous‐ensemble arbitraire de tous les objets partageant la même définition et 
qui satisfont une clé primaire K au temps t : 
Ct  ⊆ {dom (A1) x dom (A2) x ... dom( An)} 
 
Objet (instance) et classe 
La  classe  est  la  définition  générique  de  la  structure  des  objets  qui  sont  stockés  dans  un  espace 
appelé extension. Une instance de Employe est représentée sous la forme dʹune ligne de valeurs 
dans  une  table  relationnelle.  Il  y  aura  autant  de  lignes  dans  la  table  quʹil  y  a  d’instances  de 
Employe dans la base de données. Chaque ligne est aussi appelée un tuple. 
 
Employe :  matricule*  nom  departement  <‐ définition de la table Employe  
  m234  Larose  réception  Å objet ou instance 
  m45  Jobin  atelier fraisage   
  m287  Vachon atelier soudure   
Définition de la classe Employe  et de ses instances 
Figure 3.6 
 
Association;  entre les instances des classes 
Une association représente un lien sémantique générique découlant des liens particuliers entre 
les objets de  PosteTravail et ceux de Employe et Materiau.  
 
 
  poste1 poste2 poste3 Les instances : 2 sortes 
  de liens  
34kg 23kg 15kg
  18kg
  50kg
 
 
 
emp5 mat3 mat4 mat5 emp2 emp7
 
 
Travaille Utilise
 
Figure 3.7 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 87

 
Dans  les  exemples  qui  suivent,  nous  allégerons  les  figures  en  n’utilisant  que  le  minimum 
dʹattributs  pour  définir  chaque  classe.  Les  instances  ci‐dessous  modélisent  la  quantité  des 
matériaux utilisés par différents postes de travail pilotés par des ouvriers habilités à ces postes.  
Donc lorsqu’un attribut apparaît seul dans une occurrence ou dans une classe, il sera considéré 
comme  la  clé  de  la  classe  et  les  autres  attributs  sont  réputés  existés.  L’association  est 
généralement formulée par un verbe et la première lettre de son libellé est une majuscule.  
 
L’association inverse est très souvent implicite et est présumée, c’est‐à‐dire si R => R‐1. Voici un 
autre  exemple,  illustré  à  la  figure  3.7  concernant  l’approvisionnement  des  postes  de  travail 
flexible. Ainsi, dans lʹinstance du modèle ci‐dessous, lʹemployé ʹemp5ʹ travaille au poste ʹp1ʹ. De 
même,  le  matériau  ʹmat3ʹ  est  utilisé  par  les  postes  ʹposte1ʹ  et  ʹposte2ʹ.  Ces  instances 
correspondent au MCD de la figure 3.7a. 
                                
 
 
 
PosteTravail  PosteTravail
 
noPoste* noPoste*
  noBatiment
noBatiment
 
  Utilise
  Utilise Travaille qte
Travaille qte
 
 
  Employe Materiau
Employe Materiau matricule* noMat*
  matricule* noMat* nom site
  nom site
 
Modèle conceptuel : E/A et UML 
Figure 3.7a 
    
Dans  les  deux  versions  du  MCD,  les  associations  sont  représentées  sans  mention  de  leur 
contrainte  de  cardinalité  ou  de  multiplicité  (figure  3.7a).  L’état  de  ce  modèle  est  donc  une 
représentation partielle des instances de la figure 3.7.  
 
Le numéro de poste de travail est une clé primaire pour la classe PosteTravail; il en est de même 
pour  les  attributs  matricule  et  noMat  qui  sont  les  clés  respectives  des  classes  Employe  et 
Materiau. Sur le plan de la sémantique, le modèle de la figure 3.7a ne réussit pas à représenter 
toute  lʹinformation  que  lʹon  peut  obtenir  avec  lʹexamen  des  instances, notamment le  fait  qu’un 
poste de travail peut fonctionner avec aucun ou plusieurs opérateurs. Par contre, si lʹon examine 
les  entités  de  la  figure  3.7,  ce  fait  est  clairement  représenté.  Pour  enrichir  la  représentation  du 
modèle,  il  faudra  ajouter  des  informations  concernant  la  participation  des  instances  aux 
associations.  Cet  ajout  se  fera  au  moyen  de  contraintes  formelles  de  participation  et  de 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 88

cardinalité  pour  le  formalisme  E/A  et  au  moyen  de  la  multiplicité  de  chaque  association  UML 
dans les modèles de la figure 3.7a. 
                                
Définition  formelle de lʹassociation E/A de degré n 
Soit les classes E1, E2, ... En et les attributs  a1 ,a2, ... ak ; une association r entre les classes E1.. 
En définie avec les attributs a1 à ak est un élément du produit cartésien : 
  {dom(clé de E1) x dom(clé de E2) x ...dom(clé de En) x dom(a1) x ... dom(ak)} 
 
où r = (i1, i2, ... in, a1, a2, ... ak) avec ii comme identifiant de Ei ou clé de Ei, Ei = classe d’entités i, 
et aj = attribut j  de l’association. 

R ⊆ {dom(clé de E1) x dom(clé de E2) x ...dom(clé En) x dom( a1) x ... dom(ak)}

NB : En utilisant la lettre majuscule R, on fait alors référence à l'ensemble des objets de la classe
et donc à sa définition.

Degré d’une association 
Soit n le nombre de classes d’entités présentes dans une association. Selon la valeur de n, il y a
plusieurs cas de figure possibles :

a- si n = 2, alors l'association ou relation est dite binaire (l’association la plus courante)


b- si n = 3, alors l'association est dite ternaire (interprétation parfois difficile)
c- si n = n, alors l'association est dite n-aire

Un modèle conceptuel n’utilisant que les associations binaires (6) est qualifié de binaire. C'est
le cas pour le modèle de données NIAM proposé par Nijssen (7).

Association ternaire
Les associations ternaires et celles de degré supérieur bien qu’admissibles sont presque toujours
difficiles à interpréter; elles sont de préférence à éviter. Voici un exemple d’une telle association
Realise qui de plus ne porte aucun attribut particulier.

Client 1..* 1...* Constructeur


nas* Realise nom*
nom ville
1..*
Projet
Version UML avec noProjet*
une ternaire cout
chef

Figure 3.8

En tenant compte des multiplicités de cette ternaire, la sémantique du modèle UML de la figure
3.8 est la suivante :
© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 89

- Un client et un constructeur collaborent à la réalisation de un à plusieurs projets.


- Un client et un projet ont engagé un à plusieurs constructeurs.
- Un constructeur et un projet réfèrent à un à plusieurs clients.

Nous verrons avec la théorie relationnelle, le rôle et la sémantique de la dépendance fonctionnelle


(DF) entre les attributs. Nous serons en mesure alors de préciser que la ternaire sous-tend
l’absence de dépendances fonctionnelles entre les clés des classes qui participent à l’association
ternaire.
Par exemple dans une telle ternaire, les DF suivantes ne sont pas validées :

nas -/-> nom, noProjet ; noProjet -/-> nas, nom et nom -/-> noProjet, nas

Par contre, le même modèle avec des multiplicités différentes, notamment celles de 1 et 0..1
appliquées une ou deux classes de la ternaire, devient difficile à lire et constitue dans certains cas
une représentation erronée ou du moins confuse. Voici un exemple illustré par la figure 3.8a.

Client 1..* 0..1 Constructeur


nas* Realise nom*
nom ville
1
Projet
noProjet*
Version UML  cout
chef

Figure 3.8a

Les contraintes sous-tendues par la multiplicité de la ternaire ci-dessus sont les suivantes :
1- Un client et un projet sont en contact avec aucun ou un constructeur.
2- Un client et un constructeur réfèrent à un et un seul projet.
3- Un constructeur et un projet font référence à un ou plusieurs clients.
Ainsi les triplets suivants sont valides : ( cl1, co1, pr1), (cl2, co2, pr1), (cl2, co1, pr2)

Par contre les triplets suivants sont invalidés par les contraintes de multiplicité du modèle UML :
triplet (cl2, co1, pr1) invalidé par la règle 2 , triplet (cl2, co2, pr2) invalidé par la règle 3.

Cas spécial : En plus de ces contraintes sur la ternaire, il peut y avoir des contraintes particulières
impliquant que deux classes : un constructeur ne peut être associé qu’à un seul projet à la fois peu
importe le client. Cette contrainte dite d’intégrité fonctionnelle intervient entre deux classes
seulement et interdit tout triplet qui représente un même constructeur associé à deux projets
différents. Les triplets ( cl1, co1, pr1) et (cl2, co1, pr2) deviennent ainsi invalides. Une telle
restriction entre deux classes peut introduire une contradiction ou une confusion avec les
multiplicités de la ternaire. Une telle contrainte, si elle est valide peut indiquer que l’association
ternaire n’est pas apporiée pour modéliser correctement cette réalité.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 90

Client 1..* 0..1 Constructeur 1..* 0..1 Projet


nas* nom* noProjet*
nom ville cout
chef
Version UML 

Figure 3.8b

La représentation avec deux binaires est illustrée ci-dessus constitue un nouveau modèle doté
d’une sémantique différente de celle du modèle de la figure 3.8b.
 
3.2 Classe de rôle : spécialisation des classes et des associations 
Il arrive que certains attributs d’une classe ne s’appliquent pas à tous les objets de la classe8. Par
exemple, les documents de la bibliothèque ont plusieurs formes : papier, support sonore ou
visuel, disque optique compact ou CD-ROM. Selon le cas, les deux attributs ISBN et équipement
ne s’appliquent pas à toutes les entités de la base modélisées par cette structure. Un livre a un
ISBN mais n’a pas de libellé d’équipement. Par contre, un diaporama n’a pas de ISBN.
L’indicateur d’absence de valeur (le null) n’est pas acceptable pour l’attribut ISBN puisqu’un
diaporama n’a pas de ISBN lequel est réservé qu’aux livres. Un indicateur null laisserait supposer
que le ISBN existe mais qu’il est inconnu au moment de la création de l’objet.

Document Document 
noArticle* noArticle* 
isbn L’attribut dateP dans ce modèle est isbn
local considéré comme une information local
pertinente à l’emprunt du document par à
  equipement une personne, c’est-à-dire à l’association
equipement
entre les deux instances. Ainsi, il sera
  possible de garder en mémoire deux prêts
Emprunte du même document à la même personne et Emprunte
dateP cela à deux dates différentes. dateP

Personne Personne
matricule* matricule*
nom nom
E/A Figure 3.9 UML

Un premier modèle E/A présenté à la figure 3.9 permet de représenter le prêt des documents aux
abonnés de la bibliothèque. C'est une modélisation avec une structure dont les attributs ne
s'appliquent cependant pas à toutes les entités. Comme c’était le cas pour le ISBN, l’attribut
équipement ne s’applique pas à tous les documents sauf ceux du genre multimédia. L’attribut
équipement n’est donc pas pertinent à la représentation de livres. Pour contourner cette
difficulté, on attribue un rôle à la classe Document pour signifier que certains attributs
s'appliquent à certains objets et pas à d'autres. Le rôle est concrétisé dans le modèle initial par une
division des instances de Document et leur regroupement dans deux nouvelles sous-classes
définies par leurs attributs propres. Dans cette même opération, il peut y avoir aussi spécialisation

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 91

de l'association initiale pour prendre en compte les deux nouvelles classes spécialisées (figure
3.10).

La création de ces deux sous-classes est une abstraction de spécialisation représentée par la
flèche. Cette spécialisation appliquée à la modélisation conceptuelle n’est pas rendue directement
comme tel avec la technologie relationnelle, sauf dans les derniers systèmes qualifiés de système
objet-relationnel. Cette abstraction de spécialisation permet de simplifier, voire préciser la
sémantique des associations et des classes du MCD. Elle peut contribuer à découvrir de nouvelles
associations durant la phase d'analyse. L'inverse de la spécialisation est la généralisation qui
consiste à former une superclasse avec les attributs communs à plusieurs sous-classes présentes
dans un MCD. Les nouvelles classes spécialisées ont toutes les propriétés de la classe, à savoir
qu’elles peuvent participer à des associations et avoir une clé primaire en propre. La
spécialisation de la classe Document fournit deux nouvelles classes, le Multimedia et le Livre.
Dans le formalisme UML, la spécialisation est représentée par une ou deux flèches et fournit
deux sous-classes portant les mêmes noms.

Document Document
noArticle* noArticle*
 
local local
sorte sorte

{i,d
}
p,e
Multimedia Livre

equipement isbn*
Multimedia Livre

equipement isbn*
  PreterM PreterL
datePret datePret
PreterM PreterL Personne
datePret datePret matricule*
nom

Personne UML
matricule*
nom Dans l’un et l’autre de ces MCD, les contraintes 
Figure 3.10
structurelles et les multiplicités sont à définir. 
E/A 
Figure 3.10

Les nouvelles classes sont des sous-classes de rôle ou des classes spécialisées. Elles sont
obtenues par une spécialisation de la classe Document. Avec la spécialisation, il est possible de
préciser des contraintes à la spécialisation, notamment la couverture (t ou p) et le partionnement
(e ou o). Dans l’exemple E/A, la spécialisation est partielle (p) et exclusive (e) les entités de
Document. Certains documents et pas tous sont spécialisés comme un livre ou comme un
document multimédia; il ne peut pas être les deux simultanément. C’est donc en quelque sorte
© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 92

une inclusion telle que l’union des instances qui partagent la structure de l’une des deux sous-
classes forme un sous-ensemble de la superclasse. Certains documents ne sont pas spécialisés par
exemple les parchemins et ils auront la structure de la superclasse Document.

La structure d'une sous-classe est spécifiée avec ses attributs propres auxquels s'ajoutent par
héritage ceux de la superclasse. Le modèle indique donc que le type de la sous-classe Livre est
défini par une structure logique formée des attributs {isbn*, noArticle, local}, tandis que celui de
la structure de Multimédia est défini par les attributs {noArticle*, equipement, local}. Une sous-
classe peut cependant ne pas avoir d'attributs propres, mais uniquement des attributs obtenus par
héritage de la superclasse. Avec le formalisme UML, les contraintes sont incomplete (i) et
disjoint (d). Dans le même MCD E/A de la figure 3.10, si la spécialisation était plutôt (t,e), alors
aucune instance ne sera stockée dans la base de données avec la structure de Document. Dans la
formulation UML les contraintes de la spécialisation seraient {c, d}. En spécialisant une classe,
les sous-classes héritent aussi des associations de la classe source d’origine qui sont aussi
spécialisées et renommées. Nous étudierons plus en détails ces notions à la fin de ce chapitre.

Entité/Association UML
total (t) complete (c)
partiel (p) incomplete (i)
exclusif (e) disjoint (d)
chevauchement (o) overlapping (o)
Tableau des contraintes de spécialisation

Attribut discriminant (d) 
Dans un modèle conceptuel, la spécialisation est avant tout un outil d'abstraction qui facilite dans
certains cas la modélisation. Une autre caractéristique de la spécialisation consiste à définir une
structure permettant de stocker au besoin, les objets des sous-classes avec ceux de la superclasse.
Il y aura dans ce cas, deux structures logiques différentes qui cohabiteront dans la même
superclasse. Les instances ainsi mélangées seront distinguées par l'ajout d'un nouvel attribut
appelé le discriminant. Dans l'exemple ci-dessus, l'attribut discriminant est sorte dont la valeur
peut être 'L' ou 'M' pour identifier un livre ou un multimédia.

3.3 Traitement de lʹassociation réflexive  
Une association binaire (figure 3.11) dans laquelle les deux classes participantes ont le même
nom est dite réflexive. Encore ici, tous les objets de la classe Personne ne sont peut-être pas
décrites de la même façon selon que l’entité concerne le médecin ou le patient.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 93

Personne
Personne  matricule* Patient
matricule* nom
nom specialite
specialite diagnostic
diagnostic noDossier
noDossier
Medecin
Medecin Patient

Traite
dateT
Traite
E/A UML
dateT 

Figure 3.11

La notion de rôle permet donc de diviser les entités d’une même classe en fonction de leur rôle ou
du traitement particulier dévolu à chaque instance. Une personne pourrait être simultanément
patient et médecin. Ceci se traduit par une spécialisation caractérisée par un chevauchement
(overlapping (o)). En ce qui concerne la base, il pourra y avoir un objet avec la structure de
médecin, et un autre avec le même identifiant ou clé, ayant la structure de patient. Au plan
sémantique, ceci signifie que le modèle permet de représenter un médecin qui peut être aussi un
patient. Comme cela est illustré à la figure 3.12, l'association réflexive peut être transformée par
spécialisation pour obtenir deux sous-classes : Médecin et Patient. Il faut aussi noter que les
contraintes sur les associations ne sont pas exprimées dans ces modèles.

  Personne Personne
Hopital matricule* matricule*
nom nom
{c,o}
Consulte
t,o
Medecin Patient
  specialite noDossier
Medecin Patient diagnostic
specialite noDossier
diagnostic
Consulte
  Traite Traite
Consulte dateT Hopital dateT 
 
Hopital E/A UML
 
 
Figure 3.12 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 94

Ces deux nouvelles classes peuvent éventuellement participer à de nouvelles associations pour
représenter de nouveaux faits. Par exemple, une nouvelle association peut être faite entre médecin
traitant et un hôpital pour représenter le fait qu’un médecin peut communiquer avec une équipe
médicale spécialisée. Cette même équipe peut agir comme référence à plusieurs médecins, mais
cette dernière contrainte d’association n’est pas encore représentée dans l’un et l’autre des
modèles.

Dans cette base, aucune instance ne peut être représentée qu'avec la seule structure logique de
Personne {matricule, nom} et cela en raison de la couverture totale de la spécialisation qui force
une personne à être un patient, un médecin ou les deux. La classe Personne est donc une classe
abstraite et la convention UML spécifie que son nom doit être en italique. Lorsqu’un médecin est
aussi un patient, nous retrouverons le même matricule et le même nom dans deux entités, l’une
dans la sous-classe Medecin et l’autre dans Patient. Cette contrainte est modélisée par une
spécialisation caractérisée par le chevauchement ou overlapping (o).

Voici un autre exemple E/A de la modélisation des liens parentaux au moyen de l’association
réflexive ParentEnfant qui sera transformée en une spécialisation exclusive.

Dans ce cas, les instances de Personne sont séparées en deux classes mutuellement exclusives.
L’association réflexive ACharge représente une génération de parents qui ont la charge d’enfants.
Le partionnement exclusif limite la modélisation à une seule génération de sorte qu’un enfant ne
peut pas être représenté comme un parent des enfants de la génération suivante.

Personne
Personne nas*
nas* nom
nom employeur
employeur age
  age
  ecole
ecole
 
 
ACharge Enfant
Enfant  
ACharge Parent
Parent E/A
  UML
Figure 3.13 
C’est donc un modèle qui a ses limites, notamment à cause de l’absence de contraintes
d’association.

personne comme enfant


p4
p3
personne comme parent

p1
  p2 A charge de
Figure 3.13a 
© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 95

Une instance de l’association se lit ainsi : un parent p1 a la charge de 2 enfants que sont les
personnes p3 et p4. La personne p3 a aussi un autre parent p2.

Cette réflexive peut être transformée par spécialisation pour générer deux sous-classes : Parent et
Enfant. Ces dernières sont en association pour représenter le lien parental ACharge. Encore une
fois, remarquons que l’absence de contraintes sur l’association ne modélise pas entièrement les
instances de la figure 3.13a. En effet, selon les instances un parent peut avoir plusieurs enfants et
un enfant a au plus 2 parents.

La spécialisation du MCD E/A de la figure 3.14 peut fait apparaître clairement deux nouvelles
classes qui participent à l'association. La lecture du MCD devient plus simple et facilite la
découverte éventuelle de nouvelles associations comme par exemple, l’inscription d’un enfant à
un club sportif (partie ombragée).

Personne
Personne
nas*
nas*
nom
nom ClubSport
ClubSport age
age nomCl*
  nomCl*
 
  {c, d} Inscrit
t, e Inscrit
 
 
Parent Enfant
  Parent Enfant
employeur ecole
employeur ecole
 
ACharge
ACharge  
 
UML
  E/A
Figure 3.14 
La spécialisation pourrait être pilotée par un attribut spécial comme par exemple l'attribut statut
qui permettrait de choisir la classe de spécialisation à laquelle appartient une instance personne à
ranger dans la base.
 
3.4 Contraintes dʹune association 
Une association entre deux classes a des contraintes qui viennent enrichir la sémantique du MCD.
Il y a deux contraintes importantes dans le modèle sémantique E/A, à savoir la contrainte de
cardinalité (cc) et la contrainte de participation (cp). Elles sont exprimées de diverses façons
selon le formalisme adopté. Leur convention de lecture est particulière à chaque système de
codage des contraintes. Par exemple, avec Merise, les contraintes de participation et de
cardinalité sont juxtaposées pour donner la paire (min,max). Par la suite, nous utiliserons
l’équivalent en terme de multiplicité du diagramme de classe de UML.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 96

Contrainte de cardinalité (cc) de l’association  
La contrainte de cardinalité d'une classe E spécifie le nombre possible d’instances d'une autre
classe G en association avec une instance de E. La cardinalité de E se place du côté de G. Notez
aussi que le terme instance sera utilisé au lieu de entité.

Cas 1 : 1-1
Chaque instance de E peut être associée avec au plus une instance de G et vice-versa.

1-1

  E G
Figure 3.15 
La contrainte de cardinalité se place de part et d’autre des extrémités de l’association.
On peut interpréter la cardinalité de l’association de la figure 3.15 de la façon suivante :
a) Une instance de E peut participer au plus à une instance de l’association entre E et G. En
d'autres mots, une instance de E peut être associée au plus à une instance de G. Il est possible
qu’une instance de E ou de G ne soit pas en association.

b) Chaque instance de G peut participer au plus à une instance de l’association entre E et G ou


affirmer qu'une entité de G peut être associée au plus à une entité de E. Il peut y avoir des entités
de E qui ne participent pas à une association.

E 1 1 G
EG

Cas 2 : La cardinalité 1-N


 
  1- N
 
 
  E G
Figure 3.16  

Voici l'interprétation proposée :


a) Chaque instance de E peut participer à l’association E-G avec plusieurs entités de G, au plus N.
Encore ici, cela signifie qu’une instance de E peut participer à N instances de l’association E-G.

b) Chaque entité de G peut être en association avec au plus une instance de E.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 97

E 1 N G
EG

cas 3 : La cardinalité de plusieurs avec plusieurs : N-M

N-M

E G
Figure 3.17
On peut l'interpréter cette association ainsi :
a) Chaque instance de E peut participer à l’association avec au plus m instances de G. Ou encore,
une instance de E participe au plus à m instances de l’association E-G.

b) Chaque instance de G peut participer au plus à n instances de l’association E-G. En d'autres


mots une instance de G peut être associée au plus à n instances de E.

E M N G
EG

La contrainte de cardinalité sous-tend une certaine sémantique dans l’association au regard de la


réalité à modéliser. Les faits de la réalité qui ne se conforment pas à ces contraintes du modèle ne
peuvent tout simplement pas être représentés par le modèle MCD.

Voici un autre exemple concret d’un modèle E/A simple permettant de résumer les 3 cas de
figure précédents et de leur interprétation :

Client CompteBancaire
matricule* noCompte*
nom Possede succursale
rue solde
ville cas 1 : 1 1
cas 2 : 1 n
cas 3 : n m
Figure 3.18

L'interprétation des trois cas modélisés par l'association Possede est la suivante :

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 98

Cas 1 : Avec la cardinalité 1-1, un client possède 0 ou 1 compte et inversement. Les comptes en
copropriété, c’est-à-dire l'ouverture par la même personne de plusieurs comptes, ne sont pas
modélisés par cette structure logique. Il est possible pour un client de ne pas avoir de compte
bancaire. Est-ce qu’un compte bancaire peut être ouvert sans un client? Selon la contrainte 1-1,
cela est possible. Or, une telle situation n’étant pas réaliste, il faudra un autre type de contrainte,
soit celle de participation (rendue par le paramètre min) pour venir interdire la représentation de
ce fait.

Cas 2 : Avec la cardinalité 1-N, un client possède 0 ou plusieurs comptes bancaires, mais un
compte bancaire peut avoir, au plus, 0 ou 1 client propriétaire (1-N). Il est possible de modéliser
l'ouverture de plusieurs comptes par la même personne, mais pas la copropriété d’un même
compte.

Cas 3 : Avec la cardinalité M-N, un compte peut appartenir à 0 ou n clients (m) et un client peut
avoir 0 ou plusieurs comptes (m). Cette structure modélise tous les cas mentionnés auparavant;
elle est la moins contraignante et très utilisée dans les MCD.

Remarque : Il existe plusieurs formalismes de modélisation conceptuelle souvent distincts les uns
des autres par la manière de formuler les contraintes de l’association. Le formalisme UML
s’inspire des contraintes de cardinalité pour proposer son propre codage des contraintes
d’association appelé multiplicité.

Contrainte de participation de E/A 
La  contrainte  de  participation  spécifie  si  la  présence  d’une  instance  est  liée  à  celle  dʹune  autre 
par  son  inclusion  (sa  participation)  obligatoire  ou  pas  dans  une  instance  d’association.  Elle  est 
aussi  dite  d’existence,  car  elle  spécifie  quʹune  entité  de  la  classe  peut  exister  sans  ou  avec 
lʹobligation de participer à une association. La participation à une association peut être totale (t) 
ou partielle (p). Cette notion complète celle de cardinalité introduite précédemment. 
 
Participation totale (ou obligatoire) 
Chaque  instance  doit  participer  à  une  association;  en  cas  de  suppression  de  lʹassociation, 
l’instance est aussi supprimée puisquʹelle ne peut exister sans participation à lʹassociation. 
 
la participation
Employe t t Departement
nas * Travaille no *
nom n 1 ville
Figure 3.19

Par exemple, la cardinalité de la figure 3.19, un employé travaille dans 0 ou 1 département et ce 
dernier  a  0  ou  plusieurs  employés  sur  la  liste  de  personnel.  Avec  l’ajout  de  la  contrainte  de 
participation  totale  (t),  si  un  employé  est  embauché,  il  doit  être  assigné  immédiatement  à  un 
département. Toutefois, si un employé est libéré, le département reste dans la base tant et aussi 
longtemps  qu’un  autre  employé  y  travaille.  La  participation  est  une  contrainte  qui  vient 
restreindre cette de la cardinalité. 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 99

 
Participation partielle (facultative) 
Examinons maintenant la contrainte de participation partielle dans le même MCD. 
 
la participation
  Employe Departement
nas * p t no *
  nom
Travaille
ville
n   1
la cardinalité
Figure 3.20 

Dans la représentation de la figure 3.20, la cardinalité sous-tend qu’un employé travaille dans 0
ou 1 département. Toutefois, en raison de la participation partielle (p) à l’association Travaille, un
employé peut être inscrit dans la base sans avoir une assignation de travail dans un département.
Un département a cependant l’obligation d’avoir (t) un ou plusieurs (n) employés pour être
représenté dans la base. D’autres cas sont possibles et doivent être pris en considération par le
concepteur. Par exemple, quelle est l’interprétation de la contrainte de participation partielle
attribuée à chaque côté de l’association? Un employé peut être inscrit dans la base sans avoir été
associé à un département particulier et un département peut être représenté dans la base sans
avoir d’employés.

Contrainte d’existence (Existence dependency) 
La participation totale d’un employé dans une occurrence de l’association Travaille est aussi
qualifiée de contrainte d’existence parce que la suppression d’une instance du département où
ceux-ci travaillent entraîne non seulement la suppression du département de l'association, mais
aussi automatiquement la suppression de ou des employés, puisque ces derniers ne peuvent pas
être dans la base sans une participation à l'association, i.e. sans département.

 
Employe Departement
  t t
nas *   Travaille no *
  nom ville
n 1
 
Figure 3.20a 
Par exemple lors de la suppression du département d1, tous les employés travaillant dans ce
département sont enlevés automatiquement de la base parce que leur représentation est interdite
sans une participation à une association. L'inverse aussi est vrai, lorsque qu'un employé quitte un
département, ce dernier est supprimé s'il cet employé est le dernier travaillant dans ce
département, sinon le département persiste en raison des autres employés qui sont au travail dans
d1. Lors de l'ajout d'une instance de département, par exemple le d4, il faut obligatoirement que
cette nouvelle instance participe dès sa création à une association avec un employé pour avoir au
moins un employé y travaillant. De même, l’employé e5 (par exemple défini par le nas e5 et dont
le nom est Picard) est ajouté à la base que s’il peut être mis en association avec un département
déjà créé.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 100

3.5 Contraintes structurelles (cs) fusionnant la cardinalité et la participation 
La fusion des contraintes de cardinalité et de participation s’exprime par les contraintes connues
sous le vocable de contraintes structurelles (cs) bien connues dans le formalisme Merise sous la
forme d'une paire d’entiers (min, max). Cette contrainte est aussi nommée min-max et sa lecture
dans un modèle est différente de celle de la cardinalité.

cs = ( contraintes de participation, contraintes de cardinalité)


 
Employe Departement
  nas *   (0, 1) Travaille (1, 100) no *   
  nom ville
contrainte structurelle
 
Figure 3.21 

Le premier entier de la paire exprime la participation : 0 pour partielle et 1 pour totale (ou
obligatoire). Le deuxième entier de la paire permet de préciser le nombre total d'instances de
l’autre classe avec lesquelles une première instance peut être en association. Ainsi, un employé
n’est pas obligé de travailler dans un département; au plus, il peut travailler dans un seul. Par
contre, un département doit avoir au moins un employé (participation totale) et peut avoir jusqu'à
100 employés. La partie max est précisée que si elle constitue une limite supérieure significative
qui devra être renforcée, au moment de l’implantation de la base de données, par un mécanisme
de validation de cette contrainte. Si le sens de la valeur max se limite à représenter la notion de
plusieurs, sa valeur est indéterminée. Le n ou m (ou encore N ou M) signifie plusieurs.

Participation partielle dans une association exprimée avec (min, max) 
Cette  contrainte  exprime  le  fait  quʹun  employé  puisse  être  représenté  sans  travailler  dans  un 
département (participation partielle); il peut cependant travailler dans plusieurs départements, 
soit au plus à 3 départements. 
 
 
Employe Departement
  nas * (0,3) (1, 100) no *
Travaille
  nom ville

 
Merise
 
Voici,  deux  autres  modèles  équivalents  utilisant  un  formalisme  différent.  Le  formalisme  E/A 
utilise les notions de participation et de cardinalité et sa lecture est légèrement différente.  
 
 
Employe Departement
  nas *
p t
no *
Travaille
  nom
100 3
ville
  E/A

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 101

Un  employé  peut  travailler  dans  au  plus  3  départements,  mais  il  peut  aussi  être  dana  la  base 
sans  participer  à  l’association  (p).  Un  département  peut  avoir  au  plus  100  employés  et  sa 
représentation dans la base suppose un assoication avec au moins 1 employé. 
 
Diagramme de classe de UML 
Le formalisme UML s’inspire de Merise, mais les contraintes d’association sont rendues par la 
notion de multiplicité positionnée de façon inverse au regard de celle du (min,max).  
  multiplicité
  Employe Departement
nas * 1..100 Travaille 0..3 no *
  nom FaitTravailler ville
  UML
 
Figure 3.21a 
Dans la figure 3.21a, la multiplicité 1..100 du côté Employe équivaut au min‐max de Merise pour 
la classe opposée, soit Departement. En UML, la lecture doit se faire ainsi : 1 employé travaille 
dans 0 département et au plus dans 3. Un département a obligatoirement 1 employé et au plus 
100. Le triangle indique le sens privilégié, mais non exclusive, de la lecture de l’association. Très 
souvent l’association inverse est sous‐entendue et partant, non représentée. 

Participation totale dans une association exprimée avec la notation (min, max) 
L’association Travaille du MCD de la figure 3.22 est dotée d’une contrainte min‐max pour coder 
la participation totale. En effet, un min égale à 1 signifie que chaque instance de Employe est en 
association obligatoire avec au moins un département. Le max est la cardinalité et représente le 
plus grand nombre de départements où peut travailler un employé. 

Employe Departement
nas * (1,3) (1,100) no *
Travaille
nom ville

 
Merise
Figure 3.22 
Le  codage  des  contraintes  d’association  en  UML  et  les  équivalents  avec  le  (min,  max)  et  les 
cardinalité de E/A sont fournies par le tableau ci‐dessous.  
 
E/A Merise UML
participation, cardinalité (min, max) multiplicité
p, 1 0, 1 0..1
t, 1 1, 1 1
p, n 0, n 0..*
t, n 1, n 1..8

Figure 3.21b

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 102

3.6 Traitement des attributs directement reliés à une association E/A 
Une  association  peut  aussi  avoir  ses  propres  attributs.  Dans  certains  cas,  une  telle  association 
peut  être  transformée  par  une  migration  de ses  attributs  vers  l’une  des  classes  participantes  et 
cela,  sans  que  la  capacité  de  représentation  du  modèle  soit  affectée.  Un  employé  travaillant  x 
heures à la réalisation dʹun ou plusieurs projets. Le traitement réservé à lʹattribut de lʹassociation 
dépend de la contrainte de cardinalité de part et dʹautre de cette association.    

Employe Departement
? Travaille ?
nas * nbHeure no *
nom ville

Figure 3.23
Voici le traitement d’un attribut dʹassociation pour les cas de figure possibles représentés par le 
point dʹinterrogation dans la figure 3.23. 
 
Cas 1‐1 avec participation totale des deux côtés 
L’attribut nbHeure peut être rattaché à l’une ou lʹautre des classes participantes à lʹassociation. 
Le  choix  peut  être  imposé  par  la  plus  grande  fréquence  d’accès  prévue  pour  un  attribut  ou  la 
sémantique même de la classe. Si cette structure est principalement fouillée par les applications 
par  le  biais  de  la  classe  Employe,  lʹattribut  heure  sera  placé  de  ce  côté.    Or,  du  point  de  la 
sémantique,  le  nombre  d’heures  est  plus  une  caractéristique  de  Employe  que  de  Departement. 
Dans le cas contraire, l’attribut peut être déplacé du côté Departement. 
 

Employe (1,1) (1,1) Departement


Travaille
nas * no *
nbHeure
nom ville

Employe (1,1) (1,1) Departement


nas * Travaille no *
nom ville
nbHeure E/A

Employe 1 Departement
1 Travaille
nas * no *
nom ville
nbHeure
UML

Figure 3.24 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 103

Pourquoi pas une seule classe EmpDep?


Un changement anticipé dans la contrainte de cardinalité justifierait de conserver cette
association dans le modèle comme une entité autonome avec les deux classes Employe et
Departement. Tout changement de multiplicité pour la contrainte d'association n’engendre pas
alors une réorganisation importante du modèle (donc de la base de données).

Cas 1‐1 avec une participation partielle dʹun seul côté de l’association 
Lorsque la participation est partielle, l’attribut de l'association migre du côté de la contrainte de
participation totale ou demeure attaché à l’association et cela, pour éviter autant que possible
l’utilisation de l’indicateur NULL pour l'attribut nbHeure. En outre, la sémantique justifie très
bien le nombre d’heures comme étant plutôt une caractéristique de l’employé que du
département.

Employe Departement
(1,1) Travaille (0,1) no *
nas *
nom ville
nbHeure

Figure 3.24a

Cas 1‐n avec une participation totale des deux côtés 
Soit la contrainte structurelle (1,1) du côté Employe et (1,n) du côté Departement. L’attribut
nbHeure est alors rattaché au côté (1, 1), soit celui de Employe. Dans la version E/A et UML,
l’attribut nbHeure est placé du côté Employe, i.e. de la classe enfant.
 
  Employe Departement
nas * (1,1) (1,n)
no *   
  Travaille
nom ville
nbHeure
 
  (enfant)
 
Employe (1,1) (1,n) Departement
  Travaille
nas * no *
  nom ville
  nbHeure
E/A
 
 
  Employe 1..* 1 Departement
Travaille
nas * no *
  nom ville
nbHeure
  UML
(enfant)  
 
Figure 3.25 
L'employé qui travaille pour un seul département doit fournir le nombre d’heures de travail pour
l'unique département auquel cet employé est associé. Avec cette contrainte, un employé ne peut

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 104

pas travailler dans plusieurs départements différents.

Le transfert de l'attribut nbHeure du côté de Departement est en théorie possible, mais serait plus
difficile à lire et devra faire appel à une structure de données physique dynamique ayant autant
d’entrées que de départements et cela, pour chaque employé. Il faut donc dans ce cas avoir un
attribut multivalué. Avec la technologie relationnelle, cette approche n’est donc pas possible, car
les seules structures disponibles pour les attributs sont de type élémentaire. Il en sera autrement
avec la technologie objet-relationnelle qui offre des structures de stockage de type ensemble pour
un attribut.

Cas n‐m avec une participation totale des deux côtés  
Dans ce cas l’attribut peut rester attaché à l’association Travaille. Il sera traité au moment du
passage au modèle logique.

  Employe Departement
  nas * (1, 2) Travaille (1, 150) no *
nom nbHeure ville
 
 
Figure 3.26 
Cette structure conceptuelle examinée au niveau des instances de données possède plusieurs
caractéristiques sémantiques :

a- Un département a obligatoirement 1 employé et au plus 150.

b- Un employé travaille obligatoirement dans 1 département et au plus dans 2 départements.

La version UML de ce modèle fait appel à une classe d’association dont la structure comprendra
l’attribut nbHeure. La classe d’association est rattachée à l’association par une ligne pointillée.

 
  Employe Departement
nas *   1..2 1..150 no *   
 
nom ville
 
  Travaille
nbHeure 

UML

La classe d’association peut en sus participer à une autre association dans le même modèle.

3.7 Classe d’entités faibles et fortes du modèle E/A 
La plupart des classes d'un MCD sont fortes en ce sens que les entités sont distinctes les unes des
autres par une clé primaire. Dans certains modèles, cette clé n'est pas toujours disponible ou
identifiable comme étant capable de distinguer chaque instance. Il s’agit alors d’une classe dite
faible. La modélisation avec une classe faible peut être évitée en la remplaçant par une
© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 105

association entre deux classes fortes rendu possible par la migration de la clé primaire de l’autre
classe participante.

Classe faible dans le modèle E/A 
Une classe faible est asservie à celle d'une autre classe dite dominante. Supposons que les salles
de réunion des ministères sont représentées par une classe Ministere et une autre Salle. Chaque
salle de réunion au sein d’un ministère est identifiée par un numéro et ces derniers sont uniques
au sein d’un même ministère, mais pas nécessairement dans l’ensemble des ministères. Ce
numéro n’est donc pas une clé mais un discriminant (d) parce qu’il permet d’identifier une salle
que dans un ministère. Deux salles dans des ministères distincts peuvent donc avoir le même
numéro. L’unicité du numéro de salle n’est pas assurée au niveau global.

Ministere  Ministere Ministere


nomMin* nomMin* nomMin*
adresse adresse adresse

1, n noS 1, n

EstDans EstDans EstDans


1, 1
 
1, 1  1..* 1, 1
Salle  Salle Salle
  noS (d) capacite nomMin*
capacite noS*
capacite

E/A (a) (b) UML (c)


E/A
Figure 3.27
Les instances de Salle associées dans un même ministère sont différentiées par le numéro de la
salle (noS). Ce type de Classe est dit faible et l’attribut noS est son discriminant. La modélisation
avec une classe faible peut coller davantage à la réalité. Elle peut être toutefois remplacée par une
association entre deux classes.

Voici un autre exemple dans lequel la classe des enfants est faible parce que plusieurs ont le
même prénom, le même nom, le même sexe et sont nés le même jour. Tous les attributs de ;a
classe Enfant ne peuvent pas être une clé pour distinguer les instances entre elles. 

Employe (0,n) Enfant


(1,1)
nas* prenom (d)
nom ACharge nom(d)
dateNaiss dateN
  (classe forte) sexe
  (classe faible)

La participation totale est du côté de la classe faible 
Figure 3.28 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 106

Toutefois, les enfants d’un même employé (sous-ensemble de Enfant) sont distincts les uns des
autres par leur prénom et leur nom. Les attributs nom et prénom forment donc un discriminant
de la classe faible Enfant dont la classe forte est Employe. Une classe faible est toujours l'objet
d'une contrainte de participation totale, (1,1). De sorte que la suppression d'un employé dans la
base entraîne aussi celle de ses enfants . Il ne pourrait pas y avoir dans la base deux enfants sans
parent (participation partielle), car dans ce cas deux enfants sans parent qui pourraient avoir le
même discriminant ne sauraient être distincts.
Il peut y avoir plusieurs classes faibles dans un même modèle. Elles peuvent être aussi en
cascade comme l'illustre la figure 3.29.
 
Transformation de la classe faible 
La transformation d’une classe faible en une classe forte est simple et s'effectue normalement lors
du passage au modèle logique.

La classe faible est transformée ainsi :


a) Une classe faible peut être fusionnée avec sa classe propriétaire forte et être représentée par un
attribut composé ou multivaleur;

b) Une classe faible peut être transformée en classe forte par l’adjonction des clés primaires des
classes fortes associées directement ou indirectement par l'entremise d'une cascade de classes
faibles (figure 3.29). Le choix de la représentation est souvent laissé au concepteur, mais il peut
être fait en fonction de la performance et en tenant compte des accès prévus à la base. Les classes
transformées deviennent des classes fortes et peuvent être mises éventuellement en association
avec d'autres classes. La classe au bas du MCD a une clé obtenue par la juxtaposition de la clé
de la classe forte avec les discriminants des classes faibles.

  B C
A
a1* b1* c1*
a2 b2 c2

clé composée

A B C
a1* a1*, b1* a1*,b1*,c1*
a2 b2 c2

Transformation d'une cascade de classes faibles en classes fortes E/A


Figure 3.29

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 107

                                                             
Classe faible dans une association ternaire 
L'association ternaire est admise dans la modélistion E/A, mais son usage est plutôt rare car elle
est difficile à interpréter. Dans l'exemple ci-dessous l’association ternaire est composée de trois
classes dont une est faible. Le discriminant est composé des attributs {date et cout}, c'est-à-dire
du coût et de la date du projet. Ainsi, deux instances de Projet ayant les mêmes valeurs pour le
discriminant peuvent être présentes dans la même classe, à la condition d'avoir un propriétaire
différent, soit dans ce cas une instance différente de l'association binaire Realise.

  Client 0,1 0,n Constructeur


nas* Realise nom*
 
nom ville
  1,m
 
Projet
  date(d)
cout (d) Offre
  Inscrire no*
chef
  E/A 
 
Figure 3.30 
Exemple : Deux instances de Projet qui ont le même discriminant (dont les attributs sont
identifiés par un (d)) correspondent forcément à deux projets différents, car chacun est associé à
une combinaison différente de Client et Constructeur.

Constructeur
Client 

Projet Offre
: 2 instances avec même discriminant

La transformation de ce modèle pour obtenir seulement des classes fortes est relativement simple.
Elle se fait par l’adjonction des clés des classes participantes au discriminant de la classe faible,
Client, Constructeur et Offre.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 108

Client
Constructeur
nas* Realise nom*
nom
ville

nouvelle Projet
clé composée nas *
nom* Offre
de la classe Inscrire no*
Projet no*
date*
cout*
chef

Figure 3.31
 
Deux  instances  de  la  nouvelle  classe  forte  Projet  sont  alors  distinctes  par  leur  clé  primaire 
composée. 

Exclusion et inclusion des associations 
Par  défaut,  une  instance  peut  participer  à  plus  de  deux  associations.  Ainsi,  les  instances  du 
modèle ci‐dessous, figure 3.31, un chef de projet peut travailler avec une équipe internationale 
au développement de logiciels et il peut en même temps diriger une équipe locale.   
 
    
ChefProjet
 
                1,n 0,n
                
  Dirige
Participe
 

1,1 1,1
EquipeInter EquipeLocal E/A

Figure 3.31

Voici un exemple d'un ensemble d'instances valides pour ce MCD. L’association Participe est
représentée au niveau des instances par le trait continu, tandis qu’une instance de Dirige utilise le
trait pointillé.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 109

cp1 cp2 cp3 cp4


Dirige
Participe
Les instances
du modèle E/A

eqIn1 eqIn2 eqIn3 eqLo1 eqLo2

Figure 3.31a

Le chef de projet ‘cp2’ participe à une équipe internationale 'eqIn2' sans autre participation au
niveau local. Le chef de projet 'cp3' participe à l'équipe internationale 'eqIn3' et dirige aussi
l'équipe locale eqLo1.

Si la modélisation imposait qu'un chef d'équipe participe ou dirige, mais pas les deux (le OU
exclusif), il faudrait ajouter cette contrainte entre les deux association dans le modèle, comme
cela est illustré la figure 3.31b.
ChefProjet
1,n 0,n
+
Dirige
Participe

1,1 1,1
EquipeInter EquipeLocal E/A

Figure 3.31b

Le modèle UML équivalent comporte une ligne pointillée pour représenter l’exclusivité mutuelle
des associations.

ChefProjet

1..1 1..1 Exclusivité mutuelle 


entre deux associations 

Participe Dirige
1..* 0..*
UML
EquipeInter EquipeLocal
 

Figure 3.32

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 110

Les instances valides pour ce modèle sont les suivantes :

cp1 cp2 cp3 cp4


Les instances
du modèle
E/A
eqIn1 eqIn2 eqIn3 eqLo1 eqLo2

La figure 3.33 présente un MCD E/A un peu plus complexe avec les contraintes exprimées par le
(min, max). Nous conviendrons qu'un attribut composé sera codé (0) et que ses composants
hiérarchiques seront notés d'après leur niveau. Ensuite, un attribut multivaleur sera noté (mv).
Cette notation a l'avantage d'être plus compacte que celle du modèle d'origine parce que les
attributs ne sont pas déployés dans l'espace autour du symbole de classe, mais plutôt regroupés à
l'intérieur de celle-ci.

(0,n)
Employe  (1,1) (1,n) Departement
nas* Travaille no*
Supervise patronyme(0) nom*
nom (1) localisation (mv)
prenom(1) (0,1) (1,1) nbEmploye
Gere
dateDebut
(0,n)
(0,1) (1,n) (0,n)
 

Controle
ACharge

(1,1)
Projet
no*
(1,n) nom*
Participe site
(1,1)

Enfant
prenom(d)
nom(d)
dateNaiss
sexe
E/A

Figure 3.33

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 111

La notion de facette dans les modèles conceptuels  complexes 
Lorsquʹil  s’agit  de  modéliser  une  organisation  beaucoup  plus  complexe,  il  peut  arriver  que 
lʹanalyse informatique identifie plus de 200 classes différentes. Chacune est définie par plusieurs 
attributs sensiblement plus diversifiés que ceux des petits modèles académiques. Pour simplifier 
le  modèle  et  son  interprétation,  le  MCD  global  peut  être  divisé  en  facettes,  chacune 
correspondant  à  une  partie  du  modèle,  à  laquelle  est  rattachée  une  sémantique  complète  et 
cohérente. Ainsi, le MCD ci‐dessus pourrait comporter une facette pour les projets en cours, une 
autre pour la partie ressources humaines et charges familiales. Toutes ces facettes constituant le 
modèle  conceptuel.  C’est  aussi  une  façon  d’alléger  et  de  faciliter  l’interprétation  du  MCD  en 
n’utilisant que la facette nécessaire au traitement prévu. 
 

Facette A
Facette B

Figure 3.34

Les autres formalismes proposés sont distincts essentiellement par la manière d’exprimer les
cardinalités et les contraintes de participation dans les associations. Le langage graphique de ces
variantes s'inspire largement du formalisme de représentation à objets comme par exemple le
formalisme Object Modeling Tool (OMT) et surtout le langage UML qui regroupe toutes ces
notions au sein du même formalisme.

Il y a plusieurs autres formalismes proposés par différents auteurs dont la popularité est basée
davantage sur des considérations de commercialisation que sur des fonctionnalités particulières
qui leur donneraient une plus grande capacité de modélisation et un passage plus direct au
développement des applications. Entre la méthode de X et celle de Y, il n’y a hélas trop souvent
que des différences syntaxiques! Toutefois, le paradigme objet gagne du terrain (voir UML pour
Unified Modeling Language) parmi les développeurs. Le passage vers cet univers objet sera
accentué avec l'augmentation des logiciels et des outils de développement orientés objets pour la
modélisation des données et des traitements. La publication de normes UML est certainement
une façon d’accélérer son usage dans le développement des bases de données et du logiciel. 3.9
© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 112

Agrégation de classes
Couplage faible
L'agrégation ou la composition correspond à une abstraction qui génère une classe définie,
notamment (parce que cette classe peut avoir aussi d’autres attributs) par une ou plusieurs
classes existantes. L’agrégation n’a pas obligation d’avoir nom particulier. C’est en quelque
sorte une association particulière entre une classe qui représente un tout et une autre, une partie
de ce tout. Lorsque les instances d’une classe sont composées avec des objets d’une ou plusieurs
autres classes, il s’agit probablement d’une agrégation. Cette abstraction n'est pas courante dans
la pratique actuelle de la modélisation conceptuelle des données en E/A mais le deviendra avec le
diagramme de classe UML. Son usage est justifié lorsque la modélisation concerne des
organisations ou des réalités complexes.

La figure ci-dessous est un exemple simple qui pourrait faire appel aux seules associations. Nous
l’utiliserons cependant pour présenter de façon équivalente l’agrégation de deux classes. Des
instances de Personne et Batiment peuvent être dans la base, même s’il n’y a pas de propriété
légale associée. Il s’agit dans ce cas d’une agrégation qui sous-tend un couplage faible. Avec un
tel couplage, la suppression d’une propriété légale donnée (instance) n’entraîne pas
obligatoirement celle de la personne et du bâtiment. L’instance de Batiment disparaît, mais celle
de Personne n’est plus associée avec l’instance de propriété légale, mais reste dans la base parce
qu’elle possède un compte bancaire. Une agrégation est en premier une association particulière
et à ce titre possède ses contraintes de multiplicité.

ProprieteLegale
  couplage faible 
multiplicité  de « plusieurs » noActeLegal * 

0..1 agrégation 0..1


1..* 1..1
Personne Batiment
CompteBancaire 
Possede nas* noBat*
noC*
valeur
soldeC 0..1 1..1 nom
adresse taxe
margeC

Agrégation et leur multiplicité


Figure 3.35
 
Ainsi, la suppression d’un titre de propriété légale n’entraîne pas celle des personnes impliquées 
si  elles  participent  à  l’association  Possede.  Par  contre,  le  bâtiment  qui  fait  l’objet  de  l’acte  de 
propriété légale est supprimé. En ajout, un bâtiment peut être créé dans la base sans être associé 
à un acte propriété légale. 

Agrégation de composition (couplage fort) 
Par contre, une agrégation avec un couplage fort est appelée une composition; elle sous-tend
l’existence des instances des classes agrégées que si la classe composée est aussi créée. Avec le

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 113

modèle de la figure 3.36, une instance de document est représentée par la composition de
plusieurs chapitres et d’un index du document. Si par la suite, cette instance est supprimée, cela
entraîne aussi la suppression des chapitres et de l’index de celui-ci.

Document
ISBN*
titre
couplage fort

1 1
1..* 1
Chapitre Index
police nbEntrees
format style

Figure 3.36

Dans ce cas, l’existence d’un chapitre ou d’un index est présumée sans intérêt en dehors de
l’existence du document.

Agrégation et association 
Dans lʹexemple de la figure 3.35, la classe ProprieteLegale est définie comme lʹagrégation faible 
des classes Personne et Batiment. Il est possible de représenter en E/A cette classe agrégée par la 
création  dʹune  seule  classe  intégrant  les  sous‐classes  qui  la  composent  et  dont  la  clé  est 
composée avec celle de chaque composante en sus de ses propres attributs. 
 
Personne Batiment
nas* noBat*
nom EstProprio valeur
adresse (1, n) (1, 1) taxe

Représentation de l'agrégation par une association binaire en E/A


Figure 3.37
      
Agrégation avec les classes et les associations E/A
Pour représenter le nombre d'heures d'opération d'une machine par un employé dont une
partie du temps est consacré à un projet, il faudrait pouvoir modéliser cette information en
créant une association entre deux associations (figure 3.37a).

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 114

Employe
matricule* Projet
nom (0,n) Travaille (1,m) noProjet*
adresse nbHeures ville

Opere
nbHeures

Machine
noMachine*

Association interdite par la modélisation E/A


Figure 3.37a

L'attribut nbHeures de l’association Opere représente le nombre d'heures d'opération d'une


machine de production par un employé lorsque ce dernier travaille un certain nombre d’heures
sur un projet donné. Or la grammaire E/A interdit une telle association. En outre, deux
associations binaires ne modélisent pas entièrement toute l’information. La valeur nbHeures de
Opere est plus petit que nbHeures de travaille. À la limite, les deux attributs seront égaux. Pour
contourner cette difficulté, une association ternaire pourrait être utilisée, mais elle représenterait
une seule association héritant des attributs nbHeures de Travaille ou le nbHeures de l'association
Opere (figure 3.37b). Or, on ne peut plus savoir avec une ternaire s'il s'agit du nombre d'heures
travaillées sur un projet ou celui consacré aux commandes d'une machine! Il y a donc une perte
d'information. Le renommage des attributs nbHeures pour nbHeuresProjet et nbHeuresMachine
pourrait résoudre cependant l’ambiguïté.

Employe
matricule* (1,n) Projet
nom (1,m)
TravailleOper noProjet*
adresse nbHeures ville
nbHeures

(1,2) Ambiguïté possible


entre les deux attributs
Machine
noMachine

Représentation E/A avec une association ternaire


Figure 3.37b
 
Une  autre  solution  consiste  à  faire  une  agrégation  des  deux  classes  (Employe  et  Projet)  avec 
lʹassociation  Travaille  pour  obtenir  une  nouvelle  classe  agrégée  que  lʹon  peut  nommer 
EmpProjet.  Cette  agrégation  permet  donc  de  respecter  la  grammaire  du  formalisme  E/A  avec 
© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 115

une  classe  agrégée  dont  la  clé  est  composée  des  clés  primaires  des  classes  composantes.  Les 
autres attributs sont ceux des classes qui composent lʹagrégation.               
 
  Employe
                 matricule* Projet
nom (0,n) Travaille (1,m)
noProjet*
adresse nbHeures ville

EmpProj

Opere
nbHeures
classe agrégée 
(1,2)
Machine
noMachine*

Agrégation des classes et dʹune association en E/A 
Figure 3.37c 
Dans cette abstraction de type agrégation, la formation d'une classe (agrégée) n'est pas
représentée au moyen d'un symbole spécial, mais simplement par un rectangle représentant la
nouvelle classe. Avec une telle modélisation, toute l'information est représentée avec plus de
précision. Le passage au modèle relationnel se fait par des règles simples qui seront étudiées dans
le chapitre traitant de la transposition du MCD au MRD (relationnel).

Voici un autre exemple de la modélisation avec une association ternaire.


                                                     Classe d’association
Installation UML
dateInstal

1..1

Logiciel  Serveur
noSerie* 0..* 1..* IP*
Installer
fournisseur categorie

1..1
Laboratoire 
noLabo* ULM
budget
chef

Figure 3.37d

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 116

Il s’agit de modéliser l’installation de logiciels outils (traitement de texte, éditeur de HTML,


système d’exploitation,…) sur les serveurs et cela suite aux demandes des divers laboratoires
scientifiques. Chaque demande d’installation est faite à une date donnée.

La classe d’association étant une classe à part entière, elle peut donc être en association avec
d’autres classes, voire même être spécialisée.

Les multiplicités précisent la sémantique de représentation du diagramme de classe de la figure


3.37d :

a- Un couple (Serveur, Laboratoire) peut avoir accès à 0 ou plusieurs logiciels. Par exemple, le
serveur 220.234.223.24 du laboratoire de phytologie a accès aux logiciels Word Perfect et à
SAS.

b- Un couple (Logiciel, Serveur) peut être en association qu’avec un laboratoire


Par exemple le couple (ProteinSoft, 220.234.223.24) peut être associé qu’avec un laboratoire soit
celui de biochimie.

c- Le couple (Laboratoire, Logiciel) peut être associé avec serveurs. Par exemple, le laboratoire
de biochimie et le logiciel se retrouvent que sur le serveur 220.234.223.24.

En résumé, un logiciel commandé par un laboratoire ne peut être installé que sur un seul serveur.

3.10 Interprétation d’une ternaire


Le diagramme de classe UML ci-dessous illustre quelques cas de modélisation et souligne les
carences et lourdeurs possibles de la ternaire dans un modèle conceptuel. Il faut aussi noter que la
sémantique de la ternaire dépend fortement des multiplicités de l’association. Dans ce modèle, un
prospect qui devient un client réel exige de l’application qu’une partie des informations de son
instance soit recopiée dans une nouvelle instance de la classe Client malgré le fait que cette
information soit déjà dans la base. Finalement, les classes Client, Vendeur et Prospect partagent
un certain nombre d’attributs de même domaine. Ce constat doit évoquer chez le DBA l’idée que
l’abstraction d’héritage devrait apporter une contribution significative non seulement lors de la
modélisation, mais aussi au stade de l’exploitation.

1- Multiplicité * pour les trois classes de la ternaire


L’association ternaire a une multiplicité * pour classe participante ce qui permet à celle-ci d’avoir
une représentation très vaste.

Le MCD comporte une ternaire qui se lirait ainsi lorsque les instances sont représentées par les
valeurs de clé comme par exemple v1 pour désigner le matricule (valeur de clé) d’un vendeur
particulier, cl1, pour le numéro d’un client particulier et co1 pour le numéro d’une commande
particulière :

‐ Un vendeur et un client rédigent 0, 1 ou plusieurs commandes : (v1, c1, co1) , (v1, c1,co2),
(v2, c1, co2), … sont des instances valides de l’association Redige.
‐ Une paire composée d’un vendeur et d’une commande peut être associée à 0, un ou plusieurs
clients : (v1, cl1, co1), (v1, cl1, co2), (v1, cl2, co1), …
© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 117

‐ Une paire composée d’un client et d’une commande peut être associée à 1 ou plusieurs
vendeurs : ( v1, cl1, co1), (v2, cl1, co1), …

Vendeur Client
matricule* 1..* Redige
1..* noC*
nom nom
dateNaiss tel
fonction email
0..*
email adresse
tel Commande codePostal
noCom* ville
1 dateCom fonction
Contacte
0..* email
0..*
t l
Prospect 1
email* Requiert Recoit
nom qte 1..*
prenom 1..*
tel Facture
adresse Produit noF*
ville noProd* dateF
codePostal prixCatalogue
TVQ

Entre d’autres mots et compte tenu des multiplicités de la ternaire, toute combinaison des valeurs
de clé représente une instance valide de l’association Redige. En faisant référence à la notion de
dépendance fonctionnelle entre les attributs, on peut énoncer que cette ternaire Redige dotée des
cardinalités (*) n’a aucune dépendance fonctionnelle entre ses attributs i.e. au sein de la
définition de la classe :

matricule, noC -/-> noC matricule, noCom -/-> noC


noCom, noC -/-> matricule

Toutefois, cela n’exclut pas certaines dépendances fonctionnelles entre les attributs de deux
classes, notamment entre les clés primaires. Cette question sera à nouveau soulevée un peu plus
loin.
N.B. La notion de dépendance fonctionnelle sera étudiée avec le modèle relationnel. Brièvement,
une dépendance (DF) existe entre un attribut A et B, si pour chaque valeur de A correspond une
seule valeur de B : AÆ B.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 118

2- Multiplicité * pour deux classes de la ternaire


Dans le modèle ci-dessous, il y a une multiplicité est de 1. Dans un tel cas, toute combinaison
d’un vendeur avec une commande est associée avec un seul client. Les instances de l’association
(v1, co1, cl1) et (v1, co2, cl1), (v2, co1, cl1) sont valides. Par contre, l’instance (v1, co1, cl2) est
alors non valide et exclue. Il n’y a pas deux clients sur la même commande et qui relève du même
vendeur.

Vendeur Client
matricule* 1..* 1 noC*
Redige
nom nom
dateNaiss tel
fonction email
1..*
email adresse
tel Commande codePostal
noCom* ville
Contacte 1 dateCom fonction
0..* email
0..*
Prospect 1
email* Requiert Recoit
nom qte
1..*
prenom 1..*
tel Facture
adresse Produit noF*
noProd* dateF
ville
prixCatalogue
codePostal
TVQ

Cette exclusion découle aussi de la présence d’une dépendance fonctionnelle déduite de la


multiplicité 1 de la ternaire du MCD :

{matricule, noCom} Æ noC

Par contre, toute combinaison {Client, Commande} ou {Vendeur, Client} peut être associée
respectivement avec une instance quelconque de Vendeur et de Commande. Ces contraintes
respectent la multiplicité 1 du côté de la classe Client.

3- Multiplicité * pour une seule classe de la ternaire


Dans ce cas de figure, toute combinaison peu importe le Vendeur, mais avec toujours le même
Client doit être associée qu’à une seule Commande. C’est une situation d’affaires peu réaliste !
De même, toute combinaison peu importe le Vendeur avec toujours la même Commande doit être
associée qu’à un seul Client (i.e. à une seule instance de Client). C’est légèrement plus réaliste si
l’importance de la commande l’exige! Par exemple, la vente d’un avion à un client peut exiger
l’intervention de plusieurs vendeurs sur la même commande. Bien entendu, c’est la sémantique
que sous-tend la réalité à modéliser qui impose ou pas cette multiplicité.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 119

Vendeur Client
matricule* 1..* 1 noC*
Redige
nom nom
dateNaiss tel
fonction email
1
email adresse
tel Commande codePostal
1 noCom* ville
Contacte dateCom fonction
0..* email
0..*
1
Prospect Recoit
email* Requiert
nom qte
prenom 1..*
1..*
tel Facture
adresse Produit noF*
ville noProd* dateF
codePostal prixCatalogue
TVQ

Les dépendances fonctionnelles valides présentes dans ce MCD sont les suivantes :

{matricule, noC} Æ noCom {matricule, noCom} Æ noC

Selon les propriétés des dépendances fonctionnelles, il est impossible de dériver les DF
matricule Æ noCom et noC Æ noCom de celle {matricule, noC} Æ noCom .

4- Multiplicité 1 pour chaque classe participante à la ternaire


Dans ce cas de figure, une combinaison seulement, par exemple {v1, cl1} peut être associée à
une seule commande co1. Donc la combinaison (v1, cl1, co1) est admissible. Par contre, la
combinaison (v1, cl1, co2 ) est exclue de par la multiplicité de la ternaire. En même temps, la
combinaison (v1, co2, cl1) est admissible. Donc à un client donné, il n’ya pas qu’une seule
commande.

Les dépendances fonctionnelles suivantes sont alors valides :

{matricule, noC} Æ noCom {matricule, noCom} Æ noC


{noCom, matricule} Æ noCom

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 120

Vendeur Client
matricule* 1 1 noC*
Redige
nom nom
dateNaiss tel
fonction eMail
1
email adresse
tel Commande codePostal
noCom* ville
1
Contacte dateCom fonction
0..* email
0..*
Prospect 1
Requiert
email* Recoit
qte
nom
prenom 1..*
1..*
tel Facture
adresse Produit noF*
noProd* dateF
ville
prixCatalogue
codePostal
TVQ

Autres observations de la réalité qui sous-tend des dépendances entre deux classes
Cependant, il peut arriver que la réalité impose une dépendance fonctionnelle (DF) entre deux
classes de la ternaire. Par exemple, il est très fréquent que le numéro d’une commande identifie
qu’un seul client : noCom Æ noC.

Vendeur Client
matricule* 1..* 1..* noC*
nom Redi nom
dateNaiss tel
fonction eMail
1
email adresse
tel Commande codePostal
noCom* ville
Contacte 1 dateCom fonction
0..* email
0..*
Prospect 1
email* Requiert Recoit
nom qte
prenom 1..*
1..*
tel Facture
adresse Produit noF*
ville noProd* dateF
codePostal prixCatalogue
TVQ

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 121

En outre, il est possible que le client ne fasse affaire qu’avec un seul vendeur peu importe la
commande : noC Æ matricule. Si ces contraintes fonctionnelles sont intégrées au MCD doté
d’une ternaire (comme c’est le cas avec Merise avec la notion de CIF, soit la contrainte
d’intégrité fonctionnelle), il devient parfois possible de transformer le modèle en remplaçant la
ternaire par deux associations binaires. Les deux dépendances fonctionnelles ont été ajoutées au
MCD. En ce faisant, la sémantique de la ternaire est davantage précisée. Cette situation souligne
l’inadéquation dans ce cas de la ternaire telle qu’elle a été formulée initialement sans prendre en
compte les dépendances dans une paire de clases.

Ce MCD est transformé par le remplacement de la ternaire avec deux associations binaires. Par
contre, ces CIF entre deux classes ne simplifient la lecture du modèle du modèle conceptuel si la
ternaire y reste présente.

Vendeur Client
matricule* 1 Dessert 1..* noC*
nom nom
dateNaiss tel
fonction email
email 1..* 1 adresse
tel Commande Redige codePostal
noCom* ville
Contacte 1 dateCom fonction
0..* email
0..*
Prospect 1
email* Requiert Recoit
nom qte
prenom 1..*
1..*
tel Facture
adresse Produit noF*
ville noProd* dateF
codePostal prixCatalogue
TVQ

En  conclusion,  la  ternaire  est  difficile  à  interpréter  et  si  son  usage  s’avère  utile  voire  parfois 
nécessaire, il faut apporter une attention particulière au choix des multiplicités.  Il est cependant 
préférable  de  l’éviter  en  la  remplaçant  par  une  structure  incluant  une  classe  faible  ou  dans 
certains cas par des associations binaires.   
 
Modèle conceptuel de données : Abstractions d’héritage 
Généralisation et spécialisation 
La généralisation est le processus de formation d’une classe générique à partir de plusieurs
classes existantes. La spécialisation9 est l'abstraction inverse, soit la formation de classes
spécialisées à partir d'une classe existante appelée générique. L’abstraction de

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 122

généralisation/spécialisation a des propriétés particulières : couverture et partionnement. La


couverture est dite totale, si toute instance de la superclasse est aussi une instance d'une sous-
classe. Elle est dite partielle, s'il existe des instances qui ont le type de la superclasse seulement.
Le partitionnement est dit exclusif si une instance de la superclasse n’existe qu'avec le type d'une
seule sous-classe, tandis que la spécialisation est dite avec chevauchement (non disjointe), si la
même instance identifiée existe simultanément avec le type de plusieurs sous-classes. Dans les
pages suivantes, nous revenons sur ces notions en les illustrant avec plusieurs exemples. Nous
donnerons aussi les modèles avec le formalisme UML.

3.10 Généralisation 
La généralisation est assortie d’un mécanisme fort important, soit celui de l'héritage par les sous-classes des attributs
et des méthodes de la classe supérieure dans une hiérarchie de classes. Dans un contexte objet, une
propriété importante est que tout objet qui est stocké avec une sous-classe soit éventuellement
stocké dans l'extension de la superclasse parce que les règles de typage de la superclasse sont
aussi vérifiées par les instances de la sous-classe. Une sous-classe étend donc la spécification de
la superclasse et a la propriété de substitution c’est-à-dire que ses objets peuvent cohabiter sur
disque avec ceux de la superclasse. En termes du relationnel, la création d’une instance se traduit
par la création de un ou plusieurs tuples rangés par l'application dans les tables relationnelles
créées pour implanter la hiérarchie des classes du MCD. Ce passage aux tables se fait selon des
règles précises que nous verrons dans un autre chapitre.

Pour un environnement de modélisation relationnelle, lorsque deux ou plusieurs classes partagent


certains attributs identiques, il est possible de réduire la redondance des attributs au niveau du
schéma par la création d’une classe générique dont la structure (le type) est spécifiée par les
attributs communs. Cette abstraction de généralisation renforce la sémantique du modèle et
permet parfois de faciliter la découverte de nouvelles associations impliquant la nouvelle classe
générique. Il en est de même pour les associations qui peuvent être aussi généralisées et
regroupées au niveau de la superclasse.

Dans l'exemple ci-dessous, les deux classes partagent deux attributs qui justifient la création
d'une superclasse VéhiculeDeuxRoues. L’analyse informatique révèle la présence de deux types
d’instances regroupées dans deux classes apparemment sans lien. Cependant, ces deux classes
partagent des attributs qui serviront à créer la superclasse.

Moto Velo
noSerie* noSerie*
puissance  composite
prix prix

Les attributs communs entre Moto et Velo (signalés par la ligne pointillée) ont le même domaine
et donnent naissance à une abstraction de généralisation.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 123

VehiculeDeuxRoues VehiculeDeuxRoues
noSerie* noSerie*
prix prix

{c,d}
t,e

Velo Moto Velo


Moto composite
puissance composite puissance
 
E/A Figure 3.38a  UML
 
Dans  cette  abstraction,  toute  instance  d’une  sous‐classe  vérifie  aussi  le  type  de  la  superclasse. 
Une moto est aussi un véhicule à deux roues. La généralisation est totale et exclusive. Au niveau 
conceptuel,  ceci  signifie  que  toute  instance  de  la  superclasse  est  soit    une  moto,  soit  un  vélo 
(figure 3.38a), mais pas les deux simultanément. Aucun autre véhicule à deux roues ne peut être 
représenté  par  ce  modèle  à  moins  de  redéfinir  les  propriétés  de  couverture  pour  la  rendre 
partielle. Les attributs de la superclasse sont ceux qui sont communs aux sous‐classes. Il en sera 
de  même  dans  un  contexte  objet  qui  permet  d’associer  des  procédures  ou  des  méthodes  à  la 
superclasse. Celles‐ci seront alors aussi accessibles par les sous‐classes et cela, par lʹentremise du 
mécanisme  de  lʹhéritage.  Au  besoin,  il  est  aussi  possible  de  redéfinir  ces  procédures  (appelées 
aussi les méthodes). Le modèle relationnel n’intègre pas directement la propriété de lʹhéritage; 
une transformation s’imposera donc pour la concrétiser au niveau du schéma relationnel.  

L'abstraction de généralisation n'exclut par la possibilité que les sous-classes n’aient aucun
attribut propre dans le MCD. Par exemple, dans la généralisation des motos et des vélos, il serait
possible d'avoir la structure de la figure 3.38b. Les sous-classes peuvent quand même participer à
des associations avec d'autres classes du modèle.

On peut aussi se faire une image logique de cette spécialisation totale de VehiculeDeuxRoues en
concevant un véhicule à deux roues comme un objet en correspondance totale avec son image
(voir figure 3.39) au niveau des sous-classes qui sont regroupées autrement : les vélos dans une
classe et les motos dans une autre.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 124

VehiculeDeuxRoues VehiculeDeuxRoues
noSerie* noSerie*
prix prix

{c,d}
t,e

Moto Velo
Moto Velo

Appartient
Appartient

Personne
Personne nas*
  nas* nom
E/A UML
nom

Figure 3.38b 

Il faut se garder de penser que les objets sont dupliqués dans la base de données en raison de leur
instanciation dans la superclasse et de leur spécialisation. En fait, il peut y avoir un seul objet qui
intègre toutes les structures d’une hiérarchie des classes illustrées par la figure 3.39. Tous les
véhicules avec une spécialisation (t,e) sont regroupés totalement en deux groupes disjoints: les
motos et les vélos. Si la classe VéhiculeDeuxRoues ne participe pas elle-même à une autre
association, elle est abstraite et pourrait être supprimée lors de l'implantation. Une instance moto
aura donc une structure imposée par le modèle, à savoir qu’elle est formée avec les attributs
hérités auxquels sont ajoutés les attributs spécifiques de la classe Moto.

v1 v2 v3 v4 v5

t, e classe abstraite (avec des


instances virtuelles)

m1 m2 v3 v4 v5
     
 
Instances de moto Instances de vélo
 
Figure 3.39 
L'image qu'il faut avoir de cette spécialisation est celle de la figure 3.39. Les instances de la
superclasse sont classées de deux façons : en moto ou en vélo. En raison de la spécialisation

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 125

totale, les instances de la superclasse sont illustrées mais elles ne sont pas implémentées. Elles
sont en quelque sorte virtuelles puisque leur réalisation se fait dans les sous-classes. Avec une
spécialisation partielle, la classe n’est plus abstraite et les objets correspondent alors des
instances physiques de la superclasse.

Généralisation/spécialisation définie par un prédicat ou par lʹapplication 
Une instance de la classe générique peut aussi avoir un attribut qui précise la nature de la
spécialisation. Dans l'exemple du VéhiculeDeuxRoues, si la superclasse comporte un attribut
sorte dont le domaine est {moto, vélo}, tout ajout d'une instance dans la superclasse sous-tend
une spécialisation automatique par l'entremise de la valeur de l'attribut de spécialisation sorte. On
représente cette spécialisation comme étant déclenchée par un prédicat formulé avec un attribut.
Elle est dite spécialisation par prédicat (figure 3.39a).

VehiculeDeuxRoues
noSerie*
prix
sorte <-----

t,e
sorte = 'moto' sorte = 'velo'

Moto Velo
puissance E/A composite
 
Figure 3.39a 

Lorsque la spécialisation est précisée uniquement par l'application qui effectue une opération
pilotée par l’utilisateur on parle alors de spécialisation par l'application. C'est cette dernière qui
choisit la sous-classe qui modélisera l'instance du véhicule à deux roues qui est ajoutée à la base
de données. Après son stockage dans la base, il n’a pas de trace dans l’instance qui justifie son
rangement dans une sous-classe plutôt que dans l’autre, car l’attribut sorte est absent dans la
base.

Propriétés; de la généralisation/spécialisation 
Comme nous l’avons précédemment, l'abstraction de type spécialisation/généralisation a des
propriétés contraignantes de couverture: totale (t), partielle (p) et de partionnement : exclusive (e)
et non exclusive (o). Nous allons les étudier avec un peu plus de détails.

Couverture de l’héritage :  totale et partielle 
La généralisation est totale (t) si chaque instance de la superclasse en est une de la sous-classe.
Elle sera dite partielle (p), si la classe Personne (voir figure 40) représente aussi des instances
dont le type ne correspond qu'à celui de la superclasse. Il est aussi possible de formuler les
propriétés de la généralisation avec les contraintes structurelles de min-max (Voir plus loin la
section sur les notations). Dans l'exemple qui suit, la spécialisation est définie par l'application et
© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 126

elle est totale parce que toute personne représentée est soit un ouvrier, soit un technicien. Les
instances de Personne sont partitionnées en deux sous-classes disjointes.

Personne Les instances de Personne (virtuelles)


nas*
nom p1 p2 p3 p4 p5

t, e

Ouvrier Technicien
syndicat  corporation o1 o2 t3 t4 t5

E/A
Figure 3.40

Dans la figure 3.40, la superclasse est abstraite; elle ne sera pas instanciée et son rôle se limite à
fournir des attributs (et éventuellement des méthodes) aux sous-classes. Le même modèle avec
une spécialisation définie directement par un attribut supplémentaire tel que le métier pourrait
être exploité dans un prédicat pour enclencher automatiquement une spécialisation à chaque
création d'une Personne. La structure d'une instance Personne est celle d'un record défini par les
champs : {nas, nom}. Celle de Ouvrier est un record défini par les champs : { nas , nom,
syndicat}.

Avec une couverture totale, les relations ci‐dessous sont vérifiées : 

1) card(Ouvrier) + card(Technicien) = card(Personne) où card() est le nombre d'instances de la


base de données qui vérifient le type de la classe Personne.

2) Personne ⊆ Ouvrier ∪ Technicien


et
Ouvrier ∪ Technicien ⊆ Personne (égalité des ensembles)
 
Toute  instance  qui  a  le  type  de  la  Classe  Personne  est  soit  un  ouvrier,  soit    un  technicien. 
Lʹensemble Personne est un sous‐ensemble de celui obtenu par lʹunion des ensembles Ouvrier et 
Technicien, car tout élément de Personne est un élément de lʹensemble union. Comme l’inverse 
est aussi vrai, alors les deux ensembles sont identiques. 

3) Ouvrier ⊆ Personne et Technicien ⊆ Personne


Toute instance de la classe Ouvrier vérifie aussi le type de la classe Personne. C'est aussi vrai
pour une instance de Technicien. A la limite, toutes les personnes peuvent être des ouvriers ou
des techniciens.

Remarque : Le petit carré dans la structure de généralisation est le symbole de fusion des classes
pour indiquer qu’il s’agit de sous-classes impliquées dans une même abstraction de

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 127

généralisation/spécialisation. Certains auteurs proposent un petit cercle au lieu du petit carré et


d’autres le signe d’inclusion positionné sur l’arête. Dans le langage UML le carré est remplacé
par la fusion des lignes comme nous l’avons vu au début de ce chapitre.

La généralisation/spécialisation est partielle lorsqu'il existe des instances définies seulement avec
les attributs de la superclasse qui cohabitent cependant dans la base avec celles définies avec les
attributs des sous-classes.
Les instances de Personne
Personne
nas* p1 p2 p3 p4 p5
nom
2 instances sont réelles

p,  e 

Ouvrier Technicien
syndicat  corporation o1 t3 t5

E/A
Figure 3.41
Remarque : Dans les SGBD objets, il y a une distinction entre une classe du modèle et le lieu physique du 
rangement des objets. Les objets qui ont des structures compatibles mais différentes peuvent être rangés 
dans  une  extension  physique  qui  est  créée  lors  de  la  création  des  classes  ou  séparément  par  la  création 
d’une structure d’ensemble qui agit comme extension de rangement des objets. Dans le SGBD relationnel, 
cette notion d’extension n’est pas explicite, bien qu’elle corresponde à peu près aux pages de tuples. 

Les objets en pointillé ne correspondent pas à des instances physiques dans Personne. Elles sont 
en  quelque  sorte  l’ombre  de  l’objet  réel  modélisé  comme  un  ouvrier  o1.  Avec  la  spécialisation 
partielle, les propriétés suivantes sont vérifiées : 
1) Ouvrier ⊂ Personne et Technicien ⊂ Personne

Cette inclusion (dite properly contained) signifie que toute instance de la classe Ouvrier ou de la
classe Technicien en est aussi une de Personne. Les instances p1 et o1 réfèrent au même objet
réel, soit une personne donnée, mais leur description en est légèrement différente. Dans un
premier regroupement, celui de Personne, la personne p1 est abstraite, tandis que la même
personne est représentée comme un ouvrier o1 et à ce titre est décrite par le type : { nas , nom,
syndicat}. Cependant, p2 n’étant pas spécialisée aura le type de Personne. A l’implémentation,
l’ouvrier o1 a une structure de 3 attributs et cette instance peut cohabiter sur disque avec les
instances de Personne qui en possède deux seulement.

2) Ouvrier ∪ Technicien ⊂ Personne


avec card(Ouvrier) + card(Technicien) <= card(Personne)
                
Dans la base, il peut y avoir des instances des trois structures ou types : Personne avec ses
attributs spécifiques, Ouvrier et Technicien avec ses attributs propres augmentés de ceux hérités
© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 128

de Personne. Les entités de Personne non spécialisées représentent des entités qui ne sont ni du
type Ouvrier, ni du type Technicien. Cependant, toute instance d'une sous-classe en est aussi une
de la superclasse parce qu'elle satisfait le type de la superclasse. En effet, dans cet exemple le
type de la superclasse impose la présence de deux attributs typés qui sont par héritage aussi
présents dans une entité de la sous-classe. La spécialisation partielle ou incomplète peut être vue
comme une opération spécialisation avec un ensemble incomplet de sous-classes. Ainsi, la
spécialisation de Personne est limitée pour le moment aux classes Ouvrier et Technicien, mais
éventuellement d’autres sous-classes pourraient être ajoutées. Par exemple, les sous-classes
Ingénieur, Physiciens, Biologiste pourraient être ajoutées pour éventuellement toutes les avoir
pour en arriver à une spécialisation totale.

Exemple de l’évolution du schéma : ajout d’une nouvelle classe


Helicoptere  Helicoptere

p,e t,e

HelicoTransport HelicoPassager HelicoTransport HelicoPassag HelicoGuerr


er e

MCD-1 MCD-2
Figure 3.41a

Les propriétés de la spécialisation dans MCD-1 sont respectivement partiel (p) et exclusif (e)
parce qu’il existe un autre sorte d’hélicoptères qui ne sont pas représentées par une classe
présentement absente. Plus tard, cette troisième classe pourrait être ajoutée (MCD-2) permettant
de spécialiser les instances de Helicoptere, les seules qui ne pouvaient l’être avec le MCD-1. En
ce faisant, le modèle enrichi permet maintenant de tout spécialiser vers les sous-classes. De fait,
les propriétés deviennent (t, e). Avec le formalisme UML, les propriétés sont {complete,
disjoint}.
Partitionnement : exclusivité et chevauchement (e, o)
La spécialisation est exclusive si une instance de la superclasse est spécialisée en une seule de
sous-classe. Il y a non exclusivité (overlapping) si une instance de la superclasse peut être
simultanément spécialisée en dans les deux sous-classes. Voici un autre exemple qui ajoute à ce
qu’il a été vu précédemment.

Avec ce modèle, les véhicules qui ne sont ni une auto ni un camion ne peuvent être représentés  
par  des  instances  de  la  superclasse  Véhicule  parce  qu’elles  devront  être  obligatoirement 
spécialisées  dans  une  sous‐classe  qui  ne  correspond  à leur  sémantique.  Une  moto  n’est  ni  une 
auto,  ni  un  camion !    Dans  ce  cas,  a1  est  décrit  par  les  attributs  {noSerie,  traction},  tandis  que  
l’instance v1 devient une instance virtuelle.  
 
 
 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 129

Les instances de Vehicule (toutes virtuelles)


Vehicule v1 v2 v3 v4 v5
noSerie*

t, e

Auto Camion
traction capacite a1 a1 c3 c4 c5
E/A
Figure 3.42

Auto ⊆ Vehicule et Camion ⊆ Véhicule


avec card(Véhicule) = card(Auto) + card(Camion)
 
Overlapping (chevauchement)  
Le MCD de la figure 3.43 modélise seulement les sportifs qui sont joueurs de foot et/ou joueurs
de tennis. La spécialisation de cet exemple est pilotée dans l’application par un prédicat formulé
avec l’attribut sorte : Si sorte = ‘foot’ alors spécialiser cette instance comme une instance de
JoueurFoot.

Sportif
nas*
club Les instances de Sportif
sorte
s1 s2 s3

t, o

sorte ='foot' sorte ='tennis'

JoueurFoot JoueurTennis
jf1 jf2 jt2 jt3

J f Figure 3.43
 
Il  est  donc  possible  de  retrouver  le  même  sportif  à  la  fois  comme  JoueurFoot  et  comme 
JoueurTennis. Les sportifs dʹune autre discipline ne peuvent pas être représentés avec ce modèle 
en raison de la  couverture totale qui caractérise cette spécialisation. 

JoueurFoot ⊆ Sportif et JoueurTennis ⊆ Sportif


et
card(JoueurFoot) + card(JoueurTennis) >= card(Sportif)

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 130

En résumé, les combinaisons possibles pour les propriétés de couverture sont les suivantes : (t,e),
(t,o), (p,e), (p,o). La couverture de chaque spécialisation est choisie pour se conformer le plus
possible à la réalité à modéliser.

Normalement, si la superclasse est obtenue par généralisation, elle est totale, c'est-à-dire que
toutes ses instances seront spécialisées. La généralisation partielle apparaît normalement par la
voie de la spécialisation d’une classe.

Cas particulier:  sous‐classe unique dans une hiérarchie d’héritage    
Cette généralisation/spécialisation particulière est partielle ou totale et forcément exclusive,
(p,e), (t,e) puisqu'une seule sous-classe intervient dans l'abstraction. Le carré utilisé pour
regrouper les propriétés de la spécialisation peut être supprimé et remplacé par une lettre entre
deux chiffres, p ou t.

Ouvrier
nas*
nom

(p)

OuvrierPermanent
dateConfirmation

 
Figure 3.44 
Normalement une telle spécialisation est partielle. Une spécialisation totale de ce type ne
comporterait pas beaucoup d’intérêt, car elle correspondrait à une représentation équivalente par
une seule sous-classe, soit ici OuvriersPermanents (figure 3.44). en terme de représentation,
aucun gain n’est réalisé avec une spécialisation totale.

Spécialisation en cascade 
Une sous-classe de la hiérarchie peut être elle-même spécialisée pour hériter de tous les attributs
à partir de la racine. Par exemple, une instance de la classe CEssence de la figure 3.45 décrit donc
un véhicule de type camion avec un moteur à essence. La structure d'une instance de CEssence
sera composée des attributs de Véhicule obtenus par héritage enrichis avec ceux de Camion et à
nouveau augmentés par ceux spécifiques à la classe CEssence. Cet héritage pourrait être
implémenté dans un système SGBD qui gère un modèle objet ou relationnel-objet. En relationnel,
cet héritage n’est pas implémenté comme tel et doit être simulé par le biais d’un schéma
relationnel enrichi. La version 9i du SGBD Oracle, les systèmes Gemstone, O2 et Jasmine
implémentent directement cet héritage.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 131

 
Vehicule
Instances de Vehicule (toutes virtuelles)
noSerie
v1 v2 v3 v4 v5

t, e

Auto Camion
a1 a1 c3 c4 c5
traction capacite
Instances de Camion 
2 virtuelles et 1 réelle 
p, e

E/A  CDiesel CEssence


e3 e3
gazole octane
Instances de CEssence

Figure 3.45
Héritage (simple et multiple) 
En raison du mécanisme inhérent à la généralisation, les attributs de la superclasse sont visibles 
par  chaque  sous‐classe  de  sa  hiérarchie.  C’est  l’héritage  des  attributs  est  implémenté 
directement dans les systèmes SGBD objets ou relationnels‐objets. 
 

Vehicule
noVignette*
annee

c,d

Auto Utilitaire
modele volumeBenne
nbPassager chargeMax

Héritage simple Figure 3.46


L’héritage est simple si la classe générique ou superclasse est unique; il est multiple s’il y a
plusieurs classes génériques pour une même sous-classe. Avec les SGBD relationnels l'héritage
n'est pour le moment qu'un outil de modélisation qui permet de découvrir de nouvelles
associations et de simplifier parfois la structure du MCD. A l'implémentation, l'héritage dans le
MCD se traduit pour le cas (t,e) par l'adjonction des attributs de la superclasse à ceux de la sous-
classe. La nouvelle génération de SGBD à objets offre ce mécanisme de spécialisation aux
concepteurs de MCD et aux développeurs qui utilisent le modèle logique à objets pour les

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 132

applications (par exemple la méthode UML). L’héritage simple de la figure 3.46 tient au fait
qu’une sous-classe n’hérite que d’une seule classe générique. Par contre, si une sous-classe peut
hériter des attributs de plusieurs classes génériques, l’héritage est dit multiple (figure 3.47).
Voici un exemple E/A pour illustrer cette sorte d'héritage.

Employe Etudiant
nas* nas*
nom nom
adresseLocale

Héritage multiple
t, e
p, o

Professeur Moniteur 1erCycle 2eCycle

specialite noLabo programme dirRech


 
Figure 3.47  Héritage multiple des attributs    

Un moniteur de labo est un employé et aussi un étudiant. C'est donc une instnce dont le type est
spécifié par ses attributs propres en sus de ceux hérités des deux superclasses Employe et
Etudiant. L’héritage multiple peut engendrer un conflit de nom d'attribut. En effet, par héritage
automatique, un même nom d’attribut peut être hérité de plusieurs classes génériques et avoir une
sémantique différente selon la source d'héritage. Le renommage des attributs vient donc préciser
la sémantique. Ce problème ne se pose pas dans un SGBD relationnel, car le passage au MCD
résout les conflits de nom en préfixant l'attribut hérité par le nom de la superclasse. Ici encore,
l'héritage double signifie que toute instance de Moniteur est définie par les attributs hérités de
Employe et de Etudiant qui s'ajoutent aux attributs propres de Moniteur.

Plusieurs structures de généralisation/spécialisation avec une même classe 
On peut dans certains cas particuliers spécialiser une même classe générique de plusieurs façons
selon les besoins de la modélisation. Lorsqu'une employée est architecte avec en sus la
responsabilité administrative de chef d'équipe, la spécialisation selon la tâche avec la couverture
(p,e) n'est pas suffisante pour représenter les employés qui ont un rôle de chef d'équipe (voir
figure 3.48). Il faut une 2e spécialisation partielle pour représenter ces employés. Pour les
différentes spécialisations distinctes, il faut préciser les propriétés de couverture et de
chevauchement. Une même classe peut faire l’objet de plusieurs spécialisations, chacune ayant
ses caractéristiques.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 133

Employe
nas*
nom

p
p,e

Secretaire Technicien Architecte Chef


specialiteBur classification titre mandat

t,e Gere

 
Permanent Occasionnel Projet 
E/A salaire   tauxHoraire noProjet 
 
Plusieurs spécialisations de la même classe 
Figure 3.48 

La superclasse Employe est spécialisée de trois façons indépendantes et différentes. Une


employée du secrétariat est représentée entièrement par une entité dont les attributs sont ceux de
la superclasse Employe et ceux de la sous-classe Secretaire. Une employée architecte qui est
permanente et chef d’un projet se retrouvera décrite dans trois sous-classes du MCD.

Lorsque les spécialisations sont multiples, il peut y avoir une certaine redondance des attributs.
Ainsi, le nas de Employe est hérité par la classe Permanent et aussi par la classe Architecte et par
celle du Chef. Cette redondance dans le MCD et dans la base de données qui s'en suit devra être
contrôlée automatiquement lors de l'exploitation de la base.

3.11 Catégorie 
Lorsqu’une généralisation comporte plusieurs superclasses et qu’une sous-classe hérite de l’une
ou l’autre des superclasses, mais pas de plusieurs, cette sous-classe est appelée une catégorie
(10). Dans le modèle ci-dessous, le propriétaire d’un véhicule a une structure de l’une des trois
classes : Personne, Ministere ou Societe. C’est en quelque sorte l’héritage multiple proposée
pour enrichir les primitives de modélisation de E/A.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 134

Atelier
Travaille noAtelier*
specialite

Personne Ministere Societe


nas* nom* nomCorpo* Dans ce MCD, les
noPermis ministre secteur
multiplicités ne sont pas


catégorie
p

Proprio
adresse
statut
sorte VVoiture VCamion
categorie* chargeMax*

sorte = 'c'
Possede

t
Vignette

noVignette*
prix
sorte

Figure 3.49

La catégorie est partielle si une partie seulement des instances de la superclasse est spécialisée.
La catégorie est totale si toutes ses instances sont spécialisées. Dans cet exemple, la classe
Proprio est une catégorie partielle parce que certains ministères ou certaines sociétés ne sont pas
propriétaires.

(Catégorie partielle): Proprio ⊂ Personne ∪ Ministere ∪ Societe

Par contre, la catégorie Vignette est totale puisque tout véhicule, voiture ou camion, a une
vignette.

(Catégorie totale): Vignette ⊆ VVoituree ∪ VCamion

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 135

Dans cette abstraction, la classe Vignette a aussi été généralisée vers deux superclasses sur la
base de la valeur de l'attribut sorte. Elle devient alors une catégorie qui hérite des attributs soit de
VVoiture, soit de VCamion selon la valeur de l’attribut de spécialisation sorte. En effet, tout
accès à une instance de Vignette accède automatiquement aux attributs de l’une des classes
génériques qui correspond à sa généralisation. La catégorie Vignette est aussi une catégorie totale
parce que dans cet exemple toute vignette en est une d’une voiture ou d’un camion et
inversement.

La spécialisation de chaque superclasse en une catégorie est faite sur la base dʹune fonction de 
catégorisation FC. Cette fonction FC contrôle lʹhéritage des attributs de l’une des superclasses.  

UsineAgreee UsLoc
noUs*   ville*
ville
sorte-u

UsInter UsNat
permisEuro* noCorpo*
t, e siegeSoc pays

UsInter UsNat
permisEuro noCorpo ∪
siegeSoc pays
t

UsineAgree
noUs
UsLoc
ville
ville
sorteUs

Figure 3. 50

Généralisation Catégorisation

Ainsi, en accédant à une entité de Vignette, la valeur de la fonction (FC) utilisée pour la
généralisation/spécialisation précise quelle est la superclasse qui est la source des attributs
hérités. La catégorie est donc une partition d'une classe (ou Entité) avec des structures
différentes.

Il est possible de représenter une catégorisation totale par une généralisation totale. Par exemple
dans la figure 3.50, la modélisation des usines agréées pour la production peut être faite en les
regroupant en usine internationale, usine nationale et usine locale.

Catégorisation totale :
UsineAgreee ⊆ Usinter ∪ UsNat ∪ UsLoc
UsInter ∪ UsNat ∪ UsLoc ⊆ UsineAgreee
Généralisation totale :
UsineAgreee ⊆ UsiInter ∪ UsNat ∪ UsLoc
© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 136

UsInter ∪ UsNat ∪ UsLoc ⊆ UsineAgreee

Dans le cas de la spécialisation, les entités de la classe UsineAgreee sont totalement regroupées
en trois sous-classes distinctes. Comme la spécialisation est totale toute entité de la réunion des
sous-classes appartient aussi à l'ensemble UsineAgreee et inversement. En accédant à une sous-
classe, les attributs de celle-ci sont rendus disponibles en plus de ceux hérités de la superclasse
UsineAgreee. Dans le cas d'une catégorie, l’accès à une instance de UsineAgreee permet
d'obtenir ses attributs propres plus ceux de l’une seulement des superclasses.

UsineAgreee   UsLoc
noUs*   ville*
ville
sorteUs  
 
  UsInter UsNat
permisEuro* noCorpo*
 
p, e siegeSoc pays
 
UsInter UsNat
 
permisEuro noCorpo ∪
siegeSoc pays   p
  UsineAgreee
UsLoc   noUs
ville ville
  sorteUs
 
  Généralisation/Spécialisation Catégorisation
Figure 3.51 

La catégorie UsineAgreee a donc une structure qui varie selon l'instance obtenue par héritage. La
couverture de la généralisation de la figure 3.51 est partielle, alors la sémantique devient
différente de celle de la catégorie partielle. En effet, il devient possible d'avoir une usine agréée
qui n'est pas spécialisée donc décrite par 3 attributs, tandis qu'avec la catégorie partielle de la
figure 3.51, toute usine agréée hérite par la catégorie les attributs lui conférant une structure plus
complexe, i.e. composée de 4 attributs. La catégorisation partielle est pilotée par un attribut
ajouté dans UsineAgreee, soit sorte-Us qui précise la superclasse qui est la source de l'héritage.

Généralisation partielle :
UsInter ∪ UsNat ∪ UsLoc ⊂ UsineAgreee
Catégorisation partielle : UsineAgreee ⊆ UsiInter ∪ UsNat ∪ UsLoc
 
En  résumé,  la  catégorisation  totale  peut  être  remplacée  par  la  généralisation  totale  qui  a  un 
équivalent en langage UML. Pour ce qui a trait à la catégorisation partielle, il faut la tolérer ou la 
remplacer par une abstraction approximative, mais non équivalente. 
Héritage des associations 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 137

Une superclasse peut aussi avoir une association (et des attributs propres) avec une autre classe
du modèle. Cette association est aussi l'objet de l’héritage par les sous-classes d’une
spécialisation et cela, au même titre que les attributs. De plus, l'association peut être l'objet d'une
spécialisation pour générer autant de nouvelles associations qu'il y a de sous-classes. Cette
spécialisation de l'association en modifie aussi la sémantique (voir les exercices résolus) et
justifie parfois le renommage.

Type d’une sous‐classe 
Une sous‐classe a un type (structure) défini par un enrichissement de ses attributs par héritage. 
Rappelons  que  le  type  est  en  quelque  sorte  un  ensemble  nommé  de  règles,  lesquelles  doivent 
être vérifiées par toute instance ou tout objet qui appartient au type. 
 
Type de la sous-classe =
{attributs de la sous-classe} + {attributs de la superclasse}

De même, une instance de la superclasse appartient à une sous‐classe si chaque valeur dʹattribut 
de celle‐ci vérifie le type des attributs de la première. Ainsi on peut conclure quʹune instance de 
sous‐classe appartient aussi à la superclasse puisquʹelle satisfait les règles de la sous‐classe, mais 
aussi celles de la superclasse pour les attributs obtenus par héritage.  
 
Critères de modélisation 
Tout au long de la modélisation des données, le concepteur doit faire divers choix :
a- Représentation par une classe ou un attribut ?
La question est de décider si un objet ou un concept du monde réel doit être représenté comme
une classe ou un attribut. La décision doit se prendre à partir de la réalité à modéliser et en se
référant, au besoin à la règle de l’existence autonome. Il n’en demeure pas moins que ce choix est
souvent intuitif et que le résultat est généralement satisfaisant.

b- Généralisation
La généralisation/spécialisation doit être utilisée avec une classe chaque fois que certains
attributs de la classe ne sont pas "valuables" avec certaines de ses instances.

c- Attribut composé /simple


L’attribut composé est préféré chaque fois qu’un nom significatif peut être donné à un ensemble
d’attributs atomiques et qu’un type complexe approprié est implémenté dans le logiciel utilisé.
Sinon, les attributs simples sont choisis.

3.12 Les pièges à éviter en modélisation conceptuelle 
Dans la modélisation, il peut se poser quelques difficultés avec l’exploitation du modèle de sorte
que des interprétations fausses découlent de l’exploitation des données du modèle.
Le Fan Trap 
Les associations entre les classes du MCD sont telles que les instances des associations posent
des problèmes d’ambiguïté, notamment lorsque associations 1..1 émergent de la même classe.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 138

Departement
noDep*
1..1
1..1

AssigneA Opere

1..* 1..*
Employe Atelier
matricule* UML noAtelier*

Instances de Instances de Instances de Instances de Instances de


Employe AssigneA Departement Opere Atelier

e1 a1

a2

Le MCD précédent doit pouvoir représenter un employé qui travaille dans un seul atelier. Or il y
a deux chemins pour aller d’une instance de Employe à une autre de Atelier n’est pas unique
Sachant qu’un ouvrier travaille que dans un seul altelier, la réponse à la question suivante est
ambigue : dans quel atelier travaille l’ouvrier e1 ? Est-ce dans a1 ou dans a2 ?

Solution au fan trap


Le MCD est réorganisé de manière à associer l’employé à l’atelier et ensuite au département. En
ce faisant, on supprime l’émergence de deux associations 1..1 de la même classe. Le nouveau
modèle doit répondre à la question suivante : Dans quel atelier travaille l’employé Turgeon? La
réponse est claire lorsque le modèle est réorganisé comme ci-dessous.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 139

Atelier
noAtelier*
1..*
1..1

AssigneA Opere

1..* 1..1
Employe Departement
matricule* UML noDep*

Cette réorganisation du MCD correspond à une vision plus réaliste de liens administratifs d’un
employé.
Instances de Instances de Instances de Instances de Instances de
Employe Assigné-A Atelier Opere Departement

e
1
d1

d2

 
Le Chasm Trap 
Le MCD présente une association entre deux classes, mais cette association n’existe pas au
niveau de toutes les instances en raison de la présence d’une participation partielle i.e. d’un min
égale à 0 sur le chemin allant d’une classe à une autre, comme par exemple de Agence à Maison.

Employe
matricule*

1..* 0..1
Travaille Vend
  1..1 0..*
Agence Maison
noAgence* noMandat*

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 140

Instances Instances Instances de Instances de Instances de


Agence Travaille Employe Vend Maison

2345
Belmont

Il y a une instance de  la classe Employe qui n’est pas atteignable par une instance d’association. 
Par  exemple,  il  est  impossible  de  répondre  à  la  question  suivante :  Quelle  est  l’agence  qui  a  le 
mandat de vendre la maison du 2345 Belmont?  Si le mandat de vendre n’est pas attribué à un 
employé, il sera impossible d’y répondre. Si le mandat pour cette maison est enregistré dans la 
base mais que la fiche de vente n’est pas attribué à un employé (comme cela est autorisé par la 
multiplicité), alors il ne sera pas possible de fournir le nom de l’agence. 
 
Cette  difficulté  n’a  pas  toujours  de  conséquences  fâcheuses  de  sorte  qu’il  n’est  pas  toujours 
nécessaire de la supprimer. 
 
Correction du Chasm Trap
Une  solution  consiste  à  créer  dans  le  modèle  une  nouvelle  association  AMandat  avec  une 
participation obligatoire. C’est un nouveau chemin dans le graphe, entre Agence et Maison.     
                    
          
 
  Employe
matricule*
 
  1..* 0..1
  Travaille Vend
 
  1..1 0..*
  Agence 1..1 Maison
1..*
  noAgence* noMandat*
AMandat

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 141

Instances Instances Instances de Instances de Instances de


Agence Travaille Employe Vend Maison

Instances de AMandat

Le Fan trap qui apparaît dans la solution est sans conséquence si dans une interrogation le
chemin emprunté dans le MCD est exempt de la participation partielle (min= 0). Tel est le cas du
chemin de la classe Employe vers la Maison via la classe Agence.

Exercices résolus

1- Le MCD ci-dessous modélise le lieu de travail des personnes. Une même personne peut avoir
plusieurs lieux de travail selon qu’elle est pigiste pour une ou plusieurs entreprises.
a- Modifier ce MCD pour représenter les personnes qui peuvent travailler à deux endroits: au
bureau et au domicile. Lorsque la personne travaille à son domicile, elle travaille dans une ville et
peut être jointe seulement par courriel. Lorsqu'elle travaille à son bureau d'affaires elle ne peut
être jointe que par téléphone.

Personne LieuTravail
nas* (0,n) (1,n) nomLieu*
Travaille
nom ville

 
Solution : 
Il sʹagit de représenter un nouveau concept, soit celui du moyen de communication qui est varie 
selon  le  lieu  de  travail.  Lorsque  le  travail  est  au  domicile,  la  personne  peut  être  rejointe  par 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 142

Internet,  tandis  qu’au  bureau  elle  peut  être  rejointe  par  téléphone.  Ce  fait  peut  être  représenté 
par une nouvelle association dotée d’un attribut qui précise le moyen de communication.  
noTel

(0,n) TravailleB (1,n)


Personne LieuTravail
nas* nomLieu*
nom ville
TravailleD
(0,n) (1,n)

noInternet
b-Représenter dans le nouveau modèle le fait qu'une même personne ne puisse pas avoir en
même temps un bureau à son domicile et un autre à sa place d’affaires.

Solution  
Il  faut  exclure  la  participation    simultanée  dʹune  même  personne  aux  deux  associations.  Cette 
exclusion  mutuelle  est  représentée  dans  le  formalisme  Merise  avec  un  cercle  au  centre  duquel 
apparaît le signe +.  noTel
(0,n) (1,n)
  TravailleB
  Personne Bureau
nas* + nomBureau*
 
nom ville
  TravailleD
(0,n) (1,n)
 
  no Internet
                                                           
c‐  Représenter  le  modèle  initial  avec  les  contraintes  de  lʹassociation  par  la  cardinalité  et  la 
participation au lieu des contraintes (min, max) présentement utilisées. 

Solution :
La représentation équivalente est la suivante :

Personne p t Bureau
nas* Travaille nomBureau*
nom m 1 ville

Les mêmes contraintes sont exprimées par celles la participation et la cardinalité.

d- Formulez le MCD avec UML :

Personne Travaille Bureau


nas* 1 0..* nomBureau*
nom ville

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 143

2- Modifiez le modèle ci-dessous pour représenter aussi le suivi des satellites de communications.
Il faut pouvoir représenter aussi le suivi des satellites militaires qui sont inaccessibles aux
antennes non autorisées, tandis que les satellites civils le sont sans restriction. Chaque satellite
militaire est suivi obligatoirement par une écoute en temps réel par l’antenne suiveuse, tandis que
le satellite civil est, dans certains cas, non suivi. La communication avec le satellite civil exige la
connaissance d’une clé publique pour décoder les signaux, tandis qu’une clé secrète est
nécessaire pour communiquer avec le satellite militaire. Voici la situation modélisée initialement.

 
AntenneTerrestre Satellite
  noAntenne* noSatellite*
  positionCourante trajectoire
sorte 0,1 Cible 0,n spectreFrequence
 
localisation encodagePublic
  encodageSecret
 
 
 
Solution : 
La  spécialisation  de  Satellite  se  fait  en  deux  classes  exclusives,  à  savoir  la  classe  du  Satellite 
militaire et celle du Satellite civil.  
AntenneTerrestre Satellite
noAntenne* 0,1 noSatellite*
positionCourante trajectoire
sorte spectreFrequence
localisation
Exploite
+

0,1 t,e
Suit

1,n 0,n
SatelliteMilitaire SatelliteCivil
encodageSecret  encodagePublic 

Chaque sous-classe comporte ses attributs propres. L'association Cible peut être déplacée vers les
sous-classes en se spécialisant pour devenir Exploite et Suit (Tracking).

3- Comment est-il possible de traiter l’attribut date-mariage dans le modèle ci-dessous avec les
cardinalités (0, 1).

Femme 0,1 0,1 Homme


nas* EstMarie nas*
ville dateMariage ville

Solution : (une parmi plusieurs solutions possibles) :


On peut le faire par spécialisation des classes d’origine et de l’association vers les sous-classes
obtenues. Les contraintes (min, max) sont aussi ajustées.
© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 144

 
Femme Homme
nas* nas*
ville ville
p EstMarie p

FemmeMariee 1,1 1,1 HommeMarie


dateMariage

En cas de divorce, la femme et l’homme concernés ne sont plus en association. Elles sont
supprimées de la base de données et, si cela est nécessaire, recréées comme une entité de la
superclasse. Dans ce traitement, l'héritage de l'association est fait sans division par spécialisation.
Ce traitement par spécialisation permet de supprimer la participation partielle pour l’association.
Une autre solution serait de déplacer l’attribut dateMariage vers une des deux classes et de
garder la participation partielle pour l’association.

Femme 0,1 0,1 Homme


nas* EstMarie nas*
ville ville
dateMariage

Cette solution sous-tend une valeur nulle pour l’attribut mariage, lorsqu’une femme n’est pas
mariée, tandis que pour l’homme le fait de ne pas être marié n’est pas clairement modélisé,
autrement que par sa non-participation à l’association.

4- Énoncez en français les contraintes structurelles (min, max) du modèle représentant la vente
des sièges d'avion et de l’embarquement sur les vols commerciaux. Les clés du modèle illustré ci-
dessous ne sont pas identifiées.

Quai Passager
noPorte noTicket 1,n
terminal nom
securite adresse
ville Reserve
classe dateR
0,n

1,1 0,1
Utilise
Voyage Siege
noSiege
1,1 1,n noAvion
1,m
Vol A
noVol
dateD
1,n
heureD

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 145

Solution : Les contraintes sont les suivantes :


a- Un quai d’embarquement est utilisé par aucun ou plusieurs vols. Chaque vol sous-tend un
embarquement à un quai.
b- Un passager réserve un ou plusieurs sièges à une date déterminée. Un siège peut ne pas être
vendu.
c- Une place assise dans un avion correspond à un ou plusieurs vols. Un vol doit avoir des places
de passagers.
d- Un passager doit voyager sur un seul vol qui pour sa part se fait avec plusieurs passagers.
                                 
5- Donnez les clés primaires du modèle ci-dessus et précisez les clés composées. Comment est-il
possible de transformer ces dernières en clés simples ? Peut-on transformer la clé composée no-
siège et priorité en clé simple noSiege ? Quelles hypothèses faut-il faire pour chaque clé ?

Solution : Les clés choisies (primaires) sont les suivantes :


a) noVol : unique dans le système dans l’aviation civile;
b) noTicket : global pour le système de transport des passagers.
c) Les clés composées sont les suivantes :
d) noPorte et terminal parce que le numéro d’une porte d’embarquement est local au
terminal. Pour remplacer cette clé, il suffit de définir un identifiant de porte global, ce qui
peut ne pas correspondre à la réalité de l’aérogare;
e) -noSiege et no-avion parce qu’un siège portant un no correspond à celui d’un avion
particulier. Le même numéro de siège peut se retrouver dans un autre avion.

Avantages et inconvénients de la modélisation E/A 
Le formalisme E/A est simple offre plusieurs mécanismes d’abstraction faciles à maîtriser. Il y a
que quelques notions de bases : Entité et entité, association, attribut, la spécialisation et la
catégorie. Ceux-ci sont suffisants pour représenter les structures statiques dont la complexité
varie de faible à moyen.

En  revanche,  la  modélisation  E/A  est  non  déterministe.  Aucun  critère  objectif  ne  permet  de 
justifier l’usage d’une Entité ou d’un attribut pour modéliser un concept. Par exemple, dans la 
modélisation d’une collection documentaire, vaut‐il mieux représenter l’auteur d’un document 
comme une entité ou comme un attribut? Si l’attribut est privilégié, seul le nom de l’auteur sera 
inséré  dans  la  base,  tandis  qu’avec  une  entité,  il  devient  possible  de  fournir  d’autres 
informations sur l’auteur et éventuellement les partager pour d’autres documents écrits par un 
même auteur.  
 
La  deuxième  faiblesse  du  formalisme  E/A  est  importante.  Il  ne  permet  pas  d’inclure  dans  la 
représentation  d’une  entité  (i.e.  d’un  objet)  les  opérations  disponibles  pour  en  modifier  le 
contenu.  Le  formalisme  E/A  est  à  la  base  de  presque  toutes  les  méthodes  de  représentation 
conceptuelle, mais il est concurrencé par le formalisme utilisé avec le UML. Dans ce dernier cas, 
les opérateurs sont inclus dans la description d’une entité de sorte qu’elle devienne encapsulée. 
Finalement, le UML intègre les méthodes OMT, celle de Shlaer‐Mellor, celle de Jacobson et ses 
use  cases,  celle  de  Booch  et  ses  notions  de  catégorie  et  sous‐système,  …La  convergence  de  ces 
méthodes a donné lieu à la formulation d’un langage unifié pour représenter la modélisation par 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 146

objets,  le  UML.  Ce  langage  de  modélisation  permet  de  capturer  la  structure  statique,  le 
comportement des objets, de représenter formellement les besoins des utilisateurs (Use cases de 
UML), les interactions entre les objets pour fournir les résultats attendus, de découper les unités 
de traitement et de préciser les détails de leur implémentation. Le grand mérite des formalismes 
de  modélisation  conceptuelle  est  de  permettre  une  représentation  graphique  des  structures  de 
données  qui  reflète  le  plus  la  réalité  et  qui  génère  par  des  règles  de  transposition  un  modèle 
relationnel acceptable.   
                  
Sommaire 
La modélisation des données est une étape essentielle dans l’analyse informatique qui précède 
lʹexploitation  des  données  par  un  logiciel  SGBD.  Le  formalisme  E/A  de  qui  est  à  l’origine  de 
plusieurs méthodologies d’analyse a de nombreuses variantes, distinctes entre elles notamment 
par  la  façon  d’exprimer  les  contraintes  de  cardinalité  et  de  participation.  L’introduction  de 
l’abstraction de généralisation/spécialisation permet souvent de simplifier la modélisation et de 
ce fait facilite l’interprétation subséquente du MCD. Cette abstraction est aussi constructive dans 
le sens qu’elle permet de découvrir de nouvelles associations et de les exprimer plus simplement 
entre les sous‐classes spécialisées. Le passage du MCD au modèle logique d’implantation qu’il 
soit relationnel (MRD), en réseau ou hiérarchique est assuré par un jeu fini de règles de passage 
relativement  simples.  Il  en  sera  autrement  avec  le  modèle  à  objets  dans  lequel  le  passage  ne 
pourra être fait qu’en exploitant de façon appropriée les types de données complexes. A terme il 
est à prévoir que le formalisme UML  remplace tous les autres formalismes. 
 
La gestion des données occupe une place importante dans le fonctionnement des organisations. 
Elle est tributaire des systèmes de gestion de bases de données et des réseaux. L’évolution des 
logiciels SGBD est marquée par la généralisation de cet outil qui assume des fonctions capitales 
de  stockage,  de  recherche,  de  partage  et  de  validation  de  la  cohérence  des  données.  Les 
utilisateurs de ces systèmes sont l’ensemble des acteurs d’une organisation à tous les niveaux de 
responsabilité.  
 
Le volume des données à gérer est très souvent astronomique et les types de plus en plus variés. 
Le rôle essentiel du SGBD consiste à assurer une continuité des services dʹaccès aux données qui 
sous‐tend  un  soutien  efficace  du  personnel  technique  dont  la  spécialisation  et  la  compétence 
sont  critiques  dans  le  fonctionnement  de  la  base  de  données.  Les  nouvelles  architectures, 
notamment  de  type  client‐serveur,  favorisent  le  redéploiement  des  ressources  informatiques 
selon  un  mode  qui  privilégie  la  décentralisation  du  traitement  et,  éventuellement,  celle  des 
données.  La  prochaine  génération  de  SGBD  qui  exploitera  davantage  la  technologie  Internet 
donnera lieu à de nouveaux modèles.  

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 147

                             
Exercices du chapitre 3

 
ALU‐NORD : Modèle conceptuel  
La société ALU-NORD fabrique des pièces moulées en aluminium dans différentes usines
spécialisées réparties dans le monde. Les usines implantées obligatoirement dans différentes villes
produisent diverses pièces sur commande; ces dernières sont le plus souvent stockées sur place et
livrées entièrement à la fin de la production.

Ouvrier
Metier nas*
noMetier* (1,n) (1,1) nom
classe-metier Titularise prenom
taux sexe
(0,1) dNaiss
Travaille embauche

Usine
noUsine* (0,n) VracMat
noNat*
ville
noFourn*
capacStock (0,n) (0,m)
Commande volL
surfaceUsine
VolC cat
(0,n)

Production
noPiece*
(1,1) lot*
Client Realise
noclient* qte
ville dateDebut
delai
credit
(1,n) (0,1)
Achete

Le matériau en vrac est livré en volume prédéterminé par le fournisseur sur commande de chaque
usine. Les fonctions de gestion des ressources humaines se limitent à gérer un dossier sur chaque
ouvrier. L’implantation de cette base doit se faire en validant le plus possible les contraintes de
participation et de cardinalité et cela sans développer de triggers dans cette première phase de
création de la base.

Voici quelques-unes de ces contraintes d’exploitation qui découlent du MCD :


- La suppression d'un métier entraîne celle de sa participation à l'association Titularise et du même
coup, la suppression des ouvriers compétents dans ce métier.

- Il est possible de supprimer une entité dans VracMat si et seulement si sa participation à


l'association Utilise est aussi supprimée. La suppression d'une usine entraîne aussi celle de ses
productions, mais pas de ses ouvriers, ni des matériaux en vrac qu’elle utilise.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 148

Sémantique de quelques attributs :

dNaiss Date de naissance de l'ouvrier comprenant le jour, le mois et l'année.


embauche Date du premier contrat de travail exprimée avec le jour, le mois et
l'année.
classeMetier Classes de compétence pour un métier identifiées par un entier de 1 à 5.
capacStock Nombre de pièces pouvant être conservées à l'usine dans une enceinte
dont la surface représente obligatoirement 10% de celle de l'usine.
lot Unité de production d'une sorte de pièces correspondant à une
commande.
delai Nombre prévu de jours pour la fin de la production d'un lot de pièces.
volL Quantité minimale d'un matériau en vrac pouvant être livré à une usine.
noMetier Identifiant pour un métier exercé par plusieurs ouvriers.
cat Qualité du matériau en vrac fourni ou livré par un fournisseur.
qte Quantité de pièces produites dans un lot de production.
VolC Volume de matériau en vrac commandé par une usine. C’est un multiple
du volume.
surfaceUsine Surface totale de l'usine dont 10% est consacré à l'entreposage.
nas Numéro assurance sociale sous forme d'une chaîne composée de chiffres.

Voici, à titre d'information seulement quelques règles plus complexes sous-tendues par le MCD et
qui ne seront pas au départ validées dans la base, car cela exigerait l’utilisation de triggers et de
packages. Un métier n’est inscrit dans la base que si un ouvrier est qualifié pour le pratiquer dans
son travail. Un client n’est représenté que s’il a effectué au moins l’achat d’une production
complétée par une usine. Globalement, il ne peut pas y avoir plus de 10 métiers différents dans
tout le réseau des usines. Ainsi, le même matériau ne peut pas être fourni par plus de quatre
fournisseurs. Ces contraintes seront formulées éventuellement dans le schéma dans la mesure où
le SGBD utilisé pour l'exploitation le permet. Le modèle ALU-NORD est un graphe acyclique.

Domaines de quelques attributs


Certains attributs ont un domaine sémantique particulier défini dans le tableau ci-dessous. Par
définition, l’indicateur de null est hors domaine. Le domaine des autres attributs est considéré
comme étant implicite et dérivé des extensions des tables.

cat: { 'A', 'B', 'C, 'D’} capacStock: ]10...9999] volL ]0... 1000]

classeMetier : { 1...5} taux: ]10.00 ... 32.75] lot : ['b10'.... 'b99']

noMetier : [‘j1’... ‘j100’[ surfaceUsine:]100...5000] nas : chaîne de 9 car.

sexe : {'F', 'M'} noUsine : ['u10’...’u99’] credit:[1000....10000]

N.B. Un crochet ouvert par la gauche ou par la droite indique une borne exclue du domaine. Un
crochet fermé par la gauche ou par la droite indique l'inclusion de la borne dans le domaine.
L’indicateur de null n'est pas une valeur du domaine, mais correspond quand même à une réalité

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 149

pour quelques attributs, notamment les attributs délai et no-usine. Les attributs dont le domaine
n’est pas défini explicitement doivent être spécifiés en accord avec les données fournies par les
tables.

Remarques : 
1- De par la contrainte sur la capacité de stockage, toute production inférieure à 11 unités doit
quitter l'usine immédiatement et donc être livrée au client. Cette petite production exceptionnelle
n'est donc pas inscrite dans la BD et n’est pas stockée dans la BD, ce qui explique la définition du
domaine sémantique pour cet attribut.

2- La sémantique de plusieurs attributs peut être dérivée du contexte de la relation.

La connaissance des données a aussi permis de formuler quelques règles de validation


syntaxiques qui viennent en restreindre le domaine et qui seront renforcées dans le schéma de la
base ALU-NORD.

Attribut Validation syntaxique


nas chaîne de 9 caractères représentant des chiffres
seulement
noFourn 1ère lettre est un 'f'
noMetier 1ère lettre est le caractère 'j' et sa longueur max. est 3
noUsine 1ère lettre est le caractère 'u', les autres étant des chiffres.
La longueur max. est 3
noClient 1ère lettre est le caractère 'c'
noMat Chaîne dont la 1ère lettre est le caractère 'm '
nom Chaîne de lettres en majuscules
prenom 1ère lettre est un haut de casse. Les autres lettres sont des
caractères éventuellement mixtes.
noPiece 1ère lettre est un 'p' et la dernière un caractère chiffre
lot 1ère lettre est un 'b'

Interprétation du modèle de la BD 
A moins d'une indication contraire, vous faites seulement référence au MCD et aux contraintes
formulées dans le texte pour répondre aux questions ci-dessous qui visent à évaluer votre capacité
à interpréter correctement le MCD. Commentez brièvement vos réponses.

1- Est-ce qu'un matériau en vrac (VracMat) utilisé par les usines de la base de données peut l'être
par plusieurs usines?

2- Est-ce qu'un même matériau peut être fourni par plusieurs fournisseurs?

3- Est-ce que deux usines distinctes peuvent utiliser un même matériau, mais de fournisseurs
différents?

4- Est-ce qu'une usine peut fabriquer plusieurs pièces de même numéro?

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 150

5- Est-ce qu'un ouvrier peut être inscrit dans la base de données sans travailler dans une usine?

6- Que faut-il spécifier au regard d’un attribut pour que le stockage dans une usine quelconque de
ce modèle ne dépasse pas la limite supérieure de 15 000 pièces?

7- Quel effet aura la suppression d'une production dans la base de données?

8- Est-ce qu'une usine peut être représentée dans la base de données sans avoir commandé aucun
stock de matériau en vrac (VracMat)?

9- Combien de métiers peuvent être représentés dans cette base de données?

10- En théorie, quelle est la contrainte entre la quantité d'une pièce fabriquée dans une production
et la capacité de stockage de celle-ci à l'usine de production?

11- Est-ce qu'une usine sans ouvrier peut utiliser un matériau en vrac pour faire une production?

12- Est-ce qu'un ouvrier doit avoir un métier pour être représenté dans la base de données?

13- Est-ce qu'une usine planifiée par le siège social de la société ALU-NORD qui gère le réseau
d'usines peut être représentée dans la base de données même si la ville d'implantation n'est pas
encore définitivement choisie? Commenter votre réponse.

14- Commenter le cas d’une production sans client. Imaginez une situation où cela peut être
représenté.

15. En cas de fermeture d'une usine, i.e. la cessation de la production, si les productions en stock
sont conservées sur place, quelle modification faut-il apporter au MCD sans avoir à créer de
nouvelles entités ou associations?

16- Comment faut-il modifier le MCD pour représenter le fait qu'une usine peut commander les
matériaux en vrac d'un seul fournisseur? La modification doit être minimale. Quel est l’impact de
ce changement sur la représentation du modèle?

17- Décriver brièvement une procédure logique de fouille des données représentées par le MCD
pour compter combien d’instances de VracMat n'ont jamais été livrées à une usine. Supposer
qu’il existe une fonction Test(assoc) permettant de vérifier si une instance participe ou non à une
association. Cette fonction retourne Vrai ou Faux.

18- Comment est-il possible de savoir à partir du MCD si une usine donnée a une production en
stock?

19- En principe, quelle est la plus grande densité (nombre de pièces au mètre carré) possible
pour le stockage des pièces dans une usine?

20- Quelle est la contrainte entre les attributs volC et volL de l'Entité VracMat et de l'association
Utilise?
© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 151

21- La gestion des usines de ALU-NORD est transformée afin de favoriser une approche de
décentralisation. Dorénavant, une usine peut avoir un chef assigné sur place aux opérations de
gestion d'une usine. Modifier le modèle pour représenter le chef qui dirige obligatoirement une
usine. Un même chef peut diriger jusqu'à 4 usines, mais une usine n’a qu’un seul chef. Les
attributs du chef sont les suivants : nas, debutMandat, age, sexe, nom. Insérer obligatoirement
une généralisation/spécialisation dans le MCD.

22- Représenter le MCD ALU-NORD avec un autre formalisme de votre choix dans lequel les
contraintes d'association sont exprimées autrement que par le (min, max). Vous pouvez utiliser le
formalisme OMT, UML ou Merise.

23- En vous reportant au MCD RH ci-dessous qui représente les ressources humaines dans une
entreprise, décrivez le genre de structures logiques de données possibles (aussi nommées
structures conceptuelles) pour les entités (instances logiques) que l'on pourrait retrouver dans la
base de données correspondante. Une structure logique est définie comme l’ensemble des
attributs (ou valeurs) composant la définition d’une Entité et cela, sans égard à l’implémentation
physique du modèle.

Personne
nas*
nom
adresse

p
p,e

Employe Actionnaire Client


salaire nbVote margeCredit
dep

24- S'il fallait dans cette base de données représenter le fait que certains actionnaires soient aussi
des employés, quelle modification minimale faut-il apporter au modèle pour pouvoir les
représenter? Le MCD obtenu est nommé MCD RH1.

24.1 Quelle autre modification faut-il apporter si tous les actionnaires sont aussi des employés?

24.2 Modifiez le modèle pour représenter les propriétés des spécialisations par les contraintes
(min-max) équivalentes.

25- Le modèle conceptuel PUBLI ci-dessous représente la publication et la révision des livres et
des articles scientifiques publiés par des éditeurs. Compléter le modèle en y ajoutant les
contraintes (min, max) pour les associations et les propriétés de spécialisation concernées
directement ou indirectement par les faits ci-dessous. Vous ne devez pas modifier le modèle en ce
qui a trait aux Entités et aux Associations. Le nom des associations est implicite et n’a pas à être
précisé.
© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 152

Voici les contraintes des Entités et des Associations :


a- Les livres sont écrits et révisés que par certains employés des éditeurs qui à ce titre reçoivent
un salaire. Les articles sont écrits et révisés que par des pigistes bénévoles.
b- Les éditeurs peuvent publier plusieurs livres et ils peuvent aussi publier plusieurs revues.

  Editeur

Livre Revue
PigisteBenevole

Article
AuteurLivre

AuteurArticle ReviseurArticle

ReviseurLivre
Auteur

EmployeEditeur

c- Certains éditeurs publient seulement des livres, d'autres seulement des revues et certains à la
fois des livres et des revues.
d- Un livre ou une revue est publié par un éditeur.
e- Un auteur peut écrire des livres et des articles (c’est-à-dire les deux sortes de documents).
f- Un livre n’est signé que par un seul auteur, tandis que les articles sont parfois co-signés par
plusieurs.
g- Un auteur d’article ou de livre ne peut pas réviser son propre document.
h- Les pigistes et les auteurs inscrits dans la base ont respectivement révisé ou écrit au moins un
article et un livre. Ainsi, un pigiste doit avoir rédigé un article, tandis qu’un auteur doit avoir écrit
un livre.
i- Une revue publie plusieurs articles.
j- Un article est publié dans une seule revue.
k- Un livre ou un article doit être révisé, éventuellement par plusieurs réviseurs.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 153

l- Chaque réviseur d'un livre et chaque auteur d'un livre est un employé d'un éditeur.
m- Un réviseur de livre n'est pas un réviseur d'article.
n- Un éditeur embauche plusieurs personnes de fonctions différentes, notamment des rédacteurs
et des réviseurs.

26‐ Quelle modification minimale faut‐il apporter au MCD RH si tous les clients sont aussi des 
actionnaires, mais jamais un employé? 

27- Avec le MCD ci-dessous quelle modification faut-il apporter pour représenter le fait qu'un
employé travaille dans un atelier et cela pour plusieurs périodes différentes. Une période étant
définie par une paire de dates : (dateDebut: 12-3-1998, date-fin: 15-4-1998).

Employe Atelier
nas* Travaille
noAt*
nom dateDebut
budget
adresse dateFin

28- Transformez les contraintes (min, max) du modèle PUBLI ci-dessus pour les exprimer par
celles de participation et de cardinalité. Inscrivez directement les contraintes sur le schéma.

29- Que faut-il ajouter au modèle PUBLI pour qu'un auteur ne révise pas son propre article ou
livre? De même, comme les auteurs et les réviseurs d'articles ne sont pas payés, ils ne sont pas
des réviseurs de livres. Comment cette contrainte peut-elle être représentée dans le modèle
PUBLI en ajoutant une nouvelle Entité.

30- Vous devez développer un modèle qui doit comprendre une catégorie et une spécialisation.
Dans une université, il y a une banque de CoursEnClasse et de CoursEnLaboratoire. A chaque
trimestre, la direction de chaque département offre certains cours en les inscrivant à l'horaire-
trimestre. Chaque cours à l'horaire d'un trimestre est annoncé par une page web et cette page est
consacrée à un seul cours. Chaque page est hébergée sur un serveur géré par une des unités
administratives de l'université, ou par un prestataire de services externes (PageWebExterne) ou
par les deux.

Les informations décrivant les Entités (classes) de ce modèle sont les suivantes :
CoursEnClasse : noCours*, description
CoursLabo : noLabo*, materielRequis
CoursHoraireTrim: salle, jourHeure et enseignant + autres attributs (1)
PageWeb : url*
PageWebInterne : uniteAdm, url
PageWebExterne : coutJour, tel, url

(1) Les autres attributs sont en nombre variable selon qu'il s'agit d'un coursHoraireTrim qui est
un cours en classe ou un cours de laboratoire.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 154

31- Dans une société-conseil, les employés effectuent des tâches de secrétariat, d’autres de
technicien et d’autres d’informaticien. Un employé est défini par son nas et son nom de famille,
ce dernier étant composé du nom et du prénom. Une personne qui travaille au secrétariat est
singularisée par sa maîtrise d’une seule langue étrangère, tandis que le technicien l’est par la
connaissance quelques langages de programmation qu’il maîtrise parfaitement. Pour sa part,
l’informaticien a une spécialité, notamment parmi les suivantes : réseautique, commerce
électronique, analyse-objet et multimédia.

Donnez le MCD selon le formalisme E/A de (diagramme avec bulles et ovales) le plus simple
possible capable de modéliser ces informations en faisant appel à l’abstraction de
spécialisation/généralisation et en tenant compte des caractéristiques propres à chaque attribut.
Vous pouvez utiliser les attributs complexes, composés, multivalués et monovalués. La catégorie
totale peut être aussi utilisée car une spécialisation totale est équivalente à une catégorie.

32- Modélisation des œuvres d’art d’un musée (MCD ART)


Un musée national présente deux collections importantes à savoir les peinture et les sculptures. 
La  première  est  permanente  et  les  œuvres  appartiennent  au  musée,  tandis  que  certaines  
sculptures  de  la  deuxième  collection  appartiennent  à  des  personnes  qui  en  ont  fait  un  prêt  au 
musée.  L’importance  de  certaines  sculptures  et  peintures  oblige  le  musée  à  prendre  une 
assurance appropriée. Il n’y a rien qui limite la générosité des prêteurs; ceux‐ci peuvent prêter 
plusieurs  oeuvres.  Une  peinture  est  décrite  par  un  no  de  peinture,  auteur,  année,  salle.  Une 
sculpture  est  décrite  par  un  no  de  sculpture,  auteur,  poids  et  matériau.  Finalement,  l’œuvre 
assurée  est  celle  protégée  par  une  assurance  contractée,  décrite  par  le  nom  de  l’assureur,  le 
montant,  la  prime  et  l’échéance.  Les  personnes  propriétaires  de  certaines  sculptures  sont 
identifiées par leur nas, nom et adresse.  
                          
Les contraintes sont les suivantes :

‐ Une œuvre est assurée que si sa valeur le justifie selon des critères internes appliqués par les 
gestionnaires  du  musée.  Il  y  a  des  peintures  et  des  sculptures  parmi  les  œuvres  protégées  par 
une assurance.      
‐  Certaines  sculptures  appartiennent  au  musée.  Par  contre,  le  musée  est  propriétaire  de  toutes 
les peintures. 

Répondre aux questions suivantes :


a- Donner le modèle conceptuel de données pour représenter toute cette information
conformément aux contraintes énoncées.
b- Modifier le MCD obtenu pour représenter le fait que toutes les œuvres seront dorénavant
assurées.
c- Donner un autre MCD équivalent à celui obtenu en b.
 
33- Modélisation conceptuelle d’un aéroclub. (MCD AERO)
Modéliser la gestion des avions d’un aéroclub privé. Plusieurs avions du club appartiennent à des
propriétaires dont certains sont habilités à piloter leur avion ou un autre parmi ceux qui
appartiennent au club. Le hangar de rangement est décrit par un noHangar et le nombre d’avions

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 155

qu’il peut loger (sa capacité). Un avion est représenté par son immatriculation, son type et son
rayon d’autonomie. Un propriétaire d’avion est identifié par un no de dossier attribué par le
système de gestion du club. Un propriétaire d’avion peut être une société commerciale ou une
personne. La société est définie par son nomSocial et son adresse, tandis que la personne
propriétaire est décrite par son nas, son nom et son téléphone. Finalement, un pilote est
caractérisé par son noPermis, la catégorie d’avions qu’il peut piloter et la date d’échéance de son
permis.

Voici les contraintes qui doivent être représentées par ce modèle :


1- Chaque avion est rangé dans un hangar et ce dernier peut en recevoir jusqu'à 5. Tous les
avions du club sont représentés par le MCD.
2- La propriété des avions personnels (autres que ceux qui appartiennent au club) fait l’objet
d’un dossier de gestion identifié par un numéro et qui inclut toute l’information disponible sur
le propriétaire.
3- Tout propriétaire est soit une personne, soit une société. La copropriété d’un avion est
interdite. Exceptionnellement, un propriétaire peut avoir plusieurs avions.
4- Lorsque le propriétaire est une personne, celle-ci peut avoir son permis de pilote
5- Un pilote est autorisé à piloter son appareil et des avions de la catégorie autorisée appartenant
à l’aéroclub.

Le modèle demandé doit éviter le plus possible l’utilisation des valeurs nulles, i.e. des attributs
qui ne peuvent pas être valués. Selon vous, ce MCD est-il unique? Sinon, donnez un deuxième
MCD équivalent? Un MCD équivalent est un modèle qui peut représenter les mêmes données et
les mêmes contraintes sans en changer la sémantique.

34- Modélisation des matchs de tennis (MCD JMC)


Un match de tennis est identifié par la rencontre, à une date déterminée, de deux joueurs dont 
lʹun  est  obligatoirement  gagnant.  Chaque  joueur  est  défini  par  son  nom,  prénom,  âge  et 
nationalité. Il ne peut y avoir deux joueurs qui ont le même nom. Une commandite est toujours 
associée  au  joueur  et  non  au  match  et  elle  est  toujours  du  même  montant,  déterminé  par  le 
commanditaire. Les noms des gagnants et des perdants partagent le même domaine sémantique. 
Chaque  joueur  inscrit  dans  la  base  a  participé  au  moins  à  un  match,  mais  il  nʹa  pas 
nécessairement  un  commanditaire.  Ce  dernier  lorsquʹil  est  inscrit  dans  la  base  de  données  a 
nécessairement  souscrit  une  ou  plusieurs  commandites  pour  un  montant  déterminé  et  fixe  et 
pour une durée qui peut varier d’un joueur à l’autre. La date est formée avec seulement lʹannée 
représentée par une chaîne de caractères.   
Questions :
a- Donnez un MCD pour modéliser les joueurs, les commandites et les matchs. Le modèle obtenu
est nommé JMC. Pour y arriver, il vous faut faire appel à l'abstraction de spécialisation et en
préciser les propriétés.

b- Pouvez-vous donner un autre MCD avec une association récursive (ou réflexive) pour
modéliser les mêmes informations.

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 156

c- Quelle est la propriété nécessaire pour représenter un joueur non encore commandité et une
société dont le montant de la commandite est encore indéterminé ?

d- Un match peut être représenté que s'il a été joué et terminé avec un gagnant. Quel est l'impact
de cette contrainte sémantique sur les attributs?

e- Comment est-il possible de représenter le fait suivant : un joueur doit avoir un commanditaire
et même, il peut en avoir jusqu’à trois ?

f- Comment faut-il formuler la contrainte qui exige que l’âge de tout joueur soit supérieur à 17
ans ?

g- Comment formuler en français une contrainte qui limite la somme totale commanditée par une
société comme étant inférieure ou égale à 50 000.00 et cela en supposant que le montant de la
commandite est attribuée sur la base d’une durée d’une année.

h- Expliquez pourquoi la contrainte de l’association AJoueG qui représente le fait qu’un joueur a
gagné un match contre un autre joueur est (1, n) et non (0, n) ?

Références chapitre 3
1 CHEN, P., The Entity‐Relationship Model; Towards a Unified View of Data, ACM TODS, 1976, 
p. 9‐36. 
2 HULL, R., KING, R., Semantic Database Modeling; Survey, Applications, and Research Issues , 
ACM Computing Surveys, 19, mars, 1987, p. 201‐250. 
3 STOREY, VEDA, « Relational Database Design Based on the Entity‐Relationship Model », Data 
Knowledge Engineering, vol. 7, 47‐83, 1991. 
4  BLAHA,  M.  ,  PREMERLANI,  W.,  Object‐Oriented  Modeling  and  Design  for  Database 
Applications, Prentice Hall, Englewood Cliffs, NJ, 1998. 
5 HAWRYSZKKIEWYCZ, I. T., Database Analysis and Design, SRA, 1984, 576 p. 
6  ABRIAL,  J.,  Data  Semantics,  Data  Base  Management,  Proceedings  IFIP  TC2  Conference, 
Cargese, Corsica, North‐Holland, 1974. 
7  NIJSSEN,  G.  M.,  Conceptual  Schema  and  Relational  Database  Design;  A  Fact  Oriented 
Approach,  Prentice Hall,1989, p. 310, ISBN 0‐13‐167263‐0. 
8 BACHMAN, C.W., The Role Concept in Data Models, in Proceedings of the 3nd International 
Conference On Very Large Databases Tokyo, IEEE NY, October 1977,  p. 464‐476. 
9  BATINI,  C.,  CERI,  S.,  NAVATHE,  S.‐B.,  Conceptual  Database  Design,  Benjamin/Cummings, 
1992, ISBN 0‐8053‐0244‐1. 
10 ELMASRI, R., WEELDREYER, J., HEVNER, A., The Category Concept : An Extension to the 
Entity‐Relationship Model , in International Journal on Data and Knowledge Engineering, v. 1, 
no 1, 1985.    
      

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 157

INDEX 
chevauchement, 128 

Chevauchement 
abstraction de type agrégation, 115  exclusivité, 128 
Abstraction des données, 8  Classe dʹentités faibles, 105 
Accesseur, 17  Classe faible, 107 
ACCESSEUR, 30  Clé composée, 84 
active set, 55  Clé simple, 84 
ADABAS, 25  Commit, 56 
Administrateur de BD, 13  COMMIT, 56 
Agrégation, 113  Complexité de l’attribut, 81 
Agrégation  de classes, 112  Conception de la base de données, 4 
Agrégation de composition, 112  confidentialité des données, 6 
Analyseur, 17  Connexion dʹun client, 45 
Analyseur  Contrainte d’existence, 99 
API, 13  Contrainte de cardinalité, 96 
Appel au Superviseur (SVC), 32  Contrainte de participation :, 98 
Architecture, 16  Contraintes dʹassociation, 95 
Architecture ANSI/SPARC, 20  contraintes de cohérence, 7 
Architecture client/serveur, 62  contraintes structurelles, 100 
association réflexive, 92  couplage faible., 112 
Attribut, 78  couplage fort, 112 
Couverture 
B  totale, 125 
bancs dʹessai du TPC, 73  couverture totale, 126 
Base de données, 4 

C  DDL, 21 
Calcul, 17  DDL), 22 
Calcul, 30  de gestion de base de données (SGBD), 4 
Calcul dʹune réponse, 55  Degré d’une association, 88 
Caractéristiques des attributs, 81  Dictionnaire, 23 
Cas particulier  Dictionnaire de données, 11 
sous‐classe unique, 130  DML, 12, 21 
catégorie, 133  Domaine d’un attribut, 85 
Catégorie, 133 

Chasm Trap, 139 
Checkpoint, 70  Entité, 78 
CHECKPOINT, 58  Exclusion et inclusion des associations, 108 
Checkpoint et recouvrement, 59  Exercices, 147 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 158

Exercices résolus, 141  Modèle fonctionnel du logiciel, 29 
Modèles conceptuels de données, 19 
F  Modéliser avec une Classe ou un attribut ?, 
Fan Trap, 137  79 
Fichiers de contrôle, 72  MRU, 53 
Formalismes de la modélisation, 80 

G  niveau conceptuel, 8 
Généralisation, 122, 125  niveau externe, 9, 10 
Gestion Transactionnelle, 50  niveau physique, 9 

H  O 

Héritage, 131  Optimiseur, 17 
Héritage multiple, 132  Optimiseur, 30 
OSI, 63 


IDMS, 23 
Impacts du logiciel SGBD, 14  Participation totale, 98, 99 
Indépendance logique, 21  partielle, 125 
Indépendance physique, 21  Performance des SGBD, 72 
Instance de la BD, 20  Point de sauvegarde (PS), 58 
IPC, 33  Port, 37 
processus, 30 
J  Processus du SGBD, 31 
Journalisation, 71 

Journalisation, 54 
Journalisation et reprise, 56  Queue de messages, 35 

L  R 

Langage de données, 21  recouvrement après une panne, 57 
Langage de requête autonome, 12  Répartiteur, 50 
Langages L4G, 13  ROLLBACK, 57 
Le ROLL FORWARD, 57 

Logiciel SGBD, 7 
LRU, 52  Schéma de la base de données, 20 
Schéma externe, 48 
M  SDL, 21 
Mémoire partagée, 34  Serveur de processus, 68 
MER, 45  SGA, 67 
mode multithreading ( MTS), 68  SGBD, 4 
Modèle de données, 19  sous‐classe unique, 130 
Modèle Entité/Association, 77  spécialisation, 95 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca
Chapitre 3 Modèle conceptuel 159

SQL*NET, 63  U 
Superclé, 85 
utilisateurs, 14 
swapping, 31 


Validation dʹune transaction, 55 
TCP, 64 
VDL, 21 
test TPC‐A, 72 
Vue schématique du protocole IP, 65 
Thread, 32 
Vues de la BD, 9 
TOTAL, 24 
Traducteur, 17, 30  Z 
Trame technologique, 65 
ZMP, 34, 51 
Typologie des bases de données, 4 

© André Gamache, Département d’informatique et de génie logiciel, Faculté des sciences et de génie, Université
Laval, Québec, Qc, Canada, G1K 7P4. Courriel : andre.gamache@ift.ulaval.ca

Vous aimerez peut-être aussi