Bases de données orientéesobjet

-

Livres
355 pages
Lire un extrait
Obtenez un accès à la bibliothèque pour le consulter en ligne
En savoir plus

Description

Cet ouvrage approfondit les concepts des bases de données orientées-objet et présente une vision détaillée de leur mise en œuvre. Illustrant la mise en pratique des différents concepts objet dans le monde des bases de données, il propose une vision générique des principales thématiques intéressant les systèmes de gestion de bases de données orientées-objet :
la modélisation NF2,
la spécification des propriétés statiques et comportementales via les graphes de types, le langage de requête SQL-Objet,
les mécanismes d'héritage aux niveaux conceptuel et implantation, le concept de vues relationnelles-objet.
Bases de données orientées-objet comporte de nombreux exercices résolus avec variantes pédagogiques et solutions d'implantation en contexte relationnel-objet ainsi que des exercices génériques pouvant être réutilisés dans d'autres contextes.
Chapitre 1. Introduction. Chapitre 2. Modèle NF2 : Non First Normal Form. Chapitre 3. Spécification des propriétés statiques. Chapitre 4. Spécification des propriétés comportementales. Chapitre 5. Le langage de requêtes SQL-Objet. Chapitre 6. Héritage. Chapitre 7. Vues relationnelles-objet. Chapitre 8. Exercices corrigés. Chapitre 9. Travaux pratiques corrigés. Chapitre 10. Exercices complémentaires sans corrigé. Bibliographie. Index.

Sujets

Informations

Publié par
Date de parution 22 février 2011
Nombre de lectures 30
EAN13 9782746241657
Langue Français

Informations légales : prix de location à la page 0,0532€. Cette information est donnée uniquement à titre indicatif conformément à la législation en vigueur.

Signaler un problème








Bases de données orientées-objet



































© LAVOISIER, 2011
LAVOISIER
11, rue Lavoisier
75008 Paris

www.hermes-science.com
www.lavoisier.fr

ISBN 978-2-7462-3152-8
ISSN 1242-7691


Le Code de la propriété intellectuelle n'autorisant, aux termes de l'article L. 122-5, d'une part,
que les "copies ou reproductions strictement réservées à l'usage privé du copiste et non
destinées à une utilisation collective" et, d'autre part, que les analyses et les courtes citations
dans un but d'exemple et d'illustration, "toute représentation ou reproduction intégrale, ou
partielle, faite sans le consentement de l'auteur ou de ses ayants droit ou ayants cause, est
illicite" (article L. 122-4). Cette représentation ou reproduction, par quelque procédé que ce
soit, constituerait donc une contrefaçon sanctionnée par les articles L. 335-2 et suivants du
Code de la propriété intellectuelle.
Tous les noms de sociétés ou de produits cités dans cet ouvrage sont utilisés à des fins
d’identification et sont des marques de leurs détenteurs respectifs.


Printed and bound in England by Antony Rowe Ltd, Chippenham, February 2011.






Bases de données


orientées-objet


concepts, mise en œuvre et exercices résolus







Claude Chrisment

Guillaume Cabanac
Karen Pinel-Sauvagnat

Olivier Teste

Michel Tuffery






Collection dirigée par Jean-Charles Pomerol




CAFERRA Ricardo – Logique pour l’informatique et pour l’intelligence artificielle,
2010
GUILLOT Philippe – Courbes elliptiques : une présentation élémentaire pour la
cryptographie, 2010.
CHRISMENT Claude et al. – Bases de données relationnelles, 2008.
BANATRE Michel et al. – Informatique diffuse, 2007.
BARTHELEMY Pierre, ROLLAND Robert et VERON Pascal – Cryptographie, 2005.
CARDON Alain – La complexité organisée : systèmes adaptatifs, 2004.
FOURNIER Jean-Claude – Théorie des graphes et applications, 2005.
PARIS Stéphane – Le multimédia et la compression, 2009.
PARIS Stéphane – Le multimédia, 2009.
PIERSON Jacky – La biométrie, 2007.
POLI Alain et GUILLOT Philippe – Algèbre, confidentialité et intégrité en
multimédia, 2009.
POLI Alain et GUILLOT Philippe – Algèbre et protection de l’information, 2005.
VARRETTE Sébastien et BERNARD Nicolas – Programmation avancée en C
avec exercices corrigés, 2006.
VERDRET Philippe – De Perl à Java : programmation des expressions régulières,
2004.
type
alter
type
drop
create
type
Table des matières
Avant-Propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Chapitre 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2Chapitre 2. Modèle NF : Non First Normal Form . . . . . . . . . . . . . . . 21
2.1. Modélisation, formalisation . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2. Extension de l’algèbre : les opérateurs NEST et UNNEST . . . . . . . 23
22.3. Passage du modèle relationnel au modèle NF . . . . . . . . . . . . . . 24
2.3.1. Exemple et problématique . . . . . . . . . . . . . . . . . . . . . . 24
2.3.2. Règles concernant les contraintes d’imbrication . . . . . . . . . . 30
22.4. Exemple de modélisation NF . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.1. Modélisation relationnelle, schéma relationnel . . . . . . . . . . . 32
22.4.2.ation NF . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Chapitre 3. Spécification des propriétés statiques . . . . . . . . . . . . . . . 41
3.1. Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2. Identifiant d’objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3. Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4. Modélisation de classes et représentation graphique . . . . . . . . . . . 45
3.4.1. Modélisation initiale . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4.2. Graphe de Types Simple (GTS) et Étendu (GTÉ) . . . . . . . . . 47
3.4.3. de types étendu avec bi-référencement . . . . . . . . . . . 48
3.4.4. Référencements croisés . . . . . . . . . . . . . . . . . . . . . . . . 49
3.5. Langage de définition de données . . . . . . . . . . . . . . . . . . . . . 49
3.5.1. Manipulation de types . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.5.1.1. Création de type : . . . . . . . . . . . . . . . . 50
3.5.1.2. Modification de type : . . . . . . . . . . . . . . 51
3.5.1.3. Suppression de type : . . . . . . . . . . . . . . . 51
3.5.1.4. Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.5.2. Manipulation de tables . . . . . . . . . . . . . . . . . . . . . . . . 55insert
value,
alter
type
add
attribu
te
delete
nested
table
varray
m
o
r
f
deref
update
ref,
6 Bases de données orientées-objet
3.5.2.1. Création de tables . . . . . . . . . . . . . . . . . . . . . . . . 55
3.5.2.2. Suppression de tables . . . . . . . . . . . . . . . . . . . . . . 55
3.5.2.3. Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.6. Langage de manipulation de données . . . . . . . . . . . . . . . . . . . 55
23.6.1. Création de tuples NF : . . . . . . . . . . . . . . . . . . . 56
3.6.1.1. Insertion de tuple simple – premier niveau . . . . . . . . . . 56
23.6.1.2. de tuple NF . . . . . . . . . . . . . . . . . . . . . . 56
3.6.1.3. Insertion de tuple dans une table imbriquée . . . . . . . . . . 56
23.6.2. Modification de tuples NF : . . . . . . . . . . . . . . . . 56
3.6.2.1. de tuple simple – premier niveau . . . . . . . . 56
3.6.2.2. Modification de tuple dans une table imbriquée . . . . . . . 57
3.6.2.3. Valorisation d’attributs avec 57
23.6.3. Suppression de tuples NF : . . . . . . . . . . . . . . . . . 57
3.6.3.1. Suppression de tuple simple – premier niveau . . . . . . . . 57
3.6.3.2. de tuple dans une table imbriquée . . . . . . . . 57
Chapitre 4. Spécification des propriétés comportementales . . . . . . . . . 59
4.1. d’une signature . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2. Spécification du corps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.1. Exemple 1 : méthode avec manipulation de collection (
, ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.2. Exemple 2 : méthode avec balayage de collection . . . . . . . . . 64
4.2.3. Exemple 3 : méthode avec paramètres et utilisation de références 65
4.2.4. Ex 4 : avec balayage de collection et utilisation de
références . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.2.5. Exemple 5 : méthode récursive . . . . . . . . . . . . . . . . . . . . 67
re4.2.5.1. 1 approche . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
e4.2.5.2. 2 approche : prise en compte du concept d’encapsulation . 68
e4.2.5.3. 3 approche : réutilisation de la méthode pour les parcelles
divisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
e4.2.5.4. 4 approche : spécification généralisée sans récursivité . . . 70
e4.2.5.5.5 approche:spécificationgénéraliséeimpliquantlarécursivité . 71
4.2.6. Exemple 6 : méthode avec procédure . . . . . . . . . . . . . . . . 72
4.3. Encapsulation et conception par niveaux d’abstraction . . . . . . . . . 72
Chapitre 5. Le langage de requêtes SQL-Objet . . . . . . . . . . . . . . . . . 79
5.1. Premier niveau : requêtes simples . . . . . . . . . . . . . . . . . . . . . 79
5.2. Deuxième niveau : utilisation de fonctions prédéfinies sur les objets
( ) . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.3. Troisième niveau : jointures hiérarchiques basées sur l’imbrication . . 86
5.4. Quatrième niveau : requêtes sur sous-tables/tables imbriquées . . . . . 87
5.5. Cinquième niveau : manipulation de sous-tables avec curseurs . . . . . 91
5.6. Sixièmeniveau:manipulationalgébriquedetablesdanslaclause . 93of
instead
Table des matières 7
Chapitre 6. Héritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.1. Généralisation et spécialisation du point de vue méthodologique . . . . 97
6.1.1. Généralisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.1.2. Spécialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.1.3. Exemple simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.2. L’héritage du point de vue « système » . . . . . . . . . . . . . . . . . . 99
6.2.1. Taxinomie des graphes de types . . . . . . . . . . . . . . . . . . . 100
6.2.2. Héritagesimple:exempledelagestiondupersonneldel’université . 100
6.2.3. Héritage multiple / répété . . . . . . . . . . . . . . . . . . . . . . . 103
6.3. Mise en œuvre dans le contexte Oracle . . . . . . . . . . . . . . . . . . 106
6.3.1. Spécification de l’héritage . . . . . . . . . . . . . . . . . . . . . . 106
6.3.2. Implantation de en relationnel-objet . . . . . . . . . . . 107
6.3.2.1. Spécification SQL pour l’implantation aplatie
(relationnelobjet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.3.2.2.SpécificationSQLpourl’implantationverticale(relationnel) . 111.
6.3.2.3.Spécification SQL pour l’implantation horizontale
(relationnelobjet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.4. Héritage de méthodes : concept de redéfinition . . . . . . . . . . . . . . 113
6.5. Méta-classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Chapitre 7. Vues relationnelles-objet . . . . . . . . . . . . . . . . . . . . . . . 119
7.1. Introduction : quelques rappels sur les vues . . . . . . . . . . . . . . . . 119
7.1.1. Types de vues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
7.1.2. Déclencheur « » . . . . . . . . . . . . . . . . . . . . 120
7.1.3. Exemple de vue simple . . . . . . . . . . . . . . . . . . . . . . . . 121
7.1.4. Ex de vue complexe avec pseudo-jointure . . . . . . . . . . 121
7.1.5. Exemple de vuexe . . . . . . . . . . . . . . . . . . . . . . 122
7.2. Vues relationnelles-objet sur relations . . . . . . . . . . . . . . . . . . . 123
7.2.1. Commande de création d’une vue relationnelle-objet . . . . . . . 123
7.2.2. Exemple de vues relationnelles-objet . . . . . . . . . . . . . . . . 124
7.2.2.1. Étape 0 : point de départ . . . . . . . . . . . . . . . . . . . . 124
7.2.2.2. Étape 1 : spécification des types objet . . . . . . . . . . . . . 125
7.2.2.3. Étape 2 : création des vues relationnelles-objet . . . . . . . . 128
7.3. Utilisation de vues relationnelles-objet . . . . . . . . . . . . . . . . . . 129
7.3.1. Interrogation des vues . . . . . . . . . . . . . . . . . . . . . . . . . 130
7.3.2. Insertion via les vues . . . . . . . . . . . . . . . . . . . . . . . . . 133
7.3.3. Insertion via les collections imbriquées des vues . . . . . . . . . . 135
7.3.4. Mises à jour généralisées via les vues . . . . . . . . . . . . . . . . 136
7.4. Vues relationnelles-objet sur vues . . . . . . . . . . . . . . . . . . . . . 138
7.5. Vues et héritage . . . . . . . . . . . . . . . . . . . . 139
7.5.1. Construction d’une hiérarchie de vues relationnelles-objet . . . . 139
7.5.2. Interrogation d’une hiérarchie de vues . . . . 144
7.5.3. Mises à jour d’une hiérarchie de vues . . . . 1468 Bases de données orientées-objet
Chapitre 8. Exercices corrigés . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
8.1. Exercice 1 : caisse de congés payés du bâtiment . . . . . . . . . . . . . 149
8.2. Exercice2:gestiondesdéplacementspourlespersonnelsd’unesociété . 158
8.3. Exercice 3 : syndic de gestion de copropriété . . . . . . . . . . . . . . . 175
8.4. Exercice 4 : gestion de tâches . . . . . . . . . . . . . . . . . . . . . . . . 189
8.5. Exercice 5 : de stock (concept d’héritage) . . . . . . . . . . . . 207
8.6. Exercice 6 : gestion d’un système d’information d’usagers du métro . . 240
Chapitre 9. Travaux pratiques corrigés . . . . . . . . . . . . . . . . . . . . . 263
9.1. Travaux pratiques 1 : gestion du cadastre . . . . . . . . . . . . . . . . . 263
9.1.1. TP1 : création de la BDOR . . . . . . . . . . . . . . . . . . . . . . 264
9.1.1.1. Création . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
9.1.1.2. Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
9.1.1.3. Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
9.1.2. TP 2 : développement de méthodes . . . . . . . . . . . . . . . . . 270
9.1.2.1. Méthodes DISTANCE . . . . . . . . . . . . . . . . . . . . . . 271
9.1.2.2. Méthode VOISINE . . . . . . . . . . . . . . . . . . . . . . . . 273
9.1.2.3. Méthodes PERIMETRE . . . . . . . . . . . . . . . . . . . . . 274
9.1.2.4. SURFACE . . . . . . . . . . . . . . . . . . . . . . . 276
9.1.3. TP 3 : interrogation de la base . . . . . . . . . . . . . . . . . . . . 278
9.1.3.1. Requêtes mono-table . . . . . . . . . . . . . . . . . . . . . . 278
9.1.3.2. avec méthodes . . . . . . . . . . . . . . . . . . . . 280
9.1.3.3. Requêtes sur collections (tables) imbriquées . . . . . . . . . 281
9.1.3.4. multi-table . . . . . . . . . . . . . . . . . . . . . . . 283
9.1.4. TP 4 : héritage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
9.1.4.1. Création du schéma . . . . . . . . . . . . . . . . . . . . . . . 286
9.1.4.2. Peuplement de la base . . . . . . . . . . . . . . . . . . . . . . 288
9.1.4.3. Méthodes SURFACE . . . . . . . . . . . . . . . . . . . . . . . 291
9.1.4.4. Requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
9.1.5. TP 5 : vues relationnelles-objet . . . . . . . . . . . . . . . . . . . . 294
9.1.5.1. Mise en place de la base relationnelle . . . . . . . . . . . . . 294
9.1.5.2. Création des vues R0 . . . . . . . . . . . . . . . . . . . . . . 296
9.1.5.3. Interrogation des vues R0 . . . . . . . . . . . . . . . . . . . . 298
9.1.5.4. Vues R0 actives . . . . . . . . . . . . . . . . . . . . . . . . . 299
9.2. Travaux pratiques 2 : GPS . . . . . . . . . . . . . . . . . . . . . . . . . 302
9.2.1. TP1 : création de la BDOR . . . . . . . . . . . . . . . . . . . . . . 304
9.2.1.1. Création . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
9.2.1.2. Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
9.2.1.3. Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
9.2.2. TP2 : interrogation de la BDOR . . . . . . . . . . . . . . . . . . . 310
9.2.2.1. Requêtes mono-table . . . . . . . . . . . . . . . . . . . . . . 310
9.2.2.2. multi-table et/ou de tables imbriquées . . . . . . . 313Table des matières 9
9.2.3. TP3 : développement de méthodes . . . . . . . . . . . . . . . . . . 317
9.2.3.1. Manipulation d’objets . . . . . . . . . . . . . . . . . . . . . . 317
9.2.3.2. d’une collection . . . . . . . . . . . . . . . . . 318
9.2.3.3. Interrogation de la BDOR avec les méthodes . . . . . . . . . 320
9.2.4. TP4 : héritage en BDOR . . . . . . . . . . . . . . . . . . . . . . . 323
9.2.4.1. Création . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
9.2.4.2. Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
9.2.4.3. Création de méthodes et redéfinition . . . . . . . . . . . . . . 328
9.2.5. TP5 : vues RO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
9.2.5.1. Mise en place de la BDR . . . . . . . . . . . . . . . . . . . . 330
9.2.5.2. Création de la vue RO de la BDR . . . . . . . . . . . . . . . 332
9.2.5.3. Insertions avec des vues actives . . . . . . . . . . . . . . . . 333
Chapitre 10. Exercices complémentaires sans corrigé . . . . . . . . . . . . . 337
10.1. Exercice 1 : base de données pour la gestion de supports de cours . . . 337
10.2. Exercice 2 : bibliothèque de fonctions . . . . . . . . . . . . . . . . . . 338
10.3. Exercice 3 : base de données pour la gestion de messages . . . . . . . 341
10.4. Exercice 4 : hyperbase . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
10.5. Exercice 5 : plans de maison . . . . . . . . . . . . . . . . . . . . . . . . 344
Bibliographie
IndexAvant-propos
Cet ouvrage s’adresse aux étudiants des filières informatiques de l’université (niveau
licence ou master) ou aux étudiants des écoles d’ingénieurs qui souhaitent approfondir
et prolonger leurs connaissances en bases de données relationnelles pour découvrir
comment les concepts « objet » y sont appréhendés. Il reste accessible aux étudiants
des filières de premier cycle, d’IUT Informatique, etc., qui ont une bonne culture en
bases de données relationnelles.
On peut naturellement s’interroger sur l’intérêt d’un ouvrage consacré au
relationnelobjet dont les exemples sont implantés dans un environnement Oracle. Pour répondre à
cette interrogation nous soulignons que cet ouvrage permet de :
– percevoir comment les concepts objet ont été appréhendés dans les bases de
données, ceci permettant à certains lecteurs de revoir certaines de leurs idées préconçues
sur le sujet,
– connaître les implantations qui ont été retenues pour les différents concepts et
d’appréhender les raisons qui expliquent le fait que certains d’entre eux ont été laissés
de côté,
– savoir comment on peut faire évoluer une base de données relationnelle
classique vers le contexte objet, sans remettre fondamentalement en cause l’implantation
relationnelle, en utilisant le concept de « vues-objet ».
Un autre intérêt de cet ouvrage est qu’il prolonge l’ouvrage Bases de données
relationnelles : concepts, mise en œuvre et exercices [CHR 08] des mêmes auteurs, dont
il reprend un certain nombre de formalismes. Ce nouvel ouvrage s’appuie également
sur des exercices élaborés, présentés avec les solutions retenues. Certains exercices sont
issus de l’ouvrage précédent pour lesquels l’implantation objet est explorée. Tous les
exercices proposés proviennent de cas concrets auxquels les auteurs ont été confrontés
et qui ont été adaptés en fonction du propos ciblé par l’exercice.12 Bases de données orientées-objet
Le chapitre introductif rappelle comment les objets sont arrivés dans le monde des
bases de données et retrace l’évolution de la prise en compte des concepts pour arriver
sur le relationnel-objet.
2Le deuxième chapitre est consacré au modèle NF qui explicite comment les
structures de données complexes sont appréhendées à l’aide de constructeurs. Cela
permet d’introduire une représentation tabulaire généralisée manipulée par les systèmes
relationnels-objet.
Le troisième chapitre est consacré à la prise en compte des propriétés statiques des
objets et présente le concept de « graphe de types ».
Le quatrième chapitre est dédié à la prise en compte des propriétés
comportementales (concept de méthode). Il n’aborde pas le sujet dans sa globalité, mais se concentre
sur les méthodes attachées aux objets en illustrant concrètement à quoi correspond le
respect du concept d’encapsulation. Certains exemples ont recours à la récursivité pour
manipuler de façon concise certaines structures de données complexes.
Le cinquième chapitre est consacré à SQLOO (extensions de SQL vers
l’orientéobjet). Les caractéristiques du langage sont présentées via des exemples selon six
niveaux de complexité. Pour chacun de ces exemples l’écriture en SQLOO est mise en
parallèle avec une écriture équivalente dans la solution relationnelle.
Le sixième chapitre est consacré à l’héritage (simple ou multiple). Il est d’abord
traité de façon conceptuelle afin de mettre en exergue les critères qui vont piloter les
choix d’implantation. Cela permet de bien positionner l’héritage multiple par rapport à
la multi-instanciation. Des exemples concrets illustrent aussi l’utilisation du mécanisme
de redéfinition de méthode.
Le septième chapitre est consacré aux vues relationnelles-objet et donne un aperçu
des mécanismes qui permettent de migrer vers le monde objet sans remettre en cause
une implantation relationnelle initiale.
Enfin, ces chapitres sont accompagnés d’une série d’exercices et de travaux
pratiques avec solutions. Chacun d’entre eux a été utilisé en version courte pour des
travaux dirigés, en version étendue pour des travaux pratiques (8 à 10 séances par sujet),
en version synthétique pour des sujets d’interrogation de 3 heures. Les rédacteurs de
cet ouvrage ont essayé d’y retransmettre toute leur expérience pédagogique nécessaire
pour traiter un thème aussi complexe. Le huitième chapitre consacré aux exercices
propose les sujets suivants :
1) le premier exercice dédié à la CCPB (caisse de congés payés du bâtiment) est un
exercice simple qui illustre les concepts des trois premiers chapitres ;Avant-propos 13
2) le deuxième exercice concerne la gestion des déplacements vers les chantiers
des employés d’une organisation. L’intérêt de cet exercice concerne le traitement d’un
certain nombre de contraintes dynamiques ;
3) le troisième exercice concerne la gestion d’un syndic de copropriété. Cet exemple
permet d’envisager des imbrications hiérarchiques multi-niveaux qu’il ne faut surtout
pas implanter car elles introduisent davantage de complexité : un seul niveau de
hiérarchie suffit, ce qui correspond à la solution proposée ;
4) le quatrième exercice est consacré à un problème de planification de tâches et
montre la manipulation de structures récursives ;
5) le cinquième exercice est centré sur l’héritage. Il concerne des problématiques de
gestion d’approvisionnements, de gestion de stock et de gestion de production. Il permet
d’acquérir une vision claire sur les concepts d’héritage multiple et la multi-instanciation.
Il permet aussi d’appréhender les possibilités des implantations particulières proposées
par un système comme Oracle ;
6) le sixième exercice traite de la gestion d’informations touristiques pour des sites
desservis par un métro. Il s’agit là d’un exercice de synthèse qui illustre les concepts
présentés dans tous les chapitres de cours.
Le neuvième chapitre consacré aux travaux pratiques propose deux cadres de
réflexion :
1) le premier cadre est consacré à la gestion de parcelles cadastrales. Il est présenté
sous la forme d’une série de travaux pratiques (5 séances) permettant de reprendre
les concepts des différents chapitres de cours. Pour chaque séance, nous proposons
un énoncé avec une liste de questions ainsi qu’un exemple de code (environnement
Oracle) qui permet de traiter les ;
2) le second cadre de réflexion concerne la manipulation de données géolocalisées.
Il peut être adapté en fonction du système de coordonnées qui permet de repérer les
points. L’intérêt de cet ensemble de travaux pratiques réside dans la manipulation de
données à plusieurs niveaux d’abstraction.
Le livre se termine avec cinq sujets complémentaires sans corrigé, pouvant servir
de support de réflexion pour le lecteur. Ils doivent lui permettre de s’auto-évaluer
pour estimer le degré de maîtrise qu’il a acquis sur l’utilisation des concepts objet en
environnement bases de données. Le premier énoncé concerne la mise en place d’une
base d’unités d’enseignements (UE) qui correspondent à des objets multimédia : il
permet d’illustrer le concept de polymorphisme à travers la méthode d’affichage. Le
deuxième énoncé concerne la gestion de données dans un environnement de génie
logiciel ce qui permet de revoir le concept de spécification logicielle par niveau
d’abstraction comme explicité dans le chapitre quatre. Les troisième et quatrième énoncés
concernent la mise en œuvre très simplifiée d’une base d’objets documentaires (ou
hyperbase) et permettent de percevoir les problématiques liées à la manipulation de
données semi-structurées par rapport à celle des données structurées. Le dernier énoncé14 Bases de données orientées-objet
est dédié à la gestion de plans et prolonge les thématiques abordées dans le neuvième
chapitre.
J’espère donc que cet ouvrage apportera une réponse claire, pédagogique et
approfondie à tous ceux qui souhaitent avoir une vision synthétique sur le monde
relationnelobjet et sur les choix d’implantation que propose Oracle pour leur mise en œuvre.
Claude CHRISMENT
Professeur – Directeur de recherche
Responsable des enseignements Bases de Données à la MIAGE
de l’Université Paul Sabatier
Directeur Adjoint de l’IRITConventions de notation
Dans la suite du livre, nous utilisons les conventions de notation suivantes :
– les mots-clés réservés SQL sont en minuscules,
– les noms de classes, attributs, variables, types, tables et méthodes sont en petites
majuscules avec la première lettre de chaque mot en lettre capitale.
Dans les schémas relationnels, les clés primaires sont soulignées, et les clés
étrangères sont suivies du signe #.
L’écriture des noms de types construits, de types « table » ou de type « élément de
table » est homogène au sein de chaque chapitre, mais elle peut varier d’un chapitre
ou d’un exercice à un autre. En effet, ces noms sont spécifiés par le développeur et
leur choix n’est pas contraint. Cependant, nous attirons l’attention du lecteur et du
futur développeur sur la nécessité de respecter des règles mnémoniques concernant leur
écriture, afin de faciliter leur manipulation et les opérations de recherche qui peuvent
intervenir dans des contextes de maintenance logicielle.
À propos de l’utilisation de l’expression « relationnel-objet » : l’ouvrage concerne
les approches relationnelles-objet car toutes les implantations proposées ont été
réalisées avec le système relationnel Oracle. Toutefois, un certain nombre de facettes
présentées concerne indifféremment les approches objet dans les bases de données, les
approches objet-relationnelles ou les relationnelles-objet. Il s’ensuit que ces
deux expressions seront utilisées indifféremment dans cet ouvrage.Chapitre 1
Introduction
Le concept d’objet a été initialement introduit dans les langages de programmation
notamment dans SIMULA-67 (proposé par O. Dahl et K. Nygaard) dérivé d’Algol60.
Sa prise en compte remonte à 1970 avec le langage Smalltalk proposé par Alan Key
et al. du Xerox Palo Alto Research Center. Le concept a ensuite été introduit dans la
plupart des langages existants : le langage Lisp a donné lieu à ObjectLisp, Loops ou
Clos ; le langage C a été transformé en Objective-C et C++ ; Pascal en Clascal, etc. De
nouveaux langages directement objets ont également été proposés comme le célèbre
Java. Le concept d’objet a aussi été repris dans le domaine de l’Intelligence Artificielle :
au départ avec les frames introduites par Minsky avec FRL [MIN 75], puis avec les
langages de représentation de connaissances comme KEE [FIK 85], ART [CLA 85] et
KRL [BOB 77].
L’introduction du concept d’objet dans le contexte des bases de données remonte
à 1984, quand D. Maier et G. Copeland ont proposé la construction d’un Système de
Gestion de Bases de Données (SGBD) à partir de Smalltalk [COP 84]. Il s’agissait
d’intégrer le concept de « persistance » dans ce langage. Ces travaux ont conduit à
la mise au point du système Gemstone commercialisé par Serviologic en 1988. À la
même époque, en Europe, les travaux s’articulaient plutôt autour du concept « d’objet
2complexe » avec l’approche NF (Non First Normal Form), proposée par Scheck et
Pistor [SCH 82, PIS 86]. Cette approche a conduit au relationnel étendu et au prototype
AIMP (Advanced Information Management Prototype). Deux grands projets ont étés
précurseurs pour la réalisation de Systèmes de Gestion de Bases de Données Orientées
Objet (SGBDOO) : ce sont les projets ORION [KIM 85] et O2 [BAN 86].
Les fonctionnalités qui caractérisent les SGBDOO ont été précisées pour la première
fois en 1989 dans [ATK 89]. Ces systèmes présentent :
de
ty
pes
complexes/construits/
�tendus.
Les
tables/rela
tions
sont
consid�r�es
s
comme
des
class
es.
create
table
Activity
(
Name
char(20),
�tant
1.
Introduction
float
Contexte
relati
onnel
Point
de
d�part.
create
table
Employee
(
Name
char(20),
Job
char(20),
Salary
float,
Hobby
char(20),
Manager
char(20));
NumPlayers
2.
integer,
de
create
table
Employee
(
Name
char(20),
Job
char(20),
Salary
m�thode.
float,
Activity
,
Manager
Employe
e
)
procedure
RetirementB
enefits
Hobby
;
cept
char(20))
;
create
table
Employee
(
Name
char(20),
Job
char(20),
Salary
float,
Hobby
Activity
,
Manager
Employe
e
);
3.
Introduction
du
Origin
con
18 Bases de données orientées-objet
– des fonctionnalités bases de données :
1) persistance,
2) gestion de l’espace disque,
3) partage des données,
4) confidentialité,
5) sécurité ;
– des fonctionnalités orientées-objet :
1) identité d’objet,
2) classes, types, méthodes,
3) messages,
4) encapsulation,
5) héritage,
6) surcharge, polymorphisme et lien dynamique ;
– des fonctionnalités additionnelles :
1) gestion de longues transactions, transactions imbriquées,
2) gestion de versions et de l’évolution des données dans le temps.
Les premiers systèmes intégrant ces fonctionnalités avaient pour nom Gemstone,
Ontos, O2, Object Store, Objectivity, Matisse, Encore, etc. Le lecteur pourra se reporter
à [HAR 92] pour plus de détails.
L’évolution naturelle de cette approche a été ensuite son unification avec l’approche
relationnelle [KIM 92]. Cette a été prise en compte dans le développement
du système UNISQL. Kim a tout d’abord proposé une transformation graduelle du
modèle relationnel pour y intégrer les concepts objet. Cette est résumée
en quatre étapes de façon très schématique ci-dessous :child
(
Job
char(20),
Salary
float,
Hobby
Activity
,
Person
Employe
e
)
procedure
RetirementB
enefits
float
as
Employee
of
table
Manager
;
4.
Introduction
du
con
cept
d'h�ritage.
create
table
Person
(
Name
char(20),
SSN
char(9),
Age
integer)
create
;
Introduction 19
Dans un premier temps, les attributs, au lieu d’être de type simple, peuvent
appartenir à une classe (c’est le cas de l’attribut HOBBY dans l’étape 2, qui est de type
ACTIVITY, modélisé ensuite via une relation). Ensuite, on intègre des procédures
(étape 3 : intégration de la méthode RETIREMENTBENEFITS). Le dernier concept objet
introduit à l’étape 4 est celui de l’héritage : dans l’exemple, la relation EMPLOYEE
hérite de la relation PERSON.
Kim a formalisé une approche de migration du relationnel vers l’objet en 6 étapes :
– E1 : intégration au relationnel des concepts de classes (Relation$ Classe) et de
méthodes (Procédures$ Méthodes) ;
– E2 : introduction de types étendus avec les constructeurs Set et Tuple ;
– E3 : intégration de l’héritage multiple ;
– E4 : adjonction du concept de LOB (Large Objects, BLOB – Binary Large OBject
ou CLOB – Character Large OBject) ;
– E5 : développement d’extensions multimédia ;
– E6 : évolution de SQL vers OQL (Object Query Language) en permettant
notamment l’utilisation de méthodes dans la spécification de requêtes.
Dans la démarche d’unification, il y a eu également une réflexion pour unifier les
langages à objet (de type OQL) avec le standard du relationnel (SQL). Cette évolution a
été supervisée, à partir de 1993, par l’ODMG (Object Data Management Group), et est
présentée dans [CAT 95]. Elle a été ensuite partiellement reprise dans les spécifications
edes caractéristiques de SQL3 (version SQL-2008) [ISO 99]. Au 1 décembre 2010, la
référence du standard (document payant) est ISO/IEC 9075 (1-4, 9-11, 13, 14) :2008.
On distingue actuellement plusieurs types de SGBD qui intègrent des concepts
« objet » : des systèmes purement « objet » comme O2, Object Store, ou encore Matisse
et des systèmes dits « relationnel-objet » UNISQL ou Oracle (à partir de la
version 8), qui sont des systèmes relationnels au-dessus desquels est ajoutée une couche
« objet ».
En 1997, dans le contexte « relationnel-objet », le concept d’objet est devenu
manipulable au travers du concept de « vue ». Il est devenu possible de construire desof
instead
20 Bases de données orientées-objet
vues objet, couplées avec des déclencheurs particuliers (triggers « ») au
dessus de bases de données relationnelles.
Dans cet ouvrage, nous présentons l’approche objet dans sa globalité, et nous
l’illustrons au travers de son implantation sous le système Oracle. Tous les exemples
et exercices ont été testés dans un environnement Oracle 10g. Il est à noter que des
fonctionnalités relationnel-objet d’Oracle sont disponibles à partir de la version 8
(1997) (sans héritage et imbrication au-delà d’un niveau dans cette version).Chapitre 2
2Modèle NF : Non First Normal Form
2.1. Modélisation, formalisation
2L’approche NF (Non First Normal Form), proposée par Scheck et Pistor [SCH 82,
2PIS 86] a conduit au modèle relationnel étendu. Le modèle NF formalise l’imbrication
de relations. Il est basé sur le modèle relationnel auquel on ajoute deux constructeurs :
– le constructeur de tuples [],
– leteur d’ensembles {}.
En relationnel classique, une relation en 1NF (First Normal Form – première forme
normale) notée R[A, B, C, D] est composée d’attributs A, B, C, D ayant des domaines
2simples. Dans une relation en NF , les attributs peuvent être complexes, c’est-à-dire
associés à des domaines complexes (ou non simples), par exemple :
– ensemble d’éléments (les éléments sont non ordonnés et non dupliqués),
– liste d’éléments (les éléments sont différenciés par un rang : ils sont ordonnés via
le rang et leurs valeurs peuvent être dupliquées),
– paniers ou bags (alors que dans les ensembles ou dans les listes, les éléments sont
de type homogène, dans les paniers on dispose d’un ensemble ou d’une liste d’éléments
de types hétérogènes). Par exemple, si l’on considère un document électronique, il peut
être vu comme une liste de fragments informationnels. Chaque fragment informationnel
peut être d’un type différent : texte, son, image, graphique, etc.,
– ensemble de listes, ensemble d’ensembles, etc. Dans ce contexte, un tuple peut
contenir un attribut correspondant à une relation : on parle de relation imbriquée.22 Bases de données orientées-objet
2Ainsi, une relation 1NF est vue en NF comme un ensemble {} de tuples []. Afin
de préciser cette approche, nous illustrons sur les figures suivantes le passage d’une
2représentation d’une relation en 1NF en sa représentation équivalente en NF .
Considérons la relation suivante ETUDIANT[CODE, NOM, DIPLÔME] en 1NF :
ETUDIANT CODE NOM DIPLÔME
123 Dupond Bac
123 Dupond Licence
123 Dupond Master
Redondances 232 Jean
426 Emile Bac
426 Emile Licence
Figure 2.1. Relation ETUDIANT en 1NF
Dans cette relation, un certain nombre d’informations sont redondantes. Trois lignes
nous permettent en effet de savoir que le code 123 correspond à Dupond, et deux lignes
nous de savoir que le code 426 correspond à Emile.
Pour éviter cette redondance, le modèle relationnel intègre un processus de
normalisation de la relation qui aboutit à la création de différentes relations normalisées pour
lesquelles seule la redondance des clés est autorisée : on parle de 3NF (troisième forme
ETUDIANT' CODE NOM
normale). Dans l’exemple précédent, la relation initiale peut être décomposée en deux
123 Dupond
relations décrites en figure 2.2. La relation initiale ETUDIANT peut être reconstruite 232 Jean
par jointure entre les deux tables sur l’attribut CODE qui joue le rôle de la clé pour la 426 Emile
relation ETUDIANT’.
DIPLOMES CODE DIP
123 Bac
ETUDIANT' CODE NOM 123 Licence
123 Dupond 123 Master
232 Jean 426 Bac
426 Emile 426 Licence

Figure 2.2. Décomposition de la relation ETUDIANT en 3NF
DIPLOMES CODE DIP
123 Bac
123 Licence
2Dans l’approche NF , une formalisation équivalente avec une seule relation où 123 Master
la redondance est évitée fait intervenir le constructeur de tuples [] et le constructeur 426 Bac
d’ensembles {} et426se note Liccommeence suit :
ETUDIANT”{[CODE, NOM, DIPLÔMES{[DIP]}]}, où DIPLÔMES est associé à un
domaine non simple (ensemble). Elle est représentée sur la figure 2.3.2Modèle NF : Non First Normal Form 23
ETUDIANT'' CODE NOM DIPLÔMES
DIP
123 Dupond Bac
Licence
Master
232 Jean
426 Emile Bac
Licence
2Figure 2.3. Extension de la relation ETUDIANT en NF
2.2. Extension de l’algèbre : les opérateurs NEST et UNNEST
2Le passage d’une relation en 1NF en une relation NF se fait à l’aide des opérateurs
d’imbrication NEST et de désimbrication UNNEST. L’opérateur NEST comprend
trois paramètres : le nom de la relation sur laquelle s’applique l’opérateur, la liste des
attributs objets de l’imbrication et la description de la colonne générée. L’opérateur
UNNEST comprend également trois paramètres : le nom de la relation sur laquelle
s’applique l’opérateur, la liste des attributs à désimbriquer et la liste des attributs
générés. ETUDIANT et ETUDIANT” correspondent respectivement aux relations des
figures 2.1 et 2.3.
ETUDIANT{[CODE, NOM, DIPLÔME]}
UNNEST NEST
(ETUDIANT''; (ETUDIANT;
Désimbrication Imbrication
DIPLÔMES{[DIP]} ; DIPLÔME;
DIPLÔME) DIPLÔMES{[DIP]})
ETUDIANT''{[CODE, NOM, DIPLÔMES{[DIP]}]}
Figure 2.4. Illustration des opérateurs NEST et UNNEST
Il est important d’observer que ces deux opérateurs ne sont pas nécessairement
symétriques, c’est-à-dire que pour une relation donnée R, l’enchaînement d’opérations
UNNEST(NEST(R)) ne produit pas nécessairement la relation de départ R.6
24 Basesdedonnéesorientées-objet
PROPRIÉTÉS :
– si une relation R est en 1NF : UNNEST(NEST(R)) = R. Les opérateurs UNNEST
et NEST jouent un rôle symétrique si le point de départ est une relation 1NF,
2– si R est en NF : NEST(UNNEST(R)) – ou UNNEST(NEST(R)) – ne redonne
pas nécessairement R. Les opérateurs UNNEST et NEST ne sont plus symétriques sur
2des relations NF .
L’exemple suivant illustre cette deuxième propriété. Soient les transformations
suivantes appliquées à partir de la relation R représentée sur la figure 2.5 :
– désimbrication de la relation R par rapport à l’attribut B’, soit R’ = UNNEST(R ;
B’{[B]} ; B). Le résultat de la désimbrication est une relation R’ dans laquelle le tuple
[a1, b1, c1] est dupliqué. Dans une représentation 1NF, ce duplicata serait éliminé,
– imbrication dans la relation R’ d’une relation construite sur l’attribut B, soit R” =
NEST (R’ ; B ; B’{[B]}). La réimbrication fusionne les deux tuples redondants. Il
s’ensuit que : R’ = NEST(UNNEST(R ; B’{[B]} ; B) ; B ; B’{[B]}) = R.
R A {B'} C
B
a1 b1 c1
R' A B Cb2
a1 b1 c1 a1 b1 c1
UNNEST(R)b3 a1 b2 c1
a1 b1 c1
R'' A {B'} C a1 b3 c1
B
NEST(R’)a1 b1 c1
b2
b3
Figure 2.5. Dissymétrie d’application des opérateurs NEST et UNNEST
2Ces opérateurs permettent la gestion de relations NF à partir d’une base de
données relationnelle comme cela a été illustré à travers le prototype AIMP (Advanced
Information Management Prototype) développé par l’équipe de IBM-Heidelberg.
22.3. Passage du modèle relationnel au modèle NF
2.3.1. Exemple et problématique
2La transformation d’un schéma relationnel vers un schéma en NF soulève des
2questions délicates. Quel est le schéma équivalent d’un relationnel en NF ?
Que faut-il imbriquer ? Comment faut-il imbriquer ? C’est-à-dire dans quel sens :2Modèle NF : Non First Normal Form 25
décider quelle entité est englobante, quelle entité est englobée ? Nous illustrons cette
problématique à travers un exemple de transformation d’un schéma relationnel, organisé
de manière à être conforme à la 3NF. Considérons les relations :
PRODUITS [NP, DES, QTE]
FOURNISSEURS [NF, NOMF, ADR]
APPROVISIONNEMENT [NF#, NP#, PU]
Un produit est décrit par un numéro de produit (NP), une désignation (DES) et
une quantité en stock (QTE). Un fournisseur est décrit par un numéro (NF), un nom
(NOMF) et une adresse (ADR). L’attribut PU de la relation APPROVISIONNEMENT
indique le prix unitaire d’un produit pour un fournisseur. Les extensions de ces relations
sont présentées dans les tables de la figure 2.6.
PRODUITS NP DES QTE
P1 d1 100
P2 d2 200
P3 d3 150
FOURNISSEURS NF NOMF ADR
F1 Jean a1
F2 Pierre a2
F3 Paul a3
F4 Emile a4
APPROVISIONNEMENT NF NP PU
F1 P1 10
F1 P3 20
F2 P1 15
F2 P2 20
F2 P3 15
F3 P3 15
F3 P2 15
Figure 2.6. Relations initiales en 3NF
Pour déterminer les imbrications, il faut passer par l’analyse des traitements qui
vont opérer sur la base de données. Supposons que le traitement principal soit du type
suivant (RQ1).=
and
A1.NF
=
F.NF
where
A1
A1.PU
ovisionnement
F,
Fournisseurs
from
select
F.NomF,
A1.NP,
Appr
PU
(select
A2.NF
);
A1.NF
=
A1.
where
max(
nnement
Approvisio
from
)
A2.PU
A2
26 Basesdedonnéesorientées-objet
(RQ1) Restituer par fournisseur la liste des produits les plus chers.
Pour expliciter, nous exprimons ce traitement via la requête SQL suivante :
Pour traiter (RQ1) :
– il faut parcourir la liste des fournisseurs,
– pour chaque fournisseur de la liste, il faut récupérer la liste des produits fournis
et calculer le prix le plus élevé,
– avec ce prix le plus élevé, on affiche le fournisseur et la liste des produits concernés
avec le prix.
Le résultat est illustré dans la figure 2.7 :
RQ1 NOMF NP PU
Jean P3 20
Pierre P2 20
Paul P3 15
Paul P2 15

Figure 2.7. Résultat de la requête RQ1
(RQ1) fait intervenir uniquement les relations FOURNISSEURS et
APPROVISIONNEMENT. L’élaboration du résultat nécessite comme point de départ l’exploration de
la relation FOURNISSEURS pour aller sur la relation APPROVISIONNEMENT. Ce qui
suggère :
– de laisser PRODUITS{[NP, DES, QTE]} inchangée, et
– d’imbriquer la relation APPROVISIONNEMENT dans la relation FOURNISSEURS.
Le choix d’imbriquer les approvisionnements dans les fournisseurs est motivé
par l’évitement de la jointure dans le traitement (RQ1). Le schéma de la relation
FOURNISSEURS est alors complété par un attribut complexe :
1FOURNISSEURS{[NF, NOMF, ADR, APPROVISIONNEMENT {[NP, PU]}]}.
L’extension de la nouvelle relation FOURNISSEURS est illustrée dans la figure 2.8.and
=
F.NF
where
P
Produits
A1,
ovisionnement
Appr
F,
Fournisseurs
from
PU
A1.
P.Des,
F.NomF,
A1.NF
A1.NF
A1.NP
);
=
A2.NF
where
A2
nement
Approvision
select
from
A2.PU
max(
(select
in
A1.PU
and
P.NP
)
=
2Modèle NF : Non First Normal Form 27
1FOURNISSEURS' NF NOMF ADR APPROVISIONNEMENT
NP PU
F1 Jean a1 P1 10
P3 20
F2 Pierre a2 P1 15
P2 20
P3 15
F3 Paul a3 P3 15
P2 15
F4 Emile a4
2 1Figure 2.8. Relation NF en extension FOURNISSEURS
L’intérêt de cette imbrication est de limiter le coût du calcul du traitement (RQ1) :
1) avec un schéma en 3NF et des index, il y aurait de manière simplifiée et grossière
18 accès :
- 4 accès à FOURNISSEURS,
er- 7 accès pour le 1 balayage d’APPROVISIONNEMENT,
e- 7 accès pour le 2 d’APPROVISIONNEMENT.
2) en optimisant ces parcours, le deuxième balayage d’APPROVISIONNEMENT peut
2être évité, et on aurait donc au mieux 11 accès. Avec le schéma NF proposé, 4 accès à
FOURNISSEURS’ suffisent.
Supposons maintenant que le traitement à effectuer soit (RQ1a) :
(RQ1a) : idem à (RQ1), mais au lieu de restituer le numéro du produit, on restitue
sa désignation.
Pour expliciter, nous exprimons ce traitement via la requête SQL suivante, dont le
résultat est présenté dans la figure 2.9.28 Bases de données orientées-objet
RQ1a NOMF DES PU
Jean d3 20
Pierre d2 20
Paul d3 15
Paul d2 15
Figure 2.9. Résultat de la requête RQ1a
Dans (RQ1a), pour afficher le résultat, il faut aller dans PRODUITS pour récupérer
la désignation DES. On peut envisager, pour optimiser les accès, d’intégrer PRODUITS
dans APPROVISIONNEMENT puis dans FOURNISSEURS. La base de données serait
2alors composée d’une seule relation NF , représentée en figure 2.10.
2FOURNISSEURS'' NF NOMF ADR APPROVISIONNEMENT
NP DES QTE PU
F1 Jean a1 P1 d1 100 10
P3 d3 150 20
F2 Pierre a2 P1 d1 100 15
P2 d2 200 20
P3 d3 150 15
F3 Paul a3 P3 d3 150 15
P2 d2 200 15
F4 Emile a4
2 2Figure 2.10. Relation NF en extension FOURNISSEURS
Avec cette structure (RQ1a) fait toujours intervenir 4 accès. En contrepartie, le fait
de tout imbriquer introduit de la redondance. Cette redondance va dégrader le coût
des mises à jour, ce qui impose une analyse qui peut conduire à une recherche de
compromis.
Ainsi, supposons qu’on veuille prendre en compte la mise à jour suivante : la
quantité de ‘P3’ passe de 150 à 80 :
1) dans le schéma en 3NF, un seul accès suffit pour réaliser la mise à jour,
22) dans le schéma en NF , il faut accéder à chaque fournisseur et analyser
2APPROVISIONNEMENT pour détecter la présence éventuelle du produit ‘P3’ pour
2lequel la quantité sera mise à jour (4 accès + analyse de APPROVISIONNEMENT ).
2Par contre, avec le schéma NF , il n’y a pas de dégradation et un seul accès à
FOURNISSEUR” suffit.)
Approvisio
nnement
A2
where
A2.NP
=
A1.NP
);
A1.NP
null
,70)
d3
,
P4
(
values
Produits
from
insert
A2.PU
=
where
A1
nement
Approvision
P,
Produits
from
into
U
A1.NF,
P.Des,
select
P.NP
and
A1.PU
=
(select
A1.P
min(
2Modèle NF : Non First Normal Form 29
1Considérons maintenant le cas de la association hiérarchique FOURNISSEURS)
PRODUITS. Supposons que l’on veuille insérer un produit, fabriqué par la société, et
non fourni par un fournisseur :
1) dans le schéma en 3NF, il suffit d’effectuer la commande :
" " " " ;
22) dans le schéma en NF avec imbrication totale, on insère : [–, –, –, {[‘P4’, ‘d3’,
70, –]}]. Le tiret ‘–’ matérialise la valeur indéfinie ( ). Le problème est alors que
la clé de la relation est indéfinie. Si on doit ajouter 2 tuples de ce type, la relation
contiendra deux fois la valeur indéfinie sur la clé primaire NF de la relation. Or, une
clé doit être unique et non nulle. Ce type de problème n’existe pas avec l’imbrication
partielle, cas de PRODUIT séparé de FOURNISSEUR’.
Supposons que le traitement principal soit maintenant le suivant :
(RQ2) : restituer par désignation de produit le numéro du fournisseur qui le propose
au prix le plus bas.
Le résultat correspond à la table présentée en figure 2.11.
RQ2 DES NF PU
d1 F1 10
d2 F3 15
d3 F2 15
d3 F3 15

Figure 2.11. Résultat de la requête RQ2
Dans la relation en 3NF, 3 + 7 (+ 7) accès sont nécessaires, soit 17 accès ou 10 en
optimisant.
La requête (RQ2) utilise principalement PRODUITS et APPROVISIONNEMENT. En
2NF , il ne faut plus que 3 accès en tout pour traiter RQ2, soit un gain de 70 %, si
1. Une association hiérarchique est une association 1-N avec dépendance existentielle. On pourra
se reporter à [CHR 08], chapitre 2, section 2.2 pour une définition plus détaillée.30 Bases de données orientées-objet
le choix qui est fait est d’imbriquer APPROVISIONNEMENT dans PRODUITS de la
manière suivante :
3PRODUITS{[NP, DES, QTE, APPROVISIONNEMENT {[NF, PU]}]}
FOURNISSEURS{[NF, NOMF, ADR]}
Supposons que le traitement principal devienne le suivant :
(RQ2a) : identique à RQ2, mais au lieu de restituer NF, on restitue NOMF.
On pourrait penser à faire une seule relation :
4PRODUITS{[NP, DES, QTE, APPROVISIONNEMENT {[NF, NOMF, ADR, PU]}]}.
Pour les mêmes raisons que précédemment prenant en compte les opérations de
modifications, une analyse montre très simplement que c’est une mauvaise solution.
2.3.2. Règles concernant les contraintes d’imbrication
Si l’on s’appuie sur les considérations précédentes, on peut exprimer un certain
2nombre de règles à respecter pour construire un schéma NF , règles qui peuvent être
spécifiées à partir de la représentation graphique Entité/Relation (E/R) [CHE 76] du
schéma de la base de données. La question de l’imbrication se pose principalement
pour les associations hiérarchiques ou pour les associations M-N, matérialisées dans la
figure 2.12.
M N
A BL
Figure 2.12. Exemple d’association M-N dans le formalisme E/R
Cela conduit à la première règle :
(R1) : s’il y a imbrication, elle ne doit concerner que l’association qui sera intégrée
soit à A, soit à B.
Une analyse spécifique du schéma E/R doit être conduite pour traiter les liens
hiérarchiques ou les liens de composition. L’expression conceptuelle de tels liens ne
doit pas nécessairement se matérialiser par une imbrication de relations car l’expérience
de mise en œuvre de bases de données montre que la deuxième règle suivante doit être
respectée (dans plus de 99 % des cas) :2Modèle NF : Non First Normal Form 31
(R2) : il est très rare que les applications nécessitent plus d’un niveau d’imbrication.
Si très exceptionnellement on est confronté à une application où il faut dépasser un
niveau, il faut l’argumenter avec des calculs issus de l’analyse des traitements qui vont
agir sur la base de données, calculs qui prouvent l’amélioration des performances au
niveau des accès.
En revenant sur notre exemple, sachant que sur la base de données on aura des
traitements à la fois de type (RQ1) et de type (RQ2), il se pose alors la question de
décider des imbrications pertinentes. De façon caricaturale, la réponse que l’on peut
donner s’exprime schématiquement ainsi :
– si (RQ1) concerne plus de 80 % des traitements, on envisage l’imbrication simple
suivante dans FOURNISSEURS :
1FOURNISSEURS{[ NF, NOMF, ADR, APPROVISIONNEMENT {[NP, PU]}]}
PRODUITS{[NP, DES, QTE]} ;
– si (RQ2) concerne plus de 80 % des traitements, on envisage l’imbrication simple
suivante dans PRODUITS :
3PRODUITS{[NP, DES, QTE, APPROVISIONNEMENT {[NF, PU]}]}
FOURNISSEURS{[NF, NOMF, ADR]} ;
– si (RQ1) comprend 60–80 % des traitements et (RQ2) 20–40 %, on souhaite donc
privilégier RQ1. On procède à une double imbrication (à ne pas confondre avec une
imbrication à 2 niveaux) favorisant FOURNISSEURS :
4FOURNISSEURS{[NF, NOMF, ADR, APPROVISIONNEMENT {[NP, PU]}]}
5PRODUITS{[NP, DES, QTE, APPROVISIONNEMENT {[NF]}]}
si une analyse approfondie suggère que PU doit apparaître dans les deux relations
imbriquées, il vaut mieux dans ce cas ne pas imbriquer ;
– si (RQ2) comprend maintenant 60–80 % des traitements et (RQ1) 20–40 %, on
souhaite privilégier RQ2. On procède à une double imbrication favorisant PRODUITS :
6FOURNISSEURS{[NF, NOMF, ADR, APPROVISIONNEMENT {[NP]}]}
7PRODUITS{[NP, DES, QTE, APPROVISIONNEMENT {[NF,PU]}]}.
De même que précédemment, si une analyse approfondie suggère que PU doit
apparaître dans les deux relations imbriquées, il vaut mieux ne pas imbriquer ;
– si (RQ1) concerne 50–60 % des traitements et (RQ2) également, on ne fait pas
d’imbrication.32 Bases de données orientées-objet
22.4. Exemple de modélisation NF
Nous présentons ici un exemple d’une base de données relationnelle nous servant
à commenter les alternatives de mise en œuvre via un SGBDOO ou relationnel-objet.
Pour cela, nous considérons la base de données relationnelle suivante, mise en place
pour la gestion des problèmes de remembrement par des organismes tels que les sociétés
d’aménagement foncier et d’établissement rural (SAFER).
2.4.1. Modélisation relationnelle, schéma relationnel
PR [CP, NOM, ADR]
ACHATS [CP#, NP#, DTACH, DTDPVT]
PA [NP, SURFACE, PRIXM2, TYPE]
LOT [NDOS, IDL, NOMLOT, DTCR, SURFLOT]
COMPLOT [IDL#, NP#]
OP [IDOP, NDOS#, DT, NAT, NPR#]
DOP [IDOP#, NSP#]
PR est la relation décrivant les propriétaires avec pour chacun d’eux le code (CP),
le nom (NOM) et l’adresse (ADR).
ACHATS est la relation associant les propriétaires (CP) aux parcelles (NP) qu’ils
ont achetées en précisant la date de l’achat (DTACH). La date DTDPVT correspond
soit à la date à laquelle la parcelle a disparu lors d’une division ou d’un regroupement,
soit à la date de revente. Dans le cas d’une division ou d’un regroupement, cette date se
retrouve au niveau de l’attribut DT de la relation OP décrivant ces opérations.
PA est la relation décrivant les parcelles, où NP identifie une parcelle de SURFACE
donnée et dont le prix au mètre carré PRIXM2 est précisé. L’attribut TYPE caractérise
la parcelle (‘I’ : parcelle initiale d’un lot soumis à remembrement, ‘R’ : parcelle générée
par regroupement, ‘D’ : parcelle générée par division).
LOT est la relation décrivant un lot de parcelles soumis à remembrement. Pour cela,
il est constitué un dossier (NDOS) pour le lot de parcelles (qualifiées dans la relation
PA par TYPE = ‘I’ – Initiales). Ce lot est désigné par IDL (qui est une clé secondaire,
c’est-à-dire une autre clé possible). Chaque lot possède un nom (NOMLOT), une date
2de création (DTCR), une surface (SURFLOT) .
COMPLOT est la relation décrivant la composition du lot en indiquant les parcelles
qui le composent.
2. Dans ce chapitre, on considère SURFLOT comme un attribut, alors que dans les chapitres
suivants, il s’agira d’une méthode. Cela montre la difficulté de décider dans certains contextes de
la création d’un attribut, d’une méthode ou des deux.2Modèle NF : Non First Normal Form 33
OP est la relation décrivant la liste des opérations effectuées dans le contexte de
l’instruction d’un dossier. Une opération correspond soit à une division (NAT = ‘D’)
soit à un regroupement (NAT = ‘R’). DT caractérise la date de fin de réalisation
de l’opération. Une opération concerne une seule parcelle NPR qui sera divisée ou
construite par regroupement.
DOP est la relation décrivant le détail des opérations. Pour un regroupement, on
associe la parcelle obtenue (NPR associé à l’opération dans OP) aux parcelles (NSP)
regroupées pour la constituer. Pour une division on associe la parcelle à subdiviser
(NPR) à ses sous-parcelles. La surface des sous-parcelles qui sera notée dans la relation
PA est une donnée fournie par le géomètre.
Le schéma de la figure 2.13 illustre le principe du remembrement.
P1 P2 P3 P4 Lot initial
Division de P2 en P2A, P2B, P2CP2B P2CP2A
Regroupement de P1, P2A, P2B en P5
P5 P6 Regroupement de P2C, P3, P4 en P6
Figure 2.13. Illustration du principe du remembrement
On trouvera sur la figure 2.14 le schéma Entité/Relation simplifié associé à notre
exemple (formalisme de Chen [CHE 76]).
M N M
PR ACHATS PA
M
1
COMPLOT
N
DDOOPP((NNPPRR))
LOT
1 N
(NDOS)
OP
N N
Figure 2.14. Schéma Entité/Relation simplifié des SAFER