Base de données :

collection d'informations ou de données qui existent sur une

longue période de temps et qui décrivent les activités d'une
ou plusieurs organisations– ensemble de données modélisant
les objets d'une partie du monde réel et servant de support à
une application informatique

SGBD : Systèmes de Gestion de Bases de

Données/(DataBase Management Systems - DBMS):
ensemble de logiciels systèmes permettant aux utilisateurs
d'insérer, de modifier, et de rechercher efficacement des
données spécifiques dans une grande masse d'informations
(pouvant atteindre plusieurs milliards d'octets) partagée par
de multiples utilisateurs
 SGBD
Principaux composants :
– Système de gestion de fichiers
– Gestionnaire de requêtes
– Gestionnaire de transactions
Principales fonctionnalités :
– Contrôle de la redondance d’information
– Partage des données
– Gestion des autorisations d’accès
– Vérifications des contraintes d’intégrité
– Sécurité et reprise sur panne
 Instances et schéma
Instances de base de données :
données de la base à un instant donné
manipulées par un langage de manipulation de
données (DML - Data Manipulation Language)
Schéma de base de données :
description de la structure des données
ensemble de définitions exprimées en langage
de description de données (DDL – Data
Definition Language)
Conception d’une base de données
1.Un modèle conceptuel :le modèle entité- association
2. Le modèle relationnel
2.1.Définition
2.2. Règles de traduction
2.3. Dépendances entre données et formes normales
Le modèle entité-association
 Le modèle entité-association
• Avantages
– Simple

– Suffisamment puissant pour représenter des structures relationnelles

– Représentation graphique facilitant sa compréhension

• Mais
– Ne propose que des structures : pas d’opérations

– Peut mener à certaines ambiguïtés pour des schémas complexes

 Un mauvais exemple
Titre Année Nom MES Prénom MES Année de Naiss
Alien 1979 Scott Ridley 1943

Vertigo 1958 Hitchcock Alfred 1899

Titanic 1997 Cameron James 1954
Psychose 1960 Hitchcock Alfred 1899

Redondances (duplications)
Erreurs possibles lors de l’insertion
Erreurs possibles lors de la mise-à-jour
Si l’on modifie l’année de naissance d’Hitchcock pour Vertigo ...
Si destruction d’un film, on risque de supprimer le metteur en scène
 La bonne méthode
Représenter individuellement les films et les réalisateurs
• Une modification de l’un n’entraîne pas une modification de
l’autre
• Définir une méthode d’identification des films ou des
réalisateurs
• La même information est représentée une seule fois
• Préserver le lien entre films et réalisateurs, mais sans
introduire de redondance
 La bonne méthode
Titre Année Nom MES Prénom MES Année de Naiss
Alien 1979 Scott Ridley 1943
Vertigo 1958
Titanic 1997 Hitchcock Alfred 1899

Psychose 1960 Cameron James 1954

Hitchcock Alfred 1899

Table des films Table des réalisateurs

Ce n’est pas suffisant

 Il faut établir l’association
Titre Année ID MES ID Nom MES Prénom MES Année de Naiss
Alien 1979 1 1 Scott Ridley 1943
Vertigo 1958 2 2 Hitchcock Alfred 1899
Titanic 1997 3 3 Cameron James 1954
Psychose 1960 2 4 Hitchcock Alfred 1899

Table des films Table des réalisateurs

Plus d’anomalies: d’insertion, de mise à jour, de destruction

Conservation de l’information sans redondance

Il manque encore une chose !

 Le modèle conceptuel des données
Concepts de base
Schéma E/A : abstraction d’un domaine d’étude
• Entité : objet concret ou abstrait
– ayant une existence propre
– fonction des besoins de modélisation
– Ex : Assuré, Film, Contrat
• Association : lien sémantique entre entités
– fonction des besoins de modélisation
– Ex : Réaliser (entre réalisateur et film)
Propriété : donnée élémentaire Concepts de base

• ayant un sens
• pouvant être utilisée de manière autonome
– Ex : NomAssuré, AnnéeSouscription, NbContrats
• Servent à décrire les entités et les associations
– = Attributs ou colonnes
• prennent des valeurs appelées occurrences de la propriété
Propriété Occurrences

Nom Assuré Foulen

Foulena
Tounsi
Année Souscription
2006
2010
La modélisation conceptuelle est totalement indépendante de tout
choix d’implantation.

– Partie la plus stable d’une application

– Se concentrer sur l’essentiel : Que veut-on stocker dans la base ?

Le modèle E/A a été conçu en 1976 et est à la base de la plupart

des méthodes de conception.

– La syntaxe est souvent celle d’UML

– On utilise parfois la syntaxe MERISE (quasi équivalente)

 Les types d’entités
Le type d’une entité est composé de :
– son nom
– la liste de ses attributs avec, optionnellement, le domaine dans
lequel l’attribut
– prend ses valeurs : les entiers, les chaînes de caractères …
– l’indication du (ou des) attribut(s) permettant d’identifier
l’entité : ils constituent la clé.
Vocabulaire
– Une entité e est une instance de son type E.
– Un ensemble d’entités {e1, e2, ..., en} instances d’un même
type E, est une extension de E.
Définition d’une clé
– Soit E un type d’entité et A l’ensemble des attributs de E. Une
clé de E est un sous ensemble minimal de A permettant
d’identifier de manière unique une entité parmi n’importe
quelle extension de E.
 Les clés : exemples
Exemple :
– Internaute : plusieurs attributs
– email
– nom
– prénom
– Région

• email : clé naturelle car unique et discriminante pour chaque

internaute
• nom : impossible car plusieurs internautes peuvent avoir le
même nom
• (nom, prénom) : clé possible, mais peut poser des problèmes
de performance et complique les manipulations par SQL
 Les clés : caractéristiques souhaitables
Bonne clé primaire :
– sa valeur est connue pour toute entité
– on ne doit jamais avoir besoin de la modifier
– sa taille de stockage doit être la plus petite possible (pour des
raisons de performance)
Quand plusieurs clés possibles pour un même ensemble
d’entités
– On en choisit une comme clé primaire
– et les autres comme clés secondaires
Si difficile à trouver
– créer un identifiant « abstrait », indépendant de tout autre
attribut
 Type de liaison inter-entités : trois types de liaison
• Liaison de type 1 à 1 : À toute occurrence de X correspond
une et une seule occurrence de Y et réciproquement

• Liaison de type 1 à plusieurs (1 à n) : À toute occurrence de X

correspond une ou plusieurs occurrences de Y et une seule de X.

Un client a établi un ou plusieurs contrat(s) mais un contrat a été établi avec un seul client.

• Liaison de type plusieurs à plusieurs : À toute occurrence de X

correspond une ou plusieurs occurrences de Y et réciproquement

Un client peut commander plusieurs produits et un produit peut être commandé par plusieurs clients.
Attention ces questions, il faut les poser dans les deux sens de A vers B puis de B vers A.
 Cardinalité minimum
nombre minimum d’occurences d’une entité X dans l’association considérée.
Cardinalité maximum
nombre maximum d’occurences d’une entité X dans l’association considérée.
 Les valeurs de cardinalités sont en général 0, 1 ou N
La cardinalité minimum à 0 veut dire que certaines occurrences de
l’entité X ne sont pas impliquées dans une occurrence de l’association.

La cardinalité minimum à 1 veut dire qu’une occurrence de l’entité X

ne peut exister sans participer à une occurrence de l’association.

La cardinalité maximum à 1 veut dire que toute occurrence de l’entité

X ne peut participer au plus qu’à une occurrence de l’association.

La cardinalité maximum à N veut dire qu’une occurrence de l’entité X

peut être impliquée dans un maximum de N occurrences de l’association

La cardinalité maximum ne peut avoir une valeur de 0

La cardinalité minimum ne peut avoir une valeur de N

Attention ces questions, il faut les poser dans les deux sens
Acteurs vers Films : le rôle de type 1,N De Films vers Acteurs 0,N:
- (1) un acteur a joué dans au moins un film - (0) : un film n’ayant pas d’acteurs,
- (N) un acteur peut avoir joué dans plusieurs films possible si c’est un film documentaire
- (N) : un film peut avoir plusieurs acteurs

compléter le schéma ?

De Films vers Réalisateurs :

-Un film a au moins un réalisateur min=1 d’ailleurs
souvent Il y a au plus un réalisateur (max=1). Un film
a un seul réalisateur
 Plusieurs associations
peuvent exister entre les
mêmes entités
un film ne peut être
réalisé que par au plus un
artiste

Une association
peut être réflexive
(relie une entité à
un artiste peut
elle-même) réaliser plusieurs films
ou aucun

Exemple : L’association Est_Marié_A est

de dimension deux (binaire réflexive)
Association simple (type 1) Association multiple
Bijection entre E1 et E2 (type m)
À chaque entité de E1
correspond plusieurs
entités de E2

Association conditionnelle
(type c) Association multiple conditionnelle
À chaque entité de E1 (type mc)
correspond au plus une À chaque entité de E1 correspond
entité de E2 aucune, une, ou plusieurs entité(s)
Généralisation :
• Processus d’abstraction consistant à généraliser
les entités, et les ensembles d’entités, en un seul
ensemble ascendant.

Spécialisation :
• Les sous-ensembles d’entités dans une hiérarchie
de généralisation résultent du processus de
spécialisation.
• Les sous-ensembles peuvent avoir une
intersection
– Ex : Etudiant : appartenant à club de foot et club
cinéma
La spécialisation est la division d'un ensemble
d'entités en sous-classes. A l'inverse la
généralisation est un regroupement d'un
ensemble d'entités en une super classe. (ISA = ...
is a ...)
Clé d’une association
• La clé d’une association (binaire) entre un type d’entité E1 et
un type d’entité E2 est le couple constitué de la clé c1 de E1 et
la clé c2 de E2.

Entité forte
• Entité qui, disposant de son propre identifiant, peut être
considérée isolément.Ex : étudiant Assuré (N° de carte
étudiants)

Entité faible
• Entité ne pouvant exister qu’en étroite association avec une
autre. Ex : emploi de temps relatif_à une classe
 Avantages et inconvénients du modèle E/A
Avantages
•Il n’y a que trois concepts : entités, associations et attributs
•Représentation graphique intuitive (même si beaucoup de conventions)
•Permet de modéliser rapidement des structures pas trop complexes

Pauvreté
•Difficile d’exprimer des contraintes d’intégrité
•Difficile d’exprimer des structures complexes
•La conception en schémas reste en partie matière de bon sens et
d’expérience
•Ne propose pas d’opérations sur les données
 Contraintes
Contraintes d’intégrité : toutes règles implicites ou explicites que doivent
suivre les données
Le nombre d’étudiants par classe est un entier positif > 0
Contraintes d'entité: toute entité doit posséder un identificateur
Toute salle de classe porte un identifiant
Contraintes de domaine : les valeurs de certains attributs doivent être prises
dans un ensemble donné
La fonction d’un enseignant à l’Université prend sa valeur dans l’ensemble
{vacataire, prof de chair, chef département …}.
Contraintes d'unicité : une valeur d'attribut ne peut pas être affectée deux
fois à deux entité différentes
Un département, identifié par son numéro, a un nom unique (il n’y a pas deux
départements de même nom)
Contraintes générales : règle permettant de conserver la cohérence de la
base de manière générale
Un même examen ne peut pas avoir lieu dans deux salles différentes à la
même date et à la même heure.
 Méthodologie à suivre pour modéliser un problème
Déterminer les entités/classes et attributs :
• entité/instance de classe = objet décrit par de l’information
• objet caractérisé uniquement par un identifiant = attribut
• attribut multi-valué ou avec une association 1:N = entité ou
instance
• attacher les attributs aux ensemble d’entités/classes qu'ils
décrivent le plus directement
• éviter au maximum les identificateurs composites
Identifier les généralisations-spécialisations/héritage
Définir les associations
• éliminer les associations redondantes
• éviter les associations n-aires
• calculer les cardinalités de chaque association
le modèle entité/association s'appelle Modèle
Conceptuel des Données (MCD).
Et comme il est conceptuel, il n'a pas de
contraintes. Les contraintes apparaîtront dans l'une
des étapes suivantes : le Modèle Logique de
Données (MLD)... qui ne connaît ni association ni
entité.

En fait, le fil conducteur est que l'intégrité

référentielle du MLD est la traduction de
l'association du MCD. La contrainte c'est
simplement que l'on s'oblige à respecter cette
intégrité
 Dépendances fonctionnelles
Un attribut (ou un groupe d'attributs) Y dépend
fonctionnellement d'un attribut (ou groupe
d'attributs) X si : étant donné une valeur de X, il
lui correspond une valeur unique de Y (∀
l'instant considéré)
X→Y : Y dépend fonctionnellement de X ou X
détermine Y
Déclaration des dépendances au niveau du
schéma conceptuel
 Démarche de conception: règles
Identifier les entités les plus naturelles (sujets, compléments)

Identifier les associations entre ces entités ( verbes n’exprimant pas de

dépendances fonctionnelles) .

Identifier les attributs et les identifiant de ces entités et de ces association

(compléments de verbe exprimant des dépendances fonctionnelles).

Exprimer les cardinalités et les rôles (distinguer le singulier du pluriel).

Enumérer des CI (Contraintes d ’Intégrité).

 Application pour modélisation
• La société est organisée en services. Chaque service a un nom (nomSce) et un numéro unique (noSce)

et est dirigé par un employé unique (noSsDir). La date (dateDebDir) à laquelle l’employé a commencé

à diriger le service est comptabilisée. Un service peut avoir plusieurs emplacements chacun est

identifié par (noMEmp)

• Un service contrôle un certain nombre de projets, chacun d’entre eux ayant un nom(nomProjet), un

numéro (numeroProjet) et un emplacement unique (emplProjet).

• Le nom de chaque employé, son numéro de Sécurité sociale(noSs), son adresse, son salaire, son sexe

et sa date de naissance sont mémorisés. Un employé est affecté à un service(noSce), mais peut

travailler sur plusieurs projets qui ne sont pas forcément contrôlés par le même service.

• Le nombre d’heures hebdomadaires travaillées par chaque employé par projet est comptabilisé. Le

supérieur immédiat (noSssuper) de chaque employé est lui aussi mémorisé.

• Les ayants droit de chaque employé(noSsEmpl)doivent être indiqués pour des raisons d’assurance.

Leur prénom, leur sexe, leur date de naissance et leur lien de parenté avec l’employé sont mémorisés.
 Modèle relationnel
• Domaine : ensemble de valeurs caractérisé par un nom

• Relation : sous-ensemble du produit cartésien d'une liste de domaines

– caractérisé par un nom unique
– représentée sous forme de table à deux dimensions
– colonne = un domaine du produit cartésien
– un même domaine peut apparaître plusieurs fois
– ensemble de nuplets sans doublon

• Attribut : une colonne dans une relation

– caractérisé par un nom et dont les valeurs appartiennent à un domaine
– les valeurs sont atomiques

• Nuplet : une ligne d'une relation

– correspondant à un enregistrement c à d une entité/instance de classe
– enregistrement, c-à-d – les nuplets d'une relation sont tous différents
 Modèle relationnel
Lien entre le modèle Entité Association et le modèle relationnel

Modèle E/A => Modèle relationnel

Association; Entité =>Table(relation)

Propriété =>Attribut

Identifiant =>Clé Primaire

 Instances et schéma du Modèle
relationnel
Instances de base de données :les nuplets (les
valeurs) contenus dans la base à un instant donné
Schéma de base de données :
– ensemble de schémas de relation
– modélisation logique de la base de données à
l’aide du modèle relationnel
Schéma de relation :liste d’attributs et leurs
domaines
 Passage au relationnel
Transformation des ensembles d’entités
chaque ensemble d'entités/classes E ⇒

– une relation R dont le schéma est celui de l'ensemble d'entités/classe

– l'identificateur de E devient la clé de R

chaque ensemble d'entités faibles/association qualifiée E ⇒

– une relation R qui comprend tous les attributs de E +

– l'identificateur de l'ensemble d'entités fortes/classe associé(e)

généralisation-spécialisation/héritage ⇒

– l'ensemble d'entités généralisant/classe mère E ⇒ une relation R

– chaque ensemble d'entités Ei spécialisé/classe fille ⇒ une relation Ri dans

laquelle identifiant est de même domaine que l'identifiant de E
Passage d’un schéma Entité/Association à un Schéma Relationnel
Etape 1 : Toute classe d’entités du diagramme entité/association est représentée par une
relation dans le schéma relationnel équivalent. La clé de cette relation est l’identifiant de
la classe d’entités correspondante.

Etape 2 : Toute classe d’association est transformée en relation.

La clé de cette relation est composée de tous les identifiants des entités participantes

IMPORTANT : NumActeur et NumFilm sont des clés étrangères dans JOUE

 Passage d’un schéma Entité/Association à un Schéma
Relationnel
Etape 3 (optimisation) : Toute classe d’associations reliée à une classe d ’entités avec
une cardinalité de type 0,1 ou 1,1 peut être fusionnée avec la classe d ’entités. Dans ce
cas on déplace les attributs de la classe d ’associations vers ceux de la relation
traduisant la classe d’entités.

Notre schéma peut être optimisé car il contient une association de type 1,1.

A l’issue de l’étape de 2 de notre L’optimisation dit : La table qui traduit

transformation nous aurons donc :
ACTEURS(NumActeur, Nom, Prénom)
FILMS(NumFilm, Titre, MetteurEnScène)
CINEMA(NumCinéma, Nom, Adresse)
REALISATEURS(NumReal,Nom, Prénom)
JOUE(NumACteur, NumFilm, Rôle)
AFFICHE(NumFilm, NumCinema,Date)
REALISE(NumFilm,NumRéal)
l’association REALISE n’a pas lieu d’être. Il
faut l’éliminer.
On déplace les attributs de REALISE
(NumFilm et NumReal) vers ceux de FILMS
(côté duquel j’ai (1,1)).
La table Films devient alors:
FILMS(NumFilm,
Titre,MetteurEnScène,NumReal)
Attention : mettre NumFilm une seule fois.
Comment faire le lien?
Pour conclure, rappelons donc la description d'un
schéma relationnel.
Un schéma relationnel définit donc pour chaque
relation :
 le nom de la relation,
 la définition,
 les attributs et les domaines des dits attributs,
 les attributs clés
 les attributs externes (attributs définis dans une autre
relation)
 les contraintes d'intégrité de la relation.
 Il définit de plus les contraintes d'intégrités portant sur
plusieurs relations.
SQL:
 SQL:

Attention : même si le langage SQL est normalisé, chaque SGBD a des particularités
syntaxiques => il faut se référer à la documentation du système utilisé !
La norme SQL ANSI propose un ensemble de types qui sont donnés dans le tableau 4.1.
Ce tableau
présente également la taille, en octets, des instances de chaque type, cette taille n’étant
ici qu’à titre indicatif car elle peut varier selon les systèmes.
 Opérations sur tables
Définition de schémas de relations (et création des tables correspondantes) :
create table nom_relation (nom_attribut_1 type_attribut_1, …)
on admet que certains attributs peuvent ne pas avoir de valeur, ce qui est très différent
d’une chaîne vide ou de 0. Quand on parle de valeur NULL en SQL2, il s’agit en fait d’une
absence de valeur.

En conséquence :
1. on ne peut pas faire d’opération incluant un NULL ;
2. on ne peut pas faire de comparaison avec un NULL.

L’option NOT NULL oblige à toujours indiquer une valeur. L’option suivante permet ainsi de
garantir que tout internaute a un mot de passe.
motDePasse VARCHAR(60) NOT NULL

Le SGBD rejettera alors toute tentative d’insérer une ligne dans Internaute sans donner de
mot de passe. Si les valeurs à NULL sont autorisées, il faudra en tenir compte quand on
interroge la base.

Cela peut compliquer les choses, voire donner des résultats surprenants : il est préférable
de forcer les attributs important à avoir une valeur.
Une autre manière de forcer un attribut à toujours prendre une valeur est de spécifier une valeur par
défaut avec l’option DEFAULT.

CREATE TABLE Cinéma (nom VARCHAR (50) NOT NULL, adresse

VARCHAR (50) DEFAULT ’Inconnue’)
Quand on insérera une ligne dans la table Cinéma sans indiquer d’adresse, le système affectera
automatiquement la valeur ’Inconnu’ à cet attribut.
En général on utilise comme valeur par défaut une constante, sauf pour
quelques variables fournies par le système (par exemple SYSDATE qui peut indiquer la date du jour).

Contraintes
La création d’une table il y a toujours des contraintes et il est indispensable de les inclure dans
le schéma pour assurer (dans la mesure du possible) l’intégrité de la base.
Voici les règles (ou contraintes d’intégrité) que l’on peut demander au système de garantir :

• Un attribut doit toujours avoir une valeur. C’est la contrainte NOT NULL vue précédemment.
• Un attribut (ou un ensemble d’attributs) constitue(nt) la clé de la relation.
• Un attribut dans une table est liée à la clé primaire d’une autre table (intégrité référentielle).
• La valeur d’un attribut doit être unique au sein de la relation.
• Enfin toute règle s’appliquant à la valeur d’un attribut (min et max par exemple).
Contraintes
Les contraintes sur les clés doivent être systématiquement spécifiées. La dernière (clause CHECK)
s’appuie en grande partie sur la connaissance du langage d’interrogation de SQL et sera vue
ultérieurement.

Clés d’une table

Une clé est un attribut (ou un ensemble d’attributs) qui identifie(nt) de manière unique un tuple d’une
relation.
Il peut y avoir plusieurs clés mais l’une d’entre elles doit être choisie comme clé primaire. Ce
choix est important : la clé primaire est la clé utilisée pour référencer une ligne et une seule à partir
d’autres tables. Il est donc assez délicat de la remettre en cause après coup.

En revanche les clés secondaires peuvent être créées ou supprimées beaucoup plus facilement. La
clé primaire est spécifiée avec l’option PRIMARY KEY.

CREATE TABLE Internaute (email VARCHAR (50) NOT NULL,

nom VARCHAR (20) NOT NULL,
prenom VARCHAR (20),
motDePasse VARCHAR (60) NOT NULL,
anneeNaiss INTEGER,
PRIMARY KEY (email))
Il devrait toujours y avoir une PRIMARY KEY dans une table pour ne pas risquer d’insérer deux
lignes strictement identiques. Une clé peut être constituée de plusieurs attributs :
CREATE TABLE Notation (idFilm INTEGER NOT NULL,
email VARCHAR (50) NOT NULL,
note INTEGER DEFAULT 0,
PRIMARY KEY (titre, email));

On peut également spécifier que la valeur d’un attribut est unique pour l’ensemble de la
colonne. Cela permet d’indiquer des clés secondaires.
deux artistes ne peuvent avoir les mêmes nom et prénom avec l’option UNIQUE.

CREATE TABLE Artiste(id INTEGER NOT NULL,

nom VARCHAR (30) NOT NULL,
prenom VARCHAR (30) NOT NULL,
anneeNaiss INTEGER,
PRIMARY KEY (id),
UNIQUE (nom, prenom));
Clés étrangères
les clés étrangères dans une table sont les attributs qui font référence à une ligne dans
une autre table. On spécifie les clés étrangères avec l’option FOREIGN KEY.
CREATE TABLE Film (idFilm INTEGER NOT NULL,
titre VARCHAR (50) NOT NULL,
annee INTEGER NOT NULL,
idMES INTEGER,
codePays INTEGER,
PRIMARY KEY (idFilm),
FOREIGN KEY (idMES) REFERENCES Artiste,
FOREIGN KEY (codePays) REFERENCES Pays);
FOREIGN KEY (idMES) REFERENCES Artiste
idMES référence la clé primaire de la table Artiste. Le SGBD vérifiera alors, pour toute
modification pouvant affecter le lien entre les deux tables, que la valeur de idMES
correspond bien à une ligne de Artiste
modifications
1. l’insertion dans Film avec une valeur inconnue pour idMES ;
2. la destruction d’un artiste ;
3. la modification de id dans Artiste ou de idMES dans Film.
En d’autres termes le lien entre Film et Artiste est toujours valide; pas de fausse référence
dans la base, par exemple qu’un film ne fait pas référence à un artiste qui n’existe pas
 quand la violation d’une contrainte d’intégrité que fait le SGBD?
la mise à jour est rejetée, mais il est possible de demander la répercussion de cette mise à
jour de manière à ce que la contrainte soit respectée
Les événements que l’on peut répercuter sont la modification ou la destruction de la ligne
référencée, par ON UPDATE et ON DELETE respectivement.
La répercussion consiste soit à mettre la clé étrangère à NULL (option SET NULL), soit à
appliquer la même opération aux lignes de l’entité composante (option CASCADE).
CREATE TABLE Film (titre VARCHAR (50) NOT NULL,
annee INTEGER NOT NULL,
idMES INTEGER,
codePays INTEGER,
PRIMARY KEY (titre),
FOREIGN KEY (idMES) REFERENCES Artiste
ON DELETE SET NULL,
FOREIGN KEY (codePays) REFERENCES Pays);

Dans le cas d’une entité faible, on décide en général de détruire le composant quand on
détruit le composé. Par exemple, quand on détruit un cinéma, on veut également détruire
les salles ; quand on modifie la clé d’un cinéma, on veut répercuter la modification sur ses
salles.
 CREATE TABLE Salle (nomCinema VARCHAR (30) NOT NULL,
no INTEGER NOT NULL,
capacite INTEGER,
PRIMAR KEY (nomCinema, no),
FOREIGN KEY (nomCinema) REFERENCES Cinema
ON DELETE CASCADE
ON UPDATE CASCADE);
Il est important de noter que nomCinema fait partie de la clé et ne peut donc pas être NULL.
On ne pourrait donc pas spécifier ici ON DELETE SET NULL.
La spécification des actions ON DELETE et ON UPDATE simplifie considérablement la gestion
de la base par la suite : on n’a plus par exemple à se soucier de détruire les salles quand on
détruit un cinéma.
CHECK pour exprimer des contraintes portant soit sur un attribut, soit sur une ligne
CREATE TABLE Film (titre VARCHAR (50) NOT NULL,
annee INTEGER CHECK (annee BETWEEN 1890 AND 2000) NOT NULL,
genre VARCHAR (10) CHECK (genre IN (’Histoire’,’Western’,’Drame’)),
idMES INTEGER,
codePays INTEGER,
PRIMARY KEY (titre),
FOREIGN KEY (idMES) REFERENCES Artiste,
FOREIGN KEY (codePays) REFERENCES Pays);
Au moment d’une insertion dans Film, ou d’une modification de l’attribut annee ou genre, le
SGBD vérifie que la valeur insérée appartient à l’ensemble énuméré défini par CHECK.
CREATE TABLE Pays (code VARCHAR (4) DEFAULT 0 NOT NULL,
nom VARCHAR (30) NOT NULL,
langue VARCHAR (30) NOT NULL,
PRIMARY KEY (code))
INSERT INTO Pays VALUES (0, ’Inconnu’, ’Inconnue’);
INSERT INTO Pays VALUES (1, ’France’, ’Français’);
INSERT INTO Pays VALUES (2, ’USA’, ’Anglais’);
INSERT INTO Pays VALUES (3, ’Allemagne’, ’Allemand’);
INSERT INTO Pays VALUES (4, ’Angleterre’, ’Anglais’);
Si on ne fait pas de vérification automatique, soit avec CHECK, soit avec la
commande FOREIGN KEY, il faut faire cette vérification dans
l’application, ce qui est plus lourd à gérer

Modification du schéma
ALTER TABLE nomTable ACTION description
ACTION peut être principalement ADD, MODIFY, DROP ou RENAME
ALTER TABLE Internaute ADD region VARCHAR(10);
ALTER TABLE Internaute MODIFY region VARCHAR(30) NOT NULL;
ALTER TABLE Internaute ALTER region SET DEFAULT ’Tunis’;
ALTER TABLE Internaute DROP region;
Création d’index
Un index offre un chemin d’accès aux lignes d’une table qui est considérablement plus rapide
que le balayage de cette table. Les SGBDL créent systématiquement un index sur la clé primaire
de chaque table. Il y a deux raisons à cela ;
1. l’index permet de vérifier rapidement, au moment d’une insertion, que la clé n’existe pas
déjà
2. beaucoup de requêtes SQL, notamment celles qui impliquent plusieurs tables (jointures), se
basent sur les clés des tables pour reconstruire les liens. L’index peut alors être utilisé pour
améliorer les temps de réponse.
Un index est également créé pour chaque clause UNIQUE utilisée dans la création de la table.
On peut de plus créer d’autres index, sur un ou plusieurs attributs, si l’application utilise des
critères de recherche autres que les clés primaire ou secondaires.
CREATE [UNIQUE] INDEX nomIndex ON nomTable (attribut1 [, ...])
CREATE UNIQUE INDEX idxNom ON Artiste (nom, prenom);
CREATE INDEX idxGenre ON Film (genre);
Cet index permettra d’exécuter très rapidement des requêtes SQL ayant comme critère de
recherche le genre d’un film.
SELECT * FROM Film WHERE genre = ’Western’
il ne faut pas créer des index à tort et à travers, car ils ont un impact négatif sur les commandes
d’insertion et de destruction. À chaque fois, il faut en effet mettre à jour tous les index portant
sur la table, ce qui représente un coût certain
Opérations sur n-uplets

· Insertion de n-uplets dans une table :

insert into nom_relation values (valeur_attribut_1, …, valeur_attribut_n)
INSERT INTO Client (id, nom, prenom)
VALUES (40, ’foulen’, ’ali’)

· Suppression de n-uplets dans une table :

delete from nom_relation [where condition]
· Modification de n-uplets dans une table :
DELETE FROM Client
WHERE nom LIKE ’M%’

update nom_relation set nom_attribut = valeur_attribut [where condition]

UPDATE Activite
SET prix = prix * 1.1
WHERE nomStation = ’Passac’
Nom Description
SELECT Spécifie les attributs dont on souhaite connaître les valeurs.
DISTINCT Permet d’ignorer les doublons de ligne de résultat.
INTO OUTFILE Spécifie le fichier sur lequel effectuer la sélection.
FROM Spécifie le ou les relations sur lesquelles effectuer la sélection.
WHERE Définie le ou les critères de sélection sur des attributs.
GROUP BY Permet de grouper les lignes de résultats selon un ou des
attributs.
HAVING Définie un ou des critères de sélection sur des ensembles de
valeurs d’attributs après groupement.
ORDER BY Permet de définir l’ordre (ASCendant par défaut ou
DESCendant) dans l’envoi des résultats.
LIMIT Permet de limiter le nombre de lignes du résultats
 Opération de consultation
select nom_attribut_1, …, nom_attribut_n
from nom_relation_1, …, nom_relation_m
where condition_1, …, condition_p

à savoir :
- pour voir tous les attributs d’une relation : select * from nom_table
- élimination des doubles : select distinct nom_attribut …
- ordonnancement des résultats : order by nom_attribut (à la fin de la requête)
- opérateurs arithmétiques : = != > >= < <=
- opérateurs logiques : and, or, not
- test entre valeurs : nom_attribut between val_attr_1 and val_attr_2
- appartenance d’une valeur d’attribut à un ensemble : *not] in, any, all
- fonctions agrégat : avg, sum, min, max, count
- utilisation des fonctions agrégat avec groupage : group by, having

SELECT libelle, prix /1.9, ’Cours de l’euro =1. 9’,

FROM Activite
WHERE nomStation = ’Santalba’ Calcul sur les champs numériques
 manipuler simultanément plusieurs tables

La jointure permet d’exprimer des requêtes portant sur des données réparties dans plusieurs
tables
la requête suivante : donner le nom des clients avec le nom des stations où ils ont séjourné. Le
nom du client est dans la table Client, l’information sur le lien client/station dans la table Sejour

même nom d’attribut soit partagé par plusieurs tables

SELECT nom, station SELECT nomStation, tarif, libelle, prix
FROM Client, Sejour FROM Station, Activite
WHERE id = idClient WHERE Station.nomStation = Activite.nomStation

SELECT nom, station, debut, tarif

FROM Client, Sejour, Station
SELECT S.nomStation, tarif, libelle, prix WHERE ville = ’hamamet’
FROM Station as S, Activite as A AND id = idClient
WHERE S.nomStation = A.nomStation AND station = nomStation
 manipuler simultanément plusieurs tables
Les noms de région dans la base.
SELECT region FROM Station
UNION les régions à la fois des clients et des stations
SELECT region FROM Client SELECT region FROM Station
INTERSECT
SELECT region FROM Client

régions où l’on trouve des stations mais pas des clients

SELECT region FROM Station
EXCEPT
SELECT region FROM Client

REQUÊTES IMBRIQUÉES
SELECT station
FROM Sejour
WHERE idClient IN (SELECT id FROM Client WHERE ville = ’hamamet’)

si on est sûr que la sous-requête ramène un et un seul tuple

SELECT station
FROM Sejour
WHERE idClient = (SELECT id FROM Client WHERE ville = ’hamamet’)
 manipuler simultanément plusieurs tables

station pratique le tarif le plus élevé

SELECT nomStation
FROM Station
WHERE tarif >= ALL (SELECT tarif FROM Station

quelle station pratique-t-on une activité au même prix qu’à hamamet

SELECT nomStation, libelle
FROM Activite
WHERE prix IN (SELECT prix FROM Activite
WHERE nomStation = ’hamamet’)

SELECT nomStation
FROM Activite A1
WHERE EXISTS (SELECT ’x’FROM Activite A2
WHERE nomStation = ’hamamet’
AND A1.libelle = A2.libelle
AND A1.prix = A2.prix)
 manipuler simultanément plusieurs tables
SELECT COUNT(nomStation), AVG(tarif), MIN(tarif), MAX(tarif) FROM Station
SELECT nomStation, AVG(tarif) FROM Station
Combien de places réservées par ALI
SELECT SUM (nbPlaces) afficher les régions avec le nombre de stations.
FROM Client, Sejour SELECT region, COUNT(nomStation)
WHERE nom = ’ALI’ FROM Station
AND id = idClient GROUP BY region

consulter le nombre de places reservées, par client.

SELECT nom, SUM (nbPlaces)
FROM Client, Sejour
WHERE id = idClient
GROUP BY id, nom
consulter le nombre de places réservées, par client, pour les clients ayant réservé plus
de 10 places.
SELECT nom, SUM (nbPlaces)
FROM Client, Sejour
WHERE id = idClient
GROUP BY nom
HAVING SUM(nbPlaces) >= 10
exemple illustrant l’utilisation d’une sous-requête
remplacer la contrainte FOREIGN KEY par une clause CHECK.
CREATE TABLE Salle
(nomCinema VARCHAR (30) NOT NULLL,
no INTEGER,
capacite INTEGER CHECK (capacite < 300),
climatisee CHAR(1) CHECK (climatisee IN (’O’,’N’)),
PRIMARY KEY (nomCinema, no),
CHECK (nomCinéma IN (SELECT nom FROM Cinema)))

toute salle de plus de 300 places doit être climatisée :

CREATE TABLE Salle
(nomCinema VARCHAR (30) NOT NULLL,
no INTEGER,
capacite INTEGER,
climatisee CHAR(1),
PRIMARY KEY (nomCinema, no),
FOREIGN KEY nomCinema REFERENCES Cinema,
CHECK (capacité < 300 OR Climatisé = ’O’))
L’utilisation des sous-requêtes n’est pas recommandée : la contrainte
peut être satisfaite au moment de l’insertion et ne plus l’être après

Il est et recommandé, de donner un nom aux contraintes avec la

clause CONSTRAINT.
CONSTRAINT clim CHECK (capacite < 300 OR climatisee = ’O’)

• facilite la compréhension des messages

• permet de modifier ou de détruire une contrainte

ALTER TABLE Salle DROP CONSTRAINT clim

 Schémas
Un schéma est l’ensemble des déclarations décrivant une base de données au niveau
logique : tables, vues, domaines, etc.
CREATE SCHEMA agence_de_voyage
CREATE TABLE Station (...
CREATE TABLE Client (...
...
CREATE VIEW ....
...
CREATE ASSERTION ...
...
CREATE TRIGGER ...
...
Deux schémas différents sont indépendants : on peut créer deux tables ayant le même nom
La modification a lieu dans le schéma courant que l’on peut modifier avec la commande SET
SCHEMA
Par exemple, avant de modifier la table FILM, on exécute :
SET SCHEMA officiel_des_spectacles
Pour accéder à une table qui n’est pas dans le schéma courant (par exemple dans un ordre
SQL), il faut préfixer le nom de la table par le nom du schéma

SELECT * FROM officiel_des_spectacles.film

Utilisateurs
L’accès à une base de données est restreint, pour des raisons évidentes de sécurité, à des
utilisateurs connus du SGBD et identifiés par un nom et un mot de passe. Chaque
utilisateur se voit attribuer certains droits sur les schémas et les tables de chaque schéma.
La connexion se fait soit dans le cadre d’un programme, soit interactivement par une
commande du type :
CONNECT utilisateur

Les droits de cet utilisateur sont alors les suivants :

1. Tous les droits sur les éléments du schéma comme les tables ou les vues des schémas
que l’utilisateur a lui-même créé. Ces droits concernent aussi bien la manipulation des
données que la modification ou la destruction des éléments du schéma.
2. Les droits sur les éléments d’un schéma dont on n’est pas propriétaire sont accordés
par le propriétaire du schéma. Par défaut, on n’a aucun droit

6 types de droits. Les quatre premiers portent sur le contenu d’une table
Insertion (INSERT), Modification (UPDATE), Recherche (SELECT), Destruction (DELETE),
Il existe deux autres droits :
REFERENCES donne le droit à un utilisateur non propriétaire du schéma de faire référence à
une table dans une contrainte d’intégrité.
USAGE permet à un utilisateur non propriétaire du schéma d’utiliser une définition (autre
qu’une table ou une assertion) du schéma.
Nécessité de mécanismes de protection et de sécurité dans les SGBD
à différents niveaux :
a) contrôle des utilisateurs souhaitant accéder à une BD
b) contrôle de l’accès aux données (lecture, écriture)
c) contrôle de l’intégrité des données, et de la validité des MAJ
Deux classes de droits d’accès aux données :
a) consultation
b) MAJ -> insertion, suppression, modification

Exemples
Table PERSONNEL (Id, Nom, Adresse, Service, Salaire)
a) Foulen possède tous les droits d’accès (consultation, MAJ) sur PERSONNEL
b) Foulen ne possède aucun droit
c) Foulen ne peut que lire que l’information le concernant, et il ne peut pas la modifier
d) Foulen ne peut que lire que l’information le concernant, et il peut modifier son adresse
e) foulen ne peut que lire que l’information le concernant, et il peut modifier son salaire s’il
est responsable du service (information présente dans une autre table)
Pb : le schéma de la BD peut évoluer au fil du temps (MAJ des schémas de relation)
le mécanisme de contrôle des droits d’accès doit en tenir compte
Deux commandes pour l’administrateur de la base de données : grant (octroi) et
revoke (annulation)

Les droits d’accès sot stockés dans le dictionnaire des

données (méta-base). Ils sont
utilisés par le SGBD pour vérifier la validité des accès à une BD

Syntaxe :
- usage -> accès au domaine de définition d’un attribut (ou d’un ensemble d’attributs)
- select -> accès en lecture (consultation)
- insert (col) -> insertion de valeurs dans la colonne spécifiée
- insert -> insertion de valeurs dans toutes les colonnes d’une table
- update (col) -> modification de valeurs dans la colonne spécifiée
- update -> modification de valeurs dans toutes les colonnes d’une table
- delete -> suppresion de n-uplets
- references (col) et references -> possibilité de faire référence à certaines colonnes
ou à toutes les colonnes d’une table dans des contraintes d’intégrité
- all -> tous les droits
Forme générale de la commande grant :
GRANT <privilege>
ON <element du schema>
TO <utilisateur>
[WITH GRANT OPTION]

element du schema =objet = table(s), vue(s), colonne(s)

utilisateur = 1 ou plusieurs utilisateurs, ou public pour désigner tous les utilisateurs
with grant option = transmission des droits à d’autres utilisateurs
Exemple d’utilisation sur la table PERSONNEL

a) le directeur possède tous les droits, et il peut les transmettre

grant all on table PERSONNEL to ‘directeur’ with grant option
b) la secrétaire peut seulement insérer des n-uplets
grant insert on table PERSONNEL to ‘secrétaire’
c) le DRH peut augmenter les salaires
grant select, update (Salaire) on table PERSONNEL to ‘DRH’

GRANT SELECT ON Film TO ALI

GRANT ALL PRIVILEGES ON Film TO PUBLIC

On supprime un droit avec la commande REVOKE dont la syntaxe est semblable à celle de
GRANT.

Forme générale de la commande revoke

revoke droit on objet from utilisateur

revoke select on table PERSONNEL from ‘foulen’

REVOKE SELECT ON Film FROM ALI

vues
une requête produit toujours une relation. Cela suggère la possibilité d’ajouter au
schéma des tables ’virtuelles’ qui ne sont rien d’autres que le résultat de requêtes
stockées.

De telles tables sont nommées des vues dans la terminologie relationnelle.

On peut interroger des vues comme des tables stockées.

Une vue n’induit aucun stockage puisqu’elle n’existe pas physiquement, et permet
d’obtenir une représentation différente des tables sur lesquelles elle est basée.

La syntaxe de création d’une vue

CREATE VIEW <nom-vue>
AS <requête>
[WITH CHECK OPTION]

Exemple : on peut créer une vue qui ne contient que les cafés de bardo

CREATE VIEW CaféBardo

AS SELECT * FROM café
WHERE ville = ’bardo’
vues
CREATE VIEW Casting (film, annee,
acteur, prenom) AS
SELECT titre, annee, nom, prenom
FROM Film f, Role r, Artiste a
WHERE f.idFilm = r.idFilm
AND r.idActeur = a.idArtiste

On peut utiliser les vues et les tables dans des requêtes SQL.
Par exemple la requête Quels acteurs ont tourné un film en 2010
SELECT acteur, prenom
FROM Casting
WHERE annee = 2010

On peut ensuite donner des droits en lecture sur cette vue pour
que cette information limitée soit disponibleà tous.
GRANT SELECT ON Casting TO PUBLIC
Mise à jour d’une vue
Il existe de sévères restrictions sur les droits d’insérer ou de mettre-à-jour des tables
à travers les vues.
insérer une ligne dans la vue Casting. Cet ordre s’adresse à une vue issue de trois tables.
INSERT INTO CASTING (film, annee, acteur, prenom) VALUES (’Titanic’, 1998, ’DiCaprio’,
’Leonardo’);
Il n’y a clairement pas assez d’information pour alimenter ces tables de manière cohérente, et
l’insertion n’est pas possible (de même que toute mise à jour). De telles vues sont dites non
modifiables.
Les règles définissant les vues modifiables sont très strictes.
1. La vue doit être basée sur une seule table.
2. Toute colonne non référencée dans la vue doit pouvoir être mise à NULL ou
disposer d’une valeur par défaut.
3. On ne peut pas mettre-à-jour un attribut qui résulte d’un calcul ou d’une
opération.
L’usage l’option WITH CHECK OPTION permet de garantir que toute ligne insérée
dans la vue satisfait les critères de sélection de la vue.
CREATE VIEW cafébardo
AS SELECT * FROM café
WHERE ville = ’bardo’
WITH CHECK OPTION
 triggers
Le mécanisme de triggers (que l’on peut traduire par ’déclencheur’ ou ’réflexe’) implanté
dans de nombreux SGBD
Absent de la SQL2 mais constitue un des points de discussion de la norme SQL3

Un trigger est une procédure qui est déclenchée par des évènements
de mise-à-jour spécifiés par l’utilisateur et ne s’exécute que quand
une condition est satisfaite
les triggers sont une extension potentielle aux contraintes proposées par CHECK : sauf que
• l’évènement déclencheur est explicitement indiqué,
• l’action n’est pas limitée à la simple alternative acceptation/rejet

Actions offertes
• La possibilité d’éviter les risques d’incohérence dus à la présence de redondance.
• L’enregistrement automatique de certains évènements (auditing).
• La spécification de contraintes liées à l’évolution des données (exemple : le prix
d’une séance ne peut qu’augmenter).
• Toute règle complexe liée à l’environnement d’exécution (restrictions sur les
horaires, les utilisateurs, etc).
 triggers
Le mécanisme de triggers (que l’on peut traduire par ’déclencheur’ ou ’réflexe’) implanté
dans de nombreux SGBD
Absent de la SQL2 mais constitue un des points de discussion de la norme SQL3

Un trigger est une procédure qui est déclenchée par des évènements
de mise-à-jour spécifiés par l’utilisateur et ne s’exécute que quand
une condition est satisfaite
les triggers sont une extension potentielle aux contraintes proposées par CHECK : sauf que
• l’évènement déclencheur est explicitement indiqué,
• l’action n’est pas limitée à la simple alternative acceptation/rejet

Actions offertes
• La possibilité d’éviter les risques d’incohérence dus à la présence de redondance.
• L’enregistrement automatique de certains évènements (auditing).
• La spécification de contraintes liées à l’évolution des données (exemple : le prix
d’une séance ne peut qu’augmenter).
• Toute règle complexe liée à l’environnement d’exécution (restrictions sur les
horaires, les utilisateurs, etc).
Principes des triggers
Le modèle d’exécution des triggers est basé sur la séquence Evénement-
Condition-Action (ECA)
1. un trigger est déclenché par un évènement, spécifié par le programmeur, qui est en
général une insertion, destruction ou modification sur une table ;
2. la première action d’un trigger est de tester une condition : si cette condition ne
s’évalue pas à TRUE, l’exécution s’arrète ;
3. l’action proprement dite peut consister en toute opération sur la base de données :
les SGBD fournissent un langage permettant de créer des procédures.
• Un trigger permet de manipuler simultanément les valeurs ancienne et nouvelle
de la donnée modifiée, ce qui permet de faire des tests sur l’évolution de la base.
• un trigger peut être exécuté au choix une fois pour un seul ordre SQL, ou à chaque
ligne concernée par cet ordre.
• l’action déclenchée peut intervenir avant l’évènement, ou après.
L’utilisation des triggers permet de rendre une base de données
dynamique : une opération sur la base peut en déclencher d’autres, qui
elles-mêmes peuvent entraîner en cascade d’autres réflexes. Ce
mécanisme n’est pas sans danger à cause des risques de boucle infinie.
L’utilisation des triggers permet de rendre une base de
données dynamique : une opération sur la base peut en
déclencher d’autres, qui elles-mêmes peuvent entraîner en
cascade d’autres réflexes. Ce mécanisme n’est pas sans
danger à cause des risques de boucle infinie.

Syntaxe
CREATE trigger <nom-trigger>
<quand> <événements> ON <table>
[FOR EACH ROW [WHEN <condition>]]
BEGIN
<action>
END;
exemple de trigger qui maintient la capacité d’un cinéma à chaque MAJ sur la table
Salle
CREATE TRIGGER CumulCapacite
AFTER UPDATE ON Salle
FOR EACH ROW
WHEN (new.capacite != old.capacite)
BEGIN
UPDATE Cinema
SET capacite = capacite - :old.capacite + :new.capacite
WHERE nom = :new.nomCinema;
END;
Pour garantir la validité du cumul, il faut créer des triggers sur UPDATE et INSERT.
Une solution plus concise (mais plus coûteuse) est de recalculer systématiquement
le cumul, c.a.d un trigger qui se déclenche globalement
CREATE TRIGGER CumulCapaciteGlobal
AFTER UPDATE OR INSERT OR DELETE ON Salle
BEGIN
UPDATE Cinema C
SET capacite = (SELECT SUM (capacite)
FROM Salle S
WHERE C.nom = S.nomCinema);
END;
Les choix possibles sont :
• quand peut être BEFORE ou AFTER.
• événements spécifie DELETE, UPDATE ou INSERT séparés par des OR.
• FOR EACH ROW est optionnel. En son absence le trigger est déclenché une fois
pour toute requête modifiant la table, et ce sans condition. Sinon condition est
toute condition booléenne SQL.
• on peut référencer les anciennes et nouvelles valeurs du tuple courant avec la
syntaxe new.attribut et old.attribut respectivement.
• action est une procédure qui peut être implantée (sous Oracle, avec le langage
PL/SQL). Elle peut contenir des ordres SQL
• Les anciennes et nouvelles valeurs du tuple courant sont référencées par :new.attr
et :old.attr.
• Il est possible de modifier new et old.
Par exemple
:new.prix=500; forcera l’attribut prix à 500 dans un BEFORE trigger.

Remarque : la disponibilité de new et old dépend du contexte. Par exemple new est
à NULL dans un trigger déclenché par DELETE.
Exemples (syntaxe d’oracle):
lorsqu’un nouvel employé est inséré dans la base, le nombre d’employés figurant dans la
relation rayon de magasin doit augmenter de un pour le rayon du nouvel employé.
Dans SQL, on définit alors une action spontanée ou TRIGGER de la manière suivante :

DEFINE TRIGGER EMPINS ON INSERTION OF Employe

(UPDATE RAYON SET Nb-Employes = Nb-Employes + 1 1. Nom_rayon PK de
WHERE Nom-Rayon = NEW Employe.Nom-Rayon); RAYON
2. Employe.nom-rayon FK
Pour la suppression : de employe avec rayon
3. New c’est la nouvelle
DEFINE TRIGGER EMPSUP ON DELETE OF Employe valeur crée
(UPDATE RAYON SET Nb-Employes = Nb-Employes – 1
4. Old c’est l’ancienne
WHERE Nom-Rayon = OLD Employe.Nom-Rayon);
valeur supprimée
Ou encore pour toute modification

DEFINE TRIGGER EMPMAJ ON UPDATE OF Employe

(UPDATE RAYON SET Nb-Employes = Nb-Employes – 1
WHERE Nom-Rayon = OLD Employe.Nom-Rayon
UPDATE RAYON SET Nb-Employe = Nb-Employe + 1
WHERE Nom-Rayon = NEW Employe.Nom-Rayon);
les déclencheurs sont généralement utilisés pour:
• prévenir les changements (par exemple, empêcher une facture d'être changé
après qu'il ait été envoyé au client)
• changements et journalisation du log (par exemple, conserver une copie des
données anciennes)
• Débugger lors du développement de la base
• vérification des changements (par exemple tenir un journal des utilisateurs et les
rôles impliqués dans les changements)
• renforcer les changements (par exemple, veiller à ce que les changements
apportés à un document soient horodatés par l'horloge du serveur)
• appliquer les règles métier (par exemple, exiger que toutes les factures ont au
moins un poste pour les traiter)
• exécuter des règles métiers (par exemple, informer le gestionnaire de tous les
changements sur compte bancaire surveiller)
• répliquer les données (par exemple stocker un record de tous les changements,
pour être expédié à une autre base de données plus tard)
• améliorer les performances (par exemple mise à jour le solde du compte après
chaque opération en détail, pour accélérer les requêtes)
 PL/SQL Functions
CREATE [OR REPLACE] FUNCTION function_name
[parameters]
RETURN CREATE OR REPLACE FUNCTION employer_details_func
return_datatype; RETURN
IS VARCHAR(20);
Declaration_section IS
BEGIN emp_name VARCHAR(20);
Execution_section BEGIN
Return SELECT first_name INTO emp_name FROM
return_variable; emp_tbl WHERE empID = '100';
EXCEPTION RETURN
exception section emp_name;
Return END;
return_variable;
END;

Appel de la fonction
employee_name := employer_details_func;
Ou
SELECT employer_details_func FROM dual;
 PL/SQL procédure
CREATE [OR REPLACE] PROCEDURE
proc_name
[list of parameters] CREATE OR REPLACE employer_details_proc
IS IS
Declaration section emp_name VARCHAR(20);
BEGIN BEGIN
Execution section SELECT first_name INTO emp_name FROM
EXCEPTION emp_tbl WHERE empID = '100';
Exception section dbms_output.put_line(emp_name);
END; END;

Appel de la procédure
EXECUTE [or EXEC] procedure_name;
Ou
procedure_name;
PL/pgSQL (PostgreSQL) Pas de procédures au
niveau de postgress
CREATE FUNCTION genererIdUser() RETURNS OPAQUE AS
DECLARE
iduser integer;
BEGIN
SELECT INTO iduser MAX(id_user) FROM user;
IF iduser ISNULL THEN iduser := 0;
END IF;
NEW.id_user := iduser + 1;
RETURN NEW;
END;
LANGUAGE 'plpgsql';
 mysql
CREATE PROCEDURE simpleproc (OUT param1 INT)
BEGIN
SELECT COUNT(*) INTO param1 FROM t;
END

CALL simpleproc(@a)

CREATE FUNCTION TOTO (s CHAR(20))

RETURNS CHAR(50)
RETURN CONCAT('Bonjour, ',s,'!');

SELECT TOTO('le monde')

Bonjour, le monde!
 Le pourquoi des procédures
• L’appel d’une procédure stockée, nécessite simplement de
spécifier son nom et ses valeurs de paramètres. C'est donc moins
coûteux en termes de quantité de données qu'une commande
complète Dès lors cela réduit le trafic réseau entre les applications
et le serveur.
• Lorsqu'on crée une procédure stockée, celle-ci est compilée en un
plan qui demeure dans le cache de procédures, ce qui réduit
considérablement le coût de calcul du plan d'une requête,
gourmand en ressources processeur.
• L'utilisation de procédure stockées permet la réutilisation de
code. S'il est clair que cela n'augmente pas les performances, cela
augmente la productivité des développeurs qui ont moins de code
à produire, et qui passent donc moins de temps à le débugger.
Il faut garder à l'esprit que ce n'est pas parce que l'on utilise
exclusivement des procédures stockées que l'application sera
performante.
L’exécution d'une requête ou d'un programme fait naître au niveau du
SGBD une occurrence de transaction
Une transaction est une unité de traitement séquentiel (séquence
d'actions cohérente), exécutée pour le compte d'un usager, qui
appliquée à une base de données cohérente restitue une base de
données cohérente.

Une transaction peut être simplement l'exécution d'une requête SQL,

ou bien celle d'un programme dans lequel on a des appels au langage
de requête
transaction respecte les Contraintes d'Intégrité à la fin pourvu que
celles-ci soient respectées au début. Le respect des contraintes est à
la charge du programmeur de transaction

Les SGBD modernes ne permettent que des transactions.

Le mécanisme de gestion des transactions doit assurer :

- Atomicité: que lors d'une exécution d'une transaction toutes ses actions sont exécutées ou

bien aucune ne l'est

- Permanence: De plus les effets d'une transaction qui s'est exécutée correctement doivent

survivre à une panne

- Isolation : que chaque transaction soit isolée, de manière à éviter des incohérences lors

d'exécutions concurrentes
Pour terminer une transaction on peut :
• Valider la transaction (COMMIT) : toutes les modifications
deviennent effectives
• Annuler la transaction (ROLLBACK) : toutes les modifications sont
annulées
Les ordres DDL (create table par exemple)provoquent un COMMIT
automatique
Le modèle général de transaction est
le suivant :
BEGIN TRANSACTION ;
---- Exemple
REQUETES insert into dept values (10,
'Finance', ‘Tunis');
INSTRUCTIONS delete from emp;
----- rollback;
COMMIT ; ou bien ROLLBACK ;
Transaction Oracle
En Oracle, toute exécution fait
partie d’une transaction.
Une transaction commence avec la
première instruction DML ou set
transaction qui suit :
•la connexion (début de session)
•une instruction DDL réussie
• une validation (ordre commit)
•une annulation (ordre rollback)
Une transaction se termine juste
après
• une validation (ordre commit)
• une annulation (ordre rollback)
• déconnexion normale ⇒
validation
• déconnexion anormale ⇒
annulation
Transaction Postgres
En PostgreSQL une transaction
commence avec l’instruction start
transaction ... (ou begin) et se
termine comme en Oracle.
Si on n’utilise pas l’instruction start
transaction ... (ou begin) alors, par
défaut, chaque instruction DML est
exécutée comme une transaction
complète, on parle alors de
fonctionnement en auto commit (
Transactions longues
Exemple : organisation par une agence de voyage d’un voyage Tunis – Hongkong
Cela nécessite la réservation de plusieurs billets d’avion :
Tunis-> Paris ; Paris –> Pekin ; Pekin – >honking
On commence par réserver les 2 premiers mais si on ne peut trouver de Pekin – >
honkong, il faut tout annuler
Problèmes avec les transactions longues
• Manque de souplesse : si on ne trouve pas de voyage Pekin – > honkong, on
annule tout. alors qu’on aurait pu garder le Tunis-> Paris et essayer de passer par
Shanghai pour aller à honkong , en annulant seulement le Paris – pekin
• Autre problème : le contrôle de la concurrence effectue des blocages sur les
tables et les lignes qui ne sont relâchés qu’à la fin de la transaction ( on bloque
des places sur des vols pour paris et pour pekin)
Un problème de communication peut provoquer l’annulation des dernières alors
qu’on pourrait simplement réessayer le lendemain
 Transactions emboîtées
Extension de la notion de transaction « plate » et «préférablement courte » ,
avantages :
• Évite les annulations complètes de transactions
• Apporte plus de souplesse dans les transactions longues et multi-sites
• Permet de limiter la durée des blocages des ressources système
Définition des transactions emboîtées
Une transaction globale (mère) peut contenir des sous transactions filles qui, elles-mêmes,
peuvent avoir des filles
L’annulation d’une transaction n’annule pas nécessairement la transaction mère ; celle-ci peut :
• décider d’un traitement substitutif
• reprendre la transaction annulée
• s’annuler
• ou même ignorer l’annulation (traitement pas indispensable)
• L’annulation d’une transaction provoque l’annulation automatique de toutes ses
transactions filles

On a une meilleure structuration de la transaction

La structure des transactions est « plate » : les transactions
ne peuvent se chevaucher
Points de reprise
Sans passer au modèle des transactions emboîtées, on peut assouplir
le modèle des transactions plates
• Désigner des points de reprise dans une transaction : savepoint
nomPoint
• Possible d’annuler toutes les modifications effectuées depuis un point
de reprise :
• rollback to nomPoint
• Évite d’annuler toute la transaction et permet d’essayer de pallier le
problème insert into ….;
savepoint p1;
delete from …;
update …;
savepoint p2;
insert into …; -- Problème !
rollback to p2;
insert into …; -- on essaie autre chose
commit;
update Etudiant set note = 14 where nom = ‘foulen' ;

savepoint foulen_note ;

update Etudiant set note = 18 where nom = ‘foulena' ;

savepoint foulena_note ;

-- err! ce n'est pas foulena mais tounsi qui a 18 :

rollback to savepoint foulen_note ;

update Etudiant set note = 18 where nom = ‘tounsi ' ;

commit ;
 Propriétés des transactions - ACID
• Atomicité : un tout indivisible
• Cohérence : une transaction doit laisser la base dans un
état cohérent ; elle ne doit pas mettre les données dans
un état « anormal »
• Isolation : une transaction est isolée des autres
transactions (dans une certaine mesure…)
• Durabilité : le SGBD doit garantir que les modifications
d'une transaction validée seront conservées, même en
cas de panne
 Transactions et Contrôle de Concurrence

Exemple

Considérons deux transactions:

T1: BEGIN A=A+100, B=B-100 END
la première transaction fait un transfert de 100 du compte B vers A

T2: BEGIN A=1.06*A, B=1.06*B END

La seconde crédite les deux comptes de 6% d ’intérêts

Il n’y a aucune garantie que T1 soit réalisée avant T2 et vice-versa,

si elles sont soumises en même temps. L’effet doit être équivalent à
une exécution en série de ces deux transactions, quelque soit l’ordre
 Ordonnancement des Transactions
Exécution en série: une transaction après l’autre.
Exécutions équivalentes : Quelque soit la BD, l’effet de la
première exécution est identique à l’effet de la seconde
exécution (moyen de vérification : ordre des lectures et
écritures conflictuels).
Exécution sérialisable: Equivalente à une exécution en série.
Si chaque transaction préserve la cohérence, toute
exécution en série préserve la cohérence.
 ANOMALIES
Lecture des données non validées (commit non effectué),
“dirty reads” :

“dirty reads

Ré-écriture sur une valeur non validée (Uncommited Data):

Uncommited Data
Transaction: Atomicité, Cohérence, Isolation, Durabilité
Exécution
Recouvrabilité : Possibilité d’annuler l’effet d’une transaction qui
abandonnée (abort).
Solution : Ordre des Commit effectués par les transactions suit
l’ordre de dépendances Lecture(X)/Ecriture(X).

Sans Abandons en Cascade (Cascadeless) : la lecture d’une valeur

écrite par une transaction T ne peut se faire qu’une fois T a réalisé
sont Commit. Cascadeless ----> Recouvrable

Strict : l’écriture d’une valeur déjà affectée par une autre

transaction T ne peut se faire qu’une fois T a réalisé sont Commit.
Solution : Cascadeless + retarder les Write(X) jusqu’à ce que les
écritures effectuées par d’autres transactions sur X soient validées
(commit).
Même si les transactions sont cohérentes, leur entrelacement peut
conduire à des incohérences globales.
Exemple 1 :
• T1 et T2 exécutent la suite d'actions ci-dessous.
• La variable X à la fin des deux transactions a la valeur 300 alors
que sa valeur serait 400 si les deux transactions T1 et T2 s'étaient
succédées.
Exemple 2 :
La base est soumise à la contrainte d'intégrité Y=2X (X=5 et Y=10
avant), les deux transactions T1 et T2 s'exécutent, la base est alors
dans un état incohérent la CI n'étant plus vérifiée. (X=30, Y=20)
Exemple 3 :
CI : Y=2X (X=5 et Y=10 avant)
La base est cohérente après les deux transactions, maisT1 a lu des
valeurs incohérentes (X=5 et Y=60)
Avec SQL : la modification du type de transaction est réalisée avec :
SET TRANSACTION [ ISOLATION LEVEL { READ COMMITTED |
SERIALIZABLE } ][ READ WRITE | READ ONLY ]
READ UNCOMMITTED
Spécifie que les instructions peuvent lire des lignes qui ont été modifiées par d'autres
transactions, mais pas encore validées.
READ COMMITTED
Spécifie que les instructions ne peuvent pas lire des données modifiées mais non
validées par d'autres transactions. Cela permet d'éviter les lectures incorrectes.
Option par défaut dans la plus part des SGBD
REPEATABLE READ
Spécifie que les instructions ne peuvent pas lire des données qui ont été modifiées
mais pas encore validées par d'autres transactions, et qu'aucune autre transaction ne
peut modifier les données lues par la transaction active tant que celle-ci n'est pas
terminée.
SERIALIZABLE
Spécifie les indications suivantes :
•Les instructions ne peuvent pas lire des données qui ont été modifiées mais pas
encore validées par d'autres transactions.
•Aucune autre transaction ne peut modifier des données qui ont été lues par la
transaction active tant que celle-ci n'est pas terminée.
•Les autres transactions ne peuvent pas insérer de nouvelles lignes avec des valeurs
de clés comprises dans le groupe de clés lues par des instructions de la transaction
active, tant que celle-ci n'est pas terminée.
 Pour faire cela il faut gérer des verrous

Protocole 2PL: Protocole de verrouillage en 2 phases

– Chaque transaction doit obtenir un verrou partagé S (shared) sur un
granule avant de le lire, et un verrou exclusif X (exclusive) sur un
granule avant d’effectuer une écriture dessus.
– Tous les verrou émis par une transaction sont libérés à sa terminaison.
– Si une transaction émet un verrou X sur un granule, aucune
transaction ne peut obtenir un verrou (S ou X) sur le même granule.
– Une transaction ne peut émettre de verrou dès qu’elle commence à
libérer ses verrous.
Gestion des verrous
Les demandes de verrouillage et de déverrouillage sont gérées par le
gestionnaire de verrouillage
Entrées de la table des verrous (pour 1 granule):
– Nombre de transactions ayant un verrou
– Type de verrou (S ou X)
– Pointeur vers la queue de la file des demandes de verrous
verrouillage et déverrouillage sont des opérations atomiques
upgrade d’un verrou: une transaction qui détient un verrou partagé
peut demander à le transformer en verrou exclusif
Rmq : une transaction qui obéit à ce protocole a ainsi 2 phases :
une phase d ’acquisition de verrous et une phase de libération.
Dans la pratique, la phase de libération est souvent condensée en une
seul opération :COMMIT (ou ROLLACK), à la fin de la transaction.
Verrous explicites
Dans de nombreux SGBD, la résolution de conflits est évitée grâce à un
système de verrouillage des tables ou enregistrements. Les verrous sont posés
pour une transaction et persistent jusqu'à sa fin. La commande est :
– LOCK [ TABLE ] name [, ...] [ IN lockmode MODE ]

où lockmode peut être :

ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE
EXCLUSIVE | SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE |
ACCESS EXCLUSIVE

Rmq : Les verrous sont posés au niveau de la table avec cette commande.
Le niveau le plus élevé est ACCESS EXCLUSIVE qui assure que l'accès est
réservé uniquement à la transaction en cours.
C'est le niveau demandé pour la modification de la structure d'une table par
exemple.

Le verrouillage au niveau enregistrement est réalisé par la commande

– SELECT FOR UPDATE
Cette commande se met en attente de libération de verrou si les
enregistrements sont déjà verrouillés par une autre transaction.
Deadlocks
Deadlock: Des transactions en attente mutuelle.
Deux manières de gérer les deadlocks:
prévention des Deadlocks
détection des Deadlocks

Le gestionnaire de verrous peut soit détecter, soit

faire de la prévention des Deadlocks.

Le fait de gérer les verrous peut aboutir à des

problèmes imprévisibles et difficiles à corriger.
Graphe de Dépendance
Graphe dépendances : Un noeud par transaction; liens de Ti à Tj
si Tj effectue une lecture/écriture d’un granule précédemment
écrit par Ti,
ou si Tj effectue une écriture d’un granule précédemment lut par Ti.
Théorème: Une exécution est sérialisable seulement si son graphe de
précédence ne comporte pas de cycle

Théorème: Une exécution est sérialisable

seulement si son graphe de précédence ne
comporte pas de cycle
T1 T2 T3
- W(X) -
T2
- - W(Z)
- W(Y) -
- Commit - T1 T3
R(X) - -
W(Z) - -
Commit - -
R(Y)
Commit
T1 T2 T3
R(X) -
T2
- W(y)
- - -R(Y)
- - -w(z) T1 T3
- - commit
W(Z) - -
Commit - -
w(x)
Commit
• Vision des données par le SGBD : un
ensemble d’enregistrements mémoire
• Vision des données par le gestionnaire de
fichiers : un ensemble de pages mémoire
• Vision des données par le gestionnaire de
disque :un ensemble de pages disque
• Rôle du gestionnaire de buffer : passage
des pages du disque vers la mémoire (et
inversement)
 Le stockage sur disque est une des fonctionnalités les plus
sensibles d’un SGBD, et ce aussi bien pour des questions
de performances que pour des raisons de sécurité.

Un accès disque est (environ) un million de fois plus coûteux qu’un

accès en mémoire principale !
C’est vrai pour un accès aléatoire, mais très souvent les accès se
font séquentiellement si les données sont bien rangées.
un SGBD doit ranger sur disque les données

• parce qu’elle sont trop volumineuses

• parce qu’elles sont persistantes et doivent
survivre à un arrêt du système.

1.le SGBD doit toujours amener les données en

mémoire pour les traiter ;
2.si possible, les données utiles devraient résider
le plus possible en mémoire.
3.La capacité à gérer efficacement les transferts
disque-mémoire est un facteur important de
performance
L’accès à un disque se base sur l’adresse donnée à chaque bloc par
le système d’exploitation:
1. le numéro du disque dans la pile ou le numéro de la surface si
disques double-face
2. le numéro de la piste
3. le numéro du bloc sur la piste
La lecture d’un bloc, se décompose en trois étapes :
– positionnement de la tête de lecture sur la piste contenant le bloc ;
– rotation du disque pour que le bloc passe sous la tête de lecture
– transfert du bloc.
La durée d’une opération de lecture est donc la somme des temps
consacrés à chacune des trois opérations, délai de positionnement,
délai de latence et temps de transfert.
• Le temps de transfert est négligeable pour un bloc, mais devient
important quand des milliers de blocs doivent être lus.
• Le mécanisme d’écriture est semblable à la lecture, mais prend un
peu plus de temps si le contrôleur vérifie que l’écriture s’est faite
correctement
Le RAID 0 (ou stripping) :
Ce niveau de RAID permet de bénéficier de toute la capacité
des disques
RAID 0 est qu'il ne
tolère pas les
pannes. En clair un
seul disque qui
tombe en panne et
toutes vos données
sont perdues.

Exemple : nous avons trois disques durs de 100 Go chacun, et nous

souhaitons copier un fichier de 300 Mo. Le RAID 0 va copier 100 Mo
sur chaque disque. Théoriquement, nous allons donc 3 fois plus vite.
En pratique, c'est loin d'être le cas (des gains de 40 % avec deux
disques sont déjà énormes)
Inconvénient du RAID 1
la capacité totale est égale à la capacité du disque le plus
petit de votre agrégat (ensemble)
Situation de départ

D1: 11110000 RAID4 au moins 3 disques

D2: 10101010
D3: 00110011 physiques , dont deux
DC: 01101001 identiques
Supposons par exemple que le disque 2 tombe en panne. On dispose
des informations suivantes :
D1: 11110000
D3: 00110011
DC: 01101001

On doit affecter des 0 et des 1 aux bits du disque 2 de manière à

rétablir un nombre pair de 1 dans chaque colonne.
Pour la première position, il faut mettre 1, pour la seconde 0, pour la
troisième 1, etc.
On reconstitue ainsi facilement la valeur initiale 10101010
 RAID 5
Problème 1 du RAID 4 : n fois plus d’écritures sur
le disque de contrôle. Disque DC ralenti les
opérations.
Solution RAID 5 : les blocs de parité sont
distribués sur les n+1 disque. Donc ne pas
dédier un disque aux données de parité, mais
de répartir les blocs de parité sur les autres
disques .

par rapport au RAID 4, quand on modifie un bloc sur un disque D1 il faut

savoir quel est le disque D2 qui qui contient les données de parité pour
ce bloc.
Il est possible par exemple de décider que pour le bloc i c’est le bloc I
mod n (n étant nb disque) qui stocke le bloc de parité

Et si deux disques tombaient en panne ?

RAID 6
RAID6 prend en compte l’hypothèse d’une défaillance
simultanée d’au moins deux disques. Dans un tel cas
l’information sur la parité devient inutile pour reconstituer
les disques .
• si la parité est 0, l’information perdue est soit 00, soit 11
• si la parité est 1, l’information perdue peut être 01 ou 10

Usage d’une codification plus puissante que la parité : les

codes de Hamming ou les codes de Reed-solomon.

Ces codes permettent de reconstituer l’information même

quand plusieurs disques subissent des défaillances, le prix à
payer étant une taille plus importante que la simple parité, et
donc l’utilisation de plus de disques de contrôles.
RAID 6
RAID6 prend en compte l’hypothèse d’une défaillance
simultanée d’au moins deux disques. Dans un tel cas
l’information sur la parité devient inutile pour reconstituer
les disques .
• si la parité est 0, l’information perdue est soit 00, soit 11
• si la parité est 1, l’information perdue peut être 01 ou 10
Le RAID 6 enregistre deux fois les informations de parité au
lieu d'une pour le RAID 5
A nombre de disques équivalent, les performances en
écriture du RAID 6 sont inférieures à celles du RAID 5.
Ce mode nécessite au moins 4 disques pour fonctionner. La
capacité utilisable est la capacité de votre disque le plus petit
multiplié par le nombre de disques -2. ex: pour 4 disques de
60 Go, la capacité utilisable de 60*(4-2) = 120 Go
 RAID 6
Usage d’une codification plus puissante que la parité : les codes de
Hamming ou les codes de Reed-solomon.
Ces codes permettent de reconstituer l’information même quand
plusieurs disques subissent des défaillances, le prix à payer étant une
taille plus importante que la simple parité, et donc l’utilisation de plus
de disques de contrôles.

RAID 7
C'est le summum des niveaux de RAID : il permet la gestion de 48
disques. Le nombre de disques destinés au stockage des données et de
la parité est paramétrable. Les performances en écriture sont de 2 à 6
fois supérieures et celles en lecture sont elles aussi très élevées grâce à
la présence d'un cache.
Cette solution est toutefois peu utilisée car elle est très coûteuse à
mettre en œuvre.
équilibre entre la performance et la sécurité
Performance
• Taille et usage du buffers
• Fréquences d’échanges entre le buffer et le disque
Défaillance
• Un défaillance en mémoire centrale implique une perte des
données modifiées mais non encore écrites sur disque.
• Si un disque est endommagé toutes les données sont
perdues et il faut recourir à une sauvegarde.
• une perte d’information (tout ce qui a été fait depuis la
dernière sauvegarde est prévu)
• une perte de temps due à l’indisponibilité du système
pendant la récupération sauvegarde.
Le RAID 01 :
Il cumule l'avantage du Raid 0 et 1 : il y a dans
notre exemple 4 disques. On met les disques
en Raid 0 deux par deux. Les disques logiques
crées (deux dans notre cas) sont mis en Raid
1. Résultat : des performances en lecture et
écriture largement améliorées et la possibilité
de perdre deux disques (dans notre cas on
peut perdre les deux disques d'un ensemble
Raid 0)
Le RAID 10 :
C'est l'inverse du Raid 01, dans le sens ou les
disques sont d'abord placés en Raid 1 pour ne
former qu'une unité en Raid 0. On obtient
ensuite une capacité égale aux deux disques
Raid 1 si ceux ci sont de même capacité. Cette
configuration permet la perte de deux
disques.
Le Raid X0 :
Ce mode désigne en fait des niveaux comme le Raid "50" ou encore "10
Dans le cas du mode 50, on prend un ensemble Raid 5 monté ensuite en
Raid 0
Reprise du système:
Défaillance locale (transaction particulière) : discutée
précédemment. N ’affecte que la transaction dans laquelle la
défaillance s ’est produite.
Défaillance globale : affecte toutes les transactions en cours d
’exécution au moment de la défaillance => nombreuses
conséquences au niveau du système.
Il en existe 2 types :
– défaillances système, dites douces : pannes de courant, …
– défaillances des supports, dites dures : disques
endommagés, fichiers perdus, ...
On traite les défaillances douces, les défaillances dures nécessitent d ’avoir des
copies de sauvegarde, un journal, des utilitaires de sauvegarde,....
Dans les défaillances système, le point crucial est le contenu, volatile, de la
MC. Les contenus des tampons de la DB en MC sont perdus. L ’état précis des
transactions en cours d’exécution au moment de la défaillance est inconnu. De
telles transactions ne peuvent jamais se terminer par un succès et doivent
être annulées (rollback).
De plus, il pourrait être nécessaire de « rejouer » certaines transactions lors
du redémarrage du système. Ce sont celles qui ont effectué leur COMMIT
avant la défaillance et dont les mises à jour n ’ont pas eu le temps d ’être
inscrites dans la base.
Pour effectuer ce travail, le système utilise le contenu du journal (log).
A certains intervalles prédéfinis, le système positionne un point de contrôle
(checkpoint) qui consiste :
à écrire physiquement (écriture forcée) le contenu des tampons en MC sur les
fichiers disque.
À écrire physiquement le compte-rendu du point de contrôle dans le journal
physique sur disque (log). Ce compte-rendu donne la liste de toutes les
transactions qui étaient en cours d ’exécution lors du positionnement du point
de contrôle.
1. Les transactions de type T1 sont terminées avec succès (commit) avant tc.
2. Les transactions de type T2 ont débuté avant tc, et se sont terminées avec
succès (commit) après tc et avant tf.
3. Les transactions de type T3 ont également débuté avant tc, mais ne se sont
pas terminées à la date tf.
4. Les transactions de type T4 ont débuté après tc, et se sont terminées avec
succès (commit) avant tf.
5. Les transactions de type T5 ont aussi débuté après tc, mais ne sesont pas
terminées à la date tf.
Il est clair que, lorsque le système est redémarré, les transactions de types T3
et T5 doivent être annulées, celles de types T2 et T4 doivent être rejouées. Les
T1 n’interviennent pas car leurs màj ont déjà été transférées sur disque lors du
chekpoint précédent (écriture forcée à la date tc).
Par conséquent, lors du redémarrage du système, la procédure suivante est
exécutée pour identifier les types de transactions T2 à T5:
Commencer par tenir 2 listes UNDO et REDO.
Initialiser la liste UNDO à toutes les transactions enregistrées dans le
compte-rendu du point de contrôle le plus récent avant la panne.
Initialiser la liste REDO à vide.
Faire une recherche en avant dans le journal en partant du point de Contrôle.
Si un COMMIT est rencontré, alors transférer la transaction T de la liste
UNDO vers REDO.
A la fin du journal, la liste UNDO contiendra les transactions de types T3et
T5. La liste REDO contiendra les transactions de types T2 et T4.
Puis le système effectue un parcours en arrière du journal, annulant
les transactions de la liste UNDO. Ensuite, il effectue à nouveau un parcours
en avant, rejouant les transactions de la liste REDO.
Remarque :

Remettre la DB dans un état cohérent en annulant le

travail est appelé parfois reprise en arrière.

remettre la DB dans un état cohérent en rejouant des

transactions est appelé parfois reprise en avant.

Enfin, lorsque l ’activité de reprise est terminée, le

système devient prêt à accepter de nouveau travaux
sur la BD.
T1 T2 T3 T4 T5
W(X) - - -
- W(y) -
W(Z) - - -
commit - -
- w(Z) -
- -w(x) - -
Abort - - -
w(y)
Commit
W(x)

REDO UNDO