Cours Yaounde

Systèmes de Gestion
de Bases de Données
Nicolas Anciaux – Nicolas.Anciaux@inria.fr
Ressources web pour ce cours

www-smis.inria.fr/~anciaux/YAOUNDE/
1
Objectifs du module
• Aucun pré requis
• Objectifs des sessions
– Connaissance générales (culture)
• Raison d’être d’un SGBD
• Fonctionnalités logicielles : indépendance physique/logique, vues, langage
de manipulations, cohérence (contraintes d’intégrité et triggers), standards
– Connaissances de base
• Conception de BD (modèle entité association, relationnel)
• Programmation SGBD (SQL, SQL procédural, JDBC/ODBC)
– Connaissances avancées
• Optimisation, Concurrence d’accès
• Droits d’accès
• Tolérance aux pannes, audit des accès
• Sécurité des SGBD et chiffrement des données de la base
• BD distribuées : transactions et requêtes distribuées
2
Planning prévisionnel des séances
Modèles – Fondements, approches fichiers vs approche bases de données
– Conception de bases de données: modèle conceptuel de données, modèle relationnel  Exercice 1 : conception
J1 – Algèbre relationnelle  Exercice 2 : algèbre
Lanages – Le langage SQL (1) : langage de définition de données et de manipulation des données
– Le langage SQL (2) : langage d’interrogation des données et méthodologie
J2 – Programmation SQL: PL/SQL, JDBC/ODBC
[ Parenthèse utile au TP : le dictionnaire de données Oracle ]
 Exercice 3 (OracleXE): Création d’une BD, chargement, et manipulation en SQL
 Exercice 4 (OracleXE): Interrogation des données en SQL
Requêtes – Fonctionnalités essentielles des SGBD

J3 – Introduction au problèmes d'optimisation, d’indexation et évaluation de requêtes– Exécution et optimisation en
environnement contraint (SGBD embarqués)
– Requêtes distribuées : introduction du problème sur une l’étude de cas
 Exercice 5: création et utilisation des indexes, limites de l’indexation
 Exercice 6: impact de la répartition des traitements sur le BD (SQL vs. PL/SQL vs. JDBC)
 Exercice 7: étude de cas – optimisation de requête en environnement distribué
Sécurité – Sécurité des SGBD : les enjeux, les menaces, exemples d'attaques connues
J4 – Modèles de contrôle d’accès DAC-SQL, RBAC, MAC, sécurité multi-niveau dans les SGBD : Oracle VPD / OLS
– Place de la cryptographie dans la sécurité d'un SGBD
– Chiffrement par approche serveur, approche client, approche par matériel sûr
 Exercice 8 (OracleXE): Programmation d’applications BD, injection SQL, droits d’accès RBAC-SQL
Transact° – Propriétés transacitonnelles

J5 – Concurrence d’accès : algorithmes de verrouillage, niveaux d’isolation, multiversion
– Tolérance aux pannes: algorithmes de validation et de reprise
– Transactions distribuées  TP (OracleXE): concurrence d’accès dans OracleXE
Présentation du projet Folk-IS, perspective d’une thèse co-encadrée possible 3
Objectifs : compétences acquises
• Concevoir une base de données
– Réaliser un modèle conceptuel avec le modèle E/A
– Concevoir un modèle relationnelle de base de données
• Créer une application base de données
– Ecrire des requêtes SQL d’interrogation/mise à jour
– Interfacer un programme Java/JDBC avec une base de données
– Ecrire et invoquer des fonctions et procédure stockées en PL/SQL Oracle
– Implanter des triggers sur une base de données en PL/SQL Oracle
• Administrer une base de données en vue d’optimiser les performances
– Optimiser une base de données multi utilisateurs (gestion de la concurrence)
– Créer des index
– Réécrire des requêtes SQL pour obtenir un plan d’exécution plus performant
• Administrer une base en vue d’en assurer la sécurité
– Créer des utilisateurs/rôle et des droits d’accès (DAC-SQL, RBAC-SQL)
[…et chiffrer des données sensibles…]
4
Modèles
Modèle entités/associations
Modèle relationnel et algèbre
Exercice n°1: modélisation BD
Exercice n°2: algèbre relationnelle
Yaoundé, février 2014 Nicolas Anciaux 5

L’approche bases de données
(SGF vs. SGBD)
6
Systèmes
Redondance
Plusieurs dedonnées
fichiers Caractéristiques
(données)
applications
Interrogations
Partage de
Pannes ???
Confidentialité Plusieurs applications
 plusieurs formats
ComptaSoft  plusieurs langages
ChiruSoft
Dupont Dupond
Symptomes : y
Turlututu : sqj
Turlututusqjsk
Symptom: yyyy
Analyses xxxx
Redondance de données
Pas de facilité d’interrogation
Symptomes : y
Turlututu : sdd Turlututudhjsd
Analyses : xxx Analyses :xx
 Question développement
Redondance de code
Comptabilité Chirurgie
Problèmes
 Difficultés de gestion
 Incohérence des données
 Coûts élevés
Consultations Psychiatrie  Maintenance difficile
 Gestion de pannes ???
ConsultSoft
PsychiaSoft
Duhpon Duipont
Turlututu : sq  Partage des données ???
Symptomes : yy Symptomyyyy
Analyses : xxxx
Symptomes : yy
Analysesxxxx
Turlututudhjsd
 Confidentialité ???
7
L’approche ‘‘Bases de données’’ (1)
• Modélisation des données

 Éliminer la redondance de données
 Centraliser et organiser correctement les données
 Plusieurs niveaux de modélisation
 Outils de conception
• Logiciel «Système de Gestion de Bases de Données»

Factorisation des modules de contrôle des applications
- Interrogation, cohérence, partage, gestion de pannes, etc…
Administration facilitées des données
8
L’approche ‘‘Bases de données’’ (2)
I- Indépendance
Physique
X - Standards II- Indépendance

Logique
IX - Gestion de la III – Langage de

confidentialité manipulation
VIII - Concurrence BD IV - Gestion des

d’accès vues
VII - Gestion des V - Optimisation des

pannes questions
VI - Gestion de la
cohérence
9
Conception de bases de données
(Production du modèle conceptuel de
données)
10
Modélisation du réel
Réel
• Indépendant du
modèle de
Modèle données
conceptuel • Indépendant du
Médecin effectue Visite
SGBD
• Dépendant du
modèle de
Modèle données Codasyl Relationnel Objet XML
logique • Indépendant du
SGBD
• Dépendant du
modèle de • Organisation physique des données
Modèle données • Structures de stockage des données
Physique • Dépendant du • Structures accélératrices (index)
SGBD
11
Méthode de conception ?
• Plusieurs façons d’aborder la conception d’une BD
– Intuition + création directe de la BD 
– Suivre une méthode de conception (MCDMLDMPD) 
• Entité/Association (E/A) ou Entity/Relationship (E/R)
• Merise
• UML
• Suivre son intuition peut conduire à des erreurs
– Redondances
– Valeurs nulles
– Difficulté de gestion
– Impossibilité de répondre à certaines questions
• Une fois la base de données crée, difficile à modifier… (cf. TP)
• Les outils de conception sont une aide précieuse
12
Exemple de mauvaise conception (1)
• Stocker des propriétaires de véhicule:
N° Nom Prénom Ville Pays Immatriculation Marque Couleur
1 Bar Joe Paris France 125 PP 75 Renault Rouge
2 Dean Pascal Vence France 234 FF 45 Peugeot Vert
3 Ben Zoe Lyon France 324 DFT 56 Renault Rouge
4 Bar Joe Paris France 245 FT 75 Renault Jaune
• Redondance des données et incohérence potentielle

– Personne répétée pour chaque voiture :
• ex. Si Joe Bar change de ville et qu’une seule ligne est mise à jour…
– Redondance Ville/Pays : impact d’une erreur de saisie
• Anomalies de mises à jour et besoin de valeurs nulles.
– Comment insérer une personne sans voiture ?
– Sémantique de calculs avec des valeurs nulles…
– Comment supprimer la dernière voiture d'une personne ?
13
Exemple de mauvaise conception (2)
• Stocker des personnes qui ont des enfants:
N° Nom Prénom Ville Pays Enfant1 Enfant2 Enfant3 NbEnfants
1 Bar Joe Paris France Paul Zoe 2
2 Dean Pascal Vence France Lili 1
3 Ben Zoe Lyon France Sam Tor Tar 3
4 Cat Tom Lens France 0
• Redondance cachée :
– Nombre d’enfants vs enfants
• Difficulté de gestion
– Comment gérer les personnes ayant plus de 3 enfants !
– Comment afficher la liste des enfants ?
14
Méthodes de conception : Exemple Merise
Réel
DONNEES TRAITEMENT
MCD MCT
Modèle Quelles données ? Quels traitements ?
conceptuel Quelle organisation ?
Modèle MLD MLT

Modèle logique (e.g, relationnel) Structuration en procédure
logique
MPD MPT
Modèle Création de la base de donnée Description de l’architecture
Physique des traitements, algorithmes
Objectif du cours : E/A, Merise, UML ?  E/A light, Merise ultra-light

15
Approche proposée : orientée données
1/ Définir l’application (~MCT)
– Que veut-on faire exactement, définir les sorties (états)
2/ Définir les données (~MCD)
– quelles sont les données nécessaires ? Comment les organiser ?
3/ Définir les questions nécessaires pour l’application (~MLT)
4/ Validation : Est ce que la structure choisie permet de
répondre aux questions ? Sinon, retour en 1/ ou 2/
5/ Passer du MCD au MLD
6/ Définir les requêtes nécessaires pour l’application (~MPT).
Normalement, le MLD doit permettre de répondre aux
requêtes ?
7/ Passer du MLD au MPD
GENERATION AUTOMATIQUE POSSIBLE !
16
Déf° (1) : entité / type d’entité
• Entité : représentation d’un objet du monde réel …
… par rapport au problème à modéliser. Une entité peut donc être …
… concrète : ex. un docteur, un médicament, un client
… abstraite : ex. une visite médicale, une commande
• Type d'entité : représentation d'un ensemble d'entités perçues comme

similaires et ayant les mêmes caractéristiques
– Ex. docteurs, patients, médicaments, clients, visites, commandes
Profs
Profs
Bouganim Profs Nom
Luc Crenn Prénom
..... Isabelle Adresse
…
....
Entités Type d'entité

17
Déf° (2) : association / type d’association
• Association : représentation d'un lien non orienté entre plusieurs entités

(qui jouent un rôle déterminé).
– Ex. Un prof enseigne un cours
– lien non orienté : un prof enseigne un cours  un cours est enseigné par
un prof.
• Type d'association : représentation d'un ensemble d'associations
ayant la même sémantique et les mêmes caractéristiques
– Ex. enseigner
• Question : quid de visite : entité ou association ???
– Un docteur visite un patient  association
– Un docteur effectue une visite concernant un patient
– Différence ? Et clients - commandes - produits ?
18
Déf° (3) : Propriétés / Identifiants
• Propriété : donnée élémentaire permettant de décrire une entité ou une

association
– Le nom du patient, la date de la visite, l’adresse du patient
• Identifiant d’entité : Une entité est identifiée de manière unique par au

moins une propriété (généralement une)
– Ex. n° de sécurité sociale du patient, référence d’un produit
• Identifiant d’association : il n’existe pas

– On peut identifier une association par l’ensemble des identifiants des
entités associées
– Ex. pour enseigne : Code du prof, Code du cours
19
Exemple : Profs et cours...
Prof Cours
CodeProf enseigne CodeCours
Nom NbreHeures NomCours
Prénom …
Adresse Cours
Profs 1
1 Maths
enseigne
Crenn .....
Profs Isabelle 55
3 ....
enseigne Cours
Lewis
Jerry 16 2
.... Profs Info
2 enseigne s
...
Bouganim 24
Luc
.....
20
Déf°(4) : Cardinalités
• Cardinalité : Exprime le nombre minimum et maximum
d’association(s) par entité. Il est indiqué sur chaque arc,
entre le type d’entité et le type d’association concernées
• Pour un prof donné, combien d’enseignements ?

– Au minimum : Min=0 Cours
Profs enseigne
– Au maximum : Max=n 0,n
 Un prof enseigne de 0 à n cours
• Pour un cours donné, combien d’enseignements ?

– Au minimum : 0
Profs enseigne Cours
– Au maximum : 1 0,1
– Un cours est enseigné par 0 à 1 prof
21
Comment produire le MCD ? (1)
• ‘‘Énoncer le réel’’ à modéliser avec des phrases

Patient
• Exemple pour la gestion de rendez vous
0,n
– Les patients ont des rendez vous avec des médecins
• Un patient peut avoir plusieurs RDV (voire aucun)  0,n À un RDV
• Un médecin reçoit plusieurs patients (voire aucun)  0,n 0,n

Médecin
• Un patient prendre plusieurs rendez-vous avec un même médecin

 Ce MCD n’est pas bon !
Patient à RDV correspond Médecin

0,n 1,1 1,1 0,n
22
Patient à RDV correspond

0,n 1,1 1,1 0,n
– Un médecin exerce dans une salle

• Un médecin n’exerce que dans une seule salle  1,1
• Une salle peut être partagée par plusieurs médecins 1,n
Médecin
1,1
exerce
1,n
Salle
23
• On obtient :

0,n 1,1 1,1 0,n
1,1
• Pour connaître la salle, pour un rendez vous, exerce
on passe par le médecin 1,n
 Ce MCD est bon Salle

• Et si maintenant le médecin peut exercer dans plusieurs salles ?

0,n 1,1 1,1 0,n
1,n
exerce
• Comment connaître la salle d’un rendez vous ?
1,n
 Ce MCD n’est pas bon !
Salle
24
0,n 1,1 1,1 0,n
(A) 1,1
exerce
1,n
(B) (C) Salle
1,1 1,1 1,1
à a un rdv correspond à a un rdv correspond
0,n 0,n 0,n
1,1 1,1 0,n
Patient est dans Médecin Patient est dans Médecin
0,n 0,n 1,n
Salle 1,n
Salle exerce
Différences fonctionnelles (A) (B) (C)

Connaître la salle pour 1 RDV donné Non Oui Oui
Pré-allouer des salles aux médecins Non Non Oui
25
26
Règles (1) respect des règles de gestion

• Il faut vérifier que le MCD correspond bien au ‘réel’,
c’est à dire aux règles fixées (celles que l’application
doit respecter)
• par exemple:
– un prof enseigne plusieurs cours
– une matière est enseignée par plusieurs profs (info/anglais)
– les notes peuvent être données par n’importe quel prof ou
par plusieurs profs enseignant une matière... (info par
exemple)
– On peut redoubler une fois....
– etc...
26
Règles (2) : propriétés élémentaires, 27
calculées, constantes
• Toute propriété doit être élémentaire
– sinon, complexité de traitement
– Ex. de propriétés élémentaires : Age, Salaire, N° de rue
– Ex. de propriétés non élémentaires : Adresse (complète), N°SS
– la notion d’élémentaire dépend de l’application. L’adresse peut
devenir élémentaire si elle est toujours manipulée comme telle
(on ne cherchera jamais à faire, par exemple, un tri par ville)
« Il n’est pas gênant d’éclater des propriétés qui devrait être
groupés, mais on ne peut pas grouper des propriétés qui devrait
être éclatées»
• Une propriété calculée n’est pas à stocker !

– Sinon, c’est redondant  source d’incohérence
• Une propriété constante n’est pas à stocker

– Sinon, c’est redondant  source d’incohérence
– On utilisera une table de constantes ... 27
28
Règles (3) : propriétés répétitives

• Pour une entité, il ne peut y avoir qu’une instance de chaque
propriété de l’entité
– exemple: Cours ne peut être une propriété de Prof, puisqu’un prof
enseigne plusieurs cours...
– Remarque : Si un prof ne peut enseigner qu’un seul cours, cours peut
être une propriété de prof
• Attention aux propriétés n’ayant pas le même nom mais la
même sémantique
– Ex. : Enfant1, Enfant2, Enfant3 (cf. Slide 16)
– Ex. : différents types de notes d’un étudiant
• Remarque : pour éviter d’éventuelles erreurs, on nommera
différemment des propriétés de différentes entités :
– Ex. NomPatient, NomDocteur, etc.
– Du coup une propriété n’apparaît que dans une seule entité ou
association.
28
29
Règles (4) : propriétés sans signification
• Une propriété ne peut être sans signification pour une

partie des entités ou associations
– exemple : si un prof ne peut enseigner qu’un seul cours,
mais qu’on a choisi de créer une entité ‘personnel’ et non
‘prof’, on ne stockera pas le cours dans l’entité ‘personnel’
car il serait sans signification pour une secrétaire...
– contre exemple : Téléphone et Fax pour un étudiant...
29
30
Règles (5) : identifiants d’entités

• Toute entité doit être identifiée !
• Un identifiant doit être pérenne. Ex. nom et prénom
peut être l’identifiant de l’étudiant, mais ça peut être
insuffisant.
– il ne faut pas concevoir le MCD en observant les données
telles qu’elles sont (ex. l’école tel qu’elle est). Il faut le
concevoir pour le cas à modéliser (ex. l’école telle qu’elle
peut être.... et telle que l’on se propose de la gérer.... )
• Plusieurs identifiants peuvent coexister
– En choisir un…
• Si vous ne trouvez aucun identifiant, votre « entité »
est sans doute une association …
30
Règles (6) : dépendance pleine 31
de l’identifiant
• Toute propriété doit dépendre pleinement de l’identifiant
(et non d’une partie de celui-ci)
– Sinon on introduit des redondances
• Les propriétés d’une association doivent dépendre de la
totalité des entités associées
– Sinon, les déplacer, voire créer une nouvelle association…
• Exemple :
1/ la salle dépend du prof, du cours et du
enseigne
Heure
groupe  OK
Prof Groupe
Salle 2/ la salle ne dépend que du prof
Salle  Not OK (dans prof)
?
Salle 3/ la salle ne dépend que du prof et du cours
Cours  not OK (nouvelle association entre
prof et cours)
31
32
Règles (7) : entités et associations

• 2 entités ne peuvent être directement liées : il faut une
association !
• Cependant:
– Une association peut ne pas avoir de « nom »
• Il est des fois difficile à trouver…
– Une association peut ne pas avoir de propriété
• C’est un cas très fréquent
Enseigne
Prof Groupe
Heure
?
Salle
Cours
32
33
Règles (8) : pas de dépendance transitive

• Une propriété ne peut dépendre d’une autre propriété qui ne
soit pas l’identifiant
– Permet d’éliminer des sous-entités incluses dans une entité
• Exemple :
– Etudiant(nom, adresse, ville, pays)
– Le pays dépend de la ville or l’identifiant d’étudiant est le nom.
Prof Prof
1,1 Ville
CodeProf CodeProf est dans 0,n
NomVille
Nom Nom
Pays
Prénom Prénom
Ville
Pays
33
34
Première modélisation ‘restreinte’

• Gérer les notes des étudiants
– Hypothèses :
• une base de données pour chaque promo et pour chaque semestre
– Traitements :
• Moyenne par cours pour chaque étudiant
• Moyenne par pôle pour chaque étudiant
• Moyenne générale pour chaque étudiant
• Moyenne par groupe, par cours.
– ‘‘Énoncer le réel’’ à modéliser avec des phrases
• Un cours a un nom, un coefficient, et appartient à un pôle
• Un étudiant a un nom et un prénom, et appartient à un groupe
• Un étudiant obtient les notes DS1, DS2, participation, examen pour
les cours qu’il suit
34
35
Modèle entité-association (1/2)

Etudiant
a obtenu Cours
N° 0,n DS1 0,n NomCours
Nom DS2 Pôle
Participation Coefficient
Prénom
Examen
Groupe
Commentaires?
 Le schéma est simple, il répond au problème
 On a un minimum de données
 On ne peut pas faire de suivi sur une promo
 On ne peut pas faire de suivi par prof
 Pas de statistiques sur plusieurs années
 Problème de gestion: on aura 4 fois les mêmes programmes
35
Modèle entité-association (2/2)
Etudiant
a obtenu Cours
N° 0,n DS1 0,n NomCours
Nom DS2 Pôle
Participation Coefficient
Prénom
Examen
Groupe
TypeNote
Type
Coefficient
0,n
Etudiant Cours
a obtenu
N° 0,n Note
0,n NomCours
Nom Pôle
Prénom Coefficient
Groupe
36
37
Modélisation ‘complète’
• Gérer les notes des étudiants veut dire:

– Hypothèses :
• Une base de données pour l’Université (pour plusieurs années)
• On veut gérer les profs pour faire des stats par profs, par promos, etc...
– Problèmes :
• Gestion des redoublement, de la situation (actuelle) d’un étudiant
• Cohabitation de notes sur plusieurs années, des profs, des étudiants ??
• Les matières sont enseignés par plusieurs profs, qui met les notes ??
• Comment modéliser qu’un prof enseigne à un groupe de TP ?
– Données :
• Etudiants, Matières, Notes
• TypeDeNotes, Periodes, Profs, Groupes, etc...
37
38
Modèle entité-association
TypeNote
Type
Coefficient
1,n
Etudiant Cours
a obtenu
N° 1,n Note
1,n NomCours
Nom Pôle
Prénom Coefficient
1,n
1,n
Période 1,n
Code
1,n
Est dans 1,n Enseigne
Année
Semestre
Nb heures
1,n
1,n
Groupe 1,n Profs
Code Nom 1,n
Prénom
Adresse
38
Modèle relationnel
39
Le modèle relationnel
• En 1970, Edward Codd, Prix Turing 1981, chercheur chez IBM,
propose le Modèle Relationnel, basé sur la Logique du premier ordre
définie par les mathématiciens de la fin du 19e siècle pour formaliser
le langage des mathématiques
A Relational Model of Data for Large Shared Data Banks,
CACM 13, No. 6, June 1970
• Il définit le Calcul Relationnel et l’Algèbre Relationnelle, sur lesquels
sont basés SQL (Structured Query Language), le langage standard de
manipulation (LMD) et de définition des données (LDD) de tous les
SGBD Relationnels actuels
Théorème de Codd: une question est exprimable en calcul relationnel si

et seulement si elle peut être évaluée avec une expression de l’algèbre
relationnelle – de plus, il est facile de transformer une requête du calcul
relationnel en une expression algébrique qui évalue cette requête.
40
Domaine
• ENSEMBLE DE VALEURS
• Exemples:
– ENTIER
– REEL
– CHAINES DE CARACTERES
– EUROS
– SALAIRE = {4 000..100 000}
– COULEUR= {BLEU, BLANC, ROUGE}
41
Produit cartésien
• Le produit cartésien D1x D2x ... x Dn est l’ensemble

des tuples (n-uplets) <V1,V2,....Vn> tels que ViDi
• Exemple:
– D1 = {Bleu,Blanc,Rouge}
– D2 = {Vrai, Faux}
Bleu Vrai
Bleu Faux
Blanc Vrai
D1x D2 = Blanc Faux
Rouge Vrai
Rouge Faux
42
Relation, attribut
• Relation = sous-ensemble du produit cartésien d’une liste
de domaines
– Une relation est caractérisée par un nom
– Exemple: CoulVins Coul Choix
• D1 = COULEUR Bleu Faux
• D2 = BOOLEEN Blanc Vrai
Rouge Vrai
• Plus simplement …
– Une relation est une table à deux dimensions
– Une ligne est un tuple
– Un nom est associé à chaque colonne afin de la repérer
indépendamment de son numéro d'ordre
• Attribut =
– nom donné à une colonne d'une relation
– prend ses valeurs dans un domaine
43
Exemple de relation
VINS CRU MILL REGION COULEUR
CHENAS 1983 BEAUJOLAIS ROUGE

TOKAY 1980 ALSACE BLANC
TAVEL 1986 RHONE ROSE
CHABLIS 1986 BOURGOGNE BLANC
ST-EMILION 1987 BORDELAIS ROUGE
44
Clé
• Définition = Groupe d’attributs minimum qui détermine

un tuple unique dans une relation
• Exemples
– {CRU,MILLESIME} DANS VINS
– NSS DANS PERSONNE
• Contrainte d’entité
– Toute relation doit posséder au moins une clé documentée
45
Clé Etrangère
• Définition = Groupe d’attributs devant apparaître

comme clé dans une autre relation
• Les clés étrangères définissent les contraintes
d'intégrité référentielles
– Lors d'une insertion, la valeur des attributs doit exister dans
la relation référencée
– Lors d'une suppression dans la relation référencée les tuples
référençant doivent disparaître
• Elles correspondent aux liens obligatoires entre les
entités (modèle E/A)
46
Schéma
• Schéma de relation
– Définition = Nom de la relation, liste des attributs avec
domaines, et clé de la relation
– Exemple
• VINS(NV: Int, CRU:texte, MILL:entier, DEGRE: Réel,
REGION:texte)
– Par convention, la clé primaire est soulignée
• Intention et extension de relation
– L'intention de la relation = le schéma de la relation
– Une instance de table représente une extension de la
relation
• Schéma d’une BD relationnelle = l'ensemble des
schémas des relations composantes
47
Exemple de Schéma
• BUVEURS (NB, NOM, PRENOM, TYPE)
• VINS (NV, CRU, MILL, DEGRE)
• ABUS (NB, NV, DATE, QUANTITE)
BUVEURS NB NOM PRENOM TYPE VINS NV CRU MILL. DEGRE
ABUS NB NV DATE QUANTITE
• CLES ETRANGERES (italique)

–ABUS.NV référence VINS.NV
–ABUS.NB référence BUVEURS.NB
48
Métabase
DICTIONNAIRE DE DONNEES, ORGANISE SOUS
FORME RELATIONNELLE, CONTENANT LA
DESCRIPTION DES RELATIONS, ATTRIBUTS,
DOMAINES, CLES, etc.
RELATIONS NUM BASE NOM NBATT
12 PERSO EMPLOYE 4
14 PERSO DEPARTEMENT 5
1 SYS RELATIONS 4
ATTRIBUTS NUM TYPE NOM NUMREL
1 12
ENTIER NUM
2 TEXTE NOM 12
3 TEXTE PNOM 12
49
Passage de niveau conceptuel au
niveau logique
• Le modèle conceptuel est un compromis entre la flexibilité
de la langue courante et la rigueur nécessaire d’un
traitement informatisé.
• Le niveau logique est une étape de plus vers cette
informatisation
– Utilisation du formalisme du modèle relationnel :
• tables (ou relations)
• attributs
• domaine
• clefs
• contrainte d’intégrité référentielles (relations entre tables)
– Simplification du schéma de la base
• Des règles trop strictes entraînent des schémas trop complexes
• On ‘‘tolère’’ un peu de redondance ou quelques valeurs nulles....
50
Propriétés, Entités
• Règle 1 : Chaque propriété devient un attribut.
• Règle 2 : Chaque entité devient une table et son

identifiant devient sa clef primaire
• Règle 3 : Une association peut :

– être ‘‘absorbée’’ par l’une ou l’autre des entités
– devenir une table
51
Cas 1
Profs
• Un prof enseigne un et un seul
Cours
Nom 1,1 Enseigne
1,1 cours
NomCours
Prénom NbreHeures
Adresse
Description
• Un cours est enseigné par un et
un seul prof
Nom Prénom Adresse NomCours Description NbreHeures
Solution 1 Bouganim Luc Paris Info Informatique 44
Crenn Isabelle Paris Math Mathématiques 78
Rousseau Martine Versailles Droit Droit 26
Nom NomCours Nbreheures

Bouganim Info 44
Crenn Math 78
Solution 2 Rousseau Droit 26
Nom Prénom Adresse NomCours Description

Bouganim Luc Paris Info Informatique
Crenn Isabelle Paris Math Mathématiques
Rousseau Martine Versailles Droit Droit
52
Cas 2
Profs
Cours
Nom 1,1 Enseigne
0,1 cours
NomCours
Prénom NbreHeures
Adresse
Description
• Un cours est enseigné par un
prof ou n’est pas enseigné

Droit Droit
Solution 2
Nom Prénom Adresse NomCours NbreHeures NomCours Description
Bouganim Luc Paris Info 44 Info Informatique
Crenn Isabelle Paris Math 78 Math Mathématiques
Droit Droit
53
Cas 3
Profs
• Un prof enseigne un cours ou
Cours
Nom 0,1 Enseigne
1,1 aucun
NomCours
Prénom NbreHeures
Adresse
Description
un seul prof

Rousseau Martine Versailles
Solution 2
Nom Prénom Adresse
Nom NomCours Description NbreHeures
Bouganim Luc Paris
Crenn Isabelle Paris
Bouganim Info Informatique 44
Rousseau Martine Versailles Crenn Math Mathématiques 78
54
Cas 4
Profs
• Un prof enseigne un cours ou
Cours
Nom 0,1 Enseigne
0,1 aucun
NomCours
Prénom NbreHeures
Adresse
Description
prof ou n’est pas enseigné

Crenn Isabelle Paris
Droit Droit
Solution 2 Nom NomCours Nbre Heures

Bouganim Info 44

Crenn Isabelle Paris Droit Droit
55
Cas 5
Profs
Cours
Nom 1,1 Enseigne
1,n cours
NomCours
Prénom NbreHeures
Adresse
Description
ou plusieurs profs

Crenn Isabelle Paris Info Informatique 24
Rousseau Martine Versailles Droit Droit 26
Solution 2
Nom Prénom Adresse NomCours NbreHeures NomCours Description
Bouganim Luc Paris Info 20 Info Informatique
Crenn Isabelle Paris Info 24 Droit Droit
Rousseau Martine Versailles Droit 26
56
Cas 6
Profs
• Un prof enseigne un ou
Cours
Nom 1,n Enseigne
1,1 plusieurs cours
NomCours
Prénom NbreHeures
Adresse
Description
un seul prof

Crenn Isabelle Paris Math Mathématique 48
Crenn Isabelle Paris Droit Droit 26
Solution 2
Nom NomCours Description NbreHeures
Nom Prénom Adresse
Bouganim Luc Paris Bouganim Info Informatique 20
Crenn Isabelle Paris Crenn Math Mathématique 48
Crenn Droit Droit 26
57
Cas 7
Profs
Cours
• Un prof enseigne un ou
Enseigne
Nom 1,n 1,n NomCours plusieurs cours
Prénom NbreHeures
Description
Adresse • Un cours est enseigné par un
ou plusieurs profs
Crenn Isabelle Paris Info Informatique 26
Crenn Isabelle Paris Droit Droit 34
Nom NomCours Nbreheures

Bouganim Info 22
Crenn Info 26
Solution 2 Crenn Droit 34

Crenn Isabelle Paris Droit Droit
58
Cas 8
enseigne
1,n Heure 1,n
Prof Groupe
Salle
1,n
Cours
Nom NomCours Groupe heure Salle

Bouganim Info 2.1 10h A1
Crenn Math 2.1 12h A3
Crenn Info 2.2 17h A1
Bouganim Info 2.1 14h A2
Nom Prénom Adresse NomCours Description Groupe Option Responsable

Bouganim Luc Paris Info Informatique 2.1 Finance Guter Paul
Crenn Isabelle Paris Math Mathématique 2.2 Comptabilité Bourdin Jean
59
Passage au modèle relationnel - Conclusion
• Objectifs
– Ne pas créer de tables inutiles
– Ne pas dégrader le modèle conceptuel (pas de propriété
répétitive ni sans signification)
• Méthode
– Si possible, passer les propriétés de l’association dans
l’une ou l’autre des entités mais:
• Si la cardinalité minimum est 0, on ne peut le faire car, pour
certaines entités, il y aurait des valeurs nulles (ex. un prof ne
donnant pas de cours)
• Si la cardinalité maximum est n, on ne peut le faire car il y aurait
des attributs répétitif (ex. un prof donnant plusieurs cours)
– Sinon, créer une table pour l’association contenant
• les clefs des entités associées
• les propriétés de l’association 60
Algèbre relationnelle
61
Algèbre relationnelle
OPERATIONS PERMETTANT D'EXPRIMER LES
REQUETES SOUS FORME D'EXPRESSIONS
ALGEBRIQUES
• Avantages
– Concis
– Sémantique simple
– Représentation graphique
– Utile pour raisonner (cf. TD) – peu d’erreur de syntaxe !
– Utile pour l’optimisation de requêtes
62
Projection
• Elimination des attributs non désirés et suppression
des tuples en double
• Relation  Relation notée:  a1,a2,...Ap (R)
VINS Cru Mill Région Qualité

VOLNAY 1983 BOURGOGNE A
VOLNAY 1979 BOURGOGNE B
CHENAS 1983 BEAUJOLAIS A
JULIENAS 1986 BEAUJOLAIS C
Cru,Région
(VINS) Cru Région

VOLNAY BOURGOGNE
 Cru,Région (VINS) =
CHENAS BEAUJOLAIS
JULIENAS BEAUJOLAIS
63
Restriction
• Obtention des tuples de R satisfaisant un critère Q
• Relation Relation, notée Q(R)
• Q est le critère de qualification de la forme :
– Ai  Valeur,  = { =, <, ≥, >, ≤ , != }
– Il est possible de réaliser des "ou" (conjonction) et des "et" (disjonction)
de critères simples
VINS Cru Mill Région Qualité

VOLNAY 1983 BOURGOGNE A
VOLNAY 1979 BOURGOGNE B
CHENAS 1983 BEAUJOLAIS A
JULIENAS 1986 BEAUJOLAIS C
MILL>1983
 Mill>1983 (VINS) = VINS Cru Mill

JULIENAS 1986
Région
BEAUJOLAIS
Qualité
C
64
Jointure
• Composition des deux relations sur un domaine
commun
• Relation  Relation  Relation
– notée
• Critère de jointure
– Attributs de même nom égaux
• Attribut = Attribut
• Jointure naturelle
– Comparaison d'attributs
• Attribut1  Attribut2
• Théta-jointure
• Cas particulier : équi-jointure
65
Exemple de Jointure
VINS Cru Mill Qualité

VOLNAY 1983 A
VOLNAY 1979 B
CHABLIS 1983 A
JULIENAS 1986 C
LIEU Cru Région QualMoy

VOLNAY Bourgogne A
CHABLIS Bourgogne A
CHABLIS Californie B
VINSREG Cru Mill Qualité Région QualMoy

VOLNAY 1983 A Bourgogne A
VOLNAY 1979 B Bourgogne A
VINS LIEU = CHABLIS 1983 A Bourgogne A
Cru=Cru CHABLIS 1983 A Californie B
66
Exemple de -Jointure
EMPLOYES NOM DEPT SALAIRE RESPONSABLE DEPT SALAIRE
MARTIN 1 130 1 230

DURAND 1 235 2 250
DUPONT 2 280 3 300
DUPOND 3 150 270
4
EMPLOYES E RESPONSABLE R =
E.salaire > R.salaire et E.dept = R.dept
RESULTAT NOM DEPT E.SALAIRE R.SALAIRE
DURAND 1 235 230

DUPONT 2 280 250
NB : signification de la requête ?
Employés ayant un salaire supérieur à celui du responsable de leur département
67
Unions, intersections, différences
• Opérations binaires
– Relation  Relation  Relation
• Opérations pour des relations de même schéma
– UNION notée 
– INTERSECTION notée 
– DIFFERENCE notée —
• Extension pour des relations de schémas différents
– Ramener au même schéma avec des valeurs nulles
68
Union (
UNION ENSEMBLISTE POUR DES RELATIONS DE MEME SCHEMA
Exemple : VINS1  VINS2
Vins1 Cru Mill Region Couleur


CHABLIS 1985 BOURGOGNE ROUGE

Chenas 1983 Beaujolais Rouge
Tokay 1980 Alsace Blanc
Tavel 1986 Rhône Rosé
Chablis 1985 Bourgogne Rouge
69
Intersection ()
INTERSECTION ENSEMBLISTE POUR DES RELATIONS DE MEME SCHEMA
Exemple : VINS1  VINS2



Tokay 1980 Alsace Blanc
70
Différence (-)
DIFFERENCE ENSEMBLISTE POUR DES RELATIONS DE MEME SCHEMA
Exemple : VINS1 - VINS2



Chenas 1983 Beaujolais Rouge
Tavel 1986 Rhône Rose
71
Division ()
• PERMET DE RECHERCHER DANS UNE RELATION,

L’ENSEMBLE DES ‘SOUS TUPLES’ QUI SATISFONT UNE
‘SOUS-RELATION’
– inverse du produit cartésien …..
• Le quotient de la relation D(A1, …Ap, Ap+1…An) par la relation
d(Ap+1…An) est la relation Q(A1, …Ap) dont les tuples sont
ceux qui concaténés à tout tuple de d donnent un tuple de D.
– Notations  D  d = Q
72
Division () - Exemple
Compte nomAgence nomClient

 Agence NomAgence
ParisAuteuil Dupont Bellecourt

NantesCentre Queffelec Brotteaux
Bellecourt Girard LaDoua
Brotteaux Letailleur
LaDoua Girard
ParisDupleix
NantesCentre
Dutour
Passard
=
NantesCentre Martin
Bellecourt Letailleur Resultat nomClient
Brotteaux Girard Girard
LaDoua Letailleur Letailleur
LaDoua Lagaffe
73
Représentation graphique
 Union - Différence
 Projection
 Division
 Intersection
 Restriction
 Produit
critères
Jointure
cartésien
74
Récapitulatif
Produit
Sélection Projection
Union
Intersection
a x a x
b y a y
c b x
b y
c x
c y
Jointure Naturelle Division Différence
a1 b1 b1 c1 a1 b1 c1 a x x a
a y y
a2 b1 b2 c2 a2 b1 c1 a z
b x
a3 b2 b3 c3 a3 b2 c2 c y
75
Autres opérateurs
Renomage ()
Permet de renommer des attributs
Notation :  a1:b1, …, an:bn (Rel)
Affectation ()
Affecte une expression à une relation temporaire
Notation : Temp  Expression_relationnelle
Exemple : Temp  r – s
76
SemiJoin, AntiJoin, OuterJoin
• SemiJoin
• AntiJoin
• Left OuterJoin
• Right OuterJoin
77
Exercice 1 : modélisation
• A partir des règles de design proposées sur le sujet

d’exercice, établir le MCD en utilisant le modèle E/A
• Vous lirez toutes les règles de design avant de
commencer
• Mode opératoire de l’exercice : traiter les règles par
groupes successifs, en faisant abstraction des règles
restantes
78
Division
Division EmployéEmployé
Employé
1-n
1-n Code
1-1 Est dirigée 0-1 1-1
NumDiv
NumDiv Travaille Matricule Matricule postal
Travaille 0-1 0-1Matricule
SalaireEmp
Personne
dans
NomDiv
NomDiv NomEmp
SalaireEmp 1-1 Est1
1-n DateNaissEmp
PrénomEmp 1-1 CP 0-1
Travaille 1-1 1-11-1
DateNaissEmp IdPers 1-n
AdresseVoie 1-1
SalaireEmp Nom
AdresseCPN°DsRueEmp 0-1 Prénom Ville
Fonction Tel
1-n TelEmp N°DsRue
Fonction
a la 1-1 1-n
1-n
1-n a la DateNaissEmp 0-n Tel Ville
Fonction Est2
NumFonc
NumFonc 1-n Client Dans la
a 1-n 1-1
DescFonc
DescFonc habite rue1 Rue
NumFonc 0-n 0-n Client 1-n
Prime
Prime NumCli
Client 1-1
DescFonc Rédige
1-1 1-n Ds
Prime (taux) 1-n NumCli 1-1 IdRue
1-nNumCli Rue dans
NomRue
Rédige NomCli
Réalise Nom Dans la 1-n CP1-n
0-n PrénomCli
1-1 Passée
directement Prénom 1-1 rue2 1-n 1-n
Vente
Vente 1-1 1-1 N°DsRueCli habite
AdresseVoie Rue 1-1
TelCli
NumVente 1-1 AdresseCP 0-1 1-n Pays
NumVente Messager
DateVente
DateVente 1-1
Exercice de conception Tel Livrée à IdRue
Correction de l’exercice de conception

1-1 Livraison Dans
DateLivrVente
DateLivr Passée NumMess Dans lahabite 0-1 NomRue
Pays
CP
NumLiv--- Nom
FraisPort
FraisPort 1-1 1-1 rue3
1-1 1-n
1-1 1-n 1-1
NumVente
1-n
1-n
DateVente
NomLiv
--- Prénom
DateLivr Quelques
1-1 modèles Entité
PrénomLiv
1-n
N°DsRue Associations
AdresseVoie
AdresseCP possibles
1-n 1-n Dans11-n
FraisPort
Concern
Concern
Quelques 1-1 modèles Entité
Livrée à Livre
TelLiv Associations
Tel Dans lapossibles
Est3
rue4 habite
Ville
1-n
IdVille
e e 1-1
1-n Ville
NomVill
Messager
Messager 1-1
Destinataire habite
e
Qté
Qté 1-n1-n Est4 IdVille 1-1
Remise
Remise NumMess
NumMess Dans la
NumDest 1-1 NomVill
NomMess rue5
0-n
0-n Nom 1-1 e
Livrée
1-n N°DsRueMess Prénom 1-1
Livrée parpar TelMess Dans
Produit
Produit AdresseVoie
1-1
AdresseCP Fournisseur Dans2
NumProd
NumProd Fournisseur
Fournisseur Tel
1-1
NomProd Produit NumFour 1-n
NomProd
1-1 Concerne Nom 1-n
PrixUnitaire
PrixUnitaire 1-1 NumFour
NumFour
0-n parpar
fourni
fourni NumProd 1-n 1-1
NomFour fourni par 1-n Prénom Pays
Pays
Qté
NomProd 1-n PrénomFour AdresseVoie
Remise
PrixUnitaire N°DsRue AdresseCP IdPays
IdPays
TelFour Tel NomPay
NomPay
s s 79
Division Employé
Code
NumDiv Matricule postal
NomDiv SalaireEmp
Directeur DateNaissEmp CP
AdresseVoie Ville
AdresseCP Ville
Tel
Division Ville
Fonction Fonction Pays
Adresse
NumFonc Client
DescFonc
Prime (taux) NumCli
Nom
Prénom
AdresseVoie
AdresseCP Pays
Correction de l’exercice de conception
Tel Messager
Adresse Pays
Vente NumMess
NumVente
--- Nom
Prénom
DateVente
DateLivr Quelques
Passage
modèles
au Modèle
Entitélogique
Associations
AdresseVoie
AdresseCP (relationnel)
possibles
FraisPort Tel
Vendeur Adresse
Acheteur
Livreur
Destinataire
Destinataire
NumDest
Nom
Prénom
AdresseVoie
AdresseCP Fournisseur
Tel
Detail Produit Adresse NumFour
Nom
NumVente NumProd Prénom
NumProd NomProd AdresseVoie
Qté PrixUnitaire AdresseCP
Remise Fournisseur Tel
Adresse 80
Exercice 2 : algèbre
• 3 exercices d’algèbre vous sont proposés

• Nous ferons le premier à l’oral
• Pour les autres, nous commençons en séance et vous
finirez pour demain
81
Langages
Langage SQL
Langages de progr. SGBD
TP : création de BD et manipulation SQL
Yaoundé, février 2014 Nicolas Anciaux

82
Le langage SQL
Structured Query Langage
83
SQL : pour quoi faire (1) ?
• Avant SQL, rechercher des données satisfaisant une
qualification ressemblait à :
Select B.plage
From Nageurs N, Baignade B
Where N.qualité = ‘excellent’
and B.date between ‘O1-08-89’
and ’31-08-89’and N.idn = B.idn
84
SQL : pour quoi faire (2) ?
• Une interface plus simple pour les utilisateurs ?
– La majorité des manipulations utilisateurs se font via des
formulaires !
– Mais rend possible les requêtes libres (ex: analyse)
• Simplifier le développement des applications
– Code plus compact et facile à valider/maintenir
– Indépendance physique et logique des programmes par
rapport aux données
– Optimisation automatique et dynamique des requêtes par
le SGBD
• Une puissance d’expression exploitable de nb
façons
– Sélection, mises à jour, intégrité, droits d’accès, audit … 85
Le standard SQL (1)
• Trois versions normalisées de SQL :
– SQL1 (1986) : version minimale
– SQL1 (1989) : addendum (intégrité)
– SQL2 (1992) : version étendue à trois niveaux de conformité

(entry, intermediate, full)
– SQL3 (1999) : version étendue à la gestion d’objets

complexes
– SQL3 (2003) : introduction de fonctions de manipulation

XML
86
Le standard SQL (2)
LANGAGE DE DEFINITION DE DONNEES
CREATE TABLE
LANGAGE DE CONTROLE
CREATE VIEW
ALTER ….
GRANT
...
REVOKE
COMMIT WORK
LANGAGE DE MANIPULATION DE DONNEES ROLLBACK WORK
SELECT
INSERT
UPDATE
DELETE
INTEGRATION AUX LANGAGES DE PROGRAMMATION

EXEC SQL
MODULE
PROCEDURE ...
87
LDD : Langage de Définition de Données
Création, modification du schéma
88
EXEMPLE DE BASE DE DONNEES
89
Création de table
CREATE TABLE <nom_table>
(<def_colonne> * [<def_contrainte_table>*]) ;
< def_colonne > ::= <nom_colonne> < type > [CONSTRAINT nom_contrainte <
NOT NULL |
UNIQUE |
PRIMARY KEY |
CHECK (condition) |
REFERENCES nom_table (colonne) > ]
< def_contrainte_table > ::= CONSTRAINT nom_contrainte <

UNIQUE (liste_colonnes) |
PRIMARY KEY (liste_colonnes) |
CHECK (condition) |
FOREIGN KEY (liste_colonnes) REFERENCES nom_table (liste_colonnes)>
90
Exemple de création de table
CREATE TABLE RDV(
NumRdv Integer,
DateRDV Date,
NumDoc Integer,
NumPat Integer,
Motif Varchar(200),
CONSTRAINT Clé_Primaire_RDV PRIMARY KEY (NumRdv),
CONSTRAINT Référence_DOC FOREIGN KEY (NumDoc) REFERENCES
DOC,
CONSTRAINT Référence_PAT FOREIGN KEY (NumPat) REFERENCES PAT);
L'association d'un nom à une contrainte est optionnelle. Ce nom peut être utilisé
pour référencer la contrainte (ex: messages d'erreurs).
91
Index, modification du schéma
• Création d’index
– CREATE [UNIQUE] INDEX nom_index ON nom_table (<nom_colonne> * );
• Suppression
– DROP TABLE <nom_table>
– DROP INDEX <nom_index>
• Modification
– ALTER TABLE <nom_table> ADD COLUMN <def_colonne>
– ALTER TABLE <nom_table> ADD CONSTRAINT <def_contrainte_table >
– ALTER TABLE <nom_table> MODIFY <def_colonne>
– ALTER TABLE <nom_table> DROP COLUMN <nom_colonne>
– ALTER TABLE <nom_table> DROP CONSTRAINT <nom_contrainte >
• Exemples
– CREATE INDEX Index_date_RDV ON RDV (DateRDV) ;
– ALTER TABLE RDV ADD COLUMN Commentaires varchar(300);
– ALTER TABLE RDV ADD CONSTRAINT MotifNN NOTNULL(Motif);
92
LMD : Langage de Manipulation des Données
(INSERT, DELETE , UPDATE)
93
Insertion de données : INSERT
INSERT INTO < nom_table >
[( attribute [,attribute] … )]
{VALUES (<value spec.> [, <value spec.>] … ) |
<query specification>} ;
• Exemples :
– INSERT INTO DOC VALUES (1, ‘Dupont’, ‘Paris’);
– INSERT INTO DOC (NumDoc, NomDoc) VALUES (2, ‘Toto’);
– INSERT INTO PAT (NumPat, NomPat, VillePat)
SELECT NumDoc, NomDoc, VilleDoc FROM DOC;
94
Mise à jour : UPDATE
SYNTAXE :
UPDATE <relation_name>
SET <attribute> = value_expression [, <attribute> =
value_expression ] …
[WHERE <search condition> ];
EXEMPLES :
Mettre “Inconnue” quand VilleDoc n’est pas renseignée
UPDATE DOC SET VilleDoc = “Inconnue” WHERE VilleDoc IS NULL
Mettre en majuscule le nom des docteurs qui n’ont jamais prescrit

UPDATE DOC SET NomDoc = UPPER(NomDoc) WHERE NumDoc NOT IN
(SELECT NumDoc FROM ORD)
ATTENTION AUX CONTRAINTES D’INTEGRITE REFERENTIELLES !!!
95
Suppression : DELETE
SYNTAXE :
DELETE FROM <relation_name>
[WHERE <search_condition>];
EXEMPLES :
Supprimer les docteurs quand VilleDoc n’est pas renseignée
DELETE FROM DOC WHERE VilleDoc IS NULL
Supprimer les docteurs qui n’ont jamais prescrit

DELETE FROM DOC WHERE NumDoc NOT IN (SELECT NumDoc FROM ORD)
ATTENTION AUX CONTRAINTES D’INTEGRITE REFERENTIELLES !!!
96
SELECT : forme générale
SELECT [DISTINCT| ALL] { * | <value exp.> [, <value exp.>]...}

FROM relation [alias], relation [ alias]…
[WHERE <search condition>]
[GROUP BY <attribute> [,<attribute>]...]
[HAVING <search condition>]
[ORDER BY <attribute> [{ASC | DESC}] [,<attribute>[{ASC | DESC}] ]...]
* EXPRESSION DE VALEURS * CONDITION DE RECHERCHE

- Calculs arithmétiques - Sélection, projection, jointure
- Fonctions agrégats - Recherche textuelle
- Recherche par intervalle
- Recherche sur valeur nulle
97
Forme générale de la condition de recherche
<search condition> ::= [NOT]

<nom_colonne> IS [NOT] NULL
<nom_colonne>  constante  <nom_colonne>
<nom_colonne> LIKE <modèle_de_chaîne>
<nom_colonne> IN <liste_de_valeurs>
<nom_colonne>  (ALL  ANY/SOME) <liste_de_valeurs>
EXISTS <liste_de_valeurs>
UNIQUE <liste_de_valeurs>
<tuple> MATCH [UNIQUE] <liste_de_tuples>
<nom_colonne> BETWEEN constante AND constante
AND  OR <search condition>
avec
 ::= <  =  >     <>
Remarques:
<liste_de_valeurs> et <liste_de_tuples> peuvent être déterminés par une requête
<tuple> ::= (<nom_colonne> [,<nom_colonne>]…)
98
Projections et restrictions simples
Liste des médicaments de plus de 500 FF  NomMed

SELECT NomMed FROM MED WHERE Prix> 500 ;
Liste des médicaments de plus de 100 €  NomMed (prix stocké en FF)

SELECT NomMed FROM MED WHERE Prix/6,55957 > 100 ;
Nom des docteurs de LAON  NomDoc

SELECT NomDoc FROM DOC WHERE VilleDoc = “Laon”
Quelles ont été les motifs de consultations de 25/12/2006 Motif

SELECT DISTINCT Motif FROM RDV WHERE DateRDV = #25/12/2006#
99
Restrictions complexes et jointures
Liste des patients ayant un RDV avec le docteur "Dupont"  NomPat
SELECT DISTINCT PAT.NomPat FROM PAT, RDV, DOC
WHERE PAT.NumPat = RDV.NumPat and RDV.NumDoc = DOC.NumDoc
and DOC.NomDoc like “dupont”;
Médicaments commençant par « ASPI » prescrits le 25/12/2006  NomMed

SELECT DISTINCT M.NomMed FROM MED M, DET D, ORD O
WHERE M.NumMed = D.NumMed and D.NumOrd = O.NumOrd
and O.Date = #25/12/2006# and NomMed like “ASPI%”;
Docteurs ayant le même nom qu’un patient  NomDoc

SELECT D.NomDoc FROM PAT P, DOC D WHERE P.NomPat = D.NomDoc;
100
Requêtes imbriquées : IN et EXIST
Liste des patients ayant un RDV avec le docteur "Dupont"  NomPat
SELECT DISTINCT P.NomPat FROM PAT P, RDV R, DOC D
WHERE P.NumPat = R.NumPat and R.NumDoc = D.NumDoc and D.NomDoc = “Dupont”;
SELECT P.NomPat FROM PAT P WHERE P.NumPat in

(SELECT R.NumPat FROM RDV R WHERE R.NumDoc in
(SELECT D.NumDoc FROM DOC WHERE D.NomDoc = “Dupont”));
SELECT P.NomPat FROM PAT P WHERE EXISTS

(SELECT * FROM RDV R WHERE P.NumPat = R.NumPat and EXISTS
(SELECT * FROM DOC D WHERE R.NumDoc=D.NumDoc and D.NomDoc = “Dupont”));
SELECT P.NomPat FROM PAT P WHERE EXISTS

(SELECT * FROM RDV R WHERE EXISTS
(SELECT * FROM DOC D WHERE P.NumPat = R.NumPat and R.NumDoc = D.NumDoc
and D.NomDoc = “Dupont”));
101
Calculs d'agrégats
Les fonctions d’agrégation (Count, Sum, Avg, Min, Max) permettent de
réaliser des calculs sur des ensembles de données
• Calcul de statistiques globales

– Nombre de patients : SELECT count(*) FROM PAT
– Prix moyen des médicaments : SELECT avg(Prix) FROM MED
• Calcul de statistiques par groupe

– Nombre de patients par ville :
SELECT VillePat, count(*) NbPatient FROM PAT GROUP BY VillePat
– Nombre de patients par ville ayant consulté pour un mal de tête

SELECT VillePat, count(DISTINCT(NumPat)) NbPatient FROM PAT, RDV
WHERE PAT.NumPat = RDV.NumPat and Motif = ‘mal de tête’ GROUP BY VillePat
– Ville où plus de 10 patients ont consulté pour un mal de tête

SELECT VillePat FROM PAT, RDV
WHERE PAT.NumPat = RDV.NumPat and Motif = ‘mal de tête’
GROUP BY VillePat
HAVING count(DISTINCT(NumPat)) > 10
102
Agrégats : autres exemples et exercices
• Nom du(des) médicament(s) le(s) moins cher(s)
SELECT NomMed FROM MED
WHERE Prix = SELECT MIN(Prix) FROM MED
• Total des prix des médicaments prescrits par patient

SELECT P.NomPat, sum(M.prix * D.Qté) PrixTotal
FROM PAT P, ORD O, DET D, MED M
WHERE M.NumMed = D.NumMed AND D.NumOrd = O.NumOrd AND O.NumPat = P.NumPat
GROUP BY P.NomPat
• Moyenne du : Total des prix des médicaments prescrits par patient …

SELECTAVG(TMP.PrixTotal)
FROM (
SELECT P.NomPat, sum(M.prix * O.Qté) PrixTotal
FROM PAT P, ORD O, DET D, MED M
WHERE M.NumMed = D.NumMed AND D.NumOrd = O.NumOrd AND O.NumPat = P.NumPat
GROUP BY P.NomPat
) TMP
103
Union/Intersection/Différence
<requêteSQL_A>
UNION | INTERSECT | EXCEPT
CORRESPONDING précise que l’intersection se fait sur
[ALL] le nom des colonnes et non sur leur position…
[CORRESPONDING [BY <liste_de_colonnes>]]

<requêteSQL_B>
BY liste de colonnes précisée réduit « l’assiette » de
l’opération au sous-ensemble spécifié de colonnes…
[ALL] permet de conserver les doublons dans le résultat

[CORRESPONDING BY] n’est en général pas implanté
(mais peut etre remplacé par une jointure)
104
Union/Inter°/Diff. : exemples et exercices
• Ensemble des personnes de la base médicale
SELECT NomDoc NomPers FROM DOC
UNION
SELECT NomPat NomPers FROM PAT
• Patients qui sont aussi médecins

SELECT NomPat PatDoc FROM PAT
INTERSECT
SELECT NomDoc PatDoc FROM DOC
• Patients qui ne sont pas médecins

SELECT NomPat Patient FROM PAT
EXCEPT
SELECT NomDoc Patient FROM DOC
105
Des différences selon le SGBD…
Access SQL Server Oracle
GROUP BY Y Y Y
HAVING Y Y Y
UNION Y Y Y
INTERSECT N N Y
EXCEPT N N Y (MINUS)
CORRESPONDING BY N N N
106
Jointure Interne / Externe
Évite d’écrire la condition de jointure

(clause d’égalité sur les colonnes de même nom…)
<Join_expression> ::=
<table-ref> [NATURAL] [<join_type>] JOIN <table-ref>
[ON <condition>  USING <nom_colonne> *]
USING precise le sous-ensemble des colonnes
communes à considérer dans la jointure
<table-ref> CROSS JOIN <table-ref> (NB: remplace le ON…)
Produit cartésien
<join_type> ::= (INNER JOIN avec clause toujours vrai)
INNER OUTER est optionnel dans la syntaxe (même fonctionnalité)

LEFT [OUTER]
RIGHT [OUTER] OUTER produit certains tuples ne joignant pas…
FULL [OUTER]
…LEFT… UNION…RIGHT…
107
Méthodologie SQL
108
Évaluation « sémantique » d’une requête SQL
1. FROM
Réalise le produit cartésien des relations
2. WHERE
Réalise restriction et jointures
3. GROUP BY XXX
Constitue les partitions XXX
(e.g., tri sur l’intitulé du groupe) YYY
ZZZ
4. HAVING XXX
XXX
AGG1
Restreint aux partitions désirées YYY AGG2
ZZZ AGG3
5. SELECT
AGG1 XXX
Réaliser les projections/calculs finaux
AGG3 ZZZ
6. ORDER BY
Trier les tuples résultat AGG1 ZZZ
AGG3 XXX
109
Utiliser l’algèbre relationnelle
• En s’entraînant un peu, il semble plus facile d’écrire une requête en algèbre puis de
la traduire en SQL
– Cette traduction s’effectue de manière systématique et peut générer des expressions un
peu ‘lourde’. Toutefois, elle permet de bien comprendre la requête
– Certaine requêtes ne peuvent s’exprimer en algèbre
(Ex: contenant des calculs d’agrégats, groupements)
Toutefois, on peut souvent en exprimer une partie en algèbre…
– La traduction des opérateurs d’algèbre est assez simple (excepté pour la division)
• Sélection = <critère>(R)  select * from R where <critère>;

• Projection = <liste>(R)  select <liste> from R;
• Jointures (naturelle/théta) = R <critère>S = select * from R, S where <critere>;
• Union/Intersection/Différence  opérateur UNION/INTERSECT/EXCEPT…
• Division  double négation, expression relationnelle de la division…
110
Traduction des divisions : double négation
• On veut diviser R(A1,...,Ap,...,An) • La logique sur un exemple…
par Q (A1, ..., Ap)
• Nom des docteurs qui ont prescrit
• Et obtenir S (Ap+1, ....., An) tous les médicaments
• NomDoc,NumMed(DOC  VIS  ORD
Select Ap+1, ...., An from R R1  MED) %  NumMed MED
where not exists ( • Equivalent à: Nom des docteurs
select * from Q tels qu’il n’existe pas de
where not exists ( médicaments tel qu’il n’existe pas
select * from R R2 de prescription de ces
where R2.A1 = Q.A1 médicaments faites par ces
and R2.A2 = Q.A2 docteurs
and ....
SELECT NomDoc,
and R2.Ap = Q.Ap FROM DOC WHERE NOT EXIST(
and R2.Ap+1 = R1.Ap+1 SELECT * FROM MED WHERE NOT EXIST(
SELECT * FROM VIS, ORD
and .... WHERE DOC.NumDoc=VIS.NumDoc AND
and R2.An = R1.An )) VIS.NumVis=ORD.NumVis AND
ORD.NumMed=MED.NumMed
)
);
111
Comprendre le schéma et les questions
• Avant de se lancer dans l’écriture d’une requête, il faut bien
comprendre le schéma des tables sur lequel on va s’appuyer
• Si le schéma est complexe, il faut le dessiner, c.a.d. dessiner
les tables et les relations entre ces tables
• En lisant la question, on repère sur le schéma dans quelle(s)
relation(s) se trouve chaque donnée. On a alors une idée des
tables mises en jeu
• Si la question est complexe, il faut la reformuler et/ou la
décomposer.
• Une fois ce travail effectué, on peut commencer a écrire du
SQL.
112
Vérifier les clauses de jointure
• Il est assez facile d’oublier une clause dans les
prédicats de sélection, surtout lorsque l’on joint
plusieurs tables.
• Pour le vérifier, une règle simple pour les requêtes
plates (nécessaire mais non suffisante) :
– Une requête impliquant n tables doit posséder au moins (n-
1) prédicats de jointure (outre les prédicats de sélection).
113
Reformuler les questions : se rapprocher de la BD
• Paraphrasage :
– En exprimant de manière plus détaillée une requête, elle devient plus
claire... (ou plus facilement exprimable)
• Exemple : Qui est dans la base ?

 Ensemble des personnes de la base médicale
 Nom des médecins et nom des patients
 Union des noms des médecins et des noms des patients
SELECT NomDoc NomPers FROM DOC

UNION
SELECT NomPat NomPers FROM PAT
114
Reformuler les questions négatives
• Souvent l’inverse de la requête est plus facile à exprimer. Cela est particulièrement
vrai lorsque la requête contient :
• Que
– Dans quelle ville n’y a-t-il QUE des patients de plus de 40 ans?
– Toutes les villes (où il y a au moins un patient de plus 40 ans), moins les villes où il y a un
patient de 40 ans ou moins
• Aucun
– Dans quelle ville n’y a-t-il AUCUN patient de plus de 40 ans?
– L’ensemble des villes, moins celles où il y a au moins un patient de plus de 40 ans
• Tous (conduisant à une division relationnelle…)
– Quels sont les patients qui ont RDV avec TOUS les médecins
– Les patients pour lesquels il n’existe pas de docteur avec qui ils n’ont pas de RDV
• Tous
– Quels sont les patients dont TOUS les motifs de rendez vous sont « mal de tête »
– L’ensemble des patients qui ont un RDV pour un « mal de tête », moins les patients qui ont
un RDV pour un motif différent de « mal de tête »
115
Décomposer les questions complexes
• En décomposant, on simplifie la compréhension et on diminue

les risques d’erreurs :
– Quels sont les patients dont tous les motifs de rendez vous sont « mal
de tête »
• Paraphrase :
– L’ensemble des patients qui ont un RDV pour un mal de tête moins ceux
qui ont un RDV pour un motif différent
• Décomposition :
– Create view V1 AS …. (patients qui ont un RDV pour un mal de tête)
– Create view V2 AS …. (patients qui ont un RDV pour un motif ≠ mal de
tête)
– SELECT NomPat FROM V1 EXCEPT SELECT NomPat FROM V2
116
Vérifier les instance de tables à impliquer
• Il faut parfois utiliser plusieurs instances de la même table
Comment savoir?
• Lorsqu’une même table est utilisée pour obtenir deux informations de
‘sémantique différente’ (2 instances différentes d’entité)
 il faut prendre plusieurs instances de cette table
• Exemple :
Nom des patients ayant eu des RDV avec les docteurs "Dupont" et "Durand"
RDV (R1) DOC (D1)  Dupont
PAT (P)
RDV (R2) DOC (D2)  Durand
SELECT DISTINCT P.NomPat

FROM PAT P, RDV R1, DOC D1, RDV R2, DOC D2
WHERE P.NumPat = R1.NumPat AND R1.NumDoc = D1.NumDoc AND D1.NomDoc =
“Dupont”
AND P.NumPat = R2.NumPat AND R2.NumDoc = D2.NumDoc AND D2.NomDoc =
“Durand”;
117
Eliminer les doublons sémantiques
• Deux types de doublons peuvent apparaître
– plusieurs réponses sont identiques
– plusieurs réponses sont ‘sémantiquement équivalentes’
• Les premiers s’éliminent en utilisant la clause distinct.
Attention toutefois à son utilisation...
• Le deuxième cas se produit lorsque l’on demande des
combinaisons (ex: couples de personnes, ensemble de 3
pièces etc...). Le résultat (A,B) est ‘sémantiquement
équivalent’ à (B,A).
– Dans ce cas, il suffit d’utiliser un prédicat > entre chaque
composantes afin de n’obtenir qu’une seule des combinaisons
équivalentes :
SELECT P1.Nom, P2.Nom
FROM Personne P1, Personne P2
WHERE P1.Nom > P2.Nom
118
Tester les requêtes (1)
• Quand une requête est vraiment complexe, on peut, malgré
tout, avoir un doute sur la solution trouvée. Dans ce cas, il faut
créer l’extension d’une base de test afin de vérifier la validité de
la requête.
• Preuve par l’exemple :

– Un résultat positif ne prouve rien (c’est probablement juste...)
– Un résultat négatif prouve que la requête est fausse
• Comment trouver l’extension la plus ‘sensible’ possible ?

– C’est à dire, l’extension de taille minimum comportant tous les cas et
garantissant la validité de la requête
– Le problème est presque aussi complexe que la résolution de la requête
elle-même
(mais souvent le fait d’aborder la requête de cette manière permet de
mieux la comprendre…)
119
• Exemple 1 : Les couples de parents ayant au moins deux enfants?
– Dans la base de test il faut avoir :
• des couples de parents qui ont 1, 2 et 3 enfants
• et des parents seuls (ayant 2 et 3 enfants)
• Exemple 2 : Producteurs qui ne voient que les films qu’ils produisent
– Les producteurs qui voient au moins 1 film qu’ils produisent, moins ceux qui voient au
moins 1 film qu’ils ne produisent pas
Réponse :
SELECT DISTINCT P.Nom FROM Producteur P, Spectateur S WHERE P.Titre = S.Titre AND P.Nom = S.Nom
MINUS
SELECT DISTINCT P.Nom FROM Producteur P, Spectateur S WHERE P.Titre = S.Titre AND P.Nom != S.Nom
Est-ce correct ?
– Dans la base de test il faut avoir :
• un producteur qui ne voit aucun film
• un producteur qui ne voit que des films qu’il produit
• un producteur qui voit des films qu’il produit et d’autres
• Attention, cette base n’est pas forcément suffisante....
120
MINUS
Producteur.Nom Producteur.Titre Spectateur.Nom Spectateur.Titre

Nom1 Titre1 Nom1 Titre1 Producteur Nom1 qualifié, ne voit
Nom2 Titre2 Nom2 Titre1 que le film qu’il produit.
… … … … Producteur Nom2 non qualifié…
Producteur.Nom Producteur.Titre Spectateur.Nom Spectateur.Titre

Nom1 Titre1 Nom1 Titre1
Producteur.Titre
Un spectateur
Producteur.Nom Spectateur.Nom Spectateur.Titre
voit le film du
producteur…
Nom2 Titre2 Nom1 Titre1  Resultat = 
Le 2ème membre devrait être: SELECT Nom,Titre FROM Spectateur MINUS SELECT Nom,Titre FROM Producteur
121
Programmation SQL
(OBDC/JDBC, PL/SQL, Triggers)
122
Programmation SGBD: objectif
• Comment passer une commande dans la base telle que :
PROCEDURE COMM
Si le client n’est pas encore dans la base
 Insérer les informations du client dans la table client
Si l’article est disponible dans la quantité commandée
ET le livreur disponible à la date de livraison désirée
 Insérer sa commande dans la base
Sinon abandonner la commande
*cette procédure peut être déclenchée par un trigger !

• Impossible en SQL pur (SQL n’est pas un langage complet)
– Pas de structure de contrôle : itérations, tests …
– Besoin d’un langage complet pour programmer des actions sur les BD
• Les différentes possibilités
– Solution 1: Utiliser un langage propriétaire
Exemple : PL/SQL Oracle, TSQL MS-SQLServer
… Langage fourni par l’éditeur du SGBD
… pour créer des procédures stockées coté serveur
– Solution 2: Utiliser un langage traditionnel (C, C++, Java, Cobol, …)
...qui puisse parler avec la BD (avec SQL grâce à SQL CLI, JDBC, ODBC, …)
123
Programmation SGBD: outils
• Utiliser un langage « SGBD » propriétaire (fourni par l’éditeur)
– Ex: PL/SQL Oracle, PL/pgSQL (PostgreSQL), T-SQL (SQLServer), …
– Extension de SQL à des éléments de programmation procédurale
• Instructions conditionnelles, itérations, variables, etc.
• Utiliser un langage traditionnel
– Qui appelle des API Propriétaires fournies par l’éditeur de SGBD
• Ex: OCI (Oracle), DB-Lib (Sybase), …
• Programme écrit dans un langage classique (C, C++, Cobol, etc.)
… avec des appels à ces API non standards fournies par l’éditeur du SGBD
– Qui appelle des API indépendantes du SGBD
• SQL-CLI (Call Level Interface)
• Popularisé par les médiateurs ODBC, JDBC
– Embedded SQL (générateur de code + API propriétaires)
• Ex: Pro*C (Oracle), ECPG (Postgres), Pro*Cobol (Oracle), etc…
• Programme écrit dans un langage classique (C, C++, Cobol, etc.)
… avec des instructions SQL directement dans le programme
• Précompilation : le source (ex: C+SQL) …
… est transformé en code compilable (ex: C pur)
• Suivi d’une compilation classique (ex: C pur)
124
Solution 1 : exemple de PL/SQL Oracle
• Structure d’un bloc PL/SQL Oracle:
– Bloc de déclaration de variables:
DECLARE
<liste des variables utiles au programme>
– Suivi d’un bloc d’instructions et exceptions:
BEGIN
<liste d’instructions du programme PL/SQL>
[ EXCEPTION
<instructions exceptionnelles> ]
END;
/
125
Types et variables PL/SQL
• Déclaration des variables dans le bloc declare
– Types SQL de base : CHAR, NUMBER, DATE... + type BOOLEAN
– Typage explicite ou implicite (avec table.col%TYPE)
– Type Curseurs (cf. plus loin) : pour parcourir le résultat d’une
requête SQL
DECLARE
maVar VARCHAR2 DEFAULT ‘ROUGE’;
maVar Personne.nom%TYPE; -- type de l’attribut concerné
maVar Personne%ROWTYPE; -- type RECORD
maVar MonCurseur%ROWTYPE; -- type RECORD
• Affectation de valeur
– Dans toutes les sections avec l’opérateur := maVar := 2;
– Dans la section begin end avec l’opérateur into

Select max(table.col) into maVar from table;
126
Structures de contrôle PL/SQL
• Traitement conditionnel
IF condition THEN traitement1
[ELSIF condition THEN traitement2]
[ELSE traitement3]
END IF;
• Itérations
WHILE condition LOOP
traitement
END LOOP;
FOR i IN 1..n LOOP

traitement
END LOOP;
LOOP
traitement
EXIT WHEN condition END LOOP;
127
Curseurs PL/SQL : utilisation
• Résultat d’une requête SQL géré comme un fichier
– Déclaration: DECLARE
CURSOR monCurseur IS requête_SQL;
– Manipulation:
• Commandes : OPEN, FETCH, CLOSE
• Utilisation des attributs de curseur : %NOTFOUND, %ISOPEN …
DECLARE
CURSOR dept_10 IS SELECT Nom, Salaire
FROM employes WHERE NumDept = 10;
tuple dept_10%ROWTYPE;
BEGIN
OPEN dept_10;
LOOP
FETCH dept_10 INTO tuple;
.........
EXIT WHEN(dept_10%NOTFOUND) END LOOP;
CLOSE dept_10;
END;
128
Curseurs PL/SQL : utilisation simplifiée
• Dans la pratique
– Déclaration implicite du curseur
– Déclaration implicite de l’enregistrement récepteur
– Ouverture et fermeture du curseur implicites
– Ordre de lecture pas à pas fetch implicite
– Condition de sortie implicite
BEGIN
FOR tuple IN
(SELECT Nom, Salaire FROM employes WHERE NumDept = 10)
LOOP
.........
END LOOP;
END;
129
Curseurs PL/SQL : exemple
• Augmente de 5% le salaire des employés du service
compta…
DECLARE
BEGIN
FOR Emp IN (SELECT nom, salaire FROM Employe WHERE service =
‘comptabilité’) LOOP
IF Emp.salaire IS NOT NULL AND Emp.Salaire < 30.000 THEN
UPDATE Employe SET salaire = salaire*1,05 WHERE nom = Emp.nom;
END IF;
END LOOP;
END;
130
D’autres fonctionnalités importantes
• Exceptions
– Levées par le SGBD
– Définies par le programmeur PL/SQL
• Procédure et fonctions
– Stockées sous forme compilée dans la BD (objet de la base)
– soumise aux mécanismes de sécurité ou de confidentialité
• Partagées par plusieurs applications et utilisateurs
• à condition d’avoir le privilège EXECUTE
• Packages
• Regroupement de procédures, fonctions, exceptions dans
un objet de la BD
131
Solution 2 : exemple de Java/JDBC
• Comment passer une commande dans la base telle que :

PROCEDURE COMM
Si le client n’est pas encore dans la base
 Insérer les informations du client dans la table client
Si l’article est disponible dans la quantité commandée
ET le livreur disponible à la date de livraison désirée
 Insérer sa commande dans la base
Sinon abandonner la commande
*cette procédure peut être déclenchée par un trigger !
 Solution 2 : Exemple de la solution Java/JDBC

– JDBC (Java DataBase Connectivity)
• vue “objet” des mêmes concepts que ODBC
• un pont JDBC-ODBC existe
– Repose sur SQL-CLI (Call Level Interface) tout comme ODBC
• API standardisée par X/Open depuis 1994, intégrée dans SQL3
• Permet de se connecter et d’envoyer des requêtes SQL à tout serveur
SQL, quel que soit son type, sa localisation, le mode de connexion ...
132
Architecture logicielle de JDBC
• Chaque BD utilise un pilote (driver) qui convertit les requêtes
JDBC dans le langage natif du SGBD
Programme Java indépendant du SGBD cible
Applications multi-bases possibles Ensemble de classes et
d’interfaces Java
Java Appli/Applet
API
JDBC
JDBC DriverManager
API du
Driver
JDBC
Driver(pont) driver Driver driver
JDBC-ODBC JDBC JDBC SGF local
pour pour
driver Oracle Sybase Implémentation
ODBC des interface
protocole Propriétaire JDBC fournies par
protocole Propriétaire Fichier les éditeurs SGBD
Oracle Sybase
Oracle Sybase
133
Exemples d’utilisations de JDBC
• Dans un client léger classique
API
JDBC
Applet
Driver
JDBC BD
API JDBC
Driver
Clients JDBC Serveur
• Dans une architecture J2E
API Web API

(TCP/IP) JDBC
Applet Servlet Driver

BD
JDBC JDBC
Clients API
Serveur Web Driver
JDBC Serveur BD
134
L’API JDBC
• API fournie par le package java.sql (le noyau)
• Interfaces (principales) du package
– Connection // gestion des connexions
– Statement // exécution de requêtes classiques
– PreparedStatement // préparation de requêtes
dynamiques
– CallableStatement // appel de procédures stockées
– ResultSet // manipulation du résultat
– ResultSetMetaData // description du résultat
– DatabaseMetaData // description de la base
– Driver // gestion des pilotes
• Les extensions dans javax.sql 135
Utilisation de JDBC
Etapes à suivre
(Importer le package java.sql)

• Charger le driver JDBC
• Établir une connexion à la base de données
• Créer une instruction
(requête/batch/procédure…)
• Exécuter l’instruction
• Traiter le résultat
• Fermer les différents éléments
136
Les fonctions de JDBC
• Fonctions de bases • Fonctions avancées
– Charger le/les pilotes – Exceptions JDBC
– Se connecter à la base de – Accès aux méta-données
données • Du résultat
– Créer une instruction • De la base de données
• SQL statique, – Exécution de
• appel à procédure stockée, • requêtes précompilées
• précompilée et paramétrée • requêtes paramétrées
– Exécuter l’instruction • procédures stockées
• LMD de consultation, – Exécution par lots (batch)
• LDD et LMD de mise à jour, – Utilisation de curseurs
• procédures stockées – Transactions
– Traiter le résultat – Extension standard (javax.sql)
• Gestion de l’objet ResultSet
– Fermer les différents éléments
137
Conclusion : programmation SGBD
• Les langages de type PL/SQL constituent le mode
d'utilisation le plus courant des bases de données
relationnelles
– Utilisé pour programmer des procédures stockées
– Utilisé pour programmer des triggers
– Performant (réduit le transfert réseau)
– Bien adapté aux clients légers (ex: smartphones…) car déporte
des traitements sur le serveur
• Les programmes SGBD écrits dans des langages de
programmation classiques sont utilisés
– pour programmer des traitements sur un serveur d’application
(J2E)
– Pour programmer des applications de présentation
– Peuvent être indépendantes du SGBD (JDBC/ODBC) ou dédiées
(API dédiées, exemple de ICOLIB en annexe)
138
Parenthèse utile au TP:
Le dictionnaire de données Oracle
139
Contenu du Dictionnaire Oracle
• Dictionnaire Oracle = tables systèmes en lecture seule
• Evolution du dictionnaire
– Généré au moment de la création de la DB
– Mis à jour automatiquement
• Contient des informations sur la structure de la BD

– Utilisateurs (privilèges, rôles)
– Noms et caractéristiques des objets
(tables, vues, index, clusters, triggers, packages, ...)
– Contraintes d'intégrité
– Ressources physiques allouées à la base
– Valeurs par défaut pour des colonnes
– Les autres informations générales sur la base des données
• Structure
– Tables de base = tables fondamentales contenant les informations sur la BD
• Conservées dans le tablespace SYSTEM
– Vues de ces tables = présentation dépendant du rôle de celui qui consulte…
140
Utilisation du dictionnaire
• Accès avec SQL
• Utilisé par le DBA et les utilisateurs

– Consultation d’informations sur la structure de la BD
– Seulement des droits en lecture sur des vues du dictionnaire
– NB: seulement par des requêtes SELECT (lecture seule)
• Utilisé par Oracle

– A la connexion et pendant l’exécution des requêtes
• Consultation d’informations sur les utilisateurs et leurs privilèges
• Consultation d’informations sur les objets de la BD
– Lors des requêtes SQL DDL (Data Definition Language)
• Modification du dictionnaire
141
Différentes vues
SQL> SELECT table_name, comments

> FROM dictionary
> WHERE table_name LIKE '%CONSTRAINTS%';
TABLE_NAME COMMENTS
----------------------------------------------------------------
ALL_CONSTRAINTS Constraint definitions on accessible tables
DBA_CONSTRAINTS Constraint definitions on all tables
USER_CONSTRAINTS Constraint definitions on user's own tables
3 rows selected.
• La vue ‘DICTIONARY’ permet d’accéder aux noms/desc. des vues DBA, ALL, USER, V$...
142
Les vues USER
• Description des objets logiques créés par l’utilisateur
connecté
– Objets logiques = tables, index, vues, triggers, procédures…
SQL> SELECT table_name
• Exemples de vues USER_ > FROM dictionary
> WHERE table_name LIKE '%USER_%';
– USER_TABLES
• Tables créées par l’utilisateur TABLE_NAME
------------------------------
– USER_INDEXES …
USER_VIEWS
• Index créés par l’utilisateur USER_HISTOGRAMS
– USER_CONSTRAINTS 115 row(s) selected.
• Contraintes créées par l’utilisateur
– USER_VIEWS
• Informations sur les vues créées par l’utilisateur
– USER_USERS
• Information sur l’utilisateur
143
Les vues ALL
• Ces vues décrivent
– les objets créés par l’utilisateur connecté (comme dans user_tables)
– Et aussi tous les objets accessibles à cet utilisateur
Dans user_tables Dans all_tables
SQL> desc user_tables; SQL> desc all_tables;
Nom Nom
------------------------------ ------------------------------
TABLE_NAME … OWNER …
… TABLE_NAME …
…
• Exemples de vues ALL_

SQL> SELECT table_name FROM all_tables;
…
SQL> SELECT owner FROM all_users;
…
SQL> SELECT index_name FROM all_indexes;
…
SQL> SELECT table_name, constraint_name FROM all_constraints;
…
144
Les vues DBA
• Décrivent tous les objets de la base
– Sur certains objets, la description est plus complète
• Accessibles qu’aux utilisateurs
– Ayant le rôle SELECT_CATALOG_ROLE
– Ou ayant le privilège système SELECT ANY DICTIONARY
• Ex. La vue DBA_TABLES
SQL> SELECT table_name, num_rows, blocks,

< empty_blocks, avg_space
> FROM dba_tables
> WHERE table_name=’Livre’;
TABLE_NAME NUM_ROWS BLOCKS EMPTY_BLOCKS AVG_SPACE

---------- -------- ------ ------------ ---------
LIVRE 6764 180 19 861
1 row(s) selected.
145
Les vues dynamiques V$
• Vues dont les informations sont «dynamiques»
– Evoluent du démarrage de l’instance jusqu’à son arrêt
– Décrivent l’activité de la DB et de l’instance
– Sont appelées «dynamiques» mais
• en fait, elle externalise l’état de variables internes à Oracle
• Usage de ces données

– Principalement pour l’amélioration des performances de la BD
• Ex. V$Session
SQL> SELECT sid, serial#, username, type, status
> FROM v$session;
SID SERIAL# USERNAME TYPE STATUS

----- -------- ------------ ---------- -------
1 1 BACKGROUND ACTIVE
…
8 6 HEURTEL USER INACTIVE
– Le DBA peut déconnecter les utilisateurs avec la commande

suivante
SQL> ALTER SYSTEM KILL SESSION ‘8,6’ ;
146
Table DUAL
• Elle permet de
– récupérer la date système (SYSDATE)
– tester le formatage de données de type DATE
– tester le bon «parenthésage» d'expressions
– etc.
• Possède une seule colonne (DUMMY)
Et un seul tuple (NULL)
SQL> SELECT TO_CHAR(SYSDATE,'DD-MM-YYYY HH24:MI')
> FROM DUAL;
TO_CHAR(SYSDATE,'DD-MM-YYYY HH24:MI')
-------------------------------------
23-02-2004 22:05
SQL> SELECT 89456/562 FROM dual;
89456/562
----------
159.174377
147
Exercice 3 et exercice 4 (OracleXE)
• Installer OracleXE
• Exercice 3
– Nous utiliserons une BD basée sur le MCD de l’ex. 1
– Créer les tables en SQL
– Charger des données (utilisation de sqlloader)
– Modifier certaines données en SQL
• Exercice 4
– Interroger la base en SQL
148
Fonctionnalités SGBD
Focus sur l’optimisation
Exécution embarquée
Exécution distribuée
(sur une étude de cas)

149
Fonctionnalités des bases de données
(en 10 grands principes)
150
L’approche ‘‘Bases de données’’
I- Indépendance
Physique
X - Standards II- Indépendance

Logique
IX - Gestion de la III – Langage de

confidentialité manipulation
VIII - Concurrence BD IV - Gestion des

d’accès vues
VII - Gestion des V - Optimisation des

pannes questions
VI - Gestion de la
cohérence
151
I - Indépendance Physique
• Indépendance des programmes d'applications

vis à vis du modèle physique :
– Possibilité de modifier les structures de stockage
(fichiers, index, chemins d'accès, …) sans modifier les
programmes;
– Ecriture des applications par des non-spécialistes des
fichiers et des structures de stockage;
– Meilleure portabilité des applications et indépendance
vis à vis du matériel.
152
Modélisation Relationnelle
Docteurs Prescriptions
Id-D Nom Prénom Id-V Ligne Id-M Posologie
1 Dupont Pierre 1 1 12 1 par jour
2 Durand Paul
Visites
1 2 5 10 gouttes
Id-D Id-P Id-V Date Prix
3 Masse Jean 2 1 8 2 par jour
1 2 1 15 juin 250
…. …….. …… 2 2 12 1 par jour
1 1 2 12 août 180
2 3 3 2 gouttes
2 2 3 13 juillet 350
…. …. …. …………
2 3 4 1 mars 250
Patients
Id-P Nom Prénom Ville Médicaments
1 Lebeau Jacques Paris Id-M Nom Description
2 Troger Zoe Evry 1 Aspegic 1000 ……………………………..
3 Doe John Paris 2 Fluisédal ……………………………..
4 Perry Paule Valenton 3 Mucomyst ……………………………..
…. ……. ……. ……. …. …….. ……………………………..
153
II - Indépendance Logique
Les applications peuvent définir des vues logiques de la BD
Gestion des médicaments Cabinet du Dr. Masse

Prescriptions
Nombre_Médicaments Id-V Ligne Id-M Posologie
1 1 12 1 par jour
Visites
1 2 5 10 gouttes
Id-M Nom Description Nombre Id-D Id-P Id-V Date Prix
2 1 8 2 par jour
2 2 3 13 juillet 350
2 2 12 1 par jour
1 Aspegic 1000 …………………………….. 30 2 3 4 1 mars 250
2 3 3 2 gouttes
…. …. …. …………
2 Fluisédal …………………………….. 20
Patients
3 Mucomyst …………………………….. 230 Id-P Nom Prénom Ville Médicaments
…. …….. …………………………….. ….. 2 Troger Zoe Evry 1 Aspegic 1000 ……………………………..
…. ……. ……. ……. …. …….. ……………………………..
2 Durand Paul
Visites
1 2 5 10 gouttes
1 2 1 15 juin 250
…. …….. …… 2 2 12 1 par jour
1 1 2 12 août 180
2 3 3 2 gouttes
2 2 3 13 juillet 350
…. …. …. …………
2 3 4 1 mars 250
Patients
154
…. ……. ……. ……. …. …….. ……………………………..
Avantages de l’indépendance logique
• Possibilité pour chaque application d'ignorer les

besoins des autres (bien que partageant la même
BD).
• Possibilité d'évolution de la base de données
sans réécriture des applications :
– ajout de champs, ajout de relation, renommage de
champs.
• Possibilité d'intégrer des applications existantes
sans modifier les autres.
• Possibilité de limiter les conséquences du partage :
Données confidentielles.
155
III - Manipulation aisée
• La manipulation se fait via un langage déclaratif
– La question déclare l’objectif sans décrire la méthode
– Le langage suit une norme commune à tous les SGBD
– SQL : Structured Query Langage
• Syntaxe (aperçu !)
Select <Liste de champs ou de calculs à afficher>
From <Liste de relations mises en jeu>
Where <Liste de prédicats à satisfaire>
Group By <Groupement éventuel sur un ou plusieurs champs>
Order By <Tri éventuel sur un ou plusieurs champs>
156
Exemple de question SQL (1)
• Nom et description des médicaments de type

aspirine
Select Nom, Description

From Médicaments
Where Type = ‘Aspirine’
157
• Patients parisiens ayant effectués une visite le 15

juin
Select Patients.Nom, Patients.Prénom

From Patients, Visites
Where Patients.Id-P = Visites.Id-P
and Patients.Ville = ’Paris’
and Visites.Date = ’15 juin’
158
• Dépenses effectuées par patient trié par ordre

décroissant
Select Patients.Id-P, Patients.Nom, sum(Prix)

Group By Patients.Id-P, Patients.Nom
Order By sum(Prix) desc
159
IV – Gestion des vues
• Les vues permettent d’implémenter l’indépendance
logique en permettant de créer des objets virtuels
• Vue = Question SQL stockée
• Le SGBD stocke la définition et non le résultat
• Exemple : la vue des patients parisiens
Create View Parisiens as (
Select Nom, Prénom
From Patients
Where Patients.Ville = ’Paris’ )
160
Les vues : des relations virtuelles !
Le SGBD transforme la question sur les vues
en question sur les relations de base
Question Q
sur des vues
Gestionnaire
de Vues
Question Q’
Définition des sur les relations
vues de base
2 Durand Paul
Visites
1 2 5 10 gouttes
1 2 1 15 juin 250
…. …….. …… 2 2 12 1 par jour
1 1 2 12 août 180
2 3 3 2 gouttes
2 2 3 13 juillet 350
…. …. …. …………
2 3 4 1 mars 250
Patients
…. ……. ……. ……. …. …….. ……………………………..
161
Les vues : Mise à jour
• Non définie si la répercussion de la mise à jour vers la
base de données est ambiguë
– ajouter un tuple à la vue calculant le nombre de
médicaments ?
• Restrictions SQL (norme):
– Pas de distinct, d’agrégats, ni d’expression
– La vue contient les clés et les attributs « non nulls »
– Il y a une seule table dans le from
– Requêtes imbriquées possibles
– Certains SGBDs supportent plus de mises à jour
• Clause « With check option »
– Le SGBD vérifie que les tuples insérés ou mis à jour
correspondent à la définition de la vue 162
Les vues : Les instantanés (snapshot)
• Instantané, Snapshot, vue concrète, vue matérialisée
– matérialisée sur le disque
– accessible seulement en lecture
– peut être réactualisé
• Exemple
– create snapshot Nombre_Médicaments as
Select Id-M, Nom, Description, count(*)
From Médicaments M, Prescriptions P
Where M.Id-M = P.Id-M
refresh every day
• Objectif principal : la performance
163
V – Exécution et Optimisation
• Traduction automatique des questions déclaratives

en programmes procéduraux :
 Utilisation de l’algèbre relationnelle
• Optimisation automatique des questions

 Utilisation de l’aspect déclaratif de SQL
 Gestion centralisée des chemins d'accès (index,
hachages, …)
 Techniques d’optimisation poussées
• Economie de l'astuce des programmeurs

– milliers d'heures d'écriture et de maintenance de logiciels.
164
Sélection
Patients Patients
Id-P Nom Prénom Ville Id-P Nom Prénom Ville
1
2
3
Lebeau
Troger
Doe
Jacques
Zoe
John
Paris
Evry
Paris
 1
2
3
Lebeau
Troger
Doe
Jacques
Zoe
John
Paris
Evry
Paris
4 Perry Paule Valenton 4 Perry Paule Valenton
Patients de la ville de Paris
165
Projection
Patients Patients
Id-P Nom Prénom Ville Id-P Nom Prénom Ville
1
2
3
Lebeau
Troger
Doe
Jacques
Zoe
John
Paris
Evry
Paris
 1
2
3
Lebeau
Troger
Doe
Jacques
Zoe
John
Paris
Evry
Paris
4 Perry Paule Valenton 4 Perry Paule Valenton
Nom et prénom des patients
166
Jointure
Patients Visites
Id-P Nom Prénom Ville Id-D Id-P Id-V Date Prix
1 Lebeau Jacques Paris 1 2 1 15 juin 250
2 Troger Zoe Evry 1 1 2 12 août 180
3 Doe John Paris 2 2 3 13 juillet 350
4 Perry Paule Valenton 2 3 4 1 mars 250
Id-P Nom Prénom Ville Id-D Id-P Id-V Date Prix

1 Lebeau Jacques Paris 1 1 2 12 août 180
2 Troger Zoe Evry 1 2 1 15 juin 250
2 Troger Zoe Evry 2 2 3 13 juillet 350
3 Doe John Paris 2 3 4 1 mars 250
Patients et leurs visites

167
Exemple de plan d’exécution
Select
From
Patients.Nom, Patients.Prénom
Patients, Visites

and
and
Patients.Ville = ’Paris’
Visites.Date = ’15 juin’ 
Patients Visites
168
Plan d’exécution optimisé



 
 
Patients Visites Patients Visites
169
VI - Intégrité Logique
• Objectif : Détecter les mises à jour erronées
• Contrôle sur les données élémentaires

– Contrôle de types: ex: Nom alphabétique
– Contrôle de valeurs: ex: Salaire mensuel entre 5 et 50kf
• Contrôle sur les relations entre les données

– Relations entre données élémentaires:
• Prix de vente > Prix d'achat
– Relations entre objets:
• Un électeur doit être inscrit sur une seule liste électorale
170
Contraintes d’intégrité
• Avantages :
– simplification du code des applications
– sécurité renforcée par l'automatisation
– mise en commun des contraintes, cohérence
• Nécessite :
– un langage de définition de contraintes d'intégrité
– la vérification automatique de ces contraintes
BD BD
171
Exemples de contrainte
• Contraintes d’intégrité référentielles
2 Durand Paul
Visites
1 2 5 10 gouttes
1 2 1 15 juin 250
…. …….. …… 2 2 12 1 par jour
1 1 2 12 août 180
2 3 3 2 gouttes
2 2 3 13 juillet 350
…. …. …. …………
2 3 4 1 mars 250
• Vérification lors de l’insertion, la suppression, la modification

• Propagation des suppression, modification en cascade possible
(on delete cascade)
172
VII - Intégrité Physique
• Motivations : Tolérance aux fautes
– Transaction Failure : Contraintes d'intégrité, Annulation
– System Failure : Panne de courant, Crash serveur ...
– Media Failure : Perte du disque
– Communication Failure : Défaillance du réseau
• Objectifs :
– Assurer l'atomicité des transactions
– Garantir la durabilité des effets des transactions
commises
• Moyens :
– Journalisation : Mémorisation des états successifs des
données
– Mécanismes de reprise
173
Transactions
Incohérence possible...
Etat cohérent Etat cohérent
Begin Commit
Transaction
Begin
CEpargne = CEpargne - 3000
CCourant = CCourant + 3000
Commit T1
174
Atomicité et Durabilité
ATOMICITE DURABILITE
Panne
Begin Begin
CEpargne = CEpargne - 3000 CEpargne = CEpargne - 3000
CCourant = CCourant + 3000 CCourant = CCourant + 3000
Commit T1 Commit T1
Crash disque
 Annuler le débit !!  S’assurer que le

virement a été fait !
175
VIII - Partage des données
BD
• Accès concurrent aux mêmes données

Conflits d’accès !!
176
VIII - Partage des données
BD
• Le SGBD gère les accès concurrents

 Chacun à l’impression d’être seul (Isolation)
 Cohérence conservée (Verrouillage)
177
IX – Confidentialité
• Objectif :
– protéger les données de la base contre des accès non autorisés
• Mécanismes simples et puissants
– Connexion restreinte aux usagers répertoriés (mot de passe)
– Privilèges d'accès aux objets de la base (relation, vue, etc.)
• Repose sur la sécurité de l’architecture (de bout en bout)
BD
Serveur
Utilisateur BD
Identification Sécurisation des communications Protection du Protection

Authentification (confidentialité, intégrité, non répudiation) serveur des fichiers
178
Droits d'accès : Syntaxe de base et rôles
• Syntaxe de base
– Grant <droits> on <objet> to (<usager>*) [with grant option]
– Revoke <droits> on <objet> from (<usager>*)
– <droits> ::= all | select | insert | delete |update | alter
– <objet> ::= relation | vue | procedure
– <usager> ::= public | nom d'usager
• Rôles (SQL3):
– Create role <nom_role> : Création d’un nouveau rôle
– Drop role <nom_role> : Suppression d’un rôle
– Les instructions Grant et Revoke s’appliquent sur des rôles
– Grant <liste roles> to (<usager>*) : Affectation de rôles aux usagers
– Set role <liste_roles> : Activation de rôle(s) pendant une session
179
Droits d'accès : droits sur les vues
Employés Public
Id-E Nom Prénom Poste

1 Ricks Jim 5485
2 Trock Jack 1254
Nombre Masse
3 Lerich Zoe 5489 d’employés Salariale
4 Doe Joe 4049 4 890
Id-E Nom Prénom Poste Adresse Ville Salaire

Service des 1 Ricks Jim 5485 ………. Paris 230
ressources 2 Trock Jack 1254 ………. Versailles 120
3 Lerich Zoe 5489 ………. Chartres 380
humaines
4 Doe Joe 4049 ………. Paris 160
180
X - Standardisation
• L’approche bases de données est basée sur plusieurs
standards
– Langage SQL (SQL1, SQL2, SQL3)
– Communication SQL CLI (ODBC / JDBC)
– Transactions (X/Open DTP, OSI-TP)
• Force des standards

– Portabilité
– Interopérabilité
– Applications multi sources…
181
Applications traditionnelles des SGBD
• OLTP (On Line Transaction Processing)

– Cible des SGBD depuis leur existence
– Banques, réservation en ligne ...
– Très grand nombre de transactions en parallèle
– Transactions simples
• OLAP (On Line Analytical Processing)

– Entrepôts de données, DataCube, Data Mining …
– Faible nombre de transactions
– Transactions très complexes
182
Applications des SGBD (1)
• BD et WEB
– Serveurs Web dynamiques, sites marchands ...
– Plusieurs profils (OLTP, publication d’informations en ligne,
hébergement de données…)
• Challenges majeurs
– Gestion de données XML
– Fédération de sources de données hétérogènes
– Grilles de données
– Sécurité des données en ligne
183
Applications des SGBD (2)
• BD personnelles ou PME
– Comptabilité
– Agenda, comptes bancaires, carnet d’adresses, dossiers
portables
– BD embarquées sur calculateurs ultra-légers (PDA,
téléphones cellulaires, cartes à puce…)
• Challenges majeurs
– Gérer la mobilité
– S’adapter aux contraintes matérielles du calculateur hôte
– Assurer la durabilité des données
– Assurer la confidentialité des données
184
Architecture des SGBD
• Les architectures physiques de SGBD sont très liées
au mode de répartition
– BD centralisée
– BD client/serveur
– BD client/multiserveurs
– BD répartie
– BD hétérogène
– BD mobile
• Le challenge se déplace : Péta-bases  Pico-bases

– Péta-bases = parallélisme et grandes mémoires
– Pico-bases = faible empreinte et forte sécurité
185
Historiquement : architecture centralisée
• Des terminaux clients
– sans intelligence, passifs
• Un réseau
Terminaux passifs • Un ordinateur central
– grande puissance (‘mainframe’)
réseau
– Maintient la base et les applis
Appli 1 Appli 2 Appli n
SGBD
Mainframe
données
Exemple d’instance de cette architecture? le minitel 

186
Architecture client serveur
• Des clients intelligents
– Font tourner les applications
• Un réseau
Appli 1 • Un serveur
Appli 2
– Maintient la base
Clients intelligents Appli n
réseau
serveur
SGBD
code données
Exemple d’instance de cette architecture? Université

187
Architecture Client Multiserveurs
– Font tourner l’application
– Interagissent avec les serveurs
Appli 1 – Combinent les résultats
SQL
SQL • Un réseau
• Des serveurs
ODBC ODBC – Et des bases différentes
SQL SQL
SGBD 1 SGBD 2
code données code données
Exemple d’instance de cette architecture? Réservation d’un voyage

188
Architecture répartie
– Font tourner l’application
– Interagissent avec ‘1 SGBD’
(l’application ne voit pas que sa requête est
Appli 1 réacheminée)
Appli 2
• Un réseau
Appli n
• Des serveurs
– Une même base
– Gèrent chacun une portion
SGBD 1.2
SGBD 1.1
code données
code données
Exemple d’instance de cette architecture? Agences d’une société

189
Architecture hétérogène
– Interagissent avec ‘1 SGBD’
• Un médiateur
– Interroge les sources
Appli 1 Appli 2 Appli n – Nettoyage, intégration, etc.
• Des sources de données
– Données hétérogènes
Médiateur • Type, schéma, etc.
– Gestion des données différente…
Source 2 :
Source 1 : serveur Web
SGBD
code données
code données
Exemple d’instance de cette architecture? Kelkoo

190
Architecture mobile
• Des clients mobiles intelligents
Clients mobiles
– Portion SGBD répliquée
(et/ou données personnelles)
– Interagissent avec SGBD externe
• Un réseau sans fil
• Un serveur
Réseau sans fil – Données durables/partagées
serveur
SGBD
code données
Exemple d’instance de cette architecture? Représentant de commerce

191
Conclusion : couches d’un SGBD
Interface
Analyseur sémantique
Optimiseur
Moteur d’exécution
Opérations relationnelles
Méthodes d’accès aux données
Gestion de Gestion de Gestion des

Mémoire Verrous Journaux
Système opérationnel
192
Problème de l’optimisation
• Un problème global
– Touche l’ensemble des acteurs (pas seulement l’éditeur…)
Select
From
Where
Requête SQL Arbre logique Arbre Physique
Optimisation
193
194
Un problème d’équivalence sémantique

• Une question
• Plusieurs expressions
équivalentes en SQL
• Plusieurs expressions
équivalentes en algèbre
• Plusieurs algorithmes
algébriques équivalents
Ex. 9 jointures
Coût
17 Milliards de plans…
Plans sémantiquement équivalents 194

195
Objectifs de l’optimisation
• Objectif de l’optimiseur : trouver le meilleur plan …
– Donnant les résultats le + vite ….
• Optimisation pour le temps de réponse (response time)
– Minimisant la consommation de ressources
• Optimisation du travail total (Total work)
– Minimisant le temps de délivrance des premiers tuples
• Optimisation de la latence (Latency / First tuples …)
• Qui optimise ?
– Idéalement 2 requêtes équivalentes  même plan, le meilleur !
 Seuls les concepteurs de SGBD doivent maîtriser l’optimisation
– Pratiquement, ce qui conduit à des plans différents
• 2 modèles conceptuel/physiques différents (d’un même problème)
• 2 opérations sémantiques équivalentes (série de requêtes SQL différentes)
• 2 requêtes SQL équivalentes
 Le concepteur et le programmeur BD jouent un rôle majeur
195
196
Indexation (principe et B+Tree)

• Objectif : accès rapide à partir d’une clé
• Moyen : ajout de structures de données
(généralement hiérarchiques)
• Exemple : B+Tree Jean
Adam Ben Gil Karine Nicole Théo

Alain Claire Hilda Martin Paul Tom
Felix Jean Sophie Zoe
• Attention :
– Surcoût lors des mises à jour !
– Des fois un accès par index est plus coûteux !
196
197
Importance du Schéma Physique

• L'utilisation d'index
– accélère l'exécution des sélections et des jointures
– ralentit l'exécution des mises à jour et des insertions
– offre des informations statistiques à l'optimiseur
– permet le contrôle efficace de contraintes d'intégrité
• L'organisation des données
– égaliser les I/O entre disques (log et bases, index et tables,
partitions de tables sur ° disques) Ex: tablespaces en Oracle
• Le choix des "bons" index et l'organisation des
données sont déterminants pour les performances
197
198
Plan d’exécution optimisé
Select Patients.Nom, Patients.Prénom
Where
and
Patients.Id-P = Visites.Id-P
Patients.Ville = ’Paris’ 

and Visites.Date = ’15 juin’
  
 
Patients Visites Patients Visites
198
199
Optimisation Physique …

Jointure
– Nested Loop Join ?
– Index Join ?
–

Hash Join ?
 – Sort Merge Join ?
  Sélection
– FTS (Full Table Scan) ?
– Index Scan (B+tree) ?
Patients Visites – Index Scan (Bitmap) ?
199
200
Algorithmes de jointure
• Nested loop Join : Jointures par boucle imbriquées
– Pour chaque visite, parcourir les patients
• Index Join : Utilisation d’index sur une des relations
– Pour chaque visite, retrouver le patient grâce à l’index
• Sort Merge Join
– Trier les visites sur le N° de patient
– Trier les patients sur le N° de patient
– Fusionner les deux tables triées (jointure ‘à deux doigts’)
• Hash Join
– Hacher les patients sur le N° de patient
– Pour chaque visite, calculer la valeur de hachage et chercher
dans la table de hachage le patient correspondant
200
201
Optimiseur heuristique
• L’optimisation est indépendante des données
– Dépend uniquement de la requête SQL…
• Exemple d’heuristiques classiques
– Effectuer les sélections en premier
– Ajouter un maximum de projections
– Utiliser tous les indexes disponibles
– Utiliser les ‘meilleurs’ algorithmes de jointure, dans l’ordre
1. Hash join
2. Sort merge join
3. Nested Loop join avec index
4. Nested loop join
• Conclusion
– L’ordre des opérations dépends de l’expression SQL
• Ex = ordre des jointures déterminé par leur ordre d’apparition
– Présent dans Oracle = Rule Based Optimizer (RBO)
201
Optimisation basée coût
• Dépend des caractéristiques des données
• Présent dans Oracle (Cost Based Optimizer ou CBO)
• Plus efficace que le RBO !
Graphe d'opérations Schéma interne
Plans d'exécution
(espace de recherche)
Bibliothèque de
Générateur de
transformations
Plans
Statégie de Heuristiques
Recherche
de choix
Modèle de coût
Plan d'exécution
Optimal
202
Difficultés de l’optimisation basée coût
• Espace de recherche (plans candidats)
– Plusieurs algorithmes pour chaque opérateur
– Coûts et comportement différents
– Plusieurs ordonnancement pour les opérations binaires
• Sans considérer les algorithmes, il y a 1620 ordres possibles pour
joindre 5 relations, et 17 milliards pour 10 relations !
 Utilisation d’heuristiques et de programmation dynamique
• Modèle de coût (choix du plan)

– Difficulté pour estimer le coût de chaque opérateur
– Difficulté encore plus importantes pour estimer la taille des résultats
intermédiaires (permettant de calculer l’opérateur suivant)
– Propagation exponentielle des erreurs (dans l’arbre d’exécution) !
 Utilisation de statistiques re-calculés fréquemment
203
204
Les statistiques
• Possibilité d’histogrammes
– RunStat(<Table>, <attribut>)  construction et stockage d’un
histogramme de variation de l’attribut dans la table.
– Utilisation par le modèle de coût
– Sinon, hypothèse d ’uniformité
• Exemple :
– Personnes ayant un salaire entre 2K€ et 4 K€ ?
20%
– Personnes ayant 2 véhicules ?
15%
– Personnes ayant 2 véhicules et un salaire entre 2 et K4 K€?
3% ? Non !
En fait, 14%
15%
20%
0 0.5 1 1.5 2.0 2.5 3.0 3.5 4 0 1 2 3 4

204
205
Qualité de l’optimisation
1. Qualité du schéma physique
– Indexes
– Partitionnement, placement
– Configuration
2. Qualité de l'optimiseur (heuristique/coût)
– Qualité du modèle de coût utilisé
– Qualité de la stratégie de recherche de l'optimiseur
3. Qualité de l’administration
– Qualité des traces ou indicateurs générés par le système
– Qualité des outils d'aide à l'administration
– Qualité de l’administrateur !
4. Qualité des développeurs d’application ? 205
206
Réglage du SGBD – Database Tuning

• Réglages du SGBD, amélioration des performances
– Manuel par l’administrateur BD
– par des outils externes de diagnostiques
– par des outils intégrés automatiques
• Oracle : Automatic SQL Tuning
• SQL Server : Database Tunning Advisor
206
Oracle : Automatic SQL Tuning
Statistiques Index Mauvaises
SQL Profile
manquantes manquants constructions SQL
SQL Tuning Advisor
Requête SQL
Automatic Tuning Optimizer
Analyse des SQL Profiling Analyse des Analyse des

Statistiques chemins d’accès structures SQL
207
208
Conclusion sur l’optimisation

• Mécanismes puissant mais complexes à maîtriser
• Fort impact sur les performances du système
• Les performances dépendent d’autres facteurs
– Schéma physique
– Configuration du serveur (mémoire, disques, etc.)
– Administration adéquate
• De plus en plus de tâches automatiques ou automatisables
– Gestion de la mémoire automatique dans Oracle 9
– Automatic SQL Tuning dans Oracle 10
– Database Tunning Advisor dans SQL Server 2005
– Etc.
• Mais aussi : une bonne application BD
 des concepteurs qui connaissent le SGBD
208
Exécution et optimisation de
requêtes en environnement
contraint
209
Un peu d’histoire sur le dossier portable sécurisé (1)
1992 • Card Query Language (CQL) – RD2P LIFL

– Travail pionnier du LIFL sur BD et carte à puce
– API de type fichier (avec curseurs): open, fetch, close
– Sélections mono-table, Transactions
• Standard ISO 7816-7 – Gemplus / RD2P LIFL
1999 – Basé sur les travaux du LIFL
– SCQL : Structured Card Query Language
– Select/project mono-table
• Droits d’accès = vues mono-table
• GemDB (Gemplus) / SQL Java Machine (ISOL)
– Première tentative commerciale
2000
– Même caractéristique que SCQL
– Limitée par les contraintes matérielles de l’époque
210
2000 • PicoDBMS
– Moteur de SGBD embarqué supportant tous les opérateurs de l’algèbre
relationnelle
 Droits d’accès = vues multi-tables définiées par des requêtes de
sélection/projection/jointure/agrégat
2002 • MODS (MasterCard Open Data Storage)
– Définition d’une API standard pour dossier portable
• VSDB project (Very Small Data Base)
2004 – Politecnico di Milano (Bolchini, Schreiber, Tanca)
– NOR FLASH, pas de jointure ni d’agrégat
• Delite (Database for Embedded Lightweight system)
2005 – IIT Bombay (Sen, Ramamritham, Rao)
211
2007 • GhostDB
– BD partitionnée entre un serveur public traditionnel et un serveur privée
embarqué (BD en mode READ ONLY)
 Certaines colonnes privées sont stockées dans un SGBD portable
• Microsearch
2010 – Moteur de recherche embarqué dans des objets intelligents (capteurs,
composant personnels sécurisés)
• MiloDB
2013 – SGBD relationnel embarqué sur des composants embarqués à grand
capacité de stockage
– Supporte tout l’algèbre relationnel
2015 • PlugDB
– Web personnel sécurisé : serveur Web personnel addossé à un composant
sécurisé matériellement doté d’un moteur SGBD garantissant les règles de
partage édictées par le propriétaire
? • Folk-IS : vers un composant sécurisé sans infrastructure
2016
– Sans infrastructure : pas de réseau Internet, pas de serveur d’identités…
?
– Requêtes distribuées : utilisant les déplacements des personnes et leur
interactions avec des terminaux pour évaluer des requêtes distribuées 212
Resource constrained data management
• Goal: manage personal data at the extremity of the Internet
– Within sensors collecting data, in secure & personal user devices
– Potentially large data collections
• e-mails, medical records, official forms (admin., bank…), digital histories of interactions with e-
services (Amazon, Telcos…) or physical systems (transport, smart homes, …)
– Query functionalities must be embedded to compute authorized results
• Outline
– Target hardware platforms
– Problem statement
– The general framework to solve the problem
– Representative proposals: search engine & SQL queries
213
Target hardware
Sensors equipped with flash memory cards
Personal memory devices Secure devices on which
Personal in which a secure chip is implanted a GB flash chip
& secure ① ② ③ ④ is superposed
devices Sim Card

USB MicroSD Secure MicroSD Contactless + USB
reader 4GB Flash 8GB Flash
• Common architecture
MCU
– Microcontroller
Low cost (sensors)
BUS
Tamper resistance [SC02]
Miniaturization, protective layers (carrying signal),
NAND
Multi-Layering (hide sensitive lines), FLASH
Sensors (light/temp/power/freq.)
 prevent the chip from physical attacks
– GBs of memory
• NAND FLASH (dense, robust, low cost)
214
Severe hardware constraints
… with a strong impact on data management
• Microcontrollers
– Small RAM (<128 KB)
RAM is not dense
 Favor pipeline query evaluation
 (many) indexes
– Security is linked with size
• NAND FLASH
– High cost of random writes  Data structures and strategies…
Pages are erased before write … must avoid random writes
Erase by Block vs. write by Page
• How do existing techniques deal with these constraints ?
215
Existing Techniques
• Light & embedded versions of DBMS products
– e.g., SQLite, BerkeleyDB, DB2 Everyplace, …
– Target small but powerful devices (e.g., smart phones, set top boxes)
 Not compliant with very small RAM & not adapted to NAND Flash
• FLASH aware versions of traditional database indexes

– BTree adaptation: BFTL [TECS07], LATree [VLDB09], FDTree
[VLDB10]
Store index updates in a Flash resident log, itself indexed in RAM
Updates are committed to the BTree in a batch mode (amortize write cost)
Small RAM  Small index in RAM  High commit frequency  Low gains
 Not compliant with very small RAM
216
Existing Techniques (cont.)
• Flash aware implementations of key-value stores
– SkimpyStash [SIG11], LogBase [VLDB12], SILT [SOSP11]
• A log structure in FLASH is used to store the key-value pairs
• An index is maintained in RAM to index that log (~1B per key-value pair)
 Incompatible with small RAM
• Data management techniques for MCUs
– Proposals consider small amounts of (internal) memory
• PicoDBMS [VLDBJ01], VSDB [TOIS03], HybridStore [WSN13]
Exploit byte writes accesses (EEPROM, NOR) specific to certain kinds of MCUs
– Recent proposals consider large Flash memory Details next
RDBMS: GhostDB [SIG07], PBFilter [IS12], MiloDB [DAPD14]
Search engines: MAX [TSN08], Snoogle [TPDS10], Microsearch [TECS10]
217
Problem statement
• Problem : execute queries with a very small RAM
on large volumes of data stored in NAND FLASH
Evaluate queries
Increase RAM consumption
with a small RAM
Pipeline strategy Reduce cost
Build many Many random writes

indexes … unacceptable costs
in NAND Flash
Index maintenance
• How do recent works resolve the problem ?
218
General (implicit) framework to solve the problem
1- Design index structures enabling pipeline query evaluation
2- Organize them into sequential structures (Logs)

Log structures satisfy Flash constraints
Pages are written sequentially (and never updated nor moved)
…. random write are avoided by construction
Allocation & de-allocation are made on large grains (Flash block basis)
…. partial garbage collection never occurs (avoids costly GC)
3- Provide scalability by reorganizing the Logs structures

Transform the sequential indexes into more efficient data structures
… the transformation itself must only use log structures
How do recent works implement this methodology?
219
First illustration: embedded search engines
• Answer IR queries
– For a set of query keywords, produce the N most relevant documents
(according to a weight function like TF-IDF)
TF-IDF(doc) =  (weight ti,doc x Log( {doc} /  {doc containing ti} ))

{ki} query
keywords
• Inverted index
– Stores triples (keyword, docid, weight)
– Used at query time to retrieve all triples containing a query keyword
• Search algorithm
– The inverted index is accessed for each query keyword
– In RAM: one container is allocated per retrieved docid… too much!
– …used to aggregate the triples for one docid, and compute its TFIDF
– The N documents with the highest scores are returned
How to store the index sequentially? How to search in pipeline?
220
Tan et al. [TECS10]
How to store the inverted index sequentially ?
hash table
Index triples
H1
H1 (keyword, weight, docid)
H2
H2
RAM H3 17 The hash table stores the address of the last
H3 26
bucket written in Flash;
Buckets are chained in Flash to speed up keyword
search.
Inverted index
…
Log structures
FLASH Documents
docid=7 docid=9 docid=21 docid=23
doc2 doc4
221
Tan et al. [TECS10]
How to evaluate search queries in pipeline?
hash table
Documents ids are generated in increasing order H1 56
H2 40
H3 43
… …
Addr 14 Addr 17 Addr 25 Addr 26 Addr 40 Addr 43
… …
t2,1,2 t2,1,20 t2,1,25 docid sorted (desc.)
t2,1,3 t1,5,7 t2,2,21 t1,3,21 t2,2,28 t1,1,25
t2,1,5 t1,1,9 t2,1,23 t1,1,23 t2,3,30 t1,5,28
(hash value H3)
  Addr 14 Addr 17 Addr 25 Addr 26
Chained hash buckets

(Inverted index in
FLASH)
The query is computing in pipeline using a merge operation
Requires 1 page in RAM per hash list (per query keyword)
The triples are scanned, and “merged” on docids
 Triples with an equal docid arrive in RAM at the same time…
… and the TF-IDF score of each docid can be computed in pipeline
The N docids with the highest score are kept in RAM
222
Second illustration:
embedded relational database
• SQL queries
– Evaluate selections, projections, joins
• Selection and join indexes
– Q1: How to store such indexes in log structures?
– Q2: How to make it scale?
• Join algorithms consume lots of RAM
– Join indices could be a solution…
… but consecutive joins induce RAM-hungry sorts
Sorted on CUS.id
JI
Sorted on ORD.id
JI
Sorted on CUS.id
(CUSTOMER) ORDER LINETEM
– Q3: How to compute select-project-joins queries in pipeline?

223
Yin et al. [IS12]
How to build an index in log structures?
Indexed
column
Log1: «Keys» (vertical partition) Log1 CITY
Log2
Stores the index key, filled at tuple insertion
Log2: «Bloom Filters» Keys CUSTOMER
1 BF build for each page in «Keys» … …

… … … …
Joe … Lyon
… … …… …
Lyon t20 t20
BF is a probabilistic summary (~2B/key) B.Filters P2

…
Lyon t30 …
…
t30 Jack… Lyon
…… …
Retrieve CUSTOMER.CITY=‘Lyon’ … …
… …
… …
… …
… …
…
BF2
…
…
Lyon …
… Paul… Lyon
… … …
Scan of «Bloom Filters» t50 t50
… … … …
BF16
…
P16
… … … … …
For each BF : if ‘Lyon’  BF …
BF68
…
BF78 …
… …
… …
… …
… … …
Negative  ignore it … P68
…
Lyon t70 …
…
t70 Jim … Lyon
…… …
Positive  access 1 page of «Keys» … …
… … … …
Tom… Lyon
…
… …
…… … …
t90
…
Lyon t90
P78
search ‘Lyon’ & return tuples pointers … …
Summary Scan Table scan
(17 IOs) (640 IOs)
Efficient search: |Log2| I/O + 1 IO/result

… but how to achieve scalability?
224
[DAPD14]
Scalability  timely reorganize the index
…to transform it into a more efficient index
Keys
Reorganization process:
…
Lyon
…
t20
Sequential index Temp. Only uses log structures
B.Filters Lyon t30
P2
… Logs Background / interruptible
… …
Sum2
…
…
Lyon
Sorted run1 Ex: Sequential index  B-Tree like
Sum16 P16 … t50
1) Sort the (key, pointer) pairs
… … Sorted run2
…
 Temp. logs (sorted “runs”)
Sum68
… …
Sum78 P68 … …
… Lyon t70  result written seq.: «Sorted Keys»
…
… t90 2) Build a key hierarchy
Lyon
P78
…
…
B-Tree like index  No need of temporary Logs
K1  result is written seq.: «Tree»
K2
… Result: efficient B-Tree like index
…
…
… how to evaluate
t90 t70 t50 t30 t20
Lyon
SQL queries in pipeline?
Log:
«Sorted keys» … Log: «Tree»
…
Kn
225
[SIG07, DAPD14]
How to evaluate SQL queries in pipeline ?
SELECT CUS.*, ORD.*, LIN.*, PARTSUP.*
FROM CUSTOMER CUS, ORDER ORD, LINETEM LIN, PARTSUP PS, SUPPLIER SUP
WHERE CUS.CUSkey = ORD.CUSkey AND ORD.ORDkey = LIN.ORDkey AND
LIN.PSkey = PS.PSkey AND PS.SUPkey = SUP.SUPkey AND
CUS.Mktsegment = 'HOUSEHOLD' AND SUP.Name = 'SUPPLIER-1'
Tselect Indexes Tjoin Index Execution Plan

(generalized join index)
TPCD like Each key of the index contains
the rowids of the root table each rowid of the root
Project
schema Query refering to that key table contains the rowids
 LIN
root Tselect on
of the tuples it refers to in
the subtree
{LINid  , CUSid,
ORDid, PSid}
table SUP.Name
Tjoin on LIN Tjoin
Tselect on access
ORDid
PARid
LINid
SUPid
CUSid
PSid
CUS.marketsegment
Tjoin on LIN {LINid} 
 
K1
K2
… Intersect
ORD PS …
… merge
t50 t30 t20 {LINid}  {LINid} 

HOUSE
HOLD
… Tselect Tselect

…
access access
Kn ‘HOUSEHOLD’ ‘SUPPLIER-1’
CUS PAR SUP
‘HOUSEHOLD’ ‘SUPPLIER-1’ NB: Tselect returns
sorted row ids!
Tselect on CUS.Mktsegment Tselect on SUP.Name
226
Conclusion
• Encouraging results
– Efficient search engines
– Efficient SQL queries
• Remaining challenges
– Extend the principles to other data models
• XML, time series, spatial-temporal data, noSQL & key-value
stores, etc.
– A general co-design approach is still missing
• How to calibrate the HW (RAM) to data oriented treatments ?
• How to adapt to dynamic variations of the HW parameters ?
227
Exercice 5
• On souhaite développer une application d’analyse des
ventes
• Traitements:
– L’analyste souhaite avoir une application lui permettant de
consulter la liste des clients de sa base avec pour chacun la
somme totale dépensée pour ses achats
• Base de données:
– Une base de données (relationnelle) contient la liste des
clients, de commandes, les détails des articles commandés,
des produits, des fournisseurs
• Proposition pour réaliser le traitement:
– Un programme JDBC qui interroge la BD et affiche la liste
des clients avec la somme totale dépensée
228
Proposition : code Java/JDBC
Int prix = 0
Pour chaque client
Pour chaque commande
Pour chaque article
SI : Il s’agit bien d’un article de cette commande
ET d’une commande de ce client
ALORS : prix += prix de cet article
Affiche: les informations sur ce client et le prix
prix:=0
fin du programme
Ce traitement sera-t-il performant ?
Proposer une solution alternative plus performante
Quel peut être le gain potentiel (sans toucher à la BD) ?
229
Exercice 6
• On souhaite accélérer la requête suivante:
(requete avec 3 sélections peu selectives)
• Voici des informations chiffrées sur les données
• Aurais-je un gain en ajoutant un index sur xxx,

l’attribut le plus sélectif ?
• Sur les 3 attributs ?

• Voyez vous une solution d’indexation qui convienne ?
230
Exercice 7
Etude de cas
Exécution distribuée de requêtes SQL incluant
des fonctions ‘chères’ et manipulant des
objets volumineux (BLOB’s)
231
Présentation de l’étude de cas
• Contexte :
– Exécution distribuée de requêtes SQL incluant des fonctions
‘chères’ et manipulant des objets volumineux (BLOB’s)
• Problèmes :
– Optimisation de ces requêtes
– Exécution efficace
232
Exemple : Architecture
Client
Brasilia
server
Rio Paris
server Distributed Query server
Processing
Sao Paulo Function

Data (P,V)
server (CV)
Function
(CP)
233
Exemple : Description des sites
• Site de Rio:
– Table P contenant les pollutions mesurées :
P(regId:int, date:int, value:double, …)
– Table V contenant des images (type bitmap) de regions

V(regId:int, image:Blob, …)
• Site de Sao Paulo:

– Fonction CP permettant de calculer des indices de pollution en fonction
des données brutes :
function CP(double)  double
• Site de Paris:
– Fonction CV permettant de calculer la couverture végétale sur une image
raster.
function CV(Blob) double
234
Example : Programme (1)
Donne moi les regions ayant un indice de pollution dépassant 1.5 et un
indice de couverture végétale de moins de 0.3
Brasilia
server
Rio Paris
Processing
Sao Paulo Function

Data (P,V) server (CV)
Function
(CP)
235
Example : Programme (2)
SELECT P.regId, CP(P.value), CV(V.image) FROM P, V
WHERE P.regId = V.regId and
CP(P.value) > 1.5 and
CV(V.image) < 0.3
Brasilia
server
Rio Paris
Processing
Sao Paulo Function

Data (P,V) server (CV)
Function
(CP)
236
Exemple : Paramètres
Name Description Value
CardP Cardinality of relation P 300 tuples
DistP Number of distinct pollution measurements in P 150 measurements
CardV Cardinality of relation V 50 tuples
DistV Number of distinct images in V 50 images
CardV P Cardinality of the result of V join P 200 tuples
DistP_V P Number of distinct pollution measurements in V join P 100 measurements
DistV_V P Number of distinct images in V join P 40 images
ImgTrans Average image transfer time (with a 1Mb/s network bandwidth) 100 s
CostCP Average per tuple cost of function CP 30 s
CostCV Average per tuple cost of function CV 200 s
 pp Average selectivity for predicate p p (CP (P. value) > 1.5) 0.5
 pv Average selectivity for predicate p v (CV (V. image) < 0.3) 0.8
237
Le problème
Paris
Dimensions:
pv
Traitement distribué
Transfert de d’objets volumineux (Blobs)
CV Function
Execution répétée de fonctions très
coûteuses
Images
pp Sao paulo Objectif 1: minimiser

Le nombre d’execution des fonctions chères
Le nombre de Blobs transférés
CP Function
Le nombre de transfert par Blob
Images
Rio Objectif 2: exploiter le parallelisme entre

les sites
V P
238
Techniques de résolution
• Transmettre des identifiants de Blobs et
pv utiliser une commande getBlob()
– Evite les transmissions inutiles de Blobs
• Bufferiser (cache) les Blobs transmis
CV – Evite les transferts de Blobs redondants
•Analyse
Bufferiser (cache) les résultats des
de groupe
pp appels
Solution de fonctions
de l’étude de casavec l’identifiant du
Blob concerné
Images
– Eviter les appels de function redondants

CP (concernant les mêmes données)
• Lancer le transfert du prochain Blob
pendant l’execution des fonctions
– Paraléliser le transfert de Blob et l’execution
de la fonction
V P
239
Résultats
70
x 1000 s
Legend
60 N: Naïve execution
DT: Delayed Transfer only
C: Caching only
50
DTC: Delayed Transfer + Caching
ALL: Delayed Transfer + Caching +
40 BackgroundTransfer
Analyse de groupe
Computing function CP
30 Solution de l’étude de cas
Computing function CV
Network transf er time
20
10
0
D…
D…
D…
D…
D…
D…
D…
D…
D…
D…
A…
A…
A…
A…
A…
C4
C5
C1
C2
C3
N4
N3
N5
N1
N2
240
Sécurité des SGBD
Focus sur les droits d’accès
Exercice: injection SQL et droits d’accès

241
Sécurité des SI (ITSEC)
Information Technology Security Evaluation Criteria
• Confidentialité
– Seules les personnes autorisées ont accès aux ressources
• Intégrité
– Les ressources du SI ne sont pas corrompues
• Disponibilité
– L’accès aux ressources du SI est garanti de facon
permanente
• BD: les ressources sont les données de la BD + traitement
activables sur les données
• Et dans certains contexte
– Auditabilité, imputabilité
242
Besoins de protection (1)
• Omniprésence des bases de données
– Grands systèmes d’information (publics ou privés)
– BD PME
– BD personnelles (agenda, carnet d’adresses, bookmarks …)
– BD "ambiantes" (capteurs, aware home …)
• L’organisation des données est un facteur de risque

– L’analyse d’une collection d’informations insignifiantes peut
générer des résultats sensibles
• L’inter-connexion croissante en est un autre

– Connexions permanentes, accès ubiquitaires, objets
communicants
243
• Sous traitance de l’hébergement de données (DSP)
– Hébergement de site Web, délégation de la gestion du système
d’information d’une PME, dossiers personnels …
– caspio.com, quickbase.com, primadoctor.com …
– Nombreuses violations de chartes d’intimité [voir AKS02]
• Vulnérabilité des serveurs d’entreprise
– Source CSI/FBI : coût des attaques BD  $100 milliards/an, 50% des
attaques sont internes
– Même les plus sûrs sont attaqués (FBI, NASA, Pentagone)
– Sources DatalossDB, ZATAZ (musée des sites français piratés)
• Plus de 3 millions de données sensibles volées au Canada (données clients
avec infos bancaires, cartes de crédit, ...)
• Diffusion d'une BD contenant les informations (identités, adresses, email, ...)
de 13.500 adhérents au parti d'extrême droite anglais
– Source CluSSIF
(Club de la Sécurité des Systèmes d'Information Français)
• Modification du carnet de commande, par un concurrent, d’un équipementier
automobile => ruptures de stock gravissimes
• Pénétration du système de facturation de British Telecom => divulgation de
listes de N° de tél (services secrets, famille royale)
244
• Indexation des bases de données
– "Google entre vie privée et secret défense" (source : confidentiel.net)
• Négligence
– Mise en ligne des recherches AOL (US), perte de support CD (UK)
– Craquage d'un système bancaire US
(mots de passe trop courts par rapport au nb de comptes gérés)
– Consultation de la facture détaillée d’autrui (télécom brésil)
• Croisement de bases de données
– CAPPS-II (Computer Assisted Passenger Pre-Screening System)
croise des BD pour lutter contre le terrorisme
Ron Rivest : « La révolution digitale inverse les défauts : ce qui était

autrefois difficile à copier devient facile à dupliquer, ce qui était
oublié devient mémorisé à jamais et ce qui était privé devient
public »
245
Exemples d’attaques connues de SGBD
• Attaque à l’anonymat
• Attaques de BD statistiques
• Injection de code SQL (exercice)
• Attaques de bases Oracles
– Oracle Unbreakable
– Origines des failles connues
• Etc…
246
Attaque à l’anonymat
247
Quelques exemples marquants:
croisement de données publiques
Etude de L. Sweeney – 2002 :

Sur la base du recensement de 1990 aux USA, « 87% of the population in
the US had characteristics that likely made them unique based only on
{5-digit Zip, gender, date of birth} » [1].
[1] L. Sweeney. k-anonymity: a model for protecting privacy. Int. J. Uncertain. Fuzziness Knowl.-Based Syst., 10(5), 2002. 248
Quelques exemples marquants :
espionnage entre bons citoyens
Que voulez-vous savoir sur vos amis, voisins, nourrice, employés …?

249
Quelques exemples marquants :
espionnage entre bons citoyens
« The data within the report is compiled from thousands of different sources that
include government, property, and other public record repositories. » 250
Attaque contre des BD statistiques (1)
• Base de données statistique
– Permet d'évaluer des requêtes d'agrégation
• totaux, moyennes, etc.
• Ex. La requête « quelle est la moyenne du taux de leucocytes des patients
ayant plus de 30 ans ? » est permise
– Mais pas les requêtes qui dérivent des infos particulières
• Ex. La requête « quel est le taux de leucocytes de Dupont ? » est interdite
• Ex. de base de données statistique
– Relation Analyse(Patient,H/F,Age,Mutuelle,Leucocyte)
Patient H/F Age Mutuelle Leucocyte
...
Durand F 25 LMDE 3000
Dulac F 35 MMA 7000
Duval H 45 IPECA 5500
Dubois H 55 MGEN 3500
...
251
• Exemple d’attaque simple :
– U veut découvrir le taux de Leucocyte de Dubois
– U sait que Dubois est un adhérent masculin de la MGEN
• Requête 1 • Requête 2
SELECT COUNT ( Patient ) SELECT SUM ( Leucocyte )
FROM Analyse FROM Analyse
WHERE H/F =’H' WHERE H/F =’H'
AND Mutuelle =’MGEN' ; AND Mutuelle =’MGEN' ;
Résultat : 1 Résultat : 3500
 Le système doit refuser de répondre à une requête pour

laquelle la cardinalité du résultat est inférieure à une
certaine borne b
252
Résultat : 10 Résultat : 54300
WHERE NOT ( H/F =’H' WHERE NOT ( H/F =’H'
AND Mutuelle =’MGEN’ ) ; AND Mutuelle =’MGEN’) ;
Résultat: 9 ; 10 - 9 = 1 Résultat : 50800 ; 54300 –
50800 = 3500
• Conséquence :
– Le système doit aussi refuser de répondre à une requête pour laquelle la
cardinalité du résultat est inférieure à N - b
– N est la cardinalité de la relation initiale
253
• Problème :
– On peut montrer que limiter les requêtes à celles pour lesquelles le résultat a
une cardinalité c telle que b  c  N - b n'est pas suffisant pour éviter la
compromission
– Exemple : si b = 2, les requêtes auront une réponse si c est telle que 2  c  8
• Requête 8
• Requête 7
SELECT COUNT ( Patient )
SELECT COUNT ( Patient )
FROM Analyse
FROM Analyse
WHERE H/F =’H'
WHERE H/F =’H' ;
AND NOT (Mutuelle =’MGEN’) ;
Résultat : 6
Résultat : 5
• Conséquence
– U peut déduire qu'il existe exactement un patient masculin qui a la MGEN
comme mutuelle,
– Il s’agit de Dubois, puisque U sait que cette description correspond à Dubois
254
• Conséquence (suite)
– Le taux de Leucocyte de Dubois est facilement découvert de la façon
suivante :
SELECT SUM ( Leucocyte ) SELECT SUM ( Leucocyte )
WHERE H/F =’H' ; WHERE H/F =’H'
AND NOT (Mutuelle =’MGEN’) ;
Résultat : 30300
Résultat : 26800 ; 30300 - 26800 = 3500
255
Les attaques de bases Oracle
• peu nombreuses jusqu’à récemment
– plus de serveurs Web que de bases Oracle
– connaissance d’Oracle limitée
– difficile d’obtenir une version d’Oracle
– bases souvent protégées par un firewall
• de nos jours, intérêt croissant des pirates

– De plus en plus de topics Oracle sur les forums de hackers
– Téléchargement et installation d’Oracle faciles
• Engouement du défi « Oracle Unbreakable »
256
Protection : Solution Oracle ?
• Oracle's 'Unbreakable' Boast Attracts Hackers

– Hack attempts on the company's website have increased to 30,000 per
week.
• Some days after ….
– 'When they say their software is unbreakable, they're lying.'
-- Bruce Schneier
– U.K. security researcher David Litchfield revealed that a common programming
error -- a buffer overflow -- was present in Oracle's application server
257
Attaques : origines des failles...
• Bug constructeur (corrigés par des patchs)
– Ex. Oracle Listener (OL)
• Ecoute les commandes des clients et les transmet au serveur Oracle
• Contacte Oracle via le protocole TNS (Transparent NetWork Substrate)
• Attaque du OL par buffer overflow
– Si un paquet contient plus d’1 Ko de données, le OL plante
– Dans certains cas, ça génère un « core dump »
– .T.......6.,...............:................4.............(CONNECT_DATA=XXXXXXXX/0x5/0x34/0x12/0x54/
0x5/0x34/0x12/0x54/0x5/0x34/0x12/0x54/0x5/0x34/0x12/0x54/0x5/0x34/0x12/0x54/0x5/0x34)
• Bug configuration (pd de paramètres)
– Ex. Attaque OL par script de commandes TNS
• Certaines commandes ne demandent aucune autorisation
– Ex. demande de version (tnscmd version -h adresse_du_serveur -p 1521); de statut (tnscmd
status -h adresse_du_serveur -p 1521)
• Le pirate obtient les infos suivantes: version d’Oracle, système d'exploitation, chemins vers les
logs, options du Listener (Ex. option security), environnement complet (variables système) dans
lequel Listener a été lancé
– Pour se protéger : Activer l'option security dans OL, utilisation d’une authentification forte,
etc.
• Bug architectural (pb de conception de l’appli)
• Etc.
258
DBMS : qui attaque ?
• Pirate externe Pirate
externe
– capable de s’infiltrer sur le serveur
BD et de lire ses fichiers
– capable de casser une clé de
chiffrement avec un texte connu
• Pirate utilisateur
– est reconnu par le SGBD et a accès
Pirate
à une partie des données utilisateur
– suivant le mode de chiffrement, il a
accès à certaines clés Pirate
administrateur
• Pirate administrateur (DBA)
– employé peu scrupuleux ou pirate Client C1
s’étant octroyé ces droits

Client C2
– a accès à des données BD
BD
P.M.E.
inaccessibles aux autres pirates Client C3
(journal)
– peut espionner le SGBD pendant Serveur BD
l’exécution 259
Principales défenses
0- Tolérance aux pannes
260
Plan de la suite
9 - Législation
1 - Authentification
2 - Sécurisation des communications
3 - Autorisations
4 - Chiffrement de la BD
5 - Audit
8 – Anonymisation
261
9 - Législation
• Protection juridiques
• Suivies par les SGBD hippocratiques
262
Data Protection Directive 95/46/EC
263
Data Protection Directive 95/46/EC
264
Face à la réalité (ex 1: consentement)
265
Face à la réalité (ex 2: anonymisation)
266
1 - Authentification
• Base : login + password

• Nombreux protocoles
– Certains à base de systèmes matériels sûrs (carte à puce)
267
Réglage des profiles Profil des
utilisateurs
SGBD
BD
Authentification par l’OS
• Authentification : via l’OS ou directement par le SGBD

• Profile Utilisateur
– Permet d’associer différents paramètres au protocole d’authentification et à la
gestion des mots de passe
• Par exemple, sous ORACLE
– REMOTE_OS_AUTHENT = True : l’authentification aura lieu par l’OS
• Risque : un protocol non sûr (comme TCP) peut être utilisé pour se logger à L’OS…
– FAILED_LOGIN_ATTEMPTS : nombre d’échecs de tentative d’accès avant que le compte ne
soit verrouillé
– PASSWORD_LIFE_TIME : durée de vie en jours d’un mot de passe
268
Des bonnes pratiques connues…
• Choix des « logins »
– Craquage d'un système bancaire US …
• Une politique d’administration des mots de passe

– Résistance aux injection SQL sur la liste des login / mots de passe
– Distribution/transmission du mot de passe lors de la création du compte
– Expiration, complexité, etc.
• Retirer les utilisateurs par défaut (!)

– Plus de 600 utilisateurs par défaut dans Oracle Server
• Exemple : utilisateur SCOTT (mot de passe TIGER) sous ORACLE
– Audit HSC (2005 FR)
• 80% des firmes laissent les utilisateurs par défaut...
269
2 - Chiffrement des communications
• Technologie éprouvée
– ex: SSL, y compris par carte à puce
• Techniques cryptographiques
– Confidentialité et intégrité des messages
– Non répudiation des transactions 270
Confidentialité et intégrité des messages
• Risques lors de la transmission des requêtes et des résultats

entre le client et le serveur
SGBD
BD
Ecoute
Interception
Altération
Rejeu
271
Chiffrement et signature
• Exemple
– Sous Oracle, utilisation de Oracle Advanced Security
• Chiffrement (avec OAS)
– Chiffrement de bout en bout
• Chiffrement symétrique
• Supporte AES
– Pas de chiffrement des données stockées
• Signature
– Pour éviter des manipulations des données lors de la transmission
– Message Digest Value
272
5 - Audit
• Toutes les actions sont auditables…

• Problèmes: quoi auditer ? Quoi rechercher ?
273
Objectifs de l’audit
• Sécurité
– Identifier les usages illicites
• Utilisateurs cherchant à outrepasser leurs droits (inférences),
Injection SQL ou Attaque d’un Cheval de Troie (dump), Pertes de
données suspectes (suppressions), etc.
– Identifier les données / comptes compromis
– Tracer des usages exceptionnels (ex: bris de glace)
– Vérifier la conformité d’un usage (ex: prise de décision
médicale)
• Performance
• Amélioration organisationnelle, financière, etc.
274
Comment auditer ?
• L’audit du SGBD peut concerner les objets de la base
– Tables, vues, index, procédures, etc.
– Créations, modification, destruction, mises à jour, etc.
… et toutes les actions systèmes
– Connections à la base, attribution des privilèges, etc.
• Tout peut être audité
– Problème: le volume et l’exploitation de l’audit…
• Moyens:
– Audit par des déclencheurs (triggers)
– Audit en utilisant la commande AUDIT, peuplant la table
d’audit du SGBD
275
Audit par Triggers
• Triggers crées par l’administrateur BD/sécurité
– Déclenchés sur des événements « systèmes » (LOGON,
CREATE, DROP…)
• Localité de l’événement contrôlable (dans un schéma, etc.)
– Déclenchés sur des événements « objets » (INSERT,
DELETE, UPDATE)
• Avantages: faible volume, analyse ciblée
– choix fin des actions à auditer, activation à la demande
• Limites: certaines actions son difficiles à auditer
– Ex: auditer les requêtes (SELECT)
276
Le mode AUDIT du SGBD
• Les actions auditées sont stockées:
– Dans une table du SGBD (Oracle: SYS.AUD$)
– Dans un fichier de l’OS (permet l’audit de plusieurs bases)
• Actions auditables:
– Les connexions à la base
– Les actions qui affectent un type d’objet (table, rôle, etc.)
– Les actions qui affectent un objet (table EMP)
… Aussi bien pour les actions réussies et non réussies
• Activer / désactiver l’audit:
– ALTER SYSTEM SET audit_trail=db,extended scope=spfile;
• Puis redémarrer l’instance Oracle…
– NOAUDIT ALL;
277
Utilisation de la table d’audit
• Table d’audit Oracle:
– SYS.AUD$ du tablespace SYSTEM
• L’archiver et la purger périodiquement:
– Privilège DELETE_CATALOG_ROLE
• Pour consulter l’audit:
– L’interroger en SQL la table SYS.AUD$
– Utiliser les vues de l’audit_trail
• DBA_AUDIT_OBJECT,
• DBA_AUDIT_STATEMENT,
• DBA_AUDIT_SESSION,
• etc…
278
Types d’audit
• Audit de connexion
– Audite chaque tentative de connexion:
Ex: AUDIT SESSION [WHENEVER [NOT] SUCCESSFUL];
– Résultat de l’audit: SYS.AUD$, DBA_AUDIT_SESSION
• Audit des actions
– Audite chaque tentative d’action d’un certain type
Ex: AUDIT CREATE TABLE; AUDIT ROLE;
AUDIT CONNECT; AUDIT DBA; …
• Résultat de l’audit: SYS.AUD$, DBA_AUDIT_STATEMENT
• Pour arrêter l’audit: commande NOAUDIT
Ex: NOAUDIT CREATE TABLE, NOAUDIT ROLE; …
• Audit des objets
– Audite un objet particulier (par session, ou par accès)
Ex . AUDIT INSERT ON EMP; AUDIT DELET ON COM BY SESSION
– Résultat de l’audit: SYS.AUD$, DBA_AUDIT_OBJECT
279
Conclusion sur l’audit
• Contrôler le volume et le contenu de la table d’audit
• Limiter le droit de supprimer dans la table
– Attention au DBA et à tous les utilisateurs ayant le privilège
DELETE_CATALOG_ROLE
• Toute actions ou tentative d’action sur la table d’audit
peut être auditée elle aussi
280
8 – Anonymisation de données
• Une donnée personnelle est reliée à un individu

• Une donnée est dite anonyme si elle ne peut pas, de
quelque manière que ce soit, être reliée à un individu donné
Skip…
281
Donnée personnelle vs anonyme
• Définitions
– Une donnée personnelle est reliée à un individu
– Une donnée est dite anonyme si elle ne peut pas, de
quelque manière que ce soit, être reliée à un individu donné
• Application à une base de données
– Des enregistrements (tuple) anonymes ?
282
Intérêt « industriel » pour l’anonymat
• Calculs statistiques sur des données personnelles
– Intérêt commercial évident…
– Marketing et publicité (profilage)
– Compagnies d’assurance et banque (évaluation du risque,
tarification des contrats)
– Santé, recherche (études épidémiologiques), etc.
• Mais des difficultés (au moins pour l’Europe)…
– 1) Obtenir le consentement de l’usager
– 2) L’informer du traitement statistique, etc.
… qui ne se posent pas si les données personnelles
sont rendues « anonymes »…
– Car ces données n’entrent pas dans le champ de la loi
(depuis 2004) 283
Anonymisation : le principe
Données Données anonymes

personnelles (non personnelles)
Individus
Serveur de Serveur de
confiance statistiques
284
284
Anonymisation : les techniques
• Pseudonymat: remplace les identifiants par des pseudonymes
– Hachage (cryptographiques) des identifiants
– Conservation des colonnes sensibles utiles
• k-anonymat: cache chaque individu dans une classe de k individus
– Généralisation et suppression des quasi-identifiants
– Conservation des colonnes sensibles utiles
• l -diversité: diversifie les valeurs sensibles des classes
– Complète le k-anomymat
– Contrôle les valeurs sensibles présentes dans chaque classe
• t-fermeture: contrôle la distribution des valeurs sensibles
– Complète le k-anonymat et la l-diversité
– Contrôle la distribution des valeurs sensibles dans les classes
• Garantie différentielle de l’anonymat
– Ajoute de bruit
– Assure qu’un résultat anonyme change très peu avec ajout d’1 individu supplémentaire
• Suivi de cohorte
– M-invariance: les résultats successifs pour une population restent anonymes
285
Le pseudonymat…
• Base du pseudonymat
– Retirer les identifiants et les remplacer par un pseudo
Identifiants
(ID)
SSN Activity Age Diag Pseudo Activity Age Diag

123 "M2 Stud." 22 Flu ABC "M2 Stud." 22 Flu
456 "M1 Stud." 25 HIV MNO "M1 Stud" 25 HIV
789 "L3 Stud." 20 Flu XYZ "L3 Stud." 20 Flu
Données Données anonymes
personnelles (non personnelles)
…ne garantie pas l’anonymat !

286
Etude de L. Sweeney – 2002 (1)
• Un fichier anomyme produit par une compagnie d’assurance
– Sans d’identifiant (ni nom, ni numéros de sécu, etc.)
– Avec des données sensibles (traitement médical, diagnostique, etc.)
– Et d’autres non sensibles (code postal, genre, etc.)
• Un fichier nominatif (liste de grands électeurs)

– Des identifiants (nom, adresse, parti politiques, etc.)
– Des champs non sensibles (code postal, genre, etc.)
• Ces deux fichiers étant publics…

– L’identité de certaines personnes ne peut pas être préservée
– Sweeney retrouve facilement le dossier médical du gouverneur W. Weld
Comment dé-anonymiser les données ?

Quelle est la proportion de personnes qui reste protégée?
287
Etude de L. Sweeney – 2002 (2)
• Jointure des deux fichiers sur les données non sensibles
• Sur la base du recensement de 1990 aux USA

– « 87% of the population in the US had characteristics that likely made
them unique based only on {5-digit Zip, gender, date of birth} » [1].
[1] L. Sweeney. k-anonymity: a model for protecting privacy. Int. J. Uncertain.

Fuzziness Knowl.-Based Syst., 10(5), 2002. 288
k-anonymat
[Sweeney]
• Le k-anomynat répond au problème du pseudonymat

• Base du k-anonymat Identifiers Quasi-Identifiers Sensitive data
1) classifier les données (ID) (QID) (SD)
SSN Activity Age Diag
2) retirer les identifiants (comme pour le pseudonymat)

3) supprimer et/ou généraliser les quasi-identifiants (restent vrais!) …
… de manière à former des classes d’individus équivalents de taille k
Name Activity Age Diag Activity Age Diag

Sue "M2 Stud." 22 Flu "Student" [20, 22] Flu
Pat "MC" 27 Cancer "Student" [20, 22] HIV Jeu 3-anonymes
Dan "PhD" 26 Cancer "Student" [20, 22] Flu (par généralisation)
Bob "M1 Stud." 21 HIV
Bill "L3 Stud." 20 Flu "Teacher" [24, 27] Cancer
San "PhD" 24 Cancer "Teacher" [24, 27] Cancer
"Teacher" [24, 27] Cancer
289
k-anonymat : algorithme de Mondrian
290
Le k-anonymat garantit que…
• Un individu donné est toujours associé à
au moins k individus participants au jeu anonyme
– C’est-à-dire à tous ceux appartenant à une même classe
– Par exemple: « Sue » est associée à au moins 3 tuples du
jeu 3-anonyme
Activity Age Diag

Name Activity Age Diag
"Student" [20, 22] Flu
Sue "M2 Stud." 22 Flu "Student" [20, 22] HIV
Jeu 3-anonyme
(par généralisation)
291
291
… mais ne garantit pas tout
• Il n’y a pas de contrôle sur les valeurs des attributs
sensibles associées dans une même classe de taille k
– On peut donc avoir moins de k valeurs sensibles par classe
– Voire même une seule valeur sensible !
• Exemple:
– L’individu « Pat » est bien relié à une classe de taille 3…
… mais tous les individus de cette classe ont le même Diag !
Activity Age Diag
Name Activity Age Diag
Pat "MC" 27 Cancer
 Le k-anonymat ne protège pas contre

la dé-anonymisation des attributs sensibles !
292
La l-Diversité
• Complète le k-anonymat
– Afin d’éviter la dé-anonymisation des attributs sensibles
• Assure que chaque classe contient au moins l valeurs

sensibles différentes et « représentatives »
– « représentatives » peut signifier différentes choses
Jeu 3-anonyme
Name Activity Age Diag Activity Age Diag et 3-divers
Sue "M2 Stud." 22 Flu "Student" [20, 23] Flu
Pat "MC" 27 Cancer "Student" [20, 23] HIV
Dan "PhD" 26 Cancer "Student" [20, 23] Cancer
Bob "M1 Stud." 21 HIV
Bill "L3 Stud." 20 Flu "University" [22, 24] Flu
San "PhD" 24 Cancer "University" [22, 24] Cold
John "M2 Stud" 22 Cold "University" [22, 24] Cancer
Jim "M2 Stud" 23 Cancer
[3] A. Machanavajjhala, D. Kifer, J. Gehrke, M. Venkitasubramaniam, L-diversity: Privacy

beyond k-anonymity, ACM Transactions on Knowledge Discovery from Data (TKDD), 2007.
293
La l-Diversité garantie que…
• Un individu donné est toujours associé à
au moins l valeurs d’attributs sensibles différentes
parmi les plus représentatives
– Par exemple: l’individu « Bob » est bien associé à trois
valeurs sensibles représentatives {Flu, HIV, Cancer}
Activity Age Diag
Bob "Student" [20, 23] HIV
"Student" [20, 23] Cancer
– Mais elle ne garantit pas que la classe contienne des

valeurs sensibles reflétant la distribution globale
– Donc: possibilité de discriminer un individu s’il appartient à
une classe « à risque »…
294
La t-fermeture
• Complète la l-Diversité
– Dans chaque classe d’individus, la distribution des valeurs
sensibles suit la distribution globale
(…s’y écarte au maximum d’un facteur t)
– L’appartenance d’un individu à une classe n’apprend rien de
plus sur l’individu que ce qui est connu (distribution globale)
– Exemple Age Gender Diag Count
< 40 M Flu 400
< 40 M Cancer 200 Même distribution
 40 M Flu 400
 40 M Cancer 200
 40 F Flu 400
 40 F Cancer 200
[4] N.Li, T. Li, S. Venkatasubramanian. t-closeness: Privacy beyond k-anonymity and l-diversity. In IEEE
23rd International Conference on Data Engineering, 2007.
295
Suivi de cohorte
• Objectif: produire successivement dans le temps un jeu de
données anonymes correspondant à un groupe d’usagers
(cohorte), pour voir comment les données évoluent
• Problème: les mises à jour des données (suite à un
changement de valeurs sensibles ou à l’entrée ou la sortie d’un
individu dans le groupe) permettent de dé-anonymiser…
– Example

Bob "M1 Stud." 21 HIV "Student" [20, 23] Flu
Bill "L3 Stud." 20 Flu "Student" [20, 23] HIV
t1 Jim "M2 Stud" 23 Cancer "Student" [20, 23] Cancer
Bob "M1 Stud." 21 HIV "Student" [19, 21] HIV

Helen "L1 Stud." 18 Cold "Student" [19, 21] Cold
t2 Jules "L1 Stud" 19 Dysp. "Student" [19, 21] Dysp
=> Sachant que Bob est toujours dans la cohorte, on connait son Diag…
296
Introduction de bruit
• Résolution par introduction de données factices
• La m-Invariance [5]
– Les données ne doivent pas (trop) varier d’une version à la version suivante

Bob "M1 Stud." 21 HIV "Student" [20, 23] Flu
Bill "L3 Stud." 20 Flu "Student" [20, 23] HIV
t1 Jim "M2 Stud" 23 Cancer "Student" [20, 23] Cancer
Bob "M1 Stud." 21 HIV "Student" [20, 23] HIV 2 tuples

Helen "L1 Stud." 18 Cold "Student" [20, 23] Flu
t2 Jules "L1 Stud" 19 Dysp. "Student" [20, 23] Cancer
factices
Gary "PhD" 24 Gast.
"University" [18, 24] Cold
[5] X. Xiao, Y. Tao. M-invariance: towards privacy "University" [18, 24] Dysp.
preserving re-publication of dynamic datasets, In "University" [18, 24] Gast.
ACM SIGMOD 2007
• La garantie différentielle d’anonymat

– Un algorithme offre une garantie différentielle d’anonymat SSI

sont résultat diffère au plus de 0 quand on retire 1 individu (n’importe lequel)
297
La garantie différentielle d’anonymat
• But: répondre à des calculs sur des données privées et fournir
un résultat anonyme avec une garantie
• Idée de base: que les données concernant un seul individu
soient présentes ou non, les résultat des requêtes doivent être
indistingable
Bob "M1 Stud." 21 HIV R: Count « Flu » patients
D: Bill "L3 Stud." 20 Flu
Jim "M2 Stud" 23 Cancer R(D): 1 + bruit = p
D et D’ sont des tables voisines Algo.

(ne diffère que par 1 seul tuple) indistingables
(GDA)
Bob "M1 Stud." 21 HIV R: Count « Flu » patients
D’:
R(D’): 0 + bruit = q
Jim "M2 Stud" 23 Cancer
• Ce modèle résiste aux attaques conduites par des attaquants

“informés” (ayant une connaissance antérieure)
298
Définition formelle
• Distribution des résultats possibles
Base D
Base D’
Probabilité
Résultat de la requête (ensemble S)

(count « Flu » patients)
• L’algo. A offre une garantie différentielle d’anonymat de A SSI:

Paramètre d’anonymat
299
La garantie différentielle d’anonymat (3)
• Des algorithmes d’anonymisation offrent ce type de garanties
– Ex: (a, b)algorithm [14] [14] Vibhor Rastogi, Dan Suciu and Sungho Hong, The Boundary
between privacy and utility in data publishing, in VLDB 2007
• Problème:
– Le système ne peut plus fournir de résultats précis après un certain
nombre de requêtes
– L’analyste qui a consommé toutes ses requêtes est bloqué 300
Conclusion sur l’anonymat
• Très important pour l’industrie
– Permet de calculer des statistiques
– En sortant de la régulation sur les données personnelles
• De nombreuses techniques
– Pseudonymat
• Une phase incontournable mais très insuffisante
• Garanties d’anonymat très faibles voire inexistante
– k-anonymat, l-diversité, t-fermeture
• Le k-anonymat empêche la dé-anonymisation des tuples par jointure sur les
quasi-identifiants
• Le k-anonymat est préconisé aux USA
• Il ne garantie pas la dé-anonymisation des attributs sensibles
• Une famille de techniques complète les garanties d’anonymat
… mais réduisent fortement l’usage
– Difficile d’assurer l’anonymat pour des versions successives
• Ou conduit à dégrader très fortement l’usage… 301
Transactions
Concurrence d’accès
Pannes
Transactions distribuées
Exercice: concurrence dans OracleXE

302
Gestion de transactions
Incohérence possible...
Etat cohérent Etat cohérent
Rollback
Begin Commit
Transaction
Séquence d'instructions d’un programme de base de données
encadrée par un ordre de début et de fin de transaction faisant
passer la base d’un état cohérent à un état cohérent.
Begin
CEpargne = CEpargne - 3000
CCourant = CCourant + 3000
Commit T1
Aucune opération ne peut être exécutée hors transaction
(transactions chaînées). Une transaction peut se terminer par
une validation (Commit) ou un abandon (Rollback)
303
Les propriétés ACID
• Problèmes liés aux transactions :
– Concurrence d’accès
– Violation de la cohérence
– Pannes
BD
• de transaction : ex. annulation
• du système : ex. crash serveur
• de media : ex. perte du disque
• de communication : ex. défaillance réseau
• Un SGBD garantit l'exécution ACID de toute transaction :

– Atomicité : la transaction s'exécute en tout ou rien
– Cohérence : la transaction respecte les contraintes d'intégrité
– Isolation : la transaction ne "voit pas" l'effet des autres transactions
– Durabilité : les effets d'une transaction validée persistent
304
Problème de la concurrence d’accès
• Les protocoles de concurrence sont nécessaires

– Sinon conduit le SGBD à des erreurs
• La difficulté : des protocoles performants
• Les techniques
– Degrés d’isolation
– Multi-versions
– Modification des programmes
• Leur utilisation sur des exemples
305
Isolation : définition du problème
• Scénario 1 :
– Joe consulte son compte (lectures) au moment où sa banque le crédite de 500 euros (écritures)
 Blocker le crédit ? Le montrer à Joe ?
• Scénario 2 :
– Joe retire 200 euros (écritures) au même moment où sa banque le crédite de 500 euros (écritures)
 Blocker le crédit ? Ne pas le perdre !
• Scénario 3 :
– Une analyse des ventes (lectures) est faite dans un supermarché alors que les caisses sont ouvertes
(écritures)
 La lecture ne doit pas bloquer les caisses !
• Scénario 4 :
– Les places de la finale de la coupe du monde sont mises en vente sur Internet le lundi à 8h (conflits
massifs)
 conflits massifs !
• Scénario 5 :
– Réservation SNCF (lectures (choix) puis écritures (achat))
 Comment éviter de bloquer tout le monde ?
• Objectif :
Chacun doit travailler en isolation i.e. comme si il était seul utilisateur de la base de données
306
Exécution sans contrôle
• Absence de contrôle Scénario 2 – Perte d’opérations
– Perte d’opérations
T1 (Joe) T2 (banque)
– Observation d’incohérence
– Introduction d’incohérence Begin
– Lectures non reproductibles Lire CCx
Begin
Lire CCx
Protocole de concurrence x = x + 500
But: éviter les problèmes Ecrire X  CC
et rester performant Commit T2
x = x –200
Ecrire X  CC
• A base de verrouillage: Commit T1
– Verrou en lecture : partagé
– Verrou en écriture : exclusif temps
307
Protocole de Verrouillage à 2 Phases
verrous
T
Lecture Ecriture
Lecture
Ecriture
temps
• Règle 1 : verrouillage
– Avant d'accéder à une donnée D, une transaction doit acquérir un
verrou sur D. Si D est déjà verrouillée dans un mode non
compatible, la transaction attend.
• Règle 2 : deux phases
– Dès qu'une transaction relâche un verrou, elle ne peut plus acquérir
de nouveau verrou
• Verrouillage 2 phases stricts
– Les verrous sont gardés jusqu’au commit
308
Optimisation des transactions
• L'objectif, en termes de performances, est de réduire :
– les blocages : une transaction est bloquée en attente d’un verrou
– les inter-blocages : un ensemble de transactions s’attendent
mutuellement
T1 T2
• Solutions existantes T3 T4
– Degrés d’isolation
– Protocoles multiversions
– Modification des données / programmes
309
Degrés d'isolation SQL – normalisés SQL2
• Objectif: accroître le parallélisme en autorisant certaines
transactions à violer la règle d'isolation
• Degrés standardisés SQL2
(Set Transaction Isolation Level)
– Degré 0 (Read Uncommitted)
• Lecture de données sales – Interdiction d’écrire.
• Ex. lecture sans verrouillage
– Degré 1 (Read Committed)
• Lecture de données propres – Ecritures autorisées
• Ex. Verrous court en lecture, long en écriture
– Degré 2 (Repeatable Read)
• Pas de lecture non reproductible
• Ex. Verrous longs en lecture et en écriture
– Degré 3 (Serializable)
• Pas de requête non reproductible (fantôme)
310
Degrés d'isolation SQL : exemples
T1(°0, Read uncommited) T2(°3, serializable) T1(°1, Read commited) T2(°3, serializable)
Begin Begin Begin Begin

Lit CC ( 100) Lit CC ( 100)
Lit CC ( 100) Lit CC ( 100)
Ecrire CC, CC+10 Ecrire CC, CC+10
Lit CC ( 110) Lit CC ( bloque)
Ecrire CC, CC+20 Ecrire CC, CC+20
Lit CC ( 130) Commit
Commit ( 130)
T1(°2, Repeatable read) T2(°3, serializable) T1(°2, Repeatable read) T2(°3, serializable)
Begin
Begin Begin Select count(*) from Voit
Lit CC ( 100) where couleur="rouge"
Lit CC ( 100) Begin
Ecrire CC, CC+10 Insert into Voit
Lit CC ( 100)  bloque values (R4, "rouge")
Commit
Lit CC ( 100) Select count(*) from Voit
Commit where couleur="rouge"
Ecrire CC, CC+20 Commit
311
Protocoles multiversions (Oracle)
• Objectif : faire cohabiter sans blocage des transactions conflictuelles
en les faisant travailler sur différentes versions des données
T1(°1, Read commited) T2(°3,serializable) T1 (°3, serializable) T2(°3,serializable)

Lit CC ( 100)(V1) Lit CC ( 100)(V1)
Lit CC ( 100)(v1) Lit CC ( 100)(v1)
Ecrire CC, CC+10 (V2) Ecrire CC, CC+10 (V2)
Lit CC ( 100)(V1) Lit CC ( 100)(V1)
Commit Commit
Lit CC ( 130)(V2) Lit CC ( 100)(V1)
T1 (°1, Read commited) T2(°3, serializable) T1 (°3, serializable) T2(°3,serializable)

Lit CC ( 100)(V1) Lit CC ( 100)(V1)
Lit CC ( 100) (v1) Lit CC ( 100)(v1)
Ecrire CC, CC-50 (V?) Ecrire CC, CC-50 (V?)
 bloque Ecrire CC, CC+20 (V2)  bloque Ecrire CC, CC+20 (V2)
Commit Commit
Ecriture faite (CC = 80) Erreur !
312
Modifications des données / Programmes
• Scénario 4 : Les places de la finale de la coupe du monde sont
mises en vente sur Internet le lundi à 8h
• Une seule donnée  Trop de conflits
• Exemple de solution :
– Idée : partitionner le stade :
– Chaque utilisateur se connectant est
aléatoirement dirigé vers 1 des partitions.
– Le degré de parallélisme est multiplié par le
nombre de partitions.
• Scénario 5 : Réservation SNCF (choix puis achat)

– Si verrouillage dès le début, beaucoup de conflits
– Sinon, risque de perdre la place convoitée
– C’est le deuxième choix qui est implanté …
313
314
Conclusion sur le verrouillage

• Scénario 1 : Compte Joe : lecture / écriture
 Multiversion + Joe en degré Repeatable Read ou Read Commited
• Scénario 2 : Compte Joe : écriture / écriture
 Conflit inévitable quelque soit la méthode (mais rare)
• Scénario 3 : lectures massives / écritures (supermarché)
 Multiversion + degré Read Commited (peu de versions)
• Scénario 4 : écritures massives (coupe du monde)
 Partitionnement du stade
• Scénario 5 : réservations SNCF (lectures puis écritures)
 Transaction 1 = Phase de choix en Multiversion et Read Commited
 Transaction 2 = Phase d’achat en Multiversion et Repeatable Read
 Il est donc particulièrement important de maîtriser les degrés d’isolations et

les notions transactionnelles
314
Tolérance aux pannes
315
0 –Tolérance aux pannes
316
La tolérance aux pannes
• Types de pannes qui peuvent survenir…
– Abandons de transaction (transaction failure)
– Pertes de la mémoire vive (system failure)
– Perte du disque (media failure)
• Ce que l’on veut éviter en cas de panne

– L’exécution partielle de transactions
– La perte de transactions validées
 transgression des règles d’Atomicité / Durabilité

• Solution : des techniques de tolérance aux pannes
– Journalisation, sauvegardes
– Reprise après panne
317
Pannes potentielles et but de la reprise
• Abandon de transaction (trans. failure)
– Levée d’une contrainte d’intégrité
 Éliminer les effets de
– Choix de l’utilisateur l’exécution partielle de
– Plantage de l’application client la transaction
– Problèmes de concurrence
• Verrous mortels (verrouillage)
• Retard de transaction (estampillage)
• Défaillance de site (system failure)  Rétablir les effets des

– Plantage du SGBD transactions validées
– Plantage système d’exploitation  Annuler les effets des
– Coupure de courant transactions non validées
• Défaillance de mém. 2ndaire (media failure)

– Crash partiel/total du disque, incendie, etc.  Rétablir les effets de toutes
les transactions validées
 Revient à assurer Atomicité et Durabilité… 318

Abandon de transaction
Contrainte
d’intégrité
Terminal 1 Terminal 2
Abort
client Concurrence
Plantage
client Base de données
Transaction 1 Transaction 2
A  solde1
Défaire 
A  A - sur disque A  solde
Solde1  A AA+
Solde  A
 Commit
A  Solde2 Chronologie
AA+ 
Solde2  A
Commit
 Assurer l’Atomicité
319
Défaillance de site
Plantage Terminal 2
Terminal 1 serveur
Panne de Terminal 3
courant
Base de données
Transaction 1 Transaction 2 Transaction 3

A  solde1 A  solde

A  A - sur A  solde A+
Défaire
Solde1  A
disque Défaire sur
A disque
A+
Refaire surAdisque
Solde  A
Solde  A Commit
 Commit
A  Solde2
Chronologie
AA+
Solde2  A
Commit
 Assurer l’Atomicité et la Durabilité

320
Défaillance de mémoire secondaire
Terminal 2
Terminal 1 Incendie
Terminal 3
Crash disque
Base de données
Transaction 1 Transaction 2 Transaction 3

A  solde1 A  solde

A  A - sur A  solde A+
Défaire
Solde1  A
disque Défaire sur
A disque
A+
Refaire surAdisque
Solde  A
Solde  A Commit
 Commit
A  Solde2
Chronologie
AA+
Solde2  A
Commit
 Assurer la Durabilité
321
Tolérer l’abandon de transaction
• Objectif
– Éliminer les effets de l’exécution partielle de la transaction
• Mise en œuvre
– Effacer la mémoire de la transaction abandonnée (son cache)
• Ne plus rien reporter sur disque de ses effets en cache
– Retirer les effets de la transaction sur disque
• Si aucune modification reportée sur disque  Rien à faire…
• Sinon
– Remplacer les valeurs modifiées par leur valeur avant modification
– Retirer tous les objets ajoutés par la transaction
• Cela suppose
1  Pendant la transaction: Garder l’historique des valeurs avant
modification par la transaction
2  Au commit : Ajouter sur disque les pages modifiées*
et faire un commit atomique
*peut être effectué avant le commit de façon asynchrone 322
Abandon utilisant le journal avant
• Pour retirer du disque les effets de la transaction abandonnée
– Journal avant
• Fichier séquentiel stockant les valeurs avant mise à jour de chaque objet modifié
• Mise à jour d’un objet par la transaction  écriture de sa valeur avant modification
• Le journal est ensuite utilisé pour défaire les mises à jour reportées sur disque
Mises à jour Mémoire de la

transaction
Écrit page
Images avant
Lit page
Lit page
modification
Mémoire
secondaire
Base de données
• Utilisation: on part de la fin du journal, on défait les transactions non validées

dont les effets sont sur disque
323
Tolérer la défaillance de site
• S’appelle aussi la reprise à chaud…
– Perte du contenu de la mémoire vive
• But
– Rétablir les effets des transactions validées avant la panne
– Annuler les effets des transactions non validées
• Mise en œuvre
– Défaire les effets présents sur disque des transactions non validées
• Aucune modification reportée sur disque  rien à faire…
• Sinon  défaire avec le journal d’images avant
 Journal avant en mémoire secondaire (support persistent) !
– Refaire les effets absents du disque des transactions validées

• Si toutes les modifications sont déjà reportées sur disque
– rien à faire…
• Sinon
– Remplacer les valeurs par leur valeur après modification
– Écrire tous les objets crées par la transaction
 Garder les valeurs après création/modification par la transaction
324
Reprise à chaud utilisant les journaux
• Défaire les effets présents sur disque des transactions non validées
– Journal avant, sur un stockage persistant
• Refaire les effets absents du disque des transactions validées
– Journal après (en mémoire secondaire)
• Fichier séquentiel stockant les valeur après mise à jour de chaque objet modifié
• Mise à jour d’un objet par la transaction  écriture de sa valeur après modification
• Le journal est ensuite utilisé pour refaire les mises à jour non reportées sur disque
Mémoire de la transaction
Mises à jour
Écrit page
Lit page
Lit page
Journal avant Journal après
Défaire Refaire
Mémoire
secondaire Base de données
• Utilisation : on part du début du journal, on refait les transactions validées dont les effets ne
sont pas sur disque
325
Conclusion sur l’utilisation des journaux
• Abandon de transaction
– Journal avant : défait les effets sur disque de la transaction
• Utile si on reporte le cache de la transaction sur disque avant validation
• Peut être en RAM
• Il n’est plus utile une fois la transaction validée
• Il contient donc les image avant de chaque transaction non validée
• Reprise à chaud
– Journal avant : pour défaire
• Utile si on reporte le cache de la transaction sur disque avant validation
• Doit être en mémoire persistante
– Journal après : pour refaire
• Utile si on ne reporte pas le cache de la transaction après validation
• Doit être en mémoire persistante
• Il n’est plus utile une fois tous les effets de la transaction reportés sur disque
• Il contient donc les images après de chaque transaction non reportée
 La gestion du cache détermine l’existence des journaux
326
Politiques de gestion de cache
• Détermine l'instant du report sur disque des pages modifiées
– STEAL (resp. NO_STEAL)
• Des pages modifiées par des transactions non validées peuvent être reportées sur
disque
– FORCE (resp. NO_FORCE)

• À la validation d'une transaction, toutes les pages qu'elle a modifiées sont
obligatoirement présentes sur disque
• Politiques de gestion de cache possibles

– NO-STEAL / FORCE
– STEAL / FORCE
– NO-STEAL / NO-FORCE
– STEAL / NO-FORCE : aucune hypothèse sur la politique de gestion de cache

( politique considérée par les SGBD commerciaux)
 Détermine le mode de gestion du journal en cas de reprise à chaud

327
No-steal, Force
• Avantage: Presque rien à faire pour la reprise à chaud…
• Reprise à chaud des transactions validées
– Tous les effets de la transaction sont dans la base
 Inutile de refaire des mises à jour
• Reprise à chaud : des transactions non validées…

– …. Dont les effets ne sont pas dans la base
 Inutile de défaire des mises à jour Mémoire de la transaction
Mises à jour
– Cas de la panne pendant le commit
Lit page
Lit page
– Une partie des effets de la
transaction est dans la base
Gérer sur disque un mini-journal
temporaire d’images avant pour
défaire la transaction… Mini-journal
Base de données (temp.)
• Mais: mauvaises performances…

– BUT: support du mode STEAL / NO FORCE 328
Steal => journal avant
• Des pages modifiées par des transactions non validées peuvent être déjà
reportées sur disque
• En cas de panne avant le commit, l’Atomicité n’est pas assurée
 Stocker les images avant pour défaire éventuellement les mises à jour
Écrit pages Mises à jour
WAL
Lit page
Lit page
Steal
Journal avant
Mémoire
• Règle du Write Ahead Logging (WAL)

– Toute mise à jour est précédée d'une écriture dans le journal d'images avant
permettant d'invalider cette mise à jour en cas de ‘panne’ 329
No-force => journal après
• Les pages modifiées par une transaction ne sont pas toutes nécessairement
reportées sur disque au commit
• En cas de panne après le commit, la Durabilité n’est pas assurée
 Stocker les images après pour refaire éventuellement les mises à jour
Mises à jour
Force log
Lit page
Lit page
Commit
Journal après
Mémoire
Base de données secondaire
• Règle du Force Log at Commit

– Toute validation de transaction doit être précédée de l'écriture de son journal
d'images après sur un disque différent de celui contenant la base de données
330
Steal, No-force : défaire et refaire
• Steal
– Mises à jour peuvent être effectuées dans la base avant le commit
 Défaire les mises à jour non commises (journal avant)
• No-force
– Mises à jour pas forcément reportées dans la base après le commit
 Refaire les mises à jour commises (journal après)
 Les problèmes possibles : panne avant/après commit

Mises à jour
WAL Force log

Lit page
Lit page
Journal avant Journal après

Steal
Défaire Refaire
Panne après commit Panne avant commit
Mémoire
331
Tolérer la défaillance de mém. 2ndaire
• S’appelle aussi reprise à froid…
– Perte du contenu de la mémoire persistante
• Refaire sur disque les effets des transactions validées

– Reconstruction complète de la base avec le journal après
 Journal après sur un autre disque !
WAL Mises à jour Force log
Écrit page
Lit page
Lit page
Journal
avant Journal après
Défaire Refaire
Mémoire
Base de données
secondaire
332
Algorithme de reprise à froid
• Performances: utilisation de « backup »
(ie, points de reprise ou « checkpoints »)
– Recharger la base avec le dernier « backup »
– Refaire les transactions validées du journal redo log (image après)
• NB: le backup peut être réalisé à partir du redo log…
Réduit la taille
sur disque du
Sauvegarde du journal
journal après Journal après
Force Log at Commit
Chronologie
Disponible? Disponible!
Sauvegarde de
la BD
Pour
reconstruire
plus vite…

Base de données
333
Conclusion sur la journalisation
• Journaux : qu'y trouve t-on ?
– Identifiant de la transaction
– Identifiant de l'enregistrement de la BD
– Valeur avant
– Valeur après
• Défaire
– Lecture de la fin vers le début du journal des images avant
– On défait toutes les transactions non commises
– Garantir l‘Atomicité des transactions
• Refaire
– Lecture du début vers la fin du journal des images après
– On refait toutes les transactions validées
– Garantir la Durabilité 334
Vrai ou faux ?
• Le concept de transaction (ACID) n’est nécessaire que dans le cas où il y a
plusieurs utilisateurs Faux (même pour I!)
• Les protocoles de reprise assurent uniquement l’Atomicité et la Durabilité

des données Oui, par définition
• Le SGBD doit assurer la validation et la durabilité de la transaction dès qu’il

reçoit le commit Quand il a répondu favorablement au commit
• Le crash du disque servant à stocker le journal après empêche la reprise à

froid C’est son rôle
• Le group commit empêche de refaire les transactions validées du groupe en

cours Le système répond aux commits seulement si tout le groupe est reporté sur disque
• Le crash du journal avant empêche la reprise à chaud C’est son rôle
• Un point de reprise ne sert qu’à accélérer la reprise à chaud Une optimisation
• Dans un système qui ne tombe jamais en panne, les journaux d’images

avant et d’images après ne servent à rien.
Un ABORT n’est pas une panne et a besoin du journal avant (mais pas journal après) 335
Tolérance aux pannes dans Oracle (1)
• Gestion de cache : steal, no-force

– Des pages modifiées par des transactions non validées
peuvent être reportées sur disque
– À la validation d'une transaction, toutes les pages qu'elle a
modifiées ne sont pas obligatoirement reportées sur disque
 Gestion de journaux avant et après
• Journal avant : les Rollback segments

• Journal après : les fichiers Redo Logs
336
• Les Rollback Segments
– En cas de panne, servent à

défaire des mises à jour
– Un Rollback Segment par T1 T2
transaction active
– Écritures en Rollback Segments
protégées par le journal après Partie active
 les premiers objets restaurés Partie inactive
en cas de reprise après panne…
– Remarque : ce sont ces
segments qui sont utilisés pour
implémenter la lecture cohérente
des données
NB : Read Consistency d’Oracle 

337
• Les Redo Logs
– En cas de panne, servent à refaire des mise à jour
• Ils refont en premier les Rollback Segments
– Les Redo Logs sont remplis en mode circulaire
• On en sauve un sur disque pendant que les autres se remplissent
• Il doit y avoir au moins deux fichiers formant les Redo Logs
« switch »
Fichier log 1 Fichier log 2
« switch »
Sauvegarde du
journal après
– Écriture sur disque des Redo Logs

• Au commit
• Quand le buffer cache stockant les logs est rempli au tiers
• Lors d’un checkpoint
• Après time-out
338
Conclusion – Tolérance aux pannes
• Le SGBD assure que chaque transaction reste
– Atomique
• Entièrement exécutée ou pas du tout
• Tolérance aux pannes (journal avant, commit atomiques, …)
– Cohérente
• Respecte les règles d'intégrité…
• Comment définir et implanter les contraintes ) voir la suite
– Isolée
• Seules les mises à jour validées sont visibles
• Contrôle de concurrence (verrouillage, estampillage, versionning, …)
– Durable
• Les mises à jour validées ne peuvent jamais être perdues
• Tolérance aux pannes (journal après, checkpoint, …)
339
Transactions distribuées
340
Protocoles
transactionnels distribués
341
Verrou Mortel Distribué
• La majorité des SGBD sérialisent les transactions grâce à un protocole
de verrouillage deux phases
• Chaque site est capable de détecter un verrou mortel local
• Un contrôle externe est indispensable pour détecter un verrou mortel
intersites
T1 T2
SITE 1 SITE 2
T3
SITE 3
342
Résolution du Verrou Mortel Distribué
1) PREVENTION
- Garantir que le problème ne survient jamais
- Combinaison de verrouillage et d'estampillage des transaction (marque
des tuples avec un numéro croissant lors des mises à jour)
2) DETECTION
- Construction d'un graphe d'attente global par union des graphes
d'attente locaux
- En cas de cycle, abandon d'une des transactions du cycle
3) PRESOMPTION
- Annulation des transactions n'ayant pas terminé leur exécution après un
certain délai (timeout)
- Solution normalisée
343
Atomicité globale
• Garantir qu'un ensemble de mises à jour sur plusieurs sites est
totalement exécuté ou pas du tout
• Nécessite un protocole de validation atomique (ACP)
• Exemple: transfert d'argent entre deux comptes gérés par deux
agences bancaires distinctes
Commit (Ti) DB
site A
Serveur
débit(C1,M) site B
Application crédit(C2,M)
DB
Serveur
Commit (Ti)
344
Validation à 2 Phases (2PC)
Coordinateur :
Le composant système du site qui centralise et pilote le protocole
Participant :
Le composant système d'un site qui participe à l'exécution de la
transaction
Phase de vote : Le coordinateur demande à tous les participants s'ils

sont capables de valider la transaction
Phase de décision : Le coordinateur décide la validation si TOUS les
participants votent OK. Il décide l'abandon sinon.
Ce protocole doit être tolérant aux pannes
345
Cas Favorable
COORDINATEUR
PARTICIPANT PARTICIPANT
PREPARE PREPARE
... READY Sauvegarde des MAJ

READY de la transaction dans
COMMIT COMMIT un journal
... ACK ACK

Validation des MAJ de
la transaction dans la
base de données
346
Cas Défavorable (1)
COORDINATEUR
PARTICIPANT
PARTICIPANT
PREPARE PREPARE
READY KO
ABORT ABORT
ACK
ACK
347
Cas Défavorable (2)
COORDINATEUR
PREPARE PREPARE
READY READY
COMMIT COMMIT
ACK
??
COMMIT
ACK
348
Cas très défavorable (3)
COORDINATEUR
PREPARE PREPARE
READY READY
?? ??
En cas de panne du coordinateur pendant la phase d'incertitude des

participants (entre l'envoi du Ready et l'attente de la réponse), les
participants sont bloqués => protocole BLOQUANT
349
Normalisation (nécessaire)
Protocoles OSI-TP et X/Open DTP
Interopérabilité :
OSI-TP définit un protocole de validation TM TM
à 2 phases standard permettant à différents
gestionnaires de transactions de coopérer
pendant la validation d'une transaction protocole OSI-TP
Portabilité : AP
X/Open DTP définit des interfaces standards

assurant la portabilité des applications, TM
RM
des gestionnaires de transactions et
des gestionnaires de ressources
interfaces X-OPEN (API)
350
Protocole OSI-TP
• Standard Open Systems Interconnect de l'ISO [ISO92]
• Objectifs :
- Standardiser la façon d'établir et de gérer les dialogues entre les

différents participants d'une même transaction
- Standardiser un protocole de validation à 2 phases permettant

d'assurer l'atomicité des transactions distribuées
- Standardiser la gestion des reprises après pannes dans ce protocole
- OSI-TP est un protocole 2PC arborescent
351
X/OPEN DTP
• Modèle de référence pour Distributed Transaction Processing [1993]
• Objectif: étendre une sphère transactionnelle à tout type de serveur (SGBD
ou non) et assurer la portabilité de tous les composants d'un
environnement transactionnel
Serveur RPC L
o
Application g
BeginTrans Ok
SGBDR
Begin Commit L
update Trans o
Ok g
update
TID
Commit
Commit
Ok
Transaction
Manager
352
Modèles de réplication
• Règles de correction :
– Sérialisabilité à une copie (one-copy serializability)
• objets physiques = copies d'un même objet logique
• Une exécution de transactions sur des objets physiques est
sérialisable à une copie si elle est équivalente à une exécution
sérialisable de ces mêmes transactions sur les objets logiques
correspondants
– Convergence des copies (eventual consistency)
• En l'absence de nouvelles mises à jour, toutes les copies d'un même
objet finissent par atteindre le même état
• La convergence est une propriété plus faible que la sérialisabilité à
une copie
• On peut converger vers une valeur qui n’a pas de sens pour
l’utilisateur
353
Sérialisabilité à une copie
• Les objets logiques A et B sont répliqués sur les sites S1 et S2
• A1, A2 (resp. B1, B2) sont les objets physiques résultant de la réplication
T1
write(A1) write(B1) write(A2) write(B2)
T2
read(A1) read(B2)
T1
write(A) write(B)
T2
read(A) read(B)
• L'exécution ci-dessus n'est pas sérialisable à une copie mais elle

préserve la convergence des copies
354
Sérialisabilité et convergence
dépendent du modèle de réplication
• 2 modes de propagation des mises à jour

– Synchrone (Eager)
– Asynchrone (Lazy)
• 2 modes de contrôle des copies
– Symétrique (Update Everywhere)
– Asymétrique (Primary copy)
• Donc, 4 modèles de réplication
– synchrone/symétrique (SS)
– synchrone/asymétrique (SA)
– asynchrone/symétrique (AS)
– asynchrone/asymétrique (AA)
355
Propagation synchrone (Eager)
• Les mises à jour sur un objet sont reportées dans la même
transaction, sur l'ensemble de ses réplicas
Transaction T
site S1 site S2 site S3
write A1
write A2
write A3
write B1
write B2
write B3
commit
commit
commit
• Garantit la sérialisabilité à une copie mais

• Côut d’une validation atomique
• Impose une connexion permanente à tous les sites
356
Propagation asynchrone (Lazy)
• Les mises à jour sur un objet sont reportées sur ses réplicas
en mode différé, par le biais de transactions indépendantes
T1 sur S1
write A1
write B1
commit
T2 sur S2
write A2
write B2
commit
T3 sur S3
write A3
write B3
commit
• La cohérence des copies dépend du mode de contrôle choisi

(symétrique ou asymétrique)
357
Contrôle symétrique vs. asymétrique
• Symétrique: tout site est autorisé à mettre à jour sa copie
locale d'un objet
Update A Update A
A1 A2
Update A A3
• Asymétrique: seule la copie maître peut être mise à jour, les autres
copies sont en lecture seule
Update A
Update A
Update A A1 A2
A3
358
Conclusion
359
Conclusion (suite)
360
Théorème CAP
[Brewer’00,Lynch&Gilbert’02]
• Un système distribué ne peut pas garantir en même temps:

– Consistency
• Tous les sites voient le même état des données en même temps
– Availability
• Toutes les requêtes de lecture et écriture aboutissent
– Partition Tolerance
• Le système continue à fonctionner malgré des pertes de message
• Compromis
– Strong Consistency & Weak Availability
• Choix (souvent) traditionnel des SGBD
– Strong Availability & Eventual Consistency
• Choix privilégié des systèmes NoSQL
361
Procédures de réconciliation
• Timestamp
– chaque objet détient le timestamp de sa
dernière opération de mise à jour
– Si TS(objet) > TS(update) => lost update
• Opérations commutatives
– ordre d'exécution indifférent
• Règles spécifiques à une application
– priorité à certains sites, à certaines valeurs, à
certaines opérations
• Construction d'un arbre de versions
362
Réconciliation préservant l’intention
• Transformées opérationnelles
– Principe issu du domaine des éditeurs
synchrones
– Objets répliqués sur chaque site
– Les opérations exécutées sur 1 site sont
diffusées sur les autres
• Opérations sur objets typés
– String: InsertCar, DeleteCar
– Calendar: InsertEvent, DeleteEvent
– XML: AddNode, DeleteNode, ChangeAttr
• Assurer les propriétés
– Causalité
– Convergence 363
Réplication dans Oracle
• Mécanisme de base permettant de capturer les mises à jour sur un
site et de les rejouer sur un autre (Oracle Streams)
• Mutliples paramétrages permettant d’utiliser des combinaisons par
défaut ou ‘programmer’ tout modèle de réplication et écrire ses
propres procédures de réconciliation
364
Réplication dans Cassandra
• Paramètres
– R: nb de replicas lus
– W: nb de replicas écrits
– N: nb de réplicas
– Quorum Q = N/2 + 1
• Différents choix possibles
– Pour R (resp. W) = 1, on récupère la 1ère réponse
• W + R > N  consistency
– R=1, W=N (ROWA)
– R=N, W=1
– R=Q, W=Q
365
Réconciliation dans Cassandra (1)
366
Réconciliation dans Cassandra (2)
• Weak consistency
– Read réparés après l’envoi de la réponse
• Strong consistency
– Read réparés avant l’envoi de la réponse
367
Conclusion sur les transactions
• Principe fondateur des SGBD

• Isolation => concurrence d’accès
• Atomicité, Durabilité => tolérance aux pannes
• Transactions distribuées => protocoles normalisés
• Introduction du Projet Folk-IS…
368
Folk-IS: Opportunistic Data Services
in Least Developed Countries
(vision paper)
Nicolas Anciaux1, 2, Luc Bouganim1, 2, Thierry Delot3,1,
Sergio Ilarri4, Leila Kloul2, Nathalie Mitton1, Philippe Pucheral1, 2
(1) INRIA, France
(2) PRISM, UVSQ, France
BDA 2014 (3) LAMIH, UVHC, France
(4) Univ. of Zaragoza, Spain

15 Oct. 2014
Context
Least Developed Countries: 48 countries, 1 billion people

Meet UN criteria in terms of poverty, human resource weaknesses
and economic vulnerability
Nearly no improvement since the 70s ! Why?
Lack of infrastructures
(electricity, roads, communication network, etc.)
Lack of structure (lack of political commitment, powerful companies, legal…)
[ITU13] Least Connected Countries: 39 countries, 2.4 billion people

Lack of data communication facilities
< 10% inhabitants with a mobile broadband subscription
3G service at prohibitive cost
 ICT access and use is limited to basic voice
Goal: Provide data services to the inhabitants of LDC
ICT is key for development in these countries
Economy, Health, Education, Citizen empowerment, …
Advantages for the community

Have communication means to reach inhabitants in rural communities
Launch e-admin (census), detect epidemics, feed cultural programs, …
Advantages for field workers (infirmaries, teachers, NGOs)

Conduct monitoring programs, consult/fill inhabitants’ folders when visiting them in
a region where even paper folder are difficult to maintain
Advantages for the inhabitants

Hold digital folders (health, school…), communicate, administrative tasks…
Solutions for data services in LDCs
Current (working) solutions ?
Based on SMS exchanges using mobile phones
Track of vaccine cold chains [6], improve agriculture [13], ease admin. process [10]
Interesting, but limited to very specific application scenarios
Toward generic solutions ?
Google project Loon: a network of high altitude balloons

Connect people in rural areas or disconnected zones (after disasters)
Balloons work only for a few days, have limited connectivity (payload limitations)
Google tries to make it work…. Google may also use drones…
Facebook’s Internet.org: low cost wireless handsets with data caching

Provide e-services in developing countries in cooperation with Internet providers
Facebook tries to improve network coverage: Flying solar-powered drones, …
Growing interest for the industry
Provide low cost personal devices & network infrastructure
Main requirements of any ICT solution in LDCs
(1) Low cost : hardware, software, deployment, maintenance
Few dollars per user is a maximum
The lack of infrastructure considered as an assumption
(2) Self-sufficiency
The solution must not rely on rapid improvements of the infrastructure
(3) Privacy protection
Lack of security infrastructure (no coercive laws, trusted servers/authorities, etc.)
Lack of identification means for inhabitants (often have even no id cards)
 IT must provide self-enforcement of privacy principles (P-b-D)
(4) Immediate personal benefit
Lack of economical & political incentives to impose a solution in the field
Additional needs
Users’ empowerment (crucial to make the solution sustainable)
Maintenance should generate a source of revenue for new local jobs
Vision: Folk-enabled Information System (Folk-IS)
IT services are delivered by all folks

Folk-nodes: very low-cost IT devices, personal, secure
…. hosts the digital history of its owner FLASH
Folk-node
FLASH
FLASH
SMCU
Smart tokens
Microcontroller
SMCU
Fingerprint
Terminals (with screen, keyboard, etc.): provided

Existing to
[2] a few field workers
Basic Self-powered ?
(shared fonctionalities, e.g., GPS)
Shared devices
? FLASH
Specific Folk-IS device Smartphone Comp

(delivered to some users) (potentially already owned by us
Vision: Folk-enabled Information System (Folk-IS) (2)
• Mode of operation: Inhabitants apply for digital services
… by connecting their Folk-node to terminals
• People opportunistically perform network & data management tasks as they move
• Folk-net takes advantage of existing infrastructure (if any) to reduce latency
• Additional people (“postman” E) are used when needed to decrease latency
Community 1
M
Internet access
N
C
point
M D
C A B
Merchant
E D
D E
A
First Aid <
Community 2
Folk-node
T
SMCU FLASH A
E A
School
Healthcare scenario
Heatlhcare (current)
Provided by local nurses working in first-aid rooms or intervening in communities
Nurses only possess basic medicines and equipment
No Electronic Health Records system, neither paper-based medical records
Many people have no identity document to link them to their records
People move according to seasons and drought periods
Heatlhcare (Folk-IS)
The patient’s folk-node owns his complete and up-to-date medical folder
The patients authenticate by fingerprint => the link to his record is established
The nurse can also authenticate by fingerprint
Nurses can append diagnosis and treatment information locally
Nurses may request medical advice from a distant doctor and transmit documents
The patient can be notified a few days later, if a serious problem is detected
Global queries can be broadcasted to conduct epidemiological studies
Challenges
Many important challenges are not technical…

Social, economical, cultural (e.g.: economics of innovation/adoption)
Technological focus
Low-cost of ownership, deployment and maintenance
Absence of a networked infrastructure
Database challenges
(1) Privacy preserving data management without any central infrastructure
(2) Routing without any central infrastructure
Privacy preserving data management
Co-design the data engine with a triple goal: Adapt the design to low cost HW
Reducing the overall cost of the device, E.g., SD cards behavior
its energy consumption,
offering flexibility
Data management in an infrastructure-less context Establish local spheres of trust, face-to-face

Identity verification, access control interactions & security properties of folk-nodes
PKI? Certification authorities E.g., an NGO produces an app., data model,
OpenPGP/WoT? Key servers, signing parties home-made identification/AC and pushes
Application deployment it to the Folk-nodes using the Folk-net
Unified data modeling (no common referential)
Determine suitable topologies
Active/passive nodes, netmen, fixed nodes…
Global queries Adopt an open-world assumption,

Distributed databases or peer-to-peer Admit the possibility of approximate answers,
=> knowledge of data location, no mobility Use spacial conditions…
Routing without any central infrastructure
Opportunistic communications
Enable communication (encrypted messages) directly between active Folk-nodes,
or indirectly through shared devices (when passive Folk-nodes connect to it)
Routing protocols : exploit “data mules”

Choose the best candidate to carry messages (avoid flooding the human network)
OLSR / AODV (for MANETs): too many messages for Folk-IS
ZigBee is not reliable against node mobility
Geo-routing requires recipient location & own location of routing nodes
VANET carry-and-forward [16] & content-based dissemination [12]
Differ significantly (e.g., communication range, speed and power of nodes, etc.)
But have good properties (C&F exploit “data mules” => to deliver query results, CBD limit the
number of routing nodes => to disseminate queries to nodes holding potential results)
Mobility prediction : identify “familiar strangers”

Mix geolocation approx., mobility prediction & social interaction to choose the “data mules”
Track “familiar strangers”, predict future movements (local profile, global profile)
Energy saving techniques

Range adjustment, duty cycling, related with communication needs (mobility predictions)
Conclusions
The Folk-enabled Information System (Folk-IS) paradigm

Low-cost secure devices, embedded software components and opportunistic communications
Different from the main line (Google/Fb) but complementary
May answer some identified requirements of ICT in LDCs

(1) Privacy protection: Authentication and access control tasks are embedded in the
tamper-resistant Folk-node, the system is accountable
(2) Personal benefit: Passport for several applications (healthcare, education, etc.)
A new channel to pull/push information from/towards communities previously unreachable
(3) Self-sufficiency: Infrastructure-less, progressively deploys, may benefit from existing

infrastructure
(4) Very low deployment cost: No initial investment, global costs ~ scale of targeted
population, no central administration
Initial study: in cooperation with FUN & LIRIMA – H2020 ICT-39 project proposal
Opportunistic data services in least developed countries:
benefits, challenges and feasibility issues. SIGMOD Record, 43(1), 2014.
Annexe1
JDBC et OCI
381
Chargement du pilote JDBC
• Par invocation de la méthode Class.forName
• Paramètre = chemin de la classe du driver
– (fournit dans la doc. du driver)
• Exemple utilisant le pont (driver) JDBC-ODBC

import java.sql.*;
public class ObjetUtilisantJDBC

{
public static void main(String[] Args)
{
try {Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); }
catch (Exception E) {System.err.println(« Chemin du driver incorrect!");}
// ... Etapes suivantes ...
}
}
382
Connecter la base de données
• DriverManager permet d’établir la connexion avec le SGBD
• Grâce à la méthode getConnection de cette classe
– le driver adéquat est retrouvé parmi les drivers chargés
– un objet Connection est retourné
• Paramètres de la méthode
– Url fournit les informations nécessaires à la connexion
• débute par jdbc:, suivi du sous-protocole (par ex. odbc), suivi par des
informations propres au driver (par ex: le nom de la source de données dans
le cas du pont JDBC-ODBC)
– Nom et mot de passe de l’utilisateur sur le SGBD
• Exemple
import java.sql.*;
{
{
// ... Etapes précedentes...
Connection con = DriverManager.getConnection(jdbc:odbc:Oracle, "scott", "tiger");
}
}
383
Créer une instruction
• Une instruction est représentée par une instance de la classe
– Statement, (instruction SQL statique)
– CallableStatement, (appeler une procédure stockée)
– ou PreparedStatement (instruction SQL précompilée et paramétrée)
• La création se fait à partir de l’objet Connexion en utilisant
(l’objet Connexion est obtenu à la connexion)
– createStatement (SQL statique)
– prepareCall (procédure stockée)
– prepareStatement (SQL précompilé/paramétré)
• Exemple import java.sql.*;
{
{
Statement req1 = con.createStatement();
CallableStatement req2 = con.prepareCall(str);
PreparedStatement req3 = con.prepareStatement(str);
}
}
384
Exécuter l’instruction
• Méthodes (principales) pour exécuter une instruction
– executeQuery pour les requêtes de type SELECT ...
(LMD de consultation)
– executeUpdate pour les CREATE ou INSERT/DELETE/UDATE...
(LDD et LMD de mise à jour)
– execute pour les procédures stockées (entre autre)
• Les méthodes de l’interface Statement (exécution de requêtes
SQL statiques) prennent en paramètre une chaîne de
caractères représentant la requête à exécuter
• Exemple
import java.sql.*;
{
{
req1.executeUpdate("CREATE TABLE contact (nom VARCHAR(50), tel CHAR(10))");
req1.executeUpdate("INSERT INTO contact VALUES (’dupond’, ’0102030405’)");
}
}
385
Traiter le résultat
• La méthode executeQuery retourne un objet de type
ResultSet
– représente un curseur sur le résultat de la requête
– Exemple
ResultSet rs = req1.executeQuery("SELECT * FROM contact");
• La méthode executeUpdate retourne le nombre

– de tuples affectés dans le cas d’un LMD
(INSERT/DELETE/IPDATE…)
– 0 dans le cas d’un LDD (CREATE…)
– Exemple
int nbTuples = req1.executeUpdate("UPDATE contact " +
"SET nom = ’dupont’ " +
"WHERE nom = ’dupond’");
386
Accès aux résultats
(curseur)
• Un curseur permet de parcourir les tuples résultats d’une
requête
– Représenté dans JDBC par l’interface ResultSet
• Fonctionnement
– Le curseur d’un objet ResultSet est positionné avant le premier tuple
– La méthode next permet de faire avancer ce curseur sur le tuple suivant
• retour = false  il n’y a plus de tuples à traiter
• Les valeurs des attributs sont obtenues grâce aux méthodes
getXXX( )
– Paramètre = numéro/nom de colonne dans le résultat
• Exemple // ...
while(rs.next()) {
String nom = rs.getString("nom"); // ou String nom = rs.getString(1);
String tel = rs.getString("tel"); // ou String nom = rs.getString(2);
// ...
}
387
Accès aux résultats
(conversion et valeur nulles)
• Conversion de type
– Les méthodes getXXX convertissent de SQL vers JAVA
SQL Java
CHAR String
VARCHAR String
LONG VARCHAR
String NUMERIC
Boolean TINYINT
Byte SMALLINT
Short INTEGER
Etc…
• Valeurs nulles (NULL de SQL)
– Testé grâce à la méthode wasNull de ResultSet
• wasNull est appelée après la lecture de la valeur
(après l’utilisation d’une méthode getXXX)
– Les méthodes getXXX convertissent les valeurs NULL de
SQL en une valeur acceptable pour le type Java cible
388
Fermer les différents éléments
• (préférable pour libérer la mémoire)

• Les éléments concernés
– Curseurs
– Instructions
– Connexions
– Etc.
• Exemple // ... Etapes précedentes...
rs.close();
req1.close();
c.close();
// ...
389
Les fonctions de JDBC
• Fonctions de bases • Fonctions avancées
– Charger le/les pilotes – Exceptions JDBC
– Se connecter à la base de – Accès aux méta-données
données • Du résultat
– Créer une instruction • De la base de données
• SQL statique, – Exécution de
• appel à procédure stockée, • requêtes précompilées
• précompilée et paramétrée • requêtes paramétrées
– Exécuter l’instruction • procédures stockées
• LMD de consultation, – Exécution par lots (batch)
• LDD et LMD de mise à jour, – Utilisation de curseurs
• procédures stockées – Transactions
– Traiter le résultat – Extension standard (javax.sql)
• Gestion de l’objet ResultSet
– Fermer les différents éléments SKIP
390
Exceptions
• L’exception SQLException peut être lancée par les méthodes
de JDBC
• Elle permet d’obtenir des informations sur l’erreur qui s’est

produite
– une chaîne décrivant l’erreur (méthode getMessage)
– un code d’erreur spécifique au SGBD (méthode getErrorCode)
– une chaîne d’état SQL (méthode getSQLState)
• Les avertissements du SGBD peuvent aussi être capturés par

la classe d’exception SQLWarning
– Un avertissement ne stoppe pas l’exécution du programme
– On utilise la méthode getWarnings de Statement pour les récupérer
391
Accès aux méta-données
• Procurent des informations (méta-données) sur
– le SGBD et le driver JDBC (DatabaseMetaData),
– ou sur le résultat d’une requête (ResultSetMetaData)
• Exemples de méthodes de l’interface DatabaseMetaData

– getSchemas pour la liste des schémas disponibles
– getTables pour la liste des tables
• Exemples d’utilisation de ResultSetMetaData
// ...
ResultSetMetaData rsmd = rs.getMetaData();
int nbColonnes = rsmd.getColumnCount();
// ...
392
Requête précompilée
(création)
• Une requête qui doit être exécutée peut être précompilée en
utilisant PreparedStatement
– Dans un objectif de performance (temps d’exécution)
– La requête est transmise au SGBD (qui la précompile)
• Le plan d’exécution est préparé
– Des variables peuvent être utilisées pour paramétrer la requête
• Création d’une requête précompilée
– A partir de l’objet Connection
– Grâce à méthode prepareStatement
• La requête est passée en paramètre sous forme de chaîne de caractères
• Les paramètres sont représentés par des ‘?’ dans la chaîne
– Le retour est un objet PreparedStatement prêt à être exécuté
• Exemple
// ...
String req = "UPDATE contact SET tel = ? WHERE nom = ?";
PreparedStatement UpdateTel = con.prepareStatement(req);
// ...
393
(paramétrage)
• Avant d’exécuter la requête  fixer les
paramètres
(remplacent les ‘?’ par une valeur dans la chaîne)
– Grâce aux méthodes setXXX
(où XXX représente un type de données Java)
– NB: setNull fixe le paramètre à la valeur NULL de SQL
– Premier argument = numéro d’ordre du ‘?’ à remplacer
– Deuxième argument = valeur de remplacement
• Exemple
// ...
String req = "UPDATE contact SET tel = ? WHERE nom = ?";
PreparedStatement UpdateTel = con.prepareStatement(req);
UpdateTel.setString(1, "0908070605");
UpdateTel.setString(2, "durand");
// ...
394
(exécution)
• Grâce aux mêmes méthodes que pour des

requêtes fixes, mais sans argument
– ExcuteQuery/executeUpdate
– NB: l’instruction contient déjà la requête à exécuter…
• Exemple
// ...
String req = "UPDATE repertoire SET tel = ? WHERE nom = ?";
PreparedStatement updateTel = con.prepareStatement(req);
updateTel.setString(1, "0908070605");
updateTel.setString(2, "durand");
updateTel.executeUpdate();
updateTel.setString(1, "0900000000");
updateTel.executeUpdate();
// ...
395
Procédures stockées
• L’interface CallableStatement permet d’invoquer une procédure
stockée
– NB: la procédure est stockée au niveau du SGBD…
– … la création se faisant avec la méthode prepareCall de Connection
// ...
CallableStatement cs = c.prepareCall("{call nom_procedure_stockee}");
// ...
• La syntaxe de l’appel de procédure (call ...) est traduit par le

driver JDBC dans la syntaxe native du SGBD
• L’exécution de l’instruction se fait de façon classique en
fonction de ce que retourne la procédure
• L’interface CallableStatement est sous-interface de
PreparedStatement et accepte donc des paramètres
396
Transactions
(portée)
• Rappel = une transaction permet d’exécuter un ensemble de
requêtes sur une BD, la faisant passer d’un état cohérent à un
autre état cohérant, respectant les propriétés transactionnelles
(ACID)
• Par défaut, la connexion JDBC est en mode chaîné
– chaque requête est suivie d’un ordre SQL « commit » implicite
• On peut désactiver ce mode
– soit lors de la création de la connexion // ...
c.setAutoCommit(false);
– soit grâce à la méthode setAutoCommit // ...
– La validation doit alors se faire

explicitement par la méthode commit… // ...
c.commit();
– … et l’annulation se fait grâce à // ...
la méthode rollback c.rollback();
// ...
397
Transactions
(concurrence)
• Le niveau d’isolation permet de déterminer les incohérences
que peut subir une transaction (lecture sales, fantômes, . . .)
• Les différents niveaux d’isolation (normalisés) sont
– Connection.TRANSACTION_READ_UNCOMMITTED
• lectures sales, non reproductibles et fantômes peuvent se produire
– Connection.TRANSACTION_READ_COMMITTED
• les lectures sales sont évitées
– Connection.TRANSACTION_REPEATABLE_READ
• les lectures sales et non reproductibles sont évitées
– Connection.TRANSACTION_SERIALIZABLE
• la transaction est complètement sérialisable
– Connection.TRANSACTION_NONE
• indique que les transactions ne sont pas supportées
• Les méthodes getTransactionIsolation et
setTransactionIsolation de Connection permettent de connaître
398
Apports de JDBC 2.0 et 3.0 (1/2)
• Amélioration des curseurs
– Parcours dans les 2 sens, positionnement sur un tuple donné,…
– Méthodes nouvelles:
• previous, first, beforeFirst, last, afterLast, absolute, relative, …
• Mise à jour de la BD au travers des méthodes de Java
– Notamment, au travers de curseurs
– UPDATE
• Méthode updateString de ResultSet,
• puis updateRow pour reporter les changements dans la BD
(avant de déplacer le curseur sur un autre tuple)
– INSERT
• Méthode moveToInsertRow pour déplacer le curseur vers une zone particulière
d’insertion,
• puis méthodes updateXXX pour fixer les valeurs des attributs du tuple,
• puis méthode insertRow pour insérer le tuple dans le ResultSet et dans la BD
• NB: la méthode moveToCurrentRow permet de revenir sur le tuple courant (sur lequel
le curseur se trouvait avant l’appel de moveToInsertRow)
– DELETE
– Positionner le curseur sur le tuple à supprimer,
– puis appel à la méthode deleteRow pour effectuer la suppression
399
Apports de JDBC 2.0 et 3.0 (2/2)
• Envoyer plusieurs instructions à la BD en une fois
– Exécution par batch
– Avec la méthode addBatch de Statement ajouter une
requête dans la liste à exécuter
• NB: La liste peut être effacées avec la méthode clearBatch
– L’exécution des requêtes est ensuite réalisée par la
méthode executeBatch
• Cette méthode retourne un tableau d’entiers représentant le nombre
de tuples modifiés par chaque instruction
• L’exception BatchUpdateException peut être lancée si une erreur se
produit lors des mises à jour
• Support des types SQL3
– Blob, Clob, Array, etc. et ajout des méthodes getXXX et
setXXX correspondantes
400
API propriétaires : exemples de
l’interface OCI (Oracle)
utilisable depuis un code en

Langage C
401
Exemple de la librairie OCILIB
• Une librairie open source

• Pour coder une application en langage C…
… qui interagit avec une base Oracle
• Pour toute plateforme (Windows, Unix, Linux,
Mac....)
• La librairie encapsule les API OCI (Oracle)…
… dans des fonctions simples
• Documentation en ligne :
http://orclib.sourceforge.net/doc/html/modules.html
402
1) Intitialiser la librairie
#include "ocilib.h"
Importer la librairie int main(void)
{
if (!OCI_Initialize(NULL, NULL, OCI_ENV_DEFAULT))

Initialiser la librairie return EXIT_FAILURE;
/* ... application code here ... */
OCI_Cleanup();
Libérer la librairie return EXIT_SUCCESS;
}
403
2) Ouvrir une connexion à la base
#include "ocilib.h"
int main(void)
{
Déclarer une connexion OCI_Connection *cn;
Nom du service Oracle (voir la doc Oracle)

Login/mdp Oracle
return EXIT_FAILURE;
Ouvrir cette connexion cn = OCI_ConnectionCreate("XE", "login", "pwd", OCI_SESSION_DEFAULT);
printf(OCI_GetVersionServer(cn));
Afficher les propriétés printf("Server major version : %i\n", OCI_GetServerMajorVersion(cn));
printf("Server minor version : %i\n", OCI_GetServerMinorVersion(cn));
de la connexion
printf("Server revision version : %i\n", OCI_GetServerRevisionVersion(cn));
printf("Connection version : %i\n", OCI_GetVersionConnection(cn));
OCI_Cleanup();
return EXIT_SUCCESS;
}
404
3) Exécuter une requête SQL
#include "ocilib.h"
int main(void)
{
OCI_Connection *cn;
Déclarer une requête SQL OCI_Statement* st;

cn = OCI_ConnectionCreate("XE", "login", "pwd", OCI_SESSION_DEFAULT);
printf("Server major version : %i\n", OCI_GetServerMajorVersion(cn));
Créer la requête au travers printf("Connection version : %i\n", OCI_GetVersionConnection(cn));
de la connexion st = OCI_StatementCreate(cn);
Exécuter la requête OCI_ExecuteStmt(st, "SELECT * FROM CLI");
au travers de la connexion
La requête à exécuter
OCI_Cleanup();
}
405
4) Parcourir le résultat de la requête
#include "ocilib.h"
int main(void)
{
OCI_Connection *cn;
OCI_Statement* st;
Déclaration du résultat OCI_Resultset* rs;
int nb_col; int i=0; OCI_Column *col;
Déclaration d’une colonne if (!OCI_Initialize(NULL, NULL, OCI_ENV_DEFAULT))
cn = OCI_ConnectionCreate("XE", "login", "pwd", OCI_SESSION_DEFAULT);
printf("Server major version : %i\n", OCI_GetServerMajorVersion(cn));
printf("Connection version : %i\n", OCI_GetVersionConnection(cn));
st = OCI_StatementCreate(cn);
Stockage du résultat OCI_ExecuteStmt(st, "SELECT * FROM CLI");
de la requête rs = OCI_GetResultset(st);
Récupérer la i+1eme colonne
Récupération du nb_col = OCI_GetColumnCount (rs);
nb de colonnes du résultat for(i=0; i<nb_col; i++) {
col = OCI_GetColumn (rs, i+1);
Récupérer le nom de la ième colonne
fficher les noms des colonnes
printf("%s | ", OCI_ColumnGetName (col));
} printf("\n");
while (OCI_FetchNext(rs)) { Récupérer la valeur de la ième
for(i=0; i<nb_col; i++) colonne
ffichage des lignes du résultat sous forme de chaîne de
printf("%s | ", OCI_GetString(rs,i+1));
printf("\n"); caractère
}
OCI_Cleanup();
}
406
Annexe3 : modes de
chiffrement
407
Mode opératoire Electronic Code Book
• Les blocs sont chiffrés indépendamment

by tes
0 8 16
Plain-text 1 (P1) Plain-text 2 (P2) …
EK (P1) EK (P2)
Cipher-text 1 (C1) Cipher-text 2 (C2) …
• Remarque : : P1=P2 => EK(P1)=EK(P2)
408
Mode opératoire Cipher Block Chaining
• les blocs chiffrés intégrent la valeur des
précédents
by tes
0 8 16

Init. Vector (IV)
EK (IV  P1) EK (C1  P2) EK (…)
409
Mode opératoire CTR
• Résultat du XOR entre le clair et un mot aléatoire
by tes
0 8 16
+1 +2 +3
EK (IV+1)  P1 EK (IV+2)  P2
Init. Vector (IV)
410

Cours Yaounde

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

Cours Yaounde

Transféré par

Droits d'auteur :

Formats disponibles

Systèmes de Gestion

Nicolas Anciaux – Nicolas.Anciaux@inria.fr

Ressources web pour ce cours

Requêtes – Fonctionnalités essentielles des SGBD

Transact° – Propriétés transacitonnelles

Yaoundé, février 2014 Nicolas Anciaux 5

• Modélisation des données

• Logiciel «Système de Gestion de Bases de Données»

X - Standards II- Indépendance

IX - Gestion de la III – Langage de

VIII - Concurrence BD IV - Gestion des

VII - Gestion des V - Optimisation des

• Redondance des données et incohérence potentielle

N° Nom Prénom Ville Pays Enfant1 Enfant2 Enfant3 NbEnfants

1 Bar Joe Paris France Paul Zoe 2

2 Dean Pascal Vence France Lili 1

3 Ben Zoe Lyon France Sam Tor Tar 3

4 Cat Tom Lens France 0

Modèle MLD MLT

Objectif du cours : E/A, Merise, UML ?  E/A light, Merise ultra-light

• Type d'entité : représentation d'un ensemble d'entités perçues comme

Entités Type d'entité

• Association : représentation d'un lien non orienté entre plusieurs entités

• Propriété : donnée élémentaire permettant de décrire une entité ou une

• Identifiant d’entité : Une entité est identifiée de manière unique par au

• Identifiant d’association : il n’existe pas

• Pour un prof donné, combien d’enseignements ?

• Pour un cours donné, combien d’enseignements ?

• ‘‘Énoncer le réel’’ à modéliser avec des phrases

• Un médecin reçoit plusieurs patients (voire aucun)  0,n 0,n

• Un patient prendre plusieurs rendez-vous avec un même médecin

Patient à RDV correspond Médecin

Patient à RDV correspond

– Un médecin exerce dans une salle

Patient à RDV correspond Médecin

 Ce MCD est bon Salle

Patient à RDV correspond Médecin

Différences fonctionnelles (A) (B) (C)

Règles (1) respect des règles de gestion

• Une propriété calculée n’est pas à stocker !

• Une propriété constante n’est pas à stocker

Règles (3) : propriétés répétitives

Règles (4) : propriétés sans signification

• Une propriété ne peut être sans signification pour une

Règles (5) : identifiants d’entités

Règles (7) : entités et associations

Règles (8) : pas de dépendance transitive

Première modélisation ‘restreinte’

Modèle entité-association (1/2)

• Gérer les notes des étudiants veut dire:

Théorème de Codd: une question est exprimable en calcul relationnel si

• Le produit cartésien D1x D2x ... x Dn est l’ensemble

VINS CRU MILL REGION COULEUR

CHENAS 1983 BEAUJOLAIS ROUGE

• Définition = Groupe d’attributs minimum qui détermine

• Définition = Groupe d’attributs devant apparaître

BUVEURS NB NOM PRENOM TYPE VINS NV CRU MILL. DEGRE

ABUS NB NV DATE QUANTITE

• CLES ETRANGERES (italique)

RELATIONS NUM BASE NOM NBATT

ATTRIBUTS NUM TYPE NOM NUMREL

• Règle 1 : Chaque propriété devient un attribut.

• Règle 2 : Chaque entité devient une table et son