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/ENSTA/ASI13
1
 Objectifs du module
• Pré requis: connaissances de base (IN206)
– Conception de BD : modèle entité association, modèle relationnel
– Programmation SGBD : SQL, programmation SQL
– Propriétés transactionnelles : Concurrence d’accès
• Objectifs des sessions
– Connaissance générales (culture)
• Raison d’être d’un SGBD
• Fonctionnalités : indépendance physique/logique, vues, langage de
manipulations, cohérence (contraintes d’intégrité et triggers), standards…
– Connaissances avancées
• Optimisation de requêtes
• Droits d’accès
• Tolérance aux pannes
• Audit des accès
• Chiffrement et anomymisation des données

2
 Planning des sessions
Rappel: – Approche bases de données et fonctionnalités essentielles d’un SGBD
(1h30) – Conception de bases de données: modèle entité associations
1 – Modèle relationnel et Algèbre relationnelle
2/11 TD: (2h) – Exercices de conception et d’algèbre

Rappel: – Le langage SQL et programmation SQL

2 Cours: – L’optimisation de requêtes
TD: – Création de base de données relationnelle en SQL (Oracle XE)
7/11 – Expériences sur l’optimisation de questions

Cours: – Contraintes d’intégrité

3 – Triggers SQL et PL/SQL
TD: – Déclaration SQL de contraintes d’intégrité et triggers SQL3
14/11
Cours: – Politique de contrôle d'accès
4 – Modèles DAC-SQL, RBAC, MAC
6/12 – Bases de données privées virtuelles (Oracle VPD), Sécurité multi-niveau (Oracle Label Security)
TD: – Expériences d'implantation de droits d'accès, principe du moindre privilège

Cours: – Tolérance aux pannes, algorithmes de journalisation et de reprise

7/12 5 – Audit des accès : triggers d’audit et outils internes au SGBD
TD: – Expériences mettant en évidence les techniques de tolérance aux pannes
– Outils d’audit disponibles sur Oracle XE

Cours: – Place de la cryptographie dans la sécurité d'un SGBD

8/12 6 – Chiffrement de données et anonymat dans un SGBD
TD: – Utilisation des outils cryptographiques disponibles sur OracleXE

Examen
12/12 7
3
 Compétences à acquérir
• 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)
– Implanter une stratégie de tolérance aux pannes
– Auditer les accès
– Chiffrer des données sensibles 4
 L’approche bases de données
Fonctionnalités logicielles principales

5
 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

6
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

7
 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.

8
 II - Indépendance Logique
Les applications peuvent définir des vues logiques de la BD
Intérêt: dév. d’app. simplifié, intégration app., évolutivité 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
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 ……………………………..

…. ……. ……. ……. …. …….. ……………………………..

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 ……………………………..

9
…. ……. ……. ……. …. …….. ……………………………..
 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>

10
 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
– Le SGBD transforme la question sur les vues en question
sur les relations de base
– Les mises à jours sont reportées sur les relations de base
• Exemple : la vue des patients parisiens
Create View Parisiens as (
Select Id, Nom, Prénom, Ville
From Patients
Where Patients.Ville = ’Paris’ ) 11
 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.
12
 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 50k€

• Contrôle sur les relations entre les données

– Contraintes structurelle (modèle relationnel)
• Clé primaire, clé étrangère
– 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
13
 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
14
 VIII – concurrence d’accès

BD

• Le SGBD gère les accès concurrents

 Chacun à l’impression d’être seul (Isolation)
 Cohérence conservée (Verrouillage)

15
IX – Confidentialité: 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

16
 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…

17
 Conception de bases de données
(Production du modèle conceptuel de
données)

18
 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
19
 Approche proposée
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 !
20
Modèle Entités-Associations

21
 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é

22
 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 ?

23
 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

24
 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
.....
25
 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
26
 27

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...
27
 Règles (2) : propriétés élémentaires, 28

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 ... 28
 29

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.

29
 30

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...

30
 31

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 …
31
 Règles (6) : dépendance pleine 32

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)

32
 33

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
33
 34

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

34
Modèle relationnel

35
 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.
36
 Domaine

• ENSEMBLE DE VALEURS
• Exemples:
– ENTIER
– REEL
– CHAINES DE CARACTERES
– EUROS
– SALAIRE = {4 000..100 000}
– COULEUR= {BLEU, BLANC, ROUGE}

37
 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

38
 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

39
 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

40
 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

41
 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)

42
 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
43
 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
44
 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....

45
 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

46
 Cardinalités 1-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
47
 Cardinalités 0-1
Profs
• Un prof enseigne un et un seul
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é

Nom Prénom Adresse NomCours Description NbreHeures

Solution 1 Bouganim Luc Paris Info Informatique 44
Crenn Isabelle Paris Math Mathématiques 78
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

48
 Cardinalités 0-n
Profs
• Un prof enseigne un et un seul
Cours
Nom 1,1 Enseigne
1,n cours
NomCours
Prénom NbreHeures
Adresse
Description
• Un cours est enseigné par un
ou plusieurs profs

Nom Prénom Adresse NomCours Description NbreHeures

Solution 1 Bouganim Luc Paris Info Informatique 20
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

49
 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 50
Algèbre relationnelle

51
 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

52
 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
53
 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
54
 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

55
 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

56
 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
57
 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

58
 Petite classe :
Exercice de conception
Exercice d’algèbre

59
 Le langage SQL

Structured Query Langage

60
 SQL : pour quoi faire ?
• Avant SQL, rechercher des données satisfaisant une
qualification ressemblait à : [notations CODASYL]

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

61
 Le standard SQL
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 ...
62
EXEMPLE DE BASE DE DONNEES

63
 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)>

64
 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).

• Exercice 1
– Donnez l’expression SQL de la création des tables DOC et DET

65
 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);
• Exercice 2
– Créez un index sur le nom du docteur
– Supprimez l’attribut Motif de la table RDV
– Ajoutez une contrainte de clé primaire à la table MED (sur NumMed) 66
 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;

67
 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 !!!

68
 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 !!!

69
 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
- Fonctions agrégats
- Sélection, projection, jointure
- Recherche textuelle
- Recherche par intervalle
- Recherche sur valeur nulle
70
 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>]…)

71
 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#

72
 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;

73
 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”));

74
 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
75
 Union/Inter°/Différence
<requêteSQL_A>
UNION | INTERSECT | EXCEPT [ALL][CORRESPONDING [BY <liste_de_colonnes>]]
<requêteSQL_B>

• 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

76
 É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

77
 Programmation SQL

(OBDC/JDBC, PL/SQL, Triggers)

78
 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
– Utiliser un langage traditionnel (C, C++, Java, Cobol, …)
...qui puisse parler avec la BD (avec SQL grâce à SQL CLI, JDBC, ODBC, …)
– Utiliser un langage propriétaire (PL/SQL Oracle, TSQL MS-SQLServer, …)
…fourni par l’éditeur du SGBD
… pour créer des procédures stockées coté serveur

79
 Programmation SGBD : les outils
• 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)
• 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.
80
Optimisation de requêtes

81
 Du stockage à l’optimisation

• A la base de tout, le hardware

– Cache CPU, RAM, disques magnétiques, disques Flash
• Organisation des données
– Stockage des attributs, tuples, pages, fichiers
– Indexation des données
• Exécution de requêtes (algorithmes)
• Optimisation de requêtes
• Mises en oeuvre dans Oracle

82
 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
83
 84

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 84

 85

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
85
 86

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

86
 87

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 !
– Un accès par index plus coûteux qu’un parcours séquentiel ?
C’est parfois vrai…. Pourquoi ?
87
 Index primaire vs. secondaire
Index primaire : 1 seul par table Index secondaire : n par table

Index Index

Table Table
Tuples triés sur la clé de l’index Tuples rangés aléatoirement sur la clé de l’index

NB: Index couvrant une requête : les clés (composites) contiennent

tous les attributs nécessaires à la requête
=> Inutile d’accéder aux tuples…
88
 89
Optimisation logique
Select Patients.Nom, Patients.Prénom
From Patients, Visites
Where
and
Patients.Id-P = Visites.Id-P
Patients.Ville = ’Paris’ 

and Visites.Date = ’15 juin’

  
 
Patients Visites Patients Visites
89
 90

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) ?

90
 91

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

91
 92

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)
92
Optimiseur basé sur un modèle de 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

93
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

94
 95

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

95
 96

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 ? 96
 97

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

97
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

98
 99

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

99
Petite classe : exercices de SQL
et d’optimisation de requêtes

100
Contraintes d’intégrité
-

Triggers

- ENSTA Nicolas Anciaux

101
 Plan
1. Contrôle de l’intégrité des données
– Typologie et spécification des contraintes d’intégrité
• Norme SQL2
• Implémentation dans Oracle (bcp de différences avec la norme !)
– Analyse, contrôle des contraintes par le SGBD
2. Les déclencheurs
– Définition de la norme SQL2 Exercices
– Implémentation dans Oracle (bcp de diff. avec la norme !)

3. Exercices sur Oracle

– Création de contraintes : SQL pur, SQL check ou Trigger ?

102
 Contrôle d’intégrité
• But
– Détecter les mises à jour erronées
– Réagir
• rejeter la transaction
• compenser les erreurs

• Mise en oeuvre
– Langage de définition de contraintes d'intégrité
– Processus de vérification automatique des contraintes

• Bénéfice supplémentaires de cette implémentation

– Simplifie le code des applications
– Mise en commun des contraintes
– Cohérence globale des contraintes
103
 Types de contraintes
• Contraintes structurelles
– Spécifient la structure des données de la base
• Tables, colonnes, lignes
– Trois sortes de contraintes structurelles
• Contrainte d’entité
• Contrainte référentielle
• Contrainte de domaine

• Contraintes comportementales
– Spécifient une règle d’évolution des données
– Plusieurs sortes de contraintes comportementales
• Domaine de variation
• Contraintes temporelles
• Contraintes équationnelles
• Dépendances généralisées, …
104
 Contraintes structurelles
• Contrainte d‘entité
– Contrainte de clé
• Un groupe d’attributs clé par relation
• Ex: identifiant de chaque personne
– Contrainte de non nullité
• Valeur d’attribut doit être renseignée CREATE TABLE personne
• Ex: nom de chaque personne (
id INTEGER PRIMARY KEY,
– Contrainte d’unicité nom VARCHAR(15) NOT NULL,
• Valeur d’attribut doit être unique num_sécu NUMBER(15) UNIQUE NOT NULL,
• Ex: numéro de sécurité sociale nom_ent VARCHAR(15) REFERENCES entreprise
);
• Contrainte référentielle
– Valeurs d’un d’attribut existent
comme clé d’une relation

• Contrainte de domaine
– typage des valeurs de l’attribut

105
 Contraintes comportementales (1)
• Domaine de variation
– Précise l’ensemble des valeurs
permises d’un attribut
– L’ensemble peut être une liste de
valeurs discrète ou non
– Ex: couleur rouge, blanc, rosé
• Contraintes temporelles (SQL2)
– Comparent ancienne et nouvelle
valeurs d’un attribut
– Ex : degré du vin ne peut décroître
• Contraintes équationnelles
– Comparent des expr. arithmétiques
sur les données de base
– Peuvent être temporelles
(ancienne et nouvelle valeur)
– Ex : qté produite   qtés bues
CREATE TABLE Vin
(…,
couleur VARCHAR(5) CHECK ( couleur IN
('rouge', 'blanc', 'rosé') ),
…)
TRIGGER degré_croissant
BEFORE UPDATE OF degré ON vin REFERENCING
OLD ROW AS vin_avant
NEW ROW AS vin_après
FOR EACH ROW
WHEN (vin_après.date > vin_avant.date AND
vin_après.degré < vin_avant.degré )
BEGIN
lancerException
END
CREATE ASSERTION quantite_produite
CHECK ( ( SELECT SUM(qte) FROM Vins) >
( SELECT SUM(qte) FROM Buveur) )
106
 Contraintes comportementales (2)
• Dépendances fonctionnelles
–  valeur {attributs}
 valeur {autres attributs}
– Ex : cru et année d’un vin  degré
• Dépendances multivaluées
–  valeur {attributs}
! {valeurs {autres attributs}}
– Ex : prix vente > coût production
• Dépendances d’inclusion
– {valeurs {attributs}}
 {valeurs {autres attributs}}
– Ex : client.nom  personne.nom
– Cas part. : dépendance référentielle
• {valeurs {attributs}}
 {valeurs {attributs_clé}}
• Ex : client.nom_ent  ent.nom
CREATE ASSERTION dependance_fonctionnelle
CHECK( NOT EXISTS (SELECT * FROM Vin V1, Vin V2
WHERE V1.cru = V2.cru AND
V1.année = V2.année AND
V1.degré  V2.degré ));
CREATE ASSERTION dependance_nultivaluée
CHECK( NOT EXISTS (SELECT * FROM Vente V1,
Vente V2
WHERE V1.prix > V2.cout));
CREATE ASSERTION dependance_inclusion
CHECK ( NOT EXISTS ( SELECT * FROM Cli C
WHERE nom NOT IN (
SELECT C.nom
FROM Pers P
WHERE C.nom = P.nom)
)
);
CREATE TABLE Client
(…,
nom_ent VARCHAR(20) REFERENCES Ent(nom),
…)
107
 Expression des contraintes en SQL2
• Une contrainte d’intégrité peut être
– Associée à un domaine
• Spécifiée
– Au travers de la clause CREATE DOMAIN
– Lors de la définition de l’attribut dans la clause CREATE TABLE

– Associée à une relation

• spécifiée
– Après la définition des attributs de la clause CREATE TABLE
– Après la définition de la table avec ALTER TABLE

– Dissociées
• Spécifiée au travers de la clause CREATE ASSERTION

– Tout ceci peut être spécifié par la langage SQL2…

108
 SQL2 : contrainte de domaine (1)
• Définition possible dans la clause CREATE DOMAIN
CREATE DOMAIN <nom> <type> [DEFAULT VALUE ‘valeur’]
[CONSTRAINT <nom_contrainte> CHECK (VALUE expr) ]
expr ::=[NOT|IS NOT] EXISTS|IN|BETWEEN|LIKE|NULL requete_sql | <val>*

Exemple

CREATE DOMAIN couleur_vins CHAR(5) DEFAULT VALUE 'rouge'

CONSTRAINT couleurs_possibles
CHECK ( VALUE IN ('rouge', 'blanc', 'rosé') )

• Ensuite, le domaine peut servir à typer des attributs

109
 SQL2 : contrainte de domaine (2)
• Spécification possible dans la clause CREATE TABLE
CREATE TABLE <nom_table>
(
<nom_colonne type|nom_domaine>* [<contrainte_colonne>*]
[<contrainte_table>*]
)
<contrainte_colonne>::=
[CONSTRAINT nom_contrainte]
< NOT NULL|UNIQUE|PRIMARY KEY|
REFERENCES nom_table(liste_colonnes)|
CHECK(expr)>
[NOT] DEFERRABLE

Exemple
CREATE TABLE Vin
(
id INTEGER PRIMARY KEY,
couleur COULEURS_VINS,
cru VARCHAR(20),
millesime DATE,
degre INTEGER CHECK(degre BETWEEN 8 AND 15) NOT DEFERRABLE,
quantite INTEGER
);
110
 SQL2 : contraintes de relations (1)
• Spécification possible dans la clause CREATE TABLE
CREATE TABLE <nom_table>
(
<nom_colonne type|nom_domaine>* [<contrainte_colonne>*]
[<contrainte_table>*]
)
< contrainte_table > ::=
[CONSTRAINT nom_contrainte ]
< UNIQUE (liste_colonnes)|PRIMARY KEY (liste_colonnes)|
CHECK (expr)|
FOREIGN KEY (liste_colonnes) REFERENCES nom_table (liste_colonnes)>
[NOT] DEFERRABLE
Exemple
CREATE TABLE Vin
(id INTEGER PRIMARY KEY,
couleur COULEURS_VINS,
cru VARCHAR(20),
millesime DATE,
degre INTEGER CHECK(degre BETWEEN 8 AND 15) NOT DEFERRABLE,
quantite INTEGER,
CONSTRAINT dependance_fonctionnelle
CHECK (NOT EXISTS (SELECT *
FROM vins
GROUP BY cru,millesime
HAVING COUNT(degre) > 1)
NOT DEFERRABLE);
111
 SQL2 : contraintes de relations (2)
• Sous-cas important : les contraintes référentielles
– Caractérisent toutes les associations
– Peuvent être croisées  mode DEFERRABLE
• En cas de violation de la contrainte
– Mise à jour peut être rejetée
– Action de correction peut être déclenchée
• ON DELETE : action à effectuer si suppression d'un tuple référencé
• ON UPDATE : action à effectuer si MAJ de la clé d'un tuple référencé
FOREIGN KEY (<liste_colonnes>)
REFERENCES <nom_table> (<liste_colonnes>)
[ON DELETE {CASCADE | SET DEFAULT | SET NULL}]
[ON UPDATE {CASCADE | SET DEFAULT | SET NULL}]
[NOT] DEFERRABLE
Exemple
CREATE TABLE Abus
( id INTEGER NOT NULL,
id_vin INTEGER NOT NULL,
date DATE,
CONSTRAINT référence_buveurs FOREIGN KEY id REFERENCES Buveurs (id)
ON DELETE CASCADE DEFERRABLE
); 112
 SQL2 : contraintes dissociées
• Spécification sous forme d’assertion (règle)

CREATE ASSERTION <nom_contrainte> CHECK (condition)

• Ex: la quantité bue reste < 100 pour chaque buveur

Exemple
CREATE ASSERTION quantite_produite
CHECK ( NOT EXIST (SELECT Id FROM Buveur
GROUP BY Id
HAVING SUM(qté)>100)

• NB : les contraintes dissociées peuvent être multi-tables

Exemple
CREATE ASSERTION quantite_produite
CHECK ( (SELECT SUM(quantite) FROM Vins) >
( SELECT SUM(quantite) FROM Abus) )
113
 Dans les SGBD commerciaux…
• Contraintes de la norme SQL2 pas totalement implémentée
• Oracle
– Domaine et d’assertion non supportés
– Clause check ne peut contenir de requête
• Sybase, SQL Server
– Clause check ne peut contenir de requête
– Une contrainte par attribut au maximum
• IBM DB2
– Contraintes de la clause create table sur les valeurs d’un même tuple
– Une contrainte par attribut au maximum
• MsAccess
– Aucune clause check
– Pas de domaine

• Comment palier à ces limitations ?

114
 Palier aux limitations sur les contraintes
• Domaines remplacés par des tables et des clés étrangères
CREATE TABLE Ville CREATE TABLE Personne
( nom VARCHAR(128), ( …,
CONSTRAINT nom PRIMARY KEY ); ville VARCHAR(128) REFERENCES Ville,
… );

• SQL2 introduit le concept de déclencheur (cf. partie suivante)

– Si un Evènement se produit sur la base
– Et qu’une Condition est vérifiée
– Le moteur déclenche une Action (traitement)
 Les utiliser pour spécifier les contraintes complexes
TRIGGER degré_croissant
BEFORE UPDATE OF degré ON vin
REFERENCING OLD ROW AS vin_avant NEW ROW AS vin_après FOR EACH ROW
WHEN (vin_après.date > vin_avant.date AND vin_après.degré < vin_avant.degré )
BEGIN
lancerException
END

115
 Contraintes structurelles Oracle (1)
• Contrainte d‘entité (clé de relation, non nullité, unicité)
– Spécifiées lors de la création de la table
• En tant que contrainte de colonne
CREATE TABLE Ville
( id NUMBER CONSTRAINT pk PRIMARY KEY,
… );

• En tant que contrainte de table

CREATE TABLE Ville
( id NUMBER,
… ,
CONSTRAINT pk PRIMARY KEY (id) );

– Ajoutée après la création de la table (contrainte de table)

ALTER TABLE Ville ADD ( CONSTRAINT pk PRIMARY KEY(id) );

– Retirées (si nommée): ALTER TABLE Ville DROP CONSTRAINT pk;

116
 Contraintes structurelles Oracle (2)
• Contraintes référentielles (clé étrangère)
– Spécifiées lors de la création de la table
• En tant que contrainte de colonne
CREATE TABLE Ville
( …,
dept_id NUMBER CONSTRAINT fk REFERENCES Dept(Id),
… );

• En tant que contrainte de table

CREATE TABLE Ville
( …,
dept_id NUMBER,
…,
CONSTRAINT fk FOREIGN KEY (dept_id) REFERENCES Dept(Id) );

– Ajoutée après la création de la table (contrainte de table)

ALTER TABLE Ville ADD ( CONSTRAINT fk FOREIGN KEY (dept_id) REFERENCES Dept(Id) );

– NB: on delete cascade OK, on update cascade non supporté

– Retirées de la même manière que les contraintes d’entité
117
 Contraintes structurelles Oracle (3)
• Contrainte de domaine
– Typage de l’attribut lors de la création de la table
• Domaine de variation
– Exprimée avec la clause CHECK (sans requête)
• En tant que contrainte de colonne
CREATE TABLE Dept
( …,
code CHAR(2) CONSTRAINT code_dept
CHECK (code BETWEEN 1 AND 99)
… );

• En tant que contrainte de table

CREATE TABLE Dept
( …,
code CHAR(2)
…,
CONSTRAINT code_dept CHECK (code BETWEEN 1 AND 99) );

118
Contraintes comportementales Oracle

• Contraintes temporelles
• Contraintes équationnelles
• Dépendances généralisées

 Exprimées avec des triggers ?

119
 Vérification des contraintes
• Nécessite un travail (non trivial) de la part du SGBD
– Souvent pour cela que tout SQL2 n’est pas supporté dans les produits

• Lors de la création de la contrainte

– Le SGBD vérifie la cohérence des contraintes
– La non-redondance des contraintes
– Par des mécanismes de preuve

• Lors de mise à jour dans la base

– On résout les transgressions de contraintes suivant 2 méthodes
• Par prévention d’incohérence
– Des règles empêchent les mises à jours transgressant les contraintes
• Par détection d’incohérence et abandon de mise à jour
– Associe un traitement de vérification sur insert, delete, update
– Il s’agit autant que possible d’un test différentiel (ne pas tout re-tester!)
120
Prévention / détection de transgression
• 2 méthodes pour assurer la cohérence vis à vis des contraintes
• Par prévention d’incohérences
– Une mise à jour m n'est exécutée
que si l'état résultant de la base Dm
est garanti être cohérent
– Notion de pré-test
• A et A' sont des assertions
• A' est un pré-test pour A et m SSI
(D / A  Dm / A)  D / A'
– problèmes
• Nécessité de définir toutes les mises
à jour permises
• Non généralité
Performant, détaillé dans la suite
• Par détection d’incohérence
– Toute mise à jour m est exécutée
– L’état D de la base devient Dm
– Si Dm est détecté incohérent, on
restitue D
– Notion de post-test
• A et A' sont des assertions
• A' est un post-test pour A et m ssi
(D / A  Dm / A)  Dm / A‘
– Difficultés
• Trouver un A' plus simple à vérifier
que A
• Défaire la transaction en cas
d'incohérence
121
 Exemple de vérification préventive

– Pré-test : A‘ = A  Q
– L’algorithme ajoute conjonctivement l’assertion A à la sous
formule conditionnant l'exécution de la mise à jour
– Exemple : A = salaire > SMIC

UPDATE employé
SET salaire = salaire * 0.9
WHERE nom = 'Raleur';
UPDATE employé
SET salaire = salaire * 0.9
devient WHERE nom = 'Raleur'
AND salaire * 0.9 > SMIC;

122
 Notion de pré-tests différentiels
• Simplification des vérifications de contraintes lors de
modification de la base
• Ex : la relation Abus référence la relation Vins
Tuples à
insérer R+
Mises à dans R Pré-test
jour de R commit
Tuples à
supprimer
de R
R-
MEM. CACHE DISQUE

• Pré-tests simplifiés
– Insertion (Abus) : Abus+.id_vin = Vins.id
– Suppression (Abus) : rien à faire
– Insertion (Vins) : rien à faire
– Suppr. (Vins) : Count (Abus.id_vin) where (Abus.id_vin = Vins-.idm) = 0

 Très efficace mais complexe à implanter…

123
 Exemples de pré-tests différentiels
• Tests différentiels de contraintes classiques

Opération
insertion suppression modification
Type de contrainte

Clés de R+ uniques et ne sont Clés de R+ uniques et ne

K clé primaire de R Rien à faire
pas dans R sont pas dans R-R-

A clé étrangère de R Tuples de R+ référencent un S: clés K de S- ne Tuples de R+ référencent

référence RefK de S tuple de S figurent pas dans A de R un tuple de S

A domaine de R Domaine A sur R+ Rien à faire Domaine A sur R+

Non nullité Non-nullité sur R+ Rien à faire Non-nullité sur R+

Dépendance fonctionnelle  t tuple de R+,  u tuple de R

Rien à faire Pas de forme simplifiée
AB tel que t.A = u.A  t.B = u.B

Contrainte temporelle sur Vérifier les tuples de R+

Rien à faire Rien à faire
attribut par rapport à ceux de R-

124
 Conclusion contraintes d’intégrité
• Assurent la cohérence de la BD
• Définies dans la Norme SQL2
– Du papier…

• Sont vérifiées par le moteur du SGBD (sur le serveur)

– Lors de la validation du traitement ou au cours du traitement
– La centralisation permet
• De vérifier la validité globale
• Un gain en bande passante

• Implantation dans les systèmes réels

– Contraintes simples
• Définition avec SQL associée à celle des objets de la base
– Contraintes complexes ?
• Par déclenchement (éventuellement conditionnels) de traitements écrits dans
un langage procédural (triggers SQL2)
125
 Les triggers
Leur utilisation dans
Oracle

126
 SQL2 : déclencheurs (Triggers)
• Définition
– Action ou ensemble d'actions déclenchée(s) automatiquement
lorsqu'une condition se trouve satisfaite après l'apparition d'un
événement
• Un déclencheur est une règle ECA
– Événement = mise à jour d'une relation (INSERT, DELETE, UPDATE)
– Condition = optionnelle, équivaut à une clause WHERE
– Action = exécution de code spécifique (ordre SQL ou PL/SQL)
• Requête SQL de mise à jour, exécution d'une procédure stockée, abandon
d'une transaction, ...

• De multiples usages sont possibles

– Étendre les mécanismes de contrôle d’intégrité
• Validation des données entrées, maintien de règles d’intégrité complexes
– Contrôle dynamique et évolutif des manipulations de la BD
• Maintien de statistiques, audit de la base (sécurité)
– Duplication
• Mise à jour de copies multiples, Dérivation des données additionnelles
– Mise à jour au travers de vues
127
 SQL2 : définition des triggers
CREATE TRIGGER <nom-trigger> <événement> [<condition>] <action>*
<événement> ::=
BEFORE | AFTER | INSTEAD OF
{INSERT | DELETE | UPDATE [OF <liste_colonnes>]}
ON <nom_de_table>
<condition> ::=
[REFERENCING OLD AS <nom_tuple> NEW AS <nom_tuple>
FOR EACH ROW]
WHEN <condition_SQL>
<action> ::=
{requête_SQL [FOR EACH ROW] | exec_procédure |
COMMIT | ROLLBACK}
Exemples
CREATE TRIGGER degré_croissant
BEFORE UPDATE OF degre ON Vins CREATE TRIGGER référence_vins
REFERENCING BEFORE DELETE ON Vins
OLD AS old_vin FOR EACH ROW
NEW AS new_vin DELETE FROM Abus
FOR EACH ROW WHERE Abus.id_vin = Vins.id
WHEN (new_vin.degre < old_vin.degre)
ROLLBACK

128
 SQL2 : Gestion des Triggers

CREATE [OR REPLACE ] TRIGGER <nom-trigger>

<événement> [<condition>] <action>*
DROP TRIGGER <nom-trigger>
ALTER TRIGGER <nom-trigger> ENABLE
ALTER TRIGGER <nom-trigger> DISABLE

• La création d’un trigger déclenche son activation

• On peut remplacer la version précédente d’un trigger
• On peut manuellement activer/désactiver un trigger

129
 Mises en garde : interactions
• L’action d’un trigger peut déclencher d’autres triggers
• L’action d’un trigger peut causer la vérification des
contraintes d’intégrité
• Les actions de réaction aux contraintes d’intégrité
peuvent déclencher des triggers
– on delete cascade  trigger delete
– on update cascade / set default / set null
on delete set default / set null  trigger update

130
 Triggers des SGBD commerciaux
• Différences avec le standard
• Oracle
– 1 seul trigger déclenché par un même évènement
– Condition : ne peut contenir de requête SQL
– Action :
• 1 bloc PL/SQL anonyme sans COMMIT/ROLLBACK
• Pas de mise à jour de la table ayant levé le trigger
• Pas de lecture de la table ayant levé le trigger ligne
• Informix9
– Condition : ne peut contenir de requête SQL
– Action
• 1 seul ordre PL/SQL
• ou 1 seul appel de procédure/fonction
131
 Définition globale des triggers Oracle
• Lors d’une requête de MAJ sur une table…
– Insert, delete, update
• […si la clause when est vérifiée…]
– Condition sur le tuple mis à jour
CREATE TRIGGER <nom-trigger>
<BEFORE | AFTER>
<INSERT | DELETE | UPDATE>
ON <nom_de_table>
[WHEN (<condition_sur_la_ligne>)]
[FOR EACH <ROW|STATEMENT>]

• … exécution du bloc PL/SQL -- BLOC PL/SQL

DECLARE …
– Une fois  trigger ordre BEGIN …
END;
• Avant ou après l’ordre
– Une fois par tuple mis à jour  trigger ligne
• Avant ou après chaque mise à jour
– Pour la syntaxe détaillée du PL/SQL, voir cours PL/SQL…
– NB : des clauses PL/SQL sont propres aux triggers
• INSERTING, DELETING, UPDATING utilisables dans les IF

132
 Triggers ordre Oracle (1)
CREATE TRIGGER <nom-trigger>
<qd_executer> <ordre_sql> ON <nom_table>
[FOR EACH STATEMENT]
<bloc_plsql>
<qd_executer> ::= BEFORE | AFTER

<ordre_sql> ::= < INSERT | DELETE | UPDATE [OF<liste_colonnes>] >

[OR <ordre_sql>]

Exemple
CREATE TRIGGER vérif_qté
AFTER INSERT OR UPDATE OF qté ON Abus
DECLARE
qté_produite NUMBER;
qté_bue NUMBER;
BEGIN
SELECT SUM(qté) into qté_produite FROM Vins;
SELECT SUM(qté) into qté_bue FROM Abus;
IF qté_produite > qté_bue THEN
raise_application_error(-20001, ‘mise à jour incohérente’);
END IF;
END;
133
 Triggers ordre Oracle (2)
• Exécution du trigger avant ou après la requête (ordre)
– Avant : mises à jour de l’ordre toutes invisibles
– Après : mises à jour de l’ordre toutes visibles
– Dans le trigger : mise à jour impossible de la table modifiée
• Ex. du trigger vérif_qté

SCN = 7

SCN = 8
SCN = 8 Transaction

SCN = 9 SCN = 9
Insert into Abus as select… Déclenche
Requête

SCN = 10
(après insertions)
Abus
SCN =11
SCN = 11
Trigger vérif_qté
Chronologie

134
 Exercice 1
• Créer un trigger ordre qui s’assure que les
modifications sur la table Emp ont bien lieu pendant
les jours ouvrables (du lundi au vendredi)
– Vous pourrez utiliser la fonction TO_CHAR(SYSDATE, ‘DY’)
qui retourne le jour courant ‘MON’, ‘TUE’, ‘WED’, ‘THU’,
‘FRI’, ‘SAT’, ‘SUN’

CREATE TRIGGER emp_changements_permis

BEFORE DELETE OR INSERT OR UPDATE ON Emp
BEGIN
IF TO_CHAR(SYSDATE,‘DY’)=‘SAT’ OR TO_CHAR(SYSDATE,‘DY’)=‘SUN’ THEN
raise_application_error(-20001, ‘pas de changement le week end’);
END IF;
END;

135
 Triggers ligne Oracle (1)
CREATE TRIGGER <nom-trigger> [INSTEAD OF]
<qd_executer> <ordre_sql> ON <nom_table>
[REFERENCING OLD AS <nom_old> NEW AS <nom_new>]
FOR EACH ROW
WHEN(<condition>)
<bloc_plsql>
<qd_executer> ::= BEFORE | AFTER
<ordre_sql> ::= < INSERT | DELETE | UPDATE [OF<liste_colonnes>] >
[OR <ordre_sql>]
<condition> ::= <attribut> <|>|!=|=|[NOT]<IN|BETWEEN|LIKE> <valeur>

• Variables de transition old et new

– nommées implicitement old et new, ou explicitement dans le referencing
– utilisables dans le bloc PL/SQL par :new.nom_col et :old.nom_col
– NB: pas de new lors d’un delete, pas de old lors d’un insert
• Clause when
– Attribut = valeur du tuple avant ou après (old.nom_col ou new.nom_col)
– Valeur = attribut ou ‘xxx’, mais ne peut être résultat d’une requête
136
 Triggers ligne Oracle (2)
• Exécution avant ou après chaque mise à jour de tuple
• Difficile de gérer les requêtes sur la table en mutation
– Les exécution du trigger devraient pouvoir lire la table
– Mais lecture de la table mise à jour  erreur ‘mutating table’
• Raison technique : mise à jour des index en fin de requête, update et
delete posent des verrous sur les tuples à modifier ou supprimer, …
SCN =9 SCN =9
SCN = 7 Trigger degrès_croissant Trigger degrès_croissant

SCN = 8
SCN = 8 Transaction

SCN = 9 SCN = 9
Update from Vin where… Déclenche
Requête

SCN = 10 Déclenche
Vin
SCN = 11
SCN = 11
Requête
Chronologie

137
 Exercice 2
• Créer un trigger ligne qui s’assure que lorsqu’un employé est
embauché pour un type d’emploi, son salaire soit dans les
bornes admises pour ce type d’emploi. Les tables ont la
structure suivante :
– Employés (Id, Nom, Prénom, Salaire, Emploi, Dept)
– TypeEmploi (Emploi, Sal_inf, Sal_sup)
CREATE TRIGGER verif_salaire
BEFORE INSERT OR UPDATE OF salaire, emploi ON Emp
FOR EACH ROW
DECLARE
min_sal NUMBER;
max_sal NUMBER;
BEGIN
SELECT Sal_inf, Sal_sup INTO min_sal, max_sal
FROM TypeEmploi WHERE Emploi = :NEW.Emploi;
IF min_sal > :NEW.Salaire OR max_sal < :NEW.Salaire THEN
raise_application_error(-20001,
‘Salaire hors limite pour ’|| :NEW.Nom);
END IF;
END; 138
 Commandes Oracle relatives aux triggers

• DROP TRIGGER… : efface le trigger

• Slash (/) : permet de compiler le trigger dans SQLPlus

• SHOW ERRORS
– affiche les erreurs dans le cas où le trigger aurait été crée
avec des erreurs de compilation dans SQLPlus

• CREATE OR REPLACE TRIGGER… : permet de

remplacer le trigger s’il existe déjà

139
Résumé des limites des triggers Oracle
• Un trigger
– Ne peut contenir de COMMIT ou de ROLLBACK
– Ne peut mettre à jour la table qui le déclenche

• Un trigger ordre
– ne peut utiliser OLD et NEW

• Un trigger ligne
– Ne peut selectionner (lire) la table qui le déclenche, sauf dans le cas
d’un BEFORE INSERT déclenché par un ordre SQL unitaire du type
INSERT INTO <table> VALUES(…);

• Un trigger INSTEAD OF
– Ne peut etre déclenché lors d’un ordre sur autre chose qu’une vue (ex:
une table)
140
 Exercice 3
• Dire ce qu’il se passe quand on exécute les triggers suivants
CREATE TRIGGER audit_temp
AFTER DELETE ON temp
BEGIN
INSERT INTO temp VALUES (‘suppression de ligne:’||SYSDATE);
END;

CREATE TRIGGER auto_count

AFTER INSERT OR DELETE ON employee
DECLARE
i NUMBER;
BEGIN
SELECT COUNT(*) INTO i FROM employes ;
INSERT INTO stat VALUES (‘nombre d’employes = ’|| i);
END;
CREATE TRIGGER dates_commandes_croissante
AFTER INSERT ON commande
FOR EACH ROW
DECLARE
max_date NUMBER;
BEGIN
SELECT MAX(date_com) INTO max_date FROM commande;
IF :NEW.date_com < max_date THEN
RAISE_APPLICATION_ERROR(20001, ‘date invalide’);
END IF;
END; 141
 Oracle PL/SQL

Procedural Language / Structured Query

Language
(Langage propriétaire Oracle)

142
 Langage PL/SQL
• Langage propriétaire Oracle
– Types SQL, tests conditionnels, itérations
• Simple
• Performant
• Utilisé pour
– Créer des packages
– Des fonctions
– Des procédures stockées
– …. Et des Triggers

143
 Bloc PL/SQL
• 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;
/

144
 Types des variables PL/SQL (1)

• Types de base
– Types Oracle (CHAR, NUMBER, DATE...)
– Type Booléen : boolean
– Types référençant le dictionnaire de données : table.col%TYPE

• Types complexes
– Record
• TYPE monType IS RECORD (champ1 NUMBER, champ2
VARCHAR2);
– Table
• TYPE maListe IS TABLE OF NUMBER ;
– Curseurs (cf. plus loin)

145
 Types et variables PL/SQL (2)
• Déclaration des variables dans le bloc declare
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;

• Appel de variables extérieures dans le bloc begin end

– Variables SQL*FORMS préfixées par :
– Variables SQL*PLUS préfixées par &

146
 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;
147
 Curseurs PL/SQL : déclaration
• Résultat d’une requête SQL géré comme un fichier
séquentiel
• Déclaration
DECLARE
CURSOR monCurseur IS requête_SQL;

• Curseurs avec paramètres

– Paramètre fixés à l’ouverture du curseur

DECLARE
CURSOR monCurseur (nomRecherche IN VARCHAR2) IS
SELECT nom, adresse FROM Personne
WHERE nom = nomRecherche;

148
 Curseurs PL/SQL : manipulation (1)
• Attributs de curseur
– %NOTFOUND, %FOUND, %ISOPEN, %ROWCOUNT
– S’évaluent à true, false, null, ou au numéro de tuple
• commandes classiques d’ouverture, lecture, fermeture
• OPEN, FETCH, CLOSE
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;
149
 Curseurs PL/SQL : manipulation (2)
• Manipulation simplifiée
– 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;

150
 Curseurs PL/SQL : exemple
• Augmente de 5% le salaire des employés du service
compta…
DECLARE
CURSOR Compta IS
SELECT nom, salaire FROM Employe WHERE service = ‘comptabilité’;
Emp Compta%ROWTYPE;
BEGIN
OPEN Compta;
FETCH Compta INTO Emp;
WHILE Compta%FOUND 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;
FETCH Compta INTO Emp;
END LOOP;
CLOSE Compta;
END;
151
 Procédures et fonctions PL/SQL (1)
• Stockées sous forme compilée dans la base de données,
de la même façon qu’un 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
• Procédure
– unité de traitement qui peut contenir des instructions
• SQL (sauf DDL), PL/SQL, variables, constantes, curseurs et
gestionnaire d’erreurs
• Fonction
– procédure qui retourne une valeur

152
Procédures et fonctions PL/SQL (2)
• Création de procédure
CREATE [OR REPLACE] PROCEDURE nom_procédure [(liste_arguments)]
<IS|AS> declaration_variables
bloc_PLSQL
liste_arguments ::= nom_argument_1 {IN | OUT | IN OUT} type,
nom_argument_2 {IN | OUT | IN OUT} type,
…...
nom_argument_n {IN | OUT | IN OUT} type

• Création de fonction
CREATE [OR REPLACE] FUNCTION nom_fonction [(liste_arguments)]
RETURN type {IS | AS} declaration_variables
bloc_PLSQL
• Re-compilation de procédure et fonction en cas de
modification du schéma de la BD
ALTER <PROCEDURE | FUNCTION> nom COMPILE;
• Suppression de procédure et fonction
DROP {PROCEDURE | FUNCTION} nom;

153
 Procédures et fonctions PL/SQL (3)
• Exemple de procédure
– Modifie le prix d’un article d’un certain taux
CREATE PROCEDURE modif_prix (id IN NUMBER, taux IN NUMBER)
IS
BEGIN
UPDATE article a
SET a.prix_unitaire = a.prix_unitaire*(1+taux)
WHERE a.id_article = id;
END;

• Exemple de fonction
– Calcule le chiffre d’affaire
CREATE FUNCTION chiffre_affaire (id IN NUMBER) RETURN NUMBER
IS
ca NUMBER;
BEGIN
SELECT SUM(montant) INTO ca FROM vendeurs WHERE id_vendeur = id;
RETURN ca;
END;
154
 Package PL/SQL
• Package
– regroupement de programmes dans un objet de la BD
CREATE [OR REPLACE] PACKAGE nom_Package
<IS|AS>
déclaration_variables Visible par
déclaration_exceptions l’application
déclaration_procédures
déclaration_fonctions
(public)
END nom_Package;

CREATE [OR REPLACE] PACKAGE BODY nom_Package

Interne au
<IS|AS>
package
déclaration_variables_globales
corps_procédures
(privé)
corps_fonctions
END nom_Package

155
 Package PL/SQL : exemple
CREATE PACKAGE traitements_vendeurs IS
FUNCTION chiffre_affaire (id_Vendeur IN NUMBER) RETURN NUMBER;
PROCEDURE modif_com (id IN NUMBER, tx IN NUMBER);
END traitements_vendeurs;

CREATE PACKAGE BODY traitements_vendeurs IS

FUNCTION chiffre_affaire (id_Vendeur IN NUMBER) RETURN NUMBER
IS
ca NUMBER;
BEGIN
SELECT SUM(montant) INTO ca FROM vendeurs WHERE id_vendeur = id;
RETURN ca;
END;
PROCEDURE modif_com (id IN NUMBER, taux IN NUMBER)
IS
BEGIN
UPDATE vendeur v
SET v.com = v.com*(1+taux)
WHERE v.id_vendeur = id;
END;
END traitements_vendeurs;
156
 Conclusion langages dédiés
• 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 ou
des triggers
– Performant (réduit le transfert réseau)
– Bien adapté aux clients légers (ex: smartphone …) car
déporte des traitements sur le serveur

• Utilisé par les outils de développement de plus

haut niveau (SQLforms)

157
 Petite classe : création de
contraintes d’intégrité en SQL et
avec des triggers SQL3 (PL/SQL)

158
Droits d’accès SGBD

159
 Politique de contrôle d’accès
(ie, ensemble de règles)

• Précise qui est autorisé à faire quoi sur quelles

données et dans quelles conditions
• Format des règles :

avoir Permission agir

réaliser
sur Objet
avoir
Sujet Interdiction Action
réaliser
Ensemble
agir d ’objets
avoir réaliser
Obligation sur

160
 Ex. Système d’information médical
• Sujets = Personnels du Médecin Secrétaire
groupe médical médicale
Jean
Jeanne Nadine

• Objets = Dossiers des

Partie_Admin
patients
Dossier_Admin

Dossier_Patient Dossier_Médical Partie_Secu_Sociale

Dossier_Soins_Infirmiers

• Actions = Ex.
Consulter le dossier
Ausculter un patient Mettre à jour les parties
« Dossier_médical » et
« Dossier_soins_Infirmiers »

Créer le dossier d’un nouveau patient Renseigner « Dossier_Admin »

161
 Exemple de règles
• Règles indépendantes du contenu
– Les plus simples
– Règle qui permet d’accéder un objet indépendamment de son contenu
– Ex.
• R1 : La secrétaire médicale a la permission de gérer le « Dossier_Admin »
d’un patient du groupe médical
• Permet de consulter et de mettre à jour n’importe quelle information du
« Dossier_Admin » d’un patient
• Règles dépendant du contenu
– La permission d’accéder à un objet dépend du contenu de cet objet
– Ex.
• R2 : Le médecin a la permission de consulter l’intégralité du dossier d’un de
ses patients (permet de consulter un dossier médical à condition qu’il
s’agisse d’un patient de ce médecin)
• R3 : Le médecin a la permission de mettre à jour les parties
« Dossier_Medical » et « Dossier_Soins_Infirmiers » d’un de ses patients

162
 Exemple de règles (suite)
• Règles dépendant du contexte
– La permission d’accéder à un objet dépend d’une condition
associée au contexte d’exécution et indépendante du contenu de
cet objet

• Exemples :
– R4 : En l ’absence de la secrétaire médicale, le médecin a le droit
de créer le « dossier_admin » d’un nouveau patient
– R5 : La secrétaire médicale a accès au « Dossier_Admin » du
patient uniquement pendant les heures de travail
– R6 : La secrétaire médicale a accès au « Dossier_Admin » du
patient uniquement à partir d’un poste interne à la clinique
– R7 : en cas d’urgence, tout membre de l’équipe soignante à accès
au dossier du patient
• Contrôle a posteriori de la réalité de la situation d’urgence

163
 Exemple de règles (suite)
• Délégation et transfert de droit
– Règles liées à l’administration de la politique de contrôle
d’accès

• Exemple :
– R8 : Un médecin du groupe médical a la permission
d’autoriser la secrétaire médicale à mettre à jour la
prescription contenue dans le « Dossier_médical » du
patient

• Contrepartie de la délégation
– La secrétaire médicale ayant reçu autorisation a la
permission de mettre à jour la prescription du
« Dossier_médical » du patient
164
 Modèle discrétionnaire (DAC)
• DAC = Discretionary Access Control
– Contrôle d’accès discrétionnaire
• Principes de DAC
– Le créateur d’un objet fixe la politique de contrôle d’accès
sur cet objet
– Les sujets reçoivent des permissions pour réaliser des
actions sur des objets
– Les sujets ont l’autorisation de transférer certaines
permissions à d’autres sujets
– Modèle par essence décentralisé
 très souple
 difficile à administrer

165
 Modèle discrétionnaire (DAC)
• Exemple de matrice d’accès
– La matrice peut être immense
Nom Salaire ...
read
Dupont write read

Robert

read
Durand

• Deux approches pour renseigner la matrice accès

– Capacité (Capability List)
• la matrice est gérée par ligne
• Une liste d’autorisations, appelée capability list, est affectée à chaque utilisateur
– ACL(Access Control List)
• la matrice est gérée par colonne
• Une liste d’autorisations est affectée à chaque objet

166
 Exemple typique de DAC
• Gestion des droits dans UNIX
Répertoire

Owner User Group Other

F
Jean R W X R W - R - -

• Concept de propriétaire
Contenu
– Dans UNIX, chaque objet a un propriétaire
du fichier F
– C’est le propriétaire qui a les droits
discrétionnaires sur l’objet
• Le propriétaire décide des droits des autres sujets

167
 Principe du modèle DAC-SQL

U P V
Utilisateur Permission Vue

O
A Objet
Action =
N-uplet

Remarque : modèle fermé, basé exclusivement sur des autorisations

168
 Politique de sécurité dans DAC-SQL
• Modèle DAC – SGBD vs OS
– Grand nombre d’objets à protéger
– Objets de granule très hétérogène (relations, tuples, attributs)
– Protection d’objets logiques (tables) ou virtuels (vues),
[et non physiques (fichiers)]
 La matrice d’accès peut être immense, son implémentation difficile

• Basée sur le concept de « Vue »

– Permet de diviser la base de données en plusieurs parties
– Ex: la vue dossier_patient_de_Jean…
CREATE VIEW dossier_patient_de_Jean AS
SELECT *
FROM dossier_patient
WHERE dossier_patient.medecin_traitant = ”Jean” ;
…contient tous les dossiers des patients de Jean

• Instruction GRANT/REVOKE
– Permet de donner/retirer des privilèges à certains utilisateurs
169
 Création d’utilisateur – Ex. d’Oracle (1)
Créés par l’administrateur…
… ou tout utilisateur ayant la permission de créer des utilisateurs
CREATE USER <utilisateur> IDENTIFIED {BY <mot de passe> | EXTERNALLY }
[DEFAULT TABLESPACE <tablespace>] /* Tablespace par défaut : SYSTEM */
[TEMPORARY TABLESPACE <tablespace>]
[QUOTA { entier [K,M] | UNLIMITED } ON <tablespace…>]
/* Tablespace par défaut : SYSTEM */
[PROFILE <profile>] /* Profile par défaut: sans l’imitation de ressource */
[PASSWORD EXPIRE] /* Force le changement de mot de passe */
Ex. CREATE USER biblio IDENTIFIED BY auteur
DEFAULT TABLESPACE data
TEMPORARY TABLESPACE temp
QUOTA UNLIMITED ON data
QUOTA UNLIMITED ON indx
PASSWORD EXPIRE;
DROP USER utilisateur [CASCADE]; /* CASCADE supprime aussi les objets créés */
170
Création d’utilisateur – Ex. d’Oracle (2)
• Un profil = un ensemble nommé de :
– limites de ressources
– Contraintes sur le mot de passe

CREATE PROFILE <profile> LIMIT

SESSIONS_PER_USER {int | DEFAULT | UNLIMITED}
CPU_PER_SESSION {int | DEFAULT | UNLIMITED}
ressources
CONNECT_TIME {int | DEFAULT | UNLIMITED}
IDLE_TIME {entier | DEFAULT | UNLIMITED}
…
FAILED_LOGIN_ATTEMPTS {entier | DEFAULT | UNLIMITED}
PASSWORD_LIFE_TIME
Mot de passe
PASSWORD_REUSE_TIME
…

171
 Privilèges SQL
• Deux types: Privilèges « objets » et « système »
• Privilèges objets
– SELECT : permet la consultation de la table
– INSERT : permet l ’insertion de nouvelles données dans la table
– UPDATE : permet la mise à jour de n ’importe quelle colonne de la table
– UPDATE(nom_colonne) : permet la mise à jour d ’une colonne spécifique de la table
– DELETE : permet de supprimer n ’importe quelle donnée de la table
– Etc.

• Privilèges systèmes
– CREATE/ALTER/DROP TABLE : Modifier la définition d’un objet
– EXECUTE : Compiler et exécuter une procédure utilisée dans un programme
– REFERENCE : référencer une table dans une contrainte
– INDEX : Créer un index sur une table
– Etc.
• Les privilèges sont stockés dans la métabase
– Oracle: dba_sys_privs, dba_tab_privs, dba_role_privs, …

172
 Commandes SQL Grant

GRANT <liste privileges>

ON <table ou vue>
TO <liste utilisateurs>
[ WITH GRANT OPTION ] /* pour les privilèges objets */
[ WITH ADMIN OPTION ] /* pour les privilèges système*/
;

– WITH GRANT ou ADMIN OPTION

• est optionnel
• signifie que l ’utilisateur qui obtient le privilège peut ensuite accorder
ce privilège à un autre utilisateur

173
 Commande SQL Revoke
REVOKE [ GRANT OPTION FOR ] <liste privileges>
ON <table ou vue>
FROM <liste utilisateurs>
[option] ;
– [GRANT OPTION FOR]
• signifie que seul le droit de transfert est révoqué
– [option] = RESTRICT ou CASCADE
• Si A accorde le privilège p à B et B accorde ensuite p à C:
CASCADE => si A révoque p à B alors C perd aussi le privilège
RESTRICT => si A révoque p à B alors la révocation échoue

Et si un utilisateur U a reçu le privilège p de A et de B

(sans relation entre A et B) ?
174
 Gestion des vues
• Les vues permettent d’implémenter l’indépendance
logique en créant des objets virtuels
• Vue = expression d’un requête SQL
• Le SGBD stocke la définition et non le résultat
• Exemple : la vue du dossier patient

CREATE VIEW dossier_patient AS

SELECT *
FROM dossier_admin DA, dossier_medical DM, dossier_soins_infirmiers DSI
WHERE DA.id_patient = DM.id_patient AND
DA.id_patient = DSI.id_patient

175
 Gestion des vues
Le SGBD transforme la question sur les vues en
question sur les relations de base

Requête Q
sur des vues

Résultat

Gestionnaire Requête Q’
de Vues sur les relations
de base
Définition
des
vues
Exécution de
requête
176
 Confidentialité via les vues
Principe : Restreindre l'accès à la BD en
distribuant les droits via des vues :

Requête Q
sur des vues
OK
Résultat
Vérification
des droits

Définition OK
des Gestionnaire
droits Requête Q’
de Vues sur les relations
de base
Définition
des
vues
Exécution de
requête
177
 Confidentialité via les vues
Employés Public
Service des (intranet) (internet)
ressources
humaines
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 890
4 Doe Joe 4049

Id-E Nom Prénom Poste Adresse Ville Salaire

1 Ricks Jim 5485 ………. Paris 230
2 Trock Jack 1254 ………. Versailles 120
3 Lerich Zoe 5489 ………. Chartres 380
4 Doe Joe 4049 ………. Paris 160
178
 Application du modèle DAC-SQL
• Politique de sécurité du groupe médical
– Quels sont les privilèges respectifs ?
– NB : aussi, quels utilisateurs ont des privilèges système ?
• Sujets = Utilisateurs
• Objets = 3 relations
– dossier_admin
– dossier_medical
– dossier_soins_infirmiers
• Définition du dossier du patient
CREATE VIEW dossier_patient AS SELECT *
FROM dossier_admin DA, dossier_medical DM, dossier_soins_infirmiers DSI
WHERE DA.id_patient = DM.id_patient AND
DA.id_patient = DSI.id_patient
179
 Expression des règles (exemples)
• R1 : La secrétaire médicale a la permission de gérer le « Dossier_Admin » des
patients du groupe médical

GRANT ALL PRIVILEGES

ON dossier_admin
TO Nadine ;

• R2 : Le médecin a la permission de consulter l’intégralité du dossier de ses propres

patients

CREATE VIEW dossier_patient_du_medecin AS

SELECT *
FROM dossier_patient
WHERE dossier_patient.medecin_traitant = CURRENT_USER ;

(CURRENT_USER : opérateur prédéfini SQL)

GRANT SELECT
ON dossier_patient_du_medecin
TO Jean, Jeanne ;

180
 Expression des règles (exemples)
• R4 : En l’absence de la secrétaire médicale, le médecin a la permission
de créer le « dossier_admin » d’un nouveau patient

– Deux tables
• user_status (nom, status) => à créer (et à maintenir)
• user_role (nom, role) => existante dans la métabase

– Définition d’une vue

CREATE VIEW dossier_admin_medecin AS
SELECT * FROM dossier_admin
WHERE NOT EXIST (SELECT *
FROM user_status, user_role
WHERE user_status.nom = user_role.nom
AND user_role.role = ”secretaire_medicale”
AND user_status.status = ”present” ) ;

GRANT INSERT ON dossier_admin_medecin TO Jean, Jeanne ;

– Puissance d’expression élevée mais définition complexe

181
 Expression des règles (exemples)
• R5 : les dossiers administratifs ne sont accessibles que pendant les
heures ouvrables
– CREATE VIEW dossier_ouvrable
AS SELECT * FROM dossier_admin
WHERE TO_CHAR(SYSDATE,'HH') BETWEEN '08' AND '18'

en dehors de la période 8H – 18h le predicat est faux!

• R6 : les dossiers administratifs ne sont accessibles qu’à partir des
terminaux du secrétariat
– CREATE VIEW dossier_ouvrable
AS SELECT * FROM dossier_admin
WHERE sys_context(‘USERENV’, 'IP_ADDRESS') IN (‘T1', ‘T2')

le prédicat est faux pour tous les postes clients autres que T1 et T2 !

182
 Règle de délégation
• R8 : Un médecin a la permission d’autoriser la secrétaire médicale à mettre
à jour la prescription contenue dans le « Dossier_médical » de ses patients

– Création d ’une vue

CREATE VIEW prescription_du_medecin AS
SELECT dossier_medical.nom_patient, dossier_medical.prescription
FROM dossier_medical
WHERE dossier_medical.medecin_traitant = CURRENT_USER ;

GRANT SELECT, UPDATE(prescription)

ON prescription_du_medecin
TO Jean, Jeanne
WITH GRANT OPTION;

NB: pas de restriction possible des futurs grant

(eg, seulement à la secrétaire médicale…)

183
 Conclusion sur DAC-SQL
• Intérêt du concept de vue
– Permet d’exprimer des règles dépendant du contenu
– Permet d’exprimer certaines règles dépendant du contexte
• Règle de délégation
– Complexe à gérer
– « WITH GRANT OPTION » n’est pas suffisant
• Structuration des objets
– Grâce au concept de vue
• Contrôle d’accès basé sur l’identité des sujets
– Pas de structuration des sujets
 Intérêt de RBAC

184
 RBAC : Role-Based Access Control
• Rôle = ensemble de privilèges
• Les accès des utilisateurs sont gérés en fonction de
leur rôle organisationnel
• Principe de la gestion des rôles dans SQL3 :

R P V
Rôle Permission Vue

O
U A Objet
Utilisateur Action =
N-uplet
185
 RBAC introduit dans SQL3

• Instructions RBAC de SQL3

– CREATE ROLE <nom_role> ;
• Création d’un nouveau rôle nom_role

– DROP ROLE <nom_role> ;

• Suppression du rôle nom_role

– SET ROLE <liste_roles> ;

• Permet à un utilisateur d’activer un ensemble de rôle pendant la
durée d’une session SQL

186
 Adaptation de l’instruction GRANT
• Affectation des privilèges aux rôles
GRANT <liste privileges>
ON <table ou vue>
TO <liste roles>
[ WITH GRANT OPTION ] ;

• Affectation des rôles aux utilisateurs

GRANT <liste roles>
TO <liste utilisateurs>

• Rôle junior et rôle senior

GRANT <role1> TO <role2>
Le rôle role2 reçoit tous les privilèges du rôle role1

187
 Ex. d’application du modèle
• Création des rôles

CREATE ROLE secretaire_medical ;

• R1 : La secrétaire médicale a la permission de gérer le

« Dossier_Admin » d’un patient du groupe médical

GRANT ALL PRIVILEGES

ON dossier_admin
TO secretaire_medicale ;

• Puis affectation de Nadine au rôle secretaire_medicale

GRANT secretaire_medicale to Nadine ;

188
 Hiérarchie de rôles
Cardiologue Rhumatologue ...
• Spécialisation/Généralisation
– R1 est un rôle senior de R2
Généraliste Spécialiste
si chaque fois qu’un utilisateur
joue le rôle R1, cet utilisateur
joue aussi le rôle R2 Médecin

Directeur d ’un hôpital Personnel médical

• Hiérarchie organisationnelle
Directeur d ’un département
– R1 est un rôle senior de R2
Chef de service si un utilisateur jouant le rôle R1
est un supérieur hiérarchique d’un
Médecin utilisateur jouant le rôle R2
189
 Le modèle RBAC complet
Hiérarchies
Users-Role Permission-Role
Assignment (URA) Assignment (PRA)

U R P
Utilisateurs Rôles Permissions

.
.
. S
Sessions Contraintes

RBAC0 : le noyau (URA + PRA)

RBAC1 : Les hiérarchies
RBAC2 : les contraintes
RBAC3 : hiérarchies + contraintes 190
 Les contraintes dans RBAC
• Contrainte sur Utilisateur  Rôle
– Contrainte de type « Séparation des pouvoirs »
• Exemple : rôles anesthésiste et chirurgien sont exclusifs
•  u,  ( URA(u,Anesthésiste)  URA(u,Chirurgien) )
• Contrainte sur Session  Rôle
– Un utilisateur peut cumuler plusieurs rôles mais pas les
activer dans une même session
• Contrainte de type « Séparation des tâches »
• Contrainte sur Rôle  Permission
– Un rôle ne doit pas pouvoir cumuler certaines permissions
• Autre contrainte de type « Séparation des tâches »

191
Exemple de politique RBAC

192
 Conclusion sur RBAC SQL
• Conservation des avantages de DAC-SQL
– Possibilité d’exprimer des règles dépendant du contenu et
du contexte

• Intérêt des concepts de vue et de rôle

– Les vues permettent de structurer la gestion des objets
– Les rôles permettent de structurer la gestion des sujets

• Limites des modèles DAC et RBAC (détail après...)

– DAC et RBAC : l’application utilisateur a des droits élevés
– Risque de programmes malveillants
 Besoin du modèle MAC
193
 Gestion MAC dans un SGBD
• Limites des modèles DAC et RBAC
– Hypothèse de DAC
• L’application utilisateur hérite des droits de l’utilisateur
– Hypothèse de RBAC
• L’application utilisateur hérite des droits de la session
• Droit de la session = ensemble des rôles activés par l’utilisateur
• Risque de programmes malveillants
– Cheval de Troie : programme qui a une fonctionnalité
apparente mais qui contient des fonctions cachées
• Lutte contre les chevaux de Troie
– A la connexion, l’utilisateur réduit ses droits à la partie
strictement utile pour la session
– L’usage détourné des données est restreint
194
Exemple de Cheval de Troie

195
Exemple de Cheval de Troie

196
 MAC : Mandatory Access Control
• Basé sur le modèle de Bell-LaPadula
• Politique de sécurité multi-niveaux
– Niveaux de sécurité hiérarchiques: cloisonnement vertical
• Unclassified < Confidentiel < Secret < Très secret…
– Catégories: cloisonnement horizontal
• cardiologie, pédiatrie, rhumatologie, ...
– 1 niveau de sécurité + 1 catégorie = 1 classe d’accès
• Le niveau de sécurité d’une classe d’accès associée à un utilisateur
est appelé niveau d’accréditation
• Le niveau de sécurité d’une classe d’accès associée à un objet est
appelé niveau de classification
• Ex. de systèmes supportant un modèle mandataire
– Oracle Label Security, Label-Based Access Control DB2,
Label Security SQL-Server
197
 Dominance
• La décision d’accès est prise en comparant les deux
classes d’accès de l’objet et du sujet
– No read up : un sujet est autorisé à lire un objet seulement si
sa classe d’accès domine la classe d’accès de l’objet
– No write down : un sujet est autorisé à écrire un objet si
sa classe d’accès est dominée par la classe d’accès de
l’objet
• Une classe d’accès c1 domine () c2 ssi :
– Le niveau de sécurité de c1 >= niveau de sécurité de c2
– Les catégories de c1  c2
• Les deux classes c1 et c2 sont dites incomparables
ssi ni c1  c2 ni c2  c1 ne sont vérifiées
198
 Mandatory Access Control (2)

Subjects Objects
writes

writes ….. TS
TS

writes ….. S

writes
….. C

C
….. U

Flot d’information pour la confidentialité

199
 Mandatory Access Control (3)
A la connexion, un utilisateur reduit ses droits à la partie strictement utile pour la session

Médecin Médecin
Dossier médical Dossier médical

Martin ; pneumonia read Martin ; pneumonia

David ; ulcer David ; ulcer

Secret Secret
Secret Unclassified

Pirate Pirate
Fichier D Fichier D

Unclassified Unclassified
Secret Unclassified

Le médecin se connecte comme un sujet Secret Le médecin se connecte comme un sujet Unclassified

Hélas, il est difficile de contrôler tous les moyens de transmettre une information…
200
 Synthèse sur les modèles de contrôle d’accès
• Principe fondateur

Réaliser Agir sur

Sujet Action Objet

• DAC
– Permet de structurer les Objets
• RBAC
– Permet de structurer les Sujets
• MAC
– Lutte contre les programmes malveillants
– Mais permet peu de souplesse dans la définition des politiques

=> Vers d’autres modèles (VPD) permettant une

implantation de MAC plus souple (OLS)…
201
Base de données privée virtuelle (VPD)
• Principe
– Associer une règle de sécurité à une table ou une vue, en fonction d’un
contexte quelconque (lié à cet utilisateur et/ou à l’application)
– Si la VPD est activée, toute requête qui accède à cette relation ou cette vue
est automatiquement modifiée en incluant une clause WHERE
• Egalement appelé ‘Fine-grained Access Control’ (FGAC)
Requête Q

Résultat

Contexte
Requête Q’
Gestionnaire Complétée en
de VPD fonction du
contexte
Fonction
d’ajout de
condition liée
au contexte Exécution de
BD requête
202
 VPD : Contexte d’application
• Oracle a prévu un contexte par défaut
– USERENV : contient des informations système relatives à la
session courante (équiv. sys_context)
– Exemple : CURRENT_USER, HOST, ISDBA …

• Possibilité de créer un nouveau contexte et d’y

associer des attributs
– Exemple :
• Create context CTX_SEC_MEDICALE using
SCHEMA_MED.SEC_MEDICALE

• CTX_SEC_MEDICALE sera un contexte associé au package

PL/SQL nommé SEC_MEDICALE et stocké dans le schéma
SCHEMA_MED
203
 VPD : Définition des règles de sécurité
• Les règles de sécurité sont écrites en PL/SQL
create package body SEC_MEDICALE as
function DOSSIER_SEC return varchar2 is
MY_PREDICATE varchar2(2000) ;
begin
MY_PREDICATE := 'id_patient in
(SELECT id_patient
FROM dossier_medical
WHERE medecin_traitant = sys_context(‘USERENV’, ‘CURRENT_USER’))' ;
return MY_PREDICATE ;
end DOSSIER_SEC ;
end SEC_MEDICALE ;

• Puis associées à un objet

DBMS_RLS.add_policy // RLS = Row Level Security
( policy_name => ‘mesdossiers',
object_schema => 'SCHEMA_MED',
object_name => ‘dossier_patient', Une vue autorisée
policy_function => ' DOSSIER_SEC');
Une clause where ad-hoc

204
Exemple de transformation de requêtes
• Supposons que Jean formule la requête suivante :
SELECT *
FROM dossier_patient
WHERE id_patient = 'Paul'

• L’application de la politique mesdossiers va automatiquement transformer

cette requête en la requête suivante :
Clause where ad-hoc renvoyée par
SELECT *
SEC_MEDICALE.DOSSIER_SEC()
FROM dossier_patient
WHERE id_patient = 'Paul'
AND id_patient in (SELECT id_patient
FROM dossier_medical
WHERE medecin_traitant = 'Jean' ) ;

– Jean ne pourra ainsi accéder qu’aux dossiers médicaux de ses patients

205
 Oracle Label Security
• Une adaptation de MAC…
• …construite au dessus de VPD et ne nécessitant pas de programmation
• Data label
– Constitué de 3 composants (Level, Compartment, Group)
– Intégré aux tuples dans une colonne additionnelle (déclarée par le DSA)
– Valeurs définies par le DSA
• Level
– Obligatoire, unique, hiérarchique, dénotant la sensibilité de la donnée
– Exemple: Confidential, Sensitive and Highly Sensitive
• Compartment
– Optionnel, non unique, non hiérarchique, utilisé pour compartimenter les
données
– Exemple: types de données, liste de projets ou de secteur d’activité
• Group
– Optionnel, non unique, potentiellement hiérarchique, utilisé pour isoler les
données par organisation
– Exemple: FBI, CIA

206
Data Label (exemple)

207
 User Label
• User Label
– associé à chaque utilisateur
– Mêmes composants: Level, Compartment, Group
• Autorisations requises pour accéder aux données
UserLabel.level  DataLabel.level
AND UserLabel.compartment  DataLabel.compartment
AND UserLabel.group  DataLabel.group
• Exemple
– Une donnée de “DataLabel” (L2: C1,C3: G1,G2)
est accessible avec un “UserLabel” (L2: C1,C2,C3: G1)
mais pas avec un “UserLabel” (L3: C1: G1,G2)

/!\ raffinement dans les slides suivants…. 208

Détail des composants du UserLabel (1)

209
Détail des composants du UserLabel (2)

210
 Exercice

– C = Confidential, S = Secret

211
 Autorisations complémentaires
• Autorisations complémentaires pouvant être données à un
utilisateur ou une procédure stockée
– READ : Oracle ne vérifie plus les labels lors des SELECT
• les opérations update/delete/insert restent contrôlées
– FULL: Oracle ne vérifie plus aucun label
• mais les droits standards sur les objets continuent à s’appliquer (ex: un
GRANT SELECT ON T est toujours requis pour interroger T)
– WRITEUP – WRITEDOWN: donne le droit au user d’augmenter (resp.
réduire) le DataLabel.Level d’un tuple dans la limite de ses propres
capacités
– WRITEACCROSS: donne le droit de modifier Groups et Compartment
d’un DataLabel
• Performance ?
– Un test supplémentaire par tuple (sauf si READ, FULL)
– Création d’un index bitmap sur l’attribut Label est recommandé

212
 Synthèse sur les modèles de contrôle d’accès
• Via des vues
• DAC : Permet de structurer les Objets
• RBAC : Permet de structurer les Sujets
• MAC : Intègre l’hypothèse de programmes malveillants
– Lutte contre les chevaux de Troie
– Lourdeur d’implémentation (besoin de cartographier tout le système)
• VPD : Droits fins et contextuels
– Complexe à mettre en œuvre
• OLS: repose sur VPD, facilite (un peu) la mise en œuvre MAC
• Tout cela est TRES puissant… mais pas infaillible
– Nécessite d’avoir confiance dans les utilisateurs
– Nécessite de passer par la porte d’entrée
 Audit des accès autorisés et chiffrement de la base

213
 Petite classe :
administration des droits d’accès

214
Tolérance aux pannes

215
 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
– Algorithmes de reprise après panne

216
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é… 217

 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é
218
 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é

219
 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é
220
 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 221
 Abandon utilisant le journal avant
• Pour retirer du disque les effets de la transaction abandonnée
– Journal avant Pourquoi ?
• 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
– Validation de la transaction : écrire le fait qu’elle a validé
• 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, toute MAJ rencontrée effectuée par une
transaction non validée est annulée (en place) sur le disque

222
 Tolérer la défaillance de site
• Perte du contenu de la mémoire vive
– S’appelle aussi la reprise à chaud

• But
– Annuler les effets sur disque des transactions non validées
– Rétablir les effets sur disques des transactions validées avant la panne

• 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
 A la validation d’une transaction, on journalise ses valeurs après mise à jour
223
 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 après, on refait toutes les transactions sur disque

224
 Conclusion intermédiaire…
• Abandon de transaction
– Journal avant : défait les effets sur disque de la transaction
• Peut être en RAM
• Utile si on reporte le cache de la transaction sur disque avant validation
• Il contient les images avant de chaque transaction (non validée)

• Reprise à chaud
– Journal avant : pour défaire
• Doit être en mémoire persistante
• Utile si on reporte le cache de la transaction sur disque avant validation
– Journal après : pour refaire
• Doit être en mémoire persistante
• Utile si on ne reporte pas le cache de la transaction après validation
• Il contient les images après des transactions validées
 La gestion du cache détermine l’existence des journaux

225
 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

226
 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 227
 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

Mémoire de la transaction

Écrit pages Mises à jour

WAL
Lit page

Lit page

Steal
Journal avant

Mémoire
secondaire Base de données

• 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’ 228
 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

Mémoire de la transaction

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
229
 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

Mémoire de la transaction
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
secondaire Base de données
230
 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 !
Mémoire de la transaction
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

231
 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
232
 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é 233
 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) 234
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

235
Tolérance aux pannes dans Oracle (2)
• 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 

236
Tolérance aux pannes dans Oracle (3)
• 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
237
 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, …)
238
 Audit
Toutes les actions sont auditables…
Problèmes: quoi auditer ? Quoi rechercher ?

239
 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)
– Imputer des actions
• Performance
• Amélioration organisationnelle, financière, etc.

240
 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

241
 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)

242
 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 sont
– 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;
243
 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…

244
 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
• Audit d’un utilisateur particulier
– AUDIT SELECT TABLE, UPDATE TABLE BY scott, blake;
245
 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 action ou tentative d’action sur la table d’audit
peut être auditée elle aussi

246
 Petite classe
Expériences sur les pannes
et audit des accès

247
Sécurité du SGBD

248
 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é
249
 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 250
Principales défenses

251
 Chiffrement de BD
• Protection cryptographique pour
• Protéger les données de la BD
– Observation / altération illicite
• Protéger le moteur d’exécution de la BD
– Vérifier la complétude/exactitude des résultats

252
 Objectifs du chiffrement de la BD

• Seule solution pour résister aux attaques sur les fichiers

=> Chiffrer l’empreinte disque de la BD
• Questions:
– Peut-on chiffrer une BD de manière sûre avec un algorithme de
chiffrement sûr ?
– A quel niveau faut-il chiffrer: OS / application / SGBD ?
– Quelle approche de chiffrement SGBD: serveur / client / matériel sûr ?
• Solutions commerciales: basées sur l’approche serveur
– Procédures stockées de chiffrement: Obfuscation Toolkit
– SQL étendu au support du chiffrement: Transparent Data Encryption
– Séparation des tâches: Ex. Protegrity Data Security Platform

253
Chiffrement Symétrique (“à clé secrête”)
• Auteur et destinataire des messages partagent un secret (clé)
– Le secret permet de chiffrer et le déchiffrer les messages
• La sécurité repose sur ce seul secret
– Tous les détails du système sont publics, même les fonctions de
chiffrement/déchiffrement
Secret partagé: clé
K

déchiffre
Chiffre

m c c m
ALICE BOB

c = CK(m) m = DK(c)
= DK(CK(m))
MARVIN
254
 Chiffrement symétrique (algos)
• Un algorithme sûr résiste aux attaques suivantes:
– L’attaquant connait le texte chiffré c  il trouve m, ou mieux, la clé K
– L’attaquant connait des couples clair / chiffré (m, c)  il trouve K, ou peut déchiffrer d’autres messages
• DES : Data Encryption Standard (1976 – 1997)
– Chiffrement par bloc de 64 bits
– Chiffrement/déchiffrement = même algorithme
– La clé fait 56 bits
• 3DES : Remplace DES (1997 – 2001)
– Nécessite 3 clés de 56 bits
– 3DES(k1k2k3, m) = DES(k3,DES(k2,DES(k1,m)))
• RIJNDAEL (AES) : Utilisé depuis 2001
(standard depuis 2002)
– Chiffrement par bloc de 128 bits
– La clé fait 128, 192 ou 256 bits
– Rapide, nécessite peu de mémoire
 Puis-je chiffrer une BD avec 3DES ou AES sans problème ?
– 1997: 39 jours sur 10 000 Pentium
– 1998: une clé DES cassée en 56h (pour 250 000 $)
– 2007: 6.4 jours sur une machine parallèle ($10,000)
– La meilleure attaque connue nécessite 232
messages clairs connus, 2113 étapes, 290
chiffrements DES, et 288 mémoire !!
– 3DES est sûr (actuellement)
– Seules des attaques canal latéral ont été réussies
sur AES
– Voir www.cryptosystem.net/aes/ pour information
– AES est sûr (actuellement)
255
 Application du chiffrement à une BD

• Les algorithmes de chiffrement résistent aux attaques

… mais pas toujours leur mise en œuvre

• Le contexte BD a des spécificités difficiles à prendre en compte

– Gros volume de données
– Gros besoins de performance
– Motifs répétés, distribution qui peuvent être connues
– Données modifiables

256
Problème du choix du mode opératoire
• Mode ECB => attaque par analyse de fréquence
– ECB : Motif en clair identiques => motif chiffré identique

3DES + Mode opératoire ECB

3DES + Mode opératoire CBC

• Mode CTR => attaque par comparaisons successives

– CTR : m XOR m’ = DK(m) XOR DK(m) => information sur le contenu des MAJ !

 Chiffrer une BD avec un algorithme sûr pose problème…

 Les spécificités du contexte BD doivent être prises en compte…

 Quid des “concessions” faites à la sécurité pour raisons de perf.?

257
 Problème de performance

• Traiter directement les données chiffrées est

impossible 
• Indexer des données chiffrées ne sert à rien 
• SAUF SI: on dispose de chiffrement à propriétés
particulières
– Ex. Préservant l’égalité [Ora07, BoP02], l’ordre [AKS+04], ou
l’homomorphisme [GeZ07]
=> Compromis sécurité / performance…

258
 A quel niveau chiffrer ?

• Chiffrement niveau OS => chiffrement fichiers/stockage

Data DBMS engine

Storage layer
Application
Keys Encrypt/Decrypt
Server
RAM
Encrypted Data

Database Server

– Transparent pour le SGBD et l’application

– … mais chiffrement non sélectif
• Chiffrement non lié au droits d’accès
(1 clé par privilège)
• Chiffrement partiel proscrit => performances !

Solution retenue par certains SGBD

(ex: MS SQLServeur, IBM DB2) 259
 Chiffrer au niveau application
Application
– Chiffrement sélectif possible Data Application

– Résistance aux attaques internes Keys

Client
Encrypt/Decrypt

– Aucune transparence pour l’application

RAM

• L’application pilote chiffrement/déchiffrement DBMS engine

– Et gère les clés…

Storage layer
• Et prend en charge des traitements BD
Server
– Requêtes, droits, contrôle d’intégrité… RAM
Encrypted Data

– Dégradation importante des performances Database Server

– Le client peut attaquer les droits d’accès
• Les données et les clés sont en clair sur le client
– Difficile d’implanter plusieurs applications

Solution toujours possible mais pose bcp de problèmes

260
 Chiffrer au niveau SGBD

Data DBMS engine

Application
Keys Encrypt/Decrypt
– Chiffrement sélectif (spécifique)
• Chiffrer selon les privilèges utilisateur Storage layer

• Chiffrer les données les plus sensibles Server

RAM
– au niveau table, ligne, colonne… Encrypted Data

– … de façon conditionnelle (salaire >10K) Database Server

– Transparence pour l’application
– … mais mécanismes internes SGBD à revisiter
• Evaluation de requête + indexation sur des données chiffrées impossible
– sauf chiffrement à propriétés particulières
(préservant égalité ou l’ordre => dangereux pour la sécurité)
• Surtout dans un contexte où le serveur n’est pas de confiance (approche client)
– … et problème de performance en perspective

Solution retenue par certains SGBD (Oracle)

261
 Solution « crypto package »
• L’éditeur du SGBD fournit un « package »
– Procédures / fonctions de chiffrement / déchiffrement
– Ex: Oracle Obfuscation Toolkit
• Problèmes
– Difficile à mettre en œuvre
• Package utilisé par le programmeur du SGBD (trigger/proc.) / de l’application
• Gestion des clés laissée aussi à la charge du programmeur
• Impossible d’interroger des données chiffrées…
– Limites inhérentes à l’approche serveur
• Les packages peuvent être substitués (par le DBA, …)
• Les clés sont transmises (voire stockées) au serveur qui chiffre/déchiffre
• Les données apparaissent en clair sur le serveur à l’execution
En pratique: usage limité aux données très sensibles
(Ex: chiffrement des logins/mots de passe)

262
 Solution « chiffrement transparent »
• SQL étendu à la gestion du chiffrement
– Transparent pour les applications
• Chiffrement niveau attribut (Oracle 10g)
– Certaines colonnes sont chiffrées dans tous les tablespaces
(même temporaires), SGA, logs/backups…
• La colonne peut rester indexable (option NO_SALT)
…. Mais l’attaque par analyse de fréquence est alors possible !
– Certains tablespace sont chiffrés (Oracle 11g)
• Tablespaces complets chiffrés sur disque, déchiffrés en SGA
• Indexation classique (indexes chiffrés fabriqués sur le clair)
• Master key chiffrée par un mot de passe (admin.)
ou stockée dans un HSM
• Exemples: Oracle Transparent Data Encryption (TDE),
SQL server 2008 TDE, … 263
 Approche client : le principe
• Chiffrement coté client
– Pas de transmission du texte clair ni des clés au serveur
– Le traitement s’effectue sur le client (pire cas) Data Client

• La BD est protégée coté serveur Keys

Client
Encrypt/Decrypt

– Le serveur résiste aux attaque internes RAM

– Mais… dégradation très importante des performances DBMS engine

Database Server
 Problème : déporter la majeure partie du traitement
Storage layer
sur le serveur (données chiffrées), sans perte de
sécurité Server
RAM
Encrypted Data
• Limites de l’approche client
– Gestionnaire de droits côté client
– Données et clés en clair sur le client
– Or le client n’est pas forcément un site de confiance
– Donc ne convient pas à une BD partagée (BD privée uniquement)

264
 Approche client : les techniques
• L’objectif est de déporter le plus possible de taches
sur le serveur sans compromettre la sécurité
• Indexation des données
– Indexation sur le chiffré
• Utilisation d’un mode de chiffrement avec des propriétés particulières
• Ex: préservant l’égalité [Ora07, BoP02], l’ordre [AKS+04], ou
l’homomorphisme [GeZ07]
• Le serveur maintient un index sur le chiffré
• Le client interroge en posant des questions sur le chiffré
• C’est un compromis sécurité / performance…
– Etiquetage des tuples
• Le client pose des étiquettes, pour sélectionner/joindre
• Les étiquettes sont statistiquement indistingables

265
 Solution par étiquetage [HIL+02]
• Granule de chiffrement = tuple
• Ajout d’étiquettes d’attributs
– Indique qu’un attribut de tuple appartient à une plage de
valeurs
– Permet des traitements (approximatifs) sur le serveur
• Sélection, jointure, groupement

tuple: id name age salary

tuple chiffré: Encrypted row Iid Iname Iage Isalary
étiquète

266
 Attributs numériques
• Partitionner le domaine de variation d’un attribut

Connaissance du client
h(1)=17 h(2)=4 h(3)=12 h(4)=3 h(5)=6 h(6)=1 h(7)=9
20 24 31 35 40 48 50 54
Age=53 32<Age<40

Connaissance du serveur
I Age Inférences => distribution
(Age=37) E(R1) 3 uniforme
(nb tuplesIpar
Age= 9
partitionIidentique)
Age= 12
(Age=53) E(R2) 9
• connaissance a priori vs.OR
(Age=26) E(R3) 4 updates? I =3
• combinaison d’indices?Age
• (à suivre…)

267
 Architecture
Client Site Server Site
Encrypted
Query Results
Executer
Temporary
Results
Client Side
Server Side Service Provider
Query
Query
Query
Translator

Original Query Encrypted User

Metadata Database

Final Results
+vite
User
268
 Données personnelles
et anonymat

• 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é

269
 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) 270
 Anonymisation : le principe

Données Données anonymes

personnelles (non personnelles)

Individus

Serveur de Serveur de
confiance statistiques
271
271
 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

272
 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 !

273
 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?
274
 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. 275
 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
276
k-anonymat : algorithme de Mondrian

277
 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
"Student" [20, 22] Flu
Jeu 3-anonyme
(par généralisation)

278
278
 … 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
"Teacher" [24, 27] Cancer
Pat "MC" 27 Cancer
"Teacher" [24, 27] Cancer
"Teacher" [24, 27] Cancer

 Le k-anonymat ne protège pas contre

la dé-anonymisation des attributs sensibles !
279
 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.
280
 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
"Student" [20, 23] Flu
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 »…
281
 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.
282
 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

Name Activity Age Diag Activity Age Diag

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…
283
 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

Name Activity Age Diag Activity Age Diag

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)
284
 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)
285
 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

286
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é 287
 Et les dossiers « historiques » ?
Cas NetFlix (trace GPS, trace d’accès, etc.)
• NetFlix Prize :1M€
• Fin en 2010 suite à une
« class action »
• 500K recommandations
anonymes
– Arvind Narayanan & Vitaly
Shmatikov
– connaissance antérieur
prises dans Imdb
– www.cs.utexas.edu/~shmat/
shmat_oak08netflix.pdf

288
 Conclusion sur l’anonymat
• 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…
• Mais aucune ne garanti vraiment l’anonymat
289
En guise d’ouverture: cloud personnel

• $2 milliards/an dépensés aux US dans St Peter's Place, Roma

l’achat d’informations personnelles Pope Benedikt
[Rapport Forrester 30/09/2011]
• Retour sur investissement énorme
[$44.25/$1 selon Direct Marketers Association]
[77% selon Marketing Sherpa, 2013]
People listenning
• “Personal data is the new oil”
[Forum Economique Mondial]
Pope Francis
Valeur boursière GAFA
Monétisées par les acteurs dominants du Web
e.g., Ye$Profile : l’utilisateur loue ses données


n°mobile 0,60€
géolocalisation 1,00€
People recording
email 0,15€
pointure 0,15€

290290
Pour les gérer : modèle du Web actuel ? Profils Pub. ciblée

Problèmes intrinsèques
Délégation  vie privée
Très grands volumes  sécurité Achats Photos Res. sociaux

Fragmentation  complétude Banques Mail

Capteurs
Localisation
Plus de contrôle pour l’usager
Consensus : éco. (FEM), politique (EU)... Analyses croisées
Auto-évaluation Dissémination
contrôlée

Web personnel : rendre les données

Analyses croisées (complétude de facto) Calculs globaux
anonymes et
Dissémination contrôlée (information vs données) participatifs

Calculs globaux anonymes et participatifs

Quelles incitations ?

Quelles solutions techniques ?

291
Comment rendre ses données au citoyen ?

Sur son ordinateur personnel ? Auto-administration, sécurité

Sur un service Cloud ? Aggravation du problème de vie privée

Principes fondateurs des architectures envisagées

Centrées sur l’individu, la propriété des données, et la vie privée
Cadre propice à la législation et aux recommandations des CNIL

Solution centralisées : établir des serveurs de confiance

Normes, labellisation, cadre contractuel
Ex: Cloud souverain, DB Hippocratiques (IBM), infomédiaires…
Sécurité renforcée : cryptographie / matériel résistant aux attaques
Ex: CryptDB [SOSP11], Oracle/Amazon avec HSM, TrustedDB [TKDE14]

Nouvelle approche : serveurs personnels de données

PDS/PlugDB@Inria [VLDB10], OpenPDS@MIT [PLOS14], CozyCloud, OwnCloud…
Blue Button (USA), MesInfo (FR), MyData (FIN) …

292
Serveur personnel* de données …
* PIMS, Cloud personnel, Web personnel, …

Chaque serveur est personnel et de confiance pour son propriétaire

Le serveur d’un seul individu  pas de concentration
Auto-administré sous le contrôle de l’individu  pas de délégation

Exécution locale au serveur personnel

Régulation de la diffusion des données
Ex: OpenPDS@MIT [PLOS14]

+ Logiciel libre et plateforme isolée (matériel dédié ou virtualisé)

Vérification communautaire, sécurité renforcée vis-à-vis des applications
Ex: Freedombox, Owncloud, CozyCloud, CloudMask…

+ Sécurité matérielle
Résistance aux attaques physiques
Ex: PDS/PlugDB@Inria [VLDB10]

293
Exemple: PlugDB@Inria/CozyCloud
A

Web personnel sécurisé

Une plateforme de Web personnel
… dotée d’un élément de sécurité matériel

Privacy-by-Design [Cavoukian12] data

Serveur
Secure Personnel
/!\ Il ne s’agit pas de cacher des secrets HW
GPS
Contrôle du cycle de vie des données
Assuré au plus proche des sources
Capteurs, objets intelligents, PC, smartphone…… Cloud
B
Jusqu’à leur stockage & exploitation

Perspectives ( et défis technologiques) C

Dossiers transverses  hétérogénéité, sécurisation

P-b-D  gestion de données confinées, collecte minimum
Calculs à grande échelle  distribution, sécurisation

294
 Smartcard SD card
(secrets) (data)
Bluetooth
MCU
(data managt) Fingerprint
reader

USB

PlugDB@Inria : https://project.inria.fr/plugdb/
Versailles Sciences Lab:
http://vsl.prism.uvsq.fr/projets/systeme-dinformation-privacy-by-design-2/

295
295
Annexes

296
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)

297
Mode opératoire Cipher Block Chaining
• les blocs chiffrés intégrent la valeur des
précédents
by tes
0 8 16

Plain-text 1 (P1) Plain-text 2 (P2) …

Init. Vector (IV)

EK (IV  P1) EK (C1  P2) EK (…)

Cipher-text 1 (C1) Cipher-text 2 (C2) …

298
 Mode opératoire CTR
• Résultat du XOR entre le clair et un mot aléatoire

by tes
0 8 16
Plain-text 1 (P1) Plain-text 2 (P2) …

+1 +2 +3
EK (IV+1)  P1 EK (IV+2)  P2

Init. Vector (IV)

Cipher-text 1 (C1) Cipher-text 2 (C2) …

299