Vous êtes sur la page 1sur 10

Bases

de données
avancées
1

Contenu
• Cohérence des données/Modèle
transactionnel
• Normalisation
• NoSQL
• PL/SQL ?

2
Contrôle de Cohérence
OBJECTIF:
¶ Permettre les accès concurrents aux données sans
altérer la cohérence de la base de données

· Conserver une base de donnée cohérente, même


après une panne

Base de donnée cohérente : Base de donnée telle que l’ensemble des contraintes
d’intégrité (explicites ou implicites) est respecté par les données de la base.

• Accès concurrents Þ confidentialité, intégrité globales des données (MAJ


invalide)
3
• Résistance aux pannes Þ mécanismes de « reprise sur incident »

Solutions
• Définition des contraintes d’intégrités à l’aide du Langage de Description des
Données (LDD)

• Définition des règles d’accès aux données en fonction de l’utilisateur à l’aide du


Langage de Contrôle des Données (LCD)

• Mécanisme de gestion des redondances

• Normalisation des relations

• Mécanisme de gestion de la concurrence

• Mécanisme transactionnel

• Mécanisme de reprise sur incident

• Journalisation des transactions 4

• Outils de sauvegarde « à chaud » et « à froid »


I.Contraintes d’intégrité
Contraintes d’intégrité structurelle

Contrainte d’intégrité inhérente à un modèle de données exprimant une


propriété sémantique de base du modèle.

• Contraintes « Statiques »

• Contraintes d’entité (unicité de clé, clé non nulle)

• Contrainte de domaine (type de donnée)

• Contrainte référentielle (clés étrangères)

• Contrainte de non nullité (la valeur d’un attribut ne peut être nulle)

I.Contraintes d’intégrité
Contraintes d’intégrité structurelle
-- ===============
-- Création Table : fournisseur
-- ===============
create table fournisseur
( fno char(3),
fnom varchar(100) not null,
fadresse varchar(200),
fville char(100) default 'Amiens',
primary key(fno)
)
/
-- ===============
-- Création Table : produit
-- ===============
create table produit
( pno char(8),
design char(30) not null,
pu integer,
poids integer,
couleur char(10),
primary key (pno),
check (couleur in ('rouge', 'vert', 'jaune', 'bleu', 'gris')),
check (pu between .5 and 9000), 6
check (poids > 0)
)
/
I.Contraintes d’intégrité
Contraintes d’intégrité structurelle
• Les dépendances générales:
• Les dépendances fonctionnelles.
On dit que X -> Y (X détermine Y) si pour toute valeur de X il existe une valeur
unique de Y associée.
Num_etudiant -> Nom,prenom...

• Les dépendances multivaluées.


On dit que X->> Y (X multidétermine Y) dans une relation R si pour toute valeur de
X il existe un ensemble de valeur de Y, et ceci indépendamment des valeurs des
autres attributs Z de la relation R.
Dans la table Etudiant(Num_etudiant, sport), on a:
Num_etudiant ->> sport
• Dépendance d’Inclusion : une colonne de relation doit être incluse dans
une autre relation 7

• Une ville de la relation Etudiant doit aussi être une ville de la relation
CP_ville (mettant en relation les CP avec les noms des villes)

I.Contraintes d’intégrité
Contraintes d’intégrité de comportement
Contrainte d'intégrité exprimant une règle d'évolution que doivent
vérifier les données lors des mises à jour.

• Contraintes « Dynamiques »

• Dépendance Agrégative : Restreint les valeurs possibles d’une fonction agrégat


dans une relation
Min(salaire) > 1000 dans la relation personnel
Somme(qte) < qte_stock entre relation commande et prod_en_stock

• Dépendance/Invariance Equationnelle : spécifie l ’(in)égalité de 2 expressions


arithmétiques calculées à partir d’attributs de relations et de fonctions
qte_stock = somme (qte_achetées) - somme (qte_vendues)
somme(débit) = somme (crédit) dans une relation grand_jrnl

• Dépendance Temporelle : contrainte dépendante du temps 8


Un salaire ne peut que croître
I.Contraintes d’intégrité
Outils SQL pour la gestion des contraintes

• En règle générale, géré à l ’aide de déclencheurs (triggers)

CREATE [OR REPLACE] TRIGGER <nom>

// événement (avec paramètres)


{BEFORE | AFTER}
{INSERT | DELETE | UPDATE [OF <liste de colonnes>]}
ON <table> [OR {INSERT | DELETE ... }]]
[REFERENCING {NEW|OLD} AS <alias>...]

// granularité
[FOR EACH ROW] //statement par défaut

// condition
WHEN (<condition de recherche SQL>)
BEGIN
// action
<Procédure SQL> // --PL/SQL 9
END;

I.Contraintes d’intégrité
Contraintes d’intégrité de comportement
• Exemple (ORACLE)

• Contrôle d ’intégrité temporelle

CREATE TRIGGER SalaireCroissant


BEFORE UPDATE OF Salaire ON EMPLOYE
REFERENCING OLD AS V NEW AS N
FOR EACH ROW
WHEN (V.Salaire > N.Salaire)
BEGIN
RAISE_APPLICATION_ERROR(-20010,'Les salaires ne peuvent décroître');
END;

• Implémentation du ‘ ON DELETE CASCADE ’ de l’ordre CREATE TABLE


CREATE TRIGGER DeleteProduit
BEFORE DELETE ON produit
FOR EACH ROW
BEGIN
10
DELETE FROM commande
WHERE commande.pno = :old.pno;
END;
I.Contraintes d’intégrité
Contraintes d’intégrité de comportement

• Exemple (ORACLE)

• Autre utilisation des triggers : sauvegarde automatique de tuples supprimés


CREATE TRIGGER fournisseur
BEFORE DELETE ON fournisseur
FOR EACH ROW
BEGIN
INSERT INTO oldfourn
VALUES (:Old.fno, :Old.fnom, :Old.fadresse, :Old.fville);
END;

11

II. Transactions
Unité de traitement séquentiel constitué d’une suite d’instructions à
réaliser sur la base de données qui, appliquée à une base de donnée
cohérente, restitue une base de donnée cohérente.

Chaque transaction doit avoir comme dernière action soit commit soit
abort.

• Remarques :

• Les transactions n’interagissent pas ensembles, elles ne peuvent


interagir que via la base de données
12
• Les objets contenus dans la base de données sont indépendants
II. Transactions

• Exemples

• Virement bancaire d’un compte A vers un compte B:


a : Débit d’une certaine somme X sur A (1 update)
b: Crédit de la même somme X sur B (1 update)

• Modification du taux de TVA sur les TTC des produits


a: Mise à jour du prix du premier produit de la table
b: Mise à jour du prix du second produit...

13

II. Transactions
Les menaces

• Problèmes de concurrence
• pertes d’opérations
• introduction d’incohérences
• verrous mortels (deadlock)
• Panne de transaction
• erreur en cours d'exécution du programme applicatif
• nécessité de défaire les mises à jour effectuées
• Panne système
• reprise avec perte de la mémoire centrale
• toutes les transactions en cours doivent être défaites
• Panne disque 14

• perte de données de la base


II. Transactions
Les propriétés nécessaires (ACID)

• Atomicité : toutes les opérations de la transactions


sont effectuées ou aucune ne l’est (tout ou rien)
• Cohérence : préservation de la cohérence
• Isolation : Les MAJ faites par une transaction ne sont
visibles à l’extérieur de celle-ci (pour les autres
transactions) qu’après validation (commit) de la
transaction
• Durabilité : Après la fin d’une transaction, les MAJ
(faites par cette transaction) sont définitives, même 15

en cas de pannes

III. Accès concurrent aux données


A. Les Problèmes rencontrés
Perte de mise à jour

Soient les transactions T1 et T2 suivantes, qui effectuent une MAJ sur la même
donnée :
T1 T2
x := lire(A) y := lire(A)
x := x + 10 y := y + 20
écrire(A,x) écrire(A,y)

Supposons qu’an départ A=50 et que les opérations soient effectuées dans
l’ordre suivant : T1 T2
x := lire(A)
x := x + 10
y :=lire(A)
écrire(A,x)
y := y + 20
écrire(A,y)

16
Après l’exécution, A vaut 70 : la MAJ de T2 a écrasé la MAJ de T1!
III. Accès concurrent aux données
A. Les Problèmes rencontrés
Création d’incohérence

Soient les transactions T1 et T2 suivantes, qui s ’exécutent sur une base telle
que la contrainte « A=B » doit toujours être vérifiée :
T1 T2
x := lire(A) z := lire(A)
x := x + 1 z := z * 2
écrire(A,x) écrire(A,z)
y := lire(B) t := lire(B)
y := y + 1 t := t * 2
écrire(B,y) écrire(B,t)
Supposons, qu’initialement A=10 et B=10 T1 T2
x := lire(A)
x := x + 1
écrire(A,x)
z := lire(A)
z := z * 2
écrire(A,z)
t := lire(B)
t := t * 2
écrire(B,t)
y := lire(B)
y := y + 1 17
écrire(B,y)

Après cette exécution, A=22 et B=21 ! (incohérence)

III. Accès concurrent aux données


A. Les Problèmes rencontrés
Lectures non reproductibles

Soient les transactions T1 et T2 suivantes qui utilisent la même donnée et


telles que T1 effectue 2 fois la même lecture :
T1
x := lire(A) T2
afficher x y := lire(A)
x := lire(A) y := y + 1
afficher x écrire(A,y)

Supposons, qu’initialement A=10


T1 T2
x := lire(A)
afficher x
y :=lire(A)
y := y + 1
écrire(A,y)
x := lire(A)
afficher x

18
Les deux valeurs affichées ne sont pas identiques !
III. Accès concurrent aux données
B. Caractérisation des exécutions correctes

Exécution sérialisable : Une exécution d’un ensemble de transactions est


dite sérialisable si elle donne pour chaque transaction participante, le
même résultat que l’exécution en série de ces mêmes transactions.

T1 T2
x := lire(A)
écrire(A,x)
y := lire(A)
écrire(A,y)
t := lire(B)
écrire(B,t)
u := lire(B)
écrire(B,u) 19

Vous aimerez peut-être aussi