Rappels des concepts fondamentaux - smis inria

MASTER COSY 

Module 

Bases de Données Avancées 

Année 2013/2014 

P. Pucheral et L. Yeh 

Module Bases de données Avancées 

Rappels des concepts de base (et perspectives) 

Modèles de stockage et d’indexation 

Evaluation et optimisation de requêtes 

Modèles et protocoles transactionnels 

Support d’objets complexes 

XML Schema 

XQuery et optimisation 

Indexation XML 

Médiation XML 

Systèmes Pair-à-Pair 

1 

2 

Eléments de bibliographie (1 ère partie) 

• Présents à la bibliothèque UVSQ 

− Gardarin G., "Bases de données", Ed. Eyrolles, 5 ème édition, 2003. 

− 

− 

Ozsu, T., Valduriez P., “Principles of Distributed Database Systems”, Prentice-Hall, 

2nd edition, 1999. Nouvelle édition 2011 (Springer) 

J. Besancenot, M. Cart, J. Ferrié, R. Guerraoui, P. Pucheral, B. Traverson, "Les 

systèmes transactionnels : concepts, normes et produits", Ed. Hermès, 1997. 

• Disponible sur le Web 

− 

Fundamentals of Database Systems, 6th Ed, Elmasri and Navathe, Addison Wesley, 

2011 

Rappels des concepts 

fondamentaux 

1. Objectifs des SGBD 

2. Principales fonctions d’un SGBD 

3. Architecture fonctionnelle de référence 

4. Le modèle relationnel 

5. Le langage SQL 

6. Architectures physiques de SGBD 

7. Orientations de recherche 

3

Un système d’information sans SGBD (1) 

Un système d’information sans SGBD (2) 

ComptaSoft 

Dupont 

Symptomes : y 

Turlututu : sqj 

Symptomes : y 

Turlututu : sdd 

Analyses : xxx 

Comptabilité 

ConsultSoft 

Duhpon 

Symptomes : yy 

Analyses : xxxx 


Consultations 

Dupond 

Turlututusqjsk 

Symptom: yyyy 

Analyses xxxx 

Turlututudhjsd 

Analyses :xx 

Duipont 

Turlututu : sq 

Symptomyyyy 

Analysesxxxx 


ChiruSoft 

PsychiaSoft 

Chirurgie 

Psychiatrie 

Plusieurs applications 

plusieurs formats et langages 

difficulté de maintenance 

manque d’interopérabilité 

Redondance des données 

incohérence 

Pas de facilité d’interrogation 

toute question doit être prévue et 

programmée 

coût de développement élevé 

redondance de code 

difficulté d’évolution 

5 

ComptaSoft 

Dupont 

Symptomes : y 

Turlututu : sqj 

Symptomes : y 

Turlututu : sdd 

Analyses : xxx 

Comptabilité 

ConsultSoft 

Duhpon 


Analyses : xxxx 


Consultations 

Dupond 

Turlututusqjsk 

Symptom: yyyy 

Analyses xxxx 


Analyses :xx 

Duipont 

Turlututu : sq 

Symptomyyyy 

Analysesxxxx 


ChiruSoft 

PsychiaSoft 

Chirurgie 

Psychiatrie 

Gestion simpliste des droits 

violation de la confidentialité 

Gestion simpliste du 

parallélisme 

blocage du système ou bien 

incohérence en cas d ’accès simultanés 

Pas de tolérance aux fautes 

incohérence en cas de panne 

6 

L’approche Bases de données 

O1: Description canonique des données 

10 - Standards 

9 - Tolérance aux 

pannes 

8 - Concurrence 

d’accès 

1- Description 

canonique 

BD 

2- Indépendance 

Physique 

3- Indépendance 

Logique 

4 – Langage de 

manipulation 

Description cohérente, unique et centralisée des données 

manipulées par l’ensemble des applications constituant le 

système d’information. 

— Perception globale du système d'information 

=> augmentation du niveau d’informatisation 

=> nouveaux traitements (aide à la décision, analyse de données, …) 

— Factorisation de la description des données et de leur 

comportement (contraintes d’intégrité …) 

7 - Confidentialité 

des données 

6 - Intégrité des 

données 

5 - Optimisation de 

requêtes 

— Elimination de la redondance 

=> redondance coûteuse en place et source d’incohérence 

=> redondance système reste nécessaire pour : fiabilité, performance de 

consultation, disponibilité en environnement réparti ou mobile 

7 

8

Réel 

Modèle conceptuel 

O2: indépendance physique 

Indépendance des programmes d'applications vis à vis des 

structures de stockage des fichiers. 

Modèle 

conceptuel 

Modèle 

logique 

Modèle 

Physique 

•Indépendant du 

modèle de données 


SGBD 

•Dépendant du 



SGBD 



•Dépendant du SGBD 

Médecin effectue Visite 

Codasyl Relationnel Objet XML 

• Organisation physique des données 

• Structures de stockage des données 

• Structures accélératrices (index) 

9 

— Description logique des données, en termes d'entités et 

d’association, donnant une vision conceptuelle des 

données (séparation claire du monde réel et du monde 

informatique) 

— Possibilité de modifier les structures de stockage (fichiers, 

index, chemins d'accès, …) sans modifier les programmes; 

— Ecriture des applications par des non-spécialistes des 

fichiers et des structures de stockage; 

— Meilleure portabilité des applications et indépendance vis 

à vis du matériel. 

10 

Réel 

Modèle physique 

O3: indépendance logique 

Possibilité de modifier la structure conceptuelle globale de 

la base sans modifier les vues particulières de chaque 

groupe d'utilisateurs. 

Modèle 

conceptuel 

Modèle 

logique 




SGBD 




SGBD 

Médecin effectue Visite 

Codasyl Relationnel Objet XML 

— Chaque application ou groupe d'applications désire utiliser 

ses propres structures logiques de données en fonction de 

ses propres besoins; 

— Chaque application établit une description des données 

qu'elle utilise: 

• Les données décrites restent virtuelles (vues); 

Modèle 

Physique 



•Dépendant du SGBD 

• Organisation physique des données 

• Structures de stockage des données 

• Structures accélératrices (index) 

11 

• Le SGBD se charge de leur faire correspondre des 

données réelles. 

12

Id-D 

1 

2 

3 

… . 

Id-P 

1 

2 

3 

4 

… . 

D octeu r 

N om 

D upont 

D urand 

M asse 

… … .. 

Patients 

N om 

L ebeau 

T roger 

D oe 

Perry 

… … . 

P rénom 

Pierre 

Paul 

Jean 

… … 

P rénom 

Jacques 

Z oe 

John 

Paule 

… … . 

Id-D 

1 

1 

2 

2 

V isites 

Id-P 

2 

1 

2 

3 

Id-V 

1 

2 

3 

4 

D ate 

15 juin 

12 août 

13 juillet 

1 m ars 

Id-M 

1 

2 

3 

… . 

P rix 

250 

180 

350 

250 

Id-V 

1 

1 

2 

2 

2 

… . 

N om 

A spegic 1000 

Fluisédal 

M ucom yst 

… … .. 

Prescription 

L igne 

1 

2 

1 

2 

3 

… . 

M édicament 

Id-M 

12 

5 

8 

12 

3 

… . 

P osologie 

1 par jour 

10 gouttes 

2 par jour 

1 par jour 

2 gouttes 

… … … … 

D escription 

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

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

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

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

O3 – Exemples d’indépendance Logique 

Les applications peuvent définir des vues logiques de la BD 

Gestion des médicaments 

Cabinet du Dr. Masse 

Nombre_Médicaments 

Prescription 

Id -V 

Ligne 

Id -M 

Posologie 

Id-M Nom Description Nombre 

Visites 

1 

1 

12 

1 par jour 

Id -D 

Id -P 

Id -V 

Date 

Prix 

1 

2 

5 

10 gouttes 

1 Aspegic 1000 …………………………….. 30 

1 

2 

1 

15 juin 

250 

…. 

…. 

…. 

………… 

2 

3 

4 

1 mars 

250 

2 Fluisédal …………………………….. 20 

Patients 

3 Mucomyst …………………………….. 230 

Id -P 

Nom 

Prénom 

Médicament 

1 

Lebeau 

Jacques 

Id -M 

Nom 

Description 

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

2 

Troger 

Zoe 

1 

Aspegic 1000 

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

…. 

……. 

……. 

2 

Fluisédal 

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

3 

Mucomyst 

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

…. 

…….. 

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

O4: Langage de manipulation 

• Les non-informaticiens doivent pouvoir manipuler les 

données à partir de la seule connaissance du monde réel 

et de la modélisation qui en est faite 

• Mais les non-informaticiens font-ils des requêtes SQL ? 

• La manipulation se fait via un langage déclaratif 

• La question déclare l’objectif sans décrire la méthode 

• Le langage suit une norme commune à tous les SGBD 

• SQL : Structured Query Langage 

• Exemple de requête SQL 

Retrouver le nom et le n° de téléphone de tous les pédiatres 

13 

Select Nom, Tel 

From Docteur 

Where Specialite = ‘Pédiatre’ 

14 

O5: Optimisation de requêtes 

O6: Intégrité sémantique des données 

• Traduction automatique des requêtes déclaratives en 

programmes procéduraux (composition d’opérateurs 

élémentaires) 

• Optimisation automatique de ces programmes 

− 

− 

Exploitation des propriétés des opérateurs élémentaires 

Gestion centralisée des chemins d'accès (index, hachages, …) 

• Economie de l'astuce des programmeurs 

− 

milliers d'heures d'écriture et de maintenance de logiciels. 

• Course aux performances mesurées en transactions par 

seconde (TPS) sur des "benchmark" standardisés (TPC). 

15 

• Objectif : Détection automatique des mises à jour 

erronées 

• Contrôle sur les données élémentaires 

− 

Contrôle de types: Nom alphabétique 

− Contrôle de valeurs: Salaire mensuel entre 1 et 10k€ 

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

− 

− 

Relations entre données élémentaires : Prix de vente > Prix d'achat 

Relations entre objets : Un électeur est inscrit sur une seule liste 

électorale 

• Avantages 

− simplification du code des applications 

− sécurité renforcée par l'automatisation 

− mise en commun des contraintes 

16

O7: Confidentialité des données 

Confidentialité des données 

— Objectif : garantir la confidentialité de certaines 

informations et les protéger contre la dégradation 

− Dossier médical, procédé de fabrication, salaire des employés ... 

Service des 

ressources 

humaines 

Employés 

(intranet) 

Public 

(internet) 

— Plusieurs niveaux : 

− 

− 

− 

Authentification des usagers 

Privilèges d'accès aux objets de la base 

Chiffrement et hachage crytographique des données 

Id-E 

1 

2 

3 

4 

Nom 

Ricks 

Trock 

Lerich 

Doe 

Prénom 

Jim 

Jack 

Zoe 

Joe 

Poste 

5485 

1254 

5489 

4049 

Nombre 

d’employés 

4 

Masse 

Salariale 

890 

— Usagers : utilisateurs, rôles 

— Objets : objet réel ou virtuel, procédure ... 

Id-E 

1 

2 

3 

Nom 

Ricks 

Trock 

Lerich 

Prénom 

Jim 

Jack 

Zoe 

Poste 

5485 

1254 

5489 

Adresse 

………. 

………. 

………. 

Ville 

Paris 

Versailles 

Chartres 

Salaire 

230 

120 

380 

4 

Doe 

Joe 

4049 

………. 

Paris 

160 

17 

18 

O8: Accès concurrents aux données 

— Objectif : assurer l’Isolation des transaction, c.à.d que 

différentes applications partageant les mêmes données 

doivent pouvoir s'ignorer et travailler de manière 

asynchrone. 

— Le SGBD garantit la sérialisabilité des accès: l'effet d'une 

exécution simultanée de transactions doit être le même 

que celui d'une exécution séquentielle. 

< T1 || T2 …|| Tn > ≡ < T1; T2; … Tn > 

— Les transactions exécutées en parallèle ne doivent pas 

entrer en conflit lecture-écriture ou écriture-écriture, afin 

d’éviter : 

• des pertes de mises à jour 

• des introductions d’incohérence 

• des lectures non reproductibles 

19 

O9: Tolérance aux pannes 

— Le SGBD doit assurer la pérennité et la cohérence des 

données en présence de pannes multiples: 

− 

− 

− 

− 

Transaction Failure : Contraintes d'intégrité, Annulation 

System Failure : Panne de courant, Crash serveur … 

Media Failure : Perte du disque 

Communication Failure : Défaillance du réseau 

— Ceci implique l’Atomicité des transactions de mises à jour 

qui doivent être totalement exécutées ou pas du tout. 

— Ceci implique également des mécanismes de reprise 

assurant la Durabilité des effets des transactions validées. 

20

10 – Respect des standards 

3. Architecture de référence 

• L’approche bases de données est basée sur plusieurs 

standards 

− Langage de manipulation (SQL1, SQL2, SQL3) 

− Communication SQL CLI (ODBC / JDBC) 

− Transactions (X/Open DTP, OSI-TP) 

• Force des standards 

− Portabilité des applications 

− Interopérabilité des systèmes 

• De nombreuses architectures fonctionnelles ont été proposées 

• Ces architectures dépendent souvent du modèle de données 

utilisé 

• ANSI/X3/SPARC est une architecture de référence mais sa 

normalisation a échouée. 

• L'architecture ANSI/X3/SPARC repose sur un concept 

fondamental: la distinction de 3 niveaux de schémas 

21 

22 

Niveaux de schéma 

ANSI/X3/SPARC : principes 

Schéma Externe 1 

… 

Schéma Externe i 

… 

Schéma Externe n 

vision spécifique à une application 

Admin. 

BD 

Admin. 

Entreprise 

Processeur 

de schéma 

Conceptuel 

Admin. 

Application 

Construction 

de la BD 

SCHEMA CONCEPTUEL 

vision canonique globale exprimée en 

terme d'entités et d'associations 

Processeur 

de schéma 

Interne 

DICTIONNAIRE 

Processeur 

de schéma 

Externe 

SCHEMA INTERNE 

description physique des fichiers, des modes 

de stockage (séquentiel, trié, haché) et des 

index 

Transformateur 

Conceptuel 

Interne 

Système 

d’E/S 

Transformateur 

Externe 

Conceptuel 

Programme 

d’application 

Programmeur. 


Exploitation 

de la BD 

23 

Dictionnaire et Méta-base sont synonymes 

24

Architecture fonctionnelle d'un SGBD 

4. Le modèle relationnel 

META-BASE 

ANALYSEUR 

TRADUCTEUR 

OPTIMISEUR 

Analyse syntaxique 

Analyse sémantique 

Gestion des schémas 

Modification de requêtes 

Contrôle d'intégrité 

Contrôle d'autorisation 

Ordonnancement 

Optimisation 

Elaboration d'un plan 

• Concepts descriptifs 

– Domaine : caractérise un ensemble de valeurs 

– Relation : sous-ensemble du produit cartésien d'une 

liste de domaines 

– Tuple : ligne d'une relation 

– Attribut : colonne d'une relation 

EXECUTEUR 

Exécution du plan 

Méthodes d'accès 

Gestion de transactions 

• Exemple de relation (ou Table) 

Patients 

Attribut variant sur le domaine Ville 

Id-P Nom Prénom Ville 

1 Lebeau Jacques Paris 

BD 

Tuple 

2 Troger Zoe Evry 

3 Doe John Paris 

25 

4 Perry Paule Valenton 

…. ……. ……. ……. 

26 

Base de données relationnelle 

Clé, clé étrangère et schéma 

Docteurs 

Id-D Nom Prénom 

1 Dupont Pierre 

2 Durand Paul 

3 Masse Jean 

…. …….. …… 

Visites 

Id-D Id-P Id-V Date Prix 

1 2 1 15 juin 250 

1 1 2 12 août 180 

2 2 3 13 juillet 350 

2 3 4 1 mars 250 

Prescriptions 

Id-V Ligne Id-M Posologie 

1 1 12 1 par jour 

1 2 5 10 gouttes 

2 1 8 2 par jour 

2 2 12 1 par jour 

2 3 3 2 gouttes 

…. …. …. ………… 

• Clé : groupe d'attributs minimum qui détermine un tuple unique dans 

une relation 

PATIENTS (IdP, NOM, PRENOM, VILLE) 

• Clé étrangère : groupe d'attributs apparaissant comme clé dans un autre 

relation 

Patients 


Médicaments 

VISITES (IdV, IdD, IdP, DATE, PRIX) 




Id-M Nom Description 

1 Aspegic 1000 …………………………….. 

2 Fluisédal …………………………….. 

VISITES.IdD référence DOCTEURS.IdD 

VISITES.IdP référence PATIENTS.IdP 


3 Mucomyst …………………………….. 

…. ……. ……. ……. 

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

27 

28

Concepts manipulatoires 

Restriction 

• UN ENSEMBLE D'OPERATIONS DE BASE EST 

FORMALISE : L'ALGEBRE RELATIONNELLE 

• CES OPERATIONS PERMETTENT D'EXPRIMER 

TOUTES LES REQUETES SOUS FORME 

D'EXPRESSIONS ALGEBRIQUES 

Patients 






σ 

Patients 






• ELLES SONT LA BASE DU LANGAGE SQL 

Patients de la ville de Paris, noté en algèbre: 

σ Ville=‘Paris’ (Patients) 

29 

30 

Projection 

Jointure 

Patients 

Visites 

Patients 




π 


Patients 










Id-D Id-P Id-V Date Prix 

1 2 1 15 juin 250 

1 1 2 12 août 180 

2 2 3 13 juillet 350 

2 3 4 1 mars 250 



Id-P Nom Prénom Ville Id-D Id-P Id-V Date Prix 

1 Lebeau Jacques Paris 1 1 2 12 août 180 

Nom et prénom des patients, noté en algèbre: 

Π Nom, Prénom (Patients) 

2 Troger Zoe Evry 1 2 1 15 juin 250 

2 Troger Zoe Evry 2 2 3 13 juillet 350 

3 Doe John Paris 2 3 4 1 mars 250 

Notation algébrique: 

Patients Id-P=Id-P 

Visites 

31 

Au fait, qu’appelle-t-on Jointure externe gauche (Left-Outer-Join) ? 

32

Union, Intersection, Différence 

Exemple de plan d’exécution 

• Relation X Relation --> Relation (notées: ∪, ∩ , -) 

• OPERATIONS ENSEMBLISTES S'APPLIQUANT A DES 

RELATIONS DE MEME SCHEMA 

Select Patients.Nom, Patients.Prénom 

From Patients, Visites 

Where Patients.Id-P = Visites.Id-P 

π 

and 

Patients.Ville = ’Paris’ 

and Visites.Date = ’15 juin’ σ 

π 

σ 

π 

π 

σ 

Patients 

Visites 

• EXTENSION: Union externe (OUTER UNION) 

− 

− 

s'applique à des relations de schémas différents 

on ramène les deux relations au même schéma en ajoutant des valeurs 

nulles 

Patients 

Visites 

Optimisation 

33 

34 

5. Le langage SQL 

Le langage SQL (Structured Query Language) comprend trois 

parties : 

1. Le langage de définition de données (Tables, Vues, Droits, 

Intégrité) 

2. Le langage de manipulation de données (Sélections, 

Modifications, Insertions, Suppressions) 

3. L'intégration aux langages de programmation 

35 

Le standard SQL 

SQL est dérivé de l'algèbre relationnelle et de SEQUEL (SystemR 74). 

Le standard SQL évolue en permanence : 

- SQL1 86 version minimale 

- SQL1 89 addendum (intégrité) 

- SQL2 92 version étendue à trois niveaux de conformité 

(entry, intermediate, full) 

- SQL2 95 addendum (CLI : Call Level Interface) 

- SQL2 96 addendum (PSM : Persistent Stored Modules) 

- SQL3 extension aux objets complexes 

- SQL 99 contient les bases de SQL3 

- SQL 2006 intégration de XML 

36

EXEMPLE DE BASE DE DONNEES 

Création de table : syntaxe 

CREATE TABLE 

( * [*]) ; 

< def_colonne > ::= < type > [CONSTRAINT nom_contrainte < 

NOT NULL | 

UNIQUE | 

PRIMARY KEY | 

CHECK (condition) | 

REFERENCES nom_table (colonne) > ] 

< def_contrainte_table > ::= CONSTRAINT nom_contrainte < 

UNIQUE (liste_colonnes) | 

PRIMARY KEY (liste_colonnes) | 

CHECK (condition) | 

FOREIGN KEY (liste_colonnes) REFERENCES nom_table (liste_colonnes)> 

37 

38 

Création de table : exemple 

CREATE TABLE RDV( 

NumRdv Integer PRIMARY KEY, 

DateRDV Date, 

NumDoc Integer, 

NumPat Integer, 

Motif Varchar(200), 

CONSTRAINT Référence_DOC FOREIGN KEY (NumDoc) REFERENCES DOC 

(NumDoc), 

CONSTRAINT Référence_PAT FOREIGN KEY (NumPat) REFERENCES PAT 

(NumPat); 

L'association d'un nom à une contrainte est optionnelle. Ce nom peut être utilisé 

pour référencer la contrainte (ex: messages d'erreurs). 

Insertion de données 

• Syntaxe : 

INSERT INTO < nom_table > 

• Exemples : 

− 

− 

− 

[( attribute [,attribute] … )] 

{VALUES ( [, ] … ) | 

} ; 

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

INSERT INTO DOC (NumDoc, NomDoc) VALUES (2, ‘Toto’); 

INSERT INTO PAT (NumPat, NomPat, VillePat) 

SELECT NumDoc, NomDoc, VilleDoc FROM DOC; 

39 

40

Suppression de données 

Modification de données 

SYNTAXE : 

DELETE FROM 

[WHERE ] 

EXEMPLES : 

Supprimer tous les docteurs 

DELETE FROM DOC 

Supprimer le docteur numéro 20 

DELETE FROM DOC WHERE NumDoc = 20 

Et celle-ci ? 

DELETE FROM DOC WHERE NumDoc NOT IN (SELECT NumDoc FROM ORD) 

SYNTAXE : 

UPDATE 

SET 

= value_expression 

[, = value_expression ] … 

[WHERE ]; 

EXEMPLES : 

Modifier l’adresse du docteur nro 20 

UPDATE DOC 

SET VilleDoc = ‘Valenton’ 

WHERE NumDoc = 20 

Augmenter de 10% le prix de tous les médicaments dont le nom contient ‘Antibio’ 

UPDATE MED 

SET PRIX = PRIX*1.1 

WHERE NomMed = ‘%Antibio%’ 

41 

42 

Manipulation de données 

SELECT: forme générale 

SYNTAXE ELEMENTAIRE 

SELECT 

FROM 

WHERE 

SEMANTIQUE 

PROJECTION Ai ( 

RESTRICTION Ci ( 

PRODUIT ( Rj ) ) 

43 

SELECT [DISTINCT| ALL] { * | [, ]...} 

FROM relation [variable], relation [ variable]… 

[WHERE ] 

[GROUP BY [,]...] 

[HAVING ] 

[ORDER BY [.{ASC | DESC}] [,[.{ASC | DESC}] ]...] 

44

Forme de la condition de recherche 

Projections et restrictions simples 

::= [NOT] 

θ constante ⏐ 

LIKE 

IN 

θ (ALL ⏐ ANY ⏐ SOME) 

EXISTS 

UNIQUE 

MATCH [UNIQUE] 

BETWEEN constante AND constante 

AND ⏐ OR 

Liste des médicaments de plus de 50€ NomMed 

SELECT NomMed FROM MED WHERE Prix> 50 ; 

Liste des médicaments de plus de 50 € NomMed (prix stocké en FF) 

SELECT NomMed FROM MED WHERE Prix/6,55957 > 50 ; 

Nom des docteurs habitant ‘Florac’ NomDoc 

SELECT NomDoc FROM DOC WHERE VilleDoc = ‘Florac’ 

Liste des motifs des consultations du 25/12/2006 Motif sans doublons 

SELECT DISTINCT Motif FROM RDV WHERE DateRDV = ‘25/12/2006’ 

avec 

θ ::= < ⏐ = ⏐ > ⏐ ≥ ⏐≤ ⏐ 

Remarque: : peut être dynamiquement déterminée par une requête 

45 

46 

Restrictions complexes et jointures 

Requêtes imbriquées : IN et EXIST 

Liste des patients ayant un RDV avec le docteur ‘Dupont’ NomPat 

SELECT 

FROM 

WHERE 

PAT.NomPat 

PAT, RDV, DOC 

PAT.NumPat = RDV.NumPat and RDV.NumDoc = DOC.NumDoc 

and DOC.NomDoc like ‘Dupont’; 

Médicaments commençant par « ASPI » et prescrits en août 2008 NomMed 

SELECT 

FROM 

WHERE 

DISTINCT M.NomMed 

MED M, DET D, ORD O 

M.NumMed = D.NumMed and D.NumOrd = O.NumOrd 

and NomMed like ‘ASPI%’ 

and O.Date BETWEEN ’01/08/2008’ and ’31/08/2008’; 

Docteurs ayant le même nom qu’un patient NomDoc 

SELECT 

D.NomDoc FROM PAT P, DOC D WHERE P.NomPat = D.NomDoc; 

Liste des patients ayant un RDV avec le docteur ‘Dupont’ NomPat 

SELECT DISTINCT P.NomPat 

FROM PAT P, RDV R, DOC D 

WHERE P.NumPat = R.NumPat and R.NumDoc = D.NumDoc and D.NomDoc = ‘Dupont’; 

Et celle-ci ? 

SELECT P.NomPat FROM PAT P WHERE P.NumPat in 

(SELECT R.NumPat FROM RDV R WHERE R.NumDoc in 

(SELECT D.NumDoc FROM DOC WHERE D.NomDoc = ‘Dupont’)); 

Et celle-là ? 

SELECT P.NomPat FROM PAT P WHERE EXISTS 

(SELECT * FROM RDV R WHERE P.NumPat = R.NumPat and EXISTS 

(SELECT * FROM DOC D WHERE R.NumDoc=D.NumDoc and D.NomDoc = ‘Dupont’)); 

L’imbrication est un moyen de décomposer 

une requête complexe en sous-requêtes plus simples 

47 

48

Calculs d'agrégats 

Les fonctions d’agrégation (Count, Sum, Avg, Min, Max) permettent de réaliser des 

calculs sur des ensembles de données 

• Calcul de statistiques globaux 

− Nombre de patients : SELECT count(*) FROM PAT 

− Prix moyen des médicaments : SELECT avg(Prix) FROM MED 

• Calcul de statistiques par groupe 

− Nombre de patients par ville : 

SELECT VillePat, count(*) NbPatient FROM PAT GROUP BY VillePat 

− Et celle-ci ? 

SELECT VillePat FROM PAT, RDV 

WHERE PAT.NumPat = RDV.NumPat and Motif = ‘mal de tête’ 

GROUP BY VillePat 

HAVING count(DISTINCT(NumPat)) > 10 

Union/Inter°/Diff. : exemples 

• 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 

SELECT NomPat PatMed FROM PAT 

INTERSECT 

SELECT NomMed PatMed FROM MED 

• Patients qui ne sont pas médecins 

SELECT NomPat Patient FROM PAT 

EXCEPT 

SELECT NomMed Patient FROM MED 

49 

50 

Évaluation « sémantique » d’une requête SQL 

Vues relationnelles 

1. FROM 

Réalise le produit cartésien des relations 

2. WHERE 

Réalise restriction et jointures 

3. GROUP BY 

Constitue les partitions 

(e.g., tri sur l’intitulé du groupe) 

4. HAVING 

Restreint aux partitions désirées 

5. SELECT 

Réaliser les projections/calculs finaux 

6. ORDER BY 

Trier les tuples résultat 

AGG1 

AGG3 

AGG1 

AGG3 

XXX 

XXX 

YYY 

ZZZ 

XXX 

XXX 

YYY 

ZZZ 

XXX 

ZZZ 

ZZZ 

XXX 

51 

AGG1 

AGG2 

AGG3 

• Les vues permettent d’implémenter l’indépendance logique 

en créant des objets virtuels 

• Vue = Question SQL stockée 

• Le SGBD stocke la définition et non le résultat 

• Exemple : la vue des patients parisiens 

Create View Patients_Parisiens as ( 

Select 

From 

Nom, Prénom 

Patients 

Where Patients.Ville = ’Paris’ ) 

52

Les vues : des relations virtuelles ! 

Le SGBD transforme la question sur les vues en question sur 

les relations de base 

Déclencheurs : Définition 

• Définition : Déclencheurs ou Triggers 

− 

Règle E – C – A : Événement – Condition – Action 

Question Q 

sur des vues 

Définition des 

vues 

Gestionnaire 

de Vues 

Question Q’ 

sur les relations 

de base 

Lorsque l’événement se produit 

− 

Insert / Update / Delete pour une relation donnée 

si la condition est remplie 

− 

Prédicat SQL optionnel 

alors exécuter l’action 

− 

− 

Code à exécuter (ex. PL/SQL sous Oracle) 

Pour chaque tuple concerné ou une fois par événement 

53 

54 

Déclencheurs : Syntaxe (dans Oracle) 

PROGRAMMATION SQL 

Create trigger 

before | after 

insert | delete | update [of ] 

on 

[referencing old as , new as ] 

for each row 

[when ] 

DECLARE 

BEGIN 

 

END 

permet d’indiquer quand le trigger va être exécuté 

Quel est l’événement déclencheur 

indique le nom de la table qui doit être surveillée 

en SQL3, Oracle utilise :new et :old 

Précise si l’action est exécutée 1 fois par tuple concerné ou pour toute la table 

permet d’indiquer une condition pour l’exécution du trigger 

Déclaration de variables pour le bloc PL/SQL 

Bloc PL/SQL contenant le code de l’action à exécuter 

Dans SLQ3, on peut indiquer une suite de commande SQL 

• La syntaxe diffère légèrement suivant le SGBD 

•SQL n’est pas un langage complet 

• Problématique de la connexion langage hôte/SQL 

• déclaratif/ensembliste vs. procédural 

• conversion de type 

• 3 approches 

• Embedded SQL (PRO*C, SQLJ …) 

• API de bas niveau (SQL-CLI, ODBC, JDBC …) 

• Langage dédié (PL/SQL, SQL/PSM …) 

55 

56

Exemple Embedded SQL 

Exemple JDBC 

EXEC SQL DECLARE C1 CURSOR FOR 

SELECT NumDoc, NomDoc 

FROM DOC 

WHERE VilleDoc = ‘Versailles’; 

import java.sql.*; 

... 

class JdbcTest { 

static String BD_URL = "jdbc:oracle:@nomBDRoute"; 

main() 

{ 

EXEC SQL BEGIN DECLARE SECTION 

char sqlstate[6], NomDoc[21], VilleDoc[31]; 

int NumDoc; 

EXEC SQL END DECLARE SECTION 

} 

EXEC SQL OPEN C1 ; 

while (notEndofResult(sqlstate) { 

EXEC SQL FETCH C1 INTO :NumDoc, :NomDoc; 

... 

} 

EXEC SQL CLOSE C1 ; 

57 

public static void main (String args []) 

throws SQLException, ClassNotFoundException, IOException 

{ 

} 

} 

Class.forName ("oracle.jdbc.OracleDriver"); 

Connection BDRoute; 

BDRoute =DriverManager.getConnection(BD_URL, "MonNom", "MonPass"); 

Statement Trajet = BDRoute.createStatement (); 

ResultSet ResTrajet = Trajet.executeQuery 

("SELECT * FROM Route WHERE Depart = ‘Paris’"); 

while ( ResTrajet.next() ) 

{ System.out.println (ResTrajet.getString ("Arrivee")); } 

ResTrajet.close(); 

Trajet.close(); 

BDRoute.close(); 

58 

Exemple : Oracle PL/SQL 

Curseurs PL/SQL : exemple 

• Procédure Anonyme 

Client 

PL/SQL 

Moteur 

PL/SQL 

• Procédure stockée (invocation directe) 

Client 

RPC 

Moteur 

PL/SQL 

• Procédure stockée (invocation indirecte) 

Client 

Mise à jour SQL 

Moteur 

PL/SQL 

Serveur 

SQL 

Serveur 

SQL 

Serveur 

SQL 

BD 

BD 

BD 

PL/SQL 

trigger 

PL/SQL 

59 

DECLARE 

CURSOR Compta IS 

SELECT nom, salaire FROM Employe WHERE service = ‘comptabilité’; 

Emp Compta%ROWTYPE; 

BEGIN 

OPEN Compta; 

FETCH Compta INTO Emp; 

WHILE Compta%FOUND LOOP 

IF Emp.salaire IS NOT NULL AND Emp.Salaire < 30.000 THEN 

UPDATE Employe SET salaire = salaire * 1,05 WHERE nom = Emp.nom 

END IF; 

FETCH Compta INTO Emp; 

END LOOP; 

CLOSE C; 

END; 

60

Architecture physique des SGBD 

Architecture centralisée 

• Une floraison de vocabulaire et d’architectures 

− 

− 

− 

− 

− 

− 

− 

BD centralisée 

BD client/serveur 

BD 3-tiers 

BD répartie 

BD hétérogène 

BD sur le Cloud 

… 

Terminaux passifs 

réseau 

Appli 1 Appli 2 Appli n 

SGBD 

données 

• Des terminaux clients passifs 

• Un réseau 

• Un serveur central 

− 

− 

grande puissance (‘mainframe’) 

Maintient la base et les applications 

Mainframe 

61 

Exemple d’instance de cette architecture? 

le minitel, mais aussi Google ☺ 

62 

Architecture client-serveur 

Appli 1 

Clients intelligents 

Appli 2 

Appli n 

• Des clients intelligents 

− 

Font tourner les applications 


• Un serveur de données 

− 

Maintient la base 

Architecture 3-tiers 

réseau 

• Des clients 

− 

Concentrés sur la présentation 


• Un serveur d’application 

− 

Exécute le code applicatif 

• Un serveur de données 

− 

− 

Maintient la base 

Sur la même machine ou des machines différentes 

réseau 

Serveur 



serveur 

SGBD 

Serveur 

de données 

SGBD 

code 

données 

code 

données 


Client messagerie 

63 


Appli Web 

64

Architecture répartie 

Appli 1 

Appli 2 

Appli n 


− 

− 

Font tourner l’application 

Interagissent avec ‘1 SGBD’ 

(l’application ne voit pas que sa requête est réacheminée) 


• Des serveurs 

− 

Une même base 

− 

Gèrent chacun une partition 

Architecture hétérogène 


Médiateur 


− Interagissent avec ‘1 médiateur’ 

• Un médiateur 

− Interroge les sources 

− Nettoyage, intégration, etc. 

• Des sources de données 

− Données hétérogènes 

• Type, schéma, etc. 

− Gestion des données différente… 

code 

SGBD 1.1 

données 

code 

SGBD 1.2 

données 

code 

Source 1 : 

SGBD 

données 

code 

Source 2 : 

serveur Web 

données 


Agences d’une société 

65 


Kelkoo 

66 

Architecture en Cloud 

Applications traditionnelles des SGBD 

Terminaux 

réseau 


SGBD 

données 

• Virtualisation de l’approche 

centralisée avec mutualisation des 

ressources matérielles et logicielles 

• Objectif = élasticité « Pay as you go » 

• DaaS: Database as a Service 

Mainframe 

• OLTP (On Line Transaction Processing) 

− 

Cible des SGBD depuis leur existence 

− Banques, réservation en ligne ... 

− 

− 

Très grand nombre de transactions en parallèle 

Transactions simples 

• OLAP (On Line Analytical Processing) 

− 

− 

− 

Entrepôts de données, DataCube, Data Mining … 

Faible nombre de transactions 

Transactions très complexes 


Amazon EC2 

67 

68

Applications nouvelles … 

• DB in the (very) large 

− 

− 

NoSQL: sélections/màj simples sur tables géantes 

• ex: BigTable (Google), Cassandra (Facebook), Dynamo (Amazon) … 

• Performance/scalabilité au détriment de la cohérence 

Big Data: analyse de gigantesques volumes de données faiblement structurées 

• Parallélisation/distribution massive des traitements : map/reduce 

• DB in the (very) small 

− 

− 

− 

Réseaux de capteurs : calcul d’agrégats … 

Véhicules : recherche places libres, prédiction de traffic, alertes … 

BD personnelles : études épidémiologiques, enquêtes … 

• Nouvelles formes d’acquisition de données 

− 

− 

− 

Intelligence ambiante : acquisition automatique de flux de données, préservation 

de la vie privée 

BD participatives : (ex: Wikipedia), administration distribuée, data provenance, 

versions 

DB Crowdsourcing : multitude d’acteurs humains capturant des données 

cognitives (critères subjectifs) ou difficiles à accumuler de façon automatique 

69 

Orientations de recherche (1) 

• Gestion de données complexes 

− 

− 

− 

Semi-structurées : stockage, indexation, interrogation de docs XML 

Non structurées : recherche par le contenu, index multidimensionnels, relations 

spatio-temporelles 

Intégrer l’ensemble de ces données dans un ‘dataspace’ cohérent et en extraire de la 

connaissance 

• Masses de données distribuées 

− 

− 

− 

− 

Médiation de données : intégration de schémas, requêtes de médiation 

Médiation de programmes : construction de workflows, optimisation des flux, 

composition de services Web 

interrogation de masses de données : requêtes continues, personnalisation, critères 

approximatifs, publish/subscribe, etc 

BD en P2P, Content Delivery Networks : localisation des ressources/acheminement 

• Entrepôts de données et fouille 

− 

Recherche de règles associatives, de dépendances fonctionnelles, fouille de 

données spatio-temporelles … 

70 

Orientations de recherche (2) 

Orientations de recherche (3) : sécurité des BD 

• Mobilité 

− 

Requêtes spatio-temporelles, BD embarquées, cohérence des traitements 

déconnectés, réseaux de capteurs, réseaux de véhicules … 

• Architecture et performance (encore et toujours) 

− 

− 

− 

− 

− 

Évolutions matérielles : grandes mémoires, nouvelles mémoires 

persistantes, nouveaux processeurs … 

Parallélisme massif, Cloud computing 

SGBD auto-administrables 

Économie d’énergie 

Donc : indexation, optimisation de requêtes, réplication, transactions, 

benchmarks, etc … 

• Et bien sûr « Sécurité des bases de données » ☺ 

− 

Cf. transparent suivant 

(liste non exhaustive) 

71 

2- Protection des 

communications 

User 

1- Authentification 

9- Législation 

3- Autorisations 8- Anonymisation 

de données 

7- Rétention 

limitée des 

données 

4- Chiffrement 

des données 

Extraction 

Requêtes 

5- Audit 

6- Contrôle 

d’usage 

72

Rappels des concepts fondamentaux - smis inria

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?