Pour Les De: Bases Données

soutou 15/02/12 11:31 Page 1
Christian Soutou est maître de conférences à l'université Toulouse II et consultant indépendant.

Christian Soutou
2ee édition
Rattaché à l'équipe MACAO du laboratoire IRIT et au département Réseaux et Télécoms de l'IUT de Avec la collaboration de Frédéric Brouard
Blagnac, il intervient autour des bases de données et des technologies de l'information (XML et Web
services) en licence et mastère professionnels, ainsi que pour le compte de la société Orsys. Il est également
l'auteur des ouvrages SQL pour Oracle et Programmer avec MySQL, parus aux éditions Eyrolles.
UML 2
Frédéric Brouard est spécialiste du langage SQL et des bases de données relationnelles. Il dirige
UML 2 pour les bases de données

UML 2
SQLspot, entreprise d'audit et de conseil de bases de données et de serveurs SQL, et intervient dans
différentes écoles (ISEN Toulon, Cesi Aix-en-Provence et Cesi Lyon, Cnam Toulon et université Toulouse II).
Distingué MVP (Most Valuable Professional) par Microsoft à titre d'expert SQL Server, il anime depuis plus
de 10 ans la célèbre rubrique sqlpro consacrée aux base de données et au langage SQL sur le site
www.developpez.com.
Concevoir une base de données grâce à UML 2

S'adressant aux architectes logiciels, chefs de projet, analystes, développeurs, responsables méthode et étudiants en
informatique, cet ouvrage explique comment utiliser à bon escient le diagramme de classes UML pour concevoir une base de
données, puis comment traduire correctement ce diagramme en langage SQL. Sa démarche est indépendante de tout éditeur
de logiciel et aisément transposable, quel que soit l'outil de conception choisi.
pour les
pour les
Le livre décrit d'abord la construction d’un diagramme de classes UML à l'aide de règles de validation et de normalisation.
Tous les mécanismes de dérivation d'un modèle conceptuel dans un schéma relationnel sont clairement commentés à l'aide
d'exemples concrets. Le modèle logique est ensuite optimisé avant l'écriture des scripts SQL. La dernière étape consiste à
implémenter les règles métier en programmant des contraintes, déclencheurs ou transactions SQL. Le livre se clôt par une
étude comparative des principaux outils de modélisation sur le marché.
bases de données
bases de données
Entièrement réécrite, cette deuxième édition est commentée par Frédéric Brouard, expert SQL Server et auteur de nombreux Modélisation - Normalisation
Modélisation - Normalisation
ouvrages et articles sur le langage SQL. Émaillée d'une centaine de schémas et d'illustrations, elle est complétée par 30
exercices inspirés de cas réels. Génération SQL - Outils
À qui s’adresse cet ouvrage ?
Génération SQL - Outils
• Aux étudiants en IUT, IUP, Deug et écoles d'ingénieur, ainsi qu’à leurs professeurs 2ee édition
• Aux professionnels souhaitant s'initier à la modélisation de bases de données avec UML
• À tous les concepteurs de bases de données désirant migrer de Merise à UML
Au sommaire
ISBN : 978-2-212-13413-1
Code article : G13413
Le niveau conceptuel. Analyse des besoins • Concepts majeurs • Identifiants • Associations binaires et n-aires • Classes-
782212 134131
C. Soutou
associations • Agrégations • Identification relative et artificielle • Héritage • Aspects temporels • Démarche à adopter •
Règles métier et contraintes • Règles de validation • Le niveau logique. Du conceptuel au relationnel • Typez vos
Avec 30
colonnes • Normalisation • Calculs de volumétrie • Le niveau physique. Le langage SQL • Passage du logique au exercices
physique • Programmation des contraintes • Dénormalisation • Le niveau externe. Vues relationnelles (SQL2) • Vues corrigés
9
matérialisées • Vues objet (SQL3) • Déclencheurs INSTEAD OF • Les outils du marché : de la théorie à la pratique.
29,90 €
soutou 15/02/12 11:31 Page 1
Christian Soutou est maître de conférences à l'université Toulouse II et consultant indépendant.

Christian Soutou
2ee édition
Rattaché à l'équipe MACAO du laboratoire IRIT et au département Réseaux et Télécoms de l'IUT de Avec la collaboration de Frédéric Brouard
Blagnac, il intervient autour des bases de données et des technologies de l'information (XML et Web
services) en licence et mastère professionnels, ainsi que pour le compte de la société Orsys. Il est également
l'auteur des ouvrages SQL pour Oracle et Programmer avec MySQL, parus aux éditions Eyrolles.
UML 2
Frédéric Brouard est spécialiste du langage SQL et des bases de données relationnelles. Il dirige

UML 2
SQLspot, entreprise d'audit et de conseil de bases de données et de serveurs SQL, et intervient dans
différentes écoles (ISEN Toulon, Cesi Aix-en-Provence et Cesi Lyon, Cnam Toulon et université Toulouse II).
Distingué MVP (Most Valuable Professional) par Microsoft à titre d'expert SQL Server, il anime depuis plus
de 10 ans la célèbre rubrique sqlpro consacrée aux base de données et au langage SQL sur le site
www.developpez.com.
Concevoir une base de données grâce à UML 2

S'adressant aux architectes logiciels, chefs de projet, analystes, développeurs, responsables méthode et étudiants en
informatique, cet ouvrage explique comment utiliser à bon escient le diagramme de classes UML pour concevoir une base de
données, puis comment traduire correctement ce diagramme en langage SQL. Sa démarche est indépendante de tout éditeur
de logiciel et aisément transposable, quel que soit l'outil de conception choisi.
pour les
pour les
Le livre décrit d'abord la construction d’un diagramme de classes UML à l'aide de règles de validation et de normalisation.
Tous les mécanismes de dérivation d'un modèle conceptuel dans un schéma relationnel sont clairement commentés à l'aide
d'exemples concrets. Le modèle logique est ensuite optimisé avant l'écriture des scripts SQL. La dernière étape consiste à
implémenter les règles métier en programmant des contraintes, déclencheurs ou transactions SQL. Le livre se clôt par une
étude comparative des principaux outils de modélisation sur le marché.
bases de données
bases de données
Entièrement réécrite, cette deuxième édition est commentée par Frédéric Brouard, expert SQL Server et auteur de nombreux Modélisation - Normalisation
Modélisation - Normalisation
ouvrages et articles sur le langage SQL. Émaillée d'une centaine de schémas et d'illustrations, elle est complétée par 30
exercices inspirés de cas réels. Génération SQL - Outils
Génération SQL - Outils
• Aux étudiants en IUT, IUP, Deug et écoles d'ingénieur, ainsi qu’à leurs professeurs 2ee édition
• Aux professionnels souhaitant s'initier à la modélisation de bases de données avec UML
• À tous les concepteurs de bases de données désirant migrer de Merise à UML
Au sommaire
ISBN : 978-2-212-13413-1
Code article : G13413
Le niveau conceptuel. Analyse des besoins • Concepts majeurs • Identifiants • Associations binaires et n-aires • Classes-
C. Soutou
associations • Agrégations • Identification relative et artificielle • Héritage • Aspects temporels • Démarche à adopter •
Règles métier et contraintes • Règles de validation • Le niveau logique. Du conceptuel au relationnel • Typez vos
Avec 30
colonnes • Normalisation • Calculs de volumétrie • Le niveau physique. Le langage SQL • Passage du logique au exercices
physique • Programmation des contraintes • Dénormalisation • Le niveau externe. Vues relationnelles (SQL2) • Vues corrigés
matérialisées • Vues objet (SQL3) • Déclencheurs INSTEAD OF • Les outils du marché : de la théorie à la pratique.
soutou titre 9/02/12 10:53 Page 2
UML 2
pour les
bases de données
2e édition
dU même AUTEUR
C. Soutou. – SQL pour Oracle (5e édition).

N°13329, 2011, 720 pages.
C. Soutou. – Programmer avec MySQL.

N°12869, 2011, 450 pages.
Autres ouvrages
P. Roques. – Mémento UML 2.4 (2e édition).

N°13268, 2011, 14 pages.
P. Roques. – UML 2 par la pratique (7e édition).

N°12565, 2009, 396 pages.
P. Roques. – UML 2 par la pratique (6e édition).

N°13344, 2011, 370 pages (format semi-poche).
P. Roques et F. Vallée. – UML 2 en action (4e édition).

N°12104, 2007, 396 pages.
H. Balzert. – UML 2.
N°11753, 2006, 88 pages.
F. Vallée. – UML pour les décideurs.

N°11621, 2005, 282 pages.
H. Bersini. – La programmation orientée objet. Cours et exercices en UML 2 avec Java 6, C# 4, C++, Python, PHP 5 et LinQ.
N°12806, 2011, 644 pages.
P. Roques. – Mémento PHP 5 et SQL (2e édition).

N°12457, 2009, 14 pages.
p2 Soutou.indd 1 15/02/12 09:13

soutou titre 9/02/12 10:53 Page 1
Christian Soutou
UML 2
pour les
bases de données
2e édition
ÉDITIONS EYROLLES
61, bd Saint-Germain
75240 Paris Cedex 05
www.editions-eyrolles.com
En application de la loi du 11 mars 1957, il est interdit de reproduire intégralement ou partiellement le présent ouvrage,
sur quelque support que ce soit, sans l’autorisation de l’Éditeur ou du Centre Français d’exploitation du droit de copie,
20, rue des Grands Augustins, 75006 Paris.
© Groupe Eyrolles, 2007, 2012, ISBN : 978-2-212-13413-1
Copyright Soutou.indd 1 15/02/12 09:12

À Louise et Émile-Barthélémy, mes grands-parents,
à Élisabeth, ma mère,
pour Paul, mon fils.
Livre SOUTOU.indb 3 15/02/12 07:04

Table des matières
Avant-propos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Évolution des modèles de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Les fichiers et COBOL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Le modèle hiérarchique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Le modèle réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Le modèle relationnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
À qui s’adresse cet ouvrage ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Comment utiliser UML pour les bases de données ? . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Les diagrammes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Les outils. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Guide de lecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Niveau conceptuel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Transformation et normalisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Écriture des scripts SQL et programmation des contraintes. . . . . . . . . . . . . . . . . . . . . . . . . 9
Les vues SQL2 et SQL3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Les outils du marché . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Annexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Les pictogrammes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Contact avec l’auteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1 Le niveau conceptuel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Analyse des besoins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Premiers exemples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Le jargon du terrain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Ne confondez pas traitements et données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Le dictionnaire des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Les concepts majeurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Un peu d’histoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
© Éditions Eyrolles V

UML 2 pour les bases de données Table des matières
D’autres formalismes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Terminologie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Attribut ou information ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Classe ou entité ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Les identifiants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Qui dit libellé, dit identifiant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Concrets ou abstraits ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Artificiels ou naturels ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Plusieurs, c’est possible ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Les associations binaires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Multiplicités versus cardinalités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Le maximum est prépondérant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Le minimum est-il illusoire ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Réflexivité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Les rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Mise en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Les associations plus complexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Les classes-associations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Premier exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Formalismes entité-association. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Rattacher une classe-association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Classe-association réflexive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Mise en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Les associations n-aires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Savoir les interpréter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Le langage du formalisme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Quelques bêtises du Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Quelques cas valides. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Comment se prémunir ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Mise en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Les agrégations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
L’identification relative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Notations avec Merise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Réification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Exemples avec UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Mise en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
L’identification artificielle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Mise en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
VI © Éditions Eyrolles

Table des matières UML 2 pour les bases de données
L’héritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Identification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Instances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Héritage multiple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Mise en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Aspects temporels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Modélisation d’un moment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Modélisation de chronologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Modélisation de l’historisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Mise en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
La démarche à adopter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Décomposition en propositions élémentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Propositions incomplètes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Chronologie des étapes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Quelques conseils. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Les erreurs classiques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Les concepts inutiles de UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Un seul schéma valable ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Règles métier et contraintes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Contraintes prédéfinies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Contraintes personnalisées (langage OCL). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Contraintes d’héritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Mise en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Règles de validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Les dépendances fonctionnelles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Vérification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Première forme normale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Deuxième forme normale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Troisième forme normale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Forme normale de Boyce-Codd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Forme normale domaine-clé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Quatrième et cinquième formes normales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Mise en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Bilan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Exercices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
2 Le niveau logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Concepts du niveau logique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Du conceptuel au relationnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Transformation des classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
© Éditions Eyrolles VII

Transformation des associations un-à-plusieurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Transformation des associations plusieurs-à-plusieurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Cas particuliers des associations binaires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Transformation des classes-associations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Transformation de l’héritage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
La solution « universelle ». . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Les transformations à éviter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Traduire ou ne pas traduire ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Mise en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Typez vos colonnes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
La normalisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Dépendances fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Mise en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Calculs de volumétrie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Exercices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
3 Le niveau physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Le langage SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Les schémas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Schémas SQL ou bases ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Schémas et propriétaires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Les contraintes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Passage du logique au physique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Traduction des relations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Traduction des associations un-à-plusieurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Traduction des associations un-à-un. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Traduction des associations réflexives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Traduction des agrégations (composition). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Traduction des associations plusieurs-à-plusieurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Solution universelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Mise en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Programmation des contraintes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Héritage par distinction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Héritage en push-down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Héritage en push-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Contraintes multitables (assertions). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Contraintes prédéfinies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Contraintes personnalisées. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Mise en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
VIII © Éditions Eyrolles

Dénormalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Les règles de Brouard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Mise en pratique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Exercices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
4 Le niveau externe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Les vues relationnelles (SQL2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Création d’une vue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Classification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Vues monotables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Vues complexes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Vues modifiables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Confidentialité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Simplification de requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Contrôles d’intégrité référentielle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Dénormalisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Les vues matérialisées. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Réécriture de requêtes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Création d’une vue matérialisée. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Le rafraîchissement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Les vues objet (SQL3). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Étapes à respecter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Vue contenant une collection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Rendre une vue modifiable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Programmer des méthodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Les déclencheurs INSTEAD OF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Mise à jour d’une vue complexe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Mise à jour d’une vue multitable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Mise à jour de tables et vues objet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
5 Les outils du marché : de la théorie à la pratique. . . . . . . . . . . . . . . . . . . . . . . . 243

MagicDraw. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
MEGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Identifiants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Associations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Génération du modèle relationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Génération des tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Rétroconception. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
© Éditions Eyrolles IX

Modelio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Identifiants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Associations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Objecteering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Identifiants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Associations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
PowerAMC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Identifiants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Associations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Héritage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Rational Rose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Identifiants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Visual Paradigm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Win’Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Identifiants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Associations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Héritage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
A Corrigés des exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Exercice 1.1 – La déroute des bleus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Associations binaires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Classe-association. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Historique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Exercice 1.2 – L’organisme de formation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Inscriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Plannings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
X © Éditions Eyrolles

Exercice 1.3 – Les lignes de facture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

Exercice 1.4 – La décomposition des n-aires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Visite des représentants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Stages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Cote automobile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Horaires d’une ligne de bus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Exercice 1.5 – Les comptes bancaires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Associations binaires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Identification relative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Identification artificielle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Exercice 1.6 – Le RIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Exercice 1.7 – L’organisme de formation (suite). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Salles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Exercice 1.8 – L’héritage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Organisme de formation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Comptes bancaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Exercice 1.9 – Les cartes grises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Ancien régime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Coût du cheval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Nouvelle numérotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Contrôles techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Exercice 1.10 – Les contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Déroute des bleus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Organisme de formation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Comptes bancaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Exercice 1.11 – La carte d’embarquement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Exercice 1.12 – Deux cafés et l’addition ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Exercice 1.13 – La thalasso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Exercice 1.14 – Le centre de plongée. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Exercice 1.15 – L’élection présidentielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Membres des partis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Résultats des élections passées. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Titre suprême. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Exercice 2.1 – Les associations binaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Exercice 2.2 – L’héritage et la composition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Exercice 2.3 – Les classes-associations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Exercice 2.4 – Traduire ou ne pas traduire ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Exercice 2.5 – La normalisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
© Éditions Eyrolles XI

Exercice 3.1 – La création de tables (carte d’embarquement) . . . . . . . . . . . . . . . . . . . . 300

Exercice 3.2 – La création de tables (horaires de bus) . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Exercice 3.3 – La programmation de contraintes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Carte d’embarquement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Horaires des bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
E-mails des clients et prospects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Exercice 3.4 – La dénormalisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Carte d’embarquement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Horaires des bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Exercice 3.5 – Ma psy oublie tout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Rendez-vous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Confrères et livres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Exercice 3.6 – Le planning d’une école de pilotage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Flotte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Acteurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Rendez-vous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
B Ressources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Webographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Bibliographie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
XII © Éditions Eyrolles

Avant-propos
Le but de cet ouvrage est d’expliquer tout d’abord comment utiliser à bon escient le diagramme
de classes UML pour concevoir une base de données, puis comment maîtriser la traduction
de ce diagramme en script SQL permettant de générer des tables normalisées. La démarche
proposée dans ce livre est indépendante de tout éditeur de logiciel et aisément transposable
quel que soit l’outil de conception que vous adopterez.
Entièrement réécrite, cette deuxième édition est émaillée de nombreux cas concrets présentés
sous forme d’exercices. Le texte est par moments commenté par Frédéric Brouard alias SQLPro,
consultant indépendant et expert en bases de données (MS SQL Server en particulier).
Évolution des modèles de données

Avant de rentrer dans le vif du sujet, rappelons brièvement comment nous sommes arrivés à
des bases de données essentiellement relationnelles. Avant elles, l’informatique existait bien
Figure 0-1. Historique des bases de données
© Éditions Eyrolles 1

sûr ; Apollo 11 a été envoyé sur la lune en juillet 1969 avant qu’E. Codd publie ses écrits sur le
modèle relationnel. À l’époque, la conception des données se faisait avec bon sens, depuis, les
chercheurs ont amené des cadres plus formels. À vous de toujours conserver votre bon sens,
tout en utilisant ces cadres.
Les fichiers et COBOL

Le stockage des données a commencé dans les années 1960 avec les systèmes de gestion de
fichiers et le langage COBOL (Common Business Oriented Language). Loin d’être dépassé, ce
dernier fut le plus utilisé entre 1960 et 1980. En 2002, il permet une programmation de type
objet, la gestion des informations Unicode et une intégration avec XML. En 2005, le Gartner
Group estimait que COBOL manipulait près de 75 % des données de gestion stockées.
Le principal inconvénient des applications COBOL est la forte dépendance qui existe entre les
données stockées et les traitements. En effet, le fait de déclarer dans chaque programme les
fichiers utilisés impose une maintenance lourde si la structure d’un fichier doit être modifiée.
De plus, les instructions de manipulation (ouverture, lecture, écriture et modification) sont très
liées à la structure de chaque fichier. La structure des fichiers de données s’apparente à celle
d’une table (suite de champs de types numériques ou alphanumériques).
Le modèle hiérarchique
Les bases de données hiérarchiques ont introduit un modèle de données du même nom. Il s’agit
de déterminer une arborescence de données où l’accès à un enregistrement de niveau inférieur
n’est pas possible sans passer par le niveau supérieur. Promus par IBM et toujours utilisés dans
le domaine bancaire, les SGBD hiérarchiques souffrent toutefois de nombreux inconvénients.
La figure suivante illustre un modèle hiérarchique de données dans lequel des compagnies
aériennes peuvent embaucher plusieurs pilotes. Un pilote peut travailler pour le compte de
différentes compagnies.
Figure 0-2. Modèle de données hiérarchique
2 © Éditions Eyrolles

Avant-propos
Les inconvénients récurrents sont toujours la forte dépendance entre les données stockées et
les méthodes d’accès. Les chaînages internes impliquent forcément une programmation com-
plexe. Outre ces problèmes de programmation, ce modèle montre des lacunes lors de l’accès
à la base.
●● Extraire la liste des pilotes implique le parcours de toutes les compagnies.
●● L’insertion peut se révéler problématique : l’ajout d’un pilote sans compagnie n’est pas
possible, à moins d’ajouter une compagnie fictive.

●● La suppression peut se révéler dangereuse : une compagnie disparaît, alors de fait ses
pilotes aussi.
●● La modification est souvent problématique : les incohérences proviennent d’éventuelles
redondances (le nom ou l’adresse d’un pilote qui change doit se répercuter à tous les enre-
gistrements).
Bien qu’il existe de nombreuses hiérarchies autour de nous, le monde qui nous entoure n’est
pas un arbre !
Le modèle réseau
Quelques années plus tard, C. W. Bachman, pionnier dans le domaine de l’informatique, s’est
essayé aux bases de données en inventant un modèle brisant cette hiérarchie plutôt arbitraire.
Les bases de données réseau étaient nées avec le modèle CODASYL, première norme décidée
sans IBM.
Figure 0-3. Modèle de données réseau

Bien que résolvant quelques limitations du modèle hiérarchique et annonçant des perfor-
mances en lecture honorables, le modèle réseau n’est ni plus ni moins qu’une usine à gaz gavée
de pointeurs. Pour preuve, plus personne n’utilise de tels SGBD où la dépendance entre les
données stockées et les méthodes d’accès existe toujours, et l’évolution d’une base de données
est très coûteuse en termes de recompilation de pointeurs.
Soyons honnêtes, le monde ressemble bien à une telle usine à gaz ! Mais pas question de
stocker ainsi les données, ce serait bien trop compliqué de concevoir le bon graphe. Le modèle
de données se doit d’être plus simple.
Le modèle relationnel
En 1970, E. Codd publie l’article de référence posant les bases du modèle relationnel [COD
70]. D’un seul coup, toutes les limitations des précédents modèles sont résolues. Le but initial
de ce modèle était d’améliorer l’indépendance entre les données et les traitements. Cet aspect
des choses est réussi et avec ça d’autres fonctionnalités apparaissent :
●● Normalisation (dépendances fonctionnelles) et théorie des ensembles (algèbre relation-
nelle).
●● Cohérence des données (intégrité référentielle).
●● Langage SQL (déclaratif et normalisé).
●● Accès aux données optimisé (choix du chemin par le SGBD).
●● Indexation, etc.
Les liens entre les enregistrements de la base de données sont réalisés non pas à l’aide de poin-
teurs physiques, mais à l’aide des valeurs des clés étrangères et des clés primaires. Pour cette
raison, le modèle relationnel est dit « modèle à valeurs ».
Figure 0-4. Modèle de données relationnel

Avant-propos
La force de ce modèle de données réside dans le fait qu’il repose sur des principes simples et
permet de modéliser des données complexes. Le modèle relationnel est à l’origine du succès
que connaissent aujourd’hui les grands éditeurs de SGBD, à savoir Oracle, IBM, Microsoft et
Sybase dans différents domaines :
●● OLTP (OnLine Transaction Processing) où les mises à jour des données sont fréquentes,
les accès concurrents et les transactions nécessaires.
●● OLAP (Online Analytical Processing) où les données sont multidimensionnelles (cubes),
les analyses complexes et l’informatique décisionnelle.
●● Systèmes d’information géographiques (SIG) où la majorité des données sont exprimées en
2D ou 3D et suivent des variations temporelles.
Comment concevoir de telles relations ? C’est ce que nous allons voir tout au long de cet
ouvrage…
Cet ouvrage s’adresse à toutes les personnes qui s’intéressent à la modélisation et à la conception
des bases de données.
●● Les architectes, chefs de projet, analystes, développeurs et responsables méthode habitués
au modèle entité-association y trouveront les moyens de raisonner avec le diagramme de
classes UML.
●● Les novices découvriront une méthode de conception, des règles de normalisation et de
nombreux exercices mettant en jeu tous les niveaux du processus d’une base de données.
Comment utiliser UML pour les bases de données ?

Depuis plus de 30 ans, la conception des bases de données s’appuie sur un formalisme
graphique appelé entité-association que la méthode Merise avait adopté en son temps. Ce for-
malisme a fait ses preuves et bon nombre d’outils de modélisation destinés aux francophones
l’utilisent encore aujourd’hui.
La notation UML s’est imposée depuis quelques années pour la modélisation et le développe-
ment d’applications écrites dans un langage objet (C++ et Java principalement). Les entreprises
du consortium initial ayant mis en place UML étaient DEC, HP, IBM, Microsoft, Oracle et
Unisys pour parler des plus connues. Le marché a suivi cette tendance car, aujourd’hui, tous
les outils de modélisation utilisent cette notation.

L’adoption généralisée de la notation UML dépasse le simple effet de mode. La majorité des
nouveaux projets industriels utilisent la notation UML. Tous les cursus universitaires, qu’ils
soient théoriques ou plus techniques, incluent l’étude d’UML. Cela ne signifie pas qu’UML
soit la panacée, mais que cette notation est devenue incontournable. La dernière version de
la spécification UML, sortie en mai 2010, est la 2.3 (http://www.omg.org/spec/UML/2.3/).
Ce succès s’explique aussi par l’adoption unanime des concepts objet, qui ont des avantages
indéniables (réutilisabilité de composants logiciels, facilité de maintenance, prototypage et
extension des applications, etc.).
Les diagrammes
Les versions 1.x de la notation UML définissent neuf diagrammes : cinq pour les aspects
statiques (classes, objets, cas d’utilisation, composants et déploiement) et quatre pour les
aspects dynamiques (séquence, collaboration, états-transitions, activités). Les spécifications
d’UML 2.x ajoutent le diagramme d’interaction, le diagramme de structure composite et le
diagramme temporel. Seul le diagramme de classes est intéressant à utiliser pour la modéli-
sation d’une base de données.
UML concerne en premier lieu le développement logiciel et n’a pas été initialement pensé
pour les bases de données. La notation UML permet toutefois d’offrir un formalisme aux
concepteurs d’objets métier et aux concepteurs de bases de données. D’autre part, les
concepts relatifs à la modélisation de données (entités, associations, attributs et identifiants)
peuvent être parfaitement intégrés aux diagrammes de classes. De plus, d’autres concepts
(notamment les classes-associations, agrégats et contraintes) permettent d’enrichir un
schéma conceptuel.
Les outils
De nombreux outils informatiques basés sur la notation UML existent depuis quelques
années. Les plus sophistiqués permettent de générer des modèles logiques ou des scripts
SQL. Alors que l’automatisation est quasiment assurée (sous réserve de la qualité de l’outil)
entre le modèle conceptuel et la base de données, il n’en est pas de même de l’élaboration du
diagramme initial qui va conditionner toute la suite. Ici l’humain est au centre de tout et il
n’est pas question de penser que cette tâche puisse être automatisée (c’est heureux pour les
concepteurs).
Par ailleurs, il est fort probable que les scripts SQL générés devront être modifiés manuelle-
ment par la suite, soit pour des raisons d’optimisation, soit parce que l’outil ne permet pas de
générer une caractéristique particulière du SGBD (index, vues, types de données...), soit tout
simplement parce que le concepteur préfère utiliser une autre possibilité d’implémentation
pour traduire telle ou telle autre association.
Il est donc préférable de maîtriser les concepts, de comprendre les mécanismes de trans-
formation de modèles et d’adopter une démarche afin d’utiliser l’outil de manière optimale.

Avant-propos
Cet ouvrage vous permettra, je l’espère, de mieux appréhender le cheminement de la concep-

tion vers le codage en donnant des règles précises à suivre dans l’élaboration des différents
modèles pour éviter de graves erreurs au niveau de la base. Le script SQL fera office de véri-
table révélateur.
Figure 0-5. Diagramme de classes
Guide de lecture
Cet ouvrage s’organise en 5 chapitres qui suivent les étapes de modélisation illustrées dans la
figure suivante.

Figure 0-6. Niveaux de conception et d’implémentation
L’ouvrage commence par décrire la construction d’un diagramme de classes UML en respec-
tant des règles qui permettent de le valider et de le normaliser. Les mécanismes de dérivation
d’un modèle conceptuel dans un schéma de données relationnel sont clairement expliqués à
l’aide d’exemples concrets. Le modèle logique est ensuite optimisé avant l’écriture des scripts
SQL. Il s’agit ensuite d’implémenter les règles métier en programmant des contraintes ou des
déclencheurs SQL. La dernière étape consiste à préparer des vues qui composeront l’interface
de la base aux utilisateurs extérieurs.

Avant-propos
Niveau conceptuel
Le chapitre 1 décrit la première étape du processus de conception d’une base de données,
à savoir la construction d’un schéma conceptuel. Le formalisme graphique préconisé est le
diagramme de classes de la notation UML qui permet des équivalences des modèles de type
entité-association.
Transformation et normalisation
Le chapitre 2 décrit les concepts du modèle relationnel, puis présente les règles qui permettent
de dériver un schéma logique à partir d’un modèle conceptuel. La dernière partie traite de la
normalisation et du calcul de volumétrie.
Écriture des scripts SQL et programmation des contraintes

Le chapitre 3 décrit la mise en œuvre pour écrire un script SQL dérivé d’un modèle de données
relationnel. Le niveau physique présenté dans ce chapitre correspond à la définition des tables,
des clés étrangères ainsi que l’implémentation des éventuelles règles métier par des contraintes
de clés, de validation ou par déclencheurs.
Les vues SQL2 et SQL3

Le niveau externe décrit au chapitre 4 correspond à la définition de vues qui agissent comme
des fenêtres sur la base de données. Ce chapitre décrit les différents types de vues existantes
(vues relationnelles SQL2, vues matérialisées et vues objet SQL3).
Les outils du marché

Le chapitre 5 confronte l’offre des principaux outils UML du marché (MagicDraw, MEGA
Designer, Modelio, Objecteering, PowerAMC, Rational Rose, Visual Paradigm et Win’De-
sign). Chaque outil est évalué sur différents critères (saisie d’un diagramme de classes,
génération d’un modèle relationnel, d’un script SQL et rétroconception d’une base de
données).
Annexes
Les annexes contiennent les corrigés détaillés des exercices, une webographie et une biblio-
graphie. L’index propose les termes utilisés dans la définition des concepts et de certaines
instructions SQL.

Les pictogrammes
Ce pictogramme introduit une définition, un concept ou une remarque importante.
Ce pictogramme indique une astuce ou un conseil personnel.
Ce pictogramme introduit une remarque, un avis divergent, un complément ou un coup

de gueule de Frédéric Brouard.
Contact avec l’auteur

Si vous avez des remarques à formuler sur le contenu de cet ouvrage, n’hésitez pas à m’écrire
(christian.soutou@gmail.com). Vous trouverez sur le site d’accompagnement de cet ouvrage
accessible par la fiche du livre sur www.editions-eyrolles.com, les errata ainsi que d’éven-
tuelles discussions.
Vous pouvez aussi poster des questions sur vos modèles sur http://www.developpez.net/
forums/f940/general-developpement/conception/modelisation/, de nombreux contributeurs
s’y retrouvent.

Chapitre 1
Le niveau conceptuel
Ce chapitre détaille la première étape de conception d’une base de données : il s’agit d’élaborer
un schéma conceptuel. Bien que le formalisme graphique préconisé soit le diagramme de
classes de la notation UML, vous trouverez toutes les équivalences avec les modèles de type
entité-association.
La modélisation est un processus à la fois incontournable et crucial. Incontournable, car même
si vous maîtrisez le modèle relationnel et connaissez parfaitement l’environnement à auto-
matiser, vous ne pouvez pas raisonnablement créer directement les tables. Crucial, car cela
conditionne la structure de la base de données et donc influencera les performances à venir.
Ce travail d’abstraction concerne toute nouvelle conception et il est naturel d’y consacrer du
temps.
Le schéma conceptuel exprime une vue abstraite de la base de données qui, afin de préserver
l’indépendance données/traitements, ne comporte aucune indication relative aux structures de
stockage ou techniques d’accès aux données.
L’objectif d’un schéma conceptuel n’est pas de décrire complètement un système, mais de
modéliser dans un premier temps les données qui seront stockées. Par ailleurs, des règles
métier peuvent enrichir un schéma conceptuel afin de préparer au mieux la programmation
des applications.
Il faut comprendre que la modélisation conceptuelle à base de classe ou d’entité repré-

sente les aspects sémantiques du modèle de données, tandis que le modèle physique à
base de tables est une lecture purement technique de la base. Malheureusement, il est
de plus en plus fréquent de voir des informaticiens ignorer la modélisation conceptuelle
pour s’engouffrer directement sur le physique. C’est une erreur gravissime qui a des
conséquences profondes et durables, comme la mauvaise interprétation du modèle ou la
création de tables obèses.

Pour faire comprendre pourquoi il est fréquent de mal interpréter un modèle physique, je montre à mes
étudiants deux tables « voiture » et « personne » avec un lien 1:n de voiture vers personne et je leur
demande ce que ce modèle décrit. Il y a pratiquement autant de réponses que d’étudiants, mais jamais
la bonne !
Imaginez ce que cela peut donner en entreprise quand la base de données doit être utilisée par de nom-
breux informaticiens pour développer une même application, chacun ayant sa propre interprétation des
liens entre les tables…
Enfin, en ce qui concerne l’arrivée de tables obèses, elle est liée à la non-utilisation du modèle conceptuel.
Combien de fois ai-je entendu un développeur demander « J’ai une nouvelle information à stocker, je la
rattache à quelle table ? » avec à la fin des tables de 80 colonnes inexploitables et contre-performantes
lors de la montée en charge…
À lire : http://blog.developpez.com/sqlpro/p10070/langage-sql-norme/base-de-donnees-et-performances-
petites.
Analyse des besoins

Ne perdez jamais de vue que seules les données à stocker sont la partie à faire émerger de
l’analyse. Le processus d’analyse s’alimente de plusieurs éléments et événements : cahier des
charges, interviews, documents, formulaires, observation de l’existant (faits et événements),
textes légaux, etc.
Le premier résultat de cette phase est le dictionnaire des données qui recense toutes les infor-
mations (avec quelques caractéristiques comme le nom de la donnée, une désignation d’un
éventuel domaine de valeurs, l’unité de mesure souvent oubliée – €, litre, mètre, etc.) qu’il
faudra stocker. Le résultat final est la mise en diagramme, d’une manière optimale, de toutes
ces données.
Premiers exemples
Une organisation
Considérons le club de plongée qui décide d’abandonner la gestion papier de toutes ses pres-
tations. L’analyse va consister à recenser ses biens matériels, comprendre le fonctionnement
de la gestion des clients et comptabiliser les sorties des bateaux, etc. La visite des sites et la
rencontre avec chaque intervenant seront très instructives (accueil, pilote du bateau, moniteurs
et directeur de plongée) ; elles permettront de bien appréhender le contexte. L’étude de docu-
ments papier permet souvent une investigation plus approfondie : le carnet de bord d’un bateau
pour se rendre compte du nombre de sorties par jour, des cartes pour recenser les sites, les
habitudes ou réglementations associées, etc.

Chapitre 1 Le niveau conceptuel
Figure 1-1. Le club de plongée
Sans vous jeter à l’eau (elle était facile celle-là…), vous devez pousser chaque expert dans son
domaine à le faire.
Un texte de loi
Considérons le texte suivant où différentes informations sont présentes au sein d’un même
contenu. Supposons que les textes de loi soient numérisés et stockés sur un serveur ministériel.
Le contexte d’analyse est, par exemple, restreint à la recherche d’un texte en particulier.
Figure 1-2. Exemple d’extrait d’un texte légal
Il apparaît un numéro d’article, un numéro de loi ou de décret (il s’agira donc de prendre en
compte un type de document), la date de la loi ou du décret. Par ailleurs, les termes « portant
droits » et « relatif » vous amèneront à prendre en compte une donnée modélisant les mots-clés
d’un article ou décret. Enfin, le verbe « abroger » implique d’affecter un statut à chaque article
ou loi (abrogé ou pas).
Une interface graphique

L’analyse d’une interface (prévisionnelle ou existante) peut se révéler un très bon moyen de
déduire la pertinence d’informations. Dans l’interface suivante, qui décrit des services offerts
par des supermarchés, plusieurs informations seront à stocker.
A. Les codes postaux.

B. Les localités associées à un code postal saisi.

C. Le nom du magasin (et celui de sa ville) ainsi qu’un kilométrage.
D. Les types de services.
E. Un libellé et une date associés à chaque type de service pour un magasin choisi.
F. Un nombre de produits pour un magasin choisi.
Figure 1-3. Exemple d’interface de saisie
Le jargon du terrain
Lors de cette analyse, vous constaterez que le jargon du terrain n’est pas toujours clair. Chaque
domaine a ses experts et son vocabulaire. Par exemple, des simples notions comme une date,
une durée ou un prix ne seront probablement pas perçues de la même manière dans un contexte
financier ou des travaux publics.
Si vous devez concevoir une base de données, mieux vaut ne pas connaître le domaine ou
feindre de n’y rien comprendre afin que votre connaissance partielle ne vienne pas perturber
la réalité du système. À titre d’exemple, supposons que vous soyez copropriétaire et que vous
assistiez depuis de nombreuses années aux réunions houleuses organisées par votre cher (dans
les deux termes ?) syndic. Un jour, vous avez en charge d’informatiser un autre syndic (dom-
mage…). Vous constaterez sans doute que le fonctionnement de votre client est très différent
de celui que vous supposiez. Ainsi, il est probable que cela vous pénalise davantage que si vous
étiez novice dans ce domaine de l’immobilier.
Deux démarches sont à mener de front (oui, avec sa tête !) :
●● déductive : vous devrez décortiquer le discours en informations élémentaires ;
●● inductive : vous mettrez en évidence à partir des concepts du discours des informations.
Avec l’expérience, vous analyserez les choses de cette manière.

Questionnez les experts du domaine en reformulant souvent vos interrogations. N’hésitez pas
à changer d’interlocuteur afin d’avoir des points de vue complémentaires. Investiguez jusqu’au
moment où vous obtiendrez une réponse unique et sans ambiguïté à chacune de vos questions.
Le tableau suivant présente quelques questions qui ne peuvent être résolues par l’étude seule
de documents initiaux (photos, fragments de texte et interface graphique) des trois exemples
précédents. Vous devrez obtenir une réponse précise à chacune de ces questions.
Tableau 1-1 : Questions additionnelles
Club de plongée ●● Un bateau peut-il sortir plusieurs fois par jour ?

●● Un client peut-il plonger plusieurs fois par jour ?
●● Quel type de matériel est disponible en location ?
●● Les tarifs sont-ils identiques sur chaque site de plongée ?
Textes de loi ●● Un texte de loi peut-il être associé à plusieurs mots-clés ?
●● Si la première réponse est affirmative, doit-on privilégier un mot-clé parmi plusieurs ?
●● Chaque texte de loi est-il numérisé dans un ou plusieurs fichiers ?
Supermarchés ●● Jusqu’à quel kilométrage considère-t-on un supermarché dans le rayon d’un autre (pour les
présenter sur le même écran) ?
●● Un supermarché peut-il n’avoir aucun service à proposer ?
●● Existe-t-il un nombre plancher de produits en vente ?
Lors de la phase d’analyse, il est souvent difficile de « faire cracher le morceau aux inter-
viewés ». En effet, ils sont tellement dans leur univers qu’ils n’envisagent même pas qu’un
tiers, spécialiste de l’information et qui est plongé dans leur univers, puisse ignorer à ce
point leur métier. Ils ont donc souvent des difficultés à faire comprendre ou à simplifier
les règles qui les régissent ou qu’ils ont eux-mêmes créées. Pour s’en convaincre, il n’y a
qu’à voir la réaction de non-informaticiens lorsqu’ils participent à une discussion entre
développeurs passionnés !
C’est pourquoi la maîtrise du vocabulaire client est essentielle et déterminante. Je com-
mence toujours par cette phase, et je note et apprends par cœur les définitions techniques…
Au cours de la phase d’analyse par interview, il est probable qu’il y ait toujours des zones
d’ombre, notamment sur les règles de gestion, même lorsque les explications viennent de
plusieurs sources. Dans ce cas, je fais mon simplet en revenant le soir ou le lendemain
avec une question-affirmation prenant l’exact contraire de ce que j’ai pu comprendre, par
exemple : « Si j’ai bien compris, l’allotement résiduel ne peut être induit que par un tiers
au contrat… ». À ce moment-là, à tous les coups, mon interlocuteur rétorque : « Mais,
non… j’ai dû mal m’expliquer… je vais prendre un autre exemple… »
En général, là vous avez gagné… car on progresse plus de ses erreurs que de ses réussites !

Ne confondez pas traitements et données

Quelques-unes de vos premières interrogations relèveront peut-être davantage des traitements
que des données. Avec l’expérience, vous les éluderez petit à petit pour rester concentré sur la
base de données cible de toutes vos attentions.
Les questions relatives aux traitements n’ont pas, en principe, d’influence sur la structure de
la base, mais concerneront les transactions en charge d’implémenter chaque fonctionnalité.
Il revient au développeur de les prendre en compte. Si vous avez la double casquette du
concepteur et du développeur, vous gagnerez certainement du temps à vous occuper à la fois
de la base et des programmes.
Le tableau suivant présente quelques questions qui ne concernent que des traitements. Si vous
êtes en charge de la programmation, vous devrez probablement les implémenter dans le code.
Tableau 1-2 : Questions relatives aux traitements
Club de plongée ●● Si la météo n’est pas bonne, aucun bateau ne sort.

●● Un plongeur peut disposer de son propre matériel sans rien louer.
Textes de loi ●● Quelle est la différence entre une loi et un décret ?
●● Qui signe un texte de loi ?
●● Quels sont les décrets les plus récents ?
Supermarchés ●● Quelle est la période de mise à jour des informations qui apparaissent sur le site ?
●● Que doit-on afficher sur le site si un magasin est en grève ?
Le dictionnaire des données

La première phase de l’analyse doit aboutir à la production du dictionnaire de données. Ce
document recense, de manière exhaustive, les données à stocker.
La figure suivante illustre un extrait de la liste des attributs (obtenue à l’aide de l’outil PowerAMC
de Sybase) de l’exemple des supermarchés. Nous reviendrons ultérieurement à la problématique
qui consiste à choisir le type de données le plus adéquat.
Figure 1-4. Liste des attributs avec PowerAMC

La majorité des outils de conception permettent de générer des rapports, plus ou moins
détaillés, listant les données du domaine associées à certaines caractéristiques importantes :
●● identificateur (nom de la donnée) ;
●● désignation (explication en quelques mots ou lignes de la sémantique de la donnée) ;
●● type de la donnée (chaîne de caractères, date, numérique, réel, booléen…) ;
●● caractère obligatoire ou facultatif.
D’autres caractéristiques moins importantes peuvent préciser la nature des données (contrainte
de valeur, minimum, maximum, intervalle, valeur calculée…).
La figure suivante illustre un extrait d’un rapport généré à l’aide de l’outil PowerAMC.
Figure 1-5. Rapport du modèle des données avec PowerAMC
Les concepts majeurs

Par analogie avec le modèle relationnel qui propose peu de concepts (colonnes, tables et clés)
pour constituer une base de données (de la plus simple comme la facturation d’une PME à la plus
stratégique comme celle d’une place boursière ou d’une centrale nucléaire), le modèle conceptuel
dispose seulement de trois concepts majeurs pour modéliser toute chose. Bien que le monde ne
soit ni un arbre, ni un graphe comme je l’ai entendu, l’utilisation de ces concepts suffit.
Ces concepts majeurs sont les attributs, les entités (classes) et les associations (munies de leurs
cardinalités). Pour chaque concept, il existe des nuances : un attribut peut être identifiant ou
pas, une association peut être binaire ou d’héritage, etc. En combinant astucieusement chacun

de ces concepts, vous serez en mesure de concevoir votre base de données quel que soit le
domaine d’application.
Une erreur courante… Qu’est-ce qu’une relation ?

Il existe une grande confusion sur le terme relation. En effet, contrairement à une croyance
populaire disséminée par de mauvaises traductions comme par des articles pseudo-tech-
niques sur cette nouvelle Samaritaine que représente Internet, le terme relation désigne
à l’origine les objets mathématiques contenant les données et non les liens ! On a oublié
le sens primaire de relation. Il suffit d’aller sur n’importe quel dictionnaire, par exemple
le Larousse (http://www.larousse.fr/dictionnaires/francais/relation), pour lire la défini-
tion suivante : « Action de rapporter en détail ce dont on a été le témoin ou dont on a eu
connaissance… ».
Autrement dit, la relation au sens mathématique (MLD) est la traduction de l’entité du
modèle conceptuel et conduira à la table dans le modèle physique.
Un peu d’histoire
Le modèle relationnel est né en 1970 des travaux de Edgar Frank Codd, mathématicien
britannique, ex-pilote de chasse de la RAF, devenu ingénieur chez IBM.
Pendant les années qui ont suivi, deux courants de recherches relatives à la conception des
tables se sont dégagés. Le premier visait à contrôler la qualité d’un schéma relationnel en pro-
posant des règles de normalisation (les formes normales seront étudiées en détail au chapitre
suivant). Le second visait à s’abstraire des structures de données stockées en introduisant un
niveau plus abstrait : le niveau conceptuel.
Le modèle entité-association, appelé entity-relationship (entité-relation) chez les Anglo-
Saxons, a été proposé des deux côtés de l’Atlantique. La paternité de ce modèle fut attribuée à
Peter Chen en 1976 avec son article « The Entity-Relationship Model-Toward a Unified View
of Data », mais il n’était sans doute pas le premier. Il est d’ailleurs amusant de lire le titre d’un
des articles d’Hubert Tardieu paru en 1979 « A Method, A Formalism and Tools for Database
Design (three years of Experimental Practice) ».
Les principales publications

E. F. Codd, « A Relational Model for Large Shared Data Banks », Communications of the
ACM, Vol. 13, n° 6, 1970
P. Moulin, J. Randon, S. Savoysky, S. Spaccapietra, H. Tardieu, M. Teboul, « Conceptual
model as database design tool », Proceedings of the IFIP Working conference on Model-
ling in Database Management Systems, G.M. Nijssen Ed., North-Holland, 1976
P. P. Chen, « The Entity-Relationship Model: Towards a Unified View of Data », ACM
Transactions on Database Systems, Vol. 1, N° 1, 1976

Comme tout ce qui a du succès, ces approches ont été reprises : en 1991 avec le modèle
conceptuel des données (MCD) de Merise, étendu avec Merise/2 en 1994.
En 1997, d’importants acteurs (HP, Microsoft, Oracle, Unisys) utilisent des travaux de
G. Booch, J. Rumbaugh et I. Jacobson pour donner naissance à la version 1.0 d’UML.
D’autres formalismes
Il existe toujours plusieurs autres formalismes graphiques. Citons le modèle binaire NIAM
(Natural Language Information Analysis Method), IDEF1X (Integration Definition for
Information Modeling), la notation de Barker, etc. Seul le modèle entité-association avait été
initialement reconnu par l’ISO.
Figure 1-6. Différents formalismes
Selon l’outil que vous utiliserez, vous serez peut-être amené à les rencontrer. Par ailleurs, les
outils permettent aisément de générer un diagramme dans un autre formalisme.

Terminologie
Chaque concept de base se divise en sous-concepts comme le présente le tableau suivant.
Tableau 1-3 : Les trois concepts de base
Attribut (attribute) Entité/classe (entity/class) Association (relationship)

●● Le terme propriété est ●● Regroupe des objets métier ●● Relie des entités/classes (entre
aussi utilisé. (concrets ou abstraits). 2 : associations binaires, entre n :
●● Donnée élémentaire ●● Dotée d’attributs, dont un associations n-aires).
associée à un domaine identifiant. ●● Agrégation.
de valeurs. ●● Héritage.
●● Peut être identifiant (ou
en faire partie).
Dans l’état actuel de vos connaissances, et en vous supposant débutant, vous pourriez établir
le tableau suivant sans vous prononcer davantage sur la suite des événements.
Tableau 1-4 : Les trois concepts du cas des supermarchés
Attribut (attribute) Entité/classe Association

(entity/class) (relationship)
●● code_postal, nom_ville ●● Magasin ?

●● date_service, lib_service ●● Ville ?
●● nom_magasin, nbre_produits, distance_km ●● Service ?
Le tableau suivant présente les termes équivalents de la notation UML et des formalismes
entité-association (Merise compris).
Tableau 1-5 : Terminologie
UML Entité-association
Classe Entité
Association Association (Relation)
Objet Occurrence
Multiplicité Cardinalité
Diagramme de classes Modèle conceptuel de données (Merise)
Attribut ou information ?
Lors de l’analyse de l’existant ou du domaine à modéliser, vous devrez faire la distinction entre
attribut et information.

●● Les attributs caractérisent les données que vous stockerez en base. Vous les découvrirez
plus ou moins directement. Vous devrez en créer de toutes pièces dans certains cas (les
identifiants en particulier).
●● Les informations incluent toutes les données de l’univers du discours. On y retrouve les
attributs et d’autres données qui n’auront pas à être stockées (informations déduites, calcu-
lées ou de traitements).
L’attribut est une donnée brute et l’information est généralement « calculée » ou composée à
partir d’autres données brutes (date et heure système, par exemple). Le tableau suivant présente
quelques exemples de « bons » ou de mauvais candidats à devenir attribut.
Tableau 1-6 : Attribut ou information ?
Attributs – (exemples de valeurs) Informations
mail – (l.robert@orsys.com, pablo@mac.com…) age (valeur déduite)

nom_client – (Brouard, Roux…) total_facture (valeur calculée)
indice_salarial – (645, 756…) format_facture (traitement)
date_naissance – (05/02/1965, 13/05/1995…)
prix_prod_ht_euros_sans_remise – (134.40, 120.50…)
devise – (€, $, £…)
Au début vous tâtonnerez, mais ensuite vous irez rapidement à l’essentiel, en laissant de côté
les informations qui n’auront pas lieu d’être stockées, en amont du dictionnaire des données.
Par ailleurs, vous devrez veiller à ce que chaque attribut soit indécomposable en termes de
structure. Autrement dit, toute valeur d’un attribut doit être atomique. L’exemple le plus parlant
est celui d’une adresse qui ne doit pas être modélisée par un unique attribut adresse, mais
par autant d’attributs qui la composent (nom de la voie, numéro dans la voie, code postal,
cedex…).
Cet aspect des choses sera argumenté au niveau physique ; il est motivé principalement par
l’extraction et l’indexation future des données.
Classe ou entité ?
Deux appellations identiques pour le même concept, c’est ça l’informatique : on aime bien
donner des noms différents aux choses dès qu’on change d’environnement.
●● Entité est la terminologie qui fut proposée par les pionniers de la conception de base de
données.
●● Classe est la terminologie utilisée par les pionniers de la conception objet et reprise par
UML.

• Une entité (classe) est une description d’un ensemble homogène d’objets (concrets ou
abstraits), chacun caractérisé par différents attributs.
• Chaque entité (classe) doit disposer d’un identifiant.
• Les classes UML peuvent disposer de méthodes (mécanisme pas encore bien adapté aux
schémas relatifs aux bases de données).
Chaque outil a ses préférences graphiques par défaut qui diffèrent d’un autre ; la figure sui-
vante illustre quelques différences. En revanche, vous retrouverez les constantes suivantes :
●● un cadre représente une entité (classe), le nom de la classe dans le premier compartiment ;
●● les attributs au centre du cadre ;
●● les éventuelles méthodes dans un troisième compartiment.
Figure 1-7. Trois classes et une entité
Comme vous le constatez, le type des données peut apparaître (exemple de la seconde classe).
La visibilité des attributs aussi (private de la seconde classe). Ce mécanisme est issu de
l’approche objet et ne concerne pas les schémas relatifs aux bases de données.
Vous devrez affecter, à chacune de vos classes, un identifiant. Un identifiant est une propriété
naturelle ou artificielle d’une classe permettant de distinguer un objet de tous les autres (et
ce quel que soit l’objet considéré). Un identifiant peut être composé d’un ou de plusieurs
attributs.
Si l’outil que vous envisagez d’utiliser ne permet pas cette fonctionnalité, et bien changez-le
pour un autre… En effet, sans identifiant, vous ne pourrez générer aucun script SQL à partir
de votre schéma conceptuel.

Les identifiants
L’étape d’identification est fondamentale, elle va conditionner par la suite la composition des
index et des clés étrangères de vos tables. C’est aussi grâce aux identifiants que vous décou-
vrirez des nouvelles classes à définir.
Qui dit libellé, dit identifiant

« Qui dit libellé, dit identifiant », à force de le dire je l’ai écrit. Un libellé, c’est une donnée le
plus souvent textuelle que vous allez rencontrer et pour laquelle vous devrez vous demander si
cette dernière est susceptible d’être utilisée à travers différents contextes.
Voici quelques exemples.
●● Le nom d’un produit (nom_produit) est susceptible d’exister au niveau du fournisseur, du
détaillant, de la facture, du grossiste, du transporteur, etc.

●● Le type d’une voiture (type_voiture) est susceptible d’être utilisé dans les catalogues du
constructeur, au sein du service des mines, sur les cartes grises, etc.
●● Les prénom et nom (prenom_client et nom_client) du passager d’un vol se trouveront
à coup sûr au niveau des cartes d’embarquement, dans les e-mailings publicitaires, les
programmes de fidélité, etc.
Afin d’éviter en amont des probables redondances d’informations au niveau de la base de
données, vous devrez, pour chaque attribut de la sorte, y associer un identifiant ayant un nom
explicite. Ainsi, id_produit devra identifier nom_produit, id_type_voiture identifiera
type_voiture, id_client identifiera nom_client et prenom_client, etc.
Dans l’exemple suivant, il apparaît au premier abord trois attributs. Le titre des thèmes tels
« L’entretien » et « Les pièces d’usure » (lib_theme), le titre des sujets (lib_sujet) et le
numéro des pages du catalogue (num_page).
Figure 1-8. Des libellés sans identifiant

Deux de ces attributs se trouvent être des libellés qui impliquent la définition des identifiants
associés (id_theme et id_sujet). Le schéma conceptuel sera donc composé d’au moins
deux classes, illustrées comme suit. L’outil PowerAMC permet de déclarer un identifiant pour
chaque classe (et permet de le repérer visuellement).
Figure 1-9. Schéma initial des classes UML
Pourquoi avoir disposé l’attribut num_page dans la classe Sujets ? Parce qu’il « dépend »
de cette classe. En effet, d’après l’analyse qui a été établie, chaque sujet est doté d’un libellé
et une seule page du catalogue le concerne. Nous reviendrons plus loin sur cette notion de
dépendance.
Concrets ou abstraits ?
Abstrait ou concret, tout objet se doit d’être identifiable.
●● Si une classe regroupe des objets concrets, l’identifiant est naturellement concret, mais
vous pourrez le considérer également de nature abstraite.

●● Si une classe regroupe des objets abstraits, l’identifiant est naturellement abstrait, mais
vous pourrez le considérer également de nature concrète.

Le contexte et le point de vue doivent vous conduire à différencier, pour tout objet que vous
modéliserez, le concret de l’abstrait et ce que vous désirez stocker. Dans certains cas, les deux
aspects d’une même chose peuvent vous intéresser simultanément.
En considérant les objets suivants, examinons les différents points de vue et contextes afin de
déterminer, pour chaque classe, l’identifiant adéquat.
Figure 1-10. Objets concrets ou abstraits ?

●● L’avion (ici, un A320) : du point de vue de la compagnie aérienne, chaque objet est concret,
doté d’une immatriculation, d’un numéro de série, d’une date d’acquisition, et associé à des
événements (vols et révisons) etc. L’immatriculation ou le numéro de série sont de bons
candidats pour devenir identifiants. Du point de vue d’une agence de voyages, cet objet est
abstrait ; il importe peu de savoir quel aéronef de la compagnie réalise le vol. Dans ce cas, le
type de l’avion (ici, A320) suffirait à l’identifier. Pour distinguer tout vol réel, l’objet concret
avion devient un composant de l’identifiant (il faudra utiliser l’identification relative).
●● La voiture (ici, une BMW 320Ci type E46) : du point de vue de la concession, chaque objet
est concret, doté d’un numéro de série et de bien d’autres options. Le numéro de série est
un bon candidat pour devenir identifiant de chaque véhicule. D’un point de vue du départe-
ment des ventes, habitué des statistiques, chaque objet devient abstrait et associé à un type
catalogue (ici, 320Ci E46). Ce type suffirait à identifier toute voiture perçue comme un
modèle. Dans le contexte des cartes grises ou des services de police, plusieurs identifiants
seront nécessaires, le numéro de série (qui ne varie jamais) et le numéro d’immatriculation.
●● Le livre (ici, SQL 3e édition) : du point de vue de l’éditeur, chaque objet peut être perçu de
manière abstraite, doté notamment d’un numéro ISBN unique (il existe en fait plusieurs
classifications ISBN). Du point de vue d’un libraire ou d’un bibliothécaire, chaque objet est
concret et sera vendu ou prêté. En conséquence, un numéro d’exemplaire artificiel devra
être ajouté afin d’identifier tout livre perçu ici comme un exemplaire.
●● Le plat (ici, un steak-frites) : dans le contexte d’un restaurant, chaque objet sera plutôt
perçu de manière abstraite (plusieurs steaks-frites correspondent au même plat qui est
vendu à la carte à un certain prix). Un code suffira donc à identifier ce plat. S’il advenait
qu’on doive tracer la provenance des viandes, il faudrait considérer l’objet comme concret
et associer à chaque steak un numéro unique afin de pouvoir relier ce dernier à l’exploita-
tion d’origine. Dans ce cas, les deux identifiants (celui du steak et celui de l’exploitation)
seraient utilisés conjointement.
J’appelle cela les notions « générique » et « spécifique ». Alors que Livre est une classe
générique (qui décrit une œuvre littéraire, par exemple Les misérables de Victor Hugo),
Livre peut être aussi spécifique (Les misérables, collection Folio, Gallimard). Enfin, Livre
peut être un exemplaire d’une bibliothèque. Cela rejoint les notions de classe et d’instance.
Artificiels ou naturels ?
Avant de parler de la nature d’un identifiant, évoquons les deux critères de qualité à respecter :
●● stabilité (un objet ne doit pas changer d’identifiant au cours du temps) ;
●● minimalité (en termes de taille et de complexité de valeurs).
Lorsque l’attribut d’un objet remplit les deux critères fondamentaux, on parle « d’identification
naturelle » (l’identifiant a une sémantique métier ; on parle de « clé métier »).

Lorsqu’aucun attribut présent dans le dictionnaire des données ne remplit les deux critères
fondamentaux, il est nécessaire d’ajouter un attribut identifiant (le plus souvent un numérique
qui deviendra séquence ou auto-incrément). On parlera « d’identification artificielle ». Cette
technique, très utilisée, est simple et favorise le respect des critères de qualité au cours du
temps.
Si vous optez pour l’identification artificielle, vous devez, dans la majorité des cas, ajouter à la
classe un attribut naturel d’identification (clé métier). Cette identification secondaire permettra
par la suite de pouvoir rechercher un objet à l’aide d’une sémantique métier.
Plusieurs identifiants peuvent être déduits de la figure suivante (extrait du site Internet de la
banque LCL).
Figure 1-11. Identifiants
●● L’identifiant naturel de la banque LCL (id_banque) : il est aussi possible d’identifier une
banque par un numéro artificiel (c’est le cas du code attribué par la Banque de France :
30002 pour le Crédit Lyonnais).
●● L’identifiant naturel de l’agence (id_agence), indiqué en tant qu’indicatif du compte : c’est
souvent un numéro ou un code de la succursale (chaque établissement bancaire est responsable

de cette codification : 4068 pour l’agence de Ramonville Saint-Agne du Crédit Lyonnais).
●● L’identifiant naturel du compte (id_compte) : c’est souvent un code composé de numéros
et de lettres (chaque client connaît ses numéros ou est capable de les retrouver).
●● L’identifiant articiel du client (id_client) : le client ne le connaît pas, mais le banquier
est capable de le retrouver.

Le code personnel ne peut ni jouer le rôle d’identifiant articiel du client (plusieurs clients peu-
vent choisir le même code, peu probable, mais possible), ni permettre d’identifier un compte
(pour la raison précédente et parce qu’un client peut être propriétaire de plusieurs comptes).
Bannissez l’identifiant naturel !

Bien que d’un point de vue scolaire, il faille chercher l’identifiant parmi les attributs
de l’entité, cette vision conduit à des problématiques de performances particulièrement
sensibles…

Une clé naturelle peut ne pas être connue lors de la saisie primale… Que se passe-t-il si
le patient que vous avez modélisé avec comme identifiant son numéro de Sécurité sociale
arrive à l’hôpital sans ses papiers et dans le coma ?
Une clé naturelle peut évoluer dans le temps… Que se passe-t-il si ayant modélisé vos
adhérents par leurs nom et prénom, Marie DUPONT se marie avec Albert DUVAL ? Quid
des données des nombreuses tables filles ?
Une clé naturelle est souvent longue… Un numéro de Sécurité sociale (13 caractères),
comme le couple nom et prénom (en moyenne, 15 caractères), c’est 3 à 4 fois plus long
qu’un entier et permet environ 6 fois moins de combinaisons (en pratique, on ne peut uti-
liser qu’une quarantaine de caractères sur les 25 possibles). C’est donc facilement 24 fois
moins performant !
Préférez une clé arbitraire la plus courte possible. Par exemple, un entier auto-incrémenté
(SEQUENCE , IDENTITY en SQL). L’utilisation des GUID (Globally Unique IDentifier)
ou UUID (Universally Unique Identifier) posant d’autres problèmes en plus de ne pas
garantir l’unicité absolue…
Plusieurs, c’est possible ?

Un objet peut être identifié par différents attributs. L’exemple suivant illustre cette possibilité :
tout livre peut être référencé par plusieurs identifiants (un code éditeur, des numéros ISBN, des
codes-barres…). Ce raisonnement vaut pour la majorité des autres types de produits.
Figure 1-12. Plusieurs identifiants
Il est possible de définir dans une classe plusieurs identifiants à la condition qu’un seul soit
principal.

Les autres identifiants potentiels (appelés secondaires ou alternatifs) n’apparaîtront pas for-
cément visuellement sur vos schémas conceptuels (cela dépend de l’outil que vous utiliserez).
Ces identifiants secondaires se rendront plus utiles au niveau logique en jouant le rôle de clé
candidate pouvant se substituer à la clé primaire de la table. Des références supplémentaires
pourront être mises en place sans nécessairement utiliser la clé primaire de la table.
La figure suivante présente la classe UML (incomplète) que l’on peut déduire de cet exemple.
L’ensemble des données qu’il faudrait recenser n’est pas pris en compte (nom de l’auteur,
traducteur…). En revanche, les attributs identifiants potentiels sont tous répertoriés. Seul
l’identifiant principal est aisément repérable visuellement.
Figure 1-13. Plusieurs identifiants dans une classe UML (PowerAMC)
Les associations binaires

Comme son nom l’indique, une association binaire relie deux classes. Quand la classe est
reliée à elle-même, on parle d’association réflexive. Les associations sont souvent déduites
des verbes du discours. Suivant le nombre d’objets concernés par l’association, la termi-
nologie permettant de classifier ces associations est la suivante : un-à-un, un-à-plusieurs,
plusieurs-à-plusieurs.
Figure 1-14. Classification des associations binaires
●● Les associations un-à-un sont les moins courantes. À titre d’exemple, dans le contexte des
assurances, citons le contrat (classe) qui concerne (association) un véhicule (classe). Tout
véhicule n’est concerné que par un seul contrat.

●● Les associations un-à-plusieurs (hiérarchies) sont très courantes car omniprésentes dans
notre environnement. À titre d’exemple, une compagnie aérienne (classe) possède (associa-
tion) des avions (classe). Tout avion n’appartient qu’à une seule compagnie.
●● Les associations plusieurs-à-plusieurs sont aussi courantes car très présentes dans notre
environnement. À titre d’exemple, une compagnie aérienne (classe) affrète (association)

des avions (classe). Un avion peut être affrété par différentes compagnies.
On classifie toute association à l’aide d’un couple de valeurs (nombre minimal et maximal
d’objets mis en association) à l’extrémité de chaque lien. UML parle de multiplicités (les
modèles entité-association évoquent les cardinalités).
Dans l’exemple suivant, l’association UML exprime qu’un exemplaire concerne un et un seul
livre (1..1). De plus, un livre peut ne pas exister en tant qu’exemplaire ou au contraire être
présent en plusieurs exemplaires (0..*).
Figure 1-15. Association UML un-à-plusieurs
Nous pouvons maintenant relier les deux classes de l’exemple du catalogue des services auto-
mobiles, l’association précise qu’un thème inclut plusieurs sujets et un sujet ne dépend que
d’un thème.
Figure 1-16. Thèmes et sujets reliés par une association UML un-à-plusieurs
Il est important de nommer chaque association par un verbe ou une forme nominale la plus
parlante possible.
Cela est particulièrement intéressant lorsque plusieurs associations relient deux mêmes classes.
Le plus souvent, il n’y a pas de corrélation entre les objets qui participent à ces différentes

associations. Chaque lien exprime une sémantique distincte. Dans le cas contraire, il sera
nécessaire d’utiliser des contraintes (voir à la fin de ce chapitre).
Le schéma suivant présente trois associations entre deux mêmes classes. Bien que la séman-
tique de ces trois associations soit distincte, il faudra par la suite contraindre ce schéma en
précisant que la gare de départ doit être différente de la gare d’arrivée. De plus, ces deux gares
devront être répertoriées au sein de l’association plusieurs-à-plusieurs desservir qui repré-
sente le trajet complet d’un train.
Figure 1-17. Plusieurs associations binaires UML
La section suivante approfondit la classification des associations binaires en comparant les

cardinalités des modèles entité-association aux multiplicités de la notation UML.
Multiplicités versus cardinalités

Multiplicités et cardinalités sont deux termes différents pour évoquer le même concept, à
savoir préciser le nombre d’objets (Merise parlait d’occurrences) concernés par chaque asso-
ciation. En revanche, la lecture des cardinalités de Merise est différente de celle des modèles
entité-association et de la notation UML.
●● Les multiplicités de UML se notent x..y à l’extrémité de chaque lien (x et y valeur
entière : 0, 1…), le symbole * désigne plusieurs sans en limiter la valeur. La valeur x
précise le nombre minimum d’objets reliés, la valeur y exprime le nombre maximum.
●● Les cardinalités de Merise (et celles des autres formalismes entité-association) sont notées
par un couple de valeurs x,y. La lettre n (ou N) désigne plusieurs sans en limiter la valeur.
Pour ces deux notations, il est évident que le nombre minimum doit être toujours inférieur ou
égal au nombre maximum (x≤y).
Les cardinalités d’une association binaire Merise sont inversées par rapport aux multiplicités
de la notation UML (qui se comporte comme les autres modèles entité-association).

Le schéma conceptuel Merise, équivalent du diagramme UML précédent, illustre cette différence.
Figure 1-18. Associations binaires Merise
Le tableau suivant résume les équivalences entre les écritures des multiplicités de la notation
UML et les cardinalités des autres formalismes entité-association.
Tableau 1-7 : Équivalences entre multiplicités et cardinalités
Multiplicités UML Cardinalités
0..1 0,1
1..1 (ou 1) 1,1
0..* (ou *) 0,N (ou 0,n)
1..* 1,N (ou 1,n)
a..b a,b
Il est peu courant que le nombre minimum d’objets soit supérieur à 1, mais c’est une possibilité
que tous les formalismes permettent. Le schéma suivant présente un cas où toutes les multipli-
cités sont bornées. Ce schéma exprime que tout administrateur se doit de conseiller entre 2 et
5 holdings. Par ailleurs, tout holding sera associée à au moins 3 administrateurs et au plus 10.
Figure 1-19. Multiplicités UML bornées

Le maximum est prépondérant
Vous n’aurez pas le droit à l’erreur lorsque vous déterminerez le nombre maximum d’une
multiplicité. En effet, le processus de transformation au niveau logique qui génère les clés
étrangères est basé sur le nombre maximum de toutes les multiplicités. La condition princi-
pale de ce processus est la suivante :
SI (multiplicite_maximum > 1) ALORS
Modélisation A
SINON
Modélisation B
FIN SI
Ne faites pas de confusion avec le sens de lecture des multiplicités de UML si vous lisez un
schéma au formalisme de Merise (il vous suffira de permuter les couples pour chaque association
le cas échéant).
Que vous choisissiez de borner vos multiplicités par un entier supérieur à 1 (2, par exemple)
ou que vous optiez pour * (ou N pour un formalisme entité-association), le schéma logique
obtenu sera identique (la structure des tables et la composition des clés seront identiques).
Les multiplicités minimales précisent les liens d’association et n’ont pas d’influence sur la
structure des tables et des clés de la base de données. En revanche, vous devrez mettre en
œuvre, en théorie, des contraintes si vous désirez implémenter chaque multiplicité minimale.
Je dis en théorie, car bon nombre de schémas sont pleins de bonnes intentions sur le papier
qu’il faut concrétiser correctement dans la programmation des transactions.
Le minimum est-il illusoire ?

Alors que le nombre maximal d’une multiplicité ne doit pas porter à confusion, les multipli-
cités minimales sont souvent les plus sujettes à discussion. Surtout du côté de chaque lien, où
la multiplicité maximale est supérieure à 1.
Dans certains cas, le nombre minimal exprime une règle de fonctionnement (règle métier) ;
dans d’autres cas, il s’agira d’expliquer un état initial des données.
La mise en œuvre de contraintes SQL sera nécessaire pour implémenter chaque multiplicité
minimale. Pour les cas simples des associations un-à-un et un-à-plusieurs, une contrainte
NOT NULL pourra suffire (processus en général automatisé par les outils de conception). Pour
les autres cas, et par ordre de complexité, vous devrez ajouter des contraintes CHECK, des
colonnes (calculées ou pas), programmer des déclencheurs ou des transactions.
Les chapitres 2 et 3 compléteront ce propos.

Considérons la classe Aeroport qui est reliée à deux associations un-à-plusieurs ayant du
côté « un » les multiplicités minimales respectives 1 et 0.
●● Le « 1 » de l’association situer du côté Ville exprime qu’un aéroport est situé sur une
ville. Une contrainte NOT NULL sera générée.

●● Le « 0 » de l’association controler du côté Douanes exprime qu’un aéroport peut ne pas
être associé à un service douanier. Aucune contrainte NOT NULL ne sera générée.
Figure 1-20. Multiplicités minimales UML
Examinons à présent la sémantique des multiplicités minimales d’un diagramme un peu plus
complexe comme celui des actionnaires de SARL. L’association participation exprime
qu’une SARL doit avoir au minimum 2 actionnaires et au plus 10. Un actionnaire peut ne pas
être associé à une SARL, et est limité à 6 participations. Chaque actionnaire devra être détenteur
d’une à trois adresses électroniques.
Figure 1-21. Multiplicités UML bornées

●● Le « 1 » au minimum du côté Mails de l’association contacts n’est pas sujet à discus-
sion, car c’est l’expression du fait qu’un actionnaire dispose obligatoirement d’un e-mail.
Une contrainte NOT NULL sera générée pour implémenter ce contrôle. En affectant « 0 » à
cette multiplicité, la contrainte ne sera pas générée.
●● Le « 1 » au minimum du côté Actionnaires de l’association contacts peut être sujet
à discussion. Il s’agit de savoir si la base de données peut stocker des e-mails anonymes.
En théorie, il faudrait assurer un tel contrôle au niveau de la programmation. En affectant
« 0 » à cette multiplicité, vous relâchez ce contrôle.
●● Le « 0 » au minimum du côté SARL de l’association participation peut être sujet à
discussion. Il s’agit de savoir si la base de données peut stocker des actionnaires qui ne
participent à aucune SARL. Ici aucune contrainte n’est à mettre en œuvre. Le fait de choisir
« 1 » pour cette multiplicité nécessite, en théorie, la mise en œuvre de ce contrôle par
programmation (transaction ou déclencheur).
●● Le « 2 » au minimum du côté Actionnaires de l’association participation n’est
pas sujet à discussion, c’est l’expression d’une règle métier. Une simple contrainte CHECK
ne suffit pas et du code SQL doit implémenter cette règle (transactions et déclencheurs).
Ce code se chargera également de vérifier le non-dépassement du nombre maximal de la
multiplicité (10).
Si vous hésitez entre 0 et 1 pour une multiplicité minimale, choisissez 0 de sorte à moins
contraindre le schéma SQL. Vous pourrez toujours ensuite programmer une nouvelle
contrainte.
Réflexivité
Une association binaire (un-à-un, un-à-plusieurs, plusieurs-à-plusieurs) qui relie une classe à
elle-même est dite réflexive.
Bien que séduisant par sa sémantique, le concept de réflexivité produit des schémas relation-
nels plus complexes (en particulier avec des associations plusieurs-à-plusieurs) et induit une
programmation ardue qui peut s’avérer moins performante (requêtes récursives).
Afin de pallier ces problèmes potentiels, nous verrons qu’une association réflexive peut se
représenter, dans certains cas, à l’aide de plusieurs associations binaires non réflexives.
Le diagramme suivant décrit l’association un-à-plusieurs de parrainage qui relie (éventuel-
lement) un client à ses filleuls qui sont aussi des clients (0..*). Un filleul peut n’être associé à
aucun parrain (0..1), ce qui exprime qu’un client peut être ni parrain, ni filleul.

Figure 1-22. Association UML réflexive un-à-plusieurs
En considérant l’exemple des autoroutes françaises, il apparaît qu’une ville (source) est reliée à
une ou à plusieurs autres villes (cibles). Par ailleurs, une ville cible peut être reliée à plusieurs
villes sources.
Figure 1-23. Autoroutes du Sud de la France
En utilisant la réflexivité, une association réflexive plusieurs-à-plusieurs peut décrire ces

connexions.
Figure 1-24. Association UML plusieurs-à-plusieurs réflexive

Ce n’est pas la solution la plus simple pour modéliser un tel graphe. D’une part, la réflexi-
vité n’est pas le concept le plus adéquat, d’autre part, ce schéma relie une ville à plusieurs
autres sans préciser de quelle autoroute il s’agit, alors qu’il existe une forte contrainte entre les
deux associations. Une solution plus simple consiste à utiliser une classe supplémentaire pour
modéliser un tronçon (schéma décrit plus loin dans ce chapitre).
Les cardinalités Merise sont, comme au titre des associations binaires, simplement permutées
par rapport aux multiplicités (voir le schéma suivant).
Figure 1-25. Association Merise réflexive
Il est important d’utiliser des rôles pour préciser la sémantique d’une association UML a for-
tiori lorsque cette association est de nature réflexive.
Nous verrons, par la suite, qu’il est possible de relier une classe-association UML à une asso-
ciation réflexive à la condition qu’elle soit de type plusieurs-à-plusieurs.
Les rôles
Un rôle UML se note sur un lien d’association sous la forme d’un nom (forme nominale ou
verbale) qui décrit comment une classe source « voit » sa classe cible.
Dans l’exemple suivant, les comptes d’un client sont considérés comme un portefeuille, le
client d’un compte est son détenteur. Les rôles inscrits sur l’association réflexive précisent le
sens de lecture et la sémantique de l’association.
Figure 1-26. Rôles UML

Bien qu’il soit possible de nommer les associations et les rôles dans un même diagramme de
classes, cela n’est pas forcément recommandé pour des raisons de lisibilité.
Les rôles sont particulièrement utiles pour les concepteurs qui écriront toutes leurs contraintes
à l’aide du langage OCL (voir en fin de chapitre).
Mise en pratique
Testez dès à présent vos aptitudes grâce à l’exercice 1.1 « La déroute des bleus », à la fin du
chapitre. Vous y modéliserez le schéma du premier tour de la coupe du monde de football 2010
en Afrique du Sud. Vous n’aurez pas à modéliser le second tour (vous vous rappelez que notre
équipe de stars n’a pas été qualifiée…). Suite de l’exercice peut-être en 2014.
Les associations plus complexes

Bien que bon nombre de personnes soient qualifiées de « binaires » (particulièrement les infor-
maticiens !), le monde que vous aurez à modéliser ne le sera pas. Il est fort peu probable que
vos schémas ne soient constitués que d’associations binaires.
En effet, parce que la nature est complexe, d’autres types d’associations existent et la notation
UML permet de les modéliser, par exemple :
●● les classes-associations pour composer des regroupements ;
●● les associations n-aires qu’il faudra éviter en se ramenant aux classes-associations ;
●● l’héritage que tout le monde connaît depuis l’avènement des langages objet ;
●● les agrégations, qui permettent de traduire des compositions et d’implémenter l’identification
relative.
Les classes-associations
Une classe-association UML :
●● est une classe rattachée à une association plusieurs-à-plusieurs ;
●● possède éventuellement des attributs, mais pas d’identifiant ;
●● est rattachée éventuellement à d’autres classes.
D’un point de vue sémantique, une classe-association c’est comme une agence matrimoniale :
ça forme des couples qui se lient ensemble éventuellement à d’autres objets.

Premier exemple
Dans l’exemple suivant, la classe-association Comp_Aero modélise tous les couples (com-
pagnie, aéroport) valides. À chaque couple, des données peuvent être associées. Ici, la date
d’arrivée d’une compagnie dans un aéroport et le nombre de comptoirs dont elle dispose.
Figure 1-27. Classe-association UML
Notez que les deux attributs de cette classe-association ne peuvent pas être disposés ailleurs.
●● La date d’arrivée ne dépend pas de la compagnie seule (Air France peut résider à Orly
depuis l’année 1967 alors qu’elle est arrivée à Blagnac au cours de l’année 1969, par
exemple). Cette date d’arrivée ne dépend pas non plus de l’aéroport seul, car Orly qui a
accueilli Air France en 1967 a vu débarquer Air Liberté en 1990.
●● Le nombre de comptoirs ne dépend ni de la compagnie seule, ni de l’aéroport seul. Sinon,
il s’agirait de cumuls. Dans le premier cas, s’il se trouvait dans la classe Compagnie,
l’attribut indiquerait le nombre de comptoirs détenus par la compagnie (sans préciser où
chacun se trouve). Dans le second, s’il se trouvait dans la classe Aeroport, l’attribut indi-
querait le nombre de comptoirs qui se trouvent dans un aéroport (sans préciser de quelle
compagnie il s’agit).
Tout attribut d’une classe-association doit dépendre simultanément des deux classes (pas
simplement de l’une ou de l’autre). Pour toute valeur d’un couple d’objets connectés, une
valeur au plus de l’attribut doit être associée, et cet attribut doit être contenu dans la classe-
association.
Vous ne savez pas comment appeler une classe-association ? Composez son nom avec les
préfixes des deux classes connectées.
Une classe-association ne doit pas contenir d’identifiant, car l’identifiant de la classe-association

est en fait le couple des identifiants des classes connectées.

Formalismes entité-association
Avec Merise et les autres formalismes, ces attributs qui dépendent de deux entités se trouvent
aussi dans une association plusieurs-à-plusieurs.
Figure 1-28. Attributs dans une association Merise
Rattacher une classe-association

Une classe-association est considérée comme une classe à part entière, et à ce titre, elle peut
être rattachée à une autre.
Considérons à nouveau les compagnies situées dans leurs aéroports (ou les aéroports qui
accueillent des compagnies, c’est la même sémantique), et relions la classe-association à une
autre classe. Par exemple les employés. Le schéma suivant exprime que tout couple (compa-
gnie, aéroport) est associé à un ou plusieurs employés et qu’un employé ne travaille que dans
un lieu pour le compte d’une compagnie (c’est une hypothèse de travail pour présenter ce
premier exemple).
Figure 1-29. Classe-association rattachée à une classe

Classe-association réflexive
Une classe-association peut être liée à une association réflexive (à condition qu’elle soit de type
plusieurs-à-plusieurs).
Le premier exemple reprend la première modélisation des villes connectées par des auto-
routes. Modélisons un tronçon comme un couple de villes. Chaque tronçon a été ouvert à
une certaine date (postérieure à celle de l’autoroute, mais pas forcément identique) et chaque
tronçon mesure une certaine distance.
Figure 1-30. Classe-association réflexive
Ce n’est pas la modélisation la plus simple ; il n’apparaît pas explicitement la notion de sens,
du fait que les villes forment un graphe orienté. Dans ce schéma, on exprime toutefois qu’un
couple de villes forme un tronçon tout en permettant qu’entre deux villes, deux tronçons dis-
tincts existent : celui où vous roulez en regardant souvent votre compteur et votre avertisseur
de radar, et l’autre où ceux de la voie d’en face font pareil.
L’autre problème de cette modélisation concerne le lien entre Ville et Autoroute qui n’est
pas précis (il ne respecte pas la hiérarchie). La hiérarchie veut qu’une autoroute soit composée
de tronçons reliant chacun deux villes. Nous reviendrons sur cet écueil classique. Le schéma
suivant est de meilleure qualité.
Figure 1-31. Respecter la hiérarchie

Le second exemple de classe-association réflexive concerne les virements bancaires. Une

opération est modélisée ici comme une association entre un couple de comptes (débiteur,
créditeur) ou l’inverse, et plusieurs transactions caractérisées par un montant et un moment.
Une opération ne concerne toujours qu’un couple de comptes.
Figure 1-32. Classe-association réflexive
Ces deux modélisations (les comptes et les tronçons autoroutiers) peuvent se simplifier du fait
de la présence de la multiplicité 1..1 du côté de la classe-association. Nous verrons à la section
« L’identification artificielle » les moyens de procéder à une telle simplification.
Mise en pratique
Appliquez le concept de classe-association grâce à la fin de l’exercice 1.1 « La déroute des
bleus ». Il s’agit de pouvoir nommer de manière différente une équipe en fonction de la langue.
Vous pouvez également réfléchir aux exercices 1.2 « L’organisme de formation » et 1.3 « Les
lignes de facture » qui ne font intervenir que des associations binaires.
Les associations n-aires

Considérée comme une notion compliquée et pour laquelle le plus grand nombre d’âneries
sont écrites ou dites, l’association n-aire modélise un fait ou un événement impliquant simulta-
nément plus de deux classes (n en fait). En lisant les quelques cas suivants, on peut s’interroger
sur le besoin d’utiliser une association n-aire. En effet, chacun de ces faits ou événements met
indubitablement en relation plusieurs classes qui sont indiquées en italique.
●● Les employés des compagnies aériennes peuvent se trouver derrière plusieurs guichets
dans les différents aéroports qu’ils fréquentent périodiquement.

●● Des compagnies aériennes affrètent des appareils pour effectuer des vols lorsque leur
flotte est réservée par ailleurs.

●● Les fermiers peuvent amener leurs vaches au cours de la saison d’hiver dans différents prés.

●● Des logiciels sont installés sur des serveurs par des départements.
●● Les chantiers peuvent être visités plusieurs fois par jour par les véhicules de la société.
Évitez d’utiliser des associations n-aires, car votre modélisation produira un schéma rela-
tionnel non contraint (décidez plutôt de ne pas contraindre un schéma au niveau logique). La
majorité des associations n-aires doivent plutôt s’écrire, d’une manière hiérarchique, à l’aide
d’une ou de plusieurs classes-associations.
Cette section décrit tout d’abord comment décrypter une association n-aire. Ensuite, plusieurs
cas sont présentés qui mettrent en évidence le fait que l’on puisse parfois se passer de ce méca-
nisme d’association. Enfin, vous découvrirez comment décomposer une association n-aire en
une ou plusieurs classes-associations.
Savoir les interpréter

Avant tout, suivant le formalisme que vous rencontrerez (Merise ou les autres), la lecture des
couples (cardinalités/multiplicités) d’une association n-aire est fondamentalement différente.
Il ne suffit pas d’inverser les couples de valeurs puisqu’il y a plus de deux couples en jeu dans
l’association.
Avec le formalisme de Merise, les cardinalités sont lues du sens entité concernée → entités
connectées.
Dans les autres formalismes entité-association et avec UML, les multiplicités d’une classe sont
lues à partir des autres classes de l’association (sens classes connectées → classe concernée).
Pour les deux formalismes, une association n-aire peut contenir des attributs (par le biais
d’une classe-association pour UML).
Aucune de ces deux lectures n’est l’inverse ou l’opposée de l’autre ; le sens est tout bonnement
différent. Dans l’exemple suivant, l’utilisation de l’association n-aire Installer permet d’ex-
primer que des logiciels sont installés un certain jour (date_install) sur des serveurs par
des départements.
Figure 1-33. Association n-aire

Les cardinalités de Merise se lisent de la manière suivante :

●● côté Logiciel, (0,n signifie qu’un logiciel peut être associé à aucun ou plusieurs couples
(Departement, Serveur) ;
●● côté Serveur, (0,n) signifie qu’un serveur peut être associé à aucun ou plusieurs couples
(Departement, Logiciel) ;
●● côté Departement, (0,n) signifie qu’un département peut être associé à aucun ou plu-
sieurs couples (Serveur, Logiciel).

Les multiplicités UML se lisent de la manière suivante :
●● côté Logiciel, (0..*) signifie qu’un couple (Departement, Serveur) peut être associé
à plusieurs logiciels (ou aucun) ;

●● côté Serveur, (0..*) signifie qu’un couple (Departement, Logiciel) peut être associé
à plusieurs serveurs (ou aucun) ;

●● côté Departement, (0..1) signifie qu’un couple (Serveur, Logiciel) n’est associé qu’à
un seul département (ou aucun).

Vous pouvez constater que UML offre, pour cet exemple, une lecture plus riche de sémantique.
Dans ce cas, il apparaît qu’un logiciel n’est installé par un département que sur un seul serveur.
Pour faire dire la même chose au modèle Merise, il faudrait ajouter une contrainte d’unicité.
Le langage du formalisme
Quel que soit le nombre d’entités/classes connectées, le mécanisme de lecture est analogue à
l’exemple précédent. Pour une association reliant 4 entités/classes (de degré 4), vous devrez
considérer la relation entre triplets et singletons en partant de la cible ou de la source.
L’exemple suivant illustre ce propos avec Merise. De chaque côté, il est exprimé la cardinalité
(0,n) qui s’interprète pour toutes les entités ainsi : un objet est associé à plusieurs triplets d’ob-
jets ou à aucun. Du côté Employe, cette cardinalité signifie qu’un employé peut être associé à
plusieurs comptoirs dans différents aéroports (ou dans le même), pour le compte d’une com-
pagnie (ou pour plusieurs).
Figure 1-34. Association Merise 4-aire

Avec le formalisme Merise, vous ne pouvez pas déduire grand-chose des associations n-aires.
La majorité d’entre elles ne contiennent que des cardinalités (0,n). La cardinalité (0,1) impose
une décomposition en degré inférieur (une association 3-aire se décompose en deux associations
binaires).
Avec le formalisme UML, les associations n-aires sont davantage parlantes. La multiplicité
(0..1) n’impose pas forcément une décomposition en degré inférieur. Le schéma suivant pré-
cise qu’un employé qui se trouve dans un comptoir d’un aéroport ne travaille que pour le
compte d’une seule compagnie. Symétriquement, un employé qui se trouve dans un comptoir
d’une compagnie est situé dans un seul aéroport.
Figure 1-35. Association UML 4-aire
Bien que UML semble plus explicite que Merise sur cet aspect des choses, ces deux schémas
ne sont pas satisfaisants. En effet, trop peu de contraintes sont présentes entre les 4 classes.
●● Pensez-vous réellement qu’en considérant un employé répertorié, un aéroport, une compa-
gnie et un comptoir existants, vous allez composer un fait cohérent à stocker ?

●● Ne croyez-vous pas que toutes les compagnies ne sont pas présentes dans n’importe quel
aéroport, qu’un comptoir ne se trouve que dans un aéroport, qu’une compagnie n’embauche
pas n’importe quel employé ?
Ce sont toutes ces questions que vous devrez vous poser de sorte à décomposer au mieux cette
association tentaculaire (celle-là et toutes les autres que vous rencontrerez).
Quelques bêtises du Web

Maintenant que vous savez lire une association n-aire, décryptons les erreurs typiques que
vous risquez de faire en utilisant ce mécanisme.
Dans le premier schéma Merise, un pilote ne peut pas faire plusieurs fois le même trajet avec
le même avion (c’est ce qui est indiqué avec la date et l’heure de décollage dans l’association).

Cela va coûter cher à la compagnie qui devra renouveler sa flotte à un rythme mensuel ou
hebdomadaire peut-être…
Dans le second schéma Merise, vous permet facilement (enfin la structure de la base le permet)
à un patient de se faire prescrire n’importe quel médicament par tout médecin…
Figure 1-36. Associations 3-aires avec Merise
La notation UML n’est pas en reste (même dans la documentation officielle de l’OMG).
●● Le premier schéma précise qu’une équipe peut faire jouer n’importe quel joueur quelle que
soit l’année (même l’année où l’équipe n’existait pas…).

●● Le deuxième schéma indique, sans rien préciser, qu’un type de voiture peut être conçu
n’importe quelle année dans n’importe quel type de bureau (même si le bureau ou la voi-
ture n’existaient pas cette année-là…).
●● Le troisième schéma indique qu’un professeur peut enseigner n’importe quelle matière à
n’importe quel étudiant. C’est dans l’air du temps la polyvalence, mais là, ça s’apparente à
un grand écart (appelez le prof de gym !).
Figure 1-37. Associations 3-aires avec UML

Quelques cas valides

Dans quelques rares cas, l’association n-aire peut être considérée comme valide et indécompo-
sable d’une manière hiérarchique. La modélisation Merise suivante exprime le fait qu’un site
peut être visité à différentes périodes par plusieurs acteurs. En supposant qu’un acteur puisse
visiter tout site et qu’à tout moment un site puisse être visité par n’importe quel acteur, l’asso-
ciation n-aire peut être considérée comme valide et aucun contrôle au niveau des insertions ne
pourra être envisagé.
Figure 1-38. Association 3-aire avec Merise
Comment se prémunir ?
Avant de chercher systématiquement à utiliser une classe-association afin de contraindre une
association n-aire, vous devez essayer de réduire le degré de l’association n-aire à l’aide de
plusieurs associations de degré inférieur à n. Ces cas se rencontrent lorsqu’il existe un lien fort
entre deux classes (entités) connectées indépendamment de l’association, mais toutefois dans
le contexte. Le cas échéant, une association 4-aire se décomposera en une association 3-aire
et plusieurs binaires. Une association 3-aire se dérivera ensuite éventuellement en plusieurs
associations binaires.

Décomposition en associations binaires

Considérons à nouveau l’exemple d’association 4-aire modélisant les compagnies qui font
travailler des employés derrière différents comptoirs d’aéroports. Deux liens forts doivent
être pris en compte ; ils proviennent du fait qu’un comptoir est propriété d’une compagnie
et qu’il se situe dans un seul aéroport (en supposant ce contexte). Ces faits se traduisent par
deux associations binaires qui simplifient le modèle initial, car elles concernent l’association
n-aire.
Figure 1-39. Association Merise 4-aire
Dans l’exemple des contrats reliant véhicules, clients et sociétés d’assurance, vous pouvez
penser à une association de degré 3. Ici, le lien fort provient de la propriété d’un véhicule. Ce
lien doit se modéliser par une association binaire entre un client et ses véhicules.
Figure 1-40. Association 3-aire

Le contrat devient une simple association binaire reliant un véhicule à sa compagnie d’assurance.
Figure 1-41. Association 3-aire décomposée en deux binaires
L’exemple suivant utilise une association de degré 3 pour lister les qualifications des pilotes
relatives à certains types d’appareils.
Figure 1-42. Association 3-aire
Le problème de cette association est qu’elle mélange deux faits : le premier concerne les qua-
lifications qu’un avion impose (indépendamment du pilote) et le second que des pilotes soient
titulaires de différentes qualifications. Les associations binaires titulaire et necessite
simplifient le modèle initial. La troisième association est plus discutable puisqu’elle peut être
déduite des deux précédentes. La normalisation forcenée vous conduirait à ne pas la définir,
l’utilisation courante vous conseillera de la préserver.
Figure 1-43. Association 3-aire décomposée en trois binaires

Lorsqu’il ne vous est pas possible de réduire le degré d’une association n-aire du fait qu’il
n’existe aucun lien entre les différentes classes connectées, à part l’association elle-même,
trouvez s’il existe (et c’est souvent le cas) une hiérarchie à travers une ou plusieurs classes-
associations. En effet, une association n-aire exprime implicitement dans la majorité des cas
une ou plusieurs contraintes d’inclusion.
À titre d’exemple, considérons l’association 3-aire Installer étudiée au début de la section

qui exprime que des logiciels sont installés sur des serveurs par des départements. Il n’est pas
possible de réduire cette association en plusieurs binaires, car l’événement d’une installation
concerne simultanément les trois classes.
Décomposition en classe-association
Le processus décrit ici concerne une association de degré 3, mais il s’applique aux degrés
supérieurs par analogie de raisonnement.
Vous devez choisir le couple de classes le plus « fort ». Dans certains cas, le choix s’impose
facilement, dans d’autres, plusieurs couples peuvent être candidats.
Reliez ces classes par une association plusieurs-à-plusieurs, si ce n’est pas possible, votre
couple n’est pas solide (enfin, ce n’est pas ce que je veux dire !), piochez ailleurs (là non plus…).
Attachez ensuite à cette association une classe-association qui contiendra éventuellement
des attributs.
La classe restante est à associer à la classe-association et toutes les possibilités de multipli-
cités sont permises.
Concernant l’exemple des installations de logiciels, un premier choix peut se porter sur les
couples (logiciel, serveur) qui recensent toutes les compatibilités (et évitent ainsi les incom-
patibilités). La classe-association contient la date d’installation (qui dépend en fait du seul
couple). L’association d’installation concerne bien simultanément les trois classes en reliant un
couple (logiciel, serveur) au département acteur de l’événement.
Figure 1-44. Compatibilité assurée

Une deuxième alternative consiste à considérer les couples (logiciel, département) qui recen-
sent tous les achats (évitant ainsi d’installer un logiciel non acquis par le département). La
classe-association contient la date d’installation (qui dépend en fait du seul couple). L’asso-
ciation d’installation concerne toujours simultanément les trois classes en reliant un couple
(logiciel, département) aux serveurs dont le but est l’hébergement. La date d’installation doit
se trouver au niveau de cette association avec cette modélisation.
Figure 1-45. Achats vérifiés
Une troisième alternative consiste à considérer les couples (département, serveur) qui recen-
sent toutes les autorisations (évitant ainsi d’installer un logiciel sur un serveur non accessible
par le département). Cette solution est symétrique à la précédente.
Figure 1-46. Autorisations acquises

La dernière alternative consiste à inclure ces trois contraintes dans le même diagramme.
Il restera à préciser ces contraintes à l’aide d’un langage naturel ou par l’intermédiaire du
pseudo-code du langage OCL (voir la fin du chapitre).
Figure 1-47. Toutes les contraintes sont respectées
En décomposant au maximum une association n-aire, vous compliquez le schéma relationnel,

mais réduisez le risque d’incohérences dans la base de données.
En préservant une association n-aire, vous simplifiez le schéma relationnel mais risquez des
anomalies de stockage du fait d’absence de contrôle en insertions et modifications.
Mise en pratique
L’exercice 1.4 « La décomposition des n-aires » vous permettra de décomposer les prétendues
associations n-aires (en les réduisant à des associations binaires ou en regroupant judicieu-
sement des classes en couple relié à une classe-association).
Les agrégations
La notion d’agrégation a été l’un des aspects les plus discutés de la notation UML. L’agréga-
tion concerne seulement les associations binaires (réflexives ou non). Une agrégation n’est pas
une association symétrique, car une des extrémités du lien d’association joue toujours un rôle
prédominant par rapport à l’autre.
Selon P. A. Muller, [MUL 00], une agrégation est préconisée dans les cas suivants :
●● une classe fait partie d’une autre classe ;
●● une action sur une classe implique une action sur une autre classe ;
●● les objets d’une classe sont subordonnés aux objets d’une autre classe.

Dans la littérature, plusieurs types d’associations sont recensés : component-integral,

material-object, portion-object, place-area, member-brunch et member-
partnership.
Avec UML, il existe deux familles d’agrégation : l’agréation simple (partagée) et la composi-
tion. La première regroupe les associations binaires qu’on désire renforcer suivant les critères
précédemment cités (agrégations faibles). La seconde constitue les agrégations fortes, traduction
des associations binaires de type composite/composant ou fait partie de.
La composition requiert qu’un objet appartienne au plus à une composition d’objets à un instant
donné. Cette appartenance peut changer au cours du temps. La composition implique en outre
une forme de propagation entre le composite et le composant (en particulier la destruction du
composite entraînera obligatoirement la destruction de ses composants). Cette agrégation est
représentée par un losange noirci du côté du rôle de la classe composite appelée « agrégat ».
L’agrégation partagée autorise qu’un objet appartienne simultanément à différentes compo-
sitions d’objets. Cette agrégation est représentée par un losange clair du côté du rôle de la
classe concernée par l’association appelée « agrégat ».
Les agrégations partagées sont un peu plus difficiles à définir, elles renforcent le couplage
d’une association binaire et interviennent lorsque la composition ne s’applique pas et que des
objets sont fortement dépendants par rapport à d’autres objets dans le cadre de l’association.
Figure 1-48. Agrégations
Considérons l’exemple ci-dessus faisant intervenir des agrégats.

●● La composition exprime qu’un appartement appartient à un seul immeuble et est identifié
par un numéro et le numéro de son immeuble. Par ailleurs, il est entendu que sa destruction
entraînera la destruction des appartements associés.

●● Les agrégats partagés (habiter et localiser) renforcent une simple association par le
fait que la perte d’un copropriétaire ou d’un immeuble est susceptible d’entraîner la sup-
pression des adresses associées. Il ne s’agit pas ici d’une relation composite/composant, car
une même adresse (d’un immeuble ou d’un copropriétaire) peut être partagée par différents
copropriétaires.
Du fait que la suppression d’un appartement n’implique pas la perte du copropriétaire associé
(qui peut être copropriétaire d’autres appartements), l’association appartient est la moins
contrainte.
Dans un contexte de schéma conceptuel de base de données, la notion d’agrégation partagée

est un peu trop vague et pas toujours implémentée par les outils (en termes de traduction de
la nature des clés étrangères). Mieux vaut programmer au niveau de SQL les contraintes de
chaque agrégation.
Concernant les agrégations fortes, il convient de les utiliser sans modération. Elles convien-
nent à traduire toute composition, l’identification relative de classes et des aspects temporels.
Il est donc préférable que l’association de composition soit implémentée par l’outil de conception
que vous choisirez.
L’identification relative
Dans certaines situations, l’identification d’une classe nécessite de se positionner relativement
par rapport à une autre classe.
L’identification relative a son histoire, abordée initialement dans Merise ; elle est absente de
l’ouvrage de référence. À partir de 1987, A. Rochfeld et J. Morejon réhabilitent cette notion à
travers le concept d’entité faible qui s’intègre à Merise/2 ainsi que dans la plupart des outils
associés.
Notations avec Merise

Une entité faible trouve son identification à l’aide de la ou des classes fortes associées. Dans
l’outil Win’Design, un lien d’association connecté à une entité faible est noté (R), PowerAMC
l’indique avec (1,1).
L’exemple suivant modélise un appartement en tant qu’entité faible du fait que seul le numéro
d’appartement ne suffit pas à identifier un appartement. Il est en effet possible qu’il existe
plusieurs appartements numérotés « 1A », « A1 » ou « 23 » par exemple. Pour permettre que
différents appartements disposent du même numéro, il faut les identifier relativement par rap-
port à leur immeuble. En supposant deux immeubles numérotés « i1 » et « i2 », les couples
(« 1A », « i1 ») et (« 1A », « i2 ») sont distinguables et permettent un même code d’appartement.

Figure 1-49. Entité faible
Par analogie, en qualifiant de faible, la classe qui nécessite l’identifiant d’une autre classe et
en utilisant l’agrégation forte, UML implémente ce mécanisme.
Réification
Dans la sémantique du discours, sous-tendue par la structure grammaticale, lorsqu’on passe
progressivement d’une association (groupe verbal) à un objet (groupe nominal), on parle
de réification (ou substantification). La modélisation conceptuelle est avant tout une vision
sémantique : la perception en classe ou association prime sur la manière de l’identifier. Ce n’est
pas l’identification qui détermine la modélisation, mais le choix de modélisation qui implique
l’identification.
Le concept à modéliser peut apparaître de prime abord en tant que forme verbale (une associa-
tion) : un avion est affrété par une compagnie. Puis progressivement, la forme verbale devient
substantive : pour chaque affrètement…, les vols affrétés… Ce groupe nominal (un objet d’une
classe) intervient à son tour dans des associations.
Exemples avec UML

La modélisation suivante permet d’identifier un affrètement par le code de la compagnie,
l’immatriculation de l’avion et un jour de l’année. Si différents affrètements sont possibles au
cours d’une journée ; vous devrez ajouter à l’identifiant de la classe faible Affretement la
propriété heure.

Figure 1-50. Identification relative (exemple)
Considérons à présent des véhicules qui visitent quotidiennement des chantiers et appelons
mission chaque déplacement journalier. Chaque mission est identifiée par le véhicule et le
jour de sortie. L’attribut km_journalier de la classe faible Mission désigne la distance
parcourue d’un véhicule dans la journée.
Figure 1-51. Identification relative (résultat)
Alternatives
À la question « Y a-t-il une unique solution à toute conception ? », la réponse est négative ;
plusieurs schémas différents peuvent modéliser le même système. Selon le mécanisme que
vous utiliserez, diverses solutions peuvent émerger. Les mécanismes qui sont potentiellement
interchangeables sont les classes-associations, les associations de composition et l’identification
artificielle.
Les modélisations suivantes sont équivalentes. Le premier schéma utilise une classe-associa-
tion pour décrire chaque mission, alors que le second considère une mission comme un objet
artificiel qu’il est nécessaire d’identifier.

Figure 1-52. Alternatives à l’identification relative
Les différences vont se rencontrer au niveau logique. Il faudra alors préférer la solution opti-
male en termes de tables en raisonnant sur les index qu’il faudra générer.
Mise en pratique
Comment modéliser l’historique des rendez-vous de l’exercice 1.5 « Les comptes ban-
caires » ?
Trouvez les identifiants principaux et relatifs qui sont présents dans l’exercice 1.6 « Le
RIB ».
L’identification artificielle
Lorsque l’identification d’un objet est complexe ou met en jeu beaucoup trop d’autres classes,
vous pouvez faire appel à l’identification artificielle qui consiste à définir une classe (le plus
souvent de nature abstraite) afin d’héberger des attributs pour lesquels il est difficile d’y asso-
cier un identifiant naturel ou relatif. Une fois définie, la classe nécessite un identifiant (artificiel)
qui sera dépourvu de toute sémantique.
Considérons l’exemple des tronçons autoroutiers (section « Les classes-associations »). Alors
que la réflexivité n’était pas la solution la plus simple pour modéliser un tel graphe, l’identifica-
tion artificielle se révèle redoutable de simplicité. Un tronçon est désormais modélisé en tant
qu’objet relié à deux villes. L’association de composition permet en plus de pouvoir utiliser un
même numéro de tronçon pour différentes autoroutes.

Figure 1-53. Identification artificielle pour des objets concrets
Considérons l’exemple des installations de logiciels (section « Les associations n-aires »). Bien
que la classe-association soit une solution satisfaisante, l’identification artificielle est aussi pos-
sible. Une installation est modélisée en tant qu’objet abstrait relié aux classes qui interviennent
dans l’association.
Figure 1-54. Identification artificielle pour des objets abstraits

Mise en pratique
Aidez-vous de l’identification artificielle pour :
●● compléter l’exercice 1.5 « Les comptes bancaires » en modélisant les virements internes
entre comptes. Il s’agit de connaître le montant en euros, le client initiateur et la date de

l’opération ;
●● finaliser le diagramme 1.7 « L’organisme de formation (suite) ». Il s’agit de modéliser les
sessions de cours et différents événements les concernant.
L’héritage
L’héritage est un mécanisme qui provient de la programmation objet et qui consiste à réutiliser
du code (en termes de fonctionnalités). Dans le contexte d’un modèle conceptuel, l’héritage va
permettre la réutilisation de structures (classes). Une classe générique (appelées surclasse) rend
possible la définition de classes plus spécifiques (appelées sous-classes). Par conséquent, cette
décomposition rend les associations entre classes plus précises.
À l’origine, les modèles entité-association ne disposaient pas de ce concept. Des extensions
comme Merise/2 ont rendu possible le mécanisme d’héritage qui permet d’organiser les entités
en hiérarchies. La notation objet UML propose l’héritage de classes depuis sa première
spécification.
Définition
Vous devez définir un héritage entre les classes C1 et C2 si vous répondez affirmativement à
la question : la classe C1 est-elle une sorte de C2 ?
La surclasse généralise le concept alors que les sous-classes le spécialisent.
L’héritage représente un lien très fort entre classes. Avec UML, un lien d’héritage est noté par
une flèche partant d’une sous-classe vers sa surclasse.
Dans l’exemple suivant, la surclasse Personnel permet aux sous-classes Navigant et
ommercial de récupérer les attributs nup, nom et salaire qui sont génériques. Chaque
C
classe (générique ou spécifique) peut être reliée à d’autres en exprimant davantage de séman-
tique qu’en l’absence d’héritage.

Figure 1-55. Héritage
Identification
N’ajoutez pas d’identifiant à une sous-classe, car l’identifiant d’une sous-classe provient de
la surclasse.
Instances
Différents cas d’héritage peuvent être recensés en fonction de la population (instances) des
classes qui participent au graphe d’héritage [ADI 93].
Dans l’exemple précédent il faudra être capable de répondre aux questions suivantes : existe-
t-il un personnel qui ne soit ni navigant ni commercial ? Est-il possible qu’un navigant soit
aussi commercial ?
Nous étudierons cette classification à la section « Règles métier et contraintes ».
Héritage multiple
Relativement peu utilisé par les programmeurs objet, car complexe à mettre en œuvre, l’hé-
ritage multiple est le mécanisme qui autorise qu’une sous-classe hérite simultanément de
plusieurs surclasses. Dans l’exemple suivant, il permet de répondre à l’affirmative à la question :
est-il possible qu’un navigant soit aussi commercial ?

Figure 1-56. Héritage multiple
Bien que séduisant, ce mécanisme n’est implémenté dans aucune base de données objet et dans
très peu de langages. De plus, il est possible de s’en passer par l’intermédiaire des contraintes
sur un héritage simple.
Mise en pratique
Appliquez ce mécanisme aux différents cas de l’exercice 1.8 « L’héritage ».
Aspects temporels
Il est très fréquent d’avoir à prendre en compte des aspects temporels au niveau conceptuel. On
peut classifier trois modélisations : le moment, la chronologie et l’historisation.
Évitez de nommer un attribut temporel par un mot réservé du langage informatique (exemples :
date, month, day, etc.). Préférez des identificateurs plus parlants (exemples : date_nais-
sance, date_vente, mois_arrivee, etc.). Précisez toujours au niveau du dictionnaire de
données le format que vous attendez (jour/mois, jour/mois/année sur 4 positions, etc.).
Modélisation d’un moment

Il s’agit de représenter des informations indiquant un moment (le plus souvent une date). Ce
moment est représenté sous diverses formes : jour, mois, jour/mois, année, mois/année, jour/
mois/année, avec ou sans les heures, minutes et secondes, etc. Le plus souvent, cet attribut sera
positionné dans une classe.

L’exemple décrit quelques attributs temporels. On peut supposer que annee_creation et

annee_ouverture seront au format année (entier sur 4 positions), mois_ouverture au
format mois (entier sur 2 positions) et date_contrat au format jour/mois/année. Ce dernier
attribut se trouve dans la classe-association, car un supermarché peut être en rapport avec
plusieurs fournisseurs, de même un fournisseur peut traiter avec différents supermarchés. La
modélisation indique ici qu’une seule date sera mémorisée pour tout supermarché avec un
fournisseur (c’est donc probablement la dernière qui sera stockée).
Figure 1-57. Modélisation de moments
Modélisation de chronologie
Il s’agit de modéliser des situations où le temps intervient de manière régulière (plannings,
emploi du temps, prévisions, statistiques, etc.). Le plus souvent, cet attribut sera considéré en tant
que classe. Les formats de cette donnée peuvent aussi être divers (jour, mois, jour/mois, etc.).
L’exemple suivant décrit les attributs de chronologie num_sem (de 1 à 52) et num_jour_an (de
1 à 365) qui identifient respectivement les classes Semaine et Jours. Ici, on suppose que la
précision d’une semaine est suffisante pour connaître l’activité des enseignes et des fournisseurs.
Figure 1-58. Modélisation de chronologies

Modélisation de l’historisation
On utilise ce type de modélisation quand on désire conserver les valeurs antérieures d’un
attribut. Citons quelques exemples comme le montant d’un loyer (on désire connaître son évo-
lution) ou la valeur du coefficient bonus/malus d’un contrat d’assurance. En contre-exemple
(traité dans les exercices), le nombre de passagers d’un vol donné sera plutôt traité comme une
chronologie.
Alors que Merise/2 dispose d’un artifice pour noter l’historisation (symbole H sur un lien d’as-
sociation), l’historisation avec UML peut s’apparenter à de l’identification relative et donc
s’implémenter à l’aide d’une association d’agrégation forte (composition).
L’exemple suivant décrit deux historisations modélisées par une composition (une classe-asso-
ciation aurait aussi pu convenir). La classe Contrats permettra de lister les différents contrats
au cours du temps entre un supermarché et un fournisseur. La classe Gerances permettra de
faire évoluer l’appartenance d’un supermarché à une enseigne.
Figure 1-59. Modélisation d’une historisation

Modèles diachroniques, modèles synchroniques et gestion du temps dans les données…

La gestion du temps (date ou date + heure des faits) dans les bases de données relation-
nelles est un point crucial et complexe, qui, lorsqu’il est mal géré, peut conduire à des
problèmes de performances dramatiques. On appelle « modèle synchronique » un modèle
dont on copie les données à un instant t afin de les statifier (copie synchrone au fait).
Par opposition, on appelle » modèle diachronique » un modèle dans lequel on historise
chaque évolution des données (dia signifie « jour »).
Bien que le modèle synchronique apparaisse plus simple, il possède souvent plus d’incon-
vénients que d’avantages :
• il est fortement redondant : par exemple, un même libellé de produit va apparaître de
nombreuses fois dans les commandes, les factures, les envois… ;
• il induit une perte d’information : si un produit ne s’est pas vendu et qu’on le solde, il
n’existe aucun moyen de savoir qu’il avait été proposé à un prix antérieur et pendant
combien de temps.
Il est donc souvent intéressant de passer au modèle diachronique. Et comme les bases de
données évoluent, il est probable que les SGBDR bitemporels fassent leur apparition dans
peu de temps, réduisant ainsi ces problèmes à des mécanismes internes optimisés. Pour en
savoir plus sur le sujet, consultez les sites suivants.
• Bases de données bitemporelles :
http://fr.wikipedia.org/wiki/Base_de_donn%C3%A9es_temporelle
• Conception bitemporelle d’une base : http://www.itpro.fr/sql-server/administration/
conception-bitemporelle-une-notion-du-temps-peut-en-cacher-une-autre/
• Gestion bitemporelle des données :
ttp://www.trivadis.com/uploads/tx_cabagdownloadarea/F_Bitemp_ f.pdf
• Sixième forme normale et temporalité :
http://fsmrel.developpez.com/basesrelationnelles/normalisation
Mise en pratique
Utilisez ces aspects temporels pour :
●● gérer l’historique des coupes du monde de football (suite de l’exercice 1.1 « La déroute des
Bleus ») ;
●● faire évoluer le prix d’un produit et son taux de TVA (suite de l’exercice 1.3 « Les lignes
de facture ») ;
●● modéliser le cycle de vie des véhicules dans l’exercice 1.9 « Les cartes grises ».

La démarche à adopter
La première étape de conception est la mise en place du dictionnaire des données. Vous devrez
lister, de manière minimale, les attributs à stocker en rendant vos phrases élémentaires et sans
formuler des propositions incomplètes, redondantes, contradictoires ou fausses.
Décomposition en propositions élémentaires

Décomposez le discours en autant de propositions élémentaires (sujet-verbe-complément) que
nécessaire.
Tableau 1-8 : Quelques propositions
Satisfaisantes ●● Une commande est confirmée par un représentant.

●● Un client est identifié par son e-mail.
●● Un texte de loi doit être associé à plusieurs mots-clés.
Incomplètes ●● Un vol part d’un aéroport tous les jours à la même heure.
●● Les chantiers sont visités une fois par semaine.
●● La remise est proportionnelle à la quantité achetée.
À reformuler ●● Un logiciel est installé par un département sur un serveur.
●● Un personnel commercial travaille au comptoir de la compagnie dans un des
aéroports de sa zone d’affectation.
●● Un client réalise des achats de produits chez des fournisseurs.
Décomposons de manière intuitive le dernier exemple de manière à extraire des propositions

plus élémentaires.
●● « Un achat est effectué par un client. »
●● « Un achat concerne plusieurs produits. »
●● « Un achat s’effectue chez un fournisseur. »
On peut modéliser Client, Produit et Fournisseur en tant que classe. Achat sera la
classe-association reliant Fournisseur au couple (Client, Produit).
Propositions incomplètes
Il ne doit pas exister de proposition incomplète. Ainsi toute proposition mettant en jeu plu-
sieurs classes « Un logiciel est installé par un département sur un serveur. » risque d’être
incomplète. Vous devrez préciser cet événement en considérant les classes deux à deux.
●● « Un département peut-il installer tout logiciel ? »

●● « Un serveur peut-il accueillir tout logiciel ? »

●● « Un département peut-il utiliser tout serveur ? »
Il est peu probable que la réponse à chacune de ces propositions soit « oui ». Vous traduirez ainsi
chaque proposition en associations binaires en incluant éventuellement des classes-associations.
Chronologie des étapes

La construction idéale d’un schéma conceptuel suit les étapes suivantes. Les sections pré-
cédentes vous permettent de répondre jusqu’au point numéro 5, les sections suivantes
compléteront ce processus.
1. Établir la liste des attributs.
2. Épurer les attributs (éviter les synonymes et polysémies, décomposer les attributs com-
plexes).
3. Repérer les identifiants (si nécessaire en créer) et en déduire les classes.
4. Disposer les attributs dans les classes (dépendances).
5. Déterminer les associations entre classes.
6 Rattacher les attributs « orphelins » (dans des classes ou classes-associations).
7. Valider le modèle (dépendances).
8. Mise en place des contraintes.
Un attribut doit être propre à une entité

Ce simple précepte est souvent mal compris par les développeurs.
Prenons le classique cas d’une entité modélisant une personne physique, pour laquelle on
veut recueillir le maximum d’informations, y compris les informations de contacts.
Sont propres à l’entité « personne physique » le nom, les prénoms, la date de naissance,
le poids, la taille, la couleur des yeux… Mais de nombreux développeurs y ajoutent les
numéros de téléphone, l’e-mail, l’adresse… Or, aucune de ces informations n’est propre à
la personne. Où trouvez-vous le numéro de téléphone d’une personne physique ? Sous les
aisselles ? tatoué sur l’oreille ? au bout de la langue ?
La meilleure preuve qu’un téléphone ou une adresse n’est pas un attribut d’une personne
physique est que ces informations peuvent être afférentes à une personne morale : entre-
prise, collectivité, association… Une autre preuve que le téléphone ou l’e-mail n’est pas
un attribut de la personne est que certaines personnes n’ont ni téléphone ni e-mail ! Ces
informations ne sont donc pas des attributs de la personne, mais des attributs relatifs à
la personne (physique ou morale d’ailleurs). Et le mot relatif n’est pas là par hasard, car
en français il signifie (selon le Larousse) « qui n’existe qu’en relation avec quelque chose
d’autre, qui n’est pas indépendant »…

Autrement dit, ces attributs doivent être placés dans des entités secondaires associées à
l’entité primaire que constitue la personne. On aura donc trois entités supplémentaires :
l’une pour les téléphones, l’autre pour les adresses et la troisième pour les e-mails. Notez
que cette conception induit de multiples avantages parmi lesquels chaque personne peut
avoir un nombre indéterminé de téléphones (fixe, fax ou GSM…), plusieurs adresses et
une multiplicité d’e-mails, ce qui est courant !
Le fait de mettre tous les attributs de contacts dans une seule et même entité « personne
physique » contribue à créer des tables obèses dont les performances seront catastro-
phiques lors de la montée en charge de la base.
À lire sur le sujet : http://blog.developpez.com/sqlpro/p10070/langage-sql-norme/base-
de-donnees-et-performances-petites/.
Quelques conseils
Afin de rendre optimal un schéma conceptuel (minimiser les modifications à opérer avant de
créer des tables et index), quelques principes doivent être adoptés.
Décomposez si nécessaire
Décomposez tout attribut dont la structure est complexe en autant d’attributs que nécessaire.
Chacun de ces attributs devra être indécomposable (atomique). L’exemple le plus marquant est
l’adresse normée dont chaque champ possède une sémantique propre.
Figure 1-60. Adresse postale
Ainsi, préférez l’utilisation de la classe Adresse à l’attribut de même nom. D’une part, cette
classe pourra être connectée à différentes autres classes (Client, Fournisseur, Succur-
salle, etc.). D’autre part, il sera possible d’indexer différentes colonnes pour faciliter des
recherches dans la base de données (sur le code postal, le nom d’une rue, etc.).

Figure 1-61. Modélisation d’une adresse
Pour compléter cette modélisation, il faudrait connecter la classe Ville à la classe Adresse.
Tous les attributs d’une entité doivent être atomiques

Cette règle doit être appréciée à sa juste valeur… Elle est en effet relative à l’univers que
l’on modélise. Par exemple, la modélisation d’un simple numéro de Sécurité sociale sera
différente si vous l’avez à titre informatif (par exemple, dans le cadre de la gestion des
ressources humaines) ou à titre fonctionnel (par exemple, dans le domaine de la santé). À
titre informatif, un seul attribut de type chaîne de caractères de longueur 13 suffit. À titre
fonctionnel, il est important de découper ce numéro en autant de parties :
• le sexe sur un caractère ;
• l’année de naissance sur deux caractères ;
• le mois de naissance sur deux caractères ;
• le code Insee de la commune de naissance sur cinq caractères (et non le département
puis la commune comme on le croit trop souvent) ;
• le rang de naissance sur trois caractères.
En effet, il est possible que l’on vous demande un jour d’extraire toutes les femmes de la
tranche 45 à 60 ans nées en région parisienne, pour une étude sur le cancer du sein…
Un autre exemple nous est donné par les e-mails. On a tendance à oublier qu’un e-mail
est composé de deux parties : partie locale (en général, un nom de personne ou de service)
et un DNS (Domain Name Server ou nom de domaine) le tout accolé avec le caractère
@ (arobase) entre les deux. Il sera donc intéressant de décomposer les e-mails en deux
entités liées comme suit :
• MAIL_USER (MLU_ID entier auto, MLU_LIBELLE A256), l’identifiant étant MLU_ID ;
• MAIL_DNS (MLD_ID entier auto, MLD_LIBELLE A256), l’identifiant étant MLD_ID.
Avec la cardinalité n:1 entre MAIL_USER et MAIL_DNS, la volumétrie est réduite : on évite
ainsi la redondance des wanadoo.fr, free.fr, etc., on contrôle mieux la saisie, et l’indexa-
tion est facilitée. Bref, de nombreux bénéfices pour les performances.

Évitez les attributs calculés

Avant de penser à la dénormalisation de vos tables, minimisez le nombre d’attributs de
vos schémas. Ne considérez pas les attributs qui peuvent être déduits par calcul d’autres
attributs déjà présents dans le schéma. Dans la facture suivante, le fait de rendre pertinents
les attributs ref_produit, prix_tarif, quantite et remise suffit à calculer le prix
unitaire et le montant d’une ligne. Il en va de même pour les différents totaux intermédiaires
et finaux.
Figure 1-62. Attributs calculés
Les erreurs classiques

Pour éviter de tomber dans certains pièges, voici quelques erreurs caricaturalement présentées.
Le ventilateur
Afin d’éviter le piège dit « du ventilateur », soignez vos parcours d’associations (particulièrement
pour les liens à terminaison *) et suivez la hiérarchie.
Dans le premier exemple, s’il est vrai qu’un employé est embauché par une entreprise com-
posée de départements, il apparaît aussi qu’il est impossible de savoir à quel département est
rattaché chaque employé (lien Composer à terminaison *). En réorganisant la hiérarchie de
ces classes, ce problème est résolu.

Figure 1-63. Le ventilateur, exemple 1
Dans le second exemple, s’il est vrai qu’un serveur est responsable de plusieurs tables, il appa-
raît aussi qu’il est impossible de savoir quel serveur a encaissé une note (lien planning à
terminaison *). Une association supplémentaire résout ce problème.
Figure 1-64. Le ventilateur, exemple 2
L’abîme
Le piège de « l’abîme » concerne la présence de multiplicités minimales à zéro sur le parcours
de lecture d’associations entre deux classes reliées indirectement.
Dans l’exemple suivant, la multiplicité 0..1 du lien gestionnaire signifie que certains ser-
veurs peuvent être anonymes en termes de propriétaire. Pour remédier à ce risque de perte
d’informations, il suffit de rajouter un lien d’association rendant le parcours plus direct.

Figure 1-65. L’abîme
Les liens transitifs

Ne supprimez pas systématiquement les liens qui pourraient sembler redondants du fait d’une
transitivité (si je sais aller de A à B et de B à C, pourquoi devrais-je ajouter que je sais aller
de A à C ?). Avant de simplifier au maximum vos schémas (et donc le nombre d’associations),
évaluez les conditions initiales et projetez des évolutions temporelles.
Dans le premier exemple, le lien concerne peut sembler redondant. Aucun risque d’abîme,
car les multiplicités minimales du parcours sont non nulles. En revanche, il se peut qu’on
connaisse le fournisseur concerné par la commande avant qu’un représentant ne soit désigné
pour déclencher une commande.
Figure 1-66. Liens transitifs

Concernant le second exemple, le lien embaucher peut sembler redondant. Le problème vient
d’un risque d’abîme en ne sachant pas de quelle entreprise un représentant dépend du fait que
ce dernier peut ne pas être rattaché à une succursale.
Ne confondez pas conceptuel et logique

Un diagramme de classes UML ne rime pas forcément avec schéma conceptuel. Vous êtes en
présence d’un modèle logique (voir le chapitre suivant) lorsqu’un attribut identifiant est pré-
sent dans différentes classes. Ce sont les schémas qu’on peut créer à l’aide des outils comme
Access, DB Designer, MySQL Workbench, etc.
Dans le schéma suivant, les attributs CustomerId, OrderId, DeliveryId, OrderItemId et
ProductId se retrouvent dans différentes classes. Ce modèle est plus proche des tables de la
base de données que ne le serait un schéma conceptuel équivalent. Néanmoins, ce modèle est
plus difficile à concevoir en partant de rien (sans débuter par le niveau conceptuel).
Figure 1-67. Schéma logique avec
Les faits, seulement les faits !

Ne raisonnez pas en termes de traitements, mais seulement en termes de faits tangibles et
pertinents.
Le tableau suivant présente quelques propositions faisant intervenir de plus en plus de traite-
ments au détriment des données.

Tableau 1-9 : Données et traitements
Données ●● Tout passager d’un vol commercial dispose d’un siège numéroté.
prépondérantes ●● Un client cumule des miles à chaque voyage.
Données et un peu de ●● Un passager peut embarquer avec un bagage pas trop volumineux ni trop lourd.
traitement ●● Un passager peut disposer ses affaires dans un coffre à bagages.
Traitements ●● Le solde du compte du client ne doit pas être négatif pour pouvoir commander un billet.
prépondérants ●● Le montant du billet est débité sur le compte du client dès la commande.
Les données sont prépondérantes, car les attributs num_siege, nom_client et nombre_
miles apparaissent assez facilement.
Un peu de traitement est mélangé avec des données lorsqu’il faut approfondir certaines ques-
tions telles que « Doit-on stocker le volume ou le poids du bagage à main des passagers ? »,
« Doit-on connaître la contenance ou la charge limite d’un coffre à bagages utilisé lors du
voyage ? ». Peut-être des attributs tels que masse_bagage_main, masse_max et volume_
max devront être pris en compte.
Les traitements sont prépondérants lorsqu’il s’agit de processus dépendants de la valeur de
certains attributs déjà existants ou mettant à jour de tels attributs.
Les concepts inutiles de UML

Concernant les bases de données, tout n’est pas bon à prendre dans la notation UML. Ainsi,
les concepts suivants sont inutiles :
●● association navigable : les instances d’une classe ne doivent pas connaître les instances
d’une autre classe reliée par une association. Concept analogue au « private » des
langages objet, il ne peut être implémenté que par programmation. Dans l’exemple
suivant, l’association prefere vise à interdire que tout candidat puisse connaître ses
électeurs ;
●● association dérivée : déductible de plusieurs autres associations. Préfixée par le symbole /,
l’association sympathisant peut être déduite (quoique…), de la présence des associations

prefere et appartenance ;
●● association qualifiée : permet de restreindre les objets référencés dans une association
grâce à une clé. L’exemple suivant est extrait de l’article Applying UML and Patterns: UML
Class Diagrams de C. Larman (disponible sur http://www.informit.com). Le qualificateur
itemID enrichit l’identifiant de la classe Product Catalog. Ainsi, à tout couple (numéro
de produit, itemID) est associé une seule description.

Figure 1-68. Association UML navigable et dérivée
Figure 1-69. Association UML qualifiée
Les associations navigables ne sont pas significatives du point de vue des données, mais des
traitements.
Les associations dérivées peuvent être perçues comme redondantes, mais si elles doivent
être définies, elles devront être considérées comme des associations binaires standard.
Les associations qualifiées doivent être mises en œuvre par le concept d’agrégation forte
(composition).

Un seul schéma valable ?

Ne vous désolez pas si le schéma que vous créez est différent de celui de votre collègue qui
réflechissait à la même conception. Il n’existe pas qu’un seul schéma pour modéliser un certain
univers. Dans la majorité des cas, le mécanisme d’identification artificielle ou l’agrégation
forte peuvent être préférés à celui de la classe-association.
La qualité d’un schéma se jugera lors de la transformation en tables, clés et index. Moins vous
aurez à agir pour rendre optimales vos tables, plus votre schéma conceptuel sera idéal. L’ex-
périence venant, vous serez à même de mieux choisir en amont le mécanisme optimal pour
relier vos classes.
Règles métier et contraintes

Une contrainte indique en général une restriction ou donne des informations complémentaires
sur un modèle d’un point de vue sémantique. Chaque contrainte peut formaliser une règle
métier et permet de préparer l’implémentation à la manière d’un pseudo-algorithme.
Quelles que soient les contraintes que vous définirez dans vos diagrammes conceptuels,
aucune modification structurelle ne sera répercutée dans les schémas relationnels générés.
Toute contrainte devra être implémentée au niveau du code SQL (par contraintes, déclen-
cheurs ou procédures cataloguées).
Pour les contraintes personnalisées, des rôles doivent être utilisés au niveau des associations
qui seront concernées par une contrainte.
La spécification UML 2 ne propose pas beaucoup de contraintes prédéfinies et bien peu d’ou-
tils les incluent. En contrepartie, toute contrainte peut être écrite soit à l’aide du langage OCL
(Object Constraint Language), soit en langage naturel.
Graphiquement, une contrainte est un texte encadré d’accolades qui s’applique au niveau d’un
attribut, d’un rôle, ou entre associations nommées.
Les contraintes qui s’appliquent à un ou entre plusieurs éléments peuvent être notées de diffé-
rentes façons [AUD 09] :
●● en plaçant la contrainte à côté d’un attribut ou à l’extrémité d’une association ;
●● en ajoutant une note associée à l’élément à contraindre ;
●● en plaçant la contrainte sur une flèche en pointillés joignant les deux éléments de modèle
à contraindre ensemble, la direction de la flèche constituant une information pertinente au

sein de la contrainte ;
●● en plaçant la contrainte sur un trait en pointillé joignant les deux éléments de modèle à
contraindre ensemble dans le cas où la contrainte est bijective ;

●● en utilisant une note reliée, par des traits en pointillés, à chacun des éléments de modèle,
subissant la contrainte commune, quand cette contrainte s’applique sur plus de deux éléments
de modèle.
Contraintes prédéfinies
Les contraintes prédéfinies se notent en général à l’extrémité d’un lien d’association (au même
niveau que le rôle). Les plus intéressantes dans un contexte de bases de données sont :
●● {subsets nom_rôle} exprime l’inclusion d’une association par rapport à une autre ;
●● {xor} qui indique le OU exclusif entre objets reliés par deux associations.
Dans l’exemple suivant, la contrainte xor précise qu’un consultant est soit associé à un projet,
soit à une formation, mais jamais aux deux simultanément.
Figure 1-70. La contrainte du OU exclusif
Dans l’exemple suivant, la contrainte subsets exprime le fait que les formations effectuées
par un stagiaire ont été préalablement listées au niveau de l’association vœux.
Figure 1-71. La contrainte d’inclusion

Les autres contraintes prédéfinies de UML sont les suivantes :

●● {redefined nom_rôle} redéfinit un rôle ;
●● {union} signifie que le rôle rassemble une union de sous-ensembles ;
●● {ordered} exprime un ordre au niveau des objets reliés ;
●● {bag} exprime qu’un même objet cible peut apparaître plusieurs fois dans l’association ;
{sequence} notée aussi {seq} combine les caractéristiques de bag et de ordered.
En l’absence de ces contraintes (cas le plus général et celui par défaut), la terminaison d’une
association est dite de type set (chaque objet relié n’est présent au plus qu’une seule fois
dans l’association).
Pour formaliser toute autre contrainte, vous pouvez utiliser le langage OCL.
Contraintes personnalisées (langage OCL)

OCL (Object Constraint Language) est un langage formel, basé sur la logique des prédicats du
premier ordre, pour annoter les diagrammes UML en permettant notamment l’expression de
contraintes. À l’origine, OCL a été développé en 1997 par Jos Warmer (IBM), sur les bases du
langage IBEL (Integrated Business Engineering Language). OCL existe depuis la version 1.1
d’UML et fait partie intégrante de la norme UML depuis la version 1.3.
Dans le cadre d’UML 2.0, les spécifications du langage OCL figurent dans un document indé-
pendant de la norme d’UML, décrivant en détail la syntaxe formelle et la façon d’utiliser
ce langage : http://www.omg.org/spec/OCL/2.0/PDF. Un ouvrage plus complet a été publié
[WAR 03].
OCL permet de spécifier des contraintes sur l’état d’un objet ou d’un ensemble d’objets princi-
palement à l’aide d’invariants sur des classes et des préconditions/postconditions à l’exécution
d’opérations. Une expression OCL décrit une contrainte à respecter et ne décrit pas l’implé-
mentation d’une méthode.
L’exemple suivant décrit la contrainte OCL qui exprime, par l’intermédiaire de rôles, que tout
employé est soit :
●● chef, et dans ce cas il n’a pas de chef (condition isEmpty vérifiée) ;
●● sous la responsabilité d’un chef qui doit être employé dans la même entreprise que lui
(deuxième partie de la condition).

Figure 1-72. Contrainte OCL basée sur les rôles
L’exemple suivant s’inspire de [MAK 08] et présente deux contraintes basées sur des ensembles
d’objets.
Figure 1-73. Contraintes OCL basées sur des ensembles d’objets

La règle OCL (R1) qui décrit la contrainte des clauses du contrat est la suivante :
context Vehicule inv R1 :
self.implique → forAll
(s | s.option → forAll
(c | c.prevoit → exists(co |
➥co.beneficiaire=self)))
La règle OCL (R2) qui formalise la contrainte de dates est la suivante :

context Contrat inv R2 :
self.clauses → forAll
(c | c.sinistres → forAll
(s | s.date_sinistre.isBefore
➥(self.date_contrat)))
Contraintes d’héritage
L’héritage a été présenté à la section « Les associations plus complexes » avec l’exemple de la
surclasse Personnel qui permet de spécialiser les sous-classes Navigant et Commercial.
Dans tout graphe d’héritage, différents cas peuvent être recensés en fonction des instances des
classes. Ces cas traduisent des contraintes que Merise/2 nommait la partition (appelée aussi
exclusion et totalité). En considérant les personnels comme navigants et commerciaux, cette
population peut être composée :
●● de navigants ou commerciaux exclusivement (cas A) ;
●● de navigants, de commerciaux et de personnels ni navigants ni commerciaux (cas B) ;
●● de navigants, de commerciaux et de personnels à la fois navigants et commerciaux (cas C) ;
●● de toute possibilité (cas D).
Figure 1-74. Différents cas d’héritage

Le tableau suivant illustre, pour chaque cas d’héritage, la contrainte à mettre en œuvre dans
le formalisme Merise et la notation UML. Notez que l’absence de contrainte dans un graphe
d’héritage n’a pas la même signification dans Merise/2 et dans UML. Le premier autorise
qu’une occurrence appartienne à plusieurs entités sous-types. UML considère que par défaut
un objet n’existe que dans une classe pour un niveau de hiérarchie donné.
Tableau 1-10 : Héritage : couverture et disjonction
Couverture Non-couverture
Disjonction (cas A) (cas B)
Merise/2 : Partition (XT) Merise/2 : Exclusivité (X)
UML : {complete,disjoint} UML : {incomplete,disjoint} (par défaut)
Non-Disjonction (cas C) (cas D)
Merise/2 : Totalité (T) Merise/2 : pas de contrainte (par défaut)
UML : {complete,overlapping} UML : {incomplete,overlapping}
Le schéma suivant précise l’association d’héritage en indiquant qu’il n’existe pas de personnel
qui ne soit ni navigant ni commercial.
Figure 1-75. Héritage avec la contrainte de partition
Contraintes avec OCL

La programmation OCL permet également de préciser ces types de contraintes, qu’il est pos-
sible de trouver ailleurs que dans un graphe d’héritage.

À titre d’exemple, les écritures suivantes décrivent la contrainte de partition (cas A) entre les
navigants et les commerciaux. La première règle, attachée à la classe Navigant, signifie
qu’un navigant ne peut pas être commercial. Notez l’utilisation de la fonction allInstances
qui retourne pour un type donné l’ensemble de ses instances, incluant aussi les instances de
ses sous-classes.
context Navigant inv Partition1 :
Commercial.allInstances.nup®excludes(self.nup)
La deuxième, attachée à la classe Commercial signifie, d’une manière symétrique, qu’un

commercial ne peut pas être navigant.
context Commercial inv Partition2 :
Navigant.allInstances.nup->excludes(self.nup)
La troisième règle doit être attachée à la classe Personnel et signifie :

●● qu’un personnel est soit navigant, soit commercial (par le fait du ou exclusif). La fonction
oclIsKindOf permet de tester la nature de la classe d’un type ;
●● que le numéro est l’identifiant (fonction isUnique).
context Personnel inv Partition3 :

(self.oclIsKindOf(Navigant) xor self.oclIsKindOf(Commercial))
and
(Personnel.allInstances.nup → isUnique(c | c.nup))
Mise en pratique
Rendez-vous à l’exercice 1.10 « Les contraintes » pour écrire formellement les expressions
OCL afin d’enrichir différents schémas.
Règles de validation
La notation UML ne propose aucun moyen de s’assurer de la cohérence d’un diagramme de
classes. Cela est particulièrement pénalisant pour les diagrammes qui visent à modéliser une
base de données. Les règles que vous devrez adopter s’inspirent des règles de validation et de
normalisation introduites avec les modèles entité-association et la méthode Merise. La plupart
de ces règles datent du milieu des années 1970. Ces règles sont majoritairement basées sur les
dépendances fonctionnelles.
Il est aisé de transposer ces règles à vos diagrammes de classes UML de manière à obtenir
automatiquement un schéma relationnel de qualité, en limitant les risques d’erreurs de modé-
lisation lourdes de conséquences au niveau de la base de données.

Les dépendances fonctionnelles

Edgar Codd fut le premier à publier des écrits sur les dépendances fonctionnelles [COD 72].
La signification du terme « fonctionnel » n’est pas vraiment celle qui est couramment utilisée
dans le monde de l’informatique de gestion, il s’agit plutôt d’une dépendance de valeurs entre
attributs.
L’explication de l’importance d’établir toutes les dépendances principales qui régissent
un diagramme de classes réside dans le fait que le schéma à créer est un modèle relationnel
basé sur les clés primaires et étrangères. Chaque attribut d’un modèle conceptuel doit être
associé à son identifiant, car aucune clé primaire ne pourrait être déduite. Les clés étran-
gères sont déduites du fait de l’existence des associations reliant des classes correctement
identifiées.
Deux attributs a et b sont en dépendance fonctionnelle (notée a → b), si à toute valeur de a, au

plus une valeur de b peut être associée. On peut dire que b dépend de a. En d’autres termes,
a permet d’identifier b.
Considérons les attributs relatifs au billet de train : num_train, nom_passager, num_dos-

sier, jour_depart, ville_depart, heure_depart, num_classe, num_voiture et
num_siege.
Figure 1-76. Billet de train et ses dépendances
Les dépendances minimales peuvent être établies :

●● num_dossier → nom_passager (si on considère qu’un seul passager est concerné par
ce dossier) ;
●● num_dossier → num_train ;

●● num_dossier → jour_depart ;
●● num_dossier → num_classe ;
●● num_dossier → num_voiture ;
●● num_dossier → num_siege ;
●● num_train → ville_depart (si on considère qu’un numéro de train désigne le même
trajet régulier) ;
●● num_train → heure_depart.
La première dépendance n’est pas optimale, car le nom d’un passager dépend davantage d’un
code client que des voyages qu’il a réalisés. Ainsi, il conviendrait d’introduire un identifiant
pour le passager et les dépendances induites seraient :
●● num_dossier → num_client (si on considère que tous les passagers sont « fichés ») ;
●● num_client → nom_passager.
Pour connaître la composition de chaque train (voiture 12 en tête, voiture 14 en position 2,
etc.), il convient de déterminer de quoi dépend la position d’une voiture : du trajet à un jour
donné. Ces deux attributs interviennent donc dans l’identifiant qui nécessite un troisième
composant (le numéro de la voiture ou la position) afin de pouvoir déterminer le quatrième
(la position ou le numéro de la voiture). Les deux dépendances suivantes sont donc équiva-
lentes :
●● num_train, jour_depart, num_voiture → position ;
●● num_train, jour_depart, position → num_voiture.
Vérification
Non-redondance
Un attribut ne figure qu’à un seul endroit du diagramme : soit dans une classe, soit dans une
classe-association.
Si vous découvrez sur un diagramme des attributs qui se répètent dans différentes classes,
deux cas se présentent.
●● L’attribut identifie une classe à un endroit et il est répété en tant que clé étrangère.
●● L’attribut ne joue pas le rôle d’identifiant et il est redondant partout où il est dupliqué.
Le diagramme UML suivant trouvé sur le Web présente des redondances au niveau des iden-
tifiants. En réalité, ce diagramme décrit un modèle relationnel et non un modèle conceptuel.
D’un point de vue conceptuel, ce diagramme n’est pas correct, mais d’un point de vue rela-
tionnel, il ne pose pas de problème au premier abord.

Figure 1-77. Non-redondance
Bien que la normalisation soit un processus qui concerne le modèle relationnel, il est toutefois
intéressant de l’étudier au niveau conceptuel, de sorte à produire des diagrammes de classes
optimaux. Vous trouverez dans la littérature et sur le Web un très grand nombre de définitions
mathématiques des formes normales. Ne comptez pas sur moi ni pour en rajouter ni pour sou-
ligner les incohérences de l’une ou de l’autre. Je vais simplement illustrer chaque cas par un
exemple. Vous devrez transposer vos problématiques à chaque exemple présenté.
Première forme normale

Afin de préserver la première forme normale, vous devez examiner les attributs non identifiants.

Chaque attribut d’une classe ou d’une classe-association doit héberger une seule valeur à un
instant t et plusieurs attributs ne doivent pas être utilisés pour stocker plusieurs valeurs d’un
même type.
Une classe est en première forme normale si chaque attribut est en dépendance fonctionnelle
avec l’identifiant.
Les attributs multivalués (associés à plusieurs valeurs comme un tableau ou une liste) sont
proscrits de tout schéma conceptuel. En revanche, un schéma conceptuel doit être composé

d’attributs monovalués pouvant contenir au plus une valeur de tout type (chaîne de caractères,
date, entier…).
L’exemple suivant modélise le fait qu’un client dispose de trois e-mails au plus. Les deux
premières modélisations ne respectent pas la première forme normale. La première considère
l’e-mail comme un tableau, tandis que la seconde utilise plusieurs attributs de même sens.
Au final, les tables issues de cette modélisation seront difficilement indexables, contiendront
nombre de valeurs nulles et les requêtes à écrire seront infiniment plus complexes que dans le
cas d’une solution normalisée.
Figure 1-78. Première forme normale
La solution normalisée évite l’utilisation de tableaux ou de duplication d’attributs. Les tables

issues de cette conception permettront une indexation optimale et éviteront des valeurs nulles.
Deuxième forme normale

Afin de préserver la deuxième forme normale, vous devez examiner les attributs des classes-
associations.

Chaque attribut d’une classe-association dépend simultanément des identifiants des classes
connectées à l’association.
Le diagramme suivant ne respecte pas la deuxième forme normale, car plusieurs attributs de
la classe-association ne dépendent pas simultanément du couple (id_cli, immatriculation).

Figure 1-79. Deuxième forme normale non assurée
En raisonnant avec les dépendances fonctionnelles, toutes celles qui concernent les attributs
d’une classe-association doivent être élémentaires (minimales en partie gauche).
●● id_cli, immatriculation → date_achat minimale si on considère qu’un client ne
peut pas racheter une voiture lui ayant déjà appartenu.
●● id_cli, immatriculation → mise_circulation non minimale, car la date de première
mise en circulation ne dépend pas du client (immatriculation → mise_circulation).
●● id_cli, immatriculation → km minimale si on désire conserver le kilométrage lors
de l’achat.
●● id_cli, immatriculation → total_km non minimale, car le kilométrage total ne
dépend que du véhicule (immatriculation → total_km).
●● id_cli, immatriculation → tel_cli non minimale, car le téléphone du client ne
dépend pas du véhicule (id_cli → tel_cli).
En appliquant ces dépendances au diagramme précédent, on réduit la complexité de la classe-
association.
Figure 1-80. Deuxième forme normale assurée

La limitation de ce diagramme réside dans le fait qu’un client ne peut racheter sa voiture dans
le temps. Pour pallier cette limitation, utilisez l’identification relative pour exprimer le fait
qu’un achat est caractérisé par un couple (véhicule, date) qui ne peut être associé qu’à un seul
client.
Figure 1-81. Deuxième forme normale améliorée
Troisième forme normale

Afin de préserver la troisième forme normale, vous devez examiner les éventuelles dépen-
dances entre attributs qui ne sont pas des identifiants de la classe où ils résident.

Chaque attribut doit dépendre d’un identifiant dans le cas d’une entité/classe ou de plusieurs
identifiants dans le cas d’une association/classe-association et non d’un autre attribut voisin
lui-même dépendant d’un ou de plusieurs identifiants.
La classe suivante ne respecte pas la troisième forme normale, car il existe une dépendance
entre deux attributs non identifiants (id_constructeur → marque). Il convient de préserver
cette dépendance dans une autre classe.

Figure 1-82. Troisième forme normale non assurée
En raisonnant avec les dépendances fonctionnelles, il faut que toutes les dépendances soient
directes (issues de l’identifiant primaire de toute classe).
●● immatriculation → id_constructeur est directe, un véhicule est associé à un
constructeur.
●● immatriculation → marque n’est pas directe, car la marque dépend davantage de
l’identifiant du constructeur.
●● id_constructeur → marque est directe et donc il faut ajouter une classe modélisant
cette dépendance.
Figure 1-83. Troisième forme normale assurée
L’éventuelle limitation de ce diagramme réside dans le fait qu’une même appellation puisse
être partagée par plusieurs véhicules. Ainsi, cet attribut devrait être considéré comme un
libellé qui doit être associé à un identifiant.
Figure 1-84. Troisième forme normale améliorée

Forme normale de Boyce-Codd

Nommée par le patronyme de ses inventeurs, la forme normale de Boyce-Codd (BCNF) concerne
les attributs d’une classe-association qui peuvent jouer le rôle d’identifiant d’une autre classe.

Aucun attribut d’une classe-association ne doit pouvoir jouer le rôle d’un identifiant d’une autre
classe.
La classe-association suivante ne respecte pas la forme normale de Boyce-Codd, car il existe

une dépendance entre un attribut non identifiant et un identifiant (nom_region →id_pays).
Figure 1-85. Forme normale de Boyce-Codd non assurée
Il convient de préserver cette dépendance en transformant la classe-association en une classe à

part entière et en ajoutant un identifiant pour y associer le libellé que constitue le nom de la région.
Figure 1-86. Forme normale de Boyce-Codd assurée

Ce diagramme présente également l’avantage de respecter la hiérarchie Vehicule-Region-Pays.
Fais-moi plaisir, rajoute la forme normale domaine-clé… DKNF.
Forme normale domaine-clé

Débusquée par R. Fagin (encore un chercheur venant d’IBM), la forme normale domaine-clé
(DKNF pour Domain Key Normal Form) concerne les dépendances par le biais de contraintes
de valeurs.

Le modèle conceptuel ne doit pas contenir de contraintes autres que des contraintes de
domaine, de clé, prédéfinies et personnalisées.
D’après moi, cette forme normale ne doit pas être mise en œuvre d’un point de vue conceptuel.
Elle est davantage à étudier au niveau logique ou physique afin d’éviter d’éventuelles redon-
dances et anomalies de mises à jour.
En considérant que la catégorie d’un avion est en relation directe avec son envergure, l’asso-
ciation appartient ne respecte pas la forme normale domaine-clé, car suivant la valeur de
l’envergure de chaque avion, on pourrait déduire cette information.
Figure 1-87. Forme normale domaine-clé non assurée
Afin de normaliser ce modèle, il conviendrait d’éliminer cette association et d’ajouter une

contrainte personnalisée décrivant l’association sous-jacente.
Quatrième et cinquième formes normales

Les formes normales supérieures étudiées ici (quatrième et cinquième) concernent les asso-
ciations n-aires. Dans la mesure où je vous ai conseillé de ne pas les utiliser (en décomposant
le regroupement de classes à l’aide de classes-associations), vos schémas respecteront les qua-
trième et cinquième formes normales.L’erreur, dans la plupart des cas, consiste à modéliser
plusieurs faits ou événements dans une seule association n-aire. L’exemple suivant modélise le
fait qu’il est nécessaire pour chaque pilote de détenir une liste de qualifications pour voler sur
un type d’appareil donné.

Figure 1-88. Quatrième forme normale non assurée
La classe suivante ne respecte pas la quatrième forme normale, car il existe des dépendances
entre des couples de classes. Il convient de préserver ces dépendances par le biais d’associations
binaires.
Figure 1-89. Quatrième forme normale assurée
Si la modélisation initiale n’avait pas prévu le fait qu’un pilote puisse détenir des qualifica-
tions indépendamment des avions sur lesquels il est apte à voler, la cinquième forme normale
n’aurait pas été respectée. Le diagramme suivant pallie cet éventuel inconvénient.

Figure 1-90. Cinquième forme normale assurée
Mise en pratique
Respectez ces principes pour résoudre les exercices 1.11 « La carte d’embarquement », 1.12
« Deux cafés et l’addition ! », 1.13 « La thalasso », 1.14 « Le centre de plongée » et 1.15
« L’élection présidentielle ».
Bilan
Après avoir examiné différents formalismes de modélisation de bases de données (le modèle
de Chen, le MCD de Merise et ses extensions Merise/2), la notation UML semble très bien
adaptée pour les raisons suivantes.
●● UML propose autant de concepts que Merise/2, avec la possibilité de définir en plus des
stéréotypes personnalisés.
●● La représentation de certaines contraintes sur des associations n-aires est implicite avec
les classes-associations.
●● L’utilisation de la notation UML permet aux concepteurs de travailler dans un environne-
ment plus évolutif, notamment avec la possibilité d’interfacer plus facilement les langages
évolués C++ ou Java.
Exercices
Pour que vos diagrammes soient le plus en phase avec les corrigés (en annexes), le nom des
attributs est indiqué pour la plupart des exercices en police Courier.

Voici un petit rappel de la démarche à adopter pour débuter une conception :

●● établir la liste des attributs (sous la forme d’un dictionnaire des données) ;
●● épurer (éviter les synonymes, les polysémies) ;
●● décomposer les attributs structurés (adresse, nomenclature, etc.) ;
●● repérer les identifiants (si nécessaire, en créer) ;
●● déduire les classes (entités) à partir de chaque identifiant ;
●● disposer chaque attribut dans une classe (dépendance) ;
●● trouver un identifiant pour chaque classe ;
●● déterminer les associations entre classes ;
●● rattacher chaque attribut « orphelin » à sa classe ou dans une classe-association.
1.1 La déroute des bleus

Chacun des 6 groupes est composé de 4 équipes qui jouent toutes les unes contre les autres
lors du premier tour. Si vous ne connaissez pas le règlement régissant ce premier tour, vous
vous souvenez sûrement du fiasco des bleus, la grève de l’entraînement, l’entrain de nos
champions, la résistance de certains à abandonner leurs primes de participation… n’en jetez
plus ! Bref, à la fin du premier tour, les deux premières équipes de chaque groupe se quali-
fient pour le second tour.
Intéressons-nous maintenant non pas à la composition des équipes mais à la composition des
classes UML.
Figure 1-91. Premiers résultats

Dictionnaire des données

Les attributs suivants vous permettront de commencer votre modélisation. Il est toutefois
nécessaire d’en ajouter (les identifiants notamment).
Tableau 1-11 : Les attributs de départ
Attribut Désignation Type
lib_equipe Libellé de l’équipe participante (pays) Chaîne de caractères
lib_groupe Libellé du groupe (par exemple, « Groupe A ») Chaîne de caractères
nom_ville Nom de la ville (par exemple, « Johannesburg ») Chaîne de caractères
nom_stade Nom du stade (par exemple, « Ellis Park ») Chaîne de caractères
jour_match Jour d’un match (par exemple, « 11/06/2010 ») Date
heure_match Heure d’un match (par exemple, « 13 h 30 ») Décimal
score Score d’un match (par exemple, « 1-2 »). Chaîne de caractères
nom_chaine Nom de la chaîne (par exemple, « France 2 ») Chaîne de caractères
classement Classement de l’équipe au sein du groupe Entier court
Associations binaires
Qui dit libellé, dit identifiant, et qui dit identifiant, dit classe. Voilà donc les premières classes
simplement découvertes à partir des attributs initiaux.
Figure 1-92. Classes initiales

Il reste à caser :
●● jour_match, heure_match et score qui caractérisent une rencontre, concept qui n’est
pas encore représenté (classe Match à définir, donc identifiant à ajouter, car aucun de ces
attributs ne peut assurer ce rôle) ;
●● classement qui concerne une équipe (et non un groupe). En effet chaque équipe doit être
associée à un seul classement, alors qu’un groupe peut être associé à plusieurs classements
(4 par groupe en fait).
Les six classes du schéma sont à présent au complet. Vous devez les relier par des associations
judicieusement choisies.
Figure 1-93. Classes finalisées
Classe-association
Si vous savez vous servir d’une classe-association, vous pouvez réfléchir à l’évolution de ce
schéma afin de prendre en compte l’affichage des résultats dans différentes langues. Ainsi,
le nom de l’équipe d’Afrique du Sud (lib_equipe) doit pouvoir être associé à différents
libellés, par exemple « South Africa » en anglais ou « África del Sur » en espagnol. Utilisez
la classe Langue constituée d’un identifiant id_langue (par exemple, fr) et d’un libellé
lib_langue (par exemple, France).
Historique
Modifiez le diagramme pour mémoriser l’historique des coupes du monde (qui a lieu tous
les 4 ans : annee), notamment pour savoir quelle était le pays organisateur et la composition

des groupes de l’époque. Notez que le groupe n’est pas composé selon l’ordre alphabétique.
En effet, la position (position) dans le groupe s’effectue selon le classement lors du 1er tour.
Sachez également que cet événement ne peut être organisé que par 2 pays maximum.
Figure 1-94. Compositions du groupe A
1.2 L’organisme de formation

Au cours de l’année, un organisme assure différents cours auprès de stagiaires salariés en
formation continue.
Figure 1-95. Formateur en action
Inscriptions
En début d’année, chaque salarié remplit une fiche sur laquelle il indique son nom (nom), son
e-mail (mail), le code de son entreprise (codent) et la liste des formations qu’il envisage de

suivre dans l’année (6 maximum parmi les 450 présentes au catalogue). Un code lui est ensuite
automatiquement attribué (idsta).
Chaque formation est définie par un code (codef), un titre (titref) et une durée (duree),
et placée sous la responsabilité d’un consultant caractérisé par un code, un nom et un e-mail
(idemp, nomemp et mailemp).
Tout consultant doit être disponible un jour par semaine (jsem) et durant une plage horaire
définie (hrens) afin de renseigner le public à propos des formations dont il est le responsable.
Plannings
1. Modifiez le schéma pour qu’un consultant puisse être interrogé à différents moments de la
semaine tout en respectant un seul créneau par formation qu’il supervise.
2. Modifiez le schéma pour qu’un consultant puisse donner des renseignements sur une
formation qu’il supervise à différents moments de la semaine.
1.3 Les lignes de facture

Dans toute facture, plusieurs produits peuvent être commandés et un produit peut se retrouver
dans différentes factures.
Figure 1-96. Exemple de facture

Complétez le diagramme suivant ; les attributs à considérer sont la quantité (quantite), le

prix unitaire de chaque produit (prix_unitaire_ht), l’éventuelle remise (remise) et les
informations relatives à la TVA (code_tva et taux_tva).
Figure 1-97. Lignes de facture
Concernant le prix et le taux de TVA, distinguez les conditions initiales (aucune facture n’est
émise le matin du premier jour de l’exercice comptable) de la facturation courante.
1.4 La décomposition des n-aires

Décomposez toute association n-aire que vous seriez tenté de définir.
Visite des représentants

1. Dans chaque région, des représentants visitent des dépôts. Les classes principales sont
Region, Representant et Depot.
2. Mémorisez les dates des différentes visites.
3. On désire connaître quel véhicule de la société le représentant a utilisé (classe Vehicule et
sans identification artificielle).
4. Modélisez le cas précédent avec l’identification artificielle.
Stages
Chaque stage référencé dans le catalogue peut se dérouler dans différentes villes et à diffé-
rentes périodes. Les classes principales sont Stage, Ville et Periode.

Figure 1-98. Stage informatique
Cote automobile
Il s’agit de référencer les cotes des véhicules d’occasion selon la marque, le modèle et l’année.
Prenez en compte également les autres caractéristiques (type de carrosserie, énergie, émissions
de carbone et nombre de chevaux fiscaux).
Figure 1-99. Cote automobile
Horaires d’une ligne de bus

Modélisez la base de données mémorisant les horaires de toutes les lignes de bus. Les classes
principales sont Station, Ligne, Jour et Horaire.

N’oubliez pas que vous devez être en mesure d’imprimer à la demande ce tableau.
Figure 1-100. Horaires d’une ligne de bus
1.5 Les comptes bancaires

Les clients d’une agence bancaire possèdent des comptes.
Complétez le diagramme suivant pour modéliser :
●● le nom du propriétaire de chaque compte et la date d’ouverture du compte ;
●● les mandataires (clients non propriétaires) des comptes et leurs divers droits asso-
ciés (retrait, virement ou clôture). Notez qu’un mandataire ne peut pas gérer plus de
5 comptes.

Figure 1-101. Virements bancaires
Identification relative
Modélisez l’historique des rendez-vous de chaque client avec le conseiller rencontré et la date
de dernier entretien. Il est intéressant de connaître les différents produits financiers qui auront
été vendus au client lors de ces rendez-vous. Chaque conseiller perçoit une prime en fonction
du produit vendu pour toute souscription.
Identification artificielle
Modélisez les virements entre comptes. Il s’agit de connaître le montant en euros, le client
initiateur et la date de l’opération.
1.6 Le RIB
Positionnez-vous au niveau de la Banque de France en modélisant les comptes des clients de
tous les organismes bancaires. Considérez notamment les attributs suivants :
●● nom_banque, nom_agence, num_compte, cle_RIB, nom_client ;
●● debit, credit, date_ouverture.
Figure 1-102. Un RIB

1.7 L’organisme de formation (suite)

Complétez le diagramme de l’exercice 1.2 qui modélise l’organisme de formation.
Sessions
Les sessions de formations sont assurées par des formateurs en interne (c’est un consultant qui
n’est pas forcément le responsable du cours). Chaque session ne dépasse pas 5 jours.
À la fin de chaque session, chaque stagiaire note la formation qu’il a suivie (notec).
Il faut mémoriser la date du cours (datec) et l’identité du formateur de la session.
Salles
Chaque session se déroule dans une des salles de l’organisme de formation. Les locaux de
l’organisme sont composés de plusieurs étages. Chaque salle est numérotée et dispose d’un
nombre de places limité (capacite). Il faut au minimum 2 stagiaires inscrits et aucune salle
ne dépasse 12 places.
Des techniciens s’occupent de la configuration des salles à chaque session. Pour chaque session,
le technicien résume ses actions dans un mémo (memo).
Il est intéressant de connaître le temps de présence (temps_presence) de chaque technicien
passé pour chaque jour de la session.
1.8 L’héritage
Organisme de formation
Dans quelle mesure l’héritage permet de préciser le diagramme de l’exercice 1.7« l’organisme
de formation »?
Comptes bancaires
Comment pouvez-vous utiliser l’héritage pour préciser le diagramme de l’exercice 1.5 « Les
comptes bancaires » ?
1.9 Les cartes grises

Le but de cet exercice est de modéliser le cycle de vie d’un véhicule au travers de ses différents
propriétaires et de la réglementation.
Ancien régime
Le premier document à analyser est le suivant. Lorsqu’un véhicule change de propriétaire son
immatriculation est modifiée.

Figure 1-103. Première moitié d’une carte grise ancien régime
Modélisez un premier schéma en fonction des attributs que vous devez considérer :
●● immatriculation, date_immat, mise_circu, nom_departement, taxe_region ;
●● nom_proprio, prenom_proprio, adresse_proprio ;
●● genre, marque, type_veh, nserie_veh, carosserie, energie, puissance, num_

places.
Coût du cheval
Modélisez le fait que chaque région (nom_region) fixe annuellement (annee) par délibé-
ration du conseil régional la valeur du cheval fiscal (euros_cv) rentrant en compte dans le
calcul de la taxe du certificat d’immatriculation.
Nouvelle numérotation
Deux systèmes cohabitent actuellement en France. L’ancien système basé sur un comptage
départemental, en place depuis 1950, est désormais remplacé depuis le 15 avril 2009 par un
système entièrement national.
Ce nouveau numéro est attribué définitivement au véhicule, jusqu’à sa destruction ou son
exportation. La plaque intègre, sur sa partie droite, un identifiant territorial composé d’un
numéro de département et du logo de la région correspondante. Cet identifiant est choisi par le
propriétaire et n’a pas obligatoirement de rapport avec le lieu de résidence.

Figure 1-104. Immatriculation nouveau régime
Dans quelle mesure votre diagramme doit-il évoluer ?
Contrôles techniques
Indépendamment du système d’immatriculation, chaque véhicule doit passer tous les deux
ans un contrôle technique. Plusieurs enseignes existent et différents centres de contrôle
détenant un numéro d’agrément sont présents en France. Modélisez l’historique de ces évé-
nements en prenant en compte de nouveaux attributs : limite_echeance, nom_enseigne,
adresse_centre, nom_centre, num_agrement, date_visite, num_visite et num_
carte_grise.
Figure 1-105. Seconde moitié d’une carte grise
1.10 Les contraintes

Précisez la sémantique de vos diagrammes à l’aide de contraintes OCL afin de formaliser les
faits suivants.
La déroute des bleus

●● Un match ne doit pas opposer une équipe avec elle-même.
●● Un match doit opposer deux équipes du même groupe.

L’organisme de formation
●● Un consultant doit proposer entre 2 et 4 créneaux par semaine pour enseigner un cours.
●● Un technicien doit rédiger un mémo de Ses actions pour toute formation qu’il prend en charge.
●● Le nombre de stagiaires ne doit pas dépasser la capacité d’une salle pour toute session.
Les comptes bancaires

●● Un mandataire d’un compte n’est pas le propriétaire.
●● Un virement se réalise entre deux comptes distincts.
●● Un virement nécessite un crédit suffisant.
1.11 La carte d’embarquement

Tout passager est identifié par Air France par un numéro unique (num_carte). Quatre types
de cartes de fidélité existent (ce sont des libellés). Le titre IVORY (lib_fidelite) décrit des
passagers occasionnels, puis viennent SILVER, GOLD et PLATINIUM acquis par accumu-
lation de voyages.
Figure 1-106. Carte d’embarquement
Vols catalogue
Les autres attributs que vous devez considérez apparaissent clairement sur le document et
sont les suivants : nom_client, prenom_client, num_vol, jour_mois, heure_dep,
heure_emb, nom_aeroport, num_porte et num_siege. Un aéroport est identifié par un
code international (par exemple, Paris Orly est codifié « LFPO » par l’OACI, l’Organisation
de l’aviation civile internationale).
Distinguez un vol « catalogue » d’un vol réel. Le vol réel transporte plusieurs clients, tandis
que le vol catalogue renseigne les caractéristiques d’un trajet indépendamment du jour.

Vols réels
Modifiez le précédent diagramme pour :
●● calculer des statistiques des retards en mémorisant les heures de départ et d’arrivée réelles
(dep_reel, arrivee_reelle) ;
●● qu’un client puisse réserver plusieurs sièges pour le même trajet ;
●● connaître le planning annuel de chaque vol. Dans l’exemple suivant, le vol AF6146 n’est
pas ouvert du samedi 16 au mardi 19. L’heure d’arrivée catalogue (heure_arr) est égale-
ment à prendre en compte.
Figure 1-107. Planning annuel des vols
1.12 Deux cafés et l’addition !

Le document à analyser est le suivant. Les éléments à prendre en compte sont entourés.
Figure 1-108. Note de restaurant

Considérez les principaux attributs : nom_enseigne, adresse_resto, siret_resto,

tel_resto, num_table, nombre_couverts, nom_serveur, qte_produit, lib_pro-
duit, pu_ht_produit, date_repas, num_caisse et num_note.
Ajoutez à votre diagramme les éléments suivants :
●● la capacité de chaque table (différente du nombre de couverts servis à une table pour un
repas) ;
●● le taux de TVA dépend de chaque produit ;
●● plusieurs restaurants de cette enseigne peuvent exister en France ;
●● chaque restaurant de cette enseigne numérote ses tables de 1 à n ;
●● les serveurs peuvent être responsables de 3 à 10 tables chaque jour.
1.13 La thalasso
Les principaux attributs sont les suivants : num_client, num_sejour, nom_client, jour_
soin, heure_soin, num_vestiaire, lib_soin et lib_lieu.
Un type de soin n’a lieu que dans un seul espace et il peut être effectué plusieurs fois le même
jour.
Figure 1-109. Séjour en thalasso
1.14 Le centre de plongée

Un club de plongée décide d’abandonner la gestion papier de toutes ses prestations. Il dispose
de plusieurs bateaux ayant différentes caractéristiques (immat, nom_bateau, capacite,
date_conformite). Plusieurs types d’employés (type_emp) travaillent pour ce club (moni-
teurs, pilotes, mécanicien, etc.). L’identité de chaque employé (nom_emp) devra être prise en
compte.

Figure 1-110. La flotte du club
Chaque sortie d’un bateau se réalise sur l’un des sites existants. Tout site est limité en nombre
de mouillages (lib_site, nb_bateau_max). La taxe journalière de chaque site est variable
en fonction de la saison (mois) et du site. Les sites ne sont pas ouverts à tous les bateaux.
Chaque bateau ne peut effectuer plus de quatre sorties par jour. Les dates et heures de chaque
sortie doivent être mémorisées (date_sortie et heure_sortie).
Figure 1-111. Les sites de plongée

Lors de chaque sortie, plusieurs plongeurs sont embarqués. Ces plongeurs composent dif-
férentes palanquées (groupe d’au maximum cinq plongeurs réalisant la même plongée).
Un plongeur peut être rattaché à un club extérieur pour lequel des accords ont été passés
avec l’organisateur. Chaque plongeur doit être enregistré (num_brevet, nom_plongeur,
niveau_plong) et on doit pouvoir connaître le chef de chaque palanquée. Certaines palan-
quées sont dirigées par des moniteurs du club.
Figure 1-112. Des plongeurs
Le prix de chaque plongée est indépendant du site, mais peut varier selon le mois. Il existe
deux tarifs (prix_plongee) : en autonome et accompagné d’un des moniteurs du club. À la
fin de chaque plongée, le chef de palanquée annonce la durée d’immersion, ainsi que la profon-
deur maximale atteinte au cours de la plongée (duree_plongee et profondeur_max). Ces
deux chiffres doivent être consignés.
1.15 L’élection présidentielle

Dans notre pays, tous les cinq ans, le titre suprême est remis en jeu. L’objectif de cet exercice
n’est pas de modéliser les promesses non tenues, les engagements utopiques ou les beaux dis-
cours écrits par d’autres. Il s’agit simplement de compter les voix pour éviter, dans la mesure
du possible, que notre pays soit codirigé pendant un temps par deux président(e)s.
Membres des partis

Chaque membre de la vie politique (élu ou non) s’inscrit dans un parti. En général, il y reste
durant toute sa carrière. Vous devez prévoir les partis qui changent de nom sans changer d’ob-
jectifs et les éventuels « virements de bord » d’un politicien (périodes qu’il a passées au sein
d’un parti).

Figure 1-113. Historique d’un parti. Extrait du site http://fr.wikipedia.org
Il est important de connaître le leader courant de chaque parti. Les principaux attributs à
considérer sont les suivants : nom_politicien, prenom_politicien, date_naiss, nom_
parti, annee_creation, annee_fin, date_entree et date_sortie.
Résultats des élections passées

Avant de modéliser les résultats de la future élection, intéressez-vous aux chiffres des éditions
précédentes au niveau national.
Comme l’illustre la figure suivante, les attributs que vous devrez considérer sont les suivants :
annee_election, score_1tour, score_2tour, pourcent_1tour et pourcent_2tour.
Figure 1-114. Historique des résultats d’un parti. Extrait du site http://fr.wikipedia.org

Titre suprême
Le ministère de l’Intérieur propose d’analyser les résultats des premier et second tours de
l’élection au niveau national, par région ou par département.
Figure 1-115. Décomposition des résultats. Extrait du site http://www.interieur.gouv.fr
Quelle que soit la précision choisie, le résultat du premier tour est présenté sous la forme suivante.
Figure 1-116. Résultats de la présidentielle 2007 en Midi-Pyrénées. Extrait du site http://www.interieur.gouv.fr

Chapitre 2
Le niveau logique
Ce chapitre détaille la deuxième étape de conception d’une base de données : il s’agit d’éla-
borer un schéma logique (modèle relationnel) ; la dernière étape étant la création des tables
(génération de scripts SQL) puis des vues (requêtes SQL).
Les avantages d’utiliser un modèle logique de données sont nombreux :
●● rester indépendant du SGBD (mais plus proche des tables) ;
●● vérifier son modèle avant de créer les tables définitives (normalisation) ;
●● réduire la complexité du modèle (décider de ne pas créer certaines tables déduites toutefois
du modèle conceptuel) ;
●● renommer des objets (colonnes, clés, contraintes et tables) ;
●● typer les colonnes plus précisément ;
●● prévoir d’ajouter certaines contraintes de clés et de valeurs (contraintes UNIQUE et CHECK
notamment) ;
●● calculer la volumétrie prévisionnelle.
Ce chapitre se divise en trois parties. La première partie décrit les concepts du modèle rela-
tionnel. La deuxième partie présente les règles qui permettent de dériver un schéma logique
à partir d’un modèle conceptuel. La dernière partie traite de la normalisation et du calcul de
volumétrie.
Deux autres aspects importants du modèle relationnel existent. Le premier concerne l’inté-
grité des données qui est abordée au chapitre 3 (contraintes SQL). Le dernier aspect recouvre
la manipulation des données au sens des opérateurs relationnels (algèbre relationnelle, base
mathématique du langage de requêtes SQL). Vous trouverez de nombreuses ressources sur le
Web et dans la bibliographie.

Concepts du niveau logique

Le modèle relationnel a vu le jour en 1970 avec les travaux de Edgar Frank Codd , la principale
publication est « A Relational Model for Large Shared Data Banks », Communications of the
ACM, vol. 13, n° 6, 1970.
Figure 2-1. Le père du modèle relationnel
Ce modèle de données est construit principalement autour des concepts suivants.

●● Relation : structure de données qui préfigure la table qui sera créée à l’aide du langage SQL.
●● Attribut : représentation d’une information atomique qui préfigure une colonne d’une
table. Un domaine de valeurs devrait être défini ainsi que d’éventuelles règles de validation
(contraintes).
●● Clé primaire : attribut(s) identifiant une relation qui préfigure(nt) la primary key de la table.
●● Clé étrangère : attribut(s) qui référence(nt) une tierce relation, préfigure(nt) une foreign key
de la table.
Le diagramme suivant illustre les principaux concepts du modèle relationnel. Trois relations
simples sont présentées (aucune des clés primaires ou étrangères n’est composée et il n’y a pas
plusieurs clés étrangères par relation). Chacune de ces relations dispose d’une clé primaire
(notée pk par l’outil Power AMC). Les clés étrangères sont notées fk.
Figure 2-2. Principaux concepts du modèle relationnel

Chapitre 2 Le niveau logique
La relation Aeroport dispose d’une clé étrangère (attribut Vil_idville) qui référence la
relation Ville. La relation Ville dispose d’une clé étrangère (attribut idpays) qui référence
la relation Pays. Le nom des contraintes de clés étrangères apparaît ici. En revanche, le nom
des autres contraintes (clé primaire, unique ou de vérification) est absent de cet affichage.
Notez qu’une clé étrangère peut porter un autre nom que le nom de la clé primaire (ou unique)
référencée.
Une fois ce modèle établi (automatiquement par un outil de conception), vous pouvez le modifier
à loisir. Changer le nom d’un attribut (colonne), le type, etc.
Vous trouverez de nombreux formalismes graphiques qui reprennent ces fondamentaux. Le
diagramme suivant, issu du logiciel Access de Microsoft, illustre cinq relations et quatre clés
étrangères. Les clés primaires sont indiquées en gras.
Figure 2-3. Modèle logique Access
Le diagramme DB Designer suivant contient trois relations et deux clés étrangères. Les clés
primaires sont iconisées, tandis que les clés étrangères sont suffixées par fk.
Figure 2-4. Modèle logique DB Designer

Le choix de l’outil Rational Rose (inclus dans l’offre Data Modeler d’IBM) est de préfixer les
attributs clés : pk pour les clés primaires, fk pour les clés étrangères et pfk pour les attributs
jouant les deux rôles.
Figure 2-5. Modèle logique de Rational
Depuis la version 7, SQL Server propose un outil pour construire un modèle de tables. Les
clés primaires sont notées à l’aide d’une icône clé, les clés étrangères ne sont pas explicitement
distinguées.

Figure 2-6. Modèle logique de SQL Server
Du conceptuel au relationnel
Cette partie présente les règles qui permettent de créer un schéma relationnel à partir
d’un modèle conceptuel exprimé par un diagramme de classes UML. Ces règles sont
surtout basées sur l’existence des associations et la valeur des multiplicités de chaque asso-
ciation.
Bien que ces règles soient, en principe, correctement programmées dans tout outil digne
de ce nom, il est nécessaire de vérifier le schéma résultant avant de créer votre base.
Ainsi, la connaissance de ces règles vous permettra de vérifier la cohérence des relations
générées.

Figure 2-7. Étapes de la conception
Transformation des classes

Chaque classe génère une relation. La clé primaire de la relation provient de l’identifiant pri-
maire. Pour chaque éventuel identifiant secondaire, une contrainte unique est générée.
En appliquant cette règle à l’exemple suivant, la relation Aeroport préfigure la table de même
nom.
Figure 2-8. Transformation d’une classe

Transformation des associations un-à-plusieurs

Ce sont les plus nombreuses en général dans un modèle conceptuel ; chaque association un-
à-plusieurs déclenche la génération d’une clé étrangère. Toute association un-à-plusieurs
connecte une classe parent (multiplicité maximale 1) à une classe enfant (multiplicité maxi-
male *).
L’attribut identifiant de la relation parent migre dans la relation enfant et devient clé étrangère
dans la relation fils issue de l’association.
Appliquons cette règle à l’exemple suivant, il vient deux clés étrangères. Notez qu’une classe
peut être considérée à la fois parent pour une association et enfant pour une autre.
Figure 2-9. Transformation d’associations un-à-plusieurs
Le fait que la multiplicité minimale du lien côté parent soit 0 ou 1 n’a pas d’influence sur la
structure du schéma relationnel généré. Seul le modèle physique permet de différencier ces
deux cas en ajoutant une éventuelle contrainte NOT NULL appliquée à la colonne clé étran-
gère.
Transformation des associations plusieurs-à-plusieurs

Présentes en général dans la plupart des modèles conceptuels, chaque association plusieurs-à-
plusieurs déclenche la génération d’une relation munie de deux clés étrangères. Cette nouvelle
relation préfigure la table appelée souvent « table d’association » (ou « table de jointure »).
Toute association plusieurs-à-plusieurs devient une relation qui porte le nom de l’association.
La clé primaire de cette relation est composée par le couple des identifiants des deux relations
(initiales) qui sont déduites des classes connectées à l’association initiale. Chaque attribut clé
primaire de la nouvelle relation est une clé étrangère vers la relation initiale associée.

De l’application de cette règle à l’exemple suivant, émanent deux nouvelles relations. L’iden-
tifiant de chaque nouvelle relation est composé du couple d’identifiants des deux relations
initiales. Les clés étrangères relient la nouvelle relation à ses deux relations initiales associées.
Figure 2-10. Transformation d’associations plusieurs-à-plusieurs
Le fait que la multiplicité minimale d’un lien soit 0, 1 ou n (n>1) n’a pas d’influence sur la struc-
ture du schéma relationnel généré. Seule une programmation permettra de mettre en œuvre
une telle contrainte.
Cas particuliers des associations binaires

Concernant les associations binaires, deux cas particuliers existent : les associations un-à-un
et les associations réflexives. Concernant les premières, vous devrez raisonner comme pour les
associations un-à-plusieurs. Concernant les réflexives, vous devrez raisonner comme pour des
associations binaires simples en fonction des multiplicités existantes.
Transformation des associations un-à-un
Pour toute association un-à-un, considérez la relation du côté de la multiplicité 1..1 en tant
que parent et appliquez la transformation d’une association un-à-plusieurs. Si aucune mul-
tiplicité n’a cette valeur (les deux valant 0..1), appliquez la transformation d’une association
un-à-plusieurs sans considérer une relation en tant que parent en particulier. Si les deux mul-
tiplicités valent 1..1, vous devriez visiblement modifier votre schéma en fusionnant les deux
classes en une seule…

Appliquons cette règle à l’exemple suivant, deux clés étrangères doivent être générées. La
première clé étrangère (num_proj dans Collaborateur) qui concerne l’association un-à-
plusieurs devrait apparaître naturellement. En revanche, vous devrez vous assurer du bon
positionnement de la seconde clé étrangère (id_coll dans Projet).
Figure 2-11. Transformation d’une association un-à-un
En considérant ainsi la relation parent comme étant celle du côté de la multiplicité minimale 1,
vous réduirez considérablement le nombre de valeurs NULL dans les colonnes clés étran-
gères de vos tables.
Transformation des associations réflexives
Toute association réflexive doit être considérée comme une association binaire et en fonction
des multiplicités existantes, il convient d’adopter une des règles précitées.
Je précise que les associations réflexives suivent les mêmes règles de transformation :
• une association réflexive un-à-un conduit à une double clé et une assertion ;
• une association réflexive un-à-un conduit à une double clé ;
• une association réflexive un-à-un conduit à une table de jointure.
De l’application de ce principe à l’exemple suivant, émanent deux clés étrangères. La pre-

mière provient de l’association un-à-plusieurs et la seconde de l’association un-à-un. La classe
Employe joue le double rôle de parent et d’enfant pour ces deux associations.

Figure 2-12. Transformation d’associations réflexives
En renommant les colonnes clés étrangères provenant d’associations réflexives, vous amélio-
rerez considérablement, par la suite, la lisibilité de la table. Les rôles UML peuvent vous aider
dans ce sens. Dans l’exemple précédent, il convient de renommer par exemple id_emp2 par
id_mon_pote et id_emp3 par id_manager.
Transformation des agrégations (de type composition)

La transformation d’une agrégation de type composition déclenche deux mécanismes. D’une
part, la génération d’une clé étrangère du fait de l’existence de l’association un-à-plusieurs.
D’autre part, l’ajout de cette colonne à la clé primaire de la relation enfant du fait de l’enrichis-
sement de l’identifiant.
Appliquons cette règle à l’exemple suivant, et constatons la génération de la clé étrangère
id_emp qui fait désormais partie de la clé primaire de la relation enfant.
Figure 2-13. Transformation d’agrégation de type composition

Transformation des classes-associations

La transformation d’une classe-association s’apparente à celle de l’association plusieurs-
à-plusieurs. Ainsi, une nouvelle relation est générée (et porte en principe le nom de la
classe-association). De plus, si la classe-association contient des attributs, ils apparaissent dans
la nouvelle relation (sans être clé toutefois).
En appliquant cette règle à l’exemple suivant, la nouvelle relation contient l’attribut de la
classe-association.
Figure 2-14. Transformation d’une classe-association
Vous devez vous demander comment dériver un schéma relationnel lorsqu’une classe-asso-
ciation est reliée à une autre classe. Eh bien, le plus naturellement du monde : en considérant
la classe-association comme une classe à part entière et en adoptant les règles précitées en
fonction des multiplicités de l’association à traduire.
Nous verrons plus loin quelques exemples qui incluent des classes-associations connectées à
d’autres classes.
Transformation de l’héritage
Il existe trois transformations possibles pour chaque association d’héritage.
Il n’existe pas de solution miracle et vous devrez choisir la meilleure option en fonction de
la nature de la contrainte qui concerne l’héritage (partition, exclusion, totalité ou absence de
contrainte).
Vous pouvez traduire une association d’héritage par :

• distinction : en créant autant de relations que de classes (surclasse et sous-classes). L’iden-
tifiant de la surclasse est propagé dans toutes les relations et devient la clé primaire pour
chacune d’elles. Ce même identifiant joue également le rôle de clé étrangère vers la relation
déduite de la surclasse (qui préfigure la table de référence) ;
• push-down : en migrant tous les attributs de la surclasse dans les sous-classes ;
• push-up : en migrant tous les attributs des sous-classes dans la surclasse.

Le premier exemple concerne la classification des personnels en trois populations : commer-

ciaux, managers (chacun responsable de plusieurs personnels) et administratifs. En l’absence
de contrainte, ce diagramme UML signifie qu’il existe des personnels non classifiés (ni com-
merciaux, ni managers, ni administratifs) et qu’aucun d’entre eux ne peut appartenir à plus
d’une classification.
La transformation par distinction implémente correctement cet état de fait.
Figure 2-15. Transformation d’un héritage par distinction
La transformation par distinction d’une association d’héritage est la plus polyvalente. Sous
réserve de codage, elle permet d’implémenter n’importe quelle autre contrainte d’héritage
(partition, exclusion et totalité).
Le deuxième exemple considère qu’il n’existe aucun personnel n’étant ni commercial, ni

manager, ni administratif et que chacun est cantonné à un seul type d’emploi (contrainte UML
complete, disjoint). La transformation par push-down implémente correctement cette
hypothèse.
Figure 2-16. Transformation d’un héritage par push-down

Le troisième exemple présente la transformation d’un héritage simple par push-up. Cette
solution permet d’implémenter toutes les contraintes, mais convient vraiment mieux lorsque
chaque personnel peut occuper plus d’un type d’emploi.
Figure 2-17. Transformation d’un héritage par push-up
Le tableau suivant précise les options souhaitables pour chaque contrainte d’héritage. Quelle
que soit la solution que vous choisirez, vous devrez programmer la contrainte sous la forme
de directives SQL CHECK, déclencheurs ou à l’intérieur de vos procédures cataloguées (voir
le chapitre 3), sauf en ce qui concerne la transformation par distinction et lorsqu’il n’est pas
nécessaire d’assurer l’exclusivité.
Tableau 2-1 : Transformation de l’héritage
Options de Compatibilité avec les contraintes

transformation
Distinction ☺ Exclusivité : {incomplete,disjoint} (par défaut)
☺ Pas de contrainte : {incomplete,overlapping}
Push-down ☺ Partition : {complete,disjoint}
☹ Totalité : {complete,overlapping}, redondance d’informations
Push-up ☺ Totalité : {complete,overlapping}

☹ Autres cas : présence de nombreuses valeurs NULL

En pratique, il est rare d’utiliser la technique de rassemblement des données qu’est le

push-down, car le modèle relationnel est fait pour éviter les redondances. Or, la migra-
tion de tous les attributs de la surclasse dans les sous-classes entraîne systématiquement
de la redondance, sauf dans le cas ou la surclasse ne contient que la clé (et dans ce cas,
on en revient à la distinction).
De même, la technique du push-up est rare, car elle crée des tables avec un fort taux de
NULL si les sous-classes sont exclusives. Et dans ce cas, il convient de gérer proprement
les conditions de NULLification à l’aide de contraintes souvent complexes.
Enfin, même si la technique de distinction est la plus souvent implémentée, il ne faut pas
oublier qu’elle nécessite l’ajout de contraintes complexes, lorsqu’il y a exclusivité entre
les membres des sous-classes.
Pour autant, la technique de l’héritage induit d’excellents bénéfices en termes de per-
formances, en réduisant le nombre de colonnes des tables et en permettant l’élision de
jointures (dans le cas d’héritages successifs, il n’est pas utile de passer par toutes les
classes descendantes pour joindre la racine à une feuille).
La solution « universelle »
Il existe une transformation qui peut convenir à toute association binaire (un-à-un, un-à-
plusieurs, plusieurs-à-plusieurs et réflexive). Il s’agit de générer une nouvelle relation munie
de deux clés étrangères (qui préfigure la table d’association ou « table de jointure »). La clé
primaire de cette relation est composée soit par un des identifiants, soit par le couple des iden-
tifiants des deux relations initiales.
Appliquons cette règle à l’exemple de deux associations binaires. Deux relations doivent être
générées. L’association un-à-un est traduite par la relation diriger et l’association un-à-
plusieurs est traduite par la relation affecter.
Figure 2-18. Solution universelle
Pour s’assurer qu’un collaborateur ne dirige qu’un projet, il conviendra d’ajouter, au niveau
physique, une contrainte UNIQUE sur la clé étrangère (id_coll) dans la table diriger.

Dans l’autre table d’association, la clé primaire id_coll permettra de s’assurer qu’un colla-
borateur ne puisse être affecté à plusieurs projets.
Ce principe de transformation est idéal lorsque les multiplicités de vos associations sont sus-
ceptibles de changer avec le temps (dans notre exemple, le fait qu’un collaborateur puisse
diriger plusieurs projets ou participer à différents projets). En ce cas, et même avec des données
en base, il suffira d’activer ou de désactiver telle contrainte ou telle clé.
Ainsi, pour l’association universelle de type un-à-un, il faut choisir la clé primaire de
la table de jointure qui peut venir indifféremment de l’une ou l’autre des entités. Mon
conseil est donc le suivant : prenez toujours celle de l’entité qui existe avant l’autre. Dans
l’exemple proposé, la table de jointure diriger se voit dotée d’une clé primaire venant
de l’entité Projet. C’est à mon sens une erreur, car il me semble difficile qu’un projet
existe dans votre entreprise, si vous n’avez aucun collaborateur !
Les transformations à éviter

Je vais encore dire du mal des associations n-aires, mais la plupart d’entre elles le méritent.
Considérons à nouveau le premier exemple de la section « Les associations n-aires » du cha-
pitre 1, l’association n-aire Installer exprimait le fait que des logiciels soient installés sur
des serveurs par des départements.
La transformation de toute association n-aire entraîne l’apparition d’une nouvelle relation. Si
les multiplicités sont toutes de type plusieurs-à-plusieurs, la clé primaire de la nouvelle rela-
tion sera composée des clés de toutes les relations connectées. Si la multiplicité d’un lien de
l’association n-aire vaut 1, le degré de la clé primaire est réduit d’une colonne.
Figure 2-19. Une transformation à éviter
Cette transformation est à éviter, car la table d’association qu’on obtiendra ne permettra aucun
contrôle de cohérence. Ainsi, avec ce schéma, il est possible d’installer un logiciel qui n’est pas
compatible avec un serveur ou qu’un département ne détient pas par exemple.

Il est évident que toutes les associations n-aires alourdissent les clés des tables d’asso-
ciation. Chercher donc à réduire le nombre de colonnes est important et lorsque l’on ne
peut pas le faire, il devient souvent intéressant de créer artificiellement une entité asso-
ciative (classe artificielle en UML) afin d’alléger la clé primaire ce qui est grandement
bénéfique pour les performances. Il faudra, dans ce cas, ajouter une contrainte d’uni-
cité pour l’ensemble des clés étrangères composant l’association. Cette technique rajoute
effectivement une colonne, mais allège bien des objets physiques sous-jacents à la table,
comme l’écriture de certaines requêtes. La plupart des outils de modélisation permettent
d’automatiser ce genre de transformation.
Traduire ou ne pas traduire ?

Du fait que toutes les relations ne doivent pas forcément être traduites en tables, certaines
classes ne doivent exister qu’au niveau conceptuel. Le procédé qui consiste à ne pas traduire
une relation en table relève davantage d’un point de vue opérationnel que d’un point de vue
conceptuel. En général, il s’opère au niveau physique, où, avant de créer les tables, on se rend
compte de l’inutilité de telle ou telle table et on les élimine du script.
L’exemple suivant illustre la transformation d’un modèle conceptuel qui comporte une classe
relativement abstraite puisqu’il s’agit d’une date. Le modèle logique fait apparaître une relation
qui résulte de la traduction de cette classe.
Figure 2-20. Une relation à ne pas transformer
Dans la majorité des cas, il n’est pas utile de traduire cette relation en table. Elle est toutefois
indispensable au niveau conceptuel, car elle permet de faire migrer dans la table d’association
la colonne qui représente le jour de visite. Certains la traduiront pour disposer d’une table de
référence de dates, astuce qui permet de faciliter les requêtes interrogeant la base à propos de
dates où aucune visite n’a été réalisée.

Les classes qui ont une sémantique faible et qui ne sont reliées à aucune autre classe, à part
dans le cadre d’une association, sont en général de bons exemples de classes qui ne doivent
pas nécessairement être transformées en tables.
La question d’une entité DATE (ou parfois NOMBRE) paraît anodine, mais s’avère
cruciale.
Dans un modèle de données, il devrait toujours figurer une table des dates et une table des
nombres. En effet, un problème important à résoudre dans les requêtes est de retrouver
des données qui ne figurent pas dans la base. Pour cela, il faut artificiellement créer ces
données pour des ensembles continus. Par exemple, une table des dates sur quelques
siècles. Il devient alors facile et pertinent de retrouver des dates « absentes » des données
de production à l’aide d’une jointure externe droite sur la table des dates. Un exemple
que je donne en démonstration est celui d’un SAV ou je montre une table avec des lignes
d’appareils portés en réparation pendant toute une semaine. J’y omets sciemment un jour,
mettons le mercredi et demande à calculer le nombre moyen d’appareils traités par jour
au cours de cette semaine. La plupart du temps, la requête produite sera fausse, car le
jour absent n’est pas compté !
CREATE TABLE T_SAV (SAV_DATE DATE, SAV_APPAREIL VARCHAR(16));
INSERT INTO T_SAV VALUES
('2011-11-12', 'TV'), ('2011-11-14', 'RADIO'), ('2011-11-12', 'FRIGO'),
('2011-11-13', 'FOUR'), ('2011-11-16', 'RADIO'), ('2011-11-14', 'RADIO'),
('2011-11-12', 'FOUR'), ('2011-11-13', 'FOUR'), ('2011-11-16', 'TV');
requête naïve:
SELECT COUNT(*) / CAST(COUNT(DISTINCT SAV_DATE) AS FLOAT) AS NB_
APPAREIL_PAR_JOUR FROM T_SAV;
NB_APPAREIL_PAR_JOUR
----------------------
2,25
Ce résultat est faux, car la date du 15 novembre 2011 ne figure pas dans la table (peut-être
une grève ?). La solution consiste donc à rajouter une table de date :
CREATE TABLE T_DATE (D DATE);
INSERT INTO T_DATE VALUES ('2011-11-12'), ('2011-11-13'),
('2011-11-14'), ('2011-11-15'), ('2011-11-16');
La requête suivante est correcte :
SELECT COUNT(SAV_APPAREIL) / CAST(COUNT(DISTINCT D) AS FLOAT) NB_
APPAREIL_PAR_JOUR FROM T_SAV

RIGHT OUTER JOIN T_DATE ON T_SAV.SAV_DATE = T_DATE.D

NB_APPAREIL_PAR_JOUR
----------------------
1,8
Il est ensuite facile de rajouter à cette table de dates d’autres informations : numéro de
jour, semaine, mois, année, trimestre, semestre, jours fériés, congés… et d’indexer cette
table tout en la déclarant en lecture seule afin d’éviter tout verrou !
Mise en pratique
Les exercices 2.1 « Les associations binaires », 2.2 « L’héritage et la composition », 2.3 « Les
classes-associations » et 2.4 « Traduire ou ne pas traduire ? » vous proposent de traduire
manuellement différents modèles conceptuels en schémas relationnels.
Typez vos colonnes

Au moment de choisir un type pour vos colonnes, vous devez avoir à l’esprit différents critères
visant à optimiser la qualité de vos données.
●● Précision (exactitude), le typage ne doit pas entraîner de calculs erronés (décimales ou
domaine de valeurs).
●● Actualité : les données doivent être à jour au bon moment (vérification périodique ?).
●● Compréhension : le nom d’une colonne ne doit pas permettre d’ambiguïté sur son sens.
●● Complétude : évitez tant que possible les valeurs NULL.
●● Confiance : ce critère dépendra toujours de la provenance de la saisie.
Considérons l’exemple suivant qui concerne la relation modélisant les produits :
Figure 2-21. Qualité des futures données

●● La colonne prix n’est pas précise (de quelle devise s’agit-il ?). Cette colonne sera-t-elle
actualisée au bon moment ? Cette colonne n’est pas compréhensible (s’agit-il d’un prix
TTC, HT, unitaire, de revient, etc. ?). Enfin, le type flottant (FLOAT) peut réserver des
surprises lors de calculs intermédiaires importants (12.499999999 ou 12.5000000001 ?).
●● La colonne quantite n’est ni précise (les décimales doivent-elles être acceptées, pour
stocker par exemple 1,5 pour un kilo et demi ?), ni compréhensible (quelle est l’unité du
produit, des mètres, des kilos, des livres, etc. ?), ni complète (les contraintes NOT NULL
sont absentes du fait que la case « O » comme obligatoire n’est pas cochée).
Vous trouverez quelques pistes en parcourant les liens suivants :
●● documentation d’Oracle : http://download.oracle.com/docs/cd/E11882_01/appdev.112/
e17125/adfns_sqltypes.htm#i1006173 ;
●● types SQL-Server, MySQL et Access : http://www.w3schools.com/sql/sql_datatypes.asp ;
●● documentation de MySQL : http://dev.mysql.com/doc/refman/5.0/en/choosing-types.html-
Billet ;
●● à propos de SQL-Server : http://www.techrepublic.com/blog/10things/10-common-
questions-about-sql-server-data-types/355.
La normalisation
Bien que les outils permettent de modéliser un schéma logique dans ce modèle de données,
aucun n’offre la possibilité d’automatiser une quelconque normalisation. Les avantages de
normaliser un schéma relationnel sont les suivants.
●● Éviter des redondances potentielles (donc minimiser l’espace de stockage et diminuer les
risques d’incohérences qui sont appelées anomalies transactionnelles).
●● Faciliter la programmation de n’importe quelle opération sur les tables (ajout, modification
et suppression).
●● Renforcer l’intégrité des données.
Le schéma relationnel suivant, de par sa structure, rend problématique les futures (mais très
probables) actions suivantes.
●● Ajout d’un client s’il n’est pas inscrit à un cours (la clé primaire de la table Inscriptions
est composée des colonnes et interdit donc qu’une des deux colonnes soit nulle).
●● Modification du nom d’un client ou de la société d’un client (la mise à jour doit être réper-
cutée dans toutes les lignes concernées). Si une modification est partielle, la table est tout
bonnement inexploitable (au niveau de ces deux colonnes).
●● Suppression d’une inscription (qui entraînerait la perte des données du client).

Figure 2-22. Pourquoi normaliser ?
Le seul inconvénient qu’on peut trouver à la normalisation réside dans l’augmentation du

nombre de tables d’un schéma. Par conséquent, l’utilisation systématique de jointure sera
nécessaire à toute requête. Cela n’est pas forcément pénalisant et il existe des techniques
d’optimisation d’extraction (indexation, tables temporaires, partitionnement, etc.).
Le schéma suivant présente la solution normalisée de l’exemple précédent.
Figure 2-23. Schéma normalisé
Avec ces structures, tous les inconvénients précédents sont résolus.

●● L’ajout d’un client s’il n’est pas inscrit à un cours est possible.

●● La modification du nom d’un client ou de celui de sa société n’entraîne aucune redondance.

●● La suppression d’une inscription n’entraîne aucune perte des données du client.
Enfin, il n’existe pas d’outil d’aide au processus de normalisation (Embarcadero Schema Exa-
miner reste très pauvre tout en étant relativement cher). Ainsi, encore une fois, la ressource
humaine est nécessaire et c’est une bonne nouvelle. Pas d’off-shore en Inde et ce ne sont pas
des programmeurs roumains qui vont normaliser vos bases de données.
Normaliser, c’est bon pour les performances

La normalisation va conduire immanquablement à un grand nombre de petites tables
(petites par leur nombre de colonnes) et par conséquent, beaucoup de jointures. Les déve-
loppeurs naïfs pensent toujours que les jointures, c’est mal ! Ça bouffe du temps… C’est
une vision simpliste due au fait que le développeur se croit seul au monde et utilise habi-
tuellement un jeu d’essais plus que restreint.
Lorsque la concurrence d’accès commence à se faire sentir, les tables obèses (ces tables
fourre-tout que le développeur a modélisées en y mettant le maximum de colonnes) com-
mencent à devenir inaccessibles pendant de longs moments, car chaque écriture verrouille
de manière exclusive. Ainsi, la simple modification d’un numéro de téléphone empêchera
la lecture d’un nom, d’une adresse ou d’un e-mail, dans ce genre de table.
En revanche, dans une base bien modélisée, l’impact d’une telle mise à jour est beaucoup
plus rapide (car moins de données) et quasi invisible pour qui extrait des données des
autres tables… De plus, il est très facile d’indexer une petite table, alors que pour une
grosse, l’indexation devient rapidement inefficace.
C’est pourquoi en audit je m’intéresse toujours à débusquer les tables de plus de 20 colonnes
en pensant que leur normalisation est a priori mauvaise. Ce critère de 20 colonnes est le
fruit de l’expérience, mais comme toute règle, il existe des exceptions.
Dépendances fonctionnelles
La normalisation est basée sur les dépendances fonctionnelles (DF). E. Codd fut le premier à
publier sur ce type de dépendances [COD 72]. Bien que le qualificatif de « fonctionnelles » soit
communément utilisé, ces dépendances sont davantage liées aux valeurs qu’à une fonctionna-
lité particulière. Le terme qui conviendrait mieux à les qualifier serait donc : « dépendances
de valeurs ».
Un attribut b dépend fonctionnellement d’un attribut a si à une valeur de a correspond au plus

une valeur de b. La dépendance fonctionnelle est notée a → b.
Le membre droit de l’écriture s’appelle le dépendant, le membre gauche s’appelle le déter-
minant, ce dernier devient en général clé primaire (ou alternative, aussi appelée candidate).

Plusieurs attributs peuvent apparaître dans la partie gauche d’une DF. Plusieurs attributs peu-
vent apparaître dans la partie droite d’une DF. Dans ce cas, il convient de considérer chaque
DF en gardant la partie gauche et en faisant intervenir un seul attribut dans la partie droite.
On apprend scolairement, à l’aide de techniques formelles, que la réduction d’un

modèle peut se faire à partir des dépendances fonctionnelles et de certaines règles
(Armstrong, fermeture, couverture minimale… j’en passe et des meilleures). Tout cela
est bien joli de la part d’un mathématicien, mais n’a en pratique aucun intérêt, car la
difficulté de la modélisation n’est pas dans l’application bête et méchante de règles
mécaniques que certains outils mathématiques incorporent, mais bien dans le débus-
quage des dépendances fonctionnelles ! Là, il ne s’agit plus de mathématiques, mais de
sémantique, de compréhension, d’introspection, de maquettage, voire de tests… Après,
les choses s’éclaircissent naturellement et comme dirait Boileau « les mots pour le dire
arrivent aisément » !
Exemples
Étudions les exemples suivants inspirés du monde aéronautique commercial. Chaque pilote est
doté d’un numéro, d’un nom et d’une fonction (copilote, commandant ou instructeur).
●● L’écriture num_pilote → nom_pil,fonction est équivalente aux écritures num_
pilote → nom_pil et num_pilote → fonction qui sont deux DF, car tout pilote n’est
doté que d’un seul nom et d’une fonction à tout instant. Avec ces hypothèses, l’écriture
num_pilote → nom_pil,fonction est une DF.
●● L’écriture num_pilote,jour → nb_heures_vol peut être considérée comme une DF
si à tout couple cohérent et susceptible d’être stocké (num_pilote, jour), on désire
associer au plus un nombre d’heures de vol (qui sera le cumul de tous ses vols journaliers).
●● L’écriture nom_pilote → fonction peut être considérée comme une DF si on suppose
qu’il n’existera aucun homonyme dans la population des pilotes (cas peu probable). En res-
tant dans le cadre le plus général, cette écriture ne doit pas être considérée comme une DF.
●● L’écriture fonction → nom_pilote n’est évidemment pas une DF, car plusieurs pilotes
peuvent être dotés de la même fonction.
La notion de dépendance fonctionnelle simple permet de détecter les anomalies de première

forme normale.
DF élémentaire
Une DF a, b → c est élémentaire si ni a → c, ni b → c ne sont des DF.

Considérons les exemples suivants.

●● La dépendance fonctionnelle num_pilote,jour → nb_heures_vol est élémentaire dans
l’hypothèse du stockage des cumuls journaliers. En effet, num_pilote → nb_heures_
vol ne doit pas être considérée comme une DF, car chaque jour, il est nécessaire de pouvoir
associer un nombre différent d’heures de vol. L’écriture jour → nb_heures_vol n’est
évidemment pas une DF, car chaque jour plusieurs pilotes sont en mesure de voler.
●● L’écriture num_pilote,nom_pil → fonction n’est pas une dépendance fonctionnelle
élémentaire, car le numéro du pilote suffit pour retrouver sa fonction (num_pilote → fonc-
tion est une DF).
La notion de dépendance fonctionnelle élémentaire permet de détecter les anomalies de

deuxième forme normale.
DF directe
Une DF a → c est directe si elle ne peut pas être déduite par transitivité de deux DF avérées,
c’est-à-dire que les écritures suivantes a → b et b → c ne sont pas des DF.
Il est difficile de statuer sur le fait qu’une DF est directe. En revanche, il est plus facile de
déterminer qu’une DF est indirecte (si on trouve un parcours de DF cohérent). En consé-
quence, toutes les DF qui ne sont pas considérées comme indirectes doivent être considérées
comme directes.
Considérons l’exemple qui fait intervenir les attributs suivants : (immat : numéro d’imma-
triculation d’un avion, type_avion : type de l’aéronef, nom_const : nom du constructeur
de l’aéronef). L’écriture immat → nom_const n’est pas une DF directe, car les dépendances
suivantes sont directes :
●● immat → type_avion
●● type_avion → nom_const
La notion de dépendance fonctionnelle directe permet de détecter les anomalies de troisième

forme normale.
Une relation est en première forme normale si :

• toute colonne est en dépendance fonctionnelle avec la clé primaire ;
• il n’existe pas de valeurs multiples dans une colonne ;
• il n’existe pas plusieurs colonnes homogènes (pour stocker différentes valeurs similaires).

La relation Product ne respecte pas la règle de la première forme normale, car la colonne
color est prévue pour stocker différentes couleurs.
Figure 2-24. Première forme normale non respectée
Plusieurs problèmes potentiels résultent de ce choix.

●● L’indexation n’est pas possible, car une liste de valeurs ne peut convenir à définir un index
de qualité.
●● La redondance d’informations : plusieurs libellés de couleur vont se répéter probablement
dans la majorité des lignes de la table. Modifier le libellé d’une couleur en particulier peut
s’avérer dangereux si toutes les répercussions ne se produisent pas.
●● L’incohérence d’informations, suite à une mise à jour défectueuse ou une insertion non
maîtrisée, mène à des résultats erronés (il est probable que la requête qui doit extraire les
produits de couleur bleue à l’aide d’une condition WHERE color LIKE %Blue% ne retrouve
pas le produit 456…
●● La complexité assurée pour toutes les requêtes relatives aux coloris, de même que leur
probable piètre performance (absence d’index).

La normalisation en première forme normale de ce schéma est la suivante.
Figure 2-25. Première forme normale respectée
Cette solution évite tous les inconvénients précédents.

●● L’indexation est maintenant possible, car chaque colonne ne contient qu’une seule valeur.
●● La redondance d’informations est évitée : chaque libellé de couleur se trouve centralisé
dans la table Colors.

●● Toutes les requêtes relatives aux coloris se programmeront par jointures rendues perfor-
mantes par la présence d’index et par le type de la clé étrangère (ici numérique).
D’accord, il s’agit de prévoir que chaque attribut soit atomique. Mais il ne faudrait pas
oublier que tout attribut d’une relation doit être évalué (donc pas de NULL) ! (en sus du
fait que la relation doit impérativement avoir une clé).
Mais qu’est-ce que l’atomicité d’un attribut ? Une date est-elle atomique ? N’est-elle pas
elle-même composée d’une année, d’un mois et d’un jour ? Un numéro de Sécurité sociale
n’est, par nature, pas du tout atomique. Il incorpore plusieurs notions telles que le sexe,
l’année, le mois et la commune de naissance…
Pour autant, on peut inverser le problème. Demandez donc à un vendeur de listes si
l’adresse dont il a fourré tous les éléments (nom de voie, type de voie, numéro dans la
voie…) dans un seul et même attribut considère que cette information n’est pas atomique !
Bref, la notion d’atomicité est relative à la problématique du modèle analysé…
Pour autant, certaines informations sont composées de plusieurs éléments décompo-
sables, et peuvent bien entendu être considérées comme atomiques. C’est le cas par
exemple des périodes (un début + une fin) et plus généralement des intervalles, mais aussi
des objets géographiques (points, lignes, polygones…). Il devient alors très complexe de
savoir ce que représentent certaines notions d’unicité dans ce genre de cas de figure. À
titre d’exemple, voici deux polygones identiques (SQL SIG) :
POLYGON ((3 7, 5 7, 5 2, 4 2, 3 7))
POLYGON ((4 2, 3 7, 5 7, 5 2, 4 2))
Et deux intervalles se chevauchant : [33..52] et [47..49[.
Il ne semble pourtant pas évident de savoir ce qu’une contrainte d’unicité (clé de la rela-
tion par exemple) doit faire dans un tel cas de figure !
On dit bien qu’un attribut doit être atomique. Ce n’est pas pour autant que l’on devrait
cacher la non-atomicité par une fantaisie de modélisation… Je m’explique. On trouve
souvent dans les tables des attributs de même nom numéroté de 1 à…, par exemple
TELEPHONE1, TELEPHONE2, TELEPHONE3… Et, pourquoi pas, 4, 5, voire 10 téléphones ?
Dans ce cas, c’est un tableau de téléphone que l’on devrait mettre. Or, un tableau n’est à
l’évidence pas atomique, donc il se doit d’être transformé en entité à part entière.
Plus vicieux sont les attributs similaires non numérotés. Par exemple : TELEPHONE_FIXE,
TELEPHONE_MOBILE, TELECOPIE, TELEPHONE_DOMICILE, TELEPHONE_TRAVAIL!
Là aussi, la transformation est indispensable : une entité TELEPHONE avec un typage
des téléphones suffit. Songez donc au jour où votre patron vous demandera de retrouver
le client dont le numéro de téléphone est 75 78 45 15 79… Si vous avez disséminé vos
numéros de téléphone à travers plusieurs colonnes, voire plusieurs tables, ne vous étonnez
pas que la requête soit un veau et que tous les index du monde n’y pourront rien en plus
de rendre les tables bovines…

Première forme normale et le marqueur NULL
Tout attribut doit être évalué. Cette règle est aussi impérative, contrairement à SQL où
une colonne d’une table peut ne pas avoir de valeurs (dans ce cas, le marqueur NULL y
figure, mais ce n’est généralement pas très bon pour les performances). Se pose alors
la question de savoir comment modéliser lorsque l’information est connue de manière
partielle ?
Prenons par exemple le cas d’une personne modélisée traditionnellement avec les attributs
nom, prénom et date de naissance :
PERSONNE_PHYSIQUE (PRP_ID INT auto, PRP_NOM A60, PRP_PRENOM A32,
PRP_NAISSANCE DATE), l’identifiant étant PRP_ID.
Mais si nous ne connaissons pas le nom, ou le prénom ou la date de naissance d’une per-
sonne, alors que faire ? Il suffit tout simplement de décomposer l’entité en trois :
PERSONNE_PHYSIQUE_NOM (PRP_ID INT auto, PRP_NOM A60),
l'identifiant étant PRP_ID.
PERSONNE_PHYSIQUE_PRENOM (PRP_ID INT auto, PRP_PRENOM A32),
l'identifiant étant PRP_ID.
PERSONNE_PHYSIQUE_NAISSANCE (PRP_ID INT auto, PRP_NAISSANCE
DATE), l'identifiant étant PRP_ID.
Pour reconstituer l’information d’une personne, il suffira de faire des jointures externes
bilatérales. A priori ce découpage semble utopique, car il va générer de nombreuses opé-
rations de jointures… Pour autant, certains SGBDR comme Sybase IQ le font sans vous
le dire, car ce modèle (toutes les tables sont dotées d’une clé et au plus d’un seul attribut),
en sus d’être parfait, est extrêmement performant sur de grands volumes et de nombreuses
transactions. En effet :
• il répartit la charge de mise à jour sur différents objets, ce qui est moins bloquant que
d’avoir un seul objet bloqué pour tout un tas de mises à jour différentes ;
• il économise du volume (on ne stocke pas de lignes pour le NULL) ;
• il permet une indexation systématique de tous les objets (il suffit de poser un seul index
sur le seul attribut pour que tout soit indexé).
Bien entendu, si votre SGBDR ne dispose pas d’un tel mécanisme, vous pouvez le simuler
avec des vues !
Une relation est en deuxième forme normale si la première forme normale est assurée et si
tout attribut non clé est en dépendance fonctionnelle élémentaire avec la clé.

La relation Coloris ne respecte pas la règle de la deuxième forme normale, car la colonne
poids_kg ne dépend que du produit et non de la couleur (enfin, en général, c’est comme ça).
En revanche, il est plausible que le prix d’un produit dépende aussi de sa couleur (avez-vous
remarqué que les iPhone blancs sont plus chers ?).
Figure 2-26. Deuxième forme normale non respectée
Le non-respect de la deuxième forme normale induit les problèmes potentiels suivants.

●● La redondance d’informations : le poids d’un produit va se répéter à l’identique pour tous
les coloris possibles de ce produit. Modifier un poids peut s’avérer risqué si tous les coloris
ne se sont pas impactés simultanément.
●● L’incohérence d’informations, suite à une mise à jour incomplète d’un poids.
●● Davantage de jointures pour toutes les requêtes relatives aux poids.
La normalisation en deuxième forme normale de ce schéma est la suivante.
Figure 2-27. Deuxième forme normale respectée
Cette solution évite les inconvénients précédents.

●● La redondance d’informations : le poids d’un produit n’est stocké qu’une seule fois, ce qui
annule une éventuelle incohérence d’informations.
●● Les requêtes relatives aux poids n’ont plus besoin de jointures.
Seules les relations ayant des clés primaires composées sont potentiellement concernées par
la deuxième forme normale.
Une jointure permet de reconstituer la relation originale. Une vue peut être programmée à cet
effet.
Une relation est en troisième forme normale si elle respecte la deuxième forme normale
et si les dépendances fonctionnelles entre la clé primaire et les autres attributs sont toutes
directes. En d’autres termes, aucun attribut ne doit pouvoir être identifié par autre chose que
la clé (primaire ou candidate).
La relation Product ne respecte pas la règle de la troisième forme normale, car la colonne
nom_marque n’est pas en dépendance directe avec la clé (itemID). En effet, le nom
d’une marque doit être identifié par un code et un produit sera associé ensuite à sa marque.
Figure 2-28. Troisième forme normale non respectée
Le non-respect de la troisième forme normale induit les problèmes potentiels suivants.

●● La redondance d’informations : le nom de la marque va se répéter à l’identique pour tous
les produits d’une marque donnée.

●● L’incohérence, si la modification du nom d’une marque ne se répercute pas à tous les produits
associés.

La normalisation en troisième forme normale de ce schéma est la suivante.
Figure 2-29. Troisième forme normale respectée
Cette solution évite les inconvénients précédents, car le nom de la marque est unique dans
la table de référence (Marques) et ne se répète pas pour chaque produit. En revanche, les
requêtes relatives aux marques nécessiteront davantage de jointures.
effet.
Une relation est en forme normale de Boyce-Codd [COD 74] si elle respecte la troisième forme
normale et que le seul déterminant (membre gauche d’une DF) de la relation est la clé pri-
maire (mis à par d’éventuels identifiants alternatifs). En d’autres termes, aucune dépendance
vers une partie de la clé ne doit exister.
En supposant qu’un produit puisse être fabriqué dans une région de différents pays, la relation
Fabrication ne respecte pas la règle de Boyce-Codd. En effet, il existe une dépendance
entre la colonne region et une partie de la clé (itemID) qui s’explique par le fait qu’une
région est toujours associée à un unique pays.

Figure 2-30. Forme normale de Boyce-Codd non respectée
Par ailleurs, le nom de la région est un libellé qui doit être associé à un identifiant. La prise
en compte de ces deux remarques mène à la normalisation en forme de Boyce-Codd de ce
schéma.
Figure 2-31. Forme normale de Boyce-Codd respectée
La théorie montre que toute relation a une décomposition sans perte en forme normale de
Boyce-Codd. En revanche, une telle décomposition ne préserve pas toutes les DF (dans
l’exemple la DF itemID, id_pays → region a été supprimée). Il est cependant possible de
la retrouver en réalisant une jointure entre les relations normalisées.
Seules les relations ayant des clés primaires composées sont potentiellement concernées par
la forme normale de Boyce Codd.
effet.

Une relation est en forme normale domaine-clé si toutes les contraintes qui s’appliquent à la
relation sont la conséquence logique des contraintes de domaines et des contraintes de clé.
La classification suivante des avions dépend de leur envergure.
Figure 2-32. Classification FAA des avions
Le premier schéma relationnel ne vérifie pas la forme normale domaine-clé, car la relation
Avion contient le code catégorie (id_cat) qui peut être calculé en fonction de la colonne
envergure. Cette redondance est problématique si les règles régissant les catégories évo-
luent. En effet, l’adoption de l’éclatement du groupe I pour former deux nouveaux groupes
« Ia » concernant les avions d’envergure inférieure à 20 ft et « Ib » pour ceux d’envergure
jusqu’à 49 ft nécessiterait la mise à jour de nombreuses lignes de la table. Si ces mises à jour
ne forment pas une transaction, des anomalies de mises à jour peuvent se produire.
Figure 2-33. Passage à la forme normale domaine-clé

Le deuxième schéma relationnel qui est décomposé selon la forme normale domaine-clé
présente l’avantage de ne pas être sensible à de telles modifications.
Une inéqui-jointure permet de reconstituer la relation originale. Une vue peut être programmée
à cet effet.
Quatrième et cinquième formes normales

Dès qu’une relation modélise trop de faits, il y a de grandes chances qu’elle ne respecte pas les
formes normales supérieures (4e et 5e).
L’exemple suivant présente la relation Qualifier qui vise à modéliser les qualifications impo-
sées par chaque type d’appareil pour tous les pilotes. Cette relation n’est pas en quatrième
forme normale, car la liste des qualifications nécessaires pour chaque type d’appareil est indé-
pendante du nombre de personnels navigant qualifiés. En effet, pour tout couple de pilotes
qualifiés sur un type d’appareil, ces deux pilotes sont toujours à mettre en association avec
les mêmes qualifications. Cette dépendance se nomme multivaluée et se note id_type_
av → → id_qual | id_brevet.
Figure 2-34. Quatrième forme normale non respectée
Afin de dissocier ces deux états de faits, il est nécessaire de décomposer Qualifier en deux
relations Qualif_necessaire (constitue les correspondances entre un type d’avion et les
qualifications) et Aptitude (pour connaître quels sont les pilotes qualifiés pour chaque type
d’appareil).
Considérons à nouveau la relation initiale Qualifier et supposons qu’elle inclut également
les qualifications que possède chaque pilote, sans pour autant que ces qualifications soient
concernées par un type d’appareil quelconque. Cette relation ne respecte pas la cinquième
forme normale, car il existe des dépendances de jointure.

Figure 2-35. Quatrième forme normale respectée
Afin de dissocier ces trois états de faits, il est nécessaire de décomposer Qualifier en trois
relations : Qualif_necessaire et Aptitude pour répondre aux deux premiers états de
faits, et Qualif_detenues pour modéliser l’hypothèse de travail.
Figure 2-36. Cinquième forme normale respectée

Seules les relations ayant des clés primaires composées de plus de deux colonnes sont
potentiellement concernées par les quatrième et cinquième formes normales.
Si vous suivez les préconisations du chapitre 1, vous éviterez de modéliser chaque asso-
ciation n-aire en l’état (sans décomposition systématique en classes-associations), et
vous obtiendrez un schéma qui respecte naturellement les quatrième et cinquième formes
normales.
Finalement la 6e forme normale…

Vous trouverez rarement un auteur, comme un enseignant, vous parlant de la 6e forme
normale. Chris Date y a consacré un ouvrage, et les éléments ont été repris par Snodgrass
dont vous trouverez les élucubrations en ligne à l’URL : http://www.cs.arizona.edu/~rts/
tdbbook.pdf
Finalement, cela peut se résumer à un concept ultrasimple repris actuellement (et très
à la mode) dans les SGBDD (D, pour décisionnels). Toute entité ne devrait finalement
comporter qu’une clé (éventuellement composée de plusieurs attributs) et au plus d’un
attribut non clé…
Songez donc à ce que serait une entité comme PERSONNE (N°, nom, prénom, date de nais-
sance). Il faudrait la décomposer en au moins trois entités, chacune ayant une partie de
la relation d’origine… Absurde me direz-vous ? Et pourtant, dans ce modèle d’une redou-
table efficacité, tout est indexé et rien n’est nul !!! Donc on ne stocke que de l’information
et on respecte l’art de la modélisation à la lettre…
Peu pratique certes, mais cela existe bien dans des produits phares comme Sybase IQ, que
SAP a racheté à prix d’or et dont la dernière version de MS SQL Server 2012 s’inspire,
avec la notion de « columnStore Index » !
Mise en pratique
L’exercice 2.5 « La normalisation » vous propose de normaliser une relation qui contient peu
de colonnes, mais beaucoup d’informations.
Calculs de volumétrie
L’analyse de la volumétrie d’une base est un calcul a priori. Pour chaque relation, vous devrez
estimer la longueur d’un n-uplet (une ligne) : l. En considérant, d’une part, une valeur moyenne
de la taille de chaque colonne :

●● CHAR(n), VARCHAR(n): n octets ;

●● NCHAR(n), NVARCHAR(n), NTEXT(n): 2×n octets (Unicode : 2 octets) ;
●● INT : 4 octets, BIGINT : 8 octets, SMALLINT : 2 octets ;
●● NUMERIC, NUMBER ou DECIMAL : de 4 à 20 octets ;
●● FLOAT : de 4 à 8 octets ;
●● DATE, TIME : de 4 à 6 octets ;
●● TIMESTAMP : de 8 à 10 octets.
D’autre part, vous devrez, pour chaque relation, estimer le nombre de lignes (nl). Le volume
d’une relation (vr) en octets est donné par la formule suivante : vr = l × nl. De la somme de
tous ces volumes, on calcule la taille prévisionnelle de toutes les relations : ∑ vri (i = 1 à
nb_relations).
Il est communément admis qu’en appliquant un coefficient de 2,5 (indexation, espace perdu,
fragmentation, réservé libre pour d’éventuelles mises à jour, etc.), on obtient un bon indicateur
final.
Les outils disposent en général d’une aide à ce calcul. Considérons la prévision suivante appli-
quée au précédent schéma : 150 types d’avion, 3500 pilotes et 450 qualifications. Le volume
d’une table d’association est le produit des volumes des deux tables associées comme l’illustre
la figure suivante.
Figure 2-37. Calcul de volumétrie (exemple)
Une fois toutes les tables renseignées en termes de volume, un calcul théorique peut être exé-
cuté. Dans l’exemple suivant, il faudra disposer de plus de 103 Mo.

Figure 2-38. Calcul de volumétrie (résultat)
Vous venez sans doute de constater qu’un bon modèle de données est constitué d’une mul-
tiplicité d’entités. Sans doute beaucoup plus que vous ne l’auriez imaginé et certainement
plus que ce que vous avez déjà fait, si jamais vous avez commencé à travailler les bases
de données sans passer par l’étape modélisation.
Pour autant, vous vous posez avec sérénité la question des performances du fait des mul-
tiples jointures à faire lors du codage des applications, et donc de l’exploitation de la
base. Bien entendu, toute opération de jointure a un coût. Mais ce coût peut devenir très
minime en face du bénéficie considérable d’une bonne modélisation… Autrement dit, vous
ne devez pas avoir peur du nombre d’entités et donc de tables de votre base.
Mais écrire de multiples jointures pour la moindre requête vous fatigue ! Vous avez
raison, un bon informaticien doit être faignant… La solution réside donc dans la création
des vues. Ainsi, pour une personne dont vous voulez, et les données personnelles, et les
données de contact, créez une vue synthétisant toutes ces informations. N’hésitez pas à
l’utiliser systématiquement dans tous vos codes, même pour la mise à jour (nous verrons
comment mettre à jour les vues dans un chapitre ultérieur).
Sachez qu’un bon SGBDR ignorera certaines jointures inutiles d’une vue, si les infor-
mations à retourner ne sont pas utiles pour votre requête. Sachez aussi que le nombre
de jointures qu’un SGBDR peut supporter est assez élevé. C’est en général plusieurs
centaines. Sachez enfin que le coût d’une jointure entre une clé primaire (identifiant de
l’entité) et une clé étrangère (qui se doit d’être indexée) est très minime si vous avez opté
pour une clé auto-incrémentée (SEQUENCE ou IDENTITY). Apprenez que le coût d’une
jointure entre deux tables de 100 millions de lignes, devant retourner une unique ligne,
ne dépasse pas six lectures…
Enfin, si tout cela ne vous a pas convaincu, venez en discuter ici : http://www.
developpez.net/forums/d1099389/bases-donnees/decisions-sgbd/optimisations/petites-
tables-grandes-tables-consequences-performances/.

Exercices
2.1 Les associations binaires

Déduisez manuellement (sans l’aide d’un outil) les relations des associations binaires avec
leurs clés étrangères nécessaires à l’implémentation du modèle conceptuel suivant.
Figure 2-39. Associations binaires à traduire
2.2 L’héritage et la composition

Même question pour le modèle conceptuel suivant.
Figure 2-40. Héritage et composition à traduire

2.3 Les classes-associations

Même question pour le modèle conceptuel suivant.
Figure 2-41. Classes-associations à traduire
2.4 Traduire ou ne pas traduire ?

En fonction des classes-associations présentes dans le diagramme conceptuel suivant, déduisez
manuellement le modèle relationnel avec ses clés étrangères. Déterminez ensuite les relations
qui sont susceptibles de ne pas être transformées en tables.

Figure 2-42. Classes-associations à traduire
2.5 La normalisation
En considérant la relation suivante qui vise à modéliser les différents gagnants de tournois de
tennis, trouvez la clé, puis normalisez cette relation le plus possible.
Figure 2-43. Relations à normaliser

Chapitre 3
Le niveau physique
Le niveau physique présenté dans ce chapitre correspond à la définition des tables, des clés
étrangères ainsi qu’à l’implémentation des éventuelles règles métier par des contraintes de clés,
de validation ou par des déclencheurs.
Le langage SQL
Le langage SQL provient du langage System R d’IBM. SQL est implanté dans des produits
commerciaux à la fin des années 1970 avec la première version d’Oracle et de SQL/DS
d’IBM. SQL est une norme ANSI depuis 1986 et une norme ISO depuis 1987. La norme
ANSI (SQL-86) est le résultat d’un compromis entre constructeurs, mais a été fortement
influencée par le dialecte d’IBM.
La version SQL2 (appelée aussi SQL-92) a été normalisée par l’ANSI et l’ISO en 1992. Les
langages proposés par les SGBD actuels sont proches de cette norme qui définit trois niveaux
de conformité : le niveau d’entrée (entry level), le niveau intermédiaire (intermediate level) et
le niveau maximum (full level). Les langages SQL des principaux éditeurs de SGBD relation-
nels (Oracle, IBM, Microsoft, Sybase…) sont conformes au premier niveau et ont beaucoup de
caractéristiques qui relèvent des niveaux supérieurs.
SQL3 comporte de nombreuses parties (On Line Analytical Processing, séries temporelles,
accès à des sources non SQL, réplication des données, objet, XML, etc.).
Les différentes normes sont reconnues et numérotées de la manière suivante :
●● SQL1 ISO 9075:1986 (SQL86/SQL1) ISO 9075:1989 (SQL89) ;

●● SQL2 ISO 9075:1992 (SQL92/SQL2) 600 pages, 4 niveaux (entry qui reprend SQL1,
transitional, intermediate et full), ISO 9075-4:1996 (SQL/Persistant Stored Module for
SQL92), ISO 9075-3:1995 (SQL/Call Level Interface for SQL92) ;
●● SQL3, des milliers de pages, mises à jour continuelles, codifications : ISO/IEC 9075-x (x
désignant l’année, par exemple : ISO/IEC 9075-1:2008, Information technology - Database
languages - SQL -- Part 1: Framework).
Vous trouverez les dernières spécifications relatives à la gestion de données et à SQL en
particulier sur http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_tc_browse.
htm?commid=45342.
Le langage SQL vous permettra de déclarer, de manipuler et d’interroger des données, mais
aussi de contrôler leur accès. De plus, vous pourrez intégrer vos données dans vos programmes
écrits dans tout langage (COBOL, C, C++, Java avec JDBC, C#, etc.), car il existe des API pour
chaque langage et chaque SGBD du marché.
Les instructions du langage SQL qui nous intéressent sont principalement CREATE TABLE
qui crée une table et ALTER TABLE qui permet d’ajouter une contrainte à une table existante.
Les schémas
Une table est un objet nommé d’un schéma (notion de propriétaire) qui est composé de colonnes
et d’éventuelles contraintes (clés ou valeurs). La description de chaque table se trouve stockée
dans le dictionnaire de données du SGBD, ce qui permet notamment aux outils d’opérer du
reverse engineering. Une table sera par la suite éventuellement indexée, partitionnée ou clus-
terisée.
La notion de « schéma » n’a pas la même signification selon certains SGBD : certains l’assi-
milent à la notion de database (MySQL) à la notion de user comme Oracle. SQL Server est
multischéma et multibase. Un schéma joue le rôle de bibliothèque (tel un espace de noms) dans
lequel les privilèges se gèrent plus facilement.
Figure 3-1. Notion de schéma

Chapitre 3 Le niveau physique
Un serveur SQL (aussi appelé « instance ») est une machine logique installée sur un
ordinateur lui-même physique ou logique. La plupart des éditeurs permettent d’installer
plusieurs serveurs SQL sur une même machine. Dans chaque serveur SQL, il peut y avoir
plusieurs bases de données (limité à 32 000) et dans chaque base des schémas SQL (la
limite théorique étant 4 milliards par bases…) qui constituent autant d’espace logique,
dont le but est triple :
• fournir un moyen de ranger les différents objets en différentes catégories (par exemple,
un schéma pour les ressources humaines, un autre pour la comptabilité, un troisième
pour la production…) ;
• permettre d’associer des privilèges au niveau du schéma à des utilisateurs, ce qui
allège la tâche d’administration de sécurité pour les objets futurs (par exemple, GRANT
SELECT ON SCHEMA::COMPTA TO DOMINIQUE) ;
• autoriser dans un ordre CREATE SCHEMA de créer des objets mutuellement dépendants
sans pour cela se contraindre à un ordre logique particulier (voir http://blog.deve-
loppez.com/sqlpro/p5835/langage-sql-norme/de-l-interet-des-schema-sql/ et http://
docs.postgresqlfr.org/9.0/sql-createschema.html).
Il existe toujours un schéma par défaut pour la base et pour l’utilisateur.
En cas d’absence du préfixe de schéma pour atteindre un objet, le serveur doit effectuer
une résolution de nom en commençant par chercher l’objet dans le schéma associé à
l’utilisateur, et s’il ne le trouve pas, le serveur l’associe au schéma par défaut de la base.
Dans tous les cas, cette phase prend du temps et peut conduire à des problèmes de pertes
de cache donc, de mauvaises performances. Il vaut donc mieux être précis et préfixer tous
les objets de vos requêtes par le schéma dans lequel ils ont été créés.
MySQL n’implémente pas la notion de schémas SQL, mais laisse entendre que cela est
similaire à la création de multiples bases dans une même instance. Certains SGBD, en
particulier MS SQL Server et MySQL, autorisent nativement des requêtes interbases avec
des noms qualifiés (par exemple MaBase.MonSchema.MaTable pour MS SQL Server).
Pour faire cela, sous Oracle ou PostGreSQL, il faut recourir à un mécanisme de DBlink
qui semble plus lourd et moins performant.
Schémas SQL ou bases ?
Bien souvent, les développeurs se posent cette question cruciale : « Faut-il que je fasse
plusieurs schémas SQL ou est-il préférable de passer par plusieurs bases ? » Mais cette
question est idiote ! En effet, schémas et bases de données n’ont absolument pas le même
rôle et prendre l’un pour l’autre comme le fait MySQL peut s’avérer catastrophique à tous
les plans (logique, physique et administratif…).

Le schéma SQL est un conteneur logique pour les objets d’une base. Il n’a donc rien
à voir avec un stockage physique. Si votre SGBDR gère correctement les espaces de
stockage, vous pouvez avoir n tables toutes créées dans un schéma S1 et chacune de ces
tables peut stocker ses données où bon lui semble et pourquoi pas un espace de stockage
spécifique à chaque table.
Répartir les objets d’une base de données dans différents schémas SQL est une excellente
approche, car cela permet d’organiser la base en différents pans sémantiques ou fonc-
tionnels. En revanche, répartir les objets d’une même application dans différentes bases,
pose des problèmes impossibles à résoudre.
• On ne peut pas faire de contraintes SQL d’une base à une autre. En revanche, au sein
d’une même base et même si les objets sont dans différents schémas SQL c’est possible.
• On ne peut pas sauvegarder les données de deux bases différentes de manière syn-
chrone alors que la sauvegarde d’une base emporte la sauvegarde de tous les schémas
d’un seul coup au même point de synchronisation.
• La gestion des privilèges est spécifique à une base. Elle couvre les schémas, mais elle
ne peut passer de base en base (MS SQL Server est le seul SGBDR à permettre cette
fonction, mais elle s’avère complexe à mettre en œuvre).
Schémas et propriétaires
Comme tout objet de la base, un schéma est créé par un utilisateur, ce qui confère à cet
utilisateur d’être le propriétaire du schéma, à moins qu’il ne spécifie un autre utilisateur
dans l’ordre SQL CREATE SCHEMA .
Le propriétaire d’un schéma est un peu comme un châtelain du Moyen Âge… Il a le droit
de vie ou de mort sur ses sujets, je voulais dire « ses objets », tout le temps qu’il est respon-
sable de la création des objets figurant à l’intérieur de son schéma. Mais rien n’empêche
de créer au sein du schéma de Pierre un objet dont le propriétaire est Paul (une sorte de
concession en somme) !
Il y a longtemps eu une confusion au sein des éditeurs de SGBDR entre la notion de
propriétaire (la norme SQL parle d’« autorisé ») et la notion de schéma. C’est ainsi que
dans certains SGBDR le schéma par défaut porte le même nom que l’utilisateur qui en est
propriétaire, histoire d’entretenir la confusion !
Les contraintes
Les objectifs des contraintes au niveau des tables sont multiples : renforcer l’intégrité de la
base, programmer des règles de gestion élémentaires et alléger la programmation côté client.

La mise en œuvre des contraintes va s’opérer lors de la création des tables (ou ultérieurement),
la déclaration d’une contrainte lors de la création SQL peut être réalisée en ligne (in line sur la
même ligne que la colonne de la table elle-même) ou hors ligne (out of line). Les principales
contraintes de SQL que vous avez à disposition sont :
●● UNIQUE (colonne1 [,colonne2]...)
●● PRIMARY KEY (colonne1 [,colonne2]...)
●● FOREIGN KEY (colonne1 [,colonne2]...)
REFERENCES nom_table_parent(colonne1 [,colonne2]...)
●● CHECK (condition)
Une fois définie et activée, une contrainte peut être désactivée ou supprimée. Dès qu’une
contrainte n’est pas respectée au cours du temps, une exception est levée et la transaction, dans
laquelle se trouve l’instruction qui concernait la table, est annulée.
L’outil que vous utiliserez éventuellement est capable de générer un script qui contiendra ces
deux types d’instruction.
CREATE TABLE [nom_schema.]nom_table
(colonne_1 type_1 [NOT NULL] [DEFAULT valeur],
[, colonne_2 ...]
[, CONSTRAINT nom_contrainte_1 type_contrainte_1 ...])
options physiques;
ALTER TABLE [nom_schema.]nom_table

ADD CONSTRAINT nom_contrainte type_contrainte;
De plus, il faudrait signaler l’unicité des noms des objets à travers les schémas (tables,
contraintes…) et la possibilité d’avoir des doublons de noms sur les objets primaires des
bases si on les situe dans différents schémas.
D’autres instructions SQL peuvent aussi se trouver dans le script :

●● la création des index (CREATE INDEX…) sur certaines colonnes (les clés étrangères en
principe) ;
●● la destruction des objets créés pour pouvoir relancer à la demande le script de création
(ALTER TABLE… DROP CONSTRAINT…, DROP INDEX… et DROP TABLE…).
Afin de rendre les scripts plus clairs, les instructions SQL sont notées en majuscules et les
noms d’objets (tables, colonnes et contraintes) apparaissent en minuscules.

Passage du logique au physique

Si vous n’utilisez aucun outil, le processus de transformation sera manuel, cette section va
vous expliquer les procédures à suivre pour créer vos tables. Si vous envisagez d’utiliser un
outil, la création des tables (colonnes et clés) sera automatique. Vous devrez vérifier toutefois si
les tables et contraintes référentielles obtenues sont en adéquation avec ce que vous attendiez.
Dans les deux cas, il vous restera des tâches à accomplir qui ne peuvent pas s’automatiser :
●● contraintes autres que les clés et programmation des règles métier (directives SQL CHECK
ou mise en place de déclencheurs) ;

●● index additionnels ;
●● procédures cataloguées qui implémentent vos transactions.
Étudions à présent les mécanismes qui régissent le passage d’un modèle relationnel au script
SQL. Les exemples traités sont identiques à ceux du chapitre 2 de manière à ce que vous
puissiez retrouver facilement le modèle conceptuel initial. Suivant ces principes, pour tous vos
futurs schémas, vous devriez obtenir des scripts SQL analogues.
Traduction des relations

Chaque relation devient une table. Les attributs de la relation forment les colonnes de la table.
L’identifiant de la relation devient la clé primaire de la table (primary key).
Le tableau suivant décrit la transformation d’une relation simple.
Tableau 3-1 : Transformation des relations
Schéma relationnel Script SQL
DROP TABLE Aeroport CASCADE CONSTRAINTS;
CREATE TABLE Aeroport (

code_aero VARCHAR2(4) NOT NULL,
nom_aero VARCHAR2(50),
nb_pistes SMALLINT,
Figure 3-2. Relation à traduire capacite INTEGER,
CONSTRAINT pk_aeroport
PRIMARY KEY (code_aero));
La contrainte NOT NULL oblige la colonne à contenir une valeur non nulle (qui est différente de
0, blanc ou plusieurs espaces). Certains outils disposent systématiquement cette contrainte
sur les clés primaires.

Traduction des associations un-à-plusieurs

Le tableau suivant décrit la transformation de deux associations un-à-plusieurs. Il apparaît
deux colonnes clés étrangères et deux contraintes du même type.
Tableau 3-2 : Transformation des associations un-à-plusieurs
ALTER TABLE Aeroport

DROP CONSTRAINT fk_aero_situer_ville;
ALTER TABLE Ville
DROP CONSTRAINT fk_ville_localisation_reg;
DROP TABLE Aeroport CASCADE CONSTRAINTS;
DROP TABLE Region CASCADE CONSTRAINTS;
DROP TABLE Ville CASCADE CONSTRAINTS;
CREATE TABLE Aeroport (

code_aero VARCHAR2(4) NOT NULL,
id_ville SMALLINT NOT NULL,
nom_aero VARCHAR2(50),
nbPistes SMALLINT,
capacite INTEGER,
CONSTRAINT pk_aeroport
PRIMARY KEY (code_aero));
CREATE TABLE Region (

id_region SMALLINT NOT NULL,
nom_region VARCHAR2(30),
CONSTRAINT pk_region
PRIMARY KEY (id_region));
CREATE TABLE Ville (

id_ville SMALLINT NOT NULL,
id_region SMALLINT,
nom_ville VARCHAR2(40),
codePostal SMALLINT,
CONSTRAINT pk_ville
PRIMARY KEY (id_ville));
Figure 3-3. Associations un-à-plusieurs à
traduire ALTER TABLE Aeroport
ADD CONSTRAINT fk_aero_situer_ville
FOREIGN KEY (id_ville)
REFERENCES Ville (id_ville);
ALTER TABLE Ville
ADD CONSTRAINT fk_ville_localisation_reg
FOREIGN KEY (id_region)
REFERENCES Region (id_region);

La contrainte NOT NULL sur une colonne clé étrangère traduit une multiplicité minimale à 1
d’une association un-à-plusieurs (ici la colonne id_ville dans la table Aeroport).
Traduction des associations un-à-un

Le tableau suivant décrit la transformation de deux associations binaires entre les relations
Projet et Collaborateur.
L’association d’affectation (de nom affecter au niveau conceptuel) est de type de un-à-
plusieurs et doit se traduire comme précédemment. L’association qui modélise le fait qu’un
projet soit dirigé par un seul collaborateur qui ne peut en diriger plusieurs (de nom diriger
au niveau conceptuel) est de type un-à-un et doit se traduire par une clé étrangère et par une
contrainte d’unicité (index unique). Cette clé étrangère (ici, id_coll) doit être présente dans
la relation considérée comme enfant pour l’association un-à-un (multiplicité minimale à 0),
ici Projet.
Tableau 3-3 : Transformation d’une association un-à-plusieurs et d’une association un-à-un
DROP INDEX diriger_fk ;

ALTER TABLE collaborateur
DROP CONSTRAINT fk_affecter_projet;
ALTER TABLE projet
DROP CONSTRAINT fk_diriger_collabor;
DROP TABLE collaborateur CASCADE CONSTRAINTS;
DROP TABLE projet CASCADE CONSTRAINTS;
CREATE TABLE collaborateur (

id_coll VARCHAR2(5) NOT NULL,
num_proj VARCHAR2(6),
nom_coll VARCHAR2(50),
indice INTEGER,
CONSTRAINT pk_collaborateur
PRIMARY KEY (id_coll));
CREATE TABLE projet (

num_proj VARCHAR2(6) NOT NULL,
duree INTEGER,
budget NUMBER(9,2),
designation_proj VARCHAR2(60),
Figure 3-4. Association un-à-un « diriger » à traduire CONSTRAINT pk_projet
PRIMARY KEY (num_proj));

Schéma relationnel (suite) Script SQL (suite)
ALTER TABLE collaborateur

ADD CONSTRAINT fk_affecter_projet
FOREIGN KEY (num_proj)
REFERENCES projet (num_proj);
ALTER TABLE PROJET
ADD CONSTRAINT fk_diriger_collabor
FOREIGN KEY (id_coll)
REFERENCES collaborateur (id_coll);
CREATE UNIQUE INDEX diriger_fk
ON projet (id_coll ASC);
Il existe d’autres formes d’associations un-à-un comme dans le cas de l’héritage ou d’un
lien identifiant (la clé est la même entre les diverses tables).
Traduction des associations réflexives

Le tableau suivant décrit la transformation de deux associations réflexives. L’association
manager est de type un-à-plusieurs et doit se traduire classiquement (clé étrangère). L’as-
sociation meilleur_ami est de type un-à-un et peut se traduire aussi par une clé étrangère.
Tableau 3-4 : Transformation de deux associations réflexives
ALTER TABLE employe

DROP CONSTRAINT fk_manager;
ALTER TABLE employe
DROP CONSTRAINT fk_meilleur_ami;
DROP TABLE employe CASCADE CONSTRAINTS;
CREATE TABLE employe (

id_emp INTEGER NOT NULL,
id_manager INTEGER,
id_ami INTEGER,
Figure 3-5. Associations réflexives à traduire nom_emp VARCHAR2(50),
date_embauche DATE,
salaire NUMBER(7,2),
CONSTRAINT pk_employe
PRIMARY KEY (id_emp));

ALTER TABLE EMPLOYE

ADD CONSTRAINT fk_manager
FOREIGN KEY (id_manager)
REFERENCES EMPLOYE (id_emp);
ALTER TABLE EMPLOYE
ADD CONSTRAINT fk_meilleur_ami
FOREIGN KEY (id_ami)
REFERENCES EMPLOYE (id_emp);
De la même manière qu’il existe trois sortes de cardinalités de liens entre deux relations,
il en existe autant pour les autoréférences d’une même relation.
• Autoréférence avec cardinalité un-à-un : le cas est rarissime. On peut donner un
exemple d’un point de vue statique. Dans une table de personnes physiques et dans nos
religions occidentales, une personne ne peut avoir qu’un seul conjoint. Ainsi, à l’ins-
tant t, une occurrence de personne peut être en lien 0 ou 1 à une autre personne (peu
importe qu’il soit homme ou femme, certains pays ayant admis le mariage homosexuel
et c’est le cas du Pacs en France).
• Autoréférence avec cardinalité un-à-plusieurs : c’est un cas très courant, car il conduit
à modéliser une arborescence. On le trouve typiquement dans les organigrammes d’en-
treprise pour savoir qui est le chef. Il est aussi souvent présent dans les nomenclatures
pour lesquelles les données sont emboîtées.
• Autoréférence avec cardinalité plusieurs-à-plusieurs : c’est le cas des graphes mathé-
matiques qui représentent des réseaux (lignes de métro, de bus, réseaux routiers,
télécommunications, réseaux informatiques…). Dans ce cas, le graphe peut être
vu de deux façons : orienté ou non, conduisant à une multiplicité des cardinalités.
Graphe non orienté : c’est le cas notamment des réseaux de type full duplex. Par
exemple, si l’on veut modéliser la distance des routes aériennes entre deux aéroports,
peu importe le sens, car il n’y a pas de couloir aérien à sens unique ! Le résultat est
que la matrice des combinaisons est « triangulaire ». Il est ainsi inutile de stocker
la distance pour l’aller et le retour, une seule de ces deux informations suffit. En
revanche, pour la circulation des bus dans une grande ville, la présence de voies
à sens unique va multiplier les trajets orientés et donc doubler potentiellement le
nombre des combinaisons.

Traduction des agrégations (composition)

Le tableau suivant décrit la transformation d’une agrégation de composition. L’association doit
se traduire par deux mécanismes : migration d’une clé étrangère du composite et enrichisse-
ment de la clé primaire du composant.
Tableau 3-5 : Transformation d’un agrégat
ALTER TABLE histo_annee

DROP CONSTRAINT fk_histo_employe;
DROP TABLE employe CASCADE CONSTRAINTS;
DROP TABLE histo_annee CASCADE CONSTRAINTS;

nom_emp VARCHAR2(50),
date_embauche DATE,
CONSTRAINT pk_employe PRIMARY KEY (id_emp));
CREATE TABLE histo_annee (

annee INTEGER NOT NULL,
indice INTEGER,
Figure 3-6. Agrégation à traduire salaire NUMBER(7,2),
CONSTRAINT pk_histo_annee
PRIMARY KEY (id_emp, annee));
ALTER TABLE histo_annee

ADD CONSTRAINT fk_histo_employe
FOREIGN KEY (id_emp)
REFERENCES employe (id_emp);
Vérifiez que la clé primaire de la table « composant » est constituée en partie de la clé primaire
de la table « composite ».
Traduction des associations plusieurs-à-plusieurs

Le tableau suivant décrit la transformation d’une association plusieurs-à-plusieurs (résultant
d’une classe-association au niveau conceptuel).

Tableau 3-6 : Transformation d’une association plusieurs-à-plusieurs
ALTER TABLE detail

DROP CONSTRAINT fk_configure_avion;
ALTER TABLE DETAIL
DROP CONSTRAINT fk_configure_options;
DROP TABLE avion CASCADE CONSTRAINTS;
DROP TABLE detail CASCADE CONSTRAINTS;
DROP TABLE options CASCADE CONSTRAINTS;
CREATE TABLE avion (

immat VARCHAR2(6) NOT NULL,
type_av VARCHAR2(40),
nb_h_vol INTEGER,
CONSTRAINT pk_avion PRIMARY KEY (immat));
CREATE TABLE detail (

immat VARCHAR2(6) NOT NULL,
id_opt INTEGER NOT NULL,
date_pose DATE,
Figure 3-7. Association plusieurs-à-plusieurs
CONSTRAINT PK_DETAIL
à traduire
PRIMARY KEY (immat, id_opt));
CREATE TABLE OPTIONS (

id_opt INTEGER NOT NULL,
designation VARCHAR2(60),
prix_opt NUMBER(7,2),
CONSTRAINT pk_options
PRIMARY KEY (id_opt));
ALTER TABLE detail

ADD CONSTRAINT fk_configure_avion
FOREIGN KEY (immat)
REFERENCES avion (immat);
ALTER TABLE detail
ADD CONSTRAINT fk_configure_options
FOREIGN KEY (id_opt)
REFERENCES options (id_opt);
Vérifiez que la clé primaire de la table d’association est composée de deux clés étrangères.

Solution universelle
Le tableau suivant décrit la transformation de deux associations binaires entre les relations
Projet et Collaborateur. L’association affecter est de type de un-à-plusieurs l’associa-
tion diriger est de type de un-à-un.
Chaque association doit se traduire par une table d’association munie de deux clés étrangères.
Les contraintes UNIQUE et NOT NULL sur chacune de ces clés permettront d’implémenter telle
ou telle multiplicité.
Tableau 3-7 : Transformation de deux associations binaires par la solution universelle
ALTER TABLE affecter

DROP CONSTRAINT fk_affecter_collabor;
DROP CONSTRAINT fk_affecter_projet;
ALTER TABLE diriger
DROP CONSTRAINT fk_diriger_collabor;
ALTER TABLE diriger
DROP CONSTRAINT fk_diriger_projet;
DROP TABLE collaborateur CASCADE CONSTRAINTS;
DROP TABLE affecter CASCADE CONSTRAINTS;
DROP TABLE diriger CASCADE CONSTRAINTS;
CREATE TABLE collaborateur (

nom_coll VARCHAR2(50),
indice INTEGER,
CONSTRAINT pk_collaborateur
PRIMARY KEY (id_coll));
Figure 3-8. Associations binaires à traduire num_proj VARCHAR2(6) NOT NULL,
duree INTEGER,
budget NUMBER(9,2),
designation_proj VARCHAR2(60),
CONSTRAINT pk_projet
PRIMARY KEY (num_proj));
CREATE TABLE affecter (
num_proj VARCHAR2(6),
CONSTRAINT pk_affecter
PRIMARY KEY (id_coll);

CREATE TABLE diriger (

num_proj VARCHAR2(6) NOT NULL,
CONSTRAINT pk_diriger
PRIMARY KEY (num_proj),
CONSTRAINT AK_DIRIGER UNIQUE(id_coll));

ADD CONSTRAINT fk_affecter_collabor
ADD CONSTRAINT fk_affecter_projet
ALTER TABLE diriger
ADD CONSTRAINT fk_diriger_collabor
ALTER TABLE diriger
ADD CONSTRAINT fk_diriger_projet
La contrainte NOT NULL sur la colonne id_coll dans la table diriger signifie que tout
projet est dirigé par un collaborateur (multiplicité minimale 1). La contrainte UNIQUE sur
cette même colonne implémente le fait qu’un collaborateur ne peut diriger plusieurs projets
(multiplicité maximale 1).
L’absence de contrainte NOT NULL sur la colonne num_proj dans la table affecter signifie
qu’un collaborateur ne peut participer à aucun projet (multiplicité minimale 0). La contrainte
UNIQUE (du fait de la clé primaire) sur la colonne id_coll de cette même table implémente le
fait qu’un collaborateur ne peut participer à plusieurs projets (multiplicité maximale 1).
Cette solution présente l’avantage d’être la plus évolutive si les multiplicités viennent à
changer. En effet, nul besoin de modifier la structure d’une table, seules des contraintes seront
à activer ou à désactiver.
Mise en pratique
Les exercices 3.1 « La création de tables (carte d’embarquement) » et 3.2 « La création de tables
(horaires de bus) » vous proposent de déduire le script SQL à partir de différents modèles
conceptuels.

Programmation des contraintes

Cette section détaille d’une part la programmation des contraintes d’héritage et des contraintes
prédéfinies de UML (la contrainte d’inclusion et celle du ou exclusif). D’autre part, elle pré-
sente la traduction d’une contrainte personnalisée.
Il existe trois familles de décomposition pour traduire une association d’héritage (voir le cha-
pitre 2) : décomposition par distinction, descendante (push-down) et ascendante (push-up).
Héritage par distinction

Suivant le principe de décomposition par distinction, autant de tables que de relations sont
créées et la clé primaire de la table générique se propage dans les tables plus spécifiques.
Tableau 3-8 : Transformation de l’héritage par distinction
ALTER TABLE administratif

DROP CONSTRAINT fk_admin_personne;
ALTER TABLE commercial
DROP CONSTRAINT fk_commerci_personne;
ALTER TABLE manager
DROP CONSTRAINT fk_manager_personne;
DROP TABLE administratif CASCADE CONSTRAINTS;
DROP TABLE commercial CASCADE CONSTRAINTS;
DROP TABLE manager CASCADE CONSTRAINTS;
DROP TABLE personnel CASCADE CONSTRAINTS;
CREATE TABLE administratif (

idpers INTEGER NOT NULL,
syndicat VARCHAR2(60),
nbheuressupp INTEGER,
CONSTRAINT pk_administratif
PRIMARY KEY (idpers));
CREATE TABLE commercial (
prime FLOAT,
Figure 3-9. Héritage par distinction
CONSTRAINT pk_commercial
CREATE TABLE manager (
nbhmois INTEGER,

projet VARCHAR2(254),
CONSTRAINT pk_manager
CREATE TABLE PERSONNEL (
nom VARCHAR2(40),
indice INTEGER,
CONSTRAINT pk_personnel
ALTER TABLE administratif
ADD CONSTRAINT fk_admin_personne
FOREIGN KEY (idpers)
REFERENCES personnel (idpers);
ALTER TABLE commercial
ADD CONSTRAINT fk_commerci_personne
ALTER TABLE manager
ADD CONSTRAINT fk_manager_personne
Contrainte d’exclusivité
La contrainte d’exclusivité (cas par défaut, le diagramme de classes UML ne comporte aucune
indication) exprime les règles métier suivantes.
●● Il n’est pas possible qu’un personnel appartienne simultanément à plusieurs classifications
(commercial, manager ou administratif).

●● Il est possible qu’un personnel ne soit associé à aucune classification (commercial, manager
et administratif).
La première règle de gestion s’implémente à l’aide de trois déclencheurs : un sur chaque table
spécifique (commercial, manager et administratif). Il s’agit d’interdire qu’un manager
de numéro 100 soit aussi également référencé dans une autre table spécifique avec ce même
numéro (commercial et administratif). Le raisonnement devra s’appliquer à l’identique
pour les tables des commerciaux et celles des administratifs.
Le premier déclencheur est décrit dans le tableau suivant avec une syntaxe Oracle. Si vous
aviez à le programmer avec SQL Server, vous devriez utiliser les pseudo-tables Inserted et
Updated.

Tableau 3-9 : Déclencheur pour l’héritage par exclusivité
Déclencheur Oracle Jeu d’essai
CREATE TRIGGER tri_manager SQL> INSERT INTO PERSONNEL VALUES

BEFORE INSERT OR UPDATE OF idpers ON manager (100,'F. Brouard',456);
FOR EACH ROW
DECLARE 1 row created.
numero INTEGER;
BEGIN SQL> INSERT INTO COMMERCIAL VALUES
SELECT idpers INTO numero (100,14506.40);
FROM commercial WHERE idpers =
:NEW.idpers; 1 row created.
RAISE_APPLICATION_ERROR(-20001,'Le '
||numero||' est commercial...'); SQL> INSERT INTO MANAGER VALUES
EXCEPTION (100,52,'SQL Spot Design');
WHEN NO_DATA_FOUND THEN *
BEGIN ERROR at line 1:
SELECT idpers INTO numero ORA-20001: Le 100 est commercial...
FROM administratif WHERE idpers ORA-06512: at "SOUTOU.TRI_MANAGER", line 6
= :NEW.idpers; ORA-04088: error during execution of
RAISE_APPLICATION_ERROR(-20002,'Le ' trigger 'SOUTOU.TRI_MANAGER'
||numero||' est administratif...');
EXCEPTION
WHEN NO_DATA_FOUND THEN
-- la contrainte est vérifiée, mise à
jour autorisée
NULL;
END;
END;
La clause RAISE_APPLICATION_ERROR permet d’invalider la transaction en cours et de faire

passer un message applicatif.
La clause NO_DATA_FOUND permet de ne pas interrompre le bloc de traitement si une requête
ne retourne aucun enregistrement.
Les deux autres déclencheurs devront être programmés par analogie : celui portant sur la table
des commerciaux interrogeant les tables des managers et administratifs et celui de la table des
administratifs interrogeant les tables des managers et commerciaux.
Si vous ne souhaitez pas travailler avec des déclencheurs, vous devrez coder ces règles
métier dans vos procédures cataloguées.
La deuxième règle de gestion se programme naturellement du fait de l’existence de la clé

étrangère dans chaque table spécifique (commercial, manager et administratif) qui
référence la même table générique (personnel). En effet, il est possible que le personnel
numéro 100 ne soit référencé dans aucune table spécifique avec ce même numéro.

Absence de contrainte
L’absence de contrainte (notation {incomplete, overlapping} avec UML) permet les
scénarios suivants.
●● Il est possible qu’un personnel appartienne à une ou plusieurs classifications (commercial,
manager ou administratif).
●● Il est possible qu’un personnel ne soit associé à aucune classification (ni commercial, ni
manager, ni administratif).
Le premier scénario s’implémente naturellement du fait de l’existence de la clé étrangère dans
chaque table spécifique. En effet, il est autorisé que le personnel numéro 100 soit aussi égale-
ment référencé dans n’importe quelle table spécifique avec ce même numéro.
La deuxième règle de gestion est programmée aussi du fait de l’existence de la clé étrangère de
la même manière qu’au cas précédent.
Héritage en push-down
Suivant le principe de la décomposition descendante, seules les tables spécifiques créées et
toutes les colonnes et la clé primaire de la table générique se propagent.
Tableau 3-10 : Transformation de l’héritage en push-down
DROP TABLE administratif CASCADE CONSTRAINTS;

DROP TABLE commercial CASCADE CONSTRAINTS;
DROP TABLE manager CASCADE CONSTRAINTS;
CREATE TABLE administratif (

nom VARCHAR2(40),
indice INTEGER,
CONSTRAINT pk_administratif
CREATE TABLE commercial (

prime FLOAT,
nom VARCHAR2(40),
indice INTEGER,
Figure 3-10. Héritage par push-down CONSTRAINT pk_commercial

CREATE TABLE manager (

nbhmois INTEGER,
nom VARCHAR2(40),
indice INTEGER,
CONSTRAINT pk_manager
Contrainte de partition
La contrainte de partition (notation {complete, disjoint} avec UML) interdit les scéna-
rios suivants.
●● Un personnel appartient simultanément à plusieurs classifications (commercial, manager
ou administratif).
●● Un personnel n’est associé à aucune classification (ni commercial, ni manager, ni admi-
nistratif).
La première règle de gestion s’implémente à l’aide de trois déclencheurs : un sur chaque table
spécifique. Il s’agit d’interdire qu’un manager de numéro 100 soit également référencé dans
une autre table spécifique avec ce même numéro (commercial et administratif). Le
raisonnement devra s’appliquer à l’identique pour les tables des commerciaux et celle des
administratifs. Le code du déclencheur est décrit au paragraphe précédent.
La deuxième règle s’implémente naturellement du fait de l’inexistence d’une table générique.
Ici seuls managers, commerciaux ou administratifs peuvent être stockés.
Totalité ou absence de contrainte

La contrainte de totalité (notation UML {complete, overlapping}) et l’absence de
contrainte (notation UML {incomplete, overlapping}) autorisent le scénario dans lequel
un personnel n’est associé à aucune classification (ni commercial et ni manager ou adminis-
tratif).
Cette contrainte est impossible à mettre en œuvre du fait de l’inexistence d’une table géné-
rique. Si telle est la contrainte à implémenter, vous devrez opter pour une autre décomposition
de l’héritage (distinction ou push-up).
Héritage en push-up
Suivant le principe de la décomposition ascendante, seule la table générique est créée et ras-
semble toutes les colonnes des tables génériques.

Tableau 3-11 : Transformation de l’héritage en push-up
DROP TABLE personnel CASCADE CONSTRAINTS;
CREATE TABLE personnel (

nom VARCHAR2(40),
indice INTEGER,
prime FLOAT,
nbhmois INTEGER,
Figure 3-11. Héritage par push-up
CONSTRAINT pk_personnel
Contrainte d’exclusivité
La contrainte d’exclusivité interdit le fait qu’un personnel appartienne à plusieurs classifica-
tions (commercial, manager ou administratif) tout en permettant à un personnel de n’être
rattaché à aucune classification.
La première règle de gestion s’implémente à l’aide d’une contrainte de vérification (CHECK).
Il s’agit d’interdire que toutes les colonnes provenant des tables spécifiques disposent toutes
d’une valeur. Si les colonnes relatives à un manager sont renseignées, alors les autres (relatives
aux commerciaux et aux administratifs) doivent être nulles. Le même raisonnement devra
s’appliquer pour les colonnes des commerciaux et des administratifs.
Le tableau suivant présente cette contrainte ainsi que quelques insertions valides et une inva-
lide (personnel à la fois commercial et administratif).
Tableau 3-12 : Contrainte d’exclusivité pour l’héritage push-up
Contrainte d’exclusivité Jeu d’essai
-- commercial
ALTER TABLE personnel INSERT INTO personnel VALUES
ADD CONSTRAINT ck_exclusivite (100,'F. Brouard',500,47800,NULL,NULL,NULL,NULL);
CHECK 1 row created.
((projet IS NOT NULL AND nbhmois IS NOT NULL
AND prime IS NULL
AND syndicat IS NULL -- manager
AND nbheuressupp IS NULL) INSERT INTO personnel VALUES

Contrainte d’exclusivité (suite) Jeu d’essai (suite)
OR (101,'C. Date',450,NULL,45,'SQL SPOT',NULL,NULL);

(projet IS NULL AND nbhmois IS NULL 1 row created.
AND prime IS NOT NULL
AND syndicat IS NULL -- administratif
AND nbheuressupp IS NULL) I SERT INTO personnel VALUES
OR (102,'E. Codd',480,NULL,NULL,NULL,'C.F.D.T.',17);
AND prime IS NULL
AND syndicat IS NOT NULL -- aucune qualification
AND nbheuressupp IS NOT NULL) INSERT INTO personnel VALUES
OR 103,'C. Bravo',457,NULL,NULL,NULL,NULL,NULL);
AND prime IS NULL
AND syndicat IS NULL -- commercial et administratif
AND nbheuressupp IS NULL)); INSERT INTO personnel VALUES
(104,'M. Denizot',457,1500,NULL,NULL,
'C.F.D.T.',17);
*
ERROR at line 1:
ORA-02290: check constraint (SOUTOU.CK_
EXCLUSIVITE) violated
La deuxième règle de gestion s’implémente dans cette même contrainte en permettant que
toutes les colonnes spécifiques soient nulles simultanément.
Contrainte de partition
La contrainte de partition s’implémente en interdisant que toutes les colonnes spécifiques
soient nulles simultanément. Il suffit d’enlever la dernière partie de la condition composée. Le
tableau suivant décrit l’écriture de cette contrainte avec deux insertions invalides : la première
du fait d’un personnel non qualifié, la seconde à cause d’une double qualification.
Tableau 3-13 : Contrainte de partition pour l’héritage push-up
Contrainte de partition Jeu d’essai
-- invalide : aucune qualification

ALTER TABLE personnel INSERT INTO personnel VALUES
ADD CONSTRAINT ck_partition (103,'C. Bravo',457,NULL,NULL,NULL,NULL,
CHECK NULL);
((projet IS NOT NULL AND nbhmois IS NOT NULL *
AND prime IS NULL ERROR at line 1:

Contrainte d’exclusivité (suite) Jeu d’essai (suite)
AND syndicat IS NULL ORA-02290: check constraint (SOUTOU.CK_

AND nbheuressupp IS NULL) PARTITION) violated
OR
(projet IS NULL AND nbhmois IS NULL -- invalide (commercial et adminstratif par
exemple)
AND prime IS NOT NULL
INSERT INTO personnel VALUES
AND syndicat IS NULL
(104,'M. Denizot',457,1500,NULL,NULL,'C.F
AND nbheuressupp IS NULL)
.D.T.',17);
OR
*
(projet IS NULL AND nbhmois IS NULL
ERROR at line 1:
AND prime IS NULL
AND syndicat IS NOT NULL PARTITION) violated
AND nbheuressupp IS NOT NULL));
Contrainte de totalité
La contrainte de totalité permet des multiqualifications mais interdit les personnels non quali-
fiés. Le tableau suivant décrit l’écriture de cette contrainte avec deux insertions invalides : la
première du fait d’un personnel non qualifié, la seconde à cause d’une double qualification. La
contrainte doit signifier que les colonnes spécifiques ne doivent pas être nulles simultanément
(ce qui n’interdit pas des nullités partielles).
Tableau 3-14 : Contrainte de totalité pour l’héritage push-up
Contrainte de totalité Jeu d’essai
-- valide (commercial et adminstratif par

ALTER TABLE personnel exemple)
ADD CONSTRAINT ck_totalite INSERT INTO personnel VALUES
CHECK (104,'M. Denizot',457,1500,NULL,NULL,'C.F
.D.T.',17);
((projet||nbhmois||prime
1 row created.
||syndicat||nbheuressupp) IS NOT NULL);
-- aucune qualification
INSERT INTO personnel VALUES
(103,'C. Bravo',457,NULL,NULL,NULL,NULL,
NULL);
*
ERROR at line 1:
TOTALITE) violated
Absence de contrainte
Si l’héritage ne présente pas de restriction, aucune contrainte SQL n’est à mettre en œuvre.

Contraintes multitables (assertions)
Dans le cas de la modélisation des héritages, les contraintes à poser portent souvent sur
plusieurs tables. Rien n’empêche une contrainte SQL de table de s’intéresser aux données
présentes dans d’autres tables… sauf certains éditeurs de SGBDR !
En effet, Oracle s’interdit toutes contraintes de table portant sur une autre table et il n’y
a aucune échappatoire possible, pareil pour MySQL… En revanche, pour PostGreSQL,
comme pour MS SQL Server, même s’ils n’acceptent pas de référencer directement une
autre table dans une contrainte de validation CHECK , il est possible de biaiser en créant
une fonction utilisateur (ou UDF pour User Defined Function) qui lit une autre table afin
de fournir l’information nécessaire à la contrainte.
En plus des contraintes classiques, la norme SQL décrit les assertions de portée multi-
base. Pour une raison défendable, la plupart des éditeurs de SGBDR ont préféré ne pas
implémenter les assertions leur préférant les déclencheurs (triggers en anglais). On reste
cependant confondus devant les simplicités d’expression d’une assertion face à l’alterna-
tive CHECK + UDF ou trigger.
Voici un exemple d’assertion pour assurer l’exclusion mutuelle dans le cas d’un héritage
entre les personnes physiques et les personnes morales :
CREATE ASSERTION a_exclure_personne AS
CHECK NOT EXISTS(SELECT *
FROM t_personne_physique AS pp
INNER JOIN t_personne_morale AS pm
ON pp.prs_id = pm.prs_id);
Pour exprimer la même chose sous forme de déclencheurs, il faut beaucoup plus de code.
Quant à la version avec UDF, en voici un exemple, toujours sous MS SQL Server :
CREATE FUNCTION f_check_exclure_personne (@prs_id INT)
RETURNS BIT AS
BEGIN
RETURN CASE WHEN EXISTS(SELECT …
FROM t_personne_physique AS pp
INNER JOIN t_personne_morale AS pm
ON pp.prs_id = pm.prs_id
WHERE pp.prs_id = @prs_id)
THEN 1
ELSE 0
END;
END;
ALTER TABLE t_personne_physique

ADD CONSTRAINT ck_exclure_personne_pp
CHECK(f_check_exclure_personne (prs_id) = 0);
ALTER TABLE t_personne_morale

ADD CONSTRAINT ck_exclure_personne_pm
CHECK(f_check_exclure_personne (prs_id) = 0);

cLe chapitre 1 a présenté deux contraintes prédéfinies de UML : subsets (qui exprime une
contrainte d’inclusion) et xor (qui indique un ou exclusif).
Contrainte d’inclusion
Dans l’exemple suivant, la contrainte subsets exprime le fait qu’une inscription à une forma-
tion par un stagiaire (relation effectue) ne sera possible que si ce même stagiaire a choisi au
préalable cette formation (relation vœux). Le script SQL décrit n’inclut pas la contrainte qui
n’est pas générée automatiquement, mais qu’il faudra coder manuellement.
Tableau 3-15 : Contrainte d’inclusion
ALTER TABLE voeux

DROP CONSTRAINT fk_voeux_stagiair;
DROP TABLE formation CASCADE
CONSTRAINTS;
DROP TABLE stagiaire CASCADE
CONSTRAINTS;
DROP TABLE effectue CASCADE
CONSTRAINTS;
DROP TABLE voeux CASCADE CONSTRAINTS;
CREATE TABLE formation (

id_form INTEGER NOT NULL,
nom_formation VARCHAR2(50),
duree INTEGER,
prix_ht FLOAT,
CONSTRAINT pk_formation
PRIMARY KEY (id_form));
Figure 3-12. Contrainte d’inclusion CREATE TABLE stagiaire (
id_stag INTEGER NOT NULL,
prenom_stag VARCHAR2(40),
nom_stag VARCHAR2(50),
mail_stag VARCHAR2(60),
CONSTRAINT pk_stagiaire
PRIMARY KEY (id_stag));
CREATE TABLE effectue (
CONSTRAINT pk_effectue
PRIMARY KEY (id_stag, id_form));
CREATE TABLE voeux (
CONSTRAINT pk_voeux
PRIMARY KEY (id_stag, id_form));

ALTER TABLE effectue

ADD CONSTRAINT fk_effectu_forma
FOREIGN KEY (id_form)
REFERENCES formation (id_form);
ALTER TABLE effectue
ADD CONSTRAINT fk_effectue_
stagiair
FOREIGN KEY (id_stag)
REFERENCES stagiaire (id_stag);
ALTER TABLE voeux
ADD CONSTRAINT fk_voeux_form
FOREIGN
KEY (id_form)
REFERENCES formation (id_form);
ALTER TABLE voeux
ADD CONSTRAINT fk_voeux_stagiair
FOREIGN KEY (id_stag)
REFERENCES stagiaire (id_stag);
Le codage de cette contrainte se résume à la déclaration d’une nouvelle clé étrangère (com-
posée de deux colonnes) qui aura pour but de vérifier si tout couple (stagiaire, formation)
décrivant une inscription existe au préalable dans la table de référence des vœux.
Tableau 3-16 : Codage d’une contrainte d’inclusion
Contrainte d’inclusion Jeu d’essai
INSERT INTO formation VALUES (1,'SQL',4,1750);

ALTER TABLE effectue INSERT INTO formation VALUES (2,'C++',3,1050);
ADD CONSTRAINT fk_inclusion INSERT INTO formation VALUES (3,'Cobol',5,1900);
FOREIGN KEY (id_stag,id_form) INSERT INTO stagiaire VALUES
REFERENCES voeux (id_stag,id_form); (100,'Fred','Brouard','sqlspot@gmail.com');
INSERT INTO stagiaire VALUES
(101,'Rudi','Bruchez','rudi@gmail.com');
INSERT INTO voeux VALUES (100,2);
SQL> INSERT INTO effectue VALUES (100,2);

1 row created.
SQL> INSERT INTO effectue VALUES (100,1);

*
ERROR at line 1:
ORA-02291: integrity constraint (SOUTOU.FK_
INCLUSION) violated - parent key not found

Contrainte du ou exclusif
Analogue à l’héritage par exclusion, la contrainte xor suivante précise qu’un consultant est
soit associé à un projet, soit à une formation, mais pas aux deux simultanément. L’outil ne
génère pas cette contrainte dans le script SQL.
Tableau 3-17 : Contrainte xor
ALTER TABLE consultant

DROP CONSTRAINT fk_consul_forma;
DROP CONSTRAINT fk_consult_projet;
DROP TABLE consultant
CASCADE CONSTRAINTS;
DROP TABLE formation
CASCADE CONSTRAINTS;
CREATE TABLE consultant (

id_proj INTEGER,
formid INTEGER,
date_emb DATE,
prime_emp INTEGER,
Figure 3-13. Contrainte xor CONSTRAINT pk_consultant
CREATE TABLE formation (

formid INTEGER NOT NULL,
lib_cours VARCHAR2(60),
theme VARCHAR2(30),
CONSTRAINT PK_formation
PRIMARY KEY (formid));

id_proj INTEGER NOT NULL,
budget FLOAT,
lib_proj VARCHAR2(80),
CONSTRAINT pk_projet
PRIMARY KEY (id_proj));

ADD CONSTRAINT fk_consul_forma
FOREIGN KEY (formid)
REFERENCES formation (formid);
ALTER TABLE CONSULTANT
ADD CONSTRAINT fk_consult_projet
FOREIGN KEY (id_proj)
REFERENCES projet (id_proj);

La condition xor se programme à l’aide d’une contrainte de vérification qui vérifiera que tout
consultant soit associé à une formation ou à un projet, mais pas aux deux ou à aucun.
Tableau 3-18 : Codage d’une contrainte xor
Contrainte ou exclusif Jeu d’essai
ALTER TABLE consultant INSERT INTO projet VALUES (1, 40700, 'Viaduc de Millau');
ADD CONSTRAINT ck_xor CHECK INSERT INTO formation VALUES (10,'No SQL','SGBD Open source');
((id_proj IS NULL INSERT INTO consultant VALUES (100,1,NULL,'Fred
Brouard',SYSDATE,200);
AND formid IS NOT NULL)
INSERT INTO consultant VALUES (101,NULL,10,'Rudi
OR Bruchez',SYSDATE,150);
(id_proj IS NOT NULL
AND formid IS NULL))); SQL> INSERT INTO consultant VALUES (102,NULL,NULL,'Jean
Problem',SYSDATE,10);
ERROR at line 1: ORA-02290: check constraint
(SOUTOU.CK_XOR) violated
SQL> INSERT INTO consultant VALUES (103,1,10,'René

Bug',SYSDATE,10);
ERROR at line 1: ORA-02290: check constraint (
SOUTOU.CK_XOR) violated
La contrainte de simultanéité pourrait aisément se programmer d’une manière analogue en

interdisant qu’une des deux clés étrangères soit nulle.
Contraintes personnalisées
Le chapitre 1 a présenté quelques possibilités du langage OCL afin de spécifier des contraintes
à l’aide d’invariants de classes, de préconditions et postconditions à l’exécution d’opérations.
L’utilisation de rôles au niveau des liaisons entre classes du modèle conceptuel est bien souvent
nécessaire. Une expression OCL ne décrit pas l’implémentation d’une méthode, mais s’appa-
rente à un pseudo-algorithme.
Du fait de la complexité des règles métier, de simples contraintes de validation (CHECK)

ou clés étrangères (FOREIGN KEY) ne suffisent pas à implémenter la règle. Vous devrez uti-
liser des déclencheurs (triggers) ou programmer la règle dans vos procédures cataloguées si
le déclencheur n’est pas programmable ou si vous ne désirez pas procéder de cette manière.
L’exemple suivant décrit la contrainte que tout employé est soit chef, soit sous la responsabilité
d’un chef qui doit être employé dans la même entreprise que lui. L’outil ne génère pas cette
contrainte dans le script SQL. Il est préférable d’utiliser la solution universelle pour traduire
l’association réflexive de façon à pouvoir programmer un déclencheur dans de bonnes condi-
tions (éviter l’erreur des tables mutantes, avec Oracle : « ORA-04091: table name is
mutating, trigger/function may not see it »).

Tableau 3-19 : Contrainte personnalisée

id_ent INTEGER,
prenom_emp VARCHAR2(40),
mail_emp VARCHAR2(60),
salaire FLOAT,
CONSTRAINT pk_employe
CREATE TABLE entreprise (

id_ent INTEGER NOT NULL,
nom_entreprise VARCHAR2(50),
budget FLOAT,
CONSTRAINT pk_entreprise
PRIMARY KEY (id_ent));
CREATE TABLE chef_de (

id_chef INTEGER,
CONSTRAINT pk_chef_de
ALTER TABLE employe

Figure 3-14. Contrainte OCL ADD CONSTRAINT fk_emp_entrepri
FOREIGN KEY (id_ent)
REFERENCES entreprise (id_ent);
ALTER TABLE chef_de
ADD CONSTRAINT fk_chef_emp
FOREIGN KEY (id_chef)
ALTER TABLE chef_de
ADD CONSTRAINT fk_emp_emp
FOREIGN KEY (id_emp)
La règle se programme finalement par un déclencheur sur la table d’association chef_de. Ce

déclencheur devra s’assurer, après chaque ajout ou modification d’un chef, que le chef et son
subalterne appartiennent à la même entreprise.

Tableau 3-20 : Codage d’une contrainte OCL
Déclencheur Jeu d’essai
INSERT INTO entreprise VALUES (2,'Air

France',90000);
CREATE TRIGGER trg_chef_meme_entreprise INSERT INTO entreprise VALUES
(3,'Airbus',190000);
AFTER INSERT OR UPDATE OF id_chef
INSERT INTO employe VALUES (100,3,'Fred
ON chef_de
','Brouard','sqlspot@gmail.com',4000);
FOR EACH ROW
INSERT INTO employe VALUES (101,3,'Fred
DECLARE ','Brouard','sqlspot@gmail.com',4000);
v_id_ent_chef entreprise.id_ent%TYPE; INSERT INTO employe VALUES (102,2,'Rudi
v_id_ent_emp entreprise.id_ent%TYPE; ','Bruchez','bruchez@gmail.com',3000);
BEGIN
IF NOT (:NEW.id_chef IS NULL) THEN SQL> INSERT INTO chef_de VALUES
SELECT id_ent INTO v_id_ent_chef (100,NULL);
FROM employe WHERE id_emp = :NEW.id_chef; 1 row created.
SELECT id_ent INTO v_id_ent_emp
FROM employe WHERE id_emp = :NEW.id_emp; SQL> INSERT INTO chef_de VALUES
IF NOT (v_id_ent_chef = v_id_ent_emp) THEN (101,100);
RAISE_APPLICATION_ERROR(-20101,'Le chef et 1 row created.
l''employe n''ont pas la meme entreprise...');
END IF; SQL> INSERT INTO chef_de VALUES
END IF; (102,100);
END; *
ERROR at line 1:
ORA-20101: Le chef et l'employe n'ont
pas la meme entreprise...
ORA-06512: at "SOUTOU.TRG_CHEF_MEME_
ENTREPRISE", line 10
Je n’ai jamais rien compris à cette histoire de tables mutantes, limitation qui, à ma
connaissance, n’existe que chez Oracle. La norme SQL accepte qu’un déclencheur puisse
accéder à la table cible dudit déclencheur. SQL Server l’a mis en œuvre :
CREATE TRIGGER e_personne ON t_personne FOR UPDATE
AS
UPDATE t_personne SET nom = UPPER(nom)
WHERE prs_id IN (SELECT prs_id FROM inserted) -- table
comportant les données modifiées (équivalent du NEW)
GO

Mise en pratique
L’exercice 3.3 « La programmation de contraintes » vous propose de programmer quelques
contraintes sur différentes tables.
Dénormalisation
Avant de penser à la dénormalisation, il faut que vous soyez assuré que vos tables sont nor-
malisées au préalable… La majorité des problèmes de performances des applications en
production survient à la montée en charge au niveau du volume des données. En d’autres
termes, manipuler des tables mal conçues devient seulement pénalisant quand elles deviennent
volumineuses et ne tiennent plus en RAM. Quand les experts étudient le code et se rendent
compte que les tables ne sont pas normalisées, il est souvent déjà un peu trop tard. Partez sur
de bonnes bases (c’est le cas de le dire) : normalisez au maximum en amont !
Si vos tables sont normalisées et vos clés étrangères indexées, le plus gros du travail est fait.
Vous disposez d’autres outils que sont le partitionnement ou les vues matérialisées. Si malgré
tout ça, vos temps de réponse sont inacceptables, vous pouvez essayer de dénormaliser certaines
tables.
Vous pouvez dénormaliser une table en ajoutant des colonnes qui permettront de stocker
soit des colonnes calculées (qui éviteront des calculs), soit des données redondantes (mais
plus accessibles) ou des clés primaires (de taille plus réduite : une séquence par exemple) ou
étrangères (qui diminueront les jointures). Dans bien des cas, vous devrez programmer des
déclencheurs afin de maintenir l’intégrité dans le temps de votre nouvelle base. Si vous n’êtes
pas un adepte des déclencheurs, ce traitement devra être codé dans vos procédures.
La dénormalisation sera profitable si votre application effectue beaucoup de lectures et peu de
mises à jour. Si beaucoup de mises à jour sont réalisées, la dénormalisation dégradera sen-
siblement certaines performances. En revanche, si votre application effectue peu de lectures,
dénormaliser ne sert à rien (a fortiori lorsqu’il existe beaucoup de mises à jour).
Colonnes calculées
Dans l’exemple suivant, l’ajout des colonnes totaljp (nombre de jours à facturer) et totalj
(nombre de jours de formation dans l’année) évitera tout calcul impliquant des jointures avec
la table Inscriptions.

Figure 3-15. Dénormalisation par colonnes calculées
Le revers de la médaille consiste en la nécessité de programmer plusieurs déclencheurs sur

la table Inscriptions qui mettront à jour ces deux colonnes à chaque inscription et à toute
désinscription. Une ou plusieurs vues matérialisées peuvent être également utilisées.
Duplication de colonnes
Dans l’exemple suivant, l’ajout des colonnes identite2 (nom du client) et ste2 (société du
client) évitera toute jointure avec la table Client pour lister les détails des inscriptions. Ici, on
régresse de la troisième à la première forme normale.
Figure 3-16. Dénormalisation par ajout de colonnes

Les inconvénients de ce mécanisme sont d’une part l’espace utilisé, d’autre part le risque d’in-
cohérence si le nom d’un client vient à changer (ou le nom de sa société). La solution consiste
à utiliser un déclencheur sur la table Client ou une vue matérialisée (contenant entre autres
ces colonnes additionnelles).
Ajout de clés étrangères

Dans l’exemple suivant, l’ajout de la colonne nseg (numéro de segment) évitera toute jointure
avec la table Salles pour relier des postes à leur segment. Ici on régresse de la troisième à la
deuxième forme normale.
Figure 3-17. Dénormalisation par ajout de clé
On retrouve les mêmes inconvénients que précédemment (espace perdu et redondances). Pour
y remédier, il faudra programmer un déclencheur ou passer par une vue matérialisée.
Exemple de stratégie
Dénormaliser est une action forte sur la base, car la structure des tables sera altérée, des redon-
dances vont apparaître et des déclencheurs seront à mettre en œuvre. En conséquence, cette
technique doit être la dernière réponse à un problème de temps de réponse en exploitation et
en aucun cas justifiée par l’intérêt du programmeur.
Normalisez au maximum avant de mettre en exploitation puis auditez régulièrement quelques

semaines, mois ou années suivant la montée en charge.
Appliquez les requêtes les plus pénalisantes à une base dénormalisée, mais équivalente en
termes de données. Comparez les temps de réponse entre les deux bases. Si le temps de
réponse est de plus de 30 % inférieur, il devient vraiment intéressant de dénormaliser.

Dans une base de données relationnelle, donc fortement transactionnelle, rien ne justifie
a priori la dénormalisation. Il faut avant tout normaliser au maximum. La dénormali-
sation étant un acte fort, elle ne peut que résulter d’une décision risquée prise en pleine
connaissance de cause à l’aide des critères suivants.
• Le gain de dénormalisation doit être prouvé : il faut donc mettre à l’épreuve la base
avec un volume de données significatif et une concurrence équivalente à celle de l’ex-
ploitation. Cela ne peut se faire généralement qu’en cours d’exploitation…
• Le gain doit être très important. Un gain minime sera généralement perdant à long
terme du fait du surcroît de volume généré par la redondance et l’accroissement des
temps de transaction (plus de données à mettre à jour, c’est toujours plus long).
• Le gain doit s’analyser globalement. L’erreur la plus courante est de ne mesurer que
le gain apporté à la table qui est dénormalisée. Or, la dénormalisation entraîne systé-
matiquement des effets de bord, qu’il est souvent difficile de mesurer de prime abord.
Par exemple, l’accroissement du volume des données comme l’allongement du temps
de mise à jour induit par la dénormalisation, a des répercussions sur les transactions
dont la durée augmente. De ce fait, les verrous durent plus longtemps et les risques de
blocage comme d’interblocage sont accrus.
Plus une table est petite (en nombre de colonnes), plus elle est facile à indexer. D’ailleurs,
le respect absolu de la normalisation des relations (pas de valeurs NULL) conduit à une
base dont les tables sont formées d’une clé et d’au plus un attribut non clé.
Enfin, avant de dénormaliser, il existe d’autres techniques telles que : l’hypernormalisa-
tion (par exemple ajouter une table des prénoms au lieu de mettre la colonne prénom dans
la table personne) ou le partitionnement.
Quelle que soit la solution d’implémentation que vous choisirez : normaliser au maximum,
dénormaliser, indexer telle ou telle colonne, programmer une contrainte dans une procédure
plutôt que dans un déclencheur, etc., vous rencontrerez des avantages, mais aussi des inconvé-
nients. Vous devrez toujours peser le pour et le contre de toute implémentation ou optimisation
pour décider finalement le plus souvent après des tests à grandeur nature.
Les règles de Brouard

Pour en terminer avec ces mécanismes d’optimisation, quelques conseils d’ordre général à
propos de vos requêtes et de l’utilisation d’un SGBD. Parues en 2008 sur le blog de F. Brouard
(http://blog.developpez.com/sqlpro), voilà les 10 meilleures pratiques pour développer avec un
SGBDR.
1. Une base de données relationnelle doit gérer des relations et non des fichiers.
Assurez-vous que vos tables ne contiennent pas un nombre trop important de colonnes.
Respectez la normalisation introduite par le modèle relationnel. Contrairement à une

idée reçue, composer sa base avec plus de tables ayant peu de colonnes rendra meilleures
les performances de vos requêtes.
2. Une clé primaire artificielle est préférable à une clé métier (sémantique).
En choisissant le numéro d’immatriculation d’une voiture, qui vous dit qu’à la création
de l’enregistrement, l’information sera connue ou que cette valeur n’évoluera pas dans
le temps (entraînant des effets de bord très coûteux). La clé métier est en général plus
volumineuse qu’une simple colonne NUMBER . L’idéal, c’est de définir une clé primaire
artificielle et de disposer aussi d’une clé métier (contrainte UNIQUE).
3. Ne codez jamais (à part dans vos tests ou démonstrations), une requête du type « SELECT
* … », cela pour les trois raisons principales suivantes :
Moins il y a de données qui circulent sur le réseau, plus les temps de réponse sont courts.
Il est donc préférable d’indiquer dans la liste des colonnes uniquement celles qui sont
nécessaires.
Allégez la charge du transformateur de requêtes en lui évitant de rechercher les informa-
tions dans les tables système pour déduire la liste de toutes les colonnes et les privilèges
associés.
Allez-vous interdire implicitement que vos tables évoluent en termes de structure ? Ajouter
ou supprimer une colonne risque de rendre le code inopérant à tout endroit où cette
instruction se trouvera.
4. Évitez si possible d’utiliser des curseurs dans vos transactions.
Les curseurs imposent une programmation itérative (où les données sont traitées ligne
par ligne comme avec un simple fichier) et non ensembliste. Un SGBD est optimisé pour
traiter de manière ensembliste les données avec SQL. Depuis la version SQL:1999, la
récursivité est prise en charge et SQL devient un langage complet (au sens de la machine
de Turing) où tout traitement peut être théoriquement programmé à l’aide de requêtes.
5. Écourtez la durée de vos transactions et programmez côté serveur (procédures cata
loguées).
Une transaction nécessite d’accéder souvent exclusivement aux données et des verrous
sont mis en œuvre automatiquement. Les verrous induisent des temps d’attente pour les
utilisateurs concurrents. Si votre code n’est pas optimisé ou s’il s’exécute du côté du client,
la contention devient inévitable.
6. Utilisez le SQL dynamique pour écrire des requêtes simples.
Le fait d’écrire une instruction avec du SQL dynamique évite au transformateur de
requêtes un certain nombre de tâches et permet la réutilisation du plan d’exécution.
7. Paramétrez la bonne collation.
Une collation sert à gérer la manière dont les chaînes de caractères, constituant les
données de la base, vont se comporter face aux opérateurs de comparaisons et à l’ordon-
nancement des données (tri). La gestion des majuscules/minuscules, accents, ligatures
(par exemple, cœur), etc. doit être prévue.

8. N’utilisez jamais une requête du type « SELECT MAX(...)+1 … » pour générer une clé
primaire.
Ce mode de calcul est à proscrire, car il peut conduire un jour ou l’autre au mieux à un
télescopage de clé, au pire à un blocage total. En effet, tant que la nouvelle ligne pourvue
de cette nouvelle clé n’est pas encore insérée dans la base, toute autre transaction peut
effectuer le calcul générant la même valeur. Afin de rendre cohérent ce mécanisme, il
faudrait programmer une transaction intégrant le calcul du max+1 et l’ordre d’insertion
avec la nouvelle clé (ce qui n’est pas aussi simple qu’il y paraît).
Préférez le mécanisme d’auto-incrément de votre SGBD qui pour Oracle est la séquence.
SEQUENCE et IDENTITY ont été normalisés (SQL:2008) SQL Server et IBM DB2 pren-
nent les deux en charge. PostGreSQL propose le SERIAL (équivalent du IDENTITY en
plus de la séquence).
9. Utilisez avec parcimonie les tables temporaires.
Chaque objet temporaire créé au sein d’un SGBDR déclenche une écriture coûteuse au
journal de transactions et dans le dictionnaire des données. Si de nombreuses transac-
tions sont effectuées en parallèle et qu’elles génèrent de nombreux objets temporaires, des
points de contention peuvent apparaître. Préférez l’utilisation de requêtes contenant des
fonctions table ou des CTE.
10. Utilisez des index, mais à bon escient.
Indexez vos clés étrangères et choisissez bien le mode d’indexage (B-tree, bitmap ou IOT).
Si une table IOT convient à une séquence, elle peut mener à des performances désas-
treuses pour une clé sémantique alphanumérique de taille variable.
Peu importe le nombre d’index d’une table, si chaque index apporte un gain considérable.
Avec un gain de 100 voire 1 000 (facilement obtenu sur des tables ayant un grand nombre
de lignes) c’est autant de temps de gagner pour les mises à jour, dont on oublie trop sou-
vent qu’elles nécessitent pour la plupart une lecture positionelle qui sera d’autant plus
rapide qu’il existe un index adéquat !
Mise en pratique
L’exercice 3.4 « La dénormalisation » vous invite à dénormaliser un schéma, mais quelle table
sera impactée ?
Dans l’exercice 3.5 « Ma psy oublie tout », vous devez aider ma psy qui oublie tout.
L’exercice 3.6 « Le planning d’une école de pilotage » est consacré à la gestion d’un planning
d’une école de pilotage.

Exercices
3.1 La création de tables (carte d’embarquement)

Écrire le script SQL (en éliminant les tables inutiles) permettant de créer les tables correspon-
dant au modèle conceptuel suivant.
Figure 3-18. Modèle conceptuel de la carte d’embarquement
Vous devez définir un index sur chaque clé étrangère et typer les colonnes de la manière la
plus adéquate.

Tableau 3.21 : Dictionnaire des données
Colonne Désignation Type de

données
code_OACI Le code des aéroports est un classement géographique défini par 4 lettres
l’Organisation de l’aviation civile internationale.
code_fidelite Identifiant de la carte de fidélité. Entier

1 position
heure_dep, heure_emb, Heures de départ, d’arrivée et d’embarquement prévues (catalogue). Heures et

heure_arr Les heures vont de 0 à 23, seuls les quarts d’heure sont acceptés (0, minutes :
15, 30 ou 45). 2 chiffres
heure_dep_reel, Heures de départ et d’arrivée réelles. Les heures vont de 0 à 23, et Heures et
heure_arr_reelle, les minutes de 0 à 59. minutes :
min_dep_reel, 2 chiffres
min_arr_reelle
jour_mois Jour et mois de l’année (par exemple, 01-MAR). 6 caractères
jour_mois_planning Numéro du jour de l’année. 3 positions
lib_fidelite Libellé de la carte de fidélité (IVORY, SILVER, GOLD, etc.). 20 caractères
nom_aeroport Nom de l’aéroport. 50 caractères
num_carte Numéro du client. Entier

12 positions
num_porte Numéro de la porte d’embarquement (par exemple, 20L). 3 caractères
num_siege Numéro du siège dans l’avion (par exemple, 12A). 3 caractères
num_vol Numéro de vol est un code alphanumérique, composé du code 8 caractères

AITA de la compagnie aérienne (3 lettres) et d’un nombre de 3 ou (par exemple,
4 chiffres. AF-6145)
prenom_client, Identité du client. 40 caractères

nom_client pour chaque

3.2 La création de tables (horaires de bus)

Écrire le script SQL permettant de créer les tables correspondant au modèle conceptuel suivant.
Figure 3-19. Modèle conceptuel des horaires de bus
Vous devez définir un index sur chaque clé étrangère et typer les colonnes de la manière la
plus adéquate.
Tableau 3.22 : Dictionnaire des données
Colonne Désignation Type de données
id_jour, id_ligne Identifiants des jours (3 occurrences), des lignes (moins d’une Numériques de 1 à
et id_sta centaine) et des stations (plus de 300). 3 positions
lib_jour, nom_ligne Libellés des jours (30 caractères), des lignes (60 caractères) et Caractères de taille
et nom_station des stations (25 caractères). variable
heure, minute Heures et minutes de passage. Les heures vont de 0 à 23, les Numériques de
minutes de 0 à 59. 2 positions
ordre, position Ordre de la station en fonction du jour et de la ligne de bus. Numériques de

Position en colonne de l’heure de passage. 2 positions

3.3 La programmation de contraintes

Carte d’embarquement
Programmez les contraintes suivantes.
●● Pour tout vol présent au catalogue, l’aéroport de départ est différent de celui d’arrivée
(même si, parfois, il arrive qu’on atterrisse là où on décolle, mais ce n’est pas prévu au
programme en général).
●● Le nom des types de cartes est unique.
●● Les données dans les colonnes heures et minutes prévisionnelles doivent être valides (entre
0 et 23 pour les heures, tous les quarts d’heure pour les minutes).
●● Les heures de départ sont inférieures d’au moins une heure à celles d’arrivée.
Horaires de bus
●● Pas plus de trois libellés « Lundi à vendredi », « Samedi » et « Dimanche et jours fériés »).
●● Chaque ligne n’est pas forcément planifiée tous les jours.
●● Il n’y a pas plus de 15 stations sur un même trajet.
●● Les horaires sont à afficher sous la forme hh.min (avec hh de 6 à 22 et min de 0 à 59).
●● Il n’y a pas plus de 8 colonnes d’horaires à afficher.
E-mails des clients et prospects

Considérez le schéma relationnel suivant qui vise à décrire une population distincte de clients
et prospects.
Figure 3-20. Modèle physique des clients et prospects


●● Une adresse e-mail est unique dans la base de données.
●● Un client n’est pas un prospect, et réciproquement.
●● Un prospect ne peut pas détenir plusieurs adresses e-mails (une maximum).
●● Un client peut détenir au maximum 3 adresses e-mails.
●● Seuls les clients arrivés depuis plus de 4 ans peuvent détenir jusqu’à 5 adresses e-mails.
3.4 La dénormalisation
Dénormalisez les tables du schéma de la carte d’embarquement pour, d’une part, connaître le
nombre de vols effectués par les passagers et, d’autre part, optimiser l’affichage suivant. Les
données additionnelles à prendre en compte sont le prix de chaque vol (seul le montant total
est affiché), les noms de chaque compagnie et des aéroports, et un libellé qui indique qu’il ne
reste qu’un faible nombre de places disponibles.
Figure 3-21. Liste des vols réels disponibles

Horaires de bus
Réduisez le plus possible le schéma relationnel normalisé des horaires de bus quitte à dénor-
maliser certaines tables ou à abandonner de la cohérence.
3.5 Ma psy oublie tout

Ma psy oublie tout : l’heure de mon rendez-vous, mon deuxième prénom, même la date de mon
anniversaire ! En cherchant sans ses lunettes dans ses fiches manuscrites, elle a confondu ma
fiche avec celle de René Soustout, ancien pilier du Stade toulousain, devenu pilier de bar, qui
l’avait consultée quelques années auparavant.
Figure 3-22. Stockage des fiches patients
Rendez-vous
Pour sa fête, ma psy a reçu un ordinateur d’un patient passionné. Connaisant ma névrose
du rangement et de l’organisation des données, elle m’a demandé de l’aider à mettre un peu
d’ordre dans ses fiches patients. Voici les données à conserver.
●● Qui est venu la voir et à quelle heure. La classification qui l’intéresse est la suivante :
enfant, ado, femme, homme ou couple. Notez que les séances d’un couple peuvent se pour-
suivre individuellement et qu’un patient ado peut revenir quelques années plus tard en tant
qu’adulte.
●● Par quel moyen (autre patient, docteur, bouche à oreille, Pages Jaunes, Internet, etc.) le
patient l’a-t-elle connue (elle est curieuse !).

●● La date de la première consultation et si le patient est en retard à son rendez-vous.

●● Le mode de règlement de la séance.
●● Pour les consultations pour anxiété, l’indicateur de 0 à 10 que le patient s’attribue (enfin s’il
peut parler encore…).
●● Certains critères (profession du patient, liste des prénoms des personnes familières, etc.) à
consulter avant le rendez-vous.
●● Certains mots-clés (expressions utilisées à l’oral par le patient), d’éventuelles postures
affichées et certains comportements observés au cours de la séance notés après le rendez-
vous.
●● Notez que la psy prend au maximum 3 patients pour une même consultation (de toute
manière, il n’y a que deux sièges et un fauteuil !).
Confrères et livres
Pour débrieffer certaines séances lourdes, pour rigoler ou, parfois, pour pleurer, ma psy voit
des psys. Ses confrères sont de professions diverses (psychologue, psychotérapeute, psychiatre,
psychanaliste, sophrologue, marabout, etc.). Certains ont deux voire trois qualifications.
Figure 3-23. Les psys de ma psy
Les rendez-vous avec ses confrères doivent être modélisés. Elle désire noter les circonstances
de la première rencontre avec chacun des spécialistes côtoyés, pour raisons professionnelles
ou privées.
Elle envoie également certains de ses patients en consultations ponctuelles chez ses confrères
qui lui transmettent par la suite un mémo résumant la séance.
De plus, elle prête également des livres à ses patients, sans retour parfois. Elle souhaite donc
endiguer ce phénomène. Par contre, elle passe sous silence le fait que certains patients lui prêtent
des livres qu’elle dispose ensuite dans sa bibliothèque…
Ma psy ne fait pas un boulot facile alors ne ratez pas sa base de données !

3.6 Le planning d’une école de pilotage

Pour finir avec un peu plus de légèreté, modélisez la base de données visant à gérer le planning
et la comptabilité des vols d’une école de pilotage.
Flotte
La flotte de l’école est composée de différents aéronefs. Les types se caractérisent le plus
souvent par un libellé avec ou sans code (par exemple, Aquila-AT01, Robin DR400-120, CES-
SNA-172N, DA40, SR20-G3, TB20, etc). L’immatriculation de l’avion, sa puissance et son
prix horaire doivent aussi être sauvegardés. Il est possible que l’école possède plusieurs aéro-
nefs de même type. Pour chaque avion 2 indicateurs sont importants à mettre à jour : le nombre
d’heures de vol de la cellule et le nombre d’heures de vol du moteur (qui est changé plusieurs
fois au cours de la vie de l’appareil).
Figure 3-24. La flotte de l’école
Chaque aéronef doit être révisé périodiquement en fonction du nombre d’heures d’utilisation
(50 h, 100 h, 500 h, 1 000 h ou 2 000 h). Les dates de ces visites de maintenance doivent être
mémorisées de même qu’un éventuel commentaire. Il en va de même pour le détail des pièces
achetées (prix TTC) lors de l’entretien, ainsi que le nombre total d’heures de travail néces-
saires.

Acteurs
Élèves pilotes et instructeurs évoluent dans cette structure. Les élèves s’inscrivent à une date
qui doit être mémorisée. Pour tous, les nom, prénom et adresse doivent être connus. Tous dis-
posent d’un compte sur lequel ils peuvent déposer une somme d’argent. Les sommes prélevées
correspondent au montant du vol effectué par un élève pilote ou par un instructeur s’il réserve
l’avion pour lui.
Les instructeurs, qui sont identifiés sur le planning par un trigramme inspiré de leur nom,
bénéficient d’une réduction sur le coût horaire (différente en fonction de chaque type d’avion).
Notez qu’un instructeur n’est pas forcément qualifié sur tous les types d’appareils de l’école.
Chaque séance de vol (soit en instruction, soit en solo lorsque l’élève pilote vole seul) effectuée
est décomptée en dixièmes d’heures (par exemple, 1.5 signifie 1 h 30 de vol) et doit être mémo-
risée avec la date du vol. Le nombre total d’heures de vol pour un élève ou pour un instructeur
doit être facilement accessible, que ce soit pour les vols d’instruction (en double commande)
ou en solo.
Élèves et pilotes doivent passer annuellement ou semestriellement une visite médicale. Sa date
et son résultat (apte ou inapte) doivent être consignés, ainsi qu’un éventuel commentaire.
Rendez-vous
Tous peuvent effectuer des réservations. Il suffit de s’inscrire sur le planning en sélectionnant
l’aéronef, la plage horaire et, éventuellement, l’instructeur désigné par ses initales. Il est égale-
ment possible de noter un commentaire et le nombre de places disponibles. Notez que certains
avions peuvent être indisponibles, durant une période plus ou moins longue, pour cause de
maintenance.
Figure 3-25. Planning de l’école

Chapitre 4
Le niveau externe
Le niveau externe présenté dans ce chapitre concerne la définition et la manipulation des
vues (views). Les vues agissent comme des fenêtres sur la base de données. Une vue est
construite à l’aide d’une requête qui retourne un résultat tabulaire. C’est pour cette raison
qu’un vue apparaît à un utilisateur sous la forme d’une table. En réalité, une vue ne contient
pas de données (excepté les vues matérialisées), elle ne fait que filtrer les données issues de
tables.
Pour tout développement de qualité, les vues sont indispensables pour éviter tout accès direct
aux tables. En pratique, bon nombre d’applications se passent de ce concept, en manipulant
directement les tables.
En plus d’un contrôle fin à l’accès aux données (confidentialité, sécurité et privilèges), une vue
permet de masquer la complexité ou de dénormaliser des schémas relationnels, d’implémenter
des contraintes de valeur (ou d’intégrité) et de simplifier la formulation de requêtes complexes.
La figure suivante illustre trois accès à une base de données. Chaque utilisateur opère sur un
schéma externe composé des vues accessibles pour son profil. Les données peuvent provenir
de différentes tables et sont toujours stockées dans des tables (sauf pour le cas des vues maté-
rialisées qui combinent les concepts de table et de vue).

Figure 4-1. Les vues
La majeure partie des opérations réalisées sur une vue sont des extractions, mais dans cer-
tains cas, une vue peut être modifiable (les mises à jour impacteront alors la table source). Par
ailleurs, nous verrons qu’un type de déclencheur (instead of trigger) permet de programmer
des mises à jour de vues multitables.
Le niveau externe concerne aussi les routines SQL permettant de présenter ou de mettre
à jour les données de manière indirecte (procédures stockées, déclencheurs et UDF ou
User Defined Function).
Somme toute, une vue n’est qu’un nom de table donné à une requête d’extraction de
données (SELECT) et on constatera d’après la norme SQL que les vues sont considérées
comme des tables d’un type particulier VIEW, les tables conventionnelles étant considé-
rées en tant que BASE TABLE . Notons dès à présent qu’il est possible, dans certains cas,
de mettre à jour par INSERT, UPDATE , DELETE ou MERGE , les données des tables à travers
les vues.
Une catégorie particulière de routines, les fonctions table, permet de mettre en œuvre des
vues avancées. Le fait qu’une fonction table admette des paramètres en entrée et retourne
un jeu de données, rend possible la réalisation de vues paramétrables.
Globalement, les procédures stockées permettent de réaliser des traitements complexes
de mise à jour en masquant la complexité à l’utilisateur. Une procédure stockée peut aussi
renvoyer un ou plusieurs jeux de données.

Chapitre 4 Le niveau externe
Enfin, des déclencheurs d’un type particulier, les trigger INSTEAD OF, permettent de
réaliser des traitements complexes, à la manière des procédures, lorsque survient une
opération de mise à jour (INSERT, UPDATE ou DELETE).
Tous ces éléments constituent le modèle externe de données (MED).
Pour tout développement de qualité, les objets du MED sont indispensables pour éviter
tout accès direct aux tables. En pratique, bon nombre d’applications se passent de ce
concept en manipulant directement les tables. Et c’est une erreur ! En effet, la couche d’in-
terface ou d’abstraction apportée par le modèle externe de données rend indépendants la
structure de la base et l’accès aux données. En gros, une modification de la structure des
tables de la base n’affecte pas la couche externe et si l’application a été développée sur
cette couche, il n’est généralement pas nécessaire de la modifier pour qu’elle continue de
fonctionner, sauf si les modifications de structure apportent de nouvelles fonctionnalités
ou portent atteinte aux données stockées dans la base.
En combinant vues, fonctions table, déclencheurs INSTEAD OF et procédures stockées,
on peut concevoir des structures de données proches de celles des objets applicatifs et y
greffer les méthodes CRUD de manipulation desdits objets (INSERT, SELECT, UPDATE ,
DELETE). En fait, le modèle externe de données simule de manière performante ce qu’un
ORM (Object Relational Mapping) fait de manière contre-performante !
Ce chapitre décrit les différents types de vues qui existent :

●● les vues relationnelles issues de tables SQL2 ;
●● les vues matérialisées issues de tables SQL2 ;
●● les vues objet issues de tables SQL2 ou SQL3.
La syntaxe SQL utilisée dans ce chapitre est celle d’Oracle ; elle est relativement proche du
standard en comparaison avec d’autres SGBD (excepté concernant les vues objet).
Les vues relationnelles (SQL2)

Une vue SQL2 est une table virtuelle du fait qu’elle n’occupe aucun espace disque pour
contenir ses données (seules les données filtrées de la table sont montées en mémoire à chaque
sollicitation). Une vue relationnelle n’a pas d’existence propre (elle ne stocke pas de données),
seule sa structure est stockée dans le dictionnaire de données.
Une vue est créée à l’aide d’une instruction SELECT appelée « requête de définition ». Cette
requête interroge une ou plusieurs tables, vues (ou vues matérialisées). Une vue se recharge
chaque fois qu’elle est interrogée.

Création d’une vue

La syntaxe simplifiée de création d’une vue SQL2 est la suivante :
CREATE VIEW [nom_schéma.]nom_vue
[ (alias1, alias2… ) ]
AS requête_SELECT
[WITH { READ ONLY | CHECK OPTION } ];
●● alias désigne le nom de chaque colonne de la vue. Si l’alias n’est pas présent, la colonne
prend le nom de l’expression renvoyée par la requête de définition.
●● requête_SELECT extrait des données en provenance d’une ou de plusieurs tables, vues
ou vues matérialisées. Tous les éléments de la clause SELECT doivent comporter un nom
unique.
●● WITH READ ONLY déclare la vue non modifiable par INSERT, UPDATE ou DELETE.
●● WITH CHECK OPTION garantit que toute mise à jour de la vue par INSERT ou UPDATE
s’effectuera conformément au prédicat de la requête de définition.
En théorie, la clause ORDER BY (qui n’est pas, au passage, un opérateur relationnel), ne

doit pas figurer dans la définition d’une vue relationnelle.
Classification
On distingue les vues simples des vues complexes en fonction de la nature de la requête de
définition. Le tableau suivant résume cette classification.
Tableau 4-1 : Classification des vues
Requête de définition Vue simple Vue complexe

Nombre de tables 1 (monotable) 1 ou plusieurs (multitable)
Fonction d’agrégat (MAX, SUM , etc.) Non Oui
Regroupement Non Oui

Mises à jour possibles Oui Pas toujours

Une vue monotable est aussi considérée comme étant complexe si la requête comporte le
mot-clé DISTINCT, les clauses HAVING , GROUP BY ou WINDOW, une fonction de fenêtrage,
ou des colonnes définies par des expressions calculées ou constantes.
Avec Oracle, une vue est complexe si la requête comporte le mot-clé DISTINCT, ROWNUM
ou ROW_NUMBER, ORDER BY, HAVING ou CONNECT BY, des colonnes définies par des
expressions ou des colonnes NOT NULL dans les tables qui ne sont pas sélectionnées par
la vue.
Considérons les célèbres tables d’Oracle employees et departments du schéma exemple

hr dont une partie des colonnes et des données est présentée.
Figure 4-2. Les tables exemples
La structure de ces tables est présentée dans le tableau suivant. Les colonnes NOT NULL
doivent être tout particulièrement considérées lors d’éventuelles mises à jour.

Tableau 4-2 : Description des tables sources
Table departments Table employees

SQL> desc hr.employees SQL> desc hr.departments
Name Null? Type Name Null? Type
--------------------- -------- ---------- -------------------- ---------- ----------
EMPLOYEE_ID NOT NULL NUMBER(6) DEPARTMENT_ID NOT NULL NUMBER(4)
FIRST_NAME VARCHAR2(20) DEPARTMENT_NAME NOT NULL VARCHAR2(30)
LAST_NAME NOT NULL VARCHAR2(25) MANAGER_ID NUMBER(6)
EMAIL NOT NULL VARCHAR2(25) LOCATION_ID NUMBER(4)
PHONE_NUMBER VARCHAR2(20)
HIRE_DATE NOT NULL DATE
JOB_ID NOT NULL VARCHAR2(10)
SALARY NUMBER(8,2)
COMMISSION_PCT NUMBER(2,2)
MANAGER_ID NUMBER(6)
DEPARTMENT_ID NUMBER(4)
En considérant ces tables sources, composons différentes vues.
Vues monotables
Le tableau suivant crée la vue monotable v_employes dans le schéma soutou. Cette vue
décrit les employés dont le salaire dépasse 10 000 (restriction du WHERE) et masquant certaines
colonnes (restriction du SELECT). Notez les alias de colonnes qui permettent de masquer le
nom des colonnes originales de la table source.
Tableau 4-3 : Création d’une vue monotable
Création de la vue Structure de la vue
CREATE VIEW soutou.v_employes SQL> desc soutou.v_employes;

(id_emp, prenom, nom, mail, Name Null? Type
date_embauche, id_emploi) ---------------------------- -------- ---------
AS SELECT employee_id, first_name, ID_EMP NOT NULL NUMBER(6)
last_name,email, PRENOM VARCHAR2(20)
hire_date, job_id NOM NOT NULL VARCHAR2(25)
FROM hr.employees MAIL NOT NULL VARCHAR2(25)
WHERE salary > 9000; DATE_EMBAUCHE NOT NULL DATE
ID_EMPLOI NOT NULL VARCHAR2(10)

Une fois créée, la vue s’interroge comme une table par un utilisateur, sous réserve de détenir
le privilège de lecture (GRANT SELECT ON nom_vue TO nom_schema). Le tableau suivant
présente deux extractions de cette vue.
Tableau 4-4 : Interrogation d’une vue
Besoin Requête et résultat

Employés de 2005 dont l’e-mail dépasse 5 caractères. SELECT id_emp, prenom, nom, mail, date_
embauche
FROM soutou.v_employes
WHERE EXTRACT (YEAR FROM date_embauche) =
2005
AND LENGTH(mail) > 5
ORDER BY 5;
ID_EMP PRENOM NOM MAIL DATE_EMBAUCHE

------- --------------- --------------- --------------- ----------------
146 Karen Partners KPARTNER 05-JAN-05
150 Peter Tucker PTUCKER 30-JAN-05
147 Alberto Errazuriz AERRAZUR 10-MAR-05
175 Alyssa Hutton AHUTTON 19-MAR-05
151 David Bernstein DBERNSTE 24-MAR-05
101 Neena Kochhar NKOCHHAR 21-SEP-05
162 Clara Vishney CVISHNEY 11-NOV-05
Nombre d’employés triés par type d’emploi. SELECT id_emploi, COUNT(id_emp)
FROM soutou.v_employes
GROUP BY id_emploi
ORDER BY 2 DESC;
ID_EMPLOI COUNT(ID_EMP)
----------- --------------
SA_REP 14
SA_MAN 5
AD_VP 2
MK_MAN 1
PR_REP 1
AD_PRES 1
PU_MAN 1
AC_ACCOUNT 1
AC_MGR 1
FI_MGR 1

Vues complexes
Une vue complexe est caractérisée par le fait qu’elle contient, dans sa définition, plusieurs
tables (jointures, sous-requêtes, expressions de tables : CTE), une fonction appliquée à
des regroupements, une fonction de fenêtrage, le mot-clé DISTINCT ou des expressions de
colonnes.
La mise à jour directe (par INSERT ou UPDATE ou DELETE) de telles vues n’est pas possible
sans programmer un déclencheur INSTEAD OF.
Le tableau suivant présente la vue multitable v_dept_calculs du schéma soutou qui extrait
pour chaque département, le nom du manager, le nombre d’employés, ainsi que les salaires
minimum, maximum et moyens.
Tableau 4-5 : Création d’une vue complexe
CREATE VIEW soutou.v_dept_calculs SQL> DESC soutou.v_dept_calculs;

(departement, manager, employes, Name Null? Type
min_sal, max_sal, moyenne_sal) ---------------------- --------- ------------
AS SELECT d.department_name, m.last_name, DEPARTEMENT NOT NULL VARCHAR2(30)
COUNT(e.department_id), MIN(e.salary), MANAGER NOT NULL VARCHAR2(25)
MAX(e.salary), ROUND(AVG(e.salary),1) EMPLOYES NUMBER

FROM hr.employees e, MIN_SAL NUMBER
hr.departments d, hr.employees m MAX_SAL NUMBER
WHERE e.department_id = d.department_id MOYENNE_SAL NUMBER
AND d.manager_id = m.employee_id

GROUP BY d.department_name, m.last_name
ORDER BY 1;
Conseil avisé
Il est toujours préférable de programmer une jointure à l’aide de l’opérateur relationnel
INNER JOIN plutôt que dans WHERE : d’une part, pour des raisons de performances (cer-
tains SGBD y sont sensibles), d’autre part, d’un point de vue de la maintenance du code
(il est plus efficace de modifier une requête ainsi écrite).
Une fois créée, la vue multitable s’interroge simplement (sans jointure). Le tableau suivant
présente une extraction de cette vue.

Tableau 4-6 : Interrogation d’une vue complexe
Besoin Requête et résultat

Nom des départements et du manager où la moyenne SELECT departement, manager,
des salaires dépasse 9 000 en affichant l’écart entre le (max_sal - min_sal) ecart_max,
plus haut et le plus bas salaire, en triant sur la moyenne moyenne_sal
des salaires. FROM soutou.v_dept_calculs
WHERE moyenne_sal > 9000
ORDER BY 4;;
DEPARTEMENT MANAGER ECART_MAX MOYENNE_SAL

------------------ ----------- ----------- -------------
Sales Russell 7290 9492.6
Marketing Hartstein 7700 10450
Public Relations Baer 0 11000
Accounting Higgins 4078.8 11169.4
Executive King 7000
19333.3
Il est possible de mettre à jour toutes les vues, soit directement, soit indirectement par
l’intermédiaire de déclencheurs INSTEAD OF (RULE et FUNCTION pour PostgreSQL).
Vues modifiables
Lorsqu’il est possible d’exécuter des instructions insert, update ou delete directement sur
une vue, elle est dite modifiable (updatable view). Pour mettre à jour une vue simple, il doit
exister une correspondance biunivoque entre les lignes de la vue et celles de l’objet source.
Pour pouvoir mettre à jour une vue complexe, il est nécessaire de programmer un déclen-
cheur de type INSTEAD OF.
Il va de soi qu’une vue créée avec la directive WITH READ ONLY ne peut être mise à jour quelle
que soit sa structure…
La première vue monotable (employés dont le salaire dépasse 10 000) citée en exemple est
modifiable sous réserve de renseigner les colonnes déclarées non nulles (la clé primaire en fait
partie). Ici, la condition de correspondance biunivoque est respectée.
En revanche, la deuxième vue multitable (employés, manager et détails sur les employés) ne
peut pas être mise à jour d’une manière directe, car d’une part, la clé primaire n’est pas pré-
sente, d’autre part, les résultats fournis proviennent de calculs d’agrégats et il serait insensé de
vouloir insérer un calcul directement.
Le tableau suivant présente quelques mises à jour possibles (sous réserve de respecter en amont
les contraintes de clés et de valeurs qui existent au niveau de la table source).

Tableau 4-7 : Mises à jour d’une vue
Opérations Résultat
INSERT INTO soutou.v_employes Ajout d’une ligne dans la table

(id_emp, prenom, nom, mail, date_embauche, id_emploi) employees du schéma hr.
VALUES (99,'Fred','Brouard','sqlpro',SYSDATE,'IT_PROG');
UPDATE soutou.v_employes Modification d’une colonne d’une ligne

SET mail = 'WIGIETZ' dans la table employees du schéma
hr.
WHERE id_emp = 206;
DELETE FROM soutou.v_employes Suppression de deux lignes dans la

WHERE id_emp IN (150,151); table employees du schéma hr.
La première instruction est un peu paradoxale, car elle permet l’ajout, en passant par la vue,
d’un employé qui ne repassera plus par la suite le filtre de la vue (l’information du salaire est
manquante et forme la condition de filtre de la vue).
La directive WITH CHECK OPTION, qui empêche un ajout ou une modification non conforme
à la définition de la vue, permet d’éviter ce genre d’effets de bord qui peuvent être indésirables
pour l’intégrité de la base.
Contrainte de vérification
Il est nécessaire de redéfinir la vue, le tableau suivant décrit cette action et la tentative d’ajout
d’un employé non doté de salaire.
Tableau 4-8 : Vue avec WITH CHECK OPTION
Création de la vue Insertion interdite
SQL> CREATE VIEW soutou.v_employes SQL> INSERT INTO soutou.v_employes

(id_emp, prenom, nom, mail, (id_emp, prenom, nom, mail,
date_embauche, id_emploi) date_embauche, id_emploi)
AS SELECT employee_id, first_name, VALUES (99, 'Fred', 'Brouard',
last_name, email, hire_date, job_id 'sqlpro', SYSDATE, 'IT_PROG');
FROM hr.employees ERROR at line 1:
WHERE salary > 9000 ORA-01402: view WITH CHECK OPTION where-
WITH CHECK OPTION; clause violation
View created.

Les règles qui régissent les insertions ne sont pas identiques à celles qui concernent les
mises à jour ou suppressions. Des vues complexes peuvent être modifiables, dans une cer-
taine mesure, lorsqu’une table source est dite protégée par sa clé (key preserved).
Tables protégées (key preserved tables)
Une table est dite protégée par sa clé (key preserved) si sa clé primaire est préservée dans
la clause de jointure et se retrouve en tant que colonne de la vue multitable (pouvant jouer le
rôle de clé primaire de la vue).
Considérons la vue complexe qui joint les tables des départements et des employés en incluant
toutes les colonnes non nulles. On pourrait penser que les deux tables sont protégées par clé et
sont modifiables par la vue.
Tableau 4-9 : Vue multitable
CREATE VIEW soutou.v_dept_emps SQL> DESC soutou.v_dept_emps;

(ndept,departement,id_emp,prenom, Name Null? Type
nom,mail,date_embauche,id_emploi) --------------------- --------- ---------
AS SELECT d.department_id, NDEPT NOT NULL NUMBER(4)
d.department_name, e.employee_id, DEPARTEMENT NOT NULL VARCHAR2(30)
e.first_name, e.last_name, ID_EMP NOT NULL NUMBER(6)
e.email, e.hire_date, e.job_id PRENOM VARCHAR2(20)
FROM hr.employees e, hr.departments d NOM NOT NULL VARCHAR2(25)
WHERE e.department_id = d.department_id MAIL NOT NULL VARCHAR2(25)
ORDER BY 2,4; DATE_EMBAUCHE NOT NULL DATE
ID_EMPLOI NOT NULL VARCHAR2(10)
En réalité, seule la table employees est protégée par clé dans cette vue, car elle joue le rôle de
la relation enfant tandis que la table departments joue le rôle de parent. En effet, toute ligne
de cette table contiendra un unique numéro d’employé, tandis que le numéro de département
est susceptible de se dupliquer.

Tableau 4-10 : Interrogation de la vue multitable
Contenu partiel de la vue
SQL> SELECT ndept, departement, id_emp, prenom, nom, date_embauche

FROM soutou.v_dept_emps;
NDEPT DEPARTEMENT ID_EMP PRENOM NOM DATE_EMBAUCHE

--------- ------------------ ---------- ---------------
--------------- -------------------
110 Accounting 205 Shelley Higgins 07-JUN-02
110 Accounting 206 William Gietz 07-JUN-02
10 Administration 200 Jennifer Whalen 17-SEP-03
90 Executive 102 Lex De Haan 13-JAN-01
90 Executive 101 Neena Kochhar 21-SEP-05
90 Executive 100 Steven King 17-JUN-03
100 Finance 109 Daniel Faviet 16-AUG-02
100 Finance 111 Ismael Sciarra 30-SEP-05
...
Avec Oracle, afin de savoir dans quelle mesure les colonnes d’une table sont modifiables par
une vue (insertion, modification ou suppression), il faut interroger le dictionnaire des données
par l’intermédiaire de la vue USER_UPDATABLE_COLUMNS.
L’interrogation suivante illustre ce mécanisme (UPPER convertit en majuscules une chaîne de

caractères, utile ici car le nom des objets d’Oracle est stocké en majuscules dans le dictionnaire
des données).
Tableau 4-11 : Caractéristiques des colonnes d’une vue
Requête Résultat
COLUMN_NAME INS UPD DEL

SELECT COLUMN_NAME, INSERTABLE, --------------------------- --- --- ---
UPDATABLE, DELETABLE DEPARTEMENT NO NO NO
FROM USER_UPDATABLE_COLUMNS ID_EMP YES YES YES
WHERE TABLE_NAME = UPPER('v_dept_emps'); PRENOM YES YES YES
NOM YES YES YES
MAIL YES YES YES
DATE_EMBAUCHE YES YES YES
NDEPT NO NO NO
ID_EMPLOI YES YES YES

Le tableau suivant présente quelques mises à jour valides (sous réserve de respecter en amont
les contraintes de clés et de valeurs qui existent au niveau de la table source).
Tableau 4-12 : Mises à jour de vue
Opérations Résultat
INSERT INTO soutou.v_dept_emps Ajout d’une ligne dans la table

(id_emp,prenom,nom,mail,date_embauche,id_emploi) employees du schéma hr.
VALUES (99,'Fred','Brouard','sqlpro',SYSDATE,'IT_PROG');
UPDATE soutou.v_dept_emps Modification d’une colonne d’une ligne

SET date_embauche = SYSDATE dans la table employees du schéma
WHERE id_emp = 206; hr.
DELETE FROM soutou.v_dept_emps Suppression de deux lignes dans la

WHERE id_emp IN (150,151); table employees du schéma hr.
La première instruction est encore un peu étrange, car elle permet l’ajout, en passant par la
vue, d’un employé qui ne repassera plus par la suite le filtre de la vue (l’information du dépar-
tement d’appartenance est manquante).
Critères de mises à jour
Les conditions qui régissent ces limitations sont les suivantes.

• Une vue multitable est modifiable (updatable join view ou modifiable join view) si la requête
de définition ne contient pas l’option WITH READ ONLY et la mise à jour (INSERT, UPDATE,
DELETE) n’affecte qu’une seule table.
• Seuls des enregistrements de la table protégée peuvent être insérés (si la clause WITH
CHECK OPTION est utilisée, aucune insertion ne sera possible).
• Seules les colonnes de la table protégée peuvent être modifiées.
• Seuls les enregistrements de la table protégée peuvent être supprimés.
Les vues peuvent également servir à assurer la confidentialité, simplifier l’écriture de requêtes
complexes, implémenter l’intégrité référentielle et dénormaliser.
Confidentialité
La confidentialité reste une des vocations premières des vues. En plus de renommer ou de
masquer des colonnes, il est possible de restreindre l’accès à des données d’une manière tem-
porelle. La vue suivante restreint les accès à une table d’un point de vue temporel.

Tableau 4-13 : Vue monotable restreinte dans le temps
Définition de la vue Résultat
CREATE VIEW soutou.v_employes_JO Restriction en lecture et écriture (du fait de la

(id_emp, prenom, nom, mail, directive WITH CHECK OPTION), sur la table
date_embauche, id_emploi, employees du schéma hr, des jours ouvrables
salaire, bonus, id_manager, n_dept) de 8 à 17 h.
AS SELECT employee_id, first_name,
last_name, email, hire_date,
job_id, salary, commission_pct,
manager_id, department_id
FROM hr.employees
WHERE TO_CHAR(SYSDATE,'D') BETWEEN 2 AND 6
AND TO_NUMBER(TO_CHAR(SYSDATE,'HH24'))
BETWEEN 8 AND 17
WITH CHECK OPTION;
Il est possible de restreindre davantage les accès à un utilisateur particulier en utilisant les
mécanismes de transmission ou de révocation de privilèges. Il est par ailleurs toujours préfé-
rable qu’un utilisateur transmette des droits sur ses données en utilisant des vues.
Les privilèges objet (en opposition aux privilèges système comme pouvoir démarrer la base,
créer un schéma, etc.) qu’il est possible d’attribuer sur une vue sont les mêmes que ceux qui sont
applicables sur une table (à savoir SELECT et UPDATE sur des colonnes, INSERT et DELETE).
Tableau 4-14 : Privilèges sur les vues
Attribution du privilège Signification
GRANT SELECT ON soutou.v_employes_JO Accès pour tous (sous réserve d’un jour ouvré…) en lecture
TO PUBLIC; sur la vue v_employes_JO du schéma soutou.
GRANT INSERT ON soutou.v_employes_JO Accès en écriture sur la vue v_employes_JO du schéma

TO celine; soutou à l’utilisateur celine.
GRANT UPDATE (mail,salaire) Modification possible de l’e-mail et du salaire sur la vue v_
ON soutou.v_employes_JO employes_JO du schéma soutou pour l’utilisateur paul.
TO paul;
Simplification de requêtes
Considérons la table jobs qui appartient aussi au schéma hr d’Oracle. Une partie des données
est présentée ci-après.

Figure 4-3. Table jobs
La requête à simplifier est celle qui doit extraire, pour chaque département, la masse salariale
médiane de chaque département en fonction des types d’emplois. Par exemple, le départe-
ment 90 est composé d’un employé de type AD_PRES et de deux employés de type AD_VP. Le
montant calculé pour ce département doit être égal à : 1 × (40 000 – 20 080) + 2 × (30 000
– 15 000) = 49 920.
Figure 4-4. Résultat attendu
Construisons les vues nécessaires pour simplifier cette requête. La première vue groupe les
effectifs de chaque département par type d’emploi.

Tableau 4-14 : Calcul des effectifs
Vue monotable Résultat
CREATE VIEW soutou.v_job_emps SQL> SELECT n_dept, id_emploi, effectif

(n_dept, id_emploi, effectif) FROM soutou.v_job_emps;
AS SELECT department_id, job_id,
COUNT(employee_id) N_DEPT ID_EMPLOI EFFECTIF

FROM hr.employees ---------- ---------- ------------

WHERE department_id IS NOT NULL 10 AD_ASST 1
GROUP BY department_id, job_id 20 MK_MAN 1

ORDER BY 1; 20 MK_REP 1
30 PU_CLERK 5
30 PU_MAN 1
40 HR_REP 1
50 SH_CLERK 20
50 ST_CLERK 20
50 ST_MAN 5
60 IT_PROG 5
70 PR_REP 1
80 SA_MAN 5
80 SA_REP 29
90 AD_PRES 1
90 AD_VP 2
100 FI_ACCOUNT 5
100 FI_MGR 1
110 AC_ACCOUNT 1
110 AC_MGR 1
La deuxième vue joint ces effectifs pour extraire le salaire médian de chaque type d’emploi. Il
s’agit ici d’une vue complexe interrogeant conjointement une table et une autre vue.
Tableau 4-15 : Jointure avec les salaires médians
Vue complexe d’une vue Résultat
CREATE VIEW soutou.v_v_job_emps SQL> SELECT n_dept, id_emploi, effectif, montant

(n_dept, id_emploi, effectif, montant) FROM soutou.v_v_job_emps;
AS SELECT v_j.n_dept, v_j.id_emploi,
effectif, N_DEPT ID_EMPLOI EFFECTIF MONTANT
(j.max_salary-j.min_salary) ---------- ---------- ----------- -----------

FROM soutou.v_job_emps v_j, hr.jobs j 10 AD_ASST 1 3000

WHERE v_j.id_emploi = j.job_id 20 MK_MAN 1 6000
ORDER BY 1; 20 MK_REP 1 5000

Vue complexe d’une vue (suite) Résultat (suite)
N_DEPT ID_EMPLOI EFFECTIF

MONTANT
---------- ---------- ------------ -----------

30 PU_CLERK 5 3000
30 PU_MAN 1 7000

40 HR_REP 1 5000

50 SH_CLERK 20 3000

50 ST_CLERK 20 2992
50 ST_MAN 5 3000
60 IT_PROG 5 6000

70 PR_REP 1 6000
80 SA_MAN 5 10080
80 SA_REP 29 6008
90 AD_PRES 1 19920
90 AD_VP 2 15000

100 FI_ACCOUNT 5 4800

100 FI_MGR 1 7800
110 AC_ACCOUNT 1 4800
110 AC_MGR 1 7800
La troisième vue cumule le salaire médian de chaque type d’emploi pour tout département.
Tableau 4-16 : Cumul par type d’emploi et département
CREATE VIEW soutou.v_v_v_emps_cumul SQL> SELECT n_dept, id_emploi, cumul

(n_dept, id_emploi, cumul) FROM soutou.v_v_v_emps_cumul;
AS SELECT n_dept, id_emploi,
SUM(effectif*montant) N_DEPT ID_EMPLOI CUMUL
FROM soutou.v_v_job_emps ---------- ----------- ----------

GROUP BY n_dept, id_emploi 10 AD_ASST 3000

ORDER BY 1,2; 20 MK_MAN 6000

20 MK_REP 5000
30 PU_CLERK 15000
30 PU_MAN 7000
40 HR_REP 5000
50 SH_CLERK 60000
50 ST_CLERK 59840
50 ST_MAN 15000
60 IT_PROG 30000
70 PR_REP 6000

 N_DEPT ID_EMPLOI CUMUL
 ---------- ------------ ---------
 
80 SA_MAN 50400
80 SA_REP  174232
90 AD_PRES 19920
 
90 AD_VP 30000
 
100 FI_ACCOUNT 24000

 
100 FI_MGR 7800  
110 AC_ACCOUNT 4800

110 AC_MGR 7800  
La requête finale cumule ces sommes pour chaque département. Aucune jointure n’intervient
et toute la complexité est masquée par les trois niveaux de vues en amont. Essayez d’écrire
cette requête sans utiliser de vues intermédiaires, vous m’en direz des nouvelles.
Tableau 4-17 : Requête simplifiée
Requête sur une vue Résultat
SELECT n_dept, SUM(cumul)  N_DEPT SUM(CUMUL)
FROM soutou.v_v_v_emps_cumul ---------- ----------

   
GROUP BY n_dept 10 3000

ORDER BY 1; 20 11000
30 22000
40 5000
50 134840
60 30000
70 6000
80 224632
90 49920
100 31800
110 12600
L’exemple le plus classique de simplification par les vues est la présentation de l’infor-
mation par tranches… Par exemple, l’évolution des taux de TVA est fonction d’une date
d’application, qui rend de fait caduque l’application du barème précédent à la date J-1…
CREATE TABLE T_TVA

(TVA_TYPE VARCHAR(32) NOT NULL,
TVA_DATE_APPLICATION DATE NOT NULL,

TVA_TAUX FLOAT)
INSERT INTO T_TVA VALUES
('Super Réduit', '1982-07-01', 5.50),
('Super Réduit', '1989-01-01', NULL),
('Réduit', '1968-01-01', 6.38),

('Réduit', '1968-12-01', 7.53),
('Réduit', '1970-01-01', 7.50),
('Réduit', '1973-01-01', 7.00),
('Réduit', '1989-01-01', 5.50),
('Intermédiaire', '1968-01-01', 14.92),
('Intermédiaire', '1968-12-01', 15.65),
('Intermédiaire', '1970-01-01', 17.60),
('Intermédiaire', '1982-07-01', NULL),
('Normal', '1968-01-01', 20.00),
('Normal', '1968-12-01', 23.46),
('Normal', '1970-01-01', 23.00),
('Normal', '1973-01-01', 20.00),
('Normal', '1977-01-01', 17.60),
('Normal', '1982-07-01', 18.60),
('Normal', '1995-08-01', 20.60),
('Normal', '2000-04-01', 19.60),
('Majoré', '1968-01-01', 25.00),

('Majoré', '1968-12-01', 33.33),
('Majoré', '1989-01-01', 28.00),
('Majoré', '1989-09-15', 25.00),
('Majoré', '1991-01-01', 22.00),
('Majoré', '1993-01-01', NULL);
CREATE VIEW V_TVA AS
SELECT TVA_TYPE, TVA_DATE_APPLICATION AS TVA_DATE_DEBUT_
APPLICATION,
COALESCE((SELECT MIN(TVA_DATE_APPLICATION) - 1 DAY
FROM T_TVA AS T2
WHERE T1.TVA_TYPE = T2.TVA_TYPE
AND T1.TVA_DATE_APPLICATION< T2.TVA_DATE_APPLICATION),
'9999-12-31')
AS TVA_DATE_FIN_APPLICATION, TVA_TAUX
FROM T_TVA AS T1;

Et voici les données présentées par cette vue.

TVA_TYPE TVA_DATE_DEBUT_APPLICATION TVA_DATE_FIN_APPLICATION TVA_TAUX
---------------- ---------------------------- --------------------------- --------
Super Réduit 1982-07-01 1988-12-31 5,5
Super Réduit 1989-01-01 9999-12-31 NULL
Réduit 1968-01-01 1968-11-30 6,38
Réduit 1968-12-01 1969-12-31 7,53
Réduit 1970-01-01 1972-12-31 7,5
Réduit 1973-01-01 1988-12-31 7
Réduit 1989-01-01 9999-12-31 5,5
Intermédiaire 1968-01-01 1968-11-30 14,92
Intermédiaire 1968-12-01 1969-12-31 15,65
Intermédiaire 1970-01-01 1982-06-30 17,6
Intermédiaire 1982-07-01 9999-12-31 NULL
Normal 1968-01-01 1968-11-30 20
Normal 1968-12-01 1969-12-31 23,46
...
Ce serait une énorme faute que de rajouter à la table une date de fin d’application, car en cas d’erreur de
saisie, on pourrait se retrouver soit avec plusieurs taux différents pour un même jour, soit aucun…
À noter : la présence d’une ligne avec un taux à NULL signifie tout simplement la disparition de ce taux
de TVA !
Contrôles d’intégrité référentielle

Une vue peut contrôler la validité des références entre tables. En l’absence du mécanisme de
clés étrangères, vous pouvez programmer l’intégrité référentielle (un autre moyen plus coûteux
est d’utiliser des déclencheurs).
La cohérence référentielle entre deux tables t1 (table « parent ») et t2 (table « enfant ») se

programme :
• du parent vers l’enfant par l’utilisation d’une vue v1 de la table t1 définie avec la clause NOT
EXISTS ;
• de l’enfant vers le parent par l’utilisation d’une vue v2 de la table t2 définie avec la clause
WITH CHECK OPTION.
Considérons la table des départements (renommée t1 et jouant le rôle de parent : CREATE

TABLE t1 AS SELECT * FROM hr.departments) et celle des employés (renommée t2
et jouant le rôle de l’enfant : CREATE TABLE t2 AS SELECT * FROM hr.employees).
Puisqu’il n’existe aucune clé étrangère entre ces tables, les vues à créer sont les suivantes.

Tableau 4-18 : Vues à créer
Code SQL Commentaire
CREATE VIEW v1 Vue pour assurer la cohérence du parent vers l’enfant.

AS SELECT * FROM t1 pere
WHERE NOT EXISTS
(SELECT employee_id
FROM t2
WHERE department_id=pere.department_id);
CREATE VIEW v2 Vue pour assurer la cohérence de l’enfant vers le parent.

AS SELECT * FROM t2
WHERE (department_id IN
(SELECT department_id FROM t1)
OR department_id IS NULL)
WITH CHECK OPTION;
La vue v2 restitue les départements qui n’embauchent aucun employé. La vue v1 restitue les
employés associés à un département existant et ceux qui ne sont associés à aucun département
(la condition IS NULL peut être omise dans la vue si chaque enfant doit être obligatoirement
rattaché à un parent).
Les règles que vous devez respecter pour manipuler les données sont les suivantes.
• Côté parent : modifications, insertions et suppressions par la vue v1 et lecture de la table t1.
• Côté enfant : modifications, insertions, suppressions et lecture par la vue v2.
Manipulons à présent les données de notre exemple par ces vues.
Tableau 4-19 : Manipulations des vues pour l’intégrité référentielle
Cohérence fils → père Cohérence père → fils

Insertion correcte : Toute insertion à travers la vue v1 est possible (sous
INSERT INTO v2 réserve de la validité du type des colonnes et de
(employee_id, first_name, last_name, email, l’existence d’autres contraintes référentielles).
hire_date, job_id,salary, commission_pct, Insertion correcte :
manager_id, department_id )
VALUES (99,'Fred','Brouard','sqlpro', INSERT INTO v1
SYSDATE,'IT_PROG',3400,0,100,90); (department_id, department_name,
manager_id, location_id)
VALUES (800,'Eyrolles info.', 100,1700);

Cohérence fils → père (suite) Cohérence père → fils (suite)

Insertion incorrecte (le département 999 est un parent
absent) :
INSERT INTO v2
(employee_id, first_name, last_name, email,
hire_date, job_id, salary, commission_pct,
manager_id, department_id )
VALUES (98,'Fred','Comby','bezier',
SYSDATE,'IT_PROG',5400,0,100,999);
Modification correcte : Modification correcte (le département 900 n’a aucun
UPDATE v2 employé) :
SET department_id = 10 UPDATE v1
SET department_id = 77
WHERE employee_id=99;
WHERE department_id = 900;
Modification incorrecte (parent absent) :

Modification incorrecte (enfant présent : le département
UPDATE v2
90 a des employés et le mécanisme de cascade n’est
SET department_id = 999 pas pris en compte) :
WHERE employee_id=99; UPDATE v1
SET department_id = 77
Toute suppression est possible à travers la vue v2 (sous Suppression correcte (enfants absents) :
réserve de l’existence d’autres contraintes référentielles). DELETE FROM v1
Suppression incorrecte (enfants présents) :

DELETE FROM v1
Le raisonnement sur deux tables peut se généraliser à une hiérarchie d’associations ou à diffé-
rentes associations issues de la même table.
Un avantage spectaculaire et peu connu des vues : les contraintes dynamiques

Dans une base de données, les contraintes sont statiques, c’est-à-dire qu’elles empê-
chent d’introduire des données qui ne respectent pas les règles. Mais comment faire pour
stocker quand même certaines données intermédiaires et ne présenter aux utilisateurs
que les ensembles de données valides ? La réponse est une vue… Imaginons un géomètre
qui doit stocker dans une table ses relevés de mesure de parcelles de terrain. Voici la
table :

CREATE TABLE T_PARCELLE_GEOMETRIE_PCG

(PCL_NUMERO_CADASTRAL VARCHAR(16) NOT NULL,
PCG_NUMERO_POINT INT NOT NULL,
PCG_LATITUDE FLOAT NOT NULL,
PCG_LONGITUDE FLOAT NOT NULL,
PCG_ALTITUDE FLOAT,
CONSTRAINT PK_PCG PRIMARY KEY (PCL_NUMERO_CADASTRAL,
PCG_NUMERO_POINT));
Chacun sait qu’une parcelle de terrain est un polygone et qu’un polygone se doit d’avoir
au moins 3 sommets. Tant que l’on n’a pas saisi 3 points, pas de polygone. Or, aucune
contrainte ne peut « attendre » l’arrivée du troisième point pour valider ou invalider les
données. Dans ce cas, la solution réside dans la vue :
CREATE VIEW V_PARCELLE_GEOMETRIE_PCG AS
SELECT * FROM T_PARCELLE_GEOMETRIE_PCG AS P1
WHERE EXISTS(SELECT 1
FROM T_PARCELLE_GEOMETRIE_PCG AS P1 AS P2
WHERE P1.PCL_NUMERO_CADASTRAL = P2.PCL_NUMERO_CADASTRAL
AND P1.PCG_NUMERO_POINT = P2.PCG_NUMERO_POINT
GROUP BY P2.PCG_NUMERO_CADASTRAL, P2.PCG_NUMERO_POINT
HAVING COUNT(*) >= 3);
Cette dernière ne fera apparaître que les données des points des parcelles pour celles
formant des polygones… Mais comme on ne sait pas à l’avance le nombre de points d’un
polygone, la manière la plus pratique est de rajouter cette information de « fermeture »
du polygone à un niveau supérieur :
CREATE TABLE T_PARCELLE_PCL
(PCL_NUMERO_CADASTRAL VARCHAR(16) NOT NULL PRIMARY KEY,
PCL_SAISIE_FINALISE BOOLEAN NOT NULL DEFAULT 0);
ALTER TABLE T_PARCELLE_GEOMETRIE_PCG

ADD CONSTRAINT FK_PCG_PCL
FOREIGN KEY (PCL_NUMERO_CADASTRAL)
REFERENCES T_PARCELLE_GEOMETRIE_PCG (PCL_NUMERO_CADASTRAL);

Dès lors, lorsque le géomètre a terminé sa saisie, il fait passer l’information PCL_
SAISIE_FINALISE à 'true' et le polygone représentant la parcelle devient visible à
travers la vue suivante :
CREATE VIEW V_PARCELLE_GEOMETRIE_PCG AS
SELECT * FROM T_PARCELLE_GEOMETRIE_PCG AS PCG
INNER JOIN T_PARCELLE_PCL AS PCL
ON PCL.PCL_NUMERO_CADASTRAL = PCG.PCL_NUMERO_CADASTRAL
WHERE PCL_SAISIE_FINALISE;
Un autre exemple concerne les clients et les prospects. Un prospect n’est autre qu’un
client qui n’a jamais effectué de commande. Dès lors, clients et prospects peuvent figurer
dans la même table physique (CONTACT) ce qui simplifie beaucoup les choses. Il n’y aura
qu’à créer deux vues modifiables, chacune d’elles avec toutes les colonnes de la table des
contacts, l’une présentant les données des prospects, l’autre celle des clients, avec les
définitions de vues suivantes :
CREATE VIEW V_CLIENT_CLI AS
SELECT * FROM T_CONTACT_CTC
WHERE CTC_ID IN (SELECT CTC_ID FROM T_COMMANDE_CMD);
CREATE VIEW V_PROSPECT_PSP AS

SELECT * FROM T_CONTACT_CTC
WHERE CTC_ID NOT IN (SELECT CTC_ID FROM T_COMMANDE_CMD);
Dénormalisation
Les vues peuvent aider à dénormaliser un schéma relationnel. Il est possible de créer volon-
tairement des résultats tabulaires qui ne respectent aucune des formes normales (de la 1re à
la 5e).
L’exemple suivant ne respecte pas la deuxième forme normale. En effet, la clé étant id_emp,
la présence de la colonne department (nom du département qui dépend davantage d’un code
département) fait abandonner la troisième forme normale.

Tableau 4-20 : Deuxième forme normale
Création de la vue Structure
CREATE VIEW soutou.v_dept_emps_pas3FN SQL> DESC soutou.v_dept_emps_pas3FN;

(id_emp,identite,date_embauche, Name Null? Type
ndept,departement) -------------------- --------- ---------
AS SELECT e.employee_id, ID_EMP NOT NULL NUMBER(6)
e.first_name||' '||e.last_name, IDENTITE VARCHAR2(46)
TO_CHAR(e.hire_date,'DD/MM/YYYY'), DATE_EMBAUCHE VARCHAR2(10)
d.department_id,d.department_name NDEPT NOT NULL NUMBER(4)
FROM hr.employees e, hr.departments d DEPARTEMENT NOT NULL VARCHAR2(30)
WHERE e.department_id = d.department_id
ORDER BY e.last_name;
SQL> SELECT id_emp, identite, date_embauche, ndept, departement

FROM soutou.v_dept_emps_pas3FN;
ID_EMP IDENTITE DATE_EMBAUCHE NDEPT DEPARTEMENT

---------- --------------------------- --------------- ----------- ------------------
174 Ellen Abel 11/05/2004 80 Sales
166 Sundar Ande 24/03/2008 80 Sales
130 Mozhe Atkinson 30/10/2005 50 Shipping
105 David Austin 25/06/2005 60 IT
204 Hermann Baer 07/06/2002 70 Public Relations
116 Shelli Baida 24/12/2005 30 Purchasing

167 Amit Banda 21/04/2008 80 Sales
172 Elizabeth Bates 24/03/2007 80 Sales
...
Pour quitter la virtualisation, si vous rendez cette vue physiquement existante (materialized
view), vous implémentez une dénormalisation.
Lorsque l’on parle de « modèle relationnel », ce n’est pas à un modèle particulier que
nous nous adressons, mais à l’ensemble des modèles nécessaires à la « fabrication » d’une
base de données. Ainsi, comme nous l’avons vu, ce fameux modèle relationnel se décline
en (dans l’ordre) MCD, MLD, MPD et MED. Piqûre de rappel…
Le modèle conceptuel de données est le premier des modèles relationnels qui doit être
établi. Il découle de l’analyse et permet de rendre compte de la sémantique des données.

Son formalisme a été élaboré par Peter Chen en 1976. Il compte des entités et des asso-
ciations. Ces objets peuvent être représentés par différentes notations comme la très
française MERISE, la plus moderne UML 2 ou encore IDF1X, ER, etc.
Le modèle logique de données est le deuxième des modèles et se trouve être la traduc-
tion mathématique du premier. Ce modèle, élaboré par Frank Edgar Codd dans les
années 1970, comporte des « relations » (c’est-à-dire des objets mathématiques porteurs
d’informations) constituées d’attributs dont certains, communs entre différentes rela-
tions, servent de liens. Il permet d’affiner le modèle conceptuel d’un point de vue logique,
mais pas physique.
Le modèle physique de données est le troisième des modèles et découle directement du
second dont il n’est que la traduction physique, c’est-à-dire sur une machine SQL. Ce
modèle a aussi été élaboré par Frank Edgar Codd, mais c’est Larry Ellison, alors tout
jeune entrepreneur, qui en fait la première implémentation sur un produit qu’il dénomme
Oracle V2 (version 2, la première n’ayant jamais existé). Selon que l’on utilise Oracle,
SQL Server, DB2 ou PostgreSQL, le modèle est légèrement différent, car il résulte de la
capacité à prendre en compte ou non tel ou tel type de données, telle ou telle contrainte…
Il est constitué de tables et de colonnes, mais aussi de contraintes et d’index.
Le modèle externe de données est le dernier des modèles relationnels. Souvent oublié, il
permet de présenter les informations d’une manière lisible, simplifiée et enrichie de façon
à faciliter le travail des développeurs et à rendre évidente la compréhension des données
par les utilisateurs. Il est constitué de vues et de routines SQL : procédures, déclencheurs,
fonctions. À nouveau, il a été élaboré par Franck Edgar Codd, dans les années 1980, au
tout début des premières expériences sur les SGBDR commerciaux que sont Sytème R
et Oracle. Son but est de rendre indépendante la structure physique de la base, de celle
perçue au niveau du développement, afin que des modifications apportées aux tables n’en-
traînent que peu d’effets sur le code applicatif.
Bien que les développeurs ne pensent jamais à utiliser proprement le modèle externe de
données, ils en utilisent généralement une partie, celle consacrée aux routines, à force
de constater que les performances du code de traitement d’un SGBDR sont sans com-
mune mesure avec celles qu’ils peuvent obtenir d’un traitement itératif dans un langage
hôte, dès que la montée en charge se fait sentir (accroissement du volume des données
ou de la concurrence…). Il est alors dommage de constater l’absence de vues, qui leur
auraient grandement facilité le travail, surtout en termes d’évolution de la structure de
la base…
De même, l’utilisation inconsidérée des ORM (Hibernate, Symfony, Doctrine…) n’est
qu’un pis-aller de substitution au MED et possède l’inconvénient majeur de dégrader
singulièrement les performances applicatives. En effet, il n’est pas rare qu’un ORM
multiplie par 10 ou 20 les temps de réponse par rapport à une approche procédurale
en SQL.

Les vues matérialisées

Les vues (dématérialisées) précédemment étudiées offrent bon nombre de fonctionnalités
(notamment de simplification d’écriture de requêtes complexes), mais ne garantissent rien en
regard des performances. Dans le pire des cas, une vue peut être consommatrice de ressources
si d’autres vues sont impliquées en cascade dans la requête.
Les vues matérialisées (materialized views, anciennement appelées snapshots avec Oracle)
sont formées à partir de requêtes dont le résultat est physiquement stocké (comme les lignes
d’une table).
La requête de définition d’une vue matérialisée peut interroger des tables, des vues et des vues
matérialisées. Dans un contexte de réplication, une vue matérialisée s’appelle master table.
Dans un contexte de data warehouse, une vue matérialisée est nommée detail table.
Figure 4-5. Vues matérialisées © Documentation Oracle
Les vues matérialisées contribuent à l’amélioration des jointures du fait du stockage de lignes
précalculées et de la possibilité de réécriture de requêtes (query rewrite). De plus, il est pos-
sible d’utiliser le partitionnement et l’indexation sur une vue matérialisée.
Réécriture de requêtes
La réécriture de requêtes est une technique d’optimisation qui transforme une requête complexe
émise sur une table volumineuse en une requête sémantiquement équivalente interrogeant la vue
matérialisée. Dès qu’il est plus intéressant d’utiliser la vue matérialisée parce qu’elle contient des
résultats déjà calculés (agrégats et jointures), toute requête est réécrite par le moteur relationnel

du SGBDR d’une manière transparente pour l’utilisateur et utilise la vue à la place de la table
(initialement interrogée). Aucun code n’est à ajouter dans l’instruction SQL qui ne référence que
la ou les tables interrogées, la substitution se faisant à la volée à l’exécution de la requête.
Figure 4-6. Réécriture de requêtes
En général, les vues matérialisées sont basées sur la clé primaire des tables sources (ou sur la
colonne rowid). Dans un contexte d’entrepôts de données, les vues matérialisées composent
généralement des regroupements (agrégations) et des jointures.
Du fait du stockage de données redondantes (lignes présentes physiquement à la fois dans les
tables sources et dans la vue matérialisée), des méthodes de rafraîchissement (refresh) sont dis-
ponibles et peuvent être de nature incrémentale (fast refresh) ou complète (complete refresh).
Les vues matérialisées (vues indexées chez MS SQL Server) se basent le plus souvent sur
la clé primaire ou sur un identifiant interne de ligne (rowid pour Oracle) de manière à
connaître la provenance des données.
La mise à jour d’une vue peut être synchrone ou asynchrone. Dans le cas d’une mise à
jour synchrone, la vue et les tables sous-jacentes doivent avoir une relation univoque de
manière à savoir quelle ligne est à modifier dans la vue du fait des changements dans les
tables sources. En effet, la modification des données de la vue se fait par différence et
non par recalcul afin de minimiser l’impact des mises à jour dans les tables sources. Pour
les vues asynchrones, on peut généralement choisir la méthode de rafraîchissement des
données de la vue comme sa fréquence. Oracle supporte les vues asynchrones, MS SQL
Server ne propose pour l’heure que des vues synchrones.
Création d’une vue matérialisée

Utilisons une vue matérialisée pour préparer les extractions des employés appartenant aux
départements situés à l’emplacement de numéro 1700.

Tableau 4-21 : Création d’une vue matérialisée

CREATE MATERIALIZED VIEW soutou.v_mat_emps_lieu_1700 Création de la vue matérialisée située dans
(ndept,departement,id_emp,prenom,nom,mail, l’espace logique users.
date_embauche,id_emploi,salaire,id_chef)
TABLESPACE users
BUILD IMMEDIATE La construction est immédiate et la vue est
REFRESH COMPLETE éligible à la réécriture de requête (ENABLE
ENABLE QUERY REWRITE QUERY REWRITE).
AS SELECT d.department_id, d.department_name,
e.employee_id, e.first_name, e.last_name,
e.email, e.hire_date, e.job_id, e.salary,
e.manager_id
FROM hr.employees e, hr.departments d
WHERE e.department_id = d.department_id
AND d.location_id = 1700
ORDER BY 2,5;
Le rafraîchissement complet se produit à la création de la vue matérialisée (définie avec BUILD

IMMEDIATE). Bien que ce procédé puisse être coûteux si les volumes de données manipulés sont
importants, les requêtes interrogeant ces tables ultérieurement seront bien plus performantes.
Figure 4-7. Vue matérialisée obtenue

Les jointures entre employés et départements de ce lieu utiliseront la vue à la place des tables
d’une manière bien plus efficace. Pour les besoins d’une requête en particulier, des index
uniques ou non peuvent s’ajouter : CREATE INDEX … ON nom_vue (colonne1,colonne2…).
Un pari d’un million de dollars

En novembre 1998, Larry Ellison, le P.-D.G. d’Oracle (alors à la version 8i), lance un
défi à Microsoft formulé de la manière suivante : « Si vous arrivez à rendre SQL Server 7
100 fois plus rapide qu’Oracle, je vous donne un million de dollars… » Le test porte sur
un benchmark de l’organisme indépendant TPC (http://www.tpc.org/) et en particulier
sur la requête n° 5 du TPC-C.
Quelques mois plus tard, Microsoft présente sa solution, mais Larry Ellison, mauvais
joueur, sentant le vent tourner, a décidé de clore son pari de façon anticipée, s’écono-
misant ainsi son million… La solution de Microsoft était construite autour des vues
matérialisées !
http://findarticles.com/p/articles/mi_m0FOX/is_8_4/ai_54409926/
http://tutorials.beginners.co.uk/professional-sql-server-2000-programming-part-6-in-
dexed-materialized-views.htm
Le rafraîchissement
Le rafraîchissement incrémental évite de reconstruire la vue matérialisée entièrement. Cepen-
dant, ce mécanisme doit s’opérer relativement rapidement (à la demande ou périodiquement)
pour garantir l’intégrité des données. Chaque table est associée à un journal d’opérations
(materialized view log) qui recense toutes les modifications effectuées sur la table.
Dans un contexte de réplication, les vues matérialisées permettent de maintenir sur une base
locale des copies de données distantes. Ces copies peuvent être modifiables (sous réserve que
le SGBD le permette, avec Oracle il s’agit de l’option Advanced Replication).
Le rafraîchissement automatique nécessite de créer un journal d’opérations par table interrogée.
Les exemples suivants décrivent des vues matérialisées qui se mettront à jour automatique-
ment. La première vue (tous les employés) sera mise à jour dès que la table employees sera
modifiée. La deuxième (tous les départements) sera systématiquement actualisée tous les
lundis à 15 h.
Tableau 4-22 : Rafraîchissement automatique
CREATE MATERIALIZED VIEW LOG ON hr.employees Création du journal des opérations.

WITH PRIMARY KEY, ROWID;

Code SQL (suite) Commentaire (suite)
CREATE MATERIALIZED VIEW soutou.v_mat_employes Création de la vue matérialisée des employés

REFRESH FAST ON COMMIT avec une contrainte primary key (colonne clé
WITH PRIMARY KEY primaire de la table).
AS SELECT Rafraîchissement incrémental (fast) après
modifications sur la table.
employee_id, first_name, last_name,
email, hire_date, job_id,
salary, commission_pct, manager_id,
department_id
FROM hr.employees e;
CREATE MATERIALIZED VIEW LOG ON hr.departments d Création du journal des opérations qui sera vidé
WITH PRIMARY KEY, ROWID tous les 5 jours.
PURGE REPEAT INTERVAL '5' DAY;
CREATE MATERIALIZED VIEW soutou.v_mat_ Création de la vue matérialisée des départements

departements avec une contrainte primary key (colonne clé
REFRESH FAST primaire de la table).
START WITH ROUND(SYSDATE + 1) + 11/24 Rafraîchissement incrémental, première
NEXT NEXT_DAY(TRUNC(SYSDATE),'LUNDI') + 15/24 actualisation : le lendemain à 11 h puis tous les
lundis à 15 h.
WITH PRIMARY KEY
AS SELECT department_id, department_name,
manager_id, location_id
FROM hr.departments;
Les vues indexées ou matérialisées ne sont pas la panacée et doivent être abordées avec
circonspection…
Tout d’abord, la vue doit être déterministe, c’est-à-dire toujours fournir les mêmes résul-
tats si les tables sources ont les mêmes données, ce qui exclut l’appel à des fonctions
comme celles fournissant la date et l’heure courantes ou encore celles renvoyant des
données aléatoires (RAND, GUID ou UUID…).
Il existe de nombreuses restrictions à l’écriture de vues synchrones. Comme les lignes
originelles doivent pourvoir être retrouvées, cela exclut certains opérateurs d’agréga-
tion autres que SUM , COUNT, MAX et MIN , les jointures externes, les sous-requêtes, les
valeurs non définies (NULL), les opérations ensemblistes (UNION , INTERSECT, EXCEPT),
l’opérateur DISTINCT, les fonctions de fenêtrage, les groupages OLAP (CUBE , ROLLUP,
GROUPING) et presque tous les opérateurs particuliers spécifiques à certains SGBDR.
Lorsque la vue contient des calculs mathématiques, il est important (mais pas impératif)
que les expressions intègrent des calculs précis, c’est-à-dire effectués sur des types SQL à
précision fixe, définie et limitée. On devra alors utiliser du DECIMAL (ou NUMERIC) ou des
entiers (SMALLINT, INT, BIGINT). En effet, l’emploi d’un type de données numériques à

précision flottante comme REAL ou FLOAT, induirait fatalement des erreurs de calcul du
fait que les données sont mises à jour par différence et non par recalcul (erreurs d’écart
d’arrondi).
Bien que les vues indexées ou matérialisées soient d’une puissance phénoménale
lorsqu’elles sont judicieusement utilisées, il ne faut pas les systématiser. En effet, le but
d’une telle vue n’est pas de fournir l’exacte réponse à une requête, mais de participer à la
simplification d’une partie de la requête finale…
Ainsi, il ne faut pas chercher à créer autant de vues indexées qu’il y a de requêtes
« lourdes », mais trouver quels sont les dénominateurs communs de ces lourdes requêtes
et factoriser le point dur par une vue matérialisée.
En effet, et comme toujours dans les bases de données, l’excès d’utilisation d’un système,
même très alléchant, peut conduire à l’effet inverse, car n’oublions pas que de telles vues
stockant les données constituent de la redondance, plombent le volume global de la base,
et plus encore, encombrent le cache des données…
Les vues objet (SQL3)

Présente avec Oracle et IBM DB2, une vue objet (object view) est une vue relationnelle étendue.
Les vues objet permettent de construire dynamiquement des objets analogues aux structures
C, classes C++ ou Java. Ce procédé bénéficie de la technologie du cache objet côté client et
réduit ainsi le trafic réseau (données extraites et modifiées) entre la base et le programme d’ap-
plication. Il est possible de définir une vue objet à partir de tables (elles-mêmes relationnelles
ou objet) ou de vues (relationnelles, objet ou matérialisées).
Figure 4-8. Vues objet

Les vues objet de tables relationnelles permettent de conserver les données telles quelles, sans
modifier structurellement la base. Ce mécanisme est intéressant, car il permettra aux pro-
grammeurs de migrer sans effet de bord vers la technologie objet. Par la suite, des méthodes
peuvent être programmées. Ces méthodes peuvent coder des transactions tout en manipulant
des données tabulaires.
Décrivons les mécanismes qu’Oracle propose.
Étapes à respecter
Plusieurs étapes sont nécessaires à la définition d’une vue objet.
●● Utiliser un type (existant ou à créer) qui formera la structure de la vue. Ce type peut inclure
des colonnes composées, références, collections ou méthodes.

●● Écrire la requête de définition qui extrait les données et charge la vue d’objets.
●● Spécifier un identifiant (OID), valeur unique basée sur un attribut clé primaire en général.
Cet identifiant permettra de créer une référence vers chaque objet de la vue (comme pour
les tables objet qui peuvent être accessibles par références).
●● Si la vue doit être modifiable (updatable object view), il faudra programmer un déclencheur
INSTEAD OF.
La syntaxe simplifiée de création d’une vue SQL3 est la suivante.
CREATE VIEW [nom_schéma.]nom_vue
[ (alias1, alias2… ) ]
OF [schéma.]nom_type
{ WITH OBJECT IDENTIFIER { DEFAULT | ( colonne [, colonne]...) }
| UNDER [nom_schéma.]nom_super_vue }
AS requête_SELECT
[WITH { READ ONLY | CHECK OPTION } ];
●● OF nom_type précise le nom du type qui forme la structure de la vue.
●● WITH OBJECT IDENTIFIER précise la clé primaire de la table source.
●● UNDER spécifie l’héritage de vue.
●● requête_SELECT requête de définition interrogeant une ou plusieurs tables ou vues.
●● WITH READ ONLY et WITH CHECK OPTION ont la même signification que les vues SQL2.
Étudions la construction et la manipulation d’une vue objet à partir des tables relationnelles
employees et departments. Suivons les étapes énoncées précédemment.
Vue contenant une collection

Définissons la vue v_obj_dep_emps qui caractérise l’association entre les tables employees
et departments. En disposant la collection emps_nt dans la vue des départements, on peut

associer plusieurs employés à tout département. Si le nombre d’employés est limité, on choisira
de travailler avec un varray, sinon il faudra utiliser une nested table.
Figure 4-9. Vue contenant une collection
En construisant des résultats tabulaires incluant des collections, vous dénormalisez en deçà
de la première forme normale.
Trois types sont nécessaires pour composer la structure de la vue : celui de l’élément de la
collection, celui de la collection elle-même et celui du type de la vue qui contient la collection.
Tableau 4-23 : Types à créer
Création des types Commentaire
CREATE TYPE elt_emp_t AS OBJECT Type de l’élément de la collection.

(id_emp NUMBER(6), prenom VARCHAR(20),
nom VARCHAR(25), date_embauche DATE)
/
CREATE TYPE emp_nt_t AS TABLE OF elt_emp_t Type de la collection NESTED TABLE.

/
CREATE TYPE departement_t AS OBJECT Type de la vue.

(n_dept NUMBER(4), nom_dept VARCHAR(30),
id_manager NUMBER(6), lieu NUMBER(4),
emps_nt emp_nt_t)
/

Il est possible de construire dynamiquement des collections (NESTED TABLE ou VARRAY) lors
de la création d’une vue objet à l’aide des directives CAST et MULTISET. La directive cast
convertit un résultat dans un type (ici, la requête crée une collection qui est nommée). Si le
résultat d’une requête retourne plusieurs enregistrements, il est nécessaire d’utiliser conjointe-
ment la directive multiset.
La définition de la vue inclut la spécification de l’OID basé sur la clé primaire de la table source
(colonne department_id). La requête extrait, dans un premier temps, quatre colonnes de
la table departments. Par la suite, pour chaque enregistrement de la table employees, la
directive MULTISET construit un ensemble d’éléments composé de plusieurs colonnes de la
table enfant. La directive CAST nomme l’ensemble obtenu emps_nt, collection affectée à la
dernière colonne du type de la vue.
Tableau 4-24 : Création de la vue objet
CREATE VIEW v_obj_dept_emps OF SQL> DESC v_obj_dept_emps

departement_t Name Null? Type
WITH OBJECT IDENTIFIER(n_dept) ----------------------- -------- ------------
AS SELECT d.department_id, N_DEPT NUMBER(4)
d.department_name, NOM_DEPT VARCHAR2(30)
d.manager_id, d.location_id, ID_MANAGER NUMBER(6)
CAST(MULTISET LIEU NUMBER(4)
(SELECT e.employee_id, e.first_name, EMPS_NT EMP_NT_T
e.last_name, e.hire_date
FROM hr.employees e
WHERE e.department_id=d.department_id)
AS emp_nt_t
) AS emps_nt
FROM hr.departments d;
Il est possible à présent de bénéficier de la jointure implicite offerte par la collection. La

requête suivante affiche la totalité de la vue.

Figure 4-10. Interrogation de la vue
Oracle dispose de nombreux opérateurs qui permettent de manipuler des collections au sein
de requêtes (CARDINALITY, MULTISET EXCEPT, MULTISET INTERSECTION, MULTISET
UNION, etc.).
Rendre une vue modifiable

Comme les vues relationnelles, les vues objet ne sont pas toutes modifiables. Par ailleurs, toute
mise à jour est possible sous réserve de préserver les contraintes de colonnes des tables sources
(non nullité, domaine de valeurs et intégrité référentielle).
La vue de notre exemple est modifiable au premier niveau de son corps (excepté la collection),
car il existe une correspondance directe avec les colonnes de la table source. Le tableau suivant
décrit quelques mises à jour, à travers la vue, qu’il est possible de programmer directement.
Tableau 4-25 : Mises à jour de la vue
Mises à jour Commentaire
INSERT INTO v_obj_dept_emps Insertion d’un nouveau département en initialisant la

(n_dept,nom_dept,id_manager,lieu) collection associée emps_nt à NULL.
VALUES (77,'Eyrolles production', 200, 1800);
UPDATE v_obj_dept_emps Modification du lieu du département 30.

SET lieu = 2400
WHERE n_dept = 30;
DELETE FROM v_obj_dept_emps Suppression du département 77 (sous réserve des

WHERE n_dept = 77; contraintes référentielles existantes).

Pour toute mise à jour qu’il n’est pas possible d’écrire directement, vous devrez programmer
un déclencheur INSTEAD OF qui se chargera de propager les nouvelles valeurs des colonnes
modifiées de manière cohérente à travers les tables sources.
Programmer des méthodes

L’avantage de disposer de types est de pouvoir déclarer et implémenter des méthodes afin
d’encapsuler tout traitement ou instruction complexe.
Tableau 4-26 : Programmation de méthodes
ALTER TYPE departement_t Déclaration de deux nouvelles méthodes : une

ADD MEMBER FUNCTION nbre_emp RETURN NUMBER; fonction qui comptera le nombre d’employés d’un
département et une procédure qui ajoute un employé
à un département.
ALTER TYPE departement_t
ADD MEMBER PROCEDURE
ajoute_emp(id IN NUMBER, pr IN VARCHAR,
no IN VARCHAR, da IN DATE);
CREATE OR REPLACE TYPE BODY departement_t AS Codage des deux méthodes. Le mot-clé SELF
MEMBER FUNCTION nbre_emp RETURN NUMBER IS désigne l’objet qui appelle la méthode.
total NUMBER := 0;
BEGIN
SELECT COUNT(id_emp) INTO total
FROM TABLE
(SELECT emps_nt FROM v_obj_dept_emps
WHERE n_dept=SELF.n_dept);
RETURN total;
END nbre_emp;
MEMBER PROCEDURE ajoute_emp(id IN NUMBER,
pr IN VARCHAR, no IN VARCHAR, da IN DATE)
IS
BEGIN
INSERT INTO hr.employees
(employee_id,first_name,last_name,email,
phone_number, hire_date,job_id,salary,
commission_pct,manager_id,department_id)
VALUES (id,pr,no,'mail',NULL,da,'IT_PROG',
NULL,NULL,NULL,SELF.n_dept);
COMMIT;
END ajoute_emp;
END;

Code SQL (suite) Commentaire (suite)
DECLARE Appel des deux méthodes dans un bloc anonyme. Le

obj departement_t; résultat est le suivant :
BEGIN
Employe ajoute
SELECT VALUE(d) INTO obj
Effectif pour 20 = 3
FROM v_obj_dept_emps d
WHERE d.n_dept = 20;
obj.ajoute_emp(99,'Fred','Brouard',SYSDATE);
DBMS_OUTPUT.PUT_LINE('Employe ajoute');
DBMS_OUTPUT.PUT_LINE('Effectif pour ' ||
obj.n_dept || ' = ' || obj.nbre_emp());
END;
Une fois les mises à jour opérées, les nouvelles données sont visibles dans les tables sources
ou par l’intermédiaire de la vue.
Figure 4-11. Interrogation de la vue
Une méthode peut implémenter une transaction, car tous les mécanismes du langage procé-
dural du SGBD sont disponibles (validation, invalidation, points de sauvegarde, curseurs et
exceptions).

Les déclencheurs INSTEAD OF

Un déclencheur instead of permet de mettre à jour une vue qui ne peut pas être modi-
fiée directement par INSERT, UPDATE ou DELETE. L’expression instead of est explicite : le
déclencheur programmera des actions au lieu d’insérer, de modifier ou de supprimer dans
une vue.
Ce mécanisme peut être particulièrement intéressant dans un contexte de bases de données
réparties où une action sur la base doit être dupliquée via le réseau (database links).
Les déclencheurs INSTEAD OF sont des déclencheurs ligne (option for each row), ils ne
s’appliquent qu’aux vues relationnelles ou objet et ne font pas intervenir les directives BEFORE
et AFTER au niveau de l’événement déclencheur. La syntaxe simplifiée d’un déclencheur INS-
TEAD OF.
CREATE TRIGGER nom_declencheur

INSTEAD OF { UPDATE [OR INSERT] [OR DELETE] } ON nom_vue
[ REFERENCING NEW AS v1 OLD AS v2 ]
FOR EACH ROW
DECLARE
…
BEGIN
…
END;
L’option de contrôle (WITH CHECK option) d’une vue n’est pas vérifiée si un déclencheur
INSTEAD OF est programmé sur l’événement en question (ajout, modification ou suppres-
sion). Le corps du déclencheur doit donc explicitement prendre en compte la contrainte.
À l’instar des déclencheurs traditionnels, il n’est permis de programmer qu’un seul déclen-
cheur INSTEAD OF par table.
Considérons les vues relationnelles créées dans le premier paragraphe et qu’il n’était pas pos-
sible de mettre à jour.
Mise à jour d’une vue complexe

La vue suivante présente plusieurs obstacles à sa mise à jour directe : sa requête de définition
contient des fonctions d’agrégat et elle ne contient pas la clé primaire qu’elle filtre.

Tableau 4-27 : Vue complexe
Structure de la vue Contenu partiel
SQL> DESC soutou.v_dept_calculs; SQL> SELECT departement,manager,employes,moyenne_sal

Name Null? Type FROM soutou.v_dept_calculs;
------------------ --------- ------------
DEPARTEMENT NOT NULL VARCHAR2(30) DEPARTEMENT MANAGER EMPLOYES MOYENNE_SAL
MANAGER NOT NULL VARCHAR2(25) ---------------- ------------ --------- ------------
EMPLOYES NUMBER Accounting Higgins 2 11169.4
MIN_SAL NUMBER Administration Whalen 1 4840
MAX_SAL NUMBER Executive King 3 19333.3

MOYENNE_SAL NUMBER Finance Greenberg 6 8601.3
Human Resources Mavris 1 7150

IT Hunold 5 5760
Marketing Hartstein 3 10450
Public Relations Baer 1 11000
Purchasing Raphaely 6 4150
Sales Russell 34 9492.6
Shipping Fripp 45
3618.4
Permettons à cette vue des insertions et modifications (il s’agit de mettre à jour la table
departments). En modification, seuls le nom du département et celui du manager pour-
ront être modifiés. Le déclencheur INSTEAD OF devra se charger de rechercher le code du
manager.
Tableau 4-28 : Déclencheur INSTEAD OF pour la modification
Code du déclencheur Commentaire
CREATE TRIGGER trg_update_v_dept_calculs Création du déclencheur et

INSTEAD OF UPDATE ON v_dept_calculs description de l’événement
déclencheur.
FOR EACH ROW
DECLARE
id_dept NUMBER(4);
id_mgr NUMBER(6);
BEGIN
SELECT department_id INTO id_dept Mémorisation du numéro de

FROM hr.departments département modifié.
WHERE UPPER(department_name)=UPPER(:OLD.departement);

Code du déclencheur (suite) Commentaire (suite)
IF NOT (:OLD.manager = :NEW.manager) THEN Modification du manager :

SELECT employee_id INTO id_mgr recherche du numéro et
modification de la table.
FROM hr.employees
WHERE UPPER(last_name)=UPPER(:NEW.manager);
UPDATE hr.departments SET manager_id = id_mgr
WHERE department_id = id_dept;
END IF;
IF NOT (:OLD.departement = :NEW.departement) THEN Modification du nom du

UPDATE hr.departments département : modification de la
table.
SET department_name = :NEW.departement
WHERE department_id = id_dept;
END IF;
EXCEPTION Exception à traiter si le nouveau

WHEN NO_DATA_FOUND THEN manager n’est pas référencé.
id_mgr := NULL;
END;
Le scénario suivant illustre deux modifications de la vue qui conduisent à mettre à jour la table
(la vue aussi par conséquent).
Tableau 4-29 : Modification d’une vue complexe
SQL> UPDATE soutou.v_dept_calculs L’employé de nom 'Partners' remplace 'Russell' pour le

SET manager = 'Partners' département 'Sales'.
WHERE departement='Sales'; 1 row updated.
SQL> UPDATE soutou.v_dept_calculs Le département 'Sales' est renommé en 'Ventes'.

SET departement='Ventes'
WHERE departement='Sales'; 1 row updated.
SQL> SELECT * DEPARTMENT_ID DEPARTMENT_NAME MANAGER_ID LOCATION_ID

FROM hr.departments -------------- ---------------- ----------- -------------
WHERE department_name='Ventes'; 80 Ventes 146 2500
SELECT departement,manager, DEPARTEMENT MANAGER EMPLOYES MOYENNE_SAL

employes,moyenne_sal ------------ ----------- ---------- -------------
FROM soutou.v_dept_calculs Ventes Partners 34 9492.6
WHERE departement='Ventes';

En insertion, le déclencheur INSTEAD OF devra se charger d’affecter une valeur (unique) à la

clé primaire, de rechercher le code du manager et d’affecter NULL à la colonne manquante de
la vue (location_id).
Tableau 4-30 : Déclencheur INSTEAD OF pour l’insertion
CREATE TRIGGER trg_insert_v_dept_calculs Création du déclencheur et

description de l’événement
INSTEAD OF INSERT ON v_dept_calculs
déclencheur.
FOR EACH ROW
DECLARE
id_dept NUMBER(4);
id_mgr NUMBER(6);
BEGIN
SELECT MAX(department_id)+ABS(MOD(DBMS_RANDOM.RANDOM,100)) Génération du numéro du nouveau

département.
INTO id_dept FROM hr.departments;
SELECT employee_id INTO id_mgr Recherche du numéro du manager.

FROM hr.employees
WHERE UPPER(last_name)=UPPER(:NEW.manager);
INSERT INTO hr.departments Insertion du nouveau département.

(department_id,department_name,manager_id,location_id)
VALUES (id_dept,:NEW.departement,id_mgr,NULL);
EXCEPTION Exception à traiter si le nouveau

manager n’est pas référencé.
id_mgr := NULL;
END;
Le scénario suivant décrit une insertion dans la vue qui met à jour la table. Les nouvelles
données n’apparaissent pas dans initialement la vue, car le département est pour l’instant non
pourvu d’employés.

Tableau 4-31 : Insertion d’une vue complexe
SQL> INSERT INTO v_dept_calculs Le nouveau département Eyrolles Prod. est dirigé par l’employé
(departement,manager) Austin (numéro 105).
VALUES ('Eyrolles Prod.',
'Austin');
1 row created.
SQL> SELECT * DEPARTMENT_ID DEPARTMENT_NAME MANAGER_ID LOCATION_ID

FROM hr.departments -------------- ------------------ ------------ ------------
WHERE department_name= 283 Eyrolles Prod.
105
'Eyrolles Prod.';
Mise à jour d’une vue multitable

La jointure de la vue v_dept_emps présente un obstacle à sa mise à jour directe. De ce fait,
seules les données de la table préservée par clé sont modifiables (ici, employees).
Figure 4-12. Contenu partiel de la vue multitable
Pour modifier cette vue en insertion, le déclencheur INSTEAD OF doit insérer des informa-
tions simultanément dans les tables sources employees et departments. Si le département
existe déjà, il ne faut pas le recréer. Le salaire de l’employé doit être estimé puisqu’il n’est pas
présent dans la vue (on prend le salaire moyen pour le type d’emploi concerné).

Tableau 4-32 : Déclencheur INSTEAD OF pour l’insertion d’une vue multitable
CREATE TRIGGER trg_insert_v_dept_emps Création du déclencheur et description de

INSTEAD OF INSERT ON v_dept_emps l’événement déclencheur.
FOR EACH ROW

DECLARE
nb_dept NUMBER(1);
v_salaire NUMBER(8,2);
BEGIN
SELECT COUNT(*) INTO nb_dept Test de l’existence du département.

FROM hr.departments WHERE department_id = :NEW.ndept;
IF (nb_dept = 0) THEN
INSERT INTO hr.departments Insertion du nouveau département.

(department_id,department_name,
manager_id,location_id)
VALUES (:NEW.ndept,:NEW.departement,NULL,NULL);
END IF;
SELECT (max_salary-min_salary)/2 INTO v_salaire Recherche du salaire moyen.

FROM hr.jobs WHERE job_id = :NEW.id_emploi;
INSERT INTO hr.employees Insertion du nouvel employé.

(employee_id, first_name, last_name, email,
hire_date, job_id,
salary, commission_pct, manager_id, department_id)
VALUES (:NEW.id_emp,:NEW.prenom,:NEW.nom,:NEW.mail,
:NEW.date_embauche,:NEW.id_emploi,v_salaire,
NULL,NULL,:NEW.ndept);
END;
Le scénario suivant décrit deux insertions dans la vue et la vérification des données dans les
tables au final.

SQL> INSERT INTO v_dept_emps Ajout d’un nouveau département et d’un nouvel
(ndept, departement, id_emp, prenom, nom, employé.
mail, date_embauche, id_emploi)

VALUES
(99,'Eyrolles Design.',999,'Fred','Brouard',
'sqlpro',SYSDATE,'IT_PROG');
1 row created.
SQL> INSERT INTO v_dept_emps Ajout d’un nouvel employé rattaché à un

(ndept, departement, id_emp, prenom, nom, département existant.
mail, date_embauche, id_emploi)

VALUES
(99,'Eyrolles Design.',998,'Rudi','Bruchez',
'babaluga',SYSDATE-10,'IT_PROG');
1 row created.
SQL> SELECT department_id,department_name

FROM hr.departments
DEPARTMENT_ID DEPARTMENT_NAME
-------------- ------------------------------
99 Eyrolles Design.
SQL> SELECT employee_id, first_name, last_name, salary, hire_date, job_id, department_id

FROM hr.employees
WHERE employee_id IN (999,998);
EMPLOYEE_ID FIRST_NAME LAST_NAME SALARY HIRE_DATE JOB_ID DEPARTMENT_ID
------------ ------------ -------------------- -------- ---------- ------- --------------
998 Rudi Bruchez 3000 20-OCT-11 IT_PROG 99
999 Fred Brouard 3000 30-OCT-11 IT_PROG 99
Mise à jour de tables et vues objet

Dans le contexte objet, les déclencheurs INSTEAD OF trouvent un autre champ d’actions
[SOU 08]. Ils permettent la modification de structures de données complexes (tables ou vues
objet) incluant des références physiques (pointeurs) et des collections de type NESTED TABLE.

Avec Oracle, un déclencheur INSTEAD OF peut être programmé au niveau d’une collection
NESTED TABLE d’une vue objet. Ce type de déclencheur :
●● s’exécute seulement si un élément de la collection NESTED TABLE est modifié par l’ins-
truction TABLE(…) ;
●● ne s’exécute pas pour une mise à jour globale de la collection NESTED TABLE (dans son
intégralité, il n’y a pas d’accès à un élément en particulier).

Programmons l’insertion d’un élément de la collection suivante. Il s’agit d’ajouter les nouvelles
données dans une table relationnelle.
Figure 4-13. Vue multitable avec collection
Dans le corps du déclencheur, il est possible d’avoir accès aux valeurs des données de la col-
lection mise à jour, mais aussi de l’enregistrement qui contient la collection (parent row). Des
directives permettent de répercuter dans la table les modifications réalisées au niveau de la
collection :
●● ON NESTED TABLE désigne la collection surveillée (ici, emps_nt) ;
●● REFERENCING permet de renommer les pseudo-variables :NEW et :OLD ;
●● PARENT désigne le niveau parent de la collection (ici, département).

Tableau 4-34 : Déclencheur INSTEAD OF pour l’insertion dans une collection d’une vue
CREATE TRIGGER trg_insert_v_obj_dept_emps Création du déclencheur et description de

INSTEAD OF INSERT l’événement déclencheur.
ON NESTED TABLE emps_nt OF v_obj_dept_emps
REFERENCING NEW AS emp PARENT AS dept
FOR EACH ROW
BEGIN
INSERT INTO hr.employees Insertion du nouvel employé (e-mail

(employee_id,first_name,last_name,email, automatiquement construit, emploi affecté
phone_number,hire_date,job_id, arbitrairement à 'IT_PROG').
salary,commission_pct,manager_id,department_id)
VALUES
(:emp.id_emp,:emp.prenom,:emp.nom,
UPPER(SUBSTR(:emp.prenom,1,1)||:emp.nom),NULL,
:emp.date_embauche,'IT_PROG',NULL,
NULL,NULL,:dept.n_dept);
END;
Le scénario suivant décrit une insertion dans la collection de la vue et vérifie la présence des
données dans la table source et dans la vue objet.
SQL> INSERT INTO TABLE Ajout d’un nouvel employé rattaché au

(SELECT emps_nt FROM v_obj_dept_emps département 40.
WHERE n_dept=40) VALUES
(elt_emp_t(999,'Fred','Brouard',SYSDATE));
1 row created.
SQL> SELECT employee_id,first_name,last_name,email,

hire_date,job_id,department_id FROM hr.employees
WHERE employee_id = 999;
EMPLOYEE_ID FIRST_NAME LAST_NAME EMAIL HIRE_DATE JOB_ID DEPARTMENT_ID
------------ ------------- ------------- ------------- ----------- ------- --------------
999 Fred Brouard FBROUARD 31-OCT-11 IT_PROG 40
SQL> SELECT v.nom_dept,ant.id_emp,ant.prenom,ant.nom

FROM v_obj_dept_emps v, TABLE(v.emps_nt) ant
WHERE v.n_dept=40;
NOM_DEPT ID_EMP PRENOM NOM

---------------------------------- --------- --------------------- ----------
Human Resources 999 Fred Brouard
Human Resources 203 Susan Mavris

Chapitre 5
Les outils du marché :

de la théorie à la pratique
Ce chapitre finalise la démarche théorique de cet ouvrage en comparant les outils du marché
qui mettent en œuvre la notation UML et la génération de script SQL ou l’interconnexion à une
base de données, le plus souvent par un pilote ODBC ou JDBC.
Le classement que j’avais établi en 2007 était le suivant. J’avais noté les produits du moment en
fonction de leur qualité à traduire un modèle conceptuel, de leur robustesse, ergonomie, docu-
mentation et support éventuel que j’avais dû solliciter. La coquille de l’époque concernait le
prix de PowerAMC qui en vérité était bien plus élevé que celui affiché (le module objet n’était
pas pris en compte), il devait déjà avoisiner les 5 000 euros.
Figure 5-1. Le classement de 2007

Il est intéressant d’analyser l’évolution de ces offres cinq ans après. Enterprise Architect n’offre
plus la possibilité de traduire un diagramme de classes, Visual UML a été inclus dans Visual
Paradigm. Peu de nouveaux outils sont apparus et ceux qui sont gratuits ne sont ni fiables, ni
performants. Ma sélection s’est portée sur les outils suivants :
●● MagicDraw UML : http://www.magicdraw.com/
●● MEGA Designe : http://www.mega.com/en/product/mega_designer/index.asp?l=en

●● Modelio : http://www.modeliosoft.com/
●● Objecteering : http://www.objecteering.com/
●● PowerAMC : http://www.sybase.fr/products/modelingdevelopment/poweramc
●● Rational Rose : http://www.ibm.com/
●● Visual Paradigm : http://www.visual-paradigm.com/product/vpuml/
●● Win’Design : http://www.win-design.com/fr/
Ces outils proposent tous un processus de conception basé sur les différents niveaux du concep-
tuel au physique (forward engineering), un processus de rétroconception (reverse engineering)
et un processus d’interéchange (round-trip engineering) entre modèles.
La partie consacrée aux bases de données n’est pas forcément prépondérante. D’autres
fonctionnalités concernent la modélisation de processus métier BPM (Business Process
Models) qui peuvent être importés ou exportés conformément au langage BPEL4WS
(Business Process Execution Language for Web Services). Nombre d’entre eux fournissent
un référentiel utile aux architectes des systèmes d’information qui en seront les principaux
utilisateurs. Certains outils se combinent avec Hibernate, ce qui n’arrange pas nos affaires
en vérité.
Ce chapitre ne se substitue évidemment pas à la documentation des produits, il illustre seule-
ment certaines fonctionnalités des éditeurs de logiciels. Chaque outil est évalué sur la qualité
de traduction d’un diagramme de classes incluant toutes sortes d’associations. La capacité de
rétroconception d’une base de données est également étudiée.
MagicDraw
La version Architect ou Enterprise de MagicDraw présente sur le site Web des fonctionnalités
relatives à la génération de code SQL. La version d’évaluation est plus que restrictive (procé-
dure d’enregistrement et multiples vérifications) : nombre d’objets limités, fichiers en lecture
seule, le tout pour 27 jours ! Au secours !

Chapitre 5 Les outils du marché : de la théorie à la pratique
Figure 5-2. Environnement de travail de MagicDraw
Le clou de l’essai : l’impossibilité de définir un identifiant de classe. En cinq ans : zéro progrès.
Fermez le ban !
MEGA
L’offre logicielle de la société MEGA regroupe quatre catégories d’outils pour la modélisation,
le contrôle, les transformations et les outils de communication. L’outil de modélisation est ici
brièvement présenté.
Pour débuter, créez un projet, un paquetage et reliez le paquetage à la base de données. Cette
commande n’est pas active par défaut et nécessite une action manuelle (menu Tools>Options,
dossier Compatibility>Others, cochez l’option Data Package dans la partie droite de la
fenêtre).
Identifiants
Un clic droit sur la classe choix Attributes vous permettra de créer des attributs. Sélectionnez
ensuite l’identifiant. Pour le typage, sélectionnez chaque attribut par un clic droit dans l’ex-
plorateur, choix Properties, onglet Characteristics et trouvez le type adéquat dans la liste
Expression Type.

Figure 5-3. Identification des classes
Associations
Pour créer une classe-association, créez la classe du milieu et, à l’aide du bouton Link, reliez
cette classe à l’association.
Figure 5-4. Associations

Génération du modèle relationnel

Afin de générer un modèle logique, positionnez-vous sur votre base, d’un clic droit, choisissez
Edit puis Outils (synchroniser du conceptuel au logique).
Figure 5-5. Génération du modèle relationnel
Un assistant en quatre étapes est alors lancé. Le modèle relationnel est, par la suite, créé dans
le paquetage.
Figure 5-6. Modèle relationnel

Génération des tables

Pour obtenir le script SQL, positionnez-vous sur votre base, et d’un clic droit, choisissez Gene-
rate puis SQL.
Figure 5-7. Génération de la base
Rétroconception
Créez une base vide de tout diagramme, et renseignez le type du SGBD (Properties), d’un clic
droit Reverse Target Database. Vous avez le choix entre sélectionner une source de données
ODBC préalablement définie ou un script SQL. Pour ce dernier cas, MEGA fournit un outil
qui se connecte à une base par ODBC et génère automatiquement un fichier XML décrivant
les tables et clés.
Afin de générer un modèle conceptuel, vérifiez que vous avez accès au Meta Model en mode
Avanced, dans le menu Tools>Options. Un assistant en quatre étapes se lance et produit un
nouveau modèle de données (Data Model). Dans ce modèle, créez un diagramme de données
(clic droit New>Data Diagram) puis insérez dans ce diagramme par un glisser-déposer les
entités que vous avez obtenues après rétro-ingénierie.

Figure 5-8. Rétroconception d’une base
Les schémas obtenus par rétroconception sont de très bonne qualité. Dans l’exemple, seules les
agrégations devraient être notées en tant que compositions. Les points forts de cet outil sont
la robustesse, l’ergonomie de l’outil de synchronisation par étapes et les passerelles possibles
avec d’autres outils.
Modelio
Modelio est distribué par Modeliosoft, filiale de Softeam, société française. Ce produit est
basé sur l’architecture d’Objecteering (présenté plus loin) et présente une interface au look
Eclipse.
Avant tout, installez les modules Persistent Profile et SQL Designer (MDA>Installer un
module…) avant de créer un projet puis, à l’intérieur de celui-ci, un diagramme de classes.
Chaque classe, attribut et association doivent être déclarés persistants (cochez Element Persis-
tant dans la fenêtre en bas à droite dans l’onglet Persistent).

Identifiants
Pour créer des attributs et un identifiant dans une classe, rendez-vous dans la fenêtre Modèle,
d’un clic droit sur la classe et Profil de persistance, choisissez Property ou Identifier puis typez
la colonne dans la fenêtre en annotant l’élément dans l’onglet Element.
Associations
Chaque type d’association (classe-association, composition, etc.) dispose de son icône. L’anno-
tation d’une association vous permet de fixer les multiplicités.

Figure 5-10. Associations

La génération du diagramme du modèle de données (que Modelio nomme diagramme de
classes persistantes) se réalise au niveau du projet qui contient le diagramme (clic droit puis
SQL Designer>Transformation : UML en modèle de données).
Le problème que j’ai rencontré se situe à ce niveau et concerne la transformation des classes-
associations. Pour des questions d’intégration du module SQL avec le générateur Hibernate
et Java, ce type de transformation n’est pas encore implémenté. Pour contourner ce pro-
blème, il faut agir soit au niveau du modèle de données, soit modéliser chacune de vos
classes-associations en tant que classes normales. Ce n’est pas satisfaisant, mais ça vous
évitera un blocage.

Figure 5-11. Génération du modèle de données

La génération du diagramme des tables (que Modelio nomme diagramme SQL) se lance par un
clic droit sur le modèle de données puis SQL Designer>Transformation : Modèle de données
vers modèle de tables. Vous choisirez ensuite le SGBD cible (SQL92, Oracle, MySQL ou SQL
Server).
Figure 5-12. Génération des tables

La génération du script SQL s’opère par un clic droit sur le diagramme SQL, puis SQL
Designer>Générateur : Script SQL.
Pour effectuer une rétroconception à partir d’un script SQL, positionnez-vous au niveau du
projet, puis clic droit SQL Designer>Reverse : Script SQL. Vous devrez ensuite choisir le type
du script (SQL92, Oracle, MySQL ou SQL Server) et localiser le fichier contenant la création
des tables et contraintes. Pour remonter dans les niveaux, positionnez-vous sur le diagramme
SQL obtenu (qui est de bonne qualité), puis clic droit SQL Designer>Transformation : Modèle
de tables vers modèle de données. La suite des opérations est bien plus hasardeuse lorsque
vous désirez générer le modèle UML.
Figure 5-13. Rétroconception d’un script SQL
La simplicité des menus et l’ergonomie de cet outil sont appréciables de même qu’un forum
réactif. En revanche, il manque un peu de fluidité dans la manipulation graphique des schémas.
L’existence d’un modèle de données intermédiaire et la volonté d’intégrer Hibernate dans le
même contexte entravent, à mon sens, la qualité de génération entre des modèles UML et
SQL et inversement. Un autre point faible concerne l’incapacité à traiter automatiquement les
classes-associations.
Objecteering
Objecteering est un autre produit français de la société Softeam qui est un acteur majeur dans
la communauté des technologies objet et premier membre européen de l’OMG.

Dans cet outil, le terme physical model désigne un schéma relationnel (niveau logique) et
logical model désigne un script SQL.
Avant tout, créez un projet puis configurez l’affichage des tags qui serviront à annoter un
diagramme de classes pour sa transformation (Outils>Options graphiques… Diagramme de
classes, rendez visible les tagged values). Ensuite, déployez le module SQL (Outils>Deployer
un MDAC… choisissez generator>SQLDesigner). Concernant ce module (Outils>Options
MDAC…), configurez l’accès à votre base. Dans l’option Génération de diagramme sur le
modèle physique, cochez la case correspondante.
Vous pouvez créer un paquetage (dans la racine) qui contiendra votre diagramme de classes.
La transformation de modèle nécessite que vous enrichissiez au préalable le diagramme de
classes UML de tagged values. Ainsi, vous devez annoter chaque classe du tag persistence
en adjoignant la propriété persistent.
Identifiants
Pour ajouter des attributs à une classe, cliquez sur l’icône de l’attribut, puis cliquez à
nouveau dans sa classe. Les identifiants sont choisis via un clic droit sur la classe puis
MDA Components>SQL Designer>Primary key… Pendant la saisie du diagramme de
classes, servez-vous plutôt de la fenêtre de gauche (Explorer) pour supprimer les éléments
superflus.

Associations
En double-cliquant sur un lien d’association, vous obtenez une fenêtre avec différents onglets,
vous pouvez nommer l’association, les rôles, les multiplicités, etc. Décochez la case Est navi-
gable qui ne sert à rien.
Figure 5-15. Détails des associations
Pour trouver les liens de classes-associations et de composition, laissez le curseur sur le bas de
l’icône Association (au niveau du tout petit triangle noir).

La génération d’un schéma relationnel se réalise au niveau du paquetage contenant votre
diagramme de classes (clic droit MDA Components>SQL Designer>Générer un modèle phy-
sique).


Dans la fenêtre Explorer, le choix MDA Components>SQL Designer>Générer les fichiers
SQL, au niveau du paquetage contenant le modèle physique, permet de générer un script SQL.
Un grand nombre de points forts sont à noter : rigueur de la démarche et ergonomie à la fois
sobre et puissante, documentation détaillée du module SQL Designer (principes de transfor-
mations), réactivité et efficacité du support ainsi que l’existence d’un forum dédié. Les points
faibles concernent le nombre réduit de SGBD pris en compte et surtout l’absence de processus
de rétroconception.

PowerAMC
PowerAMC (anciennement AMC*Designor)est la version française de l’outil de modélisation
PowerDesigner de Sybase. Depuis la version 8, la notation UML (appelée MOO : Modèle
Orienté Objet) coexiste avec les notations Merise, entité-relation et IDEF1X.
Débutez avec un nouveau diagramme de classes (Fichier>Nouveau>Modèle Orienté Objet),
en choisissant comme langage objet Analyse. La palette graphique apparaît. Pour visualiser
le nom des associations : clic droit sur le fond puis Préférences d’affichage>Association, et
cochez la case Nom.
Figure 5-18. Environnement de travail
La fenêtre de gauche contient tous les détails du diagramme de classes.
Identifiants
Pour chaque classe, vous devez définir un identifiant primaire. Le nom de l’identifiant importe
peu, vous n’avez pas à le modifier. Sélectionnez l’attribut (ou les attributs), cliquez sur la clé et
suivez le guide…

Figure 5-19. Création d’un identifiant
Si l’attribut n’apparaît pas souligné après avoir validé cette étape, retaillez un peu la classe à
la souris, ça devrait fonctionner. Si vous désirez ajouter d’autres identifiants (alternatifs), le
principe est le même, mais vous décocherez la dernière case.
Associations
En double-cliquant sur un lien d’association, vous obtenez plusieurs fenêtres pour inscrire le
nom de l’association, les rôles, les multiplicités et la composition. Décochez la case Navigable
qui ne sert à rien.
Figure 5-20. Détails d’une association

Pour créer une classe-association, il suffit de rattacher une classe à une association existante
par un nouveau lien d’association et le tour est joué.
Héritage
La palette contient un symbole relatif aux liens d’héritage ; reliez ensuite la sous-classe à sa
surclasse.
Figure 5-21. Détails des liens d’héritage
En double-cliquant sur un lien d’héritage, vous obtenez une fenêtre qui permet de choisir la
traduction de l’héritage (distinction : par défaut, push-down : ne pas générer la classe parent,
push-up : ne pas générer la classe enfant).

Le choix Outils/Générer un Modèle Physique de Données… permet de transformer le dia-
gramme de classes en modèle relationnel. Des boîtes de dialogue donnent accès à un certain
nombre d’options, notamment choisir son SGBD et les classes à traduire.

Le résultat s’affiche en tant que nouveau schéma relationnel, la fenêtre de gauche contient tous
les détails de la composition des tables. À ce niveau, vous pourrez renommer des colonnes et
clés étrangères, mais surtout typer au mieux chaque colonne.
Figure 5-23. Modèle physique des données

Le choix SGBD/Générer la base de données… permet de transformer un schéma relationnel
en script SQL ou directement en tables par une connexion ODBC au SGBD. Des boîtes de
dialogue donnent accès à un certain nombre d’options, notamment aux relations à traduire, à
la forme du script SQL, etc. Un aperçu du code SQL est également présenté.

Rétroconception
Le choix Fichier/Reverse Engineering/Base de données… permet de construire un schéma
relationnel à partir d’un script SQL ou par une connexion au SGBD pour extraire des tables
d’un schéma. Des boîtes de dialogue donnent accès à un certain nombre d’options, notamment
le type du SGBD source, les tables à traduire après connexion au SGBD, le nom du script
SQL, etc.
Figure 5-25. Options de rétroconception
Un modèle physique des données est ensuite automatiquement généré.

Rational Rose
La société Rational Software, qui a été à l’origine de la standardisation d’UML, est propriété
d’IBM depuis 2003. L’outil de conception qui est au catalogue d’IBM s’appelle toujours
Rational Rose Data Modeler. Cet outil est basé sur le formalisme UML et inclut un profil
convenant aux bases de données. Un profil est une proposition d’une communauté et regroupe
un ensemble d’éléments UML (composants, stéréotypes, icônes, propriétés…) qui s’appliquent
à un contexte particulier et qui conservent le métamodèle d’UML intact. Quand un tel profil
est valide au niveau de la notation, il est dit « bien formé ». Ce profil n’a pas été adopté par les
autres éditeurs de logiciels.
Figure 5-26. Icônes du profil UML de Rational
Le profil UML de Rational concerne le niveau logique. Le concept d’association « faible »

représente un lien entre deux tables par une clé étrangère classique. Le concept d’association
« forte » représente un lien entre deux tables par une clé étrangère qui fait partie aussi de la clé
primaire (implémentation des tables d’association, de l’héritage par distinction ou des associa-
tions de composition).
Il est nécessaire dans un premier temps de créer un composant Database dans le répertoire
Component View (clic droit Data Modeler>New>Database). Nommez la base et choisissez le
SGBD cible (Name et Target). Créez ensuite un schéma dans le répertoire Logical View (clic
droit Data Modeler>New>Schema) et associez ce schéma à la base de données. Pour créer un
paquetage : clic droit sur le compartiment Logical View, New>Package.

Figure 5-27. Création
Les classes du diagramme UML doivent présenter les caractéristiques suivantes :

●● marquées Persistent (clic droit sur la classe, Open Specification, onglet Detail) ;
●● groupées dans un paquetage du compartiment Logical View. L’outil transforme un dia-
gramme au niveau du paquetage.

L’utilisation des domaines de valeurs est nécessaire pour affecter à chaque attribut le type de
colonne. Pour créer un domaine : clic droit sur Global Data Types, Data Modeler>New>Domain
Package.
Identifiants
Pour identifier une classe, vous devez marquer l’attribut en tant que Part of Object Iden-
tity. Pour un identifiant composé, il faut répéter ce choix sur chaque attribut. Si aucun attribut
ne vous convient, vous pouvez laisser l’outil ajouter un attribut de type ID-based column. Pour
le SGBD Oracle, le type de cette colonne est NUMBER(10).
Figure 5-28. Identification d’une classe


À l’aide de la palette, en choisissant l’icône de l’association, il suffit de relier les classes entre
elles, de nommer l’association et de préciser les multiplicités. Sélectionnez le paquetage (clic
droit, Data Modeler>Transform to Data Model…) puis indiquez les noms du schéma et de la
base. Si aucune base n’est sélectionnée, la transformation sera de type SQL2. Il est possible de
créer des index pour les clés étrangères.
Après la transformation, vous devez créer un diagramme pour visualiser le modèle logique
(clic droit sur le schéma puis Data Modeler>New>Data Model Diagram). Vous pouvez
modifier certaines caractéristiques avant de générer le script SQL (noms des contraintes et
colonnes, etc.).
Figure 5-30. Modèle de données obtenu


Pour générer le script SQL, sélectionnez le schéma (clic droit Data Modeler>Forward Engi-
neer…), un assistant est alors lancé dans lequel vous devrez choisir parmi différentes options
(chemin et nom du script SQL à générer, création de commentaires, de tablespaces, de direc-
tives DROP, etc.). Il est aussi possible d’exécuter directement le script par une connexion au
SGBD.
Rétroconception
Vous devrez au préalable créer un paquetage vide. Le processus de rétroconception démarre
du schéma (compartiment Logical View/Schemas) à sélectionner par un clic droit (Data
Modeler>Transform to Object Model). L’assistant permet de sélectionner le nom du paque-
tage en sortie ainsi que d’autres options. Le fait de transformer un modèle de données dans
un paquetage modifie les nouveaux éléments du paquetage, mais ne détruit ni ne modifie les
éléments mis à jour au niveau du modèle de données.
Cet outil n’a pas évolué depuis la première version de cet ouvrage, ce qui prouve sa très grande
robustesse. On peut toutefois regretter qu’il n’inclue pas de pilotes pour les SGBD open source.
Visual Paradigm
L’édition Enterprise de Visual Paradigm déclare des fonctionnalités relatives à SQL.
J’ai donc téléchargé la version d’évaluation qui permet l’enregistrement de diagrammes
pendant dix jours. Une fois le diagramme de classes UML saisi, vous constaterez qu’il n’est
pas possible de générer du code SQL directement. La version évaluée en 2007 ne comportait
pas ni d’identifiant de classes, ni d’associations n-aires. Cette version supporte maintenant
les associations n-aires sans inclure les identifiants de classes. Pile ce qu’il ne fallait pas
faire.
Ce qu’il est possible de faire pour l’heure, c’est générer un diagramme de classe à partir d’un
modèle de type entité-relation. Très pratique… Au suivant !

Figure 5-31. Environnement de travail de Visual Paradigm
Win’Design
Win’Design est le produit de la société Cecima basée à Aix-en-Provence. Il est présent sur le
marché français depuis 1995. Développé initialement pour Merise/2, la notation UML arrive
en 2002 avec la version 5. Depuis, l’outil est en évolution constante. En 2011, la version 11 est
disponible.
La gamme comprend trois modules autonomes et complémentaires, qui s’articulent autour d’un
référentiel (Database pour la conception et le reverse des bases de données, Business Process
pour la modélisation des processus métier et Object pour la modélisation UML). Vous devrez
disposer du premier et du troisième module pour traduire des diagrammes de classes en script
SQL. Win’Design est un outil facile à prendre en main et son interface est très intuitive. Le seul
problème de ce produit est qu’il présente encore des lacunes de traduction d’un diagramme UML
vers le modèle logique. Lacunes qui sont absentes si vous utilisez la notation Merise.
Pour débuter avec un nouveau diagramme de classes : Fichier>Nouveau>Module Objet. Cli-
quez sur le diagramme de classes et choisissez le langage cible Analyse. Un modèle vierge
d’attributs, mais contenant tous les types d’associations apparaît, ainsi qu’une palette graphique.

Figure 5-32. Environnement de travail de Win'Design
Identifiants
Pour chaque classe, le bouton Details… permet de saisir les attributs et leurs types. L’identi-
fiant est à cocher dans la case associée.
Figure 5-33. Création d’un identifiant
L’attribut identifiant apparaît d’une autre couleur que les autres.

Associations
La fenêtre de gauche contient tous les détails du diagramme de classes. La palette permet de
créer tout type de classe, d’association, de classe-association et de lien d’héritage.
Figure 5-34. Référentiel et palette d’outils
Pour visualiser le nom des associations, cliquez sur le lien, dans l’onglet Affichage, cochez
Nom. Il est possible de créer des associations n-aires, mais il n’est pas possible de relier une
classe-association à une autre classe par une association simple. Cette fonctionnalité n’est
possible qu’au niveau de Merise en utilisant un lien identifiant. Ce qui constitue pour moi le
principal inconvénient de cet outil.
Héritage
Il n’est pas possible de choisir la traduction de l’héritage (distinction, push-down ou push-up).
Par défaut, la méthode push-down est adoptée. Ce choix de décomposition n’est possible qu’au
niveau de Merise.

Le choix Modèle>Générer modèle logique permet de transformer le diagramme de classes en
modèle relationnel. Des boîtes de dialogue permettent un certain nombre d’options, notamment
le choix du SGBD.

Le résultat s’affiche en tant que nouveau modèle logique, le référentiel s’enrichit des détails
des tables (clés et index). À ce niveau, vous pourrez renommer des tables, des colonnes ou des
clés étrangères.
Figure 5-36. Modèle logique des données


Le choix Base de données>Générer script… permet de transformer un schéma relationnel en
script SQL. Des boîtes de dialogue donnent accès à un certain nombre d’options, notamment
à la composition du script SQL.
Rétroconception
Le choix Fichier>Reverse Engineering>Base de données… permet de construire un modèle
logique à partir d’un script SQL ou par une connexion au SGBD pour extraire des tables d’un
schéma. Des boîtes de dialogue donnent accès à un certain nombre d’options, notamment au
répertoire qui contient le script SQL, aux tables à traduire, etc.
Figure 5-38. Options de rétroconception
Un modèle logique des données est ensuite automatiquement généré.

Conclusion
L’évolution d’UML, d’un point de vue normatif, vers les bases de données, ne se concrétise
toujours pas, car la RFP (Request For Proposal) nommée Information Management Meta-
model proposée par l’OMG en 2006 est toujours au point mort. Cette spécification visait à
définir un métamodèle incluant différentes sous-parties : Common Warehouse Metamodel,
UML2 Profile for Relational Data Modeling, UML2 Profile for Logical (Entity Relationship)
Data Modeling, UML2 Profile for XML Data Modeling et UML2 Profile for Record Modeling
COBOL. Cette absence de normalisation n’empêche personne d’utiliser UML pour concevoir
une base de données relationnelle, la preuve, bon nombre d’outils ont implémenté les princi-
paux mécanismes.
En fonction des tests réalisés, des manipulations relatives à l’installation, à la recherche de
documentations, etc. voici le classement qui n’engage que moi bien sûr. Sachez aussi qu’il
existe des forums sur http://www.developpez.net, relatifs à Rational Rose et PowerAMC.
Tableau 5-1 : Et le gagnant est…
Produit Éditeur Prix indicatif Version Note

(€) évaluée
PowerAMC Sybase 6 800 € 15.3
MEGA Designer MEGA 3 300 € 2009 SP5
Rational Rose Data Modeler IBM 2 100 € 7.0
Objecteering Softeam 1 800 € 6.1
Win’Design Cecima 2 980 € 11.0
Modelio SQL Solution Softeam 2 400 € 2.0
Visual Paradigm Visual Paradigm 1 400 € 8.3
MagicDraw No Magic 1 700 € 12.0

Annexe A
Corrigés des exercices

Exercice 1.1 – La déroute des bleus
Les associations binaires les plus conformes aux 6 classes du schéma sont les suivantes.
Figure A-1. Classes et associations

●● Il est préférable d’utiliser deux associations pour modéliser une rencontre entre 2 équipes
qu’une seule association plusieurs-à-plusieurs.
●● Il est préférable de relier Stade à Ville plutôt que Match à Ville. Cette information est
déduite sans ambiguité par le parcours des associations derouler et lieu.
Classe-association
La classe-association Equipe_Langue permet l’affichage d’une même équipe dans diffé-
rentes langues. Le libellé de l’équipe dépend simultanément du code équipe et du code langue.
Figure A-2. Classe-association
Historique
La classe Historique permet d’identifier (d’une manière relative) une équipe et un groupe
par rapport à l’année. Ainsi, l’équipe numéro 34 couplée à l’année 2006 se différencie de la
même équipe (34) en 2010. Il en va de même pour les groupes (A-2006 est différent de A-2010).
Les autres classes reliées à Equipe et Groupe (ici, seulement Match) n’ont pas à subir le
même traitement si elles ne nécessitent pas d’être identifiées d’une manière relative par rap-
port à l’année de la compétition. C’est le cas pour une rencontre dont le numéro n’a pas de

ANNEXE A Corrigés des exercices
sémantique temporelle et qui est reliée de manière non ambiguë aux deux équipes qui seront
estampillées de l’année de l’événement.
Figure A-3. Historisation du premier tour
Bien que les associations sites et utiliser ne soient pas minimales (on peut les déduire
à partir de tous les matchs d’une année donnée), elles permettent, d’une part, d’éviter de par-
courir les matchs pour connaître les villes et les stades prévus pour chaque événement. D’autre
part, dans des conditions initiales (aucun match n’est encore joué ou prévu), elles deviennent
indispensables pour définir dans quelles villes et dans quels stades les rencontres auront lieu.
Une fois définies, elles permettent également de vérifier la cohérence du lieu d’un match réa-
lisé.

Exercice 1.2 – L’organisme de formation
Inscriptions
Il est préférable de définir une classe pour héberger l’attribut codent qui est un identifiant
potentiel. Le créneau de disponibilité (jsem et hrens) dépend du consultant responsable de
la formation.
Figure A-4. Inscriptions des stagiaires
Plannings
●● Le créneau de disponibilité (jsem et hrens) dépend désormais de la formation et plus
seulement du consultant responsable.

Figure A-5. Un planning par formation
●● Plusieurs créneaux de disponibilité (jsem et hrens) peuvent être associés à une formation
(et, donc, à son responsable) et un même créneau peut concerner différentes formations.
En conséquence, ces deux attributs ne peuvent se trouver ni dans la classe Formation, ni
dans la classe Employe.
La création de la classe Creneau permet d’héberger ces attributs. Aucun de ces deux attributs
pris isolément ne peut devenir identifiant. En revanche, le couple (jsem , hrens) identifie un
créneau unique et permet de caractériser cette classe sans recourir à l’identification artificielle.
Figure A-6. Plusieurs plannings par formations

Attention, ne déclarez pas l’association planning entre Employe et Creneau, car vous ne
pourriez pas connaître la formation renseignée pour un créneau et un formateur donnés (erreur
de l’« abîme »).
Exercice 1.3 – Les lignes de facture

La classe-association Prod_Fact modélise que, dans toute facture, plusieurs produits peuvent
être commandés et qu’un produit peut se retrouver dans plusieurs factures. Chaque attribut qui
dépend d’une ligne de facturation est présent dans cette classe-association.
Au moment de la facture, chaque produit est associé à un code TVA et est vendu au prix cou-
rant. Les conditions initiales (aucune facture n’est émise le matin du premier jour de l’exercice
comptable) imposent la présence du prix dans la classe Produit et la nécessité de relier cette
même classe à la classe TVA.
Figure A-7. Les lignes d’une facture

Exercice 1.4 – La décomposition des n-aires

Décomposez toute association n-aire que vous seriez tenté de définir.
Visite des représentants

●● Un dépôt qui se trouve dans une région est visité par plusieurs représentants.
Figure A-8. Visite des représentants
●● L’historique des visites peut se modéliser à l’aide de la classe Visite identifiée par le
couple (représentant, jour) associé à plusieurs dépôts (en supposant qu’un représentant
puisse réaliser différents déplacements le même jour).
Figure A-9. Historique des visites des représentants

●● En reliant la classe-association à la classe Vehicule, on renseigne le moyen de transport

utilisé par un représentant le jour de sa visite à un dépôt.
Figure A-10. Transport des visites des représentants
●● En identifiant artificiellement la classe Visite, les associations autour de cette classe sont
simplifiées. En revanche, les éventuelles contraintes de planning d’un représentant (liste
des jours de travail, par exemple) seront plus difficiles à mettre en œuvre.
Figure A-11. Solution avec l’identification artificielle

Stages
Le couple prépondérant est (Stage, Ville), car il est souhaitable de contraindre en premier les
lieux d’un stage donné. Ce couple est ensuite associé à plusieurs périodes. Cette modélisation
n’est valable que pour une année en cours.
Figure A-12. Les stages
Cote automobile
En ajoutant l’année au modèle, on identifie une cote brute. Les autres caractéristiques d’un
véhicule sont associées au modèle.
Figure A-13. Cote automobile

Horaires d’une ligne de bus

Le couple prépondérant est (Ligne, Jour) ; il conditionne l’activité d’une ligne de bus à un
jour donné. À tout couple, il faut associer une liste de stations (ordonnées à l’aide de l’attribut
ordre). L’identifiant de la classe Horaire est composé des numéros de la ligne, du jour, de la
station et de la position de la colonne dans le tableau.
Figure A-14. Horaires des lignes de bus
Exercice 1.5 – Les comptes bancaires

Le propriétaire de chaque compte est modélisé par une association, et la date d’ouverture du
compte est un attribut de classe. Les mandataires sont des clients particuliers (le fait qu’ils ne
soient pas propriétaires n’apparaît pas ici ; une contrainte devra être ajoutée) qui sont associés
aux comptes qu’ils peuvent gérer à travers divers droits.
Figure A-15. Les comptes bancaires

Identification relative
La classe Calendrier modélise les dates de rendez-vous de chaque conseiller. En asso-
ciant cette classe aux clients, on obtient l’historique de chaque client. La date du dernier
rendez-vous d’un client est modélisée par un attribut de classe (pouvant toutefois être
déduit). Les produits financiers souscrits sont modélisés par une association plusieurs-
à-plusieurs.
Figure A-16. Historique des rendez-vous
Identification artificielle
Sans utiliser une classe Virement (dotée d’un identifiant artificiel), il est difficile d’identifier
un virement. Distinguez les actions de crédit et de débit d’un compte. Le client initiateur du
virement est modélisé par une association.

Figure A-17. Virements bancaires
Exercice 1.6 – Le RIB
Chaque compte est identifié au niveau national par les numéros de banque, d’agence et de
compte. La composition permet de faire migrer les identifiants de classe en classe.
Figure A-18. Identification d’un compte bancaire
Exercice 1.7 – L’organisme de formation (suite)

Complétez le diagramme de l’exercice 1.2 qui modélise l’organisme de formation.

Sessions
La classe Session permet de connecter Formation (nature du cours), Employe (identité du
formateur) et Stagiaire (liste des participants). La note dépend du stagiaire et du cours suivi.
Figure A-19. Sessions de cours
Salles
Le mémo du technicien dépend aussi de la session. Le temps de présence de chaque technicien
dépend du jour et de la session.
Figure A-20. Configuration des salles

Exercice 1.8 – L’héritage
L’héritage permet de classifier chaque employé (consultant, formateur ou technicien). La
contrainte {incomplete,overlapping} signifie qu’un consultant peut être formateur, et
réciproquement.
Figure A-21. Héritage des employés
Comptes bancaires
L’héritage suivant permet de spécialiser un client en un éventuel mandataire. Le fait qu’un
mandataire d’un compte ne soit pas le propriétaire dudit compte n’apparaît pas ici ; une
contrainte doit être ajoutée.

Figure A-22. Héritage des clients
Exercice 1.9 – Les cartes grises

Le but de cet exercice est de modéliser le cycle de vie d’un véhicule au travers de ses différents
propriétaires et de la réglementation.
Ancien régime
En dissociant le certificat du véhicule, il est aisé de modéliser l’historique des immatricu-
lations successives. Certains attributs de la classe Vehicule semblent être des identifiants
potentiels d’autres classes (genre, type du véhicule, carrosserie et énergie). Il serait intéressant
de définir ces classes et d’y associer des libellés.
Figure A-23. Cartes grises

Coût du cheval
La taxe fiscale dépend de la région et du nombre de chevaux. La composition permet d’identi-
fier (d’une manière relative) une taxe par rapport à une région.
Figure A-24. Cartes grises, coût du cheval fiscal
Nouvelle numérotation
Le nouveau système de numérotation rend le numéro d’immatriculation de tout véhicule
invariable (attribut de la classe Vehicule). L’association fetiche permet de distinguer le
département qui facture (association prefecture) le certificat de celui qui est choisi pour être
accolé à la plaque d’immatriculation.
Figure A-25. Nouvelle numérotation

Contrôles techniques
Chaque contrôle technique est rattaché à un certificat d’immatriculation et se déroule dans
un centre de contrôle (qui dépend d’une enseigne). La classe artificielle Visite_Technique
permet de modéliser facilement l’historique des visites d’un véhicule.
Figure A-26. Contrôles techniques
Exercice 1.10 – Les contraintes
Déroute des bleus

●● Un match ne doit pas opposer une équipe avec elle-même.
En considérant les rôles domicile (sur l’association recevoir du côté de la classe Equipe)
et exterieur (sur l’association deplacer du côté de la classe Equipe) :

context Match inv match_entre_2 :

Match.allInstances()−>forAll(m |
not (m.domicile.id_equipe = m.exterieur.id_equipe))
●● Un match doit opposer deux équipes du même groupe.

En considérant le rôle poule (sur l’association rattacher du côté de la classe Groupe) :
context Match inv meme_groupe :
Match.allInstances()−>forAll(m |
m.domicile.poule.id_groupe = m.exterieur.poule.id_groupe)
●● Un consultant doit proposer entre 2 et 4 créneaux par semaine pour enseigner un cours.
En considérant le rôle quand (sur l’association planning du côté de la classe Creneau) :
context Formation inv plusieurs_creneaux :
Formation.allInstances()−>forAll(f |
f.quand.size() >= 2 and f.quand.size() <4)
●● Un technicien doit rédiger un mémo de ces actions pour toute formation qu’il a en charge.
context Compte-Rendu inv memo_non_nul : self.memo <> null
●● Le nombre de stagiaires ne doit pas dépasser la capacité d’une salle pour toute session.
En considérant les rôles stagiaires (sur l’association participer du côté de la classe
Stagiaire) et local (sur l’association lieu du côté de la classe Salle) :
context Session inv nb_stagiaires :
Session.allInstances()−>forAll(s |
s.stagiaires.size() <= s.local.capacite)
Comptes bancaires
●● Un mandataire d’un compte n’est pas le propriétaire.
En considérant les rôles proprio (sur l’association proprietaire du côté de la classe
Client) et madates (sur l’association comptes_geres du côté de la classe Mandataire) :
context Compte inv mandataire_proprio :
Compte.allInstances()−>forAll(c | c
c.self.proprio.excludesAll(c.mandates))

●● Un virement se réalise entre 2 comptes distincts.

En considérant les rôles reçoit (sur l’association crediter du côté de la classe Compte) et
donne (sur l’association debiter du côté de la classe Compte) :
context Virement inv virements :
Virement.allInstances()−>forAll(v |
not (v.donne.id_cpte = m.reçoit.id_cpte))
●● Un virement nécessite un crédit suffisant.

context Virement inv solde_virement :
Virement.allInstances()−>forAll(v |
(v.donne.credit-v.donne.debit) >= v.montant)
Exercice 1.11 – La carte d’embarquement

On distingue un vol « catalogue » d’un vol réel par l’existence de 2 classes distinctes. La classe
plus abstraite est identifiée par un numéro de vol et regroupe les caractéristiques qu’on peut
trouver dans un catalogue. Le vol réel est identifié par le numéro de vol et sa date. Un client
peut se trouver dans un vol réel et n’est associé qu’à un seul siège.
Figure A-27. Carte d’embarquement : vols catalogue

On associe plusieurs sièges d’un vol réel à un client en transformant la classe-association

Place en classe. L’identifiant de cette classe est composé du numéro de vol, du jour et du
numéro de siège.
Figure A-28. Carte d’embarquement : planning annuel
Exercice 1.12 – Deux cafés et l’addition !

Il est nécessaire de distinguer une enseigne d’un restaurant. L’association de composition
permet de numéroter les tables de 1 à n pour chaque restaurant. Le jour de travail permet,
avec le code serveur, d’identifier un planning et de pouvoir ensuite l’associer à plusieurs
tables.

Figure A-29. Note de restaurant
Exercice 1.13 – La thalasso
La particularité de ce schéma est le positionnement de l’heure (entre le soin et le planning)
pour autoriser qu’un soin puisse être réalisé à différents moments.
Figure A-30. Séjour en thalasso

Exercice 1.14 – Le centre de plongée

La classe Sortie est centrale ; elle regroupe les palanquées et caractérise un voyage. L’asso-
ciation de composition permet de modéliser l’historique mensuel des prix. La taxe journalière
dépend du mois et du site visité.
Figure A-31. Centre de plongée

Exercice 1.15 – L’élection présidentielle
Membres des partis

L’historique des parcours d’un politicien est modélisé par la composition qui permet d’associer
à un politicien plusieurs périodes, chacune concernant un parti.
Figure A-32. Composition des partis
Résultats des élections passées

L’identifiant de la classe Investiture est composé du couple (année, parti) associé à un
unique candidat (des primaires ne sont pas ici prises en compte).
Figure A-33. Investiture des partis

Titre suprême
Cette solution distingue le premier du second tour par l’existence de deux associations dis-
tinctes. Les DOM-TOM peuvent être considérés en tant que département.
Figure A-34. Résultats des élections
Exercice 2.1 – Les associations binaires

La particularité de ce schéma est la traduction de l’association un-à-un entre une compagnie
et un pilote (chef pilote). La relation « parent » à considérer est celle qui détient la multiplicité
minimale à 1 (ici, Pilote). Ainsi, la clé étrangère issue de cette association migre dans la
relation « enfant » (ici, Compagnie).
Figure A-35. Associations binaires

Exercice 2.2 – L’héritage et la composition

Les particularités de ce schéma sont, d’une part, la traduction de l’héritage (de partition) et,
d’autre part, la composition permettant de définir des couples (avion, jour). Cet héritage peut
se traduire par distinction. La composition génère la clé étrangère immat dans Jour_Vol qui
fait aussi partie de la clé primaire.
Figure A-36. Héritage et composition
Exercice 2.3 – Les classes-associations

La particularité de ce schéma est la double association qui existe entre une classe (Employe)
et une classe-association (Ouverture). La première de ces associations est de type un-à-plu-
sieurs et génère la migration de la colonne id_emp dans la relation enfant (ici, Ouverture)
qui devient clé étrangère. La seconde association est de type plusieurs-à-plusieurs et induit
la création de la relation Presence dont la clé primaire est composée des clés des relations
associées.

Figure A-37. Classes-associations (comptoirs d’aéroport)
Exercice 2.4 – Traduire ou ne pas traduire ?

Voici les relations dont la transformation en tables est indiscutable.
●● Ligne qui contient l’ensemble des numéros et le nom des lignes ; Station qui comporte
l’ensemble des noms des stations ; Jour qui contient les 3 libellés « Lundi à Vendredi »,
« Samedi » et « Dimanche et jours fériés ».
●● Ligne_jour qui permet de connaître les jours de sortie de chaque bus sur sa ligne.
Les relations dérivées de ces références sont les suivantes.
●● Ligne_Jour_Sta qui décrit la composition en termes d’ordre de stations d’une ligne en
fonction du jour.
●● Horaires qui permet de connaître les heures de passage de chaque bus, un jour donné,
sur sa ligne.
La dernière relation (Position) qui liste une série de numéros n’est pas à conserver en termes
de table.

Figure A-38. Classes-associations (ligne de bus)
Exercice 2.5 – La normalisation
Une clé possible de la relation initiale est le couple (tournoi, annee). Dans ce cas, la relation
est en première forme normale, mais ne respecte pas la troisième forme normale car la date de
naissance dépend directement du joueur.
Le fait de déterminer cette dépendance directe permet de déduire la relation Joueurs. Par
ailleurs, le nom du tournoi doit être considéré comme un libellé et donc être identifié d’une
manière particulière. Il est donc nécessaire de créer la relation Tournois qui doit être asso-
ciée à la relation Joueurs par une association plusieurs-à-plusieurs. La relation Gagnants
joue ce rôle.
Figure A-39. Schéma normalisé

Exercice 3.1 – La création de tables (carte d’embarquement)

Le schéma relationnel simplifié est le suivant (la table Calendrier n’est pas traduite ici). Les
heures et minutes ont été séparées pour un meilleur contrôle des données, et certaines clés
étrangères ont été renommées (code de l’aéroport de départ et d’arrivée).
Figure A-40. Schéma relationnel simplifié
Le tableau suivant présente le script de création des tables et index.
Tableau A-1 : Création des tables et index
Script SQL
CREATE TABLE aeroport ( CREATE INDEX detient_fk ON

code_oaci VARCHAR2(4) NOT NULL, passager (code_fidelite ASC);
nom_aeroport VARCHAR2(50),
CONSTRAINT pk_aeroport CREATE INDEX composer_fk ON place
PRIMARY KEY (code_oaci)); (num_vol asc, jour_mois ASC);

Script SQL (suite)
CREATE TABLE carte (

code_fidelite NUMBER(1) NOT NULL, CREATE INDEX reserver_fk ON place
lib_fidelite VARCHAR2(20), (num_carte ASC);
CONSTRAINT pk_carte
PRIMARY KEY (code_fidelite)); CREATE INDEX depart_fk ON vol
(code_oaci_dep ASC);
CREATE TABLE passager (
num_carte NUMBER(12) NOT NULL, CREATE INDEX arrivee_fk ON vol
(code_oaci_arr ASC);
code_fidelite NUMBER(1),
nom_client VARCHAR2(40),
CREATE INDEX constituer_fk ON
prenom_client VARCHAR2(40),
volreel (num_vol ASC);
CONSTRAINT pk_passager
PRIMARY KEY (num_carte));
CREATE INDEX planning_fk ON
planning (num_vol ASC);
CREATE TABLE place (
num_vol VARCHAR2(8) NOT NULL,
jour_mois VARCHAR2(6) NOT NULL,
num_siege VARCHAR2(3) NOT NULL,
num_carte NUMBER(12) NOT NULL,
CONSTRAINT pk_place
PRIMARY KEY (num_vol,
jour_mois,num_siege));
CREATE TABLE vol (

code_oaci_dep VARCHAR2(4) NOT NULL,
code_oaci_arr VARCHAR2(4) NOT NULL,
heure_dep NUMBER(2) NOT NULL,
heure_emb NUMBER(2) NOT NULL,
heure_arriv NUMBER(2) NOT NULL,
min_emb NUMBER(2) NOT NULL,
min_dep NUMBER(2) NOT NULL,
min_arr NUMBER(2) NOT NULL,
CONSTRAINT pk_vol
PRIMARY KEY (num_vol));

Script SQL (suite)
CREATE TABLE volreel (

jour_mois VARCHAR2(6) NOT NULL,
num_porte VARCHAR2(3),
heure_dep_reel NUMBER(2),
heure_arr_reelle NUMBER(2),
min_dep_reel NUMBER(2),
min_arr_reelle NUMBER(2),
CONSTRAINT pk_volreel
PRIMARY KEY (num_vol,jour_mois));
CREATE TABLE planning (

jour_mois_planning NUMBER(3) NOT NULL,
CONSTRAINT pk_planning
PRIMARY KEY (num_vol,jour_mois_planning));
Le tableau suivant présente le script de création des clés étrangères et de destruction des tables,
index et contraintes.
Tableau A-2 : Création des clés étrangères et suppression des tables
Clés étrangères Suppression des objets
ALTER TABLE passager ALTER TABLE passager

ADD CONSTRAINT fk_passager_carte DROP CONSTRAINT fk_passager_carte;
FOREIGN KEY (code_fidelite) ALTER TABLE place
REFERENCES carte(code_fidelite); DROP CONSTRAINT fk_place_volreel;
ALTER TABLE place ALTER TABLE place
ADD CONSTRAINT fk_place_volreel DROP CONSTRAINT fk_place_pax;
FOREIGN KEY (num_vol, jour_mois) ALTER TABLE vol
REFERENCES volreel(num_vol, DROP CONSTRAINT fk_vol_arrivee;
jour_mois); ALTER TABLE vol
ALTER TABLE place DROP CONSTRAINT fk_vol_depart;
ADD CONSTRAINT fk_place_pax ALTER TABLE volreel
FOREIGN KEY(num_carte) DROP CONSTRAINT fk_volreel_vol;
REFERENCES passager(num_carte); ALTER TABLE planning
DROP CONSTRAINT fk_planning_vol;

Clés étrangères (suite) Suppression des objets (suite)
ALTER TABLE vol DROP TABLE aeroport CASCADE CONSTRAINTS;

ADD CONSTRAINT fk_vol_arrivee DROP TABLE carte CASCADE CONSTRAINTS;
FOREIGN KEY(code_oaci_arr) DROP INDEX detient_fk;
REFERENCES aeroport(code_oaci); DROP TABLE passager CASCADE CONSTRAINTS;
ALTER TABLE vol DROP INDEX reserver_fk;
ADD CONSTRAINT fk_vol_depart DROP INDEX composer_fk;
FOREIGN KEY(code_oaci_dep) DROP TABLE place CASCADE CONSTRAINTS;
REFERENCES aeroport(code_oaci); DROP INDEX arrivee_fk;
ALTER TABLE volreel DROP INDEX depart_fk;
ADD CONSTRAINT fk_volreel_vol DROP TABLE vol CASCADE CONSTRAINTS;
FOREIGN KEY(num_vol) DROP INDEX constituer_fk;
REFERENCES vol (num_vol); DROP TABLE volreel CASCADE CONSTRAINTS;
ALTER TABLE planning DROP INDEX planning_fk;
ADD CONSTRAINT fk_planning_vol DROP TABLE planning CASCADE
FOREIGN KEY(num_vol) CONSTRAINTS;
REFERENCES vol(num_vol);
Exercice 3.2 – La création de tables (horaires de bus)

Le tableau suivant présente le script de création des tables et index.
Tableau A-3 : Création des tables et index
Script SQL
CREATE TABLE horaire (

id_ligne NUMBER(2) NOT NULL, CREATE INDEX horaires_fk
id_jour NUMBER(1) NOT NULL, ON horaire (
id_sta NUMBER(3) NOT NULL, id_ligne ASC,
position NUMBER(2) NOT NULL, id_jour ASC,
heure NUMBER(2), id_sta ASC);
minute NUMBER(2),

Script SQL (suite)
CONSTRAINT pk_horaire PRIMARY KEY CREATE INDEX planning_annuel_fk

(id_ligne, id_jour, id_sta, position)); ON ligne_jour (id_ligne ASC);
CREATE TABLE jour ( CREATE INDEX planning_annuel_fk2

id_jour NUMBER(1) NOT NULL, ON ligne_jour (id_jour ASC);
lib_jour VARCHAR2(30), CREATE INDEX stations_fk
CONSTRAINT pk_jour PRIMARY KEY (id_jour)); ON ligne_jour_sta
CREATE TABLE ligne ( (id_ligne ASC,id_jour ASC);
id_ligne NUMBER(2) NOT NULL,
nom_ligne VARCHAR2(60), CREATE INDEX stations_fk2
CONSTRAINT pk_ligne PRIMARY KEY (id_ligne)); ON ligne_jour_sta (id_sta ASC);
CREATE TABLE ligne_jour (

id_jour NUMBER(1) NOT NULL,
CONSTRAINT pk_ligne_jour PRIMARY KEY
(id_ligne, id_jour));
CREATE TABLE ligne_jour_sta (

id_jour NUMBER(1) NOT NULL,
id_sta NUMBER(3) NOT NULL,
ordre NUMBER(2),
CONSTRAINT pk_ligne_jour_sta PRIMARY KEY
(id_ligne, id_jour, id_sta));
CREATE TABLE station (

id_sta NUMBER(3) NOT NULL,
nom_station VARCHAR2(25),
CONSTRAINT pk_station PRIMARY KEY(id_sta));
Le tableau suivant présente le script de création des clés étrangères et de destruction des tables, index et
contraintes.

Tableau A-4 : Création des clés étrangères et suppression des tables
Clés étrangères Suppression des objets
ALTER TABLE horaire

ADD CONSTRAINT fk_horaires_ligne_jo ALTER TABLE horaire
FOREIGN KEY (id_ligne, id_jour, id_sta) DROP CONSTRAINT
REFERENCES ligne_jour_sta (id_ligne, fk_horaires_ligne_jo;
id_jour,id_sta); ALTER TABLE ligne_jour
DROP CONSTRAINT
fk_ligne_jo_planning_jour;
ALTER TABLE ligne_jour
ADD CONSTRAINT
fk_ligne_jo_planning_jour DROP CONSTRAINT
fk_ligne_jo_planning_ligne;
FOREIGN KEY (id_jour)
ALTER TABLE ligne_jour_sta
REFERENCES jour (id_jour);
DROP CONSTRAINT
fk_ligne_jo_stations_ligne_jo;
ALTER TABLE ligne_jour_sta
ADD CONSTRAINT
DROP CONSTRAINT
fk_ligne_jo_planning_ligne
fk_ligne_jo_stations;
FOREIGN KEY (id_ligne)
REFERENCES ligne (id_ligne);
DROP INDEX horaires_fk;
DROP TABLE horaire CASCADE
ALTER TABLE ligne_jour_sta CONSTRAINTS;
ADD CONSTRAINT DROP TABLE jour CASCADE CONSTRAINTS;
fk_ligne_jo_stations_ligne_jo
DROP TABLE ligne CASCADE
FOREIGN KEY (id_ligne,id_jour) CONSTRAINTS;
REFERENCES ligne_jour (id_ligne, DROP INDEX planning_annuel_fk2;
id_jour);
DROP INDEX planning_annuel_fk;
DROP TABLE ligne_jour CASCADE
ALTER TABLE ligne_jour_sta CONSTRAINTS;
ADD CONSTRAINT fk_ligne_jo_stations DROP INDEX stations_fk2;
FOREIGN KEY (id_sta) DROP INDEX stations_fk;
REFERENCES station (id_sta); DROP TABLE ligne_jour_sta CASCADE
CONSTRAINTS;
DROP TABLE station CASCADE
CONSTRAINTS;

Exercice 3.3 – La programmation de contraintes
Le tableau suivant présente les contraintes à programmer pour implémenter les différentes
règles métier.
Tableau A-5 : Programmation des règles métier (carte d’embarquement)
Règles métier Contraintes SQL

Pour tout vol présent au catalogue, l’aéroport ALTER TABLE vol
de départ est différent de celui d’arrivée. ADD CONSTRAINT ck_vol_dep_arr
CHECK (NOT(code_oaci_arr = code_oaci_dep));
Le nom des types de cartes est unique. ALTER TABLE carte
ADD CONSTRAINT un_lib_carte
UNIQUE (lib_fidelite);
Les données dans les colonnes heures et ALTER TABLE vol
minutes prévisionnelles doivent être valides ADD CONSTRAINT ck_heures_min_dep_emb_arr
(entre 0 et 23 pour les heures, tous les quarts CHECK ((heure_dep BETWEEN 0 AND 23)
d’heure pour les minutes).
AND (heure_emb BETWEEN 0 AND 23)
AND (heure_arriv BETWEEN 0 AND 23)
AND (min_emb IN (0,15,30,45))
AND (min_dep IN (0,15,30,45))
AND (min_arr IN (0,15,30,45)));
Les heures de départ sont inférieures d’au ALTER TABLE vol
moins une heure à celles d’arrivée. ADD CONSTRAINT ck_dep_1h_avant_arr
CHECK ((heure_dep+min_dep/100)+1
<= (heure_arriv+min_arr/100));
Horaires des bus

règles métier.
Tableau A-6 : Programmation des règles métier (lignes de bus)

Pas plus de 3 libellés journaliers sont admis ALTER TABLE jour
(qui valent par ailleurs « Lundi à vendredi », ADD CONSTRAINT nb_libelle_jour
« Samedi » et « Dimanche et jours fériés »). CHECK (id_jour IN (1,2,3));

Règles métier (suite) Contraintes SQL (suite)

Chaque ligne n’est pas forcément planifiée tous L’existence de la table de référence ligne_jour permettra
les types de jours. de stocker les couples valides. Les données relatives aux
stations et aux horaires référencent en cascade cette table par
l’intermédiaire de clés étrangères.
Il n’y a pas plus de 15 stations sur un même trajet. ALTER TABLE ligne_jour_sta
ADD CONSTRAINT nb_stations_trajet
CHECK (ordre BETWEEN 1 AND 15);
Les horaires sont à afficher sous la forme hh.min ALTER TABLE horaire
(avec hh de 6 à 22 et min de 0 à 59).
ADD CONSTRAINT ck_format_horaires
CHECK ((heure BETWEEN 6 AND 22)
AND (minute BETWEEN 0 AND 59));
Il n’y a pas plus de 8 colonnes d’horaires à ALTER TABLE horaire
afficher.
ADD CONSTRAINT nb_colonnes_horaires
CHECK (position BETWEEN 1 AND 8);
E-mails des clients et prospects

règles métier. La dernière règle ne peut pas s’implémenter par une contrainte de vérification,
car elle concerne des données de plusieurs tables. Un déclencheur Oracle est proposé dans
cette solution, mais ces tests peuvent également se programmer dans une procédure catalo-
guée dédiée.
Tableau A-7 : Programmation des règles métier (les e-mails)

Une adresse e-mail est unique dans La clé primaire de la table mails (l’adresse e-mail) suffit à implémenter cette
la base de données. règle.
Un client n’est pas un prospect, et ALTER TABLE mails

réciproquement.
ADD CONSTRAINT ck_prospect_client
CHECK ((id_cli IS NOT NULL AND id_pros IS NULL)
OR (id_cli IS NULL AND id_pros IS NOT NULL));
Un prospect ne peut ne pas détenir ALTER TABLE mails
plusieurs adresses e-mails (une
ADD CONSTRAINT un_mail_prospect
maximum).
UNIQUE (id_pros);

Règles métier (suite) Contraintes SQL (suite)

Un client peut détenir au maximum ALTER TABLE mails
3 adresses e-mails.
ADD num_mail NUMBER(1,0);
ALTER TABLE mails
ADD CONSTRAINT ck_3_mails_client
CHECK (num_mail IN (1,2,3));
ALTER TABLE mails
ADD CONSTRAINT un_3_mails_client
UNIQUE (id_cli,num_mail);
Seuls les clients arrivés depuis plus ALTER TABLE mails
de 4 ans peuvent détenir jusqu’à
DROP CONSTRAINT ck_3_mails_client;
5 adresses e-mails.
CREATE TRIGGER tri_3_ou_5_mails_client
BEFORE INSERT OR UPDATE OF id_cli
ON mails FOR EACH ROW
DECLARE
numero INTEGER;
v_date_arrivee DATE;
BEGIN
SELECT date_arrivee INTO v_date_arrivee
FROM clients WHERE id_cli = :NEW.id_cli;
-- client depuis moins de 4 ans
IF (ADD_MONTHS(v_date_arrivee,48)>SYSDATE) THEN
IF (:NEW.num_mail > 3) THEN
RAISE_APPLICATION_ERROR
(-20001,'Le client est limité à 3 mails...');
END IF;
ELSE
-- client depuis plus de 4 ans
IF (:NEW.num_mail > 5) THEN
RAISE_APPLICATION_ERROR
(-20002,'Le client est limité à 5 mails...');
END IF;
END IF;
EXCEPTION
-- la clé étrangère va faire son boulot
NULL;
END;

Exercice 3.4 – La dénormalisation
Le nombre de vols déjà effectués par tout passager est implémenté par un compteur dans la
table des passagers. Les données additionnelles à prendre en compte (prix de chaque vol, noms
de la compagnie et des aéroports, ainsi que l’indicateur de places disponibles) sont à disposer
dans la table des vols réels. Seules les tables qui sont impactées sont présentées dans la figure
suivante.
Figure A-41. Schéma relationnel dénormalisé
Horaires des bus

Le schéma relationnel dénormalisé et minimal est le suivant. L’avantage est qu’il fait intervenir
peu de tables. De plus, il sera de volumétrie réduite par rapport à son homologue normalisé du
fait de la fusion des tables concernant l’ordre des stations et la position des horaires.

Figure A-42. Schéma relationnel dénormalisé
Les inconvénients sont les suivants.

●● Aucun contrôle possible de la cohérence des bus et des jours de sortie.
●● Aucun contrôle possible de la cohérence de la composition des stations sur une ligne de bus
pour un jour de sortie.

●● Redondances au niveau de la colonne ordre (dont les valeurs vont se répéter pour tous les
horaires d’un jour sur une station donnée et pour toutes les lignes).
Exercice 3.5 – Ma psy oublie tout
Rendez-vous
●● La classe Rendez_vous modélise le « Qui est venu la voir et à quelle heure ».
●● La classe Population recense la classification enfant, ado, femme, homme ou couple.
Chaque patient est associé à une classification à un instant donné, mais peut consulter dans
différents contextes au cours de sa vie.
●● La classe Connaissance recense les différents moyens de connaissance (bouche à oreille,
autre patient, docteur, etc.).
●● Le retard du patient dépend de ses rendez-vous.
●● Le nombre maximum de 3 personnes durant la consultation apparaît dans l’association
entre un patient et son rendez-vous.
●● Le mode de réglement de la séance dépend de chaque rendez-vous.
●● L’anxiété est éventuellement notée pour un rendez-vous et un patient donnés.

●● La profession et la liste des prénoms des personnes familières au patient se traduisent par
de simples associations binaires.
●● Les mots-clés, postures affichées et comportements qui sont observés dépendent de chaque
rendez-vous.
Figure A-43. Les rendez-vous des patients
Confrères et livres
●● Les confrères et professions donnent lieu à la création de classes associées.
●● Les rendez-vous avec ses confrères et les consultations externes de ses patients utilisent la
même classe : Rendez_vous.

●● Les circonstances de la première rencontre avec chacun des spécialistes donnent lieu à la
création d’une classe.
●● Le prêt de livres est modélisé avec la classe-association Retour qui ne permet pas de gérer
un historique par ailleurs.
Figure A-44. Les rendez-vous de ma psy et ses prêts littéraires
Exercice 3.6 – Le planning d’une école de pilotage
Flotte
Il est nécessaire de distinguer les aéronefs en tant qu’objets concrets (l’aéronef réel) et qu’objets
abstraits (type d’avion). La puissance et le prix horaire caractérisent l’objet abstrait. L’immatri-
culation identifie un objet réel qui est caractérisé par un nombre d’heures de vol de la cellule
et du moteur.
Une visite de maintenance peut être identifiée par une date et l’immatriculation de l’appa-
reil visité. Chaque visite concerne un plan de maintenance (nombre d’heures d’utilisation) et
nécessite la commande de plusieurs pièces qui sont achetées à un prix qui peut évoluer dans
le temps.

Figure A-45. La flotte de l’école de pilotage
Acteurs
L’héritage permet de distinguer un élève pilote d’un instructeur. Le prix dépend du type
d’avion utilisé. Chaque séance de vol concerne un élève pilote, un avion et, éventuellement, un
instructeur. Chaque visite médicale est identifiée par la date et le numéro du membre.
Figure A-46. Les acteurs de l’école de pilotage

Rendez-vous
La classe créneau désigne d’une manière générique soit une réservation concernant un avion,
un élève et, éventuellement, un instructeur, soit un intervalle d’indisponibilités qui ne concerne
qu’un avion.
Figure A-47. Le planning de l’école de pilotage

Annexe B
Ressources
Webographie
Outils de génération SQL étudiés

Enterprise Architect : http://www.sparxsystems.com.au/products/ea.html
MagicDraw UML : http://www.magicdraw.com
MEGA Designer : http://www.mega.com/en/product/mega_designer/index.asp?l=en
Objecteering : http://www.objecteering.com
PowerAMC : http://www.sybase.fr/products/modelingdevelopment/poweramc
Rational Rose : http://www.ibm.com
Visual Paradigm : http://www.visual-paradigm.com/product/vpuml/
Win’Design : http://www.win-design.com/fr/
Icônes utilisées dans cet ouvrage

http://www.iconarchive.com
Théorie de la normalisation de François de Sainte-Marie

http://fsmrel.developpez.com/basesrelationnelles/normalisation/

Cours OCL de Marianne Huchard

http://www.lirmm.fr/~huchard/Enseignement/IDM/coursOCL20.pdf
SQL de A à Z par Frédéric Brouard

http://sqlpro.developpez.com
Bibliographie
[AUD 09] L. Audibert, UML 2 : de l’apprentissage à la pratique, Ellipses Marketing, 2009.
[ADI 93] M. Adiba, C. Collet, Objets et Bases de données, le SGBD O2, Hermès, 1993.
[ATK 89] M. Atkinson, F. Bancilhon, D. de Witt, K. Dittrich, D. Maier, S. Zdonik,
« The Object-Oriented database manifesto », Proceedings of the Conference Deductive and
Object-Oriented DataBases, 1989.
[BOU 99] N. Boudjilda, Bases de données et systèmes d’informations, le modèle relationnel :
langages, systèmes et méthodes, Dunod, 1999.
[BRO 10] F. Brouard, R. Bruchez, C. Soutou, SQL, 3e édition, Pearson Education, 2010.
[CHE 76] P. P. Chen, « The Entity-Relationship Model: Towards a Unified View of Data »,
ACM Transactions on Database Systems, Vol. 1, N° 1, 1976.
[COD 70] E. F. Codd, « A Relational Model for Large Shared Data Banks », Communications
of the ACM, Vol 13, N° 6, 1970.
[COD 72] E. F. Codd, « Further Normalization of the Data Base Relational Model », Data
Base Systems, Courant Computer Science Symposia Series 6, Prentice Hall, 1972.
[DEL 91] C. Delobel, C. Lécluse, P. Richard, Bases de données : des systèmes relationnels
aux systèmes à objets, InterEditions, 1991.
[DEL 00] P. Delmal, SQL2-SQL3, Applications à Oracle, De Boeck Université, 2000.
[FAG 81] R. Fagin, « A Normal Form for Relational Databases That Is Based on Domains and
Keys », ACM Transactions on Database Systems, Vol 6, N° 3, 1981.
[MAK 08] G. Maksay, Y. Pigneur, Modéliser par l’exemple, Presses polytechniques et uni-
versitaires romandes, 2008.
[MAR 94] C. Maree, G. Ledant, SQL 2 Initiation Programmation, Armand Colin, 1994.
[MOU 76] P. Moulin, J. Randon, S. Savoysky, S. Spaccapietra , H. Tardieu , M. Teboul,
« Conceptual model as database design tool », Proceedings of the IFIP Working conference
on Modelling in Database Management Systems , G.M. Nijssen Ed., North-Holland, 1976.

ANNEXE B Ressources
[MUL 99] R. J. Muller, Database Design for Smarties, Using UML for Data Modeling,
Morgan-Kaufman, 1999.
[MUL 00] P. A. Muller, N. Gaertner, Modélisation objet avec UML, Eyrolles, 2e édition,
2000.
[NAN 01] D. Nanci, B. Espinasse, B. Cohen, Ingénierie des systèmes d’information : Merise
deuxième génération, Vuibert, 4e édition, 2001.
[SOU 08] C. Soutou, Programmer Objet avec Oracle, 2e édition, Vuibert, 2008.
[TAR 79] H. Tardieu, D. Nanci, D. Pascot, « A Method, A Formalism and Tools for Database
Design (three years of Experimental Practice) », Proceedings of the International Conference
on Entity-Relationship Approach to Systems Analysis and Design, 1979.
[VAL 87] P. Valduriez, « Objets complexes dans les systèmes de bases de données relation-
nels », Techniques et science informatique, Vol. 6, N° 5, 1987.
[WAR 03] J.Warmer, A. Kleppe, « The Object Constraint Language: Getting Your Models
Ready for MDA », Addison-Wesley, 2003.

Index
A un-à-un 28
modèle relationnel 118, 119
abîme 69
SQL 158
agrégat 52
attribut 20
agrégation 51
atomique 66
composition 52
modèle relationnel 120 calculé 68
partagée 52 modèle relationnel 112
allInstances 80 monovalué 84
ALTER TABLE 155 multivalué 83
temporel 60
AMC*Designor 257
association 20
agrégation 51 B
binaire 28
bag 76
dérivée 72
héritage 58 base de données
n-aire 41 hiérarchique 2
navigable 72 relationnelle 4
plusieurs-à-plusieurs 29 réseau 4
modèle relationnel 117 BCNF 88
SQL 161 BUILD IMMEDIATE 223
qualifiée 72
réflexive 34
SQL 159
C
un-à-plusieurs 29 cardinalité 30
modèle relationnel 117 cast 229
SQL 157 CHECK 155

UML 2 pour les bases de données Index
Chen 18 E
chronologie 61
ENABLE QUERY REWRITE 223
classe 20, 22
entité 20
classe-association 37 exclusivité 79
modèle relationnel 121
réflexive 40
F
clé étrangère 112
FOREIGN KEY 155
clé primaire 112
forme normale
COBOL 2
Boyce-Codd 88, 139
Codd 18, 112
cinquième 89, 142
collection 227 deuxième 84, 136
composition 52 domaine-clé 89, 141
SQL 161 première 83, 133
contraintes quatrième 89, 142
OCL 76 troisième 86, 138
SQL 154
CREATE TABLE 155 H
héritage 58
D distinction 121
database 152
push-down 121
déclencheur 166 push-up 121
dénormalisation 180, 218 SQL 165
dépendance historisation 62
directe 87, 133
élémentaire 85, 132 I
fonctionnelle 81
identifiant 23
alternatif 28
multivaluée 142
artificiel 26
dépendant 131 naturel 25
déterminant 131 identification artificielle 56
disjoint 79 incomplete 79
DKNF 89 intégrité référentielle 214

Index UML 2 pour les bases de données
isEmpty 76 O
isUnique 80
Objecteering 253
OCL 76
K oclIsKindOf 80
key preserved 205 OID 227
OLAP 5
OLTP 5
L
ON NESTED TABLE 240
libellé 23 ordered 76
overlapping 79
M
MagicDraw 244 P
materialized view 221 PARENT 240
materialized view log 224 partition 79
MCD 19 PowerAMC 16, 257
MEGA 245 PowerDesigner 257
Merise/2 19 PRIMARY KEY 155
méthode 231 privilège 208
modèle entité-association 18 proposition incomplète 64
modèle relationnel 112 propriété 20
Modelio 249
Morejon 53
R
multiplicité 30
rafraîchissement 222
multiset 229
RAISE_APPLICATION_ERROR 167
Rational Rose 114, 262
N redefined 76
nested table 228 REFERENCING 240
NIAM 19 réification 54
NO_DATA_FOUND 167 relation 112
normalisation 129 Rochfeld 53
NOT NULL 117, 156 rôle 36

UML 2 pour les bases de données Index
S UNIQUE 155
UPPER 206
schéma 152
user 152
schéma conceptuel 11
SELF 231
sequence 76 V
seq 76
varray 228
snapshot 221
ventilateur 68
SQL 151
Visual Paradigm 265
SQL2 151
volumétrie 144
SQL3 151
vue
subsets 75
complexe 198
SQL 174
matérialisée 221
substantification 54
modifiable 203
monotable 200
T multitable 202
table objet 226
d’association 117 simple 198
de jointure 117
key preserved 205
W
Tardieu 18
totalité 79 Win’Design 53, 266
transitivité 70 WITH CHECK OPTION 198, 204, 233
type 228 WITH OBJECT IDENTIFIER 227
WITH READ ONLY 198
U
UML 5
X
profil 262 xor 75
union 76 SQL 176

Pour Les De: Bases Données

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Pour Les De: Bases Données

Transféré par

Droits d'auteur :

Formats disponibles

soutou 15/02/12 11:31 Page 1

Christian Soutou est maître de conférences à l'université Toulouse II et consultant indépendant.

UML 2 pour les bases de données

Concevoir une base de données grâce à UML 2

Christian Soutou est maître de conférences à l'université Toulouse II et consultant indépendant.

UML 2 pour les bases de données

Concevoir une base de données grâce à UML 2

C. Soutou. – SQL pour Oracle (5e édition).

C. Soutou. – Programmer avec MySQL.

P. Roques. – Mémento UML 2.4 (2e édition).

P. Roques. – UML 2 par la pratique (7e édition).

P. Roques. – UML 2 par la pratique (6e édition).

P. Roques et F. Vallée. – UML 2 en action (4e édition).

F. Vallée. – UML pour les décideurs.

P. Roques. – Mémento PHP 5 et SQL (2e édition).

p2 Soutou.indd 1 15/02/12 09:13

Copyright Soutou.indd 1 15/02/12 09:12

Livre SOUTOU.indb 3 15/02/12 07:04

Livre SOUTOU.indb 5 15/02/12 07:04

Livre SOUTOU.indb 6 15/02/12 07:04

2 Le niveau logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  111

© Éditions Eyrolles VII

Livre SOUTOU.indb 7 15/02/12 07:04

Transformation des associations un-à-plusieurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  117

3 Le niveau physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  151

VIII © Éditions Eyrolles

Livre SOUTOU.indb 8 15/02/12 07:04

4 Le niveau externe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  195

5 Les outils du marché : de la théorie à la pratique. . . . . . . . . . . . . . . . . . . . . . . .  243

Livre SOUTOU.indb 9 15/02/12 07:04

A Corrigés des exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  273

Livre SOUTOU.indb 10 15/02/12 07:04

Exercice 1.3 – Les lignes de facture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  278

Livre SOUTOU.indb 11 15/02/12 07:04

Exercice 3.1 – La création de tables (carte d’embarquement) . . . . . . . . . . . . . . . . . . . .  300

XII © Éditions Eyrolles

Livre SOUTOU.indb 12 15/02/12 07:04

Évolution des modèles de données

Figure 0-1. Historique des bases de données

Livre SOUTOU.indb 1 15/02/12 07:04

Les fichiers et COBOL

Figure 0-2. Modèle de données hiérarchique

Livre SOUTOU.indb 2 15/02/12 07:04

possible, à moins d’ajouter une compagnie fictive.

Figure 0-3. Modèle de données réseau

Livre SOUTOU.indb 3 15/02/12 07:04

Figure 0-4. Modèle de données relationnel

Livre SOUTOU.indb 4 15/02/12 07:04

À qui s’adresse cet ouvrage ?

Comment utiliser UML pour les bases de données ?

Livre SOUTOU.indb 5 15/02/12 07:04

Livre SOUTOU.indb 6 15/02/12 07:04

Cet ouvrage vous permettra, je l’espère, de mieux appréhender le cheminement de la concep-

Figure 0-5. Diagramme de classes

Livre SOUTOU.indb 7 15/02/12 07:04

Figure 0-6. Niveaux de conception et d’implémentation

Livre SOUTOU.indb 8 15/02/12 07:04

Écriture des scripts SQL et programmation des contraintes

Les vues SQL2 et SQL3

Les outils du marché

Livre SOUTOU.indb 9 15/02/12 07:04

Ce pictogramme introduit une définition, un concept ou une remarque importante.

 Ce pictogramme indique une astuce ou un conseil personnel.

2 Le niveau logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Transformation des associations un-à-plusieurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

3 Le niveau physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

4 Le niveau externe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

5 Les outils du marché : de la théorie à la pratique. . . . . . . . . . . . . . . . . . . . . . . . 243

A Corrigés des exercices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Exercice 1.3 – Les lignes de facture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

Exercice 3.1 – La création de tables (carte d’embarquement) . . . . . . . . . . . . . . . . . . . . 300

Ce pictogramme indique une astuce ou un conseil personnel.