Bd-Avancees

Bases de données avancées
Jacques Le Maitre
Université du Sud Toulon-Var
Ce cours est mis à disposition selon les termes

de la licence Creative Commons
Paternité-Pas d'Utilisation Commerciale-Pas de Modification 2.0 France
Nouvelles architectures
Architecture 3/3 pour le Web
(1) Navigateur Navigateur (Clients)
présentation présentation
Serveur d’application
(2)
Serveur Web
SGBD
(3)
BD
Jacques Le Maitre Bases de données avancées 3

Entrepôt de données
Entrepôt
Intégrateur
Extracteur Extracteur
Source 1 Source 2

Médiateur
requête réponse
Médiateur
Adaptateur Adaptateur
Source 1 Source 2

Architecture pair à pair (P2P)
pair
pair
requête
pair pair
pair
réponse
pair

Du relationnel à l’objet
relationnel
Référence : Jim Melton, Advanced
SQL:1999 – Understanding Object-
Relational and Other Advanced
Features, Morgan Kaufmann
Publishers, 2003.
Sommaire
 Atouts du modèle relationnel
 Limites du modèle relationnel
 Une solution : l’approche objet
 SGBD objet purs
 Un compromis : l’objet-relationnel
 Etude de cas : PostgresQL

Atouts du modèle relationnel
 Un modèle simple pour l’utilisateur
 BD = ensemble de tables
 Un modèle formellement bien fondé
 algèbre → implantation et optimisation
 calcul → BD logique
 Une méthode de conception de schéma
 normalisation
 Un langage de manipulation de données universel
 SQL
 Un modèle de transactions sûr
 sérialisabilité et verrouillage à 2 phases
 Des SGBD commerciaux ou libres performants
 Access, DB2, Oracle, MySQL, PostgreSQL, SQL Server,
Sybase…

Limites du modèle relationnel
 Structures de données limitées :
 table → ensemble de n-uplets de valeurs
atomiques (nombres, chaînes de caractères…)
 Opérations sur les données exclues du
modèle
 Sémantique insuffisante

Exemple
 BD décrivant un ensemble de personnes.
 Chaque personne a :
 un nom,
 une liste de prénoms,
 une date de naissance,
 une adresse personnelle,
 une adresse professionnelle,
 des amis dont chacun est une personne
 Une adresse est composée d'une rue, d'une ville et d'un
code postale,
 Un ami est une personne,
 Un nom, un prénom, une rue, une ville et un code postal
sont des chaînes de caractères.
 L'âge d'une personne est égal à la date courante moins sa
date de naissance.

Une solution : l’approche objet
 Principaux concepts :
 objet
 classe
 héritage
 polymorphisme
 persistance

Sémantique de l’héritage
 Substitution
 Un étudiant est une personne car tout programme qui
s’applique à une personne peut être appliqué à un étudiant.
 Spécialisation
 Un étudiant est une personne car il a toutes les propriétés
(attributs et opérations) d’une personne plus des propriétés
spécifiques.
 Restriction
 Un adolescent est une personne dont l’âge est compris entre
12 et 18 ans.
 Inclusion
 Un étudiant est une personne car l’ensemble des étudiants de
la BD est un sous-ensemble de celui des personnes.

SGBD objets purs
 Un standard défini par l’ODMG (Object
Data Management Group) :
 ODL → langage de définition de données
 OQL → langage de requêtes à la SQL
 Des prototypes :
 GemStone, O2, ObjectStore…
 Inconvénients :
 complexes à implanter
 peu compatibles avec les SGBD relationnels

Un compromis : l’objet-relationnel
 Principe :
 on ajoute au relationnel un certain nombre des
concepts de l’approche objet,
 on conserve la notion de table et on étend
SQL.
 Une nouvelle version de SQL :
 SQL:1999 qui étend et intègre SQL 92.
 Disponible partiellement sur DB2, Oracle,
PostgreSQL, SQL Server, Sybase…

SQL:1999
 Types distincts
 Types utilisateurs (UDT)
 Tables typées
 Héritage :
 hiérarchie de types
 hiérarchie de tables
 Méthodes associées aux UDT

SQL:1999 : types distincts
CREATE TYPE taille AS INTEGER FINAL;
CREATE TYPE poids AS INTEGER FINAL;
 Les valeurs d’attributs de type taille et celles

de type poids ne sont pas comparables.
 Pour les rendre comparables, il faut les convertir
en un type commun, par exemple : integer.

SQL:1999 : types définis par l’utilisateur
(UDT)
CREATE TYPE adresse AS (
rue ROW(
nom CHARACTER VARYING(35),
type CHARACTER VARYING(35)),
ville CHARACTER VARYING(35),
cp CHARACTER(5))
NOT FINAL;
CREATE TABLE personnes AS (

adr adresse);
SELECT p.nom, p.adr.rue.nom

FROM personnes p;

SQL:1999 : tables typées
CREATE TYPE film AS (
titre CHARACTER VARYING(100),
description CHARACTER VARYING(100),
durée INTEGER)
INSTANTIABLE
NOT FINAL
REF IS SYSTEM GENERATED
INSTANCE METHOD note() RETURNS DECIMAL(2,1);
CREATE TYPE acteur AS (

role CHARACTER VARYING(100),
film REF(film))
INSTANTIABLE
NOT FINAL
REF IS SYSTEM GENERATED;

CREATE TABLE films OF film
(REF IS id_film SYSTEM GENERATED);
CREATE TABLE acteurs OF acteur

(REF IS id_acteur SYSTEM GENERATED
film WITH OPTIONS SCOPE films);
CREATE TABLE films_courts OF film

(REF IS id_film SYSTEM GENERATED
duree WITH OPTIONS
CONSTRAINT CHECK (durée < 90));

SELECT film->durée
FROM acteurs
WHERE acteur.nom = 'Audrey Tautou';
SELECT film->note()
FROM acteurs
SELECT DEREF(film)
FROM acteurs

SQL:1999 : héritage
CREATE TYPE dvd UNDER film AS (
editeur CHARACTER VARYING(35),
bonus ROW(
durée CHARACTER VARYING(35)) ARRAY[10]))
INSTANTIABLE
NOT FINAL);
CREATE TABLE dvds OF dvd

UNDER films;

Etude de cas : PostgreSQL
 Constructeurs de n-uplets et de tableaux
 Types composites définis par l’utilisateur
 Fonctions définies par l’utilisateur
 Héritage de tables
 Types géométriques
 Règles

Types composites : définition
CREATE TYPE adresse AS (
rue text,
ville text,
cp integer);
CREATE TABLE personne (

nom text PRIMARY KEY,
prenom text[],
adr_perso adresse,
adr_pro adresse);
INSERT INTO personne

VALUES ('Dupont',
ARRAY ['Jean', 'Robert'],
ROW ('rue des Amandiers', 'Toulon', 83100),
ROW ('rue des Mimosas', 'Marseille', 13009));

Types composites : accès
SELECT (adr_pro).ville
FROM personne
WHERE nom = 'Dupont';
SELECT (p.adr_pro).ville
FROM personne p
WHERE p.nom='Dupont';
SELECT nom, prenom[1]

FROM personne p WHERE (p.adr_perso).ville = 'Toulon';

Types composites : modification
UPDATE personne
SET adr_perso =
ROW ('rue des Mimosas', 'Marseille', 13009)
UPDATE personne
SET adr_pro.ville = 'Toulon',
adr_pro.cp = 83100

Fonctions : définition et appel
CREATE FUNCTION no_dept(adresse) RETURNS integer
AS 'SELECT $1.cp / 1000'
LANGUAGE SQL;
SELECT nom, no_dept((p).adr_perso)

FROM personne p;

Héritage de tables
CREATE TABLE document (
titre text,
auteur text,
annee integer);
CREATE TABLE livre (

nb_pages integer)
INHERITS (document);
CREATE TABLE dvd (

duree interval)
INHERITS (document);

Héritage de tables
INSERT INTO dvd
VALUES ('L\'equipier',
'Philippe Lioret',
2004,
'94 min');
INSERT INTO livre

VALUES ('Le lievre de Vatanen',
'Arto Paasilina',
1975,
236);

Héritage de tables
SELECT titre FROM document;
titre
--------------------
Le lievre de Vatanen
L'equipier
SELECT p.relname, titre

FROM document d, pg_class p
WHERE d.tableoid = p.oid;
relname | titre
--------+---------------------
livre | Le lievre de Vatanen
dvd | L'equipier

Types géométriques
Points (x, y)
Segments de droite ((x1, y1), (x2, y2))
Boîte ((x1, y1), (x2, y2))
Chemins ((x1, y1), ..., (xn, yn))
Polygones Chemin fermé
Cercle ((x, y), r)

CREATE TABLE figure (
nom text PRIMARY KEY);
CREATE TABLE rectangle (

representation box)
INHERITS (figure);
CREATE TABLE cercle (

representation circle)
INHERITS (figure);

INSERT INTO rectangle
VALUES ('R1', '((3, 2), (8, 5))');
INSERT INTO rectangle

VALUES ('R2', '((6, 4), (9, 6))');
C1
INSERT INTO cercle
VALUES ('C1', '<(4, 9), 2>'); R2
R1
SELECT nom FROM figure;

CREATE FUNCTION recouvre(text, text) RETURNS boolean
AS
'SELECT
(SELECT representation
FROM rectangle
WHERE nom = $1)
&&
(SELECT representation
FROM rectangle
WHERE nom = $2)'
LANGUAGE SQL;
SELECT recouvre('R1', 'R2');

CREATE FUNCTION surface(figure) RETURNS double
precision
AS '(SELECT area(c.representation)
FROM rectangle c
WHERE c.nom = $1.nom)
UNION
(SELECT area(c.representation)
FROM cercle c
WHERE c.nom = $1.nom)'
LANGUAGE SQL;
SELECT nom, surface(f)

FROM figure f;

Règles
CREATE TABLE societe (
sigle text)
CREATE TABLE employe (

nom_societe text REFERENCES societe(nom),
salaire float)
CREATE TABLE localisation (

nom_societe text REFERENCES societe (nom),
pays text)

Règles
CREATE VIEW emp_soc_australienne(
nom, sigle_societe, salaire) AS
SELECT e.nom, s.sigle, e.salaire
FROM employe e, societe s, localisation l
WHERE e.nom_societe = s.nom
AND s.nom = l.nom_societe
AND l.pays = 'Australie';
CREATE RULE my_rule AS

ON UPDATE TO emp_soc_australienne
DO INSTEAD
UPDATE employe
SET salaire = NEW.salaire
WHERE nom = NEW.nom;
UPDATE emp_soc_australienne
SET salaire = 2 * salaire;

Concurrence
Concept de transaction
 Une transaction est un fragment de programme
dont l’exécution fait passer une BD d’un état
cohérent à un autre état cohérent.
 Une transaction est une suite d’événements
dont chacun peut être :
 la lecture ou l’écriture d’une donnée,
 le verrouillage ou le déverrouillage d’une donnée,
 le démarrage ou l’arrêt de la transaction.
 Une donnée est un fragment d’une BD :
 une valeur d’attribut, un n-uplet, une table…

Evénements
événement signification
start démarrage de la transaction
read D lecture d’une donnée D
write D modification d’une donnée D
rollback annulation de la transaction
commit confirmation de la transaction

Exemple de transaction
T
start
read A
A = A - S
write A
read A
B = B + S
write B
commit

Propriétés d’une transaction
 Atomicité
 Soit toutes les modifications effectuées par une transaction sont enregistrées
dans la BD, soit aucune ne l’est.
 Si une transaction est confirmée (commit) toutes les modifications qu’elle a
effectuées sont enregistrées dans la BD et rendues visibles aux autres
utilisateurs.
 Si une transaction est interrompue alors aucune de ces modifications n’est
enregistrée dans la BD.
 Cohérence
 Une transaction fait passer une BD d’un état cohérent à un autre état cohérent.
 Un état cohérent est un état dans lequel les contraintes d’intégrité sont vérifiées.
 Isolation
 Une transaction se déroule sans être perturbée par les transactions
concurrentes :
 tout se passe comme si elle se déroulait seule.
 Durabilité
 Une fois qu’une transaction a été confirmée le SGBD garantit qu’aucune
modification qu’elle a effectuée ne sera perdue quelque soient les accidents qui
surviendront : interruption, pannes du système d’exploitation, « crash » de
disque, etc.

Problèmes dus à la concurrence
 perte de mise à jour,
 lecture impropre :
 lecture de données incohérentes,
 lecture de données non confirmées,
 lecture non reproductible,
 objets fantômes.

Perte de mise a jour
T1 T2 BD
A = 10
read A
read A
A = A + 10
write A A = 20
A = A + 50
write A A = 60

Lecture impropre
(données incohérentes)
T1 T2 BD
A + B = 200
A = 120
B = 80
read A
A = A - 50
write A A = 70
read A
read B
display A + B
(150 est affiché)
read B
B = B + 50
write B B = 130

Lecture impropre
(données non confirmées)
T1 T2 BD
A = 50
A = 70
write A A= 70
read A
(70 est lu)
rollback A = 50
(La valeur initiale de A est
restaurée)

Lecture non reproductible
T1 T2 BD
A = 10
read A
(10 est lu)
A = 20
write A A = 20
read A
(20 est lu)

Exécution sérialisable
 Le principe sur lequel repose le contrôle de
concurrence est celui de la sérialisabilité de
l’exécution d’un ensemble de transactions.
 En effet, lorsque les transactions sont exécutées
les unes après les autres, il n’y a pas de
problèmes de concurrence.
 Malheureusement, cette solution est inapplicable
car très coûteuse en temps calcul.
 La solution adoptée consiste à exécuter un
ensemble de transactions concurrentes de façon
à ce que le résultat soit équivalent à une
exécution en série de ces transactions :
 une telle exécution est dite sérialisable.

Définition de la sérialisabilité
 L’exécution d’un ensemble de transactions est
dite en série si, pour tout couple de
transactions, tous les événements de l’une
précèdent tous les événements de l’autre.
 Deux exécutions d’un même ensemble de
transactions sont équivalentes si et seulement
si :
 elles sont constituées des mêmes événements,
 elles produisent le même état final de la BD et les
mêmes résultats pour les transactions :
 les lectures produisent les mêmes résultats,
 les écritures sont réalisées dans le même ordre.
 Une exécution concurrente d’un ensemble de
transactions est dite sérialisable si et seulement
si il existe une exécution en série équivalente.
Condition de sérialisabilité
 Deux opérations sont dites conflictuelles si elles
appartiennent à deux transactions différentes et
si elles ne sont pas permutables.
 Deux opérations appartenant à deux transactions
différentes sont conflictuelles si et seulement si
elles portent sur la même donnée et que l’une
des deux au moins est une opération d’écriture.
 Une exécution concurrente est sérialisable si elle
peut être transformée en une exécution en série
équivalente par une suite de permutations
d’opérations non conflictuelles.

Exemple d’exécution sérialisable
T1 T2 T1 T2
read A read A
write A write A
read A read B
read B write B
write A read A
write B write A
read B read B
write B write B
r1(A) w1(A) r2(A) r1(B) w2(A) w1(B) r2(B) w2(B) r1(A) w1(A) r1(B) w1(B) r2(A) w2(A) r2(B) w2(B)

Test de sérialisabilité
 Un graphe de précédence pour une
exécution d’un ensemble de transactions S
est un graphe orienté dans lequel :
 les nœuds représentent les transactions de S,
 il existe une arête d’un nœud T1 vers un nœud
T2 s’il existe dans S une opération op1 de T1 en
conflit avec une opération op2 de T2 et que op1
apparaît avant op2.
 Une exécution dont le graphe de
précédence ne comporte pas de cycle
est sérialisable.
Test de sérialisabilité
r2(A) r1(B) w2(A) r3(A) w1(B) w3(A) r2(B) w2(B)
T1 T2 T3
Cette exécution est sérialisable !
r2(A) r1(B) w2(A) r2(B) r3(A) w1(B) w3(A) w2(B)
T1 T2 T3
Cette exécution n’est pas sérialisable !

Verrouillage
 C’est la technique la plus classique pour éviter les
problèmes dus à la concurrence :
 chaque transaction verrouille les données qu’elle lit ou
écrit pour interdire aux autres transactions d’y accéder.
 Le verrouillage dégrade les performances d’un
SGBD en imposant des temps d’attente :
 il y a donc intérêt à limiter la taille des données à
verrouiller, d’où le concept de granularité de
verrouillage.
 On peut encore améliorer les performances en
précisant la nature des opérations pour lesquelles
le verrouillage est réalisé (lecture ou écriture par
exemple) :
 cela conduit à la définition de modes de verrouillage.

Granularité
 On peut verrouiller :
 une valeur d’attribut,
 un n-uplet et donc toutes ses valeurs,
 une page de fichier et donc tous ses n-uplets,
 une table et donc toutes ses lignes,
 la BD et donc toutes ses tables.

Modes de verrouillage
 Deux modes sont toujours définis :
 partagé (S) : demandé avant de lire une donnée,
 exclusif (X) : demandé avant de modifier une donnée.
 Les règles qui régissent ces deux modes sont les
suivantes :
 Un verrou partagé ne peut être obtenu sur une donnée
que si les verrous déjà placés sur cette donnée sont eux
même partagés.
 Un verrou exclusif ne peut être obtenu sur une donnée
que si aucun verrou n’est déjà placé sur cette donnée.

Matrice de compatibilité
MC S X
S oui non
X non non

Opérations de verrouillage
Opération Signification
lock m D demande d’un verrou en
mode m sur la donnée D
unlock D déverrouillage d’une
donnée D

Verrouillage à deux phases
 Une transaction est bien formée si :
 elle obtient un verrou sur une donnée avant de lire ou d’écrire cette
donnée,
 elle libère tous ses verrous avant de se terminer.
 Une transaction est à deux phases si elle est bien formée et si
après avoir libéré un verrou elle n’en acquiert plus :
 On distingue donc :
 une phase d’acquisition des verrous,
 une phase de libération des verrous.
 Le protocole habituel consiste à lever les verrous lors de la
confirmation de la transaction (commit).
 Il est démontré que l’exécution d’un ensemble de transactions à
deux phases est sérialisable.
 En conséquence il ne peut y avoir ni pertes de mise à jour, ni lectures
impropres, ni lectures non reproductibles.
 L’ordre de sérialisation est celui des instants d’acquisition du
dernier verrou.

Plus de perte de mise à jour
T1 T2 BD
A = 10
lock X A
read A
lock X A
A = A + attente
10
write A attente A = 20
unlock A attente
read A
A = A + 50
write A A = 70
unlock A

Plus de lecture non reproductible
T1 T2 BD
A = 10
lock S A
read A
(10 est
lu)
lock X A
attente read A
(10 est
lu)
attente unlock A
A = 20
write A A = 20

Interblocage
T1 T2 B(S) T
lock X A 2
lock X B
lock S B
A(S)
attente lock S A T
attente attente 1

Résolution de l’interblocage
 Prévention
 On évite les verrous mortels :
 en accordant à une transaction tous les verrous dont elle a
besoin avant son démarrage,
 ou bien en fixant un ordre sur les données et en imposant
aux transactions de respecter cet ordre dans leur
demandes de verrous.
 Détection
 On laisse les situations d’interblocage se produire et l’on
inspecte à intervalles réguliers le graphe d’attente pour
détecter si un interblocage s’est produit.
 Dans ce cas on défait l’une des transactions bloquées et
on la relance un peu plus tard.

Verrouillage à granularité multiple
 Les objets manipulés par un SGBD peuvent être
de granularité variable : BD, table, n-uplet, etc.
 Selon les opérations à réaliser, il peut être
nécessaire de spécifier le niveau de granularité
des objets à verrouiller.
 Par exemple, une requête qui calcule la moyenne
des âges d’un ensemble de personnes, doit
pouvoir verrouiller cet ensemble en écriture,
durant le temps de ce calcul.
 Ceci est possible grâce au protocole de
verrouillage intentionnel qui permet de placer
des verrous sur des objets de granularité variable
imbriqués hiérarchiquement

Hiérarchie de granularité
BD
table
bloc
ligne

Modes de verrouillage intensionnels
 Trois modes de verrouillage sont rajoutés :
 IS
 intention partagée, qui est demandée sur un objet O par
une transaction qui souhaite lire certains des sous-objets
de O.
 IX
 intention exclusive, qui est demandée sur un objet O par
une transaction qui souhaite modifier des sous-objets de O.
 SIX
 intention partagée exclusive, qui est demandée sur un
objet O par une transaction qui pour mettre à jour certains
sous-objets de O, a besoin de lire préalablement les objets
de O.

Règles de verrouillage intensionnel
 Pour placer un verrou en mode S ou X sur un
objet o, il faut se placer sur la racine de la
hiérarchie.
 Si l’objet sur lequel on se trouve est l’objet o,
alors on place le verrou et on arrête le processus.
 Si l’objet O sur lequel on se trouve contient
l’objet o à verrouiller, alors on place sur O un
verrou :
 en mode IS, si o est à verrouiller en mode S,
 en mode IX ou SIX, si l’objet o est à verrouiller en mode
X.

MC IS IX SIX S X
IS oui oui oui oui non
IX oui oui non non non
SIX oui non non non non
S oui non non oui non
X non non non non non

Justification
 Soit un objet o contenu dans un objet O.
 Si une transaction veut lire o alors elle doit empêcher
toute modification de O dans sa totalité.
 Pour lire o, elle le verrouille en mode S, ce qui implique de
verrouiller O en mode IS, ce qui interdira à une autre
transaction de verrouiller O en mode X et donc de modifier
O dans sa totalité.
 Si une transaction veut modifier o alors elle doit
empêcher toute lecture ou modification de O dans sa
totalité.
 Pour modifier o, elle le verrouille en mode X, ce qui
implique de verrouiller O en mode IX, ce qui interdira à une
autre transaction de verrouiller O en mode S ou X et donc
de lire ou de modifier O dans sa totalité.

Justification (suite)
 Le verrouillage en mode IX (resp. IS) de O par
une transaction T2 est accepté même s’il a déjà
été verrouillé en mode IS (resp. IX) par une
transaction T1 car il se peut que le sous-
ensemble des objets de O lus (resp. modifiés)
par T1 soit disjoint du sous-ensemble des
objets de O modifiés (resp. lus) par T2. Dans le
cas contraire, le verrouillage des objets
communs en mode S ou X empêcherait le
conflit.

Verrouillage en mode SIX
 Soit la relation :
 livre(isbn, titre, catégorie, prix)
et la transaction T :
 UPDATE livre
SET prix := 1.25 * prix
WHERE catégorie = 'roman';
 Pour réaliser cette mise à jour, la transaction T doit demander un
accès exclusif à la table livre pour empêcher toute modification
de cette table durant l’opération de mise à jour.
 Si T verrouille la table livre en mode exclusif alors elle ne pourra
pas lire les n-uplets de livre pour sélectionner ceux qui doivent
être mis à jour.
 Par contre, si T verrouille la table livre en mode SIX (accès
partagé exclusif), alors elle et elle seule pourra verrouiller les
lignes de cette table en mode S pour les lire afin de sélectionner
ceux qui sont des romans, qui eux seront verrouillés en mode X
afin d’être modifiés.

Objets fantômes : le problème
T1 T2
SELECT COUNT(*) INSERT INTO livre
FROM livre VALUES ("Les BD", 2003);
WHERE annee = 2003;
(réponse n)
SELECT COUNT(*)
FROM livre
WHERE annee = 2003;
(réponse n + 1)

Objets fantômes : une solution
T1 T2
LOCK IS livre LOCK X livres
SELECT COUNT(*) attente
FROM livre l attente
(Verrouillage de l en S) attente
WHERE l.annee = 2003; attente
(réponse n) attente
SELECT COUNT(*) attente
FROM livres l INSERT INTO livres
(verrouillage de l en S) VALUES ("Les BD", 2003);
WHERE l.annee = 2003;
(réponse n)
COMMIT

Transactions en SQL
 La norme SQL :
 n’impose aucun choix sur l’implantation des
mécanismes de concurrence,
 formalise les problèmes que doivent résoudre
ces mécanismes.
 La norme spécifie :
 la connexion entre un client et un serveur,
 les niveaux d’isolation,
 la définition d’une transaction,
 les points de reprise.

Connexion et session
 Un agent est l’exécution d’un programme contenant une
ou plusieurs requêtes SQL.
 L’agent démarre l’exécution sous le contrôle d’un client.
 Pour accéder à une BD, il doit établir une connexion avec
un serveur qui peut être implanté sur une machine
différente du client.
 Le client et le serveur constituent les deux composantes
d’un environnement.
 Une session se déroule de la façon suivante :
CONNECT (démarrage de la session)
transaction 1
…
transaction n
DISCONNECT (arrêt de la session)

Transaction SQL
 Une transaction est une suite de commandes
SQL.
 Deux transactions ne peuvent pas être
imbriquées :
 il est impossible de démarrer une transaction tant que la
transaction courante n’est pas terminée.
 Une transaction est démarrée par un agent
lorsqu’il exécute une commande SQL et qu’il n’y a
pas de transactions en cours.
 Une transaction est terminée explicitement par
une commande COMMIT ou une command
ROLLBACK.
Mode d’exécution d’une transaction
 Le mode d’exécution d’une transaction est
spécifié par la commande SET TRANSACTION qui
la précède immédiatement :
 SET TRANSACTION
(mode d’accès | ISOLATION LEVEL niveau d’isolation)
 mode d’accès ::= READ ONLY | READ WRITE
 niveau d’isolation ::=
 READ UNCOMMITED | READ COMMITTED
| REPEATABLE READ | SERIALIZABLE
 Attention ! la commande SET TRANSACTION n’est
pas un début de transaction et elle ne peut pas
être utilisée si une transaction est en cours.

Niveaux d’isolation
 READ UNCOMMITED
 il n’y a pas de perte de mise à jour ;
 il peut y avoir des lectures incohérentes, des lectures non reproductibles, et des
objets fantômes ;
 les lecteurs ne sont pas bloqués p/r aux écrivains.
 READ COMMITTED
 il n’y a ni pertes de mise à jour, ni lectures incohérentes ;
 il peut y avoir des lectures non reproductibles et des objets fantômes ;
 les transactions n’ont accès qu’aux données produites par des transactions
validées.
 REPEATABLE READ
 il n’y a ni pertes de mise à jour, ni lectures incohérentes, ni lecture non
reproductibles,
 il peut y avoir des objets fantômes ;
 une transaction qui lit plusieurs fois la même donnée lit toujours la même valeur.
 SERIALIZABLE (par défaut)
 il n’y a ni pertes de mise à jour, ni lectures incohérentes, ni lecture non
reproductibles, ni objets fantômes,
 l’isolation est totale, la visibilité de la BD est équivalente à un cliché réalisé au
début de la transaction.

Une mise en place des niveaux
d’isolation (1)
 Nous montrons comment un niveau d’isolation
peut être mis en place pour une transaction SQL,
à l’aide de 2 types de verrous :
 des verrous de longue durée qui peuvent être
demandés pour la lecture ou l’écriture d’un n-uplet ou
d’une table et qui ne sont libérés qu’après la
confirmation de la transaction,
 des verrous de courte durée qui sont demandés pour
la lecture d’un n-uplet et libérés après la lecture de
celui-ci.
 Soit T la transaction considérée.

d’isolation (2)
 READ UNCOMMITED
 On autorise T à lire un n-uplet sans demande préalable de
verrou.
 T peut donc lire une donnée verrouillée en écriture par une
autre transaction et donc effectuer une lecture impropre.
 READ COMMITTED
 On impose à T d’obtenir un verrou de courte durée sur un
n-uplet avant de pouvoir le lire.
 Ce verrou ne pourra pas être obtenu si une autre transaction
T’ possède un verrou en écriture sur ce n-uplet, et puisque T’
ne libérera ce verrou que lors de sa confirmation (les verrous
en écriture sont de longue durée), T ne pourra pas donc pas
lire un n-uplet non confirmé.
 Par contre, une autre transaction pourra modifier un n-uplet
entre deux lectures de celui-ci par T : les lectures de ce
n-uplet par T pourront donc ne pas être reproductibles.

d’isolation (3)
 REPEATABLE READ
 On impose à T d’obtenir un verrou de longue durée sur un
n-uplet avant de pouvoir le lire.
 Aucune autre transaction ne pourra donc modifier ce n-uplet
avant que T soit confirmée.
 Les lectures de ce n-uplet par T seront donc reproductibles.
 SERIALIZABLE
 On impose à T d’obtenir un verrou en lecture de longue durée
sur chaque table lue et donc sur chaque n-uplet de cette table.
 Aucune autre transaction ne pourra donc insérer un n-uplet
dans une de ces tables car cette opération est une opération
d’écriture de cette table et est donc interdite si un verrou en
lecture est déjà placé sur cette table, ce qui est le cas.
 Il n’y aura donc pas de n-uplets fantômes dans les tables lues
par T.

Points de reprise
 Certaines transactions peuvent durer longtemps.
Les annuler complètement à la suite d’un
problème peut coûter cher.
 Pour cela SQL permet de poser des points de reprise afin
de permettre des annulations partielles.
 Un point de reprise est un marqueur positionné
par une transaction dans le déroulement de celle-
ci.
 Une transaction peut abandonner toutes les
actions réalisées depuis un point de reprise par
l’instruction ROLLBACK POINT n.

Points de reprise : exemple
start "voyage";
…
res = reservation_train("Toulon", "Paris");
if (res = "erreur") rollback;
savepoint 1;
…
res = reservation_train("Paris", "Londres");
if (res = "erreur") rollback point 1;
savepoint 2;
…
res = reservation_hôtel("Londres");
if (res = "erreur") rollback point 2;
savepoint 3;
…
commit

Etude de cas : PostgreSQL
 Le système de gestion de transactions est
très semblable à celui d’Oracle.
 Il a été conçu pour que les lecteurs ne
soient pas bloqués par les écrivains et que
les écrivains ne soient pas bloqués par les
lecteurs. Ceci est obtenu par le
mécanisme de contrôle de concurrence
multiversions.

Contrôle de concurrence multiversions
 Le contrôle de concurrence multiversions assure que :
 Toute demande de lecture d’une transaction est satisfaite :
 elle a accès à la valeur la plus récemment confirmée de objet.
 Une transaction T peut être confirmée s’il n’y a pas d’autre
transaction qui, à la fois :
 a été confirmée entre le début de T et le moment où elle demande
à être confirmée,
 a modifié un objet que T a aussi modifié.
Dans le cas contraire, elle est abandonnée.
 Ainsi :
 un lecteur n’est jamais en attente derrière un écrivain,
 un écrivain n’est jamais en attente derrière un lecteur.
 Inconvénient :
 la maintenance des versions multiples

Contrôle de concurrence multiversions :
exemple
 Les transactions sont numérotées par ordre chronologique.
 Une nouvelle version de chaque donnée modifiée par une transaction i
confirmée est enregistrée avec le numéro de version i.
 Soit une transaction de numéro 10 qui lit les données a, b, c, d, e, f et g.
 La valeur lue pour c est celle de sa version 8 (deux retours arrière)
 La valeur lue pour e est celle de sa version 7 (un retour arrière).
4 a
10 b
8 11 16 c
9 d
7 14 e
2 f
5 g
images avant données

Début de transaction
 Contrairement à la norme SQL,
PostgreSQL offre une commande de début
de transaction qui a la syntaxe suivante :
BEGIN [TRANSACTION]
[mode d’accès |
ISOLATION LEVEL niveau d’isolation] ;
 PostgreSQL offre les deux modes d’accès :

 READ ONLY,
 READ WRITE (par défaut).

Niveaux d’isolation
 PostgreSQL n’offre que deux niveaux d’isolation
 READ COMMITTED (par défaut, contrairement à la norme SQL)
 SERIALIZABLE
 En conséquence, si dans la clause ISOLATION LEVEL des
commande
SET TRANSACTION ou BEGIN on spécifie :
 READ UNCOMMITED ou READ COMMITED :
 la transaction sera exécutée au niveau READ COMMITED,
 REPEATABLE READ ou SERIALIZABLE :
 la transaction sera exécutée au niveau SERIALIZABLE.
 Attention !
 Si une transaction est exécutée au niveau READ COMMITED, alors :
 seules les données confirmées avant le début d’une commande SELECT,
INSERT, UPDATE ou DELETE sont visibles dans la clause WHERE de cette
commande.
 Si une transaction est exécutée au niveau SERIALIZABLE, alors :
 seules les données confirmées avant le début de cette transaction sont
visibles dans la clause WHERE d’une commande de cette transaction.

Une table pour les exemples
T
K I
1 un
2 deux
3 trois

Niveau d’isolation READ COMMITED
T1 T2
BEGIN;
SELECT * FROM T WHERE K = 2;
 (2, ‘deux’)
BEGIN;
UPDATE T SET I = 'two' WHERE K = 2;
COMMIT;
 la mise à jour est effectuée
 (2, ‘two’)
COMMIT;
Les lectures ne sont pas reproductibles !

Niveau d’isolation READ COMMITED
T1 T2
BEGIN;
SELECT COUNT(*) FROM T;
3
BEGIN;
INSERT INTO T VALUES (4, 'quatre')
COMMIT;
 l’insertion est effectuée
4
COMMIT;
Il y a une ligne fantôme !

Niveau d’isolation SERIALIZABLE
T1 T2
BEGIN ISOLATION LEVEL SERIALIZABLE;
 (2, ‘deux’)
BEGIN;
UPDATE T SET I = 'two' WHERE K = 2;
COMMIT;
 la mise à jour est effectuée
 (2, ‘deux’)
COMMIT
Les lectures sont reproductibles !

Niveau d’isolation SERIALIZABLE
T1 T2
BEGIN ISOLATION LEVEL SERIALIZABLE;
3
BEGIN;
INSERT INTO T VALUES (4,
′quatre′)
COMMIT;
 l’insertion est effectuée SELECT COUNT(*) FROM T;
3
COMMIT
Il n’y a plus de ligne fantôme !

Verrous explicites
 PostgreSQL place les verrous nécessaires pour
chaque commande SQL, ce verrouillage est dit
implicite, car l'utilisateur n'a pas à les spécifier.
 Cependant, pour certaines transactions, lorsque
la protection apportée par le verrouillage n'est
pas suffisant, il peut être nécessaire de spécifier
explicitement le verrouillage.
 Ce verrouillage peut être :
 un verrouillage de table,
 un verrouillage de lignes.

Verrous de table
 LOCK TABLE t1, ..., tn IN mode MODE [NOWAIT]
 Les modes disponibles sont :
 ACCESS SHARE
 acquis notamment par SELECT
 ROW SHARE :
 acquis notamment par SELECT FOR UPDATE et SELECT FOR SHARE
 ROW EXCLUSIVE
 acquis notamment par UPDATE, DELETE et INSERT
 SHARE UPDATE EXCLUSIVE
 pour protéger une table contre les modifications concurrentes de schéma
 SHARE
 acquis par CREATE INDEX
 SHARE ROW EXCLUSIVE
 EXCLUSIVE
 ACCESS EXCLUSIVE
 la transaction qui a posé le verrou est la seule à y accéder
 acquis notamment par ALTER TABLE et DROP TABLE
 Ce qui est important, c'est ce qui est interdit aux transactions
concurrentes et donc la matrice de compatibilité.
 L'option NOWAIT indique que si le verrou demandé ne peut être acquis, la
transaction est annulée.

MC AS RS RX SUX S SRX X AX
AS oui oui oui oui oui oui oui non
RS oui oui oui oui oui oui non non
RX oui oui oui oui non non non non
SUX oui oui oui non non non non non
S oui oui non non oui non non non
SRX oui oui non non non non non non
X oui non non non non non non non
AX non non non non non non non non

Exemple
 Soit la BD de schéma :
 livre(cote, titre)
 emprunteur(nom, cote) où cote est une clé étrangère
qui réfère la relation livre.
 On veut insérer l'emprunteur du livre "Les BD en
BD" et empêcher que ce livre ne soit supprimé
pendant cette opération :
 BEGIN;
LOCK TABLE livre IN SHARE MODE;
SELECT cote FROM livre WHERE titre = 'Les BD en
BD';
INSERT INTO emprunteur VALUES ('Dupont', cote);
COMMIT;

Verrous de lignes
 SELECT ... FOR UPDATE
 verrouille en mode exclusif les lignes sélectionnées par
SELECT
 peut-être utilisé pour éviter que des lignes à
sélectionnées soient modifiées par une autre
transcation.
 SELECT ... FOR SHARE
 même comportement, mais le verrouillage des lignes
sélectionnées est réalisé en mode partagé, ce qui
bloque :
 les transactions qui veulent réaliser un UPDATE, DELETE ou
SELECT FOR UPDATE d'une autre transaction,
 mais pas celles qui veulent réaliser un SELECT FOR SHARE.

Transactions distribuées
 Une BD peut être distribuée sur plusieurs
sites
 Une transaction peut donc impliquer des
calculs sur plusieurs de ces sites :
 elle est dite distribuée.
 Questions :
 Comment abandonner ou confirmer une
transaction distribuée ?
 Comment assurer la sérialisabilité des
transactions distribuées ?

Exemple
 Une chaîne de n magasins dont chacun possède son propre
inventaire.
 Une transaction émise par le directeur de la chaîne destinée
à rééquilibrer les stocks d’un certain produit P par transfert
d’un magasin à l’autre :
 Le site directeur envoie à chaque magasin un message lui
demandant la quantité de P dont il dispose,
 Chaque magasin exécute cette requête sur son propre
inventaire et renvoie la réponse au site du directeur.
 Après un calcul celui-ci envoie à certains magasins un ordre
d’envoi d’une quantité q de P à un autre magasin.
 Les magasins recevant ce message mettent à jour leur
inventaire puis effectuent l’envoi demander.

Confirmation à deux phases
(Two-Phase Commit)
 Soit T une transaction distribuée sur n
sites et décomposée en n transactions
locales
T1, …, Tn.
 Un des sites sur lequel est exécutée T joue
le rôle de coordinateur.

1ère phase
 Le coordinateur décide d’essayer de confirmer la
transaction :
 Il envoie à chaque site Si un message lui demandant de se
préparer à confirmer sa part Ti de T.
 Chaque site Si recevant ce message décide s’il peut confirmer
Ti ou s’il doit l’abandonner.
 S’il décide de confirmer :
 il entre dans une phase de préconfirmation et ne peut plus
abandonner sauf s’il en reçoit l’ordre du coordinateur ;
 il journalise tous les effets de Ti ;
 il envoie un message au coordinateur lui annonçant qu’il est prêt à
confirmer, mais ne confirme pas effectivement.
 Si Si décide d’abandonner :
 il envoie un message au coordinateur lui annonçant qu’il
abandonne et le fait effectivement car il est sûr que T sera
abandonnée.

2e phase
 Elle commence quand le coordinateur a reçu de
tous les sites un message annonçant sa décision
de confirmer ou d’abandonner.
 S’il a reçu de tous les sites un message de décision de
confirmation, alors il envoie à chaque site Si un message
lui demandant de confirmer Ti.
 S’il a reçu d’au moins un site un message de décision
d’abandon, alors il envoie à chaque site Si un message
lui demandant d’abandonner Ti.
 Le site qui reçoit un message de demande de
confirmation la réalise.
 Le site qui reçoit un message de demande d’abandon le
réalise, s’il ne l’a déjà fait.

Panne d’un site
 Si un des sites, non coordinateur, tombe
en panne on fixe un délai de réponse qui,
s’il est dépassé est équivalent à un
message d’abandon.
 Si le coordinateur tombe en panne : c’est
plus grave ! Sans réponse de lui au bout
d’un certain temps, on doit abandonner
l’atomicité de T.

Sérialisabilité
 La sérialisabilité d’une transaction locale est
assurée par le protocole de verrouillage à deux
phases.
 Qu’en est-t’il pour la transaction globale ?
On montre que pour un ensemble de transactions
distribuées, si :
 les transactions locales sont exécutées selon un
protocole de verrouillage à deux phases,
 les transactions globales sont exécutées selon le
protocole de confirmation à deux phases,
alors les transactions globales sont sérialisables.

Index multidimensionnels
Références bibliographiques :
H. Garcia-Molina, J. D. Ullman, J. Wisdom,
Database Systems – The Complete Book,
Prentice Hall, 2002, Chapter 14.
G. Gardarin, Internet/intranet et bases de
données, Eyrolles, 1999, chapitre 3.
Index multidimensionnels
 Accès par parcours d’arbre :
 arbres k-dimensionnel (kd-trees)
 arbres quadrants (quadtrees)
 arbres R (R trees)
 Accès par hachage
 Grid files
 hachage partitionné

Dimensions
 Dimensions spatiales
 abscisse, ordonnée et élévation d’un point de l’espace
 Dimensions spatio-temporelles
 on ajoute une 4e dimension : le temps,
 Plus généralement, tout attribue d’une relation
peut-être vue comme une dimension.
 Par exemple, dans la relation :
personne(id, âge, salaire)
l’âge et le salaire constituent chacun une dimension.
Un n-uplet de la relation personne est donc un point
dans cet espace à deux dimensions.

Types de requêtes
 Requêtes exactes :
 la valeur de chaque dimension est spécifiée.
 Requêtes partielles :
 seules les valeurs de certaines dimensions sont
spécifiées.
 Requêtes par intervalle
 les intervalles auxquels doivent appartenir les valeurs de
certaines dimensions sont spécifiés.
 Requêtes de localisation spatiale :
 on recherche les objets contenus dans une ceratine
région de l’espace.
...

Arbres k-dimensionnels (kd-trees)
 J. L. Bentley, 1975
 Index mémoire centrale, généralisant la structure
d’arbre binaire.
 Chaque enregistrement possède k champs dont
chacun est associé à une dimension.
 Un enregistrement est un point dans l’espace à k
dimensions ainsi défini.
 Les dimensions sont numérotées de 0 à
k Ŕ 1.
 Chaque nœud de l’arbre contient un
enregistrement.
Insertion d’un enregistrement
 Si l’arbre est vide, on crée un nœud qui constitue
la racine de l’arbre et on y insère le nouvel
enregistrement.
 Sinon, on parcoure l’arbre depuis sa racine.
 A partir de chaque nœud n de niveau i contenant
un enregistrement e on se déplace :
 dans le sous-arbre gauche, si la valeur du nouvel
enregistrement pour la dimension i modulo k est
inférieure ou égale à celle de l’enregistrement e,
 dans le sous-arbre droit, dans le cas contraire.
 Si le sous-arbre atteint est vide, on en crée un
constitué d’une nœud unique (une feuille) dans
lequel on insère le nouvel enregistrement.
Exemple
 Chaque enregistrement représente une personne
dont l’identifiant (1er champ) l’âge (2e champ) et le salaire (3e
champ) sont donnés :
 (p1, 25, 600)
 (p2, 45, 600)
 (p3, 50, 750)
 (p4, 50, 1000)
 (p5, 50, 1200)
 (p6, 70, 1100),
 (p7, 85, 1400)
 (p8, 30, 2600)
 (p9, 25, 4000)
 (p10, 45, 3500)
 (p11, 50, 2750)
 (p12, 60, 2600)
 La dimension 0 est celle des âges et la dimension 1 est celle des
salaires.

L’arbre obtenu
p1, 25, 600

L’arbre obtenu
p1, 25, 600 âge
p2, 45, 600

L’arbre obtenu
p1, 25, 600 âge
p2, 45, 600 salaire
p3, 50, 750

L’arbre obtenu
p1, 25, 600 âge
p2, 45, 600 salaire
p3, 50, 750 âge
p4, 50, 1000

L’arbre obtenu
p1, 25, 600 âge
p2, 45, 600 salaire
p3, 50, 750 âge
p4, 50, 1000 salaire
p5, 50, 1200

L’arbre obtenu
p1, 25, 600 âge
p2, 45, 600 salaire
p3, 50, 750 âge
p4, 50, 1000 p6, 70, 1100 salaire
p5, 50, 1200

L’arbre obtenu
p1, 25, 600 âge
p2, 45, 600 salaire
p3, 50, 750 âge
p4, 50, 1000 p6, 70, 1100 salaire
p5, 50, 1200 p7, 85, 1400

L’arbre obtenu
p1, 25, 600 âge
p2, 45, 600 salaire
p3, 50, 750 âge
p4, 50, 1000 p6, 70, 1100 salaire
p5, 50, 1200 p7, 85, 1400 âge
p8, 30, 2600

L’arbre obtenu
p1, 25, 600 âge
p9, 25, 4000 p2, 45, 600 salaire
p3, 50, 750 âge
p4, 50, 1000 p6, 70, 1100 salaire
p5, 50, 1200 p7, 85, 1400 âge
p8, 30, 2600

L’arbre obtenu
p1, 25, 600 âge
p9, 25, 4000 p2, 45, 600 salaire
p3, 50, 750 âge
p4, 50, 1000 p6, 70, 1100 salaire
p5, 50, 1200 p7, 85, 1400 âge
p10, 45, 3500

L’arbre obtenu
p1, 25, 600 âge
p9, 25, 4000 p2, 45, 600 salaire
p3, 50, 750 âge
p4, 50, 1000 p6, 70, 1100 salaire
p5, 50, 1200 p7, 85, 1400 âge
p10, 45, 3500 âge
p11, 50, 2750

L’arbre obtenu
p1, 25, 600 âge
p9, 25, 4000 p2, 45, 600 salaire
p3, 50, 750 âge
p4, 50, 1000 p6, 70, 1100 salaire
p5, 50, 1200 p7, 85, 1400 âge
p8, 30, 2600 p12, 60, 2600 salaire
p10, 45, 3500 âge
p11, 50, 2750

Arbres k-dimensionnels pour BD
 Les feuilles sont des blocs disque.
 Une feuille peut contenir n
enregistrements au maximum.
 Les dimensions sont numérotées de 0 à
k Ŕ 1 ainsi que les niveaux dans l’arbre de
l’index.
 Chaque nœud interne de l’index de niveau
i est étiqueté par une valeur v prise dans
la dimension i modulo k.

Insertion d’un enregistrement
 On démarre à la racine de l’arbre et on parcoure
une branche jusqu’à atteindre une feuille.
 A partir de chaque nœud de niveau i et
d’étiquette v, on se déplace :
 dans le sous-arbre gauche si la valeur de
l’enregistrement à insérer pour la dimension
i modulo k est inférieure ou égale à v,
 dans le sous-arbre droit dans le cas contraire.
 Lorsque l’on atteint une feuille F, deux cas sont
possibles :
1. si le nombre d’enregistrements contenus dans F est
inférieur à n, le nouvel enregistrement est rangé dans
F,
2. sinon, on partage F en deux puis on reprend l’insertion
de l’enregistrement.
Partage d’une feuille
 Le partage d’une feuille F de niveau i est réalisé de la façon suivante :
1. on crée une nouvelle feuille F’,
2. soit vm la valeur médiane des valeurs de la dimension (i mod k) des
enregistrements déjà présents dans la feuille et de l’enregistrement à
insérer,
3. on transfère dans Fnouv les enregistrements de F dont la valeur pour la
dimension i modulo k est supérieure à vm,
4. on remplace la feuille F par un arbre dont la racine est un nœud étiqueté
par v et qui a pour fils gauche F et pour fils droit F’.
vm niveau i
enregistrements de F enregistrements de F
dont la valeur pour la dont la valeur pour la
dimension i modulo k dimension i modulo k
est ≤ vm est > vm
F F’

L’arbre obtenu
47,5 âge (p1, 25, 600)

(p2, 45, 600)
(p3, 50, 750)
1600 1050 salaire (p4, 50, 1000)
(p5, 50, 1200)
(p6, 70, 1100)
(p7, 85, 1400)
p1, p2 p8, p9, p10 p3, p4 60 âge (p8, 30, 2600)
F1 F4 F2 (p9, 25, 4000)
(p10, 45, 3500)
p5, p11, p12 p6, p7 (p11, 50, 2750)
F3 F5 (p12, 60, 2600)

Sa construction (1)
p1, p2, p3 (p1, 25, 600)

(p2, 45, 600)
(p3, 50, 750)
(p4, 50, 1000)
(p5, 50, 1200)
(p6, 70, 1100)
(p7, 85, 1400)
(p8, 30, 2600)
(p9, 25, 4000)
(p10, 45, 3500)
(p11, 50, 2750)
(p12, 60, 2600)

Sa construction (1)
p1, p2, p3 (p1, 25, 600)

(p2, 45, 600)
(p3, 50, 750)
(p4, 50, 1000)
(p5, 50, 1200)
(p6, 70, 1100)
(p7, 85, 1400)
(p8, 30, 2600)
(p9, 25, 4000)
(p10, 45, 3500)
(p11, 50, 2750)
(p12, 60, 2600)

Sa construction (2)
47,5 âge (p1, 25, 600)

(p2, 45, 600)
(p3, 50, 750)
p1, p2 p3, p4 (p4, 50, 1000)
(p5, 50, 1200)
F1 F2 (p6, 70, 1100)
(p7, 85, 1400)
(p8, 30, 2600)
(p9, 25, 4000)
(p10, 45, 3500)
(p11, 50, 2750)
(p12, 60, 2600)

Sa construction (3)
47,5 âge (p1, 25, 600)

(p2, 45, 600)
(p3, 50, 750)
p1, p2 p3, p4, p5 (p4, 50, 1000)
(p5, 50, 1200)
F1 F2 (p6, 70, 1100)
(p7, 85, 1400)
(p8, 30, 2600)
(p9, 25, 4000)
(p10, 45, 3500)
(p11, 50, 2750)
(p12, 60, 2600)

Sa construction (4)
47,5 âge (p1, 25, 600)

(p2, 45, 600)
(p3, 50, 750)
salaire (p4, 50, 1000)
p1, p2 1050
(p5, 50, 1200)
F1 (p6, 70, 1100)
(p7, 85, 1400)
p3, p4 p5, p6 (p8, 30, 2600)
F2 F3 (p9, 25, 4000)
(p10, 45, 3500)
(p11, 50, 2750)
(p12, 60, 2600)

Sa construction (5)
47,5 âge (p1, 25, 600)

(p2, 45, 600)
(p3, 50, 750)
p1, p2 1050 salaire (p4, 50, 1000)
(p5, 50, 1200)
F1
(p6, 70, 1100)
(p7, 85, 1400)
p3, p4 p5, p6, p7
(p8, 30, 2600)
F2 F3 (p9, 25, 4000)
(p10, 45, 3500)
(p11, 50, 2750)
(p12, 60, 2600)

Sa construction (6)
47,5 âge (p1, 25, 600)

(p2, 45, 600)
(p3, 50, 750)
p1, p2, p8 1050 salaire (p4, 50, 1000)
(p5, 50, 1200)
F1 (p6, 70, 1100)
(p7, 85, 1400)
p3, p4 p5, p6, p7 (p8, 30, 2600)
F2 F3 (p9, 25, 4000)
(p10, 45, 3500)
(p11, 50, 2750)
(p12, 60, 2600)

Sa construction (7)
47,5 âge (p1, 25, 600)

(p2, 45, 600)
(p3, 50, 750)
1600 1050 salaire (p4, 50, 1000)
(p5, 50, 1200)
(p6, 70, 1100)
(p7, 85, 1400)
p1, p2 p8, p9 p3, p4 p5, p6, p7
(p8, 30, 2600)
F1 F4 F2 F3 (p9, 25, 4000)
(p10, 45, 3500)
(p11, 50, 2750)
(p12, 60, 2600)

Sa construction (8)
47,5 âge (p1, 25, 600)

(p2, 45, 600)
(p3, 50, 750)
1600 1050 salaire (p4, 50, 1000)
(p5, 50, 1200)
(p6, 70, 1100)
(p7, 85, 1400)
p1, p2 p8, p9, p10 p3, p4 p5, p6, p7
(p8, 30, 2600)
F1 F4 F2 F3 (p9, 25, 4000)
(p10, 45, 3500)
(p11, 50, 2750)
(p12, 60, 2600)

Sa construction (9)
47,5 âge (p1, 25, 600)

(p2, 45, 600)
(p3, 50, 750)
1600 1050 salaire (p4, 50, 1000)
(p5, 50, 1200)
(p6, 70, 1100)
(p7, 85, 1400)
p1, p2 p8, p9, p10 p3, p4 60 âge (p8, 30, 2600)
F1 F4 F2 (p9, 25, 4000)
(p10, 45, 3500)
p5, p11 p6, p7 (p11, 50, 2750)
F3 F5 (p12, 60, 2600)

Sa construction (10)
47,5 âge (p1, 25, 600)

(p2, 45, 600)
(p3, 50, 750)
1600 1050 salaire (p4, 50, 1000)
(p5, 50, 1200)
(p6, 70, 1100)
(p7, 85, 1400)
p1, p2 p8, p9, p10 p3, p4 60 âge (p8, 30, 2600)
F1 F4 F3 (p9, 25, 4000)
(p10, 45, 3500)
p5, p11, p12 p6, p7 (p11, 50, 2750)
F2 F5 (p12, 60, 2600)

Découpage de l’espace
salaire
- âge ≤ 47,5 dans F1 ou F4
- 47,5 < âge ≤ 60 dans F2 ou F3
F1 - âge > 60 dans F3 ou F5
{p1, p2} - salaire ≤ 1050 dans F3 ou F4
- 1050 < salaire ≤ 1600
F2 F5 dans F2, F4, F5
1600 {p5, p11, p12} {p6, p7} - salaire > 1600 dans F1, F2 ou F5
(p1, 25, 600)

(p2, 45, 600)
1050
(p3, 50, 750)
F4 (p4, 50, 1000)
{p8, p9, p10} (p5, 50, 1200)
F3 (p6, 70, 1100)
{p3, p4} (p7, 85, 1400)
(p8, 30, 2600)
(p9, 25, 4000)
âge
47,5 60 (p10, 45, 3500)
(p11, 50, 2750)
(p12, 60, 2600)
Requêtes partielles
Employés ayant un salaire de 2600 € ?
47,5 âge (p1, 25, 600)

(p2, 45, 600)
(p3, 50, 750)
1600 1050 salaire (p4, 50, 1000)
(p5, 50, 1200)
(p6, 70, 1100)
(p7, 85, 1400)
p1, p2 p8, p9, p10 p3, p4 60 âge (p8, 30, 2600)
F1 F2 F3 (p9, 25, 4000)
(p10, 45, 3500)
p5, p11, p12 p6, p7 (p11, 50, 2750)
F4 F5 (p12, 60, 2600)

Requêtes par intervalles
Employés âgés de 50 à 60 ans ayant un salaire de plus 1500 € ?
47,5 âge (p1, 25, 600)

(p2, 45, 600)
(p3, 50, 750)
1600 1050 salaire (p4, 50, 1000)
(p5, 50, 1200)
(p6, 70, 1100)
(p7, 85, 1400)
p1, p2 p8, p9, p10 p3, p4 60 âge (p8, 30, 2600)
F1 F2 F3 (p9, 25, 4000)
(p10, 45, 3500)
p5, p11, p12 p6, p7 (p11, 50, 2750)
F4 F5 (p12, 60, 2600)

Arbres R
 A. Guttman, 1984
 Adaptation des arbres B+ aux objets
multidimensionnels :
 l’arbre de l’index est équilibré contrairement
aux arbres k-dimensionnels.
 Bien adaptés aux requêtes de recherche
des objets contenus dans une région de
l’espace.

Identification d’un objet géométrique
 Un objet géométrique est repéré par :
 un identificateur,
 le plus petit rectangle qui le contient, appelé
rectangle englobant minimal.
objet
rectangle englobant minimum

Structure d’un arbre R à 2 dimensions
 Les rectangles englobants minimaux sont regroupés à l’intérieur de
rectangles appelés rectangles directeurs qui peuvent eux-mêmes être
regroupés au sein de rectangles directeurs.
 Un rectangle est décrit par les coordonnées de son sommet en bas à
gauche et de son sommet en haut à droite.
 Les rectangles peuvent se chevaucher.
 Une feuille de l’arbre est associée à un rectangle directeur r qui contient k
objets. Elle contient une liste de k paires (ri, idi) où ri est le rectangle
englobant minimum d’un objet contenu dans r et idi est l’identificateur de
cet objet
 Un nœud non terminal de l’arbre est associé à un rectangle directeur r qui
contient k rectangles directeurs. Il contient une liste de k paires (ri, pi) où
ri est la description d’un rectangle directeur contenu dans r et pi est le
pointeur vers le nœud associé au rectangle directeur ri.
 Soit m le nombre maximum de paires dans un nœud :
 la racine contient au moins deux paires,
 les autres nœuds contiennent au moins m/2 paires.
 Un arbre R est équilibré.

Structure d’un arbre R à 2 dimensions
rectangles directeurs
4
3 B
5
1
A D
2
6 C 7
A B C
1 2 3 4 5 6 7

Recherche des objets contenus dans un
rectangle R
1. On se place sur la racine de l’arbre.
2. Soit n le nœud courant :
 si n est non terminal et si le rectangle
directeur associé à n recouvre partiellement
R, on réitère l’opération 2 sur chacun des
nœuds fils de n ;
 si n est une feuille, on recherche les objets
contenus dans le rectangle directeur associé à
cette feuille dont les rectangles englobants
sont contenus dans R.

Exemple de recherche
4
3 B
5
1
A D
2
6 C 7
A B C
1 2 3 4 5 6 7

Insertion d’un objet
1. On calcule le rectangle englobant minimal r de l’objet à
insérer. Soit id l’identificateur de cet objet, la paire à
insérer est (r, id)
2. On recherche à partir de la racine, les rectangles qui
peuvent contenir r :
 s’il en existe plusieurs, on en choisit un ;
 s’il n’en existe pas, on étend un de ces rectangles, pour qu’il
puisse contenir R (problème : lequel choisir ?),
puis on répète l’opération 2, sur les rectangles fils du
rectangle choisi.
3. Lorsque l’on atteint une feuille :
 si elle contient moins de m paires, on y insère la paire (r, id)
 sinon, on partage cette feuille en deux (problème :
comment réaliser ce partage ?) puis l’on insère la paire
(r, id) dans l’une des 2 feuilles produites. Comme dans les
arbres B+, ce découpage peut entraîner le découpage des
rectangles directeurs ancêtres.

Problèmes
 On a intérêt à minimiser la surface de chaque
rectangle directeur non occupée par des
rectangles englobants minimaux.
 En conséquence :
 Lorsque plusieurs rectangles directeurs peuvent
accueillir l’objet à insérer on a intérêt à choisir celui qui
nécessite le plus petit agrandissement.
 Lorsque l’on partage un rectangle directeur r en deux
rectangles r1 et r2, on a intérêt à répartir les rectangles
contenus dans r de telle façon à ce que r1 et r2 aient une
surface minimum. Malheureusement cette opération a
un coût exponentiel en nombre de rectangles
contenus dans r car il faut tester toutes les
combinaisons possibles.

Construction d’un arbre R (1)
route1, route2, maison 1, maison 2, canalisation, école
école
route 1
r maison 2
o
maison 1 u canalisation
t
e
2
((0, 0), (28, 10)) ((14, 4), (50, 16))
route1, route2, maison 1 maison 2, canalisation, école, cabine
école ct
route 1
r maison 2
o
t
e
2
((0, 0), (41, 10)) ((14, 4), (50, 16))
route1, route2, maison 1, maison 3 maison 2, canalisation, école, cabine
école ct
route 1
r maison 2
o
t
e maison 3
2
Index textuels
Référence bibliographique :
R. Baeza-Yates, B. Ribeiro-Neto,
Modern Information Retrieval,
Addison Wesley, 2002,
Chapter 8.
Objectifs
 Recherche d’un mot dans un ensemble de
mots.
 Recherche d’une sous-chaîne dans une
chaîne.
 Recherche de documents dont le texte
contient (ou non) certains mots.

Tries ou arbres préfixe
 Le mot trie vient de retrieval.
 Un trie est un arbre qui représente un
ensembles de mots :
 ceux d’un dictionnaire par exemple.
 Chaque mot correspond à une branche de
l’arbre.
 Chaque arête est étiquetée par une lettre.

Trie
bas
bateau
batte
baume
bauxite
berge
berger
cap

Trie
b
s bas
bateau
batte
baume
bauxite
berge
berger
cap

Trie
b
s t bas
bateau
batte
e baume
bauxite
berge
a berger
cap

Trie
b
s t bas
bateau
batte
e t baume
bauxite
berge
a e berger
cap

Trie
b
s t u bas
bateau
batte
e t m baume
bauxite
berge
a e e berger
cap

Trie
b
s t u bas
bateau
batte
e t m x baume
bauxite
berge
a e e i berger
cap
u t

Trie
b
a e
s t u r bas
bateau
batte
e t m x g baume
bauxite
berge
a e e i e berger
cap
u t

Trie
b
a e
s t u r bas
bateau
batte
e t m x g baume
bauxite
berge
a e e i e berger
cap
u t r

Trie
b c
a e a
s t u r p bas
bateau
batte
e t m x g baume
bauxite
berge
a e e i e berger
cap
u t r

Applications
 Opérations :
 recherche d’un mot et de l’information qui y
est associée
 énumération de tous les mots dont le préfixe
est donné :
 ber  berge, berger
 affichage d’un mot complet dès que les
premières lettres saisies l’identifient :
 baux  bauxite

Trie binaire (1)
0 1
pierre
0 1
0 0 jumelles 0101010101
jouet 0101001111
0 1 1 pierre 1000001001
corde 0001101111
avion corde avion 0000110110
0
0 1
jouet jumelles

Trie binaire (2)
jumelles
jumelles 0101010101
jouet 0101001111
pierre 1000001001
corde 0001101111
avion 0000110110

Trie binaire (3)
0
0 jumelles 0101010101
jouet 0101001111
1 pierre 1000001001
corde 0001101111
avion 0000110110
0
0 1
jouet jumelles

Trie binaire (4)
0 1
pierre
1
0 jumelles 0101010101
jouet 0101001111
1 pierre 1000001001
corde 0001101111
avion 0000110110
0
0 1
jouet jumelles

Trie binaire (5)
0 1
pierre
0 1
corde
0 jumelles 0101010101
jouet 0101001111
1 pierre 1000001001
corde 0001101111
avion 0000110110
0
0 1
jouet jumelles

Trie binaire (6)
0 1
pierre
0 1
0 0 jumelles 0101010101
jouet 0101001111
0 1 1 pierre 1000001001
corde 0001101111
avion corde avion 0000110110
0
0 1
jouet jumelles

Arbre PATRICIA
jumelles 0101010101
2 pierre jouet 0101001111
pierre 1000001001
corde 0001101111
avion 0000110110
4 6
avion corde jouet jumelles

Arbre des suffixes
 Ils permettent de représenter tous les
suffixes d’une chaîne de caractères.
 Par exemple, les suffixes du mot « ananas »
sont :
 ananas
 nanas
 anas
 nas
 as
 s
 Bien adaptés à la recherche d’une sous-
chaîne

Exemple
a na s
6
na s nas s ananas
123456
5 2 4
nas s
1 3

Opérations et performances
 Soit n la longueur de la chaîne.
 Construction de l’arbre en O(nlogn)
 Recherche d’une sous-chaîne de longueur m
en O(m).

Fichiers inversés
 Les fichiers inversés sont un moyen rapide d’accéder à
certains enregistrements d’une base de données à partir
d’une valeur contenue dans un champ de cet
enregistrement.
 Soit, par exemple un ensemble de livres d’informatique
dont le sujet est décrit par un ensemble de mots-clés :
algorithmique, compilation, Java, réseaux , XML...
 On peut construire un fichier inversé qui associe à chaque
mot-clé la liste (dite liste inverse) des numéros de livre
dont le domaine est décrit par ce mot-clé.
 On pourra ainsi répondre à une question telle que :
 « Quels sont les livres sur XML et les réseaux ? »
en réalisant l’intersection de la liste inverse associée au
mot-clé base de données avec celle associée au mot-clé
réseaux.
Mise en œuvre
 Soit N le nombre d’enregistrements.
 Une liste inverse peut-être représentée par une
chaîne de N bits.
 La réponse à une requête de la forme :
 Quels sont les enregistrements dont le champ C
contient les valeurs v1 et v2 ?
pourra être obtenue très rapidement en
réalisant l’intersection bit à bit des listes
inverses associées aux valeurs v1 et v2 du
champ C.
 Dans un certain nombre de SGBD relationnel,
les listes inverses peuvent être implantées à
l’aide des index bitmap.

Exemple
no_livre mots-clés mot-clé liste inverse
1 algorithmique, Java algorithmique 1000
2 compilation XML 0011
3 XML, réseaux compilation 0100
4 XML, Java Java 1001
réseaux 0010
requête réponse
Livres sur XML et les réseaux ? 0011 & 0010 = 0010 = livre 3
Livres sur Java ou la compilation 1001 | 0010 = 1011 = livres 1, 3 et 4
Livres sur XML mais pas sur les réseaux ? 0011 & ~0010 = 0001 = livre 4

Règles d’association
Règle d’association
 Une règle d’association est une règle de la
forme :
 {x1, …, xn}  y
qui indique que si les objets x1, …, xn
appartiennent à un ensemble E, alors y
appartient aussi à E.

Découverte de règles d’association
 Contexte :
 I est un ensemble d’items
 Une transaction t est un sous-ensemble de I
 Une base de données B est un ensemble de
transactions.
 Si t est une transaction, on note :
 id(t) : l’identifiant de t,
 items(t) : l’ensemble des items de t.

Exemple
Base de données
Transaction Items
T1 {Farine, Lait, Sucre}
T2 {Chocolat, Œufs, Sucre}
T3 {Chocolat, Farine, Œufs, Sucre}
T4 {Chocolat, Œufs, Thé}

 Soit X et Y des ensembles d’items d’une base
de données B :
 support(X) =
card({ t | X  items(t)}) / card(B)
 confiance(X  Y) =
support(X  Y) / support(X)
 Un ensemble d’items est fréquent si son
support est supérieur à un seuil appelé
support_minimum.
 Une règle d’association est forte si sa
confiance est supérieure à un seuil appelé
confiance_minimum.

Exemple
Base de données
Transaction Items
T1 {Farine, Lait, Sucre}
T2 {Chocolat, Œufs, Sucre}
T3 {Chocolat, Farine, Œufs, Sucre}
T4 {Chocolat, Œufs, Thé}
support({Farine, Sucre}) = 2 / 4 = 50%

confiance(Farine  Sucre) = 2 / 2 = 100%

 La découverte de règles d’association dans
une base de données B est réalisée en
deux étapes :
1. Calculer l’ensemble L des ensembles
fréquents d’items.
2. Pour chaque ensemble fréquent d’items F de
L, générer les règles d’association fortes
X  F  X telle que X est un sous-ensemble
non vide de F.

Algorithme a priori
 On appelle ensemble candidat un
ensemble d’items candidat à être un
ensemble fréquent d’items.
 On note :
 Lk : ensemble d’ensembles fréquents de k
items
 Ck : ensemble d’ensembles candidats de k
items

Algorithme a priori
 Propriété a priori :
 Tout sous-ensemble d’un ensemble fréquent d’items doit
être un ensemble fréquent d’items :
 Si {a, b} est un ensemble fréquent d’items, alors {a} et {b}
doivent être des ensembles fréquents d’items.
 On calcule itérativement L1, …, Lk en générant à
partir de Li un ensemble Ci+1d’ensembles
candidats puis en retenant parmi ceux-ci ceux qui
sont fréquents.
 On suppose que l’ensemble des items est muni
d’une relation d’ordre.
 Un ensemble d’items {i1,..., in} est représenté
sous la forme d’un ensemble ordonné selon cette
relation.

Algorithme a priori
 L1 = ensemble des ensembles fréquents de 1
item
 k=1
 Tant que Lk n’est pas vide
 Générer l’ensemble des ensembles candidats Ck+1 à
partir de Lk
 Lk+1 = 
 Pour chaque candidat c dans Ck+1
 nb(c) = 0
 Pour chaque transaction t
 Si c  items(t) alors nb(c) = nb(c) + 1
 Si nb(c) > support minimum alors
 Lk+1 = Lk+1  {c}

Calcul de L1
 L1 = 
 Pour chaque item i de l’ensemble des
transactions de B tel que
support({i}) ≥ support_minimum :
 L1 = L1  {c}

Génération de Ck+1 à partir de Lk
 Si [i1, i2, .., ik-1, ik] et [i1, i2, .., ik-1, ik+1]
sont dans Lk alors :
 [i1, i2, .., ik-1, ik, ik+1] est ajouté à Ck+1
 Pourquoi ?
 Si [i1, i2, .., ik-1, ik]  Lk et
[i1, i2, .., ik-1, ik+1]  Lk cela signifie que
[i1, i2, .., ik-1, ik+1] n’est pas un ensemble fréquent
d’items et donc que [i1, i2, .., ik-1, ik, ik+1] ne l’est
pas non plus et donc qu’il ne faut pas l’ajouter à
Ck+1.
 Ck+1 peut être obtenu par jointure de Lk par
lui-même.
Calcul des ensembles d’items fréquents
C1 {{C}:3, {F}:2, {L}:1, {O}:3, {S}:3, {T}:1}
L1 {{C}:3, {F}:2, {O}:3, {S}:3}

Base de données C2 {{C, F}, {C, O}, {C, S},
Transaction Items {F, O}, {F, S}, {O, S}}
T1 {F, L, S} C2 {{C, F}: 1, {C, O}: 3, {C, S}: 2,
{F, O}: 1, {F, S}: 2, {O, S}: 2}
T2 {C, O, S}
L2 {{C, O}:3, {C, S}:2, {F, S}:2, {O, S}:2}
T3 {C, F, O, S}
C3 {{C, O, S}}
T4 {C, O, T}
C3 {{C, O, S}: 2}
L3 {{C, O, S}: 2}
Support minimum = 50 % = 2 transactions

Génération des règles d’association
L1 {{C}:3, {F}:2, {O}:3, {S}:3}
L2 {{C, O}:3, {C, S}:2, {F, S}:2, CO:1

{O, S}:2} OC:1
Base de données C  S : 2/3
S  C : 2/3
Transaction Items
FS:1
T1 {F, L, S} S  F : 2/3
O  S : 2/3
T2 {C, O, S} S  O : 2/3
T3 {C, F, O, S} L3 {{C, O, S}: 2} {C, O}  S : 2/3
T4 {C, O, T} {C, S}  O :1
{O, S}  C :1
C  {O, S} : 2/3
O  {C, S} : 2/3
S  {C, O} : 2/3
Confiance minimum = 50 %

En SQL
transaction
id item
T1 Farine
T1 Lait
T1 Sucre
T2 Chocolat
T2 Œufs
T2 Sucre
T3 Chocolat
T3 Farine
T3 Œufs
T3 Sucre
T4 Chocolat
T4 Œufs
T4 Thé
En SQL
INSERT INTO candidat
SELECT *
FROM transaction
WHERE item IN
(SELECT item
FROM transaction
GROUP BY produit
HAVING COUNT(*) >= support_minimum
SELECT i.item, j.item, COUNT(*)

FROM candidat i, candidat j
WHERE i.id = j.id
i.item < j.item
GROUP BY i.item, j.item
HAVING COUNT(*) >= support_minimum

Des données très volumineuses
 Supermarché :
 1 000 000 transactions
 10 000 items
 20 items / transaction
 Soit :
 20 000 000 lignes dans la table transaction
 190 paires d’items par panier
 190 000 000 de paires d’items à grouper puis
compter

Bd-Avancees

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Bd-Avancees

Transféré par

Droits d'auteur :

Formats disponibles

Bases de données avancées

Ce cours est mis à disposition selon les termes

Jacques Le Maitre Bases de données avancées 3

Jacques Le Maitre Bases de données avancées 4

Jacques Le Maitre Bases de données avancées 5

Jacques Le Maitre Bases de données avancées 6

Jacques Le Maitre Bases de données avancées 8

Jacques Le Maitre Bases de données avancées 9

Jacques Le Maitre Bases de données avancées 10

Jacques Le Maitre Bases de données avancées 11

Jacques Le Maitre Bases de données avancées 12

Jacques Le Maitre Bases de données avancées 13

Jacques Le Maitre Bases de données avancées 14

Jacques Le Maitre Bases de données avancées 15

Jacques Le Maitre Bases de données avancées 16

CREATE TYPE poids AS INTEGER FINAL;

 Les valeurs d’attributs de type taille et celles

Jacques Le Maitre Bases de données avancées 17

CREATE TABLE personnes AS (

SELECT p.nom, p.adr.rue.nom

Jacques Le Maitre Bases de données avancées 18

CREATE TYPE acteur AS (

Jacques Le Maitre Bases de données avancées 19

CREATE TABLE acteurs OF acteur

CREATE TABLE films_courts OF film

Jacques Le Maitre Bases de données avancées 20

Jacques Le Maitre Bases de données avancées 21

CREATE TABLE dvds OF dvd

Jacques Le Maitre Bases de données avancées 22

Jacques Le Maitre Bases de données avancées 23

CREATE TABLE personne (

INSERT INTO personne

Jacques Le Maitre Bases de données avancées 24

SELECT nom, prenom[1]

Jacques Le Maitre Bases de données avancées 25

Jacques Le Maitre Bases de données avancées 26

SELECT nom, no_dept((p).adr_perso)

Jacques Le Maitre Bases de données avancées 27

CREATE TABLE livre (

CREATE TABLE dvd (

Jacques Le Maitre Bases de données avancées 28

INSERT INTO livre

Jacques Le Maitre Bases de données avancées 29

SELECT p.relname, titre

Jacques Le Maitre Bases de données avancées 30

Segments de droite ((x1, y1), (x2, y2))

Boîte ((x1, y1), (x2, y2))

Chemins ((x1, y1), ..., (xn, yn))

Polygones Chemin fermé

Cercle ((x, y), r)

Jacques Le Maitre Bases de données avancées 31

CREATE TABLE rectangle (

CREATE TABLE cercle (

Jacques Le Maitre Bases de données avancées 32

INSERT INTO rectangle

SELECT nom FROM figure;

Jacques Le Maitre Bases de données avancées 33

SELECT recouvre('R1', 'R2');

Jacques Le Maitre Bases de données avancées 34

SELECT nom, surface(f)

Jacques Le Maitre Bases de données avancées 35

CREATE TABLE employe (

CREATE TABLE localisation (