++master2 IRS Bases de Donnees Avancees PDF

2
Bases de données
• Conception de bases de données
• Modèle Relationnel
• SQL
• JDBC
• Transaction, Optimisation
• Sécurité
•…
Luc Bouganim – Luc.Bouganim@inria.fr
http://www-smis.inria.fr/~bouganim/afti
3 4
Plan de la session (1) Plan de la session (2)

• Jour 1: Matin
– Problèmes des approches fichiers, l’approche base de données • Jour 3: Matin
– Conception de bases de données (light) – Méthodologie SQL
Exercices sur un cas pratique – Optimisation, Concurrence d'accès, Sécurité / Confidentialité
– Le modèle relationnel • Jour 3: Après midi
– SQL : le LDD (Langage de Définition de Données)
Interrogation avancée d'une base de données en SQL
• Jour 1: Après midi Interrogation d'une BD depuis un programme JAVA
Création d'une base Oracle, insertion, chargement massif
• Jour 4: Matin
• Jour 2: Matin – (Cryptographie et bases de données)
– Vue d'ensemble des fonctionnalités des SGBD – (Dictionnaire de données)
– SQL : le LMD (Langage de Manipulation de données) Injection SQL
– SQL et JAVA : JDBC Concurrence d'accès
• Jour 2: Après midi • Jour 4: Après midi
Interrogation d'une base de données en SQL – Examen (2h)
Systèmes de fichiers Caractéristiques
6
Problèmes des approches fichiers,

l'approche base de données Comptabilité Chirurgie
Problèmes
Consultations Psychiatrie
Plusieurs applications Caractéristiques

7
Redondance (données) Caractéristiques 8
Plusieurs applications Plusieurs applications

plusieurs formats plusieurs formats
Dupont Dupond Dupont Dupond
Symptomes : y
Turlututu : sqj
Turlututusqjsk
Symptom: yyyy
Analyses xxxx
plusieurs langages Symptomes : y
Turlututu : sqj
Turlututusqjsk
Symptom: yyyy
Analyses xxxx
plusieurs langages
Symptomes : y Symptomes : y
Turlututu : sdd Turlututudhjsd Turlututu : sdd Turlututudhjsd
Analyses : xxx Analyses :xx Analyses : xxx Analyses :xx
Redondance de données
Problèmes Problèmes
Difficultés de gestion Difficultés de gestion
Incohérence des données
Duhpon Duipont Duhpon Duipont

Turlututu : sq Turlututu : sq
Symptomes : yy Symptomyyyy Symptomes : yy Symptomyyyy

Analyses : xxxx Analysesxxxx Analyses : xxxx Analysesxxxx
Symptomes : yy Turlututudhjsd Symptomes : yy Turlututudhjsd

Interrogations Caractéristiques
9
Pannes ??? Caractéristiques
10

ComptaSoft
ComptaSoft
ChiruSoft
ChiruSoft
Symptomes : y
Turlututu : sqj
Turlututusqjsk
Symptom: yyyy
Analyses xxxx
Turlututu : sqj
Turlututusqjsk
Symptom: yyyy
Analyses xxxx
plusieurs langages
Analyses : xxx Analyses :xx
Redondance de données Analyses : xxx Analyses :xx
Pas de facilité d’interrogation Pas de facilité d’interrogation
Question ⇒développement Question ⇒développement
Redondance de code
Incohérence des données Incohérence des données
Coûts élevés Coûts élevés
Maintenance difficile Maintenance difficile
ConsultSoft
ConsultSoft
PsychiaSoft
PsychiaSoft
Duhpon Duipont
Turlututu : sq
Duhpon Duipont
Turlututu : sq
Gestion de pannes ???
Symptomes : yy Symptomyyyy Symptomes : yy Symptomyyyy
Analyses : xxxx Analysesxxxx Analyses : xxxx Analysesxxxx
Partage de données Caractéristiques

11
Confidentialité Caractéristiques
12

ComptaSoft
ComptaSoft
ChiruSoft
ChiruSoft
Symptomes : y
Turlututu : sqj
Turlututusqjsk
Symptom: yyyy
Analyses xxxx
Turlututu : sqj
Turlututusqjsk
Symptom: yyyy
Analyses xxxx
plusieurs langages
Analyses : xxx Analyses :xx
Redondance de données Analyses : xxx Analyses :xx
Pas de facilité d’interrogation Pas de facilité d’interrogation
Question ⇒développement Question ⇒développement
Redondance de code Redondance de code
Incohérence des données Incohérence des données
Coûts élevés Coûts élevés
Maintenance difficile Maintenance difficile
ConsultSoft
ConsultSoft
PsychiaSoft
PsychiaSoft
Duhpon Duipont
Turlututu : sq
Gestion de pannes ??? Duhpon Duipont
Turlututu : sq
Gestion de pannes ???
Symptomes : yy
Analyses : xxxx
Symptomyyyy
Analysesxxxx Partage des données ??? Symptomes : yy
Analyses : xxxx
Symptomyyyy
Analysesxxxx Partage des données ???
Confidentialité ???
L’approche ‘‘Bases de données’’ (1)
13
L’approche ‘‘Bases de données’’ (2) 14
• Modélisation des données

I- Indépendance
Eliminer la redondance de données Physique
Centraliser et organiser correctement les données X - Standards II- Indépendance

Logique
Plusieurs niveaux de modélisation
IX - Gestion de la III – Langage de
Outils de conception confidentialité manipulation
VIII - Concurrence BD IV - Gestion des

d’accès vues
• Logiciel «Système de Gestion de Bases de Données» VII - Gestion des V - Optimisation des
questions
Factorisation des modules de contrôle des applications pannes
- Interrogation, cohérence, partage, gestion de pannes, etc… VI - Gestion de la

cohérence
Administration facilitées des données
16
Modélisation du réel
Réel
Conception de bases de données
• Indépendant du
Modèle modèle de données
• Indépendant du
conceptuel SGBD Médecin effectue Visite
• Dépendant du
Codasyl Relationnel Objet XML
• Indépendant du
logique SGBD
• Dépendant du • Organisation physique des données

• Structures de stockage des données
• Dépendant du
Physique SGBD • Structures accélératrices (index)
17 18
Méthode de conception ? Exemple de mauvaise conception (1)

• Plusieurs façons d’aborder la conception d’une BD
N° Nom Prénom Ville Pays Immatriculation Marque Couleur
– Intuition + création directe de la BD 1 Bar Joe Paris France 125PP75 Renault Rouge
– Suivre une méthode de conception (MCD MLD MPD) ☺ 2 Dean Pascal Vence France 453LL06 Peugeot Vert
• Entité/Association (E/A) ou Entity/Relationship (E/R) 3 Ben Zoe Lyon France 526UU69 Renault Rouge
• Merise 4 Bar Joe Paris France 257LPM75 Renault Jaune
• UML
• Redondance des données et incohérence potentielle
• Suivre son intuition peut conduire à des erreurs
– Personne répétée pour chaque voiture : ex. Si Joe Bar change
– Redondances de ville et qu’une seule ligne est mise à jour…
– Valeurs nulles
– Redondance Ville/Pays : impact d’une erreur de saisie
– Difficulté de gestion
– Impossibilité de répondre à certaines questions • Anomalies de mises à jour et besoin de valeurs nulles.
• Une fois la base de données crée, difficile à modifier… (cf. TP) – Comment insérer une personne sans voiture ?
– Sémantique de calculs avec des valeurs nulles…
• Les outils de conception sont une aide précieuse
– Comment supprimer la dernière voiture d'une personne ?
19 20
Exemple de mauvaise conception (2) Méthodes de conception : Exemple Merise
N° Nom Prénom Ville Pays Enfant 1 Enfant2 Enfant3 NbEnfants

1 Bar Joe Paris France Paul Zoe 2 Réel
2 Dean Pascal Vence France Lili 1
3 Ben Zoe Lyon France Sam Tor Tur 3
4 Cat Tom Lens France 0 DONNEES TRAITEMENT
MCD MCT
Modèle
• Redondance cachée : conceptuel
Quelles données ? Quels traitements ?
Quelle organisation ?
– Nombre d’enfants vs enfants
MLD MLT
Modèle Modèle logique (e.g, relationnel) Structuration en procédure
• Difficulté de gestion logique
– Comment gérer les personnes ayant plus de 3 enfants ! MPD MPT
Modèle
– Comment afficher la liste des enfants ? Création de la base de donnée Description de l’architecture des
Physique traitements, algorithmes
Objectif du cours : E/A, Merise, UML ? E/A light, Merise ultra-light

21 22
Approche proposée : orientée données Déf° (1) : entité / type d’entité

1/ Définir l’application (~MCT) • Entité : représentation d’un objet du monde réel …
– Que veut-on faire exactement, définir les sorties (états) … par rapport au problème à modéliser. Une entité peut donc être …
… concrète : ex. un docteur, un médicament, un client
2/ Définir les données (~MCD)
– quelles sont les données nécessaires ? Comment les organiser ?
… abstraite : ex. une visite médicale, une commande
3/ Définir les questions nécessaires pour l’application (~MLT)

• Type d'entité : représentation d'un ensemble d'entités perçues
4/ Validation : Est ce que la structure choisie permet de répondre aux comme similaires et ayant les mêmes caractéristiques
questions ? Sinon, retour en 1/ ou 2/ – Ex. docteurs, patients, médicaments, clients, visites, commandes
5/ Passer du MCD au MLD
Profs
Bouganim Profs
6/ Définir les requêtes nécessaires pour l’application (~MPT). Profs
Luc Crenn Nom
Normalement, le MLD doit permettre de répondre aux requêtes ?
..... Isabelle Prénom
7/ Passer du MLD au MPD .... Adresse
GENERATION AUTOMATIQUE POSSIBLE ! Entités Type d'entité
23 24
Déf° (2) : Propriétés / Identifiants Déf° (3) : association / type d’association

• Propriété : donnée élémentaire permettant de décrire une • Association : représentation d'un lien non orienté entre plusieurs entités (qui
jouent un rôle déterminé).
entité ou une association
– Ex. Un prof enseigne un cours
– Le nom du patient, la date de la visite – 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
• Identifiant d’entité : Une entité est identifiée de manière sémantique et les mêmes caractéristiques
unique par au moins une propriété (généralement une) – Ex. enseigner
– 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
• Question : quid de visite : entité ou association ???
– Un docteur visite un patient association
– Un docteur effectue une visite concernant un patient
25 26
Exemple : Profs et cours...

Déf°(4) : Cardinalités
Profs • Cardinalité : Exprime le nombre minimum et maximum
Cours
CodeProf enseigne d’association(s) par entité. Il est Indiqué sur chaque arc,
CodeCours
Nom NbreHeures NomCours entre le type d’entité et le type d’association concernées
…
Prénom
Adresse Cours
• Pour un prof donné, combien d’enseignements ?
Profs 1
1 enseigne Maths – Au minimum : Min=0
Crenn ..... Profs enseigne Cours
– Au maximum : Max=n 0,n
Profs Isabelle 55
3 .... Un prof enseigne de 0 à n cours
enseigne Cours
Lewis
Jerry 16 2
.... Profs Infos • Pour un cours donné, combien d’enseignements ?
2 enseigne ...
– Au minimum : 0
Bouganim 24 Profs enseigne Cours
Luc
– Au maximum : 1 0,1
..... – Un cours est enseigné par 0 à 1 prof
27 28
Comment produire le MCD ? (1/3) Comment produire le MCD ? (2/3)

• ‘‘Énoncer le réel’’ à modéliser avec des phrases • On obtient :
Patient a un rdv Médecin Exerce Salle

Patient 0,n 0,n 1,1 1,n
• Exemple pour la gestion de rendez vous 0,n
– Les patients ont des rendez vous avec des médecins • Pour connaître la salle, pour un rendez vous, on passe par le médecin
à un RDV
• Un patient peut avoir plusieurs RDV (voire aucun) 0,n 0,n Ce MCD est bon
• Un médecin reçoit plusieurs patients (voire aucun) 0,n Médecin
• Et si maintenant le médecin peut exercer dans plusieurs salles ?
Médecin
– Un médecin exerce dans une salle 1,1 Patient a un rdv Médecin Exerce Salle
0,n 0,n 1,n 1,n
• Un médecin n’exerce que dans une seule salle 1,1 exerce
• Une salle peut être partagée par plusieurs médecins 1,n 1,n • Comment connaître la salle d’un rendez vous ?
Salles Ce MCD n’est pas bon !
29 30
Comment produire le MCD ? (3/3) Cas pratique : Gérer les notes des étudiants
Patient a un rdv Médecin Exerce Salle

0,n 0,n 1,n 1,n • Détailler le problème : Que veut dire gérer les notes
(A) – Que veut on faire ?
• établir les bulletins semestriels ?
• établir des bulletins provisoires ?
• établir des moyennes ?
Patient 0,n a un rdv 0,n Médecin Patient 0,n a un rdv 0,n Médecin
1,n • Faire des statistiques sur plusieurs années ?
Exerce • Evaluer les notes en fonction des profs...
(B) 1,n
1,n (C) 1,n • Premier brouillon des données à gérer...
Salle Salle
– Notes, étudiants, Cours...
Différences fonctionnelles (A) (B) (C)

Connaître la salle pour 1 RDV donné Non Oui Oui
Pré-allouer des salles aux médecins Non Non Oui
31 32
Où s'arrêter dans la modélisation? Règles (1) Respect des règles de gestion

• ‘‘Énoncer le réel’’ à modéliser avec des phrases • Il faut vérifier que le MCD correspond bien au ‘réel’,
– Un étudiant obtient des notes à des cours c’est à dire aux règles fixées (celles que l’application
– Un étudiant habite dans une ville doit respecter)
– Un étudiant a eu un bac d’un certain type
– Les étudiants sont regroupés en sous groupes
• par exemple:
– Les sous groupes sont regroupés en groupes
– un prof enseigne plusieurs cours
– Les groupes sont regroupés en promotions
– une matière est enseignée par plusieurs profs (info/anglais)
– les notes peuvent être données par n’importe quel prof ou
• Ne faire des entités que si elles ont une utilité
par plusieurs profs enseignant une matière... (info par
C’est le réel à modéliser !!!! exemple)
– On peut redoubler une fois....
• Dépend de l’objectif de l’application
– etc...
Règles (2) : Propriétés élémentaires, 33 34
Règles (3) Propriétés répétitives

calculées, constantes
• Pour une entité, il ne peut y avoir qu’une instance de chaque
• Toute propriété doit être élémentaire propriété de l’entité
– sinon, complexité de traitement – exemple: Cours ne peut être une propriété de Prof, puisqu’un prof
– Ex. de propriétés élémentaires : Age, Salaire, N° de rue enseigne plusieurs cours...
– Ex. de propriétés non-élémentaires : Adresse (complète), N°SS – Remarque : Si un prof ne peut enseigner qu’un seul cours, cours peut
– la notion d’élémentaire dépend de l’application. L’adresse peut devenir être une propriété de prof
élémentaire si elle est toujours manipulé dans son intégralité
(on ne cherchera jamais a faire, par exemple, un tri par ville) • Attention aux propriétés n’ayant pas le même nom mais la même
«Il n’est pas gênant d’éclater des propriétés qui devrait être groupés, mais sémantique
on ne peut grouper des propriétés qui devrait être éclatées» – Ex. : Enfant1, Enfant2, Enfant3 (cf. Slide 16)
– Ex. : différents types de notes d’un étudiant
• Une propriété calculée n’est pas à stocker ! (rejoint la règle 8) • Remarque : pour éviter d’éventuelles erreurs, on nommera
– Sinon, c’est redondant source d’incohérence différemment des propriétés de différentes entités :
– Ex. NomPatient, NomDocteur, etc.
• Une propriété constante n’est pas à stocker (rejoint la règle 8) – Du coup une propriété n’apparaît que dans une seule entité ou association.
– Sinon, c’est redondant source d’incohérence
– On utilisera une table de constantes ...
35 36
Règles (4) : Propriétés sans signification Règles (5) : Identifiants d’entités

• Toute entité doit être identifiée !
• Une propriété ne peut être sans signification pour une • Un identifiant doit être pérenne. Ex. nom et prénom peut
partie des entités ou associations être l’identifiant de l’étudiant, mais ça peut être
– exemple : si un prof ne peut enseigner qu’un seul cours, mais insuffisant.
qu’on a choisi de créer une entité ‘personnel’ et non ‘prof’,
– il ne faut pas concevoir le MCD en observant les données telles
on ne stockera pas le cours dans l’entité ‘personnel’ car il
qu’elles sont (ex. l’école tel qu’elle est). Il faut le concevoir
serait sans signification pour une secrétaire...
pour le cas à modéliser (ex. l’école telle qu’elle peut être.... et
– contre exemple : Téléphone et Fax pour un étudiant... telle que l’on se propose de la gérer.... )
• Plusieurs identifiants peuvent co-exister. En choisir un…
• Si vous ne trouvez aucun identifiant, votre « entité » est
sans doute une association …
37 38
Règles (6) : Dépendance pleine des entités Règles (7): entités et associations
• Les propriétés d’une association doivent dépendre de • 2 entités ne peuvent être directement liées : Il faut une
la totalité des entités associées. Si certaines propriétés association ! Cependant
ne dépendent que d’un sous ensemble des entités, on – Une association peut ne pas avoir de « nom »
devra • Il est des fois difficile à trouver…
– les rattacher à une des entités – Une association peut ne pas avoir de propriété
– créer une nouvelle association • C’est un cas très fréquent
enseigne
associant ce sous ensemble Heure
Prof Groupe
Salle Enseigne
Prof Groupe
Heure
• Exemple:
1/ Un prof enseigne toujours ?
dans la même salle dans prof Cours Salle
2/ La salle dépend du prof et
Cours
du cours Nouvelle association entre prof et cours
39
Règles (8) : pas de dépendance transitive Première modélisation ‘restreinte’

• Une propriété ne peut dépendre d’une autre propriété qui ne soit • Gérer les notes des étudiants veut dire:
pas l’identifiant – Hypothèses :
– Permet d’éliminer des sous-entités incluses dans une entité • une base de données pour chaque promo et pour chaque semestre
• Exemple : – Données :
– Etudiant(nom, adresse, ville, pays) • Etudiants (nom, prénom, groupe)
– Le pays dépend de la ville or l’identifiant d’étudiant est le nom. • Cours (nom, pôle, coefficient)
• Notes (pour un étudiant et un cours: DS1, DS2, Participation, Examen)
– Traitements :
Nom Adresse Ville Pays
• Moyenne par cours pour chaque étudiant
Jim .... Paris France
• Moyenne par pôle pour chaque étudiant
Jack .... Paris France • Moyenne générale pour chaque étudiant
Joe .... Mantes France • Moyenne par groupe, par cours.
Jerry .... Paris France
Modèle entité-association Modèle entité-association
Etudiant TypeNote
a obtenu Cours
N° 0,n DS1 0,n NomCours
Type
Nom DS2 Coefficient
Pôle
Participation Coefficient
Prénom 1,n
Examen
Groupe Etudiant
a obtenu Cours
N° 1,n 1,n
Note NomCours
Commentaires Nom
Prénom
Pôle
Coefficient
☺ Le schéma est simple, il répond au problème
☺ On a un minimum de données
On ne peut pas faire de suivi sur une promo Commentaires
On ne peut pas faire de suivi par prof ☺ Le schéma est simple, il répond au problème
Pas de statistiques sur plusieurs années ☺ On a un minimum de données
Problème de gestion: on aura 4 fois les mêmes programmes
Modélisation ‘complète’ Modèle entité-association

• Gérer les notes des étudiants veut dire: TypeNote
Type
– Hypothèses : Coefficient
• Une base de données pour l’Université (pour plusieurs années) 1,n

• On veut gérer les profs pour faire des stats par profs, par promos, Etudiant
a obtenu Cours
etc... N° 1,n 1,n
Note NomCours
Nom
– Problèmes : Prénom
Pôle
Coefficient
• Gestion des redoublement, de la situation (actuelle) d’un étudiant 1,n
1,n
• Cohabitation de notes sur plusieurs années, des profs, des étudiants ?? Période 1,n
1,n
• Les matières sont enseignés par plusieurs profs, qui met les notes ?? Est dans 1,n Code Enseigne
Année
• Comment modéliser qu’un prof enseigne à un groupe de TP ? Semestre Nb heures
– Données : 1,n
• Etudiants, Matières, Notes 1,n
• TypeDeNotes, Periodes, Profs, Groupes, etc... Groupe 1,n Profs
Code
1,n
Nom
Prénom
Adresse
46
Le modèle relationnel
• En 1970, Codd, mathématicien, chercheur chez IBM,
propose le Modèle Relationnel, basé sur le concept de
Relation de la théorie des ensembles
Le modèle relationnel
A Relational Model of Data for Large Shared Data Banks,
CACM 13, No. 6, June 1970
• Il définit l’ Algèbre Relationnelle sur laquelle est basé

SQL (Structured Query Language), le langage standard
de manipulation (LMD) et de description des données
(LDD) de tous les SGBD Relationnels actuels
47 48
Domaine Produit cartésien

• ENSEMBLE DE VALEURS • LE PRODUIT CARTESIEN D1x D2x ... x Dn
• Exemples: EST L'ENSEMBLE DES TUPLES (N-UPLETS)
– ENTIER <V1,V2,....Vn> TELS QUE Vi∈Di
– REEL
– CHAINES DE CARACTERES • Exemple:
– EUROS – D1 = {Bleu,Blanc,Rouge}
– SALAIRE = {4 000..100 000} – D2 = {Vrai, Faux}
– COULEUR= {BLEU, BLANC, ROUGE}
Bleu Vrai
Bleu Faux
Blanc Vrai
Blanc Faux
Rouge Vrai
Rouge Faux
49 50
Relation, attribut Exemple de relation

• SOUS-ENSEMBLE DU PRODUIT CARTESIEN
D'UNE LISTE DE DOMAINES Champs, attributs,
– Une relation est caractérisée par un nom
Relation ou table colonnes
– Exemple:
CoulVins Coul Choix
• D1 = COULEUR Bleu Faux
• D2 = BOOLEEN Blanc Vrai
Rouge Vrai Id-D Nom Prénom
• Plus simplement … 1 Dupont Pierre
– Une relation est une table à deux dimensions 2 Durand Paul
– Une ligne est un tuple 3 Masse Jean

…. …….. ……
– 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
Tuples, lignes ou
– prend ses valeurs dans un domaine n-uplets
51 52
Clé Clé Etrangère

• GROUPE D'ATTRIBUTS MINIMUM QUI
DETERMINE UN TUPLE UNIQUE DANS UNE • GROUPE D'ATTRIBUTS DEVANT APPARAITRE
RELATION
COMME CLE DANS UNE AUTRE RELATION
• Exemples:
– {CRU,MILLESIME} DANS VINS ==> NV
• Les clés étrangères définissent les contraintes
– NSS DANS PERSONNE d'intégrité référentielles
– Lors d'une insertion, la valeur des attributs doit exister dans
• CONTRAINTE D'ENTITE la relation référencée
– Toute relation doit posséder au moins une clé documenté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 entité-association obligatoires
53 54
Modélisation Relationnelle (2) Clés primaires

Docteurs Prescriptions Docteurs Prescriptions
Id-D Nom Prénom Id-V Ligne Id-M Posologie Id-D Nom Prénom Id-V Ligne Id-M Posologie
1 Dupont Pierre 1 1 12 1 par jour 1 Dupont Pierre 1 1 12 1 par jour
Visites Visites
2 Durand Paul 1 2 5 10 gouttes 2 Durand Paul 1 2 5 10 gouttes
Id-D Id-P Id-V Date Prix Id-D Id-P Id-V Date Prix
3 Masse Jean 2 1 8 2 par jour 3 Masse Jean 2 1 8 2 par jour
1 2 1 15 juin 250 1 2 1 15 juin 250
…. …….. …… 2 2 12 1 par jour …. …….. …… 2 2 12 1 par jour
1 1 2 12 août 180 1 1 2 12 août 180
2 2 3 13 juillet 350 2 3 3 2 gouttes 2 2 3 13 juillet 350 2 3 3 2 gouttes
2 3 4 1 mars 250 …. …. …. ………… 2 3 4 1 mars 250 …. …. …. …………
Patients Patients
Id-P Nom Prénom Ville Médicaments Id-P Nom Prénom Ville Médicaments
1 Lebeau Jacques Paris Id-M Nom Description 1 Lebeau Jacques Paris Id-M Nom Description
2 Troger Zoe Evry 1 Aspegic 1000 …………………………….. 2 Troger Zoe Evry 1 Aspegic 1000 ……………………………..
3 Doe John Paris 2 Fluisédal …………………………….. 3 Doe John Paris 2 Fluisédal ……………………………..
4 Perry Paule Valenton 3 Mucomyst …………………………….. 4 Perry Paule Valenton 3 Mucomyst ……………………………..
…. ……. ……. ……. …. …….. …………………………….. …. ……. ……. ……. …. …….. ……………………………..
55 56
Clés étrangères Schéma relationnel

Docteurs Prescriptions
Id-D Nom Prénom
• Docteurs (Id-D, Nom, Prénom)
Id-V Ligne Id-M Posologie
1 Dupont Pierre
Visites 1 1 12 1 par jour • Visites (Id-D, Id-P, Id-V, Date, Prix)
2 Durand Paul 1 2 5 10 gouttes
Id-D Id-P Id-V Date Prix
3 Masse Jean 2 1 8 2 par jour • Prescriptions (Id-V, Ligne, Id-M, Posologie)
1 2 1 15 juin 250
…. …….. …… 2 2 12 1 par jour
1 1 2 12 août 180 • Patients (Id-P, Nom, Prénom, Ville)
2 2 3 13 juillet 350 2 3 3 2 gouttes
2 3 4 1 mars 250 …. …. …. ………… • Médicaments (Id-M, Nom, Description)
Patients
Id-P Nom Prénom Ville Médicaments • En souligné : clés primaires
1 Lebeau Jacques Paris Id-M Nom Description
2 Troger Zoe Evry 1 Aspegic 1000 …………………………….. • En italiques : clés étrangères
3 Doe John Paris 2 Fluisédal ……………………………..
3 Mucomyst ……………………………..
• ¨Il faudrait indiquer les types (domaines) de chaque attribut
4 Perry Paule Valenton
…. ……. ……. ……. …. …….. ……………………………..
57 58
Métabase Passage au niveau logique

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

Profs
• Un prof enseigne un et un seul
Cours
• Régle 1 : Chaque propriété devient un attribut. Nom 1,1 Enseigne
1,1 cours
NomCours
Prénom NbreHeures
Description
Adresse
• Un cours est enseigné par un et
un seul prof
• Règle 2 : Chaque entité devient une table et son
identifiant devient sa clef primaire 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
• Règle 3 : Une association peut :

– être ‘‘absorbé ’’ par l’une ou l’autre des entité Nom NomCours Nbreheures
Bouganim Info 44
– devenir une table. Solution 2 Crenn Math 78
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
61 62
Exemple 2 Exemple 3
Profs
• Un prof enseigne un et un seul Profs
• Un prof enseigne un ou
Cours Cours
Nom 1,1 Enseigne
0,1 cours Nom 1,n Enseigne
1,1 plusieurs cours
NomCours NomCours
Prénom NbreHeures Prénom NbreHeures
Description Description
Adresse
• Un cours est enseigné par un Adresse
• Un cours est enseigné par un et
prof ou n’est pas enseigné un seul prof
Nom Prénom Adresse NomCours Description NbreHeures Nom Prénom Adresse NomCours Description NbreHeures
Solution 1 Bouganim Luc Paris Info Informatique 44 Solution 1 Bouganim Luc Paris Info Informatique 20
Crenn Isabelle Paris Math Mathématiques 78 Crenn Isabelle Paris Math Mathématique 48
Droit Droit Crenn Isabelle Paris Droit Droit 26
Solution 2 Solution 2
Nom NomCours Description NbreHeures
Nom Prénom Adresse NomCours NbreHeures NomCours Description Nom Prénom Adresse
Bouganim Luc Paris Bouganim Info Informatique 20
Bouganim Luc Paris Info 44 Info Informatique
Crenn Isabelle Paris Math 78 Math Mathématiques Crenn Isabelle Paris Crenn Math Mathématique 48
Droit Droit Crenn Droit Droit 26
Passage au modèle relationnel - 63
Conclusion Le langage SQL – Partie 1

• Objectifs
– Ne pas créer de tables inutiles Création, modification du schéma.
– 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
Le standard SQL EXEMPLE DE BASE DE DONNEES
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 ...
Création de table Exemple de création de table

CREATE TABLE RDV(
CREATE TABLE <nom_table>
NumRdv Integer,
(<def_colonne> * [<def_contrainte_table>*]) ; DateRDV Date,
NumDoc Integer,
< def_colonne > ::= <nom_colonne> < type > [CONSTRAINT nom_contrainte <
NumPat Integer,
NOT NULL |
UNIQUE | Motif Varchar(200),
PRIMARY KEY | CONSTRAINT Clé_Primaire_RDV PRIMARY KEY (NumRdv),
CHECK (condition) | CONSTRAINT Référence_DOC FOREIGN KEY (NumDoc) REFERENCES DOC,
REFERENCES nom_table (colonne) > ] CONSTRAINT Référence_PAT FOREIGN KEY (NumPat) REFERENCES PAT);
< def_contrainte_table > ::= CONSTRAINT nom_contrainte < L'association d'un nom à une contrainte est optionnelle. Ce nom peut être utilisé pour
UNIQUE (liste_colonnes) | référencer la contrainte (ex: messages d'erreurs).
PRIMARY KEY (liste_colonnes) |
CHECK (condition) | • Exercice 1
FOREIGN KEY (liste_colonnes) REFERENCES nom_table (liste_colonnes)> – Donnez l’expression SQL de la création des tables DOC et DET
Index, modification du schéma Insertion de données
• Création d’index
– CREATE [UNIQUE] INDEX [nom_index] ON nom_table (<nom_colonne> * );
• Suppression INSERT INTO < nom_table >
– DROP TABLE <nom_table>
– DROP INDEX <nom_index> [( attribute [,attribute] … )]
• Modification {VALUES (<value spec.> [, <value spec.>] … ) |
– ALTER TABLE <nom_table> ADD COLUMN <def_colonne>
– ALTER TABLE <nom_table> ADD CONSTRAINT <def_contrainte_table > <query specification>} ;
– ALTER TABLE <nom_table> ALTER <def_colonne>
– ALTER TABLE <nom_table> DROP COLUMN <nom_colonne>
– ALTER TABLE <nom_table> DROP CONSTRAINT <nom_contrainte > • Exemples :
• Exemples – INSERT INTO DOC VALUES (1, ‘Dupont’, ‘Paris’);
– CREATE INDEX Index_date_RDV ON RDV (DateRDV) ; – INSERT INTO DOC (NumDoc, NomDoc) VALUES (2, ‘Toto’);
– ALTER TABLE RDV ADD COLUMN Commentaires varchar(300); – INSERT INTO PAT (NumPat, NomPat, VillePat)
– ALTER TABLE RDV ADD CONSTRAINT PK PrimaryKey(NumRdv); SELECT NumDoc, NomDoc, VilleDoc FROM DOC;
– ALTER TABLE RDV ALTER Motif CONSTRAINT MotifNN NOT NULL;
• Exercices 2
– Créez un index sur le nom du docteur • Exercices 3
– Supprimez l’attribut Motif de la table RDV – Insérez un ensemble cohérent de tuples dans chaque table (1 par table)
– Ajoutez une contrainte de clé primaire à la table MED (sur NumMed)
Suppression (basique): DELETE Correction 1

SYNTAXE :
Donnez l’expression SQL de la création des tables DOC et DET
DELETE FROM <relation_name>
[WHERE <search_condition>] CREATE TABLE DOC(
NumDoc integer,
NomDoc char(30),
EXEMPLES :
VilleDoc varchar(50),
Supprimer les docteurs quand VilleDoc n’est pas renseignée
CONSTRAINT Clé_Primaire_Doc PRIMARY KEY (NumDoc)) ;
DELETE FROM DOC WHERE VilleDoc is NULL
CREATE TABLE DET(
Supprimer le docteur numéro 20 NumOrd integer,
NumLig integer,
DELETE FROM DOC WHERE NumDoc = 20 NumMed integer,
Qté integer,
Supprimer tous les docteur CONSTRAINT Clé_Primaire_DET PRIMARY KEY (NumOrd, NumLig),
CONSTRAINT Référence_ORD FOREIGN KEY (NumOrd) REFERENCES ORD,
DELETE FROM DOC
CONSTRAINT Référence_MED FOREIGN KEY (NumMed) REFERENCES MED);
73 74
Exemple Correction 2
NumOrd NumLig NumMed Qté
Créez un index sur le nom du docteur
1 1 23 2
CREATE INDEX Index_nom_docteur ON DOC (NomDoc) ;
1 2 67 5
1 3 24 7
2 1 19 1 Supprimez l’attribut Motif de la table RDV
2 2 128 1
ALTER TABLE RDV
3 1 12 3
DROP COLUMN Motif;
4 1 11 6
4 2 3 1
4 3 7 2 Ajoutez une contrainte de clé primaire à la table MED (sur NumMed)
4 4 87 1 ALTER TABLE MED

ADD CONSTRAINT cle_prim_MED PRIMARY KEY (NumMed) ;
75
Correction 3
Insérez un ensemble cohérent de tuples dans chaque table (1 par table)
• INSERT INTO DOC VALUES (11, ‘Dupont’, ‘Paris’);

• INSERT INTO PAT VALUES (23,’Toto’, ‘Paris’, 25) Vue d’ensemble des
•
•
INSERT INTO MED VALUES (17, ‘Aspirine’, 4)
INSERT INTO MED VALUES (18, ‘Feroxite’, 19)
bases de données
• INSERT INTO RDV VALUES (45, #20/11/2006#, 11, 23, ‘mal de tête’)
• INSERT INTO ORD VALUES (38, #20/11/2006#, 11, 23)
• INSERT INTO DET VALUES (38, 1, 17, 3)
• INSERT INTO DET VALUES (38, 2, 18, 1)
Vue d’ensemble des SGBD 77
I - Indépendance Physique
78
• Indépendance des programmes d'applications

I- Indépendance
Physique
vis à vis du modèle physique :
X - Standards II- Indépendance
Logique
– Possibilité de modifier les structures de stockage
IX - Gestion de la
confidentialité
III – Langage de
manipulation
(fichiers, index, chemins d'accès, …) sans modifier les
BD programmes;
VIII - Concurrence IV - Gestion des
d’accès vues
– Ecriture des applications par des non-spécialistes des
VII - Gestion des V - Optimisation des
pannes questions fichiers et des structures de stockage;
VI - Gestion de la
cohérence – Meilleure portabilité des applications et
indépendance vis à vis du matériel.
79 80
II - Indépendance Logique Avantages de l’indépendance logique

Les applications peuvent définir des vues logiques de la BD • Possibilité pour chaque application d'ignorer les
Gestion des médicaments Cabinet du Dr. Masse
besoins des autres (bien que partageant la même BD).
Nombre_Médicaments Prescription
Id-M Nom Description Nombre
Id -D
Visites
Id -P Id -V Date Prix
Id -V
1
1
Ligne
1
2
Id -M
12
5
Posologie
1 par jour
10 gouttes
• Possibilité d'évolution de la base de données sans
1
2
Aspegic 1000
Fluisédal
……………………………..
……………………………..
30
20
1
2
2
3
1
4
15 juin
1 mars
250
250
…. …. …. …………
réécriture des applications :
Patients
3
….
Mucomyst
……..
……………………………..
……………………………..
230
…..
Id -P
1
2
Lebeau
Troger
Nom Prénom
Jacques
Zoe
Id -M
1
Nom
Médicament
Aspegic 1000
Description
……………………………..
– ajout de champs, ajout de relation, renommage de champs.
…. ……. ……. 2 Fluisédal ……………………………..
3 Mucomyst ……………………………..
…. …….. ……………………………..
• Possibilité d'intégrer des applications existantes sans

modifier les autres.
• Possibilité de limiter les conséquences du partage :

Données confidentielles.
Docteur Prescription
Id-D Nom Prénom Id-V Ligne Id-M Posologie
1 Dupont Pierre 1 1 12 1 par jour
Visites
3 M asse 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 2 3 13 juillet 350 2 3 3 2 gouttes
2 3 4 1 mars 250 …. …. …. …………
Patients
Id-P Nom Prénom Médicament
1 Lebeau Jacques Id-M Nom Description
2 Troger Zoe 1 Aspegic 1000 ……………………………..
3 Doe John 2 Fluisédal ……………………………..
4 Perry Paule 3 M ucomyst ……………………………..
…. … …. ……. …. …….. ……………………………..
81 82
III - Manipulation aisée Exemple de question SQL (1)

• La manipulation se fait via un langage déclaratif
• Nom et description des médicaments de type aspirine
– 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 Select Nom, Description
From Médicaments
• Syntaxe (aperçu !)
Where Type = ‘Aspirine’
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>
83 84
Exemple de question SQL (2) Exemple de question SQL (3)
• Patients parisiens ayant effectués une visite le 15 juin • Dépenses effectuées par patient trié par ordre décroissant
Select Patients.Nom, Patients.Prénom Select Patients.Id-P, Patients.Nom, sum(Prix)

From Patients, Visites From Patients, Visites
Where Patients.Id-P = Visites.Id-P Where Patients.Id-P = Visites.Id-P
and Patients.Ville = ’Paris’ GroupBy Patients.Id-P, Patients.Nom
and Visites.Date = ’15 juin’ OrderBy sum(Prix) desc
85 86
IV – Gestion des vues Les vues : des relations virtuelles !

• Les vues permettent d’implémenter l’indépendance Le SGBD transforme la question sur les vues en
logique en permettant de créer des objets virtuels question sur les relations de base
• Vue = Question SQL stockée
Question Q
sur des vues
• Le SGBD stocke la définition et non le résultat
• Exemple : la vue des patients parisiens
Create View Parisiens as ( Gestionnaire
de Vues
Select Nom, Prénom
Question Q’
Définition des sur les relations
From Patients vues de base
Where Patients.Ville = ’Paris’ )
87 88
Les vues : Mise à jour Les vues : Les instantanés (snapshot)

• Non définie si la répercussion de la mise à jour vers la base • Instantané, Snapshot, vue concrète, vue matérialisée
de données est ambiguë – matérialisée sur le disque
– ajouter un tuple à la vue calculant le nombre de médicaments ? – accessible seulement en lecture
• Restrictions SQL (norme): – peut être réactualisé
– Pas de distinct, d’agrégats, ni d’expression • Exemple
– La vue contient les clés et les attributs « non nulls » – create snapshot Nombre_Médicaments as
– Il y a une seule table dans le from Select Id-M, Nom, Description, count(*)
– Requêtes imbriquées possibles From Médicaments M, Prescriptions P
– Certains SGBDs supportent plus de mises à jour Where M.Id-M = P.Id-M
• Clause « With check option » refresh every day
– Le SGBD vérifie que les tuples insérés ou mis à jour correspondent • Objectif principal : la performance
à la définition de la vue
89 90
V –Exécution et Optimisation Sélection

• Traduction automatique des questions déclaratives en
programmes procéduraux : Patients Patients
Id-P Nom Prénom Ville Id-P Nom Prénom Ville
σ
Utilisation de l’algèbre relationnelle 1 Lebeau Jacques Paris 1 Lebeau Jacques Paris
2 Troger Zoe Evry 2 Troger Zoe Evry
3 Doe John Paris 3 Doe John Paris
• Optimisation automatique des questions 4 Perry Paule Valenton 4 Perry Paule Valenton
Utilisation de l’aspect déclaratif de SQL
Gestion centralisée des chemins d'accès (index, hachages, …)
Techniques d’optimisation poussées Patients de la ville de Paris
• Economie de l'astuce des programmeurs

– milliers d'heures d'écriture et de maintenance de logiciels.
91 92
Projection Jointure
Patients Visites
Id-P Nom Prénom Ville Id-D Id-P Id-V Date Prix
Patients Patients 1 Lebeau Jacques Paris 1 2 1 15 juin 250
Id-P Nom Prénom Ville Id-P Nom Prénom Ville 2 Troger Zoe Evry 1 1 2 12 août 180
π
1 Lebeau Jacques Paris 1 Lebeau Jacques Paris 3 Doe John Paris 2 2 3 13 juillet 350
2 Troger Zoe Evry 2 Troger Zoe Evry 4 Perry Paule Valenton 2 3 4 1 mars 250
3 Doe John Paris 3 Doe John Paris

4 Perry Paule Valenton 4 Perry Paule Valenton
Id-P Nom Prénom Ville Id-D Id-P Id-V Date Prix

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

93 94
Exemple de plan d’exécution Plan d’exécution optimisé
π
Select Patients.Nom, Patients.Prénom π π
From Patients, Visites
σ
Where Patients.Id-P = Visites.Id-P
and
and
Patients.Ville = ’Paris’
Visites.Date = ’15 juin’
σ π π
σ σ
Patients Visites Patients Visites
Patients Visites
95 96
VI - Intégrité Logique Contraintes d’intégrité

• Avantages :
• Objectif : Détecter les mises à jour erronées – simplification du code des applications
– sécurité renforcée par l'automatisation
• Contrôle sur les données élémentaires – mise en commun des contraintes, cohérence
– Contrôle de types: ex: Nom alphabétique
• Nécessite :
– Contrôle de valeurs: ex: Salaire mensuel entre 5 et 50kf
– un langage de définition de contraintes d'intégrité
• Contrôle sur les relations entre les données – la vérification automatique de ces contraintes
– 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 BD BD
97 98
Exemples de contrainte Contraintes d’intégrité : Syntaxe

• Contraintes d’intégrité référentielles create table <nom de table> (
<attribut> <domaine> [<contrainte d'attribut>], (mono-attribut)
Docteurs Prescriptions <attribut> <domaine> [<contrainte d'attribut>], …
Id-D Nom Prénom Id-V Ligne Id-M Posologie
1 Dupont Pierre
[<contrainte de relation>]) (mono ou multi-attributs)
Visites 1 1 12 1 par jour
3 Masse Jean
1 2 1 15 juin 250
2 1 8 2 par jour • Différent types de contraintes :
…. …….. …… 2 2 12 1 par jour – Non nullité : not null
1 1 2 12 août 180
2 3 3 2 gouttes
2 2 3 13 juillet 350 – Unicité : unique
2 3 4 1 mars 250 …. …. …. …………
– Vérification : check <formule>
– Clé primaire : primary key
• Vérification lors de l’insertion, la suppression, la modification – Contrainte d’intégrité référentielle : references <relation> (<attribut>)
• on delete / on update cascade, set null, set default
• Propagation des suppression, modification en cascade possible
(on delete cascade) • On peut nommer les contraintes
99 100
Contraintes d’intégrité : Remarques finales Déclencheurs : Définition
• Contraintes supportées (exemple d’Oracle) • Définition : Déclencheurs ou Triggers
– Les contraintes faisant intervenir un ou plusieurs attributs – Règle E – C – A : Évènement – Condition – Action
d’une seule table et d’un seul tuple
– Contraintes d’intégrité référentielles avec cascade
Lorsque l’évènement se produit
• Mécanisme puissant : – Insert / Update / Delete pour une relation donnée
– Exemple : supprimer les patients n’ayant pas consulté depuis si la condition est remplie
2 ans – Prédicat SQL optionnel
Docteurs Visites Prescriptions
alors exécuter l’action
– Code à exécuter (ex. PLSQL sous Oracle)
– Pour chaque tuple concerné ou une fois pour l’évènement
Patients Médicaments
101 102
Déclencheurs : Objectifs Déclencheurs : Syntaxe (dans Oracle)

• Objectif : une base de données ‘active’ Create trigger <nom de trigger>
– valider les données entrées before | after permet d ’indiquer quand le trigger va être exécuté
– créer un audit de la base de données insert | delete | update [of <attributs>] Quel est l’évènement déclencheur
– dériver des données additionnelles on <relation> indique le nom de la table qui doit être surveillée
[referencing old as <var>, new as <var>] en SQL3, Oracle utilise :new et :old
– maintenir des règles d’intégrité complexes
for each row Précise si l’action est exécuté 1 fois par tuple concerné ou pour toute la table
– implanter des règles métier
[when <condition>] permet d ’indiquer une condition pour l’exécution du trigger
– supporter des alertes (envoi de e-mails par exemple)
DECLARE Déclaration de variables pour le bloc PL/SQL
• Gains BEGIN Bloc PL/SQL contenant le code de l’action à exécuter
– simplification du code des applications <PL/SQL bloc> Dans SLQ3, on peut indiquer une suite de commande SQL
– sécurité renforcée par l'automatisation END

– les déclencheurs sont stockées dans la base
– Cohérence globale des déclencheurs • La syntaxe diffère légèrement suivant le SGBD
103 104
Déclencheurs : Exemples simples Déclencheurs : Remarques finales

Create trigger calcul_TTC after insert on Vente • Cascade de triggers
Begin – l’action d’un trigger peut déclencher d’autres triggers
update vente set Prix_TTC = Prix_HT*1.206
End ;
• Interactions avec les contraintes
Create trigger ModifCommande after update on Commande – l’action d’un trigger peut causer la vérification des
For each row
contraintes
Begin
if :new.qte< :old.qte – les actions des contraintes référentielles peuvent déclencher
then raise_application_error(-9996,‘ La quantité ne peut diminuer’); des triggers (delete cascade, update cascade)
End ;
Create trigger ModifCommande after update on Commande

• Mécanisme très (trop ?) puissant
For each row – Cascade ‘infinie’
When (new.qte< old.qte) – Tables en ‘mutation’
Begin Usage limité
raise_application_error(-9996, ,‘ La quantité ne peut diminuer’);
End ;
105 106
VII - Intégrité Physique Transaction

• Motivations : Tolérance aux fautes
– Transaction Failure : Contraintes d'intégrité, Annulation
Incohérence possible...
– System Failure : Panne de courant, Crash serveur ... Etat cohérent Etat cohérent
– Media Failure : Perte du disque
– Communication Failure : Défaillance du réseau Begin Commit
Transaction
• Objectifs :
– Assurer l'atomicité des transactions
– Garantir la durabilité des effets des transactions commises Begin
CEpargne = CEpargne - 3000
• Moyens :
– Journalisation : Mémorisation des états successifs des données CCourant = CCourant + 3000
– Mécanismes de reprise Commit T1
107 108
Atomicité et Durabilité VIII - Partage des données
ATOMICITE DURABILITE
BD
Panne
Begin Begin
CEpargne = CEpargne - 3000 CEpargne = CEpargne - 3000
CCourant = CCourant + 3000 CCourant = CCourant + 3000
Commit T1 Commit T1
Crash disque
Annuler le débit !! S’assurer que le

virement a été fait ! • Accès concurrent aux mêmes données
Conflits d’accès !!
109 110
VIII - Partage des données IX – Confidentialité

• Objectif : Protéger les données de la BD contre des
accès non autorisés
BD • Deux niveaux :
– Connexion restreinte aux usagers répertoriés (mot de passe)
– Privilèges d'accès aux objets de la base
• Usagers : Usager ou groupe d’usagers

• Le SGBD gère les accès concurrents
• Objets : Relation, Vue, autres objets (procédures, etc.)
Chacun à l’impression d’être seul (Isolation)
Cohérence conservée (Verrouillage)
111 112
Puissance des droits SGBD X - Standardisation

Employés Public • L’approche bases de données est basée sur plusieurs
Service des (intranet) (internet) standards
ressources – Langage SQL (SQL1, SQL2, SQL3)
humaines – Communication SQL CLI (ODBC / JDBC)
Id-E Nom Prénom Poste
1 Ricks Jim 5485 – Transactions (X/Open DTP, OSI-TP)
2 Trock Jack 1254 Nombre Masse
3 Lerich Zoe 5489 d’employés Salariale
4 Doe Joe 4049 4 890
• Force des standards
– Portabilité
– Interopérabilté
Id-E Nom Prénom Poste Adresse Ville Salaire – Applications multisources…
1 Ricks Jim 5485 ………. Paris 230
2 Trock Jack 1254 ………. Versailles 120
3 Lerich Zoe 5489 ………. Chartres 380
4 Doe Joe 4049 ………. Paris 160
113
Architecture Client-Multiserveurs Architecture hétérogène
Appli 1 Appli 2 Appli n

Appli 1
SQL SQL
ODBC ODBC Médiateur
SQL
SQL
Source 1 : Source 2 :
SGBD serveur Web
SGBD 1 SGBD 2
code données code données
code données code données
115 116
Applications traditionnelles
Applications des SGBD (1)
des SGBD
• OLTP (On Line Transaction Processing) • BD et WEB

– Cible des SGBD depuis leur existence – Serveurs Web dynamiques, sites marchands ...
– Banques, réservation en ligne ... – Plusieurs profils (OLTP, publication d’informations en ligne,
– Très grand nombre de transactions en parallèle hébergement de données …)
– Transactions simples
• Challenges majeurs
• OLAP (On Line Analytical Processing) – Gestion de données XML
– Entrepôts de données, DataCube, Data Mining … – Fédération de sources de données hétérogènes
– Faible nombre de transactions – Grilles de données
– Transactions très complexes – Sécurité des données en ligne
117
Applications des SGBD (2) SQL (Partie 2) :

Interrogation, mise à jour,
• BD personnelles ou PME
suppression de données
– Comptabilité
– Agenda, comptes bancaires, carnet d’adresses, dossiers portables
– BD embarquées sur calculateurs ultra-légers (PDA, téléphones
cellulaires, cartes à puce …)
• Challenges majeurs
– Gérer la mobilité
– S’adapter aux contraintes matérielles du calculateur hôte
– Assurer la durabilité des données
– Assurer la confidentialité des données
SELECT : forme générale Forme générale de la condition de recherche

SELECT [DISTINCT| ALL] { * | <value exp.> [, <value exp.>]...} <search condition> ::= [NOT]
<nom_colonne> θ constante ⏐ <nom_colonne>
FROM relation [variable], relation [ variable]…
<nom_colonne> LIKE <modèle_de_chaîne>
[WHERE <search condition>] <nom_colonne> IN <liste_de_valeurs>
[GROUP BY <attribute> [,<attribute>]...] <nom_colonne> θ (ALL ⏐ ANY ⏐ SOME) <liste_de_valeurs>
EXISTS <liste_de_valeurs>
[HAVING <search condition>]
UNIQUE <liste_de_valeurs>
[ORDER BY <attribute> [{ASC | DESC}] [,<attribute>[{ASC | <tuple> MATCH [UNIQUE] <liste_de_tuples>
DESC}] ]...]
<nom_colonne> BETWEEN constante AND constante
<search condition> AND ⏐ OR <search condition>
* EXPRESSION DE VALEURS * CONDITION DE RECHERCHE
- Calculs arithmétiques - Sélection, projection, jointure avec
- Fonctions agrégats< - Recherche textuelle θ ::= < ⏐ = ⏐ > ⏐ ≥ ⏐≤ ⏐ <>
- Recherche par intervalle
- Recherche sur valeur nulle Remarque: <liste_de_valeurs> peut être déterminée par une requête
Projections et restrictions simples Restrictions complexes et jointures
Liste des médicaments de plus de 500 FF NomMed Liste des patients ayant un RDV avec le docteur "Dupont" NomPat
SELECT NomMed FROM MED WHERE Prix> 500 ; SELECT DISTINCT PAT.NomPat FROM PAT, RDV, DOC
WHERE PAT.NumPat = RDV.NumPat and RDV.NumDoc = DOC.NumDoc
Liste des médicaments de plus de 100 € NomMed (prix stocké en FF) and DOC.NomDoc like “dupont”;
SELECT NomMed FROM MED WHERE Prix/6,55957 > 100 ;
Médicaments commençant par « ASPI » prescrits le 25/12/2006 NomMed
Nom des docteurs de LAON NomDoc SELECT DISTINCT M.NomMed FROM MED M, DET D, ORD O
SELECT NomDoc FROM DOC WHERE VilleDoc = “Laon” WHERE M.NumMed = D.NumMed and D.NumOrd = O.NumOrd
and O.Date = #25/12/2006# and NomMed like “ASPI%”;
Quelles ont été les motifs de consultations de 25/12/2006 Motif
SELECT DISTINCT Motif FROM RDV WHERE DateRDV = #25/12/2006# Docteurs ayant le même nom qu’un patient NomDoc
SELECT D.NomDoc FROM PAT P, DOC D WHERE P.NomPat = D.NomDoc;
EXERCICES 4
• Liste des patients de plus de 40 ans NumPat, NomPat EXERCICES 5
• Age des patients en mois (il est stocké en année) NomPat, AgeMois • Docteurs ayant le même nom que leur patient NomDoc
• Numéro des docteurs ayant consulté entre le 1/9 et le 31/12/06 NumDoc • Nom des médicaments prescrits le 25/12/2006 NomMed
• Nom des patients niçois de plus de 36 ans NumPat, NomPat • Nom des docteurs ayant un RDV pour un motif commençant par ‘grippe’ NomDoc
• Liste des quantité distinctes prescrites du médicament Bubol Qté
Requêtes imbriquées : IN et EXIST SYNTAXE :

Mise à jour : UPDATE
Liste des patients ayant un RDV avec le docteur "Dupont" NomPat UPDATE <relation_name>
SELECT DISTINCT P.NomPat FROM PAT P, RDV R, DOC D SET <attribute> = value_expression [, <attribute> = value_expression ] …
WHERE P.NumPat = R.NumPat and R.NumDoc = D.NumDoc and D.NomDoc = “Dupont”;
[WHERE <search condition> ];
SELECT P.NomPat FROM PAT P WHERE P.NumPat in
(SELECT R.NumPat FROM RDV R WHERE R.NumDoc in EXEMPLES :
(SELECT D.NumDoc FROM DOC WHERE D.NomDoc = “Dupont”));
Mettre “Inconnue” quand VilleDoc n’est pas renseignée
SELECT P.NomPat FROM PAT P WHERE EXISTS
UPDATE DOC SET VilleDoc = “Inconnue” WHERE VilleDoc is NULL
(SELECT * FROM RDV R WHERE P.NumPat = R.NumPat and EXISTS
(SELECT * FROM DOC D WHERE R.NumDoc=D.NumDoc and D.NomDoc = “Dupont”));
Mettre en majuscule le nom des docteurs qui n’ont jamais prescrit
SELECT P.NomPat FROM PAT P WHERE EXISTS
(SELECT * FROM RDV R WHERE EXISTS UPDATE DOC SET NomDoc = UPPER(NomDoc) WHERE NumDoc NOT IN
(SELECT * FROM DOC D WHERE P.NumPat = R.NumPat and R.NumDoc = D.NumDoc (SELECT NumDoc FROM ORD)
and D.NomDoc = “Dupont”));
ATTENTION AUX CONTRAINTES D’INTEGRITE REFERENTIELLES !!!
EXERCICES 6 (avec IN ou EXIST)
• Nom des docteurs ayant au moins un RDV pour une grippe NomDoc EXERCICES 7 :
• Augmenter le prix des aspirines de 10%
• Nom des patients qui n'ont jamais eu de rendez-vous NomPAT
• Fixer le prix des médicaments non prescrits à 100 euros
126
Suppression : DELETE Correction 4

SYNTAXE : DELETE FROM <relation_name> [WHERE <search_condition>] • Liste des patients de plus de 40 ans NumPat, NomPat
SELECT NumPat, NomPat
EXEMPLES : FROM PAT
WHERE AgePat > 40
Supprimer les docteurs quand VilleDoc n’est pas renseignée
• Age des patients en mois (il est stocké en année) NomPat, AgeMois
DELETE FROM DOC WHERE VilleDoc is NULL SELECT NomPat, AgePat*12 AgeMois
Supprimer le docteur numéro 20 : DELETE FROM DOC WHERE NumDoc = 20 FROM PAT
Supprimer tous les docteur : DELETE FROM DOC

• Numéro des docteurs ayant consulté entre le 1/9 et le 31/12/06 NumDoc
Supprimer les docteurs qui n’ont jamais prescrit SELECT DISTINCT NumDoc
FROM RDV
DELETE FROM DOC WHERE NumDoc NOT IN WHERE DateRDV BETWEEN #01/09/2006# AND #31/12/2006#
(SELECT NumDoc FROM ORD) SELECT DISTINCT NumDoc
ATTENTION AUX CONTRAINTES D’INTEGRITE REFERENTIELLES !!! FROM RDV
WHERE DateRDV ≥ #01/09/2006# AND DateRDV ≤ #31/12/2006#
EXERCICES 8
• Supprimer les patients de moins de 10 ans • Nom des patients niçois de plus de 36 ans NumPat, NomPat
SELECT NumPat, NomPat
• Supprimer les médicaments non prescrits FROM PAT
WHERE AgePat > 36 AND VillePat LIKE "Nice"
127 128
Correction 5 Correction 6
• Docteurs ayant le même nom que leur patient NomDoc • Nom des docteurs ayant au moins un RDV pour une grippe NomDoc
SELECT DISTINCT D.NomDoc
SELECT DISTINCT D.NomDoc FROM DOC D, RDV R
FROM PAT P, RDV R, DOC D
WHERE R.NumDoc = D.NumDoc AND R.Motif LIKE “grippe”;
WHERE P.NumPat = R.NumPat AND R.NumDoc = D.NumDoc
AND P.NomPat = D.NomDoc;
SELECT D.NomDoc FROM DOC D WHERE D.NumDoc IN
• Nom des médicaments prescrits le 25/12/2006 NomMed (SELECT R.NumDoc FROM RDV R WHERE R.Motif LIKE “grippe”):
SELECT DISTINCT M.NomMed
FROM MED M, DET D, ORD O SELECT D.NomDoc FROM DOC D WHERE EXISTS
WHERE M.NumMed = D.NumMed AND D.NumOrd = O.NumOrd (SELECT * FROM RDV R WHERE R.NumDoc = D.NumDoc
AND O.Date = #25/12/2006# ; AND R.Motif LIKE “grippe”):
• Nom des docteurs ayant un RDV pour un motif commençant par ‘grippe’ NomDoc
SELECT DISTINCT D.NomDoc
FROM RDV R, DOC D • Nom des patients qui n'ont jamais eu de rendez-vous NomPAT
WHERE R.NumDoc = D.NumDoc
AND R.Motif LIKE “grippe%”; SELECT P.NomPat FROM PAT P WHERE P.NumPat NOT IN
(SELECT R.NumPat FROM RDV R )
• Liste des quantité distinctes prescrites du médicament Bubol Qté
SELECT DISTINCT D.Qté
FROM MED M, DET D SELECT P.NomPat FROM PAT P WHERE NOT EXISTS
WHERE M.NumMed = D.NumMed (SELECT * FROM RDV R WHERE P.NumPat = R.NumPat)
AND M.NomMed LIKE “Bubol”;
129
Correction 7 et 8 SQL (Partie 3) :

• Augmenter le prix des aspirines de 10% Agrégation, Unions, Intersection, Différence
UPDATE MED
SET Prix = Prix * 1.1
Méthodologie SQL
WHERE NomMed LIKE “aspirine%”
• Fixer le prix des médicaments non prescrits à 100 euros

UPDATE MED
SET Prix = 100
WHERE NumMed NOT IN (SELECT NumMed FROM DET);
• Supprimer les patients de moins de 10 ans

DELETE FROM PAT
WHERE AgePat < 10;
• Supprimer les médicaments non prescrits

DELETE FROM MED
WHERE NumMed NOT IN (SELECT NumMed FROM DET);
132
Calculs d'agrégats Agrégats : autres exemples et exercices

Les fonctions d’agrégation (Count, Sum, Avg, Min, Max) permettent de • Nom du(des) médicament(s) le(s) moins cher(s)
réaliser des calculs sur des ensembles de données SELECT NomMed FROM MED
WHERE Prix = SELECT MIN(Prix) FROM MED
• Calcul de statistiques globaux
– Nombre de patients : SELECT count(*) FROM PAT • Total des prix des médicaments prescrits par patient
– Prix moyen des médicaments : SELECT avg(Prix) FROM MED
SELECT P.NomPat, sum(M.prix * O.Qté) PrixTotal
FROM PAT P, ORD O, DET D, MED M
• Calcul de statistiques par groupe
– Nombre de patients par ville : WHERE M.NumMed = D.NumMed and D.NumOrd = O.NumOrd and O.NumPat =
SELECT VillePat, count(*) NbPatient FROM PAT GROUP BY VillePat
P.NumPat
GROUP BY P.NomPat
– Nombre de patients par ville ayant consulté pour un mal de tête
SELECT VillePat, count(DISTINCT(NumPat)) NbPatient FROM PAT, RDV
EXERCICES 9
WHERE PAT.NumPat = RDV.NumPat and Motif = ‘mal de tête’ GROUP BY VillePat
• Nombre total d’ordonnances
– Ville où plus de 10 patients ont consulté pour un mal de tête • Nombre d’ordonnances par docteur
SELECT VillePat FROM PAT, RDV • Age du plus jeune patient
WHERE PAT.NumPat = RDV.NumPat and Motif = ‘mal de tête’ • Nom du plus jeune patient
GROUP BY VillePat
HAVING count(DISTINCT(NumPat)) > 10
133
Évaluation « sémantique » d’une
requête SQL
Union/Intersection/Différence
<requêteSQL_A>
1. FROM UNION [ALL]

Réalise le produit cartésien des relations INTERSECT
EXCEPT
2. WHERE
Réalise restriction et jointures <requêteSQL_B>
3. GROUP BY XXX
XXX
Constitue les partitions YYY
(e.g., tri sur l’intitulé du groupe) ZZZ [ALL] permet de conserver les doublons dans le résultat d'une union
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 AGG1 ZZZ
Trier les tuples résultat AGG3 XXX
135 136
Union/Inter°/Diff. : exemples et exercices Des différences selon le SGBD…

• Ensemble des personnes de la base médicale
SELECT NomMed NomPers FROM MED UNION SELECT NomPat NomPers FROM PAT
• Patients qui sont aussi médecins Access SQL Server 2000 Oracle8
SELECT NomPat PatMed FROM PAT INTERSECT SELECT NomMed PatMed FROM MED
GROUP BY Y Y Y
• Patients qui ne sont pas médecins
HAVING Y Y Y
SELECT NomPat Patient FROM PAT EXCEPT SELECT NomMed Patient FROM MED
UNION Y Y Y
INTERSECT N N Y
EXERCICES 10
• Numéro des médicaments jamais prescrits EXCEPT N N Y (MINUS)
• Villes mentionnées dans la base
• Villes où il y a au moins un docteur mais aucun patient
• Villes où il y a au moins un docteur et au moins un patient
138
Jointure Interne / Externe Correction 9

• Nombre total d’ordonnances
Évite d’écrire la condition de jointure SELECT COUNT(*) FROM ORD
(clause d’égalité sur les colonnes de même nom…)
<Join_expression> ::=
• Nombre d’ordonnances par docteur
<table-ref> [NATURAL] [<join_type>] JOIN <table-ref>
SELECT DOC.NumDoc, DOC.NomDoc, COUNT(*)
[ON <condition> ⏐ USING <nom_colonne> *]
FROM DOC, ORD where DOC.numDoc = ORD.NumDoc
USING precise le sous-ensemble des colonnes
communes à considérer dans la jointure GROUP BY DOC.NumDoc, DOC.NomDoc
<table-ref> CROSS JOIN <table-ref> (NB: remplace le ON…)
Produit cartésien • Age du plus jeune patient

<join_type> ::= (INNER JOIN avec clause toujours vrai) SELECT min(AgePat) from PAT
INNER OUTER est optionnel dans la syntaxe (même fonctionnalité)
LEFT [OUTER] • Nom du plus jeune patient

OUTER produit certains tuples ne joignant pas… SELECT NomPat FROM PAT
RIGHT [OUTER]
WHERE AgePat = SELECT min(AgePat) from PAT
FULL [OUTER]
…LEFT… UNION…RIGHT…
139
Correction 10
• Nom des médicaments jamais prescrits
SELECT NomMED FROM MED WHERE NumMED not in
(SELECT NumMed FROM DET)
• Villes mentionnées dans la base JDBC

SELECT VilleDoc Ville FROM DOC UNION
SELECT VillePat Ville FROM PAT (Java DataBase Connectivity)
• Villes où il y a au moins un docteur mais aucun patient
SELECT VilleDoc Ville FROM DOC MINUS
SELECT VillePat Ville FROM PAT
Supports inspirés des cours de P. Pucheral, N. Anciaux, S. Lopez
• Villes où il y a au moins un docteur et au moins un patient
SELECT VilleDoc Ville FROM DOC INTERSECT
SELECT VillePat Ville FROM PAT
Problématique de la connexion
Langages procéduraux dédiés (1)
langage Hôte/SQL
• Comment passer une commande dans la base telle que :
PROCEDURE COMM • SQL est un langage :
Si le client n’est pas encore dans la base
Insérer les informations du client dans la table client – déclaratif
Si l’article est disponible dans la quantité commandée
ET le livreur disponible à la date de livraison désirée
– manipulant des ensembles de tuples
Insérer sa commande dans la base – ayant ses propres types de données
Sinon abandonner la commande
• Impedance mismatch avec tout langage procédural
• Impossible en SQL pur (SQL n’est pas un langage – conversion de types (ex: varchar(n) SQL => quel type C ?)
complet) – traitement des valeurs nulles (True, False, Unknown)
– Pas de structure de contrôle : itérations, tests … – parcours itératif des résultats de requêtes SQL
– Besoin d’un langage complet pour programmer des actions
sur les BD
Langages procéduraux dédiés (2) Langages procéduraux dédiés (3)

• Exécution client (envoie de SQL par ODBC, JDBC,…) • Stockage de procédures sur le serveur
– Chargement et compilation de la procédure sur le serveur
Client
Appels Driver Serveur – Lancement à distance par appel de procédure (EXECUTE)
JDBC JDBC BD
SQL
COMM
…
Java
Serveur Oracle COMM
Client PL/SQL
Execute COMM
Moteur Serveur
BD
PL/SQL SQL
Résultat exécution
Serveur Oracle
• Exécution serveur (envoie de procédure anonyme)
COMM
Client PL/SQL – Stocké comme un objet base de données
Moteur Serveur
BD • Le créateur à les droits d’exécuter, modifier, re-compiler la procédure
PL/SQL SQL
Résultat exécution • Partage les droits avec d’autres (GRANT/REVOKE EXECUTE)
Serveur Oracle
146
L’API JDBC
API de communication à un SGBD (Java DataBase Connectivity)
• SQL-CLI (Call Level Interface)
– API standardisée par X/Open depuis 1994, intégrée dans SQL3 • Permet de simplifier l’accès à une BD depuis Java
– Permet de se connecter et d’envoyer des requêtes SQL à tout serveur (évite l’utilisation de code natif)
SQL, quel que soit son type, sa localisation, le mode de connexion ...
• Popularisé par des médiateurs tels que : • JDBC fournit un ensemble de classes et d’interfaces
– ODBC (Open DataBase Connectivity) pour l’utilisation d’un ou plusieurs SGBD à partir d’un
• API assez complexe programme Java
• interface C (nécessite l’utilisation de code natif)
– JDBC (Java DataBase Connectivity) • Intérêts de JDBC
• vue “objet” des mêmes concepts que ODBC – interface uniforme pour accéder à un SGBD
• un pont JDBC-ODBC existe
– indépendant du SGBD cible
• L’interface standard (API) assure la portabilité des – simplicité de mise en œuvre
applications et donne la possibilité de communiquer avec des
– supportant les fonctionnalités de base de SQL
SGBD divers
148
Architecture logicielle de JDBC Exemples d’utilisations de JDBC

• Chaque source de données utilise un pilote (driver) qui • Dans un client léger classique
lui est propre et qui convertit les requêtes JDBC dans le API
JDBC
langage natif du SGBD
Applet
Driver
Java Appli/Applet JDBC BD
API API JDBC
JDBC Driver
Clients JDBC
JDBC DriverManager Serveur
API du
Driver
JDBC
Driver(pont) driver Driver driver
• Dans une architecture J2EE
JDBC-ODBC JDBC JDBC SGF local
pour pour API Web API
driver Oracle Sybase (TCP/IP) JDBC
ODBC
protocole Propriétaire
Différentes Applet Servlet Driver
protocole Propriétaire Fichier
implémentations BD
de JDBC JDBC JDBC
Clients API
Oracle Sybase
Oracle Sybase Driver
Serveur Web Serveur BD
JDBC
L’API JDBC Utilisation de JDBC
Etapes à suivre
• API fournie par le package java.sql (le noyau)
• Interfaces (principales) du package (Importer le package java.sql)
– Connection // gestion des connexions • Charger le driver JDBC
– Statement // exécution de requêtes classiques • Établir une connexion à la base de données
– PreparedStatement // préparation de requêtes dynamiques
– CallableStatement // appel de procédures stockées • Créer une instruction (requête/batch/procédure…)
– ResultSet // manipulation du résultat • Exécuter l’instruction
– ResultSetMetaData // description du résultat • Traiter le résultat
– DatabaseMetaData // description de la base • Fermer les différents éléments
– Driver // gestion des pilotes
• Les extensions dans javax.sql
151 152
Les fonctions de JDBC Chargement du pilote JDBC

• Fonctions de bases • Fonctions avancées • Par invocation de la méthode Class.forName
– Charger le/les pilotes – Exceptions JDBC
– Se connecter à la base de données – Accès aux méta-données • Paramètre = chemin de la classe du driver
– Créer une instruction • Du résultat – (fournit dans la doc. du driver)
• SQL statique, • De la base de données
• appel à procédure stockée, – Exécution de
• précompilée et paramétrée • requêtes précompilées
• requêtes paramétrées
• Exemple utilisant le pont (driver) JDBC-ODBC
– Exécuter l’instruction
• LMD de consultation, • procédures stockées
import java.sql.*;
• LDD et LMD de mise à jour, – Exécution par lots (batch)
• procédures stockées – Utilisation de curseurs public class ObjetUtilisantJDBC
{
– Traiter le résultat – Transactions public static void main(String[] Args)
{
• Gestion de l’objet ResultSet – Extension standard (javax.sql) try {Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); }
catch (Exception E) {System.err.println(« Chemin du driver incorrect!");}
– Fermer les différents éléments // ... Etapes suivantes ...
}
}
153 154
Connecter la base de données Créer une instruction

• DriverManager permet d’établir la connexion avec le SGBD • Une instruction est représentée par une instance de la classe
• Grâce à la méthode getConnection de cette classe – Statement, (instruction SQL statique)
– le driver adéquat est retrouvé parmi les drivers chargés – CallableStatement, (appeler une procédure stockée)
– un objet Connection est retourné – ou PreparedStatement (instruction SQL précompilée et paramétrée)
• Paramètres de la méthode • La création se fait à partir de l’objet Connexion en utilisant
– Url fournit les informations nécessaires à la connexion (l’objet Connexion est obtenu à la connexion)
• débute par jdbc:, suivi du sous-protocole (par ex. odbc), suivi par des – createStatement (SQL statique)
informations propres au driver (par ex: le nom de la source de données dans
le cas du pont JDBC-ODBC) – prepareCall (procédure stockée)
– Nom et mot de passe de l’utilisateur sur le SGBD – prepareStatement (SQL précompilé/paramétré)
• Exemple • Exemple import java.sql.*;
public class ObjetUtilisantJDBC
import java.sql.*; {
public class ObjetUtilisantJDBC public static void main(String[] Args)
{ {
public static void main(String[] Args) // ... Etapes précedentes...
{ Statement req1 = con.createStatement();
// ... Etapes précedentes... CallableStatement req2 = con.prepareCall(str);
Connection con = DriverManager.getConnection(jdbc:odbc:Oracle, "scott", "tiger"); PreparedStatement req3 = con.prepareStatement(str);
} }
} }
155 156
Exécuter l’instruction Traiter le résultat

• Méthodes (principales) pour exécuter une instruction • La méthode executeQuery retourne un objet de type
– executeQuery pour les requêtes de type SELECT ...
(LMD de consultation) ResultSet
– executeUpdate pour les CREATE ou INSERT/DELETE/UDATE... – représente un curseur sur le résultat de la requête
(LDD et LMD de mise à jour)
– Exemple
– execute pour les procédures stockées (entre autre)
// ... Etapes précedentes...
• Les méthodes de l’interface Statement (exécution de requêtes ResultSet rs = req1.executeQuery("SELECT * FROM contact");
SQL statiques) prennent en paramètre une chaîne de caractères • La méthode executeUpdate retourne le nombre
représentant la requête à exécuter
– de tuples affectés dans le cas d’un LMD
• Exemple (INSERT/DELETE/IPDATE…)
import java.sql.*;
public class ObjetUtilisantJDBC – 0 dans le cas d’un LDD (CREATE…)
{
public static void main(String[] Args)
{
– Exemple
// ... Etapes précedentes...
req1.executeUpdate("CREATE TABLE contact (nom VARCHAR(50), tel CHAR(10))"); // ... Etapes précedentes...
req1.executeUpdate("INSERT INTO contact VALUES (’dupond’, ’0102030405’)"); int nbTuples = req1.executeUpdate("UPDATE contact " +
} "SET nom = ’dupont’ " +
} "WHERE nom = ’dupond’");
Accès aux résultats 157
Accès aux résultats 158
(curseur) (conversion et valeur nulles)

• Un curseur permet de parcourir les tuples résultats d’une requête
– Représenté dans JDBC par l’interface ResultSet
• Fonctionnement • Conversion de type
– Le curseur d’un objet ResultSet est positionné avant le premier tuple – Les méthodes getXXX convertissent de SQL vers JAVA
– La méthode next permet de faire avancer ce curseur sur le tuple suivant
• retour = false il n’y a plus de tuples à traiter
• Les valeurs des attributs sont obtenues grâce aux méthodes getXXX( ) • Valeurs nulles (NULL de SQL)
– Paramètre = numéro/nom de colonne dans le résultat – Testé grâce à la méthode wasNull de ResultSet
• wasNull est appelée après la lecture de la valeur
• Exemple
(après l’utilisation d’une méthode getXXX)
// ... – Les méthodes getXXX convertissent les valeurs NULL de SQL en
ResultSet rs = req1.executeQuery("SELECT * FROM contact");
while(rs.next()) { une valeur acceptable pour le type Java cible
String nom = rs.getString("nom"); // ou String nom = rs.getString(1);
String tel = rs.getString("tel"); // ou String nom = rs.getString(2);
// ...
}
159 160
Fermer les différents éléments Exceptions

• L’exception SQLException peut être lancée par les méthodes de JDBC
• (préférable pour libérer la mémoire)
• Les éléments concernés
• Elle permet d’obtenir des informations sur l’erreur qui s’est produite
– Curseurs
– une chaîne décrivant l’erreur (méthode getMessage)
– Instructions – un code d’erreur spécifique au SGBD (méthode getErrorCode)
– Connexions – une chaîne d’état SQL (méthode getSQLState)
– Etc.
• Exemple // ... Etapes précedentes...
rs.close();
• Les avertissements du SGBD peuvent aussi être capturés par la classe
req1.close();
c.close();
d’exception SQLWarning
// ... – Un avertissement ne stoppe pas l’exécution du programme
– On utilise la méthode getWarnings de Statement pour les récupérer
161 162
Requête précompilée
Accès aux méta-données (création)
• Procurent des informations (méta-données) sur • Une requête qui doit être exécutée peut être précompilée en
– le SGBD et le driver JDBC (DatabaseMetaData), utilisant PreparedStatement
– ou sur le résultat d’une requête (ResultSetMetaData) – Dans un objectif de performance (temps d’exécution)
– La requête est transmise au SGBD (qui la précompile)
• Le plan d’exécution est préparé
• Exemples de méthodes de l’interface DatabaseMetaData
– Des variables peuvent être utilisées pour paramétrer la requête
– getSchemas pour la liste des schémas disponibles
– getTables pour la liste des tables • Création d’une requête précompilée
– A partir de l’objet Connection
– Grâce à méthode prepareStatement
• Exemples d’utilisation de ResultSetMetaData • La requête est passée en paramètre sous forme de chaîne de caractères
• Les paramètres sont représentés par des ‘?’ dans la chaîne
// ...
ResultSet rs = req1.executeQuery("SELECT * FROM contact"); – Le retour est un objet PreparedStatement prêt à être exécuté
ResultSetMetaData rsmd = rs.getMetaData();
int nbColonnes = rsmd.getColumnCount();
// ... • Exemple // ...
String req = "UPDATE contact SET tel = ? WHERE nom = ?";
PreparedStatement UpdateTel = con.prepareStatement(req);
// ...
163 164
Requête précompilée Requête précompilée
(paramétrage) (exécution)
• Avant d’exécuter la requête fixer les paramètres
• Grâce aux mêmes méthodes que pour des requêtes
(remplacent les ‘?’ par une valeur dans la chaîne)
fixes, mais sans argument
– Grâce aux méthodes setXXX
(où XXX représente un type de données Java) – ExcuteQuery/executeUpdate
– NB: setNull fixe le paramètre à la valeur NULL de SQL – NB: l’instruction contient déjà la requête à exécuter…
– Premier argument = numéro d’ordre du ‘?’ à remplacer • Exemple
– Deuxième argument = valeur de remplacement
// ...
String req = "UPDATE repertoire SET tel = ? WHERE nom = ?";
• Exemple PreparedStatement updateTel = con.prepareStatement(req);
updateTel.setString(1, "0908070605");
updateTel.setString(2, "durand");
updateTel.executeUpdate();
// ... updateTel.setString(1, "0900000000");
String req = "UPDATE contact SET tel = ? WHERE nom = ?"; updateTel.executeUpdate();
PreparedStatement UpdateTel = con.prepareStatement(req); // ...
UpdateTel.setString(1, "0908070605");
UpdateTel.setString(2, "durand");
// ...
165
Transactions 166
Procédures stockées
(portée)
• L’interface CallableStatement permet d’invoquer une procédure • Rappel = une transaction permet d’exécuter un ensemble de
stockée requêtes sur une BD, la faisant passer d’un état cohérent à un
– NB: la procédure est stockée au niveau du SGBD… autre état cohérant, respectant les propriétés transactionnelles
– … la création se faisant avec la méthode prepareCall de Connection (ACID)
• Par défaut, la connexion JDBC est en mode chaîné
// ...
CallableStatement cs = c.prepareCall("{call nom_procedure_stockee}");
– chaque requête est suivie d’un ordre SQL « commit » implicite
// ...
• On peut désactiver ce mode
– soit lors de la création de la connexion // ...
c.setAutoCommit(false);
• La syntaxe de l’appel de procédure (call ...) est traduit par le – soit grâce à la méthode setAutoCommit // ...
driver JDBC dans la syntaxe native du SGBD
• L’exécution de l’instruction se fait de façon classique en – La validation doit alors se faire
fonction de ce que retourne la procédure explicitement par la méthode commit… // ...
c.commit();
// ...
• L’interface CallableStatement est sous-interface de – … et l’annulation se fait grâce à c.rollback();
PreparedStatement et accepte donc des paramètres la méthode rollback // ...
Transactions 167 168
Erreurs dans l’écriture de requêtes

(concurrence)
• Le niveau d’isolation permet de déterminer les incohérences que peut
subir une transaction (lecture sales, fantômes, . . .)
• Mauvaise compréhension du schéma de la base
• Les différents niveaux d’isolation (normalisés) sont
– Connection.TRANSACTION_READ_UNCOMMITTED • Mauvaise compréhension de la question
• lectures sales, non reproductibles et fantômes peuvent se produire
– Connection.TRANSACTION_READ_COMMITTED • Instances de la même table
• les lectures sales sont évitées
– Connection.TRANSACTION_REPEATABLE_READ • Oubli de clauses dans les prédicats
• les lectures sales et non reproductibles sont évitées
– Connection.TRANSACTION_SERIALIZABLE • Doublons
• la transaction est complètement sérialisable
– Connection.TRANSACTION_NONE • Utilisation d’instruction ou de structures SQL
• indique que les transactions ne sont pas supportées
incorrectes
• Les méthodes getTransactionIsolation et setTransactionIsolation de
Connection permettent de connaître et fixer le niveau d’isolation • Erreurs de syntaxe
169 170
Schéma et question Reformulation d’une question (1)

• Avant de se lancer dans l’écriture d’une requête, il faut bien • Paraphrasage :
comprendre le schéma des tables sur lequel on va s’appuyer. – En exprimant de manière plus détaillée une requête, elle devient plus
claire... (ou plus facilement exprimable)
• Si le schéma est complexe, il faut le dessiner, c.a.d. dessiner les tables
et les relations entre ces tables.
• En lisant la question, on repère sur le schéma dans quelle(s) relation(s) • Exemple : Qui est dans la base ?
se trouve chaque donnée. On a alors une idée des tables mises en jeu. Ensemble des personnes de la base médicale
• Si la question est complexe, il faut la reformuler et/ou la décomposer. Nom des médecins et nom des patients
• Une fois ce travail effectué, on peut commencer a écrire du SQL. Union des noms des médecins et des noms des patients
SELECT NomMed NomPers FROM MED

UNION
SELECT NomPat NomPers FROM PAT
171 172
Reformulation (2) : Négation Reformulation (3) : Décomposition

Souvent l’inverse de la requête est plus facile à exprimer. En décomposant, on simplifie la compréhension et on
Cela est particulièrement vrai lorsque la requête contient :
diminue les risques d’erreurs :
• que
– Dans quelle ville n’y a-t-il que des patients de plus de 40 ans?
– L’ensemble des villes moins celles où il y a au moins un patient de 40 ans ou moins • Quels sont les patients dont tous les motifs de rendez
• aucun
vous sont « mal de tête »
– Dans quelle ville n’y a-t-il aucun patients de plus de 40 ans?
– L’ensemble des villes moins celles où il y a au moins un patient de plus de 40 ans • Paraphrasage :
• tous – L’ensemble des patients qui ont un RDV pour un mal de tête moins les
– Quels sont les patients dont tous les motifs de rendez vous sont « mal de tête » patients qui ont un RDV pour un motif différent
– L’ensemble des patients qui ont un RDV pour un mal de tête moins les patients qui
ont un RDV pour un motif différent
• Décomposition
• Tous – Create view SQ1 AS …. (patients qui ont un RDV pour un mal de tête)
– Quels sont les patients qui ont RDV avec tous les médecins – Create view SQ2 AS …. (patients qui ont un RDV pour un motif ≠ de
– Les patients pour lesquels il n’existe pas de docteur avec qui ils n’ont pas eu de mal de tête)
RDV – SELECT NomPat FROM SQ1 EXCEPT SELECT NomPat FROM SQ2
173 174
Instance de tables Oubli de clauses

• Il faut parfois utiliser plusieurs instances de la même table. Comment • Il est assez facile d’oublier une clause dans les prédicats
savoir? de sélection, surtout lorsque l’on joint plusieurs tables.
• Lorsqu’une même table est utilisée pour obtenir deux informations de Pour le vérifier, une règle simple pour les requêtes plates
‘sémantiques différentes’, il faut prendre plusieurs instances de cette (nécessaire mais non suffisante) :
table.
• Exemple : Nom des patients ayant eu des RDV avec les docteurs "Dupont" et
"Durand"
SELECT DISTINCT P.NomPat • Une requête impliquant n tables doit posséder au
FROM PAT P, RDV R, DOC D , RDV R1, DOC D1
WHERE P.NumPat = R1.NumPat and R1.NumDoc = D1.NumDoc and moins (n-1) prédicats de jointure (outre les prédicats
D1.NomDoc = “Dupont” and P.NumPat = R2.NumPat and de sélection).
R2.NumDoc = D2.NumDoc and D2.NomDoc = “Durand”);
RDV (R1) DOC (D1) Dupont
PAT (P)
RDV (R2) DOC (D2) Durand
175 176
Doublons Base de tests

• Quand une requête est vraiment complexe, on peut,
• Deux types de doublons peuvent apparaître. malgré tout, avoir un doute sur la solution trouvée.
– plusieurs réponses sont identiques Dans ce cas, il faut créer l’extension d’une base de test
– plusieurs réponses sont ‘sémantiquement équivalents’ afin de vérifier la validité de la requête.
• Les premiers s’éliminent en utilisant la clause • Preuve par l’exemple :
distinct. Attention toutefois à son utilisation... – un résultat positif ne prouve rien (c’est probablement juste...)
• Le deuxième cas se produit lorsque l’on demande – un résultat négatif prouve que la requête est fausse.
des combinaisons (couples de personnes, ensemble • Comment trouver l’extension la plus ‘sensible’ possible ?
de 3 pièces etc...). Le résultat (A,B) est – c’est à dire, l’extension de taille minimum comportant tous les cas et
‘sémantiquement équivalent’ à (B,A). garantissant la validité de la requête.
– Le problème est presque aussi complexe que la résolution de la
• Dans ce cas, il suffit d’utiliser un prédicat > entre requête elle même. Parcontre, le fait d’aborder la requête de cette
chaque composantes afin de n’obtenir qu’une seule manière permet souvent de mieux la comprendre.
des combinaisons equivalentes.
177
Base de tests (2)

• Exemple 1 : Quels couples de parents ont au moins deux
enfants?
– Dans la base de test il faut avoir :
• des couples de parents qui ont 1, 2 et 3 enfants
• des parents seuls ayant 2 et 3 enfants
• Optimisation de requêtes
• Exemple 2 : Quels producteurs ne voient que les films
qu’ils produisent ? • Transactions
– Dans la base de test il faut avoir :
• un producteur qui ne voit aucun film
• un producteur qui ne voit que des films qu’il produit
• Sécurité des bases de données,
• un producteur qui voit des films qu’il produit et d’autres
• Attention, cette base n’est pas suffisante....
droits d’accès
1. Optimisation Le problème : équivalence sémantique
• Une question
Select
• Plusieurs expressions
From équivalentes en SQL
Where • Plusieurs expressions
équivalentes en algèbre
• Plusieurs algorithmes
algébriques équivalents
Requête SQL Arbre logique Arbre
Coût
Physique
Optimisation Ex. 9 jointures 17 Milliards de plans…
Plans sémantiquement équivalents

179 180
Objectifs de l’optimisation Indexation (principe et B+Tree)
• Qui optimise ? • Objectif : accès rapide à partir d’une clé

• Idéalement, 2 requêtes équivalentes même plan, le meilleur ! • Moyen : ajout de structures de données (généralement hiérarchiques)
Les concepteurs de SGBD doivent maîtriser l’optimisation • Exemple : B+Tree
• Pratiquement, 2 requêtes équivalentes plans différents Jean
l’utilisateur (concepteur de l’appli) doit comprendre !!!
Sophie
Martin
Felix
Alon
• Objectif de l’optimiseur : trouver le meilleur plan …
• Donnant les résultats le + vite …. Adam Ben Gil Karine Nicole Théo
• Optimisation pour le temps de réponse (response time) Alain Claire Hilda Martin Paul Tom
Felix Jean Sophie Zoe
• Minimisant la consommation de ressources
• Optimisation du travail total (Total work)
• Minimisant le temps de délivrance des premiers tuples • Attention :
• Optimisation de la latence (Latency / First tuples …) • Surcoût lors des mises à jour !
• Des fois un accès par index est plus coûteux !
181 182
Importance du Schéma Physique Plan d’exécution optimisé
• L'utilisation d'index Select Patients.Nom, Patients.Prénom
π
From Patients, Visites
• accélère l'exécution des sélections et des jointures Where Patients.Id-P = Visites.Id-P
and Patients.Ville = ’Paris’
π
• ralentit l'exécution des mises à jour et des insertions
and Visites.Date = ’15 juin’
• 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
Patients Visites Patients Visites
183 184
Optimisation Physique … Algorithmes de jointure
π
• Nested loop Join : Jointures par boucle imbriquées
• Pour chaque visite, parcourir les patients
Jointure
• Index Join : Utilisation d’index sur une des relations
• Nested Loop Join ?
• Pour chaque visite, retrouver le patient grâce à l’index
• Index Join ?
• Hash Join ?
• Sort Merge Join
π π
• 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’)
σ σ
Sélection
• FTS (Full Table Scan) ? • Hash Join
• Index Scan (B+tree) ? • Hacher les patients sur le N° de patient
• Index Scan (Bitmap) ? • Pour chaque visite, calculer la valeur de hachage et chercher
dans la table de hachage le patient correspondant
Patients Visites
185 186
Optimisation heuristique Optimisation basée coût
• Optimisation indépendante des données • Dépend des caractéristiques des données

• Heuristiques classiques: • Présent dans Oracle (Cost Based Optimizer ou CBO)
• Effectuer les sélections en premier • Plus efficace que le RBO !
• Ajouter un maximum de projections
• Utiliser les indexs disponibles Graphe d'opérations Schéma interne
• Utiliser les ‘meilleurs’ algorithmes de jointure Plans d'exécution

(espace de recherche)
1. Hash join
Bibliothèque de
2. Sort merge join Générateur de
transformations
Plans
3. Nested Loop join avec index
Statégie de Heuristiques
4. Nested loop join Recherche
de choix
• L’ordre des opérations dépends de l’expression SQL Modèle de coût
• Présent dans Oracle (Rule Based Optimizer ou RBO)

Plan d'exécution
Optimal
187 188
Difficultés de l’optimisation basée coût Les statistiques
• Espace de recherche (plans candidats) • Possibilité d’histogrammes

• Plusieurs algorithmes pour chaque opérateur • RunStat(<Table>, <attribut>) construction et stockage d’un
• Coûts et comportement différents histogramme de variation de l’attribut dans la table.
• Plusieurs ordonnancement pour les opérations binaires • Utilisation par le modèle de coût
• Sans considérer les algorithmes, il y a 1620 ordres possibles • Sinon, hypothèse d ’uniformité
pour joindre 5 relations, et 17 milliards pour 10 relations !
• Exemple :
Utilisation d’heuristiques et de programmation dynamique
• Personnes ayant un salaire entre 2K€ et 4 K€ ? 20%
• Modèle de coût (choix du plan) • Personnes ayant 2 véhicules ? 15%
• Difficulté pour estimer le coût de chaque opérateur • Personnes ayant 2 véhicules et un salaire entre 2 et K4 K€? 3% ? Non !
• Difficulté encore plus importantes pour estimer la taille des résultats En fait, 14%
intermédiaires (permettant de calculer l’opérateur suivant)
• Propagation exponentielle des erreurs (dans l’arbre d’exécution) ! 15%
Utilisation de statistiques re-calculés fréquemment. 20%
0 0.5 1 1.5 2.0 2.5 3.0 3.5 4 0 1 2 3 4

189 190
Qualité de l’optimisation Réglage du SGBD – Database Tuning
• Réglages du SGBD, amélioration des performances

1. Qualité du schéma physique
• Manuel par l’administrateur BD
• Indexs
• par des outils externes de diagnostiques
• Partitionnement, placement
• par des outils intégrés automatiques ex. Oracle, SQL Server
• 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 !
191 192
Oracle : Automatic SQL Tuning Database Tunning Advisor (SQL Server 2005)
• Les entrées Base de données

Charge de travail
• Ensemble de BD d’un serveur Dispositifs à régler
• Une charge de travail à optimiser Contraintes
• Propriétés/Dispositifs à régler
DTA
• Les différentes contraintes
• Configuration partielle (du DBA) Conception physique
• Contrainte de stockage recommandée
• Contrainte de temps
Automatic Tuning Optimizer
Analyse des
Statistiques
SQL Profiling Analyse des
chemins d’accès
Analyse des
structures SQL
• La sortie
• Schéma physique recommandé + index et vues matérialisées
• Recommandation partitionnement des tables, vues, index…
193 194
Conclusion sur l’optimisation
• Mécanismes puissant mais complexes à maîtriser 2. Gestion de transactions

• 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.
195
2. Gestion de transactions Les propriétés ACID
• Problèmes liés aux transactions :

Incohérence possible...
Etat cohérent Etat cohérent • Concurrence d’accès
• Violation de la cohérence
Begin Commit • Pannes
BD
Transaction • de transaction : ex. annulation
• du système : ex. crash serveur
• de media : ex. perte du disque
Séquence d'instructions d’un programme de base de données
• de communication : ex. défaillance réseau
encadrée par un ordre de début et de fin de transaction faisant
passer la base d’un état cohérent à un état cohérent.
• Un SGBD garantit l'exécution ACID de toute transaction :
Begin • Atomicité : la transaction s'exécute en tout ou rien
CEpargne = CEpargne - 3000 • Cohérence : la transaction respecte les contraintes d'intégrité
CCourant = CCourant + 3000 • Isolation : la transaction ne "voit pas" l'effet des autres transactions
Commit T1 • Durabilité : les effets d'une transaction validée persistent
197 198
Atomicité / Durabilité Isolation : définition du problème

ATOMICITE DURABILITE • Scénario 1 :
Panne • Joe consulte son compte (lectures) au même moment où sa banque le
Begin Begin crédite de 500 euros (écritures)
CEpargne = CEpargne - 3000 CEpargne = CEpargne - 3000 • Scénario 2 :
CCourant = CCourant + 3000 CCourant = CCourant + 3000 • Joe retire 200 euros (écritures) au même moment où sa banque le
Commit T1 Commit T1 crédite de 500 euros (écritures)
Crash disque • Scénario 3 :
S’assurer que le virement • Une analyse des ventes (lectures) est faite dans un supermarché alors
Annuler le débit !! que les caisses sont ouvertes (écritures)
a été reporté dans la BD !
• Scénario 4 :
• Les places de la finale de la coupe du monde sont mises en vente sur
Gestion d’un journal avant Gestion d’un journal après Internet le lundi à 8h (conflits massifs)
• Scénario 5 :
• images physiques avant • images physiques après
• Réservation SNCF (lectures (choix) puis écritures (achat))
modification modification
• permet de ‘défaire’ une • permet de ‘refaire’ une • Objectif : Chacun doit travailler en isolation i.e. comme si il était
transaction n’ayant pas commise transaction qui a commise. seul utilisateur de la base de données
199 200
Exécution sans contrôle Protocole de Verrouillage à 2 Phases
verrous
• Absence de contrôle Scénario 2 – Perte d’opérations T
• Perte d’opérations
T1 (Joe) T2 (banque) Lecture Ecriture
• Observation d’incohérence Lecture
• Introduction d’incohérence Begin temps Ecriture
• Lectures non reproductibles Lire CC x
Begin
Lire CC x • Règle 1 : verrouillage
• Mécanisme de verrouillage x = x + 500 • Avant d'accèder à une donnée D, une transaction doit acquérir un
• Verrou en lecture : partagé
Ecrire X CC verrou sur D. Si D est déjà verrouillé dans un mode non
Commit T2 compatible, la transaction attend.
• Verrou en écriture : exclusif x = x –200
Ecrire X CC
• Règle 2 : deux phases
Commit T1 • Dès qu'une transaction relâche un verrou, elle ne peut plus acquérir
• Protocole de verrouillage ? de nouveau verrou
• Verrouillage 2 phases stricts
temps
• Les verrous sont gardés jusqu’au commit
201 202
Optimisation des transactions Degrés d'isolation SQL – normalisés SQL2
• L'objectif, en termes de performances, est de réduire : • Objectif: accroître le parallélisme en autorisant certaines
• les blocages : une transaction est bloquée en attente d’un verrou transactions à violer la règle d'isolation
• les inter-blocages : un ensemble de transactions s’attendent • Degrés standardisés SQL2 (Set Transaction Isolation Level)
mutuellement
• Degré 0 (Read Uncommitted)
T1 T2 • Lecture de données sales – Interdiction d’écrire.
• Ex. lecture sans verrouillage
• Degré 1 (Read Committed)
• Lecture de données propres – Ecritures autorisées
• Solutions existantes T3 T4 • Ex. Verrous court en lecture, long en écriture
• Degrés d’isolation
• Degré 2 (Repeatable Read)
• Protocoles multiversions • Pas de lecture non reproductible
• Modification des données / programmes • Ex. Verrous longs en lecture et en écriture
• Degré 3 (Serializable)
• Pas de requête non reproductible (fantôme)
203 204
Degrés d'isolation SQL : exemples Protocoles multiversions (Oracle)
T1(°0, Read uncommited) T2(°3,serializable) T1(°1, Read commited) T2(°3,serializable) • Objectif : faire cohabiter sans blocage des transactions
Begin Begin Begin Begin conflictuelles en les faisant travailler sur différentes
versions des données
Lit CC ( 100) Lit CC ( 100)
Lit CC ( 100) Lit CC ( 100)
Ecrire CC, CC+10 Ecrire CC, CC+10 T1(°1, Read commited) T2(°3,serializable) T1 (°3, serializable) T2(°3,serializable)
Lit CC ( 110) Lit CC ( bloque) Begin Begin Begin Begin
Ecrire CC, CC+20 Ecrire CC, CC+20 Lit CC ( 100)(V1) Lit CC ( 100)(V1)
Lit CC ( 130) Commit Lit CC ( 100)(v1) Lit CC ( 100)(v1)
Commit ( 130) Ecrire CC, CC+10 (V2) Ecrire CC, CC+10 (V2)
Lit CC ( 100)(V1) Lit CC ( 100)(V1)
Ecrire CC, CC+20 (V2) Ecrire CC, CC+20 (V2)
Commit Commit
T1(°2, Repeatable read) T2(°3,serializable) T1(°2, Repeatable read) T2(°3,serializable) Lit CC ( 130)(V2) Lit CC ( 100)(V1)
Begin
Begin Begin Select count(*) from Voit
T1 (°1 Read commited) T2(°3,serializable) T1 (°3, serializable) T2(°3,serializable)
Lit CC ( 100) where couleur="rouge"
Begin Begin Begin Begin
Lit CC ( 100) Begin
Lit CC ( 100)(V1) Lit CC ( 100)(V1)
Ecrire CC, CC+10 Insert into Voit
bloque Lit CC ( 100) (v1) Lit CC ( 100)(v1)
Lit CC ( 100) values (R4, "rouge")
Commit
Ecrire CC, CC-50 (V?) Ecrire CC, CC-50 (V?)
Lit CC ( 100) Select count(*) from Voit bloque bloque
Commit where couleur="rouge"
Commit Commit
Ecrire CC, CC+20 Commit
Eciture faite (CC = 80) Erreur !
205 206
Modifications des données / Programmes Conclusion sur le verrouillage
• Scénario 4 : Les places de la finale de la coupe du • Scénario 1 : Compte Joe : lecture / écriture
monde sont mises en vente sur Internet le lundi à 8h Multiversion + degré Repeatable read ou Read Commited
• Une seule donnée Trop de conflits • Scénario 2 : Compte Joe : écriture / écriture
• Exemple de solution : Conflit inévitable quelque soit la méthode
• Idée : partitionner le stade : • Scénario 3 : lectures massives / écritures (supermarché)
• Chaque utilisateur se connectant est Multiversion + degré Read Commited (peu de versions)
aléatoirement dirigé vers 1 des partitions. • Scénario 4 : écritures massives (coupe du monde)
• Le degré de parallélisme est multiplié par le
Partitionnement du stade
nombre de partitions.
• Scénario 5 : réservations SNCF (lectures puis écritures)
Phase de choix en multiversion – Read Commited
• Scénario 5 : Réservation SNCF (choix puis achat)
Phase d’achat en multiversion – Repeatable read
• Si verrouillage dès le début, beaucoup de conflits
• Sinon, risque de perdre la place convoitée
Il est donc particulièrement important de maîtriser les
• C’est le deuxième choix qui est implanté …
degrés d’isolations et les notions transactionnelles.
207 208
3. Sécurité des BD, Droits d'accès
• Objectif :
3. Sécurité des BD, Droits d'accès • protéger les données de la base contre des accès non autorisés
• Mécanismes simples et puissants
• Connexion restreinte aux usagers répertoriés (mot de passe)
• Privilèges d'accès aux objets de la base (relation, vue, etc.)
• Repose sur la sécurité de l’architecture (de bout en bout)
BD
Serveur
Utilisateur BD
Identification Sécurisation des communications Protection du Protection

Authentification (confidentialité, intégrité, non répudiation) serveur des fichiers
210
Besoins de confidentialité (1) ? Besoins de confidentialité (2) ?
• Mémorisation massive de données • Hébergement de données (DSP)

• Hébergement de site Web, sous-traitance de la gestion du système
• Systèmes d’information publics
d’information d’une PME, équipes virtuelles, dossiers personnels …
• BD personnelles
• caspio.com, quickbase.com, cyberworker.com, primadoctor.com …
• BD d’entreprises
• Nombreuses violations de chartes de privacité [AKS02]
• Acquisition transparente des données
• Web, objets intelligents • Vulnérabilité des serveurs d’entreprise
• Source CSI/FBI : coût des attaques BD ≈ $103 milliards/an, 45%
• Organisation des données des attaques sont internes
• L’analyse d’une collection d’informations insignifiantes peut • 21551 sites français piratés dans le musée ZATAZ (~70 / mois)
générer des résultats sensibles • (Source http://www.zataz.com/hacked/)
• Interconnexion croissante des bases de données

• Croisement possible des données
211 212
Besoins de confidentialité (3) ? Curious of someone life ?
• Indexation des bases de données

• "Google entre vie privée et secret défense" (source : confidentiel.net)
• Négligence
• Craquage d'un système bancaire US (mots de passe trop courts par
rapport au nb de comptes gérés)
• Consultation de la facture détaillée d’autrui (télécom brésil)
• Croisement de bases de données
• CAPPS-II (Computer Assisted Passenger Pre-Screening System) croise des
BD pour lutter contre le terrorisme
Ron Rivest : « La révolution digitale inverse les défauts : ce qui était

autrefois difficile à copier devient facile à dupliquer, ce qui était oublié
devient mémorisé à jamais et ce qui était privé devient public
213 21
4
Curious of someone life (2) ? Protection : Solution Oracle ?
• Oracle's 'Unbreakable' Boast Attracts Hackers

• Hack attempts on the company's website have increased to
30,000 per week.
• Some days after ….

• 'When they say their software is unbreakable, they're lying.'
-- Bruce Schneier
• U.K. security researcher David Litchfield revealed that a common
programming error -- a buffer overflow -- was present in Oracle's
application server
« The data within the report is compiled from thousands of different sources
that include government, property, and other public record repositories. » 21 216
5
T1 : Identification/authentification Attaques du mécanisme d’authentification
• Utilisateurs par défaut d’une base de données

BD • Possibilité d’attaques contre ces comptes s’ils n’ont pas été
reconfigurés
• Exemple : utilisateur SCOTT (mot de passe TIGER) sous ORACLE
Utilisateur Serveur
BD
• Gestion des mots de passe
• Distribution du mot de passe lors de la création du compte
• Transmission du mot de passe entre le client et le serveur
• Base : login + password • Administrateur malveillant
• Assuré par le SGBD ou l’OS
• Nombreux protocoles et systèmes matériels (carte à puce!) • Pour limiter ces risques, possibilité d’utiliser SSL
Nécessaire mais clairement insuffisant !! • Secure Sockets Layer
• Gestion de certificats via un tiers de confiance
• Authentification mutuelle via le protocole Kerberos
217 218
T2 : Chiffrement des communications T3 : Mécanismes de contrôle d’accès
BD BD
Utilisateur Serveur Utilisateur Serveur

BD BD
• Technologie éprouvée (ex: SSL) • Contrôle d’accès très sophistiqué dans les SGBD
• Assure la confidentialité des messages • Autorisations affectées à des utilisateurs, groupes ou rôles
• Techniques cryptographiques complémentaires • Peut porter sur des objets d’une granularité très variée : tables,
vues,
• Hachage unidirectionnel (ex: SHA) : intégrité des messages
procédures stockées …
• Signature (ex: via PKI) : authentification et non répudiation du
message • Ne résiste pas à une attaque sur les fichiers du serveur
ou à une attaque du DBA !
• Nécessaire mais clairement insuffisant !! • Nécessaire mais insuffisant !!
219 220
Droits d'accès : Syntaxe de base et rôles Droits d'accès : droits sur les vues
• Syntaxe de base Employés Public

• Grant <droits> on <objet> to (<usager>*) [with grant option]
• Revoke <droits> on <objet> from (<usager>*)
Id-E Nom Prénom Poste
• <droits> ::= all | select | insert | delete |update | alter 1 Ricks Jim 5485
• <objet> ::= relation | vue | procedure 2 Trock Jack 1254

Nombre Masse
3 Lerich Zoe 5489
• <usager> ::= public | nom d'usager d’employés Salariale
4 Doe Joe 4049 4 890
• Rôles (SQL3):
• Create role <nom_role> : Création d’un nouveau rôle
• Drop role <nom_role> : Suppression d’un rôle
Id-E Nom Prénom Poste Adresse Ville Salaire
• Les instructions Grant et Revoke s’appliquent sur des rôles Service des 1 Ricks Jim 5485 ………. Paris 230
• Grant <liste roles> to (<usager>*) : Affectation de rôles aux usagers ressources 2 Trock Jack 1254 ………. Versailles 120
• Set role <liste_roles> : Activation de rôle(s) pendant une session humaines

3 Lerich Zoe 5489 ………. Chartres 380
4 Doe Joe 4049 ………. Paris 160
221 222
Droits d'accès : droits évolués Droits d'accès : exemple
• Règles indépendantes du contenu : Le médecin a accès aux dossier de ses patients

• Ex. la secrétaire a accès aux infos administratives
• grant ou revoke sur relation ou vue • Définition d ’une vue
Create view dossier_patient_du_medecin as
• Règles dépendantes du contenu :
Select * From dossier_patient
• Ex. Le médecin a accès aux dossier de ses patients
Where dossier_patient.medecin_traitant = CURRENT_USER ;
• Utilisation de vues paramétrées (e.g. avec Current_User)
• Règles dépendantes du contexte : • Création du rôle médecin :
• Ex. en l’absence du médecin traitant, tout médecin a accès au Create role medecin
dossier du patient
• Utilisation de vues paramétrées avec tables contextuelles • Affectation du rôle aux médecins :
• Ex. Les salaires ne peuvent être modifié que le 1er du mois Grant medecin to jean, jeanne
• Utilisation de procédures stockées • Affectation des droits au rôle médecin
Grant all on dossier_patient_du_medecin to medecin
223 224
Confidentialité via les vues Bases de données privées virtuelles (VPD)
Principe : Restreindre l'accès à la BD en distribuant Principe : Rajouter des conditions aux requêtes
es droits via des vues : utilisateur
Requête Q Requête Q
sur des vues
OK
Résultat Résultat
Vérification
des droits
OK Contexte
Requête Q’
Gestionnaire Requête Q’ Exécution Complétée en
de Vues sur les relations de procédure fonction du
de base contexte
Définition des Procédure de
Vues rajout de
+ condition
Droits Exécution de Exécution de
associés requête requête
225 226
Confidentialité dans les SGBDR (bilan) T4 : Chiffrement de la BD
• Via des vues

• les vues portent en général sur des données non autorisées
• Les vues peuvent inclures des variables (ex.CURRENT_USER) BD
• Base de donnée privée virtuelle

• Illusion d'une base de donnée privée Utilisateur Serveur
BD
• Complexe à mettre en œuvre.
• Via des procédures stockées
• Principe : chiffrer l’empreinte disque de la BD
• droits sur les procédures, pas de droits sur les données
• Complète les mécanismes à bases de vues • Seule solution pour résister aux attaques sur les fichiers
• Prise en compte d'éléments contextuels ( heure, utilisateur, etc.) Oracle Obfuscation Toolkit
Protegrity Secure.Data
Supposent que l'utilisateur passe "par la porte d'entrée" ! • Oracle, Informix, Sybase, SQL Server, IBM DB2
Proposition d’IBM (recherche – même principe que Protegrity)
227 228
Oracle Obfuscation Toolkit Protegrity Secure.Data
BD
• Fourniture d’un « package » permettant le chiffrement /
déchiffrement de données SGBD
Utilisateur +
Secure Clés
• Problèmes : Server Utilisateurs
Privilèges
• Gestion et partage de clés à la charge de l’application Secure
• Solution basée sur 2 modules :
• Système non résistant à un pirate administrateur Manager
• Secure.Manager : gestion des utilisateurs, droits et clés
• Les packages peuvent être substitués,
• Secure.Server : module de chiffrement intégré au noyau SGBD
• Les données apparaissent en clair lors de l’exécution des
• … et 2 personnes physiques différentes …
requêtes
• Database Administrator (DBA) / Security Administrator (SA)
• ORACLE : « DBA has all privileges » !! • Isolation DBA/SA ?

• Données toujours en clair à un moment de l’exécution
229 230
Conclusion : Sécurisation de bout en bout !

• Attaques sur l’authentification • Cryptographic tools and protocols
• Ex. Scott Tiger (Oracle), Phisching, mot de passes faibles
Authentification forte, basée sur du matériel Basic primitives
• Attaques sur les communications – Encryption
• Ex. écoute, interception, altération, rejeu
Utilisation de SSL recommandé – Cryptographic hash
• Attaques du serveur Combining cryptographic primitives (correctly)
• Ex. Intrusion, craquage de mot de passe
Détection d’intrusion, firewalls, etc.
• Fiabilité des logiciels
• Ex. Listener Service, injection SQL, Oracle Unbreakable
Utilisation/configuration correcte, Mises à jour régulière
• Attaque sur les fichiers
BD
• Chiffrement (ex. Protegrity, Oracle Obfuscation toolkit)
231 23
2
Cryptography: the characters Passive attacks Active attacks
Charlie has access to Charlie modifies the

unauthorized data transmitted data
Alice: (A) Bob: (B)

She wants to communicate with Bob! He wants to communicate with Alice!
ALICE BOB ALICE BOB
MARVIN MARVIN
Marvin: (M) Trent: (T)

Marvin is Malicious Trent is Trusted
23 23
3 4
Passive and active attacks Symmetric encryption

• Passive attacks: threaten confidentiality
• Sender and receiver share a secret allowing symmetric
• Active attacks: threaten integrity encryption and decryption
Identity theft
– Marvin sends a message to Bob with Alice IDs
Data alteration
– Marvin modifies the content of Alice message
Message forging Shared secret
– Marvin forges a fake message for Bob or Alice
Replay attack
Decryption
Encryption
– Marvin captures a message and sent it to Bob several times
Repudiation
– Alice sends a message to Bob and denies having sent this message
m c c m
ALICE BOB
Destruction
– Marvin destroys selectively some messages sent to Bob
Delays / reordering
– Marvin introduces communication delays or reorders messages
MARVIN
23 23
5 6
Kerckhoffs' principle
In 1883, the most famous work by Auguste Kerckhoffs was
published: La Cryptographie Militaire (military cryptography).
This book set forth desiderata for encryption systems…
The encryption system must not be required to be

secret, and it must be able to fall into the hands
of the enemy without inconvenience;
The system must be practically, if not

mathematically, indecipherable;
23 23
7 8
Symmetric encryption: Secret key encryption Attacking a symmetric cipher

• All the details of the system, including the encryption and
decryption functions are known, except the key
• Security is only based on the secrecy of the key K
• The attacker knows the ciphertext c
Shared secret: Find the plaintext m, or better the key K
key K
• The attacker knows couples plaintext/ciphertext (m, c)
Encryption
Decryption
Find the key K, or at least be able to decrypt other messages

m c c m
ALICE BOB
c = EK(m) m = DK(c)
= DK(EK(m))
MARVIN
23 24
9 0
Attacking a symmetric cipher (2) Attacking an simple alphabetic substitution
• Example : • Assume a random alphabetic substitution such as
Caesar cipher (used for military purposes by
Julius Caesar)
Plaintext: attackatonce
Ciphertext: exxegoexsrgi
Very easy to attack !
• Can we easily retrieve the
key (i.e., the table) knowing
a ciphertext ?
• Given the small number of possible
shifts (26), the key can be found in 13
operations, in average… (NB: French message)
The problem here is the size of the key!

(less than 5 bits !)
24 24
1 2
(1) Frequency analysis: a single letter (2) Frequency analysis: bigrams

In the cipher text In the cipher text
In French In French
Letter frequency in French In the cipher text
In French
Conclusion
24 24
3 4
(3) Using some common words (4) and more common words…
soulent L V
dommes D H
ehuipage H Q
aleatros E B
mompagnons M C
etc.
24 24
5 6
Finally ! Simple alphabetic substitution

The simple alphabetic substitution cipher is:
• Class of Cipher: Block cipher
The message is encrypted by blocks of fixed size (n bits)
• Mode of operation: ECB

Electronic Code Book
The message is split in n bits blocks, each encrypted separately
• Why the attack was so easy?

The algorithm is too weak?
The encryption key is too short?
The encryption block is too small?
Other reasons?
• Let’s check stronger algorithms

24 24
7 8
Some symmetric block ciphers Attacks on DES, 3DES and AES
• DES • DES
Data Encryption Standard (1976 - 1997) 1997: 39 days on 10 000 Pentium
Encrypts 64 bits blocks 1998: Deep Crack breaks a DES key in 56 hours (250 000 US$)
Encryption and Decryption are the same algorithms 2007: 6.4 days on a $10,000 parallel machine
The encryption key is 56 bits
• 3DES
• 3DES The best attack known on 3-key 3DES requires around 232 known plaintexts,
Used as a replacement for DES between 1997 and 2001 2113 steps, 290 single DES encryptions, and 288 memory !!
Uses three 56 bits keys 3DES is computationally secure (now)
tripleDES(k1k2k3, M) = DES(k3,DES(k2,DES(k1,M)))
• AES
• RIJNDAEL (AES) Only Side Channel Attacks were successful on AES
Used since 2001 and Encryption standard since 2002 See http://www.cryptosystem.net/aes/ for more information
Authors: Joan Daemen and Vincent Rijmen Rijndael AES is computationally secure (now)
Winners of the AES competition
128 bits blocks with keys of 128, 192 or 256 bits Thus, can I use 3DES or AES without problems ?
Fast and requires little memory
24 25
9 0
Unconditional vs Computational security Triple DES encryption with ECB mode …

• Unconditional security • Can I use 3DES or AES
“the uncertainty in the plaintext, after observing the ciphertext, must be equal
to the a priori uncertainty about the plaintext – observation of the ciphertext without problems ?
provides no information whatsoever to an adversary” [Menezes]
The unique possible attack is exhaustive key search
To reach unconditional security, the secret key must be as long as the
plaintext ! [Shannon 49]
• Computational security
“A proposed technique is said to be computationally secure if the perceived
level of computation required to defeat it (using the best attack known)
exceeds, by a comfortable margin, the computational resources of the
hypothesized adversary.” [Menezes]
NO!
25 25
1 2
Encryption mode: Electronic Code Book-ECB Triple DES encryption with CBC mode …
• Can I use 3DES or AES

by tes without problems ?
0 8 16
Plain-text 1 (P1) Plain-text 2 (P2) …
EK (P1) EK (P2)
Cipher-text 1 (C1) Cipher-text 2 (C2) … • Yes, if I take care!
25 25
3 4
Cipher Block Chaining (CBC) Other modes of operations

• Several modes of operations exists, the adequate one
depends on the desired properties of the ciphertext
by tes Error propagation
0 8 16 Partial decryption
Etc.
Plain-text 1 (P1) Plain-text 2 (P2) …
Init. Vector (IV) • See [Menezes] pp 288
EK (IV ⊕ P1) EK (C1 ⊕ P2) EK (…) • Ex. The counter mode by tes
0 8 16
Cipher-text 1 (C1) Cipher-text 2 (C2) … 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) …

25 25
5 6
Asymmetric (Public key) encryption Secret Key vs Public/Private keys
• Each user has
a public key, publicly available on a directory,
a private key kept secret
• No need for a shared secret
Public key Private key • Alice & Bob have the key • Alice uses the public key (Bob’s
KPub (bob) KPriv (bob) address) to send a message to Bob
• Alice use the key to deposit a
message into the safe • Bobs uses his private key (the
Encryption
Decryption
mailbox key) to retrieve the message
• Bob use the key to retrieve the
m c c m message from the safe
ALICE BOB
Only Alice & Bob can exchange Anyone can send a message to Bob
messages (his address being public)
c = EKPub(m) m = DKPriv(c)
Only Bob can retrieve the messages
= DKPriv(EKPub(m))
MARVIN 25 25
7 8
The RSA asymmetric cipher [Rivest - Shamir - Adleman 78] Hybrid encryption
• Security: difficulty of factoring large numbers • Combines the advantages of both encryption methods
Performance (symmetric)
• Algorithm No shared secret (asymmetric) – anyone can send a message to Bob !
Pick two large random primes p and q
Let N = p × q Public key Private key
Pick a large integer d relatively prime to (p-1)×(q-1) KPub (bob) KPriv (bob)
Find the integer e such that e*d = 1 (mod (p-1)×(q-1))
(Public) Encryption key is (e, N): C = M e (mod N)
Decryption key is (d, N): M = C d (mod N) – d must be kept secret!
RSA
RSA
• Performance Ks K’ s K’ s Ks
Much slower than symmetric algorithm
AES
AES
– (2-3 orders of magnitude)
Generally combined with symmetric algorithms
ALICE m c c m BOB
• Recommended key size: 1024 bits
25 MARVIN 26
9 0
Cryptographic hash functions Cryptographic hash functions (2)
• Goal: ensure data integrity

• Examples:
Message Digest 5 (MD5) [Riv92]
potentially combined with encryption (see after)
Secure Hash Algorithm 1 (SHA-1) [NIS95]
• A hash function h must satisfy the following properties • Process the input message by blocks of 512 bits
maps an input x of arbitrary bit length, to an output h(x) of fixed bit length n.
h(x) must be easy to compute • The result of the hash function is
160 bits for SHA-1
• A hash function h is a cryptographic hash functions if it
128 bits for MD5
satisfies (some of) the following properties
preimage resistance: given a hash value h, it is computationally infeasible • Security: SHA-1
to find any x, such that h(x) = h Find a 2nd preimage requires 2160 operations
2nd preimage resistance: given x and h, such that h(x) = h, it is Find a collision requires 280 operations
computationally infeasible to find any second input y, such that h(y)=h(x)=h
collision resistance: it is computationally infeasible to find any two distinct • Hash functions are publicly known
inputs x and y such that h(x) = h(y)
• Keyed hash functions also exist
• Thus, a cryptographic hash function h ensures that any bit (hash function taking as a parameter a cryptographic key)
change in the input will impact the output. 26 26
1 2
Combining cryptographic primitives (1) Confidentiality: Encryption alone

• Goal: Resist to passive and active attacks • Ensures confidentiality – remind that
Symmetric encryption is efficient but needs a shared secret
• Passive attacks : threaten Confidentiality 1 Asymmetric encryption is slow but does not need a shared secret
need for a PKI however (Public Key Infrastructure)
• Active attacks: threaten Integrity Combining symmetric and asymmetric is a good option
5
Both must be carefully used
Identity theft
4
– Mode of operation: ECB should not be used for messages with repetitive
Data alteration
patterns (frequency analysis)
Message forging 3
– Only use known algorithms
Replay attack 2
Repudiation 6
Destruction 2 • Encryption does not ensure integrity
Delays / reordering 2 This is a common mistake (even encrypted data can be (randomly) altered)
Unless used in a very specific way
• Approach followed – e.g., encrypting blocks with high redundancy to ensure integrity
Describe basic constructs and their rationale (e.g., a 128 bits block storing 64 bits of data, replicated)
Do not describe complete protocols (too boring) book ch. 26, wikipedia… – This may lower the algorithm resistance to attacks
26 26
3 4
(2) Replay Attack (3) Message forging: Nonce
• Problem: • Problem:
Marvin copies the message and resends it to Bob Alice and Bob share a session key, K
Alice sends a message M1 to Bob and gets M2 back.
• Solution: How can Alice be sure that M2 came from Bob and not from Marvin ?
Includes a unique timestamp (or sequence number) in the message.
The receiver keeps timestamps of recently received messages • Marvin might:
He does not accept a duplicate send a random string that Alice decrypts (using K) to another random string
that looks like a correct response
• Remark: replay an earlier message sent by Bob encrypted with K, that is a possible
Obviously, the timestamp integrity must be preserved (see point 4) response (Alice is not a server that maintains a list of timestamps)
• Remark (2): • Solution: Include a nonce, N, in M1

Using sequence number may protect from reordering/destruction attacks. A random string generated by Alice
Long enough so that Marvin cannot guess it
If M2 contains N+1 then it can only have been generated by Bob (since only
Bob knows K) and it cannot be a replay
26 26
5 6
(4) Data alteration + Confidentiality (5) Identity theft: Authentication-1

m m m m • Is asymmetric encryption sufficient to ensure authentication ?
Alice and Bob have no shared secret but want to establish a secured
Hash Encrypt Hash Encrypt Encrypt communication.
They exchange their public keys and a session key encrypted with Alice
m || h c || h c c public key
≈
Hash Hash Hi, Bob, I am Alice, here is my Public key, could you
Encrypt 1 send me yours such that we can discuss securely ?
c || h h 2
Hi Alice, I am Bob, here is my Public key and a session
key encrypted with your Public Key
Encrypt ALICE 3 Fine, Bob, here is my secret message encrypted with BOB
the session key….
• Symmetric encryption assumed c || h’ 4 Etc…
• One construction is wrong • Is this protocol secure ?

• Others have different properties
26 26
7 8
(5) Authentication-2: attacking the simple protocol (5) Authentication-3: trusted party & public keys
• A “Man in the middle” attack can be conducted !!!
• Alice has been previously registered by Trent, showing identity proofs and has
sent her public key.
• She received in return, a certificate containing her public key, certified by Trent.
MARVIN
• Trent certificate is “well known” (certification hierarchy)
1 – Bobs asks Alice her certificate
ALICE BOB
2 – Alice sends her certificate to Bob, Bob checks its validity
Marvin intercepts Alice’s message and exchange her public key with a 3 – Bob sends Alice a session key encrypted with Alice public key TRENT
generated public key (Marvin knows the corresponding private key)
4 – Alice decrypts the session key and starts
Then, he intercepts Bob’s message, decrypt the session key, re-encrypt it
with Alice’s public key (kept from 1st message) and exchange Bob’s public communicating with Bob
key with another generated public key ion
t rat
Alice and Bob does not notice anything and Marvin intercepts all messages, SSL is based on this scheme Re
gis
can even create fake message ! (remark: Bob need not be registered)
• Need for a trusted party delivering
1
public keys (PKI)
2
or secret keys (e.g., Kerberos) 3
ALICE
4 BOB
26 27
9 0
(5) Authentication-4: trusted party & secret keys (5) Authentication-5: Secret vs Public
• Alice & Bob have been previously registered by Trent • Both need trusted third parties.
• During this registration, they exchanged a secret key only known by Trent/Alice
(TA) or Trent/Bob (TB)
1 - Alice contacts Trent, sending a nonce for a communication with Bob • Secret (Kerberos)
Distributes symmetric keys
2 - Trent sends the nonce and the session key, both encrypted with TA.
A ticket, including the session key encrypted TB key is also sent Operates on-line, when interaction takes place since it creates a new
symmetric key for each session
3 - Alice checks the nonce, decrypts the session key,
sends the Ticket to Bob TRENT
4 - Bob decrypts the Ticket, retrieve the • Public (SSL, Certification authority)
n 1
session key, and starts tio Distributes public keys (certificates)
tra
gis
communicating with Alice Re
Registration
Operates off-line, prior to interaction since public key is fixed

Once certificate created, intervention by CA no longer required
KERBEROS is based on this scheme
2
3
4
ALICE BOB
27 27
1 2
(6) repudiation: Digital Signature-1 (6) Digital signature-2: Signing
• Digital Signatures can be used for
Proof of authorship
Non-repudiation by author
Guarantee of message integrity
Does not guarantee confidentiality (orthogonal)
– If confidentiality is needed, encryption of the message must be used
• Important for many Internet applications

• Based on public key cryptography
Current systems use RSA algorithm
• Basic idea:
(1) Hash the message
(2) Encrypt the hashing with the sender private key
(3) Add to the message the sender public key and a certificate (for checking)
27 27
3 4
(6) Digital Overview of database specific tools

Signature-3:
Verifying
2-Protection of 3-Authorizations 8-Data
communications anonymization
MS r
DBerve Statistical use
S
Delivered data
User
6-Usage
control
5-Audit
4-Database
encryption
7-Limited data
1-Authentication retention
27 27
5 6
(1) Authentication, (2) Communications (3) Authorizations-1: Access control
• Authentication 3-Authorizations • Basically: Discretionary Access Control (DAC)
2-Protection of
communications
Basic: Login + Password Subject: Authenticated users/processes
MS r Objects: Database objects to be protected
OS authentication can be used by the DBMS DBerve
S
DBMSs support most authentication protocols (SW & HW) Actions: Actions that are authorized (e.g., read, update)
Attacks: default passwords (600 available on the web)
User
Problems: Indirect authentication:
• Basic syntax
GRANT <Actions> ON <object> TO <Subject>
– The user is authenticated by the Application
REVOKE <Actions> ON <object> FROM <Subject>
– The application is authenticated by the DBMS
• Communications
• Role Base Access Control (RBAC)
1-Authentication
Roles are recipient of authorizations
Use of classical protocols (e.g. SSL)
Roles are assigned to users
A lot of known attacks on the Oracle Listener Service….
• Objects
Tables
Views
Stored procedures
etc.
27 27
7 8
(3) Authorizations-2: Access control Example

• View : Virtual table defined by an SQL query
• The DBMS transforms queries on views in queries on base Create View Stats as
VIEW
Select service, count(*) Nbpatients, sum(expense) Total_Exp
tables From Patients
Group By service
Query on
views
QUERY
Select Total_Exp
From Stats
Where service = "immuno"
Access control
View manager
QUERY
FINAL
Select sum(expense) Total_Exp
Rewrite query From Patients
View Where service = "immuno"
definition on base tables
27 28
9 0
(3) Authorizations-3: Access control with views (3) Authorizations-4: Virtual Private Database
Employees Statistician
Id-E LName FName Fone

1 Ricks Jim 5485
2 Trock Jack 1254
Number of Average Query
3 Lerich Zoe 5489 employees Salary
4 Doe Joe 4049 4 225
Running the
procedure
Id-E LName FName Fone Address City Salary Contextual
Human 1 Ricks Jim 5485 ………. Paris 230 information
ressources 2 Trock Jack 1254 ………. Versailles 120
3 Lerich Zoe 5489 ………. Chartres 380 Procedure for Query with
4 Doe Joe 4049 ………. Paris 170 Adding added
conditions conditions
28 28
1 2
(4) Database encryption (5) Database auditing

• Use specific auditing features of your database system
• Use classical triggers for personalized audit
• Triggers: E-C-A rules
When the EVENT happens
On insertion, update or deletion of a tuple in a given table
If the CONDITION is fulfilled

Any kind of SQL predicate
Do the ACTION
Specific code to execute (SQL, PLSQL, other languages)
• Oracle Obfuscation toolkit • Triggers allow recording who has modified what and when
• Same kind of tools for other DBMSs
• Protegrity Secure-Data
28 28
3 4
(6) Usage control, (7) Limited Data retention (8) Data Anonymization: on-going works
• Access control / Usage control:
Access control defines the rules for accessing the data
Usage control regulates the usage of delivered data
Limited data retention is one example of usage control
Digital Right Managements is usage control
– You can access a video, watch it, but not redistribute it
• Limited data retention principle

Attach a lifetime to the data
Compliant with its acquisition purpose
After which it must be withdrawn from the system
Examples
– Google: Cookies kept 2 years instead of 30 as before (!)
– Ask and IxQuick keep user information for only two days.
28 28
5 6
Bibliography
[MPO] Alfred Menezes, Paul van Oorschot, Scott Vanstone: Handbook of
Applied Cryptography.
Available online: http://www.cacr.math.uwaterloo.ca/hac/
[Sch] Bruce Schneier: Applied Cryptography: Protocols, Algorithms, and
Source Code in C
[KBL] Kifer, Bernstein, Lewis : Database Systems, an application oriented
[SL98]
approach (chapter 26)
Stefan Lucks: Attacking Triple Encryption, Fast Software Encryption
Le dictionnaire de données Oracle
1998, pp 239–253.
[AKS02] Agrawal R., Kiernan J., Srikant R., Xu Y., “Hippocratic Databases”,
VLDB , 2002.
[FBI] Computer Security Institute, "CSI/FBI Computer Crime and Security
Survey" http://www.gocsi.com/forms /fbi/pdf.html).
[Ora] Oracle Unbreakable
http://www.techtv.com/news/securityalert/story/0,24195,3364291,00.html
[Mat] U. Mattsson, Secure.Data Functional Overview, Protegity Technical
Paper TWP-0011,. (http://www.protegrity.com/White_Papers.html)
[Orab] Oracle Corp., “Advanced Security Administrator Guide”
28 Support emprunté à L. Bouganim 288

7
Contenu du Dictionnaire Oracle Utilisation du dictionnaire
• Dictionnaire Oracle = tables systèmes en lecture seule • Accès avec SQL
• Evolution du dictionnaire
– Généré au moment de la création de la DB
• Utilisé par le DBA et les utilisateurs
– Mis à jour automatiquement – Consultation d’informations sur la structure de la BD
• Contient des informations sur la structure de la BD – Seulement des droits en lecture sur des vues du dictionnaire
– Utilisateurs (privilèges, rôles) – NB: seulement par des requêtes SELECT (lecture seule)
– Noms et caractéristiques des objets
(tables, vues, index, clusters, triggers, packages, ...)
– Contraintes d'intégrité • Utilisé par Oracle
– Ressources physiques allouées à la base – A la connexion et pendant l’exécution des requêtes
– Valeurs par défaut pour des colonnes • Consultation d’informations sur les utilisateurs et leurs privilèges
– Les autres informations générales sur la base des données
• Consultation d’informations sur les objets de la BD
• Structure – Lors des requêtes SQL DDL (Data Definition Language)
– Tables de base = tables fondamentales contenant les informations sur la BD • Modification du dictionnaire
• Conservées dans le tablespace SYSTEM
– Vues de ces tables = présentation dépendant du rôle de celui qui consulte… 289 290
Différentes vues Exemple

• La vue ALL_CONSTRAINTS
– Contraintes des tables accessibles à l’utilisateur
SQL> SELECT table_name, comments

> FROM dictionary
> WHERE table_name LIKE '%CONSTRAINTS%';
TABLE_NAME COMMENTS
----------------------------------------------------------------
ALL_CONSTRAINTS Constraint definitions on accessible tables
DBA_CONSTRAINTS Constraint definitions on all tables
USER_CONSTRAINTS Constraint definitions on user's own tables
3 rows selected.
• La vue ‘DICTIONARY’ permet d’accéder aux noms/desc. des vues DBA, ALL, USER, V$...
291 292
Les vues dynamiques V$ (1) Les vues dynamiques V$ (2)
• Vues dont les informations sont «dynamiques» • Ex. V$SGA
– Evoluent du démarrage de l’instance jusqu’à son arrêt
– Décrivent l’activité de la DB et de l’instance
– Informations sur la «System Global Area» (SGA)
– Sont appelées «dynamiques» mais SQL> SELECT * FROM V$SGA;
NAME VALUE
• en fait, elle externalise l’état de variables internes à Oracle -------------------- ---------
Fixed Size 49152
• Usage de ces données Variable Size
Database Buffers
12906496
2048000
– Principalement pour l’amélioration des performances de la BD Redo Buffers 73728
• Ex. V$Session
SQL> SELECT sid, serial#, username, type, status
> FROM v$session;
• V$LOGFILE : détail des fichiers redo-log
SID SERIAL# USERNAME TYPE STATUS
----- -------- ------------ ---------- ------- SQL> SELECT * FROM v$logfile;
1 1 BACKGROUND ACTIVE GROUP# STATUS MEMBER
… ------ ------ ------------------------------
8 6 HEURTEL USER INACTIVE 1 STALE E:\ORANT\DATABASE\LOG4ORCL.ORA
2 STALE E:\ORANT\DATABASE\LOG3ORCL.ORA
3 STALE E:\ORANT\DATABASE\LOG2ORCL.ORA
4 E:\ORANT\DATABASE\LOG1ORCL.ORA
– Le DBA peut déconnecter les utilisateurs avec la commande suivante
SQL> ALTER SYSTEM KILL SESSION ‘8,6’ ;
293 294
Quelques vues intéressantes (1) Quelques vues intéressantes (2)

• Instance Oracle • Structure physique
– V$DATABASE: Statut de la base de données – V$CONTROLFILE : Liste des fichiers de contrôle de votre BD
– V$INSTANCE: Détails sur l’instance – V$DATAFILE: Détail des fichiers de données de la BD
– V$PARAMETER: Paramètres d’initialisation de l’instance – V$TABLESPACE : Tablespaces de la base de données
– V$PROCESS: Processus lancés par l’instance et les utilisateurs
– V$SGASTAT: Détail de l’occupation mémoire de votre SGA • Utilisateurs et droits
– DBA_ROLE_PRIVS : Rôles reçus et donnés de la BD
– DBA_USERS : Informations concernant les utilisateurs
• Structure logique déclarés de la base de données
– DBA_EXTENTS : Description des Extents composant les
– V$SESSION : Détail de toutes les sessions actives de l’instance
Segments de la base de données
– DBA_FREE_SPACE : Extensions libres dans tous les Tablespaces • Objets du schéma
– DBA_SEGMENTS : Allocation d’espace disque de tous les – DBA_TABLES : Description des tables relationnelles de la BD
Segments de la base de données – DBA_INDEXES: Description de tous les index de la BD
– DBA_CLUSTERS: Description de tous les clusters de la BD
295 296

++master2 IRS Bases de Donnees Avancees PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

++master2 IRS Bases de Donnees Avancees PDF

Загружено:

Авторское право:

Доступные форматы

2

Luc Bouganim – Luc.Bouganim@inria.fr

Plan de la session (1) Plan de la session (2)

Problèmes des approches fichiers,

Plusieurs applications Caractéristiques

Plusieurs applications Plusieurs applications

Duhpon Duipont Duhpon Duipont

Symptomes : yy Symptomyyyy Symptomes : yy Symptomyyyy

Symptomes : yy Turlututudhjsd Symptomes : yy Turlututudhjsd

Plusieurs applications Plusieurs applications

Symptomes : yy Turlututudhjsd Symptomes : yy Turlututudhjsd

Partage de données Caractéristiques

Plusieurs applications Plusieurs applications

Redondance de code Redondance de code

• Modélisation des données

Centraliser et organiser correctement les données X - Standards II- Indépendance

VIII - Concurrence BD IV - Gestion des

- Interrogation, cohérence, partage, gestion de pannes, etc… VI - Gestion de la

• Dépendant du • Organisation physique des données

Méthode de conception ? Exemple de mauvaise conception (1)

Exemple de mauvaise conception (2) Méthodes de conception : Exemple Merise

N° Nom Prénom Ville Pays Enfant 1 Enfant2 Enfant3 NbEnfants

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

Approche proposée : orientée données Déf° (1) : entité / type d’entité

3/ Définir les questions nécessaires pour l’application (~MLT)

GENERATION AUTOMATIQUE POSSIBLE ! Entités Type d'entité

Déf° (2) : Propriétés / Identifiants Déf° (3) : association / type d’association

Exemple : Profs et cours...

Comment produire le MCD ? (1/3) Comment produire le MCD ? (2/3)

Patient a un rdv Médecin Exerce Salle

Patient a un rdv Médecin Exerce Salle

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

Où s'arrêter dans la modélisation? Règles (1) Respect des règles de gestion

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

Règles (4) : Propriétés sans signification Règles (5) : Identifiants d’entités

Règles (8) : pas de dépendance transitive Première modélisation ‘restreinte’

Modélisation ‘complète’ Modèle entité-association

• Une base de données pour l’Université (pour plusieurs années) 1,n

• Il définit l’ Algèbre Relationnelle sur laquelle est basé

Domaine Produit cartésien

Relation, attribut Exemple de relation

– Une ligne est un tuple 3 Masse Jean

Clé Clé Etrangère

Modélisation Relationnelle (2) Clés primaires

2 3 4 1 mars 250 …. …. …. ………… 2 3 4 1 mars 250 …. …. …. …………

Clés étrangères Schéma relationnel

2 3 4 1 mars 250 …. …. …. ………… • Médicaments (Id-M, Nom, Description)

Métabase Passage au niveau logique

Propriétés, Entités Exemple 1

• Règle 3 : Une association peut :

Nom Prénom Adresse NomCours Description

Passage au modèle relationnel - 63

Conclusion Le langage SQL – Partie 1

INTEGRATION AUX LANGAGES DE PROGRAMMATION

Création de table Exemple de création de table

Suppression (basique): DELETE Correction 1

4 4 87 1 ALTER TABLE MED

• INSERT INTO DOC VALUES (11, ‘Dupont’, ‘Paris’);

• Indépendance des programmes d'applications

II - Indépendance Logique Avantages de l’indépendance logique

• Possibilité d'intégrer des applications existantes sans

• Possibilité de limiter les conséquences du partage :

2 3 4 1 mars 250 …. …. …. …………