Database Cours Complet

Introduction au
modèle Relationnel
Cours 0
Abdelkrim LAHLOU
Lahloukarim@free.fr
Introduction au modèle relationnel
◼ Proposé par CODD (Université Saint José) en 1971

◼ Caractéristiques principales
◼ simplicité des concepts
◼ facilité d’utilisation
◼ standardisation du langage de définition des données et
du langage d’interrogation: SQL
◼ pauvreté sémantique due au fait qu’il n’y a qu’un seul
concept: la relation (ou table) pour représenter une
entité, une association ou une sous classe
◼ pas de représentation graphique
◼ existence d’une théorie sous-jacente
2
Les concepts de base
◼ Concepts structuraux
◼ Le modèle relationnel s’appuie sur trois concepts structuraux de
base: le domaine, la relation (ou table) et l’attribut.
◼ Le domaine est un ensemble de valeurs caractérisé par un nom.
Exemples: le domaine des entiers E= {0,+/- 1, +/-2, ...}; le
domaine des booléens D1= {0,1}; le domaines des couleurs
possibles D2= {vert, bleu,blanc,rouge}; le domaine des
caractères...
◼ La relation, concept central du modèle, peut être définie
grossièrement comme un tableau de données à deux dimensions.
Les colonnes de ce tableau sont appelées attributs. Les lignes
de ce tableau, occurrence de la relation, seront appelées tuples
ou n-uplets
◼ Chaque attribut peut prendre des valeurs dans un domaine.
3
Les concepts de base (suite)
◼ Schéma de relation : Nom de la relation suivi de la liste

des attributs et de la définition de leurs domaines.
◼ Schéma relationnel: Ensemble des schémas de relation
◼ Clés
◼ Clé candidate : Ensemble d’attributs minimal dont la
connaissance des valeurs permet d’identifier un tuple unique
de la relation considérée.
◼ Clé primaire : Elle est choisie parmi les clés candidates.
◼ Clé étrangère : C’est un constituant ou un ensemble de
constituants d’une table apparaissant comme une clé primaire
dans une autre relation.
4
Les concepts de base (suite)
◼ Contraintes d’intégrité :
◼ Est un prédicat que doit vérifier un sous ensemble de la base afin que l’on
puisse considérer les informations comme cohérentes. Le rôle des contraintes
d’intégrité est d’assurer la cohérence des données.
On peut isoler plusieurs types de contraintes d’intégrité:
◼ Contrainte de domaine : Concerne le contrôle syntaxique et sémantique d’une
donnée, et fait référence au type de définition du domaine.

◼ Contrainte déclarative : Contrainte imposée sur des attributs (valeur nulle,
valeur par défaut, clé primaire, liste de valeurs,.)

◼ Contrainte référentielle : Impose que la valeur d’un attribut dans une relation
apparaisse comme valeur de clé dans une autre relation (Clé étrangère -->
Clé primaire).
◼ Contrainte d’entité : Contrainte d’intégrité imposant que toute relation
possède une clé primaire et que tout attribut participant à cette clé primaire
soit non nul.
5
Les concepts additionnels
◼ Valeur nulle : Valeur conventionnelle introduite dans une relation pour
représenter une information inconnue ou inapplicable.
◼ Agrégat : Partitionnement horizontal d’une relation en fonction des
valeurs d’un groupe d’attributs, suivi d’un regroupement par application
d’une fonction de calcul sur ensemble.
◼ Les fonctions de calcul sur ensemble les plus souvent proposées
sont les suivantes :
◼ Somme (SUM) permettant de calculer la somme des éléments d’un
ensemble;
◼ Moyenne (AVG) permettant de calculer la moyenne des éléments d’un
ensemble;
◼ Minimum (MIN) permettant de sélectionner l’élément minimum d’un
ensemble;
◼ Maximum (MAX) permettant de calculer l’élément maximum d’un ensemble;
◼ Compte (COUNT) permettant de compter les éléments d’un ensemble.
6
Les concepts additionnels (suite)
◼ Expression d’attributs : Expression arithmétique construite à partir
d’attributs d’une relation et de constantes, par application de fonctions
arithmétiques successives.
◼ exemples :
◼ Salaire = Salaire * 1,10,
◼ Revenu-Annuel = (Salaire-Mensuel * 13,5) + (Commission / 120)
◼ Vue (View) : Une vue est une table virtuelle (c ’est-à-dire non stockée
telle qu’elle) regroupant les données dont un utilisateur a besoin.
◼ Une vue est donc virtuelle, elle n’a donc pas d’existence physique, au moins
lorsqu’elle n’est pas accédée.
◼ Elle peut être obtenue à partir de la sélection d’attributs d ’une ou de
plusieurs tables (jointure)
◼ Elle peut être interrogée comme une table normale de la base.
7
Les concepts additionnels (suite)
◼ Délencheurs (Triggers) : Evénement déclenché suite à l’apparition
d’une condition particulière dans la base de données provoquant
l’exécution d’un programme de traitement de la base composé d’une ou
plusieurs requêtes.
◼ Un trigger peut être déclenché en réaction à une opération sur donnée
(mise à jour d’une table, d’un tuple) ou suite au passage à vrai d’une
condition sur valeurs de données (critère de sélection ou de jointure).
◼ Un trigger est défini au niveau du schéma de la base. Il permet
d’intégrer certains traitements constituant des règles communes à la
base, par exemple le maintien des contraintes d’intégrité ou des
données redondantes.
◼ Procédures : Programme écrit en pseudo-langage procédural offert par
le SGBD. Il est stocké dans le dictionnaire de données après compilation.
◼ Les résultats de la phase de “parsing” et de la phase de détermination
du chemin d’accès sont stockés avec le procédure permettant une
meilleure performance.
8
Convention de formalisme
◼ Formalisme
◼ La table, ses attributs et sa clé primaire
EMPLOYES
Matricule
Nom
Date_emb Notons que, dans cette représentation, le ou les
Code_dept
attributs composant la clé primaire sont soulignés
◼ Contraintes d’intégrité référentielle

EMPLOYES DEPARTEMENT
Code-dept de la table Employés
Matricule est clé étrangère et pointe vers Code-dept
Nom l’attribut Code-dept clé primaire
Nom
de la table Département
Date_emb Adresse
Code_dept*
9
Opérateurs algébriques de base sur les tables
relationnelles
1 - Sélection
2 - Projection
3 - Jointure
10
1 - Sélection
Patient Patient
Id-P Nom Prénom Ville Id-P Nom Prénom Ville
1
2
3
Lebeau
Troger
Doe
Jacques
Zoe
John
Paris
Evry
Paris
s 1
2
3
Lebeau
Troger
Doe
Jacques
Zoe
John
Paris
Evry
Paris
4 Perry Paule Valenton 4 Perry Paule Valenton
Patients de la ville de Paris

SELECT * FROM Patient WHERE upper(Ville) = ’PARIS’;
11
2 - Projection
Patient Patient
Id-P Nom Prénom Ville Id-P Nom Prénom Ville
2
Lebeau
Troger
Jacques
Zoe
Paris
Evry
p 1
2
3
Lebeau
Troger
Doe
Jacques
Zoe
John
Paris
Evry
Paris
4 Perry Paule Valenton
3 Doe John Paris
Nom et prénom des patients

SELECT Nom, Prénom FROM Patient;
12
3 - Jointure
Patient Visite
Id-P Nom Prénom Ville Id-D Id-P Id-V Date Prix
1 2 1 15 juin 250
1 Lebeau Jacques Paris
1 1 2 12 août 180
2 2 3 13 juillet 350
2 Troger Zoe Evry
2 3 4 1 mars 250
3 Doe John Paris
Id-P Nom Prénom Ville Id-D Id-P Id-V Date Prix

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

13
Langage SQL
Cours 4
Historique
◼ 1964 : IBM développe le GUAM pour le projet Apollo (NASA)
◼ 1966 : Première BD hiérarchique commerciale du marché d’IBM
◼ 1970 : Dr. E. F. Codd d’IBM propose le modèle relationnel
◼ 1977 : Larry Ellison, Bob Miner et Ed Oates fondent Oracle
◼ 1985 : l’ANSI adopte SQL comme langage de requête standard
◼ 1992 : SQL-2
◼ 1993 : Sortie d’Access
◼ 1995 : Sortie de Postgres95
◼ 1996 : Sortie de MySQL
◼ 1998 : SQL Server 7 disponible
◼ 1999 : SQL-3 et sortie d’Oracle8i
◼ 2000 : Sortie d’Oracle 9i
◼ 2006 : Oracle 10g 15
SQL : Structured Query Language
◼ SQL est à la fois un langage de :
◼ définition des données (DDL : Data Definition Language)
◼ manipulation des données (DML : Data Manipulating

Language)
◼ contrôle de l’accès aux données (DCL : Data Control

Language)
Remarque :
Toute commande SQL doit se terminer par ;

16
SQL - DDL
Un DDL autorise toutes les actions propres à la
définition des objets (tables, vues, utilisateurs,
index, etc.) :
◼ Créer un objet (CREATE)

◼ Modifier la structure d’un objet (ALTER)
◼ Détruire un objet (DROP)
Exemple :
CREATE TABLE Eleves (Nom CHAR(15) PRIMARY KEY,
Prenom VARCHAR(25) NOT NULL);
17
SQL-DML
Un DML autorise toutes les actions propres à la
manipulation des données :
◼ insertion de nouvelles données (INSERT)
◼ suppression de données (DELETE)
◼ mise à jour de données (UPDATE)
◼ interrogation de la base (SELECT)
Les commandes DML sont la partie centrale de SQL
Exemple :
SELECT DISTINCT Nom, Prenom
FROM Eleves WHERE UPPER(Nom) LIKE ‘L%’ ;
18
SQL-DCL
Le DCL autorise toutes les actions propres au contrôle

de la base de données, notamment la gestion des droits
d’accès à la base de données ou à un objet précis
(GRANT : accorder un privilège ou REVOKE :
supprimer un privilège), la gestion des transactions
(COMMIT : valider toutes les transactions depuis le
dernier COMMIT ou ROLLBACK : annuler toutes les
transactions effectuées depuis le dernier COMMIT),
etc...
19
Les types de base dans SQL
Les types de données
SQL offre plusieurs types de données dont les types de base suivants :
CHAR(n) chaîne de n caractères
VARCHAR(n) chaîne de caractères de longueur variable d’au plus n caractères
DATE date + heure de taille fixe et dont le format par défaut

est ‘DD-MMM-YY’
NUMERIC (n,d) type numérique pour les entiers et les réels,

n: nombre total de chiffres (max 38)
d: nombre total de chiffres décimaux (-84 à 127)
Les types dérivés sont: INT, DEC, SMALLINT, et REAL.
Remarques :
- Le type booléen n’existe pas dans SQL, il peut toutefois être simulé avec CHAR(1) ou NUMERIC (1).
- Par exemple, le SGBD Oracle accepte les types numériques SQL2 mais il les traduit dans ses propres
types. NUMERIC en NUMBER et VARCHAR en VARCHAR2
21
Les types de données Oracle
Oracle offre plusieurs types de données dont les types de base suivants :
CHAR(n) chaîne de n caractères (max 2000)
VARCHAR2(n) chaîne de caractères de longueur variable d ’au plus n caractères
LONG chaîne de caractères de longueur 2GB. Seule une colonne de type
LONG est admise par table!
BLOB grand objet binaire (Binary Large Object) peut stocker jusqu’à 4Go
de données binaires non structurées, texte, image, vidéo, son, etc…
CLOB (Character LOB), NCLOB(National CLOB) et BFILE(Binary FILE) à
utiliser plutôt que le type LONG
RAW(n) champ de longueur variable n, utilisé pour stocker des données
binaires
DATE date+heure de taille fixe et dont le format par défaut est ‘DD-MMM-YY’
NUMBER (n,d) type numérique pour les entiers et les réels,
n: nombre total de chiffres (max 38)
d: nombre total de chiffres décimaux (-84 à 127)
Les types dérivés sont: INT, DEC, SMALLINT, et REAL.
Remarques :
- Le type booléen n’existe pas dans Oracle, il peut toutefois être simulé avec CHAR(1) ou NUMBER (1).
- Oracle accepte les types numériques SQL2 mais il les traduit dans ses propres types
- Les types NCHAR(n) et NVARCHAR2(n) utilisent des caractères au format UTF-16
22
Définition des données
Le langage de définition des

données
(DDL)
Création d’une table
CREATE TABLE <nom_table>
( <column 1 > <data type> [NOT NULL] [UNIQUE][<column
constraint>],
…
<column n > <data type> [NOT NULL] [UNIQUE][<column
constraint>],
<column n > <data type> [DEFAULT valeur],
[< table constraint(s) >]
);
◼ La contrainte d’unicité UNIQUE sur une colonne spécifie que deux

enregistrements ne peuvent pas avoir la même valeur dans cette
colonne. Notons que cette contrainte autorise les valeurs nulles, d’où la
différence avec la contrainte de clé primaire.
◼ Une valeur par défaut peut être spécifiée avec la clause DEFAULT, ce
qui évite les erreurs dans le cas où aucune valeur ne serait donnée.
24
Contraintes
La création d’une table peut inclure la spécification de
contraintes d’intégrité. Ces contraintes peuvent être de deux
types différents :
◼ contrainte de colonne
◼ contrainte de table
[CONSTRAINT <name>] PRIMARY KEY (<column(s) >)
[CONSTRAINT <name>] UNIQUE (<column(s) >)
[CONSTRAINT <name>] NOT NULL (<column(s) >)
[CONSTRAINT <name>] CHECK (<expression booléenne>)
[CONSTRAINT <name>] FOREIGN KEY (<column(s) >)

REFERENCES <table>[<column(s)>] [ON DELETE CASCADE]
25
Exemple de création de table
Soit la relation Produit(NumP, Nom, PrixUnitaire, Quantite)
CREATE TABLE Produit (

NumP NUMERIC(4) NOT NULL,
Nom VARCHAR(15) NOT NULL,
PrixUNitaire NUMERIC(8,2),
Quantite NUMERIC(6),
CONSTRAINT PK_Produit PRIMARY KEY (NumP)
);
26
Modification de la structure d’une table
Il est possible de modifier la structure d’une table même si des
enregistrements ont déjà été insérés
◼ Ajout d’une colonne

ALTER TABLE <table>
ADD (<column> <datatype> [DEFAULT <value>][<column constraint>]) ;
◼ Ajout d’une contrainte de table
ALTER TABLE <table>
ADD (<column constraint>) ;
◼ Modification d’une colonne
ALTER TABLE <table>
MODIFY (<column>[ <datatype>] [DEFAULT <value>] [<column
constraint>]) ;
◼ Destruction de colonne ou contrainte
ALTER TABLE <table>
DROP [<column>] [<CONSTRAINT column constraint>]) [CASCADE];
27
Exemple de modification de schéma de table
Soit la relation :
Produit(NumP, Nom, PrixUnitaire, Quantite, #NumFabricant)
NumP est la clé primaire de la table Produit et NumFabricant est clé
étrangère référençant l’attribut NumF de la table Fabricant
Création de la table Produit :

CREATE TABLE Produit (
NumP NUMERIC(4) NOT NULL,
Nom VARCHAR(15) NOT NULL,
PrixUNitaire NUMERIC(8,2),
Quantite NUMERIC(6),
NumFabricant NUMERIC(4),
CONSTRAINT PK_Produit PRIMARY KEY (NumP)
);
28
Exemple (Suite)
Modification du schéma de la table Produit en lui ajoutant la

contrainte de clé étrangère sur l’attribut NumFabricant qui
fait référence par exemple à l’attribut NumF de la table
Fabricant qui est supposée déjà créée
ALTER TABLE Produit ADD CONSTRAINT

FK_Produit_Fabricant FOREIGN KEY
(NumFabricant) REFERENCES Fabricant(NumF);
29
Destruction d’une table
La destruction d’une table efface toutes les données qu’elle
contient ainsi que sa structure.
DROP TABLE <table>

[CASCADE CONSTRAINTS] ;
Exemple :
DROP TABLE Produit ;
30
Chargement et mise à jour
de la base de données
Le langage de manipulation des

données
(DML)
Insertion d’un enregistrement
INSERT INTO <table>

[(<column i>, … , <column j>)]
VALUES (<value i>, … , <value j>) ;
Dans le cas où les données à insérer se trouveraient dans

d’autres tables, l’insertion se fait de la suivante :
INSERT INTO <table>
[(<column i>, … , <column j>)]
<requête> ;
Exemple :
INSERT INTO client(num, nom) VALUES (32, ’Dupont’ ) ;
32
Mise à jour d’un enregistrement
UPDATE <table> SET
<column i > = <expression i >, …,
<column j > = <expression j >,
[WHERE <condition>];
Une expression peut être une constante (nouvelle valeur), une

expression arithmétique ou une expression chaîne de
caractères, ou une requête SQL.
Exemple : UPDATE Commande SET
MontantTotal =
(SELECT SUM(LigneCommande.total)
FROM LigneCommande, Commande
WHERE LigneCommande.NoCom = Commande.NoCom
AND NoCom = 45)
WHERE NoCom = 45 ; 33
Suppression d’un enregistrement
DELETE FROM <table>

[WHERE <condition>];
Exemple :
DELETE FROM client WHERE num = 32 ;
Attention :
DELETE FROM client ;
-- supprime toutes les données de la table Client
34
Commit et Rollback
◼ Une séquence de modifications (insert, update ou delete)
est appelée une transaction.
◼ Une modification est temporairement stockée dans le
système de la base de données. Elle deviendra permanente
seulement après une instruction COMMIT.
◼ Tant que l’instruction COMMIT n’a pas encore été appelée,
il est possible de « défaire » toutes les modifications, pour
se faire, l’instruction ROLLBACK est utilisée.
◼ Il est recommandé de confirmer chaque modification avec
un COMMIT. Cette instruction est toutefois implicitement
exécutée lorsqu’une session est terminée.
35
Interrogation de la base
de données
DML (suite) : la commande

SELECT...
L’instruction SELECT est composée de six clauses
différentes, dont seules les deux premières sont
obligatoires
SELECT [DISTINCT] <column(s)>

FROM <table(s) ou vues ou requêtes>
[WHERE <condition>]
[GROUP BY <group_column (s)>]
[HAVING <group_condition(s)>]
[ORDER BY <column(s) [ASC / DESC]>] ;
37
◼ SELECT permet d’indiquer quelles colonnes ou expressions
doivent être retournées par l’interrogation. Le symbole *
signifie que toutes les colonnes de la tables sont
sélectionnées. DISTINCT permet d’éliminer les doublons
éventuels du résultat
◼ FROM liste les tables participant à l’interrogation
◼ WHERE permet de spécifier quelles sont les lignes à
sélectionner dans une table ou dans le produit cartésien de
plusieurs tables. Elle est suivie d’un prédicat qui sera
évalué pour chaque ligne. Les lignes pour lesquelles le
prédicat est vrai seront sélectionnées
38
◼ GROUP BY permet de subdiviser la table en groupes,
chaque groupe étant l’ensemble des lignes ayant une
valeur commune
◼ HAVING sert à préciser quels groupes doivent être
sélectionnés
◼ ORDER BY précise l’ordre croissant (ASC) ou décroissant
(DESC) dans lequel la liste des lignes sélectionnées sera
rendue en résultat (par défaut : ASC)
39
Fonctions et opérateurs
Pour les différents types de données, plusieurs
opérateurs et fonctions sont fournis :
◼ Pour les nombres :
ABS, COS, SIN, EXP, LOG, POWER, MOD, SQRT, +, -, *, /, …
◼ Pour les chaînes de caractères :

CHR, CONCAT (string1, string2), LOWER, UPPER, REPLACE (string,
search-string, replacement-string), TRANSLATE, SUBSTR( string, m, n),
LENGTH, TO_DATE, ...
◼ Pour les dates :

ADD_MONTHS, MONTHS_BETWEEN, NEXT_DAY, TO_CHAR, …
40
Opérateurs de comparaison
Les trois types d’expressions (arithmétiques, caractères ou
dates) peuvent être comparés au moyen des opérateurs. Pour
le type date, la relation d’ordre est l’ordre chronologique; pour
le type alphanumérique, la relation d’ordre est l’ordre
lexicographique.
❖ = , != ou <>, < , > , <= , >=

❖ <column> [NOT] IN (<list of values>)
❖ <column> IS [NOT] NULL
❖ <column> [NOT] BETWEEN <lower bound>
AND <upper bound>
41
Opérateurs de chaîne de caractères
◼ « Pattern matching »
<column> [NOT] LIKE <matching-string>
cherche des chaînes correspondant à un modèle
_ exactement un caractère
% n’importe quelle chaîne de caractères, même une chaîne vide
◼ UPPER (<string>) : transformation de la chaîne en

majuscule
◼ LOWER (<string>) : transformation de la chaîne en
minuscule
◼ INITCAP (<string>) : transformation du 1er caractère en
majuscule et les autres en minuscule
42
Opérateurs de chaîne de caractères (Suite)
◼ LENGTH (<string>) longueur de la chaîne

◼ SUBSTR (<string>, n [,m])
retourne la sous-chaîne de longueur m à partir de la
position n
expression1 BETWEEN expression2 AND

expression3
est vrai si expression1 est comprise entre expression2 et
expression3, bornes incluses
expression IS [NOT] NULL

détermine si l’expression vaut [non] NULL
43
Fonctions d’agrégation
Les fonctions d’agrégation sont le résultat d’un calcul
statistique (min, max, moyenne,…) sur les valeurs d’une
colonne
◼ AVG (colonne) moyenne des valeurs de la colonne
◼ COUNT (colonne / *) compte le nombre de lignes
◼ MIN (colonne) minimum de la valeur de la colonne
◼ MAX (colonne) maximum de la valeur de la colonne
◼ SUM (colonne) somme des valeurs de la colonne
◼ STDDEV(colonnes) déviation des valeurs de la colonne
◼ VARIANCE([DISTINCT] ensemble) Variance de valeurs
en ignorant les valeurs NULL.
Remarque :
Les valeurs NULL sont ignorées par les fonctions d’agrégation 44
Sous-requêtes
◼ Une caractéristique puissante de SQL est la possibilité
qu’un critère de recherche employé dans une clause
WHERE soit lui-même le résultat d’un SELECT; on parle
alors de sous-requête.
◼ Une sous-requête peut ramener plusieurs lignes.
◼ Les opérateurs permettant de comparer une valeur à un
ensemble de valeurs sont :
◼ ANY : le prédicat est vrai si la comparaison est vraie pour l’une
des valeurs retournées par la sous-requête
◼ ALL : le prédicat est vrai si la comparaison est vraie pour toutes
les valeurs retournées par la sous-requête
45
Sous-requêtes (Suite)
◼ [NOT] IN : détermine si une valeur est égale à une

autre ou différente de toutes les autres valeurs dans
un jeu de données retourné par une sous-requête ou
fourni par une liste de valeurs
◼ [NOT] EXISTS : teste l’existence d’au moins une ligne

qui satisfait le critère de sélection dans une sous-
requête
46
Jointures
- Jointure interne
- Jointure naturelle
- Jointure externe
Jointure interne (Définition)
48
Jointure interne (Produit cartésien)
49
Jointure interne (Exemple)
50
Jointure interne (Exemple)
51
Jointure interne (Syntaxe SQL)
52
Jointure naturelle
53
Jointure externe (Définition)
54
Jointure externe (Produit cartésien)
55
Jointure externe (Exemple)
56
57
58
Jointure externe (gauche)
59
Jointure externe (droite)
60
SELECT Nom_Etablissement FROM Etablissement

WHERE No_Etab NOT IN (SELECT DISTINCT No_Etab FROM Lecteur);
61
Nombre de lecteurs par etablissement :

SELECT Nom_Etablissement, COUNT(E.Nom)
FROM Etablissement E LEFT JOIN Lecteur L ON E.No_Etab = L.No_Etab
GROUP BY Nom_Etablissement;
62
Jointure externe
63
Division
Division (1/3)
Table Docteur Table Maladie
DocNum DocNom Spécialité MalCode TypeMal

D1 Petit Pédiatre M1 Gros rhume
D2 Alain Pédiatre M2 Nez cassé
D3 Heart Cardiologue M3 Rides
D4 Brute Anesthésiste M4 Mal au cœur
M5 Bras cassé
M6 Otite
M7 Entorse
65
Division (2/3)
Table Patient Table Soin
DocNum PatNum MalCode
PatNum PatNom Age
D1 P1 M2
P1 Riri 11
D1 P2 M3
P2 Fifi 12
D1 P3 M2
P3 Loulou 13
D2 P3 M3
P4 Donald 45
D2 P2 M2
P5 Minnie 39
D2 P1 M3
P6 Picsou 70
D2 P2 M6
P7 Mickey 55
D3 P1 M6
P8 Daisy 38
D4 P4 M7
P9 Rapetou 55
D4 P2 M3
D4 P1 M5 66
Division Solution évidente (3/4)
SELECT P. PatNum, P.PatNom
FROM Patient P, Soins S
WHERE P.PatNum = S.PatNum
GROUP BY P. PatNum, P.PatNom
HAVING COUNT(DISTINCT DocNum) =
(SELECT COUNT(*) FROM Docteur);
67
Division Solution optimale (4/4)
SELECT * FROM Patient P
WHERE NOT EXISTS (
SELECT * FROM Docteur D WHERE NOT EXISTS(
SELECT * FROM Soins S
WHERE S.DocNum = D.DocNum
AND S.PatNum = P.PatNum));
68
Concepts avancés du
Langage SQL
Cours 5
Gestion de la confidentialité
- Confidentialité et vues
- Les vues virtuelles
- Les vues matérialisées
- Confidentialité et droits d’accès
Confidentialité et indépendance
◼ La résolution des problèmes de confidentialité et

d’indépendance logique nécessitent l’utilisation de
vues
◼ Nous allons donc étudier le niveau des vues

appelé niveau externe
71
Contexte
Analyse syntaxique
ANALYSEUR Analyse sémantique
Gestion des schémas
Modification de requêtes
META-BASE TRADUCTEUR Contrôle d'intégrité
Contrôle d'autorisation
Ordonnancement
OPTIMISEUR Optimisation
Élaboration d'un plan
Exécution du plan
Méthodes d'accès
Plan d'Accès EXECUTEUR Contrôle de concurrence
Atomicité des transactions
BD
72
Gestion du schéma
◼ Les schémas de BD sont
gérés comme une base SCHEMA
de données relationnelle
appelée méta-base (ou
catalogue)
TABLES CONTRAINTES
◼ SQL2 normalise les tables
de la méta-base (ou plutôt
des vues de ces tables)
COLONNES CLES DOMAINES
73
Vision globale d’une BD
Programme Programme
d’application 1 d’application n
Niveau vue 1 … vue n

externe
Niveau BD conceptuelle
Conceptuel
Niveau BD physique
Interne
74
Niveau externe
Appelé également niveau des vues
◼ Un groupe d’utilisateurs d’une base de données
conceptuelle peut avoir besoin :
◼ d’une partie seulement des informations de la base de
données, et/ou
◼ de ces informations structurées différemment
◼ i.e. d’une BD conceptuelle différente de la base de

départ, mais dépendant de celle-ci :
1. Tout attribut figurant dans la nouvelle base est aussi dans
la base de départ ou dépend des attributs de celle-ci
2. Les instances de chaque table de la nouvelle base sont
calculées à partir de celle de la base de départ
75
Vues (Définition)
◼ Toute base de données conceptuelle satisfaisant

ces deux conditions est une vue
Exemple : S = {E(emp,dep);M(dep,mgr);S(emp,sal)}
Vue V :
◼ tables = {EM(emp,mgr);BS(emp,sal)}
◼ Calcul des instances :

◼  emp,mgr (E M) pour les instances de EM
◼ s sal<1000 (S) pour les instances de BS
76
Vues
◼ Chaque table d’une vue est entièrement

déterminée par la donnée d’une expression
nommée T = e, où T est une table et e une
expression relationnelle sur la base de départ
◼ sch(T) = sch(e)
◼ Les instances de T sont calculées par e
Exemple : définition de la vue :

◼ EM = emp,mgr(E M)
◼ BS = ssal<1000 (S)
77
Définition de vue
◼ Définition de la vue
Base de données virtuelle dont le schéma et le contenu sont
dérivés de la base réelle par un ensemble de requêtes (toute
ensemble d’expressions nommées de la forme T = e sur le schéma S
de BD est une vue sur S)
◼ Vue : BD conceptuelle plus abstraite

◼ les données de la vue sont construites à partir de celles de la BD
conceptuelle mais peuvent ne pas être présentes dans celle-ci
◼ les données de la vue n’ont pas d’existence indépendante de celles
de la BD conceptuelle
◼
◼ Une vue est donc un ensemble de relations déduites d'une

bases de données, par composition des relations de la base
◼ Par abus de langage, une vue relationnelle est une table
virtuelle
78
Gestion des vues
◼ Les vues sont manipulées, interrogées et mises

à jour comme n’importe quelle BD conceptuelle
(tables), mais cela dépend de l’implémentation
choisie :
1. Vues virtuelles
2. Vues matérialisées
79
Vues virtuelles
◼ Vue virtuelle
◼ les relations de la vue ne sont pas stockées
◼ seule sa définition est stockée
◼ le SGBD doit traduire les requêtes et mises à jour sur la
vue en requêtes et mises à jour sur la BD conceptuelle
◼ Traduction des requêtes

◼ Chaque table de la vue dans la requête est remplacée
par l’expression relationnelle qui la traduit (exemple :
emp(BS) remplacée par emp(ssal<1000 (S)) )
◼ Traduction des mises à jour

◼ Problèmes dès que la vue est définie à partir de plusieurs
tables
80
Vues matérialisées
◼ Stockées physiquement (ex: entrepôts de

données)
◼ Les requêtes sont évaluées sur la vue
◼ Nécessité de propager les mises à jour effectuées

sur la base au niveau des vues pour le maintien
de la cohérence
81
Les vues virtuelles
(ou vues logiques)
Utilisation des vues
◼ Au niveau de l’utilisateur (indépendance

logique) :
◼ Indépendance logique (protection des programmes
d’application contre les modifications du schéma)
◼ Exemple : le remplacement de E et M par la table
EDM(emp,dep,mgr) n’implique pas la réécriture des
programmes définis sur EM
◼ Au niveau du système (confidentialité) :

◼ Protection des données (exemple : BS)
83
Utilisation des vues
◼ Les vues peuvent simplifier la consultation de

la base en enregistrant des select complexes
◼ On verra que l'on peut donner accès à une

vue sans donner accès à la table sous-jacente
◼ On peut ainsi utiliser les vues pour restreindre

les droits d'accès à certaines colonnes ou
lignes d'une table
◼ Les utilisateurs pourront consulter ou modifier

la base (avec certaines restrictions) à travers
la vue comme si c'était une table réelle
84
Les vues (Syntaxe SQL)
◼ Création d'une vue
CREATE [OR REPLACE] [FORCE | NOFORCE]
VIEW <Nom_Vue> [(attribut [, attribut ] )]
AS <requête>
[ WITH CHECK OPTION ]
[ WITH READ ONLY ] ;
La clause WITH CHECK OPTION permet de spécifier que les tuples

de la vue insérés ou mis à jour doivent satisfaire aux conditions de
la requête.
◼ Suppression d'une vue

DROP VIEW <nom de vue> ;
85
Exemple :
BUVEURS (NB, NOM, PRÉNOM, ADRESSE, TYPE)
VINS (NV, CRU, RÉGION, MILLESIME, DEGRE)
ABUS (NV, NB, DATE, QUANTITÉ)
Les vins de Bordeaux :

CREATE VIEW vinsbordeaux (nv, cru, mill,
degré) AS SELECT nv, cru, millésime, degré
FROM vins WHERE Région = ‘Bordelais’;
La requête pour créer la vue peut contenir toutes les clauses d'un select
sauf Order by
DROP VIEW vinsbordeaux ;

86
Exemple …
◼ Les gros buveurs :
CREATE VIEW grosbuveurs AS
SELECT b.nb, nom, prénom, adresse
FROM buveurs b, abus a
WHERE b.nb = a.nb and a.quantité > 10 ;
◼ Les quantités de vins bues par cru :

CREATE VIEW vinsbus (cru, mill, degré,
total) AS
SELECT cru, millésime, degré,
SUM(quantité)
FROM vins v, abus a
WHERE v.nv = a.nv
GROUP BY Cru , millésime, degré ;
87
Suppression avec une vue
◼ On peut effectuer des Delete à travers une
vue, sous les conditions suivantes sur le Select
qui définit la vue :
◼ Une seule table
◼ Pas de group by
◼ Pas de distinct
◼ Pas de fonction de groupe
◼ Conditions suffisantes :
◼ Clés des tables participantes déductibles de la vue
◼ Vues mono-table avec clé de la table
88
Mise à jour avec une vue
◼ Vue comportant suffisamment d'informations pour
permettre un report des mises à jour dans la base sans
ambiguïté.
◼ On peut effectuer des UPDATE à travers une vue, avec
les conditions du DELETE, et en plus :
◼ Les colonnes modifiées sont des colonnes réelles de la table (pas
des expressions)
◼ On peut effectuer des INSERT à travers une vue, avec
les conditions du UPDATE, et en plus :
◼ Toute colonne « NOT NULL" de la table représentée par la vue
est présente dans la vue
Exemple :
UPDATE vinsbordeaux SET degré = degré + 2 ; 89
Interrogation des vues
◼ Transparence pour l'utilisateur

◼ comme des tables de la base
◼ Simplifier les requêtes utilisateurs
◼ Assurer des performances en client-serveur
◼ Techniques développées à la fin des années 70

◼ Ingres à Berkeley
◼ System R à San José
90
Schéma fonctionnel
Base
Réponse
Vue
R1
F Q
...
Rn
91
Modification de requêtes
◼ Modification de requête (Query modification)

◼ Mécanisme consistant à modifier une question au niveau
de la source en remplaçant certaines relations du FROM
par leurs sources et en enrichissant les conditions de la
clause WHERE pour obtenir le résultat de la requête
initiale.
◼ Peut être effectuée au niveau de la source ou

par concaténation d'arbres
◼ Concaténation d'arbre (Tree concaténation)
◼ Mécanisme consistant à remplacer un noeud pendant
dans un arbre relationnel par un autre arbre calculant le
noeud remplacé.
92
Exemple
◼ (1) Requête :
SELECT nom, prénom FROM grosbuveurs
WHERE adresse LIKE "versailles".
◼ (2) Définition de vue
CREATE VIEW grosbuveurs AS
SELECT nb,nom,prénom, adresse FROM buveurs b, abus a
WHERE b.nb = a.nb AND a.quantité > 10 ;
◼ (3) Requête modifiée
SELECT nom, prénom FROM buveurs b, abus a
WHERE b.adresse LIKE "Versailles" AND b.nb = a.nb AND
a.quantité > 10 ;
93
Concaténation d'arbres
Résultat
B.NOM, B.PRENOM
B.ADRESSE= "Versailles" Question
Vue Vue
B.NB, B.NOM, B.PRENOM, B.ADRESSE
A.NB B.NB Définition de vue

=
A.QTE > 10 BUVEURS B
ABUS A
94
Classification des vues
Ensemble de toutes les vues Vue théoriquement
mettable à jour
Mettable à jour en SQL
( la qualification peut invoquer
plusieurs tables)
Vues multi-tables
Vues mono-tables
avec clés
avec clés
95
Approche théorique
◼ Problème
◼ Il peut manquer des données dans la vue pour reporter
dans la BD
◼ Comment définir une stratégie de report cohérente ?
Mise à jour u
Vue Vue'
as Question V as Question V
Mise à jour répercutée u’

BD BD'
◼ L’équation u(V(B)) = V(u'(B)) doit donc être vérifiée, en

notant B la base, v le calcul de vue, u la mise à jour sur la
vue et u' les mises à jour correspondantes sur la base.
96
Les vues matérialisées
(ou vues multidimensionnelles ou

vues concrètes)
Vues multidimensionnelles
◼ Besoin des entreprises
◼ accéder à toutes les données de l’entreprise
◼ regrouper les informations disséminées dans les bases
◼ analyser et prendre des décisions rapidement (OLAP :
Online Analytical Processing )
◼ Exemples d'applications concernées

◼ bancaire : regrouper les infos d’un client
◼ réponse à ses demandes
◼ mailing ciblés pour le marketing
◼ grande distribution : regrouper les infos ventes
◼ produits à succès
◼ modes, habitudes d’achat
◼ préférences par secteurs géographiques
98
Les Entrepôts de données
◼ Datawarehouse :
Ensemble de données archivées variant dans le temps, organisées
par sujets, consolidées dans une base de données unique, gérée
dans un environnement de stockage particulier, aidant à la prise de
décision dans l’entreprise.
◼ Trois fonctions essentielles :

➢ collecte de données de bases existantes et chargement
➢ gestion des données dans l’entrepôt
➢ analyse de données pour la prise de décision
◼ Vue concrète :
Idéale pour modéliser un sous-ensemble de données extrait du
datawarehouse et ciblé sur un sujet unique
99
Vue concrète
◼ Vue concrète (Concrete view)
◼ Table calculée à partir des tables de la base par une
requête et matérialisée sur disques par le SGBD.
◼ Exemple : vues concrètes avec agrégats de la

table VENTES :
◼ VENTES (NUMV, NUMPRO, NUMFOU, DATE, QUANTITÉ,
PRIX)
◼ étendue selon les dimensions PRODUITS et

FOURNISSEURS par les tables :
◼ PRODUITS (NUMPRO, NOM, MARQUE, TYPE,PRIX)
◼ FOURNISSEURS (NUMFOU, NOM, VILLE, RÉGION, TEL.)
100
Exemple
◼ Vue des ventes totalisées par produit,
fournisseurs, dates
CREATE CONCRETE VIEW VENTESPFD (numpro,
numfou, date, compte, quantot) AS
SELECT numpro, numfou, date, COUNT(*) AS
compte, SUM(quantité) AS quantot
FROM ventes GROUP BY Numpro, Numfou, Date;
◼ Vue plus compacte (sans fournisseurs) :
CREATE CONCRETE VIEW ventespd (numpro, date,
compte, quantot) AS
SELECT numpro, date,COUNT(*)AS
compte,SUM(quantité) AS quantot
FROM ventes GROUP BY numpro, date;
101
Exemple (2)
◼ Dérivable de la vue précédente :
CREATE CONCRETE VIEW ventespd

(numpro, date, compte, quantot) AS
SELECT numpro, date,SUM(compte)AS
compte,SUM(quantot) AS quantot
FROM ventespfd
GROUP BY numfou ;
102
Le treillis des vues
◼ En OLAP, il est important de garder les vues utiles

NumPro, NumFou, Date
NumPro, NumFou NumPro, Date NumFou, Date
NumPro NumFou Date
103
Problème de mise à jour
◼ La vue peut être distante
◼ on envoie seulement le « delta »
◼ les tuples ajoutés et les tuples supprimés
◼ Vue auto-maintenable (Self-maintenable view)
◼ Vue contenant suffisamment d'information pour être mise
à jour à partir des mises à jour des relations de base, sans
accès aux tuples des relations de la base.
◼ Agrégats auto-maintenables (Self-maintenable
aggregates)
◼ Ensemble d'agrégats pouvant être calculées à partir des
anciennes valeurs des fonctions d'agrégats et des mises à
jour des données de base servant au calcul de la vue.
104
Vue auto-maintenable ou non
mise à jour D mise à jour D
BD BD
V q V
F(D) F’(D)
F(D) D
F’(q ,D)
V’
BD’ BD’
V’
Vue auto-maintenable : lors d’une Vue non-auto-maintenable : lors d’une

mise à jour D mise à jour D
celle-là suffit pour mettre à jour la vue celle-là ne suffit pas pour mettre à jour la
vue; il faut en plus les tuples q de la base.
105
Conception d’applications OLAP
◼ Quelques règles
◼ concrétiser les vues multidimensionnelles de base
◼ éventuellement concrétiser des vues compactées
◼ permet d’optimiser le « drill-down »
◼ évite les calculs d’agrégats dynamiques
◼ ne jamais concrétiser des vues non auto-maintenables
106
Confidentialité
◼ Principes :
◼ objectifs :
◼ protéger les données d’accès intempestifs

◼ autoriser certains accès
◼ outils :
◼ déclaration de l’utilisateur à la connexion
◼ catégories de pouvoir (mises à jour du schéma, mises
à jour des données, consultation)
◼ autorisations locales à chaque table
◼ vues
107
Confidentialité et droits d’accès
Commande SQL pour donner des droits :
GRANT privilèges ON table (ou vue) TO user
[WITH GRANT OPTION] ;
avec :
◼ privilèges = ALL ou
{select, insert, update, delete, alter, index}
◼ table = train, ou Félix.train (pour la table d’un autre

utilisateur Félix)
◼ utilisateur = Thérèse, ou
PUBLIC (pour tous les utilisateurs)
◼ with grant option : possibilité de transmettre ces droits
108
Confidentialité et droits d’accès
Commande SQL pour supprimer des droits :
REVOKE privilèges ON table (ou vue) FROM user ;
◼ Si l’option « with grant option » a été utilisée alors les

droits sont révoquées en cascade
109
Gestion de la concurrence
- Transactions
- Gestion de la persistance
- Gestion de la reprise sur panne
- Gestion de la concurrence d’accès
Suite des problèmes BD
◼ La résolution des trois problèmes suivants
(persistance, reprise sur panne, concurrence)
nécessite de manipuler les données sous le
contrôle de transactions
◼ Une transaction est une suite d’ordres SGBD tels
que tous sont exécutés ou aucun ne l’est
◼ début de transaction : premier ordre qui suit la
connexion au serveur ou la fin d’une transaction
◼ fin de transaction :
◼ annulation, ou
◼ confirmation (la transaction est alors dite validée)
111
Gestion des transactions
Définition
◼ Une transaction est la plus petite unité logique de traitements regroupant un ensemble d’opérations
élémentaires (commandes SQL). Ces opérations doivent être exécutées entièrement, soit pas du
tout, permettant ainsi à la base de données de passer d’un état cohérent à un nouvel état cohérent.
Exemple : Transfert bancaire d’un compte à un autre
◼ Pourquoi une transaction ?

◼ Supposons maintenant que nous soyons dans un environnement défaillant, dans ce cas, les mises à jour déjà
effectuées seront prises en compte, mais le programme ne pourra pas être en mesure de redémarrer là où il
s’était arrêté.
◼ Exemple du Transfert bancaire d’un compte à un autre
Lire compte courant de M. TOTO
Retrancher 5000 €
Ecrire résultat dans compte courant
PANNE
Lire compte livret de M. TOTO
Ajouter 5000 €
Ecrire résultat dans compte livret
Dans cet exemple, si aucune précaution n’est prise, la mise à jour du compte courant est enregistré
avant que celle du compte livret ne le soit.
Bilan : M. TOTO a perdu 5000 € sans les avoir dépensés !
112
Gestion des transactions
Propriétés
◼ La transaction est validée lorsque toutes ses opérations ont été prises en
compte. Cette validation a lieu lorsque la transaction est terminée (état
connu par le système grâce au mot clé END TRANSACTION) ou lorsque
le programme contient l’ordre de validation COMMIT.
◼ Si au contraire, une panne se produit, ou si la transaction n’arrive pas
jusqu’à la fin, la transaction est avortée (ABORT) déclenchant ainsi un
retour arrière dynamique (ROLLBACK).
◼ Ce retour arrière a pour effet de “ défaire ” toutes les opérations
effectuées par la transaction jusqu’au dernier COMMIT de celle-ci (s’il
existe) ou sinon jusqu’au début de la transaction.
◼ Le gestionnaire des transactions un identifiant unique pour chacune des
transaction permettant de les repérer et attache ensuite cet identifiant à
toutes les opérations contenues dans celle-ci.
113
Confirmation d’une transaction
◼ Explicites : COMMIT;
◼ Implicites (Oracle) :
◼ commande de déconnexion en mode interactif
◼ tout ordre de mise à jour du schéma (create, drop,
alter…)
◼ Commande « grant »
◼ toute mise à jour des données en mode de
confirmation automatique (autocommit on)
◼
◼ Effet : confirme toutes les mises à jour depuis le

début de la transactions (i.e. depuis la dernière
confirmation ou annulation)
114
Annulation d’une transaction
◼ Explicites : ROLLBACK;
◼ Implicites : déconnexion anormale (autre que
« exit »)
◼ Effet : annule toutes les mises à jour depuis le

début de la transactions (i.e. depuis la dernière
confirmation ou annulation)
115
Remarques sur les transactions
◼ Au cours de la transaction, existence d’une « table

virtuelle locale » différente de la table visible par
tous jusqu’à confirmation des mises à jour
◼ Si un ordre échoue sans faire échouer le

programme (ex : insertion dans des colonnes
inconnues), alors ses éventuels effets sont annulés,
mais pas ceux des autres ordres de la transaction
116
Gestion de la Persistance
◼ Certaines mises à jour sont provisoires, d’autres
doivent persister
◼ En fin de session, une donnée persiste si et
seulement si :
◼ elle est dans une table
◼ une confirmation a eu lieu
◼ instruction de confirmation : Commit
◼ instruction d’annulation : Rollback
◼ Une mise à jour persiste ssi elle fait partie d’une
« transaction validée »
117
Gestion de la Reprise sur panne
◼ Exemple de situation :
◼ données : Thérèse a un compte à la BF
Félix a un compte à la BF
◼ action : Thérèse doit verser 1000 euros à Félix
◼ contraintes : les virements internes préservent le

montant total de la BF
◼ programme implémentant l’action :
begin
compte(Thérèse) – = 1000;
compte(Félix) + = 1000;
end
118
Reprise sur panne
◼ Exemple de situation (suite) :
◼ déroulement :
1. compte(Thérèse) – = 1000;
2. Panne
◼ problème : la contrainte n’est plus satisfaite
◼ solution : utilisation de transaction (atomicité du

programme)
begin
compte(Thérèse) – = 1000;
compte(Félix) + = 1000;
commit;
119
Gestion de la concurrence d’accès
◼ L’une des fonctions du noyau d’un SGBDR est d’assurer la gestion des accès
concurrents dans les environnements multi-utilisateurs. Selon la norme ANSI/ISO
du langage SQL, la gestion des accès concurrents consiste à assurer la
sérialisation des transactions multiples accédant simultanément aux mêmes
données. Cette sérialisation consiste à s’assurer que l’exécution simultanée d’un
ensemble de transactions accédant aux mêmes données fournit le même résultat
que leur exécution en série.
◼ La gestion des accès concurrents est basée sur les concepts d’intégrité, de
concurrence et de consistance de données. Elle utilise essentiellement la
technique de verrouillage de données.
◼ Intégrité des données :
◼ L’intégrité des données est assurée en respectant les différentes contraintes
d’intégrité définies lors de la création de la base de données. En particulier,
cette intégrité doit être assurée suite à une mise à jour de mêmes données par
différents utilisateurs. La base de données doit passer d’un état cohérent avant
les mises à jour à un autre état cohérent après les mises à jour.
◼ Concurrence des données :
◼ La concurrence des données consiste à assurer une coordination des accès
concurrents de plusieurs utilisateurs aux mêmes données. Plus le nombre
d’utilisateurs pouvant accéder simultanément aux mêmes données, plus le
degré de concurrence devient important. 120
Gestion des accès concurrents (suite)
◼ Consistance des données :
◼ La consistance des données est assurée lorsque ces données restent inchangées jusqu’à
la fin d’une opération de mise à jour ou de lecture, c’est-à-dire que, lorsqu’un utilisateur
utilise ces données en lecture ou en mise à jour, elles doivent rester dans un état
consistant (inchangé) jusqu’à la fin de l’opération même si d’autres transactions essaient
de la modifier.
◼ Consistance des données en lecture (READ CONSISTENCY)
◼ Lors du traitement d’une commande de mise à jour, le SGBDR donne pendant tout
le temps de traitement de cette commande la même image des données prise au

début de son exécution. Les modifications effectuées par cette commande ne
deviennent visibles qu’après sa validation.
◼ Exemple :
Utilisateur 1 Temps Utilisateur2

Mise à jour table T t1
t2 Lecture table T
Validation de la MAJ de T t3
t4 Lecture table T
La lecture effectuée sur la table T à l’instant t2 par l’utilisateur2 ne voit pas les
modifications apportées par l’utilisateur1. Par contre, la lecture effectuée à l’instant
t4 voit les modifications apportées par l’utilisateur 1 car il y a eu lieu validation à
l’instant t3. 121
Gestion de la concurrence d’accès
Exemple de concurrence
delete T where a=1 update T set a=3 where b=2

Client 1 Client 2
serveur
T A B État final ?
1 2
122
Concurrence
Exemple de situation de concurrence :

Réservations
Client place
Programme de réservation
Pierre 1 Next_libre() = select min(place)
from réservations
NULL 2 where client is not null
= -1 si complet
NULL 3
Réservation(x) = si n=next_libre() != -1
alors update réservation
set client = x
where place = n;
123
Situation de concurrence
Temps
Agence 1 Agence 2
Nextlibre()
2 Nextlibre()
2
update réservation
set client = ‘Félix’ update réservation
where place = 2; set client = ‘Thérèse’
where place = 2;
124
Temps
Agence 1 Agence 2
Nextlibre()
2 Nextlibre()
Demande de verrou 2
Verrou accordé
update réservation
set client = ‘Félix’ update réservation
where place = 2; set client = ‘Thérèse’
. where place = 2;
.
Verrou relaché .
attente
update réservation
set client = ‘Thérèse’ where place = 2;
125
Temps
Agence 1 Agence 2
Demande de verrou
Verrou accordé
Nextlibre()
2 Nextlibre()
2
update réservation update réservation
set client = ‘Félix’ set client = ‘Thérèse’
where place = 2; where place = 2;
.
.
Verrou relaché attente
.
update réservation
126
Temps
Agence 1 Agence 2
Demande de verrou
Verrou accordé
Demande de verrou
Nextlibre()
2 .
.
.
attente
update réservation
set client = ‘Félix’
where place = 2;
Verrou relaché Verrou accordé
Nextlibre()
3
update réservation
127
Verrouillage des données
Concepts de base
◼ Pour que l’exécution simultanée de plusieurs transactions donne le même résultat qu’une
exécution séquentielle, la solution utilisée consiste à verrouiller momentanément les données
utilisées par une transaction jusqu’à la fin de la mise à jour. Les autres transactions demandant
ces données sont mises en attente jusqu’à leur libération (déverrouillage). Cette technique de
verrouillage permet d’éviter les interactions destructives des transactions, c’est-à-dire les
opérations n’assurant pas l’intégrité des données. Le cas typique destructive est la perte de
mise à jour
La figure suivante donne un exemple de perte de mise à jour.
Transaction 1 Temps Transaction 2
Lecture A (A=50) t0
Calcul A = A + 10 t1 Lecture A (A=50)
Ecriture A (A=60) t2 Calcul A = A+20
t3 Ecriture A (A=70)
Validation T1 t4
t5 Validation T2
L’absence de verrouillage de données a pour conséquence la perte de la mise à jour faite par la
transaction T1. Au lieu que D1 ait comme résultat final la valeur 80 (50+10+20), elle n’a que
70, car la mise à jour effectuée par T1 n’a pas été prise en compte.
Le verrouillage s’applique d’une façon générale à une ressource. Une ressource peut correspondre
aux objets créés par les utilisateurs tels que les tables (ou uniquement quelques lignes d’une
table), ainsi qu’aux objets système tels que les éléments du dictionnaire et la mémoire. 128
Granule de verrouillage
◼ Un paramètre important qui affecte les performances est le
niveau de verrouillage des données, appelé aussi granule
de verrouillage. Ce granule peut être logique (une table,
une ligne) ou physique (segment, extension, bloc, fichier).
La taille du granule influence le degré de concurrence. Un
petit granule favorise la concurrence, mais il entraîne des
contrôles plus importants.
◼ Généralement les petits granules (ligne) sont mieux adaptés
aux transactions courtes ne manipulant qu’un faible volume
de données (quelques lignes), alors que des granules plus
importants sont mieux adaptés aux transactions lourdes.
129
Granule de verrouillage
◼ Types de verrous :
◼ sur relations (verrous X - exclusive)
◼ sur n-uplets (verrous RX – row exclusive)
◼ Incompatibilités :
◼ X/X ou X/RX : même table
◼ RX/RX : n-uplets communs au deux sélections
130
Demande de verrous
◼ Demande de verrous :
◼ Explicite : LOCK Table T in EXCLUSIVE MODE
◼ Implicite : Update, Delete
◼ Attribution de verrous :
◼ Si incompatibilité sur les ressources à verrouiller avec
verrous déjà accordés , alors mise en attente
◼ Relâche de verrous :
◼ Validation (Commit)
◼ Annulation (Rollback)
131
Types de verrouillage
◼ Oracle utilise deux niveaux de verrouillage des données :
verrouillage des lignes (row locks) et verrouillage des tables.
La combinaison de ces deux niveaux de verrouillage donne
lieu aux cinq modes de verrouillage suivants :
◼ Mode lignes partagées (Row Share ou RS)

◼ Mode lignes exclusives (Row eXclusive ou RX)
◼ Mode table partagée (Share ou S)
◼ Mode partage exclusif de lignes (Share Row
Exclusive ou SRX)
◼ Mode table exclusive (Exclusive ou X)
132
Compatibilité entre les modes de verrouillage
Compatibilité (O/N)
avec les autres modes
de verrouillage
Mode de verrouillage Commandes SQL RS R S SR X
correspondantes X X
RS : Lignes partagées - Select ...from ... for update
- Lock table ... in row share O O O O N
mode
- Insert into ...
- Update ...
- Delete from ...
RX : Lignes exclusives O O N N N
- Lock table ... in row exclusive
mode
S : Table partagée - Lock table ... in share mode O N O N N
SRX : Partage exclusif - Lock table ... in share O N N N N
de lignes exclusive mode
X : Table exclusive Lock table ... in exclusive mode N N N N N
133
Mises à jour concurrentes
1. Demande de verrou sur les n-uplets satisfaisant la
condition de sélection (where)
2. S’il n’y a pas d’incompatibilité avec les verrous déjà
posés, alors obtention du verrou et exécution de la mise
à jour sur la « table virtuelle locale »
3. Sinon attente de la relâche des verrous incompatibles,
puis
• obtention du verrou
• réévaluation de la condition de sélection sur les n-
uplets présélectionnés
• Exécution de la mise à jour sur cette nouvelle
sélection
4. Relâche du verrou lors de la validation ou annulation
134
Remarques
◼ Verrouillage de ressources : gêne pour les

utilisateurs, donc à minimiser
◼ Éviter les demandes de verrous mutuellement

bloquants (deadlocks)
attente
client 1 client 2
attente
Le client 1 attend la relâche d’un verrou du client 2

et inversement
135
LES INDEX
Les Index
◼ Les index permettent d'accélérer les sélections
◼ Un index utilise des techniques informatiques
pour rendre très rapide les accès aux valeurs
d'une colonne
◼ Select * From emp Where nomE = 'Dupond'
sera très longue si la table emp contient des
millions de noms
◼ Un index bien construit permet d'obtenir
l'emplacement des informations sur Dupond en
quelques accès disques (de l'ordre de la dizaine
s'il y a des millions de lignes)
137
Création et Suppression d’index
CREATE [UNIQUE] INDEX NomIndex ON
MaTable (col1, col2,…) ;
Create Unique Index nomE On emp(nomE);

◼ Après sa création un index est mis à jour
automatiquement par le SGBD
◼ Il est transparent pour l'utilisateur : il interroge
la base de la même façon que s'il n'existait pas
mais le SGBD peut l'utiliser s'il pense que la
requête sera accélérée
◼ DROP INDEX nomIndex ;
138
MongoDB: Introduction
Amadou Sonko
MongoDB: Definition
MongoDB is a document database designed for ease of development and

scaling
MongoDB offers both a Community and an Enterprise version of the database

MongoDB: Key features
High Performance
● Support for embedded data models reduces I/O activity on database system
● Indexes support faster queries and can include keys from embedded documents
and array
Rich Query Language
● CRUD
● Data aggregation
● Text search
● Geospatial queries
MongoDB: Key features
High Availability
● Automatic failover
● Data redundancy
Horizontal Scalability
● Sharding distributes data across a cluster of machines

● Zones of data based on the shard key.
Documents
Documents : Definition
● MongoDB stores data records as BSON documents

● BSON is a binary representation of JSON documents
● A document is a data structure composed of field and value pairs
● Field names are strings
● The values of fields may include other documents, arrays, and arrays of
documents
● MongoDB stores documents in collections (equivalent of tables in a
relational database)
Documents : Example
Source: mongodb.com
Documents: BSON types
Each BSON type has both integer and string identifiers

Type Number Alias
Double 1 “double”
String 2 “string”
Object 3 “object”
Array 4 “array”
ObjectId 7 “objectId”
Documents: BSON types
Type Number Alias
Boolean 8 "bool"
Date 9 "date"
Null 10 "null"
Regular Expression 11 "regex"
JavaScript 13 "javascript"
32-bit integer 16 "int"
Timestamp 17 "timestamp"
64-bit integer 18 "long"
Decimal128 19 "decimal"
Min key -1 "minKey"
Max key 127 "maxKey"

BSON Types: ObjectId
ObjectIds are small, likely unique, fast to generate, and ordered
ObjectId values are 12 bytes in length, consisting of:
● a 4-byte timestamp value, representing the ObjectId's creation, measured in

seconds since the Unix epoch
● a 5-byte random value
● a 3-byte incrementing counter, initialized to a random value
Documents : id
The field name _id is reserved for use as a primary key
Its value must be unique in the collection
It is immutable
It may be of any type other than an array
If an inserted document omits the _id field, the MongoDB driver automatically
generates an ObjectId for the _id field.
Documents : Fields
The use of $ and . in field names is not recommended
MongoDB uses the dot notation to access the elements of an array and to
access the fields of an embedded document
"<array>.<index>" to access an element of an array by the zero-based index

position
"<embedded document>.<field>" to access a field of an embedded document

Documents : Advantages
Documents correspond to native data types in OOP languages
Embedded documents and arrays reduce need for expensive joins
Dynamic schema supports fluent polymorphism

Documents : Limitations
The maximum BSON document size is 16 megabytes
MongoDB preserves the order of the document fields following write operations
except for the following cases:
● The _id field is always the first field in the document

● Updates that include renaming of field names may result in the reordering
of fields in the document
Collections
Collections: Definition
MongoDB stores documents in collections
Collections are analogous to tables in relational databases
Source: mongodb.com
Collections: Creation
Explicit creation:
MongoDB provides the db.createCollection() method to explicitly create a

collection with various options
Implicit creation:
If a collection does not exist, MongoDB creates the collection when you first
store data for that collection
Collections: Deletion
To drop a collection:
db.<collection_name>.drop()
Collections: Schema
By default, a collection does not require its documents to have the same
schema
With schema validation, document validation rules can be enforced for a

collection during update and insert operations
To change the structure of documents in a collection, update the documents to

the new structure
Databases
Databases
Databases hold one or more collections of documents
use <db_name> to switch to a database (existent or not) in the mongo shell
If a database does not exist, MongoDB creates the database when you first
store data for that database
Views
Views: Definition
A view is a queryable object whose contents are defined by an aggregation

pipeline on other collections or views
MongoDB does not persist the view contents to disk
A view's content is computed on-demand when a client queries the view
MongoDB does not support write operations against views
Views cannot be renamed

Views: Creation
Using createCollection:
db.createCollection(
"<viewName>",
{
"viewOn" : "<source>",
"pipeline" : [<pipeline>],
"collation" : { <collation> }
}
)
Views: Creation
Using createView:
db.createView(
"<viewName>",
"<source>",
[<pipeline>],
{
"collation" : { <collation> }
}
)
Views: Example
Given a collection survey with the following documents:
● { _id: 1, empNumber: "abc123", feedback: { management: 3, environment: 3 },

department: "A" }
● { _id: 2, empNumber: "xyz987", feedback: { management: 2, environment: 3 },
department: "B" }
● { _id: 3, empNumber: "ijk555", feedback: { management: 3, environment: 4 },
department: "A" }
Views: Example
db.createView(
"managementFeedback",
"survey",
[ { $project: { "management": "$feedback.management", department: 1 } } ]
)
Views: Example
db.managementFeedback.find() returns the following documents:
● { "_id" : 1, "department" : "A", "management" : 3 }

● { "_id" : 2, "department" : "B", "management" : 2 }
● { "_id" : 3, "department" : "A", "management" : 3 }
db.managementFeedback.aggregate([ { $sortByCount: "$department" } ] ):
● { "_id" : "A", "count" : 2 }

● { "_id" : "B", "count" : 1 }
Views: Deletion
To remove a view, use the db.collection.drop() method on the view

CRUD Operations
Create: Definition
Create operations add new documents to a collection
If the collection does not currently exist, insert operations will create the
collection
MongoDB provides the following methods to insert documents into a

collection:
● db.<collection_name>.insertOne()
● db.<collection_name>.insertMany()
Create: Examples
db.inventory.insertOne(
{ item: "canvas", qty: 100, tags: ["cotton"], size: { h: 28, w: 35.5, uom: "cm" } }
)
db.inventory.insertMany([
{ item: "journal", qty: 25, tags: ["blank", "red"], size: { h: 14, w: 21, uom: "cm" } },
{ item: "mat", qty: 85, tags: ["gray"], size: { h: 27.9, w: 35.5, uom: "cm" } },
{ item: "mousepad", qty: 25, tags: ["gel", "blue"], size: { h: 19, w: 22.85, uom:
"cm" } }
])
Read: Definition
Read operations retrieve documents from a collection
MongoDB provides the following method to read documents from a collection:
● db.collection.find()
You can specify query filters or criteria that identify the documents to return
Read: Examples
● db.inventory.find( {} ) : select all

● db.inventory.find( { status: "D" } ) : select all where status=“D”
● db.inventory.find( { status: { $in: [ "A", "D" ] } } ) : select all where status
in(“A”, “D”)
● db.inventory.find( { status: "A", qty: { $lt: 30 } } ): select all where status=”A”
and qty < 30
● db.inventory.find( { $or: [ { status: "A" }, { qty: { $lt: 30 } } ] } ) : select all
where status=”A” or qty < 30
Read: Examples
● db.inventory.find( { size: { h: 14, w: 21, uom: "cm" } } ) : all documents where

size is equal to the specified document, in that specified order
● db.inventory.find( { "size.uom": "in" } ) : all documents where the field “uom”
of the nested document “size” equals “in”
● db.inventory.find( { tags: ["red", "blank"] } ) : all documents where tags has
exactly two elements, "red" and "blank", in the specified order
● db.inventory.find( { tags: { $all: ["red", "blank"] } } ): all documents where
tags contains both “red” and “blank”
● db.inventory.find( { dim_cm: { $gt: 25 } } ): all documents where the array
dim_cm contains at least one element greater than 25
Read: Examples
db.inventory.find( { dim_cm: { $gt: 15, $lt: 20 } } ): at least one element greater

than 15, at least one element greater than 20
db.inventory.find( { dim_cm: { $elemMatch: { $gt: 22, $lt: 30 } } } ): at least one

element between 22 and 30
db.inventory.find( { "dim_cm.1": { $gt: 25 } } ): all documents where second

element of the array dim is greater than 25
Read: Examples
● db.inventory.find( { status: "A" }, { item: 1, status: 1 } ): project item, status

and _id of all documents where status=”A”
● db.inventory.find( { status: "A" }, { item: 1, status: 1, _id: 0 } ): project only
item and status of all documents where status=”A”
● db.inventory.find( { status: "A" }, { status: 0, instock: 0 } ): project all fields
except for status and instock
● Warning: With the exception of the _id field, you cannot combine inclusion
and exclusion statements in projection documents.
● db.inventory.find( { item: null } ): all documents where item is null
Update: Definition
Update operations modify existing documents in a collection
MongoDB provides the following methods to update documents of a collection:
● db.<collection_name>.updateOne()
● db.<collection_name>.updateMany()
● db.<collection_name>.replaceOne()
● db.<collection_name>.update()
Once set, you cannot update the value of the _id field nor can you replace an existing
document with a replacement document that has a different _id field value
Update: Definition
You can specify criteria, or filters, that identify the documents to update
These filters use the same syntax as read operations
MongoDB provides update operators, such as $set, to modify field values
To use the update operators, pass to the update methods an update document
of the form:
{
<update operator>: { <field1>: <value1>, ... },
<update operator>: { <field2>: <value2>, ... }
}
Update operators: Fields
Name Description
$currentDate Sets the value of a field to current date, either as a Date or a Timestamp.
$inc Increments the value of the field by the specified amount.
$min Only updates the field if the specified value is less than the existing field value.
$max Only updates the field if the specified value is greater than the existing field value.
$mul Multiplies the value of the field by the specified amount.
$rename Renames a field.
$set Sets the value of a field in a document.
$setOnInsert Sets the value of a field if an update results in an insert of a document. Has no effect on update
operations that modify existing documents.
$unset Removes the specified field from a document.

Update operators: Array
Name Description
$ Acts as a placeholder to update the first element that matches the query condition.
$[] Acts as a placeholder to update all elements in an array for the documents that match the
query condition.
$[<identifier>] Acts as a placeholder to update all elements that match the arrayFilters condition for the
documents that match the query condition.
$addToSet Adds elements to an array only if they do not already exist in the set.
$pop Removes the first or last item of an array.
$pull Removes all array elements that match a specified query.
$push Adds an item to an array.
$pullAll Removes all matching values from an array.

Update operators: Modifiers and Bitwise
Name Description
$each Modifies the $push and $addToSet operators to append multiple items for array updates.
$position Modifies the $push operator to specify the position in the array to add elements.
$slice Modifies the $push operator to limit the size of updated arrays.
$sort Modifies the $push operator to reorder documents stored in an array.
$bit Performs bitwise AND, OR, and XOR updates of integer values
Update: Examples
Some update operators, such as $set and $currentDate, will create the field if
the field does not exist.
db.inventory.updateOne(
{ item: "paper" },
{
$set: { "size.uom": "cm", status: "P" },
$currentDate: { lastModified: true }
}
)
Update: Examples
db.inventory.updateMany(
{ "qty": { $lt: 50 } },
{
$set: { "size.uom": "in", status: "P" },
$currentDate: { lastModified: true }
}
)
Update: Examples
db.inventory.replaceOne(
{ item: "paper" },
{ item: "paper", instock: [ { warehouse: "A", qty: 60 }, { warehouse: "B", qty: 40 } ] }
)
Update: additional methods
db.<collection_name>.findOneAndReplace()
db.<collection_name>.findOneAndUpdate()
db.<collection_name>.findAndModify()
db.<collection_name>.bulkWrite()
Delete: Definition
Delete operations remove documents from a collection
MongoDB provides the following methods to delete documents of a collection:
● db.collection.deleteOne()
● db.collection.deleteMany()
You can specify criteria, or filters, that identify the documents to remove
These filters use the same syntax as read operations
Delete operations do not drop indexes, even if deleting all documents from a collection
Delete: Examples
db.inventory.deleteMany({}) deletes all documents from the inventory collection
db.inventory.deleteMany({ status : "A" }): deletes all where status is ”A”
db.inventory.deleteOne( { status: "D" } ) : deletes first where status is “D”

Delete: Additional methods
db.<collection_name>.remove(<query>,<justOne>)
db.<collection_name>.findOneAndDelete()
Bulk write
Bulk write: Definition
MongoDB provides clients the ability to perform write operations in bulk with
the method:
db.<collection_name>.bulkWrite()
Bulk write operations can be either
● Ordered (default): serially executed and operation N+1 executed only if

operation N succeeds
● Or unordered (ordered:false in options document): might be parallel and all
are executed
Bulk write: Definition
Bulk write supports the following write operations: insertOne, updateOne,
updateMany, replaceOne, deleteOne, deleteMany
Each write operation is passed to bulkWrite() as a document in an array
db.<collection_name>.bulkWrite(
[ <operation 1>, <operation 2>, ... ],
{
ordered : <boolean>
}
)
Bulk write: Syntax
● InsertOne:
db.<collection_name>.bulkWrite( [
{ insertOne : { "document" : <document> } }
])
● updateOne (same as updateMany):
db.<collection_name>.bulkWrite( [
{ updateOne : { "filter": <document>, "update": <document or pipeline> } }
])
Bulk write: Syntax
● replaceOne:
db.<collection_name>.bulkWrite([
{ replaceOne : { "filter" : <document>, "replacement" : <document> } }
])
● deleteOne (same as deleteMany):
db.<collection_name>.bulkWrite([
{ deleteOne : { "filter" : <document> } }
])
Bulk write: Example
try {
db.characters.bulkWrite([
{ insertOne: { "document": { "_id": 4, "char": "Dithras", "class": "barbarian", "lvl": 4 } } },
{ updateOne : {
"filter" : { "char" : "Eldon" },
"update" : { $set : { "status" : "Critical Injury" } }
} },
{ deleteOne : { "filter" : { "char" : "Brisbane"} } },
{ replaceOne : {
"filter" : { "char" : "Meldane" },
"replacement" : { "char" : "Tanys", "class" : "oracle", "lvl": 4 }
}}
]);
} catch (e) {
print(e);
}
Text Search
Text Search
MongoDB supports query operations that perform a text search of string content
To perform text search queries, you must have a text index on your collection
A collection can only have one text search index
A text index can include one or several fields whose value is a string or an array of
string elements
Views do not support text search
The following creates an index over the fields name and description of the collection
stores:
db.stores.createIndex( { name: "text", description: "text" } )

Text Search
Use the $text query operator to perform text searches on a collection with a text
index
$text will tokenize the search string using whitespace and most punctuation as
delimiters, and perform a logical OR of all such tokens in the search string
The following query will find all stores containing any terms from the list "coffee",
"shop", and "java":
db.stores.find( { $text: { $search: "java coffee shop" } } )

Text Search
You can also search for exact phrases by wrapping them in double-quotes
The following will find all stores containing "coffee shop":
db.stores.find( { $text: { $search: "\"coffee shop\"" } } )
To exclude a word, you can prepend a "-" character
The following will find all stores containing "java" or "shop" but not "coffee":
db.stores.find( { $text: { $search: "java shop -coffee" } } )

Text Search
Text search queries will compute a relevance score for each document that
specifies how well a document matches the query
To sort the results in order of relevance score, you must explicitly project the $meta
textScore field and sort on it
db.stores.find(
{ $text: { $search: "java coffee shop" } },
{ score: { $meta: "textScore" } }
).sort( { score: { $meta: "textScore" } } )
Aggregation Pipeline
Aggregation Pipeline: Definition
The aggregation pipeline is a framework for data aggregation modeled on the
concept of data processing pipelines. MongoDB provides the
db.<collection_name>.aggregate() method to run the aggregation pipeline
Documents enter a multi-stage pipeline that transforms the documents into

aggregated results. For example:
db.orders.aggregate([
{ $match: { status: "A" } },
{ $group: { _id: "$cust_id", total: { $sum: "$amount" } } }
])
Aggregation Pipeline: Stages
Each stage transforms the documents as they pass through the pipeline
Pipeline stages do not need to produce one output document for every input
document
Some stages may generate new documents or filter out documents
Syntax: db.collection.aggregate( [ { <stage> }, ... ] )

Aggregation Pipeline: Stages
Stage Description
$count Returns a count of the number of documents at this stage of the aggregation pipeline
$group Groups input documents by a specified identifier expression and applies the accumulator
expression(s), if specified, to each group
$limit Passes the first n documents unmodified to the pipeline where n is the specified limit
$match Filters the document stream to allow only matching documents to pass unmodified into the next
pipeline stage
$merge Writes the resulting documents of the aggregation pipeline to a collection
$out Writes the resulting documents of the aggregation pipeline to a collection
$project Reshapes each document in the stream, such as by adding new fields or removing existing
fields
$replaceRoot Replaces a document with the specified embedded document
$search Performs a full-text search of the field

Aggregation Pipeline: Examples
Considering that documents in the zipcodes collection have the following form:
{
"_id": "10280",
"city": "NEW YORK",
"state": "NY",
"pop": 5574,
"loc": [
-74.016323,
40.710537
]
}
The following operation returns states with populations above 10 Million
db.zipcodes.aggregate( [
{ $group: { _id: "$state", totalPop: { $sum: "$pop" } } },
{ $match: { totalPop: { $gte: 10*1000*1000 } } }
])
The following operation returns average city population by state
db.zipcodes.aggregate( [
{ $group: { _id: { state: "$state", city: "$city" }, pop: { $sum: "$pop" } } },
{ $group: { _id: "$_id.state", avgCityPop: { $avg: "$pop" } } }
])
Considering that the documents in the users collection have the following form:
{
_id : "jane",
joined : ISODate("2011-03-02"),
likes : ["golf", "racquetball"]
}
The following operation returns user names in upper case and in alphabetical
order:
db.users.aggregate(
[
{ $project : { name:{$toUpper:"$_id"} , _id:0 } },
{ $sort : { name : 1 } }
]
)
The following operation returns user names sorted by the month they joined:
db.users.aggregate(
[
{ $project :
{
month_joined : { $month : "$joined" },
name : "$_id",
_id : 0
}
},
{ $sort : { month_joined : 1 } }
]
)
The following operation collects top five most "liked" activities:
db.users.aggregate(
[
{ $unwind : "$likes" },
{ $group : { _id : "$likes" , number : { $sum : 1 } } },
{ $sort : { number : -1 } },
{ $limit : 5 }
]
)
Data modeling
Data modeling
Collections, by default, do not require their documents to have the same

schema
However, in practice, the documents in a collection share a similar structure
With schema validation, you can enforce document validation rules for a
collection
The key consideration for the structure of your documents is the decision to
embed or to use references
Data modeling: Embedded data
MongoDB documents make it possible to embed document structures in a field

or array within a document
A write operation is atomic on the level of a single document, even if the

operation modifies multiple embedded documents within a single document
Embedded data models make it possible to retrieve and update related data in
a single atomic operation
For many use cases, this data model is optimal.

Data modeling: Embedded data
In general, use embedded data models when:
● you have "contains" relationships between entities

● you have one-to-many relationships between entities where the "many"
documents always appear with or are viewed in the context of the "one"
documents
Data modeling: References
References store the relationships between data by including links from one document
to another
Applications can resolve these references to access the related data

Data modeling: References
In general, use references model:
● when embedding would result in duplication of data but would not provide
sufficient read performance advantages to outweigh the implications of
the duplication
● to represent more complex many-to-many relationships
● to model large hierarchical data sets
Data modeling: One-to-Many relationships
Embed the N side if the cardinality is one-to-few and there is no need to access
the embedded object outside the context of the parent object
Use an array of references to the N-side objects if the cardinality is one-to-many

or if the N-side objects should stand alone for any reasons
Use a reference to the One-side in the N-side objects if the cardinality is

one-to-squillions
NoSQL: Introduction
Amadou Sonko
● Definition
● Motivations
● Types
NoSQL ● Benefits
● Drawbacks
● NoSQL VS SQL
Definition
NoSQL (non SQL or not only SQL) databases are non tabular, and store data
differently than relational tables
NoSQL databases come in a variety of types based on their data model
NoSQL databases can store relationship data
They provide flexible schemas and scale easily with large amounts of data and
high user loads
Motivations
NoSQL databases have existed since the late 1960s, but they really emerged in
the late 2000s
A rapid decrease in storage cost
More applications
More data
Optimized for developer productivity
Agile methods
Types
Key-value databases are a simpler type of database where each item contains
keys and values
Document databases store data in documents
Wide-column stores store data in tables, rows, and dynamic columns
Graph databases store data in nodes and edges

Types
Type Performance Scalability Flexibility Complexity
Key–value high high high none
Document high variable high low
Wide-column high high moderate low
Graph variable variable high high

Benefits
Flexible data models
Horizontal scaling
Fast queries
Easy for developers

Drawbacks
Non support of ACID Transactions
Less consistent
Higher storage cost

NoSQL VS SQL
SQL NoSQL
Primary Purpose General purpose Variable
Schemas Rigid Flexible
Scaling Vertical (scale-up with a Horizontal (scale-out across

larger server) commodity servers)
Transactions Supported Mostly not supported
Joins Typically required Typically not required
Data-object mapping Requires ORM Many do not require ORMs.

(object-relational mapping)
Cours 4
Structure logique et physique

d’une base de données
relationnelle (Oracle)
1 Introduction
Selon l’architecture ANSI/SPARC, une base de données est représentée

en trois niveaux :
- le niveau conceptuel (logique),
- le niveau physique ,
- le niveau externe.
Cette séparation permet, d’une part, une indépendance entre la
sémantique des données et leur implémentation physique, et, d’autre part,
de donner des visions restreintes et adaptées à chaque type d’utilisateur.
L’un des principaux rôles du SGBDR est de permettre la description de
chacun de ces trois niveaux et d’assurer la correspondance entre eux.
ORACLE, SYBASE, ... respectent cette architecture. Toute base de
données a ainsi une structure logique et une structure Physique. Les
utilisateurs peuvent avoir des visions partielles de la structure logique à
travers des vues.
La description de ces trois niveaux et la correspondance entre eux est faite à
travers un dictionnaire de données.
2
2 Rappel : Schéma de la base de données Oracle
Un schéma est un ensemble de structures logiques de données qui

appartiennent à un utilisateur de la base de données et porte son nom. De
ce fait, un utilisateur ne peut avoir qu’un seul schéma.
Les objets qui peuvent être manipulés dans un schéma sont les suivants :
Table : structure relationnelle qui maintient les données d’une base de
données relationnelle. Une table représente une entité du monde réel ou une
relation entre entités.
Index : structure contenant l’adresse physique de chaque ligne d’une table ou
d’un cluster, il permet l’accès direct à l’information.
Vue : relation d'un schéma externe déduite des relations de la base par une
requête.
Trigger (déclencheur) : stocké sur le serveur, mais il est déclenché
automatiquement par des événements liés à des actions sur la base (exemple :
Insertion dans une table si certaines conditions sont remplies).
Procédure : ensemble nommé de commandes PL/SQL qui sont stockées dans
la base de données.
Fonction : ensemble nommé de commande PL/SQL. Elle retourne une valeur
à l’appelant contrairement à une procédure.
3
Schéma de la base de données Oracle
(suite)
Package : collection de fonctions, de procédures et d’autres objets stockés

ensemble au sein d’une base de données.
Séquence : objet de la base de données à partir duquel plusieurs utilisateurs
peuvent générer des entiers uniques.
Snapshot (cliché) : table qui contient le résultat d’une requête définie sur une
ou plusieurs tables ou vues localisées sur une base de données appelée “ base
maître ”. Les snapshots sont utilisés dans le contexte réparti et permettent de
maintenir des copies de données de la base distante sur le noeud local en
lecture seulement.
Cluster (groupement) : objet du schéma contenant une ou plusieurs tables
qui ont une ou plusieurs colonnes communes. Un cluster est une structuration
de données dans une ou plusieurs tables pour permettre un accès rapide aux
lignes issues d’une jointure.
Lien de base de données (Database link) : aucun objet dans la base locale
qui permet l’accès à une base de données distante.
4
3 Structure logique
La structure logique d’une base de données ORACLE est composée des

tablespaces, des segments, des extensions, des blocs et des objets de schéma.
Les tablespaces, les segments et les extensions permettent de définir la façon
dont la base de données (avec ses objets de schéma) est organisée physiquement.
Ils permettent donc d’effectuer le lien entre le niveau physique et le niveau logique
de la base de données.
Notion de tablespace : Une base de données est composée d’un ensemble
d’unités logiques appelées tablespaces.
Un tablespace est utilisé pour regrouper un ensemble d’objets logiques. Chaque
objet logique doit être associé à un et à un seul tablespace.
On peut utiliser cette notion de tablespace pour regrouper, par exemple, des objets
logiques d’une application (tables, index, séquences, procédures, etc.) de façon
que des opérations telles la sauvegarde et la restauration de données soient
effectuées d’une façon efficace.
Une base de données doit avoir au moins un tablespace appelé SYSTEM qui
contient le dictionnaire de données. Il est fortement conseillé de définir au moins un
deuxième tablespace pour stocker les objets de la base.
5
Structure logique
(suite)
La création de tablespace doit se faire avec la commande suivante :
CREATE TABLESPACE nom-tablespace
DATAFILE spécif-fichier [, spécif-fichier,...]
[DEFAULT STORAGE (spécif-stockage)]
[ONLINE | OFFLINE];
nom-tablespace : nom du tablespace à créer
spécif-fichier : spécification du fichier physique de données (nom, taille)
spécif-stockage : Paramètres applicables par défaut à tous les objets affectés à ce
tablespace. Cf. paragraphe “ EXTENSION ” : clause STORAGE .
ONLINE : le tablespace est actif dès qu’il est créé.
OFFLINE : le tablespace est inactif après sa création
Exemple : CREATE TABLESPACE ts_logistique
DATAFILE ‘/usr1/base/fichier1.dbf’ SIZE 1 M,
‘/usr2/base/fichier2.dbf’ SIZE 1 M
DEFAULT STORAGE (INITIAL 100K NEXT 100K
MINEXTENT 1 MAXEXTENT 5 PCTINCREASE 50);
6
Structure logique
(suite)
Segment, Extension et Bloc .

Lors de la création d’un fichier, Oracle réserve tout l’espace qui lui est associé.
A l’intérieur de ce fichier, l’espace disque est géré dynamiquement au fur et à
mesure de l’utilisation de la base de données.
Cette gestion dynamique se fait selon trois niveaux de granularité : le segment,
l’extension et le bloc.
Le niveau le plus fin de granularité est le bloc. Il est composé d’un certain
nombre d’octets. Sa taille est définie au moment de la création de la base de
données.
l’extension (l’extent) constitue le deuxième niveau de granularité. C’est une
suite de blocs contigus alloués simultanément et utilisés pour le stockage d’un
type spécifique de données.
7
Structure logique
(suite)
Segm ent - Extension - Blocs

SEGM EN T 1
Extension 1 Extens ion2
B LO C
U n s e g m e n t c o r r e s p o n d à u n e n s e m b le d ’e x te n s io n s a llo u é e s à u n e s tr u c tu r e
lo g iq u e (D A T A S E G M E N T , IN D E X S E G M E N T , R O L L B A C K S E G M E N T ,
TEM PO RARY SEG M EN T,
8
Structure logique
Bloc de données
Un bloc de données est la plus petite unité logique d’entrée/sortie utilisée
par Oracle. il est également appelé bloc logique ou page. Cette notion de
bloc de données est différente de celle de bloc physique utilisé par les
systèmes d’exploitation.
La taille d’un bloc de données est variable selon les systèmes

d’exploitation. Elle peut varier généralement de 2 à 4 Ko. La modification
de la taille par défaut des blocs logiques se fait à travers le paramètre
DB_BLOCK_SIZE dans le fichier d’initialisation (INIT.ORA).
Les blocs de données sont organisés de la même façon, quel que soit leur
contenu : données, Index ou Cluster.
9
Structure logique
Extension
L’extension est une unité logique d’allocation d’espace composée d’un ensemble
contigu de blocs allouées simultanément à un segment. Tout segment est
initialement créé avec au moins une extension. Cette extension est appelée
extension initiale . Lorsque l’espace d’un segment est complètement utilisé,
Oracle lui attribue une nouvelle extension (extension supplémentaire).
Paramètres relatifs à l’utilisation des extensions : Ces paramètres sont définis
à l’aide de clause STORAGE.
STORAGE (INITIAL n1 EXTENT n2 MINEXTENT m1 MAXEXTENT m2
PCTINCREASE p)
avec
n1 : Taille en octet de la première extension allouée lorsqu’un segment est créé.
n2 : Taille en octets de la deuxième extension allouée au segment.
m1 : Nombre d’extensions allouées à la création du segment.
m2 : Nombre total d’extensions pouvant être allouées à un segment.
p : Pourcentage d’accroissement de la taille du segment i+1 par rapport à celle du
segment i (i>2).
10
Structure logique
Extension
Exemple :
STORAGE (INITIAL 100K NEXT 100K MINEXTENT 1 MAXEXTENT 5 PCTINCREASE 50)
La taille des différentes extensions est la suivante :
1ère extension : 100 K
2ème extension : 100 K
3ème extension : arrondi (100*1,5) = 150 K
4ème extension arrondi (150*1,5) = 225 K
5ème extension arrondi (225*1,5) = 337 K
Remarque : La clause STORAGE peut être utilisée dans des différentes commandes de
création ou de modification d’objets Oracle (tables, index, etc.). Si cette clause est définie à
différents niveaux, l’ordre de priorité est le suivant :
Tout paramètre défini au niveau d’un objet Oracle remplace celui défini au niveau du
tablespace.
A tout paramètre non défini au niveau d’un objet Oracle est appliquée par défaut la valeur définie au
niveau tablespace.
En cas d’absence de définition de paramètres au niveau du tablespace, Oracle applique des valeurs
par défaut.
Si des paramètres sont modifiés, les nouvelles valeurs s’appliquent uniquement aux extensions non
encore allouées.
11
Structure logique
Segment
Un Segment est un ensemble d’une ou plusieurs extensions contenant les
données d’une structure logique dans un tablespace. A une table, par
exemple, est allouée une ou plusieurs extensions.
Il existe cinq types de segments :
Segments de données,
Segments d’index,
Segments d’annulation (rollback),
Segments temporaires,
Segments d’amorçage (bootstrap).
SEGMENTS DE DONNEES
Les segments de données servent à stocker les données des tables utilisateurs et
système ainsi que celles des tables groupées (cluster).
Chaque table a un et un seul segment qui contient toutes les données de la table. Ce
segment est créé automatiquement lors de la création de la table.
La manière dont les extensions sont allouées dans un segment est précisée à l’aide des
paramètres de stockage explicités lors de la création d’une table ou d’un cluster.
12
Structure logique
Segment
SEGMENTS D’INDEX
Les segments d’index servent à stocker les données d’index séparément des données. Chaque index
est contenu dans un segment distinct. Ce segment est créé automatiquement lors de la création
d’index.
Lors de la création d’index, on peut préciser le tablespace dans lequel sera créé le segment d’index.
Ce tablespace peut être différent (fortement recommandé) de celui du segment de données de la table
associée
SEGMENTS TEMPORAIRES
Les segments temporaires sont utilisés pour effectuer le traitement des commandes SQL nécessitant
un espace disque temporaire (ORDER BY, GROUP BY, SELECT DISTINCT, UNION, MINUS,...).
Si aucun tablespace temporaire n’a été défini, c’est le tablespace SYSTEM qui est utilisé par défaut
(Très mauvais).
SEGMENTS D’AMORCAGE (BOOTSTRAP)
Le segment d’amorçage est créé dans le tablespace SYSTEM au moment de la création d’une base
de données. Il contient les définitions du dictionnaire de données qui sont chargées au moment de
l’ouverture de la base de données.
SEGMENTS D’ANNULATION (ROLLBACK)
Les segments d’annulation (rollback segment) permettent d’enregistrer les actions effectuées par les
transactions. Ils contiennent les données avant modification par les transactions, permettant ainsi
d’annuler leur effet en cas de besoin.
13
4 Structure Physique
La structure physique d’une base de données est composée

d’un ensemble de fichiers qui constituent le support physique
de stockage de données. Une base de données Oracle est
composée physiquement d’un ou plusieurs fichiers.
Les structures logiques déjà étudiées sont stockées dans ces
fichiers.
Types de fichiers :
Fichiers de données (Data files)
Fichiers de reprise (Redo Log Files)
Fichiers de contrôle (Control files)
14
Structure Physique
(suite)
Fichiers de données
Lors de la création de tablespace le ou les fichiers de données
seront spécifiés :
CREATE TABLESPACE ts_logistique
DATAFILE ‘/usr1/base/fichier1.dbf’ SIZE 1 M,
‘/usr2/base/fichier2.dbf’ SIZE 1 M
DEFAULT STORAGE (INITIAL 100K NEXT 100K
MINEXTENT 1 MAXEXTENT 5 PCTINCREASE 50)
Ces fichiers assurent le stockage des objets créés par les utilisateurs
(tables, clusters, index,...) ainsi que ceux nécessaires au
fonctionnement d’Oracle. Lors de création d’une base de données, il
doit y avoir au moins un fichier pour stocker le dictionnaire de données.
15
Structure Physique
(suite)
Fichiers de reprise
Les fichiers de reprise (Redo log) contiennent les modifications des
données les plus récentes. Ils sont au moins deux et sont utilisés d’une
façon circulaire. S’ils sont deux, par exemple, Oracle enregistre les
modifications dans le premier fichier et, lorsqu’il est plein, il passe au
second. Lorsque les deux fichiers sont pleins, il revient au premier, et
ainsi de suite.
Oracle offre la possibilité d’archiver un fichier de reprise plein avant sa
réutilisation (Archived redo log).
De même, Oracle offre la possibilité de dupliquer le fichier de reprise
pour que les informations de reprise soient écrites simultanément sur
plusieurs fichiers. Le risque de perte de ces informations est ainsi
réduit.
16
Structure Physique
(suite)
Fichiers de contrôle
Pour pouvoir démarrer une base de données, il doit y avoir au moins

un fichier de contrôle. Il contient les informations relatives à la structure
physique d’une base de données : nom de la base de données, ainsi
que les noms et la localisation des fichiers de données et de reprise.
Ce fichier est mis à jour automatiquement chaque fois qu’un fichier de

données ou de reprise est créé ou renommé.
17
5 Correspondance entre les structures physique et
logique
Base de d onn ées OR A CL E
Tablespa ces SY S TEM U SE R S
Fichiers D BS1 .OR A U SER S1.O RA U SER S2 .O R A
Segments Do nné es In dex Ro llba ck B oo tstra p T em por aire D onn ées Index
Extensions
Blocs logiques
Blocs physiques
18
6 Architecture fonctionnelle d’un SGBDR
Introduction
Architecture fonctionnelle d'un SG BDR

R equête
Tables Vues
A nalyse
Index Cluster
C orres pondance
Procédure s
M émoire O ptimisation Architecture à 3 niveaux

C ache ANSI/SPARC im plantée
sous fo rm e de DD
G estionnaire de données
SGB DR
BD
19
Architecture fonctionnelle d’un SGBDR
Introduction (suite)
De façon générale, le SGBDR a pour fonction principale de stocker des données

dans la base de données et de les restituer à la demande.
Le stockage des données a été abordé dans les précédents paragraphes.
Pour restituer des données,
il est essentiel que le SGBDR soit tout d’abord capable de comprendre ce que
l’utilisateur demande. Cette étape est une étape de vérification syntaxique de la
requête, en adéquation avec le langage SQL.
puis, il doit s’assurer que ces données soient disponibles à l’utilisateur, ce qui
représente une étape sémantique.
Il doit ensuite rechercher où se trouvent les données et comment il devra les
retrouver en analysant les différents chemins d’accès aux données.
Ces fonctions sont donc réparties dans le SGBDR sous la forme de deux grands
modules fonctionnels communiquant entre eux :
un analyseur de requête, dont le rôle est d’assurer la vérification syntaxique,
sémantique de la requête et de connaître où se trouvent les données impliquées
dans la requête.
un gestionnaire de données, chargé d’exécuter proprement dit la requête.
20
Architecture fonctionnelle d’un SGBDR
Introduction (suite)
L’analyseur de requêtes a comme objectif final de fournir donc le chemin
d’accès optimal aux données en transformant la requête SQL en un plan
d’accès aux données. Pour ce faire, après analyse syntaxique, il doit
étudier la correspondance entre les vues externes (vues Utilisateurs =
Requêtes) et la structure conceptuelle/logique (étape de vérification
sémantique) de la base de données, puis étudier la correspondance entre
la structure conceptuelle/logique et la structure physique (interne) de la
base de données.
Cette dernière étape doit fournir le meilleur moyen pour retrouver

l’adresse des blocs physique qui contiennent les données impliquées
dans la requête. Ce travail est effectué par un optimiseur de requêtes.
21
7 Les optimiseurs de requêtes
- Rôle -
L’optimiseur de requêtes constitue la première grande fonction que le SGBDR doit
assurer lors de l’exécution de requêtes en provenance de l’utilisateur (requêtes
interactives ou programme d’application).
Son rôle est déterminant, il doit permettre l’exécution la plus rapide possible de la
requête SQL. Il doit donc fournir d’une part la stratégie optimale d’exécution de la
requête, appelée le plan d’exécution de la requête et libérer d’autre part le
programmeur de la connaissance du fonctionnement des opérateurs SQL
(méfiance quand même ?).
La requête de l’utilisateur sera donc analysée dans le détail et “ brassée ” jusqu’à
l’obtention du meilleur plan pour son exécution, c’est à dire celui qui nécessitera le
moins d’Entrées / Sorties disques, en inspectant les tables système du dictionnaire
de données (DD).
La qualité d’un optimiseur de requêtes est l’un des critères qui permet de juger de
la performance du SGBDR tout entier, aussi bien en terme de temps de réponse
que de charge de travail. En effet, il ne faudrait pas que l’exécution des travaux de
préparation de l’optimiseur soit plus longue que l’exécution de la requête non
optimisée !.
22
Les optimiseurs de requêtes
- Stratégie d’exécution des plans “d’exécution” -
Systèmes compilés :
Certains optimiseurs compilent les plans d’exécution des requêtes afin de pouvoir les réutiliser
par la suite et éviter ainsi de recommencer le travail d’optimisation. Dans ce cas, au moment
de la nouvelle exécution d’une requête dont le plan a déjà été compilé puis sauvegardé,
l’optimiseur vérifie si le plan est toujours valide et, dans ce cas, le plan est exécuté à
nouveau. Cette approche est valable pour les requêtes définies dans des procédures stockées
ou cataloguées.
Systèmes interprétés :
A l’inverse, les systèmes interprétés effectuent une optimisation à chaque exécution de la
requête.
De façon générale, l’interprétation s’avère intéressante dans le cas où :
les requêtes SQL sont ad-hoc, c’est-à-dire non prévues à l’avance ou lorsque les applications
contiennent des ordres SQL dynamiques, c’est-à-dire dans lesquelles les paramètres de la
requêtes sont à saisir par l’utilisateur au moment de l’exécution de la requête. En effet, il y a
alors peu de chance pour que le même plan puisse être exécuté à nouveau, la requête
manipulant généralement des volumes de données différents à chaque fois;
le schéma ou le contenu de la base change fréquemment; dans ce cas, les plans d’exécution
des requêtes seront souvent rendus caducs et la perte de temps lors de la compilation ne
s’avère donc pas justifiée.
23
- Stratégie d’exécution des plans “d’exécution” -
Systèmes mixtes :
Certains optimiseurs interprétés sauvegardent quand même des résultats pour les
utiliser ultérieurement (systèmes mixtes). L’optimiseur conserve alors en mémoire
centrale les plans qu’il a exécutés récemment et essaie, lorsqu’une nouvelle requête
arrive, de trouver un plan équivalent. Si cette recherche échoue, du fait d’une requête
plus complexe, il essaie alors de trouver des morceaux de plans qui pourraient être repris
pour composer le plan final de la requête.
24
- Modes d’évaluation du coût d’une requête -
Optimisation basée sur les statistiques :
La méthode statistique est disponible dans plusieurs SGBDR du marché. Cette méthode se base sur
des statistiques relatives aux tables pour déterminer le meilleur chemin d’accès. Ces statistiques
concernent le volume des tables (nombre de lignes), le nombre de blocs alloués à la table, le nombre
de valeurs distinctes de chaque colonne, les valeurs minimale et maximale des colonnes, la
distribution de la clé, le nombre de valeurs différentes d’un index.
Ces statistiques sont mises à jour automatiquement (ce qui requiert du temps),
ou à la demande de l’Administrateur de la base de données, ou encore lorsqu’un événement apparaît
(de type “ trigger ” par exemple), par modification des tables système correspondant
Optimisation basée sur les heuristiques :
Le coût d’une requête peut être également obtenu en utilisant des heuristiques, c’est-à-dire un
ensemble des règles permettant de guider l’évaluation.
L’utilisation d’heuristiques fournit un plan contenant la liste classée des opérations à effectuer pour
satisfaire la requête. Cette liste est obtenue par consultation des coûts relatifs de chaque opération.
Cette solution est très intéressante dans le cas où la distribution des données suit les heuristiques, car
elle permet d’éviter l’évaluation des fonctions de coûts.
Par ailleurs, certains optimiseurs utilisent des techniques d’intelligence artificielle et emploient des
heuristiques de nature différente, représentant des règles de savoir-faire. Celles-ci permettent
d’éliminer certains plans jugés trop longs après l’expérience que l’optimiseur possède. En général, ces
règles de savoir-faire sont figées dans le SGBDR.
25
- Limites -
Limites de l’optimiseur
Tout optimiseur a des limites qu’il est bon de pouvoir cerner : limites en
nombre maximal de tables manipulées, de jointures, de sous-requêtes
imbriquées.
Informations fournies par l’optimiseur

Il est essentiel que l’optimiseur soit capable de fournir des
renseignements sur la façon dont il a calculé (déterminé) le plan
d’exécution de la requête. En effet, ces informations sont capitales pour
l’administrateur de la base de données pour ajuster l’organisation de la
base de données et pour le programmeur pour ajuster la structure de
ses requêtes.
L’utilitaire le plus connu dans ce domaine est la commande EXPLAIN.
26
8 Gestion de reprise après incident
Journal des transactions
Nécessité d’un journal des transactions

Il est essentiel qu ’on puisse conserver la trace des modifications
effectuées sur toutes les données. En effet, les données étant
modifiées en mémoire centrale ou secondaire, il est impossible de
récupérer une base cohérente en cas de panne que ce soit de la
mémoire volatile ou non volatile.
La technique unanimement reconnue pour enregistrer l’ensemble des
modifications effectuées sur une base est celle du JOURNAL DES
TRANSACTIONS (ou Log file en terminologie anglo-saxonne). Le
journal des transactions est constitué de un ou plusieurs fichiers, dont
l’objectif est de dresser un historique de l’exécution des transactions.
Le journal des transactions doit être organisé de façon séquentielle,
afin de conserver la notion d’ordre d’exécution des différentes
opérations.
27
Gestion de reprise après incident
Approches
Deux approches sont envisagées dans le SGBDR commercialisés pour conserver
cet historique :
Journal des transactions physiques
Journal des transactions logiques
Journal des transactions physiques
En partant du principe qu’une opération d’écriture sur une donnée lit un bloc de
données, le modifie et l’écrit, le journal des transactions prend une “ photographie ” du
bloc avant la modification et une photographie du bloc après la modification. Ces
“photographies” sont appelées des Images Avant (Before Image) et les Images Après
(ou After Image). Un tel journal des transactions est dit physique.
Journal des transactions logiques

Ou partant du principe qu’une transaction affectant une donnée lit un bloc de données
puis lui applique une séquence d’opérations, le journal des transactions enregistre les
images avant et les opérations de haut niveau appliquées sur ce bloc, c’est-à-dire la
logique de la transaction elle-même. Un tel journal des transactions est dit logique.
28
Gestion de reprise après incident
Nature des pannes
Plusieurs problèmes peuvent arrêter le déroulement normal d’une
opération sur la base de données ou même affecter l’écriture des données
sur le disque.
Certaines pannes ne nécessitent pas d’intervention de l’administrateur, car
le système assure lui-même la restauration dite reprise à chaud. D’autres
pannes sévères nécessitent l’intervention de l’administrateur, qui doit
restaurer la base (reprise à froid) à partir d’une sauvegarde récente.
Exemples de pannes
Erreur accidentelle : suppression de tables ou d’autres objets de la base.
Panne sur une commande SQL : problème d’allocation d’extension ou autres
Panne d’un processus SGBDR : il peut arriver qu’un processus du SGBDR
s’arrête brutalement sans avoir validé ou annulé les transactions en cours.
Panne réseau : une panne réseau peut interrompre l’exécution normale d’une
application cliente et provoquer une panne du processus.
Panne matérielle (disque,…)
29
Cours 5
Approches à la gestion des bases

de données réparties
ou fédérées
1 Pourquoi une gestion répartie de données
Raisons économiques :
Coût élevé d’acquisition et de maintenance des ordinateurs “main frame”
Raisons techniques :
Les développements remarquables de domaines :
Réseaux de communication
Mini et micro-ordinateurs
Bases de données relationnelles
Le développement croissant des applications
Multimédias (Données alphanumérique, Texte, Image, Son)
Infocentre (Orienté Utilisateur)
L’offre remarquable des Outils de développement sur PC.
L’exigence des entreprises d’avoir un système évolutif / progressif pour supporter les
besoins de logiciels.
Raisons organisationnelles :
Décentralisation des activités
Délégation du pouvoir
31
2 Définition
Intuitivement, une base de données répartie est une collection

de données logiquement corrélées et physiquement réparties
sur plusieurs machines interconnectées par un réseau de
communication.
Définition :
Une Base de données répartie est un ensemble de bases
de données coopérants, chacune résidant sur un site
différent, vu et manipulé par l’utilisateur comme une seule
base de données centralisée.
===> Transparence à la localisation des données .
32
3 Typologies de systèmes d’informations réparties
Base primaire centrale, mises à jour directes sur site primaire
C’est le cas d’architecture la plus simple, les données de référence (information primaire) sont sur le
site central, les mises à jours sont faites en direct par les utilisateurs sur ce site central (en
client/serveur à travers le réseau) et les données dupliquées sont transportées vers des sites
secondaires utilisés uniquement en consultation par les utilisateurs.
Base primaire centrale, mises à jour indirectes via transaction asynchrones
Même scénario que le premier, mais les mises à jour se font en local sur les sites locaux et grâce à
des procédures asynchrones déclenchées automatiquement que la base primaire centrale sera mise à
jour.
L’utilisateur est alors indépendant de la disponibilité du site central pour faire ses mises à jour.
Multiples bases primaires, base centrale dupliquées pour consolidation
Dans ce cas, plusieurs sites primaires possèdent chacun sa propre base de données et on repercute
dans la base centrale les mises à jour des tables faites en local soit en mode synchrone soit en mode
asynchrone.
Le site central contient donc des tables globales représentant l’union des tables des bases primaires.
En terme du contenu des tables, deux variantes sont possibles :
la base locale ne possède que ses propres données,
la base locale possède ses données ainsi celles des autres sites pour consultation uniquement.
33
4 Conception d’une BD répartie
Nécessité d’une démarche méthodologique
La nécessité de l’utilisation d’une méthode pour concevoir et mettre en oeuvre un système
d’information n’est plus à démontrer.
Cependant lors de conception d’un système d’informations réparties, certains points
deviennent très importants :
Cohérence des traitements de l’Entreprise :
Plus les traitements sont autonomes, et plus le problème de la cohérence se pose. c’est un
véritable enjeu
Propriété des données :
Le problème de la propriété des données va pair de pair avec celui de la cohérence des
traitements :
- Qui peut mettre à jour les données ? Qui en est responsable ? Qui peut y accéder ?
Les performances :
la productivité des utilisateurs locaux doit être optimisée parce qu’ils travaillent avec des données
locales et considèrent que les accès distants sont occasionnels.
La manipulation des seules données affectées, au lieu du remplacement de tables entières, doit
optimiser l’utilisation des réseaux.
La sécurité (fiabilité) :
Les sites locaux doivent mieux résister aux phénomènes de pannes parce qu’ils ne sont plus
tributaires d’une défaillance survenant en n’importe quel point du système
34
5 Techniques utilisées dans la répartition des
données
Technique de fragmentation
Il y a deux façons possibles de diviser une relation en plus petites
relations, horizontalement et verticalement, ce qui donne trois
types de fragments:
Horizontale
Verticale
Mixte
Afin de préserver la cohérence sémantique de la base de données
répartie, la fragmentation d’une relation doit obéir à trois règles :
Décomposition sans perte
Reconstruction
Non duplication
Technique de réplication (duplication)
35
Technique de fragmentation
Fragmentation horizontale directe (s ):

La fragmentation horizontale définit le partitionnement d’une relation
selon ses tuples. Les différents fragments sont obtenus par application
de prédicats de restriction.
La reconstruction d’une relation horizontalement fragmentée s’obtient
par la somme ou l’union (  ) de ses fragments .
Fragmentation horizontale indirecte (  ):

La fragmentation horizontale indirecte définit la fragmentation
horizontale d’une relation selon les valeurs d’attributs d’une autre
relation.
Les fragments sont obtenus par l’application de prédicats de semi-
jointure..
36
Technique de fragmentation (suite)
Fragmentation verticale (p ) :
La fragmentation verticale définit le partitionnement d’une relation
selon ses attributs.
Les fragments sont obtenus par des projections appliquées sur la
relation initiale.
Il est nécessaire de dupliquer dans chaque fragment le ou les attributs
clés pour pouvoir reconstruire la relation.
La reconstruction est obtenue par la jointure des fragments selon les
attributs communs.
Fragmentation mixte :
La fragmentation mixte combine la fragmentation horizontale et la
fragmentation verticale.
ATTENTION : Le choix de la fragmentation est un problème complexe
car il est dépendant des besoins d’accès des applications
37
Technique de réplication
L’unité de la duplication est le fragment, ou la relation si la

fragmentation n’est pas supportée. Une duplication est matérialisée
par des copies, chacune résidant sur un site différent.
Une telle duplication, contrôlée par le système, fournit :
- une grande disponibilité des données
- une meilleure résistance aux pannes
- un parallélisme dans les consultations
- une diminution du trafic réseau
Les avantages apportés par la duplication sont à comparer avec la
complexité et les coûts supplémentaires de maintenance des copies qui
doivent, en théorie, rester identique à tout moment.
Un compromis entre performance d’accès et cohérence des données

à tout instant rend difficile le choix du niveau de duplication.
38
6 Objectifs des SGBD réparties
(12 règles de DATE)
R1- Autonomie locale :
Tout site d’un système réparti doit être aussi autonome que possible. Les
données d’un noeud sont gérés par l’utilisateur qui est sur ce noeud.
L’autonomie des sites est un objectif récent qui permet à chaque site
opérationnel de contrôler et de manipuler ses données locales
indépendamment des autres sites, cependant, la coopération entre sites doit
être coordonnée par les administrateurs locaux.
R2- Pas de couplage fort avec les autres sites :
Pour une meilleure optimisation d’exécution des requêtes et de résistance aux
pannes, chaque site doit viser à privilégier la manipulation par l’utilisateur de sa
base locale, et considère que l’accès à d’autres bases est
occasionnel.
R3- Règles des opérations continues :
On doit pouvoir interrompre un noeud sans interrompre les autres noeuds du
réseau.
39
Objectifs des SGBD réparties
R4- Indépendance à la localisation des données :
Le but recherché est que la réorganisation physique de la base de
données répartie, qui peut conduire à transférer des relations d’un site à un
autre, est sans impact sur les programmes d’application qui accèdent à la
BD répartie.
R5- Indépendance à la fragmentation :

La fragmentation augmente les performances d’une base de données
répartie car elle permet de favoriser les accès locaux.
L’indépendance à la fragmentation des données cache à l’utilisateur le fait
qu’une relation conceptuelle est divisée en plus petites sous-relations
appelées fragments, pouvant être stockées à des sites différents.
40
R6- Indépendance à la duplication :
Les avantages escomptés sont :
- une grande disponibilité des données
- une meilleure résistance aux pannes
- un parallélisme dans les consultations
- une diminution du trafic réseau
Les avantages apportés par la duplication sont à comparer avec la complexité et
les coûts supplémentaires de maintenance des copies qui doivent, en théorie,
rester identique à tout moment.
Un compromis entre performance d’accès et cohérence des données à tout instant rend
difficile le choix du niveau de duplication
41
R7- Traitement réparti des requêtes :

L’évaluation de requêtes réparties, émises par les utilisateurs et invoquant la Base de
données répartie est divisée en quatre étapes:
- décomposition (traduction d’une requête SQL en une requête intermédiaire dans une
variation de l’algèbre relationnelle)
- localisation (transformation en fonction du schéma de placement d’une
requête répartie équivalente exprimée sur des fragments).
- optimisation (détermination de l’ordonnancement “ optimal ” des opérations relationnelles,
ainsi que les algorithmes d’accès aux données).
- exécution (Le plan d’exécution fournit toute l’information nécessaire à l’exécution des
traitements locaux et à leur synchronisation globale).
Remarque : Par comparaison à l’évaluation de requêtes dans un contexte centralisé,
l’évaluation de requêtes répartie est compliquée par plusieurs facteurs :
- Les possibilités de fragmentation de relations et de duplication de fragments offrent un plus grand nombre de stratégies
d’exécution d’une requête globale.
- L’utilisation des techniques de simplification conduisant à éliminer au plus tôt les stratégies de mauvaises performances.
- L’optimisation doit prendre en compte le coût supplémentaire de communication et les avantages du parallélisme.
- Le choix du site d’exécution ou du mode d’échange de données inter-sites.
42
R8- Gestion de transactions réparties :
Une transaction répartie est constituée de plusieurs sous-transactions,
chacune s’exécutant à un site différent. En général, l’information locale
concernant une sous transaction est insuffisante afin de décider de la
validation ou de l’abandon des mises à jour locales. La seule solution est de
gérer une information globale, ce qui induit un coût de communication et de
traitement supplémentaire.
L’environnement réparti affecte tous les aspects délicats de la gestion de
transactions : contrôle de concurrence, gestion de la fiabilité et traitement de
la validation .
Contrôle de concurrence : Deux approches de base sont utilisées :
Estampillage (Timestamp) et Verrouillage
Gestion de la fiabilité : Adaptation des techniques de journalisation et points
de reprise connues dans l’environnement centralisé.
Validation de transaction : Utilisation du protocole de validation en deux
étapes (Two-Phase Commit).
43
R9- Indépendance aux matériels
R10- Indépendance aux Systèmes d’exploitation (OS)
R11- Indépendance aux SGBD

c’est l’objectif particulier des bases de données réparties
hétérogènes. Il reste très difficile à atteindre totalement.
R12- Indépendance aux réseaux de communication
44
7 Etat de l’art
Sybase avec Replication Server
Oracle avec Symmetric Replication
45
Cours 6
Administration et optimisation
d’une base de données
relationnelle
1 Introduction
L ’administration de bases de données nécessitent des compétences qui

se situent à l’intersection de plusieurs domaines :
L’entreprise et la conception du système d’information
Il faut maîtriser la signification des informations manipulées dans la base
de données et les règles de gestion associées.
Le SGBD
Il faut maîtriser le système technique (SGBD) utilisé pour gérer les données
du système d’information, autrement dit :
maîtriser ses possibilités (fonctionnalités);
maîtriser ses contraintes et ses limites;
maîtriser ses outils de surveillance et d’administration de bases de données;
maîtriser l’utilité et l’impact des principaux paramètres de réglage (tuning);
maîtriser les langages de description et manipulation de données ainsi que le pseudo
langage procédural offert par le SGBD.
L’architecture technique
Il faut connaître le fonctionnement technique des systèmes matériels
supportant le SGBD (Operating System, mémoires, etc.).
47
2 Niveaux d’administration
4 niveaux d’administration
Niveau logique de la base de données
Niveau physique de la base de données
Niveau applicatif
Niveau système
48
Niveaux d’administration
Niveau logique
Gérer le dictionnaire de données (Création, modification ou

suppression des objets du dictionnaire). Le DBA est le seul habilité
à mettre à jour le dictionnaire de données ;
Gérer les droits des utilisateurs (personnalisation par utilisateur ou
par profil utilisateurs) ;
Définir les fédérations inter-bases ;
Définir les vues, les procédures et les trigger ;
Fournir les informations volumétriques permettant le
dimensionnement de la base de données ;
Assurer le support logiciel pour les équipes de développement ;
Arbitrer le choix des index, de la clusterisation des données ,du
niveau de dénormalisation / stockage des résultats de calcul dans la
base.
49
Niveau physique
Répartition physique des données;
Dimensionnement de la base de données
détermination des valeurs des paramètres de stockage sur disque (nombre de blocs
initialement alloués aux données ou aux index, nombre de blocs alloués en sus lorsque
l’espace initial est plein, nombre minimal et maximal d’extensions que le système peut
faire, le pourcentage d’espace à conserver libre dans le bloc pour les mise à jour
futures,...)
détermination de la taille de la mémoire cache (cache disque);
détermination des valeurs d’autres paramètres nécessaires au bon fonctionnement
optimal de la Base de données (Nombre de verrous, nombre de curseurs ouverts
simultanément, taille de buffer cache,...)
Détermination du type de fichier physique devant recevoir les données des tables et des
index (File system ou un Raw device si OS= UNIX);
Vérification du bon fonctionnement de la BD
Exécution des Benchmarks
Mise en place de l’environnement Base de données de production, d’intégration et
de développement et de la stratégie de la sauvegarde et la reprise des données
50
Niveau applicatif
Participation à l’élaboration et à la maintenance évolutive des

modèles conceptuel et logique de données ;
Élaboration du modèle physique de données;
Analyser les besoins de transactions (index, vue, stockage
des résultats de calcul, normalisation utile, analyse des plans
d’exécution des requêtes, procédure cataloguée, ...);
Optimisation des ordres SQL
Vérification des choix pris au niveaux logique (index ,
clusterisation, procédures cataloguées, trigger, fédérations,…)
Réorganisation du plan de stockage des données;
Analyser les plans d’exécution des requêtes;
51
Niveau système
Installation des logiciels du SGBD;

Installation des nouvelles versions . Avant toute installation il
doit étudier l’impact de celle-ci sur l’existant , prendre les
précautions nécessaires et définir l’environnement adéquat;
Paramétrage initial des logiciels du SGBD (mot de passe,
répertoires de travail, protocole de communication, taille de la
page en blocs OS, ...)
Coordination avec les ingénieurs système et réseau
Interlocuteur privilégié du fournisseur du SGBD
Veille technologique
Support aux équipes de développement
52
3 Optimisation et amélioration des performances
Introduction
Les bonnes ou mauvaises performances d’une base de données relationnelle ne se relèvent pas seulement de la bonne ou
mauvaise définition de sa structure physique.
Il est important de rappeler que, avant de définir la structure physique d’une base de données, une définition de sa structure
logique est obligatoire.
Cette structure logique est la clé, le garant de la bonne définition d’une structure physique de la base de données (cf. cours
Structures logique et physique d’une base de données relationnelle).
Il ne faut surtout pas oublier qu’en terme de modélisation de données, cette structure logique est le fruit d’un long et
fastidieux travail d’analyse et de conception du système d’information à automatiser.
Il est à rappeler aussi, que la finalité d’une base de données est d’être utilisée (exploitée) par des requêtes, des programmes
faisant des recherches (accès en lecture) ou des mises à jour des données dans la base. Ces recherches ou mises à jour
s’effectuent à l’aide des commandes SQL. Si ces dernières sont mal formulées et ne tiennent pas compte des contraintes
imposées par les optimiseurs, les conséquences peuvent être dramatiques en terme des performances du système.
L’expérience prouve que le gain que nous pouvons espérer en améliorant la structure physique d’une base de données
existante (revoir la répartition des fichiers sur plusieurs axes, gérer plus efficacement la mémoire centrale, etc.) est de l’ordre
de 15 à 25 %.
On déduit donc, qu’au moins 75% de gain des performances dépendent fortement de la bonne définition de la structure
logique de la base de données
définir un bon schéma de la base de données : Tables normalisées ou non , Cluster sur tables, Index pour tables, Index pour
Clusters, tablespaces, etc...,
définir les valeurs de paramètres de stockage en fonction de l’évolution des objets dans la base de données dans le
temps,...)
et de la bonne utilisation des commandes SQL dans les programmes applicatifs.
C’est pour cette importante raison que mettons l’accent dans ce chapitre sur l’optimisation des requêtes SQL et sur le choix
des index.
53
Optimisation et amélioration des performances
rappel des méthodes d’accès
Parcours de toute la table (Full Table Scan)
Les donnés sont cherchées directement dans la table. Les blocs qui contiennent les
données de la table sont lus d’une manière séquentielle. Toutes les lignes de la table
sont lues, et, pour chacune d’elles, la condition spécifiée dans la clause WHERE (s’il y en
une) est évaluée.
Accès par ROWID
Les données sont cherchées directement dans la table. Le ROWID spécifie l’adresse
physique de la ligne. Il est composé de l’identifiant du fichier, le bloc dans le fichier et
puis la localisation de la ligne dans le bloc. Ce ROWID est soit cité dans la clause
WHERE, soit obtenu en accédant à l’un des index définis pour la table.
La localisation d’une ligne par son ROWID constitue le moyen le plus rapide pour
retrouver la ligne.
Parcours de l’index (Index Scan)
Cette méthode permet de retrouver les données en se basant sur les valeurs d’une ou
plusieurs colonnes de l’index. Si la commande SQL spécifie seulement des valeurs de
colonnes faisant partie de l’index, Oracle recherche directement les données à partir de
l’index qui servent par la suite à retrouver les lignes elles-mêmes grâce au ROWID.
54
rappel des méthodes d’accès (suite)
Parcours du cluster (Cluster Scan)

Dans un cluster indexé, les lignes qui ont la même valeur de la clé du
cluster sont stockées dans les mêmes blocs. Cette méthode permet
de retrouver les lignes qui ont la même valeur de la clé. Pour ce faire,
Oracle obtient le ROWID des lignes sélectionnées à partir de l’index
du cluster, qui servent par la suite à retrouver les lignes elles-mêmes.
Parcours par hachage

Dans un cluster par hachage, toutes les lignes qui ont la même
valeur de hachage sont stockées dans les mêmes blocs.
Pour obtenir les lignes, Oracle applique une fonction de hachage à la
valeur de la clé du cluster (spécifiée dans la commande SQL), puis
retrouve les blocs de données contenant la valeur de hachage.
55
performance des méthodes d’accès
Les exemples suivants sont ordonnés selon le degré de performance de la
méthode employée (de plus performant vers le moins performants)
Cas 1 : accès à une seule ligne par ROWID
Disponible si la clause WHERE contient une identification de la ligne par son Rowid
Exemple : SELECT *
FROM Client
WHERE ROWID = ‘xxxxxxxxxxxxx’;
Cas 2 : accès à une seule ligne par jointure des clusters join
Disponible pour une opération de jointure de deux tables stockées dans le même
cluster et les deux conditions sont vérifiées :
1- la clause contient la condition d’égalité entre les deux tables selon la colonne clé
du cluster
2- la clause WHERE contient une condition assurant l’unicité du résultat.
Exemple : SELECT *
FROM Client, Commande
WHERE Client. Code_cli = Commande.Code_cli
AND Date_cde = ‘01-AUG-95’;
56
performance des méthodes d’accès (suite)
Cas 3 : jointure clusterisée
Disponible pour une opération de jointure de deux tables et si la
clause WHERE contient des conditions d’égalité entre chaque
colonne de la clé du cluster avec la colonne du cluster
correspondante de l’autre table.
Exemple : SELECT *
WHERE Client. Code_cli = Commande.Code_cli;
Cas 4 : Clé de cluster indexé
Disponible si la clause WHERE utilise toutes les colonnes de la clé
cluster indexé dans une condition d’égalité. Pour une clé composée
du cluster, les conditions d’égalité doivent être combinées avec des
opérateurs AND. Oracle retrouve la valeur du ROWID avec laquelle
il effectue un accès par cluster.
Exemple : SELECT *
FROM Commande
WHERE Num-cde = ‘AB1234’ ;
57
Cas 5 : Clé de cluster indexé

Disponible si la clause WHERE utilise toutes les colonnes de la clé cluster
hasch dans une condition d’égalité. Pour une clé composée du cluster, les
conditions d’égalité doivent être combinées avec des opérateurs AND.
Oracle applique la fonction de hachage à la clé pour retrouver la valeur
avec laquelle il accède aux lignes de la table.
Exemple : SELECT *
FROM Commande
WHERE Num_cde = ‘MNP654’ ;
Cas 6 : accès à une seule ligne par clé unique ou clé primaire
Disponible si la clause WHERE contient une condition d’égalité avec toutes
les colonnes d’une clé unique ou clé primaire.
Exemple : SELECT *
FROM Produit
WHERE Code_prod = 6656 ;
58
Cas 7 : index composé
Disponible si la clause WHERE utilise toutes les colonnes de l’index
combinées avec des opérateurs AND. Oracle effectue un accès par
index au ROWID, puis utilise les valeurs des ROWID pour accéder aux
données de la table.
Exemple : SELECT *
FROM Detail_commande
WHERE Num_cde = ‘AGH6754’
AND Code_prod = 6656 ;
Cas 8 : Recherche bornée sur colonnes indexées
Disponible si la clause WHERE contient des conditions qui utilisent soit
la colonne d’un index unique, soit plusieurs colonnes qui constituent une
partie d’un index composé.
Exemple : SELECT *
FROM Produit
WHERE Code_prod BETWEEN 1000 AND 6656 ;
59
Cas 9 : Recherche non bornée sur colonnes indexées

Disponible si la clause WHERE contient l’une des conditions suivantes qui
utilise une colonne d’un index unique ou bien une partie d’un index
composé.
Exemple : SELECT *
FROM Produit
WHERE Code_prod > 6656;
Cas 10 : Jointure avec tri et fusion
Disponible pour une opération de jointure de deux tables qui ne sont pas
stockées dans un cluster, si la clause WHERE utilise des colonnes de
chaque table dans des conditions d’égalité. Oracle utilise un tri et fusion
pour exécuter la requête.
Exemple :
SELECT *
WHERE Client.Code_cli=Commande.Code_cli;
60
Cas 11 : MAX et MIN de colonnes indexées

Disponible si les deux conditions sont vérifiées :
1 - la requête utilise MAX et MIN pour des colonnes (index unique) ou une colonne d’un index
composé.
2 - il n’y a pas d’autres expressions dans la clause SELECT
3 - la commande n’a pas de clause WHERE ni de clause GROUP BY
Exemple : SELECT MAX(Num_cde)
FROM Commande ;
Cas 12 : Order by sur une colonne indexée
Disponible si la condition est vérifiée :
il doit y avoir une clé primaire ou une contrainte d’intégrité NOT NULL qui garantit qu’au
moins une des colonnes indexées dans ORDER BY ne contient pas de NULL.
Exemple : SELECT *
FROM Detail_commande
ORDER BY Code_prod ;
Cas 13 : Parcours séquentiel total de la table (Full Table Scan)
Disponible pour tout ordre SQL :
Exemple : SELECT *
FROM Produit ;
61
Choix des index
Les index sont créés pour :

accélérer l’accès aux données
assurer l’unicité des clés primaires ou candidates.
Pour cela :
toujours indexer les clés primaires des tables > 100 lignes (inutile si la clause
PRIMARY KEY a été utilisée dans l’ordre de création de la table;
indexer les colonnes intervenant dans des jointures entre tables (clés étrangères par
exemple);
Indexer les colonnes intervenants dans des clauses ORDER BY. L’une des colonnes
au moins doit être déclarée en NOT NULL;
Indexer les colonnes intervenants dans des clauses GROUP BY ou utilisées dans les
fonctions MIN, MAX, AVG, etc.
Ne jamais indexer :
les colonnes contenant peu des valeurs distinctes (en règle générale lorsque 20 % ou
plus des occurrences d’une satisfont le critère de recherche, il vaut mieux se passer de
l’index);
les colonnes très souvent modifiées et très peu utilisées lors de consultation.
62
Quelques astuces
1. Vérifier l’adéquation des valeurs de paramètres de stockage

des objets du schéma de la base par rapport à leur réelle
évolution dans la base.
2. Vérifier la répartition physique des fichiers sur disques
évitant ainsi le goulot d’étranglement des E/S disque.
3. Utiliser les cluster si nécessaire.
4. Réajuster la taille et la répartition de la mémoire centrale
(SGA, PGA, etc.).
5. Réajuster la taille du bloc de données (page).
6. Procéder à une dénormalisation des tables très souvent
sollicitées en jointure définies dans des requêtes
fréquemment exécutées.
63
Les Objets d’Oracle
Abdelkrim LAHLOU
lahloukarim@free.fr
1 - Historique
Emergence de Oracle Corp.
 1964 : IBM développe le GUAM pour le projet Apollo (NASA)
 1966 : Première BD hiérarchique commerciale du marché d’IBM
 1970 : Dr. E. F. Codd d’IBM propose le modèle relationnel
 1977 : Larry Ellison, Bob Miner et Ed Oates fondent Oracle
 1985 : l’ANSI adopte SQL comme langage de requête standard
 1992 : SQL-2
 1993 : Sortie d’Access
 1995 : Sortie de Postgres95
 1996 : Sortie de MySQL
 1998 : SQL Server 7 disponible
 1999 : SQL-3 et sortie d’Oracle8i
 2000 : Sortie d’Oracle 9i
 2006 : Oracle 10g 3
2 – Dictionnaire de données
SGBD Oracle
…
5
Noyau Oracle
6
Oracle Data Dictionary
 Le dictionnaire de données (Data Dictionary) est l’un des

éléments les plus importants d’Oracle.
 Il contient toutes les informations sur les structures et objets de la
base tels que les tables, les colonnes, les utilisateurs, …
 Il est divisé en deux niveaux :
 Niveau interne (internal level) : contient toutes les tables
 Niveau externe (external level) : fournit de multiples vues sur ces tables
pour offrir de l’information sur des objets et structures
7
Tables du Data Dictionary
Les tables et les vues du Dictionnaire de données donnent
l’information suivante :
 les utilisateurs et leurs privilèges
 les tables, les colonnes et leurs types, contraintes d’intégrité,
indexes,…
 des statistiques sur les tables et indexes
 les privilèges donnés sur les objets de la base
 les structures de stockage de la base
 …
8
Comment savoir ce qu'il y a
dans ma base de données ?
Le dictionnaire des données

Dictionnaire de données Oracle
10
Dictionnaire de données Oracle
11
Vues principales du dictionnaire Oracle
12
Quelques commandes utiles
SELECT * FROM DICT[IONARY];
liste toutes les tables et les vues du Data Dictionary accessibles à l’utilisateur
SELECT * FROM TAB;

retourne le nom de toutes les tables appartenant à l’utilisateur ayant passé cette
commande
SELECT * FROM COL;

retourne toute information sur les colonnes des tables de l'utilisateur
DESC[RIBE] <nom_table>
décrit la structure d’une table
13
3 - Utilitaires de base d’Oracle
Utilitaires d’Oracle
 Oracle est un SGBD-R (Relationnel) qui utilise le langage SQL
 Il a complété SQL par le langage procédural PL/SQL (langage
propriétaire)
 Il fournit de nombreux programmes utilitaires
 SQL*PLUS pour faciliter l’utilisation de SQL
 SQL*FORMS pour faciliter la saisie et la modification des données
avec des formulaires
 SQL*REPORTWRITER pour faciliter l’impression de rapports
imprimés
 SQLWEB pour l’interface avec le Web
 Oracle HTML-DB (Oracle Application Express)
 Oracle Designer
 …
15
Les outils d’administration
 Le DBA doit être celui qui a la connaissance

la meilleure de la base de données :
 ses utilisateurs,
 son contenu,
 son utilisation,
 les données les plus utilisées,
 les types de transactions et leur fréquence,
 les clés de définition de bonnes performances.
16
Outils d’Administration
 Chaque SGBD met à la disposition du DBA

un ensemble d’outils lui permettant de :
 garantir l’intégrité des données,
 améliorer les performances,
 réduire les stockages inutiles ou redondants,
 faciliter le partage des données,
 garantir la sécurité,
 effectuer les sauvegardes.
17
Outils d’Administration Oracle
 Les principaux outils d’administration d’Oracle :
 IOR pour le démarrage et l’arrêt d’un système Oracle
 SGI pour le suivi d’un système Oracle
 ODS pour le suivi de l’utilisation d’un système Oracle
 AIJ pour la journalisation
 CRT pour la définition des caractéristiques des terminaux.
 OEM (Oracle Enterprise Manager) est l'outil graphique d'Oracle
 Sous Oracle, deux utilisateurs (SYS et SYSTEM) ont les

privilèges du DBA, qu’ils peuvent transmettre à d’autres
 SYS possède toutes les tables du dictionnaire de données
 SYSTEM possède toutes les vues du dictionnaire de données.
18
 IOR
déclenche un fichier de démarrage (INIT.ORA) qui :
 configure le SGA (System Global Area)
 réserve les espaces nécessaires
 définit les limites (nombre maximum d’utilisateurs,
nombre de tables, etc)

 SGI
 permet de tester la taille du SGA (System Global Area)
 généré par un fichier de paramètres
19
 ODS (Oracle Display System) affiche :

 les utilisateurs connectés,
 les programmes qu ’ils utilisent (SWL*Plus, SQL*Forms,
etc.),
 les tables utilisées,
 les verrouillages opérés,
 l’état du journal avant,
 l’activité logique et physique (nombre de blocs
utilisés/transférés, etc.).
20
 AIJ (After Image Journalling)

 gère un ensemble de fichiers séquentiels ayant un numéro
d’ordre
 propose une procédure de reprise à deux passes :
 lecture du journal pour repérer les transactions non
validées
 lecture et exécution du journal en évitant les
transactions repérées)
21
 CRT (Computer Resource Team ???)

 permet de créer ou de modifier les définitions des
terminaux utilisés par les programmes ORACLE.
 affecte des rôles aux touches de fonctions et aux touches
spéciales du clavier pour chaque programme ORACLE
(SQL*Forms IAP, SQL*calc, SQL*menu, etc)
 ces définitions sont stockées dans des tables ORACLE.
22
Qualités du DBA
 Le DBA doit posséder :

 une excellente connaissance de l’organisation : structure,
activités, stratégies, etc…
 des compétences techniques : méthodes, outils, produits,
etc…
 des qualités humaines : intermédiaire entre les
utilisateurs, animateur et normalisateur.
23
Organisation de la fonction DBA
 Dans une grande organisation, une personne seule ne suffit
pas : la fonction DBA revient à un groupe ou cellule
d’administration des données.
 La fonction de DBA doit être centralisée et non pas dispersée
pour assurer les responsabilités décrites plus haut.
 La fonction de DBA doit être hiérarchiquement
suffisamment élevée pour assurer un rôle stratégique
important. Dans la pratique, elle est rattachée :
 au service Etudes de la direction informatique,
 à la direction informatique,
 à la direction des systèmes d’information.
 Le groupe d’administration des bases de données doit
inclure des techniciens très qualifiés et familiers du SGBD
mais aussi des spécialistes de l’organisation et de l’analyse
des systèmes. 24
4 - Quelques objets d’oracle
Objets Oracle
26
Index (1/4)
 Définition :
 Un index est un objet contenant une entrée pour chaque valeur
apparaissant dans la colonne indexée, qui offre ainsi un accès
direct et rapide aux enregistrements
 Objectif :
 Amélioration des performances en lecture
 Indépendants des tables
 Ne modifient pas les requêtes SQL
 Basés sur un B-Tree :
 On ne peut garder toutes les données dans la RAM.
 Les accès disque sont coûteux
 Le système passe souvent plus de temps à récupérer les données
qu’à les manipuler (http://www.bluerwhite.org/btree)
27
Index (2/4)
 Quand est créé un index ?
 Explicitement avec CREATE INDEX
 Implicitement :
 PRIMARY KEY
 UNIQUE
 Effet de l’indexation :
 La construction de l’arbre ralentit les mises à jour
 Mais accélère de manière appréciable les recherches
 Il est utile de créer un index sur :
 Les attributs utilisés comme critère de jointure
 Les attributs utilisés comme critère de sélection
 Sur des tables de gros volume où la majorité des interrogations
sélectionnent moins de 5% des lignes (Règle des 5/95)
28
Index (3/4)
 Il est inutile de créer un index sur :
 Les attributs contenant peu de valeur distincte.
 Les attributs souvent modifiés
 Les attributs qui sont souvent utilisé dans les expressions
 Les petites tables
 Ordres SQL :
CREATE [UNIQUE] INDEX <indexName>
ON <table > (<columns>) [ASC / DESC] ;
UNIQUE spécifie que les valeurs de la colonne (ou combinaisons de

colonnes) indexée doivent être uniques.
ASC ou DESC spécifient respectivement l’ordre croissant ou décroissant
DROP INDEX index_name ; (suppression d’index)

29
Index (4/4)
 Index bitmap :
 Concept développé pour les datawarehouses
 Convient pour les colonnes contenant peu de valeurs
distinctes
 Création :
CREATE BITMAP INDEX <nom> ON <table>(<col>) ;
 Les vues Oracle utiles sur les indexes :

 USER_INDEXES
 USER_IND_COLUMNS
 ALL_INDEXES
30
Synonymes
31
Séquences
32
Séquences
33
Les Clusters
34
Les Clusters
 Présentation :
 Rangement de plusieurs tables selon une condition de jointure.
 Optimise les requêtes sur ces tables
 Caractéristiques :
 Doivent avoir une clé qui définit les lignes qui doivent être
stockées ensemble
 Cette clé de cluster peut être composée de plusieurs attributs.
 Mécanisme transparent pour l’utilisateur.
 Clé de cluster indépendant de la clé primaire
 Améliorent les performances en moyenne.
 Syntaxe en SQL :
CREATE CLUSTER [schema.] nom_cluster
(colonne type [, colonne type]…)
[autres options]
35
Clusters - Syntaxe
36
Exemple de clusters
 Exemple :
CREATE CLUSTER dupont.mon_cluster
(num_spec NUMBER(3)) SIZE 512 HASHKEYS 100;
CREATE TABLE Spectacle
(NumSpec NUMBER(3) PRIMARY KEY,
NomSpec VARCHAR2(20) NOT NULL,
DateDebSpec DATE, DateFinSpec DATE)
CLUSTER dupont.mon_cluster(NomSpec);
CREATE TABLE Representation
(NumRep NUMBER(3) PRIMARY KEY,
NumSpec NUMBER(3) REFERENCES Spectacle(NumSpec),
DateRep DATE)
CLUSTER dupont.mon_cluster(NomSpec);
 Suppression cluster :
DROP CLUSTER dupont.moncluster
INCLUDE TABLES;
37
Compte utilisateur
 Création d’un utilisateur :
CREATE USER toto
IDENTIFIED BY titi
DEFAULT TABLESPACE USERS
TEMPORARY TABLESPACE TEMP
QUOTA 2M ON USERS ;
 Modification de mot de passe :
ALTER USER <user>
IDENTIFIED BY <Newpassword> ;
38
5 – SQL-PLUS
39
6 – SQL*Loader
40
Exemple de fichier de données
41
Exemple de fichier de contrôle
42
Exemple de fichier de contrôle
43
Exemple de chargement de données en masse
Clients.ctl - création par SQL*Loader
Exemple de la commande de SQL-Loader :

SQLLDR clirep/clirep@orcl control=/home/oracle/clients.ctl
log=/home/oracle/clients.log
LOAD DATA INFILE "/home/oracle/clients.txt"

REPLACE INTO TABLE CLIENTS FIELDS TERMINATED
BY ',' OPTIONALLY ENCLOSED BY '"' TRAILING
NULLCOLS
(CODECLIENT,SOCIETE,CONTACT,FONCTION,ADRESSE
, VILLE,REGION,CODEPOSTAL,PAYS,TELEPHONE,FAX)
44
Création de la table Clients sur la base
drop table clients;
create table clients (

codeclient char(5) constraint pkcli primary key,
societe char(40),
contact char(30),
fonction char(30),
adresse char(60),
ville char(25),
region char(25),
codepostal char(10),
pays char(15),
telephone char(24),
fax char(24) );
45
Procedural Language
for SQL
PL/SQL
1
What is PL/SQL
• PL/SQL is an extension to SQL with design features of
programming languages.
• Data manipulation and query statements of SQL are
included within procedural units of code.
SQL
SQL
Application Other DBMSs
SQL
SQL
SQL
IF...THEN
SQL Oracle with
Application ELSE PL/SQL
SQL
END IF;
SQL 2
Benefits of PL/SQL
Modularize program development
Stored
Anonymous
procedure/
block
DECLARE function
BEGIN Application
Application
procedure/
trigger
function
EXCEPTION
Database
END; Packaged
trigger procedure
3
Benefits of PL/SQL
• You can declare identifiers.

• You can program with procedural
language control structures.
• It can handle errors.
4
Anatomy of a PL/SQL Block
• DECLARE – Optional
DECLARE
– Variables, constants, cursors, user-
defined exceptions BEGIN
• BEGIN – Mandatory
EXCEPTION
– SQL statements
END;
– PL/SQL control statements
• EXCEPTION – Optional DECLARE
– Actions to perform when v_variable VARCHAR2(5)
errors occur BEGIN
• END; – Mandatory SELECT column_name
INTO v_variable
FROM table_name
END;
5
Declaring PL/SQL Variables
Syntax
identifier [CONSTANT] datatype [NOT NULL]
[:= | DEFAULT expr];
Examples
Declare
v_hiredate DATE;
v_deptno NUMBER(2) NOT NULL := 10;
v_location VARCHAR2(13) := 'Atlanta';
c_ comm CONSTANT NUMBER := 1400;
Assigning
identifier := expr;
v_hiredate := '31-DEC-1998';
6
Base Scalar Datatypes
• VARCHAR2(maximum_length)
• NUMBER [(precision, scale)]
• DATE
• CHAR [(maximum_length)]
• LONG
• LONG RAW
• BOOLEAN
• BINARY_INTEGER
v_job VARCHAR2(9);
v_count BINARY_INTEGER := 0;
v_total_sal NUMBER(9,2) := 0;
v_orderdate DATE := SYSDATE + 7;
c_tax_rate CONSTANT NUMBER(3,2) := 8.25;
v_valid BOOLEAN NOT
7
NULL := TRUE;
The %TYPE Attribute
• Declare a variable according to
– A database column definition.
– Another previously declared variable.
• Prefix %TYPE with
– The database table and column.
– The previously declared variable name.
...
v_ename emp.ename%TYPE;
v_balance NUMBER(7,2);
v_min_balance v_balance%TYPE := 10;
...
8
Commenting Code
• Prefix single-line comments with two
dashes (--).
• Place multi-line comments between the
symbols /* and */.
Example
...
v_sal NUMBER (9,2);
BEGIN
/* Compute the annual salary based on the
monthly salary input from the user */

v_sal := v_sal * 12;
END; -- This is the end of the transaction
9
SQL Functions in PL/SQL
• Most of SQL functions are valid in PL/SQL:
– Single-row number, Single-row character, Datatype
conversion, Date
v_mailing_address := v_name||CHR(10)||
v_address||CHR(10)||
v_state||CHR(10)||v_zip;
v_ename := LOWER(v_ename);

Group functions not available
– The following example is an error
v_total := SUM(number_table);
10
Using Bind Variables
To reference a bind variable in PL/SQL, you must
prefix its name with a colon (:).
Example
:return_code := 0;
IF credit_check_ok(acct_no) THEN
:return_code := 1;
END IF;
In SQL*Plus you can display the value of the bind

variable using the PRINT command.
SQL> PRINT return_code
RETURN_CODE
-----------
1
11
Interacting with the
Server
SQL Statements in PL/SQL
• Extract a row of data from the database by using the
SELECT command.
• Make changes to rows in the database by using DML
commands.
• Control a transaction with the COMMIT, ROLLBACK, or
SAVEPOINT command.
• Determine DML outcome with implicit cursors.
• PL/SQL does not support
– data definition language (DDL), such as CREATE TABLE,
ALTER TABLE, or DROP TABLE.
– data control language (DCL), such as GRANT or REVOKE.
13
SELECT Statements in PL/SQL
Retrieve data from the database with SELECT.
SELECT select_list
INTO {variable_name[, variable_name]...
| record_name}
FROM table
WHERE condition;
Example
DECLARE
v_deptno NUMBER(2);
v_loc VARCHAR2(15);
BEGIN
SELECT deptno, loc
INTO v_deptno, v_loc
FROM dept
WHERE dname = 'SALES';
...
END; 14
Retrieving Data in PL/SQL
Retrieve the order date and the ship date
for the specified order.
Example
DECLARE
v_orderdate ord.orderdate%TYPE;
v_shipdate ord.shipdate%TYPE;
BEGIN
SELECT orderdate, shipdate
INTO v_orderdate, v_shipdate
FROM ord
WHERE id = 157;
...
END;
15
Retrieving Data in PL/SQL
Return the sum of the salaries for all
employees in the specified department.
Example
DECLARE
v_sum_sal emp.sal%TYPE;
v_deptno NUMBER NOT NULL := 10;
BEGIN
SELECT SUM(sal) -- group function
INTO v_sum_sal
FROM emp
WHERE deptno = v_deptno;
END;
16
Manipulating Data Using PL/SQL
• Make changes to database tables by

using DML commands:
– INSERT
– UPDATE INSERT
– DELETE
UPDATE
DELETE
17
Inserting Data
Add new employee information to the emp

table.
Example
DECLARE
v_empno emp.empno%TYPE;
BEGIN
SELECT empno_sequence.NEXTVAL
INTO v_empno
FROM dual;
INSERT INTO emp(empno, ename, job, deptno)
VALUES(v_empno, 'HARDING', 'CLERK', 10);
END;
18
Updating Data
Increase the salary of all employees in the
emp table who are Analysts.
Example
DECLARE
v_sal_increase emp.sal%TYPE := 2000;
BEGIN
UPDATE emp
SET sal = sal + v_sal_increase
WHERE job = 'ANALYST';
END;
19
Deleting Data
Delete rows that have belong to

department 10 from the emp table.
Example
DECLARE
v_emp deptno.emp%TYPE := 10;
BEGIN
DELETE FROM emp
WHERE deptno = v_deptno;
END;
20
Controlling Transactions
Determine the transaction processing for
the following PL/SQL block.
BEGIN
INSERT INTO temp(num_col1, num_col2, char_col)
VALUES (1, 1, 'ROW 1');
SAVEPOINT a;
VALUES (2, 1, 'ROW 2');
SAVEPOINT b;
VALUES (3, 3, 'ROW 3');
SAVEPOINT c;
ROLLBACK TO SAVEPOINT b;
COMMIT;
END;
21
Writing Control Structures
Controlling PL/SQL Flow of
Execution
You can change the logical flow of
statements using conditional IF statements
and loop control structures.
• Conditional IF statements:
– IF-THEN
– IF-THEN-ELSE
– IF-THEN-ELSIF
23
IF Statements
Syntax
IF v_ename = 'OSBORNE' THEN
IF condition THEN v_mgr := 22;
statements; END IF;
[ELSIF condition THEN . . .
statements;] IF v_ename = 'MILLER' THEN
v_job := 'SALESMAN';
[ELSE
v_deptno := 35;
statements;] v_new_comm := sal * 0.20;
END IF; END IF;
... . . .
IF v_shipdate - v_orderdate < 5 THEN IF v_start > 100 THEN
v_ship_flag := 'Acceptable'; RETURN (2 * v_start);
ELSE ELSIF v_start >= 50 THEN
v_ship_flag := 'Unacceptable'; RETURN (.5 * v_start);
END IF; ELSE
... RETURN (.1 * v_start);
END IF;
. . .
24
Iterative Control: LOOP
Statements
• Loops repeat a statement or sequence of

statements multiple times.
• There are three loop types:
– Basic loop
– FOR loop
– WHILE loop
25
Basic Loop
Syntax
-- delimiter
LOOP
statement1; -- statements
. . . /* EXIT statement, condition
EXIT [WHEN condition]; is a Boolean variable or expression*/
END LOOP; -- delimiter
. . .
v_ordid item.ordid%TYPE := 101;
v_counter NUMBER(2) := 1;
BEGIN
. . .
LOOP
INSERT INTO item(ordid, itemid)
VALUES(v_ordid, v_counter);
v_counter := v_counter + 1;
EXIT WHEN v_counter > 10;
END LOOP;
. . . 26
FOR Loop
FOR index in [REVERSE] lower_bound..upper_bound LOOP
statement1;
statement2;
. . .
END LOOP;
• Use a FOR loop to shortcut the test for the number of iterations.
• Do not declare the index; it is declared implicitly.
-- Insert the first 10 new line items for order number 101.
. . .
v_ordid item.ordid%TYPE := 101;
BEGIN
. . .
FOR i IN 1..10 LOOP
INSERT INTO item(ordid, itemid)
VALUES(v_ordid, i);
END LOOP;
. . . 27
WHILE Loop
Use WHILE loop to repeat statements while a condition is TRUE.
WHILE condition LOOP
Condition is
statement1;
evaluated at the
statement2;
beginning of
. . .
each iteration.
END LOOP;
ACCEPT p_price PROMPT ‘Enter the price of the item: ‘

ACCEPT p_itemtot PROMPT ‘Enter the maximum total forpurchase of item: ‘
DECLARE
...
v_qty NUMBER(8) := 1;
v_running_total NUMBER(7,2) := 0;
BEGIN
...
WHILE v_running_total < &p_itemtot LOOP
...
v_qty := v_qty + 1;
v_running_total := v_qty * p_price;
END LOOP;
... 28
Nested Loops and Labels
• Nest loops to multiple levels.
• Use labels to distinguish between blocks and loops.
• Exit the outer loop with the EXIT statement referencing the label.
...
BEGIN
<<Outer_loop>>
LOOP
v_counter :=v_counter+1;
EXIT WHEN v_counter>10;
<<Inner_loop>>
LOOP
...
EXIT Outer_loop WHEN total_done = 'YES';
-- Leave both loops
EXIT WHEN inner_done = 'YES';
-- Leave inner loop only
...
END LOOP Inner_loop;
...
END LOOP Outer_loop;
END; 29
Working with Composite
Datatypes
PL/SQL Records
• Must contain one or more components of any scalar,
RECORD, or PL/SQL TABLE datatype-called fields.
• Are similar in structure to records in a 3GL.
Syntax
TYPE type_name IS RECORD
(field_declaration[, field_declaration]…);
Where field_declaration stands for

field_name {field_type | variable%TYPE
| table.column%TYPE | table%ROWTYPE}
[[NOT NULL] {:= | DEFAULT} expr]
31
Creating a PL/SQL Record
Declare variables to store the name, job,

and salary of a new employee.
Example
...
TYPE emp_record_type IS RECORD
(ename VARCHAR2(10),
job VARCHAR2(9),
sal NUMBER(7,2));
emp_record emp_record_type;
...
32
The %ROWTYPE Attribute
• Declare a variable according to a collection of columns
in a database table or view.
• Prefix %ROWTYPE with the database table.
• Fields in the record take their names and datatypes
from the columns of the table or view.
Examples
Declare a variable to store the same information about a
department as it is stored in the DEPT table.
dept_record dept%ROWTYPE;
Declare a variable to store the same information about a
employee as it is stored in the EMP table.
emp_record emp%ROWTYPE;
33
Writing Cursors
About Cursors
Every executed SQL statement has an individual
cursor associated with it:
• A cursor is a private SQL work area.
• Implicit cursors:
– Declared for all DML and PL/SQL SELECT
statements.
• Explicit cursors:
– Declared and named by the programmer.
– Useful for managing queries that return one or
more rows of data
35
SQL Implicit Cursor Attributes
Using SQL cursor attributes, you can test
the outcome of your SQL statements.
SQL%ROWCOUNT Number of rows affected by the
most recent SQL statement (an
integer value).
SQL%FOUND Boolean attribute that evaluates to
TRUE if the most recent SQL
statement affects one or more rows.
SQL%NOTFOUND Boolean attribute that evaluates to
TRUE if the most recent SQL
statement does not affect any rows.
SQL%ISOPEN Always evaluates to FALSE because
PL/SQL closes implicit cursors
immediately after they are executed.
36
SQL Cursor Attributes
Delete rows that have the specified order
number from the ITEM table. Print the
number of rows deleted.
Example
VARIABLE rows_deleted VARCHAR2(20)
DECLARE
v_ordid NUMBER := 605;
BEGIN
DELETE FROM item
WHERE ordid = v_ordid;
:rows_deleted :=(SQL%ROWCOUNT ||' rows deleted.');
END;
/
PRINT rows_deleted
37
Controlling Explicit Cursors
No
Yes
DECLARE OPEN FETCH EMPTY? CLOSE
• Create a • Identify • Load the • Test for • Release

named the active current existing the active
SQL area set row into rows set
variables • Return to
FETCH if
• TESTS: rows
%FOUND, %NOTFOUND, found
%ROWCOUNT, %ISOPEN
38
Controlling Explicit Cursors
• Declare a Cursor Open the cursor.
CURSOR cursor_name IS Pointer

select_statement;
Cursor
• Open a Cursor
Fetch a Row from the cursor.
OPEN cursor_name;
Pointer
• Fetch data from a Cursor

Cursor
FETCH cursor_name INTO
[variable1, variable2, ...] | Continue until empty.
record_name];
Pointer
• Close a Cursor
CLOSE cursor_name; Cursor
39
Explicit Cursor Attributes
Obtain status information about a cursor.
Attribute Type Description
%ISOPEN Boolean Evaluates to TRUE if the cursor
is open.
%NOTFOUND Boolean Evaluates to TRUE if the most
recent fetch does not return a row.
%FOUND Boolean Evaluates to TRUE if the most
recent fetch returns a row;
complement of %NOTFOUND
%ROWCOUNT Number Evaluates to the total number of
rows returned so far.
40
Explicit Cursor - example
DECLARE
CURSOR EMP_CUR IS
SELECT empno, ename, sal FROM emp;
CURSOR c1 IS
SELECT empno, ename, job, sal FROM emp
WHERE sal > 2000;
BEGIN
IF NOT emp_cur%ISOPEN THEN -- or run OPEN EMP_CUR;
OPEN emp_cur;
END IF;
LOOP
fetch emp_cur into v_empno, v_ename, v_sal;
EXIT when emp_cur%NOTFOUND;
IF ename_cur%ROWCOUNT > 20 THEN
...
IF (v_sal > 1000) then
DBMS_OUTPUT.put_line(v_empno || ' ' || v_ename || ' ' || v_sal);
ELSE
DBMS_OUTPUT.put_line(v_ename || ' sal is less then 1000');
END IF;
END LOOP;
close emp_cur;
DBMS_OUTPUT.put_line('Execution Complete');
END; 41
Cursors and Records
Process the rows of the active set
conveniently by fetching values into a
PL/SQL RECORD.
Example
...
CURSOR emp_cursor IS
SELECT empno, sal, hiredate, rowid
FROM emp
WHERE deptno = 20;
emp_record emp_cursor%ROWTYPE;
BEGIN
OPEN emp_cursor;
. . .
FETCH emp_cursor INTO emp_record;
42
Cursor FOR Loops
FOR record_name IN cursor_name LOOP
statement1;
statement2;
. . .
END LOOP;
• Shortcut to process explicit cursors.
• Implicit open, fetch, and close occur.
DECLARE
cursor c1 is
select sal from emp
where job = 'MANAGER';
BEGIN
total_val := 0;
FOR employee_rec in c1
LOOP
total_val := total_val + employee_rec.sal;
END LOOP;
END;
43
Handling Exceptions
Handling Exceptions with PL/SQL
• What is an exception?
– Identifier in PL/SQL that is raised during
execution.
• How is it raised?
– An Oracle error occurs.
– You raise it explicitly.
• How do you handle it?
– Trap it with a handler.
– Propagate it to the calling environment.
45
Handling Exceptions
Trap the Exception Propagate the Exception

DECLARE DECLARE
BEGIN BEGIN
Exception Exception
is raised is raised
EXCEPTION EXCEPTION
Exception Exception is
is trapped END; END; not trapped
Exception
propagates to calling
environment
46
Trapping Exceptions
Syntax
EXCEPTION
WHEN exception1 [OR exception2 . . .] THEN
statement1;
statement2;
. . .
[WHEN exception3 [OR exception4 . . .] THEN
statement1;
statement2;
. . .]
[WHEN OTHERS THEN
statement1;
statement2;
. . .]
47
Declaring Exception
DECLARE exception_name EXCEPTION;
• Exception Types
– Predefined – Implicitly raised
– NO_DATA_FOUND
– TOO_MANY_ROWS
– INVALID_CURSOR
– ZERO_DIVIDE
–. . .
– User-defined – Explicitly raised
48
Predefined Exception
BEGIN SELECT ... COMMIT;

EXCEPTION
WHEN NO_DATA_FOUND THEN
statement1; statement2;
DBMS_OUTPUT.PUT_LINE(TO_CHAR(v_prodid)||' is invalid.');
WHEN TOO_MANY_ROWS THEN
statement1;
DBMS_OUTPUT.PUT_LINE('Invalid Data');
WHEN OTHERS THEN
statement1; statement2; statement3;
DBMS_OUTPUT.PUT_LINE('Other error');
END;
49
User-Defined Exception
• Each exception has an error code (default is 1) and a error
message (default is "User-defined exception"), unless using
the EXCEPTION_INIT pragma exception_name
[DECLARE]
e_products_remainingEXCEPTION;
PRAGMA EXCEPTION_INIT (e_products_remaining, -22292);
. . .
BEGIN
. . . error_number
RAISE e_products_remaining;
...
EXCEPTION
WHEN e_products_remaining THEN
DBMS_OUTPUT.PUT_LINE ('Product code specified is not valid.');
. . .
END;
• error_number is a negative integer in the range -20000 .. -20999

50
Functions for Trapping Exceptions
• SQLCODE
– Returns the numeric value for the error code.
• SQLERRM
– Returns the message associated with the error number.
...
v_error_code NUMBER;
v_error_message VARCHAR2(255);
BEGIN
...
EXCEPTION
...
WHEN OTHERS THEN
ROLLBACK;
v_error_code := SQLCODE;
SQLCODE
v_error_message := SQLERRM;
SQLERRM
INSERT INTO errors VALUES(v_error_code, v_error_message);
END; 51
Creating Procedures
Overview of Procedures
• A procedure is a named PL/SQL block that performs an
action.
• A procedure can be stored in the database, as a database
object, for repeated execution.
Syntax
CREATE [OR REPLACE] PROCEDURE procedure_name
(argument1 [mode] datatype1,
argument2 [mode] datatype2,
. . .
IS [AS]
PL/SQL Block;
• mode: has one of the following values: IN, OUT, IN OUT

• A stored procedure can be removed as follow:
DROP PROCEDURE procedure_name
53
IN Parameters: Example
7369 v_id
SQL> CREATE OR REPLACE PROCEDURE raise_salary

2 (v_id in emp.empno%TYPE)
3 IS
4 BEGIN
5 UPDATE emp
6 SET sal = sal * 1.10
7 WHERE empno = v_id;
8 END raise_salary;
9 /
Procedure created.
SQL> EXECUTE raise_salary (7369)

PL/SQL procedure successfully completed.
54
OUT Parameters: Example
Calling environment QUERY_EMP procedure
7654 v_id
MARTIN v_name
1250 v_salary
1400 v_ comm
SQL> CREATE OR REPLACE PROCEDURE query_emp

1 (v_id IN emp.empno%TYPE,
2 v_name OUT emp.ename%TYPE,
3 v_salary OUT emp.sal%TYPE,
4 v_comm OUT emp.comm%TYPE)
5 IS
6 BEGIN
7 SELECT ename, sal, comm
8 INTO v_name, v_salary, v_comm
9 FROM emp
11 END query_emp;
12 / 55
OUT Parameters and SQL*Plus
SQL> START emp_query.sql
Procedure created.
SQL> VARIABLE g_name varchar2(15)

SQL> VARIABLE g_salary number
SQL> VARIABLE g_comm number
SQL> EXECUTE query_emp (7654, :g_name, :g_salary,

2 :g_comm)
SQL> PRINT g_name

G_NAME
---------------
MARTIN
56
IN OUT Parameters
Calling environment FORMAT_PHONE procedure
'(800)633-0575' '(800)633-0575' v_phone_no
SQL> CREATE OR REPLACE PROCEDURE format_phone

2 (v_phone_no IN OUT VARCHAR2)
3 IS
4 BEGIN
5 v_phone_no := '(' || SUBSTR(v_phone_no,1,3) ||
6 ')' || SUBSTR(v_phone_no,4,3) ||
7 '-' || SUBSTR(v_phone_no,7);
8 END format_phone;
9 /
57
Invoking FORMAT_PHONE
from SQL*Plus
SQL>VARIABLE g_phone_no varchar2(15)
SQL> BEGIN :g_phone_no := '8006330575'; END;

2 /
SQL> EXECUTE format_phone (:g_phone_no)

SQL> PRINT g_phone_no
G_PHONE_NO
---------------
(800)633-0575
58
Invoking a Procedure from
• From an Anonymous PL/SQL Block
DECLARE
v_id NUMBER := 7900;
BEGIN
raise_salary(v_id); --invoke procedure
COMMIT;
...
END;
• From a Stored procedure

SQL> CREATE OR REPLACE PROCEDURE process_emps
2 IS
3 CURSOR emp_cursor IS
4 SELECT empno
5 FROM emp;
6 BEGIN
7 FOR emp_rec IN emp_cursor LOOP
8 raise_salary(emp_rec.empno); --invoke procedure
9 END LOOP;
10 COMMIT;
11 END process_emps;
12 / 59
Creating Functions
Overview of Stored Functions
• A function is a named PL/SQL block that returns a value.
• A function can be stored in the database, as a database
object, for repeated execution.
CREATE [OR REPLACE] FUNCTION function_name

(argument1 [mode] datatype1,
argument2 [mode] datatype2,
. . .
RETURN datatype
IS|AS
PL/SQL Block;
• mode: has only the value: IN

A stored function can be removed as follow:
DROP FUNCTION function_name
61
Creating a Stored Function
Using SQL*Plus: Example
SQL> CREATE OR REPLACE FUNCTION get_sal
2 (v_id IN emp.empno%TYPE)
3 RETURN NUMBER
4 IS
5 v_salary emp.sal%TYPE :=0;
6 BEGIN
7 SELECT sal
8 INTO v_salary
9 FROM emp
11 RETURN (v_salary);
12 END get_sal;
13 /
62
Executing Functions in
SQL*Plus: Example
Calling environment GET_SAL function
7934 v_id
RETURN v_salary
SQL> START get_salary.sql

Procedure created.
created
SQL> VARIABLE g_salary number
SQL> EXECUTE :g_salary := get_sal(7934)
SQL> PRINT g_salary
G_SALARY
------------------
1300
63
Procedure or Function?
Procedure Function
Calling IN argument IN argument
Calling
Environment OUT argument Environment
IN OUT argument
(DECLARE) (DECLARE)
BEGIN BEGIN
EXCEPTION EXCEPTION
END; END;
Procedure Function
Execute as a PL/SQL statement Invoke as part of an expression
No RETURN datatype Must contain a RETURN datatype
Must return a value
Can return one or more values
64
Creating Packages
Overview of Packages
• Group logically related PL/SQL types, items, and
subprograms
• Advantages
– Modularity
– Information hiding
– Added functionality
• Consist of two parts:

– Specification
– Lists all the objects that are publicly available
– Body
– Code needed to implement procedures, functions, and cursors
listed in the specification, as well as any private objects
66
Creating the Package Specification
CREATE [OR REPLACE] PACKAGE package_name
IS | AS
public type and item declarations
subprogram specifications
END package_name;
Creating the Package Body

CREATE [OR REPLACE] PACKAGE BODY package_name
IS | AS
private type and item declarations
subprogram bodies
END package_name;
67
Example
CREATE OR REPLACE PACKAGE time_pkg IS
FUNCTION GetTimestamp RETURN DATE;
PROCEDURE ResetTimestamp;
END time_pkg;
CREATE OR REPLACE PACKAGE BODY time_pkg IS

StartTimeStamp DATE := SYSDATE; -- package data.
FUNCTION GetTimestamp RETURN DATE IS
BEGIN
RETURN StartTimeStamp;
END GetTimestamp;
PROCEDURE ResetTimestamp IS
BEGIN
StartTimeStamp := SYSDATE;
END ResetTimestamp;
END time_pkg;
68
Public and Private Constructs
COMM_PACKAGE package
Package G_COMM 1
specification RESET_COMM 2
procedure declaration
VALIDATE_COMM
function definition 3
Package
body
RESET_COMM
procedure definition 2
69
Creating a Package Body:
Example
SQL>CREATE OR REPLACE PACKAGE BODY comm_package IS
2 FUNCTION validate_comm
3 (v_comm IN NUMBER) RETURN BOOLEAN
4 IS
5 v_max_comm NUMBER;
6 BEGIN
7 SELECT MAX(comm)
8 INTO v_max_comm
9 FROM emp;
10 IF v_comm > v_max_comm THEN RETURN(FALSE);
11 ELSE RETURN(TRUE);
12 END IF;
13 END validate_comm;
14 END comm_package;
15 /
70
Creating a Package Body:
Example
SQL> PROCEDURE reset_comm
2 (v_comm IN NUMBER)
3 IS
4 v_valid BOOLEAN;
5 BEGIN
6 v_valid := validate_comm(v_comm);
7 IF v_valid = TRUE THEN
8 g_comm := v_comm;
9 ELSE
10 RAISE_APPLICATION_ERROR
11 (-20210,'Invalid commission');
12 END IF;
13 END reset_comm;
14 END comm_package;
15 /
71
Invoking Package Constructs
The elements declared in the specification are referenced
from the calling application via dot notation:
package_name.package_element
For example,
DBMS_OUTPUT.PUT_LINE('This is parameter data');
Example 1: Invoke a package procedure from SQL*Plus.

SQL> EXECUTE comm_package.reset_comm(1500);
Example 2: Invoke a package procedure in a different

schema.
SQL> EXECUTE scott.comm_package.reset_comm(1500);
Example 3: Invoke a package procedure in a remote

database.
SQL> EXECUTE comm_package.reset_comm@ny
72
(1500);
Creating Database Triggers
Overview of Triggers
• A trigger is a PL/SQL block that executes implicitly
whenever a particular event takes place.
• A trigger can be either a database trigger or an
application trigger.
Application
Example SQL> INSERT INTO EMP;
EMP table CHECK_SAL trigger

EMPNO ENAME JOB SAL
7838 KING PRESIDENT 5000
7698 BLAKE MANAGER 2850
7369 SMITH CLERK 800
7788 SCOTT ANALYST 3000
74
Creating Triggers
• Trigger timing:
– BEFORE: The code in the trigger body will execute before the
triggering DML event.
– AFTER: The code in the trigger body will execute after the
triggering DML event.
• Triggering event: INSERT or UPDATE or DELETE
• Table name: On table
• Trigger type:
– Statement: The trigger body executes once for the triggering event.
This is the default.
– Row: The trigger body executes once for each row affected by the
triggering
• Trigger body: [DECLARE]
BEGIN
[EXCEPTIONS]
END 75
Statement and Row Triggers
Example 1
SQL> INSERT INTO dept (deptno, dname, loc)

2 VALUES (50, 'EDUCATION', 'NEW YORK');
Example 2
SQL> UPDATE emp

2 SET sal = sal * 1.1
3 WHERE deptno = 30;
BEFORE statement trigger
EMPNO ENAME DEPTNO

BEFORE row trigger
7839 KING 30 AFTER row trigger
BEFORE row trigger
7698 BLAKE 30 AFTER row trigger
7788 SMITH 30 BEFORE row trigger
AFTER row trigger
AFTER statement trigger

76
Syntax for Creating Triggers
CREATE [OR REPLACE] TRIGGER trigger_name

timing event_1 [OR event_2 OR event_3]
ON table_name
[REFERENCING OLD AS old | NEW AS new]
[FOR EACH ROW]
[WHEN condition]
PL/SQL block;
timing is BEFORE or AFTER

trigger-name is the name of the Trigger Object
event_i is either INSERT, DELETE or UPDATE.
It is possible to combine these, for example:
create or replace trigger FIRE_AFTER_ALL after
insert or update or delete on tab1
77
Before Statement Trigger:
Example
SQL> CREATE OR REPLACE TRIGGER secure_emp
2 BEFORE INSERT ON emp
3 BEGIN
4 IF (TO_CHAR (sysdate,'DY') IN ('SAT','SUN'))
5 OR (TO_CHAR(sysdate,'HH24')NOT BETWEEN
6 '08' AND '18'
7 THEN RAISE_APPLICATION_ERROR (-20500,
8 'You may only insert into EMP during normal
9 hours.');
10 END IF;
11 END;
12 /
78
Example
SQL> INSERT INTO emp (empno, ename, deptno)

2 VALUES (7777, 'BAUWENS', 40);
INSERT INTO emp (empno, ename, deptno)
*
ERROR at line 1:
ORA-20500: You may only insert into EMP during
normal hours.
ORA-06512: at "SCOTT.SECURE_EMP", line 4
ORA-04088: error during execution of trigger
'SCOTT.SECURE_EMP'
79
Using Conditional Predicates
SQL>CREATE OR REPLACE TRIGGER secure_emp
2 BEFORE INSERT OR UPDATE OR DELETE ON emp
3 BEGIN
4 IF (TO_CHAR (sysdate,'DY') IN ('SAT','SUN')) OR
5 (TO_CHAR (sysdate, 'HH24') NOT BETWEEN '08' AND '18') THEN
6 IF DELETING THEN
7 RAISE_APPLICATION_ERROR (-20502,
8 'You may only delete from EMP during normal hours.');
9 ELSIF INSERTING THEN
11 'You may only insert into EMP during normal hours.');
12 ELSIF UPDATING ('SAL') THEN
14 'You may only update SAL during normal hours.');
15 ELSE
17 'You may only update EMP during normal hours.');
18 END IF;
19 END IF;
20 END;
21 /
80
After statement Trigger: Example
CREATE OR REPLACE TRIGGER emp_log_t
AFTER INSERT OR UPDATE OR DELETE ON emp
DECLARE
dmltype CHAR(1);
BEGIN
IF INSERTING THEN
dmltype := 'I';
INSERT INTO emp_log (who, operation, timestamp)
VALUES (USER, dmltype, SYSDATE);
ELSIF UPDATING THEN
dmltype := 'U';
ELSIF DELETING THEN
dmltype := 'D';
END IF;
END;
81
After Row Trigger: Example
FOR EACH ROW
DECLARE
dmltype CHAR(1);
BEGIN
IF INSERTING THEN
dmltype := 'I';
ELSIF UPDATING THEN
dmltype := 'U';
ELSIF DELETING THEN
dmltype := 'D';
END IF;
END;
82
Special Variables :old and :new
• FOR EACH ROW clause:
• A Statement level trigger fires only once for the triggering event. No
access to the column.
• A Row-Level trigger fires for each affected row. Can access the original
and new column.
• Old and New Column Values:

Row level triggers have access to both the copies of the
column values. The old and the new values. These are
referenced through the special variables:
• :old.column-name
• :new.column-name
83
After Row Trigger: Example
FOR EACH ROW
DECLARE
dmltype CHAR(1);
BEGIN
IF INSERTING THEN
dmltype := 'I';
INSERT INTO emp_log (who, operation, timestamp, emp_no)
VALUES (USER, dmltype, SYSDATE, :new.empno);
ELSIF UPDATING THEN
dmltype := 'U';
VALUES (USER, dmltype, SYSDATE, :new.empno);
ELSIF DELETING THEN
dmltype := 'D';
VALUES (USER, dmltype, SYSDATE, :old.empno);
END IF;
END;
84
Using Old and New Qualifiers
SQL>CREATE OR REPLACE TRIGGER audit_emp_values

2 AFTER DELETE OR INSERT OR UPDATE ON emp
3 FOR EACH ROW
4 BEGIN
5 INSERT INTO audit_emp_values (user_name,
6 timestamp, id, old_last_name, new_last_name,
7 old_title, new_title, old_salary, new_salary)
8 VALUES (USER, SYSDATE, :old.empno, :old.ename,
9 :new.ename, :old.job, :new.job,
10 :old.sal, :new.sal);
11 END;
12 /
85
User Audit_Emp_Values Table
USER_NAME TIMESTAMP ID OLD_LAST_NAME NEW_LAST_NAME
EGRAVINA 12-NOV-97 7950 NULL HUTTON
NGREENBE 10-DEC-97 7844 MAGEE TURNER
Continuation
OLD_TITLE NEW_TITLE OLD_SALARY NEW_SALARY
NULL ANALYST NULL 3500
CLERK SALESMAN 1100 1100
86
Restricting a Row Trigger
SQL>CREATE OR REPLACE TRIGGER derive_commission_pct
2 BEFORE INSERT OR UPDATE OF sal ON emp
3 FOR EACH ROW
4 W
WHEN (new.job = 'SALESMAN')
5 BEGIN
6 IF INSERTING THEN :new.comm := 0;
7 ELSE /* UPDATE of salary */
8 IF :old.comm IS NULL THEN
9 :new.comm :=0;
10 ELSE
11 :new.comm := :old.comm * (:new.sal/:old.sal);
12 END IF;
13 END IF;
14 END;
15 /
87
Managing Triggers
Disable or Re-enable a database trigger
ALTER TRIGGER trigger_name DISABLE | ENABLE
Disable or Re-enable all triggers for a table

ALTER TABLE table_name DISABLE | ENABLE ALL TRIGGERS
Recompile a trigger for a table

ALTER TRIGGER trigger_name COMPILE
88
Summary
Procedure Package Trigger
xxxxxxxxxxxxxxxxxx
vvvvvvvvvvvvvvvvvv
xxxxxxxxxxxxxxxxxx
vvvvvvvvvvvvvvvvvv
xxxxxxxxxxxxxxxxxx
vvvvvvvvvvvvvvvvvv
Procedure A
xxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxx
declaration
vvvvvvvvvvvvvvvvvv
xxxxxxxxxxxxxxxxxx
vvvvvvvvvvvvvvvvvv
xxxxxxxxxxxxxxxxxx
vvvvvvvvvvvvvvvvvv
xxxxxxxxxxxxxxxxxx
Procedure B
definition
Procedure A
definition
Local
variable
89

Database Cours Complet

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Database Cours Complet

Transféré par

Droits d'auteur :

Formats disponibles

Introduction au

◼ Proposé par CODD (Université Saint José) en 1971

◼ Schéma de relation : Nom de la relation suivi de la liste

donnée, et fait référence au type de définition du domaine.

valeur par défaut, clé primaire, liste de valeurs,.)

◼ Contraintes d’intégrité référentielle

Patients de la ville de Paris

Nom et prénom des patients

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

Patients et leurs visites

◼ SQL est à la fois un langage de :

◼ définition des données (DDL : Data Definition Language)

◼ manipulation des données (DML : Data Manipulating

◼ contrôle de l’accès aux données (DCL : Data Control

Toute commande SQL doit se terminer par ;

◼ Créer un objet (CREATE)

Le DCL autorise toutes les actions propres au contrôle

VARCHAR(n) chaîne de caractères de longueur variable d’au plus n caractères

DATE date + heure de taille fixe et dont le format par défaut

NUMERIC (n,d) type numérique pour les entiers et les réels,

Le langage de définition des

◼ La contrainte d’unicité UNIQUE sur une colonne spécifie que deux

[CONSTRAINT <name>] PRIMARY KEY (<column(s) >)

[CONSTRAINT <name>] UNIQUE (<column(s) >)

[CONSTRAINT <name>] NOT NULL (<column(s) >)

[CONSTRAINT <name>] CHECK (<expression booléenne>)

[CONSTRAINT <name>] FOREIGN KEY (<column(s) >)

Soit la relation Produit(NumP, Nom, PrixUnitaire, Quantite)

CREATE TABLE Produit (

◼ Ajout d’une colonne

Création de la table Produit :

Modification du schéma de la table Produit en lui ajoutant la

ALTER TABLE Produit ADD CONSTRAINT

DROP TABLE <table>

Le langage de manipulation des

INSERT INTO <table>

Dans le cas où les données à insérer se trouveraient dans

Une expression peut être une constante (nouvelle valeur), une

DELETE FROM <table>

DML (suite) : la commande

SELECT [DISTINCT] <column(s)>

◼ Pour les chaînes de caractères :

◼ Pour les dates :

❖ = , != ou <>, < , > , <= , >=

◼ UPPER (<string>) : transformation de la chaîne en

◼ LENGTH (<string>) longueur de la chaîne

expression1 BETWEEN expression2 AND

expression IS [NOT] NULL

◼ [NOT] IN : détermine si une valeur est égale à une

◼ [NOT] EXISTS : teste l’existence d’au moins une ligne

SELECT Nom_Etablissement FROM Etablissement

Nombre de lecteurs par etablissement :

Table Docteur Table Maladie

DocNum DocNom Spécialité MalCode TypeMal

SELECT P. PatNum, P.PatNom

FROM Patient P, Soins S

WHERE P.PatNum = S.PatNum

GROUP BY P. PatNum, P.PatNom

HAVING COUNT(DISTINCT DocNum) =

(SELECT COUNT(*) FROM Docteur);

SELECT * FROM Patient P

WHERE NOT EXISTS (

SELECT * FROM Docteur D WHERE NOT EXISTS(

SELECT * FROM Soins S