Académique Documents
Professionnel Documents
Culture Documents
XX TotalBD PDF
XX TotalBD PDF
E Y R O L L E S
GEORGES GARDARI N
Bases de
donnes
Best o f
E Y R O L L E S
Au sommaire
Georges Gardarin
5e tirage 2003
EYROLLES
EDITIONS EYROLLES
61, bd, Saint-Germain
75240 Paris cedex 05
www.editions-eyrolles.com
Je tiens exprimer mes vifs remerciements tous ceux qui, par leurs travaux, leurs
ides, leurs prsentations, leurs collaborations ou leurs relectures, ont particip de prs
ou de loin la ralisation de cet ouvrage, en particulier :
Catherine Blirando, Christophe Bobineau, Luc Bouganim, Mokrane Bouzeghoub,
Tatiana Chan, Jean-Luc Darroux, Thierry Delot, Franoise Fabret, Batrice Finance,
Dana Florescu, lisabeth Mtais, Philippe Pucheral, Fei Sha, ric Simon, Tuyet Tram
Dang Ngoc, Patrick Valduriez, Yann Vimont, Fei Wu, Karine Zeitouni.
Une mention particulire Hlne qui ma support pendant tous ces nombreux
week-ends et vacances passs rdiger.
AVANT-PROPOS
Jai commenc travailler dans le domaine des bases de donnes en 1968 luniver-
sit de Paris VI (non, pas en lanant des pavs), alors que le modle rseau pointait
derrire les fichiers squentiels puis indexs. Sous la direction de Michel Rocher qui
fut plus tard directeur dOracle France, avec Mireille Jouve, Christine Parent, Richard
Gomez, Stefano Spaccapietra et quelques autres, nous avions dvelopp une famille
de Systmes de Fichiers pour Apprendre Les Autres : les SFALA. Nous enseignions
essentiellement les mthodes daccs squentielles, indexes, haches, et surtout le
systme. Bientt (en 1972), nous avons introduit les Systmes de Donnes pour
Apprendre Les Autres (SDALA). Il y eut un SDALA bas sur le modle rseau, puis
bientt un bas sur le modle relationnel. Aujourdhui, on pourrait faire un SDALA
objet, multimdia, et bientt semi-structur...
Le premier systme de gestion de donnes que jai construit lHopital Necker grait
un disque SAGEM ttes fixes de 256 K octets ! Ceci me semblait norme par rap-
port au 8 K de mmoire. Le systme grait les dossiers des malades avec des fichiers
hachs. Ctait en 1969 alors que jtais encore lve lENSET et stagiaire TITN.
Le deuxime le fut OrdoProcesseurs, une socit franaise qui vendait des mini-
ordinateurs franais. Ctait en 1974 et les disques atteignaient dj 10 mga-octets.
Le troisime le fut lINRIA au dbut des annes 1980 : ctait lun des trop rares
systmes relationnels franais commercialiss, le SGBD SABRE. Les disques dpas-
saient dj 100 M octets ! Aujourdhui, les disques contiennent plusieurs giga-octets
et lon parle de ptabases (10 puissance 15 octets). Demain, et demain est dj l,
avec lintgration des rseaux et des bases de donnes, tous les serveurs de donnes
du monde seront interconnects et lon grera des volumes inimaginables de donnes
en ligne par des techniques plus ou moins issues des bases de donnes...
Alors que les bases de donnes semblaient au dbut rserves quelques applications
sophistiques de gestion, toute application moderne utilise aujourdhui une base de
donnes sous une forme ou sous une autre. Certes, il y a encore beaucoup de donnes
dans des fichiers, mais lquilibre o plutt le dsquilibre se dplace. Toute
IV BASES DE DONNES : OBJET ET RELATIONNEL
application de gestion non vieillotte utilise une BD relationnelle, les BD objets per-
cent dans les applications donnes complexes, et les serveurs Web sappuient de
plus en plus sur des bases de donnes. Pourquoi ? Car les BD offrent le partage, la fia-
bilit, les facilits de recherche et bientt la souplesse et lintelligence avec le support
de donnes multimdia et semi-structures, et de techniques venues de lintelligence
artificielle, telles le data mining. Les BD sont de plus en plus distribues, intgres
avec les rseaux Intranet et Internet. Do leur gnralisation.
Voil donc un domaine que jai eu la chance de traverser depuis sa naissance qui a
cr beaucoup demplois et qui va continuer en crer dans le millnaire qui vient. Le
vingt et unime sicle devrait tre celui des sciences et techniques de linformation, au
moins son dbut. Certains mobjecteront que lon a cr beaucoup de formulaires,
alourdi la gestion et plus gnralement la socit, et aussi dtruit les petits emplois.
Peut-tre, mais ce nest pas lobjectif, et ceci devrait tre corrig (notamment avec les
formulaires en ligne). Dautres objecteront que nous crons (avec Internet notamment)
une civilisation deux vitesses : je le crains malheureusement, et voil pourquoi il est
trs ncessaire de simplifier et dmystifier, par exemple en crivant des livres essayant
de mettre ces techniques la porte de tous.
Dans le domaine des bases de donnes, comme dans beaucoup dautres, la France a
gch beaucoup de chances, mais reste encore trs comptitive, au moins en comp-
tences sinon en produits. En fait, depuis septembre 1997, lindustrie franaise ne pos-
sde plus de SGBD important. Auparavant, elle avait possd SOCRATE, IDS II,
SABRE (un SGBD important pour lauteur), et enfin O2. vrai dire, le seul bien
vendu fut IDS.II, un produit issu des tats-Unis. Mais enfin, nous avions la matrise
de la technologie...
Ce livre prsente une synthse des principes et des techniques actuelles en matire de
base de donnes. Il traite des bases de donnes relationnelles et des bases de donnes
objet. Ces paradigmes sont au cur des systmes dinformation daujourdhui. Ils
sont essentiels pour les entreprises et mritent dtre connus de tout tudiant
lUniversit ou en cole dingnieur.
Ce livre est accompagn dun compagnon plus petit traitant des nouvelles techniques :
data warehouse, data mining, BD Web et BD multimdia. Il sagit l des nouveaux
thmes en vogue du domaine, qui vont sans doute profondment rvolutionner linfor-
matique de demain. Nous avons choisi de ne pas intgrer ces sujets ce livre mais
un volume spar, car ils ne sont pas encore stabiliss, alors que le relationnel et
lobjet ainsi que le mlange des deux, connu sous le nom objet-relationnel le sont
beaucoup plus.
En rsum, cet ouvrage est le fruit dune exprience de trente ans denseignement, de
formation et de conseil luniversit et dans lindustrie. Il aborde tous les sujets au
cur des systmes dinformation modernes. Chaque chapitre traite un thme particu-
lier. laide de notions prcisment dfinies une technique denseignement inven-
Avant-propos V
te par Michel Rocher dans les annes 1970, procdant par dfinitions informelles ,
nous clarifions des concepts souvent difficiles.
En annexe de cet ouvrage, vous trouverez une cinquantaine de textes dexercices qui
drivent de sujets dexamens proposs aux tudiants Paris VI ou Versailles depuis
1980, adapts et moderniss.
Avec cet ouvrage, nous esprons mettre entre les mains des gnrations actuelles et
futures denseignants, dingnieurs et de chercheurs une exprience pratique et tho-
rique exceptionnelle en matire de bases de donnes.
NOTATIONS
Afin de prsenter la syntaxe de certains langages, nous utiliserons les notations sui-
vantes :
[a] signifie que llment a est optionnel ;
[a]... signifie que llment a peut-tre rpt 0 n fois (n entier positif) ;
{a b} signifie que les lments a et b sont considrs comme un lment unique ;
{a | b} signifie un choix possible entre lalternative a ou b ;
< a > signifie que a est un paramtre qui doit tre remplac par une valeur effective.
SOMMAIRE
PARTIE 2 LE RELATIONNEL
LES BASES
I Introduction (Introduction)
INTRODUCTION
selon nimporte quel critre. Il doit tre possible aussi de retrouver leur structure, par
exemple le fait quun produit possde un nom, un prix et une quantit.
Plutt que de disserter longuement sur le concept de bases de donnes, prcisons ce
quest un SGBD. Un SGBD peut tre peru comme un ensemble de logiciels systmes
permettant aux utilisateurs dinsrer, de modifier et de rechercher efficacement des
donnes spcifiques dans une grande masse dinformations (pouvant atteindre
quelques milliards doctets) partage par de multiples utilisateurs. Les informations
sont stockes sur mmoires secondaires, en gnral des disques magntiques. Les
recherches peuvent tre excute partir de la valeur dune donne dsigne par un
nom dans un ensemble dobjets (par exemple, les produits de prix infrieur
100 francs), mais aussi partir de relations entre objets (par exemple, les produits
commands par un client habitant Paris). Les donnes sont partages, aussi bien en
interrogation quen mise jour. Le SGBD rend transparent le partage, savoir donne
lillusion chaque utilisateur quil est seul travailler avec les donnes.
En rsum, un SGBD peut donc apparatre comme un outil informatique permettant la
sauvegarde, linterrogation, la recherche et la mise en forme de donnes stockes sur
mmoires secondaires. Ce sont l les fonctions premires, compltes par des fonc-
tions souvent plus complexes, destines par exemple assurer le partage des donnes
mais aussi protger les donnes contre tout incident et obtenir des performances
acceptables. Les SGBD se distinguent clairement des systmes de fichiers par le fait
quils permettent la description des donnes (dfinition des types par des noms, des
formats, des caractristiques et parfois des oprations) de manire spare de leur uti-
lisation (mise jour et recherche). Ils permettent aussi de retrouver les caractris-
tiques dun type de donnes partir de son nom (par exemple, comment est dcrit un
produit). Le systme de fichiers est un composant de plus bas niveau ne prenant pas
en compte la structure des donnes. La tendance est aujourdhui intgrer le systme
de fichiers dans le SGBD, construit au-dessus.
En consquence, un SGBD se compose en premire approximation de trois couches
embotes de fonctions, depuis les mmoires secondaires vers les utilisateurs (voir
figure I.1) :
La gestion des rcipients de donnes sur les mmoires secondaires constitue tradi-
tionnellement la premire couche ; cest le gestionnaire de fichiers, encore appel
systme de gestion de fichiers. Celui-ci fournit aux couches suprieures des
mmoires secondaires idales adressables par objets et capables de recherches par
le contenu des objets (mcanismes dindexation notamment).
La gestion des donnes stockes dans les fichiers, lassemblage de ces donnes en
objets, le placement de ces objets dans les fichiers, la gestion des liens entre objets
et des structures permettant dacclrer les accs aux objets constituent la deuxime
couche ; cest le systme daccs aux donnes ou SGBD interne. Celui-ci repose
gnralement sur un modle de donnes internes, par exemple des tables relies par
des pointeurs.
Introduction 5
SGBD interne
Gestionnaire
M.S.
de fichiers
SGBD interne
SGBD externe
Ces couches de fonctions constituent sans doute seulement la moiti environ du code
dun SGBD. En effet, au-del de ses fonctions de recherche, de rangement et de pr-
sentation, un SGBD gre des problmes difficiles de partage et de cohrence de don-
nes. Il protge aussi les donnes contre les accs non autoriss. Ces fonctions qui
peuvent paratre annexes sont souvent les plus difficiles raliser et ncessitent beau-
coup de code.
Pour tre complet, signalons quau-dessus des SGBD les systmes dinformations
intgrent aujourdhui de plus en plus souvent des ateliers de gnie logiciel permettant
de modliser les donnes dune base de donnes et de reprsenter les traitements asso-
cis laide de graphiques et de langages de spcifications. Ces outils daide la
conception, bien que non intgrs dans le SGBD, permettent de spcifier les descrip-
tions des donnes. Ils sappuient pour cela sur les modles de donnes dcrits dans cet
ouvrage et supports par les SGBD.
6 BASES DE DONNES : OBJET ET RELATIONNEL
intgrant le relationnel et lobjet, ainsi que des architectures mieux rparties, permet-
tant une meilleure collaboration entre des utilisateurs concurrents. Cette troisime
gnration est donc influence par les modles objets, intgrant une structuration
conjointe des programmes et des donnes en types, avec des possibilits de dfinir des
sous-types par hritage. Cependant, elle conserve les acquis du relationnel en permet-
tant une vision tabulaire des objets et une interrogation via le langage SQL tendu aux
objets. Elle intgre aussi le support de rgles actives plus ou moins drives de la
logique. Ces rgles permettent de mieux maintenir la cohrence des donnes en rper-
cutant des mises jour dun objet sur dautres objets dpendants. Les systmes objet-
relationnels tels Oracle 8, DB2 Universal Database ou Informix Universal Server, ce
dernier issu du systme de recherche Illustra, sont les premiers reprsentants des sys-
tmes de 3e gnration. Les systmes objets tels ObjectStore ou O2 constituent une
voie plus novatrice vers la troisime gnration. Tous ces systmes tentent de
rpondre aux besoins des nouvelles applications (multimdia, Web, CAO, bureau-
tique, environnement, tlcommunications, etc.).
Quant la quatrime gnration, elle est dj en marche et devrait mieux supporter
Internet et le Web, les informations mal structures, les objets multimdias, laide la
prise de dcisions et lextraction de connaissances partir des donnes. Certes, il
devient de plus en plus dur de dvelopper un nouvel SGBD. On peut donc penser que
les recherches actuelles, par exemple sur linterrogation par le contenu des objets mul-
timdias distribus et sur lextraction de connaissances (data mining) conduiront
une volution des SGBD de 3e gnration plutt qu une nouvelle rvolution. Ce fut
dj le cas lors du passage de la 2e la 3e gnration, la rvolution conduite par
lobjet ayant en quelque sorte choue : elle na pas russi renverser le relationnel,
certes bouscul et adapt lobjet. Finalement, lvolution des SGBD peut tre perue
comme celle dun arbre, des branches nouvelles naissant mais se faisant gnralement
absorber par le tronc, qui grossit toujours davantage.
SGBD modernes sont discutes. Lensemble du chapitre est une introduction aux
techniques et problmes essentiels de la gestion des bases de donnes, illustres par-
tir dun langage adapt aux entits et associations.
Le chapitre III se concentre sur la gestion des fichiers et les langages daccs aux
fichiers. Certains peuvent penser que la gestion de fichiers est aujourdhui dpasse. Il
nen est rien, car un bon SGBD sappuie avant tout sur de bonnes techniques daccs
par hachage et par index. Nous tudions en dtail ces techniques, des plus anciennes
aux plus modernes, bases sur les indexes multiples et les hachages dynamiques
multi-attributs ou des bitmaps.
Le chapitre IV traite des modles lgus par les SGBD de premire gnration. Le
modle rseau tel quil est dfini par le CODASYL et implant dans le systme IDS.II
de Bull est dvelopp. Des exemples sont donns. Le modle hirarchique dIMS est
plus succinctement introduit.
Le chapitre V introduit les fondements logiques des bases de donnes, notamment
relationnelles. Aprs un rappel succinct de la logique du premier ordre, la notion de
bases de donnes logique est prsente et les calculs de tuples et domaines, la base
des langages relationnels, sont introduits.
La deuxime partie est consacre au relationnel. Le modle et les techniques de
contrle et doptimisation associes sont approfondis.
Le chapitre VI introduit le modle relationnel de Codd et lalgbre relationnelle asso-
cie. Les concepts essentiels pour dcrire les donnes tels quils sont aujourdhui sup-
ports par de nombreux SGBD sont tout dabord dcrits. Les types de contraintes
dintgrit qui permettent dassurer une meilleure cohrence des donnes entre elles
sont prciss. Ensuite, les oprateurs de lalgbre sont dfinis et illustrs par de nom-
breux exemples. Enfin, les extensions de lalgbre sont rsumes et illustres.
Le chapitre VII est consacr ltude du langage standardis des SGBD relationnels,
le fameux langage SQL. Les diffrents aspects du standard, accept en 1986 puis
tendu en 1989 et 1992, sont tout dabord prsents et illustrs par de nombreux
exemples. La version actuelle du standard accepte en 1992, connue sous le nom de
SQL2, est dcrite avec concision mais prcision. Il sagit l du langage aujourdhui
offert, avec quelques variantes, par tous les SGBD industriels.
Le chapitre VIII traite des rgles dintgrit et des bases de donnes actives. Le langage
dexpression des contraintes dintgrit et des dclencheurs intgr SQL est tudi.
Puis, les diffrentes mthodes pour contrler lintgrit sont prsentes. Enfin, les notions
de base de donnes active et les mcanismes dexcution des dclencheurs sont analyss.
Le chapitre IX expose plus formellement le concept de vue, dtaille le langage de
dfinition et prsente quelques exemples simples de vues. Sont successivement abor-
ds : les mcanismes dinterrogation de vues, le problme de la mise jour des vues,
lutilisation des vues concrtes notamment pour les applications dcisionnelles et
quelques autres extensions possibles du mcanisme de gestion des vues.
Introduction 9
Le chapitre XVI essaie de faire le point sur tous les aspects de la gestion de transac-
tions dans les SGBD centraliss. Aprs quelques rappels de base, nous traitons
dabord les problmes de concurrence. Nous tudions ensuite les principes de la ges-
tion de transactions. Comme exemple de mthode de reprise intgre, nous dcrivons
la mthode ARIES implmente IBM, la rfrence en matire de reprise. Nous ter-
minons la partie sur les transactions proprement dites en prsentant les principaux
modles de transactions tendus introduits dans la littrature. Pour terminer ce cha-
pitre, nous traitons du problme un peu orthogonal de confidentialit.
Le chapitre XVII traite le problme de la conception des bases de donnes objet-rela-
tionnel. Cest loccasion de prsenter le langage de modlisation UML, plus prcis-
ment les constructions ncessaires la modlisation de BD. Nous discutons aussi des
techniques dintgration de schmas. Le chapitre dveloppe en outre les rgles pour
passer dun schma conceptuel UML un schma relationnel ou objet-relationnel. La
thorie de la normalisation est intgre pour affiner le processus de conception. Les
principales techniques doptimisation du schma physique sont introduites.
Enfin, le chapitre XVIII couvre les directions nouvelles dvolution des SGBD : data-
warehouse, data mining, Web et multimdia. Ces directions nouvelles, sujets de nom-
breuses recherches actuellement, font lobjet dun livre complmentaire du mme
auteur chez le mme diteur.
4. BIBLIOGRAPHIE
De nombreux ouvrages traitent des problmes soulevs par les bases de donnes.
Malheureusement, beaucoup sont en anglais. Vous trouverez la fin de chaque cha-
pitre du prsent livre les rfrences et une rapide caractrisation des articles qui nous
ont sembl essentiels. Voici quelques rfrences dautres livres traitant de problmes
gnraux des bases de donnes que nous avons pu consulter. Des livres plus spciali-
ss sont rfrencs dans le chapitre traitant du problme correspondant.
[Date90] Date C.J., An Introduction to Database Systems, 5e edition, The Systems
Programming Series, volumes I (854 pages) et II (383 pages), Addison Wesley,
1990.
Ce livre crit par un des inventeurs du relationnel est tourn vers lutilisateur.
Le volume I traite des principaux aspects des bases de donnes relationnelles,
sans oublier les systmes bass sur les modles rseau et hirarchique. Ce
volume est divis en six parties avec des appendices traitant de cas de systmes.
La partie I introduit les concepts de base. La partie II prsente un systme rela-
tionnel type, en fait une vue simplifie de DB2, le SGBD dIBM. La partie III
approfondit le modle et les langages de manipulation associs. La partie IV
traite de lenvironnement du SGBD. La partie V est consacre la conception
Introduction 11
sente des tudes de cas de systmes et deux annexes traitent des modles
rseaux et hirarchiques. La nouvelle bible des SGBD en anglais.
[Maier83] Maier D., The Theory of Relational Databases, Computer Science Press,
1983.
Le livre synthtisant tous les dveloppements thoriques sur les bases de donnes
relationnelles mens au dbut des annes 80. En 600 pages assez formelles,
Maier fait le tour de la thorie des oprateurs relationnels, des dpendances
fonctionnelles, multivalues, algbriques et de la thorie de la normalisation.
[Parsaye89] Parsaye K., Chignell M., Khoshafian S., Wong H., Intelligent Databases,
478 pages, Wiley Editions, 1989.
Un livre sur les techniques avances la limite des SGBD et de lintelligence
artificielle : SGBD objets, systmes experts, hypermdia, systmes textuels,
bases de donnes intelligentes. Le SGBD intelligent est la convergence de
toutes ces techniques et intgre rgles et objets.
[Ullman88] Ullman J.D., Principles of Database and Knowledge-base Systems,
volumes I (631 pages) et II (400 pages), Computer Science Press, 1988.
Deux volumes trs complets sur les bases de donnes, avec une approche plutt
fondamentale. Jeffrey Ullman dtaille tous les aspects des bases de donnes,
des mthodes daccs aux modles objets en passant par le modle logique. Les
livres sont finalement trs centrs sur une approche par la logique des bases de
donnes. Les principaux algorithmes daccs, doptimisation de requtes, de
concurrence, de normalisation, etc. sont dtaills. noter lauteur traite dans
un mme chapitre les systmes en rseau et les systmes objets, quil considre
de mme nature.
[Valduriez99] Valduriez P., Ozsu T., Principles of Distributed Database Systems, 562
pages, Prentice Hall, 2e dition,1999.
Le livre fondamental sur les bases de donnes rparties. Aprs un rappel sur les
SGBD et les rseaux, les auteurs prsentent larchitecture type dun SGBD
rparti. Ils abordent ensuite en dtail les diffrents problmes de conception dun
SGBD rparti : distribution des donnes, contrle smantique des donnes, va-
luation de questions rparties, gestion de transactions rparties, liens avec les
systmes opratoires et multibases. La nouvelle dition aborde aussi le parall-
lisme et les middlewares. Les nouvelles perspectives sont enfin voques.
Chapitre II
OBJECTIFS ET ARCHITECTURE
DES SGBD
1. INTRODUCTION
Mme si vous navez jamais utilis de systme de gestion de bases de donnes
(SGBD), vous avez certainement une ide de ce quest une base de donnes (BD) et
par l mme un SGBD. Une BD est peut-tre pour certains une collection de fichiers
relis par des pointeurs multiples, aussi cohrents entre eux que possible, organiss de
manire rpondre efficacement une grande varit de questions. Pour dautres, une
BD peut apparatre comme une collection dinformations modlisant une entreprise
du monde rel. Ainsi, un SGBD peut donc tre dfini comme un ensemble de logiciels
systmes permettant de stocker et dinterroger un ensemble de fichiers interdpen-
dants, mais aussi comme un outil permettant de modliser et de grer les donnes
dune entreprise.
Les donnes stockes dans des bases de donnes modlisent des objets du monde rel,
ou des associations entre objets. Les objets sont en gnral reprsents par des articles
de fichiers, alors que les associations correspondent naturellement des liens entre
articles. Les donnes peuvent donc tre vues comme un ensemble de fichiers relis
par des pointeurs ; elles sont interroges et mises jour par des programmes dappli-
cations crits par les utilisateurs ou par des programmes utilitaires fournis avec le
14 BASES DE DONNES : OBJET ET RELATIONNEL
P1 Pi Pn
Cobol C L4G
SGBD
E/S disques
Disques
EXEMPLES
3. Le type dobjet Entit possdant les proprits P1, P2Pn et muni des opra-
tions Crer, Consulter, Modifier, Dtruire est un type dobjet gnrique qui per-
met de modliser de manire trs gnrale la plupart des objets du monde rel.
EXEMPLES
disques pour simplifier la vision des utilisateurs. Pour cela, trois niveaux de descrip-
tion de donnes ont t distingus par le groupe ANSI/X3/SPARC [ANSI78,
Tsichritzis78]. Ces niveaux ne sont pas clairement distingus par tous les SGBD : ils
sont mlangs en deux niveaux dans beaucoup de systmes existants. Cependant, la
conception dune base de donnes ncessite de considrer et de spcifier ces trois
niveaux, certains pouvant tre pris en compte par les outils de gnie logiciel aidant
la construction des applications autour du SGBD.
Type dobjets :
BUVEUR(Nom, Prnom, Adresse)
VIN(Cru, Millsime, Qualit, Quantit)
Type dassociations :
ABUS(BUVEUR, VIN, Date, Quantit)
Fichier Fichier
BUVEURS VINS
Adresse Qualit
NbAbus Quantit
RefVin
Date Date
Quantit
quau niveau conceptuel et interne les schmas dcrivent toute une base de donnes,
au niveau externe ils dcrivent simplement la partie des donnes prsentant un intrt
pour un utilisateur ou un groupe dutilisateurs. En consquence, un schma externe est
souvent qualifi de vue externe. Le modle externe utilis est dpendant du langage
de manipulation de la base de donnes utilis. La figure II.4 donne deux exemples de
schma externe pour la base de donnes dont le schma conceptuel est reprsent
figure II.2. Il est souligner que la notion de schma externe permet dassurer une
certaine scurit des donnes. Un groupe de travail ne peut en effet accder quaux
donnes dcrites dans son schma externe. Les autres donnes sont ainsi protges
contre les accs non autoriss ou mal intentionns de la part de ce groupe de travail.
Identit_Buveurs
Nom
Buveurs_de_Vins Adresse
Nom Prnom
Prnom
NbAbus
Vins_Consomms
Cru Cru
Millsime Millsime
Quantit
Quantit_Consomme
Nous rappelons ci-dessous ce que reprsente chacun des niveaux de schma laide
dune notion.
SCHMA CONCEPTUEL
SCHMA INTERNE
de prix. Dupont Jules est un nom. Dans les bases de donnes, des instances de types
lmentaires sont groupes ensemble pour constituer un objet compos. Labstraction
qui concatne des donnes lmentaires (et plus gnralement des objets) est appele
lagrgation. La figure II.6 reprsente par un graphe lagrgation des donnes
(Volnay, 1978, Excellente, 100) pour constituer un objet compos dcrivant le vin
identifi par Volnay78.
Volnay78
Le modle entit-association [Chen76] est bas sur une perception du monde rel qui
consiste distinguer des agrgations de donnes lmentaires appeles entits et des
liaisons entre entits appeles associations. Intuitivement, une entit correspond un
objet du monde rel gnralement dfini par un nom, par exemple un vin, un buveur,
une voiture, une commande, etc. Une entit est une agrgation de donnes lmen-
taires. Un type dentit dfinit un ensemble dentits constitu par des donnes de
mme type. Les types de donnes agrges sont appels les attributs de lentit ; ils
dfinissent ses proprits.
Une association correspond un lien logique entre deux entits ou plus. Elle est sou-
vent dfinie par un verbe du langage naturel. Une association peut avoir des proprits
particulires dfinies par des attributs spcifiques.
Millsime Quantit
Prnom Adresse Quantit Date
Qualit
ment limage de lorganisation canonique de donnes dans le monde rel. Pour per-
mettre de conserver les possibilits doptimisation de performances vitales aux sys-
tmes informatiques, les notions de mthodes daccs, modes de placement, critres
de tri, chanages et codages de donnes devraient directement apparatre dans le
monde rel et donc dans les applications. Tout changement informatique devrait alors
tre rpercut dans la vie dune entreprise et par consquent impliquerait une recons-
truction des applications. Cela est bien sr impraticable, do la ncessit dindpen-
dance des structures de stockages aux donnes du monde rel.
tions qui permettent de dfinir les donnes et de changer leur dfinition sont appeles
outils dadministration des donnes. Afin de permettre un contrle efficace des don-
nes, de rsoudre les conflits entre divers points de vue pas toujours cohrents, de
pouvoir optimiser les accs aux donnes et lutilisation des moyens informatiques, on
a pens centraliser ces fonctions entre les mains dun petit groupe de personnes hau-
tement qualifies, appeles administrateurs de donnes.
En fait, la centralisation des descriptions de donnes entre les mains dun groupe sp-
cialis a souvent conduit des difficults dorganisation. Aussi, lvolution des SGBD
modernes tend fournir des outils permettant de dcentraliser la description de don-
nes, tout en assurant une cohrence entre les diverses descriptions partielles. Un dic-
tionnaire de donnes dynamique pourra ainsi aider les concepteurs de bases de don-
nes. Pour permettre une volution rapide, les descriptions de donnes devront tre
faciles consulter et modifier. Lvolution va donc vers le dveloppement doutils
intgrs capables de faciliter ladministration des donnes et dassurer la cohrence
des descriptions.
Un SGBD fournit des commandes permettant de dfinir les schmas interne, concep-
tuel et externe. Afin dillustrer concrtement cette fonctionnalit, voici les com-
mandes essentielles permettant de crer un schma avec le seul modle prsent
jusque-l, cest--dire le modle entit-association. La syntaxe drive dune extension
du langage QUEL [Zook77] au modle entit-association.
Voici donc les commandes minimales ncessaires :
pour crer une base de donnes :
CREATDB <nom-de-base>
pour crer une entit :
CREATE ENTITY <nom-dentit> (<nom-dattribut> <type>
[{,<nom-dattribut> <type>}])
pour crer une association :
CREATE RELATIONSHIP <nom-dassociation> (<nom-dentit>
[{,<nom dentit>}], [{,<nom-dattribut> <type>}])
pour dtruire une entit ou une association :
DESTROY {<nom-de-relation> | <nom-dassociation>}
pour dtruire une base :
DESTROYDB <nom-de-base>.
Dautres commandes sont ncessaires, par exemple pour crer le schma interne. Un
exemple typique ce niveau est une commande de cration dindex sur un ou plu-
sieurs attributs dune entit :
CREATE INDEX ON <nom-dentit>
USING <nom-dattribut> [{,<nom-dattribut>}]
Nous verrons plus loin des commandes de cration de vues (schmas externes).
32 BASES DE DONNES : OBJET ET RELATIONNEL
Une recherche sexprime alors laide de requte du type suivant, o la liste rsultat
est une suite dattributs de variables ou de fonctions appliques ces attributs :
RETRIEVE (liste rsultat)
[WHERE qualification] ;
Voici quelques questions simples afin dillustrer les capacits minimales dun SGBD.
(Q1) Rechercher les noms et adresses des buveurs :
RETRIEVE B.Nom, B.Adresse;
(Q2) Rechercher les crus et millsimes des vins de qualit excellente :
RETRIEVE V.Cru, V.Millsime
WHERE V.Qualit = Excellente ;
(Q3) Rechercher les noms des gros buveurs ainsi que les crus, dates et quantits de
vins quils ont consomm :
RETRIEVE B.Nom, V.Cru, A.Date, A.Quantit
WHERE B.Type = Gros AND A.Buveur = B AND A.Vin = V ;
Cette commande permet dajouter les instances dfinies par les listes de valeurs
lentit de nom <nom-dentit>. Plusieurs instances dentits peuvent ainsi tre ajou-
tes dans la base. La liste dattributs permet de spcifier les seuls attributs que lon
dsire documenter, les autres tant a priori remplacs par une valeur nulle signifiant
34 BASES DE DONNES : OBJET ET RELATIONNEL
inconnue. Par exemple, lajout du vin <Volnay, 1978, Excellente, 100> dans la base
seffectuera par la commande :
(U1) APPEND TO Vin (Cru, Millsime, Qualit, Quantit)
(Volnay, 1978, Excellente, 100) ;
Linsertion dinstances dassociation est plus dlicate car il faut insrer un enregistre-
ment rfrenant des entits de la base. titre indicatif, cela peut tre fait par une
commande APPEND TO dans laquelle les rfrences aux entits connectes sont des
variables calcules par une qualification. On aboutit alors une insertion qualifie du
type :
APPEND [TO] <nom-dassociation> [(<liste-dattributs>)]
<liste-de-valeurs> [{,<liste-de-valeurs>}]
WHERE <qualification> ;
Une liste de valeurs peut alors comprendre des attributs extraits de la base par la qua-
lification. Par exemple, la commande suivante insre un abus de Volnay 78 au buveur
Dupont :
(U2) APPEND TO abus(buveur, vin, date, quantit)
(V, B, 10-02-92, 100)
WHERE B.Nom = Dupont AND V.Cru = Volnay
AND V. Millsime = 1978 ;
Elle permet de changer la valeur des attributs figurant dans la liste pour tous les tuples
de la variable satisfaisant la qualification. Par exemple, lajout de 1 000 litres aux
stocks de Volnay seffectuera par la commande (V est suppose une variable sur
lentit Vin) :
(U3) REPLACE V (Quantit = Quantit + 1.000)
WHERE V.Cru = Volnay ;
Finalement, il est aussi possible de supprimer des tuples dune base de donnes par la
commande trs simple :
DELETE variable
WHERE <qualification>
Par exemple, la suppression de tous les vins de millsime 1992 seffectue par :
(U4) DELETE V
WHERE V.Millsime = 1992 ;
Objectifs et architecture des SGBD 35
Dans un SGBD trois niveaux de schmas, il existera donc deux niveaux de transfor-
mation :
la transformation conceptuelle interne permettant de faire passer des instances de
donnes depuis le format conceptuel au format interne et rciproquement ;
la transformation externe conceptuelle permettant de faire passer des instances de
donnes depuis le format conceptuel au format externe et rciproquement.
titre dexemple, la figure II.9 (page suivante) reprsente la transformation dun
ensemble doccurrences de donnes depuis le format conceptuel indiqu au format
externe indiqu.
Pour tre capable deffectuer automatiquement la transformation des donnes dun
niveau un autre, un SGBD doit connatre les correspondances existant entre les
niveaux. Pour cela, lors de la dfinition des schmas, le groupe dadministration des
donnes doit expliciter comment les schmas se dduisent les uns des autres au
moyen de rgles de correspondance. Ces rgles sont souvent exprimer sous la forme
de questions.
Dans les systmes de gestion de base de donnes classiques, les rgles de correspon-
dance sont bien souvent mlanges avec les schmas. Il y a cependant intrt distin-
guer ces deux notions. Par exemple, le langage QUEL permet de dfinir une vue de la
base (schma externe) par une commande du type suivant :
DEFINE VIEW <nom dentit> (<liste-dattributs>) AS
RETRIEVE (liste rsultat)
[WHERE qualification] ;
36 BASES DE DONNES : OBJET ET RELATIONNEL
Table Externe
Transformation
Conceptuel - Externe
Entit et Associations
Conceptuelles Chablis
Drink-1
Transformation
Conceptuel - Interne
Une transaction est donc un groupe de mises jour qui fait passer la base dun tat
un autre tat. Les tats successifs doivent tre cohrents et donc respecter les
contraintes dintgrit. Cette responsabilit incombe au programmeur qui code la tran-
saction. Cette proprit est connue sous le nom de correction des transactions.
Notion II.22 : Correction des transactions (Transaction Correctness)
Proprit dune transaction consistant respecter la cohrence de la base de donnes en fin dex-
cution.
Lorsquune transaction est partiellement excute, les donnes peuvent passer par des
tats incohrents transitoires, qui seront corrigs par les mises jour suivantes de la
transaction. Pendant cette priode dactivit, les effets de la transaction ne doivent pas
tre visibles aux autres transactions. Cette proprit est connue sous le nom disola-
tion des transactions ; lisolation doit tre assure par le SGBD.
Notion II.23 : Isolation des transactions (Transaction Isolation)
Proprit dune transaction consistant ne pas laisser visible lextrieur les donnes modifies
avant la fin de la transaction.
En rsum, un bon SGBD doit donc assurer les trois proprits prcdentes pour les
transactions quil gre : Atomicit, Correction, Isolation. Ces proprits sont parfois
rsumes par le sigle ACID, le D signifiant que lon doit aussi pouvoir conserver
durablement les mises jour des transactions (en anglais, durability). En plus, le
SGBD doit garantir la scurit des donnes. Rappelons que la scurit permet dviter
les accs non autoriss aux donnes par des mcanismes de contrle de droits daccs,
mais aussi de restaurer des donnes correctes en cas de pannes ou derreurs.
De manire plus gnrale, les SGBD sont amens supporter des rgles permettant
dinfrer (cest--dire de calculer par des raisonnements logiques) de nouvelles don-
nes partir des donnes de la base, lors des mises jour ou des interrogations. Cela
conduit la notion de SGBD dductif, capable de dduire des informations partir de
celles connues et de rgles de dduction.
Enfin, les SGBD sont aussi amens grer des objets complexes, tels des dessins
darchitecture ou des cartes de gographie, en capturant finement le dcoupage de ces
gros objets en sous-objets composants. Ces objets pourront tre atteints via des proc-
dures elles-mmes intgres au SGBD. Cela conduit la notion de SGBD objets,
capable de grer des objets multiples manipuls par des fonctions utilisateurs.
5. ARCHITECTURE FONCTIONNELLE
DES SGBD
5.1. LARCHITECTURE TROIS NIVEAUX
DE LANSI/X3/SPARC
Les groupes de normalisation se sont penchs depuis fort longtemps sur les architec-
tures de SGBD. la fin des annes 70, le groupe ANSI/X3/SPARC DBTG a propos
une architecture intgrant les trois niveaux de schmas : externe, conceptuel et
interne. Bien quancienne [ANSI78], cette architecture permet de bien comprendre les
niveaux de description et transformation de donnes possible dans un SGBD.
Larchitecture est articule autour du dictionnaire de donnes et comporte deux
parties :
1. un ensemble de modules (appels processeurs) permettant dassurer la description
de donnes et donc la constitution du dictionnaire de donnes ;
2. une partie permettant dassurer la manipulation des donnes, cest--dire linterro-
gation et la mise jour des bases.
Dans chacune des parties, on retrouve les trois niveaux interne, conceptuel et externe.
Larchitecture propose est reprsente figure II.10.
Les fonctions de chacun des processeurs indiqus sont les suivantes. Le processeur de
schma conceptuel compile le schma conceptuel et, dans le cas o il ny a pas
derreur, range ce schma compil dans le dictionnaire des donnes. Le processeur de
schma externe compile les schmas externes et les rgles de correspondance externe
conceptuel et, aprs une compilation sans erreur, range le schma compil et les
40 BASES DE DONNES : OBJET ET RELATIONNEL
Admin
Entreprise
3 Processeur 3
Admin Admin
de schma
BD Application
Conceptuel
6 2 4
Processeur 7 5 Processeur
de schma DICTIONNAIRE de schma
Interne Externe
14
12 9
Systme Programme
dE/S dapplication
13 8
Programmeur
dapplication
Modification de requtes
Contrle d'intgrit
Mtabase Contrleur Contrle d'autorisation
Ordonnancement
Optimisation
Optimiseur laboration d'un plan
Excution du plan
Mthodes d'accs
Excuteur Contrle de concurrence
Atomicit des transactions
BD
DML
SCHMA
SGBD
SCHMA DE OS
STOCKAGE
BD
6. ARCHITECTURES OPRATIONNELLES
DES SGBD
Depuis le milieu des annes 80, les SGBD fonctionnent selon larchitecture client-ser-
veur. Nous introduisons ces architectures brivement ci-dessous.
mmes donnes, il est ncessaire de les synchroniser, par exemple par des sma-
phores, afin dviter les problmes de concurrence daccs. Cela peut entraner des
pertes de temps importantes, et donc de mauvaises performances en prsence dusa-
gers multiples.
CLIENT
Langages et outils de gestion de donnes
SERVEUR DL
DMCS
i - DL
OS
BD
deux couches de traitement applicatifs est appele architecture deux strates (two-
tiered architecture).
La figure II.14 propose une vue plus dtaille dune architecture client-serveur deux
strates. Lapplication est crite laide dun outil applicatif, souvent un L4G. Elle
soumet ses demandes de services (requtes au SGBD ou invocation de procdures
stockes au middleware qui les transfert au serveur. Le middleware comporte un com-
posant client et un composant serveur qui permettent les changes de commandes via
le protocole rseau. Sur la figure, il est appel outil de connectabilit. Si vous souhai-
tez en savoir plus sur le middleware, reportez-vous [Gardarin97].
Application
Outil Applicatif
Client
Outil de connectabilit
Protocole Rseau
Requtes
Rsultats
de services
Rseau local
Protocole Rseau
BD
Avec lapparition dInternet et du Web, les architectures client-serveur ont volu vers
des architectures trois strates (three-tiered architecture). Le client est responsable
de la prsentation. Il utilise pour cela des browsers Web. Le serveur dapplication ex-
48 BASES DE DONNES : OBJET ET RELATIONNEL
Clients de
Browser .. Browser
prsentation
Rseau Internet/Intranet
Service applicatifs
Outil Applicatif
Serveur
Outil de connectabilit dapplication
Protocole Rseau
Requtes
Rsultats
de services
Rseau local
Protocole Rseau
BD
La figure II.15 illustre une telle architecture. Les middlewares mis en jeu sont beau-
coup plus complexes.
Larchitecture client-serveur est aujourdhui bien adapte aux systmes rpartis autour
dun rseau local et/ou dInternet. Elle permet de multiples postes ou stations de tra-
vail distribus sur la plante de partager les mmes donnes. Celles-ci sont gres de
manire fiable et avec de bons contrles de concurrence au niveau du serveur. Un pro-
cessus client sur la station de travail ou lordinateur personnel gre les applications de
lutilisateur qui mettent des requtes au serveur. Un client peut mme invoquer plu-
sieurs serveurs : on parle alors darchitecture client-multiserveur. Linconvnient mais
aussi lavantage du client-serveur est de centraliser la gestion des donnes au niveau
du serveur.
Donnes
textuelles
Descriptions
Systmes Donnes
des produits
classiques techniques
Rseau de communication
Donnes
gographiques
Site 5 Site 3
La figure II.16 illustre une architecture rpartie. Celle-ci est compose de diffrents
serveurs munis de SGBD diffrents et spcialiss. Cest un exemple de base de don-
nes rpartie htrogne, encore appele base de donnes fdre. Nous ntudions
pas les bases de donnes rparties dans cet ouvrage. Lauteur pourra se reporter
[Gardarin97] et [Valduriez99] pour une tude plus complte des systmes de bases
de donnes rparties.
7. CONCLUSION
Dans ce chapitre, nous avons prsent les objectifs des systmes de gestion de bases
de donnes, puis les concepts et mthodes essentiels de ces systmes. Cela nous a
conduit tudier les architectures fonctionnelles, puis les architectures opration-
nelles. Afin de concrtiser nos propos, nous avons introduit une variante du langage
QUEL pour dcrire et manipuler les donnes. Larchitecture propose en 1978 par le
groupe ANSI/X3/SPARC permet de bien comprendre les niveaux de schmas pos-
sible. Larchitecture fonctionnelle de rfrence est voisine de celle retenue dans le sys-
tme SABRINA [Gardarin86] ou encore de celle des systmes INGRES ou ORACLE.
Les architectures oprationnelles sont aujourdhui client-serveur, mais voluent de
plus en plus souvent vers le rparti.
Il est possible de rsumer ce chapitre en rappelant quun SGBD offre une interface de
description de donnes qui permet de documenter le dictionnaire de donnes. Le com-
pilateur du langage de description gre cette mtabase. Un SGBD offre aussi une
interface de manipulation de donnes (recherches et mises jour) qui permet de modi-
fier ou de retrouver des donnes dans la base. Le compilateur-optimiseur du langage
de manipulation gnre des plans daccs optimiss. Ceux-ci sont excuts par le pro-
cessus serveur, qui gre aussi la concurrence et la fiabilit. Les requtes peuvent tre
mises par des programmes dapplications crits dans des langages plus ou moins tra-
ditionnels, ou par des utilisateurs travaillant en interactif partir dutilitaires.
Objectifs et architecture des SGBD 51
Les SGBD tels que prsents dans ce chapitre sappuient au niveau interne sur une
gestion de fichiers. Celle-ci peut tre une partie intgrante du systme opratoire. Elle
peut tre plus ou moins sophistique. Dans le chapitre suivant, nous allons tudier la
gestion de fichiers, de la plus simple la plus labore. Selon le niveau de sophistica-
tion du gestionnaire de fichiers sur lequel il est construit, un SGBD devra ou non int-
grer des fonctionnalits de type gestion de fichiers au niveau interne. Aujourdhui, la
plupart des SGBD intgrent leurs propres mthodes daccs aux fichiers (parfois
appels segments), du type de celles que nous allons tudier dans le chapitre suivant.
8. BIBLIOGRAPHIE
[ANSI75] ANSI/X3/SPARC Study Group on Data Base Management Systems,
Interim Report , ACM SIGMOD Bulletin, vol. 7, n 2, ACM Ed., 1975.
Ce document prsente larchitecture ANSI/X3/SPARC et ses trois niveaux de
schmas.
[ANSI78] ANSI/X3/SPARC Study Group on Data Base Management Systems,
Framework Report on Database Management Systems , Information
Systems, vol. 3, n 3 1978.
Il sagit du document final prsentant larchitecture trois niveaux de schmas
de lANSI.
[ANSI86] ANSI/X3/SPARC Database Architecture Framework Task Group,
Reference Model for DBMS Standardization , ACM SIGMOD Record,
vol. 15, n 1, mars 1986.
Il sagit du document final prsentant ltude sur les architectures de SGBD du
groupe DAFTG. Celui-ci conseille de ne pas chercher standardiser davantage
les architectures, mais plutt de sefforcer de standardiser les langages.
[Astrahan76] Astrahan M., Blasgen M., Chamberlin D., Eswaran K., Gray. J.,
Griffiths P., King W., Lorie R., McJones P., Mehl J., Putzolu G., Traiger I.,
Wade B., Watson V., System R: Relational Approach to Database
Management , ACM Transactions on Database Systems, vol. 1, n 2, juin 1976.
Cet article prsente System R, le premier prototype de SGBD relationnel ralis
par IBM dans son centre de recherches de San Jos. System R comporte une
architecture deux niveaux de schma et deux processeurs essentiels : le RDS
(Relational Data System) qui comprend analyseur, traducteur et optimiseur, et
le RSS qui correspond lexcuteur. System R a donn naissance SQL/DS et
DB2.
52 BASES DE DONNES : OBJET ET RELATIONNEL
[Valduriez99] Valduriez P., Ozsu T., Principles of Distributed Database Systems, 562
pages, Prentice Hall, 2e dition,1999.
Le livre fondamental sur les bases de donnes rparties en anglais. Aprs un
rappel sur les SGBD et les rseaux, les auteurs prsentent larchitecture type
dun SGBD rparti. Ils abordent ensuite en dtails les diffrents problmes de
conception dun SGBD rparti : distribution des donnes, contrle smantique
des donnes, valuation de questions rparties, gestion de transactions rpar-
ties, liens avec les systmes opratoires et multibases. La nouvelle dition
aborde aussi le paralllisme et les middlewares. Les nouvelles perspectives sont
enfin voques.
[Weldon79] Weldon J.L., The Practice of Data Base Administration , National
Computer Conference, AFIPS Ed., V.48, New York, 1979.
Cet article rsume les rsultats dune tude du rle des administrateurs de don-
nes travers une enqute ralise auprs de 25 dentre eux. Un appendice
permet plus particulirement de dfinir leurs tches : tablissement du schma
directeur, conception des bases de donnes, tests, contrles et support opra-
tionnel.
[Zaniolo83] Zaniolo C., The Database Language GEM , ACM SIGMOD Int. Conf.
on Management of Data, San Jos, CA, 1983.
Cet article prsente une extension trs complte du langage QUEL pour le
modle entit-association. Cette extension a t implante au-dessus dune
machine bases de donnes excutant un langage proche de QUEL.
[Zook77] Zook W. et. al., INGRES Reference Manual, Dept. of EECS, University of
California, Berkeley, CA, 1977.
Ce document dcrit les interfaces externes de la premire version dINGRES et
plus particulirement le langage QUEL.
Chapitre III
FICHIERS, HACHAGE
ET INDEXATION
1. INTRODUCTION
Un SGBD inclut en son cur une gestion de fichiers. Ce chapitre est consacr
ltude des fichiers et de leurs mthodes daccs. Historiquement, la notion de fichier
a t introduite en informatique dans les annes 50, afin de simplifier lutilisation des
mmoires secondaires des ordinateurs et de fournir des rcipients de donnes plus
manipulables aux programmes. Au dbut, un fichier tait bien souvent limage dune
portion nomme de bande magntique. Puis, au fur et mesure de la sophistication
des systmes informatiques, les fichiers sont devenus plus structurs. Des mthodes
daccs de plus en plus performantes ont t labores. Aujourdhui, les fichiers sont
la base des grands systmes dinformation ; la gestion de fichiers est le premier
niveau dun SGBD.
Idalement, un gestionnaire de fichiers doit permettre le traitement par linformatique
de la gestion complte dune entreprise. Les donnes descriptives des objets grs par
lentreprise, ainsi que les programmes spcifiant les traitements appliqus aux don-
nes, doivent pouvoir tre stocks dans des fichiers grs par le systme informatique.
Les traitements de ces donnes peuvent tre excuts par lots, en fin de mois par
exemple, ou en fin de semaine, mais aussi (et cest en gnral plus difficile) lunit
56 BASES DE DONNES : OBJET ET RELATIONNEL
ds que survient un vnement dans le monde rel : on parle alors de traitement tran-
sactionnel, mode de traitement privilgi par les bases de donnes.
Un gestionnaire de fichiers devrait par exemple permettre de traiter lapplication
comptabilit dune socit de livraison. Cette application est reprsente figure III.1.
Elle gre les comptes des clients et dite les factures correspondant aux livraisons.
Pour calculer les montants facturer et dduire des comptes clients, un catalogue
des prix est utilis. Les traitements peuvent tre effectus en traitement par lots, en fin
de mois ; dans ce cas, les bordereaux de livraison du mois sont traits ensemble, par
exemple partir dun fichier de saisie. Le traitement dune livraison peut tre effectu
en transactionnel ; dans ce cas, la description de la livraison est tape en direct sur un
terminal et les traitements associs sont immdiatement excuts.
Livraisons Factures
Saisie
Impression
Catalogue Comptabilit
des prix
Fichier
Comptes Comptes
clients clients
Fichier Fichier mis jour
Nous allons, dans ce chapitre, tudier plus spcifiquement la gestion des fichiers au
cur des SGBD. Un fichier est un rcipient de donnes identifi par un nom et conte-
nant des informations systme ou utilisateur. La gestion des fichiers est une des fonc-
tions essentielles offertes par les systmes opratoires. Cest en effet grce cette
fonction quil est possible de traiter et de conserver des quantits importantes de don-
nes, et de les partager entre plusieurs programmes. De plus, elle sert de base au
niveau interne des Systmes de Gestion de Bases de Donnes (SGBD) qui la compl-
tent par des mthodes daccs spcifiques ou la reprennent totalement.
Ce chapitre introduit tout dabord les objectifs de la gestion des fichiers et les
concepts de base associs, puis tudie les fonctions accomplies par le noyau dun ges-
tionnaire de fichiers. Enfin, et cest son objet essentiel, il prsente les principales
organisations et mthodes daccs de fichiers. Celles-ci sont groupes en deux
Fichiers, hachage et indexation 57
classes : (i) les mthodes par hachage qui appliquent une fonction de hachage liden-
tifiant des articles dun fichier, appel cl, afin de retrouver son emplacement dans le
fichier ; (ii) les mthodes indexes qui grent une table des matires du fichier afin
daccder aux articles.
en moyenne. Notons quils restent encore de lordre de 20 000 fois plus levs que
ceux des mmoires centrales. Nous appellerons une pile de disques un volume.
Un volume disque est associ un tourne-disque. Les volumes peuvent tre fixes ou
amovibles. Si le volume est amovible, il est mont sur un tourne-disque pour utilisa-
tion puis dmont aprs. Les volumes amovibles sont monts et dmonts par les op-
rateurs, en gnral sur un ordre du systme. Un contrleur de disque contrle en gn-
ral plusieurs tourne-disques. La notion de volume sapplique galement aux bandes
magntiques o un volume est une bande. Une unit peut alors comporter un ou plu-
sieurs drouleurs de bande.
Un volume et lquipement de lecture-criture associ un tourne-disque sont repr-
sents figure III.2. Un volume se compose de p disques (par exemple 9), ce qui cor-
respond 2p 2 surfaces magntises, car les deux faces externes ne le sont pas. Les
disques ttes mobiles comportent une tte de lecture-criture par surface. Cette tte
est accroche un bras qui se dplace horizontalement de manire couvrir toute la
surface du disque. Un disque est divis en pistes concentriques numrotes de 0 n
(par exemple n = 1024). Les bras permettant de lire/crire les pistes dun volume sont
solidaires, ce qui force leur dplacement simultan. Les disques tournent continment
une vitesse de quelques dizaines de tours par seconde. Lensemble des pistes, dcrit
quand les bras sont positionns, est appel cylindre.
Chaque piste dun disque supporte plusieurs enregistrements physiques appels sec-
teurs, de taille gnralement constante, mais pouvant tre variable pour certains types
de disque. Le temps daccs un groupe de secteurs conscutifs est une des caract-
ristiques essentielles des disques. Il se compose :
1. du temps ncessaire au mouvement de bras pour slectionner le bon cylindre
(quelques millisecondes des dizaines de millisecondes selon lamplitude du dpla-
cement du bras et le type de disque) ;
2. du temps de rotation du disque ncessaire pour que lenregistrement physique
dsir passe devant les ttes de lecture/criture ; ce temps est appel temps de
latence ; il est de quelques millisecondes, selon la position de lenregistrement par
rapport aux ttes et selon la vitesse de rotation des disques ;
3. du temps de lecture/criture du groupe de secteurs, appel temps de transfert ; ce
temps est gal au temps de rotation multipli par la fraction de pistes lue, par
exemple 1/16 de 10 ms pour lire un secteur sur une piste de 16 secteurs avec un
disque tournant 100 tours par seconde.
Fichiers, hachage et indexation 59
Cylindre interne
Cylindre externe
Au total, les disques ont un temps daccs variable selon la distance qui spare lenre-
gistrement auquel accder de la position des ttes de lecture/criture. La tendance
aujourdhui est de rduire cette variance avec des moteurs acclration constante
pour commander les mouvements de bras, et avec des quantits de donnes enregis-
tres par cylindre de plus en plus importantes.
De plus en plus souvent, des volumes multiples organiss en tableaux de disques
sont utiliss pour composer des units fiables et de grande capacit (des dizaines de
milliards doctets). Ces systmes de mmorisation portent le nom de RAID
(Redundant Array of Inexpensive disques). On distingue le RAID 0 sans redondance
des RAID 1 6 qui grent des redondances. Avec ces derniers, diffrentes techniques
de redondance sont utilises lors des critures et lectures afin dassurer une grande
fiabilit. Le RAID 1 groupe les disques du tableau par deux et effectuent les critures
sur les deux disques, lun apparaissant donc comme le miroir de lautre. En cas de
panne dun disque, le disque miroir peut toujours tre utilis. Les RAID 2, 3 et 4
grent un disque de parit, respectivement au niveau bit, octet ou bloc. En cas de
panne dun disque, celui-ci peut tre reconstitu grce la parit. Les RAID 5 et 6
sont bass sur des redondances plus fortes, avec des codes cycliques (CRC). Ils per-
mettent de rsister des doubles pannes. Les disques RAID permettent des perfor-
mances en lecture et criture leves car de multiples contrleurs dentres-sorties
fonctionnent en parallle.
60 BASES DE DONNES : OBJET ET RELATIONNEL
Afin de raliser cette indpendance, on introduit des objets intermdiaires entre les
programmes dapplication et la mmoire secondaire. Ces objets sont appels fichiers.
Ainsi, les programmes dapplication ne connaissent pas les mmoires secondaires,
mais les fichiers qui peuvent tre implants sur diverses mmoires secondaires. Un
fichier peut tre dfini comme suit :
Les articles sont stocks dans les rcipients dinformation que constituent les fichiers.
Ils ne sont pas stocks nimporte comment, mais sont physiquement relis entre eux
pour composer le contenu dun fichier. Les structures des liaisons constituent lorga-
nisation du fichier.
Les programmes dapplication peuvent choisir les articles dans un fichier de diff-
rentes manires, par exemple lun aprs lautre partir du premier, ou en attribuant un
nom chaque article, selon la mthode daccs choisie.
Il est utile de rappeler le cheminement dun programme en machine. Celui-ci est donc
crit laide dun langage de programmation hte et de verbes de manipulation de
fichiers. Il est pris en charge par le compilateur du langage. Ce dernier gnre du code
machine translatable incluant des appels au systme, en particulier au gestionnaire de
fichiers. Le chargeur-diteur de liens doit ensuite amener en bonne place en mmoire
les diffrents modules composants du programme ; en particulier, les translations
62 BASES DE DONNES : OBJET ET RELATIONNEL
Programme
Compilation
Code machine
translatable
Chargement
dition de liens
Code machine
excutable
Soit lexemple dun fichier dcrivant des tudiants. Les articles comportent les
champs suivants : numro dtudiant, nom, prnom, ville, date dinscription et rsul-
tats. La cl est le numro dtudiant ; cest une donne de larticle. partir de cette
cl, cest--dire dun numro dtudiant, une mthode daccs slective doit permettre
de dterminer ladresse de larticle dans le fichier et daccder larticle en principe
en moins de 5 entres/sorties disques.
Comme cela a t dj dit, il existe diffrents types dorganisations slectives (et
mthodes daccs associes). Nous allons ci-dessous tudier les principales. Elles peu-
vent tre divises en deux classes :
Les mthodes daccs par hachage utilisent des fonctions de calcul pour dterminer
ladresse dun article dans un fichier partir de sa cl ;
Les mthodes daccs par index utilisent des tables gnralement stockes sur
disques pour mmoriser lassociation cl article-adresse article.
Un bon systme de fichiers doit permettre le partage des fichiers par diffrents pro-
grammes dapplication sans que ceux-ci sen aperoivent. Le partage peut tre simul-
tan, mais aussi plus simplement rparti dans le temps. Nous tudierons plus en dtail
les problmes de partage dans le contexte des bases de donnes o ils se posent avec
plus dacuit encore.
fichiers sur les volumes et la gestion des zones de mmoires intermdiaires appeles
tampons. Les mthodes daccs sont des modules spcifiques qui constituent une
couche plus externe et qui utilisent les fonctions du noyau. La figure III.4 reprsente
les diffrents modules dun gestionnaire de fichiers typique. Notons que ces modules
sont organiss en trois couches de logiciel : les mthodes daccs, le noyau et le ges-
tionnaire dentres-sorties compos de modules plus ou moins spcifiques chaque
priphrique. Chaque couche constitue une machine abstraite qui accomplit un certain
nombre de fonctions accessibles aux couches suprieures par des primitives (par
exemple, lire ou crire un article, ouvrir ou fermer un fichier) constituant linterface
de la couche.
MTHODES
Squentiel Hach Index 1 Index 2
D'ACCS
MODULES
ME 1 ME k
DE/S
Disques magntiques
Le noyau ou analyseur dun gestionnaire de fichiers est charg dassurer la gestion des
fichiers en temps que rcipients non structurs. Il permet en gnral dtablir le lien
entre un fichier et un programme (ouverture du fichier), de supprimer ce lien (ferme-
ture), de lire ou crire une suite doctets un certain emplacement dans un fichier. Il
accde aux mmoires secondaires par lintermdiaire du gestionnaire dentres-sor-
ties. Celui-ci, qui nappartient pas proprement parler au gestionnaire de fichiers mais
bien au systme opratoire, gre les entres-sorties physiques : il permet la lecture et
lcriture de blocs physiques de donnes sur tous les priphriques, gre les particula-
rits de chacun, ainsi que les files dattente dentres-sorties.
66 BASES DE DONNES : OBJET ET RELATIONNEL
Chaque module mthode daccs est la fois charg de lorganisation des articles
dans le fichier et de la recherche des articles partir de la cl. Un bon systme de
fichiers doit offrir une grande varit de mthodes daccs. Il offrira bien sr une
mthode daccs squentielle, mais surtout plusieurs mthodes daccs slectives.
Pour raliser ladressage relatif, on divise gnralement le fichier en pages (on trouve
galement selon les implantations les termes de bloc, groupe, intervalle) : une adresse
relative octet se compose alors dun numro de page suivi dun numro doctet dans
la page. Pour viter un nombre trop important dentres-sorties, la taille de la page est
choisie de faon contenir plusieurs enregistrements physiques et des tampons dune
page sont utiliss. La taille de la page, fixe dans le systme ou lors de la cration du
Fichiers, hachage et indexation 67
fichier, est le plus souvent de lordre de quelques kilos (K) octets (par exemple, 4K).
Elle dpend parfois de lorganisation du fichier. Celle dun enregistrement physique
dpasse rarement quelques centaines doctets.
Ainsi, lanalyseur dun gestionnaire de fichiers offre gnralement la possibilit
daccder une ou plusieurs pages dadresse relative (numro de page) donne dans
un fichier. Il peut aussi permettre daccder directement aux octets, donc de lire une
suite doctets partir dune adresse relative en octets dans le fichier. Lanalyseur se
compose essentiellement dalgorithmes dallocation de mmoire secondaire et de
conversion dadresse relative page en adresse relle de lenregistrement physique
(secteur sur disque), et rciproquement. Finalement, il permet de banaliser toutes les
mmoires secondaires en offrant un accs par adresse relative uniforme, avec
quelques restrictions cependant : il est par exemple interdit daccder autrement quen
squentiel une bande magntique.
Les articles de lusager sont alors implants dans les pages par les mthodes daccs
selon lorganisation choisie. Si plusieurs articles sont implants dans une mme page,
on dit quil y a blocage. Dans le cas o les articles sont implants conscutivement
sans trou la suite les uns des autres, on dit quil y a compactage : aucune place nest
alors perdue sur la mmoire secondaire, mais des articles peuvent tre cheval sur
plusieurs pages.
Comme les fichiers vivent et sont de tailles diffrentes, les rgions successivement
alloues un fichier ne sont gnralement pas contigus sur une mmoire secondaire.
Le gestionnaire de fichiers doit alors pouvoir retrouver les rgions composant un
fichier. Pour cela, il peut soit garder la liste des rgions alloues un fichier dans une
table, soit les chaner, cest--dire mettre dans une entre dune table correspondant
chaque rgion ladresse de la rgion suivante.
La taille dune rgion peut varier partir dun seuil minimal appel granule (par
exemple une piste, etc.). Il devient alors possible dallouer des rgions de taille
variable un fichier, mais toujours composes dun nombre entier de granules cons-
68 BASES DE DONNES : OBJET ET RELATIONNEL
cutifs. Un granule est souvent choisi de taille gale une piste o une fraction de
piste.
Lorsquun fichier est dtruit ou rtrci, les rgions qui lui taient alloues et qui ne
sont plus utilises sont libres. Les granules composants sont alors librs et intro-
duits dans la liste des granules libres. Afin de maximiser la proximit des granules
allous un fichier, plusieurs mthodes dallocations ont t proposes. Nous allons
tudier ci-dessous quelques algorithmes dallocation des rgions aux fichiers.
Il est important que lensemble des descripteurs de fichiers contenu sur un volume
dfinisse tous les fichiers dun volume. On obtient ainsi des volumes autodocuments,
donc portables dune installation une autre. Pour cela, les descripteurs de fichiers
dun volume sont regroups dans une table des matires du volume appele
catalogue.
Fichiers, hachage et indexation 69
Le catalogue est soit localis en un point conventionnel du volume (par exemple, partir
du secteur 1), soit crit dans un fichier spcial de nom standard. Le descripteur de ce pre-
mier fichier peut alors tre contenu dans le label du volume. En rsum, la figure III.5
illustre lorganisation des informations tudies jusqu prsent sur un volume.
VOLUME n
Label Catalogue
F1 F3
F2 F4
Racine
hirarchie
table de bits dans laquelle chaque bit correspond un granule; lallocation dun gra-
nule consiste alors trouver un bit 0, le positionner 1 et adjoindre ladresse du
granule allou au descripteur du fichier.
En rsum, les stratgies par rgion de tailles variables sont en gnral plus efficaces
du point de vue dplacement de bras et taille de la table des rgions dun fichier. Un
problme commun ces stratgies peut cependant survenir aprs des dcoupages trop
nombreux sil nexiste plus de rgions de taille suprieure un granule. Dans ce cas,
lespace disque doit tre rorganis (ramassage des miettes). Ce dernier point fait que
les stratgies par granule restent les plus utilises.
lintrieur dun paquet, les articles sont rangs la suite dans lordre darrive. Ils
sont retrouvs grce la donne contenant la cl. La figure III.7 illustre un exemple
de structure interne dun paquet. En tte du paquet, on trouve ladresse du premier
octet libre dans le paquet. Ensuite, les articles successifs du paquet sont rangs avec
leur longueur en tte, par exemple sur deux octets. lintrieur dun tel paquet, on
accde un article par balayage squentiel. Des structures de paquet plus sophisti-
ques permettent laccs direct un article de cl donne lintrieur dun paquet. De
telles structures sont plus efficaces que la structure simple reprsente figure III.7.
74 BASES DE DONNES : OBJET ET RELATIONNEL
Article a1
a1
de longueur lga1
Iga2
Article a2 L Octets
de longueur lga2 a2
Iga3
Article a3
de longueur lga3 a3
Index optionnel
Lorsquun nouvel article est insr dans un fichier, il est log la premire place libre
dans le paquet. Sil ny a pas de place libre, on dit quil y a dbordement. Il faut vi-
demment contrler lunicit de la cl dun article lors des insertions. Cela ncessite de
balayer tous les articles du paquet.
partir de la cl dun article, on calcule le numro de paquet dans lequel larticle est
plac laide dune fonction appele fonction de hachage (Fig. III.8). Une fonction
de hachage doit tre choisie de faon distribuer uniformment les articles dans les
paquets. Plusieurs techniques sont possibles :
le pliage, qui consiste choisir et combiner des bits de la cl (par exemple par ou
exclusif ) ;
les conversions de la cl en nombre entier ou flottant avec utilisation de la mantisse
permettants dobtenir galement un numro de paquet ;
le modulo, sans doute la fonction la plus utilise, qui consiste prendre pour
numro de paquet le reste de la division de la cl par le nombre de paquets.
Ces techniques peuvent avantageusement tre combines.
Soit un fichier de 47 paquets et des articles de cl numrique. Le modulo 47 pourra
alors tre choisi comme fonction de hachage. Ainsi, larticle de cl 100 sera plac
Fichiers, hachage et indexation 75
Fonction
Cl de
hachage
Nombre de 0 N-1
Le problme de dbordement se pose lorsquun paquet est plein. Une premire solu-
tion simple consiste ne pas grer de dbordements et rpondre fichier satur
lutilisateur. Cela implique une mauvaise utilisation de la place occupe par le fichier,
surtout si la distribution des articles dans les paquets est mauvaise. Des solutions plus
satisfaisantes consistent utiliser une technique de dbordement parmi lune des sui-
vantes [Knuth73] :
ladressage ouvert consiste placer larticle qui devrait aller dans un paquet plein
dans le premier paquet suivant ayant de la place libre ; il faut alors mmoriser tous
les paquets dans lequel un paquet plein a dbord ;
le chanage consiste constituer un paquet logique par chanage dun paquet de
dbordement un paquet plein ;
le rehachage consiste appliquer une deuxime fonction de hachage lorsquun
paquet est plein; cette deuxime fonction conduit gnralement placer les articles
dans des paquets de dbordements.
Dans tous les cas, la gestion de dbordements dgrade les performances et complique
la gestion des fichiers hachs.
La mthode daccs base sur lorganisation hache statique a plusieurs avantages. En
particulier, elle sadapte des fichiers de cls quelconques, reste simple et donne
dexcellentes performances tant quil ny a pas de dbordements : une lecture darticle
seffectue en une entre-sortie (lecture du paquet) alors quune criture en ncessite
en gnral deux (lecture puis rcriture du paquet). Cependant, les dbordements
dgradent rapidement les performances. De plus, le taux doccupation de la mmoire
secondaire rellement utilise peut rester assez loign de 1. Enfin, la taille dun
fichier doit tre fixe a priori. Si le nombre darticles dun fichier devient plus impor-
tant que prvu, le fichier doit tre rorganis.
76 BASES DE DONNES : OBJET ET RELATIONNEL
Cette organisation est illustre figure III.9. Nous montrons ici un rpertoire adress
par 3 bits de la fonction de hachage. Le fichier avait t cr avec deux paquets et
tait adress par le premier bit de la fonction de hachage (celui de droite). Puis le
paquet 1 a clat et a t distribu entre le paquet 01 et 11. Le paquet 11 a clat son
tour et a t distribu entre le paquet 011 et le paquet 111. Le rpertoire a donc t
doubl deux fois (P = 2 alors que M = 1).
78 BASES DE DONNES : OBJET ET RELATIONNEL
H (KEY)
XXXX X X X
000
001
010
011
100
101
110
111
Un fichier hach extensible est donc structur en deux niveaux : le rpertoire et les
paquets. Soit P le niveau dclatement maximal du fichier. Le rpertoire contient un en-
tte qui indique la valeur de M+P, le nombre de bits de la fonction de hachage utiliss
pour le paquet ayant le plus clat. Aprs len-tte figurent des pointeurs vers les paquets.
Les M+P premiers bits de la fonction de hachage sont donc utiliss pour adresser le rper-
toire. Le premier pointeur correspond la valeur 0 des (M+P) premiers bits de la fonction
de hachage, alors que le dernier correspond la valeur 2**(M+P) 1, cest--dire aux
(M+P) premiers bits 1. Soit Q le nombre dclatements subis par un paquet. chaque
paquet sont associs dans le rpertoire 2**(P-Q) pointeurs qui indiquent son adresse. Le
rpertoire pointe ainsi plusieurs fois sur le mme paquet, ce qui accrot sa taille.
Linsertion dun article dans un fichier hach extensible ncessite tout dabord laccs
au rpertoire. Pour cela, les (M+P) bits de la cl sont utiliss. Ladresse du paquet
dans lequel larticle doit tre plac est ainsi lue dans lentre adresse du rpertoire. Si
le paquet est plein, alors celui-ci doit tre doubl et son niveau dclatement Q aug-
ment de 1 ; un paquet frre au mme niveau dclatement doit tre cr ; les articles
sont rpartis dans les deux paquets selon la valeur du bit (M+Q+1) de la fonction de
hachage. Le mcanisme dclatement de paquet est illustr figure III.10. Si le niveau
du rpertoire P est suprieur Q, alors le rpertoire doit simplement tre mis jour,
2**(P-Q+1) pointeurs tant forcs sur ladresse du nouveau paquet. Si P est gal Q,
alors le rpertoire doit tre doubl.
En cas de suppression dans un paquet adress par M+Q bits de la fonction de hachage,
il est possible de tenter de regrouper ce paquet avec lautre paquet adress par M+Q
bits sil existe. Ainsi, la suppression dun article dans un paquet peut thoriquement
conduire rorganiser le rpertoire. En effet, si le paquet concern est le seul paquet
avec son frre au niveau dclatement le plus bas et si la suppression dun article
laisse assez de place libre pour fusionner les deux frres, la fusion peut tre entreprise.
Fichiers, hachage et indexation 79
Le niveau dclatement du rpertoire doit alors tre rduit de 1 et celui-ci doit tre
divis par deux en fusionnant les blocs jumeaux.
000 a
001 b
010 c1
011 d
100 a
101 b
110 c2
111 d
La figure III.11 illustre un fichier hach linairement. Le pointeur courant est situ en
dbut du 3e paquet (paquet 10). Les paquets 000 et 001, 100 et 101 (cest--dire 0, 1,
4 et 5) sont adresss par les trois premiers bits de la fonction de hachage, alors que les
paquets 10 et 11 (cest--dire 2 et 3) sont seulement adresss par les deux premiers
bits. Lors du prochain dbordement, le paquet 10 (2) clatera, quel que soit le paquet
qui dborde.
H (KEY) XXXXX XX
3 bits 2 bits
dbordement
Notons que le hachage linaire peut aussi simplmenter avec un rpertoire. Dans ce
cas, le pointeur courant est un pointeur sur le rpertoire : il rfrence ladresse du
paquet suivant clater. Lavantage du hachage linaire est alors la simplicit de
lalgorithme dadressage du rpertoire ; on utilise tout dabord M+P bits de la fonc-
tion de hachage ; si lon est positionn avant le pointeur courant, on utilise un bit de
plus, sinon on lit ladresse du paquet dans le rpertoire. chaque clatement, le rper-
toire saccrot dune seule entre. Linconvnient est bien sr la ncessit de grer des
dbordements.
Linsertion dun article dans un fichier hach linairement se fait trs simplement : si
P est le niveau dclatement du fichier, (M+P) bits de la cl sont tout dabord pris en
compte pour dterminer le numro de paquet. Si le numro obtenu est suprieur au
pointeur courant, il est correct ; sinon, un bit supplmentaire de la fonction de hachage
est utilis pour dterminer le numro de paquet. Linsertion seffectue ensuite de
manire classique, ceci prs que lorsquun paquet est satur, le paquet point par le
pointeur courant est clat ; ce pointeur courant est augment de 1 ; sil atteint le
paquet 2**(M+P) du fichier, il est ramen au dbut et le niveau dclatement du
fichier est augment de un.
Fichiers, hachage et indexation 81
La figure III.12 illustre cette notion dindex. Le fichier contient les articles a5, a2,
a57, a3 et a10. Lindex est rang en fin de fichier comme le dernier article du fichier.
Il contient une entre par article indiquant la cl de larticle et son adresse relative
dans le fichier. Lindex dun fichier peut en gnral tre rang dans le fichier ou plus
rarement dans un fichier spcial.
Index
{0 2 4 6 8 10 12 14 16 18 20 22 24
Adresses relatives
Les tapes successives excutes pour laccs un article dans un fichier index sont
les suivantes :
1. Accs lindex qui est mont en mmoire dans un tampon.
2. Recherche de la cl de larticle dsir en mmoire afin dobtenir ladresse relative
de larticle ou dun paquet contenant larticle.
3. Conversion de ladresse relative trouve en adresse absolue par les couches internes
du systme de gestion de fichiers.
4. Accs larticle (ou au paquet darticles) sur disques magntiques et transfert dans
un tampon du systme.
5. Transfert de larticle dans la zone du programme usager.
En gnral, laccs un article dans un fichier index ncessite une trois entres-
sorties pour monter lindex en mmoire, puis une entre sortie pour monter larticle en
mmoire. Diffrentes variantes sont possibles, selon lorganisation des articles dans le
fichier et de lindex.
La densit dun index varie entre 0 et 1. Un index dense a donc une densit gale 1.
Dans le cas dindex non dense, toutes les cls ne figurent pas dans lindex. Aussi, les
articles du fichier ainsi que lindex sont tris. Le fichier est divis en paquets de taille
fixe et chaque paquet correspond une entre en index contenant le doublet : <plus
grande cl du paquet-adresse relative du paquet>. La figure III.13 illustre un index
non dense et le fichier correspondant. Le paquet 1 contient les articles de cl 1, 3 et 7.
La plus grande cl (7) figure dans lindex non dense, etc. Lindex est compos ici dun
seul bloc contenant trois cls, la plus grande de chaque paquet.
1-3-7 9 - 11 - 23 25 - 30 - 31
7-
23 -
31 -
Comme le fichier peut tre tri ou non tri, et lindex dense ou non dense, tri ou non
tri, diverses variantes sont thoriquement possibles. Deux mthodes sont particuli-
rement intressantes : le fichier squentiel non tri avec index tri dense, historique-
ment la base de lorganisation IS3, et le fichier tri avec index non dense tri, sur
84 BASES DE DONNES : OBJET ET RELATIONNEL
lequel sont fondes des organisations telles ISAM, VSAM et UFAS. Il est impossible
dassocier un index non dense un fichier non tri.
Un index hirarchis un niveau est un index tri, gnralement non dense, compos
de paquets de cls. Un index hirarchis n niveaux est un index hiarchis n 1
niveaux, possdant lui-mme un index un niveau. La figure III.14 illustre un index
hirarchis 3 niveaux. Le niveau 1 comporte trois paquets de cls. Le niveau 2 en
comporte deux qui contiennent les plus grandes cls des paquets de niveau infrieur.
Le niveau 3 est la racine et contient les plus grandes cls des deux paquets de niveau
infrieur. La notion dindex hirarchis est indpendante du nombre de niveaux, qui
peut grandir autant que ncessaire.
21 30
Niveau 3
12 21 30
Niveau 2
2 5 12 14 18 21 23 25 30
Niveau 1
5.1.4. Arbres B
Afin de mieux caractriser la notion dindex hirarchis et de la rendre indpendante
des particularits dimplantation, on a t amen introduire une structure darbre,
Fichiers, hachage et indexation 85
La figure III.15 reprsente un arbre balanc dordre 2. La racine a deux fils. Les deux
autres nuds non feuilles ont trois fils.
i r
c f l o u x
Un arbre B peut tre utilis pour constituer un index hirarchis dun fichier. Dans ce
cas, les nuds reprsentent des pages de lindex. Ils contiennent des cls tries par
ordre croissant et des pointeurs de deux types : les pointeurs internes dsignent des
fils et permettent de dfinir les branches de larbre, alors que les pointeurs externes
dsignent des pages de donnes (en gnral, des adresses relatives darticles). La
figure III.16 prcise la structure dun nud. Une cl xi dun nud interne sert de
sparateur entre les deux branches internes adjacentes (Pi-1 et Pi). Un nud contient
entre m et 2m cls, lexception de la racine qui contient entre 1 et 2m cls.
86 BASES DE DONNES : OBJET ET RELATIONNEL
P0 x1 a1 P1 x2 a2 P2 ... xi ai Pi ... xk ak Pk
Pi : Pointeur interne permettant de reprsenter l'arbre; les feuilles ne contiennent pas de pointeurs Pi ;
ai : Pointeur externe sur une page de donnes ;
xi : valeur de cl.
De plus, lensemble des cls figurant dans larbre B doit tre tri selon lordre post-
fix induit par larbre, cela afin de permettre les recherches en un nombre daccs gal
au nombre de niveaux. Plus prcisment, en dsignant par K(Pi) lensemble des cls
figurant dans le sous-arbre dont la racine est pointe, on doit vrifier que :
1. (x1, x2xK) est une suite croissante de cls ;
2. Toute cl y de K(P0) est infrieure x1 ;
3. Toute cl y de K(P1) est comprise entre xi et xi+1 ;
4. Toute cl y de K(PK) est suprieure xk.
La figure III.17 reprsente un exemple dindex sous forme darbre B dordre 2. Cet
arbre contient les valeurs de cl de 1 26. Les flches entre les nuds reprsentent les
pointeurs internes, les traits courts issus dune cl les pointeurs externes vers les
articles. Dans la suite, nous omettrons les pointeurs externes, qui seront donc impli-
cites.
11
5 8 16 21
1 2 3 4 6 7 9 10 12 13 14 15 17 18 19 20 22 23 24 26
(a)
11
16 21
12 13 14 15 17 18 19 20 22 23 24 25 26
(b)
11
16 21 24
12 13 14 15 17 18 19 20 22 23 25 26
La suppression dune cl soulve galement des problmes. Tout dabord, si lon sup-
prime une cl non terminale, il faut remonter la cl suivante pour garder le partition-
nement. De plus, si un nud a moins de m cls, il faut le regrouper avec le prcdent
de mme niveau afin de respecter la dfinition et de conserver entre m et 2m cls dans
un nud non racine.
Une variante de larbre B tel que nous lavons dcrit pour raliser des index est
larbre B* [Knuth73, Comer79], dans lequel lalgorithme dinsertion essaie de redis-
tribuer les cls dans un nud voisin avant dclater. Ainsi, lclatement ne se produit
que quand deux nuds conscutifs sont pleins. Les deux nuds clatent alors en trois.
Les pages des index de type arbre B* sont donc en gnral mieux remplies que celles
des index de type arbre B.
5.1.5. Arbre B+
Lutilisation des arbres B pour raliser des fichiers indexs tels que dcrits ci-dessus
conduit des traitements squentiels coteux. En effet, laccs selon lordre croissant des
cls lindex ncessite de nombreux passages des pages externes aux pages internes.
Pour viter cet inconvnient, il a t propos de rpter les cls figurant dans les nuds
internes au niveau des nuds externes. De plus, les pages correspondant aux feuilles sont
chanes entre elles. On obtient alors un arbre B+. Larbre B+ correspondant larbre B
de la figure III.17 est reprsent figure III.19. Les cls 11, 8 et 21 sont rptes aux
niveaux infrieurs. Les pointeurs externes se trouvent seulement au niveau des feuilles.
Fichiers, hachage et indexation 89
11 26
5 8 11 16 21 26
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 20 21 22 23 24 26
Les arbres B+ peuvent tre utiliss pour raliser des fichiers index hirarchiss de
deux manires au moins :
Larbre B+ peut tre utilis pour implmenter seulement les index. Autrement dit,
les articles sont stocks dans un fichier squentiel classique et larbre B+ contient
toutes les cls ainsi que les adresses darticles. Une telle organisation est proche de
celle propose par IBM sur les AS 400. Pour des raisons historiques, cette mthode
sappelle IS3.
Larbre B+ peut tre utilis pour implmenter fichiers et index. Dans ce cas, les
pointeurs externes sont remplacs par le contenu des articles. Les articles sont donc
tris. Seules les cls sont dplaces aux niveaux suprieurs qui constituent un index
non dense. Cette mthode correspond lorganisation squentielle indexe rgulire
dIBM sur MVS connue sous le nom de VSAM, et galement celle de BULL sur
DPS7, connue sous le nom de UFAS.
12
15
Index
(B) tat aprs insertion de (7)
1 1 12 5 15 7
7 5
7
15
12
La cl 15 est reporte
pour permettre une 15
meilleure optimisation.
Un dernier problme est celui du stockage de lindex. Celui-ci peut tre stock en fin
de fichier. Il est ainsi possible de lire la page suprieure de lindex en mmoire cen-
trale lors du dbut dun travail sur un fichier, puis de la rcrire en fin de travail. Il est
aussi possible, avec une telle mthode denregistrement des index, de garder les ver-
Fichiers, hachage et indexation 91
sions historiques des index condition que les nouveaux articles crits le soient aprs
le dernier index enregistr, cest--dire en fin de fichier.
La mthode daccs et lorganisation associe IS3 prsentent plusieurs avantages : linser-
tion des articles est simple puisquelle seffectue en squentiel dans le fichier ; il est pos-
sible de garder des versions historiques des index. Les performances de la mthode sont
satisfaisantes. Si m est le nombre de cls par page dindex, du fait de lorganisation de
lindex en arbre B+, le nombre dentres-sorties ncessaires pour lire un article dans un
fichier de N articles reste infrieur ou gal 2 + log(m/2) ((N+1)/2). Une criture ncessite
en gnral deux accs, sauf dans les cas dclatement de page index o il faut une lecture
et deux critures de plus par niveau clat. En pratique, et titre dexemple, un fichier de
moins de 106 articles ne ncessitera pas plus de trois entres-sorties en lecture.
Cette mthode prsente cependant trois inconvnients srieux :
Du fait de la sparation des articles et de lindex, les mouvements de bras des
disques sont en gnral importants.
La lecture en squentiel par cl croissante doit se faire par consultation de lindex et
est en consquence trs coteuse.
Lindex est dense et donc de grande taille si aucune technique de compactage de
cls nest mise en uvre.
} Pistes dindex
1 3 5 7 21 23 27
} Pistes
9 14 17 29 31
de dbordement
Cylindre 0 Cylindre 1
Figure III.21 : Fichier ISAM aprs une premire criture des articles 1, 3, 5, 7, 9, 14, 17, 21, 23,
27, 29, 31 (dans lordre)
{
Zone de dbordement Zone de dbordement
de cylindre indpendante
En zone de dbordement, les articles ne sont pas bloqus. Ils sont chans entre eux
afin de reconstituer la piste qui a dbord de manire logique. Quand un article est
insr, on recherche sa squence dans la piste logique. Sil est plac en zone primaire,
les articles suivants sont dplacs et le dernier est crit en zone de dbordement. Les
Fichiers, hachage et indexation 93
chanages sont mis jour. Sil vient en zone de dbordement, il est crit dans cette
zone et est insr en bonne place dans la chane des articles en dbordement.
La zone de dbordement de cylindre est tout dabord utilise. Lorsquelle est sature,
la zone de dbordement indpendante est utilise. Dans ce cas, comme le chanage est
effectu par ordre croissant des cls, il est possible quil parte de la zone de dborde-
ment de cylindre, pointe en zone de dbordement indpendante, puis revienne en zone
de dbordement de cylindre, etc. Alors, la mthode devient particulirement peu per-
formante pour rechercher un article dans une piste ayant dbord, du fait des dplace-
ments de bras.
en index matre par piste de lindex de cylindre. Cette entre contient ladresse de la
piste et la valeur de la plus grande cl dans la piste.
Index cylindres et
Zone de dbordement
indpendante
a0 a1 a2 a10 a11 a9
Zones
primaires a5 a6 a7 a14 a15
Zones de
a3 a4 a8 a12 a13
dbordement
Les avantages de la mthode sont que le fichier est tri, ce qui facilite laccs en
squentiel tri, ainsi que les temps daccs tant que le fichier na pas dbord (3 E/S
pour lire un article). Les inconvnients sont essentiellement lis aux dbordements. La
gestion des dbordements est complexe et dgrade les performances, de sorte quil est
ncessaire de rorganiser priodiquement les fichiers ayant dbord. Le fait que la
mthode daccs ne soit pas indpendante des caractristiques physiques du support
(pistes, cylindres) amliore les performances, mais rend le changement de support
difficile. En fait, les performances dpendent des dbordements. Si une piste com-
Fichiers, hachage et indexation 95
Afin dassurer lindpendance des fichiers aux supports physiques, des divisions
logiques sont introduites. Le fichier est divis en aires, une aire tant un ensemble de
pistes du mme cylindre ou de cylindres contigus. Chaque aire est elle-mme divise
en intervalles, un intervalle tant gnralement compos dune partie de piste ou de
plusieurs pistes conscutives lue(s) en une seule entre-sortie. Lintervalle correspond
la feuille de larbre B+. Lorsquun intervalle est satur, il clate en deux intervalles ;
lorsquune aire est sature, elle clate aussi en deux aires, si bien que le fichier se
rorganise de lui-mme par incrments.
Cette organisation rsulte dune tude critique de ISAM. Cette fois, le fichier est plus ind-
pendant de la mmoire secondaire : la piste est remplace par lintervalle qui peut tre une
fraction de piste ou plusieurs pistes, le cylindre est remplac par la notion daire. Les
dbordements ne perturbent plus lorganisation puisque le mcanisme de dbordement est
celui de larbre B+, cest--dire quun intervalle ou une aire saturs clatent en deux.
vues: de la place libre est laisse dans chaque intervalle et des intervalles libres sont lais-
ss dans chaque aire afin de permettre les insertions de nouveaux articles.
titre dexemple, le fichier de la figure III.25 a t cr avec les paramtres suivants :
pourcentage doctets libres par intervalle = 25 ;
pourcentage dintervalles libres par aire = 25.
Lors de la premire criture, le programme crant le fichier a dlivr au systme les
articles suivants (dans lordre) : 1, 5, 7, 9, 15, 20, 22, 27, 30, 31, 33, 37, 40, 43, 47, 51, 53.
1 5 9 15 31 33 40 43
7 20 37 47
22 27 51 53
30
Lalgorithme dinsertion dun article consiste dterminer, grce aux index, linter-
valle qui doit contenir larticle. Ensuite, deux cas sont possibles :
a) Si lintervalle nest pas plein, alors larticle est rang dans lintervalle, en bonne
place dans lordre lexicographique des cls. Par exemple, linsertion de larticle de
cl 10 conduira la substitution dintervalle reprsente figure III.26.
9 15 9 10
Insertion de 10
20 15 20
b)Si lintervalle est plein, alors il clate en deux intervalles demi pleins. Deux sous-
cas sont encore possibles :
b1) Sil existe un intervalle libre dans laire, celui-ci est utilis afin de stocker lun
des deux intervalles rsultant de lclatement. Par exemple, linsertion de
Fichiers, hachage et indexation 97
1 5 9 10 31 33 40 43
7 13 37 47
22 27 15 20 51 53
30
1 5 9 10 31 33 40 43 15 20 22 27
7 11 37 47 30
12 13 51 53
valle correspondant ainsi que son adresse. Le deuxime niveau est appel index
daires. Il en existe un par fichier. Chaque entre contient la plus grande cl de laire
correspondante ainsi que ladresse de laire. Il est galement possible, dans le cas o
lindex daire est trop grand (par exemple plus dune piste), de faire grer au systme
un index de troisime niveau appel index matre et permettant daccder directe-
ment la partie pertinente de lindex daire. titre dillustration, la figure III.29
reprsente les index dintervalles et daires du fichier reprsent figure III.28. Chaque
entre reprsente une cl suivie dune adresse dintervalle ou daire.
20.0 30.1 _
Index dintervalles
aire 2
Index d'aires
Cependant lcriture peut parfois tre trs longue dans le cas dclatement dinter-
valles ou, pire, dans le cas dclatement daires. En fait, les critures ne seffectuent
pas en un temps constant : certaines sont trs rapides (4 E/S lorsquil ny a pas dcla-
tement), dautres sont trs longues (lorsquil y a clatement daire).
17.0 32.1
1 2 5 7 19 21 22 27
3 9
14 17 30 32
Par exemple, un index secondaire dun fichier dcrivant des vins pourra porter sur le
champ cru. Les entres correspondront aux diffrents crus (Chablis, Medoc, Volnay,
etc.) et donneront pour chaque cru la liste des adresses darticles correspondant ce
cru. Ainsi, en accdant lentre Volnay, on trouvera la liste des Volnay.
Un index secondaire est souvent organis comme un arbre B, bien que dautres orga-
nisations soient possibles. En particulier, un index secondaire peut tre un fichier
part, servant dindex au fichier principal. On parle alors de fichier inverse, le fichier
contenant lindex apparaissant comme une structure de donnes en quelque sorte ren-
verse par rapport au fichier principal. Un fichier avec un index secondaire (ou un
fichier inverse) est en gnral index ou hach sur une cl discriminante (par exemple,
le numro de vin). On parle alors de cl primaire. Par opposition, le champ sur lequel
lindex secondaire est construit (par exemple, le cru) est appel cl secondaire. Un
fichier peut bien sr avoir plusieurs cls secondaires, par exemple cru et rgion pour
le fichier des vins.
La question qui se pose alors concerne la recherche dun article dans le fichier. Si plu-
sieurs cls secondaires sont spcifies (par exemple, cru = Volnay et
rgion= Bourgogne), on peut avoir intrt choisir un index (ici le cru), puis lire
les articles correspondant en vrifiant les autres critres (ici, que la rgion est bien
Bourgogne). Dans certains cas o aucune donne nest a priori plus discriminante
quune autre, on aura au contraire intrt lire les diffrentes entres dindex slec-
tionnes, puis faire lintersection des listes dadresses darticles rpondant aux diff-
rents critres. Finalement, un accs aux articles rpondant tous les critres (ceux
dont ladresse figure dans lintersection) sera suffisant.
Un autre problme pos par la gestion dindex secondaires est celui de la mise jour.
Lors dune mise jour dun article du fichier principal, il faut mettre jour les index
secondaires. Bien sr, si la valeur dindexation est change, il faut enlever larticle de
lentre correspondant lancienne valeur, puis linsrer dans lentre correspondant
la nouvelle valeur. Cette dernire doit tre cre si elle nexiste pas. Plus coteux,
avec les mthodes daccs utilisant lclatement de paquets, il faut aller modifier dans
les index secondaires les adresses des articles dplacs lors des dplacements
darticles. On peut avoir alors intrt garder des rfrences invariantes aux dplace-
ments darticles dans les index secondaires. Une solution consiste garder les cls
primaires la place des adresses, mais cela cote en gnral un accs via un arbre B.
En rsum, bien que prsentant quelques difficults de gestion, les index secondaires
sont trs utiles pour acclrer les recherches darticles partir de valeurs de donnes.
Ils sont largement utiliss dans les SGBD. Sils permettent bien damliorer les temps
Fichiers, hachage et indexation 101
de rponse lors des interrogations, ils pnalisent les mises jour. Il faut donc indexer
les fichiers seulement sur les donnes souvent documentes lors de linterrogation.
grille, ou grid file en anglais [Nievergelt84]. La mthode peut tre vue comme une
extension du hachage extensible. Une fonction de hachage est associe chaque attri-
but de placement. Ladresse de hachage multidimensionnelle est constitue dun
nombre suffisant de bits choisi en prlevant des bits de chacune des fonctions de
hachage de manire circulaire. Cette adresse sert de pointeur dans le rpertoire des
adresses de paquets. Tout se passe donc comme avec le hachage extensible, mais avec
une fonction de hachage multi-attribut mixant les bits des diffrentes fonctions com-
posantes.
Afin de clarifier la mthode, une reprsentation par une grille multidimensionnelle du
fichier est intressante. Pour simplifier, supposons quil existe seulement deux attri-
buts de placement A1 et A2. Au dpart, le fichier est compos dun seul paquet qui
dlimite la grille (voir figure III.31.a). Quand le fichier grossit au fur et mesure des
insertions, le paquet sature. Il est alors clat en deux paquets B0 et B1 selon la
dimension A1 (voir figure III.31.b). Pour ce faire, le premier bit de la fonction de
hachage applique A1 (h1(A1)) est utilis. Quand lun des paquets, disons B0, est
plein, il est son tour clat en deux paquets B00 et B01, cette fois selon lautre
dimension. Le premier bit de la fonction de hachage applique A2 (h2(A2)) est uti-
lis. Si lun des paquets B00 ou B01 devient plein, il sera son tour clat, mais cette
fois selon la dimension A1. Le processus dclatement continue ainsi alternativement
selon lune ou lautre des dimensions.
Pour retrouver un article dans un paquet partir de valeurs dattributs, il faut appli-
quer les fonctions de hachage et retrouver ladresse du ou des paquets correspondants
dans le rpertoire des paquets. Pour cela, la mthode propose un rpertoire organis
comme un tableau multidimensionnel. Chaque entre dans le rpertoire correspond
une rgion du fichier grille. Le rpertoire est stock continment sur des pages
disques, mais est logiquement organis comme un tableau multidimensionnel. Par
exemple, avec un placement bidimensionnel, ladresse dun paquet pour la rgion (i,j)
sera dtermin par une transformation dun tableau bidimensionnel un rpertoire
linaire : lentre 2**N*i + j sera accde, N tant le nombre maximal dclatement
dans la dimension A1. Ainsi, lors dun clatement un niveau de profondeur suppl-
mentaire dune dimension, il faut doubler le rpertoire selon cette dimension. Cela
peut seffectuer par recopie ou chanage. En rsum, on aboutit une gestion de
rpertoire complexe avec un rpertoire qui grossit exponentiellement en fonction de la
taille des donnes.
Pour amliorer la gestion du rpertoire et obtenir une croissance linaire avec la taille
des donnes, plusieurs approches on t proposes. Une des plus efficaces est utilise
par les arbres de prdicats [Gardarin83]. Avec cette mthode, lensemble des fonctions
de hachage est ordonn selon les frquences dcroissantes daccs (les attributs les plus
souvent documents lors des interrogations dabord). Pour simplifier, supposons que
lordre soit de A0 An. Un arbre de placement permet dillustrer les clatement de
paquets (voir figure III.32). Au premier niveau, les paquets clatent progressivement
Fichiers, hachage et indexation 103
selon les bits de la fonction de hachage h(A1). Quand tous les bits sont exploits, on uti-
lise la fonction h2(A2), etc. Ainsi, chaque paquet est une feuille de larbre de placement
caractrise par une chane de bits plus ou moins longue correspondant aux clatements
successifs. Cette chane de bits est appele signature du paquet.
A2
(a)
Paquet B
A1
A2 clatement 1
(b)
B0 B1
A1
A2 clatement 2
(c) B01
B00
A1
A2
clatement 3
A1
Rpertoire
Signatures Adresses paquets
0 1
00 a
10 b
1 1
0 0 01 c
a b c 011 d
0 1
111 e
d e
Figure III.32 : Arbre de placement et rpertoire associ
alphanumrique des valeurs. Cest alors une bijection. La figure III.33 donne un
exemple dindex bitmap pour un fichier de sportifs sur lattribut sport.
Index cot
0-100 100-200 200-300
Fichier de donnes
0 1 0
Mnagre Produits Cot 1 0 0
0 1 0
1 {P1, P3, P5} 120 0 1 0
2 {P2, P3} 70 0 0 1
3 {P4} 150
4 {P2, P5} 110
5 {P3,P4,P6} 220
Index produits
P1 P2 P3 P4 P5 P6
1 0 1 0 1 0
0 1 1 0 0 0
0 0 0 1 0 0
0 1 0 0 1 0
0 0 1 1 0 1
7. CONCLUSION
Nous venons de passer en revue les fonctions essentielles et les techniques de base des
gestionnaires de fichiers. Dautres tudes peuvent tre trouves, par exemple dans
[Korth91] et [Widerhold83]. Il faut savoir quun gestionnaire de fichiers est de plus en
plus souvent la base dun systme de gestion de bases de donnes. Pour ce faire, des
niveaux de logiciels suprieurs sont gnralement implants pour assurer loptimisa-
tion des recherches, la description centralise des donnes des articles de fichiers, des
interfaces de gestion de donnes varies avec les programmes dapplication, etc.
La ncessit de pouvoir supporter un Systme de Gestion de Bases de Donnes
(SGBD) tend aujourdhui rendre le gestionnaire de fichiers de plus en plus labor.
Fichiers, hachage et indexation 107
Il est par exemple possible de trouver des systmes grant plusieurs index secondaires
pour un mme fichier plac selon un hachage extensible ventuellement multi-attri-
but. En effet, pour permettre la consultation des donnes selon des critres varis, les
SGBD ncessitent gnralement plusieurs chemins daccs un mme article. Nous
reviendrons sur les problmes de mthodes daccs et dorganisation de fichiers pour
les systmes de gestion de bases de donnes dans le chapitre spcifique aux modles
daccs, puis plus tard pour les donnes multimdias.
8. BIBLIOGRAPHIE
[Bayer72] Bayer R., McCreight C., Organization and Maintenance of Large Ordered
Index , Acta Informatica, vol. 1, n 3, 1972, p. 173-189.
Un des premiers articles introduisant lorganisation des index par arbres B et
dmontrant les avantages de cette organisation pour de gros fichiers.
[Chan98] Chan C-Y., Ioannidis Y.E., Bitmap index Design and evaluation , ACM
SIGMOD Intl. Conf., SIGMOD Record V 27, n 2, Seattle, USA, 1998.
Cet article tudie la conception dindex bitmap pour traiter des requtes com-
plexes sur de grandes bases de donnes. En particulier, les techniques de map-
ping des valeurs dattributs sur les indices de colonnes sont prises en compte et
diffrents critres doptimalit des choix sont tudis.
[Comer79] Comer D., The Ubiquitous B-Tree , Computing Surveys, vol. 11, n 2,
juin 1979.
Une revue trs complte des organisations bases sur les arbres B. Diffrentes
variantes, dont les arbres B+, sont analyses.
[Daley65] Daley R.C., Neuman P.G., A General Pupose File System for Secondary
Storage , Fall Joint Computer Conference, 1965, p. 213-229.
Une prsentation de la premire version du systme de fichiers de MULTICS.
Ce systme introduit pour la premire fois une organisation hirarchique des
catalogues de fichiers. Lintrt de noms hirarchiques et bass pour dsigner
un fichier est dmontr. Le partage des fichiers par liens est introduit.
[Fagin79] Fagin R., Nivergelt J., Pippengar N., Strong H.R., Extendible Hahing A
Fast Access Method for Dynamic Files , ACM TODS, vol. 4, n 3, septembre
1979, p. 315-344.
Larticle de base sur le hachage extensible. Il propose dutiliser un rpertoire
dadresses de paquets adress par exploitation progressive des bits du rsultat
de la fonction de hachage. Les algorithmes de recherche et de mise jour sont
dtaills. Une valuation dmontre les avantages de la mthode aussi bien en
temps daccs quen taux de remplissage.
108 BASES DE DONNES : OBJET ET RELATIONNEL
[Freeston87] Freeston M., The BANG file A New Kind of Grid File , ACM SIG-
MOD, mai 1987, San Fransisco, ACM Ed., p. 260-269.
Cet article prsente une variante du fichier grille, avec laquelle le rpertoire
reste linaire en fonction de la taille des donnes. La technique est voisine de
celle des signatures dveloppes dans les arbres de prdicats, mais les attributs
ne sont pas ordonns et le rpertoire des signatures dispose dune organisation
particulire. Le BANG file a t implment lECRC le centre de recherche
commun BULL, ICL, SIEMENS Munich et a servi de base au systme de
bases de donnes dductives EKS.
[Gardarin83] Gardarin G., Valduriez P., Vimont Y., Predicate Tree An Integrated
Approach to Multi-Dimensional Searching , Rapport de recherche INRIA,
n 203, avril 1983.
Cet article prsente la mthode daccs multi-attributs des arbres de prdicats.
Cette mthode part dune spcification dune suite de collections de prdicats
disjoints, chaque collection portant sur un attribut. La suite de collection per-
met daffecter une signature chaque tuple constitue par la concatnation des
numros de prdicats satisfaits. La signature est exploite progressivement bit
bit pour placer les donnes sur disques. L ide cl est de permettre un accs
multicritres selon une hirarchie de prdicats. Cette mthode a t mise en
uvre dans le SGBD SABRINA.
[IBM78] IBM Corporation, Introduction to IBM Direct Access Storage Devices and
Organization Methods , Student text, Manual Form GC20-1649-10.
Une description des supports de stockage et des mthodes daccs supportes
par IBM en 1978. Ce manuel contient en particulier une description trs didac-
tique de la mthode ISAM et une prsentation de la mthode VSAM.
[Knott71] Knott G.D., Expandable Open Addressing Hash Table Storage and
Retrieval , ACM SIGFIDET Workshop on Data Description, Access and
Control, 1971, ACM Ed., p. 186-206.
Le premier article proposant un hachage dynamique, par extension progressive
de la fonction de hachage en puissances de 2 successives. Larticle sintresse
seulement au cas de tables en mmoires.
[Knuth73] Knuth D.E., The Art of Computer Programming, Addisson-Wesley, 1973.
Le livre bien connu de Knuth. Une partie importante est consacre aux struc-
tures de donnes, plus particulirement lanalyse de fonctions de hachage.
[Korth91] Korth H., Silberschatz A., Database System Concepts, Mc Graw-Hill Ed.,
2e dition, 1991.
Un des livres les plus complets sur les bases de donnes. Deux chapitres sont
plus particulirement consacrs aux organisations de fichiers et aux techniques
dindexation.
Fichiers, hachage et indexation 109
[Larson78] Larson P., Dynamic Hashing , Journal BIT, n 18, 1978, p. 184-201.
Un des premiers schmas de hachage dynamique propos, avec clatement de
paquets quand un taux de remplissage est atteint.
[Larson80] Larson P., Linear Hashing with Partial Expansions , 6th Very Large
Data Bases, Montreal, octobre 1980, p. 224-232.
Une variante du hachage linaire ou les avances du pointeur dclatement
sont contrles par le taux de remplissage du fichier.
[Larson82] Larson P., Performance Analysis of Linear Hashing with Partial
Expansions , ACM TODS, vol. 7, n 4, dcembre 1982, p. 566-587.
Cet article rsume la mthode prsente dans [Larson80] et dmontre ses
bonnes performances par une tude analytique.
[Lister84] Lister A.M., Principes fondamentaux des systmes dexploitation, ditions
Eyrolles, 4e dition, 1984.
Cet excellent livre prsente les couches successives constituant un systme
dexploitation. Un chapitre est plus particulirement consacr aux techniques
dallocation mmoire.
[Litwin78] Litwin W., Virtual Hashing: A Dynamically Changing Hashing ,
4th Very Lare Data Bases, Berlin, septembre 1978, p. 517-523.
Sans doute le premier schma de hachage dynamique propos pour des
fichiers. Celui-ci est bas sur une table de bits pour marquer les paquets cla-
ts et sur un algorithme rcursif de parcours de cette table pour retrouver la
bonne fonction de hachage.
[Litwin80] Litwin W., Linear Hashing A New Tool for File and Table
Addressing , 6th Very Large Data Bases, Montreal, octobre 1980, p. 224-232.
Larticle introduisant le hachage linaire. Lide est de remplacer la table de bits
complexe du hachage virtuel par un simple pointeur circulant sur les paquets du
fichier. N bits de la fonction de hachage sont utiliss avant le pointeur, N+1
aprs. chaque dbordement, le paquet point par le pointeur est clat.
[Lomet83] Lomet D., A High Performance, Universal Key Associative Access
Method , ACM SIGMOD Intl. Conf., San Jos, 1983.
Une mthode daccs intermdiaire entre hachage et indexation, avec de trs
compltes valuations de performances.
[Lomet89] Lomet D., Salzberg B., Access Methods for Multiversion Data , ACM
SIGMOD Intl. Conf., Portland, 1989.
Cet article discute les techniques darchivage multiversion sur disques optiques.
De tels disques sont inscriptibles une seule fois. Ils ne peuvent tre corrigs, mais
peuvent bien sr tre lus plusieurs fois (Write Once Read Many times WORM).
Ils ncessitent des organisations spcifiques tudies dans cet article.
110 BASES DE DONNES : OBJET ET RELATIONNEL
[Nievergelt84] Nievergelt J., Hinterberger H., Sevcik K., The Grid File: An
Adaptable Symetric Multi-Key File Structure , ACM TODS, vol. 9, n 1, mars
1983.
Cet article introduit le fichier grille (Grid File). Lide est simplement
dtendre le hachage extensible en composant une fonction de hachage multi-
attribut, partir de diffrentes sous-fonctions portant sur un seul attribut. Une
prise en compte successive des bits de chaque fonction garantie la symtrie.
Diffrentes organisations de rpertoires dadresses sont possibles. Un tableau
dynamique n dimensions est propos.
[ONeil87] ONeil P. Model 204 Architecture and Performance , Springer
Verlag, LCNS n 359, Proc. of 2 nd Intl. Workshop on High Performance
Transactions Systems, p. 40-59, 1987.
Cet article dcrit larchitecture du SGBD Model 204 de Computer Corporation
of America. Il introduit pour la premire fois les index bitmap.
[ONeil97] ONeil P., Quass D., Improved Query Performance with Variant index ,
ACM SIGMOD Intl. Conf., SIGMOD Record V 26, n 2, Tucson, Arizona,
USA, 1997.
Cet article prsente les index bitmap comme une alternative aux index clas-
siques listes dadresses. Il analyse les performances compares de ces types
dindex pour diffrents algorithmes de recherche.
[Samet89] Samet H., The Design and Analysis of Spatial Data Structures, Addison-
Wesley, 1989.
Ce livre prsente des mthodes daccs et organisations fondes sur les quad-
trees pour stocker et retrouver des donnes spatiales, telles que des points, des
lignes, des rgions, des surfaces et des volumes. Les quadtrees sont des struc-
tures de donnes hirarchiques bases sur un dcoupage rcursif de lespace.
Par exemple, une image plane en noir et blanc peut tre dcoupe en deux rec-
tangles, chaque rectangle tant son tour dcoup en deux jusqu obtention
de rectangles dune seule couleur. Les dcoupages successifs peuvent tre
reprsents par un arbre dont les feuilles sont 0 si le rectangle correspondant
est blanc, 1 sil est noir. Une telle structure est un quadtree. Elle permet de
constituer un index ou un arbre de placement utilisable pour une recherche effi-
cace de motifs. Le livre de Samet tudie toutes les variantes des quadtrees.
[Scholl81] Scholl M., New File Organization Based on Dynamic Hashing , ACM
TODS, vol. 6, n 1, mars 1981, p. 194-211.
Une tude des performances des mthodes par hachage dynamique.
[Widerhold83] Widerhold G., Database Design, Mc Graw-Hill Ed., New York, 1983.
Ce livre, qui fut lun des premiers sur les bases de donnes, consacre une partie
importante aux disques magntiques, aux fichiers et aux mthodes daccs.
Chapitre IV
1. INTRODUCTION
Les systmes tudis dans ce chapitre sont aujourdhui appels systmes lgataires
(legacy systems), car il nous sont lgus par le pass. Ils permettent de modliser des
articles stocks dans des fichiers ainsi que les liens entre ces articles. Ces modles
drivent avant tout dune approche systme au problme des bases de donnes qui
tend voir une base de donnes comme un ensemble de fichiers relis par des poin-
teurs. Ils privilgient loptimisation des entres-sorties. Cest pourquoi nous les appe-
lons aussi modles daccs. ces modles sont associs des langages de manipulation
de donnes bass sur le parcours de fichiers et de liens entre fichiers, article par
article, appels langages navigationnels. Ces langages sont trs caractristiques des
modles daccs.
Nous prsentons successivement les deux modles les plus populaires, savoir le
modle rseau et le modle hirarchique, avec le langage de manipulation spcifique
associ chacun deux. Le modle rseau propos initialement par le groupe DBTG
du comit CODASYL fut et reste utilis avec diverses variantes possibles par de nom-
breux systmes tels que IDS.II (Bull), IDMS (Computer-Associate), EDMS (Xerox),
112 BASES DE DONNES : OBJET ET RELATIONNEL
2. LE MODLE RSEAU
Dans cette section, nous introduisons les principaux concepts du modle rseau pour
dfinir les bases de donnes et le langage associ du Codasyl.
De plus, les mots cls obligatoires sont souligns. Les paramtres des clauses sont
prciss entre crochets triangulaires (<>).
Il existe deux types de groupes : les groupes simples et les groupes rptitifs. Un
groupe simple est une suite datomes, alors quun groupe rptitif est une collection
de donnes qui apparat plusieurs fois conscutivement. Un groupe rptitif peut tre
compos datomes ou mme de groupes rptitifs. Un groupe rptitif compos dun
seul atome est appel vecteur. Par exemple, MILLESIME, compos dANNEE et
QUALITE, peut tre dfini comme un groupe simple apparaissant une seule fois dans
un vin. Au contraire, ENFANT compos de PRENOM, SEXE et AGE pourra appa-
ratre plusieurs fois dans le descriptif dune personne : il sagit dun groupe rptitif.
Une personne pouvant avoir plusieurs prnoms, la donne PRENOM pourra tre un
vecteur apparaissant au plus trois fois. Notons que le modle rseau impose de limiter
le nombre de rptitions possibles dun groupe. Atomes et groupes permettent de
constituer les articles.
Un article peut la limite ne contenir aucune donne. Les occurrences darticles sont
ranges dans des fichiers (AREA). Par exemple, un fichier de vins contiendra des
articles composs datomes NUMERO, CRU et du groupe rptitif MILLESIME,
rpt au plus cinq fois.
Les articles sont dcrits au niveau du type dans le schma au moyen dune clause :
RECORD NAME IS <nom-darticle>.
Par exemple, le type darticle VINS sera introduit par la clause RECORD NAME IS
VINS. Suivront ensuite les descriptions dtailles des donnes de larticle.
Chaque atome ou groupe est dfini par un nom prcd dun niveau ventuel. Les
donnes dun article sont donc dfinies au moyen dun arrangement hirarchique de
groupes dans larticle. Le groupe de niveau 1 est larticle proprement dit. Les donnes
de niveau 2 sont constitues par tous les atomes non agrgs dans un groupe. Les
groupes de niveau 3 sont composs de tous les groupes ntant pas lintrieur dun
autre groupe. Viennent ensuite les groupes internes un groupe (niveau 4), etc. Pour
chaque atome, une spcification de type prcise le domaine de la donne (dcimal,
binaire, caractres). Ainsi, la clause de dfinition dun atome est :
[<niveau>] <nom-datome> TYPE IS <spcification-de-type>
alors que celle de dfinition dun groupe est simplement :
[<niveau>] <nom-de groupe>.
Les types de donnes possibles sont les suivants (version minimale sous IDS.II):
dcimal sign condens ou non (n1 et n2 prcisent respectivement le nombre de
chiffre total et celui aprs la virgule) :
SIGNED [ {PACKED | UNPACKED} ] DECIMAL <n1>, [<n2>]
entier binaire long (signe plus 31 bits) ou court (signe plus 15 bits) :
SIGNED BINARY {15 | 31}
chane de caractres de longueur fixe (n1 caractres) :
CHARACTER <n1>.
Un atome ou un groupe peuvent tre rpts plusieurs fois (cas des vecteurs et des
groupes rptitifs). Cela est prcis par la clause OCCURS du langage de description
de donnes (n1 est un entier quelconque) :
OCCURS <n1> TIMES.
Afin dillustrer ces diffrentes clauses, nous dcrivons (figure IV.1) un type darticle
VINS regroupant les cinq derniers millsimes (caractriss par une anne et un degr)
dun vin dfini par un numro (NV) et un nom de cru (CRU). Nous dcrivons gale-
ment un type darticle PRODUCTEURS compos dun numro (NP), un nom
(NOM), un prnom (PRENOM) et un groupe simple ADRESSE, compos de RUE,
CODE et VILLE.
Bases de donnes rseaux et hirarchiques 115
PRODUCTEURS
RCOLTE
VINS
Deux limitations sont importantes : (i) un type darticle ne peut tre la fois propri-
taire et membre dun mme lien ; (ii) une occurrence darticle ne peut appartenir
plusieurs occurrences du mme lien. Par exemple, deux producteurs ne pourront par-
tager la rcolte dun mme vin, comme le montre la figure IV.3. Par contre, un type
darticle peut tre matre de plusieurs liens. Il peut aussi tre membre de plusieurs
liens. Deux types darticles peuvent aussi tre lis par des types de liens diffrents.
Afin dillustrer les concepts introduits, la figure IV.4 prsente le graphe des types
dune base de donnes vinicole compose des articles :
VINS dcrits ci-dessus,
BUVEURS composs des atomes numro de buveur, nom et prnom,
ABUS dcrivant pour chaque vin la quantit bue par un buveur et la date laquelle
celle-ci a t bue,
PRODUCTEURS dfinissant pour chaque vin le nom et la rgion du producteur,
COMMANDES spcifiant les commandes de vins passes par les buveurs aux pro-
ducteurs.
Bases de donnes rseaux et hirarchiques 117
P2
P1
ABUS
CONSOMMATION DGUSTATION
VINS BUVEURS
VENTE
RCOLTE ACHAT
PRODUCTEURS COMMANDES
Volnay Chablis
10 15 20 10 7 8 11 5
Nous verrons ci-dessous les dtails des sous-clauses OWNER et MEMBER. Plusieurs
types de membres peuvent tre spcifis par rptition de la clause MEMBER.
CODASYL autorise la dfinition de liens singuliers avec une seule occurrence. Pour
cela, il suffit dutiliser la dfinition de propritaire :
OWNER IS SYSTEM
Bases de donnes rseaux et hirarchiques 119
Tous les articles membres sont alors chans entre eux dans une seule occurrence de
lien (une seule liste dont la tte de liste est gre par le systme). Cela permet de
rechercher un article parmi les membres comme dans une occurrence de lien normale,
et aussi de chaner des articles singuliers.
Loption PERMANENT (obligatoire pour les liens tris) prcise quun programme
dapplication ne peut modifier lordre dun lien. Ainsi, tout changement effectu restera
local au programme et ne perturbera pas lordre des articles dj enregistrs dans la base.
120 BASES DE DONNES : OBJET ET RELATIONNEL
25 Article insrer
First Last
Volnay
5 30
Prior Sorted
10 20
Article courant
du programme
Next
Bien que le comit DBTG CODASYL nait pas spcifi le format des cls base de don-
nes, la plupart des systmes rseaux attribuent une place fixe aux articles, si bien quune
cl base de donnes peut tre un numro de fichier, suivi dun numro de page et dun
dplacement dans la page permettant de retrouver len-tte de larticle. Certains systmes
grent en fin de page un index des en-ttes darticles contenus dans la page, si bien que le
dplacement dans la page est simplement le numro de len-tte en fin de page.
Le placement dun article consiste calculer son adresse dans la base, ainsi que sa cl
base de donnes qui en dcoule en gnral directement. Le mode de placement est
dfini dans le schma pour chaque type darticle selon plusieurs procds possibles.
De manire surprenante, la cl base de donnes peut tre fournie directement par luti-
lisateur comme un paramtre du programme. Ce mode, appel placement direct (mot
cl DIRECT), est en gnral rserv aux programmeurs systme. Le mode le plus
facilement utilisable est le placement alatoire classique : une cl, pas forcment dis-
criminante, est prcise et le systme calcule ladresse de larticle laide dune pro-
cdure de hachage. Ce mode de placement, appel placement calcul, est spcifi par
les mots cls CALC USING.
Un mode plus complexe, mais permettant en gnral de bonnes optimisations, est le
mode par lien, spcifi par le mot cl VIA. Il possde deux variantes selon que
larticle est plac dans le mme fichier que son propritaire via le lien considr, ou
dans un fichier diffrent. Dans le premier cas, larticle est plac proximit du pro-
pritaire, alors que dans le second il est plac dans un autre fichier que celui du pro-
pritaire par homothtie.
Le placement proximit consiste placer larticle aussi prs que possible du propri-
taire du lien retenu pour le placement, dans la mme page ou dans la premire page
voisine ayant de la place disponible.
Le placement par homothtie consiste calculer ladresse de la page dans laquelle on
place larticle (dnote Adresse Article AA) partir de ladresse de la page du pro-
pritaire (dnote Adresse Propritaire AP) par la formule AA = AP * TA/TP, o TA
124 BASES DE DONNES : OBJET ET RELATIONNEL
F-PRODUCTEURS
PRODUCTEURS CALC(nprod)
via
rcolte VINS BUVEURS
DGUSTATION
CONSOMMATION
VENTE ACHAT
ABUS
via dgustation
COMMANDES
via achat
F-COMMANDES
mode SYSTEM spcifiant quun algorithme dfinit par le systme est choisi. On
retrouve les modes dcrits ci-dessus, DIRECT par adresse calcule par le programme,
CALC par cl et VIA par lien. Le fichier choisi peut tre celui du propritaire ou un
autre dans le cas VIA, ce qui diffrencie le placement proximit et le placement par
homothtie. Dans tous les cas, le fichier choisi est prcis par la clause WITHIN. La
syntaxe de la clause de placement est la suivante :
LOCATION MODE IS
{ SYSTEM
| DIRECT <NOM-DE-PARAMETRE>
| CALC USING <NOM-DE-DONNE>
[ DUPLICATES ARE [NOT] ALLOWED ]
| VIA <NOM-DE-LIEN> SET}
WITHIN {<NOM-DE-FICHIER> | AREA OF OWNER}
3. LE LANGAGE DE MANIPULATION
COBOL-CODASYL
Le langage de manipulation de donnes du CODASYL est fortement li COBOL,
bien que gnralis et utilisable depuis dautres langages de 3e gnration tel Fortran.
Outre la possibilit de ne dfinir quune partie des donnes, des articles, des liens et
des fichiers, dautres variations importantes peuvent exister entre le schma et un
sous-schma. En particulier :
lordre des atomes dans un article peut tre chang,
les caractristiques (types) dun atome peuvent tre changes,
les clauses SET SELECTION peuvent tre redfinies,
les noms de types darticles, dattributs et de liens peuvent tre changs.
128 BASES DE DONNES : OBJET ET RELATIONNEL
TITLE DIVISION
SS CLIENT WITHIN SCHEMA VINICOLE
MAPPING DIVISION
ALIAS SECTION
AD SET BOIT IS DEGUSTATION
AD SET ACHETE IS ACHAT
STRUCTURE DIVISION
REALM SECTION
RD F-BUVEURS
RD F-COMMANDES
RECORD SECTION
01 BUVEURS
02 NV PICTURE IS 999
02 NOM PICTURE IS X(10)
02 PRENOM PICTURE IS X(10)
01 ABUS
02 QUANTITE PICTURE IS 999
01 COMMANDES
02 QUANTITE PICTURE IS 999
02 DATE PICTURE IS X(8)
SET SECTION
SD BOIT
SD ACHETE
ment des autres curseurs. Sil na pas t spcifi quun curseur ne doit tre dplac,
celui-ci est repositionn ds quun article de la collection laquelle il est associ (type
darticles, liens, fichiers) est manipul (lu, crit ou travers).
Le format gnral de linstruction de recherche est :
FIND <EXPRESSION-DE-SLECTION> RETAINING CURRENCY FOR
{ MULTIPLE
| REALM
| RECORD
| SETS
| <NOM DE LIEN>+}
Il est galement possible de rechercher un article partir dune valeur de donne dans
loccurrence courante dun lien. La donne dont la valeur est utilise pour ce type de
recherche associative dans une occurrence de lien est cite en argument du mot cl
USING. Cette valeur doit bien sr tre pralablement charge en zone de travail.
Selon que lon recherche la premire (ou lunique) occurrence darticle ou la suivante,
on emploie :
FIND <nom-darticle> WITHIN <nom-de-lien>
USING <nom-de-donne>+
FIND DULICATE WITHIN <nom-de-lien>
USING <nom-de-donne>+
Un lien peut tre parcouru depuis un article membre vers le propritaire, donc en sens
inverse de larc qui le reprsente dans le diagramme de Bachman. Ainsi, il est pos-
sible de slectionner le propritaire de loccurrence courante dun lien par la com-
mande :
FIND OWNER WITHIN <nom-de-lien>
Une telle instruction permet en gnral de passer depuis un membre dun lien un
propritaire, donc de remonter les arcs du graphe des types dune base de donnes
CODASYL.
Il est aussi possible de tester des conditions concernant lappartenance de larticle
courant dun programme un lien. La condition est vraie si larticle courant du pro-
gramme est propritaire (option OWNER), membre (option MEMBER) ou plus gn-
ralement participant (option TENANT) lintrieur dune occurrence du lien cit. La
forme de la commande est :
IF [NOT] <nom-de-lien> {OWNER | MEMBER | TENANT}
EXECUTE <instructions>
Il est enfin possible de tester si une occurrence de lien slectionne par un article pro-
pritaire ne possde aucun membre en utilisant la commande :
IF <nom-de-lien> IS [NOT] EMPTY EXECUTE <instructions>
132 BASES DE DONNES : OBJET ET RELATIONNEL
Cette commande a donc pour effet de forcer le curseur du programme celui du nom-
darticle spcifi, ou celui du fichier ou du lien spcifi, ventuellement selon un
type darticle prcis.
Si cet article est propritaire doccurrences de lien, tous ses descendants sont galement
supprims seulement dans le cas o le mot cl ALL est prcis. Une suppression est ainsi
cascade tous les articles dpendants, et cela de proche en proche. Le nom darticle per-
met optionnellement au systme de vrifier le type de larticle courant dtruire.
Les donnes modifier peuvent tre prcises ou non ; dans le dernier cas, le systme
modifie toutes celles qui sont changes dans larticle en zone de travail. On doit aussi
prciser les modifications apporter aux liens dont larticle est membre ; plusieurs
options sont possibles. Il est possible de demander la rvaluation, en accord avec la
clause du schma SET SELECTION de toutes (INCLUDING ALL) ou de certaines
(INCLUDING liste de noms de liens) appartenances des occurrences de liens. Il est
aussi possible de ne modifier aucune donne, mais seulement les appartenances aux
liens (option MODIFY ONLY).
READY F-BUVEURS.
MOVE 7 TO I.
MOVE 200 TO NB IN BUVEURS.
FIND ANY BUVEURS.
FIND I ABUS IN BOIT.
GET ABUS.
ADD 10 TO QUANTITE IN ABUS.
MODIFY ABUS.
FINISH.
4. LE MODLE HIRARCHIQUE
Les bases de donnes modlisent des informations du monde rel. Puisque le monde
rel nous apparat souvent au travers de hirarchies, il est normal quun des modles
les plus rpandus soit le modle hirarchique. Quelques systmes sont encore bass
sur ce modle [MRI74, IBM78]. Vous trouverez une prsentation dtaille du modle
hirarchique dans [Tsichritzis76]. Nous rsumons ici les aspects essentiels.
Les segments sont relis par des liens de 1 vers N qui un segment pre font corres-
pondre N segments fils (N est un entier positif quelconque), aussi bien au niveau des
types quau niveau des occurrences. Ainsi, un type de segment possde en gnral
plusieurs types de segments descendants. De mme, une occurrence de segment est
relie plusieurs occurrences de chacun des segments descendants. Pour reprsenter
une descendance de segments relis par des associations pre-fils, on construit des
arbres de segments.
Les types de segments sont donc organiss en arbre. Un type racine possde N1 types
fils, qui leur tour possdent chacun N2 types fils, et ainsi de suite jusquaux seg-
ments feuilles. Il est aussi possible de considrer une occurrence dun arbre de seg-
ments : une occurrence dun segment racine possde plusieurs occurrences de seg-
ments fils. Parmi celles-ci, certaines sont dun premier type, dautres dun second, etc.
leur tour, les occurrences des fils peuvent avoir des fils, et ainsi de suite jusquaux
occurrences des feuilles.
Finalement, une base de donnes hirarchique peut tre considre comme un
ensemble darbres, encore appel fort, dont les nuds sont des segments. La dfini-
tion sapplique aussi bien au niveau des types quau niveau des occurrences. Les
arbres sont en principe indpendants. Chaque arbre possde un segment racine
unique, des segments internes et des segments feuilles. Le niveau dun segment carac-
trise sa distance la racine.
Type de segment
Occurrence de segment
Les deux graphes sont bien sr des forts, cest--dire des ensembles de hirarchies
sans lien entre elles. Un graphe des types nest pas diffrent dun diagramme de
Bachman dune base de donnes rseau ; cependant, de chaque segment est issu au
plus un lien allant vers son fils. Les liens ne sont pas nomms.
titre dexemple, nous avons dfini une base de donnes hirarchique partir de la base
vinicole. Il nest videmment pas possible de reprsenter un rseau de liens tel que dfini
figure IV.4. Afin de ne pas perdre dinformations, on est conduit dupliquer certaines
donnes, par exemple le cru du vin dans les segments ABUS et le nom du buveur dans
les segments COMMANDES (Champ CLIENT). Comme les segments ne sont pas hi-
rarchiques, le type darticle VINS doit tre clat en deux segments CRUS et MILLE-
SIMES. La figure IV.17 schmatise une reprsentation hirarchique de la base vinicole.
PRODUCTEURS BUVEURS
CRUS ABUS
MILLSIMES COMMANDES
Certains modles hirarchiques autorisent les liens entre arbres pour permettre de
modliser des associations de 1 vers N sans avoir dupliquer des segments. Tout seg-
ment dun arbre peut alors pointer vers un segment dun autre arbre. Cela peut tre
limit un seul pointeur par segment : on parle de lien frre, pour distinguer ce lien
du lien vers le fils. On aboutit alors des modles hirarchiques tendus dont les pos-
sibilits se rapprochent de celles du modle rseau [IBM78].
Arbre 1 Arbre 2
DL1 est un langage de manipulation navigationnel, en ce sens que des curseurs per-
mettent de mmoriser un positionnement sur la base. Ces curseurs, appels PCB, sont
stocks dans des structures de donnes passes en arguments des appels DL1 effec-
tus comme des appels de procdure depuis les programmes utilisateurs. Les PCB
140 BASES DE DONNES : OBJET ET RELATIONNEL
Une qualification de chemin peut tre associe un appel DL1. Elle se compose
dune suite de qualifications de segments (Search Segment Argument); une qualifica-
tion de segments est une structure dont une vue simplifie est reprsente
figure IV.20. Il sagit en fait dune expression logique parenthse ou conjonctive (ET
de OU) de critres de comparaisons portant sur un segment. Outre le nom du segment
concern, chaque prdicat lmentaire contient un code commande permettant de sp-
cifier des options telles que recherche ou insertion demande, un nom de champ, un
comparateur et une valeur. Les prdicats lmentaires sont connects par le connec-
teur logique. Ils se suivent dans un SSA. Des parenthses peuvent tre utilises pour
marquer des priorits.
/*DECLARATIONS*/
DCL 1 SSA
2 SEGMENT = BUVEURS
2 CHAMP = NB
2 OPERATEUR = =
2 VALEUR = 100
DCL 1 PCB
..........
2 STATUS
/*PROGRAMME*/
GU (PCB, BUVEUR, SSA)
PRINT BUVEUR.NOM, BUVEUR.PRENOM
/*DECLARATIONS*/
DCL 1 SSA1
2 SEGMENT = PRODUCTEURS
2 CHAMP = NOM
2 OPERATEUR = =
2 VALEUR = MARTIN
DCL 1 SSA2
2 SEGMENT = CRUS
2 CHAMP = CRU
2 OPERATEUR = =
2 VALEUR = BEAUJOLAIS
DCL 1 PCB
..........
2 STATUS
/*PROGRAMME*/
GU (PCB, CRUS, SSA1, SSA2)
WHILE STATUS fin-de-descendance
GNP
PRINT segment lu
END-WHILE
/*DECLARATIONS*/
DCL 1 SSA1
2 SEGMENT = PRODUCTEURS
2 CHAMP = NOM
2 OPERATEUR = =
2 VALEUR = MARTIN
DCL 1 SSA2
2 SEGMENT = CRUS
2 CHAMP = CRU
2 OPERATEUR = =
2 VALEUR = BEAUJOLAIS
DCL 1 SSA3
2 SEGMENT = COMMANDES
2 CHAMP = DATE
2 OPERATEUR = =
2 VALEUR = 10-02-81
2 CONNECTEUR = AND
2 CHAMP = CLIENT
2 OPERATEUR = =
2 VALEUR = DUPONT
DCL 1 PCB
..........
2 STATUS
/*PROGRAMME*/
GHU (PCB, COMMANDES, SSA1, SSA2, SSA3)
COMMANDES.QUANTITE = COMMANDES.QUANTITE + 100
RPL
5. CONCLUSION
Dans ce chapitre, nous avons prsent les principaux modles daccs, cest--dire
ceux directement issus de la modlisation dorganisation darticles stocks dans des
fichiers et relis entre eux par des pointeurs. Ces modles sont encore trs utiliss :
une part significative des grandes bases de donnes sont sans doute encore hirar-
chiques ou organises en rseaux. Ces modles sont aussi trs performants car trs
proches du niveau physique. Le modle rseau permet des organisations de liens plus
gnrales que le modle hirarchique, bien que celui-ci ait souvent t tendu par des
liens inter-hirarchies.
Compte tenu de laccroissement des possibilits des machines, les modles daccs sont
aujourdhui inadapts en tant que modles conceptuels ou externes de donnes. Ils assu-
144 BASES DE DONNES : OBJET ET RELATIONNEL
rent en effet une faible indpendance des programmes aux donnes. Ils peuvent rester
trs comptitifs au niveau interne. Les critiques proviennent sans doute aussi de la com-
plexit des langages de manipulation historiquement associs ces modles, bass sur la
navigation. Cependant, il est tout fait possible de dfinir des langages de plus haut
niveau fonds sur la logique des prdicats pour un modle hirarchique ou rseau.
Finalement, la question sest pose de savoir si le modle entit-association est un
meilleur candidat pour modliser les donnes au niveau conceptuel que le modle
rseau. La rponse est positive. En effet, un modle se voulant un cadre conceptuel
pour dfinir une large classe de base de donnes structures et un mdiateur entre des
reprsentations de donnes stockes et des vues usagers, devrait probablement avoir
au moins quatre caractristiques [Codd79] :
1. permettre une reprsentation sous forme de tableaux de donnes ;
2. permettre une interrogation ensembliste afin dautoriser des requtes sans prciser
les ordres lmentaires de navigation dans la base ;
3. permettre une interprtation des objets en termes de formules de la logique des pr-
dicats afin de faciliter les infrences de connaissances ;
4. supporter une reprsentation graphique simple afin de pouvoir visualiser les objets
et leurs associations pour concevoir la base.
Ajoutons galement que la simplicit est une caractristique essentielle dun modle.
Cest l un avantage important du modle relationnel que nous allons tudier dans la
partie suivante de cet ouvrage.
6. BIBLIOGRAPHIE
[Bachman64] Bachman C., Williams S., A General Purpose Programming System
for Random Access Memories , Fall Joint Computer Conference, vol. 26,
AFIPS Press, p. 411-422.
La premire prsentation du systme IDS, ralis General Electric au dbut
des annes 60.
[Bachman69] Bachman C., Data Structure Diagrams , Journal of ACM, SIGBDP
vol. 1, n 2, mars 1969, p. 4-10.
Cet article introduit les diagrammes de Bachman. Ceux-ci permettent de mod-
liser les types darticles par des botes et les liens (sets) par des flches depuis
le propritaire vers le membre. Ils modlisent une base de donnes comme un
graphe dont les nuds sont les types darticles et les arcs les associations de 1
vers n articles. Ce type de modlisation est toujours trs utilis, notamment
dans loutil de conception BACHMAN, du nom de linventeur.
Bases de donnes rseaux et hirarchiques 145
1. INTRODUCTION
Historiquement, les chercheurs ont tout dabord essay de modliser les langages
dinterrogation de bases de donnes par la logique. Ainsi sont ns les calculs relation-
nels, vritables langages dinterrogation fonds sur la logique du premier ordre. Ce
nest qu partir de la fin des annes 70 que lon a cherch comprendre globalement
les bases de donnes par la logique. Cela a permis de montrer quun SGBD tait un
dmonstrateur de thormes trs particulier, raisonnant sur des faits et donnant les
preuves dun thorme reprsentant la question.
Les travaux sur lintroduction dans les SGBD de raisonnements gnraux incluant
non seulement des faits, mais aussi des rgles dductives exprimes en logique du
premier ordre, ont dbut principalement au CERT Toulouse la fin de la dcennie
1970-1980 [Gallaire78]. Ils se sont surtout concentrs sur la comprhension des bases
de donnes dductives par la logique. Afin de permettre la gestion de grandes bases
de connaissances (quelques milliers de rgles associes quelques millions voire mil-
liards de faits), des problmes de recherche complexes ont d tre rsolus. Ces pro-
blmes sont la croise des chemins des bases de donnes et de lintelligence artifi-
cielle et prsentent des aspects la fois thoriques et pratiques. Dun point de vue
thorique, les approches par la logique permettent une meilleure comprhension des
langages des SGBD, des mcanismes de raisonnements sous-jacents et des techniques
doptimisation. Dun point de vue pratique, le dveloppement de SGBD bass sur la
148 BASES DE DONNES : OBJET ET RELATIONNEL
nouvelles relations partir de relations connues comme vraies. Elle peut tre vue
comme un formalisme utilis pour traduire des phrases et dduire de nouvelles
phrases partir de phrases connues.
La logique du premier ordre repose sur un alphabet qui utilise les symboles suivants :
1. Des variables gnralement notes x, y, z
2. Des constantes gnralement notes a, b, c
3. Des prdicats gnralement notes P, Q, R , chaque prdicat pouvant recevoir un
nombre fixe darguments (n pour un prdicat n-aire).
4. Les connecteurs logiques , , , .
5. Des fonctions gnralement dnotes f, g, h, chaque fonction pouvant recevoir un
nombre fixe darguments (n pour une fonction n-aire).
6. Les quantificateurs et .
Des rgles syntaxiques simples permettent de construire des formules. Un terme est
dfini rcursivement comme une variable ou une constante ou le rsultat de lapplica-
tion dune fonction un terme. Par exemple, x, a, f(x) et f(f(x)) sont des termes. Une
formule est une phrase bien construite du langage. Une formule est dfinie comme
suit :
1. Si P est un prdicat n arguments (n places) et t1, t2tn des termes, alors
P(t1,t2tn) est une formule atomique.
2. Si F1 et F2 sont des formules, alors F1 F2, F1 F2, F1 F2 et F1 sont des
formules.
3. Si F est une formule et x une variable non quantifie (on dit aussi libre) dans F,
alors x F et x F sont des formules.
Nous rsumons ci-dessous les concepts essentiels introduits jusque-l sous forme de
notions.
Pour indiquer les priorits entre connecteurs logiques, il est possible dutiliser les
parenthses : si F est une formule valide, (F) en est aussi une. Afin dviter les paren-
150 BASES DE DONNES : OBJET ET RELATIONNEL
thses dans certains cas simples, nous supposerons une priorit des oprateurs
logiques dans lordre descendant , , , et . Voici quelques exemples de formules
formelles :
P(a,x) Q(x,y),
Q(x,y),
x y (Q(x,y) P(a,x)),
x (R(x) Q(x,a) P(b,f(x))).
Afin de donner des exemples plus lisibles de formules, nous choisirons un vocabulaire
moins formel, les prdicats et fonctions tant des noms ou des verbes du langage cou-
rant et les constantes des chanes de caractres dsignant par exemple des services ou
des employs. Voici quelques exemples de formules proches du langage naturel :
SERVICE(informatique,pierre) EMPLOYE (informatique,marie)
x ((DIRIGE(pierre,x) EMPLOYE(informatique,x) EMPLOYE(finance,x))
x y ((DIRIGE(x,y) DIRIGE(y,x)) MEMESERVICE(x,y))
vaille dans le mme service . La formule est vraie si Pierre, Paul et Marie travaillent
dans le mme service.
Un univers de discours infini peut tre retenu pour interprter la formule
x (x < SUCC(x)). En effet, cette formule peut tre interprte sur lensemble des
entiers positifs {1,2,3} qui est infini. < est alors la relation est infrieur et
SUCC la fonction qui tout entier associe son successeur. Il est clair que cette for-
mule est vraie sur les entiers.
Ainsi, tant donn une interprtation dune formule sur un domaine de discours, il est
possible dassocier une valeur de vrit cette formule. Pour viter les ambiguts (les
formules pouvant avoir plusieurs valeurs de vrit), nous considrons seulement les
formules dans lesquelles toutes les variables sont quantifies, appeles formules fer-
mes. Toute formule ferme F a une unique valeur de vrit pour une interprtation
donne sur un domaine de discours D. Cette valeur note V(F) se calcule ainsi :
V(F1 F2) = V(F1) V(F2)
V(F1 F2) = V(F1) V(F2)
V( F1) = V(F1)
V(x F) = V(F x=a) V(F x=b) o a, b, sont les constantes de D.
V(x F) = V(F x=a) V(F x=b) o a, b, sont les constantes de D.
V(P(a,b)) = Vrai si [a,b] satisfait la relation P et Faux sinon.
Un modle dune formule logique est une interprtation sur un domaine de discours
qui rend la formule vraie. Par exemple, les entiers sont un modle pour la formule
x (x < SUCC(x)) avec linterprtation indique ci-dessus. En effet, en appliquant les
rgles ci-dessus, on calcule :
V(x (x < SUCC(x))) = V(1 < 2) V(2<3) V(3<4) = Vrai.
Une clause ayant un seul littral situ aprs limplication (on dit en tte de clause),
donc un seul Qi, est dite clause de Horn.
152 BASES DE DONNES : OBJET ET RELATIONNEL
Par exemple :
ENTIER(x) (x > 0) (x < SUCC(x)) (x > SUCC(x))
DIRIGE(x,y) MEMESERVICE(x,y) AIME(x,y) DETESTE(x,y)
sont des clauses.
ENTIER(x) (x > 0) (x < SUCC(x))
DIRIGE(x,y) MEMESERVICE(x,y) AIME(x,y)
sont des clauses de Horn.
La transformation dune formule ferme en clauses seffectue par des transformations
successives que nous dcrivons brivement ci-dessous. Nous illustrons les transforma-
tions avec la formule :
x y ((DIRIGE(x,y) DIRIGE(y,x)) MEMESERVICE(x,y)).
1. limination des implications. Ceci seffectue simplement en remplaant toute
expression de la forme A B par A B. En effet, ces expressions sont quiva-
lentes du point de vue logique. La formule choisie en exemple devient :
x y ( (DIRIGE(x,y) DIRIGE(y,x)) MEMESERVICE(x,y)).
2. Rduction de la porte des ngations. Le but est de faire que les ngations
sappliquent directement des prdicats atomiques. Pour cela, on utilise de manire
rpte les transformations :
(A B) devient A B;
(A B) devient A B;
(xA) devient xA;
(xA) devient xA;
( A) devient A.
Lexemple devient :
x y (( DIRIGE(x,y) DIRIGE(y,x)) MEMESERVICE(x,y)).
3. Mise en forme prenex. Il sagit simplement de mettre les quantificateurs avec la
variable quantifie en-tte de formule. Cette tape peut ncessiter de renommer les
variables afin dviter les confusions de quantification. Notre exemple reste ici
inchang.
4. limination des quantificateurs. Afin de simplifier encore, les variables quanti-
fies existentiellement sont remplaces par une constante paramtre dite constante
de Skolem. En effet, sil existe x satisfaisant une formule, il est possible de choisir
une constante s dsignant cette valeur de x. Attention, si une variable quantifie par
quel que soit apparat avant la variable quantifie par il existe , la constante
choisie dpend de la premire variable. Par exemple, dans le cas x y (pour tout x,
Logique et bases de donnes 153
il existe y, mais le y dpend de x), on remplacera donc y par s(x), cest--dire une
fonction de Skolem qui matrialise la constante y dpendant de x. Ainsi, il est pos-
sible dliminer les variables quantifies par il existe . Aprs cette transforma-
tion, toute variable restante est quantifie par quel que soit . On peut donc
oublier dcrire les quantificateurs (cest implicitement ). Notre exemple devient
alors :
(( DIRIGE(x,s(x)) DIRIGE(s(x),x)) MEMESERVICE(x,s(x))).
5. Mise en forme normale conjonctive. La formule restante est une combinaison par
des ou et des et de littraux positifs ou ngatifs (prdicats atomiques prc-
ds ou non dune ngation). Elle peut tre crite comme une conjonction () de dis-
jonction () en distribuant les et par rapport aux ou laide de la rgle :
A (B C) devient (A B) (A C).
Lexemple devient ainsi :
( DIRIGE(x,s(x)) MEMESERVICE(x,s(x))) ( DIRIGE(s(x),x))
MEMESERVICE(x,s(x))).
6. criture des clauses. Finalement, il est simple dcrire chaque clause sur une ligne
en remplaant les et par des changements de lignes. De plus, profitant du fait
que A s crit A , on peut crire tous les prdicats ngatifs dabord en
liminant la ngation et en les connectant par , puis tous les prdicats positifs
connects par . On obtient bien ainsi une suite de clauses, dfinies comme ci-des-
sus. Avec lexemple, on obtient deux clauses (dailleurs de Horn):
DIRIGE(x,s(x)) MEMESERVICE(x,s(x))
DIRIGE(s(x),x)) MEMESERVICE(x,s(x))).
vrais. Le langage permet dexprimer les requtes, comme nous le verrons ci-dessous.
Une contrainte dintgrit peut tre vue comme une requte toujours vraie, donc
exprime avec le langage.
t crdite sur votre compte est faux ! Des chercheurs ont essay de lever cette hypo-
thse : on tombe alors dans lhypothse du monde ouvert, ou un fait non enregistr
peut tre inconnu [Reiter78].
pour inclure les oprateurs de comparaison arithmtique {=, <, , >, , } comme des
prdicats particuliers, dont la valeur de vrit est calcule par les oprations usuelles
des calculateurs.
La rponse une question F(x1, , xn) o x1, xn sont des variables libres dans la
formule F est alors lensemble des n-uplets <e1, ,ep> tels que F(e1, ep) est
vraie. Certaines formules doivent tre toujours vraies sur linterprtation que constitue
la base : ce sont alors des contraintes dintgrit. Cette vue logique des bases de don-
nes a donn naissance deux calculs permettant dexprimer des questions et des
contraintes dintgrit sur les bases : le calcul de domaine et le calcul de tuple. Dans
le premier, les objets de linterprtation logique sont les valeurs atomiques de
donnes ; dans le second ce sont les faits composites correspondant aux n-uplets,
encore appels tuples. Nous tudions ces deux calculs ci-dessous.
4. LE CALCUL DE DOMAINES
Les calculs relationnels de domaine et de tuples [Codd72] permettent dexprimer des
requtes laide de formules du premier ordre sur une base de donnes logique, ou sa
reprsentation tabulaire qui est une base de donnes relationnelles. Ils ont t utiliss
pour formaliser les langages dinterrogation pour les bases de donnes relationnelles.
Ci-dessous, nous tudions tout dabord le calcul de domaine et sa reprsentation bi-
dimensionnelle QBE [Zloof77], puis le calcul de tuples. Le langage QUEL introduit
au chapitre II peut tre peru comme un paraphrasage en anglais du calcul de tuples.
La BNF du calcul relationnel de domaine est dfinie figure V.3. Pour simplifier, les
formules sont crites en forme prenex (quantificateurs devant). En pratique, une sim-
plification dcriture permet de regrouper des prdicats de restriction du type (x = a)
et des prdicats de dfinition de variable du type P (x, ) en crivant P (a, ). Toute
variable apparaissant dans le rsultat doit tre dfinie dans un prdicat extensionnel et
doit rester libre dans la formule spcifiant la condition. Une variable non utilise ni en
rsultat ni dans un critre de comparaison peut tre remplace par la variable muette
positionnelle note .
mercialis par IBM au-dessus de DB2 depuis 1983 et plus rcemment par de nom-
breux autres constructeurs avec des prsentation varies, par exemple par Microsoft
dans ACCESS. Ce langage peut tre considr comme une mise en uvre visuelle
(base sur des tableaux affichs) du calcul relationnel de domaine.
Lide de base du langage est de faire formuler une question lutilisateur partir
dun exemple dune rponse possible la question. Pour cela, lutilisateur provoque
tout dabord laffichage du schma des tables ncessaires la question quil dsire
poser (sous forme de squelettes de tables) par frappe du nom des tables correspon-
dantes. Ainsi, des tables vides (avec seulement les en-ttes de colonnes et le nom de la
relation associe) apparaissent sur lcran. Elles correspondent bien sr aux dfini-
tions des prdicats extensionnels de la base logique. Par exemple, il est possible
dafficher le schma des tables PRODUIT, VENTE et ACHAT comme reprsent
figure V.4.
Comme indiqu ci-dessus, QBE peut tre vu comme une implantation deux dimen-
sions du calcul relationnel de domaines. Pour cela, les rgles suivantes sont utilises :
1. Les rsultats (attributs projeter en relationnel) sont dfinis en frappant P.
(PRINT) dans la colonne associe. Il est possible dimprimer tous les attributs
dune table en frappant P. dans la colonne contenant le nom de la table.
160 BASES DE DONNES : OBJET ET RELATIONNEL
2. Les constantes sont tapes directement dans la colonne de lattribut associ, prc-
des de loprateur de comparaison les reliant lattribut si ce nest pas = (cest--
dire <, , >, , ). Dans le cas o un critre complexe est ncessaire avec des
conjonctions (and) et disjonctions (or), il est possible douvrir une bote condition et
de taper le critre dans cette bote (par exemple A < 10 AND A > 5).
3. Les variables domaines sont dsignes par des valeurs exemples soulignes tapes
dans la colonne les spcifiant ; la valeur exemple souligne est en fait le nom de la
variable domaine ; par suite, QBE associe deux valeurs soulignes identiques
comme dfinissant une mme variable.
4. Le quantificateur quel-que-soit est appliqu une variable en tapant ALL.
devant son nom (lexemple soulign) alors que toute variable non imprime non
prcde de P. est implicitement quantifie par il-existe .
5. Le connecteur ou (or) est exprim en utilisant deux lignes (deux exemples) comme
si lon avait en fait deux questions, lune avec la partie gauche et lautre avec la par-
tie droite de la qualification (aprs mise en forme normale disjonctive).
laide de ces rgles simples, il est possible dexprimer toute question du calcul rela-
tionnel de domaines. Nous avons formul (voir figure V.5) les questions introduites
ci-dessus (Q1 Q7) sur la base des produits. Remarquez laspect naturel de ce lan-
gage par lexemple qui peut tre simplement paraphras.
P. P.
P. P. Rouge
Logique et bases de donnes 161
100 P.
100 P.
ALL.100
100 P.
P. > 1000
boite condition
COULEUR = "Rouge" OR COULEUR = "Verte"
P.ALL.Cx
Il est galement possible dobtenir des rsultats tris par ordre croissant (mot cl AO.)
ou dcroissant (mot cl DO.). Par exemple, ldition des noms de produits en stock en
quantit suprieure 100 par ordre alphabtique descendant sera obtenue par excu-
tion de la question reprsente figure V.7.
De plus, QBE offre des facilits pour accomplir les oprations de type fermeture tran-
sitive de graphe. Le calcul de la fermeture transitive est impossible avec les langages
bass sur le calcul de prdicats. Soit par exemple la relation reprsente figure V.8.
Tout composant peut aussi tre un compos. Si lon veut rechercher les composants de
voiture au deuxime niveau, il est possible avec QBE dutiliser la question reprsen-
te figure V.9.
Logique et bases de donnes 163
Pour rechercher les composants de niveau n partir dun composant (ou les composs
de niveau n partir dun compos), il faut une question n lignes. Ceci peut tre fasti-
dieux. Afin de simplifier, QBE autorise le mot cl L entre parenthses prcd dun
nombre de niveaux (par exemple (2L)). Ainsi, la question prcdente pourra aussi tre
formule comme sur la figure V.10.
figure V.11. Une telle question nest pas exprimable laide du calcul relationnel de
domaines, mais ncessite la rcursion que nous tudierons dans le cadre des BD
dductives. Il est aussi possible dobtenir les composants de dernier niveau laide du
mot cl LAST.
Finalement, QBE dispose galement des fonctions dagrgats qui dpassent la logique
du premier ordre. Les fonctions CNT (dcompte), SUM (somme), AVG (moyenne),
MAX (maximum) et MIN (minimum) permettent de faire des calculs sur plusieurs
valeurs de variables, celles-ci tant slectionnes par des critres exprims par une
question. Ces fonctions peuvent tre appliques toute variable rsultat condition
quelle soit prcde de ALL. Si lon dsire liminer les doubles avant application de
la fonction, il faut appliquer avant loprateur unique (mot cl UNQ). Par exemple, si
lon veut connatre la quantit en stock des produits de nom Vins on crira la
question reprsente figure V.12.
"Vins" P.SUM.ALL.Q
QBE permet aussi la mise jour des prdicats extensionnels, cest--dire des tables. Il
est possible :
dinsrer des n-uplets dans une relation (oprateur I. en premire colonne) ; la
figure V.13 illustre linsertion du produit de cl 200 ;
Logique et bases de donnes 165
U. 200 10 "Rouge"
200 10 + 100
Figure V.14 : Mise jour des quantits en stock des produits rouges
S. "Rouge"
QBE permet enfin une dfinition trs dynamique de la base de donnes. Il est
possible de crer et dtruire des prdicats extensionnels (tables). De plus, il est
permis dtendre un prdicat en ajoutant des attributs. QBE est donc un langage
trs souple et complet, issu de la logique du premier ordre applique aux tables rela-
tionnelles.
5. LE CALCUL DE TUPLES
Le calcul relationnel de tuples [Codd72] se dduit de la logique du premier ordre.
Comme le calcul de domaine, le calcul de tuples permet dexprimer une question
comme une formule. Cette fois, les constantes sont interprtes comme les n-uplets de
la base. Les variables parcourent donc les lignes des tables. Afin de distinguer les
deux calculs, nous noterons les variables tuples par des majuscules X, Y, Z Il est
dailleurs possibles de mixer calcul de domaines et calcul de tuples en utilisant la
fois des variables tuples et des variables domaines [Reiter84].
(Q7) Donner les noms des produits fournis par tous les fournisseurs et achets par au
moins un client :
{(P.NOMP) | PRODUIT(P) (A1 (ACHAT(A1) (A2 (ACHAT(A2)
A2.NOMF = A1.NOMF A2.NPRA = P.NPRO)))
(V (VENTE(V) V.NPRV = P.NPRO))}
Les questions (Q6) et (Q7) dmontrent la difficult dutilisation des quantificateurs
quel-que-soit et il existe . En gnral, toute variable apparaissant dans la
rponse doit tre libre dans la condition. Les il existe ne sont utiles qu lintrieur
des quantifications universelles.
dinfrence. Une rgle dinfrence est une rgle permettant de gnrer une formule
partir de deux ou plus. Une rgle dinfrence correcte permet de gnrer une formule
valide (vraie sur les univers de discours considrs) partir de formules valides.
Deux rgles dinfrences bien connues sont :
Le modus ponens. Il permet de gnrer P partir des deux formules F et F P.
Intuitivement, cela signifie que si F et F implique P sont prouves, alors P est prou-
ve. On crit formellement :
F FP
P
La spcialisation. Elle permet de gnrer F(a) partir de la formule xF(x).
Intuitivement, cela signifie que si F(x) est prouve pour toute valeur de x, alors F(a)
est prouve. On crit formellement :
x F(x)
F(a)
Il existe une rgle dinfrence gnrale pour les formules du premier ordre en forme
clausale. Cette rgle gnre par application rcursive toutes les formules qui peuvent
tre dduites partir de deux axiomes sous forme de clauses. Il sagit de la rgle
dinfrence de Robinson [Robinson65]. Elle sappuie sur lalgorithme dunifica-
tion qui permet de comparer deux formules atomiques.
ECHEC sil est impossible de les rendre identiques par une substitution de terme
unique chaque variable.
Lalgorithme est rcursif : il exploite les termes partir du dbut en unifiant tte et
queue successivement. Il existe beaucoup dalgorithmes dunification, celui-l nest
quindicatif.
Quelques exemples simples permettent dillustrer lalgorithme. On note {x/t1; y/t2; }
la substitution qui remplace x par t1, y par t2, etc. Les formules DIRIGE(pierre,marie) et
DIRIGE(x,y) sont simplement unifiables par la substitution {x/pierre; y/marie}. Les for-
mules DIRIGE(chef(x),pierre) et DIRIGE(chef(chef(pierre)),y) sont unifiables par la
substitution {x/chef(pierre); y/pierre}. Les formules DIRIGE(chef(x),x) et
DIRIGE(chef(chef(x)),x) ne sont pas unifiables: il faudrait que x devienne la fois
chef(x) et x, ce qui est syntaxiquement impossible.
DIRIGE(pierre,julie) DIRIGE(pierre,julie)
7. CONCLUSION
Nous avons dans ce chapitre rappel les concepts de base de la logique du premier
ordre. Une base de donnes peut tre vue comme linterprtation dun langage
logique. Cette vision est limite et nous irons beaucoup plus loin avec les bases de
donnes dductives, traites dans la 4e partie de cet ouvrage.
Logique et bases de donnes 173
Quoi quil en soit, la logique constitue une bonne base pour comprendre les bases de
donnes, en particulier les BD relationnelles. Une BD relationnelle est un ensemble de
tables donnant les extensions valides des prdicats. Le calcul de tuples et le calcul de
domaines sont des formalisations logiques des langages dinterrogation des bases de
donnes relationnelles. Nous allons tudier le modle relationnel indpendamment de
la logique dans la partie qui suit, mais il ne faut pas perdre de vue que la logique est
son fondement.
8. BIBLIOGRAPHIE
[Ceri91] Ceri S., Gottlob G., Tanca L., Logic Programming and Databases, Surveys
in Computer Sciences, Springer Verlag, 1990.
Un livre fondamental sur le modle logique. Le livre introduit Prolog comme un
langage dinterrogation de donnes, les bases de donnes relationnelles vues
dun point de vue logique, et enfin les couplages de Prolog et des bases de don-
nes. Dans une deuxime partie, Datalog et ses fondements sont prsents. La
troisime partie est consacre aux techniques doptimisation de Datalog et un
survol des prototypes implmentant ces techniques.
[Clark78] Clark C. Negation as failure in Logic and databases, dit par Gallaire
et Minker, Plenum Press, New York, 1978.
Un article de base sur la ngation en programmation logique. Il est propos
daffirmer quun fait est faux sil ne peut tre dmontr vrai (ngation par
chec). Cela conduit interprter les rgles comme des quivalences : si
peut tre lu comme si et seulement si condition de collecter toutes les
rgles menant un mme but en une seule.
[Clocksin81] Clocksin W.F., Mellish C.S., Programming in Prolog, Springer Verlag,
Berlin-Heidelberg-New York, 1981.
Un livre de base sur le langage Prolog. Prolog utilise des bases de faits en
mmoire qui sont similaires aux bases logiques dcrites dans ce chapitre. En
plus, Prolog gre la dduction.
[Codd72] Codd E.F., Relational Completness of Data Base Sublanguages , In Data
Base Systems, Courant Computer Science Symposia Series, n 6, Prentice-Hall,
1972.
Cet article introduit la notion de compltude pour un langage dinterrogation
de bases de donnes relationnelles. Il donne la dfinition du calcul relationnel
de tuple et de lalgbre relationnelle. Il dmontre que lalgbre est aussi puis-
sante que le calcul en donnant un algorithme de traduction de calcul en
174 BASES DE DONNES : OBJET ET RELATIONNEL
algbre. Codd argumente aussi sur les avantages du calcul comme base dun
langage utilisateur.
[Gallaire78] Gallaire H., Minker J., Logic and Databases, Plenum Press, 1978.
Le premier livre de base sur la logique et les bases de donnes. Ce livre est une
collection darticles prsents Toulouse lors dun workshop tenu en 1977
sur le sujet.
[Gallaire81] Gallaire H., Minker J., Nicolas J.M., Advances in database theory, vol. 1,
Plenum Press, 1981.
Le second livre de base sur la logique et les bases de donnes. Ce livre est une
collection darticles prsents Toulouse lors dun workshop tenu en 1979
sur le sujet.
[Gallaire84] Gallaire H., Minker J., Nicolas J.M., Logic and databases: a deductive
approach , ACM Computing Surveys, vol. 16, n 2, juin 1984.
Un article de synthse sur les bases de donnes et la logique. Diffrents types
de clauses (fait positif ou ngatif, contrainte dintgrit, loi dductive) sont iso-
ls. Linterprtation des bases de donnes comme un modle ou comme une
thorie de la logique est discute. Les diffrentes variantes de lhypothse du
monde ferm sont rsumes.
[Lloyd87] Lloyd J., Foundations of logic programming, 2e dition, Springer Verlag
Ed., 1987.
Le livre de base sur les fondements de la programmation logique. Les diff-
rentes smantiques dun programme logique sont introduites. Les techniques de
preuve de type rsolution avec ngation par chec sont dveloppes.
[Manna85] Manna Z., Waldinger R., The Logical Basis for Computer Programming,
vol. 1, 618 pages, Addison-Wesley, 1985.
Le livre de base sur la logique. La syntaxe, la smantique et les mthodes de
preuves pour la logique du premier ordre sont dveloppes. La logique du
deuxime ordre, o des variables peuvent reprsenter des prdicats, est aussi
tudie.
[Merrett84] Merrett T.H., Relational Information Systems, Prentice Hall, 1984, cha-
pitre 5.
Un bon livre trs synthtique sur les bases de donnes, avec de nombreux
exemples pratiques. La relation composant-compos (et plus gnralement
lapplication Facture de Matriel Bill of Material ) est introduite.
[Nilsson80] Nilsson N., Principles of Artificial Intelligence, Tioga Publication, 1980.
Un des livres de base de lintelligence artificielle. Les systmes de rgles de
production pertinents aux bases de donnes dductives sont particulirement
dvelopps.
Logique et bases de donnes 175
[Reiter78] Reiter R., On closed world data bases , in Logic and databases, dit
par Gallaire et Minker, Plenum Press, New York, 1978.
Larticle de base sur lhypothse du monde ferm.
[Reiter84] Reiter R., Towards a Logical Reconstruction of Relational Database
Theory , in On Conceptual Modelling, p. 191-234, Springer-Verlag Ed., 1984.
Une redfinition des bases de donnes relationnelles en logique. Les diffrents
axiomes ncessaires linterprtation dune base de donnes comme une tho-
rie en logique sont prsents: fermeture des domaines, unicit des noms,
axiomes dgalit, etc. Les calculs relationnels sont unifis et gnraliss.
[Robinson65] Robinson J.A., A Machine oriented Logic based on the Resolution
Principle , Journal of the ACM, 12, 1965.
Larticle introduisant la mthode de rsolution.
[Ullman88] Ullman J.D., Principles of Database and Knowledge-base Systems, vol. I
et II, Computer Science Press, 1988.
Deux volumes trs complets sur les bases de donnes, avec une approche plutt
fondamentale. Jeffrey Ullman dtaille tous les aspects des bases de donnes,
depuis les mthodes daccs jusquaux modles objets en passant par le modle
logique. Les livres sont trs centrs sur une approche par la logique des bases
de donnes. Les calculs de tuples et domaines, les principaux algorithmes
daccs, doptimisation de requtes, de concurrence, de normalisation, etc. sont
dtaills.
[Zloof77] Zloof M., Query-by-Example: A Data Base Language , IBM Systems
Journal, vol. 16, n 4, 1977, p. 324-343.
Cet article prsente QBE, le langage par grille driv du calcul de domaines
propos par Zloof, alors chercheur IBM. Ce langage bi-dimensionnel est
aujourdhui oprationnel en sur-couche de DB2 et aussi comme interface
externe du systme Paradox de Borland. Zloof discute aussi des extensions
bureautiques possibles, par exemple pour grer le courrier (OBE).
Partie 2
LE RELATIONNEL
LE MODLE RELATIONNEL
1. INTRODUCTION :
LES OBJECTIFS DU MODLE
Le modle relationnel a t introduit par E. F. Codd [Codd70], qui travaillait au
fameux centre de recherche dIBM San-Jos et sopposait au dveloppement du
modle DIAM, un modle utilisant des entits lies par de multiples pointeurs. La
premire volont du modle relationnel fut dtre un modle ensembliste simple, sup-
portant des ensembles denregistrements aussi bien au niveau de la description que de
la manipulation. Les premires ides dun modle ensembliste avaient t proposes
un peu avant, notamment dans [Childs68]. Le modle relationnel est aujourdhui la
base de nombreux systmes, et les architectures permettant daccder depuis une sta-
tion de travail des serveurs de donnes sappuient en gnral sur lui. Le relationnel a
donc atteint ses objectifs au-del de toute esprance.
Les premiers objectifs du modle ont t formuls par E. F. Codd [Codd70] comme suit :
1. Permettre un haut degr dindpendance des programmes dapplications et des acti-
vits interactives la reprsentation interne des donnes, en particulier aux choix
des ordres dimplantation des donnes dans les fichiers, des index et plus gnrale-
ment des chemins daccs.
2. Fournir une base solide pour traiter les problmes de cohrence et de redondance
des donnes.
180 BASES DE DONNES : OBJET ET RELATIONNEL
Ces deux objectifs, qui ntaient pas atteints par les modles rseau et hirarchique,
ont t pleinement satisfaits par le modle relationnel, dune part grce la simplicit
des vues relationnelles qui permettent de percevoir les donnes sous forme de tables
deux dimensions, et dautre part grce aux rgles dintgrit supportes par le modle
et ses fondements logiques.
En addition aux objectifs fixs par E. F. Codd, le modle relationnel a atteint un troi-
sime objectif :
3. Permettre le dveloppement de langages de manipulation de donnes non procdu-
raux bass sur des thories solides.
Ce troisime objectif est atteint dune part laide de lalgbre relationnelle qui per-
met de manipuler des donnes de manire trs simple et formelle comme les opra-
teurs arithmtiques permettent de manipuler des entiers , et dautre part laide des
langages assertionnels bass sur la logique qui permettent de spcifier les donnes que
lon souhaite obtenir sans dire comment les obtenir.
Finalement, le modle relationnel a atteint deux autres objectifs non prvus initiale-
ment :
4. tre un modle extensible permettant de modliser et de manipuler simplement des
donnes tabulaires, mais pouvant tre tendu pour modliser et manipuler des don-
nes complexes.
5. Devenir un standard pour la description et la manipulation des bases de donnes.
Lobjectif 4 est trs important, car il a permis dintgrer de nouveaux concepts au
modle relationnel, notamment la plupart des concepts de lorient objets que nous
tudierons dans la troisime partie de cet ouvrage. Les premiers travaux de recherche
dans ce sens ont t effectus par Codd lui-mme [Codd79], puis poursuivis Bell
Laboratories [Zaniolo83], Berkeley [Stonebraker87] et, en France, lINRIA
[Gardarin89].
Lobjectif 5 a t ralis en particulier grce IBM : le modle relationnel et son lan-
gage SQL ont t normaliss au niveau international en 1986 [ISO89]. Nous ferons un
point sur le langage SQL et sa standardisation dans le chapitre suivant.
Dans ce chapitre, nous allons tout dabord prsenter les concepts structuraux de base
du modle relationnel qui permettent de modliser les donnes sous forme de tables
deux dimensions. Nous exposerons ensuite les rgles de cohrence des relations qui
sont considrs comme partie intgrante du modle. Puis nous introduirons lalgbre
relationnelle, qui est loutil formel indispensable pour manipuler des relations. Les
nombreuses extensions de cette algbre seront galement prsentes. En conclusion,
nous dmontrerons les vastes possibilits denrichissement offertes par le modle rela-
tionnel, possibilits qui seront tudies plus en dtail au niveau des modles objets et
logiques, sujets dautres parties de ce livre.
Le modle relationnel 181
Les domaines sont donc les ensembles dans lesquels les donnes prennent valeur.
Comme un ensemble, un domaine peut tre dfini en extension, en donnant la liste des
valeurs composantes, ou en intention, en dfinissant une proprit caractristique des
valeurs du domaine. Au dpart, les domaines ENTIER, REEL, BOOLEEN,
CARACTERES (une chane de caractres de longueur fixe ou variable) sont dfinis en
intention. partir de ces domaines, il est possible de dfinir en intention des
domaines plus spcifiques tels que MONNAIE (rel avec 2 chiffres derrire la virgule),
DATE (entier de 6 chiffres jour, mois et an), TEMPS (heure en secondes), etc. Un
domaine peut toujours tre dfini en extension, par exemple le domaine des couleurs
de vins : COULEUR-VINS = {Ros, Blanc, Rouge}.
Rappelons que le produit cartsien dun ensemble de domaines D1, D2..., Dn est
lensemble des vecteurs <v1, v2..., vn> o, pour i variant de 1 n, vi est une
valeur de Di. Par exemple, le produit cartsien des domaines COULEUR-
VINS = {ROSE, BLANC, ROUGE} et CRUS = {VOLNAY, SANCERRE,
CHABLIS} est compos des neuf vecteurs reprsents figure VI.1.
ROSE VOLNAY
ROSE SANCERRE
ROSE CHABLIS
BLANC VOLNAY
BLANC SANCERRE
BLANC CHABLIS
ROUGE VOLNAY
ROUGE SANCERRE
ROUGE CHABLIS
Sous-ensemble dun produit cartsien, une relation est compose de vecteurs. Une
reprsentation commode dune relation sous forme de table deux dimensions a t
retenue par Codd. Elle est gnralement utilise. Chaque ligne correspond un vec-
teur alors que chaque colonne correspond un domaine du produit cartsien
considr ; un mme domaine peut bien sr apparatre plusieurs fois. Par exemple,
partir des domaines COULEURS_VINS et CRUS, il est possible de composer la rela-
tion COULEURS_CRUS reprsente sous forme tabulaire figure VI.2.
ROSE SANCERRE
ROSE CHABLIS
BLANC SANCERRE
ROUGE VOLNAY
ROUGE SANCERRE
ROUGE CHABLIS
Pour pouvoir distinguer les colonnes dune relation sans utiliser un index, et ainsi
rendre leur ordre indiffrent tout en permettant plusieurs colonnes de mme domaine,
il est ncessaire dassocier un nom chaque colonne. Une colonne se distingue dun
domaine en ce quelle prend valeur dans un domaine et peut un instant donn com-
porter seulement certaines valeurs du domaine. Par exemple, si le domaine est
lensemble des entiers, seules quelques valeurs seront prises un instant donn, par
exemple {10, 20, 30}. Lensemble des valeurs dune colonne de relation est en gn-
ral fini. Afin de bien distinguer domaine et colonne, on introduit la notion dattribut
comme suit :
Le nom associ un attribut est souvent porteur de sens. Il est donc en gnral diff-
rent de celui du domaine qui supporte lattribut. Ainsi, la premire colonne de la rela-
tion COULEUR-CRUS pourra tre appele simplement COULEUR et la deuxime
CRU. COULEUR et CRU seront donc deux attributs de la relation COULEUR-CRUS.
Le modle relationnel 183
Les lignes dune relation correspondent des n-uplets de valeurs. Une ligne est aussi
appele tuple (du mot anglais tuple) : un tuple correspond en fait un enregistrement
dans une relation (encore appele table).
La notion de relation est bien connue en mathmatiques : une relation n-aire est un
ensemble de n-uplets. Un cas particulier souvent employ est la relation binaire, qui
est un ensemble de paires ordonnes. Une relation n-aire est souvent reprsente par
un graphe entre les ensembles composants. Ainsi, la relation LOCALISATION, don-
nant la rgion de chaque cru et certains prix moyens des vins associs, est reprsente
par un graphe figure VI.3.
Sancerre Loire 45
Chablis 42
Bourgogne
Volnay
38
Une relation peut aussi tre reprsente sur un diagramme n dimensions dont les
coordonnes correspondent aux domaines participants. Ainsi, la relation STATIS-
TIQUE, dattributs AGE et SALAIRE, donnant la moyenne des salaires par ge, est
reprsente figure VI.4.
Salaire
100
80
60
40
20
10
0 ge
Une autre perception mathmatique dune relation consiste voir chaque tuple t
comme une fonction t : Ai > Di pour i = 1, 2... n qui applique donc les
attributs sur les domaines. Ainsi, une relation peut tre vue comme un ensemble fini
de fonctions. Bien sr, cet ensemble varie en fonction du temps. Tout ceci montre la
diversit des outils mathmatiques qui peuvent tre appliqus aux relations. En cons-
quence, le modle relationnel peut apparatre comme un modle mathmatique simple
des donnes. De plus, grce la reprsentation tabulaire, il est simple apprhender
pour les non mathmaticiens.
Soulignons que le schma dune relation reprsente son intention, cest--dire les
proprits (au moins certaines) communes et invariantes des tuples quelle va contenir
Le modle relationnel 185
au cours du temps. Au contraire, une table reprsente une extension dune relation
(voir figure VI.2 par exemple), cest--dire une vue des tuples quelle contient un
instant donn. Une extension dune relation R est aussi appele instance de R.
Lintention est le rsultat de la description des donnes, alors quune extension (ou
instance) fait suite des manipulations et reprsente un tat de la base.
3.1. UNICIT DE CL
Par dfinition, une relation est un ensemble de tuples. Un ensemble nayant pas dl-
ment en double, il ne peut exister deux fois le mme tuple dans une relation. Afin
didentifier les tuples dune relation sans donner toutes les valeurs et dassurer simple-
ment lunicit des tuples, la notion de cl est utilise.
De manire plus formelle, une cl dune relation R est un ensemble dattributs K tel
que, quels que soient les tuples t1 et t2 dune instance de R, t1(K) t2(K),
cest--dire que t1 et t2 ont des valeurs de K diffrentes. Un ensemble dattributs
contenant une cl est appele super-cl [Ullman88].
Toute relation possde au moins une cl car la connaissance de tous les attributs per-
met didentifier un tuple unique. Sil existe plusieurs cls, on en choisit en gnral une
186 BASES DE DONNES : OBJET ET RELATIONNEL
arbitrairement qui est appele cl primaire. Par exemple, NV peut constituer une cl
primaire pour la relation VINS. Le couple <CRU,MILLESIME> est une cl alterna-
tive.
Soulignons que la notion de cl caractrise lintention dune relation : dans toute
extension possible dune relation, il ne peut exister deux tuples ayant mme valeur
pour les attributs cls. La dtermination dune cl pour une relation ncessite donc
une rflexion sur la smantique de la relation, cest--dire sur toutes les extensions
possibles et non pas sur une extension particulire.
NB
NV
Degr
Nom Type Cru
En relationnel, chaque entit est reprsente par une table. Une association est aussi
reprsente par une table, dont les attributs seront les cls des entits participantes,
cest--dire NB et NV, ainsi que les attributs caractrisant lassociation, par exemple
la date et la quantit bue. On aboutit ainsi au schma relationnel reprsent
figure VI.7.
moins quil nen soit spcifi autrement par une contrainte smantique, le modle
relationnel nimpose pas que les cls trangres qui nappartiennent pas une cl pri-
maire soient non nulles. Cela peut permettre une certaine souplesse, par exemple
denregistrer des employs qui ne sont attachs aucun service.
entier, rel, chane de caractres, parfois monnaie et date. Afin de spcialiser un type
de donnes pour composer un domaine plus fin (par exemple, le domaine des salaires
mensuels qui sont des rels compris entre 6 000 et 1 000 000 de francs), la notion de
contrainte de domaine est souvent ajoute aux rgles dintgrit structurelle du rela-
tionnel. Cette notion peut tre introduite comme suit :
Lassertion logique est lappartenance une plage de valeurs ou une liste de valeurs.
Par exemple, SALAIRE 5 000 et 1 000 000, COULEUR {BLEU,
BLANC, ROUGE}, etc. Les contraintes permettent de contrler la validit des valeurs
introduites lors des insertions ou mises jour. La non-nullit dune colonne peut aussi
tre considre comme une contrainte de domaine, par exemple DEGRE IS NULL.
4. LALGBRE RELATIONNELLE :
OPRATIONS DE BASE
Lalgbre relationnelle a t invente par E. Codd comme une collection doprations
formelles qui agissent sur des relations et produisent les relations en rsultats
[Codd70]. On peut considrer que lalgbre relationnelle est aux relations ce quest
larithmtique aux entiers. Cette algbre, qui constitue un ensemble doprations l-
mentaires associes au modle relationnel, est sans doute une des forces essentielles
du modle. Codd a initialement introduit huit oprations, dont certaines peuvent tre
composes partir dautres. Dans cette section, nous allons introduire six oprations
qui permettent de dduire les autres et qui sont appeles ici oprations de base. Nous
introduirons ensuite quelques oprations additionnelles qui sont parfois utilises. Des
auteurs ont propos dautres oprations qui peuvent toujours se dduire des oprations
de base [Delobel83, Maier83].
Les oprations de base peuvent tre classes en deux types : les oprations ensem-
blistes traditionnelles (une relation tant un ensemble de tuples, elle peut tre traite
comme telle) et les oprations spcifiques. Les oprations ensemblistes sont des op-
rations binaires, cest--dire qu partir de deux relations elles en construisent une
troisime. Ce sont lunion, la diffrence et le produit cartsien. Les oprations spci-
fiques sont les oprations unaires de projection et restriction qui, partir dune rela-
tion, en construisent une autre, et lopration binaire de jointure. Nous allons dfinir
toutes ces oprations plus prcisment.
190 BASES DE DONNES : OBJET ET RELATIONNEL
Plusieurs notations ont t introduites pour cette opration, selon les auteurs :
RELATION1 RELATION2
UNION (RELATION1, RELATION2)
APPEND (RELATION1, RELATION2)
La notation graphique reprsente figure VI.8 est aussi utilise. titre dexemple,
lunion des relations VINS1 et VINS2 est reprsente figure VI.9.
RSULTAT
RELATION1 RELATION2
Figure VI.8 : Reprsentation graphique de lunion
4.1.2. Diffrence
La diffrence est galement lopration classique de la thorie des ensembles adapte
aux relations de mme schma.
La diffrence est un oprateur non commutatif : lordre des relations oprandes est donc
important. Plusieurs notations ont t introduites pour cette opration, selon les auteurs :
RELATION1 RELATION2
DIFFERENCE (RELATION1, RELATION2)
REMOVE (RELATION1, RELATION2
MINUS (RELATION1, RELATION2)
La notation graphique reprsente figure VI.10 est aussi utilise. titre dexemple, la
diffrence des relations VINS1 VINS2 est reprsente figure VI.11.
RSULTAT
RELATION1 RELATION2
X
RELATION1 RELATION2
4.2.1. Projection
La projection est une opration spcifique aux relations qui permet de supprimer des
attributs dune relation. Son nom provient du fait quelle permet de passer dune rela-
tion n-aire une relation p-aire avec p<n, donc dun espace n dimensions un
espace moins de dimensions.
Les notations suivantes sont utilises pour cette opration, en dsignant par
Attributi, Attributj... Attributm les attributs de projection :
Attributi, Attributj... Attributm (RELATION1)
RELATION1 [Attributi, Attributj... Attributm]
PROJECT (RELATION1, Attributi, Attributj... Attributm)
La notation graphique reprsente figure VI.14 est aussi utilise. Le trapze horizontal
signifie que lon rduit le nombre de colonnes de la relation : partant du nombre
reprsent par la base, on passe au nombre reprsent par lanti-base. La figure VI.15
donne un exemple de projection dune relation VINS comportant aussi lattribut
QUALITE sur les attributs MILLESIME et QUALITE.
RSULTAT
A1, A2 An
RELATION
4.2.2. Restriction
La restriction est aussi une opration spcifique unaire, qui produit une nouvelle rela-
tion en enlevant des tuples la relation oprande selon un critre.
ainsi que la notation graphique reprsente figure VI.16. Le trapze vertical signifie
que lon rduit le nombre de tuples de la relation : partant du nombre reprsent par le
ct gauche, on passe au nombre reprsent par le ct droit. La figure VI.17 repr-
sente la restriction dune relation VINS enrichie dun attribut QUALITE par la condi-
tion QUALITE = BONNE.
RSULTAT
Ai Valeur
RELATION
4.2.3. Jointure
La jointure est une des oprations essentielles de lalgbre relationnelle, sans doute la
plus difficile raliser dans les systmes. La jointure permet de composer deux rela-
tions laide dun critre de jointure. Elle peut tre vue comme une extension du pro-
duit cartsien avec une condition permettant de comparer des attributs. Nous la dfini-
rons comme suit :
La jointure de deux relations produit donc une troisime relation qui contient toutes
les combinaisons de tuples des deux relations initiales satisfaisant la condition spci-
fie. La condition doit bien sr permettre le rapprochement des deux relations, et donc
tre du type :
<Attribut1> <oprateur> <Attribut2>
Lopration de jointure est reprsente par lune des notations suivantes, la condition
tant simplement omise dans le cas de jointure naturelle (cest alors lgalit des attri-
buts de mme nom) :
RELATION1 RELATION2
Condition
JOIN (RELATION1, RELATION2, Condition)
La figure VI.18 donne la reprsentation graphique de lopration de jointure ; la
figure VI.19 illustre cette opration en effectuant la jointure naturelle des deux rela-
tions VINS et LOCALISATION. Linqui-jointure de ces deux relations selon la
condition QUALITE > QUALITE MOYENNE est reprsente figure VI.20. On sup-
pose que les qualits sont codes par ordre dcroissant A, B, C, D, E.
RSULTAT
Ai Bj
RELATION1 RELATION2
La jointure nest pas toujours considre comme une opration de base de lalgbre
relationnelle. En effet, si lon tend la dfinition de la restriction de manire consi-
drer des conditions multi-attributs du type <Attribut1> <Oprateur>
<Attribut2>, alors la jointure peut tre obtenue par un produit cartsien suivi
dune restriction du rsultat comme suit :
JOIN (RELATION1, RELATION2, Condition) =
RESTRICT ((RELATION1 X RELATION2), Condition)
Compte tenu de son jointure, nous avons prfr ici dfinir la jointure comme une
opration de base.
5. LALGBRE RELATIONNELLE :
OPRATIONS DRIVES
Les oprations prsentes ci-dessous sont parfois utilises pour manipuler des rela-
tions. Elles peuvent en gnral tre obtenues par combinaison des oprations prc-
dentes. Dans certains cas (complment, jointure externe), leur expression partir des
oprations de base ncessite la manipulation de relations constantes tuples prdfi-
nis, telles que la relation obtenue par le produit cartsien des domaines, ou encore
celle compose dun seul tuple valeurs toutes nulles.
5.1. INTERSECTION
Lintersection est lopration classique de la thorie des ensembles adapte aux rela-
tions de mme schma.
Plusieurs notations ont t introduites pour cette opration selon les auteurs :
RELATION1 RELATION2
INTERSECT (RELATION1, RELATION2)
AND (RELATION1, RELATION2)
La notation graphique reprsente figure VI.21 est aussi utilise.
Le modle relationnel 199
RSULTAT
RELATION1 RELATION2
Lintersection est une opration redondante avec les oprations de base, puisquil est
possible de lobtenir partir de la diffrence laide dune des formules suivantes :
RELATION1 RELATION2 = RELATION1 (RELATION1 RELA-
TION2)
RELATION1 RELATION2 = RELATION2 (RELATION2 RELA-
TION1)
5.2. DIVISION
La division permet de rechercher dans une relation les sous-tuples qui sont complts
par tous ceux dune autre relation. Elle permet ainsi dlaborer la rponse des ques-
tions de la forme quel que soit x, trouver y de manire simple.
De manire plus formelle, dsignons par ai une valeur quelconque de lattribut Ai. Un
tuple est alors une suite de valeurs <a1, a2, a3...>. Utilisant ces notations, le quotient
de D par D est dfini par :
Q = {<a1, a2... ap> tel-que quel-que-soit <ap+1... an> de d,
<a1, a2... ap, ap+1..., an> appartient D}
RSULTAT
RELATION1 RELATION2
JULIENAS 1986 A
CRU Cru
CHABLIS
5.3. COMPLMENT
Le complment permet de trouver les tuples qui nappartiennent pas une relation. Il
suppose a priori que les domaines sont finis (sinon on obtient des relations infinies).
Le modle relationnel 201
Domaines :
CRU = { Chablis, Volnay, Mdoc}
COULEUR = {Rouge, Ros, Blanc}
5.4. CLATEMENT
Lclatement [Fagin80] est une opration qui nappartient pas vraiment lalgbre
rationnelle puisquelle donne deux relations en rsultats, partir dune. Elle est cepen-
202 BASES DE DONNES : OBJET ET RELATIONNEL
Cette opration est trs utile, en particulier pour composer des vues sans perte dinfor-
mations. Elle se note en gnral comme suit :
RELATION1 RELATION2
EXT-JOIN (RELATION1, RELATION2)
La jointure externe permet par exemple de joindre des tables CLIENTS et COM-
MANDES sur un numro de client commun, en gardant les clients sans commande et
les commandes sans client associ. Elle est donc trs utile en pratique. On peut aussi
distinguer la jointure externe droite qui garde seulement les tuples sans correspondant
de la relation de droite. On notera celle-ci ou REXT-JOIN. De mme, on peut
distinguer la jointure externe gauche ( ou LEXT-JOIN). Un exemple de jointure
externe complte apparat figure VI.25.
Le modle relationnel 203
5.6. SEMI-JOINTURE
Dans certains cas, lors de lexcution dune jointure, il nest pas ncessaire de conser-
ver tous les attributs des deux relations en rsultat : seuls les attributs dune des deux
relations sont conservs. Une opration spcifique de semi-jointure, trs utile pour
optimiser lvaluation des questions, a t dfinie [Berstein81].
Pour effectuer une fermeture transitive, il est ncessaire deffectuer une boucle dop-
rations jusqu obtention de la fermeture complte. On doit donc utiliser un langage
de programmation avec une boucle while, comme suit :
(R) = while (R) change do (R)
= (R) A1,A4 (R (R)).
Cette opration permet par exemple de calculer partir dune relation PARENTS
(Parent, Enfant) la relation ANCETRES (Ascendant, Descendant),
qui donne toute la filiation connue dune personne. La figure VI.27 illustre cette op-
ration. La fermeture transitive de PARENTS est calcule par
jointures/projections/unions successives de la relation PARENTS avec elle-mme
jusqu saturation, cest--dire jusqu obtention dune relation stable laquelle une
nouvelle jointure/projection/union napporte plus de tuples. On voit que la relation
ANCETRES reprsente le graphe correspondant la fermeture transitive du graphe de
la relation PARENTS.
Paul
Yves
Jean
Graphe
de la relation PARENTS
Nous avons tudi plus prcisment la logique du premier ordre et les langages
dinterrogation qui en dcoulent au chapitre V. Disons simplement que lalgbre rela-
tionnelle permet dexprimer toute question exprimable avec la logique du premier
ordre sans fonction, par exemple avec le calcul de tuple ou de domaine. Lalgbre
relationnelle peut dailleurs tre tendue avec des fonctions [Zaniolo85].
Voici quelques questions sur la base DEGUSTATION dont le schma a t reprsent
figure VI.7. Elles peuvent tre exprimes comme des expressions doprations, ou
comme des oprations successives appliques sur des relations intermdiaires ou de
base, gnrant des relations intermdiaires. Pour des raisons de clart, nous avons
choisi cette deuxime reprsentation. Lexpression peut tre obtenue simplement en
supprimant les relations intermdiaires notes Ri.
(Q1) Donner les degrs des vins de crus Morgon et de millsime1978 :
R1 = RESTRICT (VINS, CRUS = MORGON)
R2 = RESTRICT (VINS, MILLESIME = 1978)
R3 = INTERSECT (R1, R2)
RESULTAT = PROJECT (R3, DEGRE)
Si lon accepte les relations constantes, lalgbre relationnelle permet aussi dexcuter
les mises jour. Par exemple, lintersection du vin [100, TOKAY, 1978, 13] seffec-
tuera comme suit :
R1 = CONSTANTE (VINS, [100, TOKAY, 1978, 13])
VINS = UNION (VINS, R1)
o CONSTANTE permet de dfinir une relation de mme schma que la relation VINS
contenant le seul tuple indiqu en argument.
Ainsi, la question Noms et Prnoms des buveurs habitant Paris ayant bu du Chablis
depuis le 1 er janvier 1992 peut tre exprime laide de larbre reprsent
208 BASES DE DONNES : OBJET ET RELATIONNEL
figure VI.28. Plusieurs arbres quivalents peuvent tre dduits dun arbre donn
laide de rgles de transformation simples, telles que la permutation des jointures et
restrictions, la permutation des projections et des jointures, le regroupement des inter-
sections sur une mme relation, etc. Ces transformations sont la base des techniques
doptimisation de questions qui dpassent le sujet de ce chapitre. La figure VI.29 pro-
pose un arbre quivalent celui de la figure VI.28, obtenu par descente de projections
et regroupement dintersections.
RSULTAT
B.NOM, B. PRNOM
A. DATE 01.01.92
V. CRU = CHABLIS
A.NV = V.NV
ABUS A
BUVEURS B
RSULTAT
B.NOM, B. PRNOM
A.NV = V.NV
B.NOM
B. PRNOM V.NV
A.NV
B.NB
=
V. CRU = CHABLIS
B.NB
B.NOM A.NB
B. PRNOM A.NV
VINS V
BUVEURS B ABUS A
Figure VI.29 : Arbre quivalent larbre prcdent
7. FONCTIONS ET AGRGATS
Lalgbre relationnelle est insuffisante pour traiter de vritables applications des bases de
donnes, telles la suivie de production, la gestion de budget, etc. Il est en effet ncessaire
deffectuer des calculs sur la base pour supporter de telles applications. Cest lobjet de
lintroduction des fonctions de calcul au sein de lalgbre et du support des agrgats.
Les fonctions de calcul sur ensemble les plus souvent proposes sont :
SOMME (SUM) permettant de calculer la somme des lments dun ensemble ;
MOYENNE (AVG) permettant de calculer la moyenne des lments dun ensemble ;
MINIMUM (MIN) permettant de slectionner llment minimum dun ensemble ;
MAXIMUM (MAX) permettant de slectionner llment maximum dun ensemble ;
COMPTE (COUNT) permettant de compter les lments dun ensemble.
La figure VI.30 illustre le concept dagrgat. La table VINS est enrichie dun attribut
QUANTITE. Lagrgat reprsent calcule la somme des quantits par CRU. Lopra-
tion gnrique scrit :
R = AGREGAT(<RELATION> ; <ATTRIBUT1> ; <FONCTION>{<ATTRIBUT2>})
Le modle relationnel 211
pour lagrgat illustr figure VI.30. Notez quun agrgat peut seffectuer sans parti-
tionnement ; on peut par exemple calculer simplement la moyenne de tous les degrs
comme indiqu figure VI.30 par la commande :
RESULTAT = AGREGAT(VINS ; ; AVG{DEGRE}).
AGREGAT(VINS;; AVG{DEGRE})
8. CONCLUSION
Dans ce chapitre, nous avons introduits les concepts essentiels aujourdhui supports
par le modle relationnel dans les grands systmes industriels tels que ORACLE,
INGRES, DB2, SYBASE, etc. Ces concepts constituent la base du langage SQL, le
langage des systmes relationnels. Nous allons tudier ce langage et ses extensions
dans les chapitres qui suivent.
Le modle relationnel fait aujourdhui autorit dans lindustrie. Issu de la thorie des rela-
tions, il est lorigine une remarquable construction de la recherche. Il a su progressive-
212 BASES DE DONNES : OBJET ET RELATIONNEL
ment intgrer des concepts de plus en plus riches, tels que lintgrit rfrentielle, les
rgles actives, etc. Le modle a aujourdhui intgr les concepts de lobjet pour fonder
lobjet-relationnel, comme nous le verrons dans la troisime partie de cet ouvrage. Il a
encore un bel avenir devant lui, bien quil soit parfois contest par les tenants de lobjet.
9. BIBLIOGRAPHIE
[Berstein81] Bernstein P., Goodman N., The Power of Natural Semijoins , Siam
Journal of Computing, vol. 10, n 4, dcembre 1981, p. 751-771.
Une discussion de la puissance de loprateur de semi-jointure. Aprs une dfi-
nition de la semi-jointure, Phil Bernstein et Nathan Goodman montrent que cet
oprateur permet dexprimer un grand nombre de questions avec jointures,
plus spcifiquement toutes celles dont le graphe des jointures est un arbre.
[Chen76] Chen P.P., The Entity-Relationship Model Towards a Unified View of
Data , ACM Transactions on Database Systems, vol. 1, n 1, mars 1976.
Larticle de base sur le modle entit-association. Il introduit ce modle pour
dcrire la vue des donnes dune entreprise. En particulier, les diagrammes de
Chen sont prsents. Il est montr que le modle permet dunifier les diffrents
points de vue et de passer simplement une implmentation relationnelle. Ce
dernier point explique le fait que beaucoup doutils daide la conception de
bases de donnes relationnelles utilisent une variante du modle de Chen.
[Childs68] Childs D.L., Feasibility of a Set-Theoretic Data Structure A General
Structure Based on a Reconstituted Definition of a Relation , Congrs IFIP,
Genve, 1968, p. 162-172.
Un des premiers articles proposant un modle bas sur le concept de relation et
des oprateurs ensemblistes. La proposition de Codd sest inspire des travaux
de Childs.
[Codd70] Codd E.F., A Relational Model for Large Shared Data Banks ,
Communications de lACM, vol. 13, n 6, juin 1970, p. 377-387.
Larticle de base proposant le modle relationnel. Il introduit les concepts
essentiels de relation, domaine, attribut et cl. Lalgbre relationnelle est pro-
pose comme langage de manipulation des relations.
[Codd79] Codd E.F., Extending the Relational Model to Capture More Meaning ,
ACM TODS, vol. 4, n 4, dcembre 1979, p. 397-433.
Une proposition dextension du modle relationnel pour mieux dcrire la
smantique des applications. Lide de base est de distinguer diffrents types de
Le modle relationnel 213
LE LANGAGE SQL2
1. INTRODUCTION
Les serveurs de donnes relationnels prsentent aujourdhui une interface externe sous
forme dun langage de recherche et mise jour, permettant de spcifier les ensembles
de donnes slectionner ou mettre jour partir de proprits des valeurs, sans
dire comment retrouver les donnes. Ainsi, les oprations directement utilisables par
les usagers sont en gnral celles des langages dits assertionnels. Plusieurs langages
assertionnels permettant de manipuler des bases de donnes relationnelles ont t pro-
poss, en particulier QUEL [Zook77], QBE [Zloof77] et SQL [IBM82, IBM87].
Aujourdhui, le langage SQL est normalis [ISO89, ISO92] et constitue le standard
daccs aux bases de donnes relationnelles. Les autres interfaces par menus, fentres,
grilles, etc., ou de programmation type langage de 3e ou 4e gnration, sont le plus
souvent offertes au-dessus du langage SQL. Celui-ci constitue donc le point dentre
obligatoire des SGBD relationnels. QUEL tait le langage propos par luniversit de
Berkeley pour son systme INGRES : il est aujourdhui peu utilis dans lindustrie.
QBE est un langage par grille driv de la logique qui est souvent offert au-dessus de
SQL.
De manire gnrale, SQL comme les autres langages qui ont t proposs (e.g.,
QUEL) utilisent tous des critres de recherche (encore appels qualifications)
construits partir de la logique des prdicats du premier ordre. Ils comportent quatre
oprations de base :
218 BASES DE DONNES : OBJET ET RELATIONNEL
Un nom de table peut tre un nom simple (par exemple VINS) ou un nom compos
dun nom de schma (identifiant dautorisation daccs la base, par exemple
DEGUSTATION) suivi par le nom simple de table en notation pointe (par exemple,
DEGUSTATION.VINS).
Un lment de table est soit une dfinition de colonne, soit une dfinition de
contrainte, comme suit :
<LMENT DE TABLE> ::= <DFINITION DE COLONNE> |
<CONTRAINTE DE TABLE>
Une colonne est dfinie par un nom et un type de donnes. Une valeur par dfaut peut
tre prcise. Une contrainte de colonne peut aussi tre dfinie ce niveau. On obtient
donc la syntaxe suivante :
<DFINITION DE COLONNE> : := <NOM DE COLONNE> <TYPE DE DONNES>
[<CLAUSE DFAUT>] [<CONTRAINTE DE COLONNE>]
Les types de donnes supports sont les chanes de caractres de longueurs fixes
CHAR(<longueur>) , la valeur par dfaut de la longueur tant 1, les numriques
220 BASES DE DONNES : OBJET ET RELATIONNEL
Une vue est modifiable sil est possible dinsrer et de supprimer des tuples dans la
base au-travers de la vue. Dans ce cas, les tuples sont insrs ou supprims dans la
premire table rfrence par la question. La vue doit alors contenir toutes les
colonnes de cette table. Loption WITH CHECK OPTION permet de sassurer que les
tuples insrs vrifient les conditions exprimes dans la question, cest--dire quils
appartiennent bien la vue. Cela permet dimposer des contraintes dintgrit lors des
mises jour au travers de la vue (par exemple, le fait quun tuple de la vue doit rf-
renc un tuple dune autre table).
titre dillustration, voici une vue GROS-BUVEURS dfinie simplement comme la
table virtuelle contenant le nom et le prnom des buveurs de type GROS . Cette
222 BASES DE DONNES : OBJET ET RELATIONNEL
vue nest pas modifiable. Cette dfinition montre dj un premier exemple de ques-
tion SQL trs simple, de type slection.
avec :
<PRIVILGES> ::= ALL PRIVILEGES | <ACTION>+
<ACTION> ::= SELECT | INSERT | UPDATE [(<NOM DE COLONNE>+)]
| REFERENCE [(<NOM DE COLONNE>+)]
<RCEPTEUR> ::= PUBLIC | <IDENTIFIANT DAUTORISATION>
Le langage SQL2 223
Bien que non prvue dans la norme de 1989, la commande REVOKE permet de retirer
un droit un utilisateur. Sa syntaxe est la suivante :
REVOKE <privilges> ON <nom de table> FROM <rcepteur>.
Par exemple, la commande qui suit permet de retirer le droit donn ci-dessus ainsi que
tous les droits qui en dpendent (cest--dire ceux de slection ou mise jour de la
table VINS passs par Poivrot).
REVOKE SELECT, UPDATE ON VINS FROM POIVROT.
Une expression de valeurs est une expression arithmtique (compose avec les opra-
teurs binaires +, , * et /), ventuellement parenthse, de spcifications de constantes
224 BASES DE DONNES : OBJET ET RELATIONNEL
ou de colonnes. Une spcification de constante est soit une constante, une variable de
programme ou le nom de lusager (mot cl USER). Une spcification de colonne
dsigne le nom dune colonne prcd dun dsignateur de relation ventuel (nom de
table ou variable), comme suit :
<SPCIFICATION DE COLONNE> ::= [<DSIGNATEUR>.] <NOM DE COLONNE>
<DSIGNATEUR> ::= <NOM DE TABLE> | <NOM DE VARIABLE>
Lusage dun nom de variable ncessite de dfinir dans la clause FROM une variable
dite de corrlation, permettant de dsigner la table par cette variable. De telles
variables vitent de rpter le nom de la table dans le cas de questions portant sur plu-
sieurs tables, comme nous le verrons ci-dessous. Notez aussi quil est possible dutili-
ser une toile (*) la place de la liste dexpression de valeurs, cela signifiant simple-
ment que lon dsire lister tous les attributs de la table rfrence dans la clause FROM.
Nous illustrons la projection en utilisant la table VINS dont le schma a t dfini ci-
dessus. La premire question (Q1) indique figure VII.4 permet dobtenir pour tous
les vins les crus, millsimes et quantit dalcool pur contenue dans 1 000 litres, avec
doubles ventuels. La deuxime question (Q2) effectue la recherche de tous les tuples
de la table VINS sans double.
Une condition de recherche dfinit un critre, qui appliqu un tuple, est vrai, faux ou
inconnu, selon le rsultat de lapplication doprateurs boolens (ET, OU, NOT)
des conditions lmentaires. Lexpression boolenne de conditions lmentaires peut
tre parenthse. La figure VII.5 donne les tables de vrit permettant de calculer la
valeur de vrit dune condition de recherche. En principe, les seuls tuples satisfaisant
la condition de recherche sont slectionns par la requte.
Le langage SQL2 225
cation Millsime = 1977 et Degr > 13. La question (Q4) dlivre les crus et degrs des
vins de millsime 1977 et de degr compris entre 11 et 13. La question (Q5) retrouve
les crus, annes de production (millsime diminu de 1900) et qualit des Beaujolais.
Elle illustre le prdicat de recherche textuel (LIKE) ; le caractre % signifie dans le
cas du LIKE une quelconque sous-chane de caractres ; par exemple, BEAUJOLAIS
NOUVEAUX et NOUVEAUX BEAUJOLAIS rendent le prdicat CRU LIKE
%BEAUJOLAIS% vrai. La question (Q6) recherche tous les vins de degr nul. La
question (Q7) dlivre les crus des vins de qualit A, B ou C.
(Q3) SELECT *
FROM VINS
WHERE MILLESIME = 1977
AND DEGRE > 13
(Q4) SELECT CRU, DEGRE
FROM VINS
WHERE MILLESIME = 1977
AND DEGRE BETWEEN 11 AND 13
(Q5) SELECT DISTINCT CRU, MILLESIME 1900, QUALITE
FROM VINS
WHERE CRU LIKE
(Q6) SELECT *
FROM VINS
WHERE CRU IS NULL
(Q7) SELECT CRU
FROM VINS
WHERE QUALITE IN (A,B,C)
(Q8) SELECT *
FROM VINS, ABUS
(Q9) SELECT *
FROM VINS, ABUS
WHERE VINS.NV = ABUS.NV
(Q10) SELECT NB, NOM
FROM BUVEURS, VINS
WHERE NOM LIKE CRU
(Q11) SELECT DISTINCT NOM
FROM BUVEURS B, VINS V, ABUS A
WHERE B.NB = A. NB
AND A.NV = V.NV
AND V.CRU = Chablis
3.4. SOUS-QUESTIONS
SQL permet limbrication de sous-questions au niveau de la clause WHERE, si bien
que lon pet crire des questions du type SELECT FROM WHERE SELECT
. En effet, le rsultat dune question peut tre considr comme une valeur simple ou
comme un ensemble de valeurs avec doubles ventuels (multi-ensemble) ; dans ce der-
nier cas, chaque valeur de lensemble correspond un tuple du rsultat. Ainsi, il est
possible de considrer une sous-question comme argument particulier des prdicats de
comparaison (=, , <, >, , ) et dappartenance une liste (IN). Toute sous-question
peut elle-mme invoquer des sous-questions, si bien quil est possible dimbriquer des
blocs SELECT plusieurs niveaux. Limbrication de blocs SELECT par le prdicat IN
permet dexprimer en particulier des jointures dune manire plus procdurale.
228 BASES DE DONNES : OBJET ET RELATIONNEL
Par exemple, la question (Q12) de la figure VII.9 effectue la jointure des tables VINS
et ABUS sur numro de vin et slectionne les crus des vins rsultants sans double.
Elle est quivalente la question (Q13). Il est aussi possible dutiliser des variables
dfinies dans un bloc interne au niveau dun bloc externe. On parle alors de variable
de corrlation. La question (Q14) illustre lusage dune variable de corrlation pour
retrouver cette fois le cru du vins mais aussi la quantit bue partir de la jointure de
VINS et ABUS. Finalement, la question (Q15) recherche les noms des buveurs de
Chablis. Elle est quivalente la question (Q11), mais est crite de manire plus pro-
cdurale avec trois blocs imbriqus.
SOME) des rsultats dune sous-question. Un prdicat quantifi par ALL est vrai sil
est vrifi pour tous les lments de lensemble. Un prdicat quantifi par ANY ou
SOME est vrai sil est vrifi par au moins un lment de lensemble.
Ainsi, la question (Q16) recherche les noms des buveurs nayant commis que des abus
en quantit suprieure ou gale toutes les quantits bues, alors que la question (Q17)
recherche ceux ayant commis au moins un abus en quantit suprieure ou gale
toutes les quantits bues. La premire naura probablement pas de rponse alors que la
deuxime ditera le nom de la personne ayant effectu le plus gros abus.
SQL offre une autre possibilit de quantification pour tester si le rsultat dune sous
question est vide ou non. Il sagit du prdicat dexistence EXISTS. EXISTS <sous-
question> est vrai si et seulement si le rsultat de la sous-question est non vide. Ainsi,
la question (Q18) recherche les buveurs ayant bu du Volnay alors que la question
(Q19) recherche ceux nayant bu que du Volnay.
Cette dernire permet de prciser les attributs de partitionnement, alors que les fonc-
tions de calculs appliques aux ensembles gnrs sont directement indiques dans les
expressions de valeurs suivant le SELECT.
Une restriction peut tre applique avant calcul de lagrgat au niveau de la clause
WHERE, mais aussi aprs calcul de lagrgat sur les rsultats de ce dernier. Pour cela,
une clause spciale est ajoute la requte SELECT :
Le langage SQL2 231
Dans le cas o la liste de colonnes nest pas spcifie, tous les attributs de la relation
doivent tre fournis dans lordre de dclaration. Si seulement certaines colonnes sont
spcifies, les autres sont insres avec la valeur nulle.
Une insertion partir dune commande de recherche permet de composer une relation
partir des tuples dune relation existante, par recherche dans la base.
En guise dillustration, la commande dinsertion dun Julinas 1983 de degr inconnu
sous le numro de vins 112 est reprsente figure VII.13 (requte (I1)). Nous donnons
aussi la commande (I2) insrant dans une table BONSBUVEURS tous les buveurs
ayant bu des vins de qualit A. La table BONSBUVEURS de schma (NB, NOM,
PRENOM) a du tre cre auparavant.
Par exemple, la mise jour du degr du Julinas 1983 par la valeur 13 seffectuera par
la requte (U1). Laccroissement des quantits bues de Volnay 1983 de 10% seffec-
tuera par la commande (U2).
Par exemple, la suppression de tous les abus de vins de degr inconnu seffectuera par
la commande (D1), et la suppression de tous les vins bus par MARTIN par la com-
mande (D2).
234 BASES DE DONNES : OBJET ET RELATIONNEL
(D1) DELETE
FROM ABUS
WHERE NV IN
SELECT NV
FROM VINS
WHERE DEGRE IS NULL
(D2) DELETE
FROM VINS
WHERE NV IN
SELECT NV
FROM BUVEURS, ABUS
WHERE ABUS.NB = BUVEURS.NB
AND BUVEURS.NOM = MARTIN
5. SQL1 : LA PROGRAMMATION
DE TRANSACTIONS
Une transaction est une squence doprations, incluant des oprations bases de don-
nes, qui est atomique vis--vis des problmes de concurrence et reprise aprs panne.
Une transaction est gnralement programme dans un langage hte. Dans cette sec-
tion, nous prsentons les commandes de gestion de transactions incluses dans SQL1 et
lintgration de SQL dans un langage de programmation.
Update
Insert Delete
MMOIRE
NANT
BD
MODULE EXEMPLE
DECLARE BONVIN CURSOR
FOR SELECT NV
FROM VINS
WHERE QUALITE = A ;
PROCEDURE OPENVIN ;
OPEN BONVIN ;
PROCEDURE NEXTVIN(NV) NV INTEGER ;
FETCH BONVIN INTO NV ;
PROCEDURE CLOSEVIN ;
CLOSE BONVIN ;
PROGRAM EXEMPLE
REPONSE STRING ;
RECORD TYPE BUVEUR
NB INTEGER ;
NOM STRING ;
PRENOM STRING ;
END RECORD ;
EXEC SQL DECLARE SECTION END EXEC ;
CONS NUMVIN = 100 ;
VAR B BUVEUR ;
VAR QUANTIT INTEGER ;
VAR CODE SQLCODE ;
EXEC SQL END DECLARE SECTION END EXEC ;
EXEC SQL DECLARE CURSOR PARTICIPANT FOR
SELECT NB, NOM, PRENOM
FROM BUVEURS
WHERE ADRESSE LIKE %LYON%
END EXEC ;
BEGIN
EXEC SQL OPEN PARTICIPANT END EXEC ;
WHILE CODE 100 DO
BEGIN
EXEC SQL FETCH PARTICIPANT INTO B END EXEC ;
PRINT NOM :, B.NOM, PRENOM, B.PRENOM ;
PRINT CE BUVEUR A-T-IL PARTICIP ?
READ REPONSE ;
IF REPONSE = O THEN
BEGIN
PRINT QUANTIT ? ;
READ QUANTIT ;
EXEC SQL INSERT INTO ABUS
(B.NB, NUMVIN, 10-08-96, QUANTIT) END EXEC ;
END ;
END ;
EXEC SQL CLOSE PARTICIPANT END EXEC ;
END.
modle relationnel qui supporte des requtes ensemblistes et les langages classiques
qui sont avant tout squentiels. Ces derniers permettent seulement dcrire des pro-
grammes traitant un tuple (record) la fois. Do la ncessit de boucles complexes.
La complexit rsulte aussi de lexistence de deux systmes de dfinition de types dif-
frents, dans notre exemple celui de PASCAL (RECORD TYPE) et celui de SQL
(CREATE TABLE). Do la ncessit de doubles dclarations. Tout ces problmes
sont souvent mieux rsolus au niveau des langages de 4e gnration, qui malheureuse-
ment ne sont pas standardiss.
Avec SQL2, il est possible de renommer des colonnes rsultats. Cette fonctionnalit est
trs utile, par exemple lors du calcul dun agrgat. Avec SQL1, la colonne de la table
rsultat prend souvent un nom dpendant du systme. La clause AS de SQL2 permet de
rsoudre ce problme. Par exemple, une question calculant la moyenne des degrs par
crus pourra maintenant spcifier un nom de colonne rsultat MOYENNE comme suit :
SELECT CRU, AVG(DEGRE) AS MOYENNE
FROM VINS
GROUP BY CRU
Un autre ajout propos SQL1 au niveau de SQL2 entre est la possibilit dutiliser
les mots cls de SQL comme des noms de table, dattributs, etc. Pour ce faire, il suffit
dinclure ces mots cls entre double cotes. Par exemple, on pourra crer une table de
nom SELECT par la commande :
CREATE TABLE SELECT (QUESTION CHAR(100)).
En rsum, les extensions de SQL1 proposes au niveau de SQL2 entre sont donc
des corrections et clarifications ncessaires au langage. SQL2 entre est donc le nou-
veau standard minimal que devrait terme fournir les constructeurs de SGBD. Il per-
mettra une meilleure portabilit des programmes. Linterface avec C est dailleurs
aussi prcise au niveau de SQL2 entre.
SQL2 admet galement la cration de domaines par lutilisateur. Cela permet en parti-
culier lintroduction de types de donnes par lutilisateur au sein du modle avec un
meilleur contrle de lintgrit de domaine ; ces types restent en SQL2 purement des
sous-ensembles des types prdfinis ; aucune opration spcifique ne peut leur tre
associe. Par exemple, la cration dun domaine MONNAIE seffectuera par la com-
mande :
CREATE DOMAINE MONNAIE IS DECIMAL(5,2)
DEFAULT (1)
CHECK (VALUE = 1 OR VALUE > 0)
NOT NULL
Ce domaine pourra tre utilis lors dune cration de table. Il sagit essentiellement
dune macro-dfinition permettant dinclure les contrles dintgrit, par exemple
dans une table FACTURE :
CREATE TABLE FACTURE (NOM CHAR(5), MONTANT MONNAIE)
Le nom de contrainte ALL indique que toutes les contraintes sont concernes.
Diffrents niveaux de contrle de transactions sont aussi possibles. Une clause
SET TRANSACTION <MODE>
est introduite, permettant de prciser le niveau disolation dsir (0 = aucune pour lec-
ture non protge, 1 = criture protge, lecture non protge, 2 = criture et lecture
protges, 3 = criture et lecture exclusives), le mode daccs (lecture seule READ
ONLY, ou lecture-criture READ-WRITE), et le nombre de diagnostics possibles.
Les jointures externes sont utiles pour retenir lors dune jointure les tuples dune table
nayant pas de correspondant dans lautre table, avec des valeurs nulles associes. On
distingue ainsi des jointures externes droite, gauche et complte selon que lon retient
les tuples sans correspondant des deux tables ou seulement dune. Rappelons aussi
quune jointure est dite naturelle si elle porte sur des attributs de mme nom. SQL2
offre la possibilit de spcifier de telles jointures au niveau de la clause FROM, selon
la syntaxe suivante :
FROM <NOM DE TABLE> [NATURAL] [{LEFT | RIGHT}]
JOIN <NOM DE TABLE>
[ON (<SPCIFICATION DE COLONNE>+=<SPCIFICATION DE COLONNE>+)]
242 BASES DE DONNES : OBJET ET RELATIONNEL
On peut par exemple retrouver la somme des quantits bues par chaque buveur, y
compris les buveurs nayant pas bu par la requte suivante :
SELECT NB, NOM, SUM(QUANTITE)
FROM BUVEURS NATURAL LEFT JOIN ABUS
GROUP BY NB
7. CONCLUSION
Le standard SQL2 est adopt depuis 1992 par les organismes de standardisation inter-
nationaux (ISO). Une large extension appele SQL3 est en cours de finition et devrait
tre adopte en 1999. SQL3 intgre les fonctionnalits nouvelles non purement rela-
tionnelles. En particulier, sont traites au niveau de SQL3 les fonctionnalits orientes
objet, le support de questions rcursives et le support de rgles dclenches par des
vnements bases de donnes (en anglais, triggers). Les fonctionnalits orientes
objet sont offertes sous forme de constructeurs de types abstraits de donnes permet-
tant la dfinition dobjets complexes par lutilisateur. Les questions rcursives permet-
tent dintgrer loprateur de fermeture transitive SQL. Une syntaxe est propose
pour dfinir des triggers. Ces fonctionnalits seront tudies dans les chapitres qui
suivent. Plus spcifiquement, SQL3 se veut le langage des SGBD objet-relationnel ;
ce titre, nous ltudierons donc dans la troisime partie de cet ouvrage.
En rsum, SQL est un langage standardis de programmation de bases de donnes.
Bien qu lorigine issu du modle relationnel, SQL est aujourdhui un langage qui
couvre un spectre plus large. Les standards SQL1, SQL2 et SQL3 traitent de
lensemble des aspects des bases de donnes, dont la plupart seront tudis dans la
suite. SQL sert aussi de langage dchange de donnes entre SGBD. Cela explique
donc son trs grand succs, qui se traduit par le fait que tous les SGBD offrent une
244 BASES DE DONNES : OBJET ET RELATIONNEL
variante de SQL. La normalisation du langage assure une bonne portabilit des pro-
grammes bases de donnes. Elle a t possible grce au soutient des grands construc-
teurs, tels IBM, DEC, ORACLE et SYBASE.
Certains critiquent le manque de rigueur et de cohrence de SQL [Date84]. Il est vrai
que lensemble peut paratre parfois htroclite. La syntaxe est souvent lourde. Quoi
quil en soit, SQL est et reste la rfrence. Il est le langage de nombreux systmes
commercialiss tels Oracle, DB2, Sybase, Informix et SQL Server.
8. BIBLIOGRAPHIE
[Boyce75] Boyce R., Chamberlin D.D., King W.F., Hammer M., Specifying Queries
as Relational Expressions , Comm. de lACM, vol. 18, n 11, novembre 1975.
Une prsentation du language SQUARE qui permet dexprimer en anglais sim-
plifi des expressions de lalgbre relationnelle. SQUARE est lorigine du
langage SQL.
[Chamberlin76] Chamberlin D.D., Astrahan M.M., Eswaran K.P., Griffiths P., Lorie
R.A, et al., SEQUEL 2 : A Unified Approach to Data Definition,
Manipulation and Control , IBM Journal of Research and Development,
vol. 20, n 6, novembre 1976.
Cet article dcrit la deuxime version du langage SEQUEL, le langage du
fameux systme R, le premier SGBD relationnel prototyp IBM San-Jos de
1974 1980. Pendant cette priode, luniversit de Berkeley ralisait INGRES.
SEQUEL 2 tend SEQUEL 1 avec des constructions drives de QUEL le
langage de INGRES et permet de paraphraser en anglais les expressions de
lalgbre. Il introduit aussi les commandes de description et contrle de don-
nes et constitue en cela un langage unifi. Cest en tout cas un langage assez
proche de SQL1.
[Date84] Date C.J., A Critique of the SQL Database Language , ACM SIGMOD
Record, vol. 14, n 3, novembre 1984.
Chris Date, qui vient de quitter IBM en cette fin de 1984, critique la cohrence
du langage SQL et dmontre quelques insuffisances.
[Date89] Date C.J., A Guide to the SQL Standard, 2e dition, Addison-Wesley,
Reading, Mass., 1989.
Une prsentation didactique du standard SQL, avec beaucoup dexemples.
[IBM82] IBM Corporation, SQL/Data System Terminal Users Guide , IBM Form
Number SH24-5017-1, 1982.
Le langage SQL2 245
Cet article fait le point sur les efforts de standardisation de SQL. Il rsume les
dveloppements passs en matire de standardisation des bases de donnes et
introduit les propositions SQL2 et SQL3. Les niveaux de SQL2 sont particuli-
rement dvelopps et illustrs par des exemples. Phil Shaw tait cette poque
le responsable de la normalisation de SQL.
[X/Open92] X/Open Group, Structured Query Language (SQL) Common
Application Environment CAE Specification C201, septembre 1992.
Ce document est une prsentation du langage SQL2 labore par lX/OPEN
Group.
[Zook77] Zook W. et al., INGRES Reference Manual , Dept. of EECS, University
of California, Berkeley, CA, 1977.
Ce document dcrit les interfaces externes de la premire version dINGRES et
plus particulirement le langage QUEL.
[Zloof77] Zloof M., Query-by-Example : A Data Base Language , IBM Systems
Journal, vol. 16, n 4, 1977, p. 324-343.
Cet article prsente QBE, le langage par grille propos par Zloof, alors cher-
cheur IBM. Ce langage bidimensionnel est aujourdhui oprationnel en sur-
couche de DB2 et aussi comme interface externe du systme Paradox de
Borland. Zloof discute aussi des extensions bureautiques possibles, par
exemple pour grer le courrier (OBE).
Chapitre VIII
INTGRIT ET BD ACTIVES
1. INTRODUCTION
Un SGBD doit garantir la cohrence des donnes lors des mises jour de la base. En
effet, les donnes dune base ne sont pas indpendantes, mais obissent des rgles
smantiques appeles contraintes dintgrit. Ces rgles peuvent tre dclares
explicitement et mmorises dans le dictionnaire de donnes, ou plus discrtement
implicites. Les transactions sont des groupes de mises jour dpendantes qui font pas-
ser la base dun tat cohrent un autre tat cohrent. la fin de chaque transaction,
ou plus radicalement aprs chaque mise jour, il est ncessaire de contrler
quaucune rgle dintgrit nest viole.
Une contrainte dintgrit peut spcifier lgalit de deux donnes ; par exemple, un
numro de vins dans la table VINS doit tre gal au numro du mme vin dans la
table ABUS. De manire plus complexe, elle peut spcifier une assertion comportant
de multiples donnes ; par exemple, la somme des avoirs des comptes doit rester gale
lavoir de la banque. Nous tudions ci-dessous les diffrents types de contraintes
supportes par le modle relationnel. Quelle que soit la complexit de la contrainte, le
problme est de rejeter les mises jour qui la violent. Pour ce faire, diffrentes tech-
niques sont possibles, fondes soit sur la prvention qui consiste empcher les mises
jour non valides de se produire, soit sur la dtection impliquant de dfaire les tran-
sactions incorrectes.
248 BASES DE DONNES : OBJET ET RELATIONNEL
Une autre manire de protger lintgrit des donnes est lutilisation de dclen-
cheurs (en anglais, triggers). Ceux-ci permettent de dclencher une opration cons-
quente suite une premire opration sur la base. La forme gnrale dun dclencheur
est ON <vnement> IF <condition> THEN <action>. Lvnement est
souvent une action de mise jour de la base. La condition est un prdicat logique vrai
ou faux. Laction peut permettre dinterdire la mise jour (ABORT) ou de la compen-
ser (UPDATE). Ainsi, en surveillant les mises jour et en dclenchant des effets de
bord, il est possible de maintenir lintgrit dune base.
Mieux, les dclencheurs permettent de modliser au sein de la base de donnes le
comportement ractif des applications. Les SGBD traditionnels sont passifs, en ce
sens quils excutent des commandes de mises jour et de recherche en provenance
des applications. Avec des dclencheurs, ils deviennent actifs et sont capables de
ragir des vnements externes. Par exemple, la surveillance dun commerce lec-
tronique peut ncessiter le refus de vente un client suspect, une demande dapprovi-
sionnement en cas de rupture de stock, etc. Tous ces vnements peuvent tre capturs
directement par le SGBD avec des dclencheurs appropris. On passe alors la notion
de base de donnes actives, qui peut comporter des rgles avec conditions dclen-
ches par des vnements composes de plusieurs sous-vnements (par exemple, une
conjonction dvnements simples). Une base de donnes active permet donc de
dplacer le comportement ractif des applications dans le SGBD. Ceci ncessite la
prise en compte dun modle de dfinition de connaissances et dun modle dexcu-
tion de rgles au sein du SGBD. Nous examinerons ces aspects dans la deuxime par-
tie de ce chapitre.
Ce chapitre traite donc des rgles dintgrit et des bases de donnes actives. Aprs
cette introduction, la section 2 examine les diffrents types de contraintes dintgrit
et rsume le langage de dfinition de contraintes de SQL2. La section 3 introduit
quelques techniques danalyse (contrle de cohrence, de non-redondance) de
contraintes et quelques techniques de simplification : simplifications possibles compte
tenu du type dopration, diffrenciations en considrant les delta-relations, etc. La
section 4 montre comment contrler les contraintes lors des mises jour : diverses
techniques curatives ou prventives sont tudies, pour aboutir la technique prven-
tive au vol souvent applique pour les contraintes simples exprimables en SQL. La
section 5 introduit les notions de base de donnes active et de dclencheur, et analyse
les composants dun SGBD actif. La section 6 tudie plus en dtail les dclencheurs et
donne lessentiel de la syntaxe SQL3, les dclencheurs napparaissant qu ce niveau
dans la norme. La section 7 montre comment sont excuts les dclencheurs dans un
SGBD actif. Au-del de SQL, elle soulve quelques problmes pineux lis aux
dclencheurs.
Intgrit et BD actives 249
4. Contrainte de non nullit. Une telle contrainte spcifie que la valeur dun attribut
doit tre renseigne. Par exemple, le degr dun vin ne pourra tre nul, et devra
donc tre document lors de linsertion dun vin dans la base, ou aprs toute mise
jour.
Le choix des contraintes structurelles est effectu lors de la dfinition dun modle.
Codd a par exemple retenu la notion de cl compose dattributs visibles lutilisa-
teur pour identifier les tuples dans une table. Ce choix est plutt arbitraire. Le modle
objet a choisi dutiliser des identifiants systme appels identifiants dobjets. Codd
aurait pu retenir les identifiants de tuples invariants (TID) pour identifier les tuples.
On aurait alors un modle relationnel diffrent, mais ceci est une autre histoire. Au
contraire, dans sa premire version, le modle relationnel nintroduisait pas les
contraintes rfrentielles : elles ont t ajoutes en 1981 pour rpondre aux critiques
des tenants du modle rseau, qui trouvaient que le modle relationnel perdait la
smantique des associations [Date81].
SQL2 tend dune part les contraintes attaches une table et permet de dclarer
dautres contraintes par une commande spare CREATE ASSERTION. Lextension
essentielle au niveau du CREATE TABLE porte sur les contraintes rfrentielles. Il
devient possible de rpercuter certaines mises jour de la relation rfrence. La nou-
velle syntaxe est donne figure VIII.3. La clause ON DELETE indique laction que
doit excuter le systme dans la table dpendante lors dune suppression dans la table
matre. NO ACTION ne provoque aucune action, et a donc un effet identique
labsence de la clause comme en SQL1. CASCADE signifie quil faut enlever les
tuples correspondant de la table dpendante. SET DEFAULT indique quil faut rem-
placer la cl trangre des tuples correspondant de la table dpendante par la valeur
par dfaut qui doit tre dclare au niveau de lattribut. SET NULL a un effet iden-
tique, mais cette fois avec la valeur nulle. La clause ON UPDATE indique comment le
systme doit modifier la cl trangre dans la table dpendante lors de la mise jour
dune cl primaire dans la table matre. Les effets sont identiques au ON DELETE,
ceci prs que CASCADE provoque la modification de la cl trangre de la mme
manire que la cl primaire.
Intgrit et BD actives 253
De mme pour la clause ON UPDATE lors dune mise jour de la cl rfrence dans
la table matre.
Celle qui suit vrifie que la quantit totale bue reste infrieure 100 pour chaque
buveur :
CREATE ASSERTION SOMMEQUANTITBUE
BEFORE COMMIT
CHECK (SELECT SUM(QUANTITE) FROM ABUS GROUP BY NB) < 100
FOR ABUS.
En supposant que la table VINS possde un attribut QUALIT, on pourra par exemple
vrifier que chaque vin de qualit suprieure a au moins dix tuples dABUS le rfren-
ant. Une telle contrainte ncessitera dinsrer les ABUS dabord et de reporter la
vrification de contrainte rfrentielle au COMMIT, ce qui peut tre fait par la clause
BEFORE COMMIT.
254 BASES DE DONNES : OBJET ET RELATIONNEL
On peut donc ainsi crire des contraintes trs complexes, difficiles vrifier pour le
systme.
EXEMPLE
CREATE ASSERTION
AFTER INSERT ON VINS CHECK DEGR > 12 ;
Intgrit et BD actives 255
et :
CREATE ASSERTION
AFTER INSERT ON VINS CHECK DEGR < 11 ;
EXEMPLE
CREATE ASSERTION
AFTER INSERT ON VINS CHECK DEGR > 12 ;
et :
CREATE ASSERTION
AFTER INSERT ON VINS CHECK DEGR > 11 ;
sont deux contraintes redondantes, la seconde pouvant tre rduite de la pre-
mire.
L encore, si les contraintes sont exprimables en logique du premier ordre, il est pos-
sible dutiliser une mthode de preuve pour tester leur non-redondance. En cas de
redondance, il nest pas simple de dterminer quelle contrainte liminer. Le problme
est de trouver un ensemble minimal de contraintes vrifier permettant de dmontrer
que toutes les contraintes sont satisfaites. Lensemble retenu doit tre optimal du point
de vue du temps de vrification, ce qui implique lutilisation dune fonction de cot.
De nos jours, aucun SGBD (sauf peut-tre les trop rares SGBD dductifs) nest
capable de vrifier la non-redondance dun ensemble de contraintes, et encore moins
de dterminer un ensemble minimal de contraintes. Cela nest pas trs grave car les
contraintes non structurelles restent peu utilises.
peut tre viole par une suppression sur R. Pour viter des contrles inutiles, il est
important didentifier quel type de mise jour peut violer une contrainte donne. SQL
distingue les oprations dinsertion (INSERT), de suppression (DELETE) et de mise
jour (UPDATE). Il est alors intressant de marquer une contrainte gnrale I avec des
tiquettes (R,U), R indiquant les relations pouvant tre violes et U le type de mise
jour associ. Par exemple, lunicit de cl K sur une relation R sera tiquete
(R,INSERT) et (R,UPDATE).
Des rgles gnrales dtiquetage peuvent tre simplement nonces :
1. Toute contrainte affirmant lexistence dun tuple dans une relation R doit tre ti-
quete (R,DELETE).
2. Toute contrainte vraie pour tous les tuples dune relation R doit tre tiquete
(R,INSERT).
3. Toute contrainte tiquete (R,DELETE) ou (R,INSERT) doit tre tiquete
(R,MODIFY).
Soit par exemple une contrainte rfrentielle de R vers S. Celle-ci affirme que pour
tout tuple de R il doit exister un tuple de S vrifiant R.A = S.K. Un tuple de S doit
exister, do ltiquette (S,DELETE). Tout tuple de R doit vrifier la contrainte, do
ltiquette (R,INSERT). Il faut donc ajouter les tiquettes (S,MODIFY) et
(R,MODIFY). Ces petites manipulations peuvent tre plus formellement dfinies en
utilisant le calcul relationnel de tuples avec quantificateurs que nous verrons dans le
contexte des bases de donnes dductives.
Dbut Transaction
BD
U1
tat transitoire
U2
...
Un
BD
Fin Transaction
EXEMPLE
Considrons une contrainte de domaine telle que DEGRE > 10 et une transac-
tion dinsertion dans la table VINS. Il est clair que seuls les nouveaux vins ins-
rs doivent tre vrifis. Dans ce cas R = . On en dduit que ((R R)
R+) |= I est quivalent (R R+) |= I. La contrainte devant tre
vrifie pour chaque tuple, sa vrification commute avec lunion, et il suffit
donc vrifier que R+ |= I. Ceci est dailleurs vrai lors dune insertion pour
toute contrainte vrifie par chaque tuple.
De manire gnrale, ltablissement de tests diffrentiels est possible pour les diff-
rentes contraintes du modle relationnel tudies ci-dessus dans la section 2. Le
tableau de la figure VIII.6 donne quelques tests diffrentiels valuer pour les opra-
tions dinsertion, de suppression et de diffrence.
258 BASES DE DONNES : OBJET ET RELATIONNEL
Type de contrainte
rer les performances, la dtection recherche en gnral les tuples ne satisfaisant pas la
contrainte.
Ainsi, soit I une contrainte dintgrit mettant en jeu des relations R1, R2...Rn dans
une base de donnes. Une mthode de dtection nave lors dune mise jour consiste
excuter la requte :
SELECT COUNT(*)
FROM R1, R2...Rn
WHERE NOT (I)
Un post-test diffrentiel prendra en compte le fait que la contrainte tait vrifie avant
la modification. Il portera sur les relations diffrentielles R et R+. Par exemple, pour
une contrainte de domaine et une insertion, un post-test possible consistera vrifier
simplement que les tuples insrs satisfont la condition :
(SELECT COUNT(*)
FROM R+
WHERE NOT (I)) = 0.
Pour cela, un test avant mise jour garantissant lintgrit de la base si elle est mise
jour est appliqu. Un tel test est appel un pr-test.
La contrainte dintgrit modifie est (Pour tout VINS : DEGRE+1 < 15),
puisque leffet de la mise jour est de remplacer DEGRE par DEGRE+1.
partir dune contrainte dintgrit modifie I(u(R)), il est possible de gnrer un
pr-test en vrifiant simplement que la requte suivante a une rponse gale 0 :
SELECT COUNT(*)
FROM R
WHERE NOT (I(U(R)).
Ceci permet donc la mise jour si aucun vin na un degr suprieur ou gal 14. En
effet, dans ce cas aucun vin ne pourra avoir un degr suprieur 15 aprs mise jour.
Une mthode de prvention plus connue est la modification de requtes
[Stonebraker75] applique dans INGRES. Elle amliore la mthode prcdente en
intgrant le pr-test la requte de mise jour, ce qui permet de restreindre cette mise
jour aux seuls tuples respectant la contrainte dintgrit aprs mise jour. Bien que
dfinie en QUEL, la mthode est transposable en SQL. Soit la mise jour gnrique :
UPDATE R
SET R = U(R)
WHERE Q.
Soit donc I(R) une contrainte dintgrit sur R et I(u(R)) la contrainte modifie par la
mise jour inverse, comme vu ci-dessus. La mise jour est alors transforme en :
Intgrit et BD actives 261
UPDATE R
SET R = U(R)
WHERE Q AND I(U(R)).
EXEMPLE
Dans le cas des vins de degr infrieur 15, on excutera la mise jour modi-
fie :
UPDATE VINS
SET DEGRE = DEGRE+1
WHERE DEGRE < 14,
ce qui fait que seuls les vins de degr infrieur 14 seront incrments. La
contrainte ne sera pas viole, mais la smantique de la mise jour sera quelque
peu change.
Loptimisation des pr-tests peut tre plus pousse et prendre en compte la smantique
des mises jour. Par exemple, si la mise jour dcrot le degr dun vin, il nest pas
ncessaire dajouter un pr-test pour vrifier que le degr ne dpassera pas 15 ! Plus
gnralement, si la mise jour est intgre un programme, par exemple en C/SQL, il
est possible de bnficier de la smantique du programme pour laborer un pr-test.
Une technique pour laborer des pr-tests en PASCAL/SQL a t propose dans
[Gardarin79]. Lide est dutiliser les axiomes de Hoare dfinissant la smantique de
PASCAL pour pousser les contraintes dintgrit crites en logique du premier ordre
depuis la fin dune transaction vers le dbut, en laissant ainsi au dbut de chaque mise
jour les pr-tests ncessaires.
Dans le cas de contrainte avec agrgats, les pr-tests constituent une des rares
mthodes efficaces de contrle. Lide simple dveloppe dans [Bernstein80] est de
grer dans la mta-base des agrgats redondants. Par exemple, si la moyenne des
salaires dans une relation EMPLOYES doit rester infrieure 20 000 F, on grera cette
moyenne (note MOYENNE) ainsi que le nombre demploys (not COMPTE) dans la
mta-base. Un pr-test simple lors de linsertion dun nouvel employ consistera alors
vrifier que (MOYENNE*COMPTE+NOUVEAU SALAIRE)/(COMPTE+1)
< 2000. De mme, pour une contrainte spcifiant que toute valeur dune colonne A
doit rester infrieure toute valeur dune colonne B, on pourra garder le minimum de
B dans la mta-base. Lors dune mise jour de A, un pr-test efficace consistera sim-
plement vrifier que la nouvelle valeur de A reste infrieure au minimum de B.
Bien que les mises jour ne soient pas effectues lors de lvaluation des pr-tests,
une mthode intermdiaire a t applique dans le systme SABRE lINRIA
[Simon87], base sur des pr-tests diffrentiels. Elle comporte deux tapes :
1. Prparer la mise jour en construisant les relations R+ et R, comme vu ci-dessus.
2. Pour chaque contrainte menace, appliquer un pr-test diffrentiel pour contrler la
validit de la mise jour.
262 BASES DE DONNES : OBJET ET RELATIONNEL
4.3.1. Unicit de cl
Tout SGBD gre en gnral un index sur les cls primaires. Un pr-test simple
consiste vrifier que la nouvelle cl ne figure pas dans lindex. Ce pr-test est effec-
tu lors de linsertion dun tuple ou de la modification dune cl dans la table, en
gnral dailleurs juste avant mise jour de lindex.
3. Suppression dans la table matre. Le pr-test consiste vrifier quil nexiste pas
de tuple contenant la valeur de cl supprimer dans la colonne rfrenante. Si le
pr-test est faux, une complexit importante surgit du fait de la multitude des
actions prvues dans ce cas en SQL2. Il faut en effet soit rejeter la mise jour, soit
modifier voire supprimer les tuples de la table dpendante correspondant cette
valeur de cl. Ceci peut ncessiter dautres contrles dintgrit, source de com-
plexit examine plus loin.
4. Modification de cl dans la table matre. Le pr-test est identique au prcdent
pour la valeur de cl avant modification.
Finalement, sauf pour les suppressions de cl dans la table matre, les vrifications
sont simples. Elles peuvent devenir trs complexes en cas de suppression en cascade
le long de plusieurs contraintes rfrentielles.
etc. Elle est certes un peu complexe, ce qui dmontre finalement la difficult de traiter
efficacement les contraintes exprimables en SQL2.
5.1. OBJECTIFS
La notion de SGBD actif soppose celle de SGBD passif, qui subit sans ragir des
oprations de modification et interrogation de donnes.
Une rgle de production permet dagir sur une base de donnes lorsque la condition
de la rgle est satisfaite : laction est alors excute et change en gnral ltat de la
base. Le systme de contrle choisit quelle rgle appliquer, jusqu saturation dune
condition de terminaison, ou jusquau point de saturation o plus aucune rgle ne peut
modifier ltat de la base : on a alors atteint un point fixe.
Intgrit et BD actives 265
Cette ide, qui est aussi la source des bases de donnes dductives comme nous le
verrons plus tard, a t reprise dans les SGBD relationnels en ajoutant aux rgles un
contrle procdural : chaque rgle sera applique suite un vnement. Les rgles
deviennent alors des dclencheurs ou rgles ECA (vnement Condition
Action).
Lorsque lvnement se produit, la condition est value sur la base. Si elle est vraie,
laction est effectue. Nous prciserons ultrieurement ce quest un vnement, une
condition et une action. Disons pour linstant que lvnement est souvent une modifi-
cation de la base, la condition un prdicat vrai ou faux, et laction un programme de
mise jour. La condition est optionnelle ; sans condition, on obtient un dclencheur
dgnr vnement-action (EA). Il est a remarquer que, dans ce dernier cas, la condi-
tion peut toujours tre teste dans le programme constituant laction, mais celui-ci est
alors dclench plus souvent et inutilement.
Le modle dexcution des dclencheurs est trs variable dans les SGBD, mais il a t
propos une dfinition standard pour SQL [Cochrane96]. Malheureusement, les trig-
gers apparaissent seulement au niveau de SQL3. Dans la suite, nous nous appuierons
sur ce modle, mais il faut savoir que les systmes ne le respectent en gnral gure.
Pour comprendre la smantique des dclencheurs dans un SGBD actif, il faut distin-
guer la prise en compte des vnements, la dtermination des rgles candidates
lexcution, le choix dune rgle si plusieurs sont candidates, lexcution dune rgle
qui comporte lvaluation de la condition puis lexcution de laction.
La faon dont les rgles sont excutes dans les SGBD actifs nest pas standard. La
smantique dune BD active est donc souvent difficile percevoir. Pour cela, un
SGBD actif se doit de rpondre aux questions suivantes :
1. Quand prendre en compte un vnement ? Ce peut tre ds son apparition, ou seule-
ment lorsquune rgle nest pas en cours dexcution ; dans ce dernier cas, il ne sera
pas possible dinterrompre lexcution dune rgle pour en excuter une plus priori-
taire.
2. Quand excuter les rgles ? Ce peut tre ds lapparition de lvnement, ou plus
tard lors dun retour au systme par exemple.
3. Comment choisir une rgle lorsque plusieurs sont candidates lexcution ? Des
mcanismes de priorit simples (par exemple, un niveau de priorit de 1 10) peu-
vent tre mis en uvre.
4. Quelle est la force du lien condition-action ? Autrement dit, doit-on excuter
laction ds que la condition a t value ou peut-on attendre ?
266 BASES DE DONNES : OBJET ET RELATIONNEL
Dfinitions
valuateur
Moteur Analyseur
Excuteur
Moniteur d'vnements
Requtes
Noyau du SGBD
BD active
Dictionnaire
vnement
Externe Interne
6.2. LA CONDITION
La condition est une expression logique de prdicats portant sur les variables de
contexte dexcution de la rgle ou/et sur la base de donnes. Peu de systmes per-
mettent des requtes compltes au niveau de la condition.
Si lon souhaite tester lexistence de tuples, on utilisera les prdicats EXIST et NOT
EXIST, ou le compte de tuples rsultats (COUNT). La condition est en gnral option-
nelle au niveau des dclencheurs : sans condition, on a simplement une rgle vne-
ment-action.
6.3. LACTION
Laction est une procdure excute lorsque la condition est vrifie.
270 BASES DE DONNES : OBJET ET RELATIONNEL
Ce peut tre une seule requte ou une squence de requtes SQL, une procdure stoc-
ke agissant sur la base crite en L4G ou dans un L3G intgrant SQL (C/SQL par
exemple), ou enfin une opration sur transaction (ABORT, COMMIT). Laction peut
utiliser les paramtres du contexte. Elle peut tre excute une seule fois suite lv-
nement ou pour chaque ligne satisfaisant la condition, comme nous le verrons plus en
dtail ci-dessous.
6.4.1. Syntaxe
La figure VIII.9 donne la syntaxe rsume de la requte de cration de dclencheur en
SQL3. La smantique est explicite dans le paragraphe qui suit.
6.4.2. Smantique
Lvnement de dclenchement est une mise jour (UPDATE), une insertion (INSERT)
ou une suppression (DELETE) dans une table. En cas de mise jour, un paramtre
optionnel permet de prciser une liste de colonnes afin de rduire la porte de lvne-
ment. Lvnement nest pas instantan et a un effet. Afin de prciser linstant dactiva-
tion de la rgle, trois options sont disponibles : avant (BEFORE), aprs (AFTER) la
modification, ou la place de (INSTEAD OF). On revient donc l des vnements
instantans. Loption avant est trs utile pour contrler les paramtres et les donnes
dentres avant une modification. Loption aprs permet plutt de dclencher des
traitements applicatifs conscutifs une mise jour. Loption la place de permet de
remplacer un ordre par un autre, par exemple pour des raisons de scurit.
Un ordre optionnel est spcifi pour prciser les priorits lorsque plusieurs dclen-
cheurs sont dfinis sur une mme table. La dclaration REFERENCING NEW AS
<nom> dfinit une variable de nom <nom> contenant la valeur de la dernire ligne
modifie dans la base par lvnement. De mme, REFERENCING OLD AS <nom>
dfinit une variable de nom <nom> contenant la valeur de la mme ligne avant lv-
nement. Des tables diffrentielles contenant les valeurs avant et aprs lvnement
sont dfinies par les options NEW_TABLE et OLD_TABLE. Les dclencheurs sur
INSERT ne peuvent que dclarer les nouvelles valeurs. Les dclencheurs sur
DELETE ne peuvent que dclarer les anciennes.
Chaque dclencheur spcifie en option une action garde par une condition. La condi-
tion est un critre de recherche SQL pouvant porter sur les variables de contexte ou
sur la base via des requtes imbriques. Laction est une procdure contenant une
squence dordre SQL. Condition et action peuvent donc interroger la base de don-
nes et le contexte du dclencheur (par exemple, manipuler les variables et les tables
diffrentielles). Condition et action lisent ou modifient les valeurs de la base avant
mise jour dans un dclencheur avant (BEFORE), aprs mise jour dans un dclen-
cheur aprs (AFTER).
La granularit dun dclencheur est soit ligne (FOR EACH ROW), soit requte (FOR
EACH STATEMENT). Dans le premier cas, il est excut pour chaque ligne modifie
(0 fois si aucune ligne nest modifie), alors que dans le second, il lest une seule fois
pour la requte.
Leffet net est une notion importante aussi pour les transactions qui sont composes de
plusieurs mises jour. Par exemple, une transaction qui insre puis supprime un tuple
a un effet net vide.
Le second problme concerne les risques de bouclage. En effet, il peut exister des
boucles de dclencheurs qui ne sarrtent pas. En effet, une mise jour peut impliquer
une nouvelle mise jour, et ainsi de suite. Le nombre de relations tant fini, la boucle
reviendra forcment plusieurs fois sur une mme relation. Cest un critre simple
dtectable par lanalyseur de dclencheurs. Cependant, ceci limite fortement lusage
des dclencheurs. Par exemple, on ne peut crire un dclencheur qui en cas de baisse
de votre salaire dclenche une autre rgle pour vous donner une prime compensa-
trice ! Une solution plus sophistique consiste dtecter les boucles lexcution en
limitant le nombre de dclencheurs activs lors dune mise jour. Une approche plus
sophistique encore consiste prendre en compte leffet net dun ensemble de dclen-
cheurs successifs et vrifier quil change de manire continue.
276 BASES DE DONNES : OBJET ET RELATIONNEL
8. CONCLUSION
Un systme de rgles supporte au minimum des vnements simples de mise jour.
Cest le cas de SQL3 et des SGBD relationnels du commerce. Il est aussi possible de
considrer les vnements de recherche (SELECT) comme dans Illustra
[Stonebraker90]. Seuls des systmes de recherche grent des vnements composs,
avec OU, ET, squences et intervalles de temps. On citera par exemple HIPAC
[Dayal88] et SAMOS [Gatziu92].
Le standard SQL3 supporte des conditions et actions excutes avant le traitement
naturel de lopration initiatrice, ou aprs, ou sa place. Il permet aussi de diffrer
lexcution de certains dclencheurs en fin de transaction. Par contre, les dclencheurs
sont excuts pour le compte de la transaction dclenchante. Ils ne peuvent tre
dcoupls. Le dcouplage pose beaucoup de problmes de smantique et a t partiel-
lement explor dans des projets de recherche comme SAMOS.
Intgrit et BD actives 277
Les dclencheurs sont trs utiles dans les SGBD. Ils correspondent cependant une
vision procdurale des rgles. De ce fait, la smantique est souvent obscure. La
conception de bases de donnes actives efficaces reste un problme difficile.
9. BIBLIOGRAPHIE
[Agrawal91] Agrawal R., Cochrane R.J., Linsay B., On Maintaining Priorities in a
Production Rule System , Proc. 17th Int. Conf. on Very Large Data Bases,
Barcelona, Spain, Morgan Kaufman Ed., p. 479-487, Sept. 1991.
Cet article rapporte sur lexprimentation du mcanisme de priorit entre
rgles implment IBM dans le projet Starburst. Il montre lintrt du mca-
nisme.
[Bernstein80] Bernstein P., Blaustein B., Clarke E..M., Fast Maintenance of seman-
tic Integrity Assertions Using Redundant Aggregate Data , Proc. 6th Int. Conf.
on Very Large Data Bases, Montreal, Canada, Morgan Kaufman Ed., Oct.
1991.
Les auteurs furent les premiers proposer la maintenance dagrgats redon-
dants pour faciliter la vrification des contraintes dintgrit lors des mises
jour. Depuis, ces techniques se sont rpandues sous la forme de vues concrtes.
[Ceri90] Ceri S., Widom J., Deriving Production Rules for Constraint
Maintenance , Proc. 16th Intl. Conf. on Very Large Data Bases, Brisbane,
Australia, Morgan Kaufman Ed., p. 566-577, Aug. 1990.
Les auteurs proposent des algorithmes pour gnrer des dclencheurs permet-
tant la vrification automatique de rgles dintgrit lors des mises jour. De
tels algorithmes pourraient tre intgrs un compilateur de dfinitions de
contraintes dintgrit.
[Cochrane96] Cocherane R., Pirahesh H., Mattos N., Integrating triggers and
Declarative Constraints in SQL Database Systems, Proc. 16th Intl. Conf. on
Very Large Data Bases, Brisbane, Australia, Morgan Kaufman Ed., p. 566-577,
Aug. 1990.
Larticle de rfrence pour la smantique des dclencheurs en SQL3. Aprs un
rappel des contraintes dintgrit existant en SQL2, larticle montre comment
on excute les dclencheurs en absence de contraintes, puis les interactions
entre ces deux mcanismes. Il dfinit ensuite une smantique de point fixe pour
les dclencheurs.
278 BASES DE DONNES : OBJET ET RELATIONNEL
[Date81] Date C.J., Referential Integrity , Proc. 7th Intl. Conf. on Very Large Data
Bases, Cannes, France, IEEE Ed., Sept. 1981.
Larticle de base qui a introduit les contraintes rfrentielles. Celles-ci taient
intgres au relationnel pour rpondre aux attaques de perte de smantique du
modle par rapport aux modles type rseau ou entit-association.
[Dayal88] Dayal U., Blaunstein B., Buchmann A., Chakravavarthy S., Hsu M., Ladin
R., McCarthy D., Rosenthal A., Sarin S., Carey M. Livny M., Jauhari J., The
HiPAC Project : Combining Active databases and Timing Constraints , SIG-
MOD Record V 17, n 1, Mars 1988.
Un des premiers projets tudier un systme de dclencheurs avec contraintes
temporelles. Le systme HiPAC fut un prcurseur en matire de dclencheurs.
[Dittrich95] K.R., Gatziu S., Geppert A., The Active Database Management System
Manifesto , Proc. 2nd Int. Workshop on Rules in Databas Systems, Athens,
Greece, Sept. 1995.
Ce manifesto se veut lquivalent pour les bases de donnes actives du mani-
festo des bases de donnes objet. Il dfinit prcisment les fonctionnalits que
doit supporter un SGBD actif.
[Eswaran75] Eswaran K.P., Chamberlin D.D., Functional Specifications of a
Subsystem for Database Integrity , Proc. 1st Intl. Conf. on Very Large Data
Bases, Framingham, Mass., p. 48-67, Sept. 1975.
La description dtaille du premier sous-systme dintgrit ralis. Ce travail
a t effectu dans le cadre du System R IBM.
[Eswaran76] Eswaran K.P., Chamberlin D.D., Specifications, Implementations and
Interactions of a Trigger Subsystem in an Integrated Database System , IBM
Research report RJ 1820, IBM Research Lab., San Jos, California, Aot 76.
La description dtaille du premier sous-systme de dclencheurs ralis. Ce
travail a t effectu dans le cadre du System R IBM.
[Gardarin79] Gardarin G., Melkanoff M., Proving Consistency of Database
Transactions , Proc. 5th Int. Conf. on Very Large Data Bases, Rio de Janeiro,
Brsil, Sept. 1979.
Cet article propose une mthode pour gnrer automatiquement des pr-tests
dans des programmes crits en PASCAL/SQL. La mthode est base sur une
technique de preuve dassertions en utilisant la smantique de Hoare.
[Hammer78] Hammer M., Sarin S., Efficient Monitoring of Database Assertions ,
Proc. ACM SIGMOD Int. Conf. On Management of Data, 1978.
Cet article propose des techniques de simplification de contraintes dintgrit
bases sur ltude logique de ces contraintes.
Intgrit et BD actives 279
[Widom96] Widom J., Ceri S., Active Database Systems: Triggers and Rules for
Advanced Database Processing, Morgan-Kaufmann, San Fransisco, California,
1996.
Ce livre de synthse sur les bases de donnes actives prsente les concepts de
base, diffrents prototypes et de multiples expriences ralises sur le sujet.
Chapitre IX
1. INTRODUCTION
Pourquoi des vues ? Elles permettent de raliser, dans le monde des SGBD relation-
nels, le niveau externe des SGBD selon larchitecture ANSI/SPARC. Rappelons que
le niveau externe propose lutilisateur une perception de la base plus proche de ses
besoins, en termes de structures et de formats de donnes. De manire gnrale, les
vues garantissent une meilleure indpendance logique des programmes par rapport
aux donnes. En effet, le programme restera invariant aux modifications de schma
sil accde la base via une vue qui lisole de celle-ci. Lors des modifications du
schma de la base, ladministrateur modifiera seulement la dfinition des vues, et les
programmes dapplication pourront continuer travailler sans modification. Les vues
ont aussi un rle de scurit : lutilisateur ne peut accder quaux donnes des vues
auxquelles il a droit daccs ; ainsi, les donnes en dehors de la vue sont protges. De
manire dtourne, les vues permettent aussi certains contrles dintgrit lorsquelles
sont utilises pour les mises jour : on dit alors quon effectue une mise jour au tra-
vers dune vue. De telles mises jour sont trs contrles, comme nous le verrons ci-
dessous.
Ces dernires annes, les vues ont trouv de nouvelles applications. Elles permettent
de dfinir des tables virtuelles correspondant aux besoins des programmes dapplica-
tion en termes de donnes. Dans le monde du client-serveur, les vues constituent un
lment essentiel doptimisation de performance. Par exemple, la dfinition dune vue
282 BASES DE DONNES : OBJET ET RELATIONNEL
jointure de deux tables, ou rsultant dun calcul dagrgat, vite au client les risques
de lire les tuples des tables et de faire le calcul de jointure ou dagrgat sur le client :
seules les donnes rsultant du calcul de la vue sont exportes sur le site client. On
laisse ainsi faire au serveur les calculs de jointure, agrgat, etc., quil sait en principe
bien faire. Dans le monde des entrepts de donnes et du dcisionnel, les vues peu-
vent tre concrtises. Elles permettent de raliser par avance des cumuls ou syn-
thses plus sophistiqus de quantits extraites de la base selon plusieurs dimensions.
Des mcanismes de mises jour des vues concrtes lors des mises jour des relations
de base sont alors dvelopps afin dviter le recalcul des cumuls.
Les vues ont donc une importance croissante dans les bases de donnes. En pratique,
ce sont des relations virtuelles dfinies par des questions. Cette dfinition est stocke
dans la mtabase. Les vues sont interroges comme des relations normales.
Idalement, elles devraient pouvoir tre mises jour comme des relations normales.
Les vues concrtes sont calcules sur disques lors de leurs crations. Des mcanismes
de mise jour diffrentiels permettent le report efficace des mises jour des relations
de base. Toutes ces techniques sont aujourdhui bien matrises ; nous allons les pr-
senter ci-dessous.
Afin dillustrer les mcanismes de vues, nous utiliserons tout dabord la base de don-
nes viticole classique compose des relations :
BUVEURS (NB, NOM, PRENOM, ADRESSE, TYPE)
VINS (NV, CRU, REGION, MILLESIME, DEGRE)
ABUS (NV, NB, DATE, QUANTIT).
dcrivant respectivement les buveurs, les vins, et les consommations de vins quoti-
diennes. Comme habituellement, les cls des relations sont soulignes. Des vues
typiques sont les vins de Bordeaux, les gros buveurs, les quantits de vins bues par
crus, etc.
Pour des exemples plus avancs, intgrant notamment des agrgats complexes, nous
utiliserons la base MAGASINS suivante :
VENTES(NUMV, NUMPRO, NUMFOU, DATE, QUANTIT, PRIX)
PRODUITS (NUMPRO, NOM, MARQUE, TYPE,PRIX)
FOURNISSEURS (NUMFOU, NOM, VILLE, RGION, TELEPHONE)
Des vues typiques sont les quantits de produits vendus par fournisseurs et par mois,
les volutions des quantits commandes par rgion, etc. La relation Ventes dcrit les
ventes journalires de produits. NUMPRO est la cl de produits et NUMFOU celle de
fournisseurs. Dans une telle base de donnes, les faits de base sont les ventes, alors
que produits et fournisseurs constituent des dimensions permettant dexplorer les
ventes selon une ville ou une rgion par exemple.
Ce chapitre est organis comme suit. Aprs cette introduction, la section 2 expose
plus formellement le concept de vue, dtaille le langage de dfinition et prsente
quelques exemples simples de vues. La section 3 dveloppe les mcanismes dinterro-
La gestion des vues 283
gation de vues. La section 4 pose le problme de la mise jour des vues et isole les
cas simples tolrs par SQL. La section 5 traite des vues concrtes, notamment en vue
des applications dcisionnelles. En particulier, les techniques de report des mises
jour depuis les relations de base sur des vues concrtes avec agrgats sont tudies. La
conclusion voque quelques autres extensions possibles du mcanisme de gestion des
vues.
Une vue est donc un ensemble de relations dduites dune base de donnes, par com-
position des relations de la base. Le schma de la vue est un schma externe au sens
ANSI/SPARC. Dans la norme SQL, la notion de vue a t rduite une seule relation
dduite. Une vue est donc finalement une table virtuelle calculable par une question.
La syntaxe gnrale de la commande SQL1 de cration de vue est :
CREATE VIEW <NOM DE VUE> [ (LISTE DATTRIBUT)]
AS <QUESTION>
[WITH CHECK OPTION]
Le nom de vue est le nom de la table virtuelle correspondant la vue, la liste des attri-
buts dfinit les colonnes de la table virtuelle, la question permet de calculer les tuples
peuplant la table virtuelle. Les colonnes du SELECT sont appliques sur celles de la
vue. Si les colonnes de la vue ne sont pas spcifies, celle-ci hrite directement des
colonnes du SELECT constituant la question.
La clause WITH CHECK OPTION permet de spcifier que les tuples insrs ou mis
jour via la vue doivent satisfaire aux conditions de la question dfinissant la vue. Ces
conditions seront vrifies aprs la mise jour : le SGBD testera que les tuples insrs
ou modifis figurent bien parmi la rponse la question, donc dans la vue. Ceci
garantit que les tuples insrs ou modifis via la vue lui appartiennent bien. Dans le
cas contraire, la mise jour est rejete si la clause WITH CHECK OPTION est pr-
sente. Par exemple, si la vue possde des attributs dune seule table et la question un
critre de jointure avec une autre table, les tuples insrs dans la table correspondant
284 BASES DE DONNES : OBJET ET RELATIONNEL
la vue devront joindre avec ceux de lautre table. Ceci peut tre utilis pour forcer la
vrification dune contrainte rfrentielle lors dune insertion via une vue. Nous tu-
dierons plus en dtail la justification de cette clause dans la partie traitant des mises
jour au travers de vues.
La suppression dune vue seffectue simplement par la commande :
DROP <NOM DE VUE>.
Cette vue est simplement construite par une restriction suivie dune projection de la
table Vins. Chaque tuple de la vue est driv dun tuple de la table Vins.
(V2) Les gros buveurs :
CREATE VIEW GROSBUVEURS
AS SELECT NB, NOM, PRNOM, ADRESSE
FROM BUVEURS B, ABUS A
WHERE B.NB = A.NB AND A.QUANTIT > 10
WITH CHECK OPTION
Cette vue fait appel une jointure (suivant une contrainte rfrentielle) suivie dun
calcul dagrgat (la somme). Un tuple de la table Vins donne plusieurs tuples lors de
la jointure (autant quil y a dabus) ; ceux-ci sont ensuite regroups selon le cru.
Pour la base MAGASINS, nous dfinirons seulement une vue (V4) documentant la
table VENTES selon les dimensions PRODUITS et FOURNISSEURS, rsultant
de jointures sur cl de ces tables :
CREATE VIEW VENTEDOC (NUMV,NOMPRO,MARQUE,NOMFOU,VILLE,RGION, DATE,
QUANTIT, PRIX) AS
SELECT V.NUMV,P.NOM,P.MARQUE,F.NOM,F.VILLE,F.RGION,V.DATE,
V.QUANTIT, V.PRIX
FROM VENTES V, PRODUITS P, FOURNISSEURS F
WHERE V.NUMPRO=P.NUMRO AND V.NUMFOU=F.NUMFOU
Nous verrons des vues plus complexes, notamment avec des agrgats ci-dessous.
La suppression des vues ci-dessus seffectuera par les commandes :
DROP VINSBORDEAUX.
DROP GROSBUVEURS.
DROP VINBUS.
DROP VENTESDOC.
;
Base Rponse
Vue
R1
F Q
...
Rn
La modification de question est une technique invente dans le projet Ingres Berkeley
[Stonebraker75]. Elle permet de remplacer les vues par leurs dfinitions lors des
recherches ou dajouter des prdicats afin de vrifier des proprits avant dexcuter une
requte. La figure IX.2 illustre cette technique pour la recherche des gros buveurs habi-
tant Versailles. Cette technique peut aussi tre utilise pour les mises jour afin denri-
chir le critre pour vrifier par exemple la non-violation de contraintes dintgrit.
(1) Question
SELECT NOM, PRNOM
FROM GROSBUVEURS
WHERE ADRESSE LIKE VERSAILLES.
(2) Dfinition de vue
CREATE VIEW GROSBUVEURS
AS SELECT NB, NOM, PRNOM, ADRESSE
FROM BUVEURS B, ABUS A
WHERE B.NB = A.NB AND A.QUANTIT > 10.
(3) Question modifie
SELECT NOM, PRNOM
FROM BUVEURS B, ABUS A
WHERE B.ADRESSE LIKE VERSAILLES AND B.NB=A.NB AND A.QUANTIT>10.
Rsultat
B.NOM, B.PRENOM
Question
B.ADRESSE = "Versailles"
Vue Vue
A.NB B.NB
=
Dfinition de vue
ABUS A
De manire plus fine, une vue peut tre mettable jour en insertion, en suppression,
ou en modification. Par exemple, la vue V1 dfinissant les vins de Bordeaux est tota-
lement mettable jour, cest--dire que toute opration INSERT, DELETE ou
UPDATE est reportable sur la base. Ajoutons la vue V2 dfinissant les gros buveurs
la quantit bue (QUANTIT) aprs le SELECT. Ceci pose problme lors dune inser-
tion : comment gnrer le numro de vins (NV) et la date (DATE) de labus qui doit
obligatoirement tre insr puisque NB, NV, DATE est cl de ABUS ? Si lon obligeait
lexistence de labus avant dinsrer le buveur il ny aurait pas de problme. La clause
WITH CHECK OPTION permet justement de vrifier lexistence de tels tuples.
Malheureusement, sa prsence simultane la contrainte rfrentielle ABUS.NB
REFERENCE BUVEURS est impossible ! La suppression et la modification de tuples
existants ne pose pas non plus de problme. La vue V3 est encore plus difficile
mettre jour : il est impossible de dterminer les quantits lmentaires partir de la
somme ! En rsum, lutilisation de certaines vues en mises jour est problmatique.
au critre. La dfinition de vue peut rfrencer dautres tables qui permettent de prci-
ser les tuples de la vue. En thorie, il faut vrifier que les tuples insrs, supprims ou
modifis appartiennent bien la vue. En pratique, SQL neffectue cette vrification
que si elle a t demande lors de la dfinition de vue par la clause WITH CHECK
OPTION.
Restreindre la mise jour des vues monotables est beaucoup trop fort. On peut sim-
plement tendre, au moins en insertion et en suppression, aux vues multitables com-
portant les cls des tables participantes. Les attributs non documents sont alors rem-
placs par des valeurs nulles lors des insertions. Cette solution pratique gnre cepen-
dant des bases de donnes avec de nombreuses valeurs nulles. Elle sera souvent
interdite dans les systmes commercialiss. Ceux-ci sont donc loin de permettre toutes
les mises jour thoriquement possibles, comme le montre la figure IX.4.
Vues thoriquement
Ensemble de toutes
mettables jour Vues mettables jour en SQL
les vues
(la qualification peut invoquer
plusieurs tables)
Vues multitables
avec cls
Vues monotables
avec cls
Figure IX.4 : Classification des vues selon les possibilits de mise jour
Mise jour u
Vue Vue
as Question V as Question V
BD BD
Mise jour rpercute u
5.1. DFINITION
Une vue est en principe une fentre dynamique sur une base de donnes, dont une par-
tie est instancie lors dune question. La concrtisation de la vue par le serveur peut
La gestion des vues 291
tre plus avantageuse si celle-ci est souvent utilise et si les tables sources sont peu
modifies. Ainsi, certains serveurs supportent des vues concrtes.
Une vue concrte est calcule ds sa dfinition et mise jour chaque fois quune tran-
saction modifie la base sous-jacente. La mise jour seffectue si possible en diffren-
tiel, cest--dire que seuls les tuples modifis sont pris en compte pour calculer les
modifications apporter la vue. Mais ceci nest pas toujours possible. Dans le cas de
vues dfinies par des slections, projections et jointures (SPJ), le report diffrentiel
des insertions est simple, celui des mises jour de type suppression ou modification
beaucoup plus difficile. Pour rpercuter suppressions et mises jour, il faut en gnral
retrouver au moins partiellement les chanes de drivation qui ont permis de calcu-
ler les tuples de la vue concrte. Dans le cas gnral (vues avec diffrence, agrgat,
etc.), les reports diffrentiels sont trs difficiles, comme nous le verrons ci-dessous
Les vues concrtes sont dfinissables par une requte du type :
CREATE CONCRETE VIEW <SPCIFICATION DE VUE>.
La vue suivante donne les ventes de produits par fournisseur et par jour :
CREATE CONCRETE VIEW VENTESPFD(NUMPRO,NUMFOU,DATE,COMPTE,QUANTOT)AS
SELECT NUMPRO,NUMFOU,DATE,COUNT(*)AS COMPTE,SUM(QUANTIT) AS QUANTOT
FROM VENTES
GROUP BY NUMPRO, NUMFOU, DATE.
Notez que la vue VENTESPD peut tre drive de la vue VENTESPFD par la dfini-
tion suivante :
CREATE CONCRETE VIEW VENTESPD (NUMPRO, DATE, COMPTE,QUANTOT) AS
SELECT NUMPRO, DATE,SUM(COMPTE)AS COMPTE,SUM(QUANTOT) AS QUANTOT
FROM VENTESPFD
GROUP BY NUMFOU.
Il est aussi possible de driver des vues concrtes avec agrgats par jointures avec les
tables dimensions, par exemple en cumulant les ventes par rgion des fournisseurs :
CREATE CONCRETE VIEW VENTESPRD(NUMPRO,RGION,DATE,COMPTE,QUANTOT) AS
SELECT NUMPRO, DATE,COUNT(*)AS COMPTE,SUM(QUANTIT) AS QUANTOT
FROM VENTES V, FOURNISSEURS F
WHERE V.NUMFOU = F.NUMFOU
GROUP BY V.NUMPRO, F.RGION.
Toutes ces vues concrtes sont trs utiles pour laide la dcision dans un contexte
dentrept de donnes, o lon souhaite analyser les ventes selon diffrentes dimen-
sions [Gray96].
Cette notion est trs importante dans les architectures distribues (client-serveur,
entrepts de donnes, copies), o la vue est matrialise sur un site diffrent de celui
La gestion des vues 293
de la base. Elle est illustre figure IX.6. Il est possible de distinguer lauto-maintena-
bilit en insertion ou en suppression, cest--dire lors des insertions ou suppressions
dans une relation de base. Lauto-maintenabilit peut aussi tre caractrise pour
chaque relation, et enfin gnralise au cas dun groupe de vues [Huyn97].
BD BD
V V
F() F() F()
F(, )
V
BD BD
maintenable savre difficile, et mme trs difficile lorsque la vue contient des agr-
gats [Gupta96]. Ce dernier cas est examin dans le paragraphe qui suit.
Dans le cas dune vue calcule par slections, projections et jointures (SPJ), les pro-
blmes essentiels semblent provenir des jointures. Toute vue comportant toutes les infor-
mations de la base ncessaires son calcul (attributs de projection et de jointure, tuples)
est auto-maintenable en insertion ; en effet, la nouvelle instance de la vue V est :
V = F (R1..., Ri +Ri..., Rn) .
Comme F ne contient pas de diffrence, on a :
V = F (R1..., Ri..., Rn) F (R1..., +Ri..., Rn) = V F (R1..., +Ri..., Rn)
do lon dduit :
V+ = F (R1..., +Ri..., Rn).
Si F (R1..., +Ri..., Rn) est calculable partir de V et +Ri, la vue est auto-mainte-
nable en insertion. Tel est le cas condition que V contienne les attributs et les tuples
de R1...Rn ncessaires son calcul. Les jointures externes seules ne perdent pas de
tuples. Donc, une vue calcule par des jointures externes et projections est gnrale-
ment auto-maintenable en insertion.
Pour lauto-maintenabilit en suppression, le problme est plus difficile encore. On
ne peut distribuer F par rapport Ri Ri, ce qui rend le raisonnement prcdent
caduc. Cependant, toute vue contenant les attributs de R1..., Rn ncessaires son cal-
cul et au moins une cl de chaque relation de base est auto-maintenable. En effet,
lorigine des tuples de la vue peut tre identifie exactement par les cls, ce qui per-
met de reporter les suppressions.
Des structures annexes associes une vue peuvent aussi tre maintenues [Colby96,
Colby97]. Les reports sur la vue concrte peuvent tre diffrs. La vue devient alors
un clich (snapshot) [Adiba80]. Beaucoup de SGBD supportent les clichs.
des agrgats a t tudi dans [Gray96], qui propose de distinguer trois classes de
fonctions : distributives, algbriques, et non rgulires (holistic).
Les fonctions agrgatives distributives peuvent tre calcules en partitionnant leurs
entres en ensembles disjoints, puis en appliquant la fonction chacun, enfin en agr-
geant les rsultats partiels pour obtenir le rsultat final. Une fonction distributive
AGG vrifie donc la proprit :
AGG(v1,v2...vn) = AGG(AGG(v1...vi},AGG(vi+1..vn)).
Parmi les fonctions standard de calcul dagrgats, SUM, MIN et MAX sont distributives.
La fonction COUNT, qui compte le nombre dlments sans liminer les doubles, peut
tre considre comme distributive en linterprtant comme une somme de comptes
partiels gaux 1 pour des singletons ; par contre, COUNT DISTINCT nest pas dis-
tributive car se pose le problme des doubles.
Les fonctions agrgatives algbriques peuvent tre exprimes comme fonctions alg-
briques de fonctions distributives. Par exemple, la moyenne AVG est une fonction
algbrique, car AVG(v1...vn) = SUM(v1...vn) / COUNT(v1...vn).
Pour le problme de la maintenance des vues concrtes, les fonctions algbriques peu-
vent tre remplaces par plusieurs fonctions distributives ; par exemple, une colonne
AVG sera remplace par deux colonnes SUM et COUNT.
Les fonctions non rgulires ne peuvent tre calcules par partitions. Des vues com-
portant de telles fonctions sont a priori non auto-maintenables.
La notion de vue auto-maintenable sapplique tout particulirement aux vues rsultant
dune agrgation dune table de base. On parle alors dagrgats auto-maintenables.
6. CONCLUSION
La gestion de vues en interrogation est un problme bien compris dans les SGBD rela-
tionnels depuis la fin des annes 70. Nous avons introduit ci-dessus ses principes de
base. Le report des mises jour des vues sur la base est un problme plus difficile
encore. Des solutions pratiques et gnrales restent inventer. Lutilisation de dclen-
cheurs sur les vues peut tre une solution pour dfinir les stratgies de report.
La matrialisation des vues a connu une nouvelle activit ces dernires annes, avec
lapparition des entrepts de donnes. Les vues avec agrgats sont particulirement
importantes pour grer des donnes rsumes, en particulier le fameux cube de don-
nes trs utile en dcisionnel. Les techniques sont maintenant connues. Il reste les
mettre en uvre efficacement dans les systmes, qui gre pour linstant peu de redon-
dances et souvent des organisations physiques ad hoc pour le multidimensionnel. Ceci
nest plus vrai dans les entrepts de donnes, qui utilisent souvent les vues concrtes
pour faciliter les calculs dagrgats [Bello98].
Les vues connaissent aussi un nouveau dveloppement dans le monde objet avec lappa-
rition de vues orientes objets au-dessus de bases de donnes relationnelles par exemple.
Nous aborderons cet aspect dans le cadre des SGBD objet ou objet-relationnel.
La gestion des vues 297
7. BIBLIOGRAPHIE
[Abiteboul91] Abiteboul S., Hull R., Vianu V., Foundations of Databases, Addison-
Wesley, 1995.
Comme son nom lindique, ce livre traite des fondements des bases de donnes
relationnelles et objet. Souvent fond sur une approche logique ou algbrique,
il reprend toute la thorie des bases de donnes, y compris le problme de la
mise jour au travers des vues, parfaitement bien analys.
[Adiba80] Adiba M., Lindsay B., Database Snapshots , Intl. Conf. on Very Large
Databases, IEEE Ed., Montral, Canada, Sept. 1980.
Cet article introduit la notion de clich (snapshot) et montre son intrt, notam-
ment dans les bases de donnes rparties. Il dcrit aussi la ralisation effectue
dans le fameux systme R*.
[Adiba81] Adiba M., Derived Relations : A Unified Mechanism for Views,
Snapshots and Distributed Data , Intl. Conf. on Very Large Databases, IEEE
Ed., Cannes, France, Sept. 1981.
Lauteur gnralise les clichs aux relations drives, dont il montre lintrt dans
les bases de donnes rparties. Il discute aussi les algorithmes de mise jour.
[Astrahan76] Astrahan M. M. et al., System R : Relational Approach to Database
Management , ACM TODS, V1, N2, Juin 1976.
Larticle de rfrence sur le fameux System R. Il dcrit aussi le mcanisme de
concatnation darbres implment pour la premire fois dans ce systme.
[Bancilhon81] Bancilhon F., Spyratos N., Update Semantics and Relational
Views , ACM TODS, V4, N6, Dec. 1981, p. 557-575.
Un article de rfrence en matire de mises jour de vues. Les auteurs posent
le problme en termes dinvariance de la vue suite aux mises jour directes ou
rpercutes dans la base. Ils montrent quune condition suffisante de maintena-
bilit est la possibilit de dfinir des stratgies de report complments
constants.
[Bello98] Bello R.G, Dias K., Downing A., Freenan J., Norcott D., Dun H.,
Witkowski A., Ziauddin M., Materialized Views in Oracle , Intl. Conf. on
Very Large Databases, Morgan & Kauffman Ed., New York, USA, Aot 1998,
p. 659-664.
Cet article explique la gestion des vues matrialises dans Oracle 8. Celles-ci
sont utilises pour les entrepts de donnes et la rplication. Elles peuvent tre
rafrachies la fin des transactions, sur demande ou priodiquement. Les
rafrachissements par lots sont optimiss. Loptimisation des requtes prend en
compte les vues concrtes laide dune technique de rcriture base sur un
modle de cot.
298 BASES DE DONNES : OBJET ET RELATIONNEL
OPTIMISATION DE QUESTIONS
1. INTRODUCTION
La plupart des SGBD relationnels offrent aujourdhui des langages de manipulation
bass sur SQL, non procduraux et utilisant des oprateurs ensemblistes. Avec de tels
langages, lutilisateur dfinit les donnes quil veut visualiser sans fournir les algo-
rithmes daccs aux donnes. Le but des algorithmes doptimisation de questions est
justement de dterminer les algorithmes daccs. Ces algorithmes sont aussi utiles
pour les mises jour, car une mise jour est une question suivie dun remplacement.
Plus prcisment, il sagit dlaborer un programme daccs compos doprations de
bas niveau attaches des algorithmes efficaces de recherche dans les tables. Il est
essentiel pour un systme de dterminer des plans daccs optimiss ou au moins
proches de loptimum pour les questions les plus frquentes. Ce nest pas l un pro-
blme facile, comme nous allons le voir dans ce chapitre.
Depuis les annes 1975, loptimisation de requtes dans les bases de donnes relation-
nelles a reu une attention considrable [Jarke84, Kim85, Graefe93]. Les systmes ont
beaucoup progress. Alors que les premiers taient trs lents, capables seulement
dexcuter quelques requtes par seconde sur les bases de donnes du benchmark
TPC/A ou B [Gray91], ils supportent aujourdhui des milliers de transactions par
seconde. Bien sr, cela nest pas d seulement loptimiseur, mais aussi aux progrs
du matriel (les temps dentre-sortie disque restent cependant de lordre de la dizaine
de millisecondes) et des mthodes daccs. Loptimiseur est donc un des composants
302 BASES DE DONNES : OBJET ET RELATIONNEL
Les tables BUVEURS, VINS et PRODUCTEURS correspondent des entits alors que
ABUS et PRODUIT sont des tables reprsentant des associations. La table BUVEURS
dcrit des buveurs caractriss par un numro, un nom et un prnom. La table VINS
contient des vins caractriss par un numro, un cru, un millsime et un degr. Les abus
commis par les buveurs associant un numro de buveur, un numro de vin bu, une date et
une quantit bue, sont enregistrs dans la table ABUS. La table PRODUCTEURS dcrit des
producteurs caractriss par un numro, un nom et une rgion. Lassociation entre un vin
et le producteur qui la produit est mmorise dans la table PRODUIT. On considrera par
exemple la question Quels sont les crus des vins produits par un producteur bordelais en
1976 ayant un degr infrieur ou gal 14 ? . Celle-ci scrit comme suit en SQL :
(Q1) SELECT V.CRU
FROM PRODUCTEURS P, VINS V, PRODUIT R
WHERE V.MILLESIME = 1976 AND V.DEGRE 14
AND P.REGION = BORDELAIS AND P.NP = R.NP
AND R.NV = V.NV.
Pour diversifier un peu les exemples, nous considrerons aussi parfois la base de don-
nes drive du banc dessai (benchmark) TPC-D [TPC95]. Ce banc dessai est centr
sur laide la dcision et comporte donc beaucoup de questions avec des agrgats sur
une base plutt complexe. Cest dans de telles conditions que loptimisation de ques-
tions devient une fonction trs importante. Le schma simplifi de la base est le suivant :
COMMANDES(NUMCO, NUMCLI, ETAT, PRIX, DATE, PRIORIT, RESPONSABLE,
COMMENTAIRE)
LIGNES(NUMCO, NUMLIGNE, NUMPRO, FOURNISSEUR, QUANTIT, PRIX, REMISE,
TAXE, TAT, DATELIVRAISON, MODELIVRAISON, INSTRUCTIONS, COMMENTAIRE)
PRODUITS(NUMPRO, NOM, FABRIQUANT, MARQUE, TYPE, FORME, CONTAINER,
PRIX, COMMENTAIRE)
FOURNISSEURS(NUMFOU, NOM, ADRESSE, NUMPAYS, TELEPHONE, COMMENTAIRE)
PRODFOURN(NUMPRO, NUMFOU, DISPONIBLE, COUTLIVRAISON, COMMENTAIRE)
304 BASES DE DONNES : OBJET ET RELATIONNEL
Cette base dcrit des commandes composes dun numro absolu, dun numro de
client ayant pass la commande, dun tat, dun prix, dune date, dune priorit, dun
nom de responsable et dun commentaire textuel de taille variable. Chaque ligne de
commande est dcrite par un tuple dans la table LIGNES. Celle-ci contient le numro
de la commande rfrence, le numro de la ligne et le numro de produit qui rf-
rence un produit de la table PRODUITS. Les fournisseurs et les clients sont dcrits par
les attributs indiqus dont la signification est vidente, lexception de lattribut
SEGMENT qui prcise le type de client. La table associative PROFOURN relie chaque
fournisseur aux produits quil est capable de fournir ; elle contient pour chaque couple
possible la quantit disponible, le cot de la livraison par unit, et un commentaire
libre. Les tables PAYS et CONTINENTS sont lies entre elles par le numro de conti-
nent ; elles permettent de connatre les pays des fournisseurs et des clients, ainsi que
le continent dappartenance de chaque pays.
La question suivante est une requte dcisionnelle extraite de la vingtaine de requtes du
banc dessai. Elle calcule les recettes ralises par des ventes de fournisseurs des clients
appartenant au mme pays, cest--dire les recettes rsultant de ventes internes un pays,
et ceci pour tous les pays dEurope pendant une anne commenant la date D1.
(Q2) SELECT P.NOM, SUM(L.PRIX * (1-L.REMISE* QUANTIT) AS RECETTE
FROM CLIENTS C, COMMANDES O, LIGNES L, FOURNISSEURS F, PAYS P,
CONTINENTS T
WHERE C.NUMCLI = O.NUMCLI
AND O.NUMCOM = L.NUMCO
AND L.NUMFOU = F.NUMFOU
AND C.NUMPAYS = F.NUMPAYS
AND F.NUMPAYS = P.NUMPAYS
AND P.NUMCONT = T.NUMCONT
AND T.NOM = EUROPE
AND O.DATE $D1
AND O.DATE < $D1 + INTERVAL 1 YEAR
GROUP BY P.NOM
ORDER BY P.NOM, RECETTE DESC ;
Il sagit l dune requte complexe contenant six jointures, trois restrictions dont deux
paramtres par une date ($D1), un agrgat et un tri ! De telles requtes sont courantes
dans les environnements dcisionnels.
les contient. Dautres au contraire sont construites dynamiquement, par exemple sai-
sies une seule fois pour un test ou une recherche ad hoc. Pour loptimiseur, il est
important de distinguer ces diffrents types de requtes. Les premires rptitives sont
appeles requtes statiques, alors que les secondes sont qualifies de requtes dyna-
miques.
Ce deuxime type de requtes, aussi appel requtes ad hoc car correspondant des
requtes souvent saisies en ligne sans une longue rflexion pralable, est excut une
seule fois. On doit donc limiter le temps doptimisation afin de ne pas trop pnaliser
lunique excution de la requte.
tion), ventuellement tendu avec des agrgats et des tris, appel arbre algbrique,
ou arbre relationnel, ou parfois aussi arbre de traitement (processing tree).
Dans larbre algbrique, chaque nud est reprsent par un graphisme particulier,
dj dcrit lors de lintroduction des oprateurs algbriques. Nous rappelons les nota-
tions figure X.1, en introduisant une notation particulire pour les tris (simplement un
rectangle avec le nom des attributs de tri lintrieur) et les agrgats, qui peuvent tre
vus comme un tri suivi dun groupement avec calculs de fonctions pour chaque mono-
tonie. Les agrgats sont ainsi reprsents par un rectangle contenant les attributs de la
clause GROUP BY, suivi dun rectangle contenant les attributs rsultats calculs.
V.NV,
V. CRU = "BEAUJOLAIS" V.CRU, V.MILL
V.CRU
V V V
JOINTURE DIFFRENCE
A. NV V. NV
=
AGRGAT
A V B1 B2
COUNT(*),AVG(DEGRE)
PRODUIT CARTSIEN UNION
V.CRU, V.MILL
V
U
A V B1 B2
Plusieurs arbres reprsentent une mme question, selon lordre choisi pour les opra-
tions. Une mthode de gnration simple dun arbre consiste prendre les prdicats
de qualification dans lordre o ils apparaissent et leur associer lopration relation-
Optimisation de questions 307
nelle correspondante, puis ajouter les agrgats, et enfin une projection finale pour
obtenir le rsultat avec un tri ventuel. Cette mthode permet par exemple de gnrer
larbre reprsent figure X.2 pour la question Q1, puis larbre de la figure X.3 pour la
question Q2.
RECETTE
P.NOM, RECETTE
P.NOM
V.CRU
C.NUMCLI O.NUMCLI and
O.NUMCOM = L.NUMCO
V.MILLESIME = 1976
L.NUMFOU F.NUMFOU
=
V.DEGRE 14
L
P.NP R.NP C
=
P F.NUMPAYS P.NUMPAYS
=
R. NV V. NV
= F
R V P.NUMCONT T.NUMCONT
=
Figure X.2 : Un arbre algbrique pour
la question Q1 sur la base des vins P
$D1 O.DATE T.NOM = "EUROPE"
<$D1+1
O V
partir dun arbre algbrique, il est possible de gnrer un plan dexcution en par-
courant larbre, des feuilles vers la racine. Une opration peut tre excute par
ensembles de tuples ou tuple tuple, ds que ses oprandes sont disponibles. Lexcu-
308 BASES DE DONNES : OBJET ET RELATIONNEL
tion ensembliste consiste attendre la disponibilit des oprandes pour excuter une
opration.
Dans ce mode, si lopration O1 nutilise pas les rsultats de lopration O2, les op-
rations O1 et O2 peuvent tre excutes en parallle. Ce mode dexcution peut tre
intressant pour des algorithmes capables de travailler efficacement sur des ensembles
(bass sur le tri par exemple).
Plus souvent, on cherche dmarrer une opration ds quun tuple est disponible dans
lune des tables arguments. Cest le mode tuple tuple ou pipeline.
Pour les oprations unaires, il suffit quun tuple soit disponible. On peut ainsi excu-
ter deux oprations successives de restriction en pipeline, cest--dire commencer la
deuxime ds quun tuple (ou un groupe de tuples, par exemple une page) a t gn-
re par la premire. Les oprations binaires comme la diffrence peuvent ncessiter
davoir calculer compltement lun des deux oprandes pour commencer. Le mode
pipeline est donc seulement possible sur un des deux oprandes. Ceci peut dpendre
de lalgorithme pour la jointure.
Cette phase comporte un aspect smantique pouvant aller jusqu prendre en compte
des rgles dintgrit, et un aspect syntaxique concernant le choix dune forme cano-
nique. Celle-ci comprend la mise sous forme normale des critres et laffectation dun
ordre fix pour les oprateurs algbriques.
La phase suivante est donc le planning, qui peut remettre en question certains choix
effectus lors de la rcriture.
Alors que la premire phase gnre un arbre logique, la seconde ajoute les annotations
et obtient un plan dexcution. Elle sappuie de prfrence sur un modle de cot. Les
deux phases ne sont pas indpendantes, la premire pouvant influer sur la seconde et
biaiser le choix du meilleur plan. Cependant, on les distingue souvent pour simplifier.
On cherche bien sr optimiser les temps de rponse, cest--dire minimiser le
temps ncessaire lexcution dun arbre. Le problme est donc de gnrer un arbre
optimal et de choisir les meilleurs algorithmes pour excuter chaque oprateur et
larbre dans son ensemble. Pour cela, il faut optimiser simultanment :
le nombre dentres-sorties ;
le paralllisme entre les oprations ;
le temps de calcul ncessaire.
La fonction de cot doit si possible prendre en compte la taille des caches mmoires
disponibles pour lexcution. Loptimisation effectue dpend en particulier de lordre
des oprations apparaissant dans larbre algbrique utilis et des algorithmes retenus.
Il est donc essentiel dtablir des rgles permettant de gnrer, partir dun arbre ini-
tial, tous les plans possibles afin de pouvoir ensuite choisir celui conduisant au cot
minimal. En fait, le nombre darbres tant trs grand, on est amen dfinir des heu-
ristiques pour dterminer un arbre proche de loptimum.
Nous allons maintenant tudier les principales mthodes proposes pour accomplir
tout dabord la rcriture, puis le planning. Leur objectif essentiel est videmment
doptimiser les temps de rponse aux requtes.
310 BASES DE DONNES : OBJET ET RELATIONNEL
3. LOPTIMISATION LOGIQUE
OU RCRITURE
La rcriture permet dobtenir une reprsentation canonique de la requte, sous la
forme dun arbre algbrique dans lequel les oprations sont ordonnes et les critres
mis sous forme normale. Elle peut comporter elle-mme deux tapes : la rcriture
smantique qui transforme la question en prenant en compte les connaissances
smantiques sur les donnes (par exemple, les contraintes dintgrit), et la rcriture
syntaxique qui profite des proprits simples de lalgbre relationnelle pour ordonner
les oprations.
Avec SQL, chaque instance de relation dans la clause FROM correspond un nud.
Les arcs sont valus par la condition quils reprsentent. Ainsi, le graphe de
connexion des relations de la question Q1 est reprsent figure X.4. Notez la difficult
reprsenter des questions avec des disjonctions (ou) de jointures qui peuvent tre
modlises par plusieurs graphes.
Plusieurs variantes dun tel graphe ont t proposes, en particulier le graphe des
jointures [Berstein79] o seules les jointures sont matrialises par un arc entre les
nuds relations. Le nud singulier figurant le rsultat, les arcs reprsentant les pro-
Optimisation de questions 311
jections finales, et les boucles symbolisant les restrictions sont omis. Ce graphe sim-
plifi peut tre utilis pour diverses manipulations smantiques sur les jointures, mais
aussi pour ordonner les jointures ; il est alors coupl un modle de cot.
V.CRU
Rsul V
P.REGION = "BORDELAIS"
R.N
V=
P
P
V.N
.N
P =R
V
P.N
R
Le graphe de connexion des attributs peut tre dfini comme suit [Hevner79].
V.DEGRE 14
=
V.MIL. 1976
=
V.NV R.NV
=
P.NP R.NP
=
P.REGION "BORDELAIS"
La figure X.5 reprsente le graphe de connexion des attributs de la question Q1. Notez
que ce graphe perd la notion de tuple, chaque attribut tant reprsent individuellement.
312 BASES DE DONNES : OBJET ET RELATIONNEL
Il est possible dintroduire des hyper-nuds (cest--dire des groupes de nuds) pour
visualiser les attributs appartenant un mme tuple, comme reprsents figure X.5. Un
tel graphe permet de dcouvrir les critres contenant une contradiction : il possde alors
un cycle qui ne peut tre satisfait par des constantes. Il peut aussi permettre de dcouvrir
des questions quivalentes la question pose par transitivit (voir ci-dessous).
Ainsi, quels que soient les tuples dans la base (obissant videmment aux contraintes
dintgrit), deux questions quivalentes excutes au mme instant donneront le
mme rsultat.
Tout dabord, des questions quivalentes peuvent tre gnres par ltude des pro-
prits de transitivit du graphe de connexion des attributs. Si lon considre ce der-
Optimisation de questions 313
nier, tout couple dattributs (x, y) relis par un chemin x > y dont les arcs sont ti-
quets par des galits doit vrifier x = y. Il est alors possible de gnrer la fermeture
transitive de ce graphe. Tous les sous-graphes ayant mme fermeture transitive gn-
rent des questions quivalentes, bien quexprimes diffremment. Ils correspondent en
effet des contraintes quivalentes sur le contenu de la base. Par exemple, consid-
rons la question Q3 : Noms des buveurs ayant bu un Bordeaux de degr suprieur
ou gal 14 . Elle peut sexprimer comme suit :
(Q3) SELECT B.NOM
FROM BUVEURS B, ABUS A, PRODUIT R, PRODUCTEURS P, VINS V
WHERE B.NB = A.NB AND A.NV = R.NV AND R.NV = V.NV
AND R.NP = P.NP AND P.REGION = BORDELAIS
AND V.DEGRE 14 ;
La diffrence rside dans le choix des jointures, le prdicat R.NV = V.NV tant
remplac par A.NV = V.NV. Dautres expressions sont possibles. Le problme
consiste bien sr choisir celle qui pourra tre value le plus rapidement. Le pro-
blme est plus difficile si lon considre des ingalits, mais il peut tre rsolu en
tendant le graphe de connexion des attributs [Rosenkrantz80].
=
B.NB A.NB
=
A.NV R.NV
= =
V.NV
=
R.NP P.NP
=
B.NB A.NB
=
A.NV R.NV
= =
V.NV
=
R.NP P.NP
R S S R
T R
R S S T
A1,Ap
A1,Ap
Ai,...Aj,
A1, Ap
Ai = a
Ai = a
et
Aj = b
Aj = b
A1,Ap
A1,Ap
Ai = a
Ai = a
Ai,
A1,Ap
6. Quasi-commutativit des restrictions et des jointures (la restriction est applique sur
la relation contenant lattribut restreint)
Ai = a
S(...Bj...)
Ai = a
Ai = a
Ai = a Ai = a
R S R S
A1,Ap
B1,Bq
A1,Ap
B1,Bq
Ai Bj
=
Ai Bj
=
A1,Ap B1,Bp
Ai Bj
R(...Ai...) S(...Bj...)
R(...Ai...) S(...Bj...)
A1,Ap
A1,Ap A1,Ap
R S R S
binaires qui ont tendance accrotre la taille des rsultats par rapport aux relations
arguments. Par exemple, une jointure peut gnrer une trs grande relation. Ceci se
produit lorsque de nombreux tuples de la premire relation se compose de nombreux
de la seconde. la limite, elle peut se comporter comme un produit cartsien si tous
les couples de tuples des deux relations vrifient le critre de jointure.
Aussi, afin de ne considrer que les arbres flux de donnes minimal et de rduire
ainsi le nombre dentres-sorties effectuer, on est conduit descendre les restrictions
et projections. De plus, quand deux projections successives portent sur une mme
relation, il est ncessaire de les regrouper afin dviter un double accs la relation.
De mme pour les restrictions. Ces principes prcdents conduisent lalgorithme
doptimisaton suivant :
1. Sparer les restrictions comportant plusieurs prdicats laide de la rgle 4 appli-
que de la droite vers la gauche.
2. Descendre les restrictions aussi bas que possible laide des rgles 5, 6, et 7.
3. Regrouper les restrictions successives portant sur une mme relation laide de la
rgle 4 applique cette fois de la gauche vers la droite.
4. Descendre les projections aussi bas que possible laide des rgles 8 et 9.
5. Regrouper les projections successives partir de la rgle 3 et liminer dventuelles
projections inutiles qui auraient pu apparatre (projection sur tous les attributs dune
relation).
Pour simplifier les arbres et se rapprocher des oprateurs physiques rellement impl-
ments dans les systmes, une restriction suivie par une projection est note par un
unique oprateur de slection (restriction + projection) ; celui-ci permet dviter
deux passes sur une mme relation pour faire dabord la restriction puis la projection.
Il en est de mme pour une jointure suivie par une projection : on parle alors dopra-
teur de jointure-projection.
titre dillustration, lalgorithme de descente des restrictions et des projections a t
appliqu larbre de la figure X.2. On aboutit larbre reprsent figure X.9. Cet
arbre nest pas forcment optimal pour au moins deux raisons : la descente des restric-
tions et des projections nest quune heuristique et lordre des oprations binaires na
pas t optimis.
V.CRU
V.CRU
P.NP = R.NP
V.MILLESIME = 1976
P.NP R.NP,
V.DEGRE 14 V.CRU
P.REGION = "Bordelais"
P.REGION = "Bordelais"
R. NV V. NV
P =
P.NP = R.NP
R
V.CRU,
P
V. NV
R. NV V. NV
=
V.MILLESIME = 1976 and
R V V.DEGRE 14
Figure X.9 : Optimisation dun arbre par descente des restrictions et des projections
relation en lappliquant sur chacun des tuples de la relation. Cette technique revient
donc au balayage et nous ninsisterons pas dessus. Le dtachement permet par contre
un premier ordonnancement des jointures.
Les questions nayant pas de variables communes, il est possible dexcuter la ques-
tion interne q1, puis la question externe q2.
Une question dans laquelle aucun dtachement nest possible est dite irrductible. On
peut montrer quune question est irrductible lorsque le graphe de connexion des rela-
tions ne peut tre divis en deux classes connexes par limination dun arc [Wong76].
Autrement dit, la semi-jointure de R par S est compose de tuples (ou partie de tuples)
de R qui joignent avec S. On peut aussi voir la semi-jointure comme une gnralisa-
tion de la restriction : cette opration restreint les tuples de R par les valeurs qui appa-
Optimisation de questions 323
raissent dans le (ou les) attribut(s) de jointure de S (par la projection de S sur ce (ou
ces) attributs(s)). La semi-jointure R S est donc une opration qui rduit la taille
de R, tout comme une restriction.
Le dtachement permet de faire apparatre dune part les restrictions, dautre part les
semi-jointures. Ce sont les deux seuls cas de dtachement possibles. Nous allons illus-
trer ces dtachements sur la question Q1 dj vue ci-dessus :
SELECT DISTINCT V.CRU
FROM PRODUCTEURS P, VINS V, PRODUIT R
WHERE V.MILLESIME = 1976 AND V.DEGRE 14
AND P.REGION = BORDELAIS AND P.NP = R.NP
AND R.NV = V.NV.
Le graphe de connexion des relations de cette question est reprsent figure X.4.
Tout dabord, les deux slections :
(q11) SELECT V.NV INTO V1
FROMS VINS V
WHERE V.DEGRE 14 AND V.MILLESIME = 1976
et
(q12) SELECT P.NP INTO P1
FROMS PRODUCTEURS P
WHERE P.REGION = BORDELAIS
peuvent tre dtaches.
En faisant maintenant varier V sur la relation V1 rsultat de Q11 et P sur la relation
P1 rsultat de Q12, il reste excuter la question :
(q1) SELECT DISTINCT V.CRU
FROM P1 P, V1 V, PRODUIT R
WHERE P.NP = R.NP
AND R.NV = V.NV.
Larc du graphe des relations correspondant la jointure P.NP = R.NP peut ensuite
tre enlev, ce qui correspond au dtachement de la sous-question :
(q13) SELECT R.NV INTO R1
FROM P1 P, PRODUIT R
WHERE P.NP = R.NP.
q13 est bien une semi-jointure. Finalement, en faisant varier R sur la relation R1
rsultat de q13, il ne reste plus qu excuter une dernire semi-jointure :
(Q14) SELECT DISTINCT V.CRU
FROM V1 V, R1 R
WHERE V.NV = R.NV
324 BASES DE DONNES : OBJET ET RELATIONNEL
est une question irrductible. Son graphe de connexion des relations prsente en effet
un cycle, comme le montre la figure X.10.
B.NB = A.NB
B A
B.NOM
A.NV=R.NV
Rsultat
P.NOM R.NP=P.NP
P R
tuples satisfont le critre). De plus, aucun index nest peut tre spcifi. En rsum, on
doit donc considrer deux algorithmes diffrents : la slection par balayage squentiel
et par utilisation dindex.
Echec
R O U G
Init
S
Echec
E
E
Succs
Un paramtre important pour la slection sans index est le fait que le fichier soit tri
ou non sur lattribut de restriction. Dans le cas o le fichier nest pas tri, le balayage
squentiel (BS) complet du fichier est ncessaire. Le nombre dentres-sorties nces-
saire est alors le nombre de pages du fichier : Cot(BS) = Page(R).
Optimisation de questions 327
Dans le cas o le fichier est tri sur lattribut test, une recherche dichotomique (RD)
est possible : le bloc mdian du fichier sera dabord lu, puis selon que la valeur cher-
che de lattribut est infrieure ou suprieure celle figurant dans le premier tuple du
bloc, on procdera rcursivement par dichotomie avec la premire ou la seconde par-
tie du fichier. Quoi quil en soit, la recherche sans index est longue et conduit lire
toutes les pages du fichier si celui-ci nest pas tri, ou Log2(Page(R)) pages si le
fichier est tri sur lattribut de slection : Cot(RD) = Log2(Page(R)).
Les index non plaants peuvent parfois tre utiles avec des comparateurs suprieurs
ou infrieurs, mais ceci est plus rare car ils provoquent des accs dsordonns au
fichier. Tout cela montre lintrt dun modle de cot qui permet seul de faire un
choix motiv, comme nous le verrons ci-dessous.
FICHIERS DE VINS
(NV,CRU,QUALITE,DEGRE,MILLESIME) INDEX SECONDAIRE SUR CRU :
Beaujolais 1,5,18
1,Beaujolais, Excellente, 11,1987 Chenas 2,7,14
2, Chenas,Mediocre,12,1990 Julienas 3,6,15,25
3, Julienas, Mediocre,12,1990
5, Beaujolais, Bonne,10,1985
6, Julienas, Mediocre,12,1987
7, Chenas, Excellente,11,1989 INDEX SECONDAIRE SUR DEGRE :
PLAN DACCS
(table VINS critre (CRU = CHENAS) AND (MILLESIME 1986)
AND (DEGRE = 12))
{ C = LIRE (index CRU entre CHENAS)
D = LIRE (index DEGRE entre 12)
L = UNION (C, D)
Pour chaque l de L faire
{ Tuple = LIRE (table VINS adresse l)
if Tuple.MILLESIME 1986 alors
rsultat = UNION (rsultat, Tuple)}
}
}
Le tri de donnes qui ne tiennent pas en mmoire est appel tri externe. Des algo-
rithmes de tri externes ont t proposs bien avant lavnement des bases de donnes
relationnelles [Knuth73]. On distingue les algorithmes par tri-fusion (sort merge) et
les algorithmes distributifs. Les algorithmes par tri-fusion crent des monotonies en
mmoire. Par exemple, si (B+1) pages sont disponibles, des monotonies de B pages
sont cres, sauf la dernire qui comporte en gnral moins de pages. Le nombre de
monotonies cres correspond au nombre de pages de la relation R crer divis par
B en nombre entier, plus la dernire :
Nmon = 1+ ENT(Page(R)/B).
Pour constituer une monotonie, au fur et mesure des lectures denregistrements, un
index tri est cr en mmoire. Lorsque les B pages ont t lues, les enregistrements
sont crits par ordre croissant des cls dans un fichier qui constitue une monotonie. La
constitution de toutes les monotonies ncessite de lire et dcrire la relation, donc
2*Page(R) entres-sorties.
Dans une deuxime phase, les monotonies sont fusionnes. Comme seulement B
pages en mmoire sont disponibles pour lire les monotonies, il faut ventuellement
plusieurs passes pour crer une monotonie unique. Le nombre de passes ncessaires
est LOGB(Nmon). Chaque passe lit et crit toutes les pages de la relation. Do le
nombre total dentres-sorties pour un tri-fusion :
Cot(TF) = 2*Page(R)*(1+LOGB(1+ ENT(Page(R)/B))).
Lorsque Page(R) est grand, un calcul approch donne :
Cot(TF) = 2*Page(R)*(1+LOGB(Page(R)/B))),
On obtient :
Cot(TF) = 2*Page(R)*LOGB(Page(R)).
4.3.1.2. Tri-fusion
Lalgorithme par tri-fusion effectue le tri des deux relations sur lattribut respectif de
jointure. Ensuite, la fusion des tuples ayant mme valeur est effectue. Lalgorithme
est schmatis figure X.14. En supposant des tris de N pages en 2N LOG N comme
ci-dessus, le cot en entres-sorties de lalgorithme est :
Cot(JT) = 2*Page(R1)*LOG(Page(R1)) + 2*Page(R2)*LOG(Page(R2))
+ Page(R1) + Page(R2).
Les logarithmes (LOG) sont base 2 pour des tris binaires, et base B pour des tris
avec (B+1) pages en mmoire cache. Lalgorithme est en gnral beaucoup plus effi-
cace que le prcdent. Son efficacit dpend cependant de la taille mmoire dispo-
nible. Soulignons aussi que si lune des relations est dj trie sur lalgorithme de
jointure, il nest pas ncessaire de refaire le tri.
4.3.1.3. Partition
Il sagit dune mthode par hachage qui peut aisment tre combine avec lune des
prcdentes. Lalgorithme par partition consiste dcouper les deux relations en parti-
tions en appliquant une mme fonction de hachage h sur les attributs de jointure A et
B. Dans la mesure du possible, les partitions gnres sont gardes en mmoire. On
est alors ramen joindre les paquets de mme rang par lun des algorithmes prc-
dents. En effet, pour pouvoir tre joints, deux tuples doivent donner la mme valeur
par la fonction de hachage applique aux attributs de jointure, car ceux-ci doivent tre
gaux.
Lalgorithme peut tre amlior par la gestion dun tableau de bits de dimension N en
mmoire [Babb79] (N aussi grand que possible). Lastuce consiste hacher la pre-
mire relation simultanment avec la fonction h pour crer les partitions et une autre
fonction g distribuant uniformment les valeurs de A sur [1,N]. La fonction g permet
de maintenir un tableau de bits servant de filtre pour la deuxime relation. chaque
tuple hach de R1, le bit g(B) est mis 1 dans le tableau de bits. Lorsquon parti-
tionne la deuxime relation, on effectue pour chaque tuple de R2 un test sur le bit
g(B) du tableau. Sil est 0, on peut liminer ce tuple qui na aucune chance de join-
ture (aucun tuple de R1 ne donne la mme valeur par g). Le principe de lalgorithme
par hachage est reprsent figure X.15 : seuls les paquets de mme rang, donc de la
diagonale sont joints.
332 BASES DE DONNES : OBJET ET RELATIONNEL
R2 g(B)
Tableau de bits
Partition de R2 par h(B)
0
1
0
0
1
R1 g(A) 1
Partition de R1
par h(A) 0
.
.
.
1
Jointure R1.A = R2.B
4.3.1.4. Hachage
Lalgorithme par hachage le plus simple consiste hacher seulement la premire rela-
tion dans un fichier hach si possible gard en mmoire. Ensuite, on balaye la
deuxime relation, et pour chaque tuple lu on tente daccder au fichier hach en tes-
tant lexistence denregistrement de cl identique dans le fichier hach (fonction
PROBE). Tant que lon trouve des enregistrements de cl similaire, on compose la
jointure rsultat. Cet algorithme est schmatis figure X.16.
Une autre possibilit encore plus restrictive est dliminer tous les plans qui neffec-
tuent pas les slections ds que possible. Ces heuristiques liminant souvent des plans
intressants, on prfre aujourdhui mettre en uvre une stratgie dexploration de
lespace des plans plus sophistique pour trouver un plan proche de loptimal, comme
nous le verrons ci-dessous.
Le nombre de plans devient vite trs grand. En effet, considrons simplement le cas
dune requte portant sur n relations et effectuant donc (n-1) jointures. Soit P(n) le
nombre de plans. Si lon ajoute une relation, pour chaque jointure il existe deux posi-
tions possibles pour glisser la nouvelle jointure ( droite ou gauche), et ce de deux
manires possibles (nouvelle relation droite ou gauche) ; pour la jointure au som-
met de larbre, il est aussi possible dajouter la nouvelle jointure au-dessus en posi-
tionnant la nouvelle relation droite ou gauche. Le nombre de jointures de n rela-
tions tant (n-1), il est possible de calculer :
P(n+1) = 4*(n-1) *P(n)+2*P(n) avec P(2) = 1.
Do lon dduit encore :
P(n+1) = 2*(2n-1)*P(n) avec P(2) = 1.
Il sensuit le nombre de plans possibles :
P(n+1) = (2n) ! / n !
Optimisation de questions 337
Un rapide calcul conduit au tableau suivant donnant le nombre de plans possibles P(n)
pour n relations :
n P(n)
2 2
3 12
4 120
5 1680
6 30240
7 665280
8 17297280
9 518918400
10 1,7643E+10
11 6,7044E+11
12 2,8159E+13
On voit ainsi que le nombre de plans devient rapidement trs grand. Ce calcul ne
prend pas en compte le fait que plusieurs algorithmes sont possibles pour chaque op-
rateur de jointure. Si a algorithmes sont disponibles, le nombre de plans pour n rela-
tions doit tre multipli par an-1. Ceci devient rapidement un nombre considrable.
Le calcul du cot dun plan peut tre effectu rcursivement partir de la racine N de
larbre en appliquant la formule suivante, dans laquelle Filsi dsigne les fils du nud
N:
COUT (PT) = COUT(N) + COUT(FILSI).
Le problme est donc de calculer le cot dun nud qui reprsente une opration rela-
tionnelle. La difficult est que lestimation du cot dune opration ncessite, au-del
de lalgorithme appliqu, la connaissance de la taille des relations dentre et de sor-
tie. Il faut donc estimer la taille des rsultats intermdiaires de toutes les oprations de
larbre considr. Le choix du meilleur algorithme pour un oprateur ncessite dautre
part la prise en compte des chemins daccs aux relations (index, placement, lien)
qui change directement ces cots. Nous allons ci-dessous examiner les rsultats
concernant ces deux problmes.
rsultat. Le modle le plus simple est celui qui suppose luniformit de la distribution
des valeurs et lindpendance des attributs [Selinger79]. De telles hypothses sont uti-
lises dans tous les optimiseurs de systmes en labsence dinformations plus prcises
sur la distribution des valeurs dattributs. Un tel modle ncessite de connatre au
minimum :
le nombre de valeurs dun attribut A not Tuple(A);
les valeurs minimale et maximale dun attribut A notes MIN(A) et MAX(A);
le nombre de valeurs distinctes de chaque attribut A not NDIST(A);
le nombre de tuples de chaque relation R not Tuple(R).
Le nombre de tuples dune restriction est alors calcul par la formule :
TUPLE ((R)) = P(CRITERE) * TUPLE(R)
o p(critre) dsigne la probabilit que le critre soit vrifi, appele facteur de slec-
tivit du prdicat de restriction.
Le nombre de tuples dune projection sur un groupe dattributs X est plus simplement
obtenu par la formule :
TUPLE((R)) = (1-d) * TUPLE(R)
Au-del des cots en entres-sorties, il faut aussi estimer les cots de calcul, souvent
ngligs. Dans Systme R [Selinger79], la dtermination du plan dexcution est
effectue en affectant un cot chaque plan candidat calcul par la formule suivante :
COUT = NOMBRE DACCES PAGE + W*NOMBRE DAPPELS INTERNES.
Un optimiseur est ferm lorsque tous les oprateurs et algorithmes daccs, ainsi que
toutes les rgles de permutation de ces oprateurs, sont connus la construction du sys-
tme. Les systmes relationnels purs ont gnralement des optimiseurs ferms. La stra-
tgie de recherche dans les optimiseurs ferms est base sur un algorithme dterministe,
qui construit une solution pas pas soit en appliquant une heuristique ou une mthode
dvaluation progressive permettant dexhiber le meilleur plan, de type programmation
dynamique. Nous tudions dans cette section quelques algorithmes de cette classe.
Algorithme MinSel {
Rels = liste des relations joindre ;
p = plus petite relation ;
Tant que Rels non vide {
R = relation de selectivit minimum de Rels ;
p = join(R,p) ;
Rels = Rels R ;} ;
Retourner(p) ;}
Algorithme DP {
PlanOuverts = liste de tous les plans mono-relation possible ;
Eliminer tous les plans quivalents excepts les moins coteux ;
Tant quil existe p PlanOuverts {
Enlever p de PlanOuverts ;
PlanOptimal = p ;
Pour chaque oprateur o permettant dtendre p {
Etendre le plan p en ajoutant cet oprateur o ;
Calculer le cot du nouveau plan ;
Insrer le nouveau plan dans PlanOuverts ;}
Eliminer tous les plans quivalents excepts les moins coteux ;}
Retourner(PlanOptimal) ;} ;
Stratgie
de recherche
Enumrative Alatoire
Amlioration Recuit
Exhaustive Augmentation Gntique
itrative simul
Toutes ces stratgies sont trs intressantes pour des systmes extensibles, objet ou
objet-relationnel. En effet, dans un tel contexte le nombre de plans dexcution
344 BASES DE DONNES : OBJET ET RELATIONNEL
devient trs grand. Les choix sont donc trs difficiles et les stratgies de type pro-
grammation dynamique deviennent dapplication difficile. Voil pourquoi nous tu-
dierons les stratgies alatoires plus en dtail dans la partie III de cet ouvrage.
7. CONCLUSION
Dans ce chapitre, nous avons tudi les algorithmes et mthodes de base pour lva-
luation efficace des requtes dans les SGBD relationnelles. Ltude a t ralise
partir de requtes exprimes en algbre relationnelle. Pour rduire la complexit, nous
avons dcompos le problme de loptimisation en une phase logique fonde sur les
techniques de rcriture et une phase physique base sur un modle de cot. De nos
jours, la ralisation dun optimiseur performant ncessite dintgrer ces deux phases.
Nous nous sommes plus concentrs sur loptimisation des requtes avec jointures car
celles-ci sont trs frquentes et souvent coteuses dans les bases de donnes relation-
nelles. Nous navons quesquiss loptimisation des agrgats. Nous reviendrons sur ce
problme dans les perspectives pour laide la dcision. Nous navons aussi quesquiss
ltude des stratgies de recherche alatoires, qui permettent de trouver rapidement un
plan satisfaisant dans des espaces de recherche trs vastes. Nous reviendrons sur cet
aspect dans le cadre des optimiseurs extensibles, mis en uvre dans les SGBD objet et
objet-relationnel, au moins en thorie. Dans ce contexte, les plans sont encore plus nom-
breux que dans les SGBD relationnels, et la stratgie devient un composant essentiel.
Les techniques abordes se gnralisent au contexte des bases de donnes rparties et
parallles. Les techniques de base de lapproche multiprocesseurs consistent diviser
pour rgner : les tables sont partitionnes sur plusieurs serveurs parallles ou rpartis,
les requtes sont divises en sous-requtes par lvaluateur de requtes. Le problme
supplmentaire est doptimiser les transferts entre serveurs. Ceux-ci seffectuent par le
biais dune mmoire commune, dun bus partag ou dun rseau, selon le contexte. Le
modle de cot doit prendre en compte ces transferts, et les algorithmes doivent tre
adapts. Les fondements restent cependant identiques ceux prsents dans ce chapitre.
8. BIBLIOGRAPHIE
[Aho79] Aho A.V., Sagiv Y., Ullman J.D., Equivalences among Relational
Expressions , SIAM Journal of Computing, vol. 8, n 2, p. 218-246, Juin 1979.
Optimisation de questions 345
[DeWitt86] DeWitt D., Gerber R., Graefe G., Heytens M., Kumar K., Mualikrishna
M., Gamma A high performance Dataflow Database Machine , Proc.
12th Intl. Conf. on Very Large Data Bases, Kyoto, Japan, Morgan Kaufman Ed.,
Septembre 1986.
La machine GAMMA ralise lUniversit de Madison explore les techniques
de flot de donnes pour parallliser les oprateurs de jointure. Les algorithmes
de type pipeline ont t expriments pour la premire fois sur un rseau local
en boucle.
[DeWitt92] DeWitt D., Naughton J., Schneider D., Seshadri S., Practical Skew
Handling in Parallel Joins Proc. 18th Intl. Conf. on Very Large Data Bases,
Sydney, Australia, Morgan Kaufman Ed., Septembre 1992.
Cet article tudie les effets des distributions biaises de valeurs dattributs de
jointure sur les algorithmes de jointure. Les algorithmes hybrides semblent les
plus rsistants.
[Finance94] Finance B., Gardarin G., A Rule-based Query Optimizer with
Adaptable Search Strategies , Data and Knowledge Engineering, North-
Holland Ed., vol. 3, n 2, 1994.
Les auteurs dcrivent loptimiseur extensible ralis dans le cadre du projet
Esprit EDS. Cet optimiseur est extensible grce un langage de rgles puissant
et dispose de diffrentes stratgies de recherche paramtrables.
[Fushimi86] Fushimi S., Kitsuregawa M., Tanaka H., An Overview of the System
Software of a Parallel Relational Database Machine : GRACE , Proc. 12th Int.
Conf. on Very Large Data Bases, Kyoto, Japan, Morgan Kaufman Ed.,
Septembre 1986.
Les auteurs prsentent la machine bases de donnes GRACE. Celle-ci se dis-
tingue par son algorithme de jointure parallle bas sur une approche mixte,
combinant hachage et tri.
[Gardarin84] Gardarin G., Jean-Nol M., Kerherv B., Mermet D., Pasquer F., Simon
E., Sabrina : un Systme de Gestion de Bases de Donnes Relationnelles issu
de la Recherche , Revue TSI, Dunod AFCET Ed., vol. 5, n 6, 1986.
Cet article dcrit le SGBD SABRE ralis lINRIA de 1980 1984, puis
industrialis et commercialis par la socit INFOSYS de 1984 1990. Ce
SGBD disposait dun optimiseur bas sur des heuristiques sophistiques.
[Graefe93] Graefe G., Query Evaluation Techniques for Large Databases , ACM
Computer Surveys, vol. 25, n 2, p. 73-170, Juin 1993.
Un des plus rcents articles de synthse sur loptimisation de requtes.
Lauteur prsente une vue densemble des techniques doptimisation de
requtes, en mettant en avant leur comportement vis--vis de grandes bases de
donnes.
Optimisation de questions 347
[Gray91] Gray J., The Benchmark Handbook for Database and Transaction
Processing Systems, 2nd edition, Morgan Kaufman, San Mateo, CA, 1991.
Le livre de rfrence du Transaction Processing Council (TPC). Il prsente les
benchmarks de base, notamment TPC/A, TPC/B, TPC/C, et les conditions
prcises dexcution de ces bancs dessais.
[Haas89] Haas M.L., Freytag J.C., Lohman G.M., Pirahesh H., Extensible Query
Processing in Starbust , Proc. ACM SIGMOD Intl. Conf. On Management of
Data, p. 377-388, 1989.
Cet article prsente loptimiseur de Starbust, un systme extensible ralis
IBM. Cet optimiseur se dcompose clairement en deux phases, la rcriture et
le planning. Il est la base des nouvelles versions de loptimiseur de DB2.
[Hevner79] Hevner A.R., Yao B., Query Processing in Distributed Database
Systems , IEEE Transactions on Software Engineering, vol. 5, n 3, p. 177-
187, Mai 1979.
Cet article prsente une synthse des techniques doptimisation de requtes
connues cette date dans les BD rparties. Il dveloppe un modle de cot
incluant le trafic rseau.
[Jarke84] Jarke M., Koch J., Query Optimization in Database Systems ACM
Computing Surveys, vol. 16, n 2, p. 111-152, Juin 1984.
Un des premiers articles de synthse sur loptimisation de requtes dans les
bases de donnes relationnelles. Larticle suppose les questions exprimes en
calcul relationnel de tuples. Il donne un cadre gnral pour lvaluation de
requtes et couvre les algorithmes de rcriture logique, les mthodes doptimi-
sation physique, les modles de cot, et plus gnralement les principales tech-
niques connues cette poque.
[Kim85] Kim Won, Reiner S., Batory D., Query Processing in Database Systems,
Springer-Verlag Ed., 1985.
Ce livre de synthse est compos dune collection darticles. partir dun cha-
pitre de synthse introductif, les auteurs dveloppent diffrents aspects spci-
fiques : bases de donnes rparties, htrognes, objets complexes, optimisa-
tion multi-requtes, machines bases de donnes, modle de cot, etc.
[King81] King J.J., QUIST : A System for Semantic Query Optimization in
Relational Data Bases , Proc. 7th Intl. Conf. on Very Large Data Bases,
Cannes, France, IEEE Ed., p. 510-517, Sept. 1981.
Cet article dcrit lun des premiers systmes capables de prendre en compte les
contraintes dintgrit pour loptimisation de requtes.
[Knuth73] Knuth D.E., The Art of Computer Programming, Volume 3 : Sorting and
Searching, Addison-Wesley, Reading, Mass., 1973.
348 BASES DE DONNES : OBJET ET RELATIONNEL
Cet article tudie les stratgies de recherche du meilleur plan pour des requtes
comportant plus dune dizaine de jointures. Des stratgies alatoires telles que
lamlioration itrative et le recuit simul sont compares.
[TPC95] Transaction Processing Council, Benchmark TPC/D, San Fransisco, CA,
1995.
La dfinition du TPC/D telle que propose par le TPC.
[Ullman88] Ullman J.D., Principles of Database and Knowledge-base Systems,
volumes I (631 pages) et II (400 pages), Computer Science Press, 1988.
Deux volumes trs complets sur les bases de donnes, avec une approche plutt
fondamentale. Jeffrey Ullman dtaille tous les aspects des bases de donnes,
depuis les mthodes daccs aux modles objets en passant par le modle
logique. Ces ouvrages sont finalement trs centrs sur une approche par la
logique aux bases de donnes. Les principaux algorithmes daccs et doptimi-
sation de requtes sont dtaills dans un chapitre plutt formel.
[Valduriez84] Valduriez P., Gardarin G., Join and Semi-Join Algorithms for a
Multiprocessor Database Machine , ACM TODS, vol. 9, n 1, 1984.
Cet article introduit et compare diffrents algorithmes de jointure et semi-join-
ture pour machines multiprocesseurs. Il montre quaucune dentre-elles nest
dominante, mais que chacune a son domaine dapplication selon la taille des
relations et la slectivit des jointures.
[Valduriez87] Valduriez P., Join Indices , ACM TODS, vol. 12, n 2, Juin 1987.
Lauteur introduit les index de jointure, des index qui mmorisent la jointure
pr-calcule entre deux tables. Chaque entre de lindex est un couple de poin-
teurs rfrenant deux tuples participant la jointure, lun appartenant la
premire table, lautre la seconde. De tels index sont trs efficaces en interro-
gation. Le problme de ce type dindex est la mise jour.
[Wong76] Wong E., Youssefi K., Decomposition A Strategy for Query
Processing , ACM TODS, vol. 1, n 3, Septembre 1976.
Cet article prsente la mthode de dcomposition telle quimplmente dans le
systme Ingres. On a compris plus tard que la mthode permettait de dtacher
les semi-jointures en plus des slections.
Partie 3
LOBJET
ET LOBJET-
RELATIONNEL
LE MODLE OBJET
1. INTRODUCTION
Les modles objets, encore appels modles orients objets ou simplement modles
objet, sont issus des rseaux smantiques et des langages de programmation orients
objets. Ils regroupent les concepts essentiels pour modliser de manire progressive
des objets complexes encapsuls par des oprations de manipulation associes. Ils
visent permettre la rutilisation de structures et doprations pour construire des
entits plus complexes. Ci-dessous, nous dfinissons les concepts qui nous semblent
importants dans les modles de donnes objets. Ces concepts sont ceux retenus par
lOMG lorganisme de normalisation de lobjet en gnral , dans son modle objet
de rfrence [OMG91]. Certains sont obligatoires, dautres optionnels. Ce modle est
proche du modle de classe de C++ [Stroustrup86, Lippman91], qui peut tre vu
comme une implmentation des types abstraits de donnes. Il est aussi trs proche du
modle objet du langage Java [Arnold96].
Bien que C++ et Java soient aujourdhui les langages de programmation dapplica-
tions sur lesquels sappuient la plupart des bases de donnes objets, il existe dautres
langages orients objet. Historiquement, Simula a t le premier langage orient
objet ; il est toujours un peu utilis. Simula a introduit le concept de classe qui
regroupe au sein dune mme entit la structure de donnes et les fonctions de ser-
vices qui la grent. Simula avait t dvelopp pour la simulation et disposait notam-
ment doutils gnriques dont un chancier intressants. Smalltalk [Goldeberg83] est
354 BASES DE DONNES : OBJET ET RELATIONNEL
n la fin des annes 70, en reprenant des concepts de Simula. Cest un langage
orient objet populaire, souvent interprt et disposant denvironnements interactifs
intressants. Dans le monde des bases de donnes, il a t utilis par les concepteurs
de GemStone [Maier86] comme langage de base pour dfinir les structures dobjets et
programmer les applications.
Divers dialectes Lisp sont orients objet, si bien que lapproche bases de donnes
objets est ne partir de Lisp. Orion [WonKim88] fut historiquement le premier
SGBD objets construit partir dun Lisp objet. Aujourdhui, et malgr quelques
dtours vers des langages spcifiques [Lcluse89], la plupart des SGBD objets sont
bass sur C++ et sorientent de plus en plus vers Java. Ils permettent de grer des
classes dobjets persistants. Ce choix est effectu essentiellement pour des raisons de
performance et de popularit du langage C++, qui est une extension du langage C ;
C++ est dailleurs traduit en C par un pr-compilateur. Quelques SGBDO supportent
Smalltalk. Java est le langage objet davenir, support par la plupart des SGBDO. La
trs grande portabilit et la scurit du code intermdiaire gnr le fameux byte-
code facile a distribuer , en font un langage de choix pour les applications client-ser-
veur et web plusieurs niveaux de code applicatif.
Ce chapitre se propose dintroduire les concepts de la modlisation objet et les opra-
tions de base pour manipuler des objets persistants. Aprs cette introduction, la sec-
tion 2 introduit les principes des modles objets en les illustrant par un modle de
rfrence proche de celui de lOMG. La section 3 dfinit plus prcisment ce quest
un SGBDO et discute des principales techniques de gestion de la persistance propo-
ses dans les systmes. La section 4 propose une algbre pour objets complexes dfi-
nie sous forme de classes et permettant de manipuler des collections dobjets un
niveau intermdiaire entre un langage SQL tendu et un langage de programmation
navigationnel de type C++ persistant. La conclusion rsume les points abords et
introduit les problmes essentiels rsoudre pour raliser un SGBDO.
Un objet est donc une instance dentit. Il possde une identit qui permet de le rep-
rer. Par exemple, un vhicule particulier V1 est un objet. Un tel vhicule est caract-
ris par un tat constitu dun numro, une marque, un type, un moteur, un nombre de
kilomtres parcourus, etc. Il a aussi un comportement compos dun ensemble dop-
rations permettant dagir dessus, par exemple crer(), dmarrer(), rouler(), stopper(),
dtruire(). Chaque opration a bien sr des paramtres que nous ne prcisons pas pour
linstant.
Lobjet de type vhicule didentit V1 peut tre reprsent comme un groupe de
valeurs nommes avec un comportement associ, par exemple :
V1 {
Numro: 812 RH 94, Marque: Renault, Type: Clio, Moteur: M1 ;
crer(), dmarrer(), rouler(), stopper(), dtruire() }.
Une personne est aussi un objet caractris par un nom, un prnom, un ge, une voi-
ture habituellement utilise, etc. Elle a un comportement compos dun ensemble
doprations { natre(), vieillir() , conduire(), mourir() }. Lobjet de type personne
didentit P1 peut tre dcrit comme suit :
P1 {
Nom: Dupont, Prnom: Jules, Age: 24, Voiture: V1 ;
natre(), vieillir(), conduire(), mourir() }.
Un objet peut tre trs simple et compos seulement dune identit et dune valeur
(par exemple, un entier E1 {Valeur: 212}). Il peut aussi tre trs complexe et lui-
mme compos dautres objets. Par exemple, un avion est compos de deux moteurs,
de deux ailes et dune carlingue, qui sont eux-mmes des objets complexes.
travers ces exemples, deux concepts importants apparaissent associs la notion
dobjet. Tout dabord, un objet possde un identifiant qui matrialise son identit.
Ainsi, deux objets ayant les mmes valeurs, mais un identifiant diffrent, sont consi-
drs comme diffrents. Un objet peut changer de valeur, mais pas didentifiant
(sinon, on change dobjet).
internes invariants dans les bases de donnes objets soppose aux bases de donnes
relationnelles dans lesquelles les donnes (tuples) ne sont identifis que par des
valeurs (cls). Deux objets O1 et O2 sont identiques (on note O1 == O2) sils ont le
mme identifiant ; il ny a alors en fait quun objet dsign par deux pointeurs O1 et
O2. Lidentit dobjet est donc lgalit de pointeurs. Au contraire, deux objets sont
gaux (on note O1 = O2) sils ont mme valeur. O1 == O2 implique O1 = O2,
linverse tant faux.
Lidentit dobjet apporte une plus grande facilit pour modliser des objets com-
plexes ; en particulier, un objet peut rfrencer un autre objet. Ainsi, le vhicule V1
rfrence le moteur M1 et la personne P1 rfrence le vhicule V1. Les graphes peu-
vent tre directement modliss (voir figure XI.1). Le partage rfrentiel dun sous-
objet commun par deux objets devient possible sans duplication de donnes. Par
exemple, une personne P2 { Nom: Dupont; Prnom: Juliette; Age: 22; Voiture: V1 }
peut rfrencer le mme vhicule que la personne P1.
Objet P1
Objet P2
Objet V1
Figure XI.1 : Partage rfrentiel dun objet par deux autres objets
Comme le montre ces exemples, en plus dun identifiant, un objet possde des attri-
buts aussi appels variables dinstance. Un attribut mmorise une valeur ou une
rfrence prcisant une caractristique dun objet. La valeur peut tre lmentaire (un
entier, un rel ou un texte) ou complexe (une structure valeurs multiples). La rf-
rence correspond un identifiant dun autre objet. Elle permet de pointer vers un autre
objet avec des pointeurs invariants.
Le terme mthode sera aussi employ pour dsigner une opration. Issu de Smalltalk,
ce concept a cependant une connotation plus proche de limplmentation, cest--dire
que lorsquon dit mthode, on pense aussi au code constituant limplmentation. Quoi
quil en soit, un objet est manipul par les mthodes qui lencapsulent et accd via
celles-ci : le principe dencapsulation hrit des types abstraits cache les structures
de donnes (les attributs) et le code des mthodes en ne laissant visible que les opra-
tions exportes, appeles oprations publiques. Par opposition, les oprations non
exportes sont qualifies de prives. Elles ne sont accessibles que par des mthodes
associes lobjet. Lencapsulation est un concept fondamental qui permet de cacher
un groupe de donnes et un groupe de procdures associes en les fusionnant et en ne
laissant visible que linterface compose des attributs et des oprations publics.
Linterface dun objet contient donc toutes les oprations publiques que peuvent utili-
ser les clients de lobjet. Pour viter de modifier les clients, une interface ne doit pas
tre change frquemment : elle peut tre enrichie par de nouvelles oprations, mais il
faut viter de changer les signatures des oprations existantes. En consquence, un
objet exporte une interface qui constitue un vritable contrat avec les utilisateurs. Les
attributs privs (non visibles lextrieur) et le code des oprations peuvent tre
modifis, mais changer des oprations de linterface ncessite une reprise des clients.
Ce principe facilite la programmation modulaire et lindpendance des programmes
limplmentation des objets. Par exemple, il est possible de dvelopper une structure
de donnes sous la forme dun tableau, permettant de mmoriser le contenu dun
cran. Cette structure peut tre encapsule dans des oprations de signatures fixes
permettant dafficher, de redimensionner, de saisir des caractres. Le changement du
tableau en liste ncessitera de changer le code des oprations, mais pas linterface, et
donc pas les clients.
358 BASES DE DONNES : OBJET ET RELATIONNEL
En rsum, les oprations et attributs publics constituent linterface dun objet. Ceux-
ci sont les seuls accessibles lextrieur de limplmentation de lobjet. Le code qui
constitue cette implmentation peut tre structur. Certaines oprations sont alors
invisibles lextrieur de lobjet : elles sont appeles oprations prives. Par
exemple, la saisie dun texte peut seffectuer par plusieurs appels dune mthode sai-
sissant une ligne : la mthode SaisirLigne restera invisible au monde extrieur et seule
la mthode SaisirTexte pourra tre invoque. Dans la suite et afin de simplifier, nous
supposerons que toutes les mthodes dun objet sont publiques. Si nous ne le prci-
sons pas, les attributs sont publiques. Mettre des attributs publics ne respecte pas trs
bien le principe dencapsulation qui consiste cacher les proprits servant limpl-
mentation. Briser ainsi lencapsulation conduit des difficults si lon veut changer
par exemple le type dun attribut : il faut alors prvenir les clients qui doivent tre
modifis !
Notez quun attribut dun objet peut tre lu par une fonction applique lobjet dlivrant
la valeur de lattribut. Nous noterons cette fonction GetAttribut, o Attribut est le nom
de lattribut considr. Ainsi, lattribut Nom dfinit une fonction GetNom qui, applique
une personne P, dlivre un texte (son nom). La proprit Voiture peut aussi tre lue par
une fonction GetVoiture qui, applique une personne, dlivre lidentifiant de lobjet
constituant son vhicule habituel. Un attribut peut aussi tre crit par une fonction parti-
culire que nous noterons PutAttribut. En rsum, tout attribut dfinit implicitement
deux mthodes (criture : Put, et lecture : Get) qui peuvent tre prives ou publiques,
selon que lattribut est visible ou non lextrieur. Le formalisme unificateur des fonc-
tions est trs puissant, car il permet de raccrocher une mme thorie (les types abs-
traits) les proprits mmorises (attributs) et calcules (fonctions) dun objet.
Notez que certains systmes objets sparent la fonction de cration des objets de la
classe : on obtient alors des classes qui sont simplement des implmentations de types
abstraits et lon ajoute des usines objets (Object factory) pour crer les objets.
Chaque classe doit alors avoir son usine, ce qui complique le modle.
Une classe spcifie donc la structure et le comportement communs des objets quelle
permet de crer. Au-del du nouveau type de donnes abstrait ajout lenvironne-
ment par une dfinition de classe, une classe supporte une implmentation : cest le
code des oprations. Elle donne aussi naissance une famille dobjets : on parle alors
de lextension de la classe. Cette extension est une collection dobjets ayant mmes
structure et comportement. La classe est donc un peu lanalogue de la table dans les
bases de donnes relationnelles, bien quune table ne permette que de modliser la
structure commune des tuples qui la composent.
En rsum, le concept de classe est plutt complexe. Par abus de langage, le mot
classe dsigne gnralement une intention (le type abstrait), mais aussi parfois une
extension (la collection des objets membres de la classe), dautre fois une implmen-
tation (la structure des objets et le code des oprations). La spcification progressive
des classes dobjets composant une base de donnes objets permet de modliser le
comportement commun des objets de manire modulaire et extensible. Elle permet
aussi de spcifier les collections contenant les objets ou extensions de classes. La plu-
part des systmes distinguent lintention de lextension, une classe (ou un type selon
le vocabulaire) pouvant avoir plusieurs extensions.
Du point de vue de la reprsentation dune dfinition de classe, nous utiliserons la
notation prconise par UML [Rational97] et illustre figure XI.2. Nous avons
gauche le cadre gnrique servant reprsenter une classe, droite le cas de la classe
Vin. Chaque attribut a un nom, de mme que chaque opration. Un attribut est typ.
Les oprations peuvent avoir des paramtres, et un type dans le cas de fonctions. Un
attribut ou une opration publics sont prcds de + ; de mme pour une opration.
Nous pouvons maintenant illustrer la notion de classes par quelques exemples. La
syntaxe choisie pour les dfinitions de classe est proche de C++, chaque attribut ou
mthode ayant un type suivi dun nom et dventuels paramtres. Notre premier
exemple (voir Figure XI.3) vise modliser le plan gomtrique sous forme de points.
Pour crer et rassembler les points crs, nous dfinissons une classe comportant deux
attributs, X et Y, de type flottant. Une mthode sans paramtre Distance permet de cal-
culer la distance du point lorigine ; cette mthode retourne un flottant. Une
mthode Translater permet de translater un point dun vecteur fourni en para-
360 BASES DE DONNES : OBJET ET RELATIONNEL
mtre et ne retourne aucun paramtre (void en C++). Une autre mthode Afficher
permet de gnrer un point lumineux sur un cran ; elle ne retourne aucun paramtre.
Classe
Vins
+ Cru : char[20]
Nom
+ Millsime : int
- Degr : fixed 5.2
- Quantit: int
attributs
oprations + Produire()
+ Livrer()
+ Int Get_Degr()
+ Set_Degr(degr int)
Illustrations
non
UML
Class Point {
Float X;
Float Y;
Float Distance();
Void Translater(Float DX, Float DY);
Void Afficher(); };
La figure XI.4 permet de dfinir les classes Vin, Personne et Vhicule dont
quelques objets ont t vus ci-dessus. Les mots cls Public et Private permettent
de prciser si les proprits sont exportes ou non. Par dfaut, il restent cachs dans la
classe, donc privs. Notez que comme en C++, nous dfinissons une rfrence par le
type de lobjet point suivi dune toile (par exemple Vhicule*). Deux mthodes
sont attaches la classe Personne : Vieillir qui permet dincrmenter de 1 lge
dune personne et rend le nouvel ge, Conduire qui permet de changer le vhicule
associ et ne retourne aucun paramtre. Notez que la classe Vhicule rfrence
dautres classes (Constructeur, Propulseur) non dfinies ici.
Le modle objet 361
Class Vin {
Fixed 5.2 degr ;
Int quantit ;
Public :
Char cru [20] ;
Int millsime ;
void Produire()
void Livrer()
Int Get_Degr()
void Set_Degr(Int degr) } ;
Class Personne {
String Nom;
String Prnom;
Int Age;
Vhicule* Voiture;
Public :
Int Vieillir();
Void Conduire(Vhicule V); };
Class Vhicule {
Public :
String Numro;
Constructeur* Marque;
String Type;
Propulseur* Moteur; };
Une opration dfinie dans le corps dune classe sapplique un objet particulier de la
classe. Par exemple, pour translater un point rfrenc par P dun vecteur unit, on
crira PTranslater(1,1). Pour calculer la distance de P lorigine dans une
variable d, on peut crire d = PDistance(). Certaines mthodes peuvent
sappliquer plusieurs objets de classes diffrentes : une telle mthode est dite multi-
classe. Elle est en gnral affecte une classe particulire, lautre tant un paramtre.
La possibilit de supporter des mthodes multiclasses est essentielle pour modliser
des associations entre classes sans introduire de classes intermdiaires artificielles.
gnrale pour obtenir une classe plus spcifique. On peut aussi procder par mise en
facteur des proprits communes diffrentes classes afin de dfinir une classe plus
gnrale. La notion de gnralisation ainsi introduite est emprunte aux modles
smantiques de donnes [Hammer81, Bouzeghoub85].
Personne
- nss
- nom
- prnom
- ge
- photo*
+ vieillir()
Employ
Buveur
- profession
- lieu de travail - tat
- salaire - abus
- primes + boire()
+ dormir()
+ travailler()
Cadre
+ travailler() Non cadre
Class Personne {
Int nss ;
String nom ;
String prenom ;
Int age ;
Image* photo ;
Public :
Int vieillir() ; }
Class Employ : Personne {
String profession ;
String lieudetravail ;
Double salaire ;
Double primes ;
Public :
void travailler() ; }
Class Buveur : Personne {
Enum etat (Normal, Ivre) ;
List <consommation> abus ;
Public :
Int boire() ;
void dormir() ; }
364 MATRISER LES BASES DE DONNES
Dans ce cas, la sous-classe hrite des proprits et oprations de toutes ses super-
classes. Lhritage multiple permet de dfinir des classes intersection comme dans la
figure XI.7, o les EmploysBuveurs hritent la fois des Buveurs et des Employs.
Ils hritent certes dun seul nom provenant de la racine Personne.
Employ
Buveur
- profession
- tat
- lieu de travail
- abus
- salaire
- primes
+ boire
+ dormir
+ travailler()
EmployBuveur
+BoireTravailler()
dambigut de noms. Enfin, un choix automatique peut tre fait par le systme, par
exemple le premier gauche. Dans lexemple de la figure XI.8, les triangles rec-
tangles isocles vont hriter de trois fonctions de calcul de surface. Deux dentres
elles sont identiques et proviennent de lopration surface associe aux triangles. Il
faut pouvoir choisir parmi les deux restantes, soit en conservant les deux en les
renommant polygone_surface et triangle_surface, soit en en slection-
nant une, par exemple la premire gauche, donc celle des polygones droits.
PolygoneDroit Triangle
+Surface() +Surface
TriangleRectangle TriangleIsocle
TriangleRectangleIsocle
Dire quune classe C1 est plus gnrale quune classe C2 permet de dfinir une rela-
tion dordre C2 C1, qui reprsente le fait que les instances de C2 sont incluses dans
celles de C1. Cette relation dordre correspond donc une inclusion au niveau des
ensembles dobjets. La relation dordre ainsi dfinie permet de considrer le treillis
des classes. Ce treillis possde en gnral un plus grand lment qui est la classe
dnomme Objet (Object) ; cette classe apparat alors comme la racine de la hirar-
chie dhritage qui fournit toutes les mthodes de base de manipulation des objets,
mthodes hrites par toutes les autres classes. La hirarchie des types et lhritage de
proprits ont t formellement tudis dans le contexte des types abstraits sous forme
de sigma-algbres [Guogen78], et plus rcemment dans le contexte de la programma-
tion objet [Castagna96].
classe une fonctionnalit similaire de mme signature dopration, mais avec un code
diffrent. On parle alors de redfinition.
Par exemple, une mthode globale telle que Travailler peut tre spcifie au
niveau de la classe Employ, puis redfinie de manire spcifique au niveau de la
classe Cadre. En effet, la mthode Travailler de la classe Employ pourra tre
redfinie par un code correspondant un travail de direction au niveau de la classe
Cadre. Il est mme possible de ne pas dfinir le code de lopration au niveau dune
classe et dimposer de le dfinir au niveau des sous-classes : on parle alors de
mthode virtuelle au niveau de la super-classe.
Pour une mme classe, il est aussi possible de dfinir plusieurs implmentations pour
une mme opration. Chacune delle sera alors distingue par des paramtres diff-
rents. Ceci correspond la notion de surcharge.
Collection
Insert
Delete
Get
IsEmpty
Count
Apply
Aggregate
Search
class Phrase {
List <Array <char>> Squence; };
class Paragraphe {
Phrase Thme;
List <Phrase> Dtails;
Phrase Conclusion; };
class Texte {
List <Paragraphe*> Contenu; };
Lexistence de collections imbriques traduit le fait que certains objets sont inclus
dans dautres. Il sagit en fait dune reprsentation de la relation dagrgation entre
classes.
Lagrgation traduit la relation fait partie de ; par exemple, les caractres font par-
tie de la phrase. Les collections permettent dimplmenter les agrgations multiva-
370 BASES DE DONNES : OBJET ET RELATIONNEL
lues. Lagrgation peut tre implmente par une rfrence (par exemple
List<Paragraphe*>) ou par une imbrication, selon que lon dsire ou non partager
les objets inclus. La reprsentation des agrgations par un graphe permet de visualiser le
processus de construction des objets complexes. La figure XI.11 reprsente le graphe
dagrgation, encore appel graphe de composition, de la classe Texte. Les cardinalits
multiples sont mentionnes par des toiles (*), conformment la notation UML
[Rational97].
Texte
Contenu
*
Paragraphe
Thme
* Conclusion
Dtails
Phrase
Squence
*
Char
Personne
Forme
Tte ilD ilG
*
Cercle Point
Centre
-x
- Rayon -y
Class Vin {
public:
Char Cru[20] ;
Int Mill ;
Double Degr ; }
Class Buveur {
private:
Enum Etat (Normal, Ivre) ;
public:
Char Nom[15] ;
Char Prnom[15] ;
List <Date Jour, Vin* Boisson, Int Quantit> Abus ;
Caricature* Reprsentation ;
// opration sur buveur
void Boire (Date d, Vin* v, Int q) ;
void Dormir (Int dure); }
Class Caricature {
Cercle* Tte ;
Cercle* OeilD ;
Cercle* OeillG ;
Figure* Nez ;
Le modle objet 373
Figure* Bouche ;
// operations sur personnage
void Sourire () ;
void Pleurer () ;
Graphic Dessiner (Int Echelle) ; }
Class Cercle {
Point Centre ;
Double Rayon ; }
Class Figure {
List <Point> Forme ; }
Soulignons quun schma de classes modlise la fois la structure (les attributs des
classes) et le comportement (les mthodes) des objets. La dfinition complte dune
base de donnes objets ncessite donc un langage de programmation afin de spci-
fier le code des programmes. Ce langage est un langage orient objet, du type
Smalltalk, ou de plus en plus souvent C++ ou Java.
La persistance des objets. Tout objet doit pouvoir persister sur disque au-del du
programme qui le cre. Un objet peut tre persistant ou transient. Dans le
deuxime cas, sa dure de vie est au plus gale celle du programme qui le cre ; il
sagit dun objet temporaire qui reste en mmoire.
En C++ ou en Java, le constructeur dun objet est une fonction membre de la classe. Il
fait en gnral appel une fonction de rservation de mmoire et des fonctions
dinitialisation. Les constructeurs sont normalement dfinis par le programmeur, mais
C++ et Java insrent un constructeur minimal dans les classes qui nen possdent pas.
Le nom du constructeur est le nom de la classe. Par exemple, un point origine pourra
tre dfini comme suit :
Point Origine(0,0).
Le destructeur libre la place mmoire associe lobjet. Il peut tre fourni par le pro-
grammeur. Certains langages orients objet tels Java et Smalltalk sont munis dun
ramasse-miettes dtruisant automatiquement les objets non rfrencs, si bien que le
programmeur na pas se soucier dappeler le destructeur dobjets.
Le problme qui se pose dans les SGBDO est dassurer la persistance des objets sur
disques pour pouvoir les retrouver ultrieurement. En effet, constructeur et destructeur
dobjets ne font que construire et dtruire les objets en mmoire. Une solution cou-
ramment retenue pour sauvegarder les objets sur disques consiste donner un nom
chaque objet persistant et fournir une fonction permettant de faire persister un objet
pralablement construit en mmoire. Cette fonction peut tre intgre ou non au
constructeur dobjet. Sa signature pourra tre la suivante :
// Rendre persistant et nommer un objet point.
Oid = Persist(<Nom>, <Ref>);
Nom est le nom attribu lobjet qui permettra ultrieurement de le retrouver (dans le
mme programme ou dans un autre programme). Ref est la rfrence en mmoire de
lobjet. Oid est lidentifiant attribu lobjet dans la base par le SGBDO.
Un objet persistant pourra ensuite tre retrouv partir de son nom, puis mont en
mmoire partir de son identifiant dobjet (adresse invariante sur disque). On trouvera
donc deux fonctions plus ou moins caches au programmeur dans les SGBD objets :
// Retrouver loid dun objet persistant partir du nom.
Oid = Lookup(<Nom>);
// Activer un objet persistant dsign par son oid.
Ref = Activate(<Oid>);
Un objet actif en mmoire pourra tre dsactiv (rcriture sur disque et libration de
la mmoire) par une fonction du style:
Le modle objet 377
Finalement, il sera aussi possible de rendre non persistant (dtruire) dans la base un
objet persistant partir de son identifiant dobjet ou de son nom, en utilisant lune des
fonctions suivantes :
// Supprimer un objet persistant dsign par son nom
Void UnPersist(<Nom>);
// Supprimer un objet persistant dsign par son identifiant
Void UnPersist(<Oid>);
Une telle bibliothque de fonction peut tre utilise directement par le programmeur
dans un langage orient objet comme C++ ou Java pour grer manuellement la persis-
tance des objets. De plus, des fonctions de gestion de transactions devront tre int-
gres afin dassurer les critures disques, la gestion de concurrence et de fiabilit. Les
critures peuvent tre explicites par une fonction Put ou implicites lors de la valida-
tion, en fin de transaction. Un tel systme est voisin de celui offert par Objective-C
pour la persistance des objets dans des fichiers. Il constitue un niveau minimal de
fonctionnalits ncessaire la gestion de la persistance que nous qualifierons de per-
sistance manuelle. Ce niveau de fonctions peut tre cach au programmeur du
SGBDO par lune des techniques tudies ci-dessous.
Dans tous les cas, un problme qui se pose lors de lcriture dun objet dans la base
est la sauvegarde des pointeurs vers les autres objets persistants. Comme lors de
lactivation dun objet persistant, il faut restaurer les pointeurs en mmoire vers les
autres objets actifs. Des solutions sont proposes par chacune des techniques de per-
sistance dcrites ci-dessous. Notez que les systmes implmentent parfois des tech-
niques de persistance mixtes, qui empruntent un peu aux deux dcrites ci-dessous.
Objet
New
Delete
Pobjet
Classes dobjets
transients
New {Persist}
Delete {Unpersist}
operator
Classesdobjets
persistants
Outre les constructeurs et destructeurs destins grer lobjet sur disque, la technique
de persistance par hritage surcharge en gnral le parcours de rfrence (oprateur
en C++). Cela permet dactiver automatiquement un objet point par un objet dj
actif lors du premier parcours de la rfrence, en utilisant une technique de mutation
de pointeur, comme nous le verrons ci-dessous.
En rsum, nous dfinirons la persistance par hritage comme suit :
Cette technique prsente lavantage dtre simple raliser. Cependant, elle nassure
pas lorthogonalit de la persistance aux types de donnes, si bien que tout type ne
peut pas persister. Si lon veut avoir dans une mme classe des objets persistants et
transients (par exemple des personnes persistantes et des personnes transientes), on est
conduit dupliquer les classes. Ceci peut tre vit en marquant les objets non persis-
tants dune classe persistante simplement par un boolen. La performance de la tech-
nique de persistance par hritage est discute, la surcharge des oprateurs (construc-
teurs et parcours de rfrences) pouvant tre coteuse.
condition dtre dclar comme tel, puis que tout objet point par un objet persistant
est persistant (voir figure XI.15). En gnral, les objets persistants sont les objets
nomms, nom et persistance tant dclars dans la mme commande de cration
dobjet persistant. Cela conduit ajouter un mot cl persistant ou db au lan-
gage de programmation (par exemple C++) et donc ncessite un prcompilateur qui
gnre les appels aux fonctions Persist, Unpersist, Activate, etc. Par
exemple, un employ pourra tre cr persistant par la dclaration :
Employe* emp = new persistant Employe(Toto);
De mme, une simple variable x pourra tre rendue persistante par la dclaration :
persistant int x;
Au vu de ces dclarations, le prcompilateur gnrera les commandes de persistance
et de recherche ncessaires. Tout objet racine de persistance (donc dclar persistant)
sera rpertori dans un catalogue o lon retrouvera son nom et son oid.
Catalogue
toto
lulu
x 7
. adresse
.
.
voiture
moteur garage
Tout objet rfrenc par un objet persistant sera persistant. L encore, le pr-compila-
teur devra assurer la gnration des appels aux fonctions de persistance lors des assi-
gnations ou des parcours de rfrences. Les rfrences devront aussi tre rendues per-
sistantes par lune des techniques que nous allons tudier ci-dessous.
En rsum, nous dfinirons la persistance par rfrence comme suit :
380 BASES DE DONNES : OBJET ET RELATIONNEL
Dans les langages objet comme C++, la navigation seffectue en mmoire par simple
dcodage de pointeurs. Dans une base dobjets, les choses ne sont pas aussi simples :
un objet pointant sur un autre objet est en effet crit dans la base, puis relu par un
autre programme plus tard. Lobjet point nest alors plus prsent en mmoire (voir
figure XI.16). Le problme soulev est donc de mmoriser de manire persistante les
chanages dobjets sur disques, puis de les dcoder en mmoire de manire efficace.
Toto VoitureToto
Mmoire
Vhicule* Peugeot
Pointeur invalide
Toto
Disque
Vhicule*
En rsum, il faut pouvoir utiliser des identifiants dobjets comme des pointeurs sur
disques et des adresses en mmoire. Le passage dun type de pointeur lautre est
appel mutation de pointeurs.
PREF
REF
OID
Disques
En criture
si OID = NUL ALORS {OID = AllouerBD(Objet) ; Ecrire (REF, OID) } ;
En lecture
si REF = NUL ALORS {REF = AllouerMC(Objet) ; Lire (OID, REF) } ;
2 Violation
Image Disque
Cette technique est parfois appele mmoire un seul niveau (Single Level Store) ;
en effet, lutilisateur travaille directement sur limage de la base en mmoire. Elle est
trs efficace lorsquun mme objet est travers plusieurs fois et que les objets parcou-
rus sont groups dans une mme page. Cependant, la dpendance du programme la
structure de la mmoire virtuelle peut constituer un inconvnient encore mal mesur
aujourdhui.
Une expression de chemin permet deffectuer un parcours dans le graphe des associa-
tions de classes. Sur la base de la figure XI.12, Reprsente.Tte.Centre.x est une
expression de chemins : partant dun buveur B, elle permet datteindre un rel repr-
sentant labscisse du cente de la tte, en traversant les classes Caricature Cercle et
Point. De telles expressions sont la fois utilisables en algbre dobjets complexes et
en SQL tendu, comme nous le verrons dans les chapitres suivants. Ds que lon ren-
contre un chemin multivalu, la traverse devient ambigu ; par suite, la plupart des
langages interdisent les expressions de chemins multivalues du style Abus.cru sur
la base de la figure XI.12, car bien sr un buveur boit plusieurs vins.
Expression
Valuable
Entier Rel
partir des expressions valuables gnralises, il est possible de spcifier une qualifi-
cation de restriction ou jointure gnralise, capable de traiter des objets complexes.
Une telle qualification peut tre vue comme un arbre ET-OU de prdicats lmen-
taires (voir figure XI.20). Un prdicat lmentaire est de la forme :
<Prdicat lmentaire> ::= <Expression valuable>
[<Comparateur> <Expression valuable>].
AND
AND
P1
OR
P2
P3 P4
Cette opration, note dans certaines extensions de lalgbre relationnelle, fait donc
apparatre des attributs valeur dans des ensembles. Elle est illustre figure XI.21.
Une dfinition plus gnrale pourrait consister grouper la relation selon un schma
hirarchique des attributs : on pourrait ainsi faire plusieurs groupages en une seule
opration. Dans le monde objet, cette opration peut tre applique une collection
pour gnrer une nouvelle collection, avec pour chaque objet obtenu par groupage,
attribution dun nouvel identifiant.
Lopration de dgroupage est lopration inverse (voir figure XI.21).
A 1
A 7
B 3
B 8
C 2
Grouper(Type,{Numro}) Dgrouper(Type,{Numro})
A { 1,7 }
B { 3,8 }
C {2}
Attention il nest pas toujours vrai quun dgroupage aprs un groupage donne la rela-
tion initiale, en particulier si cette dernire a des doubles.
Laplatissage dune collection est utilis pour restructurer des collections de col-
lections. Il est dfini par : Flatten(Collection) = {r t Collection r t}.
La jointure de collections sur un prdicat p est une transposition simple de la join-
ture par valeur du relationnel : OJoin(Collection1, Collection2,A1,A2,p) = {<A1 :
s, A2 : r> s Collection1 r Collection2 p(s,r)}.
Afin dliminer les doubles, une opration dlimination de duplicata est introduite.
Elle est note DupEliminate (Collection, e). e est un paramtre permettant de dfinir
lgalit dobjets dans la collection. Ce peut tre par exemple lgalit didentifiants
ou de valeurs. Coallesce (Collection, Ai, e) est une variante permettant dliminer les
doubles dans un attribut Ai dun tuple avec attribut multivalu.
Les oprations ensemblistes classiques dunion, intersection et diffrence de collec-
tions sont considrer. Elles ncessitent la dfinition du type dgalit dobjets consi-
dr, sur identifiant ou sur valeur.
Lalgbre distingue les oprations par valeur et par rfrence, dont largument est en
gnral un ou plusieurs identifiants. Les oprations sont classes en oprations de
recherche, oprations ensemblistes, oprations de groupement et enfin oprations de
mise jour. La figure XI.23 reprsente la hirarchie de gnralisation des oprations
de lalgbre propose.
388 BASES DE DONNES : OBJET ET RELATIONNEL
Opration
Algbrique
class Opration {
// Options de tri et ddoublement des rsultats:
LIST(Field*) SortInfo; // Champs de tri.
Boolean Ascendant; // Ascendant si Vrai.
Boolean Duplicata; // Garder les doubles si vrai.
};
Le modle objet 389
Les suppressions seffectuent partir dune collection calcule qui contient les identi-
fiants des tuples supprimer dans lautre collection. La suppression est quivalente
une diffrence sur identifiant dobjets. Elle est dfinie figure XI.27.
Les modifications seffectuent aussi partir dune extension de classe calcule qui
contient les identifiants de tuples modifier dans une classe de base et les lments
pour calculer les nouvelles valeurs des champs modifis. Ces lments sont exprims,
pour chaque attribut, sous la forme dune expression de calcul (par exemple
A = A *1,1 pour une augmentation de 10 % de A). La figure XI.28 dfinit plus prci-
sment lopration Changer.
Le modle objet 391
Vhicule
+ numro
+ couleur
+ fabriquant Constructeur
+ nom
+ ville
+ directeurs * Employ
+ nss
+ nom
- date naissance
+ age()
Project
[numro]
RefJoin [directeurs]
Select[ville = "Paris"]
Employ
RefJoin [Fabriquant]
Constructeur
Select[couleur = "Rouge"]
Vhicule
Class Nud {
Operation* Oper; // Operation effectuer en ce nud.
Flot* Input[MaxIn]; // collections dentre (fils).
Flot* Output[MaxOut]; // collections de sortie (parents).
};
Class Flot {
Int TailleEst; // Taille du flux estime.
} ;
5. CONCLUSION
Dans ce chapitre, nous avons prsent les concepts de modlisation introduits par
lorientation objet, les techniques de gestion de la persistance des objets et une algbre
dobjets complexes. Ces concepts et techniques constituent lessentiel des fonctionnali-
ts aujourdhui offertes par les SGBDO par le biais du langage de dfinition dobjets, du
langage de requtes et du langage de manipulation dobjets. Au-del, il est important de
mentionner que les SGBDO offrent pour la plupart des environnements de dveloppe-
ments visuels labors. Ceux-ci permettent de parcourir les graphes de gnralisation et
de composition (agrgation et association) de classes, mais aussi de visualiser les objets,
voire de crer de nouvelles classes et de programmer des mthodes. Ces diteurs vo-
lus (en anglais, browsers) sont un des attraits importants des SGBDO : en exploitation
par exemple, ils autorisent la vision des classes dobjets sous forme dicnes clicables
pour dclencher les mthodes associes. Ces mthodes peuvent dailleurs tre des op-
rations de recherche ou de mise jour proches de celles de lalgbre dobjets.
Outre ceux tudis dans ce chapitre, les bases de donnes objets soulvent de nom-
breux problmes difficiles. Les plus cruciaux sont sans doute ceux darchitecture et de
performance. Quelle architecture client-serveur retenir ? Faut-il plutt des serveurs
dobjets ou de pages [Dewitt90] ? Comment optimiser les performances, en grant des
caches dobjets, en utilisant des techniques de type mmoire virtuelle dobjets, en dve-
loppant des mthodes de regroupement des objets souvent accds ensemble, etc. ? Du
point de vue du langage de requtes tendu aux objets, nous allons voir que deux propo-
sitions de standards sopposent quelque peu. Les techniques doptimisation sont encore
mal matrises en pratique. Un autre problme important est celui pos par les modifica-
tions de schmas : comment viter de dcharger la base et recompiler les mthodes, par
exemple lors dajout de super-classes ou de suppression de sous-classes ? Une solution
est sans doute la gestion de versions dobjets et de schmas [WonKim90]. Les pro-
blmes de concurrence en prsence de transactions longues (une transaction de concep-
tion peut durer plusieurs heures) sont eux aussi cruciaux. Tous ces problmes (notre liste
nest malheureusement pas exhaustive) seront tudis dans les chapitres qui suivent.
Sous sa forme pure ou sous forme intgre au relationnel, lobjet constitue sans doute
la voie davenir pour les bases de donnes, comme pour bien dautres domaines. Des
standards de reprsentation se dveloppent au niveau des applications selon les tech-
niques de modlisation oriente objet, en particulier les standards XML, SGML,
EXPRESS et CMIS/CMIP respectivement pour le WEB, la gestion de donnes tech-
niques, la CAO et ladministration de rseaux. Ces langages de modlisation de docu-
ments ou de composants semblent bien adapts aux bases de donnes objets.
Lapproche objet reste cependant limite, car elle ncessite de bien connatre les
objets pour en dfinir le type. Fond sur un typage fort, lobjet est peu adapt pour
aborder les applications donnes faiblement structures, comme le Web. Des exten-
sions sont ncessaires.
Le modle objet 395
6. BIBLIOGRAPHIE
[Abiteboul95] Abiteboul S., Foundations of databases, Addison-Wesley, Reading,
Mass., 1995.
Ce livre prsente les fondements thoriques des bases de donnes en faisant le
lien avec des domaines de recherche connexes, tels que la logique et la com-
plexit. Il fait le point sur les problmes avancs des bases de donnes, notam-
ment sur le couplage des modles dductifs et objets.
[Abiteboul87] Abiteboul S., Beeri C., On the Power of Languages for the
Manipulation of Complex Objects , International Workshop on Theory and
Applications of Nested Relations and Complex Objects, 1987, aussi rapport
INRIA n 846, Paris, mai 1988.
Cet article prsente une vue densemble thorique mais progressive des algbres
pour objets complexes. Il discute de la puissance des langages rsultants.
[Arnold96] Arnold K., Gosling J., Le Langage Java, International Thomson
Publishing France, Traduction de The Java Programming Language par S.
Chaumette et A. Miniussi, Addison Wesley Pub., 1996.
Ce livre est la rfrence sur le langage Java, par les inventeurs. Il inclut une
brve introduction au langage et une prsentation dtaille des commandes,
constructions et bibliothques. Sont couverts les aspects dfinition de classes et
dinterfaces, traitement des exceptions, multitche, package, classes systmes
et bibliothques.
[Atkinson89] Atkinson M., Bancilhon F., DeWitt D., Dittrich K., Maier D.,
Zdonick S., The Object-Oriented Database System Manifesto , Deductive
and Object-Oriented Databases Int. Conf., Kyoto, Japan, 1989.
Le fameux manifesto pour les bases de donnes pures objet. Les caractristiques
obligatoires et optionnelles des SGBDO sont prcises comme vu ci-dessus.
[Banerjee87] Banerjee J., Kim W., Kim H.J., Korth. H.F., Semantics and
Implementation of Schema Evolution in Object-Oriented Databases , ACM
SIGMOD Int. Conf., San Fransisco, Cal., 1987.
Cet article pose les problmes de modification de schmas dans les bases de
donnes objets: suppression ou addition dattributs, de mthodes, de sur-
classes, etc. Les solutions retenues dans ORION, qui permettent une grande
souplesse condition de respecter des rgles prcises (par exemple, pas de
cycle de gnralisation), sont prsentes.
[Bouzeghoub85] Bouzeghoub M., Gardarin G., Mtais E., SECSI: An Expert
System for Database Design , 11 th Very Large Data Base International
Conference, Morgan Kaufman Pub., Stockolm, Sude, 1985.
Cet article dcrit le systme SECSI bas sur un modle smantique appel
MORSE. MORSE supporte lagrgation, la gnralisation, lassociation et
396 BASES DE DONNES : OBJET ET RELATIONNEL
linstanciation. SECSI est construit selon une architecture systme expert. Cest
un outil daide la conception de bases de donnes relationnelles qui trans-
forme le modle smantique en relations normalises. Le modle smantique
est labor partir de langages quasi naturels, graphiques ou de commande.
[Bouzeghoub91] Bouzeghoub M., Mtais E., Semantic Modelling of Object
Oriented Databases , 17th Very Large Database International Conference,
Morgan Kaufman Pub., Barcelone, Espagne, aot 1991.
Cet article propose une mthodologie de conception de bases de donnes
objets, fonde sur un rseau smantique. Lapplication est spcifie par un lan-
gage de haut niveau bti autour dun modle smantique et permet de dfinir
des contraintes dintgrit et des rgles de comportements. Cette approche est
intgre dans la version objet du systme daide la conception SECSI.
[CACM91] Communication of the ACM, Special Issue on Next-Generation
Database Systems , Communication of the ACM, vol. 34, n 10, octobre 1991.
Ce numro spcial des CACM prsente une synthse des volutions des SGBD
vers une nouvelle gnration. Les produits O2 commercialis par O2 Technology,
ObjectStore commercialis par Object Design, GemStone commercialis par
Servio, et les prototypes Postgres de luniverst de Californie Berkeley et
Starbust du centre de recherche dIBM Alamaden sont dcrits en dtail.
[Cardelli84] Cardelli L., Wegner P., On Understanding Types, Data, Abstraction,
and Polymorphism , ACM Computing Surveys, vol. 17, n 4, dcembre 1985.
Vaste article de synthse sur le typage, les abstractions de type et le polymor-
phisme. Les conditions de typage sr, cest--dire vrifiable la compilation,
sont tudies.
[Castagna96] Castagna G., Object-Oriented Programming A Unified Foundation,
366p., Birkhauser, Boston, 1997.
Ce livre dveloppe une thorie de lorientation objet, plus spcialement du poly-
morphisme, qui couvre les mthodes multiclasses. Il apporte un nouvel clairage
au problme du typage des paramtres des mthodes dans les cas de surcharge et
redfinition. En clair, la nouvelle thorie en vogue dans le monde objet.
[Cattell91] Cattell R.G., The Engineering Database Benchmark , in [Gray91].
Article prsentant les rsultats du premier benchmark comparant bases de don-
nes objets et relationnelles. Les rsultats dmontrent la supriorit des
SGBD objets pour les parcours de graphes.
[Cluet90] Cluet S., Delobel C., Lcluse C., Richard P., RELOOP, an Algebra Based
Query Language for an Object-Oriented Database System , Data &
Knowledge Engineering, vol. 5, n 4, octobre 90.
Une prsentation du langage dinterrogation du systme O2. La smantique du
langage est base sur une algbre tendue. Bien que possdant une syntaxe
Le modle objet 397
particulire, le langage est dun point de vue smantique proche dun SQL
tendu supportant des objets complexes.
[Delobel91] Delobel C., Lcluse Ch., Richard Ph., Bases de donnes : des systmes
relationnels aux systmes objets, 460 pages, Interditions, Paris, 1991.
Une tude trs complte de lvolution des SGBD, des systmes relationnels
aux systmes objets, en passant par les systmes extensibles. Une attention
particulire est porte sur les langages de programmation de bases de donnes.
Le livre dcrit galement en dtail le systme O2, son langage CO2 et les tech-
niques dimplmentation sous-jacentes. Un livre en franais.
[Dewitt90] DeWitt D., Futtersack P., Maier D., Velez F., A Study of Three
Alternative Workstation-Server Architectures for Object-Oriented Database
Systems , 16 th Very Large Database International Conference, Morgan
Kaufman Pub., Brisbane, Australie, aot 1990.
Une tude comparative de trois architectures (serveur dobjets, de pages et de
fichiers) client-serveur pour les SGBDO. Lanalyse dmontre sommairement
que lapproche serveur de pages est plus performante sous certaines conditions
dans un contexte mono-utilisateur.
[Gardarin89] Gardarin G., Kiernan J., Cheiney J.P., Pastre D., Managing Complex
Objects in an Extensible Relational DBMS , 15th Very Large Databases Interna-
tional Conference, Morgan & Kaufman Ed., Amsterdam, p. 55-65, Aot 1989.
Cet article prsente le SGBD Sabrina ralis lINRIA de 1988 1990, qui fut
un des premiers SGBD relationnels intgrer lobjet. Les objets taient dfinis
comme des types abstraits dont les oprations taient programmes en LeLisp ou
en C. Ils taient intgrs au relationnel comme valeurs de domaines des tables.
Ce SGBD fut commercialis par une start-up qui fut malheureusement plus sou-
tenue aprs 1988, les pouvoirs publics prfrant une dmarche objet pure.
[Gardarin94] Gardarin G., Nowak M., Valduriez P., Flora : A Functional-Style
Language for Object and Relational Algebra , 5th DEXA (Database and Expert
System Application) Intl. Conf., Athens, in LNCS n 856, p. 37-46, Sept. 1994.
FLORA est un langage fonctionnel permettant dcrire des plans dexcution
rsultant de la compilation de requtes objet. Il est du mme niveau quune
algbre dobjets complexes, mais bas sur une approche fonctionnelle. FLORA
manipule une riche bibliothque de collections.
[Goldberg83] Goldberg A., Robson D., Smalltalk-80: The Language and its
Implementation, Addison-Wesley, Reading, Mass., 1983.
Le livre de rfrence de Smalltalk, par les inventeurs du langage.
[Gray91] Gray J. Ed., The Benchmark Handbook, Morgan & Kaufman Pub., San
Mateo, 1991.
Le livre de base sur les mesures de performances des SGBD. Compos de diff-
rents articles, il prsente les principaux benchmarks de SGBD, en particulier le
398 BASES DE DONNES : OBJET ET RELATIONNEL
[Stoustrup86] Stoustrup B., The C++ Programming Language, New York, Addison-
Wesley, 1986.
Le livre de rfrence de C++ par son inventeur. Stoustrup a cr C++ pour
modliser des problmes de rseaux de tlcommunications.
[WonKim88] Won Kim et. al., Features of the ORION Object-Oriented Database
System , dans le livre Object-Oriented Concepts, Applications and
Databases , W. Kim et Lochovsjy Ed., Addison-Wesley, 1988.
Une description du systme ORION, le SGBDO qui a popularis lapproche
bases de donnes objets. Dvelopp MCC ds 1985, ORION est un SGBDO
trs complet. Initialement bas sur Lisp, le produit, commercialis aujourdhui
par Itasca Systems, a volu vers C et C++.
[WonKim89] Won Kim, A Model of Queries for Object-Oriented Database , Very
Large Database International Conference, Morgan Kaufman Pub., Amsterdam,
Pays-Bas, aot 1989.
Cet article prsente les mthodes doptimisation utilises dans le systme
ORION pour le langage dinterrogation. La technique retenue est trs proche
de la restructuration darbre, considrant en plus les jointures par rfrences et
les parcours de chemins.
[WonKim90] Won Kim, Introduction to Object-Oriented Databases, 235 pages, The
MIT Press, 1990.
Ce livre dcrit les diffrentes techniques des SGBD objets. Il sinspire forte-
ment du systme ORION. Plus particulirement, les problmes de modle
orient objet, de modification de schma, de langage SQL tendu aux objets, de
structures de stockage, de gestion de transactions, doptimisation de requtes et
darchitecture sont abords. Une bonne rfrence sur les bases de donnes
objets.
[Zaniolo85] Zaniolo C., The Representation and Deductive Retrieval of Complex
Objects , 11th Very Large Data Bases International Conference, Morgan
Kaufman Pub., Stockholm, Sude, aot 1985.
Cet article prsente une extension de lalgbre relationnelle aux fonctions per-
mettant de retrouver des objets complexes. Des oprateurs dductifs de type
point fixe sont aussi intgrs.
[Zdonik90] Zdonik S., Maier D., Readings in Object-Oriented Database Systems,
Morgan Kaufman Pub., San Mateo, California, 1990.
Une slection darticles sur les bases de donnes objets.
Chapitre XII
LE STANDARD DE LODMG :
ODL, OQL ET OML
1. INTRODUCTION
Depuis 1988, une dizaine de petites socits commercialisent des SGBDO, avec un
succs encore limit. Elles se heurtent au problme de la portabilit des applications.
Il existe maintenant des langages de programmation objet ayant une bonne portabilit
comme C++, ou vraiment portables comme Java, qui a t conu pour tre port. Mais
porter des applications accdant des bases de donnes exige la portabilit des inter-
faces daccs. Ceci est possible en relationnel, avec SQL et des middlewares univer-
sels comme ODBC ou JDBC pour Java. Ceci tait trs difficile en objet devant
labsence de standards.
Ainsi, afin de dfinir des interfaces portables, sest constitu lObject Database
Management Group (ODMG), form au dpart par cinq vendeurs de SGBDO.
LODMG vise raliser pour les bases de donnes objets lquivalent de la norme
SQL, ou au moins dun projet de norme. Deux versions du standard propos ont t
publies assez rapidement : lune en 1993 [Odmg93], lautre prsente dans ce cha-
pitre, en 1997 [Odmg97]. Un des buts des SGBDO, et donc de lODMG, est dviter
le problme soulev par les SGBD classiques o deux systmes cohabitent lors de
linterfaage avec un langage : celui du SGBD et celui du langage. Pour permettre une
402 BASES DE DONNES : OBJET ET RELATIONNEL
utilisation directe des types des langages objet, lODMG a choisi de dfinir un modle
abstrait de dfinition de bases de donnes objet, mis en uvre par un langage appel
ODL (Object Definition Language). Ce modle est ensuite adapt un langage
objet particulier : lODMG propose un standard dintgration en C++, Smalltalk, et
Java. Un langage dinterrogation pour ce modle est propos : il sagit dOQL (Object
Query Language), pour beaucoup issu du langage de requte du systme O2 ralis
lINRIA [Bancilhon92, Adiba93]. OQL est aussi intgrable dans un langage de pro-
grammation objet.
Ce chapitre prsente le standard de lODMG, en lillustrant par des exemples. Aprs
cette introduction, la section 2 prcise le contexte et larchitecture dun SGBDO
conforme lODMG. La section 3 dveloppe le modle abstrait et le langage ODL.
La section 4 prsente un exemple de base et de schma en ODL. La section 5 aborde
le langage OQL travers des exemples et des syntaxes types de requtes constituant
des exemples gnriques, appels profils. La section 6 se consacre lintgration dans
un langage de programmation ; le cas de Java est dtaill. La section 7 conclut ce cha-
pitre en montrant les limites du standard de lODMG.
2. CONTEXTE
Dans cette section, nous prsentons le contexte gnral du standard : les auteurs,
le contenu de la proposition et larchitecture dun systme conforme lODMG.
ODMG93. En fait, il ne sagit pas dun standard avalis par les organismes de nor-
malisation, mais plutt dune proposition dun groupe de pression reprsentant des
vendeurs de SGBDO.
Le groupe a continu travailler et sest enrichi de reprsentants de POET Software,
UniSQL, IBEX et Gemstone Systems, ainsi que de multiples gourous et observateurs
externes. Une nouvelle version du livre a t publie en 1997, sous le titre
ODMG 2.0 ; elle comporte dix auteurs. Le groupe est maintenant bien tabli et colla-
bore avec lOMG et lANSI, notamment sur lintgration CORBA et SQL3. Les
constructeurs participants sengagent suivre les spcifications de lODMG, malheu-
reusement sans dates prcises. Un des checs majeurs du groupe est sans doute
labsence de systmes conformes aux nouvelles spcifications. O2, qui est le systme
le plus proche, ne rpond pas exactement aux fonctionnalits requises [Chaudhri98].
Une dfinition peut aussi tre effectue directement dans lun des langages supports.
La partie la plus intressante de la proposition est le langage OQL (Object Query
Language).
Une intgration est propose avec les langages objets C++, Smalltalk et Java. Celle-ci
prcise les conversions de types effectues et permet la manipulation des objets grs par
le SGBD depuis le langage. Elle est appele OML (Object Manipulation Language).
La figure XII.1 illustre les diffrentes interfaces proposes par le standard ODMG. Ce
sont celles permettant de raliser des applications autour dun SGBDO. Sont-elles suffi-
santes pour assurer la portabilit ? Probablement non, car les interfaces graphiques sont
aussi importantes et souvent spcifiques du SGBDO. Quoi quil en soit, le respect de
ces interfaces par les produits amliorerait de beaucoup la portabilit des applications.
SGBDO
2.3. ARCHITECTURE
La figure XII.2 illustre larchitecture typique dun SGBDO conforme lODMG.
Autour dun noyau grant la persistance des objets, lattribution des identifiants, les
mthodes daccs, et les aspects transactionnels, gravitent trois composants : le pr-
processeur ODL permet de compiler les dfinitions dobjets et de gnrer les donnes
de la mtabase ; le composant langage OML spcifique chaque langage de program-
mation permet de manipuler les objets conformes aux dfinitions depuis un langage
de programmation tel C++, Smalltalk ou Java ; le composant OQL comporte un ana-
lyseur et un optimiseur du langage OQL capables de gnrer des plans dexcution
excutables par le noyau. Au-dessus de ces trois composants, diffrents outils interac-
tifs permettent une utilisation facile des bases ; ce sont par exemple un diteur de
classes pour diter les schmas ODL, un manipulateur dobjets pour naviguer dans la
base (les deux runis constituent souvent le browser), une bibliothque dobjets gra-
phiques, des dbogueurs et diteurs pour les langages de programmation, etc.
Du ct interface avec les langages de programmation, le schma prconis est bas
sur un systme de type unique entre le langage et le SGBDO, chaque type du modle
objet du SGBDO (en principe celui de lODMG) tant traduit directement dans un
type correspondant du langage. Un principe de base est aussi de ne ncessiter aucune
modification du compilateur du langage. Les dclarations de classes persistantes peu-
vent tre crites en ODL, ou directement dans le langage de programmation (PL
ODL). Un prcompilateur permet de charger la mtabase du SGBDO et de gnrer la
dfinition pour le langage de programmation. Les programmes enrichis avec les dfi-
nitions de classes dobjets persistants sont compils normalement. Le binaire rsultant
Le standard de lODMG : ODL, OQL et OML 405
Persistance Concurrence
Grant d'objets Identification Fiabilit
Accs Scurit
Dclaration en Application
ODL ou PL ODL Source en PL
Pr-compilateur Compilateur
de dclarations de PL
ODBMS Application
Runtime Binaire
diteur
de liens
Excutable
3. LE MODLE DE LODMG
Nous dcrivons maintenant le modle abstrait propos pour la dfinition des schmas
des bases de donnes objet.
Nous dfinissons par exemple figure XII.4 une interface calculateur modlisant une
machine calculer.
Le standard de lODMG : ODL, OQL et OML 407
INTERFACE CALCULATEUR {
CLEAR();
FLOAT ADD(IN FLOAT OPERAND);
FLOAT SUBSTRACT (IN FLOAT OPERAND);
FLOAT DIVIDE(IN FLOAT DIVISOR);
FLOAT MULTIPLY (IN FLOAT MULTIPLIER);
FLOAT TOTAL();}
Une classe implmente ainsi une ou plusieurs interfaces. En plus dun comportement,
une classe dfinit un tat abstrait. Pour mmoriser les tats abstraits de ses instances,
une classe possde aussi une extension de classe.
Le comportement abstrait pourra tre hrit dune interface. On voit donc quune
classe donne une spcification dune ou plusieurs interfaces en prcisant quelques l-
ments dimplmentation, en particulier ltat des objets (abstrait car indpendant de
tout langage) et lextension qui va les contenir. Dans certains cas complexes, une
classe peut dailleurs avoir plusieurs extensions. Il est aussi possible de prciser une
cl au niveau dune extension de classe : comme en relationnel, il sagit dun attribut
dont la valeur dtermine un objet unique dans lextension. La figure XII.5 illustre une
dfinition de classe incorporant linterface calculateur.
Notez quune interface peut aussi comporter des attributs abstraits, mais ceux-ci sont
vus comme des raccourcis doprations, une pour lire lattribut, lautre pour lcrire.
Une interface na en principe pas dextension.
Interfaces et classes sont des spcifications de types. Il est aussi possible de spcifier
des types de valeurs : ceux-ci sont appels des littraux.
408 BASES DE DONNES : OBJET ET RELATIONNEL
Les littraux correspondent aux types de base tels entier, rel, chane de caractres,
mais aussi aux structures. Un exemple de littral est un nombre complexe : struct
complex {float re; float im}. Les littraux sont directement implments comme des
types de valeurs en C++. Dans les autres langages purs objets (Smalltalk ou Java), ce
seront des objets.
En rsum, lODMG propose donc un systme de types sophistiqu, capable dtre
facilement mapp en C++, Smalltalk ou Java. Il y a donc des types, des interfaces, des
classes et des littraux. Lensemble forme la hirarchie de spcialisation reprsente
figure XII.6.
Type
Littral Interface
Classe
Soulignons que lhritage de comportement (not :) peut tre multiple : une classe
peut implmenter plusieurs interfaces, mais elle ne peut driver que dune seule autre
classe. En cas de conflits de noms, cest lutilisateur quil incombe de distinguer les
noms.
INTERFACE OBJECTFACTORY {
OBJECT NEW(); // CRATION DUN NOUVEL OBJET
};
INTERFACE OBJECT {
ENUM LOCK_TYPE{READ, WRITE, UPGRADE}; // TYPES DE VERROUS
EXCEPTION LOCKNOTGRANTED(); // ERREUR VERROU REFUS
VOID LOCK(IN LOCK_TYPE MODE) RAISES (LOCKNOTGRANTED); //VERROUILLAGE
BLOQUANT
BOOLEAN TRY_LOCK(IN LOCK_TYPE MODE);// VERROUILLAGE NON BLOQUANT
BOOLEAN SAME_AS(IN OBJECT ANOBJECT); // COMPARAISON DIDENTIFIANTS
DOBJETS
OBJECT COPY(); // COPIE AVEC GENERATION DUN NOUVEL OBJET
VOID DELETE()}; // SUPPRESSION DUN OBJET
proprits (taille, vide ou non, ordre ou non, doubles permis ou non, appartenance
dun lment), pour insrer ou supprimer un lment, pour parcourir la collection par
le biais dun itrateur mono ou bidirectionnel.
Comme son nom lindique, un itrateur permet ditrer sur les lments. Pour cela, il
fournit une interface rsume figure XII.10. Un itrateur bidirectionnel permet daller
en avant, mais aussi en arrire.
INTERFACE ITERATOR {
VOID RESET() ; // INITIALISATION AU DBUT
ANY GET_ELEMENT() RAISES(NOMOREELEMENTS); // OBTENTION LMENT
VOID NEXT_POSITION RAISES(NOMOREELEMENTS); // AVANCE POSITION
REPLACE_ELEMENT (IN ANY ELEMENT) RAISES(INVALIDCOLLECTIONTYPE) ;
...
};
Type
Object Literal
Atomic Obj Collection Obj Structured Obj Atomic Lit. Collection Lit. Structured Lit.
(1:1), (1:N), ou (N:M), sans donnes. Une association de A vers B dfinit deux che-
mins de traverse inverses, A->B et B->A. Chaque chemin doit tre dfini en ODL au
niveau du type dobjet source par une clause RELATIONSHIP. Lassociation pointe vers
un seul objet cible ou vers une collection. Elle porte un nom et son inverse doit tre
dclar. Pour la gestion, le SGBDO doit fournir des oprations sur associations telles
que Add_member, Remove_member, Traverse et Create_iterator_for.
De fait, les associations sont simplement des dclarations abstraites dattributs cou-
pls, valus par une valeur simple ou une collection, contenant des identifiants
dobjets rciproques. La figure XII.13 illustre lassociation classique entre VINS et
BUVEURS, mais sans donnes.
INTERFACE BUVEURS {
...
RELATIONSHIP LIST<VINS> BOIRE INVERSE VINS::EST_BU_PAR;
...
};
INTERFACE VINS {
...
RELATIONSHIP SET<BUVEURS> EST_BU_PAR INVERSE BUVEURS::BOIRE;
...
};
INTERFACE BUVEURS {
...
INT BOIRE(IN VINS V, IN INT QTE) RAISES(NOVINS); //SIGNATURE DE
LOPRATION
...
};
Support
Class
Instantiate 1 key_list
extent_name *
Extends *
super_class Operation
1
signature
Has
invoke
* * return
Object Property
return_abnormally
OID
has_name
Attribute Traversal path
names
attr_name path_name
class
attr_type to_cardinality
create
set_value to_type
delete
get_value traverse Relationship
exits
same_has? creator_iterator
Define
2 add_member
1
remove_member
Appartient Habite
Voiture Personne Appart.
nveh Possde nss Loge tage
couleur nom no
marque prenom rue
km datenais code
rouler() vieillir() ville
dormir()
Infrieur Boire
Employ Buveur * Vin
fonction type
*
Bu_par cru
salaire tat millsime
*
primes boire() degr
Suprieur
travailler() qualit
EmployBuveur
short vieillir();
void dormir()
short age(); };
class Employ : Personne(extent Employs key nss) { //classe avec extension
attribute enum fonct{ingnieur, secrtaire, analyste, programmeur}
fonction;
attribute float salaire ;
attribute list<float> primes ; //attribut multi-valu
relationship Set<Employ> inferieur inverse suprieur;
relationship Employ suprieur inverse infrieur;
void travailler(); };
class Buveur : Personne(extent buveurs key nss) { // classe avec extension
attribute typebuv{petit,moyen,gros} type;
attribute etabuv{normal,ivre} etat;
relationship list<Vin> boire inverse vin::bu_par;
void boire(in Vin v); // paramtre dentre v };
class Appart (extent Apparts) { // classe avec extension
attribute struct adresse (short etage, unsigned short numero, string rue,
unsigned short code, string ville);
relationship Set<personne> loge inverse Personne::habite; };
class Vin (extent Vins) { // classe avec extension
attribute string cru;
attribute string millesime;
attribute string degre;
attribute string qualite;
relationship list<Buveur> bu_par inverse Vin::boire; };
class EmployBuveur extends Employ { // classe sans extension hrite
de employ
attribute typebuv{petit,moyen,gros} type;
attribute etabuv{normal,ivre} etat;
relationship list<Vin> boire inverse vin::bu_par;
void boire(in Vin v); // paramtre dentre v
};
5. LE LANGAGE OQL
Cette section dtaille le langage de requtes OQL et introduit des profils de requtes
typiques.
point de vue typage. OQL nest pas seulement un langage dinterrogation, mais bien
un langage de requtes avec mises jour. En effet, il est possible de crer des objets et
dinvoquer des mthodes mettant jour la base.
OQL permet aussi la navigation via les objets lis de la base, mais seulement avec des
expressions de chemins monovalues.
Il est possible de naviguer par des expressions de chemins un peu particulire,
rduites des chemins simples, que lon dfinira comme suit :
Par exemple, chaque buveur rfrence par lassociation Boire une liste de Vins. Si B
est un buveur, B.Boire est une collection dpendante, ici une collection de Vins. Par
des variables ainsi lies du style B in Buveurs, V in B.Boire, OQL va permettre de
parcourir les associations multivalues. Ceci est puissant pour naviguer, mais plutt
procdural.
Pour prsenter un peu plus prcisment ce langage somme toute remarquable, nous
procdons par des exemples un peu gnraliss. Avant de les lire, il est bon de se rap-
peler que dans toute syntaxe une collection peut tre remplace par une requte pro-
duisant une collection. Rciproquement, il est possible de crer des collections inter-
mdiaires et de remplacer chaque sous-requte par une collection intermdiaire. Cela
peut permettre de simplifier des requtes nombreuses sous-requtes imbriques.
optionnel, [a]* signifie une liste de 0 N a spars par des virgules, [a]+ de 1 N a
spars par des virgules, {a|b} signifie un choix entre a ou b, et... indique une syntaxe
libre compatible avec celles dj introduites. Cette syntaxe peut servir de profil (les
patterns sont la mode) pour formuler un type de requte. Nous appelons aussi
lexpression syntaxique un profil, ou plus simplement un format. Chaque profil est
prcd dun nom de trois lettres suivi de : servant de rfrence pour un usage
ultrieur ventuel. Nous donnons aussi le type du rsultat infr par le compilateur
(aprs la requte, sous forme ===> type). Le langage tant complexe, nous ne don-
nons pas une dfinition, celle-ci pouvant tre trouve dans [ODMG97]. Il y en a
dailleurs deux, une formelle, une autre en BNF, et elles ne semblent pas totalement
cohrentes !
Ceci donne en principe la chane 25TOTO . Cette requte montre la fois le calcul
dexpressions et les conversions de type. Son profil syntaxique est :
PEX: (<TYPE>) <EXPRESSION>
o lexpression peut tre calcule avec tous les oprateurs classiques (+, *, , /, mod,
abs, concatnation). Plus gnralement, lexpression peut aussi tre une collection
dobjets, et donc une requte produisant une telle collection, comme nous en verrons
beaucoup ci-dessous.
Plus gnralement, OQL permet de naviguer dans la base en parcourant des chemins
monovalus, comme vu ci-dessus. Par exemple, la question (Q2) retourne le nom du
propritaire de ma voiture (en principe, Gardarin !) :
(Q2) MAVOITURE.APPARTIENT.NOM
===> LITTRAL STRING
De manire gnrale, les qualifications peuvent faire intervenir, comme en SQL, des
AND et des OR, et des expressions parenthses contenant ces connecteurs logiques.
Une question quivalente peut utiliser le type EMPLOYEBUVEUR comme suit :
(Q5) SELECT ((EMPLOYBUVEUR)B).NOM, ((EMPLOYBUVEUR)B).PRENOM
FROM B IN BUVEURS
WHERE B.TYPE = GROS
==> LITTRAL BAG<STRUCT<NOM:STRING,PRENOM:STRING>
Le standard de lODMG : ODL, OQL et OML 421
Lvaluateur doit alors vrifier lexcution lappartenance des gros buveurs trouvs
la classe des EMPLOYEBUVEUR.
Le profil de telles questions avec indicateurs de classe est :
PIC: SELECT [((<CLASSE>)<VARIABLE>).<ATTRIBUT>]+
FROM...
[WHERE...]
Bien sr, la clause WHERE peut tre compose de slections, de jointures, etc.
Par similarit avec SQL, la collection rsultat est un BAG. Il est aussi possible dobte-
nir une collection de type SET en rsultat ; on utilise alors le mot cl DISTINCT,
comme en SQL :
(Q8) SELECT DISTINCT (NAME: B.NOM, CITY: B.HABITE.ADRESSE.VILLE)
FROM B IN BUVEURS
WHERE B.NOM = DUPONT
===> LITTRAL SET <STRUCT(NAME, CITY)>
422 BASES DE DONNES : OBJET ET RELATIONNEL
Plus gnralement, il est possible demployer tous les buveurs sans emploi par la
requte suivante :
(Q14) EMPLOY(SELECT STRUCT(NSS : B.NSS, NOM: B.NOM, SALAIRE : 4000)
FROM B IN BUVEURS
WHERE NOT EXIST E IN EMPLOYS : E.NSS=B.NSS)
==> BAG<EMPLOYS> INSR DANS EMPLOYS
Notez que cette requte utilise une quantification que nous allons expliciter plus loin.
Le profil gnral de ces requtes de cration dobjets est donc :
PCO : <CLASSE>(<QUESTION>).
424 BASES DE DONNES : OBJET ET RELATIONNEL
PAG: SELECT...[<AGGREGAT>(<ATTRIBUT>)]*
FROM...
[WHERE...]
GROUP BY {<ATTRIBUT>+ | <PREDICAT>+}
HAVING <PRDICAT>
AGGREGAT dsigne une fonction dagrgats choisie parmi COUNT, SUM, MIN, MAX et
AVG. PREDICAT dsigne un prdicat expression logique de prdicats simples de la
forme <ATTRIBUT> <COMPARATEUR> <CONSTANTE> ou
<AGGREGAT>(PARTITION) <COMPARATEUR> <CONSTANTE>. On voit donc
que OQL gnralise les agrgats de SQL2 en permettant de grouper par prdicats
explicites. Cest aussi possible en SQL3 avec dautres constructions.
5.2.14.1. Tris
La premire syntaxe tait fonctionnelle. La nouvelle est copie sur SQL, comme suit :
(Q19) SELECT E.NOM, E.SALAIRE
FROM E IN EMPLOYS
WHERE E.SALAIRE > 21000
ORDER BY DESC E.SALAIRE
Les priorits sont selon lordre indiqu, les parenthses tant aussi possibles.
au type de collection. Les constructeurs de collections struct, set, list, bag, array sont
aussi utilisables pour construire des collections comme nous lavons dj vu. Ainsi :
(Q21) SELECT B.NOM, FIRST(B.BOIRE)
FROM B IN BUVEURS
Les collections apparaissant en rsultat de requtes sont parfois imbriques. Les col-
lections peuvent tre aplaties laide de loprateur FLATTEN. Par exemple :
(Q23) FLATTEN (SELECT B.NOM, SELECT V.MILLSIME
FROM V IN B.BOIRE
WHERE V.CRU = VOLNAY
FROM B IN BUVEURS)
slectionne simplement des doublets nom de buveurs et millsime de Volnay pour les
buveurs ayant bu du Volnay.
En gnral, les profils permis sont donc :
PCO : LISTTOSET(<COLLECTION>)|
ELEMENT(<COLLECTION>)|
DISTINCT(<COLLECTION>)|
FLATTEN(<COLLECTION>)
Le standard de lODMG : ODL, OQL et OML 427
LODMG propose trois intgrations de son modle et de son langage de requtes, une
pour C++, une autre pour Smalltalk, une enfin pour Java. Autrement dit, la vision de
lusager dune BD conforme aux spcifications de lODMG est prcise pour ces trois
langages objet. Les objectifs essentiels de ces propositions sont :
1. La fourniture dun systme de types unique lutilisateur. En principe, le sys-
tme de types utilis est celui du langage de programmation parfois tendu, par
exemple avec des collections. En effet, les vendeurs de SGBDO ayant longtemps
dcri les SGBD relationnels pour lhtrognit des types des langages de pro-
grammation et de SQL, ils se devaient dviter cet cueil.
2. Le respect du langage de programmation. Cela signifie que ni la syntaxe ni la
smantique du langage ne peuvent tre modifies pour accommoder la manipula-
tion des donnes. Des classes supplmentaires seront gnralement fournies, mais
le langage de base ne sera pas modifi.
3. Le respect du standard abstrait ODMG. Ceci signifie que lintgration propose
doit donner accs toutes les facilits abstraites du modle ODMG et de son lan-
gage de requtes OQL. Ce principe nest que partiellement suivi dans ltat actuel
du standard, certaines facilits ntant pas supportes, par exemple les associations
en Java. Mais ceci devrait tre le cas dans une future version.
Pour illustrer ces principes, nous traitons ci-dessous de lintgration Java, celles
avec les autres tant similaires, mais un peu plus complexes. Auparavant, nous allons
discuter des interfaces gnrales de gestion des bases de donnes et des transactions
qui doivent tre fournies.
SGBDO : dfinir la classe en ODL et crire un compilateur ODL gnrant des dfini-
tions de classes Java, avoir un prprocesseur reconnaissant les classes persistantes ou
ajouter une interface spcifique de persistance ces classes, etc. Le standard actuel ne
se prononce pas sur le moyen de dclarer une classe Java persistante. De telles classes
sont supposes existantes et connues du SGBDO. Elles peuvent alors contenir des
objets persistants, mais aussi toujours des objets transients.
Alors, comment rendre un objet (dune classe persistante) persistant ? Le mcanisme
retenu est la persistance par atteignabilit. Les racines de persistance sont les objets
nomms au moyen de lopration bind de linterface base de donnes vue ci-dessus.
Tout objet rfrenc par un objet persistant est persistant. Tout objet non rfrenc par
un objet persistant doit tre dtruit automatiquement de la base, ce qui sous-entend
lexistence dun ramasse-miettes sur disques. Au-del, le standard propose que les
objets persistants puissent conserver des attributs non persistants, ce qui nest sans
doute pas simple dclarer sans modifier Java.
De manire plus complte, une classe OQLQuery est propose afin de composer des
requtes paramtres OQL sous forme dobjets, de demander leur excution et de
rcuprer les rsultats dans des objets Java, en gnral des collections. La classe
OQLQuery comporte plus prcisment les oprations :
OQLQuery(String question) pour crer des requtes avec le texte param-
tr (les paramtres sont nots $i) en OQL pass en argument ;
OQLQuery() pour crer des requtes gnriques, le texte tant pass ensuite par
lopration create(String query) ;
bind(Object parameter) pour lier le premier paramtre non encore li de la
requte ;
execute() pour excuter une requte pralablement construite et rcuprer un
objet Java de type collection ou simple en rsultat.
Voici une illustration simple de cette classe pour retrouver les buveurs dun cru quel-
conque, par exemple de Volnay ; Java ne supportant pas les associations, on supposera
que lattribut Boire de buveurs est implment comme une collection de vins :
SET BUVEURSCRU;
QUERY = OQLQUERY (SELECT DISTINCT B FROM B IN BUVEURS,
V IN B.BOIRE WHERE V.CRU = $1);
QUERY.BIND(VOLNAY);
BUVEURSCRU = QUERY.EXECUTE();
6.3.6. Bilan
Java OML propose une vision simple dune base de donnes ODMG en Java. La pre-
mire version de cette proposition est assez brivement dcrite dans le standard. Nous
en avons donn un aperu ci-dessus. La cl du problme semble tre dans le support
des collections en Java, qui est loin dtre standard. Le problme de lODMG pourrait
tre terme de faire concider son standard avec le standard Java, notamment pour les
collections. Sinon, il y aurait vraiment opposition de phase (impedance mismatch), ce
qui serait paradoxal ! Ceci ne serait cependant pas tonnant, car peut-on construire
432 BASES DE DONNES : OBJET ET RELATIONNEL
deux standards (un pour les bases de donnes, lautre pour le langage) indpendam-
ment et conserver un systme de type unique ? Une meilleure approche est probable-
ment de dvelopper un langage de programmation bas sur les types du SGBD pour
viter les problmes de conversion de types. Cest ce que propose SQL3, comme nous
le verrons dans le chapitre qui suit.
7. CONCLUSION
Depuis 1991, les vendeurs de SGBDO tentent de crer un standard afin dassurer la
portabilit des programmes utilisateurs, donc des applications. Cette dmarche est
importante car elle seule peut garantir la prennit de lapproche bases de donnes
objet pour les utilisateurs. Deux versions de ce standard ont t publies, lune en
1993, lautre en 1997. Nous nous sommes bass sur la version 1997 (ODMG 2.0)
pour crire ce chapitre. Bien que remarquable, la version 2 est quelque peu complexe
et nest gure supporte par les systmes actuels (ni dailleurs celle de 1993). Aussi,
elle est parfois ingale dans le niveau de dtails fourni. Elle se compose dun modle
abstrait de bases de donnes objet et dinterfaces concrtes pour chacun des langages
supports.
En outre, le langage de requtes OQL constitue une contribution importante de cette
proposition. OQL offre les fonctionnalits du SQL de base avec en plus des exten-
sions pour manipuler les expressions de chemins, les mthodes et surtout les collec-
tions. Cest un langage trs puissant, mais complexe, qui a aussi quelques dficiences,
comme labsence de contrle de droits et de gestion de vues. Il peut tre intgr
C++, Smalltalk et Java de manire standard. Tout ceci est positif.
Alors, peut-on enfin parler de portabilit des applications des SGBDO, par exemple
crites en Java ? Il y a pour linstant peu de retour dexpriences. De plus, les ven-
deurs de SGBDO, lexception sans doute de O2, nimplmentent pas OQL et ne se
soucient finalement gure plus que dans le discours du standard ODMG. Pour garantir
une certaine portabilit, il faut donc utiliser du pur Java, sans requte. Cest encore
faible. Mais que les adeptes des langages objets, et particulirement les dfenseurs de
Java se rassurent : il ny a pas besoin de SGBDO conforme lODMG pour faire per-
sister et retrouver des objets Java et garantir la portabilit des applications. JDBC,
dvelopp par SunSoft, est un package vraiment standard pour faire persister et
retrouver via SQL des objets Java dans toute base de donnes, y compris dailleurs
certaines bases de donnes objet. Vous pouvez aussi regarder du ct de Persistant
Java et dinterfaces plus spcifiques comme JSQL.
Le standard de lODMG : ODL, OQL et OML 433
8. BIBLIOGRAPHIE
[Adiba93] Adiba M., Collet C., Objets et Bases de Donnes : Le SGBD O2, Herms,
Paris, 1993.
Cet ouvrage de 542 pages dcrit la gnration des SGBD objet et dtaille plus
particulirement le SGBD O2. Il dcrit tout le cycle dutilisation de ce SGBD et
les principaux composants du systme.
[Bancilhon89] Bancilhon F., Cluet S., Delobel C., A Query Language for an Object-
Oriented Database System , In 2nd Intl. Workshop on Database Programming
Language, DBPL, p. 301-322, 1989.
Cet article introduit la premire version du langage de requtes du systme O2,
prcurseur du langage OQL. Cette version souligne les aspects fonctionnels du
langage.
[Bancilhon92] Bancilhon F., Delobel C., Kanellakis P., Building an Object-Oriented
Database System : The Story of O2, Morgan Kaufmann Pub., San Fransisco,
CA, 1992.
Ce livre est une collection darticles prsentant lhistoire, la conception et
limplmentation du systme O2, un des premiers SGBD pur objet.
[Chaudhri98] Chaudhri A.B., Workshop Report on Experiences Using Object Data
Management in the Real-World , SIGMOD Record, V. 27, n 1, p. 5-10, Mars
1998.
Cet article rsume les prsentations effectues un Worshop portant sur les
applications relles des BD objet. Il discute en particulier de quelques insuffi-
sances dObjectStore et des multiples diffrences entre O2 et le standard ODMG.
[Ferrandina95] Ferrandina F., Meyer T., Zicari R., Ferran G., Madec J., Schema and
Database Evolution in the O2 Object Database System , Proc. of 21st Intl.
Conf. On Very Large Databases, Zurich, p. 170-181, 1995.
Cet article souligne la difficult dvolution des schmas ODL dans une base
de donnes objet. Il dcrit les algorithmes implments dans O2 pour faire vo-
luer la base en conformit au schma.
[Fishman88] Fishman et. al., Overview of the IRIS DBMS, Hewlett-Packard Internal
Report, Palo Alto, 1988.
Cet article prsente le systme IRIS et son langage OSQL. OSQL est une ver-
sion fonctionnelle dun SQL tendu aux objets. OSQL est un langage qui per-
met de dfinir des types abstraits comme des ensembles de fonctions, de crer
des classes dobjets accessibles par des fonctions, puis dappliquer ces fonc-
tions en les imbriquant partir darguments ventuellement instancis. Il sagit
dun des premiers SQL tendus aux objets bas sur une approche fonctionnelle,
donc un prcurseur de OQL.
434 BASES DE DONNES : OBJET ET RELATIONNEL
LOBJET-RELATIONNEL ET SQL3
1. INTRODUCTION
Le dveloppement des SGBD objet sest rapidement heurt la ncessit de conserver
la compatibilit avec lexistant. En effet, la fin des annes 80 a vu le dploiement des
SGBD relationnels et des applications client-serveur. Les utilisateurs ntaient donc
pas prts remettre en cause ces nouveaux systmes ds le dbut des annes 90.
Cependant, les tables relationnelles ne permettaient gure que la gestion de donnes
alphanumriques. Avec lavnement du Web au milieu de la dcennie 90, la ncessit
de supporter des donnes complexes au sein de la base de donnes sest amplifie.
Ces donnes complexes peuvent tre des documents textuels, des donnes gom-
triques ou gographiques, audiovisuelles ou soniques. En bref, il sagit de supporter
de manire intelligente des donnes multimdia (voir figure XIII.1).
Ce chapitre est consacr ltude du modle objet-relationnel et du langage de
requtes associ SQL3. SQL3 est une extension de SQL2, dveloppe par le groupe
de normalisation ANSI X3 H2 et internationalise au niveau de lISO par le groupe
ISO/IEC JTC1/SC21/WG3. Il sagit de la nouvelle version de SQL. SQL3 comporte
beaucoup daspects nouveaux, lessentiel tant sans doute son orientation vers une
intgration douce de lobjet au relationnel. Ce chapitre traite en dtail de cette intgra-
tion et survole les autres aspects de SQL3.
436 BASES DE DONNES : OBJET ET RELATIONNEL
Types de
donnes
ABC123 Temps
1996
riques. Le concept de table dont les lignes constituent les enregistrements successifs
est simple, bien adapt pour reprsenter par exemple des employs, des services, ou
des paiements. Avec SQL2, les domaines se sont diversifis. Les dates, les monnaies,
le temps et les intervalles de temps sont parfaitement supports.
Dans les annes 80, les SGBD relationnels se sont centrs sur le transactionnel (On
Line Transaction Processing OLTP) et sont devenus trs performants dans ce
contexte. Les annes 90 ont vu le dveloppement du dcisionnel (On Line Analysis
Processing OLAP). Le relationnel sest montr capable dintgrer la prsentation
multidimensionnelle des donnes ncessaire lOLAP. En effet, il est simple de coder
un cube 3D en table, trois colonnes mmorisant les valeurs dune dimension et la qua-
trime la grandeur analyse.
En bref, grce au langage assertionnel puissant que constitue le standard universel
SQL2, sa bonne adaptation aux architectures client-serveur de donnes, sa thorie
bien assise aussi bien pour la conception des bases (normalisation), loptimisation de
requtes (algbre, rcriture, modle de cots) et la gestion de transactions (concur-
rence, fiabilit) intgre, le relationnel sest impos dans lindustrie au cours des
annes 80.
Les objets longs prsentent deux inconvnients majeurs : ils ne sont pas structurs et
ne supportent pas les recherches associatives. La seule possibilit est de les lire
squentiellement. Ils sont donc particulirement insuffisants pour le stockage intelli-
gent de documents structurs, o lon souhaite accder par exemple une section sans
faire dfiler tout le document. En clair, il faut pouvoir lever la contrainte datomicit
des domaines, serait-ce que pour stocker des attributs composs (par exemple
ladresse compose dune rue, dun code postal et dune ville) ou multivalus (par
exemple les points dune ligne).
La non intgration des oprations dans le modle relationnel constitue un manque.
Celui-ci rsulte dune approche traditionnelle o lon spare les traitements des don-
nes. Certes, les procdures stockes ont t introduites dans le relationnel pour les
besoins des architectures client-serveur, mais celles-ci restent spares des donnes.
Elles ne sont pas intgres dans le modle. Il est par exemple impossible de spcifier
des attributs cachs de lutilisateur, accessibles seulement via des oprations manipu-
lant ces attributs privs.
Tout ceci conduit un mauvais support des applications non standard telles que la
CAO, la CFAO, les BD gographiques et les BD techniques par les SGBD relation-
nels. En effet, ces applications grent des objets structures complexes, composs
dlments chans souvent reprsents par des graphes. Le relationnel pur est finale-
ment mal adapt. Il en va de mme pour le support dobjets multimdia que lon sou-
haite pouvoir rechercher par le contenu, par exemple des photos que lon souhaite
retrouver partir dun portrait robot.
Lencapsulation des donnes permet disoler certaines donnes dites prives par des
oprations et de prsenter des interfaces stables aux utilisateurs. Ceci facilite lvolu-
tion des structures de donnes qui peuvent changer sans modifier les interfaces
publiques seules visibles des utilisateurs. Au lieu doffrir des donnes directement
accessibles aux utilisateurs, le SGBD pourra offrir des services cachant ces donnes,
beaucoup plus stables et complets. Ceux-ci pourront plus facilement rester invariants
au fur et mesure de lvolution de la base de donnes.
Lhritage doprations et de structures facilite la rutilisation des types de don-
nes. Il permet plus gnralement ladaptation de composants son application. Les
composants pourront tre des tables, mais aussi des types de donnes abstraits, cest-
-dire un groupe de fonctions encapsulant des donnes caches. Il sera dailleurs pos-
sible de dfinir des oprations abstraites, qui pourront, grce au polymorphisme, por-
ter le mme nom mais sappliquer sur des objets diffrents avec pour chaque type
dobjet un code diffrent. Cela simplifie la vie du dveloppeur dapplications qui na
plus qu se soucier doprations abstraites sans regarder les dtails dimplmentation
sur chaque type dobjet.
Notion XIII.2 : Non premire forme normale (Non First Normal Form NF2)
Forme normale tolrant des domaines multivalus.
EXEMPLE
Services
3. LE MODLE OBJET-RELATIONNEL
Le modle objet-relationnel est fond sur lide dextension du modle relationnel
avec les concepts essentiels de lobjet (voir figure XIII.3). Le cur du modle reste
donc conforme au relationnel, mais lon ajoute les concepts cls de lobjet sous une
forme particulire pour faciliter lintgration des deux modles.
Lobjet-relationnel et SQL3 441
Types utilisateurs
et encapsulation
Rfrence Hritage
et identit Relationnel et rutilisation
Collection
et objets complexes
Le systme de type du SGBD devient donc extensible, et nest plus limit aux types
alphanumriques de base, comme avec le relationnel pur et SQL2. On pourra par
exemple dfinir des types texte, image, point, ligne, etc. Les types de donnes dfinis-
sables par lutilisateur sont appels types abstraits (ADT) en SQL3. La notion de
type abstrait fait rfrence au fait que limplmentation est spcifique de lenvironne-
ment : seule linterface dun type utilisateur est visible.
Les SGBD objet-relationnels offrent diffrents types de collections, tels que le tableau
dynamique, la liste, lensemble, la table, etc. Le patron LISTE(X) pourra par
442 BASES DE DONNES : OBJET ET RELATIONNEL
exemple tre instanci pour dfinir des lignes sous forme de listes de points : LIGNE
LISTE(POINT).
Les rfrences sont les identifiants dobjets (OID) dans le modle objet-relationnel.
Elles sont en thorie des adresses logiques invariantes qui permettent de chaner direc-
tement les objets entre eux, sans passer par des valeurs ncessitant des jointures.
Lhritage de type permet donc de dfinir un sous-type dun type SQL ou dun type
utilisateur. Une table correspondant un type sans opration, lobjet-relationnel per-
met aussi lhritage de table.
OBJET
Accident Rapport Photo
Polymorphisme
RELATIONNEL 134
Types Domaine
utilisateurs Table Collections
Attribut
Cl 219
Rfrence
Opration Identifiant
037
Hritage
Robert 17 134
219
037
Objet Police
8 abandonn
4.3. LA BASE
Le composant 2 contient lessentiel du langage SQL3, en particulier les fonctionnali-
ts de base pour dfinir les autres composants (Basic SQL/CLI capabilities, Basic
SQL/PSM capabilities), les dclencheurs (Triggers), les types utilisateurs appels
446 BASES DE DONNES : OBJET ET RELATIONNEL
types abstraits (Abstract Data Types) et les fonctionnalits orientes objets que nous
allons tudier en dtail ci-dessous. Un mot sur les dclencheurs : bien que partie int-
grante du relationnel tudie en tant que telle au chapitre VIII, les dclencheurs ne
sont normaliss que dans SQL3. Il sagit l de combler une lacune de la normalisa-
tion.
5.1.1. Principes
La premire nouveaut de SQL3 est lapparition dune commande CREATE TYPE.
Au-del des types classiques (numriques, caractres, date) de SQL, il devient pos-
sible de crer des types dpendant de lapplication, multimdia par exemple (voir
figure XIII.8).
Numrique 245
Types Georges
Caractres
simples 20-Dec-98
Date
Texte
Spatial
Types
multimdia Image
Vido
Une instance dun type peut tre un objet ou une valeur. Un objet possde alors un
OID et peut tre rfrenc. Une valeur peut simplement tre copie dans une ligne
dune table. Un type possde en gnral des colonnes, soit directement visibles, soit
Lobjet-relationnel et SQL3 447
caches et accessibles seulement par des fonctions encapsulant le type. Les oprateurs
arithmtiques de SQL (+, *, , /) peuvent tre redfinis au niveau dun type. Par
exemple, on redfinira laddition pour les nombres complexes. Enfin, un type peut
possder des clauses de comparaison (=, <) permettant dordonner les valeurs et peut
tre reprsent sous la forme dun autre type, une chane de caractres par exemple.
5.1.2. Syntaxe
La syntaxe de la commande de dclaration de type est la suivante :
CREATE [DISTINCT] TYPE <NOM ADT> [<OPTION OID>] [<CLAUSE SOUS-TYPE>]
[AS] (<CORPS DE LADT>)
Le mot cl DISTINCT est utilis pour renommer un type de base existant dj, par
exemple dans la commande :
CREATE DISTINCT TYPE EURO AS (DECIMAL(9,2)
La clause :
<OPTION OID> ::= WITH OID VISIBLE
permet de prciser la visibilit de lOID pour chaque instance (objet). Par dfaut, une
instance de type est une valeur sans OID. Cette clause semble plus ou moins avoir dis-
parue de la dernire version de SQL3, le choix tant report sur les implmentations.
La clause :
<CLAUSE SOUS-TYPE> ::= UNDER <SUPERTYPE>[,<SUPERTYPE>]
La dfinition de colonne permet de spcifier les attributs du type sous la forme <NOM>
<TYPE>. Un type peut bien sr tre un type de base ou un type prcdemment cr par
une commande CREATE TYPE. Un attribut peut tre priv ou public, comme en
C++. La clause gale permet de dfinir lgalit de deux instances du type, alors que
la clause infrieure dfinit le comparateur <, important pour comparer et ordonner les
valeurs du type. La clause CAST permet de convertir le type dans un autre type.
Plusieurs clauses CAST sont possibles.
448 BASES DE DONNES : OBJET ET RELATIONNEL
Une dclaration de fonction permet de dfinir les fonctions publiques qui encapsulent
le type. Il existe diffrents types de fonctions : les constructeurs permettent de
construire des instances du type ; ils portent en gnral le nom du type ; les acteurs
agissent sur une instance en manipulant les colonnes du type ; parmi les acteurs, il est
possible de distinguer les observateurs qui ne font que lire ltat et les mutateurs qui
le modifient ; les destructeurs dtruisent les instances et doivent tre appels explici-
tement pour rcuprer la place disque (pas de ramasse-miettes). Plus prcisment, la
syntaxe dune dfinition de fonction est la suivante :
<DCLARATION DE FONCTION> ::=
[<FUNCTION TYPE>] FUNCTION <FUNCTION NAME> <PARAMETER LIST>
RETURNS <FUNCTION RESULTS>
{ <SQL PROCEDURE> | <FILE NAME> } END FUNCTION
Les fonctions SQL3 ne sont pas forcment associes un type ; elles peuvent aussi
tre associes une base ou une table. Elles peuvent tre programmes en SQL, en
SQL/PSM (voir ci-dessous) ou dans un langage externe comme COBOL, C, C++ ou
Java. Comme en C++, un oprateur est une fonction portant un nom particulier et
dclare comme oprateur.
Au-del des types de collections SET, LIST et MULTISET, SQL3 propose des types
additionnels multiples : piles (stack), files (queue), tableaux dynamiques (varray),
tableaux inserables (iarray) pour grer des textes par exemple. Un tableau dynamique
peut grandir par la fin, alors quun tableau insrable peut aussi grandir par insertion
partir dune position intermdiaire (il peut donc grandir par le milieu). Ces types de
collections sont seulement optionnels : ils ne sont pas intgrs dans le langage de base
mais peuvent tre ajouts.
De manire gnrale, il est possible de rfrencer des objets via des OID mmoriss
comme valeurs dattributs. De tels attributs sont dclars rfrences (REF) comme
dans lexemple ci-dessous :
CREATE TYPE VOITURE (NUMRO CHAR(9), COULEUR VARCHAR,
PROPRITAIRE REF(PERSONNE))
450 BASES DE DONNES : OBJET ET RELATIONNEL
en supposant dfinis les types TEXT (texte libre) et IMAGE, qui sont gnralement
fournis avec un SGBD objet-relationnel, comme nous le verrons plus loin.
La table de la figure XIII.6 pourra tre dfinie partir des mmes types avec en plus :
CREATE TYPE CONDUCTEUR (CONDUCTEUR VARCHAR, AGE INT)
CREATE TYPE ACCIDENT (ACCIDENT INT, RAPPORT TEXT, PHOTO IMAGE)
par la commande :
CREATE TABLE POLICE (NPOLICE INT, NOM VARCHAR, ADRESSE ADRESSE,
CONDUCTEURS SET(CONDUCTEUR), ACCIDENTS LIST(ACCIDENT)).
SQL3 donne aussi des facilits pour passer dun type une table de tuples de ce type
et rciproquement, dune table au type correspondant.
Par exemple, en utilisant le type EMPLOY dfini ci-dessus, il est possible de dfinir
simplement une table demploys par la commande :
CREATE TABLE EMPLOYS OF EMPLOY ;
En dfinissant une table VINS, il sera possible de dfinir le type VIN compos des
mmes attributs comme suit :
CREATE TABLE VINS(NV INT, CRU VARCHAR, DEGR FLOAT(5.2))
OF NEW TYPE VIN ;
Comme mentionn, lhritage de table qui recopie la structure est possible par la
clause :
CREATE TABLE <TABLE> UNDER <TABLE> [WITH (LISTE DATTRIBUTS TYPS)].
La liste des attributs typs permet dajouter les attributs spcifiques la sous-table.
Par exemple, une table de vins millsim pourra tre cre par :
CREATE TABLE VINSMILL UNDER VINS WITH (MILLSIME INT, QUALIT VARCHAR).
termes SQL, qui peuvent figurer dans les expressions de valeurs slectionnes ou dans
les prdicats de recherche. Une fonction sapplique laide de la notation parenthse
sur des termes du type des arguments spcifis.
Considrons par exemple la table demploys contenant des instances du type EMPLOY
dfinit ci-dessus. La requte suivante retrouve le nom et lge des employs de moins
de 35 ans :
SELECT E.NOM, AGE(E)
FROM EMPLOYS E
WHERE AGE(E) < 35;
La notation pointe applique au premier argument est aussi utilisable pour invoquer
les fonctions :
SELECT E.NOM, E..AGE()
FROM EMPLOYS E
WHERE E..AGE() < 35;
Il sagit dun artifice syntaxique, la dernire version utilisant dailleurs la double nota-
tion pointe (..) pour les fonctions et attributs composs, la notation pointe simple (.)
tant rserve au SQL de base (accs une colonne usuelle de tuple).
Au-del des fonctions, SQL3 permet aussi laccs aux attributs composs par la notation
pointe. Supposons par exemple une table demploys localiss dfinies comme suit :
CREATE TABLE EMPLOYSLOC UNDER EMPLOYS WITH (ADRESS ADRESSE).
La requte suivante permet de retrouver le nom et le jour de repos des employs des
Bouches-du-Rhne habitant Marseille :
SELECT NOM, REPOS
FROM EMPLOYSLOC E
WHERE DEPT(E.ADRESS) = BOUCHES DU RHONE
AND E.ADRESS..VILLE = MARSEILLE;
La requte suivante recherche alors les noms et adresses de tous les employs moins
de 100 units de distance (par exemple le mtre) de lemploy Georges :
452 BASES DE DONNES : OBJET ET RELATIONNEL
La question suivante retrouve les employs dont la position est contenu dans un cercle
de rayon 100 autour de lemploy Georges :
SELECT E.NAME, E.ADRESS
FROM EMPLOYS G, EMPLOYS E
WHERE EMPLOYS.NOM = GEORGES AND
CONTIENT(E.POSITION, CERCLE(G.POSITION,1));
Les deux requtes prcdentes sont de fait quivalents et gnrent les mmes
rponses.
La requte suivante recherche les noms des propritaires de voitures rouges habitant
Paris :
Lobjet-relationnel et SQL3 453
SELECT V.PROPRIETAIRENOM
FROM VOITURES V
WHERE V.COULEUR = ROUGE AND V.PROPRIETAIREADRESSE..VILLE = PARIS.
La requte suivante retrouve les rfrences des personnes ayant pour passe-temps le
vlo :
SELECT REF(P)
FROM PERSONNES P
WHERE VLO IN
SELECT *
FROM TABLE (P.PASSETEMPS).
Plus complexe, la requte suivante recherche les numros des polices dassurance
dont un accident contient un rapport avec le mot cl Pont de lAlma :
SELECT P.NPOLICE
FROM POLICE P, TABLE P.ACCIDENTS A, TABLE A.RAPPORT..KEYWORDS M
WHERE M = PONT DE LALMA.
Cette requte suppose la disponibilit de la fonction KEYWORDS sur le type TEXT du rap-
port qui dlivre une liste de mots cls. Nous tablons tout dabord la liste des accidents,
puis la liste des mots cls du rapport de chaque accident. Ceci donne donc une sorte
dexpression de chemins multivalus. SQL3 est donc trs puissant !
454 BASES DE DONNES : OBJET ET RELATIONNEL
6. LE LANGAGE DE PROGRAMMATION
PSM
Le composant PSM dfinit un L4G adapt SQL. Il a t adopt tout dabord dans le
cadre SQL2, puis tendu SQL3.
sortie) ou des fonctions (clause RETURN <type>), Ces procdures sont en gnral
invoques depuis des programmes htes par des ordres EXEC SQL plus ou moins
spcifiques du langage hte, ou directement depuis dautres procdures PSM par des
ordres CALL <procdure> ou des appels directs de fonctions.
Une assignation seffectue par une clause SET suivie dune expression de valeur
conforme SQL, ou par lassignation du rsultat dune requte dans une variable. Par
exemple :
DECLARE MOYENNE DECIMAL(7.2)
SELECT AVG(SALAIRE) INTO MOYENNE FROM EMPLOYS
Par exemple :
CASE MOYENNE
WHEN <100 THEN CALL PROC1 ;
WHEN = 100 THEN CALL PROC2 ;
ELSE CALL PROC3 ;
END CASE
Les boucles LOOP, REPEAT et WHILE sont des boucles de calculs en mmoire clas-
siques, qui ne font pas directement appel la base. La boucle FOR permet au contraire
de parcourir le rsultat dune requte par le biais dun curseur. Sa syntaxe simplifie
est la suivante :
<ORDRE FOR> ::=
[<TIQUETTE> :]FOR <NOM DE BOUCLE>
AS [<NOM DE CURSEUR> CURSEUR FOR] <SPECIFICATION DE CURSEUR>
DO
<ORDRE SQL>
END FOR <TIQUETTE> ;
Une procdure pour calculer la variance des quantits commandes dun cru donn en
paramtre peut tre dfinie comme suit :
CREATE PROCEDURE (IN C VARCHAR,
OUT VARIANCE DECIMAL(10.2))
BEGIN
DECLARE MOYENNE DECIMAL(10.2) ;
VARIANCE = 0 ;
SELECT AVG(QUANTITE) INTO MOYENNE
FROM COMMANDES C, VINS V
WHERE V.NV = C.NV AND V.CRU = C ;
BOUCLE1:
FOR M AS SELECT NCO, QUANTIT
FROM COMMANDES C, VINS V
WHERE V.NV = C.NV AND V.CRU = C
DO
SET VARIANCE = VARIANCE+(M.QUANTITE MOYENNE)**2
END FOR BOUCLE1 ;
END
Tout SQL est bien sr intgr PSM. Il serait possible dutiliser un curseur et une
boucle WHILE avec un FETCH dans la boucle la place de la boucle FOR.
Lobjet-relationnel et SQL3 457
Dautres types de boucles peuvent bien sr tre utiliss pour calculer cette fonction
[Melton98].
7. CONCLUSION
SQL3 est un standard en volution. Comme nous lavons vu, les composants ne sont
pas tous au mme niveau davancement. La plupart sont au stade de brouillons inter-
nationaux, et vont donc subir encore des modifications. Lensemble devrait tre ter-
min vers lan 2000.
SQL3 se situe, au moins pour la partie objet et les interfaces avec les langages objet,
comme un concurrent de lODMG. Il est support par tous les grands constructeurs,
comme IBM, Oracle et Sybase, et est impliqu dans un processus de standardisation
international. Au contraire, lODMG est un accord entre quelques constructeurs de
458 BASES DE DONNES : OBJET ET RELATIONNEL
SGBD objet autour dun langage pur objet. LODMG traite bien les aspects collec-
tions et, dans une moindre mesure, traverse de chemins. Les deux propositions pour-
raient donc apparatre comme complmentaires, condition de converger. Il existe
dailleurs un accord entre les groupes ANSI X3 H2 responsable de SQL et ODMG
pour explorer la convergence. Souhaitons que cet accord aboutisse.
Dautres, comme Stonebraker [Stonebraker96], pensent plutt que les bases de don-
nes objet ont un crneau dapplication diffrent de celui des bases de donnes objet-
relationnel. Les premires seraient plutt orientes vers les applications crites en
C++ ou Java, naviguant dans les bases mais ne formulant pas de questions complexes
sur de gros volumes de donnes persistantes. Au contraire, les bases de donnes objet-
relationnel profiteraient de lorientation disque du relationnel et seraient capables de
supporter des questions complexes sur des donnes complexes. La figure XIII.9
rsume ce point de vue. Il est possible de mesurer la complexit des requtes en
nombre de jointures et agrgats, la complexit des donnes en nombre dassociations.
Cependant, lvolution des systmes objet vers la compatibilit SQL, et donc vers
lobjet-relationnel, pousse par le march, ne plaide gure pour la validit de ce
tableau.
Complexit
des requtes
Relationnel
Obbjjeett--rreellaattiioonnn e l
O
ne l
8. BIBLIOGRAPHIE
[Darwen95] Darwen H., Date, Introducing the Third Manifesto , Database
Programming & Design Journal, C-J.vol. 1, n 8, p. 25-35, Jan. 1995.
Cet article plaide pour le modle objet-relationnel vu comme une extension
naturelle du relationnel, tel que propos par Codd (et Date). Pour C. Date,
lapport essentiel utile du modle objet est la possibilit de dfinir des types de
donnes utilisateur. En clair, aucune modification nest ncessaire au modle
relationnel qui avait dj le concept de domaine : il suffit douvrir les domaines
et de les rendre extensibles.
[Gardarin89] Gardarin G., Cheiney J.P., Kiernan J., Pastre D., Managing Complex
Objects in an Extensible DBMS , 15th Very Large Data Bases International
Conference, Morgan Kaufman Pub., Amsterdam, Pays-Bas, aot 1989.
Une prsentation dtaille du support dobjets complexes dans le SGBD exten-
sible Sabrina. Ce systme est driv du SGBD relationnel SABRE et fut lun des
premiers SGBD supportes des types abstraits comme domaines dattributs. Il
a ensuite volu vers un SGBD gographique (GoSabrina) qui fut commercia-
lis par la socit INFOSYS.
[Gardarin92] Gardarin G., Valduriez P., ESQL2: An Object-Oriented SQL with F-
Logic Semantics , 8th Data Engineering International Conf., Phnix, Arizona,
Feb. 1992.
Cet article dcrit le langage ESQL2, prcurseur de SQL3 compatible avec
SQL2, permettant dinterroger la fois des bases de donnes objets et rela-
tionnelles. Le langage supporte des relations rfrenant des objets complexes.
Une notation fonctionnelle est utilise pour les parcours de chemins et les
applications de mthodes. Une version plus labore de ESQL2 avec classes et
relations a t spcifie dans le projet EDS. La smantique base sur la F-
Logic (une logique pour objets) illustre les rapports entre les modles objets et
logiques.
[Godfrey98] Godfrey M., Mayr T., Seshadri P., von Eicken T., Secure and Portable
Database Extensibility , Proc. of the 1998 ACM SIGMOD Intl. Conf. On
Management of Data, ACM Pub. SIGMOD Record vol. 27, n 2, p. 390-401,
Juin 1998.
Cet article dcrit limplmentation de types abstraits dans le SGBD PREDATOR
en Java. Il montre lintrt de fonctions sres et portables, mais souligne aussi les
difficults de performance par comparaison une implmentation en C++.
[Haas90] Haas L., Chang W., Lohman G.M., McPherson J., Wilms P.F., Lapis G.,
Lindsay B., Pirahesh H., Carey M., Shekita E., Starburst Mid-Flight : As the
Dust Clears , IEEE Transactions on Knowledge and Data Engineering, vol. 2,
n 1, Mars 1990.
460 BASES DE DONNES : OBJET ET RELATIONNEL
OPTIMISATION
DE REQUTES OBJET
1. INTRODUCTION
Une des fonctionnalits essentielles des systmes objet ou objet-relationnel est la pos-
sibilit dinterroger la base partir de requtes non procdurales, exprimes en OQL
ou en SQL3 (voir chapitre prcdent). Ces requtes peuvent invoquer des oprations
sur des types de donnes utilisateur. En effet, dans les SGBD objet ou relationnel-
objet, lutilisateur, ou plutt un implmenteur systme, peut ajouter ses propres types
de donnes, avec des comparateurs logiques et des mthodes daccs spcifiques.
Loptimiseur doit alors tre extensible, cest--dire capable de supporter une base de
rgles de connaissances pouvant tre tendue par lutilisateur afin dexplorer un
espace de recherche plus riche pour les plans dexcution.
Un premier problme est dtre capable de gnrer tous les plans dexcution pos-
sibles pour une requte complexe. Ceci ncessite tout dabord des techniques de
rcriture de requtes en requtes quivalentes. La rcriture peut seffectuer au
niveau de la requte source ; plus souvent, elle sapplique sur des requtes traduites en
format interne, sous forme darbres algbriques. De nombreux travaux ont t effec-
tus sur les techniques de rcriture de requtes objet [Graefe93, Haas89, Cluet92,
Mitchell93, Finance94, Florescu96].
464 BASES DE DONNES : OBJET ET RELATIONNEL
Un deuxime problme est le choix des algorithmes et mthodes daccs les plus per-
formants pour raliser une opration de lalgbre dobjets. Ce choix est plus riche que
dans le cas relationnel pour les jointures qui peuvent maintenant seffectuer directe-
ment par traverses de pointeurs. Le support direct de pointeurs sous forme didenti-
fiants invariants est en effet une des fonctionnalits nouvelles des systmes objet, per-
mettant la navigation. Le choix des algorithmes daccs va dpendre du modle de
stockage qui inclut de nouvelles techniques dindexation de chemins et de groupage
dobjets. Dautres problmes difficiles sont la mise en place doprateurs spcifiques
sur collections et des index sur fonctions. Nous examinerons plus particulirement les
nouveaux algorithmes de traverses de chemins.
Comme dans le cas relationnel, le choix du meilleur plan ncessite un modle de cot
permettant destimer le cot dun plan la compilation. Ce modle doit prendre en
compte les groupages dobjets, les parcours de pointeurs, les index de chemins, et
aussi les mthodes utilisateur. Ceci pose des problmes difficiles. Plusieurs modles
ont t proposs [Bertino92, Cluet92]. Nous en proposons un prenant en compte le
groupage des objets.
Si lon est capable de gnrer tous les plans candidats pour calculer la rponse une
requte et destimer le cot de chacun, il faut encore choisir le meilleur plan. Une
stratgie exhaustive nest pas possible compte tenu du grand nombre de plans en
gnral. Des stratgies de recherche sophistiques ont t proposes, depuis loptimi-
sation itrative [Ioannidis90, Lanzelotte91] jusqu la recherche gntique [Tang97].
Nous donnons dans ce chapitre une vue densemble des mthodes alatoire de
recherche de plan optimal.
Ce chapitre prsente une synthse des techniques essentielles de loptimisation des
requtes dans les bases de donnes objet, au-del du relationnel. Il sappuie en partie
sur les travaux de recherche que nous avons mens au laboratoire PRiSM de
Versailles de 1990 1996. Ces techniques commencent aujourdhui tre intgres
dans les SGBD objet-relationnel et objet. Dans la section suivante, nous dtaillons
plus particulirement la problmatique doptimisation spcifique lobjet, en lillus-
trant par quelques exemples. Dans la section 3, nous introduisons un modle de stoc-
kage gnrique pour bases de donnes objet. La section 4 se consacre aux algorithmes
de traverse de chemins. Nous donnons diffrents algorithmes de parcours dassocia-
tions et de collections imbriques qui gnralisent les algorithmes de jointures en cas-
cade aux bases de donnes objet. La section 5 discute de la gnration des plans qui-
valents et des types de rgles de rcriture considrer. Elle conduit dvelopper une
architecture type pour un optimiseur extensible. La section 6 dveloppe un modle de
cot pour SGBD objet. Nous examinons ensuite dans la section 7 les diffrentes stra-
tgies de recherche du meilleur plan proposes par les chercheurs. Nous terminons le
chapitre en proposant une stratgie gntique originale applique au choix dalgo-
rithmes de traverses de chemins.
Loptimisation de requtes objet 465
2. PROBLMATIQUE
DES REQUTES OBJET
Dans cette section, nous examinons plus particulirement les problmes soulevs par
loptimisation de requtes OQL ou SQL3 par rapport aux requtes purement relation-
nelles, cest--dire exprimes en SQL2.
deviennent alors trs difficiles, les mthodes rellement appliques ntant connues
qu la compilation.
Habite
Personnes Pays
nom Nom
adresse
telephones
* *
Ligne
Commandes * Produits
numco numpro
etat Quantit nom
date marque
responsable prix
prix()
On note que les chemins sont monovalus. Il est aussi possible de parcourir des che-
mins multivalus, en utilisant par exemple des collections dpendantes en OQL. La
question suivante recherche par exemple les clients qui ont command des produits de
prix suprieur 10 000 :
(Q2) SELECT C.NOM, C.ADRESSE
FROM CLIENTS C, C.PASSE M, M.LIGNE P
WHERE P.PRIX > 10.000
Loptimiseur doit alors tre capable dvoluer en prenant en compte les nouveaux
types et les rgles doptimisation des oprations sur ces types. Par exemple, on pourra
maintenant rechercher tous les fournisseurs localiss dans une zone donne ( :Z) et
moins de 100 km dun client donn ( :N) par la requte :
(Q3) SELECT NUMFOU, NOM, ADRESSE
FROM CLIENTS C, FOURNISSEURS F
WHERE C.NUMCLI = :N AND INCLUS( :Z, F.LOCALISATION)
AND DISTANCE(C.LOCALISATION, F. LOCALISATION) < 100 ;
468 BASES DE DONNES : OBJET ET RELATIONNEL
Supposons maintenant que les types figure et cercle soient connus du SGBD exten-
sible, dfini comme suit :
TYPE FIGURE (ATTRIBUT CONTOUR LIST<POINT> ;
BOOLEAN FUNCTION INCLUS (P POINT, F FIGURE))
TYPE CERCLE (ATTRIBUT CENTRE POINT, RAYON REAL ;
CERCLE FUNCTION CERCLE(C POINT, R REAL) ;
FIGURE FUNCTION INTERSECTION(C CERCLE, Z ZONE)).
Une requte quivalente la requte prcdente consiste chercher tous les fournis-
seurs inclus dans la figure gomtrique rsultant de lintersection de la zone paramtre
et dun cercle de centre le client et de rayon 100 km, ce qui donne :
(Q4) SELECT NUMFOU, NOM, ADRESSE
FROM CLIENTS C, FOURNISSEURS F
WHERE C.NUMCLI = :N
AND INCLUS(F.LOCALISATION, INTERSECTION(CERCLE(C.LOCALISATION,100),:Z)
Un bon optimiseur doit tre capable de dterminer le meilleur plan dexcution pour
cette requte. Il doit donc sapercevoir de lquivalence des formulations. Voil qui
nest pas chose simple et demande de bonnes notions de gomtrie !
Grce aux proprits des ensembles, plus particulirement de loprateur dunion par
rapport lappartenance, elle doit pouvoir tre transforme en une requte plus simple.
3. MODLE DE STOCKAGE
POUR BD OBJET
Dans cette section, nous introduisons un modle de stockage gnral pour bases de
donnes objet. Ce modle intgre diffrentes variantes didentifiants dobjets, de tech-
niques de groupages dobjets et dindexation. Il est suffisamment gnral pour repr-
senter les mthodes de stockage existant dans les SGBD. Lobjectif est dillustrer les
techniques possibles, qui nous servirons plus loin de base aux calculs des cots
daccs.
Objet 1
Objet 2
Objet 3
Fentes
Les identifiants physiques sont rapides dcoder pour atteindre lobjet rfrenc. Par
contre, ils ne permettent pas le dplacement libre des objets dans la base. En cas de
dplacement, une technique de chanage doit tre mise en place : lentre de la page
initiale doit indiquer que lobjet nest plus dans la page et pointe sur son nouvel iden-
tifiant physique. Cette technique de suite (forwarder) est trs lourde grer, surtout si
les objets se dplacent souvent. On lui prfrera les identifiants logiques, plus coteux
lors de laccs mais invariants au dplacement dobjet.
En cas de dplacement de lobjet, seule lentre dans la table est change ; elle est
positionne la nouvelle adresse de lobjet. En gnral, les SGBD grent une table
didentifiant logique par type dobjets. La taille de la table est ainsi limite. Pour la
limiter plus encore et viter les entres inutiles, la table est souvent organise comme
une table hache : chaque identifiant logique est affect une entre dtermine par
une fonction de hachage ; chaque entre contient des couples de correspondance
<identifiant logique-identifiant physique>. La figure XIV.3 illustre le dcodage dun
identifiant logique.
Un bon modle de stockage permet la fois les identifiants physiques (OIDP) et les
identifiants logiques (OIDL). Le choix du type didentifiants affecte directement le
cot de traverse des pointeurs.
Loptimisation de requtes objet 471
OID logique
Objet 1
Objet 2
Objet 3
OID physique
Page
Il existe diffrents types dindex de chemins [Bertino89, Kim89]. Les index de che-
min simples [Bertino89] [Kemper90] associent pour chaque valeur figurant la fin
du chemin tous les identifiants dobjets suffixes du chemin. Ils peuvent tre impl-
ments comme des relations : chaque colonne dun tuple correspond une collection
du chemin, en remontant depuis la fin du chemin. Le premier attribut contient la
valeur figurant la fin du chemin, les suivants contiennent des identifiants dobjets
dsignant les objets successivement rencontrs en parcourant le chemin lenvers. La
figure XIV.4 illustre un index de chemins simple pour le chemin Produits
Fournisseurs Pays de la base reprsente figure XIV.1.
472 BASES DE DONNES : OBJET ET RELATIONNEL
vendu habite
Produits Fournisseurs Pays
Une premire variante consiste imbriquer les chemins, en vitant ainsi de rpter plu-
sieurs fois un mme identifiant dobjet pour chacun de ses parents. Par exemple, pour le
fournisseur F1, on indiquera directement la liste des parents, pour F2 de mme, si bien
que lentre Allemagne de lindex prcdent devient (Allemagne(F1(P1, P2) F2 (P1,
P3) ). Un tel index est appel index de chemin imbriqu [Bertino91]. De tels index
sont plus difficiles maintenir et utiliser que des tables lors des mises jour.
Les multi-index [Kim89] sont une alternative aux index de chemin. Pour chaque
couple de collections (Ci, Ci+1) conscutives du chemin, on gre un index de jointure
[Valduriez87] contenant les couples identifiants dobjets lis par le chemin. Le dernier
index est un index classique donnant pour chaque valeur terminale du chemin lidenti-
fiant de lobjet contenant cette valeur. Le parcours du chemin seffectue alors par des
intersections de listes didentifiants. Chaque index est finalement un index classique
qui peut tre implment comme un arbre B. Le problme des multi-index est que
chaque index doit tre lu ou crit indpendamment, ce qui ncessite des entres-sor-
ties supplmentaires par rapport aux index de chemin. Lutilisation de tels index est
par contre plus large, par exemple pour acclrer des jointures de collections interm-
diaires sur le chemin ou des slections sur la collection feuille.
plusieurs objets relis par des identifiants logiques ou physiques. On distingue alors la
liaison de lincorporation dobjets.
La liaison peut tre effectue dans les deux sens, lobjet rfrenc pointant lui-mme
son ou ses objets associs. Il existe alors pour chaque objet cible un ou plusieurs liens
inverses vers lobjet source. La liaison est une technique classique pour reprsenter
les associations ncessitant le parcours didentifiants pour retrouver les objets asso-
cis. La liaison inverse permet le parcours de lassociation dans les deux sens. La liai-
son a le mrite de rendre les objets lis quasiment indpendants, ce qui nest pas le cas
avec lincorporation.
Lincorporation rend les objets incorpors dpendants de lobjet englobant : ils sont
dtruits avec lui. Le choix entre liaison ou incorporation est donc aussi un problme
de smantique : un objet incorpor a le mme cycle de vie que lobjet incorporant. Du
point de vue stockage, lincorporation prsente lavantage de rendre les objets incor-
porant et incorpor accessibles simultanment. En outre, elle permet le placement des
objets dans une mme page, ce qui est aussi possible avec la liaison comme nous le
verrons ci-dessous. Elle prsente par contre linconvnient de ne pas supporter le par-
tage rfrentiel des objets dpendants, qui sont de fait copis sils sont rfrencs
ailleurs. La figure XIV.5 illustre la liaison et lincorporation dans le cas de com-
mandes et de lignes de commandes.
Commandes Commandes
C1 C1
Ligne Ligne Ligne
L1 L2 L3
P1-10 P2-15 P3-7
Le groupage est plus souple que lincorporation car il permet une vie autonome des
objets lis, qui peuvent exister sans objets associs. En cas dobjets sans matre ou
dobjets partags par plusieurs matres, le choix de la page de stockage nest pas vi-
dent. Pour capturer une large classe de stratgies de groupage, il est possible de dfi-
nir les groupes par des prdicats de slection ou dassociation. Un prdicat de slec-
tion permet par exemple de dfinir le groupe des commandes de prix suprieur
10 000 (Commandes.prix>10.000). Un prdicat dassociation permet par
exemple de dfinir un groupe pour chaque produit (Produits vendu
Fournisseurs). Ces prdicats sont utiliss pour dfinir les ensembles dobjets
stocker ensemble dans une mme page ou au moins dans des pages proximit.
Les prdicats ntant pas forcment disjoints, un objet peut appartenir logiquement
plusieurs groupes. Si lon exclut les duplications dobjets, il faut lors du chargement
choisir un groupe. Une technique possible consiste associer des priorits chaque
prdicat de liens. Si un objet appartient deux groupes ou plus, celui de priorit sup-
rieure est retenu. Pour pouvoir discriminer les groupes, les priorits doivent tre diff-
rentes, dfinies par exemple par un nombre de 0 10.
Afin de visualiser les informations de spcifications des groupes, il a t propos
[Amsaleg93] dutiliser un graphe de groupage dfini comme suit :
Un graphe de groupage est correct si tous les arcs pointant vers un mme nud ont
une priorit diffrente. Les objets points par plusieurs liens de groupage sont donc
assigns au groupe de plus forte priorit. La figure XIV.6 prsente diffrents graphes
de groupage possibles pour les fournisseurs, les produits et les commandes. Elle sup-
pose que lassociation directe des fournisseurs aux produits est gre par le SGBD.
droite du graphe de groupage, les groupes de diffrents types possibles sont repr-
sents, par exemple les groupes de fournisseurs, de produits, ou les groupes mixtes.
Loptimisation de requtes objet 475
Fournisseurs
Produits
Fournisseurs
Produits Commandes
Clients Produits
5 10
Commandes
min par lobjet matre selon larc de poids maximal. Par exemple, figure XIV.6c,
chaque objet commandes sera stock prs de son fournisseur sil existe.
Habite
Personnes Pays
nom Nom
adresse
telephones
Clients Fournisseurs
Passe numcli numfou Vendu
type commentaire
7 10
* *
Ligne
Commandes * Produits
numco 3 numpro
etat Quantit nom
date marque
responsable prix
prix()
4. PARCOURS DE CHEMINS
Optimiser la navigation dans une base de donnes objet est lun des soucis essentiels
dun optimiseur. Ce problme prolonge loptimisation des squences de jointures dans
les bases de donnes relationnelles. Dans cette partie, nous prsentons plusieurs algo-
rithmes pour valuer une expression de chemins avec prdicats. De tels algorithmes
ont t tudis dans [Bertino91, Shekita90, Gardarin96]. Ils correspondent des types
varis de traverse dun graphe dobjets. Un tel graphe est reprsent figure XIV.8.
Chaque famille verticale dobjets correspond une collection Ci (par exemple, une
extension de classes). Chaque objet de la collection Ci pointe sur 0 N objets de la
collection Ci+1, selon les cardinalits des associations traverses. Nous crivons
lexpression de chemin C1(P1).C2(P2)Cn(Pn) en dsignant par Pi le prdicat de
slection de la collection Ci. Il sagit donc dassembler les squences c1.c2cn
dobjets lis par des pointeurs et vrifiant respectivement (c1 C1 et P1), (c2 C2 et
P2) (cn Cn et Pn).
// Recherche des objets dun chemin C1.C2Cn vrifiant les prdicats P1,P2Pn
DFF(C1(P1).C2(P2)....Cn(Pn)) {
i = 1 ;
while (in) {
for each x in (Ci) {
if Pi(x) = VRAI {
if i < n return (x + DFF(FETCH(x.Ci+1)(Pi+1).Cn(Pn)))
else return(x) }
}
i = i+1 ;
}
}
Lavantage de DFF est quil sagit dun oprateur n-aire qui ne gnre pas de rsultats
intermdiaires. Lalgorithme assemble les objets en accdant via les OID, ce qui est
efficace dans la plupart des SGBD. Les rsultats sont obtenus lun aprs lautre en
pipeline. Lalgorithme est dailleurs trs analogue celui de jointures n-aire en pipe-
line vu dans le cadre relationnel, ceci prs quil navigue en suivant les pointeurs.
Ainsi le SGBD peut-il retourner une rponse avant davoir travers tous les objets.
Intuitivement, cet oprateur est trs efficace lorsque la taille mmoire est suffisante
Loptimisation de requtes objet 479
pour contenir tous les objets sur un chemin de la racine aux feuilles, cest--dire au
moins une page par collection. Cependant, si les objets ne sont pas groups selon le
chemin et si la taille mmoire est insuffisante, le systme peut tre conduit relire de
nombreuses fois une mme page.
T12 T13
C1 C2 C1 C3
a1 b5 a1 c5
FJ FJ
a2 b2 a1 c7
a3 b1 a3 c1
a4 b3 a4 c2
C1 C2 T12 C3
a5 b2 a5 c8
a6 b4 a6 c4
(a) (b)
a7 b1 a6 c2
Lavantage de lalgorithme en largeur dabord est dtre bas sur des jointures binaires
par rfrence, donc pr-calcules. Le cot de calcul est donc rduit. Cependant, pour
accomplir la jointure entre les collections Ci et Ci+1, les tats des objets de la premire
collection Ci doivent tre chargs en mmoire pour trouver les pointeurs vers les objets
de Ci+1 (contenus dans lattribut Ai) ; les tats de la seconde Ci+1 doivent aussi tre
chargs en mmoire pour tester le prdicat Pi+1. Si aucun groupage selon lassociation
480 BASES DE DONNES : OBJET ET RELATIONNEL
nest ralis, des accs multiples alatoires aux pages peuvent tre ncessaires. Un tri
des identifiants des objets de la deuxime collection sera alors souvent avantageux.
Contrairement lalgorithme DFF, lalgorithme BFF ncessite de conserver si possible
en mmoire des rsultats intermdiaires. Si lon veut dlivrer tous les objets sur les che-
mins qualifiants, la table support doit tre tendue avec un attribut contenant les identi-
fiants dobjets par collection traverse. Lalgorithme ne permet gure de dlivrer des
rsultats avant la traverse totale au moins des n-1 premires collections. Soulignons
que dans le cas rduit de deux collections, les algorithmes DFF et BFF sont similaires.
T32 T31
C3 C2 C3 C1
c1 b2 c1 a2
RJ RJ
c2 b5 c1 a4
c2 b4 c2 a5
c4 b7 c4 a7
C3 C2 T32 C1
c4 b4 c6 a4
c7 b2 c6 a1
(a) (b)
c6 b1 c6 a6
La traverse lenvers est avantageuse lorsquune slection directe est possible sur la
dernire collection (par exemple par un index) et que cette slection retrouve un
nombre faible dobjets (forte slectivit). Pour mmoriser le parcours, une table sup-
Loptimisation de requtes objet 481
port est gnre (voir figure XIV.11). Un avantage de la mthode est qu chaque pas
la jointure est faite entre cette table support et la collection prcdente sur le chemin.
Lalgorithme est bon si la table support est petite (expression de chemin slective).
Soulignons quune expression de chemins peut toujours tre divise en plusieurs sous-
expressions, chacune pouvant tre traite avec un algorithme diffrent, DFF, BFF ou
RBFF. Si un prdicat trs slectif est rapidement valuable sur une collection du che-
min, on aura avantage considrer RBFF pour la partie prfixant cette collection, puis
BFF ou DFF pour la partie suffixe. Le choix dun algorithme ou dun autre nest pas
vident et ncessite un modle de cot, comme nous le verrons plus loin.
Cette notion doptimiseur extensible a t bien formalise pour la premire fois dans
[Grafe93]. Un optimiseur extensible est construit autour dune base de connaissance
mmorisant les dfinitions de types et oprateurs associs, de mthodes daccs, de
fonctions de cot et de rgles de transformation de plans dexcution. Toutes les trans-
formations de plans peuvent tre exprimes sous la forme de rgles. Comme en rela-
tionnel, les rgles permettent de transformer les arbres doprateurs de lalgbre repr-
sentant les requtes en arbres quivalents. Au-del du relationnel, pour supporter les
types de donnes utilisateurs, lalgbre relationnelle doit tre tendue en une algbre
dobjets complexes, avec en particulier les fonctions dans les expressions de qualifica-
tion et de projection, et le support doprations sur collections imbriques telles que
Nest, Unnest et Flatten. Une telle algbre a t prsente au chapitre XI.
Nous reprsentons figures XIV.12 et XIV.13 les questions Q1 et Q3 du paragraphe 2.2
sous la forme darbres algbriques. Larbre de la figure XIV.12 contient trois restric-
tions sur attributs ou mthodes, suivies de deux jointures par rfrences qui traduisent
le parcours de chemin. Ces deux jointures peuvent par exemple tre remplaces par un
oprateur de parcours du graphe en profondeur dabord (DFF) vu ci-dessus, ou par
des jointures en arrire (RBFF). Une projection finale gagnerait tre descendue par
les rgles classiques vues en relationnel.
Rsultats
P.nom,
F. adresse
habite
Pays P
vendu
F.age() > 50
Produits P
Fournisseurs F
tion de telles requtes est difficile et ncessite des connaissances spcifiques sur les
fonctions utilisateurs [Hellerstein93], ici des fonctions gomtriques.
Rsultats
F.numfou,
F.nom, F.adresse
C.numcli = :N
Clients C
Inclus(:Z, F.localisation)
Fournisseurs F
Dautres rgles ne sont applicables que dans un sens et peuvent ncessiter des condi-
tions. titre dexemple, nous les crirons sous la forme suivante :
<SOUS-ARBRE> [<CONDITION>] <SOUS-ARBRE>.
Une telle rgle signifie que lorsquun sous arbre est rencontr, si la condition option-
nelle est satisfaite, il peut tre rcrit dans le sous-arbre figurant aprs limplication.
En pratique, il faut en plus appliquer quelques procdures par exemple pour changer
484 BASES DE DONNES : OBJET ET RELATIONNEL
des variables ou des annotations ; celles-ci sont supposes attaches la rgle ; elles
ne sont pas mentionnes pour des raisons de simplicit.
Toutes les rgles classiques de lalgbre relationnelle peuvent ainsi tre codes, avec
plus ou moins de difficults. Il est possible aussi dajouter des rgles prenant en
compte les oprations sur collections, NEST,UNNEST et FLATTEN. Par exemple, la
rgle permettant de pousser une restriction avant une opration dimbrication NEST
peut scrire :
RESTRICT(NEST(X, G, N), Q) [ ATTRIBUT(Q) G ]
RESTRICT(NEST(RESTRICT(X, Q1), G, N), Q2) ;
Cette rgle exprime le fait que si une restriction est applique sur certains attributs de
groupement, alors la partie de la restriction concernant ces attributs peut tre appli-
que avant le groupement.
Au-del, des rgles de simplification peuvent aussi tre introduites pour isoler des
sous-arbres identiques et les remplacer par une relation intermdiaire utilisable en plu-
sieurs points. Ce genre de rgles est important car il permet dviter de calculer deux
fois la mme sous-question. Son expression gnrale ncessite un langage de rgles
un peu plus puissant, permettant de tester si deux sous-arbre sont quivalents.
Les expressions sont des termes fonctionnels du langage OQL, cest--dire des
expressions de chemins, des prdicats avec expressions de chemins ou des requtes.
De telles rgles permettent dexprimer divers types de contraintes, comme lexistence
de liens inverses et la redondance de donnes. Considrons par exemple la dfinition
en ODL de la base dcrivant pays et clients, en supposant ces classes lies par une
association 1N :
INTERFACE CLIENTS {
ATTRIBUT INT NUMCLI KEY, STRING NOM,
ADRESSE CADRESSE, REF(PAYS) CPAYS, INT TELEPHONE,
INT SEGMENT, STRING COMMENTAIRE }
INTERFACE PAYS {
ATTRIBUT INT NUMPAYS KEY, STRING NOM, INT NUMCONT,
STRING COMMENTAIRE, RESIDENTS SET <CLIENTS>}
La rgle de lien inverse spcifiant quun client rfrence un pays sil est rsident de ce
pays scrit :
FOR ALL C OF TYPE CLIENTS, P OF TYPE PAYS
C.CPAYS = P C IN P.RESIDENTS.
Supposons en plus que les adresses contiennent le pays :
INTERFACE ADRESSE {
ATTRIBUT INT NUM, STRING RUE,
STRING VILLE, INT ZIP, STRING PAYS }
Une rgle exprimant une redondance de valeurs est :
FOR ALL C OF TYPE CLIENTS
C.CADRESSE.PAYS C.CPAYS.NOM
De telles quivalences sont trs puissantes et permettent dexprimer toutes sortes de
redondances, par exemple lexistence de vues matrialises ; lquivalence peut tre
remplace par une implication. Les quivalences ou implications peuvent tre facile-
ment tendues pour exprimer des impossibilits, telles que la valeur nulle interdite ou
lunicit de cl (absence de doubles). Il est aussi possible de prendre en compte des
assertions dinclusion et des assertions dappartenance [Florescu96].
Par exemple, une rgle exprimant la non-nullit de lattribut pays peut scrire :
FOR ALL C OF TYPE CLIENTS C
C.CPAYS = NIL
Une rgle exprimant lunicit de la cl de client scrit :
FOR ALL C1,C2 OF TYPE CLIENTS
C1.NUMCLI = C2.NUMCLI C1 = C2
INTERFACE IMAGE {
ATTRIBUT NUMCLI INT, CONTENT ARRAY[1024,1024] INT,
OPERATION
ARRAY[10] SUMMARY(IMAGE),
IMAGE ROTATE (IMAGE, ANGLE),
IMAGE CLIP (REGION) }
Considrons la requte suivante qui recherche les images des clients du segment 5, les
intersecte avec une fentre prdfinie $zone, et les fait tourner de 90 avant de les
afficher :
SELECT CLIP(ROTATE(I,90),$ZONE)
FROM CLIENTS C, IMAGES I
WHERE C.NUMCLI = I.NUMCLI
AND C.SEGMENT = 5 ;
Il apparat que plutt de faire tourner les images, on aurait intrt faire lintersection
(le clip) avec la zone tourne de 90, et faire tourner seulement la partie intres-
sante. Lquivalence de termes est aussi trs approprie la dfinition daxiomes sur
des types abstraits. Par exemple, la transformation ncessaire pour rcrire la question
prcdente de manire plus optimise est :
FOR ALL I OF IMAGE, F OF FENETRE
CLIP(ROTATE(I,$A), F) ROTATE(CLIP(I,ROTATE(F,-$A),$A).
Pour les systmes objet, il est possible de les tendre [Gardarin96] par quelques rgles
permettant de prendre en compte les traverses de chemin, avec les algorithmes prsen-
ts dans la section 4. Ces nouvelles rgles concernent lutilisation de loprateur DFF
de parcours en profondeur dabord, des jointures par rfrences et des index de che-
mins. JOINFJ dsigne la jointure par rfrence en avant non considre ci-dessus et
JOINRJ la jointure par rfrence en arrire. JOINPATH-INDEX dsigne lalgorithme de
jointure exploitant lexistence dun index de chemin. On obtient les nouvelles rgles :
1. Jointure en avant ou en arrire :
A JOINFJ B A JOINRJ B
2. Dcoupage et groupage de traverses en profondeur dabord :
DFF(A,B,C...N) JOIN(DFF(A,B..x-1),DFF(x...N))
3. Utilisation dindex de chemin :
JOINFJ(X,Y) [PATH-INDEX(X,Y)] JOINPATH-INDEX(X,Y)
DFF(A,B,C...N)[PATH-INDEX(A,B,C...N)] JOINPATH-INDEX(X,Y)
Pour simplifier, supposons labsence dindex de chemins. Chaque collection est relie
chacune de ses voisines par une association multivalue (le cas monovalu est un
cas dgnr).
teur n-aire de jointure par rfrence parcourant le graphe en profondeur dabord. Dans
le cas o DFF nest pas utilis, le problme revient calculer le nombre dordres de
jointures possibles avec deux oprateurs de jointures en vitant les produits cartsiens
[Tan91], [Lanzelotte93]. On obtient pour lespace de recherche de jointures binaires
de n collections :
(2n 2)! n1
BJ_SS(n) = *2
n!(n 1)!
1 1 5 256
2 2 6 1544
3 9 7 9910
4 45 8 65462
Arbre Schma de
algbrique stockage
Plans dexcution
Gnrateur Rgles
de plans de transformation
action : { }
cot : rel
but : boolen Plan quasioptimal
respond au temps pass excuter des instructions de lunit centrale, par exemple
pour valuer un prdicat ou excuter une boucle. Le deuxime correspond au temps
de lecture et criture sur disques. Le troisime intervient surtout dans les bases rpar-
ties o des changes de messages sont ncessaires sur le rseau.
Dans cette section, nous prsentons un modle de cot pour bases de donnes objet,
publi dans [Gardarin95]. Considrant une base centralise, nous valuons seulement
les cots dentres-sorties et de calcul. Pour simplifier, nous supposons que les objets
ont une taille infrieure une page et que les valeurs dattributs sont uniformment
distribues lintrieur de leurs domaines de variation.
Dans le cas de plusieurs collections groupes, certaines pages peuvent tre homo-
gnes, dautres contenir des objets de diffrentes collections. Une mthode pour esti-
mer le nombre total de pages dune collection groupe avec dautres a t propose
dans [Tang96]. Supposons que la collection B soit groupe avec la collection A (voir
figure XIV.17). Rappelons que nous notons respectivement SA et S B les tailles
moyennes des objets des collections A et B, et que SA et SB sont supposes inf-
rieures la taille de la page. Estimons tout dabord la taille de la collection A qui est
la racine de larbre de groupage. Il existe deux partitions physiques pour A aprs le
492 BASES DE DONNES : OBJET ET RELATIONNEL
placement des deux collections, lune contenant des objets groups avec des objets de
B note ClAB, lautre ne contenant que des objets de A note ClA.
ClA
ClAB
A
ClB
Pour ClAB, le nombre dobjets de A dans cette partition est AXA,B. La taille
dun groupe autour dun objet A est SClAB = SA+(ZA,B*SB), do lon dduit :
A XA, B
si S C l < Sp
Sp AB
A C l = SC l
AB AB
A X A, B si S C l Sp
AB
Pour ClAB, la taille et le nombre dobjets par groupe reste le mme que celui cal-
cul ci-dessus, mais le nombre de groupes auxquels accder est maintenant
XClAB= Min(ZA,B*XA,B, XA,B). Nous obtenons donc :
A C l si S C l < Sp
AB AB
sinon
B C l = A X A, B si Z A, B * S B S p
AB
Z A, B * S B
(A X A, B) * si Z A, B * S B > S p
Sp
Dans le cas dune collection C groupe avec dautres, il nest pas possible dappliquer
simplement la formule de Yao pour estimer le nombre de pages auxquelles accdes
lors dune slection par un prdicat P par Yao(C,C,Sel(P)*C). Le problme est
quune collection groupe est compose de plusieurs partitions. Certains objets sont
groups avec des objets de collections diffrentes. Ainsi, la distribution des objets
dans les pages nest pas uniforme, bien que les collections soient supposes indpen-
dantes dun point de vue probabiliste. Il est possible dappliquer la formule de Yao
494 BASES DE DONNES : OBJET ET RELATIONNEL
chaque partition, aprs avoir dtermin la taille de chaque partition comme vu ci-des-
sus, soit ||C||i objets et |C|i pages pour la partition i. Nous obtenons alors la formule de
Tang pour le calcul des entre-sorties [Tang96].
Si les objets slectionner sont placs uniformment dans les partitions, on slec-
tionne ki = (Ci/C)*k dans la partition i. Quand les objets qui satisfont le prdicat
de recherche ne sont pas placs uniformment, il faut calculer la slectivit du prdi-
cat dans chaque partition pour calculer ki. Bien que drive de la formule de Yao, la
formule de Tang est plus gnrale que celle de Yao, qui en est un cas particulier pour
une collection avec une seule partition.
Par exemple, si une classe Gomtrie publie une fonction distance(gomtrie), elle
pourra aussi publier une fonction cot_distance(gomtrie). Le cot pourra tre trs dif-
frent selon les gomtries sur lesquelles sapplique la fonction : il est par exemple beau-
coup plus simple de calculer la distance de deux points que celle de deux polygones.
Au dpart, le cot de la mthode est inconnu, et estim par exemple comme une pro-
jection sur attribut. Puis, suite aux requtes ou des demandes destimation de
ladministrateur (par une requte spcifique ANALYZE <mthode>), la mthode
est excute sur un chantillon de N objets. Une table est gre dans la mta-base
pour maintenir le cot moyen observ, de schma simplifi COSTMETHOD (cot
real, nombre int), cot tant le cot moyen et nombre le nombre dexcu-
tions observes. La table peut aussi mmoriser le type des paramtres, les heures
dappels, etc., afin dobtenir des statistiques plus fines.
Le cot de calcul associ lvaluation dun tel prdicat est le cot de projection plus
le cot dvaluation des prdicats lmentaires pour chaque objet travers, soit :
CPU_Eval_Cost(P) = C 1 * (CPU_Pr oj_Cost
n i
+ CPU_Comp_Cost) * fan C , C * S j 1)
i = 2i = 2 j1 J
7. STRATGIES DE RECHERCHE
DU MEILLEUR PLAN
La recherche du meilleur plan dexcution dans une base de donnes objet ou objet-
relationnel est encore plus complexe que dans une base relationnelle. En effet,
lespace des plans est plus large du fait de la prsence de rfrences, dindex de che-
mins, de collections imbriques, etc. Au-del de la programmation dynamique clas-
sique limite des espaces de recherche de faible taille [Swami88, Swami89,
Vance96] vue dans le cadre relationnel, des mthodes doptimisation pour la
recherche de plans optimaux base sur des algorithmes alatoires ont t proposes.
Aprs les avoir prsents, nous proposons une mthode plus avance base sur des
algorithmes gntiques.
Procedure II(Question) {
p = Initial(Question); // gnrer un plan intial
PlanOptimal = p; // Initialiser le plan optimal
while not(condition_arrt) do { // Boucle doptimisation globale
while not (condition_locale) do { // Boucle doptimisation locale
p = dplacer(p); // Appliquer une transformation valide p
if (Cot(p)<Cot(p)) then p = p; // Garder si moins coteux
}
// Slectionner le plan optimal
if cot(p)<cot(PlanOptimal) then PlanOptimal = p;
p = Random(p) ; // Se dplacer au hasard vers un autre plan
}
Return(PlanOptimal);
}
Procdure SA(Question) {
p = Initial(Question); // gnrer un plan intial
PlanOptimal = p; // Initialiser le plan optimal
T = T0; // Initialiser la temperature
while not(condition_arrt) do { // Boucle doptimisation globale
while not(equilibrium) do { // Boucle doptimisation locale
p = dplacer(p); // Appliquer une transformation valide p
delta = cost(p)-cost(p); // Calculer la diffrence de cot
if (delta<0) then p = p; // Si cot rduit prendre le nouveau plan
// Si cot accru, accept si chaud
if (delta>0) then p = p with probability e delta/T;
// Maintenir le plan optimal
if cost(p)<cost(PlanOptimal) then PlanOptimal = p;
}
T = reduce(T); // Reduire la temprature
}
Return(PlanOptimal); }
Procedure TS(Question) {
p = Initial(Question); // gnrer un plan intial
PlanOptimal = p; // Initialiser le plan optimal
T = ; // initialiser la liste taboue
while not(condition_arrt) do { // boucle globale
// accepter tous les mouvements non tabous
gnrer V*N(p)-T en appliquant dplacer(p);
choisir le meilleur plan p V*; // Prendre le meilleur plan
T= (T-(plus vieux)){p}; // Mettre jour la taboue liste
// maintenir le plan optimal
if cot(p)<cot(PlanOptimal) then PlanOptimal = p;
}
return(PlanOptimal);
}
tive (II) et loptimisation deux phases (TP) utilisent une transformation alatoire pour
explorer cet espace. Pour amliorer les performances de ces algorithmes, des
mthodes de transformation darbres introduisant une meilleure couverture de
lespace de recherche ont t mises au point. Ce sont par exemple lchange de join-
tures et le swap [Swami89, Lanzelotte93]. Lchange de jointure permute alatoire-
ment des relations alors que le swap change des parties darbres. De telles mthodes
ont t introduites seulement pour les jointures relationnelles. Il est possible de les
tendre au cas objet.
Suite aux mouvements ascendants, SA est gnralement plus lent que les autres
mthodes mais trouve souvent de meilleurs plans que II quand le temps de recherche
est suffisant. TP combine les avantages de SA et II. Il a t montr [Ioannidis90] que
TP trouve en gnral de meilleurs plans que SA et II. TS est rapide mais accomplit
une recherche agressive. En consquence, lalgorithme peut rester bloqu sur un mini-
mum local. Ceci peut tre vit avec une longue liste taboue, mais la recherche ralen-
tit alors lalgorithme.
II, SA, TP et TS utilisent tous une fonction appele dplacer. Celle-ci applique
lune des rgles de transformation pour trouver un plan quivalent. Comme vu ci-des-
sus, dans une base de donnes objet ou objet-relationnel avec beaucoup de types, le
nombre de rgles peut tre important. Certaines ne provoquent que de petits dplace-
ments dans lespace des plans, dautres de beaucoup plus larges. Il faudrait donc pou-
voir introduire des transformations permettant dappliquer des squences de rgles, et
donc de faire de grands sauts dans lespace des plans. Nous allons tudier une
mthode permettant de telles transformations dans la section suivante.
8. UN ALGORITHME DOPTIMISATION
GNTIQUE
Dans cette section, nous tudions lapproche gntique et son application possible
loptimisation de requtes [Bennett91]. Pour lillustrer concrtement, nous tudions le
cas de longues expressions de chemins avec prdicats. Les expressions de chemins
sont importantes dans les BD objets ; certains SGBD se concentrent dailleurs sur leur
optimisation et ne proposent gure dautres optimisations.
Initialisation
Mutation Croisement
valuation
Tri
Slection
Fin ?
Non
Dans tous les cas, le nombre de gnes est de lordre de O(n2). Un plan dexcution
peut tre vu comme une combinaison de gnes dont le rsultat permet le parcours du
chemin, dans un sens ou dans lautre, ceci afin de trouver le rsultat de la requte.
Lobjectif de loptimiseur est de trouver la meilleure combinaison de gnes pour obte-
nir le plan de cot minimal.
504 BASES DE DONNES : OBJET ET RELATIONNEL
DFF/PI
(0,4)
DFF/PI DFF/PI
(0,3) (1,4)
0 1 2 3 4
DFF/PI DFF/PI
(3,0) (4,1)
DFF/PI
(4,0)
DFF RJ
A B C D A DFF
B C D
FJ Si liens inverses FJ
A B B A
RJ RJ
FJ C FJ A
A B B C
DFF PI
A B C A B C
RJ
FJ DFF
A DFF
E F G
B C D
crossover
RJ
FJ RJ
FJ RJ
D E
FJ
C F G
A B
Procedure GA(Question) {
Gnrer(Popu[BasePopu]) ; // Initialiser la population alatoirement
Sort(Popu) ; // Trier la population des plans par cot croissant
PlanOptimal = Popu[0] ; // Garder le meilleur plan trouv
While not (condition_arrt) do {
Pourcent = 0;
While Pourcent < Part * BasePopu do {
// Appliquer croisement Part de la population
p1 = Popu[Random(BasePopu)] ; // Choisir p1 et p2 de Popu
p2 = Popu[Random(BasePopu)] ; // alatoirement
Croisement(p1, p2) ; // Les croiser si possible
Pourcent = Pourcent + 2 ;
}
For le reste de Popu do Mutation ; // Mutation pour les autres
For (i=0 ; i < NewPopu ; i++) do evaluate(Popu[i]) ; // Calcul du cot
Trier(Popu) ; // Trier la population par cot croissant
PlanOptimal = Popu[0] ; // Garder le meilleur plan trouv
}
return(PlanOptimal) ;
}
Des expriences effectues avec cet algorithme ont montr quil pouvait tre amlior
en ajoutant des plans alatoirement gnrs chaque gnration, ceci afin de garantir
la diversit des plans explors [Tang96]. Les limites de tels algorithmes doptimisa-
tion appliqus aux bases de donnes, notamment dans le cas dun trs grand nombre
de rgles, restent encore dcouvrir.
9. CONCLUSION
Dans ce chapitre, nous avons tudi diffrentes techniques doptimisation pour les
SGBD objet. Tout dabord, les techniques de groupage des objets sur disques permet-
tent de placer proximit les objets souvent accds ensemble, par exemple via des
parcours de chemins. Elles prolongent les techniques de groupage des relations par
jointures pr-calcules de certains SGBD relationnels. Au-del, les index de chemins
constituent aussi une spcificit des BD objet ; ils peuvent tre perus comme une
extension des index de jointure des BD relationnelles.
Ensuite, nous avons tudi diffrents algorithmes de parcours de chemins. Ces algo-
rithmes permettent la navigation ensembliste dans les BD objet. Ils sont des exten-
sions naturelles des algorithmes de jointures [Valduriez87], quils tendent en utilisant
des identifiants dobjets.
La gnration de plans quivalents est plus complexe que dans le cas relationnel, surtout
par la ncessit de prendre en compte les types de donnes utilisateurs et les rcritures
dexpressions de mthodes associes. Ceci ncessite le dveloppement doptimiseurs
extensibles, supportant lajout de rgles de rcriture. Ce sont de vritables systmes
experts en optimisation, qui sont maintenant au cur des SGBD objet-relationnel.
Le dveloppement dun modle de cot pour bases de donnes objet est un problme
des plus difficiles. Il faut prendre en compte de nombreuses statistiques, les groupes,
les rfrences, les index de chemins, les mthodes et les diffrentes formes de collec-
tions. Nous avons prsent un modle de cot simple labor par extension des
modles classiques des BD relationnels. Peu doptimiseurs prennent en compte un
modle de cot intgrant les spcificits de lobjet, par exemple les mthodes.
Beaucoup reste faire.
Nous avons enfin dvelopp des stratgies de recherche sophistiques pour trouver le
meilleur plan dexcution. Beaucoup ont t proposes et paraissent suffisantes pour
des questions mettant en jeu une dizaine de collections. Au-del, les stratgies gn-
tiques semblent prometteuses. Peu de SGBD utilisent aujourdhui ces stratgies, la
plupart restant bass sur la programmation dynamique. Lintgration dans des sys-
tmes pratiques reste donc faire.
508 BASES DE DONNES : OBJET ET RELATIONNEL
10. BIBLIOGRAPHIE
[Amsaleg93] Amsaleg L., Gruber O., Object Grouping in EOS , Distributed Object
Management, Morgan Kaufman Pub., San Mateo, CA, p. 117-131, 1993.
EOS est un grant dobjets un seul niveau de mmoire ralis lINRIA de
1990 1995. Une technique originale de groupement dobjets avec priorit a
t propose, ainsi que des techniques de ramassage de miettes.
[Bertino89] Bertino E., Kim W., Indexing Techniques for Queries on Nested
Objects , IEEE Transactions on Knowledge and Data Engineering, vol. 1(2),
June 1989, p. 196-214.
Cet article compare diffrentes techniques dindexation pour les bases de don-
nes objet, en particulier plusieurs techniques dindex de chemins et dindex
spars ou groups (multi-index) dans le cas de hirarchie de gnralisation.
[Bertino91] Bertino E., An Indexing Technique for Object-Oriented Databases ,
Proceedings of Int. Conf. Data Engineering, Kobe, Japan, p. 160-170, April
1991.
Cet article dveloppe le prcdent et propose des techniques de recherche et
mise jour avec index de chemin.
[Bertino92] Bertino E., Foscoli P., An Analytical Model of Object-Oriented Query
Costs , Persistent Object Systems, Workshop in Computing Series, Springer-
Verlag, 1992.
Les auteurs dveloppent un modle de cot analytique pour BD objet. Celui-ci
prend notamment en compte les index de chemin.
[Bennett91] Bennett K., Ferris M.C., Ioannidis Y.E., A Genetic Algorithm for
Database Query Optimization , Proc. 4th International Conference on Genetic
Algorithms, San Diego, CA, p. 400-407, June 1991.
Cet article a propos pour la premire fois lutilisation dun algorithme gn-
tique dans les bases de donnes objet.
[Christophides96] Christophides V., Cluet S., Moerkotte G., Evaluating Queries
with Generalized Path Expressions , Proceedings of the 1996 ACM SIGMOD
International Conference on Management of Data, ACM Ed., 1996.
Cet article propose dtendre OQL avec des expressions de chemin gnrali-
ses, par exemple traversant de multiples associations. Des techniques dva-
luation de telles expressions de chemin sont discutes. Il est montr comment
ces techniques peuvent tre intgres dans le processus doptimisation.
[Cluet92] Cluet S., Delobel C., A General framework for the Optimization of Object-
Oriented Queries , Proceedings of the 1992 ACM SIGMOD International
Conference on Management of Data, ACM Ed., p. 383-392, 1992.
Loptimisation de requtes objet 509
peut lui mme contenir une question imbrique. Cet article dcrit la stratgie
doptimisation de questions implmente.
[Ozsu95] Ozsu T., Blakeley J.A., Query Processing in Object-oriented Database
Systems , Modern database systems, edited by W. Kim, p. 146-174, 1995.
Cet article prsente une vue densemble des techniques doptimisation dans les
BD objet : architecture, techniques de rcriture algbriques, expressions de
chemins, excution des requtes. Cest un bon tutorial sur le sujet.
[Shekita89] Shekita E. J., Carey M. J., A Performance Evaluation of Pointer-Based
Joins , Proceddings of the 1990 ACM SIGMOD Intl. Conference on
Management of Data, New Jersey, p. 300-311, May 1990.
Cet article dcrit trois algorithmes de jointures bass sur des pointeurs. Ce sont
des variantes des boucles imbriques, du tri-fusion et du hachage hybride. Une
analyse permet de comparer ces algorithmes aux algorithmes correspondants
qui ne sont pas bass sur des pointeurs. Il est montr que lalgorithme naturel
de traverse en profondeur est peu efficace.
[Steinbrunn97] Steinbrunn M., Moerkotte G., Kemper A., Heuristic and
Randomized Optimization for the Join Ordering Problem , VLDB Journal,
p. 191-208, 1997.
Les auteurs prsentent une description assez complte et une valuation com-
pare de tous les algorithmes doptimisation combinatoire proposs pour les
bases de donnes.
[Swami88] Swami A. N., Gupta A., Optimization of Large Join Queries ,
Proceedings of the 1988 ACM SIGMOD Intl. Conference on Management of
Data, Chicago, Illinois, p. 8-17,1988.
Il sagit du premier article ayant introduit les techniques doptimisation ala-
toire pour chercher le meilleur plan dexcution. Les auteurs montrent que le
problme de recherche du meilleur plan est NP complet. Les mthodes combi-
natoires doptimisation telles que litration itrative et le recuit simul sont
alors proposes. Des comparaisons montrent lintrt de lamlioration itra-
tive.
[Swami89] Swami A. N., Optimization of Large Join Queries : Combining
Heuristics and Combinatorial Techniques , Proceedings of the 1989 ACM SIG-
MOD Conference, Portland, Oregon, 1989, p. 367-376.
Les auteurs discutent la combinaison dalgorithmes combinatoires tels que
lamlioration itrative et le recuit simul avec des heuristiques doptimisation
comme laugmentation, lamlioration locale et KBZ. Laugmentation consiste
choisir les relations dans un certain ordre croissant selon une mesure simple
la taille, la taille du rsultat attendu, la slectivit, le nombre de relations joi-
gnant, etc. Lheuristique KBZ consiste tudier tous les arbres drivant dun
514 BASES DE DONNES : OBJET ET RELATIONNEL
AU-DEL DU SGBD
BASES DE DONNES
DDUCTIVES
1. INTRODUCTION
Depuis que la notion de base de donnes dductive est bien comprise [Gallaire84],
sous la pression des applications potentielles, les concepteurs de systmes sefforcent
de proposer des algorithmes et mthodes efficaces pour raliser des SGBD dductifs
traitant de grands volumes de faits (les bases de donnes classiques) et de rgles.
Lobjectif est de fournir un outil performant pour aider la rsolution de problmes,
exprims sous forme de requtes, dont la solution ncessite des volumes importants
de donnes et de rgles. Les applications potentielles sont nombreuses. Outre la ges-
tion classique ou prvisionnelle, nous citerons par exemple laide la dcision, la
mdecine, la robotique, la productique et plus gnralement toutes les applications de
type systmes experts ncessitant de grands volumes de donnes. Il a mme t pos-
sible de penser que lcriture de rgles rfrenant de grandes bases de donnes rem-
placerait la programmation classique, au moins pour les applications de gestion. Ces
espoirs ont t quelque peu dus, au moins jusqu aujourdhui.
Ce chapitre introduit la problmatique des SGBD dductifs, puis prsente le langage
standard dexpression de rgles portant sur de grandes bases de donnes, appel
DATALOG. Celui-ci permet les requtes rcursives. Nous tudions les extensions de
518 BASES DE DONNES : OBJET ET RELATIONNEL
ce langage, telles que le support des fonctions, de la ngation, des ensembles. Ensuite,
nous abordons les problmes de lvaluation de questions sur des relations dduites.
Aprs une brve vue densemble, nous introduisons quelques techniques de reprsen-
tation des rgles par les graphes, puis nous nous concentrons sur la rcursion. Les
mthodes gnrales QoSaQ et Magic sont prsentes. Quelques mthodes plus spci-
fiques sont rsumes. Avant un bilan en conclusion, nous abordons, travers des
exemples, les langages de rgles pour BD objet.
Le langage de rgle est donc utilis afin de spcifier les parties conditions et actions
des rgles de dduction. Plus prcisment, partir des prdicats B1, B2... Bn dfinis
dans la base implante (extensionnelle), le langage de rgles permet de spcifier com-
ment construire des prdicats drivs R1,R2... interrogeables par les utilisateurs. Un
langage de rgles peut donc tre peru comme une extension des langages de dfini-
tion de vues et de triggers des SGBD relationnels classiques.
Lextension est de taille car le langage de dfinition et de manipulation de connais-
sances va intgrer les fonctionnalits suivantes :
1. la possibilit deffectuer les oprations classiques du calcul relationnel (union, res-
triction, projection, jointure, diffrence) ;
Bases de donnes dductives 519
2. le support des ensembles incluant les fonctions dagrgats traditionnelles des lan-
gages relationnels classiques ainsi que les attributs multivalus ;
3. la rcursivit, qui permet de dfinir une relation dduite en fonction delle-mme ;
4. la ngation, qui permet de rfrencer des faits non existants dans la base ;
5. les fonctions arithmtiques et plus gnralement celles dfinies par les utilisateurs ;
6. les mises jour des faits au travers des rgles ;
7. la modularit avec la gestion de niveaux dabstraction successifs et de mta-rgles.
En bref, toutes les facilits qui existent dans les langages de dveloppement de bases
de donnes vont chercher figurer dans les langages de rgles. Lobjectif vis est
dailleurs de remplacer ces langages.
SGBD
SGBD
Couplage fort
Couplage faible
lg. intgr
MOTEUR RGLES
SGBD
Intgration
Une base de donnes est manipule par des programmes logiques constitus dune
suite de clauses de Horn qui dfinissent des prdicats intentionnels. Un prdicat
intentionnel est donc dfini par un programme de rgles logiques ; il correspond une
vue du modle relationnel.
Une base de donnes logique est constitue dun ensemble de prdicats extensionnels
constituant la base de donnes extensionnelle et dun ensemble de prdicats intention-
nels constituant la base de donnes intentionnelle. Les rgles permettant de calculer
les instances des prdicats intentionnels sont donc partie intgrante de la base de don-
nes logique. Elles sont crites dans le langage DATALOG bas sur les clauses de
Bases de donnes dductives 521
Horn. La figure XV.2 illustre les notions de bases de donnes extensionnelle et inten-
tionnelle, la seconde tant drive de la premire par des rgles stockes dans la mta-
base du SGBD.
QUESTIONS INFORMATIONS
MISES JOUR
BD intentionnelle
Mta-donnes
RGLES
BD extentionnelle
Donnes
BD
Infrence
Tables Rgles
3. LE LANGAGE DATALOG
Le langage DATALOG est driv de la logique du premier ordre. Cest la fois un
langage de description et de manipulation de donnes. Le modle de description de
donnes support par DATALOG est essentiellement relationnel, une relation tant
vue comme un prdicat de la logique. Le langage de manipulation est un langage de
rgles bti partir des clauses de Horn. Le nom DATALOG signifie logique pour
les donnes . Il a t invent pour suggrer une version de PROLOG (le langage de
programmation logique) utilisable pour les donnes. Dans cette section, nous tudions
tout dabord la syntaxe de DATALOG, puis sa smantique.
Q est appel tte de rgle ou conclusion ; P1, P2 Pn est appel corps de rgle ou
prmisse ou encore condition. Chaque Pi est appel sous-but. En appliquant lqui-
valence Q P P Q, une rgle scrit aussi (P1, P2Pn) Q ; puis en
appliquant (P1, P2) P1 P2, on obtient P1 P2 Pn Q. Donc,
une rgle est une clause de Horn avec au plus un littral positif (la tte de rgle Q).
La figure XV.4 donne un exemple de programme DATALOG dfinissant une base de
donnes extensionnelle dcrivant les employs (prdicat extensionnel EMPLOYE) et
les services (prdicat extensionnel SERVICE) dune grande entreprise. La base de
donnes intentionnelle spcifie le chef immdiat de chaque employ (prdicat
DIRIGE1), puis le chef du chef immdiat (prdicat DIRIGE2).
{
/* Dclaration des prdicats extensionnels */
EMPLOYE(NomService : String, NomEmploye : String) ;
SERVICE(NomService : String, NomChef : String) ;
/* Dfinition des prdicats intensionnels */
DIRIGE1(x,y) SERVICE(z,x), EMPLOYE(z,y)
DIRIGE2(x,y) DIRIGE1(x,z), DIRIGE1(z,y)
}
Un autre exemple de programme DATALOG est prsent figure XV.5. Il dfinit une
base de donnes extensionnelle compose de pays et de vols ariens reliant les capi-
tales des pays. La base de donnes intentionnelle permet de calculer les capitales
proches (prdicat CPROCHE) comme tant les capitales atteignables lune depuis
lautre en moins de cinq heures dans les deux sens. Les pays proches (prdicat
PPROCHE) sont ceux ayant des capitales proches.
{
/* Dclaration des prdicats extensionnels */
PAYS(Nom : String, Capitale : String, Pop : Int) ;
VOLS(Num : Int, Depart : String, Arrivee : String, Duree : Int) ;
/* Dfinition des prdicats intensionnels */
CPROCHE(x,y) VOLS(z,x,y,t), t5, VOLS(w,y,x,u), u5 ;
PPROCHE(x,y) PAYS(x,u,p), PAYS(y,v,q), CPROCHE(u,v) ;
}
Parmi les rgles, il en existe une classe particulirement importante par la puissance
quelle apporte au langage : il sagit des rgles rcursives qui permettent de dfinir
un prdicat intentionnel en fonction de lui-mme.
Une rgle rcursive dont le prdicat de tte apparat une seule fois dans le corps est
dite linaire. Une rgle non linaire est quadratique si le prdicat de tte apparat
deux fois dans le corps. Au-del, une rgle rcursive dont le prdicat de tte apparat n
(n 3) fois dans le corps devient difficilement comprhensible.
La figure XV.6 illustre quelques exemples de rgles rcursives.
{
/* Dirige tout niveau spcifi par une rgle rcursive linaire */
DIRIGE(x,y) DIRIGE1(x,y) ;
DIRIGE(x,y) DIRIGE1(x,z), DIRIGE(z,y) ;
/* Dirige tout niveau spcifi par une rgle rcursive quadratique */
DIRIGE(x,y) DIRIGE1(x,y) ;
DIRIGE(x,y) DIRIGE(x,z), DIRIGE(z,y) ;
/* Liaisons effectuables par tapes de moins de 5 heures */
LIAISON(x,y) VOLS(z,x,y,t), t 5 ;
LIAISON(x,y) LIAISON(x,z), LIAISON(z,y) ;
}
Chaque relation rcursive ncessite une rgle dinitialisation non rcursive, puis une
rgle de calcul rcursive. Le premier couple de rgles dfinit qui dirige qui et ce,
tout niveau. Le deuxime dfinit la mme relation, mais en utilisant une rgle non
linaire. Le dernier couple spcifie les liaisons ariennes possibles entre capitales par
des suites de liaisons simples effectues en moins de cinq heures.
La figure XV.7 spcifie en DATALOG la clbre base de donnes des familles partir
des prdicats extensionnels PERE et MERE indiquant qui est pre ou mre de qui. La
relation rcursive ANCETRE a souvent t utilise pour tudier les problmes de la
rcursion. Nous avons ajout la dfinition des grand-parents comme tant les parents
des parents et celle des cousins comme tant deux personnes ayant un anctre com-
mun. Les amis de la famille (AMIF) sont les amis (prdicat extensionnel AMI) ou les
amis de la famille des parents. Les cousins de mme gnration (prdicat MG) se
dduisent partir des frres ou surs. Notez que cette dfinition est large : elle donne
non seulement les cousins, mais aussi soi-mme avec soi-mme (vous tes votre
propre cousin de niveau 0 !), les frres et surs, puis vraiment les cousins de mme
gnration.
{
/* Prdicats extensionnels Pre, Mre et Ami */
PERE(Pre String, Enfant String)
MERE(Mre String, Enfant String)
AMI(Personne String, Personne String)
/* Parent comme union de pre et mre */
PARENT(x,y) PERE(x,y) ;
PARENT(x,y) MERE(x,y) ;
/* Grand-parent par auto-jointure de parents */
GRAND-PARENT(x,z) PARENT(x,y), PARENT(y,z) ;
/* Anctre dfini par une rgle linaire */
ANCETRE(x,y) PARENT(x,y) ;
ANCETRE(x,z) ANCETRE(x,y), PARENT(y,z) ;
/* Cousin partir danctres */
COUSIN(x,y) ANCETRE(z,x), ANCETRE(z,y) ;
/* Ami de la familles comme ami des anctres */
AMIF(x,y) AMI(x,y) ;
AMIF(x,y) PARENT(x,z), AMIF(z,y) ;
/* Cousins de mme gnration partir des parents */
MG(x,y) PARENT(z,x), PARENT(z,y) ;
MG(x,y) PARENT(z,x),MG(z,u),PARENT(u,y) ;
}
Plus gnralement, une relation rcursive est une relation dfinie en fonction delle-
mme. Une relation rcursive nest pas forcment dfinie par une rgle rcursive. En
effet, des rgles mutuellement rcursives permettent de dfinir une relation rcursive.
Plus prcisment, il est possible de reprsenter la manire dont les prdicats dpen-
dent lun de lautre par un graphe de dpendance. Les sommets du graphe sont les
prdicats et un arc relie un prdicat P un prdicat Q sil existe une rgle de tte Q
dans laquelle P apparat comme un sous-but. Un prdicat intentionnel est rcursif sil
apparat dans un circuit. La figure XV.8 illustre un programme DATALOG avec
rcursion mutuelle. Le prdicat R est rcursif.
{
R(x,y) B(x,y) ;
R(x,y) P(x,z), B(z,y) ;
P(x,y) R(x,z), C(z,y) ;
}
SERVICE(informatique,Pierre)
EMPLOYE(informatique,y) DIRIGE1(Pierrre,y)
EMPLOYE(informatique,Julie)
DIRIGE(Pierre, Julie)
et de la rgle
DIRIGE1 (x,y) SERVICE (z,x), EMPLOYE (z,y)
a en particulier pour modles :
1. { EMPLOYE (informatique,Pierre), EMPLOYE (informatique,Julie), SERVICE
(informatique,Pierre), DIRIGE1 (Pierre,Julie), DIRIGE1 (Pierre,Pierre) } ;
2. { EMPLOYE (informatique,Pierre), EMPLOYE (informatique,Julie),
SERVICE (informatique,Pierre), DIRIGE1 (Pierre,Julie), DIRIGE1 (Pierre,Pierre),
DIRIGE1 (Julie,Julie)} ;
Le plus petit modle est :
{ EMPLOYE (informatique,Pierre), EMPLOYE (informatique,Julie),
SERVICE (informatique,Pierre), DIRIGE1 (Pierre,Julie),
DIRIGE1 (Pierre,Pierre) }.
Il dfinit donc la smantique du programme DATALOG.
on calcule :
TP = { PARENT = PARENT PERE;
PARENT = PARENT MERE;
ANCETRE = PARENT;
ANCETRE = ANCETRE 1,4 (PARENT ANCETRE); }
Ainsi, si la relation PERE (Pre, Enfant) contient les faits PERE (Julie,Pierre) et
PERE (Jean,Paul), on en dduit :
PERE (Julie,Paul), PERE (Julie,Jean), PERE (Julie,Julie),
PERE (Pierre,Julie), PERE (Pierre,Jean), PERE (Pierre,Paul), etc.
Lhypothse du monde ferm est une rgle puissante pour infrer des faits ngatifs.
Elle suppose quun domaine peut prendre toutes les valeurs qui apparaissent dans la
base (domaine actif) et que tous les faits correspondant ces valeurs non connus sont
faux [Reiter78]. Pour tre valide, cette hypothse ncessite des axiomes additionnels
tels que lunicit des noms et la fermeture des domaines [Reiter84].
Par exemple, en prsence de valeurs nulles dans les bases de donnes, lhypothse du
monde ferm est trop forte car elle conduit affirmer comme faux des faits inconnus.
Les thoriciens se sont penchs sur des hypothses plus fines, tolrant les valeurs
nulles [Reiter84]. Une variante de lhypothse du monde ferme consiste modifier la
mthode de rsolution permettant de rpondre une question en supposant faux tout
fait qui ne peut tre prouv comme vrai. Cette approche est connue comme la nga-
tion par chec.
Bases de donnes dductives 533
En fait, le plus petit modle dune strate est calcul partir du plus petit modle de la
strate prcdente, la ngation tant remplace par un test de non-appartenance. Si M
est le plus petit modle de la strate Si-1, P(x) est interprt comme P(x) nappar-
tient pas M dans la strate Si.
Tout programme DATALOG nest pas stratifiable ; il doit tre possible de calculer
compltement toute lextension dun prdicat avant dutiliser sa ngation pour pou-
voir stratifier un programme. Cela nest pas vrai si la rcursion traverse la ngation.
Les programmes stratifiables ont un plus petit modle unique qui est caractris en
dfinissant un ordre partiel entre les prdicats. Lordre correspond un calcul de plus
petit modle strate par strate en utilisant lhypothse du monde ferm.
Par exemple, les programmes :
{P(x) P(x)} et
{ PAIRE(0); IMPAIRE(x) PAIRE(x) ; PAIRE(x) IMPAIRE(x) }
ne sont pas stratifiables car la ngation se rencontre sur un cycle de rcursion (cest--
dire traverse la rcursion). Le programme
{ R(1) ; P(1) ; P(2) ; Q(x) R(x); T(x) P(x),Q(x)}
est stratifiable; deux strates possibles sont :
S1 = {R(1) ; Q(x) R(x)} puis
S2 = { P(1) ; P(2) ; T(x) P(x), Q(x)};
S1 calcule Q sans utiliser Q, puis S2 calcule T en utilisant Q et P. Le plus petit
modle de S1 est {R(1); Q(1)}. Celui de S2 est {R(1); Q(1); T(2)}. Notez que lordre
de calcul des prdicats est fondamental : si on commenait calculer T avant Q, on
obtiendrait T(1) et un rsultat qui ne serait pas un modle.
La ngation en corps de rgle est importante car elle permet de raliser la diffrence rela-
tionnelle. La stratification correspond la smantique couramment admise en relation-
nelle : avant dappliquer une diffrence une relation, il faut calculer compltement cette
relation (autrement dit, le pipe-line est impossible avec loprateur de diffrence).
La ngation en tte de rgle est donc interprte comme une suppression. Cest elle
qui confre rellement la non monotonie des programmes DATALOG. Au-del, il
est possible de placer plusieurs prdicats en tte dune rgle DATALOG. Supporter
la fois les rgles ttes multiples et des prdicats ngatifs en tte de rgle conduit
permettre les mises jour dans le langage de rgles. On parle alors du langage DATA-
LOG avec mise jour, not DATALOG*.
Par exemple, la rgle suivante, dfinie sur la base de donnes intentionnelle
{ PARENT(Ascendant, Descendant), ANCETRE(Ascendant, Descendant) } est une
rgle DATALOG* :
ANCETRE(x,z), ANCETRE(z,x) PARENT(x,y), ANCETRE(y,z)
Cette rgle gnre de nouveaux anctres et supprime des cycles qui pourraient appa-
ratre dans la relation anctre (si x est le parent de y et y lanctre de z, alors x est
lanctre de z mais z nest pas lanctre de x).
Une interprtation de DATALOG* est possible partir des rgles de production, trs
populaires dans les systmes experts. Une rgle de production est une expression de
la forme :
<condition> <expression dactions>.
Une expression dactions est une squence dactions dont chacune peut tre soit une
mise jour, soit un effet de bord (par exemple, lappel une fonction externe ou ldi-
tion dun message). Une condition est une formule bien forme de logique. Quand
lordre dvaluation des rgles est important, celles-ci sont values selon des priori-
ts dfinies par des mta-rgles (des rgles sur les rgles) ; par exemple, une mta-
rgle peut simplement consister excuter les rgles dans lordre squentiel. Ainsi, un
langage de rgles de production nest pas compltement dclaratif mais peut contenir
une certaine procduralit. Il en va de mme pour les programmes DATALOG avec
mises jour.
536 BASES DE DONNES : OBJET ET RELATIONNEL
CIRCUIT(x,f1,o,e1,i1), CIRCUIT(x,f2,e1,e,i2),
CIRCUIT(x,new(f1,f2),o,e,i1+i2)
CIRCUIT(x,f1,o,e1,i1),CIRCUIT(x,f2,e1,e,i2), CIRCUIT(x,f3,e1,e2,i3)
Ces deux rgles rduisent les circuits par remplacement des fils en parallle et en srie
appartenant un mme circuit par un fil rsultat de la transformation effectue. Notez
quelles ne sont pas stratifiables. Cependant, le programme de rgles est confluent, au
moins pour des circuits lectriques connexes.
Dautres smantiques que la smantique oprationnelle des rgles de production intro-
duite ci-dessus ont t proposes pour Datalog* [Abiteboul95], comme la smantique
inflationiste et la smantique bien fonde. La smantique inflationiste est simple :
elle calcule les conditions, puis tous les faits dduits de toutes les rgles la fois. Elle
applique donc un oprateur de point fixe global modifi. Malheureusement, le rsultat
ne correspond gure la signification courante. La smantique bien fonde est plus
gnrale : elle est base sur une rvision de lhypothse du monde ferme, en autori-
sant des rponses inconnues des questions. Pour Datalogneg, elle concide avec la
smantique stratifie lorsque les programmes sont stratifiables. Les problmes de
smantique de Datalog* sont en rsum trs difficiles et ont donn lieu de nombreux
travaux thoriques de faible intrt.
Ainsi, des prdicats tels que P(a,x,f(x),f(g(x,a))) o f est une fonction unaire et g une
fonction binaire sont accepts. La smantique de DATALOG doit alors tre complte
pour intgrer les fonctions. Cela seffectue comme en logique, en faisant correspondre
chaque fonction n-aire une application de Dn dans D, D tant le domaine dinterpr-
tation.
Les fonctions sont trs utiles en pratique pour effectuer des calculs. Par exemple, un
problme de cheminement avec calcul de distance sur un graphe pourra tre exprim
comme suit :
{ CHEMIN(x,y,d) ARC(x,y,d) ;
CHEMIN(x,y,d+e) CHEMIN(x,z,e), ARC(z,y,d) }
La recherche des longueurs de tous les chemins allant de Paris Marseille seffectuera
par la requte ? CHEMIN(Paris,Marseille,x).
Un problme qui devient important avec DATALOGfonc est celui de la finitude des
rponses aux questions (ou des relations dduites). Une question est saine (en anglais
safe) si elle a une rponse finie indpendamment des domaines de la base (qui peu-
vent tre finis ou infinis). Le problme de dterminer si une question est saine existe
dj en DATALOG pur. Si les domaines sont infinis, un programme DATALOG peut
gnrer des rponses infinies. Par exemple, le programme:
{ SALAIRE(100) ;
SUPERIEUR(x,y) SALAIRE(x), x < y ;
? SUPERIEUR(x,y) }
gnre une rponse infinie. Pour viter des programmes a modle infini, une caractri-
sation syntaxique des programmes sain a t propose [Zaniolo86]. Cette caractrisa-
tion est base sur la notion de rgle champ restreint. Une rgle est champ res-
treint si toutes les variables figurant en tte de rgle apparaissent dans un prdicat
relationnel dans le corps de la rgle. Par exemple, la rgle
SUPERIEUR(x,y) SALAIRE(x), x < y nest pas champ restreint car y
napparat pas dans un prdicat relationnel dans le corps de la rgle. Si toutes les
rgles dun programme DATALOG sans fonction sont champ restreint, alors le pro-
gramme est sain et ne peut gnrer des rponses infinies.
Avec des fonctions, le problme de savoir si un programme est sain est plus difficile.
Par exemple, le programme :
{ ENTIER(0);
ENTIER(x+1) ENTIER(x) }
Bases de donnes dductives 539
nest pas sain car il gnre un prdicat infini (les entiers positifs sont gnrs dans
ENTIER). Cependant, ce programme est champ restreint. Notez cependant que la
question ? ENTIER(10) a une rponse finie unique (vrai). Vous trouverez une
mthode gnrale pour dterminer si un programme avec fonctions est sain dans
[Zaniolo86].
En conclusion, il est intressant de remarquer quil est possible dtendre lalgbre
relationnelle avec des fonctions [Zaniolo85], comme vu dans le chapitre XI sur le
modle objet. En fait, il est ncessaire dinclure des fonctions dans les qualifications
de jointures et restrictions (les qualifications sont alors des expressions de logique du
premier ordre avec fonctions). Il est aussi ncessaire dinclure des fonctions dans les
critres de projection. On projette alors sur des termes fonctionnels calculs partir
dattributs. Le plus petit modle dun programme DATALOGfonc peut alors tre cal-
cul par un programme utilisant des boucles dexpressions dalgbre relationnelle
sans diffrence. Ainsi, DATALOGfonc a la puissance de lalgbre relationnelle avec
fonction sans diffrence, mais avec la rcursion. Pour avoir la diffrence, il faut passer
DATALOGfonc,neg et pour avoir les mises jour DATALOGfonc,*.
locomotive roue 4
locomotive moteur 1
roue rayon 20
roue jante 1
moteur bielle 1
NEST UNEST
Remarquons que le groupage ne donne pas plus de puissance au langage que les fonc-
tions interprtes et la ngation. En fait, si lon dfinit la fonction unaire interprte
qui un lment fait correspondre un ensemble compos de cet lment {}: x {x}
et la fonction binaire interprte sur ensemble : X,Y X Y (cest--dire lunion
classique), il est possible deffectuer le groupage par les rgles suivantes :
SOUS-PIECE (x,Y) PIECE (x,y), Y = {y}
SOUS-PIECE (x,Y) SOUS-PIECE (x,Z), SOUS-PIECE (x,T), Y = Z T
COMPOSE (x,Y) SOUS-PIECE (x,Y), SOUS-PIECE (x,Z), Z Y
En clair, la deuxime rgle fait lunion de tous les lments composant chaque pice x
et la dernire garde le plus grand ensemble de sous-pices Y ainsi gnr. Il va de soi
quutiliser loprateur de groupage est plus simple ; aussi, si le systme ralise effica-
cement cet oprateur, il sera probablement plus performant pour effectuer le groupage
quen excutant les trois rgles ci-dessus.
Pour conclure sur les ensembles, notons que lintroduction densembles en DATA-
LOG ncessite la stratification pour dfinir la smantique dun programme sans ambi-
gut. Cela provient du fait que les ensembles intgrent un cas particulier de ngation.
La smantique de la stratification ncessaire peut tre exprime comme suit : calcu-
ler tout ensemble avant dutiliser son contenu . Ainsi, les rgles doivent tre partiel-
lement ordonnes en strates dans lesquelles les oprations de groupage sont effectues
ds que possible. Si des groupages sont effectus dans des cycles de calculs de prdi-
cats rcursifs, le programme nest pas stratifiable et a une smantique ambigu : il
doit tre rejet.
sont instancies avec des faits connus. Cela ncessite dvaluer la condition compo-
sant le corps de rgle sur les faits connus ; pour chaque instance des variables satisfai-
sant la condition, laction (ou les actions) dfinie par le prdicat de tte est excute.
La procdure de gnration est applique jusqu saturation, cest--dire jusquau
point o aucune rgle ne peut produire de nouveau fait. Une telle procdure est
connue en intelligence artificielle comme la gnration en chanage avant
[Nilsson80]. Elle est rsume figure XV.12.
Lapproche propose part des donnes pour laborer la rponse lusager. Pour cette
raison, elle est souvent appele mthode dvaluation bottom-up.
BASE EXTENSIONNELLE
APPLICATION DE r1 APPLICATION DE r2
APPLICATION DE r3 APPLICATION DE q
Les faits relevants peuvent tre utiliss afin de gnrer toutes les rponses la ques-
tion si ncessaire, en appliquant une procdure de chanage avant partir de ces faits.
Cependant, la technique est trs diffrente de lvaluation bottom-up puisquelle pro-
fite des constantes de la question pour rduire les espaces de recherche. La mthode
part de la question de lusager pour remonter aux faits de la base. En consquence,
elle est appele mthode top-down.
demande de comprendre les connexions entre les rgles dans un programme de rgles,
cest--dire les unifications possibles entre prdicats. Dans ce but, plusieurs reprsen-
tations par des graphes dun programme DATALOG ont t proposes.
BASE EXTENSIONNELLE
Marie Jean
6. LA MODLISATION DE RGLES
PAR DES GRAPHES
Il est important de comprendre les connections entre les rgles dun programme. Un
modle bas sur un graphe est gnralement utilis pour visualiser les liens entre
rgles. Un tel modle capture les unifications possibles entre les prdicats en tte de
546 BASES DE DONNES : OBJET ET RELATIONNEL
rgles et ceux figurant dans les conditions. Il permet souvent dillustrer le mcanisme
doptimisation-excution ou de vrifier la cohrence des rgles. Par exemple, des
rgles peuvent tre contradictoires ou organises de telle manire que certaines rela-
tions restent vides. Dans cette section, nous allons prsenter les modles graphiques
les plus connus.
+ D
REPONSE
DESC = toto
ANCETRE
PARENT
t > 16
t > 16
MERE PERE
de rgles sont ajoutes pour dvelopper les nuds qui correspondent des relations
rcursives. Nous dvelopperons la rcursion dans la section suivante. Cependant, il
apparat dj que des graphes plus sophistiqus sont ncessaires pour reprsenter les
rgles rcursives.
GRANDPARENT (x,Jean)
z /Jean
r3
r1 r2 r1 r2
Une extension de larbre ET/OU pour viter les branches infinies en cas de prdicats
rcursifs est le graphe rgle/but. Un graphe rgle/but est aussi associ une question
qui spcifie un prdicat valuer. Il contient en outre des nuds circulaires reprsen-
tant les prdicats et des nuds rectangulaires reprsentant les rgles. Les seuls arcs
dun graphe rgle/but sont dfinis par la rgle suivante : sil existe une rgle r de la
forme P P1, P2 Pn dans le programme de rgles, alors il existe un nud allant
du nud r au nud P et, pour chaque Pi, il existe un arc allant du nud Pi au nud r.
Dans sa forme la plus simple, un graphe rgle/but peut tre dfini comme une varia-
tion dun graphe ET/OU :
ANCETRE
r1 r4
r1 r2
MERE PERE
x/x, x/x,
x/x, z/z z/z
x/x,
z/z
z/z
x/y, y/x,
ANCETRE(x,z) PARENT(x,z) z/z z/z
x/y, y/x,
x/x, z/z z/z
x/x, z/y
y/z
x/x,
y/z
x/x, z/y
PERE MERE
x,t,z x,t,z
yp,z
x,z ANCETRE
ya = yp
x,z
MSER
MC MC
CHEF z1 z2 z3 z4 CHEF
x y
Il est aussi possible dutiliser DATALOGfonc afin de dfinir des prdicats rcursifs
avec calculs de fonctions. Des exemples typiques sont drivs des problmes de par-
cours de graphes. Un graphe valu peut tre reprsent par une relation :
ARC (SOURCE, CIBLE, VALUATION).
Chaque tuple de la relation reprsente un arc. Les rgles suivantes dduisent une rela-
tion CHEMIN reprsentant tout les chemins du graphe, avec une valuation compose
calcule par une fonction f :
CHEMIN(x,y,z) ARC(x,y,z)
CHEMIN(x,y,f(z1,z2)) ARC(x,z,z1), CHEMIN(z,y,z2)
Par exemple, si f(z1,z2) = z1 + z2 et si les valuations reprsentent des distances, les
rgles prcdentes dfinissent tous les chemins du graphe avec leur longueur associe.
Une autre application possible des fonctions dans les rgles rcursives est la manipu-
lation dobjets structurs. Par exemple, des listes peuvent tre manipules avec la
fonction concatnation de deux listes X et Y, note X|Y. La base de donnes peut tre
compose dun prdicat dfinissant lensemble des listes constructibles partir de n
Bases de donnes dductives 555
lments. On spcifie lajout (par la fin) dune liste X une liste Y comme tant une
liste Z dfinie par le prdicat AJOUT(X,Y,Z), puis linversion des lments dune
liste X comme tant une liste Y dfinie par le prdicat INVERSE(X,Y). Les rgles
suivantes dfinissent ces prdicats drivs ([] dsigne la liste vide) :
(r1) AJOUT(X,[],X|[]) LISTE(X)
(r2) AJOUT(X,W|Y,W|Z) AJOUT(X,Y,Z),LISTE(W)
(r3) INVERSE([],[])
(r4) INVERSE(W|X,Y) INVERSE(X,Z),AJOUT(W,Z,Y)
AJOUT et INVERSE sont ainsi deux prdicats rcursifs linaires.
Le problme qui se pose est bien sr dvaluer des questions portant sur des prdicats
rcursifs. Ces questions spcifient en gnral des constantes pour certaines variables,
ou des ensembles de constantes (question avec , <, ,>). Voici quelques questions
typiques sur les prdicats dfinis prcdemment :
(1) Qui sont les anctres de Jean ?
? ANC(x,Jean)
(2) Pierre est-il un anctre de Jean ?
? ANC(Pierre,Jean)
(3) Qui sont les cousins de mme gnration de Jean ?
? MG(Jean,x)
(4) Qui sont les chefs au mme niveau que Jean ?
? MC(Jean,x)
(5) Quel est linverse de la liste [1,2,3,4,5] :
? INVERSE([1,2,3,4,5], x)
Il est bien sr possible de remplacer par des constantes tout sous-ensemble de para-
mtres afin de retrouver les autres (cependant, selon les instanciations, DATALOGfonc
peut conduire des rponses infinies comme vu ci-dessus), ou encore dinstancier
tous les paramtres afin dobtenir une rponse boolenne du type VRAI/FAUX.
Dans la suite, nous allons tudier les principales solutions proposes, en commen-
ant par les solutions simples, en gnral peu performantes ou incompltes. Nous
tudierons ensuite les solutions interprtes qui transforment progressivement la
requte en sous-requtes adresses au SGBD, puis les solutions compiles qui, dans
un premier temps, gnrent un programme dalgbre relationnelle et dans un
deuxime temps demandent lexcution de ce programme. Bien que dcrivant les
principales approches, notre tude est loin dtre complte. En particulier, nous
ignorons des approches importantes bases sur des rgles de rcriture [Chang81],
des automates [Marque-Pucheu84] ou une mthode de rsolution adapte
[Henschen84].
556 BASES DE DONNES : OBJET ET RELATIONNEL
Cette mthode de calcul de point fixe part donc des faits de la base et calcule les ins-
tances des prdicats drivs par application des rgles afin de rpondre la question.
En gnral, une valeur R0 est calcule pour le prdicat rcursif partir des rgles
dinitialisation. Puis, par un programme de lalgbre relationnelle qui rsulte dune
compilation lmentaire de la rgle rcursive, on effectue un calcul itratif
R = R E(R), o E est lexpression de lalgbre relationnelle traduisant la rgle
rcursive. Le processus sarrte quand lapplication de E R ne permet pas de gnrer
de nouveau tuple : on a alors le point fixe du prdicat rcursif dfini par R = E(R). Ce
point fixe existe en DATALOG [Aho-Ullman79]. Un programme de calcul naf dune
relation rcursive R scrit donc comme reprsent figure XV.23, E tant une expres-
sion de lalgbre relationnelle drive de la rgle rcursive.
Par exemple, dans le cas des anctres, on initialisera ANC par la rgle r1 avec les
parents, puis on appliquera la rgle r2 en effectuant une boucle de jointures de la rela-
tion ANC avec la relation PAR, et ce jusqu ce que lon ne gnre plus de nouvel
anctre. Le calcul est illustr figure XV.24. Le processus sera similaire pour gnrer la
relation MC : les rgles r1 et r2 permettent de lui attribuer une valeur initiale MC0, puis
les jointures des relations CHEF,MC0,MSER,MC0,CHEF permettront de calculer MC1.
De manire itrative, les jointures de CHEF,MCi,MSER,MCi,CHEF permettront de cal-
culer MCi+1. Le calcul sarrtera quand aucun nouveau tuple sera gnr : on aura
Bases de donnes dductives 557
obtenu le point fixe de la relation MC qui dcrit toutes les personnes de la base un
mme niveau hirarchique.
RGLES
ANC(x,y) PAR(x,y)
ANC(x,y) PAR(x,z),ANC(z,y)
PROGRAMME NAF
ANC := ;
while "ANC changes" do
ANC := ANC PAR AN
CALCULS SUCCESSIFS
Jack Jean
Jack Marie
Ted Jack
Pierre Ted ANCETRE ASC DE
Jack Je
Jack Ma
Ted Ja
ANCETRE ASC DESC Pierre T
Jack Jean
Jack Marie
Ted Jack
Pierre Ted ANCETRE ASC DE
Ted Jean
Ted Marie Jack Je
Pierre Jack Jack Ma
Ted Ja
Pierre T
Ted Je
Ted Ma
Pierre Ja
ANCETRE(x,Jean) ASC DESC
Pierre Je
Pierre Ma
Jack Jean
Ted Jean
Pierre Jean
Si les programmes de rgles sont en DATALOG pur, comme pour ANC et MC, il
nexiste pas de fonction pour gnrer des valeurs qui ne sont pas dans la base : ceci
garantit la finitude du processus de gnration [Aho-Ullman79]. Dans le cas des listes,
la stratgie bottom-up ne peut tre applique telle quelle ; en effet, par ajout de listes,
on gnre des listes sans fin. Le processus de gnration ne se termine pas.
558 BASES DE DONNES : OBJET ET RELATIONNEL
Une tude plus dtaille du processus de gnration naf dmontre plusieurs faiblesses
de la mthode, outre le fait quune terminaison nest garantie quen cas dabsence de
fonction :
1. chaque itration, un travail redondant est effectu, qui consiste refaire les inf-
rences de litration prcdente ; cela provient du fait que lon cumule les rsultats
avec les anciens et que lon applique nouveau la jointure tous les rsultats sans
distinction.
2. Dans le cas o des constantes figurent dans la question, un travail inutile est effec-
tu car la gnration produit des rsultats qui ne figurent pas dans la rponse ; ils
sont limins par la slection finale. Par exemple, pour calculer les seuls anctres de
Jean, le processus conduit gnrer les anctres de toutes les personnes de la base.
Voici maintenant les principales mthodes qui rpondent ces critiques.
RGLES
ANC(x,y) PAR(x,y)
ANC(x,y) PAR(x,z),ANC(z,y)
PROGRAM SEMI-NAF
ANC := PARENT ;
PARENT ASC DESC
ANC := ANC;
Tantque " ANC changes" faire
Jack Jean
ANC := PARENT ANC
Jack Marie
ANC := ANC ANC ;
Ted Jack
Pierre Ted
CALCULS SUCCESSIFS
de la question pour remonter aux faits via les rgles. En consquence, elle est quali-
fie de stratgie top-down comme vu ci-dessus. Malheureusement, dans le cas de
rgles rcursives la mthode top-down peut conduire boucler.
Nous allons tout dabord montrer une application de la mthode dans le cas favorable.
Par exemple, avec la rgle :
ANC(x,y) PAR(x,z), ANC(z,y)
la question ANC(Jean,y) gnre la sous-question PAR(Jean,z),ANC(z,y). Tenter de
rsoudre directement ANC(z,y) en chanage arrire conduit boucler. Par contre, si
lon value PAR(Jean,z) sur la relation de base PARENT, on obtient des constantes
c0, c1... pour z. Il devient alors possible de rsoudre en chanage arrire
ANC(c0,y),ANC(c1,y)... qui gnrent les sous-questions
PAR(c0,z),ANC(z,y),PAR(c1,z),ANC(z,y), etc. Le processus sarrte
quand il nexiste plus de sous-question gnrable du type PAR(ci,z) ayant une
rponse non vide.
La mthode nest cependant applicable que dans le cas particulier o la constante de
la question se propage pour regnrer la mme sous-question. Par exemple, dans le
cas de la rgle :
ANC(x,y) ANC(x,z), PAR(z,y)
la question ANC(Jean,y) conduit gnrer la sous-question ANC(Jean,z).
Changer y en z ne fait pas progresser le problme et le processus boucle totalement.
Nous verrons dans la suite des extensions de cette approche la Prolog qui per-
mettent dviter le bouclage en utilisant les autres rgles et en mlant chanage
arrire-chanage avant. Auparavant, nous allons tudier plus en dtail la propagation
des constantes dans les rgles.
Les propagations dinformations dans les rgles se reprsentent donc par des graphes.
Un graphe de propagation pour une rgle est un graphe tiquet qui dcrit comment
les constantes obtenues par la tte de la rgle se propagent aux autres prdicats de la
rgle. Il existe plusieurs graphes de propagation possibles pour une rgle, suivant les
choix de propagation effectus. Pour faciliter la comprhension et viter de rpter
des morceaux de rgles, une reprsentation simplifie avec des bulles reprsentant les
sommets du graphe est propose. Les prdicats de la rgle sont crits de gauche
droite, depuis la tte jusquau dernier prdicat de la condition. Un sommet du graphe
(donc reprsent par une bulle) est, soit un groupe de prdicats, soit un prdicat rcur-
sif. Un arc N p relie un groupe de prdicats N une occurrence dun prdicat
rcursif p. Larc N p est tiquet par des variables dont chacune apparat dans un
prdicat de N et dans p. Un graphe de propagation est valide sil existe un ordre des
sommets (appel ici ordre de validit) tel que, pour chaque arc, tout membre de sa
source apparaisse avant sa cible. Pour faciliter la visualisation dun graphe de propa-
gation valide, il est souhaitable dcrire les occurrences de prdicats selon lordre de
validit. Les figures XV.27 et XV.28 prsentent deux graphes de propagation valides
pour les rgles rcursives des exemples Anctres et Chefs.
z1
z3
pagation de constantes vers un prdicat rcursif en chanage arrire suite une instan-
tiation dune variable de la tte. Une telle propagation est donc une propagation par
effet de bord.
Un graphe de propagation valide est linaire si pour tout arc N p, N contient tous
les nuds qui prcdent p selon lordre de validit. Suivant [Beeri87], nous dirons
quun graphe de propagation valide linaire est total si toute variable dun prdicat
rcursif r cible dun arc apparaissant dans un prdicat qui prcde r tiquette un arc
entrant dans r. Nous utiliserons les graphes de propagation de constantes dans la suite,
notamment pour la mthode des ensembles magiques gnraliss [Beeri87].
La tte de la rgle est tout dabord signe selon lunification ralise avec la question.
La signature est ensuite propage aux autres prdicats rcursifs en suivant les arcs du
graphe de propagation et en marquant 1 les variables correspondant aux tiquettes
dans les prdicats cibles [Beeri87]. Lutilisation de rgles signes permet de distinguer
des prdicats de mmes noms ayant des variables instancies diffrentes. Cela est trs
utile dans le cas de rgles non stables, o les constantes changent de position dans les
occurrences dun mme prdicat [Henschen-Naqvi84]. Voici les rgles rcursives
signes pour les Anctres et les Chefs, selon les graphes de propagation repr-
sents respectivement figure XV.27 et XV.28, pour les questions ? ANC(Jean,x)
et ? MC(Jean,y) :
ANC10(x,y) PAR(x,z), ANC10(z,y)
MC10(x,y) CHEF(x,z1),MC10(z1,z2),MSER(z2,z3),
MC10(z3,z4),CHEF(y,z4)
Dans la suite, nous utiliserons les rgles signes pour tous les algorithmes bass sur la
rcriture de rgles.
564 BASES DE DONNES : OBJET ET RELATIONNEL
quune instance de relation dfinit en fait des fonctions ; chaque fonction transforme
un ensemble de valeurs dune colonne dans lensemble de valeurs correspondant dans
une autre colonne. Ainsi toute question ? R(a,y) est interprte comme une fonction r
appliquant lensemble des parties du domaine de a dans lensemble des parties du
domaine de y, cest--dire avec des notations classiques, r : 2dom(a) 2dom(y). valuer
la question ? R(a,y) revient alors valuer la fonction r({a}).
Etant donns une question et un ensemble de rgles, un algorithme permet de gnrer
une quation fonctionnelle au point fixe du type r = F(r), o F est une expression
fonctionnelle. Pour ce faire, des oprations monotones entre fonctions ont t intro-
duites :
1. la composition de deux fonctions f o g (X) = f(g(X)) modlise en fait une jointure
suivie dune projection ;
2. laddition (f+g) (X) = f(X) g(X) modlise lunion ;
3. lintersection (f g) (X) = f(X) g(X) permet de modliser des jointures
cycliques.
Dans le cas de rgles prdicats binaires sans fonction, lalgorithme est simple et
repose sur un graphe de connexion des variables dans la rgle. Ce graphe reprsente
simplement par un nud chaque variable et par un arc les prdicats (ou un hyper arc
dans le cas de prdicats non binaires). Il est orient pour visualiser les passages
dinformation en chanage arrire. Ce graphe peut tre peru comme une simplifica-
tion du graphe de propagation dinformation vu ci-dessus.
La gnration dquation fonctionnelle seffectue par un algorithme de cheminement
dans le graphe, chaque arc tant interprt comme une fonction de calcul du nud
cible en fonction du nud source. Cet algorithme dcrit dans [Gardarin86] est appli-
qu ci-dessous aux cas des anctres et des chefs. Pour simplifier les notations, pour
toute relation binaire R(x,y), R(X) dnote la fonction qui applique {x} sur {y} et
R(Y) celle qui applique {y} sur {x}. Aprs obtention, lquation fonctionnelle au
point fixe est simplement rsolue par application du thorme de Tarski [Tarski55].
Nous illustrons tout dabord la mthode avec le problme des anctres. La
figure XV.30 reprsente les graphes de connexion des variables des rgles :
ANC(x,y) PAR(x,y)
ANC(x,y) PAR(x,z),ANC(z,y).
z
PAR PAR ANC
x y x y
ANC ANC
PROCEDURE CALCUL(ANC,X); {
ANC := ;
DELTA := X;
Tant que DELTA faire {
DELTA := PAR.2(PAR.1DELTA(PAR));
ANC := ANC DELTA;
} ;
};
De manire plus gnrale, la mthode sapplique trs simplement aux rgles forte-
ment linaires de la forme :
R(X,Y) B1(X,Y)
R(X,Y) B2(X,X1),R(X1,Y1),B3(Y1,Y)
o B1, B2 et B3 sont des relations de base ou simplement des jointures/restrictions de
relations de base et o X, Y, X1, Y1 reprsentent des variables ou des n-uplets de
variables. Le graphe de connexion des variables de ce type de rgles est reprsent
figure XV.32.
R
x1 y1
B1 B2 B3
x y x y
R R
Lquation fonctionnelle au point fixe est, pour des questions du type ? R(a,Y) :
r(X) = b1(X) + b3(r(b2(X))).
Le thorme de Tarski permet dobtenir la forme gnrale de la solution :
r(X) = b1(X) + b3(b1(b2(X))) +... + b3n(b1(b2n(X))).
Bases de donnes dductives 569
PROCEDURE CALCUL(R,X); {
i,n : integer;
n:= 0 ;
R := B1.2(B1.1 X(B1));
B2N := X;
Tant que B2N faire {
n := n + 1;
B2N := B2.2(B2.1 B2N(B2));
DELTA := B1.2(B1.1 B2N(B1));
Pour i : = 1 n faire {
DELTA := B3.2(B3.1 B2N(B3));
R := R DELTA;
} ;
} ;
} ;
Figure XV.33 : Calcul des rponses des requtes sur rgles fortement linaires
8. RGLES ET OBJETS
De nombreuses tentatives pour combiner les bases de donnes objet et les rgles ont
t effectues. Citons notamment IQL [Abiteboul90], Logres [Ceri90], Coral
Bases de donnes dductives 571
Les rgles en ROL sont organises en modules. Chaque module commence par des
dfinitions de variables valables pour tout le module, de la forme :
VAR <nom> IN <collection>.
Le nom dune variable est gnralement une lettre, alors quune collection est une
extension de classe ou une collection dpendantes, comme en OQL. Il est aussi pos-
sible dutiliser des variables symboliques (chanes de caractres), afin damliorer la
clart des programmes. Nous dfinissons simplement les variables :
VAR X IN Film, VAR Y IN X.Categories ;
VAR Z IN Calcul ;
La condition est analogue une qualification de requtes OQL. Cest une combinai-
son logique de conditions lmentaires. Une condition lmentaire permet de compa-
rer deux termes. Un terme est une constante, un attribut, une expression de chemin ou
de mthode. Les actions sont :
Des insertion de valeurs. Une valeur ventuellement complexe (tuple par exemple)
est insre dans une collection temporaire ou persistante par la construction +<col-
lection>(<valeurs>).
Des crations dobjets. Un objet est cr dans une collection temporaire ou persis-
tante par la construction +<classe>(<paramtres>). La classe doit tre dfinie aupa-
ravant. Laction provoque simplement lappel au constructeur dobjet avec les para-
mtres indiqus.
Des destruction de valeurs. Une valeur dune collection est dtruite par la
construction <collection>(<valeurs>).
Des destructions dobjets. Un objet est dtruit dans une collection temporaire ou
persistante par la construction <classe>(). La classe doit tre dfinie auparavant.
Laction provoque simplement lappel au destructeur de lobjet avec les paramtres
indiqus sur les objets de la classe slectionns par la condition.
Des appels de mthodes. Toute mthode dfinie au niveau du schma est valide en
partie action prcde de + pour faciliter la lecture des expressions.
Un bloc dactions lmentaires (cration et destruction dobjets et/ou valeurs,
appels de mthodes). Une rgle peut avoir en consquence une suite dactions spa-
res par des + et des . Elle peut donc accomplir des mises jour, des impressions,
etc.
Une smantique ensembliste type point fixe est donne au langage par traduction en
algbre dobjet complexe [Gardarin94]. Les difficults des langages objets est quils
intgrent la fois la cration de nouveaux objets (linvention dobjets daprs
[Abiteboul90]) et les fonctions. De ce fait, il est facile dcrire des programmes infinis
ds quon utilise des rgles rcursives. notre connaissance, aucun compilateur nest
capable de dtecter les programmes non sains.
titre dillustration, nous dfinissons figure XV.35 deux rgles en ROL. La premire
ralise une suite dactions pour tous les films daventure dans lesquels joue Quinn
avec un salaire suprieur 1 000 $ de lheure. La seconde calcule la fermeture transi-
tive de la relation Domine, puis imprime qui fut (transitivement) meilleur que
Marilyn. Il ny a pas de boucle infinie car MEILLEUR est dfini comme un ensemble.
Il nen serait rien avec une liste. Notons aussi que la structure de blocs imbriqus per-
met de dfinir des ordres de calcul, donc une certaine stratification. De tels langages
sont complexes, mais puissants. Les perspectives dapplications sont importantes
daprs [Nicolas97].
Bases de donnes dductives 573
Au-del des corps de rgles, les conditions permettent dexprimer des contraintes
dintgrit et peuvent tre utilises dans les ordres impratifs conditionnels (if et
while). DEL supporte aussi de nombreux prdicats prdfinis appelables depuis les
conditions ou les ordres impratifs. Le temps est galement support sous diffrentes
formes. DEL apparat donc comme un langage trs puissant, capable damliorer la
productivit des dveloppeurs dapplications intelligentes. Limplmentation du sys-
tme dductif a t ralise Bull, partir des travaux effectus la fin des annes 80
lECRC Munich. Un grant dobjets spcifique avec des mthodes de reprise et de
gestion des accs concurrents efficaces sert de support au moteur dinfrence qui
applique un driv de la mthode QoSaQ vue ci-dessus.
9. CONCLUSION
Ce chapitre a propos une synthse des recherches et dveloppements en matire de
bases de donnes dductives. Parmi les multiples approches, nous avons surtout
insist sur lintgration dun langage de rgles au sein dun SGBD relationnel tendu.
Cette approche est probablement valable long terme, bien que quelques produits
commencent apparatre. Une approche plus immdiate consiste coupler un inter-
prteur de rgles un SGBD relationnel. De nombreux produits offrent de tels cou-
plages. Ils constituent une approche trs primitive aux bases de donnes dductives.
Plusieurs caractristiques souhaitables dun langage de rgles pour bases de donnes
ont t tudies. La plupart ont t intgres un langage de programmation logique
appel DATALOG, qui a une smantique de type point fixe. Les extensions essen-
tielles de DATALOG ncessaires la programmation sont finalement les fonctions et
les attributs multivalus (ensembles). Lapproche DATALOG est utile pour la compr-
hension des problmes, mais sans doute difficile utiliser vu sa syntaxe plutt for-
melle. Un langage plus pratique que DATALOG peut tre driv de SQL, partir des
qualifications de questions et des actions dinsertion et de mise jour. Il sagit essen-
tiellement dun choix de syntaxe. De mme, avec les objets il est possible de driver
un langage de rgles du langage OQL, comme le montre le langage ROL bauch ci-
dessus. DEL est une autre variante plus proche de DATALOG. La puissance de tous
ces langages est rsume figure XV.36.
Le problme de loptimisation des requtes dans un contexte de rgles rcursives est
complexe. Vous pouvez consulter [Ceri91] pour un approfondissement. Loptimisation
en prsence de fonctions et dobjets complexes est encore mal connue. De plus, les
techniques de maintenance de la cohrence des rgles et des donnes sont peine tu-
dies. Finalement, il nexiste encore gure de SGBD dductif fonctionnant avec des
applications en vraie grandeur, sans doute lexception de Validity. Cependant, les
Bases de donnes dductives 575
techniques essentielles pour tendre un SGBD relationnel ou objet avec des rgles
sont connues. Elles ont t prsentes dans ce chapitre.
IQL
Algbre relationnelle
ROL DATALOGFonc, Neg, Neg DATALOGFonc, Neg
avec fonctions
DEL
10. BIBLIOGRAPHIE
[Abiteboul89] Abiteboul S., Kanellakis P., Object Identity as a Query Language
Primitive , ACM SIGMOD Intl. Conf. on Management of Data, p. 159-173,
1989.
Une prsentation des fondements du langage IQL, un langage de rgles
capable de crer de nouveaux objets. IQL utilise des identifiants dobjets pour
reprsenter des structures de donnes partages avec de possibles cycles, pour
manipuler les ensembles et pour exprimer toute question calculable. IQL est un
langage typ capable dtre tendu pour supporter des hirarchies de types.
[Abiteboul90] Abiteboul S., Towards a Deductive Object-Oriented Database
Language , Data and Knowledge Engineering, vol. 5, n 2, p. 263-287, 1990.
Une extension dIQL vers un langage plus praticable. Un langage de rgles
pour objets complexes est prsent, incluant toutes les extensions de Datalog,
linvention dobjets, lappel de mthodes et la construction de fonctions dri-
ves.
[Abiteboul91] Abiteboul S., Simon E., Fundamental Properties of Deterministic and
Nondeterministic Extensions of Datalog , Theoretical Computer Science,
n 78, p. 137-158, 1991.
576 BASES DE DONNES : OBJET ET RELATIONNEL
Une tude des diffrentes extensions de Datalog avec ngations et mises jour.
La puissance des diffrents langages obtenus est caractrise en termes de
complexit.
[Abiteboul95] Abiteboul S., Hull R., Vianu V., Foundations of Databases, Addison-
Wesley Pub. Comp., Reading, Mass, USA, 1995.
Ce livre prsente les fondements thoriques des bases de donnes. Une large
place est donne Datalog et ses extensions, ainsi qu la smantique de tels
langages.
[Aho79] Aho A.V., Ullman J.D., Universality of data retrieval languages , Conf.
POPL, San-Antonio, Texas, 1979.
Cet article est lun des premiers souligner lincapacit des langages dinter-
rogation de bases de donnes supporter la rcursion. La notion de plus petit
point fixe dune quation de lalgbre est notamment introduite.
[Aiken92] Aiken A., Widom J., Hellerstein J., Behavior of Database Production
Rules: Termination, Confluence, and Observable Determinism , ACM SIG-
MOD Int. Conf. on Management of Data, San Diego, Calif., 1992.
Des mthodes danalyse statiques dun programme de rgles sont prsentes
pour dterminer si un ensemble de rgles de production rfrenant une base
de donnes : (1) se terminent ; (2) produisent un tat base de donnes unique ;
(3) produisent une chane dactions observables unique.
[Apt86] Apt C., Blair H., Walker A., Towards a theory of declarative knowledge ,
Foundations of Deductive Databases and Logic Programming, Minker J. Ed.,
Morgan Kaufmann, Los Altos, 1987, aussi IBM Research Report RC 11681,
avril 1986.
Une tude sur les points fixes minimaux et la stratification. Il est montr quun
programme avec ngation plusieurs points fixes minimaux et que la stratifica-
tion consiste choisir le plus naturel.
[Bancilhon86a] Bancilhon F., Maier D., Sagiv Y., Ullman J.D., Magic sets and other
strange ways to implement logic programs , 5 th ACM Symposium on
Principles of Database Systems, Cambridge, USA, 1986.
Cet article expose la mthode des ensembles magiques pour effectuer les res-
trictions avant la rcursion lors de lvaluation de questions dductives.
Comme la mthode dAlexandre, les ensembles magiques rcrivent les rgles
en simulant un chanage arrire partir de la question. Une valuation en
chanage avant permet alors de ne sintresser quaux seuls faits capables de
gnrer des rponses (les faits relevants).
[Bancilhon86b] Bancilhon F., Ramakrishnan R., An Amateurs Introduction to
Recursive Query Processing Strategies , ACM SIGMOD Intl. Conf. on
Management of Data, Washington D.C., mai 1986.
Bases de donnes dductives 577
tie contrle permettant de spcifier les priorits dexcution des rgles. RDL1 a
t implant lINRIA laide de rseaux de Petri prdicats tendus rsul-
tant de la compilation des rgles. Ces rseaux sont interprts sur la couche
basse du systme SABRINA qui offre une interface proche dune algbre rela-
tionnelle tendue avec des types abstraits.
[Kifer87] Kifer M., Lozinskii E., Implementing Logic Programs as a Database
System , IEEE Intl. Conf. on Data Engineering, Los Angeles, 1987.
Une prsentation dun prototype supportant Datalog. Lide essentielle de cet
article est de compiler un programme logique en un rseau de transitions (le
system graph ) reprsentant les rgles. Le rseau peut alors tre optimis
par des techniques de gnration de sous-questions.
[Kifer89] Kifer M., Lausen G., F-Logic : A Higher-Order Language for Reasoning
about Objects, Inheritance and Schema , ACM SIGMOD Intl. Conf. on
Management of Data, Portland, 1989.
Une logique pour objets complexes. Cet article dfinit un langage de rgles
supportant hritage, mthodes et objets complexes. Une mthode de rsolution
tendue est propose pour dmontrer un thorme dans un tel contexte.
[Kuper86] Kuper G., Logic programming with sets , Proc. ACM PODS, 1987.
Cet article discute du support des ensembles en programmation logique.
[Lloyd87] Lloyd J., Foundations of logic programming, 2e dition, Springer Verlag, 1987.
Le livre de base sur les fondements de la programmation logique. Les diff-
rentes smantiques dun programme logique sont introduites. Les techniques de
preuve de type rsolution avec ngation par chec sont dveloppes.
[McKay81] MacKay D., Shapiro S., Using active connection graphs for reasoning
with recursive rules , Proc. Intl. Conf. on Artificial Intelligence IJCAI, 1981.
Cet article introduit les PCG comme support danalyses de rgles et mthodes
de preuves.
[Minker82] Minker J., Nicolas J.M., On Recursive Axioms in Deductive
Databases , Information Systems Journal Vol.8, n 1, p. 1-13, Jan. 1982.
Un des premiers articles sur le problme des rgles rcursives.
[Naqvi89] Naqvi S., Tsur S., A Logical Language for Data and Knowledge Bases ,
Principles of Computer Science, Computer Science Press, New York, 1989.
Ce livre dcrit le langage LDL. LDL est un langage driv de Prolog pour
manipuler les bases de donnes relationnelles supportant des objets complexes
(ensembles). Il est assez proche de Datalog tendu avec la ngation, des mises
jour et des ensembles. Une version oprationnelle a t dveloppe MCC et
distribue dans les universits amricaines. Le livre est illustr de nombreux
exemples.
Bases de donnes dductives 581
[Next98] Next Century Media, Validity Database System, DEL Language Reference
Manual, Next Century Media Inc., Versailles, France
Ce document prsente le langage DEL du SGBD dductif (DOOD) Validity,
commercialis par Next Century Media, une start-up issue du groupe Bull.
[Nicolas97] Nicolas J-M., Deductive Object Oriented Databases Technology,
Products and Applications : Where are we ? , Intl. Symp. On Digital Media
Information Base DBIM97, Nara, Japan, Nov. 1997.
Cet article donne une vue quelque peu optimiste du pass, du prsent et du
futur des bases de donnes dductives. Il est crit par le prsident de Next cen-
tury Media.
[Nilsson80] Nilsson N., Principles of Artificial Intelligence, Tioga Publication, 1980.
Un des livres de base sur lintelligence artificielle. Les systmes de rgles de
production pertinents aux bases de donnes dductives sont particulirement
dvelopps.
[Przymusinski88] Przymusinski T., On the declarative semantics of stratified deduc-
tive databases and logic programs , in Foundations of Deductive Databases
and Logic Programming, Morgan & Kaufmann, Los Altos, 1988.
Une discussion de la smantique des programmes de rgles stratifis. La
smantique inflationniste o toutes les rgles sont dclenches en parallle est
notamment introduite.
[Ramakrishnan95] Ramakrishnan R., Ullman J.D., A Survey of Deductive Database
Systems , Journal of Logic Programming, vol. 23, n 2, Elsevier Science Pub.
Comp., New York, 1995.
Une vue densemble rcente des bases de donnes dductives et de leurs
apports et perspectives thoriques.
[Reiter78] Reiter R., On closed world data bases , in Logic and databases, dit
par Gallaire et Minker, Plenum Press, New York, 1978.
Larticle de base sur lhypothse du monde ferm.
[Reiter84] Reiter R., Towards a Logical Reconstruction of Relational Database
Theory , in On Conceptual Modelling, p. 191-234, Springer Verlag, 1984.
Une redfinition des bases de donnes relationnelles en logique. Les diffrents
axiomes ncessaires linterprtation dune base de donnes comme une tho-
rie en logique sont prsents : fermeture des domaines, unicit des noms,
axiomes dgalit, etc. Les calculs relationnels sont unifis et gnraliss.
[Rohmer86] Rohmer J., Lescur R., Kerisit J.M., The Alexander Method A
Technique for the Processing of Recursive Axioms in Deductive Databases ,
New Generation Computing, n 4, p. 273-285, Springer-Verlag, 1986.
Les auteurs introduisent la mthode dAlexandre, premire mthode propose
ds 1985 lors du stage de J.M. Kerisit pour transformer les rgles rcursives en
582 BASES DE DONNES : OBJET ET RELATIONNEL
rgles de production appliques aux seuls faits relevants. Cette mthode est trs
proche de la mthode des ensembles magiques propose un peu plus tard par
Bancilhon et Ullman.
[Sacca86] Sacca D., Zaniolo C., Magic Counting Methods , MCC Technical Report
DB-401-86, Dec. 1986.
Cet article dcrit la mthode de comptage tudie ci-dessus pour optimiser les
rgles rcursives.
[Simon92] Simon E., Kiernan J., de Maindreville C., Implementing High Level
Active Rules on top of Relational DBMS , Proc. of the 18th Very Large Data
Bases Int. Conf., Morgan Kaufman, Vancouver, Canada, 1992.
Cet article prsente le langage de dfinition de dclancheurs driv du langage
de rgle RDL1. Les rgles deviennent actives du fait quelles sont dclenches
suite des vnements (par exemple des mises jour). Elles sont dfinies dans
un langage de haut niveau avec une smantique de point fixe. Un grant dv-
nements implment au-dessus du SGBD SABRINA dclenche lvaluation des
rgles.
[Srivastava93] Srivastava D., Ramakrishnan, Seshadri P., Sudarshan S., Coral++ :
Adding Object-Orientation to a Logic Database Language , Proc. of the
19th Very Large Data Bases Int. Conf., Morgan Kaufman, p. 158-170, Dublin,
Ireland, 1993.
Cet article prsente le langage de rgles CORAL, extension de Datalog avec
des concepts objet. Le modle objet de CORAL est inspir de C++. Les
mthodes sont crites en C++. CORAL est compil en C++. Ce langage a t
ralis luniversit du Maddisson aux USA.
[Stonebraker86] Stonebraker M., Rowe A.L., The Postgres Papers , UC Berkeley,
ERL M86/85, BERKELEY, novembre 1986.
Une collection darticles sur POSTGRES. Ce systme supporte la dfinition de
rgles exploites lors des mises jour. Les rgles sont donc utilises pour dfi-
nir des dclencheurs. Elles permettent de rfrencer des objets complexes dfi-
nis sous forme de types abstraits de donnes. Elles se comportent comme des
rgles de production de syntaxe if <opration> on <relation> then <opra-
tions>. Les oprations incluent bien sr des mises jour. Un systme de prio-
rit est propos pour rgler les conflits en cas de rgles simultanment dclen-
chables. Ce mcanisme de rgles est aujourdhui commercialis au sein du
SGBD INGRES.
[Tarski55] Tarski A., A lattice theoretical fixpoint theorem and its applications ,
Pacific journal of mathematics, n 5, p. 285-309, 1955.
Larticle de base sur la thorie du point fixe. Il est notamment dmontr que
toute quation au point fixe construite avec des oprations monotones sur un
Bases de donnes dductives 583
treillis a une plus petite solution unique. Ce thorme peut tre appliqu pour
dmontrer que lquation au point fixe R = F(R) sur le treillis des relations, o
F est une expression de lalgbre relationnelle sans diffrence, a un plus petit
point fixe.
[Tsur86] Tsur D., Zaniolo C., LDL: a Logic-Based Data Language , Very Large
Databases Int. Conf., Kyoto, Japon, septembre 1986.
Une prsentation synthtique du langage LDL1 implment MCC. Cet article
insiste notamment sur le support de la ngation, des ensembles et des fonctions
externes.
[Ullman85] Ullman J.D., Implementation of logical query languages for
Databases , ACM SIGMOD Intl. Conf. on Management of Data, aussi dans
ACM TODS, vol. 10, N. 3, p. 289-321, 1986.
Une description des premires techniques doptimisation de programmes
Datalog. Le passage dinformations de ct est notamment introduit pour
remonter les constantes dans les programmes Datalog, y compris les pro-
grammes rcursifs.
[VanEmden76] Van Emden M., Kowalski R., The semantics of predicate logic as a
programming language , Journal of the ACM Vol.23, n 4, octobre 1976.
Une premire tude sur la smantique du point fixe, dveloppe dans le
contexte de la programmation logique. Plus tard, cette approche a t retenue
pour dfinir la smantique de Datalog.
[Vieille86] Vieille L., Recursive axioms in deductive databases : the query sub-
query approach , Proc. First Intl. Conference on Expert Database Systems,
Charleston, 1986.
Cet article dcrit la mthode QSQ, dont lextension QoSaQ a t implment
dans le prototype EKS lECRC entre 1986 et 1990. Ce prototype a t ensuite
repris pour donner naissance au produit Validity, un des rares DOOD.
[Zaniolo85] Zaniolo C., The representation and deductive retrieval of complex
objects , 11th Int Conf. on Very Large Data Bases, aot 1985.
Une extension de lalgbre relationnelle au support de fonctions. Cet article
prsente une extension de lalgbre relationnelle permettant de rfrencer des
fonctions symboliques dans les critres de projection et de slection, afin de
manipuler des objets complexes. Des oprateurs dductifs de type fermeture
transitive tendue sont aussi intgrs.
[Zaniolo86] Zaniolo C., Safety and compilation of non recursive horn clauses ,
MCC Tech. Report DB-088-85, 1986.
Une discussion des conditions assurant la finitude des prdicats gnrs par
des clauses de Horn et des questions poses sur ces prdicats.
Chapitre XVI
GESTION DE TRANSACTIONS
1. INTRODUCTION
En bases de donnes, le concept de transaction a t introduit depuis prs de trente ans
[Bjork72]. Ce concept est aussi dactualit dans les systmes dexploitation. Dans ce
chapitre, nous tudions les problmes lis la gestion de transactions dans les sys-
tmes de bases de donnes. Le concept de transaction est fondamental pour maintenir
la cohrence des donnes. Une transaction est une unit de mise jour compose de
plusieurs oprations successives qui doivent tre toutes excutes ou pas du tout. En
gestion, les transactions sont courtes (quelques secondes). En conception, elles peu-
vent tre beaucoup plus longues (quelques minutes voire quelques heures). Le SGBD
doit garantir les fameuses proprits ACID des transactions. Outre latomicit men-
tionne, les transactions effectuent des accs concurrents aux donnes qui doivent tre
contrls afin dviter les conflits entre lecteurs et crivains. Cela ncessite disoler
les mises jour dont les effets doivent par ailleurs tre durables. En consquence, la
gestion de transactions mlange intimement les problmes de fiabilit et de reprise
aprs panne avec les problmes de concurrence daccs. Les problmes de scurit
qui recouvrent la confidentialit sont aussi connexes.
Ce chapitre essaie de faire le point sur tous les aspects de la gestion de transactions
dans les SGBD centraliss. Aprs quelques rappels de base, nous traitons dabord les
problmes de concurrence. Nous introduisons la thorie de la concurrence, qui
sappuie sur le concept de srialisation, conduisant naccepter que les excutions
simultanes de transactions produisant les mmes rsultats quune excution squen-
586 BASES DE DONNES : OBJET ET RELATIONNEL
tielle des transactions, cest--dire lune aprs lautre. Nous exposons la technique de
verrouillage qui est une mthode prventive de conflits plutt pessimiste. Bien
quentranant des difficults telles que le verrou mortel, cette mthode est de loin la
plus applique. Cependant, nous analysons aussi les mthodes optimistes qui laissent
les conflits se produire et les corrigent aprs, telles que lordonnancement par estam-
pille, la certification et les contrles avec versions multiples.
Nous tudions ensuite les principes de la gestion de transactions. Tout repose sur les
algorithmes de validation et de reprise aprs panne. Nous approfondissons les outils
ncessaires ces algorithmes puis les diffrents algorithmes de validation et de
reprise, en incluant la validation en deux tapes, gnralement applique mme dans
les systmes centraliss. Comme exemple de mthode de reprise intgre, nous dcri-
vons la mthode ARIES implmente IBM, la rfrence en matire de reprise. Nous
terminons la partie sur les transactions proprement dites en prsentant les principaux
modles de transactions tendus introduits dans la littrature. Ces modles sont desti-
ns permettre un meilleur support des transactions longues, en particulier pour les
applications de conception qui ncessitent de longs travaux sur des objets complexes.
Ces modles sophistiqus commencent tre introduits dans les SGBD, notamment
dans les SGBD objet ou objet-relationnel.
Pour terminer ce chapitre, nous traitons du problme un peu orthogonal de confiden-
tialit. Beaucoup peut tre dit sur la confidentialit. Nous rsumons lessentiel des
mthodes DAC (Discretionary Access Control) et MAC (Mandatory Access Control).
La premire permet dattribuer des autorisations aux utilisateurs et de les contrler, la
seconde fonctionne avec des niveaux de confidentialit. Nous concluons par quelques
mots sur le cryptage des donnes.
2. NOTION DE TRANSACTION
Un modle simplifi de SGBD se compose de programmes utilisateurs, dun systme
et de mmoires secondaires. Les programmes accdent aux donnes au moyen dop-
rations du SGBD (Select, Insert, Update, Delete), gnralement en SQL. Ces opra-
tions dclenchent des actions de lecture et criture sur disques (Read, Write), qui sont
excutes par le systme, et qui conduisent des entres-sorties sur les mmoires
secondaires. Afin de pouvoir dterminer les parties de programmes correctement ex-
cutes, le concept de transaction a t propos depuis longtemps.
Elles sappliquent toujours sur les donnes les plus rcentes. Un exemple typique de
transaction est fourni par le banc dessais TPC A [Gray91]. Il sagit de raliser le
dbit/crdit sur une base de donnes bancaire. Le benchmark a pour objectif la mesure
des performances du SGBD en nombre de transactions excutes par seconde.
La base se compose des tables Agences, Comptes, Caissiers et Historique (voir
figure XVI.1). Une agence gre 100 000 comptes, possde 100 caissiers et comporte
un systme avec 10 terminaux.
1 100000
Agences Comptes
Caissiers Historique
100
Begin-Transaction
Update Account Set Balance = Balance + Delta
Where AccountId = Aid ;
Insert into History (Aid, Tid, Bid, Delta, TimeStamp) ;
Update Teller Set Balance = Balance + Delta
Where TellerId = Tid ;
Update Branch Set Balance = Balance + Delta
Where TellerId = Tid ;
End-Transaction.
Ces vingt dernires annes, lobjectif de tous les SGBD a t dexcuter un maximum
de telles transactions par seconde.
En pratique, les transactions doivent souvent cohabiter avec des requtes dcision-
nelles, traitant un grand nombre de tuples en lecture, souvent pour calculer des agr-
gats. Par exemple, une requte dcisionnelle pourra calculer la moyenne des avoir des
comptes par agence comme suit :
SELECT B.BRANCHID, AVG(C.BALANCE)
FROM BRANCH B, ACCOUNT C
WHERE B.BRACHID = C.BRANCHID
GROUP BY B.BRANCHID ;
Une telle requte parcourt tous les comptes et peut en consquence empcher les tran-
sactions dbit/crdit de sexcuter. Elle peut aussi tre bloque par les transactions
dbit/crdit. Nous allons tudier les solutions aux problmes des transactions ci-dessous.
2.2.1. Atomicit
Une transaction doit effectuer toutes ses mises jour ou ne rien faire du tout. En cas
dchec, le systme doit annuler toutes les modifications quelle a engages. Latomi-
cit est menace par les pannes de programme, du systme ou du matriel, et plus
gnralement par tout vnement susceptible dinterrompre une transaction en cours.
2.2.2. Cohrence
La transaction doit faire passer la base de donnes dun tat cohrent un autre. En
cas dchec, ltat cohrent initial doit tre restaur. La cohrence de la base peut tre
viole par un programme erron ou un conflit daccs concurrent entre transactions.
Gestion de transactions 589
2.2.3. Isolation
Les rsultats dune transaction ne doivent tre visibles aux autres transactions quune
fois la transaction valide, afin dviter les interfrences avec les autres transactions.
Les accs concurrents peuvent mettre en question lisolation.
2.2.4. Durabilit
Ds quune transaction valide ses modifications, le systme doit garantir quelles
seront conserves en cas de panne. Le problme essentiel survient en cas de panne,
notamment lors des pannes disques.
Ces proprits doivent tre garanties dans le cadre dun systme SGBD centralis,
mais aussi dans les systmes rpartis. Elles ncessitent deux types de contrle, qui
sont intgrs dans un SGBD : contrle de concurrence, rsistance aux pannes avec
validation et reprise. Nous allons les tudier successivement, puis nous tudierons la
mthode intgre ARIES qui est une des plus efficaces parmi celles implmentes
dans les SGBD.
3. THORIE DE LA CONCURRENCE
Cette section aborde les problmes de gestion des accs concurrents. Les solutions
proposes permettent de garantir la cohrence et lisolation des mises jour des tran-
sactions (le C et le I de ACID). Elles sont bases sur la thorie de la srialisabilit des
transactions, que nous examinons maintenant.
3.1. OBJECTIFS
Lobjectif gnral est de rendre invisible aux clients le partage simultan des donnes.
Cette transparence ncessite des contrles des accs concurrents au sein du SGBD.
Ceux-ci seffectuent au moyen de protocoles spciaux permettant de synchroniser les
mises jour afin dviter les pertes de mises jour et lapparitions dincohrences.
Une perte de mise jour survient lorsquune transaction T1 excute une mise jour
calcule partir dune valeur prime de donne, cest--dire dune valeur modifie
par une autre transaction T2 depuis la lecture par la transaction T1. La mise jour de
T2 est donc crase par celle de T1. Une perte de mise jour est illustre
figure XVI.3. La mise jour de la transaction T2 est perdue.
590 BASES DE DONNES : OBJET ET RELATIONNEL
T1 : Read A->a;
T2 : Read A->b;
T2 : b+1 -> b;
T2 : Write b->A;
T1: a*2 ->a;
T1: Write a -> A;
temps
Une incohrence apparat lorsque des donnes lies par une contrainte dintgrit
sont mises jour par deux transactions dans des ordres diffrents, de sorte
enfreindre la contrainte. Par exemple, soient deux donnes A et B devant rester
gales. Lexcution de la squence doprations {T1 : A = A+1 ; T2 : B = B*2 ; T2 :
A = A*2; T1: B=B+1} rend en gnral A diffrent de B, du fait de la non-commutati-
vit de laddition et de la multiplication. Elle provoque donc lapparition dune inco-
hrence. Cette situation est illustre figure XVI.4.
A=B
T1 : A*2->A;
T2 : A+1->A;
T2 : B+1 -> B;
T1 : B*2 -> B;
temps
jour, lisolation des mises jour nest pas suffisante : il faut aussi ne pas laisser deux
transactions modifier simultanment une mme donne.
T1 : Read A->a;
T2 : Read A->b;
T2 : b+1 -> b;
T2 : Write b->A;
temps
Un granule au sens de la concurrence peut tre une ligne, une page ou une table dans
un systme relationnel. Ce peut tre un objet ou une page dans un SGBD objet. Nous
discuterons de la taille du granule de concurrence plus loin.
Les granules de concurrence sont lus et crits par les utilisateurs, ventuellement par
parties. On appelle action un accs lmentaire un granule.
Un systme de bases de donnes excute donc une suite dactions rsultant de transac-
tions concurrentes. Aprs compltude dun ensemble de transactions (T1, T2Tn),
une histoire du systme peut tre reprsente par la suite des actions excutes. Plus
gnralement, toute suite dactions pouvant reprsenter une histoire possible sera
appele simplement excution.
Une excution respecte donc lordre des actions de chaque transaction participante et
est, par dfinition, squentielle. Par exemple, considrons les transactions T1 et T2
figure XVI.6, modifiant les donnes A et B relies par la contrainte dintgrit A = B ;
A et B appartiennent deux granules distincts, maximisant ainsi les possibilits de
concurrence. Une excution correcte de ces deux transactions est reprsente
figure XVI.7 (a). Une autre excution est reprsente figure XVI.7 (b), mais celle-l
est inacceptable car elle conduit une perte doprations.
T1 T2
Read A a1 Read A a2
a1+1 a1 a2*2 a2
Write a1 A Write a2 A
Read B b1 Read B b2
b1+1 b1 b2*2 b2
Write b1 B Write b2 B
T1 : Read A a1 T2 : Read A a2
T1 : a1+1 a1 T2 : a2*2 a2
T1 : Write a1 A T1 : Read A a1
T2 : Read A a2 T1 : a1+1 a1
T2 : a2*2 a2 T2 : Write a2 A
T2 : Write a2 A T2 : Read B b2
T1 : Read B b1 T2 : b2*2 b2
T1 : b1+1 b1 T1 : Write a1 A
T1 : Write b1 B T1 : Read B b1
T2 : Read B b2 T1 : b1+1 b1
T2 : b2*2 b2 T1 : Write b1 B
T2 : Write b2 B T2 : Write b2 B
(a) (b)
Par exemple, si le granule est la page, les oprations de base sont souvent LIRE
(page) et ECRIRE (page), qui sont galement dans bien des systmes des actions indi-
visibles. Si le granule est larticle, des oprations plus globales ncessitant plusieurs
actions indivisibles sont LIRE (article) et ECRIRE (article), mais aussi MODIFIER
(article) et INSERER (article). Avec ces oprations de base, il est possible den
construire dautres plus globales encore. Sur un objet typ, tel un compte en banque,
on peut distinguer des oprations, crer, crditer, dbiter, dtruire, etc.
Lapplication doprations des granules conduit des rsultats. Le rsultat dune
opration est constitu par ltat du granule concern aprs lapplication de lopra-
tion considre et par les effets de bords quelle provoque. Par exemple, le rsultat
dune opration LIRE est reprsent par la valeur du tampon rcepteur aprs excu-
tion, alors que le rsultat dune transaction modifiant une base de donnes est ltat
des granules modifis aprs excution ainsi que la valeur des messages dits.
Les oprations sont enchevtres au niveau des actions lors de lexcution simultane
de transactions. Deux oprations qui ne modifient aucun granule et qui appartiennent
deux transactions diffrentes peuvent tre enchevtres de manire quelconque sans
modifier les rsultats de leur excution. Autrement dit, toute intercalation doprations
neffectuant que des lectures conduit des rsultats identiques une excution suc-
cessive de ces oprations. Plus gnralement, il est possible de dfinir la notion
doprations compatibles.
Considrons par exemple les oprations reprsentes figure XVI.8. Les oprations
O11 et O21 sont compatibles ; O11 et O12 ne le sont pas.
Il est important de remarquer que deux oprations travaillent sur deux granules diff-
rents sont toujours compatibles. En effet, dans ce cas aucune perte doprations ne
594 BASES DE DONNES : OBJET ET RELATIONNEL
peut survenir si lon intercale les oprations. Or il est simple de voir que deux opra-
tions sont incompatibles lorsque quil existe une possibilit dintercalation gnrant
une perte doprations.
O11 O12
{ Read A a1 { Read A a2
a1+1 a1 a2*2 a2
Write a1 A } Write a2 A
O21 O22
{ Read B b1 { Read B b2
b1+1 b1 b2*2 b2
Write b1 B } Write b2 B }
O31
{ Read A a1
a1+10 a1
Write a1 A }
Par exemple, les oprations O11 et O31 reprsentes figure XVI.8 sont permutables
alors que les oprations O11 et O12 ne le sont pas. Soulignons que deux oprations
travaillant sur des granules diffrents sont toujours permutables. En effet, dans ce cas,
lexcution de la premire ne peut modifier le rsultat de la seconde et rciproque-
ment. Par exemple, O11 et O12 sont permutables. Plus gnralement, deux oprations
compatibles sont permutables, mais la rciproque nest pas vraie.
laisser sexcuter que des excutions sans pertes doprations ou inconsistances. Il est
bien connu que lexcution successive de transactions (sans simultanit entre tran-
sactions) est un cas particulier dexcution sans perte doprations ni inconsistances.
Une telle excution est appele succession et peut tre dfinie plus formellement
comme suit :
Afin dassurer labsence de conflit, il est simple de ne tolrer que les excutions qui
donnent le mme rsultat quune succession pour chaque transaction. De telles excu-
tions sont dites srialisables.
Ti : crire(D) Tj : crire(D) ;
Ti : crire(D) Tj : lire(D) ;
implique que Ti prcde Tj.
Considrons une excution simultane de transactions. La relation de prcdence
entre transactions peut tre reprsente par un graphe :
{ T1 : Lire A ; T1
T2 : Ecrire A ;
T2 : Lire B ;
T2 : Ecrire B ; A B
T3 : Lire A ;
T1 : Ecrire B } T2
T3
4. CONTRLE DE CONCURRENCE
PESSIMISTE
Deux types de techniques ont t dveloppes pour garantir la srialisabilit des tran-
sactions : les techniques de prvention des conflits qui empchent leur apparition et
598 BASES DE DONNES : OBJET ET RELATIONNEL
les techniques de dtection qui laissent les conflits se produire mais les dtectent et
annulent leurs effets. Les premires sont dites pessimistes car elles prviennent des
conflits qui ne surviennent en gnral pas. Elles sont bases sur le verrouillage. Les
secondes sont dites optimistes. Dans cette partie, nous tudions le verrouillage qui est
de loin la technique la plus applique.
Une transaction comporte donc deux phases (voir figure XVI.10) : une phase dacqui-
sition de verrous et une phase de relchement. Cette condition garantit un ordre iden-
tique des transactions sur les objets accds en mode incompatible. Cet ordre est celui
dexcution des points de verrouillage maximal . En pratique, afin de garantir liso-
lation des mises jour, les verrous sont seulement relchs en fin de transaction, lors
de la validation.
Nombre
de verrous
temps
L E
L V F
E F F
4.3.1. Dfinition
Le verrouillage soulve quelques problmes. Le problme essentiel est le risque de
verrous mortels entre transactions.
T1 T2
temps
Deux classes de solutions sont possibles dans les SGBD afin de rsoudre le problme
du verrou mortel : la premire, appele prvention, empche les situations de verrous
mortels de survenir ; la seconde, appele dtection, est une solution curative qui
consiste supprimer les verrous mortels par reprise de transactions.
simple. En effet, si le graphe des attentes possde un circuit, cest quil existe un
groupe de transactions tel que : T1 attend T2, T2 attend T3,Tk attend T1. Chaque
transaction du groupe est donc bloque en attente dun objet du fait de lutilisation de
cet objet par une autre transaction du groupe. La fin dexcution de toutes les transac-
tions nappartenant pas au groupe ne permet donc pas de dbloquer une transaction du
groupe.
T1 T2
T1 T4
T2 T3 T5
Il est intressant dtablir le rapport entre graphes des attentes et graphe de prc-
dence. Par dfinition, si une transaction Ti attend une transaction Tj, alors Tj a ver-
rouill un objet O dont le verrouillage est demand par Ti dans un mode incompatible.
Ainsi, lopration pour laquelle Tj a verrouill O sera excute avant celle demande
par Tj car les deux oprations sont incompatibles et donc non permutables. Donc Tj
prcde Ti. Toutefois, la relation de prcdence nimplique gnralement pas la
relation dattente. Donc, en changeant lorientation des arcs du graphe des attentes, on
obtient un sous-graphe du graphe de prcdence. Cela implique que si le graphe des
attentes a un circuit, il en sera de mme pour le graphe de prcdence. En cons-
quence, une situation de verrou mortel ne peut pas donner lieu une excution sriali-
sable mme sil tait possible de terminer les transactions interbloques.
Gestion de transactions 603
T1 T2
G1 G2
celle dun circuit dans le graphe des attentes. Sous cette condition, la prsence dun
circuit dans le graphe des allocations entrane ainsi celle dun circuit dans le graphe de
prcdence.
// Algorithm WAIT-DIE
Procdure Attendre (Ti,Tj) {
// Ti rclame un verrou tenu par Tj
si ts(Ti) < ts(Tj) alors Ti waits sinon Ti dies ; }
Lalgorithme WOUND-WAIT est un peu plus subtil. Tout type dattente est permis.
Mais si une transaction plus ancienne attend une plus rcente, la rcente est blesse
(wounded), ce qui signifie quelle ne peut plus attendre : si elle rclame un verrou
Gestion de transactions 605
tenu par une autre transaction, elle est automatiquement dfaite et reprise. Le contrle
des attentes impos par lalgorithme est reprsent figure XVI.18 ; une transaction
blesse ne peut donc attendre.
// Algorithm WOUND-WAIT
Procdure Attendre (Ti,Tj) {
// Ti rclame un verrou tenu par Tj
si ts(Ti) < ts(Tj) alors Tj is wounded sinon Ti waits ; }
Les deux algorithmes empchent les situations de verrous mortels en donnant priorit
aux transactions les plus anciennes. Lalgorithme WOUND-WAIT provoque en prin-
cipe moins de reprises de transactions et sera en gnral prfr.
sinon. Le code de cette procdure est analogue celui de lalgorithme LOCK vu ci-
dessus, ceci prs que seule les transactions de T sont prises en compte (les autres
sont supposes excutes et termines) et que ltat de verrouillage nest pas modifi.
La figure XVI.19 prsente une procdure DETECTER rpondant VRAI sil y a situa-
tion de verrou mortel et FAUX sinon. Cette procdure limine donc progressivement
les transactions pendantes du graphe des attentes.
Quand une situation dinterblocage est dtecte, le problme qui se pose est de choisir
une transaction recycler de faon briser les circuits du graphe des attentes. Lalgo-
rithme de dtection prsent ci-dessus fournit la liste des transactions en situation
dinterblocage. Il faut donc choisir une transaction de cette liste. Cependant, tous les
choix ne sont pas judicieux, comme le montre la figure XVI.20. Une solution ce
problme peut tre de recycler la transaction qui bloque le plus grand nombre dautres
transactions, cest--dire qui correspond au sommet de demi-degr intrieur le plus
lev sur le graphe des attentes. Le choix de la transaction reprendre doit aussi cher-
cher minimiser le cot de reprise.
T1
T2 T3
Le cot dune solution de type dtection avec reprise peut tre rduit. En effet, il est
possible de dclencher un algorithme dtection seulement quand une transaction
attend un verrouillage depuis un temps important (par exemple, quelques secondes),
plutt qu chaque dbut dattente.
Dautres algorithmes de dtection sont possibles. Le graphe dallocation est souvent
utilis dans les systmes rpartis. Lors dune attente qui dure, un algorithme envoie
une enqute le long des arcs du graphe des allocations. Cette enqute est transmise au
granule attendu, puis aux transactions bloquant ce granule, puis aux granules attendus
sil en existe, etc. Si lenqute revient la transaction initiale, cest quil y a un verrou
mortel. Cet algorithme est moins efficace en centralis.
valide puisque T2 accde un granule non verrouill qui nexiste mme pas lorsque
T1 excute sa 1re partie : le tuple Fantomas . Toutefois, le rsultat de T1 est une
liste de 4 noms alors que le nombre de passagers est 5. Fantomas est ici un fan-
tme pour T1.
Durand 100 5
Dupont 100 10
Martin 100 15
Ce problme, ainsi que la difficult de citer les granules verrouiller, peuvent tre
rsolus par la dfinition de granules logiques (dans lexemple, les passagers du
vol 100) au moyen de prdicats [Eswaran76]. Le verrouillage par prdicat permet ga-
lement de dfinir des granules de tailles variables, ajustes aux besoins des transac-
tions. Malheureusement, il ncessite des algorithmes pour dterminer si deux prdi-
cats sont disjoints et ce problme de logique na pas de solution suffisamment efficace
pour tre appliqu dynamiquement lors du verrouillage des objets. De plus, les prdi-
cats sont dfinis sur des domaines dont les extensions ne sont pas consultables dans la
base pour des raisons videntes de performance. Donc, il est trs difficile de dtermi-
ner si deux prdicats sont disjoints ; par exemple, PROFESSION = Ingnieur et
SALAIRE < 7000 seront dtermins logiquement non disjoints, alors quils le sont
dans la plupart des bases de donnes. Le verrouillage par prdicat est donc en pratique
source dattentes inutiles et finalement inapplicable.
L E IL IE
L V F V F
E F F F F
IL V F V V
IE F F V V
Une telle mthode peut tre applique dans les bases relationnelles, mais aussi objet.
Le graphe dinclusion pour une base de donnes objet peut tre base, extension de
classe, page ou groupe (cluster) et objet. Il est reprsent figure XVI.23.
base
classe
cluster page
objet
Objets
w = write
T1 T2
d
w w T3 w T4 w
c
Commit w Abort
b
Abort
Commit Temps
transactions non encore termines. Il faut donc grer la porte des transactions, par
exemple sous forme de listes de transactions dpendantes. Leffet domino introduit ci-
dessus survient : lors de la reprise dune transaction, toutes les transactions dpen-
dantes doivent tre reprises.
[Ins,ok] 1 0 0 0
[Del,ok] 0 1 0 1
[In,true] 0 0 1 1
[In,False] 0 1 1 1
5. CONTRLES DE CONCURRENCE
OPTIMISTE
Le verrouillage est une solution pessimiste : il empche les conflits de se produire, ou
plutt les transforme en verrou mortel. Analysons maintenant une autre gamme de
Gestion de transactions 613
solutions qualifies doptimistes qui laissent se produire les conflits et les rsout
ensuite.
Il est en gnral trs difficile de refaire le pass. Cependant, il est parfois possible de
forcer lordonnancement des critures de Ti en insrant une nouvelle version cre par
Ti juste aprs celle destampille immdiatement infrieure, soit Oj. Malheureusement,
si une transaction Tk (k >i) a lu la version Oj, alors cette lecture doit aussi tre res-
quence. Ce nest possible que si la transaction Tk pouvait tre reprise. Afin dviter
la reprise de transactions termines, on prfrera reprendre lcrivain Tj avec une nou-
velle estampille i suprieure k.
Lalgorithme de contrle de lopration WRITE correspondant est reprsent
figure XVI.29. Les notations sont identiques celles utilises ci-dessus, les indices
dsignant les numros de versions dobjets.
W R W R W R
1 1 5 7 7 10
(a) Lecture de T3
La version 1 est dlivre
(b) criture de T3 : cration d une version 3 non lue
3
(c) criture de T6
Impossible : T7 et T10 devraient tre rexcutes
T6 est annule et reprise plus tard comme T12
Version 3
Les transactions entrent en conflit sur un objet O unique dont les versions successives
sont reprsentes par des rectangles. La situation originale est reprsente en haut de
la figure. Trois versions de lobjet existent, successivement cres par les transactions
1, 5 et 7. La version 1 a t lue par la transaction 1, la version 5 par la transaction 7 et
la version 7 par la transaction 10. Nous supposons que T3 accomplit une criture sur
lobjet O aprs lavoir lu. La nouvelle version 3 cre est insre en bonne place.
Nous supposons ensuite que T6 procde une criture sur O. Lobjet ayant t lu par
T7, il faudrait refaire le pass. On prfrera annuler T6 et la relancer plus tard.
En rsum, beaucoup dalgorithmes bass sur des estampilles peuvent tre invents
pour contrler les accs concurrents. Il est mme possible de mixer estampilles et ver-
rouillage, comme dj vu au niveau des algorithmes DIE-WAIT et WOUND-WAIT.
Cependant, les performances de ces algorithmes restent faibles car ils provoquent tous
des reprises qui deviennent de plus en plus frquentes lorsquil y a un plus grand
nombre de conflits, donc lorsque le systme est charg. Voil sans doute pourquoi la
plupart des SGBD utilisent le verrouillage deux phases.
Begin_Trans
update
unit d'uvre
update
savepoint Non-perte du contexte
update
unit d'uvre
update
End_Trans
Les objectifs premiers de la rsistance aux pannes sont de fournir un protocole aux
applications permettant dassurer latomicit. Pour ce faire, une application doit pou-
voir commencer lexcution dune transaction et la terminer avec succs ou par un
chec. Des actions atomiques sont ainsi fournies par le systme de gestion de transac-
tions aux applications. En plus de la cration dune transaction, ces actions correspon-
dent aux trois notions de validation (encore appele commitment, consolidation ou
confirmation), dannulation (encore appele abort ou abandon ou retour arrire) et de
reprise (encore appele restauration ou redo). Nous dfinissons ci-dessous ces trois
notions.
La validation est donc la terminaison avec succs dune transaction. Dans le cas de
transactions composes de plusieurs units duvre, une validation est effectue la
fin de chaque unit duvre. Loppos de la validation est lannulation.
Notez que seules les transactions non valides peuvent tre annules. Dfaire une
transaction valide est une opration impossible sauf utiliser des versions ant-
rieures de la base. Par contre, une transaction dfaite peut tre refaite (on dit aussi
rejoue) : cest lobjet de la reprise.
La reprise peut seffectuer partir de journaux des mises jour, comme nous le ver-
rons ci-dessous. Elle peut aussi ncessiter une nouvelle excution de la transaction.
elle ne peut tre dtruite que par une panne catastrophique explicite ou par une rcri-
ture.
Dans les SGBD, la mmoire stable est le disque ; il permet de mmoriser les donnes
persistantes. La ralisation dune mmoire sre garantissant latomicit des critures nest
pas triviale. Les techniques utilises sont en gnral les codes de redondances, ainsi que
les doubles critures. Dans la suite, nous considrons les mmoires stables comme sres.
Les transactions actives excutent des mises jour dont leffet apparat dans le cache
et nest pas instantanment report sur disque. En thorie, leffet dune transaction
devrait tre report de manire atomique lors de la validation. La figure XVI.32
illustre les mouvements entre mmoire volatile (le cache) et mmoire stable souhai-
tables lors de la validation ou de lannulation.
Cache volatile
Update
Update
Commit
Abort
Bases de donnes
Nant
Ceci est la vue logique donne lutilisateur. En pratique, les mcanismes pour assu-
rer un tel fonctionnement logique sont plus complexes.
Le journal des images avant est utilis pour dfaire les mises jour dune transaction
(undo). Pour cela, il doit tre organis pour permettre daccder rapidement aux enre-
gistrements correspondant une transaction. Un fichier hach sur lidentifiant de tran-
saction (TrId) sera donc opportun.
Le journal des images aprs est utilis pour refaire les mises jour dune transaction
(redo). Comme le journal des images aprs, il doit tre organis pour permettre
daccder rapidement aux enregistrements correspondant une transaction. Un fichier
hach sur lidentifiant de transaction (TrId) sera donc opportun.
En guise dillustration, la figure XVI.33 reprsente un enregistrement dun journal
contenant la fois les images avant et aprs. Les enregistrements sont prcds dune
lettre R (Redo) pour les images aprs, U (Undo) pour les images avant, et T
(Transaction) pour les changements dtats des transactions.
Gestion de transactions 623
Comme indiqu ci-dessus, les modifications sont tout dabord excutes dans des
caches en mmoire. Ces caches sont volatils, cest--dire perdus lors dune panne. Ce
nest bien souvent que lors de la validation que les mises jour sont enregistres dans
le journal et dans la base. Afin dtre capable dannuler une transaction dans tous les
cas, il faut crire les enregistrements dans le journal avant de reporter le cache dans la
base, comme illustr figure XVI.34.
Journal
2.Log 4.Log
3.Update
Page lue Page modifie
1.Read 5.Write
Base persistante
Lordre dans lequel les oprations doivent tre accomplies est indiqu sur la figure.
Les rgles suivantes sont souvent conseilles [Bernstein87] :
1. Avant dcrire une page modifie en mmoire stable, il faut enregistrer son image
avant dans le journal (pour pouvoir dfaire) ainsi que son image aprs (pour pou-
624 BASES DE DONNES : OBJET ET RELATIONNEL
voir refaire). Cette rgle est connue sous le nom de journalisation avant criture
(log ahead rule).
2. Toutes les pages modifies en mmoire volatile par une transaction doivent tre
crites en mmoire stable, donc sur disque, avant la validation de la transaction.
Cette dernire rgle est connue sous le nom de validation aprs criture (commit
after rule).
Lapplication de ces deux rgles conduit naturellement enregistrer journal puis page
modifie sur disques soit chaque mise jour, soit en fin de transaction avant le com-
mit effectif. Elles sont donc trs limitatives. En consquence, la premire est gnrale-
ment suivie pour viter de ne pouvoir dfaire des transactions non valides ou refaire
des valides. La seconde peut tre relaxe avec quelques prcautions. Dans certains
cas, par exemple si les journaux sont doubls ou si la base est double par une base
miroir, ces deux rgles peuvent tre remplaces par des rgles plus souples.
Lutilisation dun journal cote trs cher : chaque mise jour ncessite a priori trois
entres-sorties. Afin damliorer les performances, les enregistrements du journal sont
gnralement gards dans un tampon en mmoire et vids sur disques lorsque le tam-
pon est plein. Malheureusement, il faut crire le journal avant dcrire dans la base
pour pouvoir dfaire ou refaire les mises jour de la mmoire stable. La technique
utilise pour rsoudre ce problme consiste bloquer ensemble plusieurs validations
de transactions.
Ainsi, le systme peut attendre quun tampon du journal soit plein avant de le vider.
Lorsquune transaction commet, si le tampon nest pas plein, elle attend que dautres
transactions effectuent des mises jour pour remplir le tampon. Si le systme est peu
actif, un dlai maximal (time out) permet de forcer le vidage du tampon journal.
Soulignons que le journal est en gnral compress, pour rduire sa taille au maxi-
mum et aussi maximiser le nombre de transactions commises simultanment.
Un dernier problme concernant le journal est celui de sa purge. En effet, on ne peut
enregistrer indfiniment les enregistrements tudis sur un disque dans un fichier
hach. Mme avec du hachage extensible, le fichier risque de devenir important et dif-
ficile grer. En consquence, les systmes changent priodiquement de fichier jour-
nal. Il est possible par exemple de tourner sur N fichiers hachs, en passant au suivant
chaque fois que lun est plein ou au bout dune priode donne. Un fichier journal qui
nest plus actif est vid dans une archive. Il sera rutilis plus tard pour une nouvelle
priode de journalisation.
Gestion de transactions 625
Une sauvegarde peut par exemple tre effectue en dbut de chaque semaine, de
chaque journe, de chaque heure. La prise de sauvegarde pendant le fonctionnement
normal du systme est un problme difficile. Pour cela, un mcanisme de verrouillage
spcifique ou mieux, un mcanisme de multi-versions [Reed79] peut tre utilis.
7. VALIDATION DE TRANSACTION
Comme indiqu ci-dessus, la validation de transaction doit permettre dintgrer toutes
les mises jour dune transaction dans une base de donnes de manire atomique,
cest--dire que toutes les mises jour doivent tre intgres ou quaucune ne doit
ltre. Latomicit de la validation de transaction rend les procdures dannulation de
626 BASES DE DONNES : OBJET ET RELATIONNEL
transactions non valides simples. Le problme est donc de raliser cette atomicit.
Plusieurs techniques ont t introduites dans les systmes afin de raliser une valida-
tion atomique. Elles peuvent tre combines afin damliorer la fiabilit [Gray81]. La
plupart des SGBD combinent dailleurs les critures en place et la validation en deux
tapes.
Enregistrements
dans le journal
Enregistrements
dans le journal
Lannulation dune transaction ayant mis en place des mises jour dans la base est
une procdure difficile. Elle seffectue partir du journal des images avant. Lannula-
tion ncessite le parcours du journal lenvers, cest--dire en reculant dans le temps.
Nom
Fichier
Adresse Validation
Table des Pages
Page ombre Page ombre
Nouvelles pages
Le protocole ncessite la journalisation des mises jour prpares et des tats des
transactions dans un journal local chaque participant, ceci afin dtre capable de
retrouver ltat dune transaction aprs une ventuelle panne et de continuer la valida-
tion ventuelle. Le protocole est illustr figure XVI.37 dans le cas favorable o un site
client demande la validation deux sites serveurs avec succs. Notez quaprs excu-
tion de la demande de validation (VALIDER), les participants envoient un acquitte-
ment (FINI) au coordinateur afin de lui signaler que la transaction est maintenant ter-
mine.
Coordinateur
Participant 1 Participant 2
prparer prparer
prt prt
valider valider
fini fini
Le cas de la figure XVI.38 est plus difficile : le participant 2 est en panne et ne peut
donc rpondre au message de demande de prparation. Une absence de rponse est
assimile un refus. Le coordinateur annule donc la transaction et envoie le message
ANNULER. Le participant 1 annule la transaction. Le participant 2 lannulera
lorsquil repartira aprs la panne, une transaction non prte tant toujours annule.
Coordinateur
Participant 1 Participant 2
prparer prparer
prt
timeout
panne
abandon abandon
fini
fini reprise
Le cas de la figure XVI.39 est encore plus difficile : le participant 2 tombe en panne
aprs avoir rpondu positivement la demande de prparation. Le coordinateur
envoie donc le message COMMIT qui nest pas reu par le participant 2.
Heureusement, celui-ci a d sauvegarder ltat de la sous-transaction et ses mises
jour dans un journal fiable sur disque. Lors de la procdure de reprise, le journal sera
examin. La transaction tant dtecte prte commettre, son tat sera demand au
coordinateur (ou a un participant quelconque) par un message appel STATUS. En
rponse ce message, la validation sera confirme et les mises jour seront appli-
ques partir du journal. Les deux sous-transactions seront donc finalement valides.
Coordinateur
Participant 1 Participant 2
prparer prparer
prt prt
valider valider
panne
fini
prt reprise
valider
prt
Au-del du protocole en deux tapes, il existe des protocoles en trois tapes qui vi-
tent les blocages du protocole prcdent en cas de panne du coordinateur. Le plus cou-
rant est le protocole dit dabort suppos, qui en cas de panne du coordinateur suppose
labandon de la transaction. Ceci est mme possible en deux phases [Mohan86].
Le protocole en deux tapes a t standardis par lISO. TP est le protocole standard
propos par lISO dans le cadre de larchitecture OSI afin dassurer une validation
cohrente des transactions dans un systme distribu. Le protocole est arborescent en
ce sens que tout participant peut dclencher une sous-transaction distribue. Un site
responsable de la validation de la sous-transaction est choisi. Un coordinateur est res-
ponsable de ses participants pour la phase 1 et collecte les PREPARE. Il demande
ensuite la validation ou labort selon la dcision globale un site appel point de vali-
dation qui est responsable de la phase 2 : cest le point de validation qui envoie les
COMMIT aux participants. Lintrt du protocole, outre laspect hirarchique, est que
le point de validation peut tre diffrent du coordinateur : ce peut tre un nud cri-
tique dans le rseau dont la prsence la validation est ncessaire. La figure XVI.40
illustre ce type de protocole hirarchique avec point de validation.
Gestion de transactions 631
Coordinateur global
Coordinateur
local
Point de validation
Coordinateur (Nud critique)
local
La reprise normale ne pose pas de problme. Elle a lieu aprs un arrt normal de la
machine. Lors de cet arrt, un point de reprise systme est crit comme dernier enre-
632 BASES DE DONNES : OBJET ET RELATIONNEL
Dbut transaction i
M1 (i)
Dbut transaction i+1
M1 (i+1)
Dbut transaction i+2
M1 (i+2)
M2 (i)
Les transactions i et (i+2) sont gagnantes alors que (i+1) et (i+3) sont perdantes.
Mj(i) dsigne la je mise jour de la transaction i. Les mises jour dfaites sont mar-
ques par une flche.
Cette procdure est excute lors des redmarrages du systme quand le dernier enre-
gistrement du journal nest pas un point de reprise et que loprateur ne signale pas
une perte de mmoire secondaire.
9. LA MTHODE ARIES
ARIES (Algorithm for Recovery and Isolation Exploiting Semantics) [Mohan92] est
une des mthodes de reprise de transactions des plus efficaces. Elle est la base des
algorithmes de reprises implments dans de nombreux systmes, dont ceux des
SGBD dIBM. Ralise dans le cadre du projet de SGBD extensible dIBM Starburst,
cette mthode sest impose comme une des meilleures mthodes intgres.
Gestion de transactions 635
9.1. OBJECTIFS
Les objectifs essentiels initiaux de la mthode taient les suivants [Mohan92] :
Simplicit. Vu la complexit du sujet, il est essentiel de viser la simplicit de
sorte tre applicable en vraie grandeur et garantir des algorithmes robustes.
Cest dailleurs vrai pour tous les algorithmes, au moins en systme.
Journalisation de valeur et dopration. Classiquement, ARIES permet de dfaire
et refaire une mise jour avec les images avant et aprs. Au-del, la mthode
intgre la possibilit de journaliser des oprations logiques, comme incrment et
dcrment dun compte. Cela permet le verrouillage smantique avec des modes
doprations sophistiqus, pour supporter des excutions oprations commutatives
non srialisables au niveau des lectures et critures. Ceci est important pour per-
mettre une meilleure concurrence, comme vu ci-dessus. Une des difficults dans ce
type de journalisation par opration est de bien associer un enregistrement du jour-
nal avec ltat de la page qui lui correspond : ceci est accompli astucieusement avec
un numro de squence denregistrement journal (Log Sequence Number, LSN)
mmoris dans la page. Une autre difficult est due aux pannes pendant la reprise :
il faut pouvoir savoir si lon a refait ou non une opration. Ceci est accompli en
journalisant aussi les mises jour effectues pendant la reprise par des enregistre-
ments de compensation (Compensation Log Records, CRLs).
Gestion de mmoire stable et du cache flexible. La mmoire stable est gre effi-
cacement. Diffrentes stratgies de report du cache sont utilisables. Reprise et ver-
rouillage sont logiques par nature ; cela signifie que la reprise reconstruit une base
cohrente qui nest pas forcment physiquement identique la base perdue (pages
diffrentes), mais aussi que les verrouillages sont effectus des niveaux de granu-
larits variables, en utilisant le verrouillage dintention vu ci-dessus.
Reprise partielle de transactions. Un des objectifs de la mthode est de pouvoir
dfaire une transaction jusquau dernier point de sauvegarde. Cest important pour
pouvoir grer efficacement les violations de contraintes dintgrit et lutilisation de
donnes primes dans le cache.
Reprise granulaire oriente page. La mthode permet de reprendre seulement une
partie de la base, la reprise dun objet (une table par exemple) ne devant pas impli-
quer la reprise dautres objets. La reprise est oriente page en ce sens que la granu-
larit de reprise la plus fine est la page : si une seule page est endommage, il doit
tre possible de la reconstruire seule.
Reprise efficace et rapide. Il sagit bien sr davoir de bonnes performances, la
fois pendant lexcution normale de transactions et pendant la reprise. Lide est de
rduire le nombre de pages rcrire sur disques et le temps unit central ncessaire
la reprise.
Outre ces quelques objectifs, ARIES en a atteint de nombreux autres tels que lespace
disque minimal ncessaire en dehors du journal, le support dobjets multi-pages, la
636 BASES DE DONNES : OBJET ET RELATIONNEL
UndoNxtLSN Undo next LSN : LSN de lenregistrement suivant traiter pendant la reprise
arrire.
Prsent seulement pour les enregistrements de compensation.
Data Data : Donnes dcrivant la mise jour qui a t effectue, soit limage avant
et limage aprs, soit lopration et son inverse si elle ne sen dduit pas.
Prsent seulement pour les enregistrements de mise jour ou de compensation
qui nont que les informations pour refaire.
Pour chaque page de donnes, ARIES ncessite un seul champ par page nomm
page_LSN qui mmorise le numro LSN du dernier enregistrement du journal qui
concerne cette page.
En plus, ARIES gre une table des transactions utilise pendant la reprise pour
mmoriser ltat de validation des transactions actives (Prte ou Non dans le protocole
deux phases), et enfin une table des pages sales, cest--dire modifie en cache et
ne correspondant plus la version sur mmoire stable.
Gestion de transactions 637
Une deuxime passe de reconstruction est ensuite effectue, durant laquelle ARIES
rpte lhistoire mmorise dans le journal et non enregistre sur mmoire stable.
Ceci est fait pour toutes les transactions, y compris celles qui navaient pas t vali-
des au moment de la panne. Lobjectif est de rtablir ltat de la base au moment de
la panne. Un enregistrement du journal est appliqu en avant (refait) sur une page si
son LSN est suprieur celui de la page, ce qui rduit le nombre de rfactions nces-
saires. Durant cette phase, les verrous pour les transactions prtes valider au
moment de la panne sont restaurs, afin de pouvoir les relancer.
Une troisime passe de rparation consiste dfaire les transactions perdantes,
cest--dire celles non valides ou non prtes valider au moment de la panne. Ceci
seffectue par parcours du journal en arrire depuis le plus grand LSN restant traiter
pour les transactions perdantes. Si lenregistrement du journal est un enregistrement
normal, les donnes dannulation (image avant ou opration inverse) sont appliques.
Lenregistrement suivant traiter pour la transaction est alors dtermin en regardant
le champ PrevLSN. Sil sagit dun enregistrement de compensation, il est simple-
ment utilis pour dterminer lenregistrement suivant traiter mmoris dans
UndoNxtLSN, puisque les enregistrements de compensation ne sont jamais compen-
ss.
En rsum, la mthode comporte donc trois passes : analyse, reconstruction en avant
et rparation en arrire. Grce aux chanages intelligents des enregistrements du jour-
nal et la mmorisation du numro de squence du dernier enregistrement pertinent
au niveau de chaque page, la mthode vite de refaire et dfaire des mises jour inuti-
lement. Elle intgre aussi la possibilit dannulation logique ou physique doprations,
ce qui permet des verrouillages en modes varis exploitant la commutativit. La
mthode a t implmente dans de nombreux systmes industriels.
On obtient ainsi un arbre de transactions (voir figure XVI.44). Une transaction fille
est lance par sa mre par excution dune commande BEGIN ; elle rend un compte-
rendu sa mre qui se termine aprs toutes ses filles. De manire classique, chaque
(sous-)transaction se termine par COMMIT ou ABORT et est une unit atomique tota-
lement excute ou pas du tout. Chaque (sous-)transaction peut tre refaite (REDO)
ou dfaite (UNDO) par un journal hirarchis.
Begin(T)
Begin(t'1) Begin(t1)
Commit(t'1) Commit(t1)
Begin(t2)
Begin(t21)
Commit(t21)
Abort(t2)
Commit(T)
La validation dune transaction fille est conditionne par celle de ses anctres, et ce
rcursivement.
En consquence, bien que chaque transaction se termine par COMMIT ou ABORT, la
validation nest confirme que lorsque tous les anctres ont valid. Le modle ferm
[Moss85] garantit latomicit de la transaction globale. Donc un chec dune sous-
transaction implique une annulation de la mre. Ceci est trs limitatif, mais conserve
les proprits ACID entre transactions globales. Au contraire, le modle ouvert
relche latomicit de la transaction globale.
Du point de vue de la concurrence, chaque (sous-)transaction applique le verrouillage
deux phases. Les verrous sont hrits dans les deux sens : lorsquune transaction fille
rclame un verrou tenu par un de ses anctres, elle nest pas bloque ; lorsquune tran-
saction fille valide, les verrous quelle a acquis sont transmis sa mre. Deux (sous-
)transactions peuvent donc se bloquer voir sinterbloquer si le verrou nest pas tenu
par un anctre commun. Ceci complique les dtections de verrous mortels.
Le modle ouvert relche donc la ncessit datomicit des transactions globales.
Alors, une (sous-)transaction peut tre annule alors que sa mre est valide. Le travail
est donc seulement partiellement ralis. Ceci ncessite lintroduction de transactions
de compensation [Korth90]. Par exemple, la compensation dune transaction achetant
de la marchandise consiste rendre cette marchandise. Une (sous-)transaction de com-
pensation dfait donc une (sous-)transaction prcdemment excute. Une variante est
une transaction de complment. Ces transactions de complment viendront plus tard
refaire les portions de travail non valides. Par exemple, le complment dune transac-
tion de mise jour dun ouvrage qui a chou sur le chapitre II est une transaction qui
met jour le chapitre II. Finalement, ds que lon relche latomicit, il est ncessaire
dintroduire de telles transactions dpendant de la smantique de lapplication.
Ces principes ont conduit dfinir un modle de transactions imbriques ouvert trs
flexible [Weikum92]. Outre latomicit, ce modle relche en plus le principe disola-
tion en laissant les rsultats des sous-transactions commises visibles aux transactions
concurrentes. La reprise ncessite alors de grer des sphres dinfluence de transac-
tions, gnralisation de la notion de trane dj vue. La smantique des oprations est
aussi intgre pour grer les commutativits doprations types. De tels modles
commencent tre implments dans les SGBD classiques. Leurs limites et intrts
restent encore mal connus.
T1 T2 T3 ... Tn
T1 T2 CT2 CT1
Lintrt des sagas est de pouvoir relcher le principe disolation. En effet, chaque
transaction composante relche ses verrous ds quelle est termine. Une autre saga
peut alors voir les rsultats. Lannulation de la saga doit donc provoquer lannulation
de lautre saga. Pour cela, il suffit denchaner les transactions de compensation.
met de contrler les transactions par des ordres du type If abort, If commit, Run alter-
native, Run compensation, etc. Le moniteur contrle les transactions et excute les
programmes de ce langage. On obtient ainsi des systmes de gestion de la coopration
trs flexibles, proches des workflows [Rusinkiewicz95].
BD PARTAG
Objet
versionnable
CheckOut
V1
Version
CheckIn personnelle
V2
V3 CheckOut
Version
CheckIn personnelle
V4
Drivation Drivation
Lecture Ecriture
Partage Exclusive
Lecture 1 0 1 1
criture 0 0 0 0
Drivation
1 0 1 0
Partage
Drivation
1 0 0 0
Exclusive
Lors de la rinsertion dune version dans la base (Check-in), le graphe de versions est
mis jour et la nouvelle version ajoute comme une fille de celle dont elle drive. Les
versions sont gnralement maintenues en diffrentiel, cest--dire que pour un nud
donn de larbre, seuls les attributs ou pages modifis par rapport au nud pre sont
maintenus. Le problme qui se pose est de faire converger les versions. Si deux ver-
sions drivant dun anctre commun nont pas de donnes communes modifies, une
fusion automatique peut tre ralise par intgration de toutes les mises jour effec-
tues lanctre. Sinon, il y a ncessit de dfinir des procdures de rconciliation de
versions, voire dune intervention manuelle effectuant des choix.
Au-del de ces modles fort nombreux, des formalismes de comprhension et descrip-
tion ont t proposs. ACTA [Chrysanthis90] est un cadre pour spcifier et raisonner
sur la structure des transactions et leur comportement. Il permet dexprimer la sman-
644 BASES DE DONNES : OBJET ET RELATIONNEL
tique des interactions entre transactions en termes deffets sur la validation ou lannu-
lation des autres transactions, et sur ltat des objets et des synchronisations nces-
saires. Il permet ainsi de dcrire et de raisonner sur un modle dactivit ou de tran-
saction.
Un premier moyen de violer la scurit des donnes est pour un sujet de se faire pas-
ser pour un autre. Afin dviter cela, un procd dauthentification des sujets est
introduit.
tifs. Il est donc souhaitable de choisir des mots de passe longs (plus de 7 caractres),
comportant un mixage de caractres numriques, alphanumriques et de contrle.
Dautres procds plus sophistiqus et plus srs sont lutilisation de questionnaires,
lexcution dalgorithmes connus seulement par lobjet et le sujet, lutilisation de
badges, de cartes puces, dempreintes digitales ou dempreintes de la rtine. Ces
derniers procds ncessitent un priphrique spcialis.
La dfinition des sujets ne pose a priori pas de problme : tout utilisateur est un sujet.
Cependant, il est utile de considrer des groupes dutilisateurs.
La notion de groupe peut tre tendue de manire hirarchique, avec des sous-
groupes. Dans ce cas, un groupe hrite de toutes les autorisations de ses antcdents
hirarchiques. Il est aussi possible de superposer plusieurs hirarchies [Fernandez80].
Egalement, un sujet peut tre un ensemble de transactions catalogues ; laccs ces
transactions doit alors tre aussi protg.
Un utilisateur peut joindre ou quitter un groupe. La dynamique des groupes lors des
dparts de personnes dans une entreprise peut tre un problme : il faut par exemple
enlever un utilisateur et le remplacer par un autre. Attribuer ou enlever de multiples
droits des groupes devient rapidement difficile lors des changements de fonctions.
Pour viter ces problmes, les SGBD ont introduit la notion de rle.
Ainsi, des droits sur les objets sont attribus aux rles. Ceux-ci peuvent tre ensuite
affects aux utilisateurs ou aux groupes dutilisateurs. Les SGBD modernes sont
capables de grer la fois des utilisateurs, des groupes et des rles qui sont donc les
sujets des mcanismes de contrle dautorisations.
Les autorisations considres sont en gnral positives : ce sont des accords de droits.
Cependant, la dfense amricaine a aussi introduit dans ses standards des possibilits
dautorisations ngatives, qui sont des interdictions daccs. Cela pose des problmes
de conflits, les interdictions dominant en gnral les autorisations. Dans la suite, nous
ne considrons que les autorisations positives.
Lattribution dune autorisation peut dpendre :
du sujet, par exemple de ses privilges daccs ou du terminal quil utilise,
de lobjet, par exemple de son nom, son tat actuel, son contenu ou sa valeur,
de lopration effectue, par exemple lecture ou mise jour,
dautres facteurs, par exemple de lheure du jour ou de la date.
Il existe plusieurs manires de mmoriser les autorisations. Une premire est lutilisa-
tion de matrices dautorisations. Une matrice dautorisations est une matrice dont
les lignes correspondent aux sujets et les colonnes aux objets, dfinissant pour chaque
couple sujet-objet les oprations autorises.
Considrons par exemple deux relations dcrivant les objets NOM et RESULTAT
dtudiants et des sujets tudiants, secrtaires et professeurs. Les oprations que peu-
vent accomplir les sujets sur les objets nom et rsultat sont lecture et criture. Les
autorisations peuvent tre codes par deux bits, droit dcriture puis droit de lecture.
La figure XVI.48 reprsente la matrice correspondant cet exemple, 0 signifiant
accs interdit et 1 accs autoris.
NOM RSULTAT
TUDIANT 01 01
SECRTAIRE 11 01
PROFESSEUR 11 11
Dans les SGBD, les dfinitions des sujets, objets et autorisations sont mmorises
dans la mta-base ou catalogue du systme. En pratique, la matrice dautorisation peut
tre stocke :
par ligne chaque sujet est alors associe la liste des objets auxquels il peut acc-
der ainsi que les droits daccs quil possde ;
648 BASES DE DONNES : OBJET ET RELATIONNEL
par colonne chaque objet associe la liste des sujets pouvant y accder avec les
droits daccs associs ;
par lment chaque couple sujet-objet sont associs les droits daccs du sujet
sur lobjet.
Cest cette dernire technique qui est retenue dans les SGBD relationnels. Les autori-
sations sont mmorises dans une table DROITS(<Sujet>, <Objet>, <Droit>,
<Donneur>), le donneur permettant de retrouver la provenance des droits.
Lattribution de droits aux sujets sur les objets est un autre problme important. Plus
prcisment, il est ncessaire de dfinir qui attribue les droits. Deux approches sont
possibles. Soit, comme dans SQL2, le crateur dun objet (une relation ou une vue par
exemple) devient son propritaire et reoit tous les droits. Afin de passer et retirer les
droits quil possde, il doit alors disposer de commandes du type [Griffiths76] :
GRANT < types oprations > ON < objet >
TO < sujet >
[WITH GRANT OPTION]
avec :
<type opration> ::= ALL PRIVILEGES | <action>+
<action> ::= SELECT | INSERT
| UPDATE [(<nom de colonne>+)]
| REFERENCE [(<nom de colonne>+)]
<sujet> ::= PUBLIC | <identifiant dautorisation>
REVOKE < types oprations > FROM < objet > TO < sujet >.
Soulignons que PUBLIC dsigne lensemble des utilisateurs, alors quun identifiant
dautorisation peut dsigner un utilisateur, un groupe ou un rle. Loption WITH
GRANT OPTION permet de passer aussi le droit de donner le droit.
Soit un groupe de sujets particuliers (les administrateurs des bases de donnes) poss-
dent tous les droits et les allouent aux autres par des primitives du mme type. La pre-
mire approche est dcentralise alors que la seconde est centralise. Des approches
intermdiaires sont possibles si lon distingue plusieurs groupes de sujets avec des
droits a priori [Chamberlin78].
NOM RSULTAT
TUDIANT 11 01
SECRTAIRE 11 00
PROFESSEUR 11 11
Linconvnient de la solution niveau dautorisation est que lon perd la notion dop-
ration. Cependant, cette solution est simple implanter et de plus elle permet de com-
biner les niveaux. En effet, si un sujet de niveau S1 accde travers une procdure ou
un quipement de niveau S2, on associera au sujet le niveau S = min (S1, S2). Par
exemple, sil existe un terminal en libre accs de niveau 1 et un terminal situ dans un
bureau priv de niveau 3, un enseignant ne conservera ses privilges que sil travaille
partir du terminal situ dans le bureau. De plus, la mthode peut tre tendue, avec
des classes de niveaux partiellement ordonnes, vers un modle plus complet de
contrle de flots dinformations. Elle peut aussi tre combine avec la mthode MAC.
parallles les plus puissantes. Le mcanisme est donc sr, mais le problme est la ges-
tion des cls qui doivent tre changes. Lapplication dun tel algorithme aux bases
de donnes ncessite son implmentation dans le SGBD et au niveau de lutilisateur.
Il faut en effet pouvoir dcrypter au niveau du SGBD pour effectuer les recherches.
Rechercher sur des donnes cryptes est trs difficile puisque les chanes de donnes
codes dpassent en gnral un attribut. Le SGBD devra donc garder un catalogue des
cls de cryptage/dcryptage. Les utilisateurs doivent pouvoir accder au catalogue
pour retrouver leur cl secrte. Celui-ci devient un point faible du systme.
Les algorithmes cls publiques et prives proposent deux cls diffrentes, inverses
lune de lautre. Lune permet de coder, lautre de dcoder. Les cls doivent tre plus
longues quavec les algorithmes cls secrtes, car elles sont plus facilement cassables,
cest--dire qu partir dune cl publique de 40 bits, on peut dduire la cl prive en
lessayant sur un message comprhensible en quelques heures de calcul dune machine
puissante. Il faut donc des cls de 512 bits et plus pour obtenir une scurit totale, ce qui
peut poser des problmes de lgislation. Avec de telles cls, le SGBD peut garder ses cls
prives et publier ses cls publiques. Lutilisateur code les donnes avec une cl publique
et les insre dans la base. Le SGBD dcode avec la cl prive correspondante. Les rsul-
tats peuvent tre envoys cods avec une cl publique de lutilisateur qui dcode alors
avec sa cl prive. Ce schma est trs sr si les cls sont assez longues. Il est illustr
figure XVI.50. Les algorithmes asymtriques tels que Diffie-Hellmann et RSA permet-
tent ainsi des solutions trs sres, o SGBD et utilisateurs gardent leurs cls prives.
Codage
Donnes
cl publique de S
cryptes
Dcodage
cl prive de S
Recherche
Dcodage Codage
cl prive de U cl publique de U
Utilisateur SGBD
13. BIBLIOGRAPHIE
[Baer81] Baer J.-L., Gardarin G., Girault C., Roucairol G., The Two-Step
Commitment Protocol : Modeling, Specification and Proof Methodology ,
5th Intl. Conf. on Software Engineering, IEE Ed., San Diego, 1981.
Cet article modlise le protocole de validation en deux tapes par des rseaux
de Petri. Il prouve partiellement la correction du protocole, cest--dire que
tous les sites prennent la mme dcision pour une transaction.
[Barghouti91] Barghouti N. S., Kaiser G. E., Concurrency Control in Advance
Database Applications ACM Computing Survey, vol. 23, n 3, p. 270-317,
Sept. 1991
Cet article fait le point sur les techniques de contrle de concurrence avances.
Il rappelle les techniques traditionnelles vues ci-dessus et rsume le ver-
rouillage altruiste, la validation par clichs, les transactions multi-niveaux, le
verrouillage smantique, les sagas, etc.
[Bancilhon85] Bancilhon F., Korth H., Won Kim, A Model of CAD Transactions ,
11th Int. Conf. on Very Large data Bases, Stockholm, Sude, Aot 1985.
Cet article propose un modle de transactions longues pour les bases de don-
nes en CAO. Il fut lun des prcurseurs des modles de transactions imbriqus
dvelopps par la suite.
[Beeri88] Beeri C., Scheck H-J., Weikum G., Multi-Level Transaction Management,
Theoretical Art or Practical Need ? , Proc. Intl. Conf. on Extending Database
Technology (EDBT), p. 134-155, Venise, Mars 1988.
Cet article introduit la srialisabilit niveaux multiples prsente ci-dessus.
[Bernstein80] Bernstein P.A., Goodman N., Timestamp-based Algorithm for
Concurrency Control in Distributed Database Systems , 5th Intl. Conf. On Very
Large data Bases, Montreal, Oct. 1980.
Cet article introduit diffrents algorithmes destampillage de transactions dans
le contexte de systmes rpartis.
[Bernstein87] Bernstein P.A., Hadzilacos V., Goodman N., Concurrency Control and
Recovery in Database Systems, Addison-Weley, 1987.
Cet excellent livre de 370 pages fait le tour des problmes de gestion de tran-
sactions dans les SGBD centraliss et rpartis. Il prsente notamment la tho-
rie de base, le verrouillage, la certification, le multi-version, les protocoles de
validation deux et trois phases, la gestion de donnes rpliques.
[Bernstein90] Bernstein P.A., Hsu M., Mann B., Implementing Recoverable
Requests Using Queues , ACM SIGMOD Int. Conf., ACM Ed., SIGMOD
Record V. 19, n 2, June 1990.
Gestion de transactions 653
Cet article propose un protocole rsistant aux pannes pour grer les flots de
requtes de transactions entre clients et serveurs. Il discute une implmentation
en utilisant des files dattente persistantes rcuprables aprs panne.
[Besancenot97] Besancenot J., Cart M., Ferri J., Guerraoui R., Pucheral Ph.,
Traverson B., Les Systmes Transactionnels : Concepts, Normes et Produits,
Ed. Herms, Paris, 1997.
Ce remarquable livre sur les systmes transactionnels couvre tous les aspects
du sujet : concepts de base, algorithmes de reprise, transactions rparties,
duplication, modles de transactions tendus, normes et standards, transac-
tions dans les SGBD relationnels et objet.
[Bjork72] Bjork L.A., Davies C.T., The Semantics of the Preservation and Recovery
of Integrity in a Data System , Technical Report TR-02.540, IBM, Dec. 1972.
Un des tout premiers articles introduisant un concept proche de celui de tran-
saction.
[Cart90] Cart M., Ferri J., Integrating Concurrency Control into an Object-
Oriented Database System , Proc. Intl. Conf. on Extending Database
Technology, EDBT, LCNS n 416, p. 367-377, Venise, Mars 1990.
Cet article prsente lintgration dalgorithmes de contrle de concurrence
avec prise en compte de la commutativit des oprations dans un SGBD objet.
[Chamberlin75] Chamberlin D.D., Gray J.N., Traiger I.L., Views, Authorizations
and Locking in a Relational Data Base System , Proc. of ACM National
Computer Conf., p. 425-430, 1975
Cet article discute de lutilisation des vues comme mcanisme dautorisation et
de verrouillage par prdicat dans un SGBD.
[Chamberlin78] Chamberlin D.D., Gray J.N., Griffiths P.P., Mresse M., Traiger I.L.,
Wade B.W., Data Base System Authorization , in Foundations of Secure
Computation [Demillo78], p. 39-56.
Cet article discute des mcanismes dautorisation dans un SGBD relationnel.
[Chrysanthis90] Chrystandis P.K., Ramamritham K., ACTA : A Framework for
Specifying and reasoning about Transaction Structure and Behavior , ACM
SIGMOD Intl. Conf. on Management of Data, SIGMOD Record vol. 19, n 2,
p. 194-203, Atlantic City, NJ, Juin 1990.
Cet article prsente ACTA, un formalisme permettant de spcifier structure et
comportement des transactions, en exprimant notamment la smantique des
interactions.
[Dayal91] Dayal U., Hsu M., Ladin R., A Transactional Model for Long-Running
Activities , Proc. of the 17th Intl. Conf. on Very Large Data Bases, Morgan
Kaufmann Ed., p. 113-122, Bacelonne, Sept. 1991.
654 BASES DE DONNES : OBJET ET RELATIONNEL
Cet article introduit les transactions imbriques, inventes par Moss dans son
PhD. Les transactions imbriques, au dpart fermes, ont t ouvertes (non-
atomicit globale) et son implmentes dans des systmes de plus en plus nom-
breux.
[Moss85] Moss J.E.B., Nested Transactions : An Approach to Reliable Distributed
Computing, The MIT Press, Cambridge, Mass., 1985.
Ce livre, version amliore du PhD de Moss, introduit et tudie en dtail la
thorie et la pratique des transactions imbriques.
[Murphy68] Murphy J.E., Ressource Allocation with Interlock Detection in a Multi-
Task system , Proc of AFIPS-FJCC Conf., vol. 33, n 2, p. 1169-1176, 1968.
Cet article introduisit les graphes dattente et lun des premiers algorithmes de
dtection de deadlock.
[zsu91] zsu M.T., Valduriez P., Principles of Distributed Database Systems,
Prentice Hall, Englewood Cliffs, New Jersey, 562 p., 1991.
Cet ouvrage est le livre de rfrence en anglais sur les bases de donnes rpar-
ties. Il couvre en particulier les aspects architecture, conception, contrle
smantique, optimisation de requtes, gestion de transactions, fiabilit et
concurrence, bases de donnes fdres. Chaque aspect est trait de manire
trs complte. Les algorithmes sont esquisss et une formalisation minimale est
souvent introduite.
[Ozsu94] Ozsu T., Transaction Models and Transaction Management in Object-
Oriented Database Management Systems , in Advances in Object-Oriented
Database Systems, p. 147-184, A. Dogac et. Al. Ed., NATO ASI Series,
Springer Verlag, Computer and System Sciences, 1994.
Ce remarquable article est un autre tutorial sur la gestion de transactions. Il
couvre particulirement bien les modles de transactions tendus et linfluence
de la commutativit des oprations.
[Pu88] Pu C., Kaiser G.E., Hutchinson N., Split-Transactions for Open-Ended
Activities 14th Intl. Conf. on Very Large data Bases, p. 26-37, Morgan
Kaufman Ed., Los Angels, 1998.
Cet article prsente le modle dynamique split et join voqu ci-dessus pour les
transactions imbriques.
[Rabitti91] Rabitti F., Bertino E., Kim W., Woelk D., A Model of Authorization for
Next Generation Database Systems , ACM Trans. On Database Systems,
vol. 16, n 1, p. 88-131, Mars 1991.
Cet article dveloppe un modle formel de scurit de type DAC pour un SGBD
objet. Il sappuie sur lexprience conduite avec le SGBD ORION.
658 BASES DE DONNES : OBJET ET RELATIONNEL
CONCEPTION
DES BASES DE DONNES
1. INTRODUCTION
Une des tches essentielles des dveloppeurs de bases de donnes est la conception du
schma des bases. Lobjectif est de structurer le domaine dapplication de sorte le
reprsenter sous forme de types et de tables. La reprsentation doit tre juste pour vi-
ter les erreurs smantiques, notamment dans les rponses aux requtes. Elle doit aussi
tre complte pour permettre le dveloppement des programmes dapplication souhai-
ts. Elle doit enfin tre volutive afin de supporter la prise en compte rapide de nou-
velles demandes.
Le concepteur, ou plutt ladministrateur de base, effectue galement le choix du place-
ment des tables sur disques et le choix des index, choix essentiels pour les performances.
En exagrant un peu, on peut dire quil ny a pas de mauvais SGBD, mais de mauvais
concepteurs responsables des erreurs smantiques ou des mauvaises performances. Les
choix de structures physiques sont dpendants des programmes qui manipulent la base,
particulirement des types et frquences des requtes dinterrogation et de mise jour.
Traditionnellement, la dmarche de conception seffectue par abstractions succes-
sives, en descendant depuis les problmes de lutilisateur vers le SGBD. Nous propo-
sons de distinguer cinq tapes :
662 BASES DE DONNES : OBJET ET RELATIONNEL
1. Perception du monde rel et capture des besoins. Cette tape consiste tudier
les problmes des utilisateurs et comprendre leurs besoins. Elle comporte des
entretiens, des analyses des flux dinformation et des processus mtier. Des
dmarches de type BPR (Business Process Reengineering) [Hammer93] de recon-
ception des processus mtiers existants en les dirigeant vers le client peuvent tre
un support pour cette tape. La gnration de modles de problmes est aussi une
technique courante ce niveau [DeAntonellis83]. Comme il est difficile de com-
prendre le problme dans son ensemble, les concepteurs ralisent des tudes de cas
partiels. Le rsultat se compose donc dun ensemble de vues ou schmas externes
quil faut intgrer dans ltape suivante. Ces vues sont exprimes dans un modle
de type entit-association ou objet, selon la mthode choisie.
2. laboration du schma conceptuel. Cette tape est base sur lintgration des
schmas externes obtenus ltape prcdente. Chaque composant est un schma
entit-association ou objet. Il rsulte dun modle de problme reprsentant une
partie de lapplication. La difficult est dintgrer toutes les parties dans un schma
conceptuel global complet, non redondant et cohrent. Des allers et retours avec
ltape prcdente sont souvent ncessaires.
3. Conception du schma logique. Cette tape ralise la transformation du schma
conceptuel en structures de donnes supportes par le systme choisi. Avec un
SGBD relationnel, il sagit de passer des tables. Avec un SGBD objet-relationnel,
il est possible de gnrer des types et des tables, les types tant rutilisables. Avec
un SGBD objet, il sagit de gnrer des classes et des associations. Cette tape peut
tre compltement automatise, comme nous le verrons.
4. Affinement du schma logique. Une question qui se pose est de savoir si le
schma logique obtenu est un bon schma. titre de premire approximation,
un bon schma est un schma sans oublis ni redondances dinformations. Pour
caractriser plus prcisment les bons schmas, le modle relationnel sappuie
sur la thorie de la normalisation, qui peut tre avantageusement applique ce
niveau. En relationnel, lobjectif est de grouper ou dcomposer les tables de
manire reprsenter fidlement le monde rel modlis.
5. laboration du schma physique. Cette tape est ncessaire pour obtenir de
bonnes performances. Elle ncessite la prise en compte des transactions afin de
dterminer les patterns daccs frquents. partir de l, il faut choisir les bonnes
structures physiques : groupage ou partitionnement de tables, index, etc. Cest l
que se jouent pour une bonne part les performances des applications.
Dans ce chapitre, nous tudions essentiellement les tapes 2, 3 et 4 qui font largement
partie du domaine des bases de donnes. La partie 1 appartient plutt au gnie logi-
ciel, voire lconomie ou la psychologie. Nous ne laborderons gure. Nous
dtaillons surtout la partie 3 o toute une thorie sest dveloppe la fin des
annes 70 et au dbut des annes 80 pour les bases relationnelles.
Dans la section qui suit, nous abordons le problme de la conception du schma
conceptuel. Cest loccasion de prsenter le langage de modlisation UML, plus prci-
Conception des bases de donnes 663
2. LABORATION DU SCHMA
CONCEPTUEL
Dans cette section, nous traitons des techniques permettant de dfinir un schma
conceptuel. Nous procdons par modlisation entit-association ou objet en construi-
sant des diagrammes bass sur UML, le langage de modlisation unifi standardis
par lOMG.
doute rsistant lusure du temps, comme tous les standards. La construction de base
drive du langage UML pour reprsenter des entits est symbolise figure XVII.1.
titre dexemple, nous avons reprsent des voitures avec les attributs numro de
vhicule (NV), marque, type, puissance et couleur.
Nom Voitures
Entit1 Entit2
Association
Rle1 Rle2
Donnes
Dans une association, chaque entit participante joue un rle. Celui-ci peut tre expli-
citement nomm, comme indiqu figure XVII.2. Mais ceci nest pas obligatoire. Les
associations sont caractrises par des cardinalits : la cardinalit [m,n] attache
une entit indique les nombres minimal et maximal dinstance dassociations pour une
instance de cette entit.
Une cardinalit se lit donc dans le sens entit vers association. Il faut se demander
pour une instance dentit (ou de classe) combien dinstances dassociation lui sont
attaches ? Avec des associations binaires, cela revient indiquer le nombre dins-
tances de lautre entit pour une instance de celle laquelle est attache la cardinalit.
UML propose les notations indiques figure XVII.3 pour les cardinalits. Notez que 1
signifie la fois un minimum de 1 et un maximum de 1. La notation {ord} signifie
que lordre dapparition des entits dans lassociation est important.
1
1
* plusieurs (0 N)
0..1
optionnel (0 ou 1)
0..*
ordonn (0 N)
{ord}
3..5
limit (de 3 5)
titre dexemple, soient une base modlisant des entits personne et voiture ,
et le type dassociation possde qui traduit le fait quune personne est propritaire
dune ou plusieurs voitures. Une personne est caractrise par un numro de Scurit
Sociale (NSS), un nom, un prnom et une date de naissance alors quune voiture est
caractrise par les attributs dj vus NV, MARQUE, TYPE, PUISSANCE et COU-
LEUR. Chaque personne est identifie par une occurrence du numro de Scurit
Sociale (NSS), alors que chaque voiture est identifie par un numro de vhicule
666 BASES DE DONNES : OBJET ET RELATIONNEL
(NV). chaque occurrence dassociation correspond par exemple une date dachat
(DATE) et un prix dachat (PRIX). La figure XVII.4 reprsente le schma externe
correspondant dcrit avec les notations UML rduites aux entits, associations et attri-
buts. Les cardinalits indiquent quune personne peut possder de O N voitures alors
quune voiture est possde par une et une seule personne.
Voiture Personne
Possde
nv nss
marque * 1 nom
type prenom
puissance datenais
couleur
date
prix
Nous prsentons figure XVII.5 lexemple classique des buveurs, des vins et de lasso-
ciation boire caractrise par une date et une quantit. Les cardinalits sont donc por-
tes par les rles : le rle Estbu porte la cardinalit 1..*, ce qui signifie qu un buveur
est associ entre 1 et N abus ou vins si lon prfre. * est une notation raccourcie pour
0..*. Le rle Estbu porte cette cardinalit, ce qui signifie quun vin est bu par 0 N
buveurs. Tout cela, aux notations prs, est bien connu mais souvent confus, les cardi-
nalits tant interprtes de diffrentes manires selon les auteurs. Nous avons choisi
ces notations pour assurer la compatibilit avec lapproche objet et UML que nous
allons maintenant dvelopper un peu plus.
Buveurs Vins
* Boire 1..*
Abus Estbu
Abus
Date
Quantit
Nom Voiture
Dmarrer()
Acclrer()
Rouler(km:Int)
Freiner()
La dcouverte des classes, comme celle des entits, ncessite disoler les types
dobjets du monde rel qui ont un cycle de vie propre. Dans une description en lan-
gage naturel, les classes comme les entits correspondent souvent des noms. partir
des objets, il faut abstraire pour dcouvrir les proprits, attributs et mthodes. Une
rflexion sur le cycle de vie de lobjet et sur ses collaborations avec les autres objets
permet de prciser les mthodes, et par l les attributs manipuls par ces mthodes.
UML fournit des outils pour reprsenter cycle de vie et collaboration : ce sont les dia-
grammes dtat et de collaboration, dont ltude dpasse le cadre de cet ouvrage.
La dcouverte des classes conduit dcouvrir les liens de gnralisation et de sp-
cialisation entre classes. Dans une description en langage naturel, les objets sont alors
668 BASES DE DONNES : OBJET ET RELATIONNEL
relis par le verbe tre (relation is a). UML permet la reprsentation de lhritage
comme indiqu figure XVII.7. Sil est possible de grouper les deux flches en une
seule, cela na pas de signification particulire. Si les deux sous-classes sont dis-
jointes, une contrainte {Exclusive} peut tre explicitement note. De mme, il est pos-
sible de prciser {Inclusive} si tout objet se retrouve dans toutes les sous-classes. Un
nom discriminant peut tre ajout sur larc de spcialisation, pour distinguer diff-
rentes spcialisations dune classe.
Classe
de base
Sous-classe Sous-classe
Personnes C1 C2 Personnes
{exclusif}
Employs Etudiants Hommes Femmes
Lagrgation est utilise pour reprsenter les situations o une classe est compose
dun ou plusieurs composants. UML permet de distinguer lagrgation indpendante
de lagrgation composite. La premire est une association particulire qui relie un
objet un ou plusieurs objets composants ; les deux classes sont deux classes auto-
nomes. La seconde permet de reprsenter des objets composites rsultant de lagrga-
tion de valeurs. Elle se distingue de la premire par un losange plein. Les diagrammes
reprsentant ces deux types dassociations sont symboliss figure XVII.8.
Classe
attributs
oprations
Composant Attribut
attribut nom
opration opration
Les figures XVII.9 et XVII.10 illustrent les constructions introduites par deux tudes de
cas conduisant llaboration de schmas externes ou vues, ou encore paquetages (un
paquetage UML est un ensemble de composants objets qui peut comporter beaucoup
dautres lments). Chaque paquetage est reprsent par un rectangle tiquet contenant
ses composants. UML permet dajouter des notes tous les niveaux. Pour les paque-
tages, nous dfinissons dans la note associe la situation correspondante en franais.
La vie
La voiture
Classe Classe
Noms diffrents pour des classes quivalentes
Noms identiques pour des classes diffrentes
Inclusion de lune dans lautre
Intersection non vide
Contraintes entre instances
Attribut Attribut
Noms diffrents pour des attributs quivalents
Noms identiques pour des attributs diffrents
Types diffrents
Compositions diffrentes
Classe Attribut
Significations identiques
Compositions similaires
Association Association
Noms diffrents pour des associations quivalentes
Noms identiques pour des associations diffrentes
Cardinalits diffrentes
Donnes diffrentes
Compositions de plusieurs autres
Agrgation Agrgation
Agrgation composite versus non composite
Cardinalits diffrentes
Association Attribut
Association versus rfrence
Cardinalits incompatibles
Le premier problme est disoler les conflits. Cela ncessite le passage par un diction-
naire unique des noms, voire par une ontologie. Une ontologie est une dfinition com-
plte des concepts, avec leurs relations smantiques. Lutilisation dune ontologie sp-
cifique au domaine permet de ramener les concepts un rfrentiel unique et de
mesurer la distance et le recouvrement entre eux [Mtais97]. On peut ainsi isoler les
conflits potentiels.
Pour chaque cas, des solutions doivent tre envisages, telles que :
Changement de dnomination de classes, dassociations ou dattributs
Ajout dattributs ou remplacement par des oprations
Dfinition de classes plus gnrales ou plus spcifiques
Transformation dagrgation en objets composites et vice versa
Redfinition de types plus gnraux
Transformation de reprsentation
Conversion et changement dunits.
Certains conflits ne sont solubles que manuellement. Un outil graphique daide
lintgration peut tre avantageusement utilis.
Possde Habite
Voiture Personne Habitation
* 1 * 1
nveh nss tage
couleur nom no
km prenoms rue
Date datenais dmnager() code
rouler() Prix ville
1 1 vieillir()
Vendre() dormir()
1 1
Moteur Type
type marque
puissance code
Boire
dmarrer() Employ Buveur Vin
Infrieur * 1..*
stopper() Dpend fonction type nv
salaire tat cru
Suprieur primes millsime
boire() date degr
travailler() quantit qualit
EmployBuveur
1 Ass *
Ent1 Ent2
K1 K2
A1 B1
Abus
An D1 Bm
Dp
sibles, consistant toutes aplatir les hirarchies de spcialisation. Pour les mthodes,
le polymorphisme doit tre ralis dans le corps de la mthode par des tests (CASE).
Nous examinons ici la transformation des donnes, comme il se doit pour une base de
donnes.
La solution la plus naturelle pour traduire une hirarchie de gnralisations de classes
C1, C2Cn vers une classe C est dappliquer la rgle suivante, en plus de la rgle R1
qui conduit traduire chaque classe (ou entit) comme une table avec une cl pri-
maire, la rgle suivante :
R4.a Une spcialisation dune classe C en plusieurs classes C1, C2Cn est traduite
par rptition de la cl de la table reprsentant C au niveau de chacune des
tables reprsentant C1, C2Cn.
Cette solution conduit une table par classe (voir figure XVII.14(a)). Lorsquon sou-
haite retrouver un attribut hrit dans une classe drive, il faut effectuer une jointure
avec la table reprsentant la classe de base. Lhritage doit donc tre accompli par les
programmes dapplication. La dfinition dune vue jointure des tables drives et de
la table de base (par exemple C|X|C1) permet dautomatiser lhritage.
Dautres solutions sont possibles pour traduire des spcialisations, comme le montre
la figure XVII.14(b) et (c). La solution (b) consiste faire une table par classe feuille
de la hirarchie en appliquant la rgle suivante :
R4.b Une spcialisation dune classe C en plusieurs classes C1, C2Cn est traduite
par rptition des attributs reprsentant C au niveau de chacune des tables
reprsentant C1, C2Cn et par transformation de C en une vue drive de C1,
C2Cn par union des projections sur les attributs de C.
Le problme avec cette solution survient lorsque les classes C1, C2, Cn ne sont pas
exclusives et contiennent des objets communs. Les attributs de C sont alors rpts
dans chacune des tables C1, C2Cn, ce qui pose des problmes de cohrence. Cette
rgle sera donc seulement applique dans le cas dhritage exclusif. Par exemple, il
est intressant de reprsenter la hirarchie dhritage FEMMES, HOMMES PER-
SONNES de la figure XVII.7 par les tables FEMMES et HOMMES, la table PER-
SONNES pouvant tre drive par une vue. Au contraire, la mme technique utilise
pour la hirarchie dhritage EMPLOYES, ETUDIANTS PERSONNES condui-
rait dupliquer les employs tudiants. On prfrera alors appliquer la rgle R4.a
conduisant trois tables EMPLOYES, ETUDIANTS et PERSONNES, chacune ayant
pour cl le numro de scurit sociale de la personne.
Une autre solution encore possible consiste implmenter une seule table comme
illustr figure XVII.14(c) :
R4.c Une spcialisation dune classe C en plusieurs classes C1, C2Cn est traduite
par une table unique comportant la traduction de la classe C complte avec les
attributs de C1, C2Cn, les tables correspondant C1, C2Cn tant des vues
drives de C par projection sur les attributs pertinents.
Conception des bases de donnes 675
Classe
C
Sous-classe Sous-classe
C1 C2
C K
C1 K C1 C C C1 C2
C2 K C2 C
Le problme avec cette solution survient lorsquun objet de la classe C na pas de sp-
cialisation dans une sous classe Ci : dans ce cas, tous les attributs de la classe Ci appa-
raissent comme des valeurs nulles ! Par exemple, pour la hirarchie FEMMES,
HOMMES PERSONNES, les attributs spcifiques aux femmes seront nuls pour
chaque homme dans la table PERSONNES gnrale (par exemple, le nom de jeune
fille). Pour la hirarchie EMPLOYES, ETUDIANTS PERSONNES, tout employ
non tudiant aura les attributs dtudiants nuls et tout tudiant non employ aura les
attributs spcifiques aux tudiants nuls. Cette solution nest donc bonne que dans le
cas dhritage complet, o chaque objet de la classe de base est membre de la sous-
classe.
En rsum, les diffrents cas sont illustrs figure XVII.14. Bien sr, ils peuvent tre
mixs et il faut rflchir pour chaque sous-classe. Certaines peuvent par exemple tre
regroupes avec la classe de base, dautres implmentes de manire autonome.
par concatnation des noms des entits participantes. On ajoutera un nom de rle si
plusieurs agrgations indpendantes relient deux classes.
Lagrgation composite correspond un groupe dattributs (et mthodes) imbriqus
dans lobjet composite. Dans le cas de bijection (cardinalit 1..1), tous les attributs de la
classe cible (le composant) sont simplement ajouts la table reprsentant la classe
source (le compos). La classe cible est reprsente par une vue. La rgle est la suivante :
R5. Une classe dpendant dune autre par une agrgation composite monovalue
est reprsente par des attributs ajouts la table reprsentant lobjet composite
et si ncessaire transforme en une vue, sinon omise.
Cette rgle est applique figure XVII.15. Au-del, le relationnel pur ne permet pas de
traduire les agrgations composites multivalues par une seule table. On procde alors
comme avec une agrgation indpendante et plus gnralement une association. Des
contraintes dintgrit additionnelles peuvent tre ajoutes, comme nous le verrons ci-
dessous.
Les attributs multivalus peuvent tre intgrs directement dans une classe par le
biais de collections SET<X>, LIST<X>, BAG<X>, etc. Une bonne modlisation
UML traduit de tels attributs en agrgations composites. Cependant, il est permis
dutiliser des templates ; alors le problme de la traduction en relationnel se pose.
Deux cas sont considrer pour traduire en relationnel. Si le nombre maximal N de
valeurs est connu et faible (< 5 par exemple), il est possible de dclarer N colonnes, de
nom A1, A2,, etc., o A est le nom de lattribut. Cette solution manque cependant de
flexibilit et conduit des valeurs nulles ds quil y a moins de N valeurs. Une solution
plus gnrale consiste isoler la cl K de la table rsultant de la classe ayant un attribut
collection, et crer une table rpertoriant les valeurs de la collection associe la cl.
La table a donc pour schma AS (K, A) et donne les valeurs de A pour chaque valeur
de K. Par exemple, si une collection a trois valeurs v1, v2, v3 pour la cl 100, (100-v1),
Conception des bases de donnes 677
(100-v2) et (100-v3) seront trois tuples de la table AS. Les collections seront reconsti-
tues par des jointures lors des interrogations. Cette solution est connue sous le nom
de passage en premire forme normale et nous y reviendrons ci-dessous.
* Boire 1..*
Buveurs Vins
Abus Estbu
nb nv
nom cru
type Abus millsime
Date degr
Quantit
sens permet les parcours de chemins dans les deux sens. Cest utile si les requtes le
ncessitent.
En fait, aujourdhui bien peu de SGBD objet-relationnel supporteront une telle
dmarche pour une grosse base (quelques centaines de classes). Elle conduit en effet
grer beaucoup de types et beaucoup de rfrences. De plus, le schma rsultat ne
peut tre normalis simplement et peut prsenter des difficults dvolutions, les types
tant souvent lis par hritage ou par agrgation. Nous conseillerons donc plutt
lapproche UML/RO plus compatible avec la thorie hrite du relationnel que nous
tudions ci-dessous.
Lentit VIN a t reprsente par deux tables VIN1 et VIN2. En interrogeant par des
jointures et projections, et plus gnralement en SQL, il est impossible de retrouver
prcisment le degr dun vin ou la qualit dun cru millsim. Il y a perte de sman-
tique car la jointure naturelle des deux tables VIN1 et VIN2 sur lattribut commun
CRU ne permet pas de retrouver les vins de dpart, avec un degr unique (par exemple
pour les Chablis).
Par suite, lors dune dcomposition, le schma de relation R (A1, A2 An) est remplac
par une collection de schmas dont lunion des attributs est (A1, A2 An). La jointure
naturelle R1 |X| R2 |X| Rn constitue donc une relation de mme schma que R, mais
dont les tuples ne sont pas forcment les mmes que ceux de R. titre dillustration, la
figure XVII.20 propose deux dcompositions possibles pour la relation VOITURE.
Dcomposition 1 Dcomposition 2
P206A 7 Bleue
P206A 7 Rouge
Si lon admet qu un type de vhicule sont associes une seule marque et une seule
puissance (ce qui est vrai pour les tuples figurant sur des cartes grises), la dcomposi-
Conception des bases de donnes 683
tion 1 est plus plaisante que lautre : elle permet de retrouver toutes les informations
par jointure, alors que la dcomposition 2 ne permet pas de retrouver la couleur dun
vhicule ; la jointure V1 V2 V3 est diffrente de la relation initiale VOI-
TURE. Do la notion de dcomposition sans perte (dinformation).
5. DPENDANCES FONCTIONNELLES
Dans cette section, nous tudions les liens smantiques entre attributs, particulire-
ment les liens fonctionnels.
Il est essentiel de bien remarquer quune dpendance fonctionnelle (en abrg, DF)
est une assertion sur toutes les valeurs possibles et non pas sur les valeurs actuelles :
elle caractrise une intention et non pas une extension dune relation. Autrement dit, il
est impossible de dduire les DF dune ralisation particulire dune relation. La seule
manire de dterminer une DF est de regarder soigneusement ce que signifient les
attributs car ce sont des assertions sur le monde rel qui lient les valeurs possibles des
attributs entre elles. Les DF devraient ainsi tre dclares par ladministrateur dentre-
prise au niveau du schma conceptuel et un bon SGBD devrait les faire respecter.
Dcomposition : X Y et Z Y X Z.
partir de ces rgles, il est possible dintroduire la notion de dpendance fonction-
nelle lmentaire [Zaniolo81].
NV COULEUR
TYPE MARQUE
PUISSANCE
Il nest pas toujours possible de reprsenter les DF dune relation par un graphe
simple : si une partie gauche dune DF comporte plus dun attribut, il faut introduire
des arcs reprsentant une association de plusieurs sommets vers un sommet. Nous
pouvons alors utiliser la notation des rseaux de Ptri pour reprsenter les dpen-
dances (voir figure XVII.23).
En effet, la relation :
REDUCTION (CRU, TYPE, CLIENT, REMISE)
Conception des bases de donnes 687
dans laquelle :
(a) un cru possde un type associ et un seul,
(b) les rductions sont effectues selon le type et le client,
comporte une dpendance partie gauche multiple :
TYPE, CLIENT REMISE.
CHENAS A C1 3%
MEDOC A C2 5%
JULIENAS B C1 4% TYPE
CLIENT
NV COULEUR
TYPE MARQUE
PUISSANCE
En clair, une cl est un ensemble minimal dattributs qui dtermine tous les autres. Un
ensemble dattributs qui inclut une cl est appel supercl. Par exemple, NV est une
cl de la relation VOITURE, alors que (NV, TYPE) nest pas une cl mais une super-
cl. Il peut y avoir plusieurs cls pour une mme relation : on en choisit en gnral
une comme cl primaire. On parle parfois de cl candidate pour dsigner une cl
quelconque.
Cette forme normale est justifie par la simplicit et lesthtique. Elle consiste simple-
ment viter les domaines composs de plusieurs valeurs. Plusieurs dcompositions
sont possibles, comme vu ci-dessus. Par exemple, la relation PERSONNE(NOM, PRE-
NOMS) pourra tre dcompose en PERSONNE1(NOM, PRENOM1) et
PERSONNE2(NOM, PRENOM2) si lon sait que les personnes nont pas plus de deux
prnoms. Plus gnralement, nous avons montr ci-dessus quune relation de cl K
avec un attribut multivalu A* pouvait tre dcompose en deux relations par limina-
690 BASES DE DONNES : OBJET ET RELATIONNEL
tion de lattribut multivalu et gnration dune table de schma (K, A) donnant les
valeurs lmentaires de A associes aux valeurs de la cl. La rgle de dcomposition
en premire forme normale nest rien dautre que lapplication systmatique de cette
transformation. Si la relation na pas dautre attribut que la cl et lattribut multivalu,
elle est simplement dsimbrique comme pour lexemple de la figure XVII.25.
MARTIN Gomtre
Une telle relation doit tre dcompose en rptant les noms pour chaque
profession (Opration UNNEST)
Soulignons que la premire forme normale est une question de dfinition de domaine :
chaque valeur dun domaine est en effet un atome du point de vue du modle relation-
nel. Par suite, rien nempche de considrer une date ou une figure gomtrique
comme atomique si les domaines de valeur sont les dates et les figures gomtriques.
Cest une question de point de vue et de niveau de dcomposition.
Le schma typique dune relation qui nest pas en 2e forme normale est reprsent
figure XVII.26. K1 et K2 dsignent deux parties de la cl K. Le problme est que K2
lui seul dtermine Y : K2 Y. Donc Y dpend dune partie de la cl. Comme nous
le verrons plus loin, une telle relation doit tre dcompose en R1(K1,K2,X) et
R2(K2,Y).
Par exemple, considrons la relation :
FOURNISSEUR (NOM, ADRESSE, ARTICLE, PRIX)
Conception des bases de donnes 691
Par suite, une partie de la cl (NOM) dtermine un attribut nappartenant pas la cl.
Cette relation nest donc pas en deuxime forme normale. Elle pourra tre dcompo-
se en deux relations :
FOURNISSEUR (NOM, ADRESSE)
PRODUIT (NOM, ARTICLE, PRIX)
R K1 K2 X Y
Soulignons quune partie de cl nest pas une cl. En consquence, une relation en 3e
forme est automatiquement en 2e : la condition 1 est automatiquement vrifie, mais
figure par souci de claret. Soulignons aussi que si la relation possde plusieurs cls
candidates, la dfinition doit tre vrifie pour chacune delles successivement.
Le schma typique dune relation qui nest pas en 3e forme normale est reprsent
figure XVII.27. K est la cl de R. Le problme est que X lui seul dtermine Z : X
Z. Donc Z dpend dun attribut non cl. Comme nous le verrons plus loin, une telle
relation doit tre dcompose en R1(K1,K2,X) et R2(K2,Y).
692 BASES DE DONNES : OBJET ET RELATIONNEL
R K X Y Z
nest pas en troisime forme normale. En effet, lattribut non cl TYPE dtermine
MARQUE et aussi PUISSANCE. Cette relation peut tre dcompose en deux rela-
tions :
VOITURE (NV, TYPE, COULEUR)
MODELE (TYPE, MARQUE, PUISSANCE).
Si la relation possde une seule cl primaire, il est possible de donner une dfinition
quivalente comme suit. Une relation R est en troisime forme normale si et seule-
ment si :
1)elle est en deuxime forme normale ;
2)tout attribut nappartenant pas la cl ne dpend pas transitivement de la cl.
Par exemple, dans la relation VOITURE, lattribut MARQUE dpend transitivement
de la cl ainsi que lattribut PUISSANCE :
NV TYPE PUISSANCE,
NV TYPE MARQUE.
NV COULEUR
TYPE MARQUE
PUISSANCE
R1 R2
K1 K2
X Y
R1
K R2
X
Y
dpendances entre les attributs non cls. Quid des dpendances de parties de cls entre
elles ou dattributs non cl vers une partie de cl ? Eh bien, la 3e FN est insuffisante.
Afin dliminer les redondances cres par des dpendances entre parties de cls et
celles dj limines par la 3e FN, Boyce et Codd ont introduit la forme normale qui
porte leur nom (en abrg BCNF) [Codd74].
Cette dfinition a le mrite dtre simple : pas de dpendance autre que KA, K tant
la cl et A un attribut non cl. Il a t montr que toute relation a une dcomposition
en BCNF qui est sans perte. Par contre, une dcomposition en BCNF ne prserve en
gnral pas les DF. La figure XVII.32 illustre le cas typique o un attribut non cl
dtermine une partie de cl, et indique le schma de dcomposition associ.
R K1 K2 X Y
Une telle relation doit tre dcompose en R1(K1, K2, X) et R2(Y, K1)
Cette relation nest pas en BCNF bien quen 3e forme puisque le cru ne dtermine pas
la rgion (il y a du Chablis en Bourgogne mais aussi en Californie ; notez que la qua-
lit dpend bien du pays !). Une instance, le rseau de DF et la dcomposition souhai-
table sont reprsents figure XVII.33. La DF CRU, PAYS REGION est perdue. La
dcomposition est cependant sans perte.
Conception des bases de donnes 697
PAYS
CRU
REGION
QUALITE
Dcomposition :
CRUS (CRU, PAYS, QUALITE)
REGIONS(REGION, PAYS)
NE est le numro dtudiant, COURS les cours suivis et SPORT les sports pratiqus.
Une extension de cette relation est reprsente figure XVII.34. NE, COURS et SPORT
constituent la cl compose. En effet, NE ne dtermine ni cours ni sport car il est
conseill de suivre plusieurs cours et de pratiquer plusieurs sports (cest le cas de
ltudiant 100 ci-dessous).
NE COURS SPORT
100 Bases de donnes Tennis
100 Bases de donnes Football
100 Rseaux Tennis
100 Rseaux Football
200 Rseaux Vlo
Comme avec les dpendances fonctionnelles, il est possible deffectuer des infrences
partir des dpendances multivalues. Les axiomes dinfrence des DM sont les sui-
vants, en considrant une relation compose dun ensemble dattributs R [Beeri79] :
1. Complmentation : (X Y) (X R X Y)
2. Augmentation : (X Y) et (V W) (XW YV)
3. Transitivit : (X Y) et (Y Z) (X Z Y)
Des rgles additionnelles sen dduisent, telles que celle dunion :
4. Union : (X Y) et (Y Z) (X YZ)
partir des axiomes prcdents, il est possible dintroduire la notion de dpendance
multivalue lmentaire, ceci afin dliminer les dpendances dduites trivialement
dun ensemble de dpendances de base [Zaniolo81].
Rappelons quune supercl est un ensemble dattributs contenant une cl. Donc, une
relation R nest pas en 4e FN si lon peut trouver une dpendance de la forme
X Y o X ninclut pas une cl de R. Comme une dpendance fonctionnelle est
un cas particulier de dpendance multivalue, il apparat quune relation en quatrime
forme normale est en forme normale de Boyce-Codd et donc en troisime forme nor-
male.
titre dexemple, la relation ETUDIANT (NE, COURS, SPORT) nest pas en qua-
trime forme normale : la cl est lensemble des attributs et il existe des DM lmen-
taires entre des attributs participants la cl :
NE COURS
NE SPORT.
Il a t montr que toute relation a une dcomposition (pas forcment unique) en qua-
trime forme normale qui est sans perte [Fagin77]. Par exemple, la relation ETU-
DIANT peut tre dcompose en deux relations (NE, COURS) et (NE, SPORT) qui
sont bien en quatrime forme normale.
Cette relation est bien en quatrime forme normale. En effet, il nexiste pas de dpen-
dance multivalue daprs lextension reprsente ci-dessus :
Conception des bases de donnes 701
BUVEUR CRU est faux car par exemple le tuple (Ronald Volnay Georges)
nexiste pas.
CRU PRODUCTEUR est faux car par exemple le tuple (Claude Chablis
Georges) nexiste pas.
PRODUCTEUR BUVEUR est faux car par exemple le tuple (Claude Volnay
Nicolas) nexiste pas.
Autrement dit, si lon considre les projections R1, R2, R3 de la relation BUVCRU
sur deux attributs (voir figure XVII.36), on constate que lon a :
BUVCRU R1 R2,
BUVCRU R1 R3,
BUVCRU R2 R3.
Cependant, la relation reprsente figure XVII.35 prsente bien des redondances : on
apprend deux fois que Ronald boit du Chablis et que Nicolas produit du Chablis. Elle
nest cependant pas dcomposable en deux relations.
R2 CRU PRODUCTEUR
Chablis Georges
Chablis Nicolas
Volnay Nicolas
Lide simple est que si la DJ est implique par les cls, la dcomposition nliminera
pas de redondance et est sans intrt. Si elle contient R, elle ne sert rien puisque R
demeure. Dans les autres cas, il est possible de dcomposer par projection selon les
schmas de la DJ ; lexpression de jointures drives de la JD permet de recomposer
la relation R. Par suite, la dcomposition dune relation non en 5e forme suit les DJ et
est sans perte. Par contre, elle ne prserve en gnral pas les DF, comme la BCNF.
Notons aussi que la 5e forme normale est une gnralisation directe de la BCNF et de
la 4e ; donc une relation en 5e forme est en 4e et bien sr en 3e.
Ainsi la relation BUVCRU nest pas en 5e forme normale puisque la seule cl candi-
date (BUVEUR, CRU, PRODUCTEUR) nimplique pas la DJ *{(BUVEUR CRU),
(CRU PRODUCTEUR), (BUVEUR PRODUCTEUR)}. Elle doit donc tre dcompose
en ces trois relations afin dviter les anomalies de mise jour.
[Fagin79] a dmontr le rsultat essentiel suivant. Toute relation en 5e forme normale
ne peut plus tre dcompose sans perte dinformations (except par les dcomposi-
tions bases sur les cls qui sont sans intrt) si lon ne considre que la dcomposi-
tion par projection et la recomposition par jointure. La 5e forme normale est donc un
point final la dcomposition par projection-jointure. Voil pourquoi Fagin a propos
dappeler cette forme forme normale de projection-jointure (JD/NF).
La 5e forme nest cependant pas la forme ultime de dcomposition si lon accepte
aussi des dcompositions horizontales, cest--dire en partitionnant la table en sous-
tables comportant chacune un ensemble de tuples avec tous les attributs. Il est pos-
sible dintroduire des dpendances algbriques du style R E(R) o E est une
expression de lalgbre relationnelle avec union, projection et jointure
[Yannakakis80]. Les dpendances dinclusion constituent une forme plus restreinte
de dpendances qui unifient les FD et les JD [Abiteboul95]. Mais tout cela nest pas
dune grande utilit pour concevoir une BD.
704 BASES DE DONNES : OBJET ET RELATIONNEL
ou en supprimant un index. Les modles base doutils gnraux bass sur les files
dattente sont aussi utilisables.
Au-del du modle qui est un problme en soi, nous examinons ci-dessous les para-
mtres sur lequel ladministrateur systme peut jouer. Ceux-ci sont souvent dpendant
du SGBD.
Cette technique est connue depuis longtemps sous le nom de placement proximit
dans le modle rseau. Elle permet par exemple de placer les lignes de commandes
dans la page de len-tte. Ainsi, la jointure ne ncessite quune entre-sortie par com-
mande. Il ny a cette fois pas de duplication et donc pas de problme introduit en mise
jour. Cest donc une excellente technique qui peut cependant pnaliser les slections
sur lune et lautre des tables.
706 BASES DE DONNES : OBJET ET RELATIONNEL
Tout tuple respectant les contraintes dintgrit doit appartenir lune des partitions.
Un exemple typique est la cration de partitions sur le mois pour la table des com-
mandes. Ainsi, douze partitions sont cres, une par mois. Cette technique est particu-
lirement intressante si les requtes indiquent souvent le mois de la commande, donc
en gnral un des i. Elle permet surtout de diviser les grosses tables notamment pour
le chargement et la sauvegarde. De nombreux SGBD limplmentent de manire invi-
sible au dveloppeur dapplication. Le partitionnement horizontal correspond de fait
une dcomposition par union.
recherche sur cl, etc. Les SGBD du march automatisent de plus en plus ce type
dindexation.
2. Un attribut sur lequel figure un prdicat conjonctif avec galit sera index :
par un arbre B si le nombre de valeurs possibles dpasse quelques centaines ;
par un index bitmap sinon.
Il ne faut cependant pas abuser de lindexation pour les tables frquemment mises
jour ou avec insertions nombreuses. Dans ce cas, un modle analytique ou une simu-
lation permettront dy voir plus clair. On pourra consulter [Cardenas75,
Schkolnick85] pour de tels modles.
9. CONCLUSION
En rsum, concevoir une base de donnes ncessite tout dabord dlaborer un
schma conceptuel. Le modle objet et le langage graphique de modlisation UML
nous semble un bon vhicule pour ce faire. partir de l, des rgles prcises permet-
tent dobtenir un schma logique relationnel. Faut-il ensuite normaliser les schmas
de tables ? Cela peut tre utile en cas de mauvaise isolation des entits. Cependant, la
normalisation est un processus long qui ncessite danalyser les dpendances quon
napplique finalement qu lexception. Trop systmatiquement applique, elle
conduit clater les tables en molcules de quelques attributs. Il apparat alors des
myriades de tables quil faut regrouper. Loptimisation est finalement beaucoup plus
importante pour les performances, mais trs difficile matriser. Cest un mtier de
spcialiste de systme.
La conception reste encore plus un art quune science, surtout avec le modle objet.
En effet, on est peu prs incapable de dire ce quest un bon schma objet. De plus, le
passage dun schma objet un schma logique objet-relationnel reste une tape
mal matrise. Les approches par un modle smantique de plus haut niveau sont trs
708 BASES DE DONNES : OBJET ET RELATIONNEL
10. BIBLIOGRAPHIE
[Abiteboul95] Abiteboul S., Hull R., Vianu V., Foundations of Databases, Addison-
Wesley, 1995.
Ce livre sur les fondements des bases de donnes couvre particulirement bien
la thorie des dpendances fonctionnelles, de jointure et dinclusion, et bien
dautres aspects.
[Aho79] Aho A.V., Beeri C., Ullman J-D., The Theory of Joins in Relational
Databases , ACM Transactions on Database Systems, Vol.4, n 3, p. 297-314,
Sept. 1979.
Cet article tudie la dcomposition dune relation par projection et donne des
algorithmes efficaces pour dterminer si la jointure de relations est sans perte
en prsence de dpendances fonctionnelles et multivalues.
[Armstrong74] Amstrong W.W., Dependency Structures of Database
Relationships , IFIP World Congress, North-Holland Ed., p. 580-583, 1974.
Cet article introduit les fameux axiomes de Armstrong.
[Batini86] Batini C., Lenzerini M., A Methodology for Data Schema Integration in
the Entity-Relationship Model , IEEE Transactions on Software Engineering,
vol. 10, n 6, p.650-664, Nov. 1984.
Les auteurs prsentent une mthodologie pour intgrer les schmas entit-asso-
ciation.
[Beeri79] Beeri C., Bernstein P.A., Computational Problems Related to the Design
of Norma Form Schemas , ACM Transactions on Database Systems, Vol.4,
n 1, Mars 1979.
Cet article dcrit un algorithme linaire pour tester si une dpendance fonc-
tionnelle est dans la fermeture dun ensemble de DF et une implmentation
optimise de lalgorithme de synthse de Bernstein.
[Benci76] Benci E., Concepts for the Design of a Conceptual Schema , IFIP
Conference on Modelling in Database Management Systems, North-Holland
Ed., p. 181-200, 1976.
Conception des bases de donnes 709
CONCLUSION ET PERSPECTIVES
1. INTRODUCTION
Trois gnrations de systmes de bases de donnes ont dj vu le jour. La premire
gnration des annes 70 correspondait aux modles hirarchique et rseau. Elle tait
reprsente par des produits tels TOTAL, IDS II, IMS et Socrate. La seconde gnra-
tion des annes 80 tait base sur le modle relationnel et fut conduite par les produits
Oracle, DB2, Ingres, Informix et Sybase. La 3e gnration des annes 90 a vu lint-
gration de lobjet aux systmes de 2e gnration. Bien que des systmes purs objets
tels O2 ou Object Store aient montr le chemin, lindustrie a procd par extension, si
bien que dun point de vue industriel Oracle, DB2, Informix et SQL Server restent les
produits phares maintenant de 3e gnration.
Les principes des systmes de bases de donnes sont souvent venus de la recherche au
cours de ces trente dernires annes. Lenjeu aujourdhui est le dveloppement de la
gnration de SGBD de lan 2000. Celle-ci devrait voir lintgration efficace du dci-
sionnel aux systmes transactionnels, le support transparent de lInternet et bien sr la
possibilit de recherche par le contenu des objets multimdias sur le Web vu comme
une grande base de donnes. Tous ces travaux sont dj bien engags dans les labora-
toires de recherche et chez les constructeurs de SGBD, notamment aux USA. Nous
rsumons ci-dessous quelques aspects des recherches en cours qui nous paraissent
essentiels pour le futur.
714 BASES DE DONNES : OBJET ET RELATIONNEL
2. LES BD ET LE DCISIONNEL
La dcennie 90 a vu le dveloppement des entrepts de donnes (Datawarehouse). Un
entrept de donnes est un ensemble de donnes historises variant dans le temps,
organis par sujets, agrg dans une base de donnes unique, gr dans un environne-
ment de stockage particulier, aidant la prise de dcision dans lentreprise. Trois
fonctions essentielles sont prises en compte par ces nouveaux systmes dcisionnels :
la collecte de donnes partir de bases existantes et le chargement de lentrept, la
gestion et lorganisation des donnes dans lentrept, lanalyse de donnes pour la
prise de dcision en interaction avec les analystes.
La figure XVIII.1 illustre les composants dun entrept de donnes. Le moniteur-
adapteur est charg de la prise en compte des mises jour des sources de donnes
locales, de la prparation de tables diffrentielles (les deltas) pour envois lentrept
et du transfert des deltas priodiquement vers le mdiateur. Ce dernier assure la fusion
des sources et la mise en forme des donnes pour la base de lentrept. Autour du
datawarehouse, les outils OLAP (On Line Analysis Processing) permettent lanalyse
des donnes historises. Les outils de data mining permettent lextraction de rgles et
de modles partir des donnes.
Prsentation
Composant Composant
dcisionnel Datawarehouse dcisionnel
Mining BD Analyse
Entrept
Transformation
Mdiateur
Moniteur/Adaptateur Moniteur/Adaptateur
Donnes Donnes
BD Source
externes oprationnelles
BD lgataires
3. BD ET WEB
Le Web sest dvelopp comme un hypertexte sur le rseau Internet, pour permettre
facilement laccs des fichiers chans. Rapidement, le besoin de couplage avec les
716 BASES DE DONNES : OBJET ET RELATIONNEL
bases de donnes est apparu. Pourquoi coupler ? Trois raisons au moins motivent ce
besoin : lintroduction du client-serveur prsentation universelle (architectures 3-
tiers), la gnration de sites Web dynamiques composs partir de templates Html et
de donnes extraites de bases, et le commerce lectronique, qui ncessite la gestion de
catalogues et de transactions en bases de donnes.
Il existe dj de nombreuses solutions industrielles, plus ou moins issues de la
recherche, telles Oracle Web, Web SQL de Sybase, LiveWire de Netscape, Visual
Interdev de Microsoft, O2 Web, etc. Ces outils ralisent une intgration faible de deux
modles de donnes (le relationnel-objet et le modle semi-structur abstrait de Html).
Ils sont insuffisants car ils ne permettent gure la transcription automatique de rsul-
tats de requtes en Html et vice-versa.
De nombreux projets de recherche (par exemple, Tsimmis Stanford [Abiteboul97],
Strudel ATT [Fernandez97], MiroWeb au PriSM en collaboration avec Osis et
lInria) tendent permettre le stockage direct dhypermdia dans la base. XML parat
le standard adapt pour les bases de donnes semi-structures. Les principaux projets
proposent des modles de reprsentation de documents XML et des langages dinter-
rogation associs. Les bases de donnes semi-structures [Abiteboul96, Buneman97]
modlisent les donnes par un graphe tiquet, chaque nud feuille pouvant corres-
pondre un objet externe, structur ou non. Les tiquettes correspondent aux tags
XML. La figure XVIII.2 illustre un document semi-structur reprsent sous la forme
dun graphe et en XML.
Lutcia <RACINE>
RACINE
NOM <HOTEL>
<NOM> Lutcia </NOM>
TEL 12345678
HOTEL.1 <TEL> 12345678 </TEL>
FAX <FAX> 98765432 </FAX>
98765432 <ADRESSE>
Rivoli <RUE> Rivoli </RUE>
ADRESSE
RUE <VILLE> Paris </VILLE>
</ADRESSE>
HOTEL.2 Paris
VILLE </HOTEL>
<HOTEL>
NOM <NOM> Crillon </NOM>
Crillon
<TEL> 13578642 </TEL>
</HOTEL>
13578642 </RACINE>
TEL
grammaire des documents (DTD) peut tre maintenue comme une nouvelle sorte de
contrainte dintgrit. La question dintgrer le semi-structur aux SGBD existants
reste pose. Elle ncessite en particulier la capacit dcouvrir des structures rpti-
tives dans les documents, afin de les reprsenter sous forme dextensions de types.
Les langages SQL ou OQL doivent aussi tre tendus pour manipuler les graphes
dobjets semi-structurs, par exemple avec des parcours de chemins et des expressions
rgulires [Abiteboul97, Arocena98, Consens93, Fernandez97, Konopnicki95,
Mendelzon96].
La ralisation dadaptateurs capables de gnrer une vue semi-structure de sources
de donnes structures ou non est aussi un problme dactualit. Il faut non seulement
comprendre la smantique des sources afin de dcouvrir un peu de structure mais
aussi assurer le passage du structur au semi-structur. Des vues partielles de sources
sous forme de graphes tiquetes doivent tre gnres sur demande partir de
requtes.
Loptimisation de requtes mixant des donnes structures et semi-structures pose
aussi des problmes nouveaux. Il faudrait pouvoir disposer dun modle de cot pour
donnes semi-structures. La gestion de documents distribus (sur Intranet ou
Internet) ncessite aussi des techniques doptimisation originale pouvant allier les
approches push et pull.
4. BD MULTIMDIA
Le multimdia est la mode [Subrahmanian96]. Il est reconnu quune BD multimdia
doit possder cinq caractristiques :
1. grer des types de donnes multimdias incluant texte libre, gomtrie, image, son,
vido ;
2. offrir les fonctionnalits des bases de donnes, cest--dire lexistence dun langage
dinterrogation non procdural permettant les recherches par le contenu, la persis-
tance, la concurrence et la fiabilit ;
3. assurer la gestion de larges volumes de donnes, pouvant atteindre les pta-bases
(10**15) ;
4. supporter des structures de stockage efficaces comme les Quadtree, les Rtree et
leurs variantes, pour permettre la recherche rapide par le contenu ;
5. tre capable de rcuprer des informations partir de sources htrognes.
Linterrogation dobjets multimdias passe par la recherche classique dans une BD
structure partir dattributs dcrivant les objets (exact-match retrieval), mais surtout
par la recherche base sur le contenu des objets. Une requte typique est la recherche
718 BASES DE DONNES : OBJET ET RELATIONNEL
des k objets les plus similaires un objet donn. L, il ny a pas de garantie sur la cor-
rection et la prcision des rsultats. On rcupre un ensemble de rsultats classs par
ordre de pertinence et interrogeable nouveau (raffinement). Dans cet esprit, une
extension de SQL3 avec des types de donnes abstraits spcifiques au multimdia est
en cours de conception par un sous-groupe de lISO : SQL multimdia (SQL/MM). Il
sagit dun projet international de standardisation dont lobjectif est de dvelopper une
librairie de types SQL pour les applications multimdias. SQL/MM est compos de
diverses parties amenes voluer : Full text, Graphic still, Animation, Image still,
Full motion video, Audio, Spatial 2D et 3D, Music. Tous ces types de donnes
devraient tre standardiss, en conjonction avec dautres efforts (MPEG 7 par
exemple).
Les thmes de recherche lis au multimdia sont nombreux et sortent souvent du strict
domaine des bases de donnes. Il sagit en particulier de lindexation automatique
[Salton88], de lextraction de caractristiques (features), de lvaluation de distances
combines entre objets, de la gestion de proximit smantique, du dveloppement de
structures de stockage efficaces. Loptimisation de requtes, les modles de cots, la
formulation et lvaluation de requtes mixtes, lintgration aux SGBD existants, la
distribution et la recherche sur Internet/Intranet devraient aussi contribuer la consti-
tution de muses virtuels interrogeables par le contenu sur les grands rseaux.
5. CONCLUSION
Les bases de donnes ont connu une volution douce vers lobjet, le standard tant
aujourdhui le relationnel-objet et SQL3. Les domaines les plus actifs sont le dci-
sionnel, lintgration avec le Web et le multimdia. Nous dveloppons ces thmes
dans un ouvrage complmentaire. Les bases de donnes mobiles ne sont pas non plus
ngliger et la conception, notamment dentrept de donnes et de BD actives, res-
tent des problmes ouverts. Il ne faut pas non plus ngliger les thmes de recherche
traditionnels o il y a encore beaucoup faire (mthodes daccs, concurrence,
rparti, intgrit et vues, paralllisme).
Un sondage effectu rcemment auprs de 20 chercheurs reconnus (comit de pro-
gramme de CIKM) sur leurs domaines dintrt a donn les rsultats indiqus
figure XVIII.3. La note est un poids entre 0 et 20 (intrt ou non).
Si lon analyse les thmes des articles des derniers VLDB et SIGMOD, on obtient des
rsultats sensiblement diffrents comme indiqus figure XVIII.4. Tout ceci montre
la fois la multiplicit, la diversit et louverture de la recherche en bases de donnes.
Les enjeux conomiques sont trs grands, ce qui explique la croissance du nombre de
chercheurs (400 articles soumis au dernier VLDB, 220 CIKM).
Nouvelles perspectives 719
Multimedia Databases 19
DataWarehousing and Mining 18
Query Languages and Query Processing 9
Semi-structured and Web DB 7
Heterogeneous an Distributed Systems 7
Object Storage Methods 7
Transaction and Reliability 7
Active & Rule Databases 5
Tuning, Benchmarking and Performance 4
Application 3
Database Design 3
User and Application Interfaces 2
Parallel database systems 2
Imprecise and Uncertain Information 1
Privacy and Security Issues 1
Figure XVIII.4 : Analyse des thmes des articles des derniers SIGMOD et VLDB.
Pour terminer, nous voudrions souligner la vertu des prototypes et des applications en
bases de donnes. La ralisation de systmes plus ou moins exploratoires (Socrate,
720 BASES DE DONNES : OBJET ET RELATIONNEL
Syntex, Sabre, O2) a permis par le pass de constituer des quipes masse critique de
pointe. Elle permet aussi dacqurir des connaissances, de les et maintenir et de le
passer de nouveaux chercheurs au sein dun systme. Il ne faudrait pas que la rduc-
tion et la dispersion des crdits conduisent abandonner les grands projets au profit
de publications souvent secondaires.
La ralisation dapplications laide de prototypes avancs permet de cerner les vri-
tables besoins et de dcouvrir des sujets neufs. De grandes expriences couples au
rseau (Intranet ou Internet) sont dj en cours par exemple au Muse du Louvre et
Bibliothque Nationale. Une meilleure participation de la recherche dans ces projets
est souhaitable.
6. BIBLIOGRAPHIE
[Abiteboul97] Abiteboul S., Querying semi-structured data , Proc. Of the
International Conference on Database Theory (ICDT), Jan. 1997.
Une mise en perspective thorique des bases de donnes semi-structures.
[Abiteboul97] Abiteboul S., Quass D., McHugh J., Widom J., Weiner J., The Lorel
Query Language for Semi-structured Data , Journal of Digital Libraries,
vol. 1, n 1, p. 68-88, April 1997.
Cet article prsente le langage LOREL, extension de OQL pour les donnes
semi-structures.
[Agrawal93] Agrawal R., Imielinski T., Swami A. N., Mining Association Rules
between Sets of Items in Large Databases , Proc. of the 1993 ACM SIGMOD
International Conference on Management of Data, Washington, D.C., 1993 ,
p. 207-216.
Le premier article sur les rgles associatives. Il propose la mthode Apriori
pour extraire les rgles associatives de grandes bases de donnes.
[Arocena98] Arocena G., Mendelzon A., WebOQL : Restructuring documents, data-
bases and Webs , in Proc. IEE ICDE 98, Orlando, Florida, Feb. 1998.
Cet article propose un langage dinterrogation pour le Web construit partir
dOQL.
[Buneman97] Buneman P., Semi-structured data , Proc. ACM PODS97, Tucson,
Arizona, USA, p. 117-121, 1997.
Cet article prsente un tutoriel sur les donnes semi-structures. En particulier
le langage UnQL et les premires techniques doptimisation, en particulier
pour les expressions rgulires, sont dcrits.
Nouvelles perspectives 721
Question 1
Rappelez le fonctionnement dune E/S disque et calculez le temps ncessaire en fonc-
tion de la vitesse de rotation et du temps de dplacement de bras unitaire. Fixez les
paramtres des valeurs correspondant aux technologies courantes.
Question 2
Quel est le temps ncessaire pour excuter les requtes en attente suivant leur ordre
darrive (stratgie FIFO) ?
Question 3
Dterminez les quatre meilleures permutations possibles des requtes minimisant le
temps dE/S disques. Parmi ces quatre squences, quelle est la meilleure ? Pourquoi ?
Question 4
Donnez le principe dun algorithme permettant de trouver la squence optimale. Quel
doit tre son temps de rponse maximal pour quil puisse tre utilis ?
Question 5
Calculez le temps ncessaire pour excuter les cinq instructions dE/S en attente en choi-
sissant chaque fois dexcuter la requte la plus proche des ttes de lecture-criture.
Question 6
Lutilisation de disques RAID permet dacclrer les E/S disques. Discutez des diff-
rents types de RAID et de leur intrt pour acclrer les cinq requtes.
Exercices 725
Question 1
Discutez le choix de la taille du paquet.
Proposez quelques fonctions de hachage afin de dterminer le numro de paquet
partir du numro de produit. Discutez de lintrt de ces fonctions selon le mcanisme
dattribution des numros de produits.
Question 2
Lorsquun paquet est plein, un produit devant tre insr dans ce paquet est crit en
dbordement. Proposez diffrentes solutions pour la gestion des dbordements. Pour
chacune delles, calculez le nombre dentres-sorties moyen ncessaires pour crire
un nouvel article et lire un article existant.
Question 3
On utilise le hachage extensible. Rappelez lalgorithme dcriture dun nouvel article
et de lecture dun article. Calculez le nombre dentres-sorties ncessaires pour crire
un nouvel article et lire un article existant.
Question 4
Mme question avec le hachage linaire.
Question 1
Rappelez la dfinition dun arbre B et dun arbre B+. Illustrez ces dfinitions en
construisant un arbre B et un arbre B+ pour stocker lalphabet dans des arbres dordre
2. Quel est lintrt dun arbre B+ par rapport un arbre B ?
Question 2
Calculez le nombre de comparaisons de cls ncessaires la recherche dune lettre
dans un arbre B et B+ dordre 2. Ce nombre est-il diffrent pour un arbre dordre 3 ?
726 BASES DE DONNES : OBJET ET RELATIONNEL
Question 3
Il est possible de comprimer les cls dans un arbre B ou B+ en enregistrant pour
chaque cl seulement la diffrence par rapport la prcdente. Prciser alors le format
de chaque entre dans larbre B. Donnez les algorithmes de recherche et dinsertion
dune cl dans un arbre B ou B+ en prenant en compte la compression.
Question 4
VSAM implmente les arbres B+ en essayant de les calquer la structure des disques.
Discutez de lintrt de cette approche et de ses inconvnients. Calculez le nombre
dentres-sorties ncessaires pour lire un article dans un fichier avec un seul niveau
dindex matre. Mme question pour les insertions darticles.
Question 5
Une recherche dans un fichier simplement index par un arbre B sur une cl non dis-
criminante (cl secondaire) peut tre coteuse. Pourquoi ? Proposez des approches
pour rduire le temps dentres-sorties disques ncessaire.
Question 1
Donnez larbre obtenu en partant dune racine vide aprs insertion des articles de cl :
{Marcel, Marius, Martine, Maurice, Marcelle, Maude, Marc, Marguerite, Mathilde,
Maxime, Marielle, Martial, Mariette, Marina, Matthieu, Mattias} dans lordre indi-
qu.
Question 2
Donnez larbre obtenu si la liste des articles est trie selon lordre des cls :
{Marc, Marcel, Marcelle, Marguerite, Marielle, Mariette, Marina, Marius, Martial,
Martine, Mathilde, Matthieu, Mattias, Maude, Maurice, Maxime}.
Question 3
Proposez une procdure de construction de larbre B+ par construction directe des
feuilles et des sommets intermdiaires partir dun fichier tri des articles.
Question 4
On remarque que dans un arbre B+ les cls dans les sommets non-feuilles ne servent
que daiguilleurs dans la recherche dun article de cl donne. On utilise cette
remarque pour augmenter le nombre de couples cl/pointeur dans les sommets non-
feuilles en remplaant les cls par un prfixe de ces cls.
Donnez la rgle qui permet de dterminer le plus petit prfixe possible qui conserve la
proprit daiguiller correctement la recherche dans larbre.
Question 5
Donnez larbre obtenu en utilisant des prfixes par insertions rptes comme dans la
question 1.
Question 6
Discutez les avantages et les inconvnients de cette mthode pour de petits fichiers et
pour de grands fichiers.
728 BASES DE DONNES : OBJET ET RELATIONNEL
Question
Quelle est la meilleure mthode et le nombre correspondant dentrees/sorties disques
ncessaires pour rpondre aux recherches suivantes :
Q1. (A = valeur)
Q2. (valeur < A )
Q3. (C = valeur)
Q4. (B = valeur)
Q5. (valeur 1 < C < valeur 2).
Q6. (C = valeur 1) ET (E = valeur 2)
Exercices 729
Les comparateurs peuvent tre =, <, > , , . Les expressions de AND et OR peuvent
tre encadres de parenthses pour indiquer les priorits.
Par exemple, on recherchera dans un fichier de vins tous les articles satisfaisant :
(CRU = Volnay OR CRU = Chablis)
AND DEGR 12 AND MILLSIME = 2000.
Question 1
On suppose le fichier des vins indexs par un arbre B sur la cl secondaire DEGR.
Proposez un format dentre pour un tel index. Justifiez votre solution.
Les degrs tant nombreux car continus entre 0 et 20, comment peut-on rduire leur
nombre ?
Proposez un algorithme permettant de rpondre aux requtes prcisant DEGR > $v,
o $v dsigne un rel compris entre 0 et 20.
Question 2
Ce fichier est aussi index sur les cls secondaires CRU et MILLSIME. Proposez
trois mthodes pour rsoudre des requtes du type CRU = $c AND MILLSIME =
$m, lune utilisant les deux index, les deux autres un seul ($c et $m sont deux
constantes). Essayer destimer le cot en entres-sorties de chacune delles. Donnez
des heuristiques simples pour choisir lune ou lautre.
Question 3
De manire gnrale, proposez un algorithme capable dvaluer efficacement des
recherches avec critres multiples conjonctifs (AND).
Question 4
tendre lapproche au cas de critres multiples connects avec des AND et des OR.
Question 5
Un fichier hach peut aussi tre index selon plusieurs attributs. Comment peut-on
amliorer lalgorithme prcdent pour supporter aussi des fichiers hachs ?
730 BASES DE DONNES : OBJET ET RELATIONNEL
Question 1
On dsire placer un fichier de lignes de commandes de format (NC, NP, TYPE,
QUANTIT, PRIX) par hachage multi-attributs. NC dsigne le numro de com-
mande, NP le numro de produit et TYPE le type du produit. Sachant que 50 % des
recherches se font sur NC, 20% sur NP et 30% sur le type de produit, proposez des
fonctions de hachage optimum afin de placer un tel fichier dans 100 paquets.
Question 2
Proposez un algorithme gnral pour rpondre aux requtes multicritres prcisant
deux des attributs hachs parmi les trois, par exemple NC et TYPE.
Question 3
Gnralisez lalgorithme pour traiter des requtes multicritres avec AND et OR,
comme vu lexercice prcdent.
Question 4
Les fichiers hachs peuvent aussi tre indexs par des arbres B. Discutez des formats
dadresses darticles intressants pour grer les index en conjonction au hachage.
Intgrez les rsultats de lexercice prcdent lalgorithme de la question 3. En
dduire un algorithme gnral pour traiter des requtes multicritres sur des fichiers
hachs sur plusieurs attributs et indexs.
Question 1
Prcisez le format dun index bitmap et des structures associes. Calculez la taille
dun tel index. Proposez des mthodes de compression pour un tel index.
Question 2
Donnez les algorithmes dinsertion et suppression dun enregistrement dans un fichier
avec index bitmap.
Question 3
Un index bitmap sur un attribut A est idal pour acclrer des recherches sur critre
de la forme :
A = $a0 OR A = $a1 OR ... A = $an.
Question 4
On peut grer plusieurs index bitmap pour un mme fichier, sur des attributs A, B, etc.
Prcisez les types de critres pouvant tre traits par des index bitmap.
Question 5
On considre un fichier avec index bitmap et index secondaires sous la forme darbre
B. Que doit rfrencer une entre dans un index secondaire pour tre combinables
avec les index bitmap ? Donnez un algorithme gnral de recherche multicritres pre-
nant en compte les index secondaires et les index bitmap.
RUE CARREFOUR
RC CC
CONNEXION
732 BASES DE DONNES : OBJET ET RELATIONNEL
Une rue possde un nom, une longueur, une largeur minimum, un revtement et un
nombre de voies. Un carrefour possde un nom et un indicateur de prsence de feu tri-
colore. Une connexion indique la prsence ventuelle dun sens interdit.
Question 1
Donnez le schma CODASYL correspondant ce diagramme.
Question 2
Donnez le graphe des occurrences correspondant au plan simplifi, trois rues (X, Y,
Z) et quatre carrefours (C1, C2, C3, C4), suivant :
C2 Rue Y
Rue X C3 C4
C1
Rue Z
Question 3
Donnez le programme en DML CODASYL permettant de trouver tous les carrefours
avec feu de la rue Albert Einstein.
Question 4
Donnez le programme en DML CODASYL permettant de trouver toutes les rues qui
sont directement accessibles depuis la rue Albert Einstein (donc qui lintersectent o
sy raccordent). Une rue nest pas accessible si elle est en sens interdit.
Question 5
Sachant que les poids lourds partent dun dpt situ dans la rue A, doivent rejoindre
le client situ rue B et ne doivent circuler que dans des rues de largeur suprieure 10
mtres, donner le programme en DML CODASYL et pseudo-code qui recherche tous
les itinraires possibles en ne les donnant quune fois avec leur longueur et le nombre
de feux. On prcise que la partie pseudo code devra rester un niveau de quelques
blocs de commentaires et devra rsoudre le problme de la dtection des boucles.
Exercices 733
Question 6
Proposez un placement des types darticle dans un ou plusieurs fichiers pour acclrer
les performances. Donnez le nombre dentres-sorties disque ncessaires pour traiter
la question 4.
(0,N)
FOURNISSEURS ACHTE CLIENTS
(1,N) Prix
VEND
(0,N) Remise
FOURNISSEURS
NF Nom Rgion
Cette base dcrit des produits vendus par des fournisseurs des clients.
Question 1
Donnez le schma rseau en DDL CODASYL correspondant au diagramme entit-
association reprsent figure 1. On prcise que les entits PRODUITS et FOURNIS-
SEURS sont ranges dans un mme fichier FOU via le set VEND, alors que les ins-
tances de CLIENTS sont ranges dans le fichier CLI.
Question 2
crire les programmes en DML CODASYL correspondant aux requtes suivantes :
1. Nom des fournisseurs vendant des produits de type informatique .
2. Nom des clients ayant achet de tels produits.
734 BASES DE DONNES : OBJET ET RELATIONNEL
3. Noms des produits et liste des fournisseurs associs ayant vendu au client de NSS
153300017012.
4. Chiffre daffaires total ralis avec le client Dupond Jules.
Utiliser du pseudo-Pascal ou pseudo-C si ncessaire.
Question 3
Donnez un schma relationnel pour la base de donnes reprsente.
Question 4
Exprimer en SQL les requtes correspondant aux questions tudies au 2.
Question 5
Pour les schmas reprsents, proposez un algorithme de traduction automatique de
requte SQL de type restriction-projection-jointure en programme DML CODASYL.
Pour cela, on traduira chaque requte en un arbre doprations de lalgbre relation-
nelle optimis de manire adquate ; ensuite, on traduira des groupes doprateurs
choisis en programmes DML avec du pseudo-PASCAL ou pseudo-C.
Question 6
tudiez le r-engineering de la base rseau propose en base relationnelle. Discutez
des difficults. Proposez une dmarche.
C1 C2 C3 C4 B1 A1 A2
A3
(0,N)
S RS R
(0,1) (1,1)
D1
ST2 ST1
D2
(0,N) (1,N)
E1 E2 E3
Question 1
Donnez le schma de la base de donnes relationnelle reprsentant directement ce dia-
gramme entit-association (une entit gnrant une relation, une association gnrant
une relation), avec les cls et les contraintes rfrentielles ncessaires.
Question 2
Exprimer en calcul de tuples les requtes suivantes :
1. Donnez tous les attributs de S pour les tuples dont lattribut C3 est compris entre
100 et 200.
2. Donnez les attributs C1 et C2 de S, E1 et E2 de T tels que les tuples de S et T soient
associs par un tuple de ST1 dattribut D1 suprieur 10.
3. Mme question, mais on souhaite en plus quil existe un tuple de R correspondant
chaque tuple de S slectionn, via lassociation RS, ayant un attribut A2 positif.
4. Donnez les tuples de T associs par RS tout tuple de R et au moins un tuple de T
par ST1 ou ST2.
Question 3
Exprimer ces mmes requtes en calcul de domaines.
Question 4
Exprimer ces mmes requtes en QBE.
Question 5
Exprimer ces mmes requtes en SQL.
736 BASES DE DONNES : OBJET ET RELATIONNEL
Question 1
Exprimer sous la forme dun arbre de calcul de lalgbre relationnelle les requtes sui-
vantes :
a) Donnez le nom, le prnom, la date de laccident pour chaque personne blesse fata-
lement dans un accident du dpartement 75 dans une voiture Citron.
b)Trouver les personnes qui ont t blesses dans tous les accidents o elles taient
conductrices.
Question 2
Que retrouve larbre algbrique suivant ?
Exercices 737
=
NACC NACC
N COND N PERS
NVH = NVH
N PERS
Question 3
Calculez le cot en entres/sorties disques de larbre de la question prcdente avec
les hypothses suivantes :
La relation VHICULE comporte 1 000 000 tuples dont 850 sont des Honda Civic;
elle est place par hachage statique sur le NVH ; elle possde un index secondaire
sur le TYPE qui est un arbre B+ 3 niveaux.
Les index secondaires du systme utilis retournent la cl primaire (ou cl de place-
ment) et non pas directement ladresse physique.
La relation VHPART comporte 100 000 tuples ; elle est place sous forme darbre
B+ sur le NACC (index primaire).
La relation BLESS comporte 40 000 tuples dont 10 000 sont des blesss lgers ;
elle est place en squentiel avec un facteur de blocage (moyen) de 20 tuples par
page.
Les jointures sont faites par lalgorithme des boucles imbriques.
Tous les rsultats intermdiaires tiennent en mmoire centrale ; une page de
mmoire correspond un bloc de disque.
Question 4
Que devient le cot des entres/sorties si la mmoire est limite m pages ?
738 BASES DE DONNES : OBJET ET RELATIONNEL
R A B
1 5
1 7
2 8
3 8
A(B*)(R) A {B}
1 {5,7}
1 {8}
2 {8}
A(B*)(R) A {B}
1 {5,7}
1 {8}
2 {8}
Afin dillustrer, on considre une base de donnes dcrivant un stock de jouets de type
A, B, C ou D livrs par des fabricants en une certaine quantit une certaine date. Le
schma de la base est le suivant :
JOUETS(NJ,NOMJ,TYPE,PRIX)
FABRIQUANTS(NF,NOMF,VILLE,ADRESSE)
LIVRAISONS(NF,NJ,DATE,QUANTITE)
Question 1
Exprimez en algbre relationnelle tendue les questions suivantes sur la base de don-
nes des jouets :
a) Donnez la liste des fabricants qui ont livr au moins un jouet de type A et de prix
suprieur 1 000 F ainsi que le nom des jouets correspondants livrs.
b)Donnez la liste des fabricants qui nont pas livr de jouets.
c) Donnez la somme des quantits livres par chaque fabricant (caractris par NOMF
et ADRESSE).
Question 2
On se propose doptimiser lalgorithme dintersection de deux relations R1 et R2.
Proposez trois algorithmes permettant de raliser cet oprateur dans les cas sans
index, respectivement bass sur :
a) le produit cartsien des deux relations ;
b)le tri des deux relations ;
c) le hachage des relations avec tableaux de bits.
En supposant quil existe trois tampons dune page en mmoire, que les relations
comportent respectivement r1 et r2 pages (r1 < r2) et que la relation intersection est
compose de i pages, calculez approximativement le cot en E/S de chaque algo-
rithme. On supposera que les tableaux de bits tiennent en mmoire et quils permet-
tent dliminer un pourcentage b des tuples de la deuxime relation.
740 BASES DE DONNES : OBJET ET RELATIONNEL
Question 3
On se propose dtudier lalgorithme de groupage dune relation R. Proposez trois
algorithmes permettant de raliser cet oprateur dans les cas sans index, respective-
ment bass sur :
a) la comparaison des tuples de la relation (proche du produit cartsien) ;
b)le tri de la relation ;
c) le hachage de la relation avec comparaisons internes aux paquets.
En supposant quil existe trois tampons dune page en mmoire, que la relation com-
porte r pages et que la relation groupe est compose de g pages, calculez approxima-
tivement le cot en E/S de chaque algorithme.
Question 4
Exprimer la question suivante en SQL sur la base de donnes des jouets :
Donnez les chiffres daffaires de chaque fabricant (caractris par son NOMF et son
ADRESSE) de poupes (NOMJ LIKE Poupe ).
Exprimer cette question en algbre relationnelle tendue.
Donnez un arbre doprateurs dalgbre relationnelle optimis permettant de calculer
la rponse cette question. On ajoutera pour cela loprateur de groupage (not par un
rectangle) aux oprateurs classiques.
Les rayons identifis par la cl NOMR sont situs un tage donn. Les articles sont
rfrencs par lentier RFRENCE et dcrit par un type, une description et une cou-
leur. Ils sont disponibles en une certaine quantit chaque rayon. Un employ tra-
vaille un rayon et a pour responsable un autre employ. Lattribut responsable repr-
sente donc un numro demploy.
Exercices 741
Question 1
Proposez sous la forme dun graphe un ensemble de cls trangres pour cette base de
donnes.
Question 2
Exprimer en algbre relationnelle puis en SQL les requtes suivantes :
a) rfrences des articles de type lectromnager en rayon au second tage,
b)nom des employs travaillant dans un rayon proposant des articles de type jouet
pour une quantit totale suprieure 1 000.
Question 3
Exprimer en SQL les requtes suivantes :
c) nom des employs qui gagnent plus que leur responsable,
d)tages qui ne vendent que des vtements.
Question 4
Exprimer en calcul de tuple puis en SQL la requte suivante :
e) nom et salaire du responsable le mieux pay.
La base du WCCR comprend cinq relations et les cls sont soulignes. Les SPOTS
sont les bons coins pour faire de la planche, avec un numro, leur nom, lexposition
principale par exemple Sud-Ouest, le type par exemple Slalom ou Vague, et une
note dapprciation globale. Les PLANCHISTEs sont les membres du club et les invi-
ts, les niveaux varient de Dbutant Comptition. Le MATOS (jargon planchiste
pour matriel) comprend la description des planches utilises (pour simplifier les
voiles, ailerons, etc., ne sont pas reprsents). Le VENT dcrit la condition moyenne
dun spot pour une date donne. Enfin NAVIGUE enregistre chaque sortie dun plan-
742 BASES DE DONNES : OBJET ET RELATIONNEL
chiste sur un spot une date donne avec le matos utilis. Pour simplifier, on suppose
quun planchiste ne fait quune sortie et ne change pas de matos ni de spot dans une
mme journe.
Question 1
Indiquez les cls trangres ventuelles de chaque relation.
Question 2
Donnez les expressions de lalgbre relationnelle qui permettent de calculer les
requtes suivantes :
a) Nom des planchistes de niveau Confirm qui ont navigu le 20/07/99 sur un spot
o le vent moyen tait suprieur force 4 sur une planche de moins de 2,75 m.
b)Nom des planchistes qui ne sont pas sortis le 20/07/99
c) Nom des planchistes qui ont essay tous les types de planches de la marque
FANA-BIC. On suppose que tous les types sont dans la relation MATOS.
Question 3
Donnez les expressions de calcul de tuples correspondant aux trois requtes prc-
dentes.
Question 4
Donnez les ordres SQL correspondant aux requtes suivantes :
c) Nom des planchistes qui ont essay tous les types de planches de la marque
FANA-BIC. On suppose que tous les types sont dans la relation MATOS.
d)Pour chaque spot de la base, en indiquant son nom, donner le nombre de jours de
vent au moins de force 4 pour lanne 94.
e) Pour chaque marque de matriel reprsente par au moins 10 planches, indiquer le
nombre dutilisateurs Confirm ou Expert.
Les clients rservent des chambres dans des htels en station. On note que pour une
rservation de plusieurs personnes (couple ou famille) un seul nom de client est enre-
gistr. De plus une rservation porte sur une seule chambre (pour une famille dans
deux chambres il faudra deux tuples dans rservation).
Exprimer en SQL les questions suivantes :
Question 1
Donnez le nom des clients et le nombre de personnes correspondant pour les rserva-
tions de lhtel Bellevue Courchevel.
Question 2
Pour chaque station de Haute-Savoie, donner le nombre de lits en catgorie trois
toiles.
Question 3
Pour chaque station de Haute-Savoie, donner le nombre de chambres rserves le
samedi 11/02/95.
Question 4
Quels sont les noms des htels de catgorie deux toiles de Mribel qui sont com-
plets la semaine du 12/02/2000 au 18/02/2000 ?
Question 5
Quelles sont les rgions dont toutes les stations sont plus de 1500 m daltitude ?
Question 6
Quels sont les clients qui sont alls dans toutes les stations du Jura ?
Tous les attributs sont de type chanes de caractres notamment un bar, un buveur ou
un vin.
744 BASES DE DONNES : OBJET ET RELATIONNEL
Cette base gre des objets archologiques et des publications sur ces objets. La rela-
tion OBJET dcrit les objets proprement dits avec lindication de leur type (par
exemple vase), de leur datation qui est une anne, du site o ils ont t dcouverts et
du muse o ils se trouvent actuellement. La relation VILLE comprend deux noms
pour simplifier (ce qui par exemple exclut le cas BIZANCE-CONSTANTINOPLE-
ISTAMBUL). La relation SITE indique la ville laquelle se rattache le site et un
numro qui est un numro dordre pour cette ville : toutes les villes ont un site 1, un
site 2, etc. La civilisation du site est une grande catgorie comme romaine ou cr-
toise. Les cls sont soulignes.
Question 1
Exprimer en SQL les requtes suivantes sur la base :
Q1. Quelles sont les frises du troisime sicle ? Donnez leur numro et leur description.
Q2. Mme question avec en plus le nom du muse o elles sont exposes.
Q3. Noms et prnoms des auteurs douvrage(s) rfrenant des objets de la civilisa-
tion Dorienne.
Q4. Quelles statues sont exposes dans la ville o elles ont t dcouvertes ?
Donnez le numro et la description.
Q5. Donnez le nom actuel des villes (sil en existe) dont le nom actuel est le mme
que le nom ancien dune autre ville.
Q6. Donnez le nombre de statues trouves dans chaque site de la civilisation phni-
cienne.
Q7. Quels sont les sites dAthnes qui ont fourni plus dobjets que le site 5 nen a
fourni ?
Q8. Noms et prnoms des auteurs des ouvrages qui rfrencent tous les objets trou-
vs dans le site 2 de Thbes.
746 BASES DE DONNES : OBJET ET RELATIONNEL
Question 2
Soit la requte SQL suivante :
SELECT P.TITRE, P.DATE
FROM PUBLICATION P, AUTEUR A, COOPERATION C,
REFERENCE R, OBJET O, MUSEE M
WHERE A.NOM = Vieille
AND A.PRENOM = Pierre
AND A.NUM-AUT = C.NUM-AUT
AND C.NUM-PUB = P.NUM-PUB
AND P.EDITEUR = ditions archologiques modernes
AND P.NUM-PUB = R.NUM-PUB
AND R.NUM-OBJ = O.NUM-OBJ
AND O.TYPE = Mosaque
AND O.NUM-MUSEE = M.NUM-MUSEE
AND M.NOM = Le Louvre
Proposez deux arbres algbriques diffrents pour excuter cette requte. Le premier
arbre sera optimis au mieux en utilisant les heuristiques de restructuration algbrique
et le second sera le pire possible.
Question 3
On suppose quil y a dans la base 10 000 publications, 100 diteurs distincts,
1 000 auteurs de noms diffrents (pas dhomonymes), 2000 cooprations, 100 000 objets,
200 types dobjets diffrents, 1 000 000 de rfrences et 100 muses de noms diff-
rents (pas dhomonyme).
On suppose de plus que toutes les distributions sont uniformes et indpendantes.
En prenant comme unit de cot la comparaison pour les slections et les jointures, en
supposant quil ny a pas dindex et en admettant que toutes les jointures se font par
produit cartsien, calculer le cot dexcution des deux arbres que vous avez propos.
Question 4
Si vous tiez autoris crer un seul index pour acclrer cette requte, lequel choisi-
riez-vous ? Pourquoi ?
relations diffrentielles sont associes chaque relation R : la relation des tuples sup-
prims R et celle des tuples insrs R+. Un tuple modifi donne naissance deux
tuples, lun dans R-, lautre dans R+. En fin de transaction valide, les tuples de R
sont enlevs de R et ceux de R+ ajouts R. Le SGBD ralise : R = (R R-) R+.
En guise dillustration, on utilisera la base compose des tables suivantes :
PLAGE (NP, NOMP, TYPE, REGION, POLLUTION)
NAGEUR (NN, NOM, PRENOM, QUALITE)
BAIGNADE (NN, NP, DATE, DUREE).
La relation PLAGE modlise les plages de France, de nom NOMP, de type TYPE
(galets, sable ou rocher) ayant un taux de pollution donn (attribut POLLUTION). La
relation NAGEUR mmorise les nageurs de qualit excellente, bonne ou mdiocre. La
relation BAIGNADE dcrit les bains effectus par les nageurs.
Question 1
Dfinir en SQL2 les contraintes dintgrit suivantes :
1. La qualit dun nageur est excellente, bonne ou mdiocre (contrainte de domaine).
2. Toute baignade a t effectue par un nageur existant dans la base sur une plage
existante (contraintes rfrentielles).
3. Le type et la rgion dune plage dterminent sa pollution de manire unique (dpen-
dance fonctionnelle).
4. La somme des dures des baignades dun nageur par jour ne doit pas excder deux
heures.
Question 2
Prcisez quels types de contraintes dintgrit peuvent tre vrifies aprs chaque
ordre de mise jour (INSERT, DELETE, UPDATE) ceux qui ncessitent dattendre la
fin de transaction.
Question 3
Proposez des algorithmes pour traiter chaque type de contraintes dintgrit, soient
excuts aprs la mise jour, soient en fin de transaction. Montrer quil est possible
de combiner les deux types de vrification.
Question 4
Les contraintes avec agrgats comme la somme des dures des baignades sont co-
teuses vrifier chaque mise jour. Proposez une mthode base sur des donnes
redondantes afin de rduire ce cot.
748 BASES DE DONNES : OBJET ET RELATIONNEL
NUMF, NUMP, NUMA, NUMC, NUMS, sont des identifiants uniques (cls primaires) pour
respectivement : FILM, PERSONNE, ACTEUR, CINMA, SALLE.
Tout nom de relation utilis comme attribut est une cl trangre qui renvoie liden-
tifiant (cl primaire) de la relation correspondante, par exemple dans GNRIQUE,
FILM correspond NUMF de FILM et est dfini sur le mme domaine.
RALISATEUR dans FILM et NUMA dans ACTEUR sont dfinis sur le domaine des
NUMP.
Le numro de salle NUMS est un numro local pour chaque cinma (Salle 1, 2, 3, ).
Question 1
Donnez la dfinition de FILM en SQL2 en prcisant les contraintes de domaine, de
cl (primaire ou candidate), et de cl trangre.
Question 2
Mme question pour GNRIQUE si on suppose quun acteur peut jouer plusieurs
rles dans un mme film.
Question 3
Exprimer la contrainte gnralise suivante : Le budget dun film doit tre suprieur
la somme des salaires des acteurs jouant dans ce film
Question 4
crire un dclencheur qui met jour automatiquement le numro de film dans toutes
les relations o il est utilis si ce numro est modifi dans la relation FILM.
On ajoute un attribut NBSALLES a FILM qui indique le nombre de salles o le film
est actuellement visible.
Exercices 749
Question 5
Utiliser des dclencheurs pour grer automatiquement ce nombre de salles.
La relation produit dcrit des produits en stock de numro NP, de nom NOMP, en
quantit QTES, dont le prix de vente unitaire est PRIXU. La relation VENTES dcrit
les ventes ralises ; celles-ci sont numrotes par client. QTEV est la quantit vendue
pour le produit NP au client NC lors de la vente NV. Pour simplifier, on supposera que
les prix des produits ne changent pas.
Question 1
Dfinir les vues VENTEPRO (NC,NP,NV, QTEV, PRIXU) et VENTETOT (NC,
PRIXT) spcifies comme suit :
VENTEPRO donne pour chaque client, pour chaque produit et pour chaque vente la
quantit de produit vendu et le prix unitaire du produit correspondant.
VENTETOT donne pour chaque client le montant total en francs (PRIXT) des
ventes effectues.
On crira les questions SQL permettant de crer ces vues partir des relations de
base.
Montrer que la vue VENTETOT peut tre dfinie partir de la vue VENTEPRO.
Donnez sa dfinition en SQL partir de VENTEPRO.
Question 2
On introduit un oprateur partitionnement reprsent par un rectangle prparant
lapplication du GROUP BY sur une relation, utilisable dans les arbres relationnels ;
cet oprateur partitionne horizontalement la relation sur les attributs paramtres en
effectuant simplement un tri sur ces attributs : il sagit donc en fait dun oprateur de
tri. En addition, on permet lusage de fonctions agrgats et arithmtiques dans les pro-
jections. Appliques aux relations partitionnes suite loprateur prcdent, les fonc-
tions agrgats accomplissent les calculs dagrgats selon le dernier partitionnement
effectu.
750 BASES DE DONNES : OBJET ET RELATIONNEL
Donnez larbre relationnel optimis permettant de retrouver les clients ayant achet
pour plus de 10 000 F de produits avec la liste des produits quils ont achets.
Question 3
La modification de questions sur des vues (avec ou sans agrgat) ne permettant pas
toujours doptimiser, une autre mthode dimplantation de vues peut tre base sur la
matrialisation de la vue comme une relation implante sur disque (vue concrte). Le
problme qui se pose est alors de mettre jour la vue concrte lors des mises jour
des relations de base. Une technique possible consiste gnrer des dclencheurs
(triggers).
Exprimer en SQL les dclencheurs permettant de maintenir les relations VENTEPRO et
VENTETOT lors dinsertion dun nouveau produit ou dune nouvelle vente dans la base.
De manire gnrale, prciser les rgles gnrer pour maintenir une vue lors dinser-
tion dans une relation de base. On pourra considrer les cas suivants :
1. La vue est sans agrgat, cest--dire issue de projection, jointure et restriction des
relations de base.
2. La vue est avec agrgat.
Question 4
Donnez les rgles permettant de maintenir les relations VENTEPRO et VENTETOT
lors dune suppression dun produit ou dune vente dans la base.
De manire gnrale, prciser les rgles gnrer pour maintenir une vue sans agr-
gat, puis avec agrgat, lors dune suppression dans une relation de base. Discutez
selon les cas. Prciser les attributs quil est ncessaire de rajouter la vue afin dtre
capable de grer correctement les suppressions.
Celles-ci dcrivent des buveurs identifis par lattribut numro NB, des vins identifis
par lattribut numro NV et des consommations (ABUS) de vins identifis par le
numro de buveur, le numro de vin et la date de consommation.
Question 1
Donnez les commandes SQL permettant de crer les vues suivantes :
BUVEURSB (NB, NOM, PRENOM, NV, DATE, QUANTITE)
Question 2
Un utilisateur ayant droit dinterroger partir des vues prcdentes pose la question
suivante :
Donnez le nom des buveurs ayant bu du Beaujolais de millsime 1983 en quantit
suprieure 100, le mme jour .
Exprimez cette question telle que doit le faire lutilisateur en SQL. Exprimez gale-
ment la question modifie portant sur les relations BUVEURS, VINS et ABUS que trai-
tera le systme.
Question 3
De manire gnrale, proposez en quelques botes, sous la forme dun organigramme,
un algorithme permettant de transformer une question pose sur une vue en une ques-
tion exprime sur la base.
Question 4
partir de lexemple, dcouvrir et noncer quelques problmes soulevs par la mise
jour travers une vue rfrenant plusieurs tables :
1. ajout dun tuple dans BUVEURSB ;
2. suppression dun tuple dans BUVEURSB.
752 BASES DE DONNES : OBJET ET RELATIONNEL
o:
NOMV = nom de ville,
POP = population,
NDEP = numro de dpartement,
NOMD = nom de dpartement,
REGION = nom de rgion,
NOMP = nom de produit,
TYPE = type de produit.
Soit lexpression algbrique suivante rfrenant les relations de cette base de don-
nes ( reprsente la jointure naturelle) :
NOMV,NOMP(REGION=Auvergne(POP>10000 (VILLE DEPARTEMENT
SPECIALITE)))
NOMV,NOMP ( NOMP=Fromage (VILLE DEPARTEMENT
SPECIALITE)))
Question 1
Exprimez cette requte :
1) en calcul relationnel de domaine;
2) en calcul relationnel de tuple;
3) en SQL.
Question 2
Reprsentez la question sous forme dun arbre doprations algbriques.
Proposez un arbre optimis par restructuration algbrique pour cette question.
Question 3
Soit v, d et s les tailles respectives en tuples des relations VILLE, DEPARTEMENT et
SPECIALITE. En supposant luniformit des distributions des valeurs dattributs,
calculez une approximation de la taille du rsultat de la question prcdente en
nombre de tuples. On pourra introduire tout paramtre supplmentaire jug nces-
saire.
Exercices 753
Question 1
Donnez les arbres algbriques relationnels optimiss par les heuristiques classiques
des BD relationnelles (descente des projections et restrictions) permettant dexcuter
cette question.
Question 2
On choisit larbre qui effectue les jointures dans lordre R1 avec R2 puis avec R3. En
considrant lutilisation dun algorithme de jointure par produit Cartsien (boucles
imbriques), calculez le temps dexcution en nombre dE/S de cet arbre en fonction
de la taille en page des relations R1, R2 et R3, du nombre moyen de tuples par page T,
du nombre de valeurs distinctes et non distinctes des attributs utiliss. On supposera
pour cela une distribution uniforme des valeurs dattributs. Tout paramtre suppl-
mentaire jug ncessaire pourra tre introduit.
Question 3
Proposez un ensemble dindex plaant et non plaant optimaux pour la base de don-
nes et la question considre.
Calculez alors le temps dexcution de la question.
On pourra supposer pour simplifier que tous les index sont deux niveaux et on ngli-
gera les temps de calcul.
754 BASES DE DONNES : OBJET ET RELATIONNEL
Question 1
On considre alors la question :
SELECT U2,V2
FROM R1, R2, R3
WHERE R3.U1 = R2.V2 AND R2.V1 = R1.T1 AND R3.U3 = 100.
Donnez tous les arbres relationnels effectuant les projections ds que possible permet-
tant dexcuter cette question.
Question 2
Calculez le cot en nombre dentre-sortie des trois arbres effectuant la restriction
dabord dans le cadre dun SGBD relationnel implmentant les restrictions par
balayage et les jointures par parcours dindex ou boucles imbriques. On prcise quil
existe un index sur les cls U1 de R3 et V1 de R2 et pas dautre index. La taille de
chaque relation R1, R2 et R3 est respectivement r1, r2 et r 3. On supposera une distri-
bution uniforme des valeurs dattributs. Le nombre de valeurs distinctes dun attribut
est obtenu par la fonction DIST (par exemple, DIST(U2) est le nombre de valeurs dis-
tinctes de U2). Ce nombre peut tre calcul.
Question 3
Mme question avec des jointures par hachage.
Question 4
Avec un algorithme par hachage ou par boucles imbriques, il est possible de com-
mencer une jointure avant davoir fini la prcdente. Expliquez ces algorithmes dits
de type pipeline.
Dans quel cas est-il intressant dutiliser un algorithme de type pipeline ?
Question 5
On gnralise ce type de requtes N relations Rn, Rn-1,...R1. Donnez la forme gn-
rale dune requte. Calculez le nombre de plans possibles pour une telle requte.
Exercices 755
Question 1
Proposez un algorithme en pseudo-code, utilisant au mieux lindex de jointure, per-
mettant de rpondre la question (bta est une constante et il ny a pas dindex sur
V2) :
SELECT U.U2
FROM U, V
WHERE U1 = V1 AND V2 = beta
Question 2
On suppose que le systme gre un index de U sur U1 et de V sur V1 la place de
lindex de jointure. Dtailler lalgorithme pour rpondre la question prcdente en
utilisant la jointure par index. Calculez le cot dune telle jointure. On prcise que :
1. le nombre doctets occups par chaque valeur de U1 ou U2 est dnot a ;
2. le nombre de valeurs distinctes de U1 est DIST(U1), celui de U2 est DIST(U2) ;
3. les index sont des arbres B+ deux niveaux (feuille + racine).
Comparer la solution index de jointure vue en 1.
756 BASES DE DONNES : OBJET ET RELATIONNEL
Question 1
Donnez en UML la dfinition dun schma objet quivalent cette base relationnelle.
Exprimez ce schma en ODL.
Question 2
Puisque DOCTEUR et INFIRMIER sont des EMPLOYEE, proposez un nouveau
schma objet utilisant lhritage pour la base hospitalire.
Exercices 757
Question 3
Exprimez en OQL la requte suivante : Nom et prnom des cardiologues soignant un
malade Parisien (dont ladresse contient Paris) dans le service de Chirurgie gnrale.
Question 4
Essayez de simplifier le schma objet en introduisant des attributs multivalus.
Proposez des requtes OQL utilisant des collections dpendantes.
Question 1
Discutez de lintrt de choisir un SGBD objet ou objet-relationnel. Effectuez un
choix.
Question 2
Compltez la reprsentation UML de la base en prcisant les cardinalits des associa-
tions.
758 BASES DE DONNES : OBJET ET RELATIONNEL
Personnes
PreNoel Enfants
Effectue
Visite
Tourne Possde
Distribue
Contient
Hte Jouets
Question 3
Dfinir le schma de la base en C++. Bien lire le texte et la question 4 afin de prvoir
les structures et mthodes capables dy rpondre.
Question 4
crire des programmes C++ naviguant dans la base et rpondant aux requtes sui-
vantes :
Q1 : Nom du pre nol qui vous a visit et prix total des jouets que vous avez reus
Nol (on suppose que vous tes un enfant).
Q2 : Distance parcourue par le pre nol Georges Gardarin et liste des jouets distri-
bus.
U1 : Mettre jour la base par enregistrement dune nouvelle tourne pour un pre
nol donn.
M# Nom ...
Ingnieur Suivi
Date Pice
Rle
...
P# Des. ...
Question 1
Proposez une reprsentation objet de ce schma en utilisant UML. Discutez les pro-
prits de votre reprsentation. Donnez la dfinition en ODL correspondante.
Question 2
crire les mthodes ncessaires pour faire une affectation dune pice un modle
davion avec lindication de la liste des ingnieurs chargs du suivi. Les mthodes
seront crites en Smalltalk, C++ ou Java persistant (ODMG) ou en pseudo-code pour
ceux qui ne sont pas laise avec les concepts de lun de ces langages objet. Attention
lencapsulation.
Question 3
Certaines pices sont en fait des modules composs dautres pices ou dautres
modules. Proposez une modification du schma pour Pice.
Question 4
crire une mthode qui donne la liste de tous les ingnieurs impliqus dans le suivi
dun module, soit directement soit au titre dun composant. On pourra utiliser la
mthode prdfinie union de la classe gnrique Set qui prend un autre Set en
paramtre.
760 BASES DE DONNES : OBJET ET RELATIONNEL
Question 1
Rappelez les extensions ncessaires lalgbre relationnelle pour exprimer les
requtes objets. Proposez des exemples gnriques de requtes illustrant chaque
extension.
Question 2
Soit une succession de classes T1, T2, ...Tn relies par des associations [M-N] via des
attributs de rle nomms A, B, ...X, comme reprsent ci-dessous :
* * * * * *
C1 C2 C3 * ... Cn1 Cn
A B C X
Cette base reprsente des objets RGIONS ayant un identifiant utilisateur (ID), un
pays (PAYS), un nom (NOM) une population et une carte gomtrique. Les objets
VILLES dcrivent les grandes villes de ces rgions et sont positionns sur la carte par
une gomtrie. Les forts (FORETS) ont un identifiant utilisateur, un nom et une go-
mtrie. Les routes (ROUTES) sont reprsentes comme des relations entre villes ori-
gine et extrmit ; elles ont une gomtrie.
Une gomtrie peut tre un ensemble de points reprsents dans le plan, un ensemble
de lignes reprsentes comme une liste de points ou un ensemble de surfaces, chaque
surface tant reprsente comme un ensemble de lignes (en principe fermes). Sur le
type GEOMETRIE, les mthodes Longueur, Surface, Union, Intersection et DRAW
(pour dessiner) sont dfinies.
Question 1
Proposez une dfinition du schma de la base en ODL.
Question 2
Exprimer les questions suivantes en OQL:
Q1. Slectionner les noms, pays, populations et surfaces des rgions de plus de
10 000 km2 et de moins de 50 000 habitants.
Q2. Dessiner les cartes des rgions traverses par la RN7.
Q3. Donnez le nom des rgions, dessiner rgions et forts pour toutes les rgions
traverses par une route dorigine PARIS et dextrmit NICE.
Question 3
Rappelez les oprations dune algbre dobjets complexes permettant dimplmenter
le langage OQL. Donnez les arbres algbriques correspondants aux questions Q1, Q2
et Q3.
Question 1
Proposez un schma UML pour cette base de donnes. On ajoutera les mthodes
appropries pour illustrer. On supprimera tous les pointeurs cachs (cls de jointures)
qui seront remplacs par des associations. Dfinir ce schma directement en SQL3, en
utilisant des rfrences et des collections imbriques.
Exercices 763
Question 2
Exprimer en SQL3 les questions (a), (b), (c) et (d).
Question 3
Comparer limplmentation objet-relationnelle avec une implmentation directe en
relationnel.
Question 4
Reprendre les questions 1, 2 et 3 en utilisant ODL et OQL la place de SQL3.
Comparer les solutions.
Question 1
Dfinir cette base en ODL puis en SQL3.
Question 2
Exprimer les requtes suivantes en OQL puis SQL3 :
Q1 : Nom du pre nol qui vous a visit et prix total des jouets que vous avez reu
Nol (on suppose que vous tes un enfant).
Q2 : Distance parcourue par le pre Nol Georges Gardarin et liste des jouets distri-
bus.
Question 3
Pour chacune des questions prcdentes, proposez un arbre algbrique optimis per-
mettant de lexcuter.
Question 4
Rappelez la dfinition dun index de chemin. Proposez deux index de chemins per-
mettant dacclrer lexcution des questions Q1 et Q2.
764 BASES DE DONNES : OBJET ET RELATIONNEL
Compagnies
numro
nom
employs Personnes
nss
nom
vhicules Voitures
date_nais nveh
* age() marque
couleur
Question 1
Exprimer en OQL les questions suivantes:
Q1: ensemble des numros de scurit sociale et noms de personnes ges de plus
de 40 ans possdant au moins un vhicule de couleur rouge.
Q2: liste des noms de compagnies employant des personnes de plus de 40 ans pos-
sdant une voiture rouge.
Question 2
Donnez un arbre doprations dalgbre dobjets complexes optimis par heuristique
simple permettant dexcuter la question Q2.
Question 3
La jointure de deux classes C1 et C2, telles que Personnes et Voitures relies par une
association oriente multivalue du type A>>C1 peut tre ralise par un algo-
rithme de parcours de pointeurs ou de jointure sur comparaison didentifiant clas-
Exercices 765
sique. Nous les appellerons jointure avant JV (par pointeur) et jointure arrire
JR (par valeur). Dtailler ces deux algorithmes en pseudo-code.
Question 4
On constate que la jointure de N classes relies par des associations peut tre ralise
par un seul oprateur de jointure n-aire, traversant le graphe en profondeur dabord,
appel ici DFF. Dtailler cet algorithme en pseudo-code.
Question 5
En dnotant page(Ci) et objet(Ci) le nombre respectif de pages et dobjets dune
classe Ci, par fan(Ci,Cj) le nombre moyen de pointeurs par objet de Ci vers Cj, en
supposant un placement squentiel sans index des objets, calculez le cot de chacun
des algorithmes JR, JV et DFF. On pourra introduire dautres paramtres si ncessaire.
PRE et MRE sont des cls trangres sur la relation PERSONNE elle-mme, ce
sont donc des numros de personne. Cette relation permet donc de reprsenter un
arbre gnalogique complet.
Question 1
Donnez larbre algbrique correspondant la requte : Quels sont les enfants de M.
Martin, de numro 152487.
Question 2
Donnez larbre algbrique correspondant la requte : Quels sont les petits enfants de
M. Martin, de numro 152487.
Question 3
Donnez larbre algbrique tendu correspondant la requte : Quels sont les descen-
dants de M. Martin, de numro 152487.
Pour cette dernire question on tendra les arbres algbriques de la faon suivante :
Un nud supplmentaire de test permettra de spcifier un branchement condition-
nel ;
766 BASES DE DONNES : OBJET ET RELATIONNEL
Question 1
Donnez une expression relationnelle quivalente ce programme pour le calcul des
faits instances des prdicats p1(X,X) et p2(X,Y).
Question 2
Donnez les faits instancis de symbole de prdicat p1 dduits de ce programme et de
la base de donnes.
PARTIE 2
Soit le programme DATALOG :
anc(X,Y) par(X,Y)
anc(X,Y) anc(X,Z), par(Z,Y)
la base de donnes :
par(baptiste,lon), par(lon,lucie), par(janine,lon), par(tienne,clo),
par(lucie,clo), par(baptiste,pierre), par(janine,pierre), par(pierre,bernard),
par(bernard,nicolas), par(bernard,lucien), par(bernard,nomie), par(lucien,ric).
Exercices 767
et la requte :
? anc(bernard,Y)
Question 1
Calculez les rponses cette requte en appliquant la mthode nave. Donnez les faits
dduits chaque itration.
Question 2
Mme question avec la mthode semi-nave.
Question 3
crire le programme modifi obtenu par la mthode des ensembles magiques.
valuez ce programme modifi sur la base, en montrant chaque itration les faits
dduits, et en prcisant pour chaque fait dduit, par quelle rgle il a t dduit.
Question 1
crire un programme DATALOG calculant la relation :
DIRIGE(NSSC, NSSD)
donnant quel employ dirige directement ou indirectement quel autre employ (le
numro de scurit sociale NSSC dirige le numro de scurit sociale NSSD), ceci
pour tous les employs.
Question 2
Transformer le programme DATALOG obtenu la question 1 en appliquant la
mthode des ensembles magiques pour trouver les employs dirigs par Toto.
Question 3
Modifier le programme trouv la question 1 pour calculer la relation
DIRIGE(NSSC, NSSD, NIVEAU)
768 BASES DE DONNES : OBJET ET RELATIONNEL
NIVEAU est le niveau hirarchique du chef (1 chef direct, 2 chef du chef direct, etc.).
Dans quel cas ce programme a-t-il un modle infini ?
Question 4
Donnez le graphe Rgle-But et le graphe doprateurs relationnels correspondant la
question ? DIRIGE(Toto, x, 2) pour le programme trouv en 3.
Question 5
crire en DATALOG avec ensemble la question permettant de calculer la table
STATISTIQUE (NSER, CHEF, SALMAX, SALMIN, SALMOY)
donnant pour chaque service, le nom du chef, le salaire maximum, le salaire minimum
et le salaire moyen, ceci pour tous les services dont le salaire minimum dpasse
7 000 F.
Question 1
En utilisant les ensembles magiques, donnez le programme de rgles transformes
permettant de calculer la rponse cette question.
Question 2
Simplifier le programme obtenu par limination des rgles redondantes. Peut-on pro-
poser une mthode gnrale permettant dviter de transformer des rgles
redondantes ?
Exercices 769
Une gomtrie peut tre un ensemble de points reprsents dans le plan, un ensemble
de lignes reprsentes comme une liste de points ou un ensemble de surfaces, chaque
surface tant reprsente comme un ensemble de lignes (en principe fermes). Sur le
type GEOMETRIE, les mthodes LONG, UNION, INTERSECTION et DRAW (pour
dessiner) sont dfinies. LONG est suppose calculer la longueur dune gomtrie en
km.
Question 1
Donnez un programme DATALOG avec fonctions (utiliser en particulier les fonctions
OID et DRAW) permettant de gnrer et tracer tous les parcours allant de la ville de
nom A la ville de nom B en parcourant moins de K km.
Discutez de loptimisation de ce programme.
Question 2
On dsire calculer le cot dun billet de train. Le cot est proportionnel au nombre de
km parcourus. Il existe des billets normaux, des billets rduits, des billets T.G.V., et
des billets T.G.V. rduits. La majoration sur les lignes T.G.V. est un cot de rserva-
tion initial plus un cot proportionnel la longueur du trajet. La rduction est un pour-
centage du prix appliqu au seul cot proportionnel la distance parcourue. Proposez
une organisation en classes et sous-classes pour les billets de train. Programmer en
pseudo C++ une mthode TARIF qui calcule le prix de chaque billet. On prcise quil
est possible dappeler une mthode dune classe (qui peut tre une super-classe) par la
syntaxe classe::mthode ().
Question 3
Proposez une intgration de la mthode TARIF dans le programme ralis la ques-
tion 1 afin de calculer le prix de chaque itinraire de moins de x km permettant daller
de A B et de choisir le moins coteux.
770 BASES DE DONNES : OBJET ET RELATIONNEL
Question 1
Dessiner le graphe de prcdence. Que peut-on en conclure ?
Question 2
On suppose que les demandes se font dans lordre global suivant :
E2(A) L2(B) L6(D) E5(C) E3(A) L5(A) L1(C) L2(D) L3(C) E4(C) E3(D)
L4(B) L1(B)
Question 3
On rappelle que pour lalgorithme destampillage multiversion, les accs doivent tre
effectus dans lordre des estampilles des transactions, sauf les lectures qui peuvent se
produire en retard. Une lecture en retard obtient la version quelle aurait d lire si elle
tait arrive son tour. Les critures en retard provoquent par contre un abandon de
transaction.
Toujours avec lordre des accs de Q2, que se passe-t-il en estampillage multiver-
sion ?
Question 4
Pour grer le multiversion on suppose que lon dispose dune table en mmoire pouvant
contenir 100 000 versions avec les estampilles correspondantes (pour lensemble des gra-
nules). De plus on conserve sur disque la dernire version produite de chaque granule.
On se propose de modifier lalgorithme destampillage multiversion de la faon sui-
vante : chaque nouvelle version dun granule mis jour est crite sur disque tandis
que la version prcdente est recopie dans la table en mmoire. Cette table est gre
comme une file circulaire : chaque nouvelle version entre chasse la version la plus
ancienne (tous granules confondus). Lors dune lecture on recherche dans la table (ou
Exercices 771
sur disque) la version ncessaire si elle est disponible. Une lecture peut donc chouer
et conduire un abandon.
Donnez en pseudo-code les algorithmes LIRE et CRIRE correspondants.
Les actions de base indivisibles pour le contrle de concurrence tudier sont les op-
rations sur objets, cest--dire + et * sur lexemple.
On considre trois transactions travaillant sur des rels nomms A et B :
T1: { A+1 -> A; B+1 -> B }
T2: { A+2 -> A: B+2 -> B}
T3: { A*3 -> A: B*3 -> B}
Question 1
Donnez un exemple dexcution simultane des transactions T1 et T3 non srialisable.
Tracer le graphe de prcdence associ.
Question 2
Montrer que la commutativit de lopration daddition garantie la correction de toute
excution simultane de T1 et T2.
Question 3
La commutativit des oprations permet donc daccepter des excutions simultanes
non priori srialisable. On se propose de munir chaque classe persistante dun
contrleur de concurrence utilisant une matrice de commutativit des oprations et un
vecteur doprations en cours par transaction.
Dfinir les primitives ncessaires un tel contrle de concurrence.
Prciser les algorithmes sous-jacents.
772 BASES DE DONNES : OBJET ET RELATIONNEL
Question 1
Que fait ce programme ? Prcisez le dbut et la fin de la (des) transaction(s).
Question 2
Que se passe-t-il si on supprime linstruction exec sql commit ?
Question 3
Prcisez les effets du rollback.
Exercices 773
Question 4
On lance plusieurs instances simultanes du programme prcdent. Une transaction ne
peut pas lire (et encore moins modifier) les donnes mises jour par une transaction
non valide. Pourquoi ?
Prcisez les complications des procdures de reprise quimpliqueraient la leve de
cette limitation, cest--dire le non respect de la proprit disolation des mises jour.
Agences Comptes
Numro * Numro
Ville IdClient
Avoir Avoir
*
Caissiers Comptes
Numro Numro
Ville IdClient
Avoir Avoir
Lobjectif de ltude est dtudier la rsistance aux pannes dans un contexte centralis
puis rparti sur une telle base de donnes implmente en relationnel.
Question 1
Donnez le schma relationnel de la base. crire le code de la transaction dbit/crdit
sous la forme de requtes SQL.
Question 2
Le systme dmarre aprs un point de reprise et excute quatre instances de la tran-
saction dbit/crdit notes T1, T2, T3, T4. T1 crdite 1 000 F sur votre compte avec
774 BASES DE DONNES : OBJET ET RELATIONNEL
succs. T2 tente de crditer 2 000 F mais choue, T3 crdite 3 000 F avec succs et T4
dbite 4 000 F avec succs. Donnez le format du journal (images aprs et avant
comme dans ARIES) aprs excution de ces quatre transactions.
Ce journal est gr en mmoire. Quand est-il crit sur disque ?
Question 3
Le systme tombe en panne aprs validation (commit) de T4. Que se passe-t-il lors de
la procdure de reprise ?
Question 4
Chaque agence bancaire possde un serveur grant sa base de donnes. crire le code
dune transaction sexcutant depuis un client C et effectuant le transfert de m francs
depuis un compte dune agence A sur le compte dune agence B. Prciser les mes-
sages changs entre client et serveurs dans le cas dexcution avec succs dune telle
transaction, puis dans le cas o le site A ne rpond plus lors de la premire phase du
commit.
Question 5
Le site client lance la transaction de transfert qui est bien excute sur A et B.
Malheureusement, le site client se bloque juste avant lenvoi de la demande de valida-
tion (COMMIT). Prciser ltat du systme (messages changer et journaux). Que se
passe-t-il alors ?
Afin de sortir des situations de blocage, proposez une extension au protocole de vali-
dation deux phases en ajoutant une phase et en introduisant un tat intermdiaire
basculant automatiquement en chec de la transaction aprs un dlai dattente.
Question 1
crire la commande permettant de transmettre les droits de lecture et insertion sur la
relation VINS lusager FANTOMAS, en lui garantissant le droit de transmettre ces
droits.
Exercices 775
Question 2
Afin de rendre plus souple lattribution de droits, on introduit la notion de rle.
Prcisez les commandes ncessaires la gestion des rles.
Question 3
Les droits donns aux usagers sont mmoriss dans une relation DROITS. Proposez
un schma pour la relation DROITS.
Question 4
Dcrivez en quelques lignes ou par un organigramme les principes des algorithmes
daccord de droit (GRANT), de suppression de droits (REVOKE) et de vrification dun
droit.
Question 1
Proposez une couverture minimale DF pour DF.
Question 2
Dessiner le graphe des dpendances fonctionnelles.
Question 3
Proposez une dcomposition en troisime forme normale pour R.
PARTIE 2
Soit la liste suivante de donnes lmentaires utilises pour construire une base de
donnes Commandes :
776 BASES DE DONNES : OBJET ET RELATIONNEL
On suppose que lon commence par former une unique relation Commandes avec les
donnes prcdentes pour attributs.
Question 1
Proposez une liste de dpendances fonctionnelles entre ces attributs en respectant les
hypothses.
Question 2
Dessiner le graphe des dpendances fonctionnelles en utilisant des arcs en traits pleins
pour la couverture minimale et des arcs en pointill pour ceux qui peuvent se dduire
par transitivit.
Question 3 :
Proposez une dcomposition en troisime forme normale de la relation.
Exercices 777
On prcise que:
1. Il nexiste pas deux stations de mme nom (NOMS)
2. Une rgion appartient un pays unique.
3. ALTITUDE et HAUTEUR_NEIGE sont dtermins par le nom de station NOMS.
4. Deux pistes de stations diffrentes peuvent avoir le mme nom.
5. Une piste dans une station possde une longueur et une dnivele unique.
6. La position dune bosse la dtermine de manire unique sur une piste donne.
Question 1
En considrant chaque classe, donnez le graphe des dpendances fonctionnelles entre
attributs. Ajouter au graphe des arcs reprsentant les dpendances hirarchiques de 1
vers N reprsents par des arcs tte multiple (du style ->>). Complter ce graphe
par les dpendances interclasses fonctionnelles ou hirarchiques.
Question 2
partir du graphe prcdent, dduire un schma relationnel en 3e forme normale per-
mettant de reprsenter la base de donnes objet initiale.
Question 3
Prciser les contraintes dunicit de cl du schma relationnel. Spcifier ensuite les
contraintes rfrentielles permettant dimposer lexistence dune station pour insrer
une piste puis lexistence dune piste pour insrer une bosse.
778 BASES DE DONNES : OBJET ET RELATIONNEL
Question 4
Proposez un langage de dfinition de contraintes permettant dexprimer les mmes
contraintes dans le monde objet. Illustrez sur la base objet initiale.
Question 1
Donnez la liste des dpendances fonctionnelles non triviales entre donnes lmen-
taires sous la forme dun graphe. Sassurer quil ne reste aucune dpendance fonction-
nelle qui puisse se dduire des autres par transitivit (les enlever sil en reste).
Question 2
Proposez un schma normalis en 3FN pour la base DGUSTATION partir de
lensemble des dpendances fonctionnelles et laide de lalgorithme vu en cours.
Question 3
Exprimez en SQL les requtes suivantes sur le schma propos :
a) Quels sont les vins de 1991 de la rgion du Pimont (en Italie) qui ont reu au
moins une note suprieure 17 lors de la dgustation du 14/05/1994 ?
b)Quelle est la note moyenne dcerne tous vins confondus par chaque membre
(dgustateur) ?
c) Quels sont les crus qui nont pas reu de note infrieure 15 pour le millsime 1989 ?
d)Quels sont les dgustateurs qui ont particip tous les vnements ?
Question 4
Donnez une expression des requtes a) c) et d) en algbre relationnelle (en utilisant de
prfrence la notation graphique vue en cours).
Question 5
Proposez un schma physique pour le schma relationnel prcdent. On suppose que
lon peut placer en squentiel (avec index primaire non plaant), par des index pri-
maires plaant de type arbre B+ ou par hachage classique. Choisir un mode de place-
ment pour chaque relation en le justifiant.
780 BASES DE DONNES : OBJET ET RELATIONNEL
Question 6
Proposez les index secondaires les mieux mme dacclrer la manipulation de la
base. Indiquer les organisations dindex retenues dans chaque cas et donner les justifi-
cations des choix raliss.
TRANSPARENTS
Pour chacun des chapitres, une srie de transparents peut tre obtenue pour lensei-
gnement public en contactant le site Web du laboratoire PRiSM de luniversit de
Versailles :
www.prism.uvsq.fr/~gardarin/home.html
INDEX
A arbre dductive, 154
acteur, 448 algbrique, 306 hirarchique, 137
action, 269, 591 B, 85 logique, 154
administrateur, 30 B+, 88 blocage, 67
dapplication, 30 de segments, 136 permanent, 607
dentreprise, 30 de traitement, 306 boucles imbriques, 330
de bases de donnes, 30 de versions dobjet, 642
ET/OU, 548 C
de donnes, 16, 30
linaire droit ou gauche, cache volatile, 621
adressage ouvert, 75
335 calcul relationnel
adresse relative, 66
ramifi, 335 de domaine, 157
affinement du schma logique,
relationnel, 207 de tuples, 166
662
relationnel, 306 capture des besoins, 662
agrgat, 210 cardinalits dassociation, 665
architecture
agrgation 21, 668, 369, 670 catalogue, 68
deux strates, 47
composite, 668, 676 de base, 71
trois strates, 48
indpendante, 668, 675 hirarchis, 69
BD rpartie, 50
agrgats auto-maintenables, client-serveur, 45 certification de transaction,
295 rpartie, 50 614
algorithme article, 60, 61, 113 chanage, 75
dunification, 169 association, 21, 670 arrire, 543
gntique, 501, 503 bijective, 673 avant, 542
amlioration itrative, 343, atome, 113, 523 champ, 136
497, 498 instanci, 523 classe, 358, 670
analyseur atomicit des transactions, 37, de base, 362
de rgles, 266 588 drive, 362
de requtes, 43 attribut multivalu, 676 gnrique, 367
annotation, 302 attribut, 22, 182, 356, 663 paramtre, 367
annulation de transaction, 619 attribution de droits, 648 clause, 151
anomalies de mise jour,680 authentification, 644 de Horn, 152
aplatissage dune collection, autorisation, 646 cl, 63,136, 185
387 base de donnes, 122, 123
apparition dincohrence, 589 B candidate, 689
appel de mthodes, 572 balayage squentiel, 326 darticle, 63
approche base cohrente, 254 de relation, 689
par synthse, 683 base de donnes primaire, 100, 186, 689
relationnelle tendue, 678 active, 264, 248 prive, 650
784 BASES DE DONNES : OBJET ET RELATIONNEL
parcours de graphes, 570 problme des fantmes, 607 rfrence dobjet, 442
partage rfrentiel, 356 procdure rgion, 67
participant validation, 628 de reprise, 631 rgle, 523
partitionnement stocke, 46 champ restreint, 538
horizontal, 706 produit cartsien, 192 dinfrence de Robinson,
vertical, 706 programme 169
passage en premire forme confluent, 536 DATALOG, 523
normale, 677 stratifi, 534 de correspondance, 35
patron de collection, 441 projection, 193 de production, 535
pattern de classe, 367 dune collection, 386 ECA, 265
persistance propagation dinformations, fortement linaire, 568,
des objets, 374 561 569
manuelle, 377 protocole linaire, 524, 553, 563
par atteignabilit, 430 daccs aux donnes quadratique, 524, 554
par hritage, 377, 378 distantes, 45 rectifie, 529
par rfrence, 378, 380 de validation en deux rcursive, 524
perte tapes, 628 signe, 563
dinformations, 680 Dfaire et Refaire (Undo, rehachage, 75
de mise jour, 589 Redo), 633 relation, 182
pipeline, 308 Dfaire sans Refaire rcursive, 526
placement, 123 (Undo, No Redo), 634 universelle, 681
proximit, 123, 705 Ni Refaire Ni Dfaire reprise, 619
calcul, 123 (No Undo, No Redo),634 chaud, 632
CODASYL, 123 Refaire sans Dfaire (No froid, 634
direct, 123 Undo, Redo), 633 de transaction, 619
multi-attribut, 101 granulaire oriente page,
multi-attribut statique, Q 635
101 qualification, 32 partielle de transactions,
par homothtie, 123 de chemin, 140 635
plan dexcution, 302, 308 de question, 32 requte
planning, 308, 309 quatrime forme normale, chane, 487
plus petit modle, 528 700 dynamique, 305
point question statique, 305
de reprise systme, 625, contradictoire, 312 rseaux de Petri prdicats,
637 correcte, 312 550
de validation, 630 irrductible, 322 rsolvant, 171
polymorphisme, 366, 375, mal formule, 312 restriction, 194
465 questions quivalentes, 312 rvlation de cot, 494
post-test, 259 rle, 645, 665
pr-test, 260 R
prcdence, 596 recherche, 218 S
prdicat, 225 taboue, 497, 500 sac, 367
de comparaison, 156, 523 recuit simul, 497, 499 sagas, 640
extensionnel, 156, 520 redfinition, 366 sauvegarde, 625
intensionnel, 520 rduction de la porte des schma
relationnels, 523 ngations, 152 conceptuel, 17, 20
prmisse de rgle, 523 rcriture, 308 de BD objet, 371
prvention, 601 smantique, 310 de classes, 371
principe dencapsulation, 357 syntaxique, 310 de donnes, 16
788 BASES DE DONNES : OBJET ET RELATIONNEL