Vous êtes sur la page 1sur 173

NF17

CONCEPTION

DE BASES

DE DONNES

Version 10.01
Cours Gnral

STPHANE CROZAT

Paternit - Pas d'Utilisation Commerciale - Partage des Conditions Initiales l'Identique :


http://creativecommons.org/licenses/by-nc-sa/2.0/fr/

Publi le 11 janvier 2010

TABLE DES MATIRES

Introduction

I - Prsentation des bases de donnes

11

A. BD et SGBD : vue d'ensemble...............................................................................................................11


1. Qu'est ce qu'une BD ?..................................................................................................................................................11
2. Qu'est ce qu'un SGBD ?...............................................................................................................................................11
3. Pourquoi des SGBD ?..................................................................................................................................................12
4. Caractristiques des SGBD.........................................................................................................................................13

B. Notions gnrales pour les bases de donnes........................................................................................13


1. Notion de donnes........................................................................................................................................................14
2. Notion de modle de donnes......................................................................................................................................14
3. Notion de schma de donnes......................................................................................................................................15
4. Notion de langage de donnes.....................................................................................................................................16
5. Notion d'administration de donnes............................................................................................................................17

C. Les mthodes de conception de bases de donnes.................................................................................17


1. Mthodologie de conception d'une base de donnes...................................................................................................18
2. La mthode MERISE et le modle E-A........................................................................................................................19
3. Le langage de modlisation UML................................................................................................................................19
4. lments pour l'analyse de l'existant et des besoins....................................................................................................19
5. Le MCD........................................................................................................................................................................21
6. Le MLD........................................................................................................................................................................21

D. En rsum : Conception de bases de donnes.......................................................................................22

II - Le niveau conceptuel

: la modlisation des bases de donnes

23

A. Bases du diagramme de classes UML...................................................................................................23


1. Prsentation d'UML.....................................................................................................................................................23
2. Classes.........................................................................................................................................................................24
3. Attributs.......................................................................................................................................................................24
4. Mthodes......................................................................................................................................................................25
5. Associations.................................................................................................................................................................26
6. Cardinalit...................................................................................................................................................................27
7. Hritage.......................................................................................................................................................................27
8. Exemple : Des voitures et des conducteurs..................................................................................................................28

B. Diagramme de classes UML avanc......................................................................................................29


1. Explicitation des associations......................................................................................................................................29
2. Classe d'association.....................................................................................................................................................30
3. Associations ternaires..................................................................................................................................................31
4. Composition.................................................................................................................................................................31
5. Classes abstraites........................................................................................................................................................32
6. Contraintes...................................................................................................................................................................34
7. Contraintes sur les associations..................................................................................................................................35
8. Paquetages...................................................................................................................................................................36

C. Le modle E-A.......................................................................................................................................37
1. Le modle E-A en bref.................................................................................................................................................37

S. Crozat - UTC 2009

2. Entit............................................................................................................................................................................37
3. Association...................................................................................................................................................................39
4. Cardinalit d'une association......................................................................................................................................39
5. Modle E-A tendu.......................................................................................................................................................40
6. Entit de type faible.....................................................................................................................................................41
7. Illustration d'entits faibles.........................................................................................................................................41

D. En rsum : Schma conceptuel............................................................................................................42


E. Bibliographie commente sur la modlisation UML.............................................................................43

III - Le niveau logique

: la modlisation relationnelle

45

A. Description du modle relationnel.........................................................................................................45


1. Le niveau logique.........................................................................................................................................................45
2. Le modle relationnel..................................................................................................................................................46
3. Domaine.......................................................................................................................................................................46
4. Produit cartsien..........................................................................................................................................................46
5. Relation........................................................................................................................................................................47
6. Attribut et enregistrement............................................................................................................................................47
7. La relation Vol.............................................................................................................................................................48
8. Cl................................................................................................................................................................................48
9. Cl artificielle..............................................................................................................................................................49
10. Lien entre relations....................................................................................................................................................50
11. clatement des relations pour viter la redondance.................................................................................................50
12. Cl trangre.............................................................................................................................................................52
13. Schma relationnel....................................................................................................................................................52
14. Exemple de schma relationnel simple pour la gographie......................................................................................53

B. Le passage UML vers Relationnel.........................................................................................................54


1. Transformation des classes..........................................................................................................................................54
2. Transformation des associations.................................................................................................................................55
3. Remarques concernant la transformation des associations 1:1..................................................................................55
4. Transformation des attributs et mthodes...................................................................................................................56
5. Transformation des classes d'association....................................................................................................................56
6. Transformation des compositions................................................................................................................................57
7. Transformation de la relation d'hritage.....................................................................................................................57
8. Transformation de la relation d'hritage par rfrence..............................................................................................59
9. Transformation de la relation d'hritage par les classes filles....................................................................................59
10. Transformation de la relation d'hritage par la classe mre....................................................................................60
11. Exemple de transformation d'une relation d'hritage...............................................................................................61
12. Hritage et cl primaire.............................................................................................................................................63
13. Liste des contraintes..................................................................................................................................................63
14. Correspondance entre UML et relationnel................................................................................................................63

C. Le passage E-A vers Relationnel...........................................................................................................64


1. Transformation des entits...........................................................................................................................................64
2. Transformation des associations.................................................................................................................................64
3. Transformation de la relation d'hritage.....................................................................................................................65
4. Exemple de passage E-A vers relationnel....................................................................................................................65
5. Comparaison des modles E-A, UML et relationnel...................................................................................................66

D. Algbre relationnelle.............................................................................................................................67
1. Concepts manipulatoires.............................................................................................................................................67
2. Oprateurs ensemblistes..............................................................................................................................................68
3. Projection.....................................................................................................................................................................69
4. Restriction....................................................................................................................................................................69
5. Produit.........................................................................................................................................................................70
6. Jointure........................................................................................................................................................................70
7. Jointure naturelle.........................................................................................................................................................71
8. Jointure externe...........................................................................................................................................................71
9. Division........................................................................................................................................................................72
10. Proposition de notations............................................................................................................................................73
11. Exercice de synthse : Oprateurs de base et additionnels.......................................................................................73

S. Crozat - UTC 2009

E. En rsum : Schma relationnel.............................................................................................................74


F. Bibliographie commente sur le modle relationnel..............................................................................74

IV - Le langage SQL

75

A. Qu'appelle-t-on SQL?............................................................................................................................75
B. Le Langage de Dfinition de Donnes de SQL.....................................................................................76
1. Types de donnes.........................................................................................................................................................76
2. Cration de tables........................................................................................................................................................77
3. Contraintes d'intgrit.................................................................................................................................................78
4. Cration de vues..........................................................................................................................................................79
5. Suppression d'objets.....................................................................................................................................................80
6. Modification de tables.................................................................................................................................................80
7. Exemple de modifications de tables.............................................................................................................................81

C. Gestion avec le Langage de Manipulation de Donnes de SQL............................................................82


1. Insertion de donnes....................................................................................................................................................82
2. Mise jour de donnes................................................................................................................................................83
3. Suppression de donnes...............................................................................................................................................83

D. Questions avec le Langage de Manipulation de Donnes de SQL........................................................84


1. Slection.......................................................................................................................................................................84
2. Oprateurs de comparaisons et oprateurs logiques..................................................................................................85
3. Expression du produit cartsien..................................................................................................................................86
4. Expression d'une projection.........................................................................................................................................86
5. Expression d'une restriction........................................................................................................................................86
6. Expression d'une jointure............................................................................................................................................86
7. Oprateurs ensemblistes..............................................................................................................................................87
8. Tri.................................................................................................................................................................................88
9. Fonctions de calcul......................................................................................................................................................88
10. Agrgats.....................................................................................................................................................................89

E. Instructions avances pour le LMD de SQL..........................................................................................90


1. Requtes imbriques....................................................................................................................................................90
2. Sous-requte d'existence IN.........................................................................................................................................91
3. Sous-requte d'existence EXISTS.................................................................................................................................92
4. Sous-requte de comparaison ALL..............................................................................................................................92
5. Sous-requte de comparaison ANY..............................................................................................................................93
6. Raffinement de questions dans la clause FROM.........................................................................................................93

F. Le Langage de Contrle de Donnes de SQL........................................................................................94


1. Attribution de droits.....................................................................................................................................................94
2. Rvocation de droits....................................................................................................................................................95

G. En rsum : SQL....................................................................................................................................95
H. Bibliographie commente sur le SQL....................................................................................................96

V - La thorie de la normalisation relationnelle

97

A. Les dpendances fonctionnelles............................................................................................................97


1. Exercice introductif : Redondance..............................................................................................................................97
2. Les problmes soulevs par une mauvaise modlisation.............................................................................................98
3. Principes de la normalisation......................................................................................................................................99
4. Dpendance fonctionnelle............................................................................................................................................99
5. Les axiomes d'Armstrong...........................................................................................................................................100
6. Autres proprits dduites des axiomes d'Armstrong................................................................................................100
7. DF lmentaire..........................................................................................................................................................101
8. Notion de fermeture transitive des DFE....................................................................................................................101
9. Notion de couverture minimale des DFE...................................................................................................................101
10. Notion de graphe des DFE......................................................................................................................................102
11. Dfinition formelle d'une cl....................................................................................................................................102

B. Les formes normales............................................................................................................................103


1. Principe de la dcomposition.....................................................................................................................................103
2. Formes normales.......................................................................................................................................................103

S. Crozat - UTC 2009

3. Premire forme normale............................................................................................................................................104


4. Deuxime forme normale...........................................................................................................................................104
5. Troisime forme normale...........................................................................................................................................105
6. Forme normale de Boyce-Codd.................................................................................................................................106

C. Bibliographie commente sur la normalisation...................................................................................107

VI - Le relationnel-objet

109

A. Introduction : R, OO, RO....................................................................................................................109


1. Les atouts du modle relationnel...............................................................................................................................109
2. Les inconvnients du modle relationnel...................................................................................................................109
3. Les SGBDOO.............................................................................................................................................................110
4. Les SGBDRO.............................................................................................................................................................111

B. Le modle relationnel-objet.................................................................................................................111
1. Les SGBDRO.............................................................................................................................................................111
2. Le modle imbriqu...................................................................................................................................................111
3. Les types utilisateurs..................................................................................................................................................112
4. Les collections............................................................................................................................................................113
5. Comparaison relationnel et relationnel-objet...........................................................................................................113
6. Tables d'objets...........................................................................................................................................................114
7. Hritage et rutilisation de types...............................................................................................................................114
8. Identification d'objets et rfrences...........................................................................................................................115

C. Le passage conceptuel vers relationnel-objet......................................................................................116


1. Classe.........................................................................................................................................................................116
2. Attributs.....................................................................................................................................................................116
3. Association 1:N..........................................................................................................................................................117
4. Association N:M.........................................................................................................................................................117
5. Hritage.....................................................................................................................................................................117

D. SQL3 (implmentation Oracle 9i).......................................................................................................117


1. Les nouveaux types de donnes.................................................................................................................................117
2. Les types de donnes abstraits...................................................................................................................................117
3. Mthodes et SELF......................................................................................................................................................118
4. Nested tables..............................................................................................................................................................119
5. Tables d'objets...........................................................................................................................................................119
6. Insertion d'objets........................................................................................................................................................120
7. Insertion de collections partir de requtes SELECT..............................................................................................120
8. Slection dans des objets...........................................................................................................................................121
9. Slection dans des tables imbriques.........................................................................................................................122
10. Manipulation d'OID.................................................................................................................................................123

E. Exemples RO.......................................................................................................................................124
1. Exemple : Gestion de cours.......................................................................................................................................124
2. Exemple : Gestion de cours simplifie (version avec OID).......................................................................................127

F. En rsum : Le relationnel-objet..........................................................................................................129
G. Bibliographie commente sur le relationnel-objet...............................................................................129

VII - La gestion des transactions

131

A. Problmatique des pannes et de la concurrence..................................................................................131


B. Transactions.........................................................................................................................................132
1. Notion de transaction.................................................................................................................................................132
2. Droulement d'une transaction..................................................................................................................................132
3. Proprits ACID d'une transaction...........................................................................................................................132
4. Transactions en SQL..................................................................................................................................................133
5. Exemple de transaction sous Oracle..........................................................................................................................133
6. Exemple de transaction sous Access..........................................................................................................................134
7. Journal des transactions............................................................................................................................................134

C. Fiabilit et transactions........................................................................................................................135
1. Les pannes..................................................................................................................................................................135
2. Point de contrle........................................................................................................................................................135

S. Crozat - UTC 2009

3. Reprise aprs panne...................................................................................................................................................136


4. Algorithme de reprise UNDO-REDO........................................................................................................................137
5. Ecriture en avant du journal......................................................................................................................................138

D. Concurrence et transactions.................................................................................................................139
1. Trois problmes soulevs par la concurrence...........................................................................................................139
2. Le verrouillage...........................................................................................................................................................141
3. Le dverrouillage.......................................................................................................................................................142
4. Protocole d'accs aux donnes..................................................................................................................................142
5. Solution aux trois problmes soulevs par la concurrence.......................................................................................143
6. Inter-blocage..............................................................................................................................................................144

E. En rsum : Les transactions................................................................................................................145


F. Bibliographie commente sur les transactions.....................................................................................145

VIII - L'optimisation du schma interne

147

A. Introduction l'optimisation des BD...................................................................................................147


1. Schma interne et performances des applications.....................................................................................................147
2. valuation des besoins de performance....................................................................................................................148
3. Indexation..................................................................................................................................................................149
4. Dnormalisation........................................................................................................................................................149
5. Groupement de tables................................................................................................................................................150
6. Partitionnement de table............................................................................................................................................151
7. Vues concrtes...........................................................................................................................................................151

B. En rsum : L'optimisation..................................................................................................................152
C. Bibliographie commente sur l'optimisation.......................................................................................152

IX - Ouvrage de rfrence conseill

153

Questions de synthse

155

Solution des exercices de TD

173

Glossaire

175

Signification des abrviations

177

Bibliographie

179

Index

181

S. Crozat - UTC 2009

INTRODUCTION

Les BD sont nes vers la fin des annes 1960 pour combler les limites des systmes de fichiers. Les BD
relationnelles, issues de la recherche de Codd, sont celles qui ont connu le plus grand essor depuis plus de 20 ans, et
qui reste encore aujourd'hui les plus utilises. Le langage SQL est une couche technologique, idalement
indpendante des implmentations des SGBDR, qui permet de crer et manipuler des BD relationnelles.
Les usages de BD se sont aujourd'hui gnraliss pour entrer dans tous les secteurs de l'entreprise, depuis les
"petites" BD utilises par quelques personnes dans un service pour des besoins de gestion de donnes locales,
jusqu'aux "grosses" BD qui grent de faon centralise des donnes partages par tous les acteurs de l'entreprise.
Paralllement l'accroissement de l'utilisation du numrique comme outil de manipulation de toutes donnes
(bureautique, informatique applicative, etc.) et comme outil d'extension des moyens de communication (rseaux)
d'une part et les volutions technologiques (puissance des PC, Internet, etc.) d'autre part ont la fois rendu
indispensable et complexifi la problmatique des BD.
Les consquences de cette gnralisation et de cette diversification des usages se retrouvent dans l'mergence de
solutions conceptuelles et technologiques nouvelles et sans cesse renouveles.

S. Crozat - UTC 2009

I -

PRSENTATION DES BASES DE

DONNES

BD et SGBD : vue d'ensemble

11

Notions gnrales pour les bases de donnes

14

Les mthodes de conception de bases de donnes

19

En rsum : Conception de bases de donnes

24

Les BD ont t cres pour faciliter la gestion qualitative et quantitative des donnes informatiques.
Les SGBD sont des applications informatiques permettant de crer et de grer des BD (comme Oracle
ou MySQL par exemple). Les BD relationnelles sont les plus rpandues et l'on utilise des SGBDR
pour les implmenter. Le langage SQL est le langage commun tous les SGBDR, ce qui permet de
concevoir des BD relativement indpendamment des systmes utiliss.

A. BD et SGBD : vue d'ensemble


Objectifs
Comprendre l'intrt des BD.
Comprendre ce qu'est un SGBD.

1. Qu'est ce qu'une BD ?
Dfinition : Base de donnes
Une BD est un ensemble volumineux, structur et minimalement redondant de donnes, relies entre
elles, stockes sur supports numriques centraliss ou distribus, servant pour les besoins d'une ou
plusieurs applications, interrogeables et modifiables par un ou plusieurs utilisateurs travaillant
potentiellement en parallle.

Exemple : Compagnie arienne


Une BD de gestion de l'activit d'une compagnie arienne concernant les voyageurs, les vols, les avions,
le personnel, les rservations, etc. Une telle BD pourrait permettre la gestion des rservations, des
disponibilits des avions en fonction des vols effectuer, des affectation des personnels volants, etc.

2. Qu'est ce qu'un SGBD ?


Dfinition : Systme de Gestion de Bases de Donnes
Un SGBD est un logiciel qui prend en charge la structuration, le stockage, la mise jour et la
S. Crozat - UTC 2009

11

Prsentation des bases de donnes

maintenance d'une base de donnes. Il est l'unique interface entre les informaticiens et les donnes
(dfinition des schmas, programmation des applications), ainsi qu'entre les utilisateurs et les donnes
(consultation et mise jour).

Exemple : Exemples de SGBD

Oracle est un SGBD relationnel (et Relationnel-Objet dans ses dernires versions) trs reconnu
pour les applications professionnelles.
MySQL est un SGBD relationnel libre (licence GPL et commerciale), simple d'accs et trs
utilis pour la ralisation de sites Web dynamiques. Depuis la version 4 MySQL implmente la
plupart des fonctions attendues d'un SGBD relationnel.
PosgreSQL est un SGBD relationnel et relationnel-objet trs puissant qui offre une alternative
open-source aux solutions commerciales comme Oracle ou IBM.
Access est un SGBD relationnel Microsoft, qui offre une interface conviviale permettant de
concevoir rapidement des applications de petite envergure ou de raliser des prototypes
moindre frais.

3. Pourquoi des SGBD ?


a) Jadis...
Avant l'avnement des SGBD, chaque application informatique dans l'entreprise impliquait sa propre
quipe de dveloppement, ses propres supports physiques, ses propres fichiers, ses propres normes, ses
propres langages, etc.

b) Consquences...
L'existence conjointe et croissante de ces applications indpendantes a des effets ngatifs, tels que :

La multiplication des tches de saisie, de dveloppement et de support informatique

La redondance anarchique des informations dans les fichiers

L'incohrence des versions simultanes de fichiers

La non-portabilit des traitements en raison des diffrences dans les formats et langages.

La multiplication des cots de dveloppement et de maintenance des applications.

c) Problmes...
Les consquences prcdemment cites se rpercutent sur l'entreprise en gnrant des problmes humains
et matriels.
Cots en personnels qualifis et en formations

Remise des pouvoirs de dcision entre les mains de spcialistes informatiques

Tout changement matriel ou logiciel a un impact sur les applications

Tout changement de la structure des donnes ncessite de modifier les programmes

d) Or...
En ralit les applications ne sont jamais totalement disjointes, des donnes similaires (le coeur de
l'information d'entreprise) sont toujours la base des traitements.
On peut citer typiquement :

Les donnes comptables

Les donnes clients et fournisseurs

Les donnes relatives la gestion des stocks

Les donnes relatives aux livraisons

Les donnes marketting et commerciales

12

S. Crozat - UTC 2009

Prsentation des bases de donnes

Les donnes relatives au personnel


etc.

4. Caractristiques des SGBD


La conception d'un systme d'information pour tre rationnelle l'chelle d'une entreprise se doit
d'adopter un certain nombre de principes, tels que :

Une description des donnes indpendante des traitements

Une maintenance de la cohrence de donnes

Le recours des langages non procduraux, interactifs et structurants


Dans ce cadre les SGBD se fixent les objectifs suivants :

Indpendance physique des donnes


Le changement des modalits de stockage de l'information (optimisation, rorganisation,
segmentation, etc.) n'implique pas de changements des programmes.

Indpendance logique des donnes


L'volution de la structure d'une partie des donnes n'influe pas sur l'ensemble des donnes.

Manipulation des donnes par des non-informaticiens


L'utilisateur n'a pas savoir comment l'information est stocke et calcule par la machine, mais
juste pouvoir la rechercher et la mettre jour travers des IHM ou des langages
assertionnels simples.

Administration facilite des donnes


Le SGBD fournit un ensemble d'outils (dictionnaire de donnes, audit, tuning, statistiques, etc.)
pour amliorer les performance et optimiser les stockages.

Optimisation de l'accs aux donnes


Les temps de rponse et de dbits globaux sont optimiss en fonctions des questions poses la
BD.

Contrle de cohrence (intgrit smantique) des donnes


Le SGBD doit assurer tout instant que les donnes respectent les rgles d'intgrit qui leurs
sont imposes.

Partageabilit des donnes


Les donnes sont simultanment consultables et modifiables.

Scurit des donnes


La confidentialit des donnes est assure par des systmes d'authentification, de droits d'accs,
de cryptage des mots de passe, etc.

Sret des donnes


La persistance des donnes, mme en cas de panne, est assure, grce typiquement des
sauvegardes et des journaux qui gardent une trace persistante des oprations effectues.

B. Notions gnrales pour les bases de donnes


Objectifs
Connatre les diffrences entre modle conceptuel, modle logique et
implmentation physique.
Comprendre l'importance de la modlisation conceptuelle.

S. Crozat - UTC 2009

13

Prsentation des bases de donnes

1. Notion de donnes
Dfinition : Donnes
Elment effectif, rel, correspondant une type de donnes.
Synonymes : Occurence, Instance

Exemple : Donnes

L'entier 486
Le vhicule (460HP59, Renault, Megane, Jaune)

Dfinition : Type de donnes


Ensemble d'objets qui possdent des caractristiques similaires et manipulables par des oprations
identiques.
Synonymes : Classe

Exemple : Type de donnes

Entier = { 0, 1, 2, ... , N }
Vhicule = (immatriculation, marque, type, couleur)

2. Notion de modle de donnes


Dfinition : Modle de donnes
Ensemble de concepts et de rgles de composition de ces concepts permettant de dcrire des donnes (cf.
Bases de donnes : objet et relationnel [Gardarin99]).
Un modle est souvent reprsent au moyen d'un formalisme graphique permettant de dcrire les donnes
(ou plus prcisment les types de donnes) et les relations entre les donnes.
On distingue trois niveaux de modlisation pour les bases de donnes :

Le modle conceptuel
Il permet de dcrire le rel selon une approche ontologique, sans prendre en compte les
contraintes techniques.

Le modle logique
Il permet de dcrire une solution, en prenant une orientation informatique gnrale (type de
SGBD typiquement), mais indpendamment de choix d'implmentation prcis.

Le modle physique
Il correspond aux choix techniques, en terme de SGBD choisi et de sa mise en uvre
(programmation, optimisation, etc.).

Exemple : Exemple de formalisme de modlisation conceptuelle

Le modle Entit-Association (cf. The entity-Relationsheep Model - Towards a Unified View of


Data [Chen76]) a t le plus rpendu dans le cadre de la conception de bases de donnes.
Le modle UML, qui se gnralise pour la conception en informatique, se fonde sur une
approche objet.

Exemple : Exemple de formalisme de modlisation logique

14

Le modle relationnel est le modle dominant.


Le modle relationnel-objet (adaptation des modles relationnel et objet au cadre des SGBD) est
actuellement en pleine croissance.
Le modle objet "pur" reste majoritairement au stade exprimental et de la recherche.

S. Crozat - UTC 2009

Prsentation des bases de donnes

Des modles plus anciens (hirarchique, rseau, etc.) ne sont plus gure utiliss aujourd'hui.

3. Notion de schma de donnes


Dfinition : Schma de donnes
Description, au moyen d'un langage formel, d'un ensemble de donnes dans le contexte d'une BD.
Un schma permet de dcrire la structure d'une base de donnes, en dcrivant l'ensemble des types de
donnes de la base. L'occurence d'une base de donnes est constitue de l'ensemble des donnes
correspondant aux types du schma de la base.

Exemple : Schma de base de donnes


Etudiant (NumEtud, nom, ville)
Module(NumMod, titre)
Inscription(NumEtud, NumMod, date)

Exemple : Instance de base de donnes


Etudiant (172, 'Dupont', 'Lille')
Etudiant (173, 'Durand', 'Paris')
Etudiant (174, 'Martin', 'Orlans')
Module(1, 'SGBD')
Module(1, 'Systmes d'exploitation')
Inscription(172, 1, 2002)
Inscription(172, 2, 2002)
Inscription(173, 1, 2001)
Inscription(174, 2, 2002)
On distingue trois niveaux d'abstraction de schmas :

Le niveau conceptuel
Il permet de dcrire les entits et les associations du monde rel. Il s'agit du schma global de la
base de donnes, il en propose une vue canonique.
Le niveau conceptuel correspond au modle conceptuel.

Le niveau externe
Il permet de dcrire les entits et les associations du monde rel, mais vues d'un utilisateur ou
d'un groupe d'utilisateurs particuliers (on parle d'ailleurs galement de "vue" pour un shma
externe). Il s'agit d'une restriction du schma conceptuel oriente vers un usage prcis. Il existe
gnralement plusieurs schmas externes pour un mme schma conceptuel.
Le niveau externe correspond un sous ensemble du modle conceptuel restreint aux points de
vue de certains utilisateurs.

Le niveau interne
Il correspond l'implmentation physique des entits et associations dans les fichiers de la base.
Le niveau interne correspond aux modles logiques et physiques.

Remarque : ANSI/X3/SPARC
Les trois niveaux, conceptuel, externe et interne, sont les trois niveaux distingus par le groupe de
normalisation ANSI/X3/SPARC en 1975.

S. Crozat - UTC 2009

15

Prsentation des bases de donnes

Les trois niveaux de schma selon ANSI/X3/SPARC

4. Notion de langage de donnes


Dfinition : Langage de donnes
Langage informatique permettant de dcrire et de manipuler les schmas d'une BD d'une une manire
assimilable par la machine.
Synonymes : Langage orient donnes

Exemple : SQL
SQL est le langage orient donnes consacr aux SGBD relationnels et relationnels-objet.
Un langage de donnes peut tre dcompos en trois sous langages :

Le Langage de Dfinition de Donnes


Le LDD permet d'implmenter le schma conceptuel (notion de table en SQL) et les schmas
externes (notion de vue en SQL).

Le Langage de Contrle de Donnes


Le LCD permet d'implmenter les droits que les utilisateurs ont sur les donnes et participe
donc la dfinition des schmas externes.

Le Langage de Manipulation de Donnes


Le LMD permet l'interrogation et la mise jour des donnes. C'est la partie du langage

16

S. Crozat - UTC 2009

Prsentation des bases de donnes

indispensable pour exploiter la BD et raliser les applications.

Exemple : Dfinition de donnes en SQL


CREATE TABLE Etudiant (
NumEtu : integer,
Nom : string,
Ville : string)
Cette instruction permet de crer une relation "Etudiant" comportant les proprits "NumEtu", "Nom" et
"Ville".

Exemple : Contrle de donnes en SQL


GRANT ALL PRIVILEGES ON Etudiant FOR 'Utilisateur'
Cette instruction permet de donner tous les droits l'utilisateur "Utilisateur" sur la relation "Etudiant".

Exemple : Manipulation de donnes en SQL


SELECT Nom
FROM Etudiant
WHERE Ville = 'Compigne'
Cette instruction permet de rechercher les noms de tous les tudiants habitant la ville de Compigne.

5. Notion d'administration de donnes


Dfinition : Administrateur
Personne ou groupe de personnes responsables de la dfinition des diffrents niveaux de schma.
On distingue un type d'administrateur par niveau de schma :

L'administrateur entreprise est en charge de la gestion du schma conceptuel et des rgles de


contrle des donnes.

L'administrateur de donnes est en charge de la gestion des schmas externes et de leur


correspondance avec le schma conceptuel.

L'administrateur base de donnes est en charge de la gestion du schma interne et de sa


correspondance avec le schma conceptuel.

Dfinition : Dictionnaire des donnes


Le dictionnaire de donnes d'un SGBD contient les informations relatives aux schmas et aux droits de
toutes les bases de donnes existantes au sein de ce SGBD. Il s'agit d'un outil fondamental pour les
administrateurs.
Les dictionnaires de donnes sont gnralement implments sous la forme d'une base de donnes
particulire du SGBD, ce qui permet de grer les donnes relatives aux bases de donnes de la mme
faon que les autres donnes de l'entreprise (i.e. dans une base de donnes).
Synonymes : Catalogue des donnes, Mtabase

C. Les mthodes de conception de bases de donnes


Objectifs
Connatre la mthodologie de conception d'une BD.

S. Crozat - UTC 2009

17

Prsentation des bases de donnes

1. Mthodologie de conception d'une base de donnes


Mthode : tapes de la conception d'une base de donnes
1. Analyse de la situation existante et des besoins
2. Cration d'une srie de modles conceptuels (canonique et vues externes) qui permettent de
reprsenter tous les aspects importants du problme
3. Traduction des modles conceptuels en modle logique et optimisation (normalisation) de ce
modle logique
4. Implmentation d'une base de donnes dans un SGBD, partir du modle logique

Processus de conception d'une base de donnes

Conseil : L'importance de l'tape d'analyse


La premire tape de la conception repose sur l'analyse de l'existant et des besoins. De la qualit de la
ralisation de cette premire tape dpendra ensuite la pertinence de la base de donnes par rapports aux
usages. Cette premire tape est donc essentielle et doit tre mene avec soins.
Si la premire tape est fondamentale dans le processus de conception, elle est aussi la plus dlicate. En
effet, tandis que des formalismes puissants existent pour la modlisation conceptuelle puis pour la
modlisation logique, la perception de l'existant et des besoins reste une tape qui repose essentiellement
sur l'expertise d'analyse de l'ingnieur.

Conseil : L'importance de l'tape de modlisation conceptuelle


Etant donne une analyse des besoins correctement ralise, la seconde tape consiste la traduire selon
un modle conceptuel. Le modle conceptuel tant formel, il va permettre de passer d'une spcification en
langage naturel, et donc soumise interprtation, une spcification non ambige. Le recours aux
formalismes de modlisation tels que E-A ou UML est donc une aide fondamentale pour parvenir
une reprsentation qui ne sera plus lie l'interprtation du lecteur.
La traduction d'un cahier des charges spcifiant l'existant et les besoins en modle conceptuel reste
nanmoins une tape dlicate, qui va conditionner ensuite l'ensemble de l'implmentation informatique.
En effet les tape suivantes sont plus mcaniques, dans la mesure o un modle logique est dduit de
faon systmatique du modle conceptuel et que l'implmentation logicielle est galement ralise par
traduction directe du modle logique.

Remarque : Les tapes de traduction logique et d'implmentation


Des logiciels spcialiss (Sybase PowerDesigner [w_sybase] pour la modlisation E-A ou
Objecteering software [w_objecteering] pour la modlisation UML) sont capables partir d'un modle

18

S. Crozat - UTC 2009

Prsentation des bases de donnes

conceptuel d'appliquer des algorithmes de traduction qui permettent d'obtenir directement le modle
logique, puis les instructions pour la cration de la base de donnes dans un langage orient donnes tel
que SQL. L'existence de tels algorithmes de traduction montre que les tapes de traduction logique et
d'implmentation sont moins complexes que les prcdentes, car plus systmatiques.
Nanmoins ces tapes exigent tout de mme des comptences techniques pour optimiser les modles
logiques (normalisation), puis les implmentations en fonction d'un contexte de mise en oeuvre matriel,
logiciel et humain.

2. La mthode MERISE et le modle E-A


MERISE est une mthode d'analyse informatique particulirement adapte la conception de bases de
donnes.

L'analyse selon MERISE


La mthode MERISE a pour fondement le modle E-A, qui a fait son succs.
Les principales caractristiques du modle E-A sont :

Une reprsentation graphique simple et naturelle

Une puissance d'expression leve pour un nombre de symboles raisonnables

Une lecture accessible tous et donc un bon outil de dialogue entre les acteurs techniques et non
techniques

Une formalisation non ambige et donc un bon outil de spcification dtaille

3. Le langage de modlisation UML


UML est un autre langage de modlisation, plus rcent et couvrant un spectre plus large que les bases
de donnes. En tant que standard de l'OMG et en tant que outil trs utilis pour la programmation
oriente objet, il est amen supplanter petit petit la modlisation E-A.

4. lments pour l'analyse de l'existant et des besoins

S. Crozat - UTC 2009

19

Prsentation des bases de donnes

La phase d'analyse de l'existant et des besoins est une phase essentielle et complexe. Elle doit aboutir
des spcifications gnrales qui dcrivent en langage naturel les donnes manipules, et les traitements
effectuer sur ces donnes.
On se propose de donner une liste non exhaustive d'actions mener pour rdiger de telles spcifications.

Mthode : L'analyse de documents existants


La conception d'une base de donnes s'inscrit gnralement au sein d'usages existants. Ces usages sont
gnralement, au moins en partie, instruments travers des documents lectroniques ou non (papier
typiquement). Il est fondamental d'analyser ces documents et de recenser les donnes qu'ils manipulent.

Exemple : Exemples de document existants

Fichiers papiers de stockage des donnes (personnel, produits, etc.)


Formulaires papiers d'enregistrement des donnes (fiche d'identification d'un salari, fiche de
description d'un produit, bon de commande, etc.)
Documents lectroniques de type traitement de texte (lettres, mailing, procdures, etc.)
Documents lectroniques de type tableurs (bilans, statistiques, calculs, etc.)
Bases de donnes existantes, remplacer ou avec lesquelles s'accorder (gestion des salaires, de
la production, etc.)
Intranet d'entreprise (information, tlchargement de documents, etc.)
etc.

Mthode : Le recueil d'expertise mtier


Les donnes que la base va devoir manipuler sont toujours relatives aux mtiers de l'entreprise, et il existe
des experts qui pratiquent ces mtiers. Le dialogue avec ces experts est une source importante
d'informations. Il permet galement de fixer la terminologie du domaine.

Exemple : Exemples d'experts consulter

Praticiens (secrtaires, ouvrier, contrleurs, etc.)


Cadres (responsables de service, contre-matres, etc.)
Experts externes (clients, fournisseurs, etc.)
etc.

Mthode : Le dialogue avec les usagers


La base de donnes concerne des utilisateurs cibles, c'est dire ceux qui produiront et consommeront
effectivement les donnes de la base. Il est ncessaire de dialoguer avec ces utilisateurs, qui sont les
dtenteurs des connaissances relatives aux besoins rels, lis leur ralit actuelle (aspects de
l'organisation fonctionnant correctement ou dfaillants) et la ralit souhaite (volutions, lacunes, etc.).

Exemple : Exemples d'utilisateurs

Personnes qui vont effectuer les saisies d'information ( partir de quelles sources ? Quelle est
leur responsabilit ? etc.)
Personnes qui vont consulter les informations saisies (pour quel usage ? pour quel destinataire ?
etc.)
Personnes qui vont mettre jour les informations (pour quelles raisons ? comment le processus
est enclench ? etc.)
etc.

Mthode : L'tude des autres systmes informatiques existants


la base de donnes va gnralement (et en fait quasi systmatiquement aujourd'hui) s'insrer parmi un
ensemble d'autres logiciels informatiques travaillant sur les donnes de l'entreprise. Il est important

20

S. Crozat - UTC 2009

Prsentation des bases de donnes

d'analyser ces systmes, afin de mieux comprendre les mcanismes existants, leurs forces et leurs lacunes,
et de prparer l'intgration de la base avec ces autres systmes. Une partie de ces systmes seront
d'ailleurs souvent galement des utilisateurs de la base de donnes, tandis que la base de donnes sera elle
mme utilisatrice d'autre systmes.

Exemple : Exemples d'autres systmes coexistants

Autres bases de donnes (les donnes sont elle disjointes ou partiellement communes avec celles
de la base concevoir ? quelles sont les technologies logicielles sur lesquelles reposent ces
BD ? etc.)
Systmes de fichiers classiques (certains fichiers ont-ils vocations tre supplants par la base ?
tre gnrs par la base ? alimenter la base ? etc.)
Applications (ces applications ont elles besoins de donnes de la base ? peuvent-elles lui en
fournir ? etc.)
etc.

5. Le MCD
Dfinition : MCD
Le MCD est l'lment le plus connu de MERISE et certainement le plus utile. Il permet d'tablir une
reprsentation claire des donnes du SI et dfinit les dpendances des donnes entre elles.

Exemple
Le modle E-A est un formalisme de MCD, le diagramme de classe UML en est un autre.

Remarque
Un MCD est indpendant de l'tat de l'art technologique. A ce titre il peut donc tre mis en oeuvre dans
n'importe quel environnement logiciel et matriel, et il devra tre traduit pour mener une
implmentation effective.

6. Le MLD
Introduction
On ne sait pas implmenter directement un modle conceptuel de donnes dans une machine et il existe
diffrentes sortes de SGBD qui ont chacun leur propre modle : SGF (qui ne sont pas vraiment des
SGBD), SGBD hirarchiques (organiss selon une arborescence), SGBD rseau (encore appels
CODASYL), SGBDR, SGBDOO, SGBDRO, etc.

Dfinition : MLD
Un MLD est une reprsentation du systme tel qu'il sera implment dans un ordinateur.

Exemple
Le modle relationnel est un formalisme de MLD.

Remarque
Il ne faut pas confondre le MLD (relationnel par exemple) avec le MCD (E-A par exemple).
Il ne faut pas confondre le MLD avec son implmentation logicielle en machine (avec Oracle par
exemple)

S. Crozat - UTC 2009

21

Prsentation des bases de donnes

D. En rsum : Conception de bases de donnes


Conception

Modle Conceptuel
Schma conceptuel canonique et schmas externes
Exemples
E-A
UML
Modle Logique
Schma interne indpendant d'un SGBD
Exemples
Relationnel
Objet
Relationnel-Objet
Rseau
Hirarchique
Modle Physique
Schma interne pour un SGBD particulier
Exemples
Oracle
MySQL
PostgreSQL
DB2
Access
SQLServer

* *
*

Les SGBD assurent la gestion efficace et structure des donnes partages. Leur conception repose sur
une approche trois niveaux : conceptuel et externe, logique, physique.

22

S. Crozat - UTC 2009

II -

LE NIVEAU CONCEPTUEL : LA

MODLISATION DES BASES DE

II

DONNES
Bases du diagramme de classes UML

27

Diagramme de classes UML avanc

36

Le modle E-A

46

En rsum : Schma conceptuel

52

Bibliographie commente sur la modlisation UML

52

La modlisation est l'tape fondatrice du processus de conception de BD. Elle consiste abstraire le
problme rel pos pour en faire une reformulation qui trouvera une solution dans le cadre technologique
d'un SGBD. Aprs avoir rappel succinctement les fondements et objectifs des SGBD, ce chapitre
proposera les outils mthodologiques ncessaires la modlisation, travers les formalismes E-A et
UML.

A. Bases du diagramme de classes UML


Objectifs
Savoir-faire un modle conceptuel.
Savoir interprter un modle conceptuel.

Si le modle dominant en conception de bases de donnes a longtemps t le modle E-A, le modle


UML se gnralise de plus en plus. Nous ne donnons ici qu'une introduction au diagramme de classes
(parmi l'ensemble des outils d'UML), limit aux aspects particulirement utiliss en modlisation de bases
de donnes.

1. Prsentation d'UML
UML est un langage de reprsentation destin en particulier la modlisation objet. UML est devenu
une norme OMG en 1997.
UML propose un formalisme qui impose de "penser objet" et permet de rester indpendant d'un langage
de programmation donn. Pour ce faire, UML normalise les concepts de l'objet (numration et dfinition
exhaustive des concepts) ainsi que leur notation graphique. Il peut donc tre utilis comme un moyen de
communication entre les tapes de spcification conceptuelle et les tapes de spcifications techniques.
Dans le domaine des bases de donnes, UML peut tre utilis la place du modle E-A pour modliser
le domaine. De la mme faon, un schma conceptuel UML peut alors tre traduit en schma logique

S. Crozat - UTC 2009

23

Le niveau conceptuel : la modlisation des bases de donnes

(relationnel ou relationnel-objet typiquement).

2. Classes
Dfinition : Classe
Une classe est un type abstrait caractris par des proprits (attributs et mthodes) communes un
ensemble d'objets et permettant de crer des instances de ces objets, ayant ces proprits.

Syntaxe

Reprsentation UML d'une classe

Exemple : La classe Voiture

Exemple de classe reprsente en UML

Exemple : Une instance de la classe Voiture


L'objet V1 est une instance de la classe Voiture.
V1 : Voiture

Marque : 'Citron'

Type : 'ZX'

Portes : 5

Puissance : 6

Kilomtrage : 300000

Remarque : Cl
Le reprage des cls n'est pas systmatique en UML (la dfinition des cls se fera alors au niveau
logique). On conseillera nanmoins de les reprsenter (en les soulignant dans le dessin). On vitera par
contre d'ajouter des cls artificielles lorsqu'aucune cl n'est vidente.

Remarque
La modlisation sous forme de diagramme de classes est une modlisation statique, qui met en exergue la
structure d'un modle, mais ne rend pas compte de son volution temporelle. UML propose d'autres types
de diagrammes pour traiter, notamment, de ces aspects.

3. Attributs

24

S. Crozat - UTC 2009

Le niveau conceptuel : la modlisation des bases de donnes

Dfinition : Attribut
Un attribut est une information lmentaire qui caractrise une classe et dont la valeur dpend de l'objet
instanci.

Remarque

Un attribut est typ : Le domaine des valeurs que peut prendre l'attribut est fix a priori.
Un attribut peut tre multivalu : Il peut prendre plusieurs valeurs distinctes dans son
domaine.
Un attribut peut tre driv : Sa valeur alors est une fonction sur d'autres attributs de la classe
(il peut donc aussi tre reprsent comme une mthode, et c'est en gnral prfrable).
Un attribut peut tre compos : Il joue alors le rle d'un groupe d'attributs (par exemple une
adresse peut tre un attribut compos des attributs numro, type de voie, nom de la voie). Cette
notion renvoie la notion de variable de type Record dans les langages de programmation
classiques.

Syntaxe
attribut:type
attribut_multivalu[nbMinValeurs..nbMaxValeurs]:type
/attribut_driv:type
attribut_compos
- sous-attribut1:type
- sous-attribut2:type
- ...

Exemple : La classe Personne

Reprsentation d'attributs en UML


Dans cet exemple, les attributs Nom, Prnom sont de type string, l'un de 20 caractres et l'autre de 10,
tandis que DateNaissance est de type date et Age de type integer. Prnom est un attribut multivalu, ici
une personne peut avoir de 1 3 prnoms. Age est un attribut driv, il peut tre calcul par une fonction
sur DateNaissance.

4. Mthodes
Dfinition : Mthode
Une mthode (ou opration) est une fonction associe une classe d'objet qui permet d'agir sur les objets
de la classe ou qui permet ces objets de renvoyer des valeurs (calcules en fonction de paramtres).

S. Crozat - UTC 2009

25

Le niveau conceptuel : la modlisation des bases de donnes

Syntaxe
methode(paramtres):type

Remarque : Mthodes et modlisation de BD


Pour la modlisation des bases de donnes, les mthodes sont surtout utilises pour reprsenter des
donnes calcules ( l'instar des attributs drives) ou pour mettre en exergue des fonctions importantes
du systme cible. Seules les mthodes les plus importantes sont reprsentes, l'approche est moins
systmatique qu'en modlisation objet par exemple.

Remarque : Mthodes, relationnel, relationnel-objet


Lors de la transformation du modle conceptuel UML en modle logique relationnel, les mthodes ne
seront pas implmentes. Leur reprage au niveau conceptuel sert donc surtout d'aide-mmoire pour
l'implmentation au niveau applicatif.
Au contraire, un modle logique relationnel-objet permettra l'implmentation de mthodes associes
des tables. Leur reprage au niveau conceptuel est donc encore plus important.

5. Associations
Dfinition : Association
Une association est une relation logique entre deux classes (association binaire) ou plus (association naire) qui dfinit un ensemble de liens entre les objets de ces classes.
Une association est nomme, gnralement par un verbe. Une association peut avoir des proprits (
l'instar d'une classe). Une association dfinit le nombre minimum et maximum d'instances autorise dans
la relation (on parle de cardinalit).

Syntaxe

Notation de l'association en UML

Remarque
Une association est gnralement bidirectionnelle (c'est dire qu'elle peut se lire dans les deux sens). Les
associations qui ne respectent pas cette proprit sont dites unidirectionnelles ou navigation restreinte.

Exemple : L'association Conduit

Reprsentation d'association en UML


L'association Conduit entre les classes Conducteur et Voiture exprime que les conducteurs conduisent des
voitures.

26

S. Crozat - UTC 2009

Le niveau conceptuel : la modlisation des bases de donnes

6. Cardinalit
Dfinition : Cardinalit d'une association
La cardinalit d'une association permet de reprsenter le nombre minimum et maximum d'instances qui
sont autorises participer la relation. La cardinalit est dfinie pour les deux sens de la relation.

Syntaxe
Si mina (resp. maxa) est le nombre minimum (resp. maximum) d'instances de la classe A autorises
participer l'association, on note sur la relation, ct de la classe A : mina..maxa.
Si le nombre maximum est indtermin, on note n ou *.

Attention
La notation de la cardinalit en UML est oppose celle adopt en E-A. En UML on note gauche (resp.
droite) le nombre d'instances de la classe de gauche (resp. de droite) autorises dans l'association. En EA, on note gauche (resp. droite) le nombre d'instances de la classe de droite (resp. de gauche)
autorises dans l'association.

Remarque
Les cardinalit les plus courantes sont :

0..1 (optionnel)

1..1 ou 1 (un)

0..n ou 0..* ou * (plusieurs)

1..n ou 1..* (obligatoire)

Exemple : La cardinalit de l'association Possde

Reprsentation de cardinalit en UML


Ici un conducteur peut possder plusieurs voitures (y compris aucune) et une voiture n'est possde que
par un seul conducteur.

7. Hritage
Dfinition : Hritage
L'hritage est l'association entre deux classes permettant d'exprimer que l'une est plus gnrale que l'autre.
L'hritage implique une transmission automatique des proprits (attributs et mthodes) d'une classe A
une classe A'.
Dire que A' hrite de A quivaut dire que A' est une sous-classe de A. On peut galement dire que A est
une gnralisation de A' et que A' est une spcialisation de A.

Syntaxe

S. Crozat - UTC 2009

27

Le niveau conceptuel : la modlisation des bases de donnes

Notation de l'hritage en UML

Remarque
L'hritage permet de reprsenter la relation "est-un" entre deux objets.

Remarque
Outre qu'il permet de reprsenter une relation courante dans le monde rel, l'hritage a un avantage
pratique, celui de factoriser la dfinition de proprits identiques pour des classes proches.

Exemple : La classe Conducteur

Reprsentation d'hritage en UML


Dans cet exemple la classe Conducteur hrite de la classe Personne, ce qui signifie qu'un objet de la
classe conducteur aura les attributs de la classe Conducteur (TypePermis et DatePermis) mais aussi ceux
de la classe Personne (Nom, Prnom, DateNaissance et Age). Si la classe Personne avait des mthodes, la
classe Conducteur en hriterait de la mme faon.

8. Exemple : Des voitures et des conducteurs


Exemple

28

S. Crozat - UTC 2009

Le niveau conceptuel : la modlisation des bases de donnes

Exemple trs simple de diagramme de classes


Les relations de ce diagramme expriment que les conducteurs sont des personnes qui ont un permis ; que
toute voiture est possde par une unique personne (qui peut en possder plusieurs) ; que les voitures
peuvent tre conduites par des conducteurs et que les conducteurs peuvent conduire plusieurs voitures.

Remarque
Les mots cls in, out et in/out devant un paramtre de mthode permettent de spcifier si le paramtre est
une donne d'entre, de sortie, ou bien les deux.

Remarque
Le but d'une modlisation UML n'est pas de reprsenter la ralit dans l'absolu, mais plutt de proposer
une vision d'une situation rduite aux lments ncessaires pour rpondre au problme pos. Donc une
modlisation s'inscrit toujours dans un contexte, et en cela l'exemple prcdent reste limit car son
contexte d'application est indfini.

B. Diagramme de classes UML avanc


Objectifs
Matriser le diagramme de classe UML dans le cas de la conception de BD.

Les lments de modlisation suivant compltent les notations basiques du diagramme de classe : classe,
attribut, association, cardinalit et hritage.

1. Explicitation des associations


Syntaxe : Sens de lecture
Il est possible d'ajouter le sens de lecture du verbe caractrisant l'association sur un diagramme de classe
UML, afin d'en faciliter la lecture. On ajoute pour cela une flche sur l'association

S. Crozat - UTC 2009

29

Le niveau conceptuel : la modlisation des bases de donnes

Syntaxe : Rle
Il est possible de prciser le rle jou par une ou plusieurs des classes composant une association afin d'en
faciliter la comprhension. On ajoute pour cela ce rle ct de la classe concerne (parfois prcd d'un
"+" ou bien dans un petit encadr coll au trait de l'association.

Exemple

Rle et sens de lecture sur une association

Remarque : Associations rflexives


L'explicitation des associations est particulirement utile dans le cas des associations rflexives.

2. Classe d'association
Dfinition : Classe d'association
On utilise la notation des classes d'association lorsque l'on souhaite ajouter des proprits une
association.

Syntaxe : Notation d'une classe d'association en UML

Notation d'une classe d'association en UML

Exemple : Exemple de classe d'association

30

S. Crozat - UTC 2009

Le niveau conceptuel : la modlisation des bases de donnes

Emplois

3. Associations ternaires
Syntaxe

Notation d'une association ternaire

Conseil : Ne pas abuser des associations ternaires


Il est toujours possible de rcrire une association ternaire avec trois associations binaires, en
transformant l'association en classe.

Conseil : Pas de degr suprieur 4


En pratique on n'utilise jamais en UML d'association de degr suprieur 3.

4. Composition
Dfinition : Association de composition
On appelle composition une association particulire qui possde les proprits suivantes :

S. Crozat - UTC 2009

31

Le niveau conceptuel : la modlisation des bases de donnes

La composition associe une classe composite et des classes parties, tel que tout objet partie
appartient un et un seul objet composite. C'est donc une association 1:N.
La composition n'est pas partageable, donc un objet partie ne peut appartenir qu' un seul objet
composite la fois.
Le cycle de vie des objets parties est li celui de l'objet composite, donc un objet partie
disparat quand l'objet composite auquel il est associ disparait.

Remarque
La composition est une association particulire.

Syntaxe : Notation d'une composition en UML

Notation d'une composition en UML

Attention : Composition et cardinalit


La cardinalit ct composite est toujours de exactement 1.
Ct partie la cardinalit est libre, elle peut tre 0..1, 1, * ou bien 1..*.

Exemple : Exemple de composition

Un livre
On voit bien ici qu'un chapitre n'a de sens que faisant partie d'un livre, qu'il ne peut exister dans deux
livres diffrents et que si le livre n'existe plus, les chapitres le composant non plus.

Remarque : Composition et entits faibles


La composition permet d'exprimer une association analogue celle qui relie une entit faible une entit
identifiante en modlisation E-A. L'entit de type faible correspond un objet partie et l'entit
identifiante un objet composite.

5. Classes abstraites

32

S. Crozat - UTC 2009

Le niveau conceptuel : la modlisation des bases de donnes

Dfinition : Classe abstraite


Une classe abstraite est une classe non instanciable. Elle exprime donc une gnralisation abstraite, qui ne
correspond aucun objet existant du monde.

Attention : Classe abstraite et hritage


Une classe abstraite est toujours hrite. En effet sa fonction tant de gnraliser, elle n'a de sens que si
des classes en hritent. Une classe abstraite peut tre hrite par d'autres classes abstraites, mais en fin de
chane des classes non abstraites doivent tre prsentes pour que la gnralisation ait un sens.

Syntaxe : Notation d'une classe abstraite en UML


On note les classes abstraites en italique.

Notation d'une classe abstraite en UML

Exemple : Exemple de classe abstraite

Des chiens et des hommes


Dans la reprsentation prcdente on a pos que les hommes, les femmes et les chiens taient des objets
instanciables, gnraliss respectivement par les classes mammifre et humain, et mammifre.
Selon cette reprsentation, il ne peut donc exister de mammifres qui ne soient ni des hommes, ni des
femmes ni des chiens, ni d'humains qui ne soient ni des hommes ni des femmes.

S. Crozat - UTC 2009

33

Le niveau conceptuel : la modlisation des bases de donnes

6. Contraintes
Ajout de contraintes dynamiques sur le diagramme de classe
Il est possible en UML d'exprimer des contraintes dynamiques sur le diagramme de classe, par annotation
de ce dernier.

Syntaxe : Notation de contraintes

Notation contraintes en UML

Exemple : Exemple de contraintes

Commandes

34

S. Crozat - UTC 2009

Le niveau conceptuel : la modlisation des bases de donnes

Mthode : Expressions formelles ou texte libre ?


Il est possible d'exprimer les contraintes en texte libre ou bien en utilisant des expressions formelles.
On privilgiera la solution qui offre le meilleur compromis entre facilit d'interprtation et non ambigut.
La combinaison des deux est galement possible si ncessaire.

Mthode : Quelles contraintes exprimer ?


En pratique il existe souvent de trs nombreuses contraintes, dont certaines sont videntes, ou encore
secondaires. Or l'expression de toutes ces contraintes sur un diagramme UML conduirait diminuer
considrablement la lisibilit du schma sans apporter d'information ncessaire la comprhension. En
consquence on ne reprsentera sur le diagramme que les contraintes les plus essentielles.
Notons que lors de l'implmentation toutes les contraintes devront bien entendu tre exprimes. Si l'on
souhaite prparer ce travail, il est conseill, lors de la modlisation logique, de recenser de faon
exhaustive dans un tableau toutes les contraintes implmenter.

7. Contraintes sur les associations


Concernant les associations, il existe une liste de contraintes exprimes de faon standard.

Syntaxe

Notation des contraintes sur les associations

Dfinition : Inclusion
Si l'association inclue est instancie, l'autre doit l'tre aussi (la contrainte d'inclusion a un sens, reprsent
par une flche).

Syntaxe
{IN}, galement note {Subset} ou {I}.

Dfinition : Et (galit, simultanit)


Si une association est instancie, l'autre doit l'tre aussi (quivalent une double inclusion).

Syntaxe
{AND}, galement note {=} ou {S} pour simultanit.

Dfinition : Exclusion
Les deux associations ne peuvent tre instancis en mme temps.

Syntaxe
{X}

S. Crozat - UTC 2009

35

Le niveau conceptuel : la modlisation des bases de donnes

Dfinition : Ou inclusif (couverture, totalit)


Au moins une des deux relations doit tre instancie.

Syntaxe
{OR}, galement not {T} pour totalit.

Dfinition : Ou exclusif (partition)


Une exactement des deux relations doit tre instancie.

Syntaxe
{XOR}, galement note {+} ou {XT} ou {Partition}.

8. Paquetages
Dfinition : Package
Les paquetages (plus communment appels package) sont des lments servant organiser un modle.
Ils sont particulirement utile ds que le modle comporte de nombreuses classes et que celles-ci peuvent
tre tries selon plusieurs aspects structurants.

Syntaxe

Syntaxe des paquetages

Exemple

Exemple d'utilisation des packages

Mthode
On reprsente chaque classe au sein d'un package. Il est alors possible de faire une prsentation globale
du modle (tous les packages), partielle (1 package) ou centre sur un package : l'on reprsente alors le

36

S. Crozat - UTC 2009

Le niveau conceptuel : la modlisation des bases de donnes

package avec ses classes, ainsi que toutes les classes lies des autres packages.

Prsentation partielle du modle centre sur un package

C. Le modle E-A
Objectifs
Savoir-faire un modle E-A tendu.
Savoir interprter un modle E-A tendu.

1. Le modle E-A en bref


Le modle E-A (ou E-R en anglais) permet la modlisation conceptuelle de donnes.
Il correspond au niveau conceptuel de la mthode MERISE (mthode d'analyse informatique), le MCD
(cf. Mthode MERISE Tome 1 : Principes et outils [Tardieu83], Mthode MERISE Tome 2 : Dmarche
et pratiques [Tardieu85]).
La conception E-A est issue des travaux de Chen [Chen76] et se fonde sur deux concepts principaux et
un troisime sous-jacent : l'entit, l'association et l'attribut ou proprit.

2. Entit
Dfinition : Entit
Une entit est un objet du monde rel avec une existence indpendante.
Une entit (ou type dentit) est une chose (concrte ou abstraite) qui existe et est distinguable des autres
entits.
L'occurrence dune entit est un lment particulier correspondant lentit et associ un lment du
rel. Chaque entit a des proprits (ou attributs) qui la dcrivent. Chaque attribut est associ un
domaine de valeur. Une occurence a des valeurs pour chacun de ses attributs, dans le domaine
correspondant.

Syntaxe

Notation MERISE de l'entit

S. Crozat - UTC 2009

37

Le niveau conceptuel : la modlisation des bases de donnes

Notation Chen de l'entit

38

S. Crozat - UTC 2009

Le niveau conceptuel : la modlisation des bases de donnes

Remarque

Un attribut est atomique, c'est dire qu'il ne peut prendre qu'une seule valeur pour une
occurence.
Un attribut est lmentaire, c'est dire qu'il ne peut tre exprim par (ou driv) d'autres
attributs.
Un attribut qui identifie de faon unique une occurence est appel attribut cl.

3. Association
Dfinition : Association
Une association (ou type dassociation) reprsente un lien quelconque entre diffrentes entits.
Une occurrence dune association est un lment particulier de lassociation constitu dune et une seule
occurrence des objets participants lassociation. On peut dfinir des attributs sur les associations. Le
degr d'une association est le nombre d'entits y participant (on parlera notamment d'association binaire
lorsque deux entits sont concernes).

Syntaxe

Notation MERISE de l'association

Notation Chen de l'association

Remarque
On peut avoir plusieurs associations diffrentes dfinies sur les mmes entits.

4. Cardinalit d'une association


Dfinition : Cardinalit d'une association binaire
Pour les associations binaires la cardinalit minimale (resp. maximale) d'une association est le nombre
minimum (resp. maximum) d'occurrences de l'entit d'arrive associes une occurrence de l'entit de
dpart.

Syntaxe

S. Crozat - UTC 2009

39

Le niveau conceptuel : la modlisation des bases de donnes

Notation de la cardinalit

Exemple

Livre-Auteur
Le diagramme E-A prcdent exprime qu'un auteur peut avoir crit plusieurs livres (mais au moins un), et
que tout livre ne peut avoir t crit que par un et un seul auteur.

Remarque : Trois grands types de cardinalit


Il existe trois grands types de cardinalit :

Les associations 1:N (qui incluent les association 0,1:N)

Les associations N:M

Les associations 1:1 (qui incluent les association 0,1:1)


Les autres associations peuvent toujours tre ramenes des associations N:M (dans le cas gnral) ou
plusieurs associations 1:N (cas des associations 2:N ou 3:N par exemple).

5. Modle E-A tendu


Introduction
On peut tendre le modle E-A "classique" de faon accroitre son pouvoir de reprsentation. Cette
extension du modle E-A permet de favoriser la dimension conceptuelle et de s'approcher des
reprsentations objet, telles que UML.

a) Attributs composites
Un attribut peut tre compos hirarchiquement de plusieurs autres attributs.

Exemple
Un attribut Adresse est compos des attributs Numro, Rue, No_Appartement, Ville, Code_Postal, Pays.

Remarque
Le domaine d'un attribut composite n'est donc plus un domaine simple (entier, caractres, etc.).

b) Attributs multivalus
Tout attribut peut tre monovalu ou multivalu.

Exemple
Les ges des enfants dun employ.

Remarque
Un attribut multivalu n'est donc plus atomique.

40

S. Crozat - UTC 2009

Le niveau conceptuel : la modlisation des bases de donnes

c) Attributs driv
La valeur d'un attribut peut tre drive d'une ou plusieurs autres valeurs d'attributs.

Exemple
L'ge d'une personne peut tre driv de la date du jour et de celle de sa naissance.

Remarque
Un attribut driv n'est donc plus lmentaire.

d) Sous-type d'entit
Une entit peut-tre dfinie comme sous-type d'une entit plus gnrale.

Exemple
Les entits Cadre et Technicien sont des sous-types de l'entit Employ.

Remarque
La notion de sous-type est quivalente la notion d'hritage en modlisation objet.

6. Entit de type faible


Certaines entits dites "faibles" n'existent qu'en rfrence d'autres entits dites "identifiantes". L'entit
identifiante est appel "identifiant tranger" et l'association qui les unit "association identifiante".

Dfinition : Entit de type faible


Une entit de type faible, galement appele entit non identifie, possde une cl locale (appele
identifiant relatif) qui permet d'identifier une de ses occurrences parmi l'ensemble des occurrences
associes une occurrence de l'entit identifiante. La cl complte d'une entit faible est la concatnation
de la cl de l'entit identifiante et de sa cl locale.

Exemple

Association identifiante
L'entit Tche est compltement dpendante de l'entit Projet et sa cl locale (No_tche) n'est pas
suffisante l'identifier de faon absolue.

Attention
Le reprage des entits de type faible est trs important dans le processus de modlisation, il permet de
rflchir la meilleure faon d'identifier de faon unique les entits et donc de trouver les meilleures cls.
Notons de plus que le reprage d'entits faibles aura une influence importante sur le modle relationnel
rsultant.

7. Illustration d'entits faibles


Exemple

S. Crozat - UTC 2009

41

Le niveau conceptuel : la modlisation des bases de donnes

Villes
Dans le schma ci-avant, on remarque que l'entit "ville" est faible par rapport l'entit "dpartement",
qui est faible par rapport "rgion", qui est faible par rapport "pays". Cela signifie que la cl de ville,
son nom, est une cl locale et donc que l'on considre qu'il ne peut pas y avoir deux villes diffrentes avec
le mme nom, dans un mme dpartement. Il est par contre possible de rencontrer deux villes
diffrentes avec le mme nom, dans deux dpartements diffrents. De la mme faon chaque dpartement
possde un nom qui l'identifie de faon unique dans une rgion, et chaque rgion possde un nom qui
l'identifie de faon unique dans un pays.
Si les entits n'taient pas faibles, l'unicit d'un nom de ville serait valable pour l'ensemble du modle, et
donc, concrtement, cela signifierai qu'il ne peut exister deux villes avec le mme nom au monde (ni deux
dpartements, ni deux rgions).

Remarque
Notons pour terminer que, puisque "pays" n'est pas une entit faible, sa cl "nom" est bien unique pour
l'ensemble du modle, et donc cela signifie qu'il ne peut exister deux pays avec le mme nom au monde.

D. En rsum : Schma conceptuel


Schma conceptuel
Un schma conceptuel peut tre reprsent sous forme de modle E-A ou sous forme de diagramme de
classe UML.

Entit ou Classe
Proprit ou Attribut
Typ
Multi-valu
Compos
Driv
Mthode
Paramtres
Valeur de retour

Association
Association
Verbe
Cardinalit
Hritage
Hritage d'attributs
Hritage de mthodes
Composition (ou entit faible)
Cardinalit

42

S. Crozat - UTC 2009

Le niveau conceptuel : la modlisation des bases de donnes

E. Bibliographie commente sur la modlisation UML


Complment : Outils de modlisation UML
Il existe de nombreux outils de modlisation UML. On pourra citer :

Dia [w_dia] : logiciel Open Source et multi-plateformes facile d'usage (qui marche nanmoins
mieux sur Linux que sur Windows).

Objecteering [w_objecteering] (version gratuite).


voir galement en Open Source : ArgoUML1 ou EclipseUML.2 (non test par l'auteur).

Complment : Modlisation UML


UML2 en action [Roques04]
Pour un aperu plus dtaill des possibilits d'expression du diagramme de classe UML, lire le chapitre
7 : Dveloppement du modle statique (pages 133 163).
On pourra notamment y trouver :

L'association d'agrgation

Les proprits d'association

L'expression de rles dans les associations

Les attributs de classe

Les qualificatifs

Les oprations (ou mthodes)


Le chapitre donne de plus des conseils mthodologiques pour la conception (voir en particulier la
synthse page 163).
On pourra galement y trouver :

Des principes de choix de modlisation entre attributs et classes et sur la segmentation des
classes

Des principes de slection des attributs (redondance avec les associations, avec les classes, etc.)

Des principes de slection des associations

Des principes de choix de cardinalit (notamment pour la gestion d'historisation)

Des principes de slection des relations de gnralisation (hritage)

Des principes d'introduction de mtaclasses (type)s

Complment : Rfrence UML en ligne


UML en Franais [w_uml.free.fr]
Une trs bonne rfrence en ligne sur la modlisation UML, avec des cours, des liens vers la norme, etc.
Le contenu dpasse trs largement l'usage d'UML pour la modlisation de BD (et ne fait d'ailleurs pas de
rfrence prcise ce sous-ensemble particulier).
On pourra consulter en particulier le chapitre sur les diagrammes de classe : http://uml.free.fr/cours/ip14.html

Complment : Tutoriel sur la modlisation UML.


UML en 5 tapes [w_journaldunet.com(1)]
On
consultera
en
particulier
le
tutoriel
sur
les
diagrammes
http://developpeur.journaldunet.com/tutoriel/cpt/010607cpt_umlintro.shtml

de

classe

Complment : Conseils
Cinq petits conseils pour un schma UML efficace [w_journaldunet.com(2)]
1 - http://argouml.tigris.org/
2 - http://www.eclipsedownload.com/
S. Crozat - UTC 2009

43

III -

LE NIVEAU LOGIQUE : LA

MODLISATION RELATIONNELLE

III

Description du modle relationnel

55

Le passage UML vers Relationnel

68

Le passage E-A vers Relationnel

80

Algbre relationnelle

85

En rsum : Schma relationnel

92

Bibliographie commente sur le modle relationnel

93

Le modle relationnel est aux fondements des SGBDR. Il a t - et continue d'tre - le modle
thorique dominant pour la reprsentation logique des BD. Le modle relationnel permet de reformuler le
modle conceptuel dans un formalisme beaucoup plus proche de l'implmentation informatique, bien que
encore indpendant d'une solution technologique particulire.
Le modle relationnel, et en particulier l'algbre relationnelle qui lui est associe, est aussi le fondement
thorique du langage standard SQL, qui est utilis pour manipuler les donnes stockes dans une BD.

A. Description du modle relationnel


Objectifs
Connatre les fondements thoriques du modle relationnel.
Comprendre le principe d'clatement des relations et de non-redondance.

1. Le niveau logique
Le niveau logique est le lien entre le niveau conceptuel et l'implmentation effective de l'application. Le
modle conceptuel tant un modle formel, le modle logique a pour vocation d'tre galement un modle
formel, mais spcifiant non plus la ralit existante ou recherche comme le modle conceptuel, mais les
donnes telles qu'elles vont exister dans l'application informatique.
Pour assumer cette fonction, le modle relationnel [Codd70] s'est impos en raction aux insuffisances
des modles prcdents, les modles hirarchique et rseau, et de part la puissance de ses fondements
mathmatiques.
Encore aujourd'hui dominant le modle relationnel est un fondement indispensable la conception de
bases de donnes. De plus le modle mergeant actuellement est le modle relationnel-objet, et ce dernier
est bien une extension du modle relationnel qui le renforce et s'y appuie.

S. Crozat - UTC 2009

45

Le niveau logique : la modlisation relationnelle

2. Le modle relationnel
Introduction
Le modle relationnel a t introduit par Codd [Codd70], en 1970 au laboratoire de recherche d'IBM
de San Jos. Il s'agit d'un modle simple et puissant la base de la majorit des bases de donnes
aujourd'hui.

Dfinition : Modle relationnel


Ensemble de concepts pour formaliser logiquement la description d'articles de fichiers plats,
indpendamment de la faon dont ils sont physiquement stocks dans une mmoire numrique.
Le modle relationnel inclut des concepts pour la description de donnes, ainsi que des concepts pour la
manipulation de donnes.
Les objectifs du modle relationnel, formuls par Codd, sont les suivants :

Assurer l'indpendance des applications et de la reprsentation interne des donnes

Grer les problmes de cohrence et de redondance des donnes

Utiliser des langages de donnes bass sur des thories solides

Remarque : Extension du modle relationnel


Le modle relationnel est un standard, normalis par l'ISO travers son langage, le SQL. Il se veut
nanmoins ds l'origine extensible, pour permettre de grer des donnes plus complexes que les donnes
tabulaires. Le modle relationnel-objet est n de cette extension.

3. Domaine
Dfinition : Domaine
Ensemble, caractris par un nom, dans lequel des donnes peuvent prendre leurs valeurs.

Remarque
Un domaine peut-tre dfini en intention (c'est dire en dfinissant une proprit caractristique des
valeurs du domaine) ou en extension (c'est dire en numrant toutes les valeurs du domaine)

Exemple : Domaines dfinis en intention

Entier
Rel
Boolen
Chane de caractres
Montaire : rel avec deux chiffres aprs la virgule
Date : chane de 10 caractres comprenant des chiffres et des tirets selon le patron "00-00-0000"
Salaire : Montaire compris entre 15.000 et 100.000

Exemple : Domaines dfinis en extension

Couleur : {Bleu, Vert, Rouge, Jaune, Blanc, Noir}


SGBD : {Hirarchique, Rseau, Relationnel, Objet, Relationnel-Objet}

4. Produit cartsien
Dfinition : Produit cartsien
Le produit cartsien, not "X", des domaines D1, D2, ... , Dn, not "D1 X D2 X ... X Dn" est l'ensemble
des tuples (ou n-uplets ou vecteurs) <V1,V2,...,Vn> tel que Vi est une valeur de Di et tel que toutes les

46

S. Crozat - UTC 2009

Le niveau logique : la modlisation relationnelle

combinaisons de valeurs possibles sont exprimes.

Exemple
D1 = {A, B, C}
D2 = {1, 2, 3}
D1 X D2 = {<A,1>, <A,2>, <A,3>, <B,1>, <B,2>, <B,3>, <C,1>,
<C,2>, <C,3>,}

5. Relation
Dfinition : Relation
Une relation sur les domaines D1, D2, ..., Dn est un sous-ensemble du produit cartsien "D1 X D2 X ... X
Dn". Une relation est caractrise par un nom.
Synonymes : Table, tableau

Syntaxe
On peut reprsenter la relation R sur les domaine D1, ... , Dn par une table comportant une colonne pour
chaque domaine et une ligne pour chaque tuple de la relation.
D1

...

Dn

V1

...

Vn

...

...

...

V1

...

Vn

Tableau 1 Relation R

Remarque
Une relation est toujours dfinie en extension, par l'numration des tuples la composant.

6. Attribut et enregistrement
Dfinition : Attribut
On appelle attribut d'une relation, une colonne de cette relation. Un attribut est caractris par un nom et
un domaine dans lequel il prend ses valeurs.
Synonymes : Champs, Proprit, Colonne

Dfinition : Enregistrement
On appelle enregistrement d'une relation, une ligne de cette relation. Un enregistrement prend une valeur
pour chaque attribut de la relation.
Synonymes : Tuple, N-uplet, Vecteur, Ligne

Exemple
A

Tableau 2 Relation R
La relation R comporte les deux attributs A et B et les trois enregistrements <1,1>, <1,2> et <2,2>

S. Crozat - UTC 2009

47

Le niveau logique : la modlisation relationnelle

Remarque : Attribut, domaine, ordre


Un attribut se distingue d'un domaine car il peut ne comporter que certaines valeurs de ce domaine.
Les colonnes de la relation ne sont pas ordonnes et elles ne sont donc repres que par le nom de
l'attribut.

Remarque : Valeur nulle


Un enregistrement peut ne pas avoir de valeur pour certains attributs de la relation, parce que cette valeur
est inconnue ou inapplicable, sa valeur est alors "null".

7. La relation Vol
Exemple
Numero

Compagnie

Avion

Dpart

Arriv e

Date

AF3245

AirFrance

747

Paris

OulanBator

01082002

AF6767

AirFrance

A320

Paris

Toulouse

30072002

KLM234

KML

727

Paris

Amsterdam

31072002

Tableau 3 Relation Vol

8. Cl
Dfinition : Cl
Une cl est un groupe d'attributs minimum qui dtermine un tuple unique dans une relation.

Attention : Attributs de cls toujours valus


Afin d'tre dterminants pour l'identification d'un enregistrement, tous les attributs d'une cl doivent tre
valus, c'est dire qu'aucun ne peut avoir de valeur "null".

Dfinition : Cl primaire
Toute relation doit comporter au moins une cl, ce qui implique qu'une relation ne peut contenir deux
tuples identiques.
Si plusieurs cls existent dans une relation, on en choisit une parmi celles-ci. Cette cl est appele cl
primaire.
La cl primaire est gnralement choisie de faon ce qu'elle soit la plus simple, c'est dire portant sur le
moins d'attributs et sur les attributs de domaine les plus basiques (entiers ou chanes courtes
typiquement).

Dfinition : Cls candidates


On appelle cls candidates l'ensemble des cls d'une relation qui n'ont pas t choisies comme cl
primaire (elles taient candidates cette fonction).

Remarque : Dtermination d'une cl


Dfinir un groupe d'attributs comme tant une cl ncessite une rflexion smantique sur les donnes
composant ces attributs, afin de s'assurer de leur unicit.

Exemple

48

L'attribut numro de scurit sociale d'une relation personne est une bonne cl car son unicit est
assure smantiquement.

S. Crozat - UTC 2009

Le niveau logique : la modlisation relationnelle

Le groupe d'attributs nom, prnom d'une relation personne est en gnral une mauvaise cl, car
les homonymes existent.

9. Cl artificielle
Dfinition : Cl artificielle
S'il est impossible de trouver une cl primaire, ou que les cls candidates sont trop complexes, il est
possible de faire appel une cl artificielle. Une cl artificielle est un attribut supplmentaire ajout au
schma de la relation, qui n'est li aucune signification, et qui sert uniquement identifier de faon
unique les enregistrements et/ou simplifier les rfrences de cls trangres.

Dfinition : Cl signifiante
Une cl est signifiante si elle n'est pas artificielle.

Remarque : Cl artificielle et niveau logique


Au niveau du modle logique, il faut viter la simplicit consistant identifier toutes les relations avec
des cls artificielles, et ne rserver cet usage qu'aux cas particuliers.

Remarque : Cl artificielle et niveau physique, volutivit, maintenance et


performance
Au niveau de l'implmentation physique par contre, il est courant que des cls artificielles soient utilises
de faon systmatique.
Du point de vue de l'volutivit de la BD, il existe toujours un risque qu'une cl non-artificielle perde sa
proprit d'unicit ou de non-nullit.
Du point de vue de la maintenance de la BD, il existe toujours un risque qu'une cl non-artificielle voit
sa valeur modifie et dans ce cas, la rpercution de ce changement pour mettre jour toutes les rfrences
peut poser problme.
Du point de vue de la performance de la BD, les cls non-artificielles ne sont pas en gnral optimises
en terme de type et de taille, et donc peuvent limiter les performances dans le cadre des jointures.
Prcisons nanmoins qu'inversement les cls artificielles ont pour consquence de systmatiser des
jointures qui auraient pu tre vites avec des cls primaires signifiantes.

Exemple : Problme d'volutivit pos par une cl signifiante


Soit le numro de scurit sociale la cl primaire d'une table d'une BD franaise, elle ne permettra pas
d'entrer un individu non-franais issu d'un pays ne disposant pas d'un tel numro.

Exemple : Problme de maintenance pos par une cl signifiante


Soit le numro de scurit sociale la cl primaire d'une table d'une BD centrale dont les donnes sont
exploites par d'autres tables d'autres BD qui viennent "piocher" dans cette BD pour leurs propres usages,
sans que la BD centrale ne connaisse ses "clients". Soit une erreur dans la saisie d'un numro de scurit
sociale dans la BD centrale, si ce numro est corrig, il faudrait (ce qui n'est pas possible dans notre cas)
imprativement en avertir toutes les bases utilisatrices pour qu'elles mettent jour leurs rfrences.

Exemple : Problme de performance pos par une cl signifiante


Soit le numro de scurit sociale la cl primaire d'une table comptant un million d'enregistrements, ce
numro est gnralement un nombre 13 chiffres ou une chane 13 caractres, ce qui dans les deux cas
est suprieur au nombre 7 chiffres suffisant pour identifier tous les individus de la BD. Les
performances seront donc toujours moins bonnes, lors des jointures, si une cl prend deux fois plus de
place en mmoire que son optimum. Mais ajoutons que cette perte de performance n'a pas toujours de
consquence sur la ralit perceptible par les utilisateurs de la BD.
Inversement, soit une cl artificielle la cl primaire d'une table T1, par ailleurs rfrence par une autre
table T2. Soit le numro de scurit sociale un attribut cl de T1. Si l'on veut par requte disposer des

S. Crozat - UTC 2009

49

Le niveau logique : la modlisation relationnelle

informations de T2 ainsi que du numro de scurit sociale de T1, alors il faudra faire une jointure, tandis
que si ce numro signifiant avait t choisi comme cl primaire, cela n'aurait pas t ncessaire.

10. Lien entre relations


Le modle relationnel a pour objectif la structuration de donnes selon des relations. L'enjeu est de
parvenir traduire un modle conceptuel en modle logique relationnel. Typiquement si le formalisme
conceptuel utilis est le modle E-A, il faudra pouvoir traduire les entits et les associations en
relations. Afin que la reprsentation des donnes ne soit pas redondante, il est ncessaire que les donnes
soit rparties dans de multiples relations et non regroupes dans une seule. Or un modle conceptuel
informe sur les liens entre les entits et associations, cela est traduit graphiquement par les lignes qui les
relient. Il est donc fondamental que le modle relationnel puisse galement maintenir cette information,
savoir les liens entre les donnes rparties dans les relations.
Afin de reprsenter des liens entre relations dans un modle relationnel, la seule solution est de stocker
l'information dans une relation, et donc que certains attributs d'une relation servent pointer sur d'autres
relations.

Mthode : Lien
Le lien entre deux tuples A=>B de deux relations diffrentes est matrialisable par une rfrence depuis
l'un des tuples, A, la cl primaire de l'autre tuple, B.

Exemple

Principe des liens entre relations


L'attribut "Attribut2" de la relation "Relation1" rfrence l'attribut "Attribut1" de la relation "Relation2"
("Attribut1" est la cl primaire de "Relation2").

Remarque : Direction du lien


Dans un modle relationnel, un lien est toujours unidirectionnel.

11. clatement des relations pour viter la redondance


a) Relation redondante
Numero

Date

Gare1

Gare2

Train

Vitesse

Nom

Prnom

1010

01012001 Paris

Lyon

TG V

450

Dupont

Jolle

1011

02012001 Paris

Limoges

TER

200

Durand

JeanPierre

1012

03012001 Paris

Madrid

TG V

450

Dupont

Jolle

1013

03012001 Lyon

Limoges

TER

200

Dupont

JeanPierre

Tableau 4 Relation VoyageEnTrain

Dans la reprsentation prcdente, les voyages en train sont reprsents dans une unique relation, qui
contient des informations relatives au voyage lui mme (numro, date, dpart, arrive), mais aussi au train
utilis pour le voyage (type de train et vitesse maximale), et au conducteur du train (nom et prnom).
Cette reprsentation, bien que trs simplifie par rapport la ralit (on imagine facilement plusieurs

50

S. Crozat - UTC 2009

Le niveau logique : la modlisation relationnelle

dizaines d'attibuts possibles) est redondante. En effet chaque fois qu'un voyage mobilisera un train TGV,
la vitesse maximale de 450 km/h devra aussi tre rappele. De mme pour chaque conducteur, il faudra
rappeler le nom et le prnom.
Cette redondance pose un certain nombre de problmes :

Incohrence
Imaginons qu'une faute de saisie se glisse dans l'orthographe du nom de Dupont (un "d" la
place du "t") pour le voyage 1010, il sera impossible de savoir que c'est la mme personne qui
conduit le train pour le voyage 1012 (car Jolle Dupond peut exister et tre conductrice de train).

Mise jour
Imaginons que Jolle Dupont se marie et change de nom, il faudra changer cette information
pour tous les voyages auxquels participe cette conductrice. Ceci est galement un risque d'erreur,
qui renvoie au risque d'incohrence prcdemment mis en exergue.

Perte d'information
Imaginons que temporairement plus aucun voyage n'existe pour des TGV. Tous les
enregistrements portant sur les TGV disparaitront. On perdra alors l'information comme quoi la
vitesse d'un TGV est de 450 km/h, car cette information n'existera plus dans la base. Or
l'information intrinsque au TGV, qui est sa vitesse maximale, n'est pas lie un voyage en
particulier, et donc il est dommage de ne pas conserver cette information indpendamment du
fait que les TGV sont ou non utiliss un instant t.

Dpendance des insertions


Imaginons que nous souhaitions reprsenter dans la base de donnes un nouveau conducteur, qui
n'est encore affect aucun voyage. Il est impossible d'ajouter une telle information, car
l'insertion d'une personne est dpendant de l'insertion d'un tuple complet portant galement sur
un voyage. Il est videmment trs mauvais d'imaginer des solutions de contournement, telles que
par exemple un tuple avec des valeurs nulles sur toutes les proprits sauf les nom et prnom.

b) Relation clate
Le bon usage du modle relationnel consiste donc clater les informations dans de multiples relations,
afin de ne pas conserver de redondance. Dans le cas prcdent, on prfrera donc un dcoupage de la
relation VoyageEnTrain en trois relations, Voyage, Modele et Conducteur, chacune reprsentant des
informations correspondant des objets diffrents (notons l'ajout d'une cl artificielle numro pour la
nouvelle relation conducteur, non identifiable de faon unique par les attributs nom et prnom).
Numero

Date

Gare1

Gare2

1010

01012001

Paris

Lyon

1011

02012001

Paris

Limoges

1012

03012001

Paris

Madrid

1013

03012001

Lyon

Limoges

Tableau 5 Relation Voyage


Modele

Vitesse

TGV

450

TER

200

Tableau 6 Relation Modele

S. Crozat - UTC 2009

51

Le niveau logique : la modlisation relationnelle


Numero

Nom

Prnom

Dupont

Jolle

Durand

JeanPierre

Tableau 7 Relation Conducteur

c) Relation clate avec liens


Dans cette reprsentation clate des donnes prcdemment regroupes dans la mme relation, on a
perdu des informations importantes, relatives aux liens entre les voyages, les modles de train et les
conducteurs. En effet on ne sait plus que le voyage numro 1010 s'effectue sur un TGV avec la
conductrice Jolle Dupont. Il est indispensable, pour conserver l'ensemble des informations, de
matrialiser nouveau ces liens, en ajoutant des rfrences dans la relation Voyage, aux tuples de Modele
et Conducteur.
Numero

Date

Gare1

Gare2

Modele

Conducteur

1010

01012001

Paris

Lyon

TGV

1011

02012001

Paris

Limoges

TER

1012

03012001

Paris

Madrid

TGV

1013

03012001

Lyon

Limoges

TER

Tableau 8 Relation Voyage

12. Cl trangre
Dfinition : Cl trangre
Groupe d'attributs d'une relation R1 devant apparatre comme cl dans une autre relation R2 afin de
matrialiser un lien entre les tuples de R1 et les tuples de R2. La cl trangre d'un tuple rfrence la cl
primaire d'un autre tuple.

Dfinition : Contrainte d'intgrit rfrentielle


Une cl trangre respecte la contrainte d'intgrit rfrentielle si sa valeur est effectivement existante
dans la cl primaire d'un tuple de la relation rfrence, ou si sa valeur est "null".
Une cl trangre qui ne respecte pas la contrainte d'intgrit rfrentielle exprime un lien vers un tuple
qui n'existe pas et donc n'est pas cohrente.

Remarque : Suppression et mise jour en cascade


Pour que la cohrence soit conserve, lors de la suppression d'un tuple rfrenc par d'autres tuples, les
tuples rfrenants doivent galement tre supprims. Sinon leur cl trangre pointerait vers des tuples
qui n'existent plus et la contrainte d'intgrit rfrentielle ne serait plus respecte. Afin de maintenir la
cohrence, il faut donc procder une suppression en cascade (sachant que les tuples rfrenant peuvent
galement tre rfrencs par ailleurs).
La problmatique est la mme lors d'une mise jour de la cl primaire d'un tuple : il faut alors mettre
jour toutes les cls trangres rfrenant ce tuple.
Notons que certains SGBD peuvent se charger automatiquement de ces suppressions et mises jour en
cascade.

13. Schma relationnel


Dfinition : Schma d'une relation
Le schma d'une relation dfinit cette relation par intention. Il est compos du nom de la relation, de la

52

S. Crozat - UTC 2009

Le niveau logique : la modlisation relationnelle

liste de ses attributs avec les domaines respectifs dans lesquels ils prennent leurs valeurs, de la cl
primaire, et des cls trangres.

Dfinition : Schma relationnel d'une base de donne


Le schma relationnelle d'une BD est la dfinition en intention de cette BD (par opposition l'instance
de la BD qui est une extension de la BD). Il est compos de l'ensemble des schmas de chaque relation de
la BD.

Syntaxe : Relation
Relation (Attribut1:Domaine1, Attribut2:Domaine2, ... ,
AttributN:DomaineN)
La relation "Relation" contient N attributs chacun dfini sur son domaine.

Syntaxe : Cl primaire
Relation (#Attribut1:Domaine1, ... ,
#AttributM:DomaineM, ... , AttributN:DomaineN)
La cl de la relation "Relation" est compose des attributs "Attribut1" "AttributM" (attribut prcds de
# ou bien souligns)
En gnral on note la cl primaire en premier dans la relation.

Syntaxe : Cl trangre
Relation1 (..., AttributM=>Relation2, ... ,
AttributN=>Relation2)
La relation "Relation1" comporte une cl trangre (compose des attributs "AttributM" "AttributN")
rfrenant la cl primaire de "Relation2". Bien sr il peut exister plusieurs cls trangres vers plusieurs
relations distinctes. Une cl trangre et sa cl primaire rfrence sont toujours composes du mme
nombre d'attributs. Il n'est pas ncessaire de prciser les domaines des attributs appartenant la cl
trangre car ce sont forcment les mmes que ceux de la cl primaire rfrence. Il n'est pas non plus en
gnral ncessaire de prciser dans le schma relationnel quels attributs de la cl trangre rfrencent
quels attributs de la cl primaire (cela est gnralement vident) mais il est possible de la faire on notant
"Attribut=>Relation.Attribut".
En gnral on note les cls trangres en dernier dans la relation, sauf pour les cls trangres qui font
partie de la cl primaire (cls identifiantes).

Attention : Cls candidates


On ne reprsente pas, en gnral, sur le schma relationnel les cls candidates afin de ne pas alourdir la
notation. On recommande nanmoins de dresser la liste des cls candidates (non choisies comme cls
primaires) en annotation du schma relationnel afin d'en conserver la mmoire.
On peut nanmoins noter les cls candidates en les soulignant en pointill.

14. Exemple de schma relationnel simple pour la gographie


Exemple
Personne (#Numero:Entier, Nom:Chane, Prnom:Chane,
LieuNaissance=>Ville)
Pays (#Nom:Chane, Population:Entier, Superficie:Rel,
Dirigeant=>Personne)
Rgion (#Pays=>Pays, #Nom:Chane, Superficie,
Dirigeant=>Personne)
Ville (#CodePostal:CP, Nom:Chane, Pays=>Rgion.Pays,

S. Crozat - UTC 2009

53

Le niveau logique : la modlisation relationnelle

Rgion=>Rgion.Nom, Dirigeant=>Personne)
Le schma relationnel prcdent dcrit :

Des personnes
Elles sont identifies par un numro qui est en fait une cl artificielle. En effet, mme une cl
compose de tous les attributs (Nom, Prnom, LieuNaissance) laisse une possibilit de doublons
(homonymes ns dans la mme ville).
La cl trangre LieuNaissance fait rfrence la relation Ville, et plus prcisment sa cl
primaire CodePostal, ce qui est est laiss implicite car vident.

Des pays
Ils sont identifis par leur nom, puisque deux pays ne peuvent avoir le mme nom.
Les pays sont dirigs par des personnes, et ce lien est matrialis par la cl trangre Dirigeant.

Des rgions
Elles font partie d'un pays et ont un nom. Deux rgions de pays diffrents pouvant avoir le mme
nom, il faut utiliser une cl primaire compose la fois du nom de la rgion et du nom du pays,
qui est une cl trangre (le nom est appel cl locale car il n'est pas suffisant pour identifier un
tuple de la relation Rgion, et la cl trangre vers la relation Pays est appele cl identifiante).

Des villes
Elles sont identifi par un code postal qui est unique dans le monde (en utilisant le prfixe de
pays de type "F-60200"). Ce code postal pour domaine CP qui est une chane compose d'une
ou deux lettres, d'un tiret, puis d'une srie de chiffres.
Le lien d'appartenance entre une ville et une rgion est matrialis par la cl trangre compose
des deux attributs Pays et Rgion. Cette cl rfrence la cl primaire de la relation Rgion,
galement compose de deux attributs. Pour clairement expliciter les rfrences (bien que
smantiquement la dnomination des attributs ne laisse pas de place au doute) on utilise la
syntaxe Rgion.Pays et Rgion.Nom.

B. Le passage UML vers Relationnel


Objectifs
Savoir-faire le passage d'un schma conceptuel UML un schma
relationnel.
Connatre les choix possibles pour les cas dlicats (hritage, relation 1:1, etc.)
et savoir-faire les bons choix.

Afin de pouvoir implmenter une base de donnes, il faut pouvoir traduire le modle conceptuel en
modle logique. Cela signifie qu'il faut pouvoir convertir un modle UML en modle relationnel. Les
modles conceptuels sont suffisamment formels pour ce passage soit systmatis.

1. Transformation des classes


Mthode : Classe
Pour chaque classe C non abstraite, on cre une relation R dont le schma est celui de la classe. La cl
primaire de R est une des cls de C.

54

S. Crozat - UTC 2009

Le niveau logique : la modlisation relationnelle

Remarque
Les classes abstraites sont ignores ce stade, et n'tant pas instanciables, ne donnent gnralement pas
lieu la cration de relation.

2. Transformation des associations


Mthode : Association 1:N
Pour chaque association binaire A de type 1:N (le cas chant 0,1:N) entre les classes S et T (reprsents
par les relations RS et RT respectivement) on inclut dans la dfinition de RT comme cl trangre la cl
de RS.

Mthode : Association M:N et associations de degr suprieur 2


Pour chaque association binaire A de type M:N ou pour chaque association A de degr suprieur 2, on
cre une nouvelle relation RA pour reprsenter A. On met dans RA comme cl trangre, les cls de
toutes les relations correspondant aux classes participant A et dont la concatnation formera sa cl.

Mthode : Association 1:1


Pour chaque association binaire A de type 1,1:1,1 ou 1,1:1,0 entre les classes S et T (reprsents par les
relations RS et RT respectivement) on substitut dans la dfinition de RS l'ventuelle cl primaire (si RS
tait identifie) par la cl primaire de RT qui est galement dfinie comme cl trangre vers RT. Notons
que dans le cas d'une association 1,1:1,1 RT peut-tre choisi la place de RS pour accueillir la cl
trangre.
Pour chaque association binaire A de type 0,1:0,1 entre les classes S et T (reprsents par les relations RS
et RT respectivement) on inclut dans la dfinition de RS comme cl trangre la cl de RT. La cl
trangre vers RT incluse dans RS est galement dfinie comme tant unique, afin d'assurer la cardinalit
maximum de 1. Notons qu'il n'tait pas possible dans ce cas 0,1:0,1 que la cl trangre vers RT incluse
dans RS soit galement la cl primaire, car la cardinalit de 0 supposerait que la cl primaire puisse tre
"null", ce qui est illgal pour une cl.

Mthode : Cardinalit minimale 0 ou 1


Selon que la cardinalit minimale est 0 ou 1 (ou plus) du ct de la relation rfrenante on ajoutera ou
non une contrainte de non nullit sur la cl trangre.
Selon que la cardinalit minimale est 0 ou 1 (ou plus) du ct de la relation rfrence on ajoutera ou non
une contrainte d'existence de tuples rfrenant pour chaque tuple de la relation rfrence.

3. Remarques concernant la transformation des associations 1:1


Remarque : Choix de la relation rfrenante pour la traduction de l'association 1:1
La traduction d'une association 1:1 ou 0..1:0..1 conduit devoir faire un choix entre les deux classes
composant l'association, afin de dterminer laquelle est rfrence de laquelle est rfrenante. Ce choix
peut-tre arbitraire, mais peut galement tre clair par la smantique des relations, et l'on choisira alors
celle qui est de plus faible importance du point de vue de la modlisation pour rfrencer (et donc intgrer
la cl trangre).

Exemple : Exemple de choix de la relation rfrenante pour une relation 1:1


Soit deux classes, "homme" et "femme" et une association "mariage" de cardinalit 1:1 (hommes et
femmes sont donc obligatoirement maris) unissant ces deux classes. Les classes "homme" et "femme"
sont identifies par un attribut "nom". S'il serait plus galant de choisir "femme" comme classe principale,
il sera dans la pratique plus opportun de choisir "homme", car le "nom" de la classe "homme" sera
effectivement une proprit pertinente pour la classe "femme" et donc aura plus de sens en tant que cl
primaire et en tant que cl trangre (dans le cas inverse, la cl de l'homme serait le nom de sa femme, ce
qui ne correspond pas la ralit administrative du mariage). On choisira donc plutt la reprsentation :

S. Crozat - UTC 2009

55

Le niveau logique : la modlisation relationnelle

homme (#nom)
femme (#nomMariage=>homme, nomJeuneFille) avec
nomJeuneFille cl
Si l'association avait t de cardinalit 0..1:0..1 (certains hommes et femmes ne sont pas maris), le mme
choix se serait impos et l'on aurait abouti au rsultat suivant:
homme (#nom)
femme (#nomJeuneFille, nomMariage=>homme) avec nomMariage
unique

Remarque : Fusion des relations dans le cas de la traduction de l'association 1:1


Il est possible, dans le cas d'une association 1:1 de dcider de fusionner les deux relations en une seule.
La relation rsultante est alors compose de l'ensemble des attributs de chacune des deux relations, en
choisissant l'une des deux cls de l'une des deux relations pour identifier la nouvelle relation.
Ce choix sera conduit par une apprciation du rapport entre :

La complexit introduite par le fait d'avoir deux relations l ou une suffit,

La pertinence de la sparation des deux relations d'un point de vue smantique,

Les pertes de performance dues l'clatement des relations,

Les pertes de performance dues au fait d'avoir une grande relation,

Les questions de scurit et de suret factorises ou non au niveau des deux relations,

etc.
Dans le doute il est prfrable d'adopter l'approche systmatique consistant sparer les deux relations.

4. Transformation des attributs et mthodes


Mthode : Attributs simples
Pour chaque attribut lmentaire et monovalu A d'une classe E (idem pour les associations), on cre un
attribut correspondant A sur la relation RE correspondant E.

Mthode : Attributs composites


Pour chaque attribut composite C, comprenant N sous-attributs, d'une classe E (idem pour les
associations), on cre N attributs correspondants C sur la relation RE correspondant E.

Mthode : Attributs multivalus


Pour chaque attribut multivalu M d'une classe E (idem pour les associations), on cre une nouvelle
relation RM qui comprend un attribut monovalu correspondant M plus la cl de RE (relation
reprsentant E). La cl de RM est la concatnation des deux attributs.

Mthode : Attributs drivs et mthodes


On ne reprsente pas en gnral les attributs drivs ni les mthodes dans le modle relationnel, ils seront
calculs dynamiquement soit par des procdures internes la BD (procdures stockes), soit par des
procdures au niveau applicatif.
On peut nanmoins dcider (pour des raisons de performance essentiellement) de reprsenter l'attribut
driv ou la mthode comme s'il s'agissait d'un attribut simple, mais il sera ncessaire dans ce cas
d'ajouter des mcanismes de validation de contraintes dynamiques (avec des triggers par exemple) pour
assurer que la valeur stocke volue en mme temps que les attributs sur lesquels le calcul driv porte.
Notons qu'introduire un attribut driv ou un rsultat de mthode dans le modle relationnel quivaut
introduire de la redondance, ce qui est en grnal dconseill, et ce qui doit tre dans tous les cas contrl.

5. Transformation des classes d'association

56

S. Crozat - UTC 2009

Le niveau logique : la modlisation relationnelle

Mthode : Classe d'association 1:N


Les attributs de la classe d'association sont ajouts la relation issue de la classe ct N.

Mthode : Classe d'association N:M


Les attributs de la classe d'association sont ajouts la relation issue de l'association N:M.
Si la classe d'association possde une cl, celle-ci est concatne aux cls trangres composant dj la
cl primaire de la relation d'association.

Mthode : Classe d'association 1:1


Les attributs de la classe d'association sont ajouts la relation qui a t choisie pour recevoir la cl
trangre. Bien entendu si les deux classes ont t fusionnes en une seule relation, les attributs sont
ajoute celle-ci.

6. Transformation des compositions


Remarque
Une composition est transforme comme une association 1:N, mais on ajoute la cl de la classe partie
(dite cl locale) la cl trangre vers la classe composite.

Mthode : Compositions
Soit la composition entre la classe composite C et la classe partie P (reprsents par les relations RC et
RP respectivement) on inclut dans la dfinition de RP comme cl trangre la cl de RC. La cl de RP est
redfinie comme la concatnation de la cl de P (cl locale) avec la cl trangre vers RC.

Remarque : Composition et entits faibles en E-A


Une composition est transforme selon les mmes principes qu'une entit faible en E-A.

7. Transformation de la relation d'hritage


Le modle relationnel ne permet pas de reprsenter directement une relation d'hritage, puisque que seuls
les concepts de relation et de rfrence existent dans le modle. Il faut donc appauvrir le modle
conceptuel pour qu'il puisse tre reprsent selon un schma relationnel.
Trois solutions existent pour transformer une relation d'hritage :

Reprsenter l'hritage par une rfrence entre la classe mre et la classe fille.

Reprsenter uniquement les classes filles par des relations.

Reprsenter uniquement la classe mre par une relation.

Mthode : Choisir le bon mode de transformation d'une relation d'hritage


La difficult consiste donc pour chaque relation d'hritage choisir le bon mode de transformation,
sachant que chaque solution possde ses avantages et ses inconvnients.

S. Crozat - UTC 2009

57

Le niveau logique : la modlisation relationnelle

Modedetrans
formation

Limite

Casd'usage

Exemple

Vue

Parrfrence

EtudiantetEm
ployehritentde
Personne(un
Adapttousles tudiantpeut tre
Lourdeurli ela casd'hritageni employ etles
ncessitdere exclusif,nicom propritsdes
prsenterles
pletpar
tudiantsetdes
donnesdes
ticulirementad employ ssont
classesfillessur aptlorsquela
diffrentes,de
deuxrelations
classemren'est plusdesper
pasabstraite.
sonnespeuvent
existerquine
sontniemploy s
nitudiants).

Unevuedoit tre
crepour
chaqueclasse
fille(ralisantla
jointureavecla
classemre).

Parlesclasses
filles

Hommeet
Femmehritent
dePersonne(un
tupledeHomme
Adaptl'hrit
Redondanceli e
nepeutpas tre
ageexclusifpar
l'existancesim
untuplede
ticulirementad
ultanedetuples
FemmeetPer
aptlorsquela
dansplusieurs
sonneestab
classemreest
classesfilles
straite,iln'existe
abstraite.
pasdePersonne
quinesoitniun
Homme,niune
Femme).

Unevuedoit tre
cre,unique
mentdanslecas
olaclassem re
n'estpasab
straite,pourunir
lestuplesdes
classesfilles
avecceuxsp ci
fiques laclasse
mre.

Parlaclasse
mre

ResponsableetS
alarihritent
deEmploy (un
Nullitsys
responsableest
tmatiquepour
salarietaucun
lesattributsd'une
Adaptl'hrit
attributn'estsp
classe
agecompletpar cifiqueni Re
fillen'existantpas
ticulirementad sponsable,ni
pouruneautre
aptlorsquela
Salari,deplusil
classefille(et
classemren'est existedesstagi
pourlaclasse
pasabstraite.
airesparexemple
mresicelleci
quisontjuste
n'estpasab
employ s,mais
straite)
nonsalari set
nonrespons
ables)

Unevuedoit tre
systmatique
mentcrepour
chaqueclasse
fille(ralisantla
restrictionetla
projectiondepuis
larelationunique
cre).

Tableau 9 Choix de la bonne transformation

58

S. Crozat - UTC 2009

Le niveau logique : la modlisation relationnelle

Modede
transform
ation

Classe
mreab
straite

Classe
mrenon
abstraite

Hritage
exclusif

Hritage
nonex
clusif

Hritage
complet

Hritage
presque
complet

Hritage
noncom
plet

Par
rfrence

Parles
classes
filles

++

Parla
classe
mre

++

Tableau 10 Choix de la bonne transformation

8. Transformation de la relation d'hritage par rfrence


Mthode : Hritage reprsent par une rfrence
Chaque classe, mre ou fille, est reprsente par une relation. La cl primaire d'une classe mre est
utilise pour identifier chacune de ses classes filles (cette cl tant pour chaque classe fille la fois la cl
primaire et une cl trangre vers la classe gnrale).
Si une classe fille avait une autre cl primaire candidate dans le modle conceptuel, cette cl n'est pas
retenue pour tre la cl primaire, tant donn que c'est la cl trangre rfrence la classe mre qui est
retenue.
La cardinalit d'un lien entre une classe fille et une classe mre est (1,1):(0,1). En effet toute classe fille
rfrence obligatoirement une et une seule classe mre (pas d'hritage multiple) et toute classe mre est
rfrence une ou zro fois (zro fois si un objet peut tre directement du type de la classe mre) par
chaque classe fille .
Une vue devra tre cre pour chaque classe fille en ralisant une jointure sur la classe mre.

Exemple : Hritage reprsent par une rfrence


Soit la classe A avec la cl K et les attributs A1 et A2. Soit la classe B, classe fille de A, comprenant la
cl K' et les attributs B1 et B2. Le modle relationnel correspondant selon cette transformation est :
A (#K, A1, A2)
B (#K=>A, K', B1, B2)

Remarque : Classe mre non abstraite


Cette solution est particulirement adapte lorsque la classe mre n'est pas abstraite, car cela en autorise
l'instanciation sans aucun bruit dans la relation li aux classes filles. Par contre si la classe mre est
abstraite il faut introduire une contrainte dynamique complexe pour imposer la prsence d'un tuple
rfrenant dans une des classes filles.
Ainsi dans l'exemple prcdent, un A peut tre instanci en toute indpendance par rapport la relation B.

Conseil : Solution gnrale


Cette solution est la plus gnrale, elle fonctionne correctement dans tous les cas. Le seul problme est la
complexit de la structure de donne qu'elle induit.

9. Transformation de la relation d'hritage par les classes filles


Mthode : Hritage absorb par les classes filles
Chaque classe fille est reprsent par une relation. Tous les attributs de la classe mre sont rpts au
niveau de chaque classe fille .
S. Crozat - UTC 2009

59

Le niveau logique : la modlisation relationnelle

Si une classe fille a une cl primaire propre, cette cl n'est pas retenue, et c'est bien la cl hrite de la
classe mre qui devient la cl primaire (mais la cl est bien entendu maintenue comme cl candidate)
Si la classe mre n'est pas abstraite, elle est galement reprsente par une relation qui ne contiendra que
les tuples qui ne sont pas aussi des instances de classes filles. La classe mre est alors reprsente par une
vue qui unit ses propres tuples avec les tuples de toutes ses classes filles et en les projetant sur les attributs
hrits uniquement.

Exemple : Hritage absorb par les classes filles


Soit la classe abstraite A avec la cl K et les attributs A1 et A2. Soit la classe B, classe fille de A avec les
attributs B1 et B2. Soit la classe C, classe fille de A avec les attributs C1 et C2 Le modle relationnel
correspondant selon cette transformation est :
B (#K, A1, A2, B1, B2)
C (#K, A1, A2, C1, C2)
Si A n'avait pas t abstraite elle aurait donn naissance une relation A possdant les attributs A1 et A2
et qui n'aurait alors contenu que les tuples qui ne sont ni des B ni des C.

Remarque : Classe mre abstraite


Cette solution est particulirement adapte lorsque la classe mre est abstraite, car elle permet de ne pas
matrialiser cette classe mre par une relation.
En revanche dans le cas o la classe mre n'est pas abstraite, la solution est moins adapte, car il faut alors
passer par une vue pour retrouver tous les tuples de la classe.

Conseil : Hritage exclusif


Cette solution est optimum dans le cas d'un hritage exclusif, c'est dire si aucun objet d'une classe fille
n'appartient aussi une autre classe fille. Dans le cas contraire, le problme est que des redondances vont
tre introduites puisqu'un mme tuple devra tre rpt pour chaque classe fille laquelle il appartient.

10. Transformation de la relation d'hritage par la classe mre


Mthode : Hritage absorb par la classe mre
La classe mre est reprsente par une relation, mais ses classes filles ne sont pas reprsentes par des
relations. Tous les attributs de chaque classe fille sont rintgrs au niveau de la classe mre.
Un attribut supplmentaire, dit de discrimination, est ajout la classe mre, afin de distinguer les tuples
des diffrentes classes filles. Cet attribut est de type numration et a pour valeurs possibles les noms des
diffrents classes filles. Afin de grer l'hritage non exclusif (un objet peut tre de plusieurs classe fille
la fois), le domaine de l'attribut de discrimination, peut tre tendu des combinaisons de noms des
diffrents classes filles. Si la classe mre n'est pas abstraite, une valeur supplmentaire peut-tre ajoute
au domaine, ou bien l'on peut autoriser la valeur null qui dsignera alors un objet de la classe mre.
Si une classe fille a une cl primaire propre, cette cl sera rintgre la classe mre, au mme titre qu'un
autre attribut, mais bien entendu n'officiera pas en tant que cl primaire (et en gnral pas non plus en tant
que cl candidate car elle pourra contenir des valeurs nulles).
Chaque classe fille est reprsente par une vue qui slectionne les tuples de la classe mre qui
appartiennent la classe fille et les projete sur les attributs de la classe fille.

Exemple : Hritage absorb par la classe mre


Soit la classe A avec la cl K et les attributs A1 et A2. Soit la classe B, classe fille de A avec les attributs
B1 et B2. Soit la classe C, classe fille de A avec les attributs C1 et C2 Le modle relationnel
correspondant selon cette transformation est :
A (#K, A1, A2, B1, B2, C1, C2, D:{'B','C','BC'})
Si l'on pose que A n'est pas abstraite, alors un tuple sera un A s'il a la valeur null pour sa proprit D. Si
l'on pose que A est abstraite, on ajoutera la contrainte NOT NULL la proprit D.

60

S. Crozat - UTC 2009

Le niveau logique : la modlisation relationnelle

Remarque : Classe mre non abstraite


Cette solution est particulirement adapte lorsque la classe mre n'est pas abstraite, car cela en autorise
l'instanciation naturellement, en ne renseignant pas l'attribut de discrimination. Lorsque la classe mre est
abstraite il est moins naturel de disposer d'une table associe cette classe (et l'on pensera ajouter la
contrainte NOT NULL sur l'attribut de discrimination).

Conseil : Hritage complet


Cette solution est optimum dans le cas d'un hritage complet, c'est dire si les classes filles ne dfinissent
pas d'attributs autre que ceux hrits. Dans le cas contraire cela engendre des valeurs null.
En pratique l'hritage complet est rare, mais nombre d'hritages le sont presque et pourront alors tre
raisonnablement grs sellon cette approche, a fortiori si la classe mre n'est pas abstraite.

Conseil : Autre reprsentation de la discrimination


Si l'hritage concerne un nombre lev de classes filles et qu'il est principalement non exclusif alors le
domaine de l'attribut de discrimination peut impliquer une combinatoire importante de valeurs. Pour
contourner cette lourdeur il est possible d'utiliser, en remplacement, un attribut de domaine boolen pour
chaque classe fille spcifiant si un tuple est un objet de cette classe.
Dans cette configuration la classe mre sera logiquement considre comme non abstraite et un objet
appartiendra la classe mre si tous ses attributs de discrimination valent "faux". Seule une contrainte
dynamique permettra de dfinir la classe mre comme abstraite, en prcisant que les attributs de
discrimination ne peuvent tre tous "faux".

11. Exemple de transformation d'une relation d'hritage


Exemple
Soit le modle UML suivant :

Reprsentation de documents
Il existe trois faons de traduire la relation d'hritage : par rfrence, par absorption par les classes filles,
par absorption par la classe mre.

Remarque : Type d'hritage


Si une thse peut galement tre un livre (c'est le cas si une thse peut-tre publie comme un livre par
exemple), alors l'hritage n'est pas exclusif puisque un mme document peut tre une thse et un livre.
L'hritage n'est pas non plus complet, puisque l'on observe que les thses et les livres ont des attributs qui
ne sont pas communs (la discipline pour la thse et l'diteur pour le livre).
En toute rigueur, il faudrait donc appliquer le cas gnral (ni exclusif, ni complet) et appliquer une
traduction de l'hritage par rfrence. Observons nanmoins les avantages et inconvnients que chacun
des trois choix porterait.

S. Crozat - UTC 2009

61

Le niveau logique : la modlisation relationnelle

a) Hritage reprsent par une rfrence


Document(#Titre:Chane, Auteur:Chane)
These(#Titre=>Document, Discipline:Chane)
Livre(#Titre=>Document), Editeur:Chane

Remarque : Avantages du choix


Il n'y a ni redondance ni valeur nulle inutile dans les relations These et Livre, c'est la traduction la plus
juste pour le problme pos.

Remarque : Inconvnient du choix


Il est relativement lourd de devoir crer un tuple dans Document pour chaque tuple dans These ou Livre,
alors que la relation Document ce porte que l'information concernant l'auteur, juste pour assurer les cas,
par ailleurs plutt rare dans la ralit, o les thses sont publies sous forme de livres.
De plus la classe Document tant abstraite, il ne devra jamais y avoir de tuple dans document qui n'a pas
de tuple correspondant dans Livre ou These. Ceci n'est pas contrlable directement en relationnel et devra
donc tre vrifi au niveau applicatif (ou bien la classe ne devra plus tre considre comme abstraite).

b) Hritage absorb par les classes filles


These(#Titre, Discipline:Chane, Auteur:Chane)
Livre(#Titre, Editeur:Chane, Auteur:Chane)

Remarque : Avantages du choix


Il est plus simple que le prcdent, puisque la reprsentation d'une thse ou d'un livre ne ncessite plus
que d'ajouter un seul tuple. Il vite donc les cls trangres, toujours plus dlicates grer d'un point de
vue applicatif.

Remarque : Inconvnient du choix


Lorsqu'une thse est publie sous la forme d'un livre, alors une information sera duplique (l'auteur), ce
qui introduit de la redondance. Si une telle redondance peut-tre tolre pour des raisons de simplification
ou de performance (si on considre que le cas est rare par exemple et donc que l'hritage est "presque"
exclusif), il sera nanmoins ncessaire d'assurer son contrle par un moyen supplmentaire.
Dans le cas gnral, il n'est pas souhaitable de tolrer une telle redondance.

c) Hritage absorb par la classe mre


Document(#Titre, Discipline:Chane, Editeur:Chane,
Auteur:Chane, Type:{These|Livre|These+Livre})

Remarque : Avantages du choix


Il est plus simple que le premier, puisque la reprsentation d'une thse ou d'un livre ne ncessite plus que
d'ajouter un seul tuple. Il vite donc les cls trangres, toujours plus dlicates grer d'un point de vue
applicatif.

Remarque : Inconvnient du choix


Puisqu'il est rare que les thses soient publies sous forme de livre alors les tuples de la relation
Document contiendront la plupart du temps une valeur nulle soit pour l'diteur soit pour la discipline.
Cette introduction de valeurs nulles est moins problmatique que l'introduction de redondance observe
dans le cas prcdent, aussi elle peut-tre plus facilement tolre. On considre alors que l'hritage est
"presque" complet, puisque seuls deux attributs sont distingus. Cela dit ils s'agit de deux attributs sur
quatre, soit une proportion importante d'une part, et il est regrettable que l'hritage soit galement

62

S. Crozat - UTC 2009

Le niveau logique : la modlisation relationnelle

"presque" exclusif puisque l'introduction d'une valeur nulle sera quasi-systmatique.

d) En conclusion
Conseil
L'hritage est toujours dlicat traduire en relationnel, ce qui est dommage car son pouvoir de
reprsentation conceptuel est fort.
Un conseil pour assumer une gestion correcte de la traduction de la relation d'hritage serait d'appliquer
la lettre les rgles de transformation (ce qui conduira le plus souvent un hritage par rfrence) et,
l'exprience aidant, de tolrer dans des cas bien matriss des digressions cette rgle.

Attention : Penser aux vues !


Il est important de bien penser ajouter les vues permettant de retrouver le schma initialement
recherch.

12. Hritage et cl primaire


Attention
Dans tous les cas, notamment en cas d'hritage plusieurs niveaux, c'est la cl primaire de la classe la
plus gnrale qui est retenue pour identifier les classes filles hritant directement ou indirectement de
cette classe.

Exemple
Ainsi si C hrite de B qui hrite de A, c'est la cl de A qui permettra d'identifier les classes A, B et C, et
ce quelque soit le mode de transformation retenu.

13. Liste des contraintes


Mthode : Contraintes exprimes sur le diagramme
Les contraintes exprimes sur le diagrammes sont reportes dans un tableau qui accompagnera le modle
logique.

Mthode : Extension des contraintes exprimes


On s'attachera lors de la modlisation logique exprimer l'ensemble des contraintes dynamiques pesant
sur le modle, mme celles qui ont t considres comme secondaires ou videntes lors de la
modlisation conceptuelle.

14. Correspondance entre UML et relationnel

S. Crozat - UTC 2009

63

Le niveau logique : la modlisation relationnelle

ModleUML

Modlerelationnel

Classeinstanciable

Relation

Classeabstraite

Rien

Objet

Nuplet

Attributsimple

Attributatomique

Attributcomposite

Ensembled'attributs

Attributmultivalu

Relation

Attributdriv

Procdurestock eoucontraintedynamique

Mthode

Procdurestock e

Association1:N

Attributs

AssociationN:M

Relation

Associationdedegr 3ousuprieur

Relation

Composition

Attributs

Classed'association

Attributs

Occurenced'uneassociation

Nuplet

Hritage

Vues

Tableau 11 Passsage UML vers Relationnel

C. Le passage E-A vers Relationnel

Le passage E-A vers relationnel est trs similaire au passage UML vers relationnel. Les rgles dcrites ciaprs sont donc complter avec celles prescrites dans la partie prcdente.

1. Transformation des entits


Mthode : Entit identifie
Pour chaque entit (identifie) E, on cre une relation R dont le schma est celui de l'entit. La cl
primaire de R est une des cls de E.

Mthode : Entit non identifie


Pour chaque entit non identifie I ayant un identifiant tranger E, on cre une relation R qui comprend
tous les attributs de I, ainsi que les attributs cls de la relation correspondant E. La cl de R est la
concatnation de la cl locale de I et de la cl de E.

2. Transformation des associations


Mthode : Association 1:N
Pour chaque association binaire A de type 1:N (le cas chant 0,1:N) entre les entits S et T (reprsents
par les relations RS et RT respectivement) on inclut dans la dfinition de RT comme cl trangre la cl
de RS ainsi que tous les attributs simples de A.

Mthode : Association M:N et associations de degr suprieur 2


Pour chaque association binaire A de type M:N ou pour chaque association A de degr suprieur 2, on

64

S. Crozat - UTC 2009

Le niveau logique : la modlisation relationnelle

cre une nouvelle relation RA pour reprsenter A. On met dans RA comme cl trangre, les cls de
toutes les relations correspondant aux entits participant A et dont la concatnation formera sa cl. On
ajoute galement RA (et ventuellement dans sa cl pour les attributs cls) les attributs dfinis sur A.

Mthode : Association 1:1


Pour chaque association binaire A de type 1,1:1,1 ou 1,1:1,0 entre les entits S et T (reprsentes par les
relations RS et RT respectivement) on substitut dans la dfinition de RS l'ventuelle cl primaire (si RS
tait identifie) par la cl primaire de RT qui est galement dfinie comme cl trangre vers RT. On
ajoute galement RS l'ensemble des attributs de A. Notons que dans le cas d'une association 1,1:1,1 RT
peut-tre choisie la place de RS pour accueillir la cl trangre.
Pour chaque association binaire A de type 0,1:0,1 entre les entits S et T (reprsentes par les relations
RS et RT respectivement) on inclut dans la dfinition de RS comme cl trangre la cl de RT ainsi que
tous les attributs simples de A. La cl trangre vers RT incluse dans RS est galement dfinie comme
tant unique, afin d'assurer la cardinalit maximum de 1. Notons qu'il n'tait pas possible dans ce cas
0,1:0,1 que la cl trangre vers RT incluse dans RS soit galement la cl primaire, car la cardinalit de 0
supposerait que la cl primaire puisse tre "null", ce qui est illgal pour une cl.

Remarque : Cardinalit minimale 0 ou 1


Selon que la cardinalit minimale est 0 ou 1 (ou plus) du ct de la relation rfrenante on ajoutera ou
non une contrainte de non nullit sur la cl trangre.
Selon que la cardinalit minimale est 0 ou 1 (ou plus) du ct de la relation rfrence on ajoutera ou non
une contrainte d'existence de tuples rfrenant pour chaque tuple de la relation rfrence.

3. Transformation de la relation d'hritage


Comme en UML, trois solutions existent pour transformer une relation d'hritage exprime en E-A :

par rfrence,

par absorption par les sous-types d'entit,

par absorption par l'entit gnrale.

Attention : Les entits non finales sont abstraites


En modlisation E-A on considrera toujours que les entits non finales (c'est dire qui sont hrites par
d'autres entits) sont abstraites. Une entit abstraite est une entit qui ne peut pas tre instancie.
Donc si E2 hrite de E1 (et que E2 est finale c'est dire qu'aucune classe n'hrite de E2), il existera des
objets de E2, mais pas des objets de E1. Si l'on veut disposer d'objets de E1, il suffit de crer une classe
E1' qui hrite de E1 sans apporter de proprit supplmentaire.
En modlisation UML on pourra diffrencier les classes abstraites des classes instanciables.

4. Exemple de passage E-A vers relationnel


Exemple

S. Crozat - UTC 2009

65

Le niveau logique : la modlisation relationnelle

Transformation avec une relation 1:N

Exemple

Transformation avec une relation M:N

5. Comparaison des modles E-A, UML et relationnel

66

S. Crozat - UTC 2009

Le niveau logique : la modlisation relationnelle


Mod leEA

Mod leUML

Entit
Occurenced'uneentit

Mod lerelationnel

Classe

Relation

Objet

Nuplet

Attributsimple

Attributsimple

Attributatomique

Attributcomposite

Attributcomposite

Ensembled'attributs

Attributmultivalu

Attributmultivalu

Relation

Attributd riv

Attributd riv

Proc durestock eoucon


traintedynamique

Mthode

Proc durestock e

Entit faible

Relation

Association1:N

Association1:N

Attributs

AssociationN:M
Associationdedegr
sup rieur

AssociationN:M
3ou

Associationdedegr
sup rieur

Relation
3ou

Relation

Occurenced'uneassociation

Occurenced'uneassociation

Nuplet

Hritage

Hritage

Vue

Tableau 12 Passage E-A et UML vers Relationnel

D. Algbre relationnelle
Objectifs
Connatre les oprateurs relationnels.
Matriser l'algbre relationnelle.

1. Concepts manipulatoires
La reprsentation d'information sous forme relationnelle est intressante car les fondements
mathmatiques du relationnel, outre qu'ils permettent une modlisation logique simple et puissante,
fournissent galement un ensemble de concepts pour manipuler formellement l'information ainsi
modlise.
Ainsi une algbre relationnelle, sous forme d'un ensemble d'oprations formelles, permet d'exprimer des
questions, ou requtes, poses une reprsentation relationnelle, sous forme d'expressions algbriques.
L'algbre relationnelle est compose par les cinq oprateurs de base et les trois oprateurs additionnels
suivants :

Oprateurs de base
Union
Diffrence
Projection
Restriction
Produit cartsien

Oprateurs additionels
Intersection
Jointure
Division
S. Crozat - UTC 2009

67

Le niveau logique : la modlisation relationnelle

Remarque : Algbre relationnelle et SQL


Les questions formules en algbre relationnelle sont la base du langage SQL, qui est un langage
informatique d'expressions permettant d'interroger une base de donnes relationnelle.

Remarque : Algbre relationnelle et objet


L'algbre relationnelle est tendue une algbre permettant de manipuler des objets autres, et a priori plus
complexes, que des relations. Cette algbre tendue permet l'interrogation d'informations modlises sous
forme relationnelle-objet.

2. Oprateurs ensemblistes
Attention
Les oprateurs ensemblistes sont des relations binaires (c'est dire entre deux relations) portant sur des
relations de mme schma.

Dfinition : Union
L'union de deux relations R1 et R2 de mme schma produit une relation R3 de mme schma constitue
de l'ensemble des tuples appartenant R1 et/ou R2.

Dfinition : Diffrence
La diffrence entre deux relations R1 et R2 de mme schma produit une relation R3 de mme schma
constitue de l'ensemble des tuples de R1 n'appartenant pas R2. Notons que la diffrence entre R1 et R2
n'est pas gale la diffrence entre R2 et R1.

Dfinition : Intersection
L'intersection de deux relations R1 et R2 de mme schma produit une relation R3 de mme schma
constitue de l'ensemble des tuples appartenant la fois R1 et R2. Notons que l'intersection n'est pas
une opration de base, car elle est quivalent deux oprations de diffrence successives.

Exemple
Soit les deux relations suivantes :
Homme (Nom, Prnom, Age)
Femme (Nom, Prnom, Age)
Soit les tuples suivants pour ces deux relations respectivement :
(Dupont, Pierre, 20)
(Durand, Jean, 30)
(Martin, Isabelle, 20)
(Tintin, Hlne, 30)
Soit l'opration suivante :
R = Union (Homme, Femme)
On obtient alors la relation R compose des tuples suivants :
(Dupont,
(Durand,
(Martin,
(Tintin,

Pierre, 20)
Jean, 30)
Isabelle, 20)
Hlne, 30)

La diffrence entre Homme et Femme (respectivement entre Femme et Homme) renvoie la relation
Homme (respectivement Femme), car aucun tuple n'est commun aux deux relations. L'intersection entre

68

S. Crozat - UTC 2009

Le niveau logique : la modlisation relationnelle

Homme est Femme est vide, pour la mme raison.

Remarque : Union externe


Il est possible de dfinir une opration d'union externe, qui permet de raliser l'union de deux relations de
schma diffrent, en ramenant les relations aux mmes schmas, et en les compltant avec des valeurs
nulles.

3. Projection
Dfinition : Projection
La projection est une opration unaire (c'est dire portant sur une seule relation). La projection de R1 sur
une partie de ses attributs {A1, A2, ...} produit une relation R2 dont le schma est restreint aux attributs
mentionns en oprande, comportant les mmes tuples que R1, et dont les doublons sont limins.

Remarque : Elimination des doublons


Aprs suppression d'une partie des attributs du schma, la relation peut comporter des doublons. Etant
donn que l'on ne pourrait plus identifier ces doublons les uns par rapport aux autres, la seule solution
sense est donc de considrer que deux doublons sont quivalents, et donc de n'en garder qu'un seul dans
la relation rsultante.

Exemple
Soit la relation suivante :
Personne (Nom, Prnom, Age)
Soit les tuples suivants :
(Dupont, Pierre, 20)
(Durand, Jean, 30)
Soit l'opration suivante :
R = Projection (Personne, Nom, Age)
On obtient alors la relation R compose des tuples suivants :
(Dupont, 20)
(Durand, 30)

4. Restriction
Dfinition : Restriction
La restriction est une opration unaire (c'est dire portant sur une seule relation). La restriction de R1,
tant donne une condition C, produit une relation R2 de mme schma que R1 et dont les tuples sont les
tuples de R1 vrifiant la condition C.

Exemple
Soit la relation suivante :
Personne (Nom, Prnom, Age)
Soit les tuples suivants :
(Dupont, Pierre, 20)
(Durand, Jean, 30)
Soit l'opration suivante :

S. Crozat - UTC 2009

69

Le niveau logique : la modlisation relationnelle

R = Restriction (Personne, Age>25)


On obtient alors la relation R compose de l'unique tuple restant suivant :
(Durand, Jean, 30)

5. Produit
Dfinition : Produit cartsien
Le produit cartsien est une opration binaire (c'est dire portant sur deux relations). Le produit de R1
par R2 (quivalent au produit de R2 par R1) produit une relation R3 ayant pour schma la juxtaposition
de ceux des relations R1 et R2 et pour tuples l'ensemble des combinaisons possibles entre les tuples de R1
et ceux de R2.
Synonymes : Produit

Remarque
Le nombre de tuples rsultant du produit de R1 par R2 est gal au nombre de tuples de R1 multipli par le
nombre de tuples de R2.

Exemple
Soit les deux relations suivantes :
Homme (Nom, Prnom, Age)
Femme (Nom, Prnom, Age)
Soit les tuples suivants pour ces deux relations respectivement :
(Dupont, Pierre, 20)
(Durand, Jean, 30)
(Martin, Isabelle, 15)
(Tintin, Hlne, 40)
Soit l'opration suivante :
R = Produit (Homme, Femme)
On obtient alors la relation R compose des tuples suivants :
(Dupont,
(Durand,
(Dupont,
(Durand,

Pierre, 20, Martin, Isabelle, 15)


Jean, 30, Martin, Isabelle, 15)
Pierre, 20, Tintin, Hlne, 40)
Jean, 30, Tintin, Hlne, 40)

6. Jointure
Dfinition : Jointure
La jointure est une opration binaire (c'est dire portant sur deux relations). La jointure de R1 et R2, tant
donn une condition C portant sur des attributs de R1 et de R2, de mme domaine, produit une relation
R3 ayant pour schma la juxtaposition de ceux des relations R1 et R2 et pour tuples l'ensemble de ceux
obtenus par concatnation des tuples de R1 et de R2, et qui vrifient la condition C.

Exemple
Soit les deux relations suivantes :
Homme (Nom, Prnom, Age)

70

S. Crozat - UTC 2009

Le niveau logique : la modlisation relationnelle

Enfant (Nom, Prnom, Age)


Soit les tuples suivants pour ces deux relations respectivement :
(Dupont, Pierre, 20)
(Durand, Jean, 30)
(Dupont, Georges, 1)
(Dupont, Jacques, 3)
Soit l'opration suivante :
R = Jointure (Homme, Enfant, Homme.Nom=Enfant.Nom)
On obtient alors la relation R compose des tuples suivants :
(Dupont, Pierre, 20, Dupont, Georges, 1)
(Dupont, Pierre, 20, Dupont, Jacques, 3)

Remarque : Opration additionnelle


La jointure n'est pas une opration de base, elle peut tre rcrite en combinant le produit et la restriction.

7. Jointure naturelle
Dfinition : Jointure naturelle
La jointure naturelle entre R1 et R2 est une jointure pour laquelle la condition est l'galit entre les
attributs de mme nom de R1 et de R2. Il est donc inutile de spcifier la condition dans une jointure
naturelle, elle reste toujours implicite.

Exemple
Soit deux relations R1 (A, B, C) et R2 (A, D), l'opration Jointure(R1,R2,R1.A=R2.A) est quivalente
l'opration JointureNaturelle(R1,R2).

Remarque
Pour appliquer une jointure naturelle, il faut que les deux relations oprandes aient au moins un attribut
ayant le mme nom en commun.

8. Jointure externe
Introduction
La jointure est une opration qui entrane la perte de certains tuples : ceux qui appartiennent une des
deux relations oprandes et qui n'ont pas de correspondance dans l'autre relation. Il est ncessaire dans
certains cas de palier cette lacune, et l'on introduit pour cela la notion de jointure externe.

Dfinition : Jointure externe


La jointure externe entre R1 et R2 est une jointure qui produit une relation R3 laquelle on ajoute les
tuples de R1 et de R2 exclus par la jointure, en compltant avec des valeurs nulles pour les attributs de
l'autre relation.

Dfinition : Jointure externe gauche


La jointure externe gauche entre R1 et R2 est une jointure externe pour laquelle on ajoute seulement les
tuples de R1 (c'est dire la relation de gauche) ayant t exclus.
Synonymes : Jointure gauche

S. Crozat - UTC 2009

71

Le niveau logique : la modlisation relationnelle

Dfinition : Jointure externe droite


La jointure externe droite entre R1 et R2 est une jointure externe pour laquelle on ajoute seulement les
tuples de R2 (c'est dire la relation de droite) ayant t exclus.
Bien entendu une jointure externe droite peut tre rcrite par une jointure externe gauche (et
rciproquement) en substituant les relations oprandes R1 et R2.
Synonymes : Jointure droite

Exemple
Soit les deux relations suivantes :
Homme (Nom, Prnom, Age)
Enfant (Nom, Prnom, Age)
Soit les tuples suivants pour ces deux relations respectivement :
(Dupont, Pierre, 20)
(Durand, Jean, 30)
(Dupont, Georges, 1)
(Martin, Isabelle, 15)
Soit l'opration suivante :
R = JointureExterne (Homme, Enfant, Homme.Nom=Enfant.Nom)
On obtient alors la relation R compose des tuples suivants :
(Dupont, Pierre, 20, Dupont, Georges, 1)
(Durand, Jean, 30, Null, Null, Null)
(Null, Null, Null, Martin, Isabelle, 15)
Une jointure externe gauche n'aurait renvoy que les deux premiers tuples et une jointure externe droite
n'aurait renvoye que le premier et le troisime tuple.

9. Division
Dfinition : Division
La division est une opration binaire (c'est dire portant sur deux relations). La division de R1 par R2,
sachant que R1 et R2 ont au moins un attribut commun (c'est dire de mme nom et de mme domaine),
produit une relation R3 qui comporte les attributs appartenant R1 mais n'appartenant pas R2 et
l'ensemble des tuples qui concatns ceux de R2 donnent toujours un tuple de R1.

Exemple
Soit les deux relations suivantes :
Homme (Nom, Prnom, Mtier)
Mtier (Metier)
Soit les tuples suivants pour ces deux relations respectivement :
(Dupont, Pierre, Ingnieur)
(Dupont, Pierre, Professeur)
(Durand, Jean, Ingnieur)
(Ingnieur)
(Professeur)
Soit l'opration suivante :
R = Division (Homme, Mtier)

72

S. Crozat - UTC 2009

Le niveau logique : la modlisation relationnelle

On obtient alors la relation R compose des tuples suivants :


(Dupont, Pierre)

Remarque : Rponse aux questions : Pour tous les ...


La division permet de rpondre aux questions du type : "Donnez toutes les personnes qui pratiquent tous
les mtiers de la relation mtier".

Remarque : Opration additionnelle


La division n'est pas une opration de base, elle peut tre rcrite en combinant le produit, la restriction et
la diffrence.

10. Proposition de notations


Introduction
Il existe plusieurs syntaxes pour crire des oprations d'algbre relationnelle, certaines inspires de
l'algbre classiques, d'autres reposant sur des notations graphiques. Nous proposons une notation
fonctionnelle qui a le mrite d'tre facile crire et d'tre lisible. Si cette notation peut parfois perdre en
simplicit, lorsqu'elle concerne un nombre lev d'oprateurs, il est possible de dcomposer une opration
complique afin de l'allger.

Syntaxe
R
R
R
R
R
R
R
R
R
R
R
R

=
=
=
=
=
=
=
=
=
=
=
=

Union (R1, R2)


Diffrence (R1, R2)
Intersection (R1, R2)
Projection (R1, A1, A2, ...)
Restriction (R1, condition)
Produit (R1, R2)
Jointure (R1, R2, condition)
JointureNaturelle (R1, R2)
JointureExterne (R1, R2, condition)
JointureGauche (R1, R2, condition)
JointureDroite (R1, R2, condition)
Division (R1, R2)

Exemple : Notation synthtique


R = Projection( Restriction(R1, A1=1 AND A2=2), A3)

Exemple : Notation dcompose


R' = Restriction(R1, A1=1 AND A2=2)
R = Projection (R', A3)

11. Exercice de synthse : Oprateurs de base et additionnels


Rcrivez les oprateurs additionnels suivants, partir d'oprateurs de base :
Question 1
[Solution n1 p 173]

Rcrivez Intersection partir de Diffrence


Question 2
[Solution n2 p 173]

Rcrivez Jointure partir de Produit et Restriction


S. Crozat - UTC 2009

73

Le niveau logique : la modlisation relationnelle

Question 3
[Solution n3 p 173]

Rcrivez Division partir de Produit, Restriction et Difference

E. En rsum : Schma relationnel


Schma relationnel
Un schma relationnel permet une formalisation d'un modle logique.

Relation ou table
Sous-ensemble d'un produit cartsien
Attribut ou colonne
Prend ses valeurs dans un domaine
Enregistrement ou ligne
Pose une valeur (y compris la valeur "null") pour chaque attribut

Cl
Groupe d'attributs ayant un rle d'identification au sein d'un enregistrement
Cl candidate
Identifie de faon unique un enregistrement
Cl primaire
Cl candidate choisie pour reprsenter un enregistrement pour sa facilit d'usage
Cl trangre
Rfrence la cl primaire d'un tuple d'une autre relation pour exprimer un lien

F. Bibliographie commente sur le modle relationnel


Complment : Synthses
SQL2 SQL3, applications Oracle [Delmal01]
Une dfinition synthtique et efficace du domaine relationnel : relation, domaine, attribut, cl, intgrit,
oprateurs (Premier chapitre).

74

S. Crozat - UTC 2009

IV -

LE LANGAGE SQL

IV

Qu'appelle-t-on SQL?

95

Le Langage de Dfinition de Donnes de SQL

96

Gestion avec le Langage de Manipulation de Donnes de SQL

103

Questions avec le Langage de Manipulation de Donnes de SQL

105

Instructions avances pour le LMD de SQL

115

Le Langage de Contrle de Donnes de SQL

119

En rsum : SQL

122

Bibliographie commente sur le SQL

123

SQL est un langage standardis, implment par tous les SGBDR, qui permet, indpendamment de
la plate-forme technologique et de faon dclarative, de dfinir le modle de donnes, de le contrler et
enfin de le manipuler.

A. Qu'appelle-t-on SQL?
Dfinition : SQL
SQL (pour langage de requtes structur) est un langage dclaratif destin la manipulation de bases
de donnes au sein des SGBD et plus particulirement des SGBDR.
SQL est un langage dclaratif, il n'est donc pas a proprement parl un langage de programmation, mais
plutt une interface standard pour accder aux bases de donnes.
Il est compos de trois sous ensembles :

Le Langage de Dfinition de Donnes (LDD, ou en anglais DDL Data Definition Language)


pour crer et supprimer des objets dans la base de donnes (tables, contraintes d'intgrit, vues,
etc.).

Le Langage de Contrle de Donnes (LCD, ou en anglais DCL, Data Control Language) pour
grer les droits sur les objets de la base (cration des utilisateurs et affectation de leurs droits).

Le Langage de Manipulation de Donnes (LMD, ou en anglais DML, Data Manipulation


Language) pour la recherche, l'insertion, la mise jour et la suppression de donnes. Le LMD est
bas sur les oprateurs relationnels, auxquels sont ajouts des fonctions de calcul d'agrgats et
des instructions pour raliser les oprations d'insertion, mise jour et suppression.

Complment : Origine du SQL


Le modle relationnel a t invent par E.F. Codd (Directeur de recherche du centre IBM de San Jos) en
1970, suite quoi de nombreux langages ont fait leur apparition :

IBM Sequel (Structured English Query Language) en 1977

S. Crozat - UTC 2009

75

Le langage SQL

IBM Sequel/2
IBM System/R

IBM DB2
Ce sont ces langages qui ont donn naissance au standard SQL, normalis en 1986 au tats-Unis par
l'ANSI pour donner SQL/86 (puis au niveau international par l'ISO en 1987).

Complment : Versions de SQL

SQL-86 (ou SQL-87) : Version d'origine


SQL-89 (ou SQL-1) : Amliorations mineures
SQL-92 (ou SQL-2) : Extensions fonctionnelles majeures (types de donnes, oprations
relationnelles, instruction LDD, transactions, etc.
SQL-99 (ou SQL-3) : Introduction du PSM (couche procdurale sous forme de procdure
stockes) et du RO
SQL-2003 : Extensions XML
SQL-2006 : Amliorations mineures (pour XML notamment)
SQl-2008 : Amliorations mineures (pour le RO notamment)

Remarque : Version SQL et implmentations SGBD


Selon leur niveau d'implmentation de SQL, les SGBD acceptent ou non certaines fonctions.
Certains SGBD ayant entam certaines implmentations avant leur standardisation dfinitive, ces
implmentations peuvent diffrer de la norme.

B. Le Langage de Dfinition de Donnes de SQL


Objectifs
Matriser les bases du SQL pour crer et modifier des tables et des vues,

Le LDD permet de crer les objets composant une BD de faon dclarative. Il permet notamment la
dfinition des schmas des relations, la dfinition des contraintes d'intgrit, la dfinition de vues
relationnelles.

1. Types de donnes
Introduction
Un attribut d'une relation est dfini pour un certain domaine. On peut galement dire qu'il est d'un type
particulier. Les types de donnes disponibles en SQL varient d'un SGBD l'autre, on peut nanmoins
citer un certain nombre de types standards que l'on retrouve dans tous les SGBD.

a) Les types numriques

76

Les nombres entiers


INTEGER(X), o X est optionnel et dsigne le nombre de chiffres maximum pouvant composer
le nombre. Il existe galement un certain nombre de variantes permettant de dfinir des entiers
plus ou moins volumineux, tels que TINYINT, SMALLINT ou LONGINT.
Les nombres dcimaux
DECIMAL(X,Y), o X et Y sont optionnels et dsignent respectivement le nombre de chiffres
S. Crozat - UTC 2009

Le langage SQL

maximum pouvant composer le nombre avant et aprs la virgule. NUMERIC est galement
utilis de faon quivalente.
Les nombres virgule flottante
REAL(X,Y), avec X et Y optionnels et dfinissant le nombre de chiffres avant et aprs la
virgule.
Il existe galement un certain nombre de variantes permettant de dfinir une prcision plus
grande, telles que DOUBLE.

b) Les types chane de caractres


On distingue principalement les types CHAR(X) et VARCHAR(X), o X et obligatoire et dsigne la
longueur de la chane. CHAR dfinit des chanes de longueur fixe (complte droites par des espaces, si
la longeur est infrieure X) et VARCHAR des chanes de longueurs variables. CHAR et VARCHAR
sont gnralement limits 255 caractres. La plupart des SGBD proposent des types, tels que TEXT ou
CLOB (Character Long Object), pour reprsenter des chanes de caractres longues, jusqu' 65000
caractres par exemple.

c) Les types date


Les types date dont introduits avec la norme SQL2. On distingue le type DATE qui reprsente une date
selon un format de type "AAAA-MM-JJ" et le types DATETIME qui reprsente une date avec un horaire,
dans un format tel que "AAAA-MM-JJ HH:MM:SS". Il existe galement des restrictions de ces types,
tels que YEAR, TIME, etc.

d) Les autres types


En fonction du SGBD, il peut exister de nombreux autres types. On peut citer par exemple les types
montaires pour reprsenter des dcimaux associs une monnaie, les types ENUM pour reprsenter des
numrations, les types BLOB (pour Binary Long Oject) pour reprsenter des donnes binaires tels que
des documents multimdia (images bitmap, vido, etc.).

e) Le type absence de valeur


L'absence de valeur, reprsente par la valeur NULL, est une information fondamentale en SQL, qu'il ne
faut pas confondre avec la chane espace de caractre o bien la valeur 0. Il ne s'agit pas d'un type
proprement parler, mais d'une valeur possible dans tous les types.

2. Cration de tables
Introduction
La cration de table est le fondement de la cration d'une base de donnes en SQL.

Dfinition : Cration de table


La cration de table est la dfinition d'un schma de relation en intension, par la spcification de tous les
attributs le composant avec leurs domaines respectifs.

Syntaxe
CREATE TABLE <nom de table> (
<nom colonne1> <type colonne1>,
<nom colonne2> <type colonne2>,
...
<nom colonneN> <type colonneN>,
);

S. Crozat - UTC 2009

77

Le langage SQL

Exemple
CREATE TABLE Personne (
Nom VARCHAR(25),
Prenom VARCHAR(25),
Age INTEGER(3)
);

Attention : Contrainte d'intgrit


La dfinition des attributs n'est pas suffisante pour dfinir un schma relationnel, il faut lui adjoindre la
dfinition de contraintes d'intgrit, qui permette de poser les notions de cl, d'intgrit rfrentielle, de
restriction de domaines, etc.

3. Contraintes d'intgrit
Dfinition : Contraintes d'intgrit
Une contrainte d'intgrit est une rgle qui dfinit la cohrence d'une donne ou d'un ensemble de
donnes de la BD.
Il existe deux types de contraintes :

sur une colonne unique,

ou sur une table lorsque la contrainte porte sur une ou plusieurs colonnes.
Les contraintes sont dfinies au moment de la cration des tables.
Les contraintes d'intgrit sur une colonne sont :

PRIMARY KEY : dfinit l'attribut comme la cl primaire

NOT NULL : interdit l'absence de valeur pour l'attribut

UNIQUE : interdit que deux tuples de la relation aient la mme valeur pour l'attribut.

REFERENCES <nom table> (<nom colonnes>) : contrle l'intgrit rfrentielle entre l'attribut
et la table et ses colonnes spcifies

CHECK (<condition>) : contrle la validit de la valeur de l'attribut spcifi dans la condition


dans le cadre d'une restriction de domaine
Les contraintes d'intgrit sur une table sont :

PRIMARY KEY (<liste d'attibuts>) : dfinit les attributs de la liste comme la cl primaire

UNIQUE (<liste d'attibuts>) : interdit que deux tuples de la relation aient les mmes valeurs
pour l'ensemble des attributs de la liste.

FOREIGN KEY (<liste d'attibuts>) REFERENCES <nom table>(<nom colonnes>) : contrle


l'intgrit rfrentielle entre les attributs de la liste et la table et ses colonnes spcifies

CHECK (<condition>) : contrle la validit de la valeur des attributs spcifis dans la condition
dans le cadre d'une restriction de domaine

Syntaxe
CREATE TABLE <nom de table> (
<nom colonne1> <type colonne1> <contraintes colonne1>,
<nom colonne2> <type colonne2> <contraintes colonne2>,
...
<nom colonneN> <type colonneN> <contraintes colonneN>,
<contraintes de table>
);

Remarque : Cl candidate
La contrainte UNIQUE NOT NULL sur un attribut ou un groupe d'attributs dfinit une cl candidate non
primaire.

78

S. Crozat - UTC 2009

Le langage SQL

Remarque
Les contraintes sur une colonne et sur une table peuvent tre combines dans la dfinition d'un mme
schma de relation.
Une contrainte sur une colonne peut toujours tre remplace par une contrainte sur une table.

Exemple
CREATE TABLE Personne (
NSS CHAR(13) PRIMARY KEY,
Nom VARCHAR(25) NOT NULL,
Prenom VARCHAR(25) NOT NULL,
Age INTEGER(3) CHECK (Age BETWEEN 18 AND 65),
Mariage CHAR(13) REFERENCES Personne(NSS),
Codepostal INTEGER(5),
Pays VARCHAR(50),
UNIQUE (Nom, Prenom),
FOREIGN KEY (Codepostal, Pays) REFERENCES Adresse (CP,
Pays)
);
CREATE TABLE Adresse (
CP INTEGER(5) NOT NULL,
Pays VARCHAR(50) NOT NULL,
Initiale CHAR(1) CHECK (Initiale = LEFT(Pays, 1)),
PRIMARY KEY (CP, Pays)
);
Dans la dfinition de schma prcdente on a pos les contraintes suivantes :

La cl primaire de Personne est NSS et la cl primaire de Adresse est (CP, Pays).

Nom, Prnom ne peuvent pas tre null et (Nom, Prnom) est une cl.

Age doit tre compris entre 18 et 65 et Initiale doit tre la premire lettre de Pays (avec la
fonction LEFT qui renvoie la sous chane gauche de la chane passe en premier argument, sur
le nombre de caractres passs en second argument)

Mariage est cl trangre vers Personne et (Codepostal, Pays) est une cl trangre vers Adresse.

4. Cration de vues
Dfinition : Vue
Une vue est une dfinition logique d'une relation, sans stockage de donnes, obtenue par interrogation
d'une ou plusieurs tables de la BD. Une vue peut donc tre perue comme une fentre dynamique sur
les donnes, ou encore une requte stocke (mais dont seule la dfinition est stocke, pas le rsultat, qui
reste calcul dynamiquement).
Une vue permet d'implmenter le concept de schma externe d'un modle conceptuel.
Synonymes : Relation drive, Table virtuelle calcule

Syntaxe
CREATE VIEW <nom de vue> <nom des colonnes>
AS <spcification de question>
La spcification d'une question se fait en utilisant le LMD.
Le nombre de colonnes nommes doit tre gal au nombre de colonnes renvoyes par la question
spcifie. Le nom des colonnes est optionnel, s'il n'est pas spcifi, c'est le nom des colonnes telle qu'elles
sont renvoyes par la question, qui sera utilis.

S. Crozat - UTC 2009

79

Le langage SQL

Exemple
CREATE VIEW Employe (Id, Nom)
AS
SELECT NSS, Nom
FROM Personne
La vue Employe est ici une projection de la relation Personne sur les attributs NSS et Nom, renomms
respectivement Id et Nom.

Remarque : Vue en lecture et vue en criture


Une vue est toujours disponible en lecture, condition que l'utilisateur ait les droits spcifis grce au
LCD. Une vue peut galement tre disponible en criture dans certains cas, que l'on peut restreindre
aux cas o la question ne porte que sur une seule table (mme si dans certains cas, il est possible de
modifier une vue issue de plusieurs tables).
Dans le cas o une vue est destine tre utilise pour modifier des donnes, il est possible d'ajouter la
clause "WITH CHECK OPTION" aprs la spcification de question, pour prciser que les donnes
modifies ou ajoutes doivent effectivement appartenir la vue.

Remarque : Vue sur une vue


Une vue peut avoir comme source une autre vue.

Rappel : Vues et hritage


Les vues sont particulirement utiles pour restituer les relations d'hritage perdues lors de la
transformation MCD vers MLD.

5. Suppression d'objets
Il est possible de supprimer des objets de la BD, tels que les tables ou les vues.

Syntaxe
DROP <type objet> <nom objet>

Exemple
DROP TABLE Personne;
DROP VIEW Employe;

6. Modification de tables
Introduction
L'instruction ALTER TABLE permet de modifier la dfinition d'une table (colonnes ou contraintes)
pralablement cre.
Cette commande absente de SQL-89 est normalise dans SQL-92

Syntaxe : Ajout de colonne


ALTER TABLE <nom de table>
ADD (<dfinition de colonne>);

80

S. Crozat - UTC 2009

Le langage SQL

Syntaxe : Suppression de colonne


ALTER TABLE <nom de table>
DROP (<nom de colonne>);

Syntaxe : Modification de colonne


ALTER TABLE <nom de table>
MODIFY (<redfinition de colonne>);

Syntaxe : Ajout de contrainte


ALTER TABLE <nom de table>
ADD (<dfinition de contrainte de table>);

Remarque : Modification de table sans donne sans la commande ALTER


Pour modifier une table ne contenant pas encore de donne, la commande ALTER n'est pas
indispensable, l'on peut supprimer la table modifier (DROP) et la recrer telle qu'on la souhaite. Notons
nanmoins que si la table est rfrence par des clauses FOREIGN KEY, cette suppression sera plus
complique, car il faudra galement supprimer et recrer les tables rfrenantes (ce qui ce complique
encore si ces dernires contiennent des donnes).

Remarque : Modification de table avec donnes sans la commande ALTER


Pour modifier une table contenant des donnes, la commande ALTER n'est pas absolument indispensable.
On peut en effet :
1. Copier les donnes dans une table temporaire de mme schma que la table modifier
2. Supprimer et recrer la table modifier avec le nouveau schma
3. Copier les donnes depuis la table temporaire vers la table modifie

7. Exemple de modifications de tables


a) Table initiale
Soit une table intiale telle que dfinie ci-aprs.
create table t_personnes (
pk_n number (4),
nom varchar(50),
prenom varchar (50),
PRIMARY KEY (pk_n)
);

b) Modifications
On dcide d'apporter les amnagements suivants la table : on passe la taille du champ "nom" de 50
255 caractres maximum, on dfinit "nom" comme UNIQUE et on supprime le champ "prenom".
alter table t_personnes
modify (nom varchar(255));
alter table t_personnes
add (UNIQUE (nom));
alter table t_personnes

S. Crozat - UTC 2009

81

Le langage SQL

drop (prenom);

c) Table finale
La table obtenue aprs modification est identique la table qui aurait t dfinie directement telle que ciaprs.
create table t_personnes (
pk_n number (4),
nom varchar(255),
PRIMARY KEY (pk_n),
UNIQUE (nom)
);

C. Gestion avec le Langage de Manipulation de Donnes de SQL


Objectifs
Matriser les bases du SQL pour entrer, modifier et effacer des donnes dans
les tables.

1. Insertion de donnes
Le langage SQL fournit galement des instructions pour ajouter des nouveaux tuples une relation. Il
offre ainsi une interface standard galement pour ajouter des information dans une base de donnes.
Il existe deux moyens d'ajouter des donnes, soit par fourniture directe des valeurs des proprits du tuple
ajouter, soit par slection des tuples ajouter dans une autre relation.

Syntaxe : Insertion directe de valeurs


INSERT INTO <Nom de la relation> (<Liste ordonne des
proprits valoriser>)
VALUES (<Liste ordonne des valeurs affecter aux
proprits spcifies ci-dessus>)

Exemple : Insertion directe de valeurs


INSERT INTO Virement (Date, Montant, Objet)
VALUES (14-07-1975, 1000, 'Prime de naissance');

Syntaxe : Insertion de valeurs par l'intermdiaire d'une slection


INSERT INTO <Nom de la relation> (<Liste ordonne des
proprits valoriser>)
SELECT ...
L'instruction SELECT projetant un nombre de proprits identiques aux proprits valoriser.

Exemple : Insertion de valeurs par l'intermdiaire d'une slection


INSERT INTO Credit (Date, Montant, Objet)

82

S. Crozat - UTC 2009

Le langage SQL

SELECT Date, Montant, 'Annulation de dbit'


FROM Debit
WHERE Debit.Date = 25-12-2001;
Dans cet exemple tous les dbits effectus le 25 dcembre 2001, sont recrdits pour le mme montant (et
la mme date), avec la mention annulation dans l'objet du crdit. Ceci pourrait typiquement ralis en
cas de dbits errrons ce jour l.

Remarque
Les proprits non valorises sont affectes la valeur null.
Il est possible de ne pas spcifier les proprits valoriser, dans ce cas, toutes les proprits de la relation
seront considres, dans leur ordre de dfinition dans la relation ( n'utiliser que dans les cas les plus
simples).

2. Mise jour de donnes


Le langage SQL fournit une instruction pour modifier des tuples existants dans une relation.

Syntaxe : Mise jour directe de valeurs


UPDATE <Nom de la relation>
SET <Liste d'affectation Proprit=Valeur>
WHERE <Condition pour filtrer les tuples mettre jour>

Exemple : Mise jour directe de valeurs


UPDATE Compte
SET Monnaie='Euro'
WHERE Monnaie='Franc'

Exemple : Mise jour par calcul sur l'ancienne valeur


UPDATE Compte
SET Total=Total * 6,55957
WHERE Monnaie='Euro'

3. Suppression de donnes
Le langage SQL fournit une instruction pour supprimer des tuples existants dans une relation.

Syntaxe
DELETE FROM <Nom de la relation>
WHERE <Condition pour filtrer les tuples supprimer>

Exemple : Suppression de tous les tuples d'une relation


DELETE FROM FaussesFactures

Exemple : Suppression slective


DELETE FROM FaussesFactures
WHERE Auteur='Moi'

S. Crozat - UTC 2009

83

Le langage SQL

D. Questions avec le Langage de Manipulation de Donnes de SQL


Objectifs
Matriser les bases du SQL pour crire des questions exigeant des jointures,
projections, restriction, des tris et des agrgats.

1. Slection
Introduction
La requte de slection ou question est la base de la recherche de donnes en SQL.

Dfinition : Slection
La selection est la composition d'un produit cartsien, d'une restriction et d'une projection (ou encore la
composition d'une jointure et d'une projection).

Syntaxe
SELECT <liste d'attributs projets>
FROM <liste de relations>
WHERE <condition>
La partie SELECT indique le sous-ensemble des attributs qui doivent apparatre dans la rponse (c'est le
schma de la relation rsultat).
La partie FROM dcrit les relations qui sont utilisables dans la requte (c'est dire l'ensemble des
attributs que l'on peut utiliser).
La partie WHERE exprime les conditions que doivent respecter les attributs d'un tuple pour pouvoir tre
dans la rponse. Une condition est un prdicat et par consquent renvoie un boolen. Cette partie est
optionnelle.
Afin de dcrire un attribut d'une relation dans le cas d'une requte portant sur plusieurs relations, on
utilise la notation "RELATION.ATTRIBUT".

Exemple
SELECT Nom, Prenom
FROM Personne
WHERE Age>18
Cette requte slectionne les attributs Nom et Prenom des tuples de la relation Personne, ayant un attribut
Age suprieur 18.

Exemple
SELECT Parent.Prenom, Enfant.Prenom
FROM Parent, Enfant
WHERE Enfant.Nom=Parent.Nom
Cette requte slectionne les prnoms des enfants et des parents ayant le mme nom. On remarque la
notation Parent.Nom et Enfant.Nom pour distinguer les attributs Prenom des relations Parent et Enfant.
On notera que cette slection effectue une jointure sur les proprits Nom des relations Parent et Enfant.

Remarque : SELECT *
Pour projeter l'ensemble des attributs d'une relation, on peut utiliser le caractre "*" la place de la liste
des attributs projeter.

84

S. Crozat - UTC 2009

Le langage SQL

Exemple
SELECT *
FROM Avion
Cette requte slectionne tous les attributs de la relation Avion.
Notons que dans cet exemple, la relation rsultat est exactement la relation Avion

Remarque : SELECT DISTINCT


L'oprateur SELECT n'limine pas les doublons (i.e. les tuples identiques dans la relation rsultat) par
dfaut. Il faut pour cela utiliser l'oprateur "SELECT DISTINCT".

Exemple
SELECT DISTINCT Avion
FROM Vol
WHERE Date=31-12-2000
Cette requte slectionne l'attribut Avion de la relation Vol, concernant uniquement les vols du 31
dcembre 2000 et renvoie les tuples dans doublons.

Remarque : Renommage de proprit


Il est possible de redfinir le nom des proprits de la relation rsultat. Ainsi "SELECT p AS p' FROM
relation" renvoie une relation ayant comme proprit p'. Cette possibilit est offerte partir de SQL2
(niveau entre).

Remarque : Projection de constante


Il est possible de projeter directement des constantes. Ainsi "SELECT 'Bonjour' AS Essai" renverra un
tuple avec une proprit Essai la valeur 'Bonjour'.

2. Oprateurs de comparaisons et oprateurs logiques


Introduction
La clause WHERE d'une instruction de slection est dfinie par une condition. Une telle condition
s'exprime l'aide d'oprateurs de comparaison et d'oprateurs logiques. Le rsultat d'une expression de
condition est toujours un boolen.

Dfinition : Condition
Condition Elmentaire ::= Proprit <Oprateur de
comparaison> Constante
Condition ::= Condition <Oprateur logique> Condition |
Condition Elmentaire
Les oprateurs de comparaison sont :

P=C

P <> C

P<C

P>C

P <= C

P >= C

P BETWEEN C1 AND C2

P LIKE 'chane'

S. Crozat - UTC 2009

85

Le langage SQL

P IN (C1, C2, ...)


P IS NULL
Les oprateur logique sont :

OR

AND

NOT

Remarque : Oprateur LIKE


L'oprateur LIKE 'chane' permet d'insrer des jokers dans l'opration de comparaison (alors que
l'oprateur = teste une galit stricte) :

Le joker % dsigne 0 ou plusieurs caractres quelconques

Le joker _ dsigne 1 et 1 seul caractre


On prfrera l'oprateur = l'oprateur LIKE lorsque la comparaison n'utilise pas de joker.

3. Expression du produit cartsien


Syntaxe
SELECT *
FROM R1, R2, Ri

4. Expression d'une projection


Syntaxe
SELECT P1, P2, Pi
FROM R

5. Expression d'une restriction


Syntaxe
SELECT *
FROM R
WHERE <condition>

6. Expression d'une jointure


Syntaxe : Jointure par la clause WHERE
En tant que composition d'un produit cartsien et d'une restriction la jointure s'crit alors :
SELECT *
FROM R1, R2, Ri
WHERE <condition>
Avec Condition permettant de joindre des attributs des Ri

Syntaxe : Jointure par la clause ON


On peut galement utiliser la syntaxe ddie suivante :
SELECT *
FROM R1 INNER JOIN R2

86

S. Crozat - UTC 2009

Le langage SQL

ON <condition>
Et pour plusieurs relations :
SELECT *
FROM (R1 INNER JOIN R2 ON <condition>) INNER JOIN Ri ON
<condition>

Exemple : Une jointure naturelle


SELECT *
FROM R1, R2
WHERE R2.NUM = R1.NUM

Remarque : Auto-jointure
Pour raliser une auto-jointure, c'est dire la jointure d'une relation avec elle-mme, on doit utiliser le
renommage des relations. Pour renommer une relation, on note dans la clause FROM le nom de
renommage aprs le nom de la relation : "FROM NOM_ORIGINAL NOUVEAU_NOM".

Exemple : Auto-jointure
SELECT E1.Nom
FROM Employe E1, Employe E2
WHERE E1.Nom= E2.Nom

Remarque : Jointure externe gauche ou droite


Pour exprimer une jointure externe on se base sur la syntaxe INNER JOIN en utilisant la place LEFT
OUTER JOIN ou RIGHT OUTER JOIN.

Exemple : Jointure externe gauche


SELECT Num
FROM Avion LEFT OUTER JOIN Vol
ON Avion.Num=Vol.Num
Cette requte permet de slectionner tous les avions, y compris ceux non affects un vol.

Remarque
Remarquons que "Avion LEFT OUTER JOIN Vol" est quivalent "Vol RIGHT OUTER JOIN Avion"
en terme de rsultat.
Intuitivement, on prfre utiliser la jointure gauche pour slectionner tous les tuple du ct N d'une
relation 1:N, mme si il ne sont pas rfrencs ; et la jointure droite pour pour slectionner tous les tuples
d'une relation 0:N, y compris ceux qui ne font pas de rfrence. Cette approche revient toujours garder
gauche de l'expression "JOIN" la relation "principale", i.e. celle dont on veut tous les tuples, mme s'ils
ne rfrencent pas (ou ne sont pas rfrencs par) la relation "secondaire".

7. Oprateurs ensemblistes
Introduction
Les oprateurs ensemblistes ne peuvent tre exprims l'aide de l'instruction de slection seule.

Syntaxe : Union
SELECT * FROM R1

S. Crozat - UTC 2009

87

Le langage SQL

UNION
SELECT * FROM R2

Syntaxe : Intersection
SELECT * FROM R1
INTERSECT
SELECT * FROM R2

Syntaxe : Diffrence
SELECT * FROM R1
EXCEPT
SELECT * FROM R2

Remarque
Les oprations INTERSECT et EXCEPT n'existe que dans la norme SQL2, et non dans la norme SQL1.
Certain SGBD sont susceptibles de ne pas les implmenter.

8. Tri
Introduction
On veut souvent que le rsultat d'une requte soit tri en fonction des valeurs des proprits des tuples de
ce rsultat.

Syntaxe : ORDER BY
SELECT <liste d'attributs projets>
FROM <liste de relations>
WHERE <condition>
ORDER BY <liste ordonne d'attributs>
Les tuples sont tris d'abord par le premier attribut spcifi dans la clause ORDER BY, puis en cas de
doublons par le second, etc.

Remarque : Tri dcroissant


Pour effectuer un tri dcroissant on fait suivre l'attribut du mot cl "DESC".

Exemple
SELECT *
FROM Personne
ORDER BY Nom, Age DESC

9. Fonctions de calcul
Dfinition : Fonction de calcul
Une fonction de calcul s'applique l'ensemble des valeurs d'une proprit d'une relation avec pour
rsultat la production d'une valeur atomique unique (entier, chane, date, etc).
Les cinq fonctions prdfinies sont :

Count(Relation.Proprit)
Renvoie le nombre de valeurs non nulles d'une proprit pour tous les tuples d'une relation ;

Sum(Relation.Proprit)

88

S. Crozat - UTC 2009

Le langage SQL

Renvoie la somme des valeurs d'une proprit des tuples (numriques) d'une relation ;
Avg(Relation.Proprit)
Renvoie la moyenne des valeurs d'une proprit des tuples (numriques) d'une relation ;
Min(Relation.Proprit)
Renvoie la plus petite valeur d'une proprit parmi les tuples d'une relation .
Max(Relation.Proprit)
Renvoie la plus grande valeur d'une proprit parmi les tuples d'une relation.

Syntaxe
SELECT <liste de fonctions de calcul>
FROM <liste de relations>
WHERE <condition appliquer avant calcul>

Exemple
SELECT Min(Age), Max(Age), Avg(Age)
FROM Personne
WHERE Qualification='Ingnieur'

Remarque : Utilisation de fonctions pour les agrgats


Dans le cas du calcul d'un agrgat, les fonctions peuvent tre utilises dans la claude HAVING ou dans la
clause ORDER BY d'un tri. Les fonctions ne peuvent pas tre utilises dans la clause WHERE.

Remarque : Comptage d'une relation


Pour effectuer un comptage sur tous les tuples d'une relation, appliquer la fonction Count un attribut de
la cl primaire. En effet cet attribut tant non nul par dfinition, il assure que tous les tuples seront
compts.

10. Agrgats
Dfinition : Agrgat
Un agrgat est un partitionnement horizontal d'une table en sous-tables, en fonction des valeurs d'un ou
plusieurs attributs de partitionnement, suivi de l'application d'une fonction de calcul chaque attribut des
sous-tables obtenues.

Syntaxe
SELECT <liste d'attributs de partionnement projeter et de
fonctions de calcul>
FROM <liste de relations>
WHERE <condition appliquer avant calcul de l'agrgat>
GROUP BY <liste ordonne d'attributs de partitionnement>
HAVING <condition sur les fonctions de calcul>

Exemple
SELECT Societe.Nom, AVG(Personne.Age)
FROM Personne, Societe
WHERE Personne.NomSoc = Societe.Nom
GROUP BY Societe.Nom
HAVING Count(Personne.NumSS) > 10
Cette requte calcul l'ge moyen du personnel pour chaque socit comportant plus de 10 salaris.

S. Crozat - UTC 2009

89

Le langage SQL

Remarque : Restriction
Une restriction peut tre applique avant calcul de l'agrgat, au niveau de la clause WHERE, portant ainsi
sur la relation de dpart, mais aussi aprs calcul de l'agrgat sur les rsultats de ce dernier, au niveau de la
clause HAVING.

Remarque : Projection
Si dans la clause SELECT, un attribut est projet directement, sans qu'une fonction lui soit applique,
alors il faut imprativement que cet attribut apparaisse dans la clause GROUP BY (car ce ne peut tre
qu'un attribut de partitionnement).

Remarque : Fonctions de calcul sans partitionnement


Si une ou plusieurs fonctions de calcul sont appliques sans partitionnement, le rsultat de la requte est
un tuple unique.

Remarque : Intrt de la clause GROUP BY


Pour que l'utilisation de la clause GROUP BY ait un sens, il faut qu'au moins une fonction de calcul soit
utilise, soit dans la clause SELECT, soit dans la clause HAVING.

Remarque : Contrle impos par quelques SGBDR


Notons que dans le cas de certains SGBDR (par exemple Oracle), l'ensemble des attributs de
l'agrgation (clause GROUP BY) doivent tre pralablement projets (donc dclars dans la clause
SELECT).

E. Instructions avances pour le LMD de SQL


Objectifs
tre capable d'apprendre des notions particulires de SQL lis un SGBD
en particulier ou des volutions futures de SQL.

1. Requtes imbriques
Introduction
Il est possible d'imbriquer des requtes les unes dans les autres pour procduraliser les questions, et ainsi
rpondre des questions plus complexes, voire impossibles, crire en algbre relationnel classique.

Dfinition : Sous-requte
Requte incluse dans la clause WHERE ou FROM d'une autre requte.
Synonymes : Sous-question, Requte imbrique

Syntaxe : Requtes imbriques par la clause WHERE


SELECT <projections>
FROM <relations>
WHERE <sous-requte>

90

S. Crozat - UTC 2009

Le langage SQL

Exemple
SELECT Nom
FROM Chercheur
WHERE Nom IN
(SELECT Nom FROM Enseignant)

2. Sous-requte d'existence IN
Introduction
Cette sous-requte permet de vrifier que la projection d'un tuple de la requte principale est prsent dans
la sous-requte.

Syntaxe
SELECT <projections>
FROM <relations>
WHERE (<projection d'un tuple>) IN
(<requte imbrique>)
La projection du tuple de la requte principale doit conduire un schma relationnel identique celui de
la requte imbrique.

Exemple : Sous-requte IN une colonne et plusieurs lignes


SELECT Chercheur.Nom
FROM Chercheur
WHERE Chercheur.Universite IN
(SELECT Universite.Nom
FROM Universite
WHERE Universite.Ville='Paris')

Exemple : Sous-requte IN plusieurs colonnes et plusieurs lignes


SELECT NSS
FROM Chercheur
WHERE (Nom, Prenom, Age) IN
(SELECT Nom, Prenom, Age
FROM Enseignant)

Exemple : Imbrication multiple de requtes


SELECT Nom
FROM Chercheur
WHERE Universite='Paris6' AND Nom IN
(SELECT Nom
FROM Enseignant
WHERE Universite IN
(SELECT Nom
FROM Universite
WHERE Ville='Paris'))

Remarque : Jointure par la sous-requte IN


La sous-requte IN est une troisime voie, avec les clauses WHERE et JOIN, pour raliser des jointures
entre relations. On prfrera nanmoins viter d'utiliser cette unique fin cette version plus procdurale.

S. Crozat - UTC 2009

91

Le langage SQL

Remarque : NOT IN
On peut tester la non existence du tuple dans la sous requte en utilisant la clause NOT IN la place de la
clause IN.

3. Sous-requte d'existence EXISTS


Introduction
Cette sous-requte permet de vrifier que la sous-requte contient au moins un tuple.

Syntaxe
SELECT <projections>
FROM <relations>
WHERE EXISTS
(<requte imbrique>)
La requte imbrique faisant rfrence des proprits (ventuellement non projetes) de la requte
principale.

Exemple
SELECT Chercheur.Nom
FROM Chercheur
WHERE EXISTS
(SELECT *
FROM Universite
WHERE Universite.Nom=Chercheur.Universite)

Remarque : Projection dans la sous-requte


Puisque la sous-requte n'est destine qu' valider l'existence d'un tuple, il est inutile de procder une
projection particulire pour cette sous-requte. On utilise donc en gnral la clause SELECT * pour une
sous-requte avec une clause EXISTS.

Remarque : NOT EXISTS


On peut tester la non prsence de tuple dans la sous-requte en utilisant la clause NOT EXISTS la place
de la clause EXISTS.

4. Sous-requte de comparaison ALL


Introduction
Cette sous-requte permet de vrifier que les tuples de la requte principale vrifient bien une condition
donne avec tous les tuples de la sous-requte.

Syntaxe
SELECT <projections>
FROM <relations>
WHERE <proprit> <oprateur de comparaison> ALL
(<requte imbrique>)
La requte imbrique renvoyant un tuple ne comportant qu'une proprit de mme domaine que la
proprit teste de la requte principale.

92

S. Crozat - UTC 2009

Le langage SQL

Exemple
SELECT Nom
FROM Chercheur
WHERE Age > ALL
(SELECT Age
FROM Etudiant)

5. Sous-requte de comparaison ANY


Introduction
Cette sous-requte permet de vrifier que les tuples de la requte principale vrifie bien une condition
donne avec au moins un tuple de la sous-requte.

Syntaxe
SELECT <projections>
FROM <relations>
WHERE <proprit> <oprateur de comparaison> ANY
(<requte imbrique>)
La requte imbrique renvoyant un tuple ne comportant qu'une proprit de mme domaine que la
proprit teste de la requte principale.

Exemple
SELECT Nom
FROM Chercheur
WHERE Age < ANY
(SELECT Age
FROM Etudiant)

Remarque : SOME
SOME peut tre utilis comme un synonyme de ANY.

6. Raffinement de questions dans la clause FROM


Il est possible de raffiner progressivement une requte en enchanant les questions dans la clause FROM.

Syntaxe
SELECT ... FROM (SELECT ... FROM ... WHERE ...) WHERE ...)

Remarque
Il est possible d'enchaner rcursivement N questions.

Mthode
Cette extension est particulirement utile pour les calculs d'agggat aprs filtrage ou pour enchaner les
calculs d'aggrgat (par exemple pour faire la moyenne de sommes aprs regroupement).

Exemple : Enchanement de calculs d'aggrgat


select avg(s) from (select sum(b) as s from t group by a)

S. Crozat - UTC 2009

93

Le langage SQL

F. Le Langage de Contrle de Donnes de SQL


Objectifs
Matriser les bases du SQL pour attribuer et rvoquer des droits sur des
objets d'une base de donnes.

Le LCD permet de crer les utilisateurs et de dfinir leurs droits sur les objets de la BD de faon
dclarative. Il permet notamment l'attribution et la rvocation de droits des utilisateurs, sur l'ensemble
des bases du SGBD, sur une BD en particulier, sur des relations d'une BD, voire sur certains attributs
seulement d'une relation.

1. Attribution de droits
SQL propose une commande pour attribuer des droits des utilisateurs sur des tables.

Syntaxe
GRANT <liste de droits> ON <nom table> TO <utilisateur>
[WITH GRANT OPTION]
Les droits disponibles renvoient directement aux instructions SQL que l'utilisateur peut excuter :

SELECT

INSERT

DELETE

UPDATE

ALTER
De plus il est possible de spcifier le droit ALL PRIVILEGES qui donne tous les droits l'utilisateur
(sauf celui de transmettre ses droits).
La clause WITH GRANT OPTION est optionnelle, elle permet de prciser que l'utilisateur a le droit de
transfrer ses propres droits sur la table d'autres utilisateur. Une telle clause permet une gestion
dcentralise de l'attribution des droits et non reposant uniquement dans les mains d'un administrateur
unique.
La spcification PUBLIC la place d'un nom d'utilisateur permet de donner les droits spcifis tous les
utilisateurs de la BD.

Exemple
GRANT SELECT, UPDATE ON Personne TO Pierre;
GRANT ALL PRIVILEGES ON Adresse TO PUBLIC;

Remarque : Droits sur un SGBD


Certains SGBD permettent de spcifier des droits au niveau du SGBD, c'est dire pour toutes les tables
de toutes les BD du SGBD. La syntaxe dans le cas de MySQL est "*.*" la place du nom de la table.
Dans ce cas les droits CREATE et DROP sont gnralement ajouts pour permettre ou non aux
utilisateurs de crer et supprimer des BD et des tables.

Remarque : Droits sur une BD


Certains SGBD permettent de spcifier des droits au niveau d'une BD, c'est dire pour toutes les tables

94

S. Crozat - UTC 2009

Le langage SQL

de cette base de donnes. La syntaxe dans le cas de MySQL est "nom_bd.*" la place du nom de la table.
Dans ce cas les droits CREATE et DROP sont gnralement ajouts pour permettre ou non aux
utilisateurs de crer et supprimer des tables sur cette BD.

Remarque : Droits sur une vue


Il est possible de spcifier des droits sur des vues plutt que sur des tables, avec une syntaxe identique (et
un nom de vue la place d'un nom de table).

Remarque : Catalogue de donnes


Les droits sont stocks dans le catalogue des donnes, il est gnralement possible de modifier
directement ce catalogue la place d'utiliser la commande GRANT. Cela reste nanmoins dconseill.

Remarque : Cration des utilisateurs


Les modalits de cration d'utilisateurs, voire de groupes d'utilisateurs dans le SGBD, reste dpendantes
de celui-ci. Des commande SQL peuvent tre disponibles, telles que CREATE USER, ou bien la
commande GRANT lorsque qu'elle porte sur un utilisateur non existant peut tre charge de crer cet
utilisateur. Des modules spcifiques d'administration sont gnralement disponibles pour prendre en
charge la gestion des utilisateurs.

2. Rvocation de droits
SQL propose une commande pour rvoquer les droits attribus des utilisateurs.

Syntaxe
REVOKE <liste de droits> ON <nom table> FROM <utilisateur>

Exemple
REVOKE SELECT, UPDATE ON Personne TO Pierre;
REVOKE ALL PRIVILEGES ON Adresse TO PUBLIC;

Remarque : Rvocation du droit de donner les droits


Pour retirer les droits de donner les droits un utilisateur (qui l'a donc obtenu par la clause WITH
GRANT OPTION), il faut utiliser la valeur GRANT OPTION dans la liste des droits rvoqus.

Remarque : Rvocation en cascade


Lorsque qu'un droit est supprim pour un utilisateur, il l'est galement pour tous les utilisateurs qui avait
obtenu ce mme droit par l'utilisateur en question.

G. En rsum : SQL
Langage SQL
Le langage SQL permet la cration, le contrle et la manipulation d'une BD.

LDD
Permet de crer, modifier et supprimer les objets d'une BD
CREATE TABLE
CREATE VIEW

LCD
Permet de dfinir les droits des utilisateurs sur les objets de la BD

S. Crozat - UTC 2009

95

Le langage SQL

GRANT
REVOKE
LMD
Permet d'entrer et sortir des donnes dans la BD
INSERT, UPDATE, DELETE
SELECT
-

H. Bibliographie commente sur le SQL


Complment : Exerciseur faire
Tutoriel SQL [w_univ-lyon2.fr/~jdarmont]
Un excellent exerciseur permettant de poser des questions en SQL une base de donnes en temps rel.
18 questions faire absolument.

Complment : Pour continuer de s'exercer


Initiation SQL : Cours et exercices corrigs [Pratt01]
Un ensemble d'exemples, de questions/rponses, de how-to, et d'exercices corrigs pour travailler les
basiques du LMD SQL avec une approche trs pratique. Un bon outil pour s'entraner et un bon
compagnon avoir ses cts pour des dbuts en SQL (pour la ralisation de travaux pratiques par
exemple).
Programmation SQL [Mata03]
De nombreux exemples et exercices, des listings complets, une rfrence SQL (mots rservs et
diagrammes de Conway de la syntaxe).

Complment : Pratique
Comprendre les jointures dans Access [w_mhubiche.developpez.com]
Un tutoriel trs pdagogique sur l'expression de jointures sous Access qui aide comprendre l'opration
de jointure en gnral.

96

S. Crozat - UTC 2009

V-

LA THORIE DE LA

NORMALISATION
RELATIONNELLE
Les dpendances fonctionnelles

125

Les formes normales

134

Bibliographie commente sur la normalisation

139

La thorie de la normalisation relationnelle est trs importante pour la conception de BD, dans la
mesure o elle donne le cadre thorique pour la gestion de la redondance, et dans la mesure o une bonne
matrise de la redondance est un aspect majeur de cette conception.

A. Les dpendances fonctionnelles


Objectifs
Comprendre la problmatique de la redondance et des dpendances
fonctionnelles.

1. Exercice introductif : Redondance


Soit la relation R suivante, dfinie en extension :
A

10

10

10

10

20

10

20

20

Tableau 13 Relation R
Question 1
[Solution n4 p 173]

Proposez une cl primaire pour cette relation. Justifiez brivement.

S. Crozat - UTC 2009

97

La thorie de la normalisation relationnelle

Question 2
[Solution n5 p 174]

Cette relation contient-elle des redondances ? Si oui lesquelles ? Justifiez brivement.


Question 3
[Solution n6 p 174]
Si la relation contient des redondances, proposez une solution contenant exactement la mme
information, mais sans redondance.

2. Les problmes soulevs par une mauvaise modlisation


Attention
Il y a toujours plusieurs faons de modliser conceptuellement un problme, certaines sont bonnes et
d'autres mauvaises. C'est l'expertise de l'ingnieur en charge de la modlisation, travers son exprience
accumule et sa capacit traduire le problme pos, qui permet d'obtenir de bons modles conceptuels.
S'il est difficile de dfinir un bon modle conceptuel, on peut par contre poser qu'un bon modle logique
relationnel est un modle o la redondance est contrle. On peut alors poser qu'un bon modle
conceptuel est un modle conceptuel qui conduit un bon modle relationnel, aprs application des rgles
de passage E-A ou UML vers relationnel. Mais on ne sait pas pour autant le critiquer avant ce passage,
autrement qu' travers l'oeil d'un expert.
A dfaut de disposer d'outils systmatiques pour obtenir de bons modles conceptuels, on cherche donc
critiquer les modles relationnels obtenus. La thorie de la normalisation est une thorie qui permet de
critiquer, puis d'optimiser, des modles relationnels, de faon en contrler la redondance.

Exemple : Un mauvais modle relationnel


Imaginons que nous souhaitions reprsenter des personnes, identifies par leur numro de scurit
sociale, caractrises par leur nom, leur prnom, ainsi que les vhicule qu'elles ont achet, pour un certain
prix et une certaine date, sachant qu'un vhicule est caractris par un type, une marque et une
puissance. On peut aboutir la reprsentation relationnelle suivante :
Personne(NSS, Nom, Prnom, Marque, Type, Puiss, Date, Prix)
Imaginons que cette relation soit remplie par les donnes suivantes :
NSS

Nom

Prnom

Marque

Type

Puiss

Date

Prix

16607...

Dupont

Paul

Renault

Clio

1/1/96

60000

16607...

Dupont

Paul

Peugeot

504

2/7/75

47300

24908...

Martin

Marie

Peugeot

504

1/10/89

54900

15405...

Durand

Olivier

Peugeot

504

8/8/90

12000

15405...

Durand

Olivier

Renault

Clio

7/6/98

65000

15405...

Durand

Olivier

BMW

520

10

4/5/2001

98000

Tableau 14 Relation redondante


On peut alors se rendre compte que des redondances sont prsentes, et l'on sait que ces redondances
conduiront des problmes de contrle de la cohrence de l'information (erreur dans la saisie d'un
numro de scurit sociale), de mise jour (changement de nom reporter dans de multiples tuples), de
perte d'information lors de la suppression de donnes (disparition des informations concernant un type de
vhicule) et de difficult reprsenter certaines informations (un type de vhicule sans propritaire).

Complment
On conseillera de lire le chapitre 2 de SQL2 SQL3, applications Oracle [Delmal01] (pages 42 49)
qui propose une trs bonne dmonstration par l'exemple des problmes poss par une mauvaise
modlisation relationnelle.

98

S. Crozat - UTC 2009

La thorie de la normalisation relationnelle

3. Principes de la normalisation
Fondamental
La thorie de la normalisation est une thorie destine concevoir un bon schma dune BD sans
redondance dinformation et sans risques d'anomalie de mise jour. Elle a t introduite ds l'origine dans
le modle relationnel.
La thorie de la normalisation est fonde sur deux concepts principaux :

Les dpendances fonctionnelles


Elles traduisent des contraintes sur les donnes.

Les formes normales


Elles dfinissent des relations bien conues.
La mise en oeuvre de la normalisation est fonde sur la dcomposition progressive des relations jusqu'
obtenir des relations normalises.

4. Dpendance fonctionnelle
Dfinition : Dpendance fonctionnelle
Soient R(A1, A2, ... , An) un schma de relation, X et Y des sous-ensembles de A1, A2, ... , An. On dit
que X dtermine Y, ou que Y dpend fonctionnellement de X, si est seulement s'il existe une fonction qui
partir de toute valeur de X dtermine une valeur unique de Y.
Plus formellement on pose que X dtermine Y pour une relation R ssi quelle que soit l'instance r de R,
alors pour tous tuples t1 et t2 de r on a :
Projection (t1,X) = Projection (t2,X) Projection (t1,Y) = Projection (t2,Y)

Syntaxe
Si X dtermine Y, on note : XY

Exemple
Soit la relation R suivante :
Personne(NSS, Nom, Prnom, Marque, Type, Puiss, Date, Prix)
On peut poser les exemples de DF suivants :

NSSNom

NSSPrnom

TypeMarque

TypePuiss

(NSS, Type, Date)Prix

etc.

Remarque : Comment trouver les DF ?


Une DF est dfinie sur l'intention du schma et non son extension. Une DF traduit une certaine perception
de la ralit. Ainsi la DF (NSS, Type, Date)Prix signifie que personne n'achte deux voitures du mme
type la mme date.
La seule manire de dterminer une DF est donc de regarder soigneusement ce que signifient les attributs
et de trouver les contraintes qui les lient dans le monde rel.

Remarque : Pourquoi trouver les DF ?


Les DF font partie du schma d'une BD, en consquence, elles doivent tre dclares par les

S. Crozat - UTC 2009

99

La thorie de la normalisation relationnelle

administrateurs de la BD et tre contrles par le SGBD.


De plus l'identification des DF est la base indispensable pour dterminer dans quelle forme normale est
une relation et comment en diminuer la redondance.

5. Les axiomes d'Armstrong


Introduction
Les DF obissent des proprits mathmatiques particulires, dites axiomes d'Armstrong.

Dfinition : Rflexivit
Tout groupe d'attributs se dtermine lui mme et dtermine chacun de ses attributs (ou sous groupe de ses
attributs).
Soient X et Y des attributs :
XYXY et XYX et XYY

Dfinition : Augmentation
Si un attribut X dtermine un attribut Y, alors tout groupe compos de X enrichi avec d'autres attributs
dtermine un groupe compos de Y et enrichi des mmes autres attributs.
Soient X, Y et Z des attributs :
XY XZYZ

Dfinition : Transitivit
Si un attribut X dtermine un attribut Y et que cet attribut Y dtermine un autre attribut Z, alors X
dtermine Z.
Soient X, Y et Z des attributs :
XY et YZ XZ

6. Autres proprits dduites des axiomes d'Armstrong


Introduction
A partir des axiomes d'Amstrong, on peut dduire un certain nombre de proprits supplmentaires.

Dfinition : Pseudo-transitivit
Si un attribut X dtermine un autre attribut Y, et que Y appartient un groupe G qui dtermine un
troisime attribut Z, alors le groupe G' obtenu en substituant Y par X dans G dtermine galement Z.
Soient, W, X, Y et Z des attributs :
XY et WYZ WXZ
Cette proprit est dduite de l'augmentation et de la rflexivit :
XY et WYZ WXWY et WYZ WXZ

Dfinition : Union
Si un attribut dtermine plusieurs autres attributs, alors il dtermine tout groupe compos de ces attributs.
Soient X, Y et Z des attributs :
XY et XZ XYZ
Cette proprit est dduite de la rflexivit, de l'augmentation et de la transitivit :
XY et XZ XXX et XXXY et YXYZ XYZ

Dfinition : Dcomposition
Si un attribut dtermine un groupe d'attribut, alors il dtermine chacun des attributs de ce groupe pris

100

S. Crozat - UTC 2009

La thorie de la normalisation relationnelle

individuellement.
Soient X, Y et Z des attributs :
XYZ XZ et XY
Cette proprit est dduite de la rflexivit et de la transitivit :
XYZ XYZ et YZZ XZ

7. DF lmentaire
Dfinition : Dpendance fonctionnelle lmentaire
Soit G un groupe d'attributs et A un attribut, une DF GA est lmentaire si A n'est pas inclu dans G
et qu'il n'existe pas d'attribut A' de G qui dtermine A.

Exemple : DF lmentaires

ABC est lmentaire si ni A, ni B pris individuellement ne dterminent C.


Nom, DateNaissance, LieuNaissancePrnom est lmentaire.

Exemple : DF non lmentaires

ABA n'est pas lmentaire car A est inclu dans AB.


ABCB n'est pas lmentaire car CB n'est pas un attribut, mais un groupe d'attributs.
NSSNom, Prnom n'est pas lmentaire.

Remarque
On peut toujours rcrire un ensemble de DF en un ensemble de DFE, en supprimant les DF triviales
obtenues par rflexivit et en dcomposant les DF partie droite non atomique en plusieurs DFE.

Exemple : Rcriture de DF en DFE


On peut rcrire les DF non lmentaires de l'exemple prcdent en les dcomposant DFE :

ABA n'est pas considre car c'est une DF triviale obtenu par rflxivit.

ABCB est dcompose en ABC et ABB, et ABB n'est plus considre car triviale.

NSSNom, Prnom est dcompose en NSSNom et NSSPrnom.

8. Notion de fermeture transitive des DFE


Dfinition : Fermeture transitive
On appelle fermeture transitive F+ d'un ensemble F de DFE, l'ensemble de toutes les DFE qui peuvent
tre composes par transitivit partir des DFE de F.

Exemple
Soit l'ensemble F = {AB, BC, BD, AE}.
La fermeture transitive de F est F+ = { AB, BC, BD, AE, AC, AD }

9. Notion de couverture minimale des DFE


Dfinition : Couverture minimale
La couverture minimale dun ensemble de DFE est un sous-ensemble minimum des DFE permettant de
gnrer toutes les autres DFE.
Synonymes : Famille gnratrice

S. Crozat - UTC 2009

101

La thorie de la normalisation relationnelle

Remarque
Tout ensemble de DFE (et donc tout ensemble de DF) admet au moins une couverture minimale (et en
pratique souvent plusieurs).

Exemple
L'ensemble F = {AB, AC, BC, CB} admet les deux couvertures minimales :
CM1 = {AC, BC, CB} et CM2 = {AB, BC, CB}

10. Notion de graphe des DFE


On peut reprsenter un ensemble de DFE par un graphe orient (ou plus prcisment un rseau de Ptri),
tel que les noeuds sont les attributs et les arcs les DFE (avec un seul attribut en destination de chaque arc
et ventuellement plusieurs en source).

Exemple : Relation Voiture


Soit la relation Voiture(NVH, Marque, Type, Puis, Couleur) avec l'ensemble des DF F = {NVHType,
TypeMarque, TypePuis, NVHCouleur}. On peut rprsenter F par le graphe ci-dessous :

Graphe des DFE de la relation Voiture

Exemple : Relation CodePostal


Soit la relation CodePostal(Code, Ville, Rue ) avec l'ensemble des DF F={CodeVille,
(Ville,Rue)Code}. On peut rprsenter F par le graphe ci-dessous :

Graphe des DFE de la relation CodePostal

11. Dfinition formelle d'une cl


Dfinition : Cl
Soient une relation R(A1,A2,...,An) et K un sous-ensemble de A1,A2,... ,An. K est une cl de R si et
seulement si KA1,A2,...,An et il n'existe pas X inclu dans K tel que XA1,A2,...,An.
Une cl est donc un ensemble minimum d'attributs d'une relation qui dtermine tous les autres.

102

S. Crozat - UTC 2009

La thorie de la normalisation relationnelle

Remarque : Cls candidates et cl primaire


Si une relation comporte plusieurs cls, chacun est dite cl candidate et l'on en choisit une en particulier
pour tre la cl primaire.

Remarque
Toute cl candidate dtermine les autres cls candidates, puisque qu'une cl dtermine tous les attributs de
la relation.

B. Les formes normales


Objectifs
Savoir crer des schmas relationnels en troisime forme normale.

1. Principe de la dcomposition
Dfinition : Dcomposition
L'objectif de la dcomposition est de "casser" une relation en relations plus petites afin d'en liminer les
redondances et sans perdre d'information.
La dcomposition d'un schma de relation R(A1,A2,...,An) est le processus de remplacement de ce
schma par une collection de schmas R1,R2,...,Rn telle qu'il est possible de reconstruire R par des
oprations relationnelles de jointure sur R1,R2,...,Rn.

Dfinition : Dcomposition prservant les DF


Une dcomposition d'une relation R en relations R1,R2,...Rn prserve les DF si la fermeture transitive
F+ des DF de R est la mme que celle de l'union des fermetures transitives des DF de R1,R2,...,Rn.

Exemple : Dcomposition prservant les DF d'une relation Voiture


Soit la relation Voiture(Numro,Marque,Type,Puissance,Couleur) avec la fermeture transitive suivante :

NumroMarque

NumroType

NumroPuissance

NumroCouleur

TypeMarque

TypePuissance
On peut dcomposer Voiture en prservant les DF en deux relations R1(Numro,Type,Couleur) et
R2(Type,Puissance,Marque).

2. Formes normales
Les formes normales ont pour objectif de dfinir la dcomposition des schmas relationnels, tout en
prservant les DF et sans perdre d'informations, afin de reprsenter les objets et associations
canoniques du monde rel de faon non redondante.
On peut recenser les 6 formes normales suivantes, de moins en moins redondantes :

la premire forme normale

la deuxime forme normale

la troisime forme normale


S. Crozat - UTC 2009

103

La thorie de la normalisation relationnelle

la forme normale de Boyce-Codd


la quatrime forme normale

la cinquime forme normale


La troisime forme normale est gnralement reconnue comme tant la plus importante respecter.

3. Premire forme normale


Dfinition : 1NF
Une relation est en 1NF si elle possde une cl et si tous ses attributs sont atomiques.

Dfinition : Attribut atomique


Un attribut est atomique si il ne contient qu'une seule valeur pour un tuple donn, et donc s'il ne regroupe
pas un ensemble de plusieurs valeurs.

Exemple : Avoir plusieurs mtiers


Soit la relation Personne instancie par deux tuples :
Personne(Nom, Profession)
(Dupont, Gomtre)
(Durand, Ingnieur-Professeur)
La relation n'est pas en 1NF, car l'attribut Profession peut contenir plusieurs valeurs.
Pour que la relation soit en 1NF, on pourrait par exemple ajouter Profession la cl et faire apparatre
deux tuples pour Durand, on obtiendrait :
Personne(Nom, Profession)
(Dupont, Gomtre)
(Durand, Ingnieur)
(Durand, Professeur)
Une autre solution aurait t d'ajouter un attribut ProfessionSecondaire. On obtiendrait ainsi :
Personne(Nom, Profession, ProfessionSecondaire)
(Dupont, Gomtre, Null)
(Durand, Ingnieur, Professeur)

Remarque : Relativit de la notion d'atomicit


L'atomicit d'un attribut est souvent relative : on peut dcider qu'un attribut contenant une date n'est pas
atomique (et que le jour, le mois et l'anne constituent chacun une valeur), ou bien que l'attribut est de
domaine date et donc qu'il est atomique.

4. Deuxime forme normale


Introduction
La deuxime forme normale permet d'liminer les dpendances entre des parties de cl et des attributs
n'appartenant pas une cl.

Dfinition : 2NF
Une relation est en 2NF si elle est en 1NF et si tout attribut qui n'est pas dans une cl ne dpend pas
d'une partie seulement d'une cl. C'est dire encore que toutes les DF issues d'une cl sont
lmentaires.

104

S. Crozat - UTC 2009

La thorie de la normalisation relationnelle

Exemple : Echelle de salaire


Soit la relation Personne :
Personne(Nom, Profession, Salaire)
Soit les DF suivantes sur cette relation :

Nom,ProfessionSalaire

ProfessionSalaire
On note alors que la premire DF est issue de la cl et qu'elle n'est pas lmentaire (puisque Profession
dtermine Salaire) et donc que le schma n'est pas en 2NF.
Pour avoir un schma relationnel en 2NF, il faut alors dcomposer Personne en deux relations :
Personne(Nom, Profession)
Profession(Profession, Salaire)
On remarque que ce schma est en 2NF (puisque Salaire dpend maintenant fonctionnellement d'une cl
et non plus d'une partie de cl).
On remarque aussi que la dcomposition a prserv les DF, puisque nous avons prsent :

ProfessionSalaire (DF de la relation Profession)

Nom,ProfessionProfession (par Rflexivit)

Nom,ProfessionSalaire (par Transitivit)

Remarque
La dfinition de la 2NF doit tre vrifie pour toutes les cls candidates et non seulement la cl primaire
(dans le cas o il y a plusieurs cls).

Remarque
Si toutes les cls d'une relation ne contiennent qu'un unique attribut, et que la relation est en 1NF, alors la
relation est en 2NF.

5. Troisime forme normale


Introduction
La troisime forme normale permet d'liminer les dpendances entre les attributs n'appartenant pas une
cl.

Dfinition : 3NF
Une relation est en 3NF si elle est en 2NF et si tout attribut n'appartenant pas une cl ne dpend pas
d'un autre attribut n'appartenant pas une cl. C'est dire encore que toutes les DFE vers des attributs
n'appartenant pas une cl, sont issues d'une cl.

Attention : Cl candidate
La dfinition concerne toutes les cls candidates et non uniquement la cl primaireSQL avanc :
Programmation et techniques avances. [Celko00] (p.27).

Exemple : Echelle de salaire et de prime


Soit la relation Profession :
Profession(Profession, Salaire, Prime)
Soit les DF suivantes sur cette relation :

ProfessionSalaire

ProfessionPrime
S. Crozat - UTC 2009

105

La thorie de la normalisation relationnelle

SalairePrime
Cette relation n'est pas en 3NF car Salaire, qui n'est pas une cl, dtermine Prime.
Pour avoir un schma relationnel en 3NF, il faut dcomposer Profession :

Profession(Profession, Salaire)
Salaire(Salaire, Prime)
Ce schma est en 3NF, car Prime est maintenant dtermin par une cl.
On remarque que cette dcomposition prserve les DF, car par transitivit, Profession dtermine Salaire
qui dtermine Prime, et donc Profession dtermine toujours Prime.

Remarque : 3NF et 2NF


Une relation en 3NF est forcment en 2NF car :

Toutes les DFE vers des attributs n'appartenant pas une cl sont issues d'une cl, ce qui
implique qu'il n'existe pas de DFE, issues d'une partie de cl vers un attribut qui n'appartient pas
une cl.

Il ne peut pas non plus exister de DFE issues d'une partie de cl vers un attribut appartenant
une cl, par dfinition de ce qu'une cl est un ensemble minimum.
On n'en conclut qu'il ne peut exister de DFE, donc a fortiori pas de DF, issues d'une partie d'une cl, et
donc que toutes les DF issues d'une cl sont lmentaires.

Fondamental
Il est souhaitable que les relations logiques soient en 3NF. En effet, il existe toujours une dcomposition
sans perte d'information et prservant les DF d'un schma en 3NF. Si les formes normales suivantes
(BCNF, 4NF et 5NF) assurent un niveau de redondance encore plus faible, la dcomposition
permettant de les atteindre ne prserve plus les DF.

Remarque : Limite de la 3NF


Une relation en 3NF permet des dpendances entre des attributs n'appartenant pas une cl vers des
parties de cl.

6. Forme normale de Boyce-Codd


Introduction
La forme normale de Boyce-Codd permet d'liminer les dpendances entre les attributs n'appartenant pas
une cl vers les parties de cl.

Dfinition : BCNF
Une relation est en BCNF si elle est en 3NF et si tout attribut qui n'appartient pas une cl n'est pas
source d'une DF vers une partie d'une cl. C'est dire que les seules DFE existantes sont celles dans
lesquelles une cl dtermine un attribut.

Exemple : Employs
Soit la relation Personne :
Personne(NSS, Pays, Nom, Rgion)
Soit les DF suivantes sur cette relation :

NSS,PaysNom
NSS,PaysRgion
RgionPays
Il existe une DFE qui n'est pas issue d'une cl et qui dtermine un attribut appartenant une cl. Cette
relation est en 3NF, mais pas en BCNF (car en BCNF toutes les DFE sont issues d'une cl).

106

S. Crozat - UTC 2009

La thorie de la normalisation relationnelle

Pour avoir un schma relationnel en BCNF, il faut dcomposer Personne :


Personne(NSS, Rgion, Nom)
Rgion(Region, Pays)
Remarquons que les DF n'ont pas t prserves par la dcomposition puisque NSS et Pays ne
dterminent plus Rgion.

Remarque : Simplicit
La BCNF est la forme normale la plus facile apprhender intuitivement et formellement, puisque les
seules DFE existantes sont de la forme KA o K est une cl.

Attention : Non prservation des DF


Une dcomposition en BCNF ne prserve en gnral pas les DF.

* *
*

La normalisation permet de dcomposer un schma relationnel afin d'obtenir des relations non
redondantes.
La 3NF est souhaitable car toujours possible obtenir, sans perte d'information et sans perte de DF.
La BCNF est galement indique, car elle est un peu plus puissante, et plutt plus simple que la 3NF.
La BCNF n'est pas encore suffisante pour liminer toutes les redondances. Il existe pour cela les
4NF et 5NF qui ne sont pas abordes dans ce cours. Notons galement que les cas de non-4NF et de
non-5NF sont assez rares dans la ralit.

C. Bibliographie commente sur la normalisation


Complment : Synthses
SQL2 SQL3, applications Oracle [Delmal01]
On conseillera de lire le chapitre 2 (pages 42 49) qui propose une trs bonne dmonstration par
l'exemple des problmes poss par une mauvaise modlisation relationnelle.
Une description claire des formes normales, rendue simple et pratique grce des exemples reprsentatifs
(chapitre 2).

S. Crozat - UTC 2009

107

VI -

LE RELATIONNEL-OBJET

VI

Introduction : R, OO, RO

141

Le modle relationnel-objet

144

Le passage conceptuel vers relationnel-objet

149

SQL3 (implmentation Oracle 9i)

151

Exemples RO

158

En rsum : Le relationnel-objet

163

Bibliographie commente sur le relationnel-objet

164

Si le modle logique relationnel a prouv sa puissance et sa fiabilit au cours des 20 dernires annes, les
nouveaux besoins de l'informatique industrielle ont vu l'mergence de structures de donnes complexes
mal adaptes une gestion relationnelle. La naissance du courant "orient objet" et des langages associes
(Java et C++ par exemple) ont donc galement investi le champ des SGBD afin de proposer des
solutions pour tendre les concepts du relationnel et ainsi mieux rpondre aux nouveaux besoins de
modlisation.

A. Introduction : R, OO, RO
Objectifs
Comprendre les limites du modle relationnel
Comprendre pourquoi et comment le modle relationnel peut tre tendu

1. Les atouts du modle relationnel

Fond sur une thorie rigoureuse et des principes simples


Mature, fiable, performant
Indpendance programme et donnes
SGBDR : les plus utiliss, connus, matriss
SQL une implmentation standard du modle relationnel, avec des API pour la plupart des
langages de programmation
Les SGBDR incluent des outils performants de gestion de requtes, de gnrateurs
d'applications, d'administration, d'optimisation, etc, ...

2. Les inconvnients du modle relationnel


S. Crozat - UTC 2009

109

Le relationnel-objet

La structure de donne en tables est pauvre d'un point de vue de la modlisation logique
Le mapping MCD vers MLD entrane une perte de smantique
La manipulation de structures relationnelles par des langages objets entrane une impedance
mismatch, c'est dire un dcalage entre les structures de donnes pour le stockage et les
structures de donnes pour le traitement (ce qui implique des conversions constantes d'un format
l'autre)
La 1NF est inapproprie la modlisation d'objets complexes
La normalisation entrane la gense de structures de donnes complexes et trs fragmentes, qui
peuvent notamment poser des problmes de performance ou d'volutivit
Le SQL doit toujours tre combin d'autres langages de programmation pour tre
effectivement mis en uvre
La notion de mthode ne peut tre intgre au modle logique, elle doit tre gre au niveau de
l'implmentation physique
Les types de donnes disponibles sont limits et non extensibles

3. Les SGBDOO
Introduction
Les SGBDOO ont t crs pour grer des structures de donnes complexes, en profitant de la
puissance de modlisation des modles objets et de la puissance de stockage des BD classiques.
Objectifs des SGBDOO :

Offrir aux langages de programmation orients objets des modalits de stockage permanent et de
partage entre plusieurs utilisateurs

Offrir aux BD des types de donnes complexes et extensibles

Permettre la reprsentation de structures complexes et/ou taille variable


Avantages des SGBDOO :

Le schma d'une BD objet est plus facile apprhender que celui d'une BD relationnelle (il
contient plus de smantique, il est plus proche des entits relles)

L'hritage permet de mieux structurer le schma et de factoriser certains lments de


modlisation

La cration de ses propres types et l'intgration de mthodes permets une reprsentation plus
directe du domaine

L'identification des objets permet de supprimer les cls artificielles souvent introduites pour
atteindre la 3NF et donc de simplifier le schma

Les principes d'encapsulation et d'abstraction du modle objet permettent de mieux sparer les
BD de leurs applications (notion d'interface).
Inconvnient des SGBDOO :

Gestion de la persistance et de la coexistence des objets en mmoire (pour leur manipulation


applicative) et sur disque (pour leur persistance) complexe

Gestion de la concurrence (transactions) plus difficile mettre en uvre

Interdpendance forte des objets entre eux

Gestion des pannes

Complexit des systmes (problme de fiabilit)

Problme de compatibilit avec les SGBDR classiques


Les SGBDOO apportent donc des concepts fondamentaux pour l'volution des BD, mais leur ralit est
encore en grande partie du domaine de la recherche ou d'applications "de niche".
Ils apportent donc une innovation sur des aspects que les SGBDR ne savent pas faire, mais sans tre au

110

S. Crozat - UTC 2009

Le relationnel-objet

mme niveau sur ce que les SGBDR savent bien faire.

4. Les SGBDRO
Introduction
Les SGBDRO sont ns du double constat de la puissance nouvelle promise par les SGBDOO et de
l'insuffisance de leur ralit pour rpondre aux exigences de l'industrie des BD classiques. Leur
approche est plutt d'introduire dans les SGBDR les concepts apports par les SGBDOO plutt que de
concevoir de nouveaux systmes.
Objectifs additionnels des SGBDRO :

Grer des donnes complexes (temps, go-rfrencement, multimdia, types utilisateurs, etc.)

Rapprocher le modle logique du modle conceptuel

Rduire l' impedance mismatch

B. Le modle relationnel-objet
Objectifs
Connaitre les caractristiques principales du modle relationnel-objet
Comprendre les avantages du modle relationnel-objet

1. Les SGBDRO
Dfinition : Modle relationnel-objet
Modle relationnel tendu avec des principes objet pour en augmenter les potentialits.
Synonymes : Modle objet-relationnel
Les apports principaux du modle relationnel-objet sont :

Les types utilisateurs et l'encapsulation (recours aux mthodes)

La gestion de collections

L'hritage et la rutilisation

L'identit d'objet et les rfrences physiques

2. Le modle imbriqu

nested model
La 1NF est relche pour permettre d'affecter des valeurs non atomiques un attribut, pour
modliser des objets complexes.
Gestion directe des attributs multivalus, sans passer par une nouvelle relation
Gestion directe des attributs composs
Un attribut ne sera plus seulement value par une valeur simple, mais pourra l'tre par une
collection d'objets complexes

Exemple

S. Crozat - UTC 2009

111

Le relationnel-objet

Exemple de table imbrique

3. Les types utilisateurs


Dfinition : Type de donnes utilisateur
Type de donnes cr par le concepteur d'un schma relationnel-objet, qui encapsule des donnes et des
oprations sur ces donnes. Ce concept est rapprocher de celui de classe d'objets.
Synonymes : Type utilisateur, Type de donnes abstrait

Syntaxe
Type nom_type : <
attribut1 typeattribut1,
attribut2 typeattribut2,
...
attributN typeattributN,
=methode1 (paramtres) typeretourn1,
=methode2 (paramtres) typeretourn2,
=...
=methodeN (paramtres) typeretournN
>

Remarque
Les type des attributs ou des mthodes d'un type peuvent galement tre des types utilisateurs.

Exemple : Adresse en relationnel


employe (#nom:chane, prenom:chane, ad_num:chane,
ad_rue:chane, ad_ville:chane, ad_cp:chane,
ad_ville:chane, ad_pays:chane, societe=>societe)
societe (#nom:chane, ad_num:chane, ad_rue:chane,
ad_ville:chane, ad_cp:chane, ad_ville:chane,
ad_pays:chane)

Exemple : Adresse en relationnel-objet avec type


Type adresse : <num:chane, rue:chane, ville:chane,
cp:chane, ville:chane, pays:chane>
employe (#nom:chane, prenom:chane, ad:adresse,
societe=>societe)
societe (#nom:chane, ad:adresse)

Exemple : Type adresse avec mthode


Type adresse : <
num:chane,
rue:chane,
ville:chane,
cp:chane,
ville:chane,
pays:chane,
=CPprefix() chane

112

S. Crozat - UTC 2009

Le relationnel-objet

>

Remarque : Premire forme normale


Le recours aux types utilisateurs brise une rgle de la premire forme normale, celle de l'atomicit des
valeurs d'attribut.
Ce non respect de la 1NF ne pose pas de problme car la dclaration de type permet d'accder la
structure interne des attributs composs.
Dans le modle relationnel classique, le problme du non respect de la 1NF tait bien l'opacit de la
structure interne des attributs ainsi constitus qui interdisait l'accs des sous informations extraites de la
valeur de l'attribut (par exemple un attribut comprenant le nom et le prnom ensemble interdit l'accs
l'information "nom" ou l'information "prnom" indpendamment). L'usage de type claire cette opacit
et rend ainsi le respect de l'atomicit superflu.

4. Les collections
Dfinition : Collection
Une collection est un type de donnes gnrique dfini afin de supporter les attributs multi-valus.
Synonymes : Collection d'objets

Syntaxe
Type nom_type : collection de <type_objet>

Remarque
Les objets d'une collection peuvent tre d'un type utilisateur.

Exemple : Collection d'entiers


Type liste_telephone : collection de <entier>

Exemple : Collection d'objets complexe


Type adresse : <num, rue, ville>
Type liste_adresse : collection de <adresse>

5. Comparaison relationnel et relationnel-objet


Exemple : Documents en relationnel
document (#ISBN:entier, titre:chane, soustitre:chane,
editeur:chane, annee:entier)
auteur (#id:entier, nom:chane, prenom:chane)
motscles (#document=>document, #motcle=>motcle
auteurslivres(#idauteur=>auteur, #ISBN=>document

Exemple : Documents en relationnel-objet


Type
Type
Type
Type
Type

S. Crozat - UTC 2009

titre : <titre, soustitre>


edition : <titre, soustitre>
liste_motscles : collection de <chane>
liste_auteurs : collection de <auteur>
auteur : <nom, prenom>

113

Le relationnel-objet

document (#ISBN, titre:titre, edition:edition,


motscles:liste_motscles, auteurs:liste_auteurs)

Remarque : Perte de smantique


La transformation prcdente du modle initiale, a limin l'entit auteur. La notion d'auteur n'est donc
plus qu'une proprit des livres et non un objet dfini indpendamment dans le schma de donne. Dans
le cas gnral cette modlisation ne sera pas souhaitable et on prfrera conserver l'entit auteur. Bien
entendu l'existence pralable d'un schma conceptuel permet de lever l'ambigut puisque selon que les
auteurs seront dfinis comme des entits ou bien comme des proprits de l'entit livre, le choix de
modlisation sera effectu.

Exemple : Documents et auteurs en relationnel-objet


Type titre : <titre, soustitre>
Type edition : <titre, soustitre>
Type liste_motscles : collection de <chane>
Type liste_auteurs : collection de <number>
document (#ISBN, titre:titre, edition:edition,
motscles:liste_motscles, auteurs:liste_auteurs)
auteur (#id:entier, nom:chane, prenom:chane)

Remarque : Association N:M imbrique


Dans l'exemple ci-dessus, le schma relationnel-objet a permis de se dbarrasser de la table
"auteurslivres" du modle initial et qui n'existait que pour modliser l'association N:M entre les livres et
les auteurs. Dans l'exemple ci-dessus l'utilisation d'une collection a permis de simplifier le schma en le
dbarassant de cette relation artificielle. Notons nanmoins que le fait d'avoir choisi d'imbriquer les
auteurs dans les livres (et non l'inverse qui tait galement possible) est porteur de sens tant au niveau
conceptuel (ce sont plutt les livres qui nous intressent que les auteurs), qu'au niveau oprationnel (il
sera plus facile et plus efficace de trouver les auteurs d'un livre que les livres d'un auteur).

6. Tables d'objets
Une table peut tre dfinie en rfrenant un type de donnes plutt que par des instructions LDD
classiques.
On parle alors de table d'objets.

Syntaxe
nom_table de nom_type (#attributs_cls)

Remarque : OID
Une telle dfinition de table peut permettre d'identifier les objets par un OID

Remarque : Hritage
Cette modalit de dfinition de schma permet de profiter de l'hritage de type pour permettre l'hritage
de schma de table.

7. Hritage et rutilisation de types


Dfinition : Hritage de type
Un type de donnes utilisateur peut hriter d'un autre type de donnes utilisateur.

114

S. Crozat - UTC 2009

Le relationnel-objet

Syntaxe
Type sous_type hrite de type : <
attributs et mthodes spcifiques
>

Remarque : Hritage de schma de table


Pour qu'une table hrite du schma d'une autre table, il faut dfinir les tables depuis des types.
L'hritage entre les types permet ainsi l'hritage entre les schmas de table.

8. Identification d'objets et rfrences


Le modle relationnel-objet permet de disposer d'identificateurs d'objet (OID)

Caractristiques

L'OID est une rfrence unique pour toute la base de donnes qui permet de rfrencer un
enregistrement dans une table d'objets.
L'OID est une rfrence physique (adresse disque) construit partir du stockage physique de
l'enregistrement dans la base de donnes.

Avantages

Permet de crer des associations entre des objets sans effectuer de jointure (gain de
performance).
Fournit une identit l'objet indpendamment de ses valeurs (cl artificielle).
Fournit un index de performance maximale (un seul accs disque).
Permet de garder en mmoire des identificateurs uniques dans le cadre d'une application objet, et
ainsi grer la persistance d'objets que l'on ne peut pas garder en mmoire, avec de bonnes
performances (alors que sinon il faudrait excuter des requtes SQL pour retrouver l'objet).

Inconvnient

Plus de sparation entre le niveau logique et physique.


L'adresse physique peut changer si le schma de la table change (changement de la taille d'un
champs par exemple)
Manipulation des donnes plus complexes, il faut un langage applicatif au dessus de SQL pour
obtenir, stocker et grer des OID dans des variables.

Exemple : Cadre d'usage


L'usage d'OID est pertinent dans le cadre d'applications crites dans un langage objet, manipulant un trs
grand nombre d'objets relis entre eux par un rseau d'associations complexe.
En effet si le nombre d'objets est trop grand, les objets ne peuvent tous tre conservs en mmoire vive
par l'application objet qui les manipule. Il est alors indispensable de les faire descendre et remonter en
mmoire rgulirement. Or dans le cadre d'un traitement portant sur de trs nombreux objets, la remont
en mmoire d'un objet est un point critique en terme de performance. A fortiori si l'identification de
l'objet remonter demande une interrogation complexe de la BD, travers de nombreuses jointures. Le
fait d'avoir conserv en mmoire un OID permet de retrouver et de recharger trs rapidement un objet,
sans avoir le rechercher travers des requtes SQL comportant des jointures et donc trs couteuses en
performance.

Remarque : Dbat
la communaut des BD est plutt contre les OID, qui rompent avec la sparation entre manipulation
logique et stockage physique des donnes.
La communaut objet est l'origine de l'intgration des OID dans SQL3, en tant qu'ils sont une rponse

S. Crozat - UTC 2009

115

Le relationnel-objet

au problme de persistance dans les applications objets.

Syntaxe : Rfrence en utilisant l'OID


Dans une dfinition de table ou de type :
attribut REF nom_table_d_objets

C. Le passage conceptuel vers relationnel-objet


Objectifs
Savoir dduire un modle logique relationnel-objet depuis un modle
conceptuel E-A ou UML.
Intgrer les apports du modle relationnel-objet par rapport au relationnel
dans ce processus.

Cette partie permet de traiter la traduction d'un modle conceptuel UML ou E-A en modle
relationnel-objet. Le modle E-A tendu est bien plus adapt au relationnel-objet que le modle E-A
classique.

1. Classe
Pour chaque classe (ou entit), crer un type d'objet avec les attributs de la classe (ou entit).
Crer une table d'objets de ce type pour instancier la classe (ou entit), en ajoutant les contraintes
d'intgrit.

Remarque : Table d'objet


La fait d'instancier la classe (l'entit) via une table d'objets plutt qu'une relation classique, permet l'accs
l'hritage de type, l'implmentation des mthodes et ventuellement l'usage d'OID la place de
cls trangres classiques.
Si aucun de ces aspects n'est utilis, il est possible d'instancier directement la classe (l'entit) en table.
Mais le passage par un type est a priori plus systmatique.

Remarque : Mapping des mthodes


Si le modle conceptuel autorise l'expression de mthodes (UML ou extension de E-A), alors on
ajoute la dfinition de ces mthodes sur le type d'objet cr pour de chaque classe (ou entit).

2. Attributs
Attributs composites
Pour chaque type d'attribut compos, crer un type d'objet.

Attributs multi-valus
Pour chaque attribut multi-valu crer une collection du type de cet attribut.

Remarque : Attributs composites multi-valus


Si l'attribut multi-valu est composite, alors crer une collection d'objets.

116

S. Crozat - UTC 2009

Le relationnel-objet

Attributs drivs
Pour chaque attribut driv crer une mthode associe au type d'objet de la classe (l'entit).

3. Association 1:N
Les associations 1:N sont gres comme en relationnel.
On peut nanmoins favoriser l'usage d'objets pour les cls trangres composes de plusieurs attributs,
ainsi que pour les attributs migrants de l'association vers le relation ct N.
Il est aussi possible de grer la cl trangre avec un OID la place d'une cl trangre classique.

4. Association N:M
Les associations N:M peuvent tre gres comme en relationnel.
Il est aussi possible de grer ces relations, en utilisant une collection de rfrences (une collection de cls
trangres) (NB : on favorise ainsi une des deux relations).
Il est aussi possible de grer ces relations en utilisant un OID comme cl trangre.
Il est aussi possible de grer ces relations en utilisant une collection de rfrence OID.

Remarque : Collection de cls trangres


Oracle n'autorise pas ( ma connaissance ...) la spcification de contraintes d'intgrit rfrentielle dans
une table imbrique. Ce qui limite l'utilisation de telles tables pour grer des relations N:M avec des
collections de cls trangres.
Par contre cela fonctionne avec des rfrences des OID.

5. Hritage
L'hritage est gr comme en relationnel classique, avec la possibilit de profiter de l'hritage de type
pour liminer la redondance dans la dfinition des schmas.

D. SQL3 (implmentation Oracle 9i)


Objectifs
Connaitre l'extension du LDD, et en particulier les types abstrait, les
relations imbriques et l'hritage.
Connaitre l'extension du LMD pour naviguer dans les objets manipuls.

1. Les nouveaux types de donnes


SQL3 introduit de nouveaux types de donnes :

Large Object (CLOB and BLOB)

Boolean

Array

Row

2. Les types de donnes abstraits


S. Crozat - UTC 2009

117

Le relationnel-objet

Implmentation des types utilisateurs.

Syntaxe : Dclaration de type de donnes


CREATE TYPE nom_type AS OBJECT (
nom_attribut1 type_attribut1
...
MEMBER FUNCTION nom_fonction1 (parametre1 IN|OUT
type_parametre1, ...) RETURN type_fonction1
...
) [NOT FINAL];
CREATE TYPE BODY nom_type
IS
MEMBER FUNCTION nom_fonction1 (...) RETURN type_fonction1
IS
BEGIN
...
END
MEMBER FUNCTION nom_fonction2 ...
...
END

Syntaxe : Hritage de type


CREATE TYPE sous_type UNDER sur_type (
Dclarations spcifiques ou surcharges
)

Remarque : NOT FINAL


Pour tre "hritable", un type doit tre dclar avec la clause optionnelle NOT FINAL.

3. Mthodes et SELF
SELF
Lorsque l'on crit une mthode on a gnralement besoin d'utiliser les attributs propres (voire d'ailleurs
les autres mthode), de l'objet particulier que l'on est en train de manipuler.
On utilise pour cela la syntaxe SELF qui permet de faire rfrence l'objet en cours.

Syntaxe : SELF
self.nom_attribut
self.nom_mthode(...)

Exemple : Total d'une facture


MEMBER FUNCTION total RETURN number
IS
t number;
BEGIN
SELECT sum(f.qte) INTO t
FROM facture f
WHERE f.num=self.num;
RETURN t;
END total;

118

S. Crozat - UTC 2009

Le relationnel-objet

Remarque : SELF implicite


Dans certains cas simples, lorsqu'il n'y a aucune confusion possible, SELF peut tre ignor et le nom de
l'attribut ou de la mthode directement utilis.
Il est toutefois plus systmatique et plus clair de mettre explicitement le self.

Exemple : Exemple de SELF implicite


MEMBER FUNCTION adresse RETURN varchar2
IS
BEGIN
RETURN num || rue || ville;
END;

4. Nested tables
Implmentation des collections sous forme de tables imbriques.

Syntaxe : Dclaration de type de donnes


--Cration d'un type abstrait d'objet
CREATE TYPE nom_type AS OBJECT (...);
-- Dclaration d'un type abstrait de collection
CREATE TYPE liste_nom_type AS TABLE OF nom_type;
-- Dclaration d'une table imbriquant une autre table
CREATE TABLE nom_table_principale (
nom_attribut type_attribut,
...
nom_attribut_table_imbrique liste_nom_type,
...
)
NESTED TABLE nom_attribut_table_imbrique STORE AS
nom_table_stockage;

5. Tables d'objets
Implmentation d'une dfinition de table depuis un type.

Syntaxe : Dclaration de type de donnes


CREATE TABLE nom_table_principale OF nom_type (
PRIMARY KEY(attribut1),
attribut2 NOT NULL,
UNIQUE (attribut3)
FOREIGN KEY (attribut4) REFERENCES ...
);

Remarque : Mthodes
Si le type sur lequel s'appuie la cration de la table dfinit des mthodes, alors les mthodes seront
associes la table.

Remarque : Contraintes
Il est possible, sur une table ainsi dfinie, de spcifier les mmes contraintes que pour une table cre

S. Crozat - UTC 2009

119

Le relationnel-objet

avec une clause CREATE TABLE (contraintes de table). Ces contraintes doivent tre spcifies au
moment de la cration de la table, et non au moment de la cration du type. (bien que la dfinition d'objet
permet de spcifier des contraintes du type NOT NULL, etc.)

6. Insertion d'objets
La manipulation de donnes est tendue pour assurer la gestion des objets et des collections.

Remarque : Constructeur d'objet


Pour tout type d'objet est automatiquement cre une mthode de construction, dont le nom est celui du
type et les arguments les attributs du type.

Syntaxe : Insertion d'objets


INSERT INTO nom_table (..., attribut_type_objet, ...)
VALUES
(..., nom_type(valeur1, valeur2, ...), ...);

Syntaxe : Insertion de collections d'objets


INSERT INTO nom_table (..., attribut_type_collection, ...)
VALUES (
...
nom_type_collection(
nom_type_objet(valeur1, valeur2, ...),
nom_type_objet(valeur1, valeur2, ...),
...);
...
);

7. Insertion de collections partir de requtes SELECT


Les constructeurs d'objets sont utilisables dans les instructions de type INSERT ... VALUES, mais
ne peuvent tre utiliss dans les instructions de type INSERT ... SELECT. Pour ces dernires une
autre mthode de construction est ncessaire.

Syntaxe : Insrer une collection d'objets depuis une table


Soient les tables tro et t dfinies par le schma RO ci-aprs.
type col : collection de <string>
tro(a_obj:col)
t(a:string)
L'instruction suivante permet d'insrer le contenu de l'attribut a pour tous les enregistrements de t dans
un seul attribut a_obj d'un seul enregistrement de tro sous la forme d'une collection.
INSERT INTO tro (a_objet)
VALUES (CAST(MULTISET(SELECT a FROM t ) AS col));

L'instruction CAST (...) AS <type> permet de renvoyer un type donn partir d'une
expression.
L'instruction MULTISET (...) permet de renvoyer une collection partir d'une liste de
valeurs.

Mthode : Approche gnrale


Soit la table tro dfinie par le schma RO ci-aprs. Elle contient un attribut cl (pk_id) et un attribut

120

S. Crozat - UTC 2009

Le relationnel-objet

qui est une collection (a_obj).


type col : collection de <string>
tro(#pk_id:string, a_obj:col)
Soit la table tr dfinie par le schma relationnel ci-aprs.
tr(a:string, b:string)
a1

b1

a1

b2

a1

b3

a2

b4

a2

b5
Tableau 15 Extrait de tr

Si l'on souhaite insrer le contenu de tr dans tro de telle faon que les valeurs de a correspondent
pk_id et celles de b obj_a, en insrant une ligne pour chaque valeur ax et que tous les bx
correspondant soient stocks dans la mme collection, il faut excuter une requte INSERT ...
SELECT qui fait appel aux instructions CAST et MULTISET.
INSERT INTO tro (pk_id, a_obj)
SELECT
a,
CAST(
MULTISET(
SELECT b
FROM tr tr1
WHERE tr1.a= tr2.a)
AS col)
FROM tr tr2;
a1
a2

(b1, b2, b3)


(b4, b5)
Tableau 16 Extrait de tro aprs excution de la requte INSERT

8. Slection dans des objets


Syntaxe : Accs aux attributs des objets
SELECT alias_table.nom_objet.nom_attribut
FROM nom_table AS alias_table

Syntaxe : Accs aux mthodes des objets


SELECT alias_table.nom_objet.nom_mthode(paramtres)
FROM nom_table AS alias_table

Remarque : Alias obligatoire


L'accs aux objets se fait obligatoirement en prfixant le chemin d'accs par l'alias de la table et non
directement par le nom de la table.

S. Crozat - UTC 2009

121

Le relationnel-objet

9. Slection dans des tables imbriques


Syntaxe : Accs aux tables imbriques
Soit "nt" une table imbrique dans la table "t".
SELECT t2.*
FROM t t1, TABLE(t1.nt) t2;

Remarque : Jointure avec la table imbrique


La jointure entre la table principale et sa table imbrique est implicitement ralise, il n'est pas besoin de
la spcifier.

Remarque : Accs la colonne d'une table imbrique de scalaires


Lorsque la table imbrique est une table de type scalaire (et non une table d'objets d'un type utilisateur),
alors la colonne de cette table n'a pas de nom (puisque le type est scalaire la table n'a qu'une colonne).
Pour accder cette colonne, il faut utiliser la syntaxe ddie :
COLUMN_VALUE

Exemple : Nested table pour grer une collection de cls trangres


Soit la gestion de deux relations pour grer des livres et des auteurs, avec une relation N:M entre elles. On
dcide de grer cette relation par une collection de cls trangres dans la table des livres.
CREATE TABLE tAuteur (
Id integer PRIMARY KEY,
Nom char(20),
Prenom char(20));
CREATE TYPE ListeFkAuteur AS TABLE OF integer;
CREATE TABLE tLivre (
Titre char(20) PRIMARY KEY,
fkAuteurs ListeFkAuteur
) NESTED TABLE fkAuteurs STORE AS tLivresAuteurs;
INSERT INTO tAuteur VALUES (1, 'Merle', 'Robert');
INSERT INTO tAuteur VALUES (2, 'Barjavel', 'Ren');
INSERT INTO tLivre VALUES ('Malvil', ListeFkAuteur(1, 2));
SELECT t1.Titre, t2.COLUMN_VALUE
FROM tLivre t1, TABLE(t1.fkAuteurs) t2;
TITRE COLUMN_VALUE
----------------------------Malvil 1
Malvil 2
SELECT t1.Titre, t3.Nom
FROM tLivre t1, TABLE(t1.fkAuteurs) t2, tAuteur t3
WHERE t2.COLUMN_VALUE=t3.Id;
TITRE NOM
----------------------------Malvil Merle
Malvil Barjavel

122

S. Crozat - UTC 2009

Le relationnel-objet

10. Manipulation d'OID


Une table d'objets, i.e. cre depuis un type, dispose d'un OID pour chacun de ses tuples.
Cet OID est accessible depuis la syntaxe REF dans une requte SQL.

Syntaxe : REF
SELECT REF(alias)
FROM nom_table alias

Exemple : OID
0000280209DB703686EF7044A49F8FA67530383B36853DE7106BC74B678
1275ABE5A553A5F01C000340000

Syntaxe : Cl trangre par l'OID


CREATE TYPE type_objet AS OBJECT ...
CREATE TABLE table1 OF type_objet ...
CREATE TABLE table2 (
...
cl_trangre REF type_objet,
SCOPE FOR (cl_trangre) IS table1,
);

Remarque : SCOPE FOR


Renforce l'intgrit rfrentielle en limitant la porte de la rfrence une table particulire (alors que
REF seul permet de pointer n'importe quel objet de ce type)

Syntaxe : Insertion de donnes en SQL


INSERT INTO table1 (champs1, ..., cl_trangre)
SELECT 'valeur1', ..., REF(alias)
FROM table2 alias
WHERE cl_table2='valeur';

Syntaxe : Insertion de donnes en PL/SQL


DECLARE
variable REF type_objet;
BEGIN
SELECT REF(alias) INTO variable
FROM table2 alias
WHERE cl_table2='valeur';
INSERT INTO tCours (champs1, ..., cl_trangre)
VALUES ('valeur1', ..., variable);
END;

Syntaxe : Navigation d'objets


La rfrence par OID permet la navigation des objets sans effectuer de jointure, grce la syntaxe
suivante :
SELECT t.cl_trangre.attribut_table2

S. Crozat - UTC 2009

123

Le relationnel-objet

FROM table1 t;

E. Exemples RO
1. Exemple : Gestion de cours
a) Modle conceptuel

Modle conceptuel en UML

b) Modle logique
Type Bureau : <
poste:entier,
centre:chane,
btiment:chane,
numro:entier,
=coordonnes():chane
>
Type Personne : < nom:chane, prnom:chane >
Type Intervenant hrite de Personne : < bureau:Bureau >
tIntervenant de Intervenant (#nom, #prnom)
Type RefIntervenant : <nom:chane, prnom:chane>
Type ListeRefIntervenants: collection de <RefIntervenant>
Type Cours(semestre:chane, num:entier, titre:chane,
type:enum, contenu:chane,

124

S. Crozat - UTC 2009

Le relationnel-objet

lIntervenant:ListeRefIntervenant)
tCours de Cours (#semestre, #num)

Remarque : Mthode coordonnes()


On a choisi de mettre la mthode coordonnes au niveau du type Bureau plutt que du type Personne,
pour augmenter les possibilits de rutilisabilit (car d'autres entits que Intervenant pourraient utiliser le
type Bureau). C'est une possibilit offerte par le fait que les attributs composs donnent naissance des
types utilisateurs (on dcide donc de remonter certaines mthodes qui ne concerne que cet attribut
compos au niveau de ce type).

c) Implmentation
CREATE TYPE Bureau AS OBJECT (
poste number(4),
centre char(2),
batiment char(1),
numero number(3),
MEMBER FUNCTION coordonnees RETURN varchar2
);
CREATE TYPE BODY Bureau
IS
MEMBER FUNCTION coordonnees RETURN varchar2
IS
BEGIN
RETURN centre||batiment||numero||' - poste '||poste;
END;
END;
CREATE TYPE Personne AS OBJECT(
pkNom varchar2(50),
pkPrenom varchar2(50)
) NOT FINAL ;
CREATE TYPE Intervenant UNDER Personne (
aBureau Bureau
);
CREATE TABLE tIntervenant OF Intervenant (
PRIMARY KEY(pkNom,pkPrenom)
);
CREATE TYPE RefIntervenant AS OBJECT (
nom varchar2(50),
prenom varchar2(50)
);
CREATE TYPE ListeRefIntervenants AS TABLE OF
RefIntervenant;
CREATE TYPE Cours AS OBJECT(
pkSemestre char(5),
pkNum number(2),
aTitre varchar2(50),
aType char(2),
aContenu varchar2(300),
lIntervenant ListeRefIntervenants
);

S. Crozat - UTC 2009

125

Le relationnel-objet

CREATE TABLE tCours OF Cours (


PRIMARY KEY(pkSemestre, pkNum),
CHECK (aType='C' or aType='TD' or aType='TP')
)
NESTED TABLE lIntervenant STORE AS ntCoursIntervenants;

d) Initialisation
INSERT INTO tIntervenant VALUES ('CROZAT', 'Stphane',
Bureau('4287','R','A',108));
INSERT INTO tIntervenant VALUES ('JOUGLET', 'Antoine',
Bureau('4423','R','C',100));
INSERT INTO tCours VALUES ('P2003',1,'Conception','C','E-A
et UML',
ListeRefIntervenants(RefIntervenant('CROZAT','Stphane')));
INSERT INTO tCours VALUES
('P2003',5,'Access','TP','Initiation',
ListeRefIntervenants(RefIntervenant('CROZAT','Stphane'),
RefIntervenant('JOUGLET','Antoine')));

e) Questions
SET LINESIZE 60
SET PAGESIZE 10
COLUMN Quand FORMAT A5
COLUMN Quoi FORMAT A10
COLUMN Qui FORMAT A20
COLUMN Ou FORMAT A19
SELECT t.pkNom||' '||t.pkPrenom AS Qui,
t.aBureau.coordonnees() AS Ou
FROM tIntervenant t;
QUI OU
------------------------------------CROZAT Stphane R A108 - poste 4287
JOUGLET Antoine R C100 - poste 4423
SELECT c.pkSemestre AS Quand,c.aTitre AS Quoi,ci.Nom AS Qui
FROM tCours c, TABLE(c.lIntervenant) ci;
QUAND QUOI QUI
-----------------------------P2003 Conception CROZAT
P2003 Access CROZAT
P2003 Access JOUGLET
SELECT c.pkSemestre AS Quand,c.aTitre AS Quoi,i.pkNom AS
Qui,i.aBureau.coordonnees() AS Ou
FROM tCours c, TABLE(lIntervenant) ci, tIntervenant i
WHERE ci.nom=i.pkNom AND ci.prenom=i.pkPrenom;
QUAND QUOI QUI OU
-------------------------------------------------

126

S. Crozat - UTC 2009

Le relationnel-objet

P2003 Conception CROZAT R A108 - poste 4287


P2003 Access CROZAT R A108 - poste 4287
P2003 Access JOUGLET R C100 - poste 4423

2. Exemple : Gestion de cours simplifie (version avec OID)


a) Modle conceptuel

Modle conceptuel en UML

b) Modle logique
Type Intervenant : < nom:chane, prnom:chane >
tIntervenant de Intervenant (#nom)
Type Cours(num:entier, titre:chane, fkIntervenant REF
tIntervenant)
tCours de Cours (#num)

c) Implmentation
CREATE TYPE Intervenant AS OBJECT (
pkNom varchar2(50),
aPrenom varchar2(50)
);
CREATE TABLE tIntervenant OF Intervenant (PRIMARY KEY
(pkNom));
CREATE TYPE Cours AS OBJECT (
pkNum number(2),
aTitre varchar2(50),
fkIntervenant REF Intervenant
);
CREATE TABLE tCours OF Cours (
SCOPE FOR (fkIntervenant) IS tIntervenant,
PRIMARY KEY(pkNum)
);

d) Initialisation de la table d'objets tIntervenant


INSERT INTO tIntervenant
VALUES ('CROZAT', 'Stphane');

S. Crozat - UTC 2009

127

Le relationnel-objet

e) Insertion de donnes dans la table d'objets tCours (SQL)


INSERT INTO tCours
SELECT 2, 'Modlisation', REF(i)
FROM tIntervenant i
WHERE pkNom='CROZAT';

f) Insertion de donnes dans la table tCours (PL/SQL)


DECLARE
ri REF Intervenant;
BEGIN
SELECT REF(i) INTO ri
FROM tIntervenant i
WHERE i.pkNom='CROZAT';
INSERT INTO tCours
VALUES (1,'Conception',x);
END;

g) Slection : Cl trangre sous forme d'OID


SELECT * FROM tCours;
PKNUM ATITRE FKINTERVENANT
----------------------------------------------------------1 Conception
0000220208DE4BD8F3191044589847E31E64B83EBB5807280A335B44C4A
D958EDF20D185B5
2 Modlisation
0000220208DE4BD8F3191044589847E31E64B83EBB5807280A335B44C4A
D958EDF20D185B5

h) Slection : Jointure sur l'OID


Contre-exemple : ce qu'il ne faut pas faire !
SELECT c.pkNum, i.pkNom
FROM tCours c, tIntervenant i
WHERE c.fkIntervenant=REF(i);
PKNUM PKNOM
------------------------1 CROZAT
2 CROZAT

i) Slection : Navigation d'objets


SELECT pkNum, c.fkIntervenant.pkNom
FROM tCours c
PKNUM PKNOM
------------------------1 CROZAT
2 CROZAT

128

S. Crozat - UTC 2009

Le relationnel-objet

F. En rsum : Le relationnel-objet
Types

Pr-dfinis
Domaines classiques
Chane, Entier, Date, Boolen, etc.
Domaines avancs
CLOB, BLOB, etc.
Dfinis par l'utilisateur
Relation
Comme dans le modle relationnel classique
Objets
Types utilisateurs
Collections
Tables imbriques

Modle RO

Modle imbriqu
Table d'objets
CREATE TYPE
CREATE TABLE OF
Collection
NESTED TABLE
Type utilisateur
OID
REF
SCOPE FOR
Hritage de type
NOT FINAL
Mthode
MEMBER FUNCTION
CREATE TYPE BODY

G. Bibliographie commente sur le relationnel-objet


Complment : Synthse SQL3 sous Oracle 8i
SQL2 SQL3, applications Oracle [Delmal01]
On consultera les chapitre 11 et 12 pour avoir une description des extensions SQL3 et de ses
implmentations et extensions sous Oracle (version 8i).

S. Crozat - UTC 2009

129

VII -

LA GESTION DES

TRANSACTIONS

VII

Problmatique des pannes et de la concurrence

165

Transactions

166

Fiabilit et transactions

169

Concurrence et transactions

174

En rsum : Les transactions

181

Bibliographie commente sur les transactions

182

Les transactions sont une rponse gnrale aux problmes de fiabilit et d'accs concurrents dans les BD,
et en particulier dans les BD en mode client-serveur. Elles sont le fondement de toute implmentation
robuste d'une BD. Des systmes comme Oracle ne fonctionnent nativement qu'en mode transactionnel.

A. Problmatique des pannes et de la concurrence


Une BD est un ensemble persistant de donnes organises qui a en charge la prservation de la
cohrence de ces donnes. Les donnes sont cohrentes si elles respectent l'ensemble des contraintes
d'intgrit spcifies pour ces donnes : contraintes de domaine, intgrit rfrentielle, dpendances
fonctionnelles, etc.
La cohrence des donnes peut tre remise en cause par deux aspects de la vie d'une BD :

La dfaillance
Lorsque le systme tombe en panne alors qu'un traitement est en cours, il y a un risque qu'une
partie seulement des instructions prvues soit excute, ce qui peut conduire des incohrences.
Par exemple pendant une mise jour en cascade de cls trangres suite au changement d'une cl
primaire.

La concurrence
Lorsque deux accs concurrents se font sur les donnes, il y a un risque que l'un des deux accs
rende l'autre incohrent. Par exemple si deux utilisateurs en rseau modifient une donne au
mme moment, seule une des deux mises jour sera effectue.
La gestion de transactions par un SGBD est la base des mcanismes qui permettent d'assurer le
maintien de la cohrence des BD. C'est dire encore qu'il assure que tous les contraintes de la BD seront
toujours respectes, mme en cas de panne et mme au cours d'accs concurrents.

S. Crozat - UTC 2009

131

La gestion des transactions

B. Transactions
Objectifs
Comprendre les principes et l'intrt des transactions
Connatre les syntaxes SQL standard, Oracle et Access pour utiliser des
transactions
Matriser les modalits d'utilisation des transactions

1. Notion de transaction
Dfinition : Transaction
Une transaction est une unit logique de travail, c'est dire une squence d'instructions, dont l'excution
assure le passage de la BD d'un tat cohrent un autre tat cohrent.

Fondamental : Cohrence des excutions incorrectes


La transaction assure le maintien de la cohrence des donnes que son excution soit correcte ou
incorrecte.

Exemple : Exemples d'excutions incorrectes


L'excution d'une transaction peut tre incorrecte parce que :

Une panne a lieu

Un accs concurrent pose un problme

Le programme qui l'excute en a dcid ainsi

2. Droulement d'une transaction


1. DEBUT
2. TRAITEMENT
Accs aux donnes en lecture
Accs aux donnes en criture
3. FIN
Correcte : Validation des modifications
Incorrecte : Annulation des modifications

Remarque
Tant qu'une transaction n'a pas t termine correctement, elle doit tre assimile une tentative ou une
mise jour virtuelle, elle reste incertaine. Une fois termine correctement la transaction ne peut plus tre
annule par aucun moyen.

3. Proprits ACID d'une transaction


Une transaction doit respecter quatre proprits fondamentales :

L'atomicit
Les transactions constituent l'unit logique de travail, toute la transaction est excute ou bien
rien du tout, mais jamais une partie seulement de la transaction.

La cohrence
Les transactions prservent la cohrence de la BD, c'est dire qu'elle transforme la BD d'un
tat cohrent un autre (sans ncessairement que les tats intermdiaires internes de la BD au

132

S. Crozat - UTC 2009

La gestion des transactions

cours de l'excution de la transaction respectent cette cohrence)


L'isolation
Les transactions sont isoles les unes des autres, c'est dire que leur excution est indpendante
des autres transactions en cours. Elles accdent donc la BD comme si elles taient seules
s'excuter, avec comme corollaire que les rsultats intermdiaires d'une transaction ne sont
jamais accessibles aux autres transactions.
La durabilit
Les transactions assurent que les modifications qu'elles induisent perdurent, mme en cas de
dfaillance du systme.

Remarque
Les initiales de Atomicit, Cohrence, Isolation et Durabilit forme le mot mnmotechnique ACID.

4. Transactions en SQL
Introduction
Le langage SQL fournit trois instructions pour grer les transactions.

Syntaxe : Dbut d'une transaction


BEGIN TRANSACTION
Cette syntaxe est optionnelle (voire inconnue de certains SGBD), une transaction tant dbute de
faon implicite ds qu'instruction est initie sur la BD.

Syntaxe : Fin correcte d'une transaction


COMMIT TRANSACTION (ou COMMIT)
Cette instruction SQL signale la fin d'une transaction couronne de succs. Elle indique donc au
gestionnaire de transaction que l'unit logique de travail s'est termine dans un tat cohrent est que les
donnes peuvent effectivement tre modifies de faon durable.

Syntaxe : Fin incorrecte d'une transaction


ROLLBACK TRANSACTION (ou ROLLBACK)
Cette instruction SQL signale la fin d'une transaction pour laquelle quelque chose s'est mal pass. Elle
indique donc au gestionnaire de transaction que l'unit logique de travail s'est termine dans un tat
potentiellement incohrent et donc que les donnes ne doivent pas tre modifies en annulant les
modifications ralises au cours de la transaction.

Remarque : Programme
Un programme est gnralement une squence de plusieurs transactions.

5. Exemple de transaction sous Oracle


Exemple : Exemple basique en SQL
INSERT INTO t1 (a,b) VALUES (1,1);
COMMIT;

Exemple : Exemple de gestion de compte toujours positif sur Oracle en PL/SQL


DECLARE
vTotal number;

S. Crozat - UTC 2009

133

La gestion des transactions

BEGIN
UPDATE compte
SET total=total-1000
WHERE nom="dupont";
SELECT total INTO vTotal
FROM compte
WHERE nom="dupont";
IF vTotal<0 THEN
ROLLBACK;
ELSE
COMMIT;
END IF;
END;

6. Exemple de transaction sous Access


Exemple : Exemple de transfert financier sous Access
Sub Transaction
BeginTrans
CurrentDb.CreateQueryDef("", "UPDATE Compte1 SET
Solde=Solde+100 WHERE Num=1").Execute
CurrentDb.CreateQueryDef("", "UPDATE Compte2 SET
Solde=Solde-100 WHERE Num=1").Execute
CommitTrans
End Sub

Remarque : VBA et transactions


Sous Access, il n'est possible de dfinir des transactions sur plusieurs objets requtes qu'en VBA.

Remarque : Transactions automatique sous Access


Sous Access, toute requte portant sur plusieurs lignes d'une table est (sauf paramtrage contraire)
encapsule dans une transaction.
Ainsi par exemple la requte "UPDATE Compte SET Solde=Solde*6,55957" est excute dans une
transaction et donc, soit toutes les lignes de la table Compte seront mises jour, soit aucune.

7. Journal des transactions


Dfinition : Journal
Le journal est un fichier systme qui constitue un espace de stockage redondant avec la BD. Il
rpertorie l'ensemble des mises jour faites sur la BD (en particulier les valeurs des enregistrements avant
et aprs mise jour). Le journal est donc un historique persistant (donc en mmoire secondaire) qui
mmorise tout ce qui se passe sur la BD.
Le journal est indispensable pour la validation (COMMIT), l'annulation (ROLLBACK) et la reprise aprs
panne de transactions.
Synonymes : Log

134

S. Crozat - UTC 2009

La gestion des transactions

C. Fiabilit et transactions
Objectifs
Apprhender la gestion des pannes dans les SGBD.
Comprendre la rponse apporte par la gestion des transactions.

1. Les pannes
Une BD est parfois soumise des dfaillances qui entranent une perturbation, voire un arrt, de son
fonctionnement.
On peut distinguer deux types de dfaillances :

Les dfaillances systme


ou dfaillances douces (soft crash), par exemple une coupure de courant ou une panne rseau.
Ces dfaillances affectent toutes les transactions en cours de traitement, mais pas la BD au sens
de son espace de stockage physique.

Les dfaillances des supports


ou dfaillances dures (hard crash), typiquement le disque dur sur lequel est stocke la BD. Ces
dfaillances affectent galement les transactions en cours (par rupture des accs aux
enregistrements de la BD), mais galement les donnes elles-mmes.

Remarque : Annulation des transactions non termines


Lorsque le systme redmarre aprs une dfaillance, toutes les transactions qui taient en cours
d'excution (pas de COMMIT) au moment de la panne sont annuls (ROLLBACK impos par le
systme). Cette annulation assure le retour un tat cohrent, en vertu des proprits ACID des
transactions.

Remarque : R-excution des transactions termines avec succs


Au moment de la panne certaines transactions taient peut-tre termines avec succs (COMMIT) mais
non encore (ou seulement partiellement) enregistres dans la BD (en mmoire volatile, tampon, etc.).
Lorsque le systme redmarre il doit commencer par rejouer ces transactions, qui assurent un tat
cohrent de la BD plus avanc.
Cette reprise des transactions aprs COMMIT est indispensable dans la mesure o c'est bien l'instruction
COMMIT qui assure la fin de la transaction et donc la durabilit. Sans cette gestion, toute transaction
pourrait tre remise en cause.

Remarque : Unit de reprise


Les transactions sont des units de travail, et donc galement de reprise.

Remarque : Dfaillance des supports


Tandis que la gestion de transactions et de journal permet de grer les dfaillances systmes, les
dfaillances des supports ne pourront pas toujours tre grs par ces seuls mcanismes. Il faudra leur
adjoindre des procdures de sauvegarde et de restauration de la BD pour tre capable au pire de revenir
dans un tat antrieur cohrent et au mieux de rparer compltement la BD (cas de la rplication en temps
rel par exemple).

2. Point de contrle
Dfinition : Point de contrle
Un point de contrle est une criture dans le journal positionne automatiquement par le systme qui
S. Crozat - UTC 2009

135

La gestion des transactions

tablit la liste de toutes les transactions en cours (au moment o le point de contrle est pos) et force la
sauvegarde des donnes alors en mmoire centrale dans la mmoire secondaire.
Le point de contrle est positionn intervalles de temps ou de nombre d'entres dans le journal
prdfinis.
Le dernier point de contrle est le point de dpart d'une reprise aprs panne, dans la mesure o c'est le
dernier instant o toutes les donnes ont t sauvegardes en mmoire non volatile.
Synonymes : Syncpoint

3. Reprise aprs panne


Introduction
Le mcanisme de reprise aprs panne s'appuie sur le journal et en particulier sur l'tat des transactions au
moment de la panne et sur le dernier point de contrle.
Le schma ci-aprs illustre les cinq cas de figure possibles pour une transaction au moment de la panne.

tats d'une transaction au moment d'une panne

136

Transactions de type T1
Elles ont dbut et se sont termines avant tc. Elles n'interviennent pas dans le processus de
reprise.
Transactions de type T2
Elles ont dbut avant tc et se sont termines entre tc et tf. Elles devront tre rejoues (il n'est pas
sr que les donnes qu'elles manipulaient aient t correctement inscrites en mmoire centrale,
puisque aprs tc, or le COMMIT impose la durabilit).
Transactions de type T3
S. Crozat - UTC 2009

La gestion des transactions

Elles ont dbut avant tc, mais n'tait pas termines tf. Elles devront tre annules (pas de
COMMIT).
Transactions de type T4
Elles ont dbut aprs tc et se sont termines avant tf. Elles devront tre rejoues.
Transactions de type T5
Elles ont dbut aprs tc et ne se sont pas termines. Elles devront tre annules.

Remarque
Les transactions sont des units d'intgrit.

4. Algorithme de reprise UNDO-REDO.


Introduction
L'algorithme suivant permet d'assurer une reprise aprs panne qui annule et rejoue les transactions
adquates.
1. SOIT deux listes
1a. Initialiser la
1b. Initialiser la
en cours au dernier

REDO et UNDO
liste REDO vide
liste UNDO avec toutes les transactions
point de contrle

2. FAIRE une recherche en avant dans le journal, partir


du point de contrle
2a. SI une transaction T est commence ALORS ajouter T
UNDO
2b. SI une transaction T est termine avec succs alors
dplacer T de UNDO REDO
3. QUAND la fin du journal est atteinte
3a. Annuler les transactions de la liste UNDO (reprise en
arrire)
3b. Rejouer les transactions de la liste REDO (reprise en
avant)
4. TERMINER la reprise et redevenir disponible pour de
nouvelles instructions

Exemple

S. Crozat - UTC 2009

137

La gestion des transactions

tats d'une transaction au moment d'une panne

Transactions de type T1
Non prises en compte par l'algorithme.
Transactions de type T2
Ajoutes la liste UNDO (tape 1b) puis dplace vers REDO (tape 2b) puis rejoue (tape
3b).
Transactions de type T3
Ajoutes la liste UNDO (tape 1b) puis annule (tape 3a).
Transactions de type T4
Ajoutes la liste UNDO (tape 2a) puis dplace vers REDO (tape 2b) puis rejoue (tape
3b).
Transactions de type T5
Ajoutes la liste UNDO (tape 2a) puis annule (tape 3a).

5. Ecriture en avant du journal.


Fondamental
On remarquera que pour que la reprise de panne soit en mesure de rejouer les transactions, la premire
action que doit effectuer le systme au moment du COMMIT est l'criture dans le journal de cette fin
correcte de transaction. En effet ainsi la transaction pourra tre rejoue, mme si elle n'a pas eu le temps
de mettre effectivement jour les donnes dans la BD, puisque le journal est en mmoire secondaire.

138

S. Crozat - UTC 2009

La gestion des transactions

* *
*

On voit que la gestion transactionnelle est un appui important la reprise sur panne, en ce qu'elle assure
des tats cohrents qui peuvent tre restaurs.

D. Concurrence et transactions
Objectifs
Apprhender la gestion de la concurrence dans les SGBD.
Comprendre la rponse apporte par la gestion des transactions.

1. Trois problmes soulevs par la concurrence.


Introduction
Nous proposons ci-dessous trois problmes poss par les accs conccurents des transactions aux donnes.

a) Perte de mise jour


Temps

TransactionA

TransactionB

t1

LIRET

t2

...

LIRET

t3

UPDATET

...

t4

...

UPDATET

t5

COMMIT

...

t4

COMMIT

Tableau 17 Problme de la perte de mise jour du tuple T par la transaction A


Les transaction A et B accdent au mme tuple T ayant la mme valeur respectivement t1 et t2. Ils
modifient chacun la valeur de T. Les modifications effectues par A seront perdues puisqu'elle avait lu T
avant sa modification par B.

Exemple

S. Crozat - UTC 2009

139

La gestion des transactions


Temps
t1
t2
t3
t4
t5

A:Ajouter100

B:Ajouter10

LIRECOMPTE
C=1000
...

LIRECOMPTE
C=1000

UPDATECOMPTE
C=C+100=1100

...

...

UPDATECOMPTE
C=C+10=1010

COMMIT
C=1100

...
COMMIT
C=1010

t6

Tableau 18 Doucle crdit d'un compte bancaire C


Dans cet exemple le compte bancaire vaut 1010 la fin des deux transactions la place de 1110.

b) Accs des donnes non valides


Temps

TransactionA

t1
t2

TransactionB
UPDATET

LIRET

...

t3

ROLLBACK

Tableau 19 Problme de la lecture impropre du tuple T par la transaction A


La transaction A accde au tuple T qui a t modifi par la transaction B. B annule sa modification et A a
donc accd une valeur qui n'aurait jamais d exister (virtuelle) de T. Pire A pourrait faire une mise
jour de T aprs l'annulation par B, cette mise jour inclurait la valeur avant annulation par B (et donc
reviendrait annuler l'annulation de B).

Exemple
Temps

A:Ajouter10

B:Ajouter100(erreur)

t1

LIRECOMPTE
C=1000

t2

UPDATECOMPTE
C=C+100=1100

t3
t4

LIRECOMPTE
C=1100

...

...

ROLLBACK
C=1000

t5

UPDATEC
C=C+10=1110

t6

COMMIT
C=1110

Tableau 20 Annulation de crdit sur le compte bancaire C


Dans cet exemple le compte bancaire vaut 1110 la fin des deux transactions la place de 1010.

140

S. Crozat - UTC 2009

La gestion des transactions

c) Lecture incohrente
Temps

TransactionA

TransactionB

t1

LIRET

t2

...

UPDATET

t3

...

COMMIT

t4

LIRET

Tableau 21 Problme de la lecture non reproductible du tuple T par la transaction A


Si au cours d'une mme transaction A accde deux fois la valeur d'un tuple alors que ce dernier est,
entre les deux, modifi par une autre transaction B, alors la lecture de A est inconsistente. Ceci peut
entraner des incohrences par exemple si un calcul est en train d'tre fait sur des valeurs par ailleurs en
train d'tre mises jour par d'autres transactions.

Remarque
Le problme se pose bien que la transaction B ait t valide, il ne s'agit donc pas du problme d'accs
des donnes non valides.

Exemple
Temps
t1

A:CalculdeS=C1+C2

B:Transfertde10deC1

LIRECOMPTE1
C1=100
...

LIRECOMPTE1
C1=100

...

LIRECOMPTE2
C2=100

...

UPDATECOMPTE1
C1=10010=90

...

UPDATECOMPTE2
C2=100+10=110

t6

...

COMMIT

t7

LIRECOMPTE2
C2=110

t8

CALCULS
S=C1+C2=210

t2
t3
t4
t5

C2

Tableau 22 Transfert du compte C1 au compte C2 pendant une opration de calcul C1+C2


Dans cet exemple la somme calcule vaut 210 la fin du calcul alors qu'elle devrait valoir 200.

2. Le verrouillage.
Introduction
Une solution gnrale la gestion de la concurrence est une technique trs simple appele verrouillage.

Dfinition : Verrou
Poser un verrou sur un objet (typiquement un tuple) par une transaction signifie rendre cet objet
inaccessible aux autres transactions.
Synonymes : Lock

S. Crozat - UTC 2009

141

La gestion des transactions

Dfinition : Verrou partag


Un verrou partag, not S, est pos par une transaction lors d'un accs en lecture sur cet objet.
Un verrou partag interdit aux autres transaction de poser un verrou exclusif sur cet objet et donc d'y
accder en criture.
Synonymes : Verrou de lecture, Shared lock, Read lock

Dfinition : Verrou exclusif


Un verrou exclusif, not X, est pos par une transaction lors d'un accs en criture sur cet objet.
Un verrou exclusif interdit aux autres transactions de poser tout autre verrou (partag ou exclusif) sur cet
objet et donc d'y accder (ni en lecture, ni en criture).
Synonymes : Verrou d'criture, Exclusive lock, Write lock

Remarque : Verrous S multiples


Un mme objet peut tre verrouill de faon partage par plusieurs transactions en mme temps. Il sera
impossible de poser un verrou exclusif sur cet objet tant qu'au moins une transaction disposera d'un
verrou S sur cet objet.

Mthode : Rgles de verrouillage


Soit la transaction A voulant poser un verrou S sur un objet O
1. Si O n'est pas verrouill alors A peut poser un verrou S
2. Si O dispose dj d'un ou plusieurs verrous S alors A peut poser un verrou S
3. Si O dispose dj d'un verrou X alors A ne peut pas poser de verrou S
Soit la transaction A voulant poser un verrou X sur un objet O
1. Si O n'est pas verrouill alors A peut poser un verrou X
2. Si O dispose dj d'un ou plusieurs verrous S ou d'un verrou X alors A ne peut pas poser de
verrou X
VerrouXpr sent

Verrou(s)Spr sent(s)

Pasdeverroupr

sent

VerrouXdemand

Demanderefus e

Demanderefus e

Demandeaccord

VerrouSdemand

Demanderefus e

Demandeaccord

Demandeaccord

Tableau 23 Matrice des rgles de verrouillage

Remarque : Promotion d'un verrou


Une transaction qui dispose dj, elle-mme, d'un verrou S sur un objet peut obtenir un verrou X sur cet
objet si aucune autre transaction ne dtient de verrou S sur l'objet. Le verrou est alors promu du statut
partag au statut exclusif.

3. Le dverrouillage.
Dfinition : Dverrouillage
Lorsqu'une transaction se termine (COMMIT ou ROLLBACK) elle libre tous les verrous qu'elle a pos.
Synonymes : Unlock

4. Protocole d'accs aux donnes.


Mthode : Rgles de verrouillage avant les lectures et critures des donnes
Soit la transaction A voulant lire des donnes d'un tuple T :
1. A demande poser un verrou S sur T
2. Si A obtient de poser le verrou alors A lit T

142

S. Crozat - UTC 2009

La gestion des transactions

3. Sinon A attend le droit de poser son verrou (et donc que les verrous qui l'en empchent soient
levs)

Soit la transaction A voulant crire des donnes d'un tuple T :


1. A demande poser un verrou X sur T
2. Si A obtient de poser le verrou alors A crit T
3. Sinon A attend le droit de poser son verrou (et donc que les verrous qui l'en empchent soient
levs)
Soit la transaction A se terminant (COMMIT ou ROLLBACK) :
1. A libre tous les verrous qu'elle avait pos
2. Certaines transactions en attente obtiennent ventuellement le droit de poser des verrous

Remarque : Liste d'attente


Afin de rationaliser les attentes des transactions, des stratgies du type FIFO sont gnralement
appliques et donc les transactions sont empiles selon leur ordre de demande.

5. Solution aux trois problmes soulevs par la concurrence.


Introduction
Le principe du verrouillage permet d'apporter une solution aux trois problmes classiques soulevs par les
accs aux concurrents aux donnes par les transactions.

a) Perte de mise jour


Temps
t1

TransactionA

TransactionB

LIRET
VerrouS
...

LIRET
VerrouS

t3

UPDATET
Attente...

...

t4

...
Attente...

UPDATET
Attente...

...

Interblocage

t2

Tableau 24 Problme de la perte de mise jour du tuple T par la transaction A

Remarque
Le problme de perte de mise jour est rgl, mais soulve ici un autre problme, celui de l'interblocage.

b) Accs des donnes non valides

S. Crozat - UTC 2009

143

La gestion des transactions


Temps

TransactionA

UPDATET
VerrouX

t1
t2

LIRET
Attente...

...
ROLLBACK
LibrationduverrouX

t3
t4

TransactionB

VerrouS

Tableau 25 Problme de la lecture impropre du tuple T par la transaction A

c) Lecture incohrente
Temps
t1

TransactionA

TransactionB

LIRET
VerrouS
...

UPDATET
Attente...

t3

LIRET
VerrousS

...

...

...lib rationdesverrous...

...reprisedelatransaction...

t2

Tableau 26 Problme de la lecture non reproductible du tuple T par la transaction A

Remarque
La lecture reste cohrente car aucune mise jour ne peut intervenir pendant le processus de lecture d'une
mme transaction.

6. Inter-blocage
Dfinition : Inter-blocage
L'inter-blocage est le phnomne qui apparait quand deux transactions (ou plus, mais gnralement deux)
se bloquent mutuellement par des verrous poss sur les donnes. Ces verrous empchent chacune des
transactions de se terminer et donc de librer les verrous qui bloquent l'autre transaction. Un processus
d'attente sans fin s'enclenche alors.
Les situations d'inter-blocage sont dtectes par les SGBD et gres, en annulant l'une, l'autre ou les
deux transactions, par un ROLLBACK systme. Les mthodes utilises sont la dtection de cycle dans un
graphe d'attente et la dtection de dlai d'attente trop long.
Synonymes : Deadlock, Blocage, Verrou mortel

Dfinition : Cycle dans un graphe d'attente


Principe de dtection d'un inter-blocage par dtection d'un cycle dans un graphe reprsentant quelles
transactions sont en attente de quelles transactions (par infrence sur les verrous poss et les verrous
causes d'attente). Un cycle est l'expression du fait qu'une transaction A est en attente d'une transaction B
qui est en attente d'une transaction A.
La dtection d'un tel cycle permet de choisir une victime, c'est dire une des deux transactions qui sera
annule pour que l'autre puisse se terminer.
Synonymes : Circuit de blocage

144

S. Crozat - UTC 2009

La gestion des transactions

Dfinition : Dlai d'attente


Principe de dcision qu'une transaction doit tre abandonne (ROLLBACK) lorsque son dlai d'attente est
trop long.
Ce principe permet d'viter les situations d'inter-blocage, en annulant une des deux transactions en cause,
et en permettant donc l'autre de se terminer.
Synonymes : Timeout

Remarque : Risque li l'annulation sur dlai


Si le dlai est trop court, il y a un risque d'annuler des transactions en situation d'attente longue, mais non
bloques.
Si le dlai est trop long, il y a un risque de chute des performances en situation d'inter-blocage (le temps
que le systme ragisse).
La dtection de cycle est plus adapte dans tous les cas, mais plus complexe mettre en uvre.

Remarque : Relance automatique


Une transaction ayant t annule suite un inter-blocage (dtection de cycle ou de dlai d'attente) n'a pas
commis de "faute" justifiant son annulation. Cette dernire est juste due aux contraintes de la gestion de la
concurrence. Aussi elle n'aurait pas d tre annule et devra donc tre excute nouveau.
Certains SGBD se charge de relancer automatiquement les transactions ainsi annules.

E. En rsum : Les transactions


Transaction
Unit logique de travail pour assurer la cohrence de la BD mme en cas de pannes ou d'accs
concurrents.

Panne
Mme en cas de panne, la BD doit rester cohrente.
Dfaillances systme
Coupure de courant, de rseau, etc.
Dfaillances du support
Crash disque (dans ce cas les transactions peuvent tre insuffisantes).

Concurrence
Dimension relevant de la conception d'application.
Perte de mise jour
Accs des donnes non valides
Lecture incohrente

Programmation
Un programme peut dcider de l'annulation d'une transaction.
ROLLBACK
Instruction SQL d'annulation d'une transaction.

F. Bibliographie commente sur les transactions


Complment : Synthses
Les transactions [w_developpez.com/hcesbronlavau]
Une bonne introduction courte au principe des transactions avec un exemple trs bien choisi. Des
exemples d'implmentation sous divers SGBD (InterBase par exemple)

S. Crozat - UTC 2009

145

La gestion des transactions

SQL2 SQL3, applications Oracle [Delmal01]


Une bonne description des principes des transactions, avec les exemples caractristiques,
l'implmentation SQL et une tude de cas sous Oracle 8 (chapitre 5).
Tutoriel de bases de donnes relationnelles de l'INT Evry [w_int-evry.fr] (http://www-inf.intevry.fr/COURS/BD/BD_REL/SUPPORT/poly.html#RTFToC30
Un aperu gnral de l'ensemble de la problmatique des transactions, de la concurrence et de la fiabilit.
Programmation SQL [Mata03]
Un exemple d'excution de transactions (pages 20-23)

146

S. Crozat - UTC 2009

VIII -

L'OPTIMISATION DU SCHMA

INTERNE

VIII

Introduction l'optimisation des BD

184

En rsum : L'optimisation

189

Bibliographie commente sur l'optimisation

189

La conception des SGBDR exige qu'une attention particulire soit porte la modlisation conceptuelle,
afin de parvenir dfinir des modles logiques relationnels cohrents et manipulables. De tels modles
relationnels, grce au langage standard SQL, prsentent la particularit d'tre implmentables sur toute
plate-forme technologique indpendamment de considrations physiques.
Nanmoins l'on sait que dans la ralit, il est toujours ncessaire de prendre en considration les
caractristiques propres de chaque SGBDR, en particulier afin d'optimiser l'implmentation. Les
optimisations concernent en particulier la question des performances, question centrale dans les
applications de bases de donnes, qui, puisqu'elles manipulent des volumes de donnes importants,
risquent de conduire des temps de traitement de ces donnes trop longs par rapport aux besoins d'usage.
Chaque SGBDR propose gnralement des mcaniques propres pour optimiser les implmentations, et il
est alors ncessaire d'acqurir les comptences particulires propres ces systmes pour en matriser les
arcanes. Il existe nanmoins des principes gnraux, que l'on retrouvera dans tous les systmes, comme
par exemple les index, les groupements ou les vues matrialises. Nous nous proposerons d'aborder
rapidement ces solutions pour en examiner les principes dans le cadre de ce cours.
Nous aborderons galement quelques techniques de conception, qui consistent revenir sur la structure
propose par l'tape de modlisation logique, pour tablir des modles de donnes plus aptes rpondre
correctement des questions de performance. La dnormalisation ou le partitionnement en sont des
exemples.

A. Introduction l'optimisation des BD


Objectifs
Assimiler la problmatique de la performance en bases de donnes
Connatre les grandes classes de solutions technologiques existantes aux
problmes de performance
Connatre et savoir mobiliser les techniques de conception permettant
d'optimiser les performances d'une BD

1. Schma interne et performances des applications


La passage au schma interne (ou physique), i.e. l'implmentation du schma logique dans un SGBD

S. Crozat - UTC 2009

147

L'optimisation du schma interne

particulier, dpend de considrations pratiques lies aux performances des applications.


Les possibilits d'optimisation des schmas internes des BD dpendent essentiellement des fonctions
offertes par chaque SGBD.
On peut nanmoins extraire certains principes d'optimisation des schmas internes suffisamment
gnraux pour tre applicables dans la plupart des cas.

2. valuation des besoins de performance


a) lments surveiller
Pour optimiser un schma interne, il est d'abord ncessaire de reprer les aspects du schma logique qui
sont succeptible de gnrer des problmes de performance.
On pourra citer titre d'exemple les paramtres surveiller suivants :

Taille des tuples

Nombre de tuples

Frquence d'excution de requtes

Complexit des requtes excutes (nombre de jointures, etc.)

Frquence des mises jour (variabilit des donnes)

Accs concurents

Distribution dans la journe des accs

Qualit de service particulire recherche

Paramtrabilit des excutions

etc.

b) valuation des cots


Une fois les lments de la BD valuer reprs, il faut mesurer si oui ou non ils risquent de poser un
problme de performance.
L'valuation des performances peut se faire :

Thoriquement
En calculant le cot d'une opration (en temps, ressources mmoires, etc.) en fonction de
paramtres (volume de donnes, disparit des donnes, etc.). En gnral en BD le nombre de
paramtres est trs grand, et les calculs de cots trop complexes pour rpondre de faon prcise
aux questions poses.

Empiriquement
En ralisant des implmentations de parties de schma et en les soumettant des tests de charge,
en faisant varier des paramtres. Ce modle d'valuation est plus raliste que le calcul thorique.
Il faut nanmoins faire attention ce que les simplifications d'implmentation faites pour les
tests soient sans influence sur ceux-ci.

c) Proposition de solutions
Une fois certains problmes de performance identifis, des solutions d'optimisation sont proposes, puis
values pour vrifier leur impact et leur rponse au problme pos.
Parmi les solutions d'optimisation existantes, on pourra citer :

L'indexation

La dnormalisation

Le regroupement (clustering) de tables

Le partitionnement vertical et horizontal

Les vues concrtes

148

S. Crozat - UTC 2009

L'optimisation du schma interne

3. Indexation
Dfinition : Index
Un index est une structure de donnes qui permet d'acclrer les recherches dans une table en associant
une cl d'index (la liste des attributs indexs) l'emplacement physique de l'enregistrement sur le disque.
Les accs effectues sur un index peuvent donc se faire sur une liste trie au lieu de se faire par parcours
squentiel des enregistrements.

Mthode : Cas d'usage


Les index doivent tre utiliss sur les tables qui sont frquemment soumises des recherches. Ils sont
d'autant plus pertinents que les requtes slectionnent un petit nombre d'enregistrements (moins de 25%
par exemple).
Les index doivent tre utiliss sur les attributs :

souvent mobiliss dans une restriction, donc une jointure

trs discrimins (c'est dire pour lesquels peu d'enregistrements ont les mmes valeurs)

rarement modifis
Les index diminuent les performances en mise jour (puisqu'il faut mettre jour les index en mme
temps que les donnes). Les index ajoutent du volume la base de donnes et leur volume peut devenir
non ngligeable.

Syntaxe : Syntaxe Oracle


CREATE INDEX nom_index ON nom_table (NomColonneCl1,
NomColonneCl2, ...);

Remarque : Index implicites


La plupart des SGBD crent un index pour chaque cl (primaire ou candidate). En effet la vrification
de la contrainte d'unicit chaque mise jour des donnes justifie elle seule la prsence de l'index.

Attention : Attributs indexs utiliss dans des fonctions


Lorsque les attributs sont utiliss dans des restrictions ou des tris par l'intermdiaire de fonctions, l'index
n'est gnralement pas pris en compte. L'opration ne sera alors pas optimise. Ainsi par exemple dans le
code suivant, le restriction sur X ne sera pas optimise mme s'il existe un index sur X.
SELECT *
FROM T
WHERE ABS(X) > 100
Cette non prise en compte de l'index est logique dans la mesure o, on le voit sur l'exemple prcdent,
une fois l'attribut soumis une fonction, le classement dans l'index n'a plus forcment de sens (l'ordre des
X, n'est pas l'ordre des valeurs absolues de X).
Lorsqu'un soucis d'optimisation se pose, on cherchera alors sortir les attributs indexs des fonctions.
Notons que certains SGBD, tels qu'Oracle partir de la version 8i, offrent des instructions d'indexation
sur les fonctions qui permettent une gestion de l'optimisation dans ce cas particulier SQL2 SQL3,
applications Oracle [Delmal01].

4. Dnormalisation
La normalisation est le processus qui permet d'optimiser un modle logique afin de le rendre non
redondant. Ce processus conduit la fragmentation des donnes dans plusieurs tables.

Dfinition : Dnormalisation
Processus consistant regrouper plusieurs tables lies par des rfrences, en une seule table, en ralisant

S. Crozat - UTC 2009

149

L'optimisation du schma interne

statiquement les oprations de jointure adquates.


L'objectif de la dnormalisation est d'amliorer les performances de la BD en recherche sur les tables
considres, en implmentant les jointures plutt qu'en les calculant.

Remarque : Dnormalisation et redondance


La dnormalisation est par dfinition facteur de redondance. A ce titre elle doit tre utilise bon escient
et des moyens doivent tre mis en oeuvre pour contrler la redondance cre.

Mthode : Quand utiliser la dnormalisation ?


Un schma doit tre dnormalis lorsque les performances de certaines recherches sont insuffisantes et
que cette insuffisance pour cause des jointures.
La dnormalisation peut galement avoir un effet nfaste sur les performances :

En mise jour
Les donnes redondantes devant tre dupliques plusieurs fois.

En contrle supplmentaire
Les moyens de contrle ajouts (triggers, niveaux applicatifs, etc.) peuvent tre trs couteux.

En recherche cible
Certaines recherches portant avant normalisation sur une "petite" table et portant aprs sur une
"grande" table peuvent tre moins performantes aprs qu'avant.

5. Groupement de tables
Dfinition : Groupement de table
Un groupement ou cluster est une structure physique utilise pour stocker des tables sur lesquelles
doivent tre effectues de nombreuses requtes comprenant des oprations de jointure.
Dans un groupement les enregistrements de plusieurs tables ayant une mme valeur de champs servant
une jointure (cl du groupement) sont stockes dans un mme bloc physique de la mmoire permanente.
Cette technique optimise donc les oprations de jointure, en permettant de remonter les tuples joints par
un seul accs disque.

Dfinition : Cl du groupement
Ensemble d'attributs prcisant la jointure que le groupement doit optimiser.

Syntaxe : Syntaxe sous Oracle


Il faut d'abord dfinir un groupement, ainsi que les colonnes (avec leur domaine), qui constituent sa cl.
On peut ainsi ensuite, lors de la cration d'une table prciser que certaines de ses colonnes appartiennent
au groupement.
CREATE CLUSTER nom_cluster (NomColonneCl1 type,
NomColonneCl2 type, ...);
CREATE TABLE nom_table (...)
CLUSTER nom_cluster (Colonne1, Colonne2, ...);

Remarque
Le clutering diminue les performances des requtes portant sur chaque table prise de faon isole,
puisque les enregistrements de chaque table sont stocks de faon clate.

Remarque : Groupement et dnormalisation


Le groupement est une alternative la dnormalisation, qui permet d'optimiser les jointures sans crer de
redondance.

150

S. Crozat - UTC 2009

L'optimisation du schma interne

6. Partitionnement de table
Dfinition : Partitionnement de table
Le partitionnement d'une table consiste dcouper cette table afin qu'elle soit moins volumineuse,
permettant ainsi d'optimiser certains traitements sur cette table.
On distingue :

Le partitionnement vertical, qui permet de dcouper une table en plusieurs tables, chacune ne
possdant qu'une partie des attributs de la table initiale.

Le partitionnement horizontal, qui permet de dcouper une table en plusieurs tables, chacune ne
possdant qu'une partie des enregistrements de la table initiale.

a) Implmentation de projection
Dfinition : Partitionnement vertical
Technique consistant implmenter deux projections ou plus d'une table T sur des table T1, T2, etc. en
rptant la cl de T dans chaque Ti pour pouvoir recomposer la table initiale par jointure sur la cl Bases
de donnes : objet et relationnel [Gardarin99].

Remarque
Ce dcoupage quivaut considrer l'entit diviser comme un ensemble d'entits relies par des
associations 1:1.

Mthode : Cas d'usage


Un tel dcoupage permet d'isoler des attributs peu utiliss d'autres trs utiliss, et ainsi amliore les
performances lorsque l'on travaille avec les attributs trs utiliss (la table tant plus petite).
Cette technique diminue les performances des oprations portant sur des attributs ayant t rpartis sur
des tables diffrentes (une opration de jointure tant prsent requise).
Le partitionnement vertical est bien entendu sans intrt sur les tables comportant peu d'attributs.

b) Implmentation de restriction
Dfinition : Partitionnement horizontal
Technique consistant diviser une table T en plusieurs sous-table T1, T2, etc. selon des critres de
restriction Bases de donnes : objet et relationnel [Gardarin99] et de telle faon que tous les tuples de
T soit conservs. La table T est alors recomposable par union sur les Ti.

Mthode : Cas d'usage


Un tel dcoupage permet d'isoler des enregistrements peu utiliss d'autres trs utiliss, et ainsi amliore
les performances lorsque l'on travaille avec les enregistrements trs utiliss (la table tant plus petite).
C'est le cas typique de l'archivage. Un autre critre d'usage est le fait que les enregistrements soient
toujours utiliss selon un partitionnement donn (par exemple le mois de l'anne).
Cette technique diminue les performances des oprations portant sur des enregistrements ayant t
rpartis sur des tables diffrentes (une opration d'union tant prsent requise).
Le partitionnement horizontal est bien entendu sans intrt sur les tables comportant peu
d'enregistrements.

7. Vues concrtes
Un moyen de traiter le problme des requtes dont les temps de calcul sont trs longs et les frquences de
mise jour faible est l'utilisation de vues concrtes.

S. Crozat - UTC 2009

151

L'optimisation du schma interne

Dfinition : Vue concrte


Une vue concrte est un stockage statique (dans une table) d'un rsultat de requte.
Un accs une vue concrte permet donc d'viter de recalculer la requte et est donc aussi rapide qu'un
accs une table isole. Il suppose par contre que les donnes n'ont pas t modifies (ou que leur
modification est sans consquence) entre le moment o la vue a t calcule et le moment o elle est
consulte.
Une vue concrte est gnralement recalcule rgulirement soit en fonction d'un vnement particulier
(une mise jour par exemple), soit en fonction d'un moment de la journe ou elle n'est pas consulte et o
les ressources de calcul sont disponibles (typiquement la nuit).
Synonymes : Vue matrialise

B. En rsum : L'optimisation
Optimisation
Modification du schma interne d'une BD pour en amliorer les performances.

Techniques au niveau physique


Indexation
Regroupement physique
Vue concrte

Techniques de modlisation
Dnormalisation
Partitionnement
Horizontal
Vertical

C. Bibliographie commente sur l'optimisation


Complment : Synthses
SQL2 SQL3, applications Oracle [Delmal01]
Une bonne description des index (page 79) et clusters (page 81) par l'image. Une description intressante
d'une fonction (sous Oracle 8i) qui permet d'indexer des fonctions, ce qui rpond un problme
important d'optimisation (page 84). Une description des vues matrialises, leur implmentation sous
Oracle, des exemples d'usage dans le domaine du datawarehouse.
Bases de Donnes Relationnelles et Systmes de Gestion de Bases de Donnes Relationnels, le Langage
SQL [w_supelec.fr/~yb]
Des informations gnrales sur les index3 et sur les clusters4.

3 - http://wwwsi.supelec.fr/~yb/poly_bd/node122.html
4 - http://wwwsi.supelec.fr/~yb/poly_bd/node126.html

152

S. Crozat - UTC 2009

Ouvrage de
rfrence conseill
IX -

SQL2 SQL3, applications Oracle [Delmal01]


Cet ouvrage aborde tous les thmes du cours de faon claire et illustre, en dehors de la phase de
modlisation.

S. Crozat - UTC 2009

153

Questions de
synthse
En quoi une base de donnes est-elle plus intressante qu'un systme de fichier classique ?

Quelles sont les fonctions remplies par un SGBD ?

Pourquoi est-ce que l'on distingue trois niveaux de modlisation lors de la conception d'une base de donnes ?

S. Crozat - UTC 2009

155

Ouvrage de rfrence conseill

Quelles est la diffrence entres le schma conceptuel et le ou les schmas externes ?

Quelles sont les fonctions d'un langage orient donnes ?

A quoi et qui sert un dictionnaire de donnes ?

Pourquoi est-il fondamental mais difficile de parvenir un MCD correct ?

156

S. Crozat - UTC 2009

Ouvrage de rfrence conseill

Enoncer quelques actions mener pour raliser une spcification gnrale de l'existant et des besoins ?

Qu'est ce qui diffrencie fondamentalement un MCD d'un MLD ?

Quels sont les principaux lments du diagramme de classes UML ?

Quelles sont les diffrences et points communs entre la diagramme de classe UML et le modle E-A tendu ?

S. Crozat - UTC 2009

157

Ouvrage de rfrence conseill

A quoi servent les classes abstraites ?

Quand doit-on expliciter des contraintes sur les associations ?

Quand doit-on utiliser les paquetages ?

Enoncer les principaux lments composants le modle E-A ?

158

S. Crozat - UTC 2009

Ouvrage de rfrence conseill

Quels sont les avantages apports par l'extension du modle E-A ?

Que permet d'exprimer une entit de type faible ?

Qu'est ce qu'un domaine ?

Quel rapport y-a-t il entre une relation et une table ?

S. Crozat - UTC 2009

159

Ouvrage de rfrence conseill

Comment identifie-t-on un attribut d'une relation ?

Comment identifie-t-on un enregistrement d'une relation ?

Quelle problme pose la redondance et comment le rsoudre ?

Le passage UML vers relationnel est-il systmatique ou soumis interprtation ? Pourrait-il tre ralis par un
algorithme ?

160

S. Crozat - UTC 2009

Ouvrage de rfrence conseill

Pourquoi dispose-t-on de trois mthodes pour traduire l'hritage dans un modle relationnel ? Ces trois mthodes
sont-elles quivalentes ?

Quels sont les oprateurs algbriques de base ? Quels sont les autres oprateurs ? Qu'est ce qui les diffrencie ?

Quels sont les oprateurs ensemblistes ? Qu'est ce qui les caractrise ?

Pourquoi la jointure est-elle un oprateur essentiel ?

S. Crozat - UTC 2009

161

Ouvrage de rfrence conseill

Qu'est ce qui diffrencie une jointure externe d'une jointure classique ?

A quoi sert le LDD ?

En quoi le LDD est il un langage dclaratif ?

Quel rapport y-a-t il entre le LDD et le concept de relation ?

162

S. Crozat - UTC 2009

Ouvrage de rfrence conseill

A quoi sert le LMD ?

Quel rapport y-a-t il entre le SQL et l'algbre relationnelle ?

Pourquoi SQL n'est-il pas un langage de programmation ?

Quels types de droits peuvent tre accords ou rvoqus en SQL ?

S. Crozat - UTC 2009

163

Ouvrage de rfrence conseill

Pourquoi peut-on dire que la gestion des droits est dcentralise en SQL ?

En quoi peut-on dire que certains schmas relationnels sont mauvais ?

Pourquoi est-il primordial de reprer les dpendances fonctionnelles sur un schma relationnel ?

Comment repre-t-on ces dpendances fonctionnelles ?

164

S. Crozat - UTC 2009

Ouvrage de rfrence conseill

Que sont les axiomes d'Armstrong et quoi servent-ils ?

Qu'est ce que la dcomposition d'une relation ?

Pourquoi le respect de la premire forme normale reste-t-il en partie subjectif ?

Quelle forme normale est gnralement souhaitable pour un schma relationnel ?

S. Crozat - UTC 2009

165

Ouvrage de rfrence conseill

Quels sont les atouts du modle relationnel-objet par rapport au modle relationnel ?

Quels sont les extensions les plus importantes apports par le modle relationnel-objet au modle relationnel ?

En quoi le modle relationnel-objet peut-il tre considr comme plus proche que le modle relationnel du modle
conceptuel ?

En quoi le mapping E-A vers relationnel-objet est-il plus fidle que le mapping E-A vers relationnel ?

166

S. Crozat - UTC 2009

Ouvrage de rfrence conseill

Dans quel cas l'utilisation de collections peut-il tre destructeur de smantique ?

En quoi l'implmentation de l'hritage en relationnel-objet simplifie-t-il le mapping ? En quoi ne le simplifie-t-il


pas ?

Qu'apporte les OID par rapport aux cls trangres classiquement manipules dans le modle relationnel ?

Quelles solutions de modlisation apporte les instructions de cration de type sous Oracle ?

S. Crozat - UTC 2009

167

Ouvrage de rfrence conseill

L'utilisation d'OID pour les rfrences est-elle prfrable l'utilisation de cls trangres classique, en particulier
dans le cas o la cl trangre est compose ?

Pourquoi une transaction est-elle atomique ?

Pourquoi une transaction est-elle cohrente ?

Pourquoi une transaction est-elle isole ?

168

S. Crozat - UTC 2009

Ouvrage de rfrence conseill

Pourquoi une transaction est-elle durable ?

A quoi sert le journal des transactions ?

Qu'est ce qu'un point de contrle ?

L'aglorithme de reprise UNDO-REDO terminera-t-il toutes les transactions qui taient commences au moment de
la panne ?

S. Crozat - UTC 2009

169

Ouvrage de rfrence conseill

Laquelle des proprits ACID des transactions est-elle particulirement utile pour grer les accs concurrents ?

Le verrouillage est-il une solution parfaite pour la gestion de la concurrence ?

Pourquoi peut-on dire que les transactions sont les unit logique de travail, les units d'intgrit, les units de reprise
et les units de concurrence ?

Citer des paramtres propres une BD que l'on doit surveiller dans le cadre de la performance ?

170

S. Crozat - UTC 2009

Ouvrage de rfrence conseill

Peut-on anticiper sur des problmes de performance futurs lors de la conception d'une BD ?

Pourquoi n'indexe-t-on pas tous les champs d'une BD ?

Quels problmes pose la dnormalisation ?

Quels problmes pose le clustering ?

S. Crozat - UTC 2009

171

Ouvrage de rfrence conseill

Quels problmes pose le partionnement ?

Quels problmes pose les vues concrtes ?

172

S. Crozat - UTC 2009

Solution des
exercices de TD
> Solution n1 (exercice p. 73)
Intersection (R1, R2) = Difference (R1, Difference (R1,
R2))

> Solution n2 (exercice p. 73)


Jointure (R1, R2, condition) = Restriction ( Produit (R1,
R2), condition)

> Solution n3 (exercice p. 74)


Considrons la division de R1 par R2 :
Soit Ai les attribut de R1 n'appartenant pas R2
Soit R_p = Projection (R1, Ai)
Soit R_px2 = Produit (R_p, R2)
Soit R_px2-1 = Difference (R_px2, R1)
Soit R_px2-1p = Projection (R_px2-1, Ai)
Division (R1, R2) = Difference (R_p, R_px2-1p)
Notons ce que reprsente les relations intermdiaires :

"R_p" est la relation obtenu partir de R1 en ne gardant que les attributs n'appartenant pas R2.
Cette relation est de mme schma que la relation rsultat.

"R_px2" est la relation qui combine tous les tuples de R2 avec les tuples de la relation R_p.
Cette relation est de mme schma que R1, et elle contient tous les tuples possibles, et non
seulement ceux qui correspondent au rsultat.

"R_px2-1" est la relation qui restreint R_px2 au tuples n'appartenant pas R1, elle contient donc
tous les mauvais tuples, c'est dire tous ceux que l'on ne veut pas voir appartre dans le rsultat.

"R_px2-1p" est la relation de mme schma que le rsultat, et donc qui contient les mauvais
tuples.
Le rsultat de la division est obtenu par diffrence entre tous les tuples possibles (R_p) et tous les
mauvais tuples (R_px2-1p).

> Solution n4 (exercice p. 97)


Il y a trois cls candidates : {B,C}, {B,E} et {B,G}, soit la concatnation des colonnes B et C, ou B et E
ou Bet G. Ce sont en effet les plus petites combinaisons qui sont uniques pour cette relation, et donc qui
permettent de distinguer deux enregistrements. Pour toutes les autres combinaisons, soit elles ne sont pas
uniques, soit elles contiennent {B,C}, {B,E} ou {B,G}.

S. Crozat - UTC 2009

173

Ouvrage de rfrence conseill

La cl primaire peut donc tre choisie parmi ces trois candidates.

> Solution n5 (exercice p. 98)


La relation contient des redondances : les colonnes A, D et F d'une part et E et G d'autre part sont
redondantes. En effet pour une valeur donne de A, on obtient toujours les mmes valeurs de D et F et
pour une valeur donne de E on obtient toujours la mme valeur de G.

> Solution n6 (exercice p. 98)


La seule solution pour supprimer les redondances est de dcouper la relation R en relations non
redondantes.
A

Tableau 27 Relation R1
A

10

20

Tableau 28 Relation R2
E

Tableau 29 Relation R3

174

S. Crozat - UTC 2009

Glossaire

Constructeur d'objet
En programmation oriente objet, un constructeur d'objet est une mthode particulire d'une classe qui
permet d'instancier un objet de cette classe. L'appel cette mthode de classe a donc pour consquence la
cration d'un nouvel objet de cette classe.
Exception
Une exception est un vnement gnr par un systme informatique pour signifier une erreur
d'excution. La gestion des exceptions est un aspect de la programmation informatique, qui consiste
intercepter ces vnements particuliers et les traiter pour, soit les corriger automatiquement, soit en
donner une information approprie un utilisateur humain.
Impedance mismatch
Le terme d'impedance mismatch renvoie au dcalage qui peut exister entre le niveau d'abstraction de deux
langages qui ont travailler sur des structures de donnes communes, par exemple un langage applicatif
objet et un langage de donnes relationnel. L'impedance mismatch a des consquences ngatives en terme
de complexification de l'implmentation et en terme de performance, puisqu'il faut constamment passer
d'une structure de donnes l'autre.
RAID
La technologie RAID permet de repartir de l'information stocker sur plusieurs "petits" disques, au lieu
de la concentrer sur un seul "gros" disque. Cette technologie permet donc d'amliorer les performances
(les accs disques pouvant tre parallliss) et d'amliorer la sret (en repartissant les risques de crash et
en jouant sur une redondance des donnes). Il existe plusieurs types d'architecture RAID, privilgiant ou
combinant la paralllisation et la redondance.
Serveur
Un serveur est un programme informatique qui a pour fonction de recevoir des requtes d'un autre
programme, appel client, de traiter ces requtes et de renvoyer en retour une rponse. Notons qu'un
programme peut-tre serveur vis vis d'un programme et client vis vis d'un autre. On ne prend pas ici le
terme serveur dans son acception matrielle, qui signifie alors un ordinateur qui a pour fonction
d'hberger des programmes serveurs.

S. Crozat - UTC 2009

175

Signification des
abrviations
-

1NF
2NF
3NF
4NF
5NF
ACID
ANSI
API
BCNF
BD
DF
DFE
E-A
E-R
FIFO
IHM
ISO
LCD
LDD
LMD
MCD
MLD
OID
OMG
PSM
RO
SGBD
SGBDOO
SGBDR
SGBDRO
SGF
SI
SQL
UML
XML

S. Crozat - UTC 2009

First Normal Form


Second Normal Form
Third Normal Form
Fourth Normal Form
Fifth Normal Form
Atomicity, Consistency, Isolation, Durability
American National Standards Institute
Application Program Interface
Boyce-Codd Normal Form
Base de Donnes
Dpendance Fonctionnelle
Dpendance Fonctionnelle Elmentaire
Entit-Association
Entity-Relationship
First In First Out
Interaction Homme Machine ou Interface Homme Machine
International Standardization Organization
Langage de Contrle de Donnes
Langage de Dfinition de Donnes
Langage de Manipulation de Donnes
Modle Conceptuel de Donnes
Modle Logique de Donnes
Object Identifier
Object Management Group
Persistent Stored Modules
Relationnel-Objet
Systme de Gestion de Bases de Donnes
Systme de Gestion de Bases de Donnes Orientes Objets
Systme de Gestion de Bases de Donnes Relationnelles
Systme de Gestion de Bases de Donnes Relationnelles-Objets
Systme de Gestion de Fichiers
Systme d'Information
Structured Query Language
Unified Modeling Language
eXtensible Markup Language

177

Bibliographie

[C el ko00]
CELKO JOE

. SQL avanc : Programmation et techniques avances. Vuibert, 2000.

[C h en 76]
CHEN P.P . The entity-Relationsheep Model - Towards a Unified View of Data. ACM Transactions
on Database systems. 1976-mars. 1, 1.
[C odd70]
CODD EF

, A relational model for large shared data banks, Communications de l'ACM, juin 1970.

[Del m al 01]
DELMAL PIERRE

. SQL2 SQL3, applications Oracle. De Boeck Universit, 2001.

[Gar dar i n 99]


GARDARIN GEORGES
[M at a03]
MATA-TOLEDO RAMON A.
Ediscience, 2003.
[M u ll er 98]
MULLER P.A.

. Bases de donnes : objet et relationnel. Eyrolles, 1999.


, CUSHMAN PAULINE K.

. Programmation SQL.

, Modlisation objet avec UML, Eyrolles, 1998.

[Pr at t 01]
PRATT PHILIP J.
2001.

. Initiation SQL : Cours et exercices corrigs. Eyrolles, Collection Noire.

[Roqu es 04]
ROQUES PASCAL
, VALLE FRANCK
. UML 2 en action : De l'analyse des besoins la
conception J2EE. ISBN 2-212-11462-1 (3me dition). Paris : Eyrolles, 2004. 385 p. architecte logiciel.
[S ou t ou 02]
SOUTOU CHRISTIAN

. De UML SQL : Conception de bases de donnes. Eyrolles, 2002.

[Tar di eu 83]
TARDIEU H.
, ROCHFELD A.
, COLLETI R.
outils. Paris : Les Editions d'Organisation, 1983.

. Mthode MERISE Tome 1 : Principes et

[Tar di eu 85]
TARDIEU H.
, ROCHFELD A.
, COLLETI R.
, PANET G. , VAHEE G.
Mthode MERISE Tome 2 : Dmarche et pratiques. Paris : Les Editions d'Organisation, 1985.

S. Crozat - UTC 2009

179

Ouvrage de rfrence conseill

[w _devel oppez .com / h ces br on l avau ]


CESBRON-LAVAU HENRY
, Les transactions,
http://www.developpez.com/hcesbronlavau/Transactions.htm, 2002.
[w _di a]
Dia, http://live.gnome.org/Dia
[w _in t -evr y.fr ]
DEFUDE BRUNO
, Tutoriel de bases de donnes relationnelles de l'INT Evry, http://www-inf.intevry.fr/COURS/BD/, consult en 2009.
[w _j ou r n al du n et .com (1)]
MORLON JRME
, UML en 5 tapes,
http://developpeur.journaldunet.com/dossiers/alg_uml.shtml, 2004.
[w _j ou r n al du n et .com (2)]
BORDERIE XAVIER
, Cinq petits conseils pour un schma UML efficace,
http://developpeur.journaldunet.com/tutoriel/cpt/031013cpt_uml5conseils.shtml, 2004.
[w _mh u bi ch e.devel oppez .com ]
HUBICHE MAXENCE
, Comprendre les jointures dans Access,
http://mhubiche.developpez.com/Access/tutoJointures/, consult en 2009.
[w _obj ect eer i n g]
Objecteering software. www.objecteering.com. [2002-septembre].
[w _su pel ec.fr / ~yb ]
BOURDA YOLAINE
, Bases de Donnes Relationnelles et Systmes de Gestion de Bases de
Donnes Relationnels, le Langage SQL, http://wwwsi.supelec.fr/~yb/poly_bd/, consult en 2009.
[w _s ybas e]
Sybase PowerDesigner, http://www.sybase.com/products/enterprisemodeling, consult en 2002.
[w _u m l .fr ee.fr ]
UML en Franais, http://uml.free.fr, consult en 2002.
[w _u n i v- l yon 2.fr / ~j dar m ont ]
DARMONT JRME
janvier].

180

. Tutoriel SQL. http://eric.univ-lyon2.fr/~jdarmont/tutoriel-sql/. [2004-

S. Crozat - UTC 2009

Index

1:N
p.117
1NF p.104, 111, 112
2NF p.104
3NF p.105, 106
Abstraite.................................... p.32
Acces p.134
ACID p.132
Administration................... p.13, 17
Agrgat.............................. p.88, 89
Algbre p.46, 67, 67, 68, 69,
69, 70, 70, 71, 71, 72,
73
ALL p.92
ALTER TABLE.................. p.80, 81
Analyse....... p.17, 18, 19, 19, 19
AND p.85
Annulation.............................. p.132
ANY p.93
Armstrong..................... p.100, 100
Association p.26, 30, 31, 39, 50,
50, 55, 56, 57, 64, 117,
117
Association 1:1.......................... p.55
Atomicit................................. p.104
Attente..................................... p.142
Attribut p.24, 30, 40, 47, 48,
48, 49, 52, 56, 56
Attribut composite.................. p.116
Attribut driv......................... p.116
Attribut multi-valu................ p.116
BCNF p.106
BD
p.9, 11, 11
BETWEEN................................. p.85
BLOB p.117
Boolean................................... p.117
Calcul p.88
Cardinalit......................... p.27, 39
Cartsien................................... p.70
Catalogue.................................. p.17
CHECK..................................... p.78
Classe p.14, 24, 28, 32, 54, 56,
112
Cl
p.41, 48, 49, 52, 102
Cl artificielle........................... p.49

S. Crozat - UTC 2009

Cl candidate............................ p.48
Cl trangre...... p.113, 117, 122
Cl primaire...................... p.48, 49
Cl signifiante........................... p.49
Cluster.................................... p.150
Codd p.46
Cohrence p.131, 132, 132, 139
Collection p.113, 116, 117, 119,
122
COMMIT...................... p.133, 138
Comparaison............................. p.85
Composition....................... p.31, 57
Conception.... p.9, 13, 17, 18, 98
Conceptuel p.9, 14, 15, 18, 19,
19, 21, 23, 23, 29, 37,
37, 54, 63, 66
Concurrence....... p.131, 139, 143
Condition................................... p.85
Constructeur........................... p.120
Contrainte............................... p.119
Contraintes........................ p.34, 63
Contrle............................. p.13, 94
CREATE INDEX..................... p.149
CREATE TABLE............. p.77, 119
CREATE TYPE............. p.117, 119
CREATE VIEW......................... p.79
Cration.................................... p.76
Dclaratif.................................. p.76
Dcomposition................ p.99, 103
Dfaillance............................. p.131
DELETE............................ p.82, 83
Dnormalisation........... p.149, 150
Dpendance.................... p.97, 103
Dverrouillage........................ p.142
DF
p.99, 100, 100, 101,
101, 101, 102, 103
Diagramme................ p.23, 28, 29
Dictionnaire.............................. p.17
Diffrence.................................. p.68
DISTINCT................................. p.84
Division..................................... p.72
Domaine............. p.46, 46, 47, 76
Donne...................................... p.13
Donnes..................................... p.14

Droits p.94
DROP p.80
Durabilit............................... p.134
Dynamique................................ p.34
E-A
p.14, 19, 21, 26, 27, 37,
37, 37, 39, 39, 40, 41,
64, 64, 65, 65, 66
Ecriture................................... p.141
Enregistrement.................. p.47, 48
Entit p.37, 40, 41, 64, 116
valuation.............................. p.148
EXCEPT.................................... p.87
Excution................................ p.132
EXISTS...................................... p.92
Externe............................... p.15, 71
Fermeture............................... p.101
Fonction.......................... p.88, 117
FOREIGN KEY......................... p.78
FROM p.84
FUNCTION............................ p.117
GRANT...................................... p.94
GROUP BY............................... p.89
Groupement............................ p.150
HAVING.................................... p.89
Hritage p.27, 32, 40, 57, 59,
59, 60, 61, 63, 65, 114,
117
IN
p.85, 91
Index p.149
INNER....................................... p.86
INSERT.............................. p.82, 82
INSERT INTO............... p.120, 123
Instance............................. p.14, 15
Inter-blocage................ p.143, 144
Interne....................................... p.15
INTERSECT.............................. p.87
Intersection............................... p.68
IOD p.123
IS NULL.................................... p.85
JOIN p.86
Jointure...................... p.70, 71, 71
Journal............... p.134, 135, 138
Langage...... p.13, 16, 82, 84, 90
LCD p.16, 94

181

Ouvrage de rfrence conseill

LDD p.16, 76, 114


Lecture.................................... p.141
LEFT p.86
Lien p.50, 50
LIKE p.85
LMD p.16, 82, 84, 90
Logique. p.9, 13, 14, 21, 45, 45,
46, 54, 63, 66, 85, 97,
103
Manipulation............................. p.67
MERISE..................... p.19, 21, 37
Mthode p.25, 112, 116, 116,
119, 121
Modle p.9, 13, 14, 21, 21, 37,
45, 46, 52, 53, 97, 103,
111
N:M p.117
Naturelle.................................... p.71
NESTED TABLE........... p.119, 122
NF
p.103
Nomalisation................... p.97, 103
Normalisation p.99, 99, 100,
100, 101, 101, 101, 102,
103, 103, 104, 104, 105,
109, 149
NOT p.85
NOT NULL................................ p.78
Objet p.110, 114, 115, 120
Occurence................................. p.14
OID p.115, 127
OMG p.23
Oprateur.................................. p.85
Opration........................... p.25, 46
Optimisation p.13, 97, 103, 147,
148
OR
p.85
Oracle p.133
ORDER BY................................ p.88

182

OUTER...................................... p.86
Panne p.134, 135, 135, 136,
137
Partitionnement...................... p.151
Passage.............. p.54, 63, 65, 66
Performance........................... p.148
Perte p.139
Physique............................ p.13, 14
PL/SQL......................... p.123, 133
Point de contrle p.135, 136, 137
PRIMARY KEY.......................... p.78
Problme................................... p.98
Produit....................... p.46, 47, 70
Projection........................ p.69, 151
Proprit.................... p.24, 30, 40
Question............................. p.84, 90
Redondance p.12, 97, 98, 103,
149
Rfrence...................... p.113, 115
REFERENCES.......................... p.78
Relation p.47, 47, 48, 48, 49,
50, 50, 52, 52
Relationnel p.11, 14, 21, 45, 45,
46, 46, 47, 52, 53, 54,
54, 55, 56, 56, 57, 57,
59, 59, 60, 61, 63, 63,
63, 64, 64, 65, 65, 66,
67, 67, 73, 97, 103, 109,
109
Relationnel-objet p.45, 46, 111,
124, 127
Requte...................... p.82, 84, 90
Restriction....................... p.69, 151
REVOKE................................... p.95
RIGHT....................................... p.86
ROLLBACK........ p.133, 135, 144
Schma p.9, 13, 15, 52, 53,
114, 147

Scurit..................................... p.13
SELECT........... p.84, 86, 86, 121
SGBD p.9, 11, 11, 12, 14
SGBDOO................................ p.110
SGBDRO............ p.111, 124, 127
SGBR p.13
Sous-requtes p.90, 91, 92, 92,
93
Spcifications............................ p.19
SQL p.16, 76, 82, 84, 90, 94,
117, 133
Table p.76
TABLE.................................... p.122
Table imbrique p.111, 113, 119,
122
Transaction. p.13, 132, 133, 134
Tri
p.88
Tuple p.47
Type p.14, 76, 112, 113, 114,
114, 116, 116, 117, 119
UML p.14, 19, 23, 23, 24, 24,
25, 27, 28, 29, 30, 31,
32, 34, 54, 54, 55, 56,
56, 57, 57, 59, 59, 60,
61, 63, 63, 63, 66
UNDO-REDO......................... p.137
Union p.68
UNION...................................... p.87
UNIQUE.................................... p.78
Unit p.132, 132, 135, 136
UPDATE............................ p.82, 83
Utilisateur................................. p.94
Validation............................... p.132
VBA p.134
Verrou p.141, 142, 142, 143,
144
Vue
p.151
WHERE...................... p.84, 86, 86

S. Crozat - UTC 2009