Tuto BDD de a jusqu'à z_sql_transaction

179
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 organisationsensemble 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

description

cours complet bases de données avec les niveau de RAID ,gestion de transactions,Tous les requêtes SQL fourni par le prof de ABDENNOUR TOUMI

Transcript of Tuto BDD de a jusqu'à z_sql_transaction

Page 1: Tuto BDD de a jusqu'à z_sql_transaction

Base de données :collection d'informations ou de données qui existent sur unelongue période de temps et qui décrivent les activités d'uneou plusieurs organisations– ensemble de données modélisantles 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 utilisateursd'insérer, de modifier, et de rechercher efficacement desdonnées spécifiques dans une grande masse d'informations(pouvant atteindre plusieurs milliards d'octets) partagée parde multiples utilisateurs

Page 2: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 3: Tuto BDD de a jusqu'à z_sql_transaction

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éesensemble de définitions exprimées en langage

de description de données (DDL – DataDefinition Language)

Page 4: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 5: Tuto BDD de a jusqu'à z_sql_transaction

Le modèle entité-association

Page 6: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 7: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 8: Tuto BDD de a jusqu'à z_sql_transaction

La bonne méthodeRepré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

Page 9: Tuto BDD de a jusqu'à z_sql_transaction

La bonne méthode

Titre Année

Alien 1979

Vertigo 1958

Titanic 1997

Psychose 1960

Nom MES Prénom MES Année de Naiss

Scott Ridley 1943

Hitchcock Alfred 1899

Cameron James 1954

Hitchcock Alfred 1899

Table des films Table des réalisateurs

Ce n’est pas suffisant

Page 10: Tuto BDD de a jusqu'à z_sql_transaction

Il faut établir l’association

Titre Année ID MES

Alien 1979 1

Vertigo 1958 2

Titanic 1997 3

Psychose 1960 2

ID Nom MES Prénom MES Année de Naiss

1 Scott Ridley 1943

2 Hitchcock Alfred 1899

3 Cameron James 1954

4 Hitchcock Alfred 1899

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

Il manque encore une chose !

Conservation de l’information sans redondance

Table des films Table des réalisateurs

Page 11: Tuto BDD de a jusqu'à z_sql_transaction

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)

Page 12: Tuto BDD de a jusqu'à z_sql_transaction

Propriété : donnée élémentaire

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

2010

Concepts de base

Page 13: Tuto BDD de a jusqu'à z_sql_transaction

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)

Page 14: Tuto BDD de a jusqu'à z_sql_transaction

Les types d’entitésLe 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.

Page 15: Tuto BDD de a jusqu'à z_sql_transaction

Les clés : exemplesExemple :

– 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

Page 16: Tuto BDD de a jusqu'à z_sql_transaction

Les clés : caractéristiques souhaitablesBonne 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

Page 17: Tuto BDD de a jusqu'à z_sql_transaction

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.

• Liaison de type plusieurs à plusieurs : À toute occurrence de X correspond une ou plusieurs occurrences de Y et réciproquement

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

Un client peut commander plusieurs produits et un produit peut être commandé par plusieurs clients.

Page 18: Tuto BDD de a jusqu'à z_sql_transaction

Attention ces questions, il faut les poser dans les deux sens de A vers B puis de B vers A.

Page 19: Tuto BDD de a jusqu'à z_sql_transaction

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.

Page 20: Tuto BDD de a jusqu'à z_sql_transaction

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 0La cardinalité minimum ne peut avoir une valeur de N

Attention ces questions, il faut les poser dans les deux sens

Page 21: Tuto BDD de a jusqu'à z_sql_transaction

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

Acteurs vers Films : le rôle de type 1,N- (1) un acteur a joué dans au moins un film- (N) un acteur peut avoir joué dans plusieurs films

De Films vers Acteurs 0,N:- (0) : un film n’ayant pas d’acteurs, possible si c’est un film documentaire- (N) : un film peut avoir plusieurs acteurs

compléter le schéma ?

Page 22: Tuto BDD de a jusqu'à z_sql_transaction

Plusieurs associations peuvent exister entre les mêmes entités

Une association peut être réflexive (relie une entité à elle-même)

Exemple : L’association Est_Marié_A est de dimension deux (binaire réflexive)

un artiste peut réaliser plusieurs films ou aucun

un film ne peut être réalisé que par au plus un artiste

Page 23: Tuto BDD de a jusqu'à z_sql_transaction

Association simple (type 1)Bijection entre E1 et E2

Association conditionnelle (type c)

À chaque entité de E1 correspond au plus une

entité de E2

Association multiple (type m)

À chaque entité de E1 correspond plusieurs

entités de E2

Association multiple conditionnelle (type mc)

À chaque entité de E1 correspond aucune, une, ou plusieurs entité(s)

Page 24: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 25: Tuto BDD de a jusqu'à z_sql_transaction

La spécialisation est la division d'un ensembled'entités en sous-classes. A l'inverse lagénéralisation est un regroupement d'unensemble d'entités en une super classe. (ISA = ...is a ...)

Page 26: Tuto BDD de a jusqu'à z_sql_transaction
Page 27: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 28: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 29: Tuto BDD de a jusqu'à z_sql_transaction
Page 30: Tuto BDD de a jusqu'à z_sql_transaction
Page 31: Tuto BDD de a jusqu'à z_sql_transaction
Page 32: Tuto BDD de a jusqu'à z_sql_transaction
Page 33: Tuto BDD de a jusqu'à z_sql_transaction

ContraintesContraintes d’intégrité : toutes règles implicites ou explicites que doiventsuivre 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 prisesdans 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 deuxfois à 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 labase 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.

Page 34: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 35: Tuto BDD de a jusqu'à z_sql_transaction

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é

Page 36: Tuto BDD de a jusqu'à z_sql_transaction

Dépendances fonctionnelles

Un attribut (ou un groupe d'attributs) Y dépendfonctionnellement d'un attribut (ou grouped'attributs) X si : étant donné une valeur de X, illui correspond une valeur unique de Y (∀l'instant considéré)

X→Y : Y dépend fonctionnellement de X ou Xdétermine Y

Déclaration des dépendances au niveau duschéma conceptuel

Page 37: Tuto BDD de a jusqu'à z_sql_transaction
Page 38: Tuto BDD de a jusqu'à z_sql_transaction

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

Démarche de conception: règles

Page 39: Tuto BDD de a jusqu'à z_sql_transaction

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

Application pour modélisation

Page 40: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 41: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 42: Tuto BDD de a jusqu'à z_sql_transaction
Page 43: Tuto BDD de a jusqu'à z_sql_transaction

Instances et schéma du Modèle relationnel

Instances de base de données :les nuplets (lesvaleurs) 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 leursdomaines

Page 44: Tuto BDD de a jusqu'à z_sql_transaction

Passage au relationnelTransformation 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

Page 45: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 46: Tuto BDD de a jusqu'à z_sql_transaction

Passage d’un schéma Entité/Association à un Schéma Relationnel

A l’issue de l’étape de 2 de notre 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)

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.

L’optimisation dit : La table qui traduit 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.

Page 47: Tuto BDD de a jusqu'à z_sql_transaction

Comment faire le lien?

Page 48: Tuto BDD de a jusqu'à z_sql_transaction
Page 49: Tuto BDD de a jusqu'à z_sql_transaction
Page 50: Tuto BDD de a jusqu'à z_sql_transaction
Page 51: Tuto BDD de a jusqu'à z_sql_transaction
Page 52: Tuto BDD de a jusqu'à z_sql_transaction
Page 53: Tuto BDD de a jusqu'à z_sql_transaction
Page 54: Tuto BDD de a jusqu'à z_sql_transaction
Page 55: Tuto BDD de a jusqu'à z_sql_transaction
Page 56: Tuto BDD de a jusqu'à z_sql_transaction
Page 57: Tuto BDD de a jusqu'à z_sql_transaction

Pour conclure, rappelons donc la description d'unschéma relationnel.

Un schéma relationnel définit donc pour chaquerelation : 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.

Page 58: Tuto BDD de a jusqu'à z_sql_transaction

SQL:

Page 59: Tuto BDD de a jusqu'à z_sql_transaction
Page 60: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 61: Tuto BDD de a jusqu'à z_sql_transaction
Page 62: Tuto BDD de a jusqu'à z_sql_transaction

La norme SQL ANSI propose un ensemble de types qui sont donnés dans le tableau 4.1. Ce tableaupré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.

Page 63: Tuto BDD de a jusqu'à z_sql_transaction

Opérations sur tablesDéfinition de schémas de relations (et création des tables correspondantes) :create table nom_relation (nom_attribut_1 type_attribut_1, …)

Page 64: Tuto BDD de a jusqu'à z_sql_transaction

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.

Page 65: Tuto BDD de a jusqu'à z_sql_transaction

Une autre manière de forcer un attribut à toujours prendre une valeur est de spécifier une valeur pardé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).

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

Page 66: Tuto BDD de a jusqu'à z_sql_transaction

ContraintesLes 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 tableUne clé est un attribut (ou un ensemble d’attributs) qui identifie(nt) de manière unique un tuple d’unerelation.Il peut y avoir plusieurs clés mais l’une d’entre elles doit être choisie comme clé primaire. Cechoix 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))

Page 67: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 68: Tuto BDD de a jusqu'à z_sql_transaction

Clés étrangèresles 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 idMEScorrespond bien à une ligne de Artiste

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

Page 69: Tuto BDD de a jusqu'à z_sql_transaction

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

quand la violation d’une contrainte d’intégrité que fait le SGBD?

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

Page 70: Tuto BDD de a jusqu'à z_sql_transaction

CREATE TABLE Salle (nomCinema VARCHAR (30) NOT NULL,no INTEGER NOT NULL,capacite INTEGER,PRIMAR KEY (nomCinema, no),FOREIGN KEY (nomCinema) REFERENCES CinemaON DELETE CASCADEON 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.

Page 71: Tuto BDD de a jusqu'à z_sql_transaction

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 dansl’application, ce qui est plus lourd à gérer

Modification du schémaALTER TABLE nomTable ACTION descriptionACTION 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;

Page 72: Tuto BDD de a jusqu'à z_sql_transaction

Création d’indexUn 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 commandesd’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

Page 73: Tuto BDD de a jusqu'à z_sql_transaction

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 ClientWHERE nom LIKE ’M%’

update nom_relation set nom_attribut = valeur_attribut [where condition]UPDATE ActiviteSET prix = prix * 1.1WHERE nomStation = ’Passac’

Page 74: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 75: Tuto BDD de a jusqu'à z_sql_transaction

Opération de consultationselect nom_attribut_1, …, nom_attribut_nfrom nom_relation_1, …, nom_relation_mwhere 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 ActiviteWHERE nomStation = ’Santalba’ Calcul sur les champs numériques

Page 76: Tuto BDD de a jusqu'à z_sql_transaction

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

SELECT nom, stationFROM Client, SejourWHERE id = idClient

SELECT nomStation, tarif, libelle, prixFROM Station, ActiviteWHERE Station.nomStation = Activite.nomStation

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

SELECT S.nomStation, tarif, libelle, prixFROM Station as S, Activite as AWHERE S.nomStation = A.nomStation

SELECT nom, station, debut, tarifFROM Client, Sejour, StationWHERE ville = ’hamamet’AND id = idClientAND station = nomStation

Page 77: Tuto BDD de a jusqu'à z_sql_transaction

manipuler simultanément plusieurs tables

Les noms de région dans la base.SELECT region FROM StationUNIONSELECT region FROM Client

les régions à la fois des clients et des stationsSELECT region FROM StationINTERSECTSELECT region FROM Client

régions où l’on trouve des stations mais pas des clientsSELECT region FROM StationEXCEPTSELECT region FROM Client

REQUÊTES IMBRIQUÉESSELECT stationFROM SejourWHERE 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 tupleSELECT stationFROM SejourWHERE idClient = (SELECT id FROM Client WHERE ville = ’hamamet’)

Page 78: Tuto BDD de a jusqu'à z_sql_transaction

manipuler simultanément plusieurs tables

station pratique le tarif le plus élevéSELECT nomStationFROM StationWHERE tarif >= ALL (SELECT tarif FROM Station

quelle station pratique-t-on une activité au même prix qu’à hamametSELECT nomStation, libelleFROM ActiviteWHERE prix IN (SELECT prix FROM ActiviteWHERE nomStation = ’hamamet’)

SELECT nomStationFROM Activite A1WHERE EXISTS (SELECT ’x’FROM Activite A2

WHERE nomStation = ’hamamet’AND A1.libelle = A2.libelleAND A1.prix = A2.prix)

Page 79: Tuto BDD de a jusqu'à z_sql_transaction

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 ALISELECT SUM (nbPlaces)FROM Client, SejourWHERE nom = ’ALI’AND id = idClient

afficher les régions avec le nombre de stations.SELECT region, COUNT(nomStation)FROM StationGROUP BY region

consulter le nombre de places reservées, par client.SELECT nom, SUM (nbPlaces)FROM Client, SejourWHERE id = idClientGROUP 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, SejourWHERE id = idClientGROUP BY nomHAVING SUM(nbPlaces) >= 10

Page 80: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 81: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 82: Tuto BDD de a jusqu'à z_sql_transaction

SchémasUn 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_voyageCREATE 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

SELECT * FROM officiel_des_spectacles.film

Pour accéder à une table qui n’est pas dans le schéma courant (par exemple dans un ordreSQL), il faut préfixer le nom de la table par le nom du schéma

Page 83: Tuto BDD de a jusqu'à z_sql_transaction

UtilisateursL’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 tableInsertion (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.

Page 84: Tuto BDD de a jusqu'à z_sql_transaction

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 BDb) 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) consultationb) 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 PERSONNELb) Foulen ne possède aucun droitc) Foulen ne peut que lire que l’information le concernant, et il ne peut pas la modifierd) Foulen ne peut que lire que l’information le concernant, et il peut modifier son adressee) 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

Page 85: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 86: Tuto BDD de a jusqu'à z_sql_transaction

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 utilisateurswith grant option = transmission des droits à d’autres utilisateursExemple 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 optionb) 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

Page 87: Tuto BDD de a jusqu'à z_sql_transaction

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 utilisateurrevoke select on table PERSONNEL from ‘foulen’

REVOKE SELECT ON Film FROM ALI

Page 88: Tuto BDD de a jusqu'à z_sql_transaction

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.

vues

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éBardoAS SELECT * FROM café WHERE ville = ’bardo’

Page 89: Tuto BDD de a jusqu'à z_sql_transaction

vues

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 2010SELECT acteur, prenomFROM CastingWHERE 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

CREATE VIEW Casting (film, annee, acteur, prenom) ASSELECT titre, annee, nom, prenomFROM Film f, Role r, Artiste aWHERE f.idFilm = r.idFilmAND r.idActeur = a.idArtiste

Page 90: Tuto BDD de a jusqu'à z_sql_transaction

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ébardoAS SELECT * FROM caféWHERE ville = ’bardo’WITH CHECK OPTION

Page 91: Tuto BDD de a jusqu'à z_sql_transaction

Le mécanisme de triggers (que l’on peut traduire par ’déclencheur’ ou ’réflexe’) implanté dans de nombreux SGBD

triggers

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ènementsde 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

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

Actions offertes

Page 92: Tuto BDD de a jusqu'à z_sql_transaction

Le mécanisme de triggers (que l’on peut traduire par ’déclencheur’ ou ’réflexe’) implanté dans de nombreux SGBD

triggers

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ènementsde 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

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

Actions offertes

Page 93: Tuto BDD de a jusqu'à z_sql_transaction

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éesdynamique : une opération sur la base peut en déclencher d’autres, quielles-mêmes peuvent entraîner en cascade d’autres réflexes. Cemécanisme n’est pas sans danger à cause des risques de boucle infinie.

Page 94: Tuto BDD de a jusqu'à z_sql_transaction

L’utilisation des triggers permet de rendre une base dedonnées dynamique : une opération sur la base peut endéclencher d’autres, qui elles-mêmes peuvent entraîner encascade d’autres réflexes. Ce mécanisme n’est pas sansdanger à cause des risques de boucle infinie.

SyntaxeCREATE trigger <nom-trigger><quand> <événements> ON <table>[FOR EACH ROW [WHEN <condition>]]BEGIN<action>END;

Page 95: Tuto BDD de a jusqu'à z_sql_transaction

exemple de trigger qui maintient la capacité d’un cinéma à chaque MAJ sur la table SalleCREATE TRIGGER CumulCapaciteAFTER UPDATE ON SalleFOR EACH ROWWHEN (new.capacite != old.capacite)BEGINUPDATE CinemaSET capacite = capacite - :old.capacite + :new.capaciteWHERE 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 CumulCapaciteGlobalAFTER UPDATE OR INSERT OR DELETE ON SalleBEGINUPDATE Cinema CSET capacite = (SELECT SUM (capacite)FROM Salle SWHERE C.nom = S.nomCinema);END;

Page 96: Tuto BDD de a jusqu'à z_sql_transaction

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 foispour 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.attret :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.

Page 97: Tuto BDD de a jusqu'à z_sql_transaction

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

WHERE Nom-Rayon = NEW Employe.Nom-Rayon);

Pour la suppression :

DEFINE TRIGGER EMPSUP ON DELETE OF Employe

(UPDATE RAYON SET Nb-Employes = Nb-Employes – 1

WHERE Nom-Rayon = OLD Employe.Nom-Rayon);

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

1. Nom_rayon PK de RAYON

2. Employe.nom-rayon FK de employe avec rayon

3. New c’est la nouvelle valeur crée

4. Old c’est l’ancienne valeur supprimée

Page 98: Tuto BDD de a jusqu'à z_sql_transaction

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)

Page 99: Tuto BDD de a jusqu'à z_sql_transaction

CREATE [OR REPLACE] FUNCTION function_name[parameters]

RETURN return_datatype;

IS Declaration_section

BEGIN Execution_sectionReturn return_variable;

EXCEPTION exception section Return return_variable;

END;

PL/SQL Functions

CREATE OR REPLACE FUNCTION employer_details_funcRETURN

VARCHAR(20); IS

emp_name VARCHAR(20); BEGIN

SELECT first_name INTO emp_name FROM emp_tbl WHERE empID = '100';

RETURN emp_name;

END;

Appel de la fonction employee_name := employer_details_func;Ou SELECT employer_details_func FROM dual;

Page 100: Tuto BDD de a jusqu'à z_sql_transaction

CREATE [OR REPLACE] PROCEDUREproc_name[list of parameters]

IS Declaration section

BEGIN Execution section

EXCEPTION Exception section

END;

PL/SQL procédure

CREATE OR REPLACE employer_details_procIS

emp_name VARCHAR(20); BEGIN

SELECT first_name INTO emp_name FROM emp_tbl WHERE empID = '100'; dbms_output.put_line(emp_name);

END;

Appel de la procédure EXECUTE [or EXEC] procedure_name;Ou procedure_name;

Page 101: Tuto BDD de a jusqu'à z_sql_transaction

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

PL/pgSQL (PostgreSQL) Pas de procédures au niveau de postgress

Page 102: Tuto BDD de a jusqu'à z_sql_transaction

CREATE PROCEDURE simpleproc (OUT param1 INT)BEGINSELECT COUNT(*) INTO param1 FROM t;END

CALL simpleproc(@a)

CREATE FUNCTION TOTO (s CHAR(20))

RETURNS CHAR(50)

RETURN CONCAT('Bonjour, ',s,'!');

mysql

SELECT TOTO('le monde')

Bonjour, le monde!

Page 103: Tuto BDD de a jusqu'à z_sql_transaction

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

Le pourquoi des procédures

Page 104: Tuto BDD de a jusqu'à z_sql_transaction
Page 105: Tuto BDD de a jusqu'à z_sql_transaction

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.

Page 106: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 107: Tuto BDD de a jusqu'à z_sql_transaction

Pour terminer une transaction on peut :• Valider la transaction (COMMIT) : toutes les modifications

deviennent effectives• Annuler la transaction (ROLLBACK) : toutes les modifications sont

annuléesLes ordres DDL (create table par exemple)provoquent un COMMIT automatique

Le modèle général de transaction est le suivant :BEGIN TRANSACTION ;----REQUETESINSTRUCTIONS-----COMMIT ; ou bien ROLLBACK ;

Exemple insert into dept values (10, 'Finance', ‘Tunis');delete from emp;rollback;

Page 108: Tuto BDD de a jusqu'à z_sql_transaction
Page 109: Tuto BDD de a jusqu'à z_sql_transaction
Page 110: Tuto BDD de a jusqu'à z_sql_transaction
Page 111: Tuto BDD de a jusqu'à z_sql_transaction

Transaction Oracle Transaction Postgres

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)

En PostgreSQL une transaction commence avec l’instruction starttransaction ... (ou begin) et se termine comme en Oracle.

Une transaction se termine juste après• une validation (ordre commit)• une annulation (ordre rollback)• déconnexion normale ⇒validation• déconnexion anormale ⇒annulation

Si on n’utilise pas l’instruction starttransaction ... (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 (

Page 112: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 113: Tuto BDD de a jusqu'à z_sql_transaction

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éesUne transaction globale (mère) peut contenir des sous transactions filles qui, elles-mêmes, peuvent avoir des fillesL’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

Transactions emboîtées

Page 114: Tuto BDD de a jusqu'à z_sql_transaction

Points de repriseSans 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 chosecommit;

Page 115: Tuto BDD de a jusqu'à z_sql_transaction

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 ;

Page 116: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 117: Tuto BDD de a jusqu'à z_sql_transaction
Page 118: Tuto BDD de a jusqu'à z_sql_transaction

Exemple

Considérons deux transactions:

T1: BEGIN A=A+100, B=B-100 END

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

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

Transactions et Contrôle de Concurrence

la première transaction fait un transfert de 100 du compte B vers A

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

Page 119: Tuto BDD de a jusqu'à z_sql_transaction
Page 120: Tuto BDD de a jusqu'à z_sql_transaction

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.

Page 121: Tuto BDD de a jusqu'à z_sql_transaction
Page 122: Tuto BDD de a jusqu'à z_sql_transaction

ANOMALIES

Lecture des données non validées (commit non effectué), “dirty reads” :

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

“dirty reads

Uncommited Data

Page 123: Tuto BDD de a jusqu'à z_sql_transaction

Transaction: Atomicité, Cohérence, Isolation, Durabilité

ExécutionRecouvrabilité : Possibilité d’annuler l’effet d’une transaction quiabandonné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).

Page 124: Tuto BDD de a jusqu'à z_sql_transaction

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.

Page 125: Tuto BDD de a jusqu'à z_sql_transaction

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)

Page 126: Tuto BDD de a jusqu'à z_sql_transaction

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)

Page 127: Tuto BDD de a jusqu'à z_sql_transaction
Page 128: Tuto BDD de a jusqu'à z_sql_transaction
Page 129: Tuto BDD de a jusqu'à z_sql_transaction

Avec SQL : la modification du type de transaction est réalisée avec :SET TRANSACTION [ ISOLATION LEVEL { READ COMMITTED | SERIALIZABLE } ][ READ WRITE | READ ONLY ]

Page 130: Tuto BDD de a jusqu'à z_sql_transaction
Page 131: Tuto BDD de a jusqu'à z_sql_transaction
Page 132: Tuto BDD de a jusqu'à z_sql_transaction
Page 133: Tuto BDD de a jusqu'à z_sql_transaction

READ UNCOMMITTEDSpécifie que les instructions peuvent lire des lignes qui ont été modifiées par d'autrestransactions, mais pas encore validées.READ COMMITTEDSpécifie que les instructions ne peuvent pas lire des données modifiées mais nonvalidées par d'autres transactions. Cela permet d'éviter les lectures incorrectes.Option par défaut dans la plus part des SGBDREPEATABLE READSpécifie que les instructions ne peuvent pas lire des données qui ont été modifiéesmais pas encore validées par d'autres transactions, et qu'aucune autre transaction nepeut modifier les données lues par la transaction active tant que celle-ci n'est pasterminée.SERIALIZABLESpécifie les indications suivantes :•Les instructions ne peuvent pas lire des données qui ont été modifiées mais pasencore validées par d'autres transactions.•Aucune autre transaction ne peut modifier des données qui ont été lues par latransaction active tant que celle-ci n'est pas terminée.•Les autres transactions ne peuvent pas insérer de nouvelles lignes avec des valeursde clés comprises dans le groupe de clés lues par des instructions de la transactionactive, tant que celle-ci n'est pas terminée.

Page 134: Tuto BDD de a jusqu'à z_sql_transaction

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.

Page 135: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 136: Tuto BDD de a jusqu'à z_sql_transaction

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.

Page 137: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 138: Tuto BDD de a jusqu'à z_sql_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 fait de gérer les verrous peut aboutir à des problèmes imprévisibles et difficiles à corriger.

Le gestionnaire de verrous peut soit détecter, soit faire de la prévention des Deadlocks.

Page 139: Tuto BDD de a jusqu'à z_sql_transaction

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érialisableseulement si son graphe de précédence necomporte pas de cycle

Page 140: Tuto BDD de a jusqu'à z_sql_transaction
Page 141: Tuto BDD de a jusqu'à z_sql_transaction
Page 142: Tuto BDD de a jusqu'à z_sql_transaction
Page 143: Tuto BDD de a jusqu'à z_sql_transaction

T1----R(X)W(Z)Commit

T2W(X)-W(Y)Commit---

T3-W(Z)-----R(Y)Commit

T2

T3T1

Page 144: Tuto BDD de a jusqu'à z_sql_transaction

T1R(X)----W(Z)Commit

T2

W(y)-----w(x)Commit

T3-

-R(Y)-w(z)commit--

T2

T3T1

Page 145: Tuto BDD de a jusqu'à z_sql_transaction
Page 146: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 147: Tuto BDD de a jusqu'à z_sql_transaction

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.

Page 148: Tuto BDD de a jusqu'à z_sql_transaction

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 enmémoire pour les traiter ;

2.si possible, les données utiles devraient résiderle plus possible en mémoire.

3.La capacité à gérer efficacement les transfertsdisque-mémoire est un facteur important deperformance

Page 149: Tuto BDD de a jusqu'à z_sql_transaction
Page 150: Tuto BDD de a jusqu'à z_sql_transaction
Page 151: Tuto BDD de a jusqu'à z_sql_transaction

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-face2. le numéro de la piste 3. le numéro du bloc sur la piste

Page 152: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 153: Tuto BDD de a jusqu'à z_sql_transaction
Page 154: Tuto BDD de a jusqu'à z_sql_transaction
Page 155: Tuto BDD de a jusqu'à z_sql_transaction

Le RAID 0 (ou stripping) :Ce niveau de RAID permet de bénéficier de toute la capacité des disques

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)

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.

Page 156: Tuto BDD de a jusqu'à z_sql_transaction

Inconvénient du RAID 1la capacité totale est égale à la capacité du disque le plus petit de votre agrégat (ensemble)

Page 157: Tuto BDD de a jusqu'à z_sql_transaction
Page 158: Tuto BDD de a jusqu'à z_sql_transaction

Situation de départ

D1: 11110000D2: 10101010D3: 00110011DC: 01101001

Supposons par exemple que le disque 2 tombe en panne. On dispose des informations suivantes :D1: 11110000D3: 00110011DC: 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

RAID4 au moins 3 disques physiques , dont deux identiques

Page 159: Tuto BDD de a jusqu'à z_sql_transaction

Problème 1 du RAID 4 : n fois plus d’écritures surle disque de contrôle. Disque DC ralenti lesopérations.

Solution RAID 5 : les blocs de parité sontdistribués sur les n+1 disque. Donc ne pasdédier un disque aux données de parité, maisde répartir les blocs de parité sur les autresdisques .

RAID 5

Et si deux disques tombaient en panne ?

par rapport au RAID 4, quand on modifie un bloc sur un disque D1 il fautsavoir quel est le disque D2 qui qui contient les données de parité pource bloc.Il est possible par exemple de décider que pour le bloc i c’est le bloc Imod n (n étant nb disque) qui stocke le bloc de parité

Page 160: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 161: Tuto BDD de a jusqu'à z_sql_transaction

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 10Le RAID 6 enregistre deux fois les informations de parité au lieu d'une pour le RAID 5A 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

Page 162: Tuto BDD de a jusqu'à z_sql_transaction

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

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.

RAID 7

Page 163: Tuto BDD de a jusqu'à z_sql_transaction

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.

équilibre entre la performance et la sécurité

Performance

• Taille et usage du buffers

• Fréquences d’échanges entre le buffer et le disque

Page 164: Tuto BDD de a jusqu'à z_sql_transaction

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.

Page 165: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 166: Tuto BDD de a jusqu'à z_sql_transaction
Page 167: Tuto BDD de a jusqu'à z_sql_transaction
Page 168: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 169: Tuto BDD de a jusqu'à z_sql_transaction
Page 170: Tuto BDD de a jusqu'à z_sql_transaction

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

Page 171: Tuto BDD de a jusqu'à z_sql_transaction
Page 172: Tuto BDD de a jusqu'à z_sql_transaction
Page 173: Tuto BDD de a jusqu'à z_sql_transaction
Page 174: Tuto BDD de a jusqu'à z_sql_transaction
Page 175: Tuto BDD de a jusqu'à z_sql_transaction
Page 176: Tuto BDD de a jusqu'à z_sql_transaction

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.

Page 177: Tuto BDD de a jusqu'à z_sql_transaction

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, annulantles transactions de la liste UNDO. Ensuite, il effectue à nouveau un parcours en avant, rejouant les transactions de la liste REDO.

Page 178: Tuto BDD de a jusqu'à z_sql_transaction

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.

Page 179: Tuto BDD de a jusqu'à z_sql_transaction

T1W(X)-W(Z)commit-

T2

W(y)--w(Z)-Abort

T3------w(x)-

Commit

T4-

--w(y)

T5-

-

--

W(x)

REDO UNDO