[PDF] SGBD avances pdf guide de formation pour comprendre les bases de donnees

1

SGBD Avancés

Nicolas Anciaux et Phil

ip

pe Pucheral

Objectifs du cours

•

C

omprendre le fonctionnement interne d’un SGBD

_–S

uffisamment pour comprendre une doc. technique

–

P

our déduire le comportement au niveau des performances

–

P

our être capable de régler un SGBD

•

Illustrations

du fonctionnement interne de SGBD existants

– S GBD commercial le noyau d’ Oracle – S GBD open source le noyau de MySQL

•

A

ppréhender certaines thématiques très actuelles

_–E

ngouement actuel pour la sécurité

dans les SGBD

–

E

volution vers la mémoire Flash

–… 3

Menu …

•

S

urvol des

SGBD –

architecture générale d’

Oracle

: 1 cours

•

F

onctionnement interne des

S

GBD : 5 cours

– T rans actions –

isolation, atomicité, durabilité, répartition

–

M

odèle de stockage et d’index

ation – structures de données – M odèle d’ex écution –

algorithmes, allocation mémoire

–

O

ptimisation –

coûts des opér

ations, choix du meilleur

plan

–

S

écurité

–

droits d’accès, chiffrement, tiers de confiance

(NB: pour

chaque item, description de l’implantation dans

Ora cl e)

•

F

onctionnement interne de

MySQL

: 1 cours ½

– expos és sur le noy au de MySQL (6 sujets)

Lecture de doc. technique [en angl

ais], [analyse de code C,C++]

•

E

xamen : ½

cours

–

1h30, tous documents autorisés

Sujets d’exposés : MySQL/InnoDB

internals

• S ujet 1 – M ySQL/InnoDB internals – The Q uery Processor • S ujet 2 – M ySQL/InnoDB internals –

Transactions & Conc

urrency • S ujet 3 – M ySQL/InnoDB internals – Logging & Rec overy • S ujet 4 – M ySQL/InnoDB internals – Memory Management • S ujet 5 – M ySQL/InnoDB internals – Storage & Indexes • S ujet 6 – M ySQL/InnoDB internals – Physical D eletion • http://www-smis.inria.fr/~ancia ux/SGBD/ISTY%202007-2008/Expos es/ •P la nn in g – D

ans les deux dernières séances

–

P

5

Rappels sur les

S

GBD

Plan du cours

•

S

GBD vs. système de gestion de fichiers

•

R

evue des

apports majeurs d’un SGBD

–

D

escription canonique des données

– Indépendance logique/physique – Langage de manipulation – G

estion des vues

–

O

ptimisation des questions

–

G

estion de la cohérence

–

G

estion des pannes

– C oncurrence d’accès – G estion de la confidentialité – S tandards

•

A

rchitecture globale d’un SGBD

_–Introduction des cours suivants

•

A

rchitecture d’Oracle

7

Un système d’information

sans

SGBD

(1)

Du pont S ymp to me s : y Tur lut ut u : sq j S ymp to me s : y Tur lut ut u : sd d Analyses : xxx Du pond Tur lut ut usqjsk Sy m p to m: yyyy Analyses xxxx Tur lut ut udhjsd

Analyses :xx _Duipont Tur

lut ut u : sq Sy m p to myyyy Analysesxxxx Tur lut ut udhjsd Du hpon S ymp to me s : yy Analyses : xxxx S ymp to me s : yy ChiruSoft ConsultSoft PsychiaSoft ComptaSoft Chirurgie Psychiatrie Comptabilité Consultations

Plusieurs applications

plusieurs formats et

langages difficulté de maintenance difficult é d’interopérabilité

Redondance des données

incohérence

Pas de facilité

d’interrogation

toute question doit être prévue et programmée coût de développement élevé redondance de code difficult

é d’évolution

Un système d’information

sans

SGBD

Du pont S ymp to me s : y Tur lut ut u : sq j S ymp to me s : y Tur lut ut u : sd d Analyses : xxx Du pond Tur lut ut usqjsk Sy m p to m: yyyy Analyses xxxx Tur lut ut udhjsd

Analyses :xx _Duipont Tur

lut ut u : sq Sy m p to myyyy Analysesxxxx Tur lut ut udhjsd Du hpon S ymp to me s : yy Analyses : xxxx S ymp to me s : yy ChiruSoft ConsultSoft PsychiaSoft ComptaSoft Chirurgie Psychiatrie Comptabilité Consultations

Gestion simpliste des droits

violation de la confidentialité

Gestion simpliste du

parallélisme

blocage du système ou bien incohérence en cas d

’accès

9

L’approche Bases de données

BD

8 -C oncurrence d’accès 9 -T olér an ce au x panne s 2-Indépen d ance Physique 7 -C onfidentialité des donnée s 3-Indépen d ance Logique 6 -Intégrité des donnée s 10 -S tandard s 5 -O ptimisation de requêtes 4 – L an gage de manipulation 1-Description _canonique

I-Description

canonique

des données

Description

cohérente, unique et centralis

ée des données manipulées par l’ensemble des applic ations constituant le système d’infor m ation. — P

erception globale du système

d'information

=> augmentation du niveau d’informatisation => nouveaux traitements

(aide à

la décision, analyse de données, …)

—

F

actorisation de la description des

données et de leur comportement (contraintes d’intégrité … ) — E

limination de la redondance _{=> redondance = source}

d’incohérence

=> redondance système reste nécessaire

pour : fiabilité, performance de

consultation, disponibilité

en environnement réparti ou mobile

11

Exemple : modélisation

Relationnelle

…… …….. …. Prénom Nom Id-D Jea n Masse 3 Paul Durand 2 Pierre Dupont 1 Docteurs Visites 2 2 1 1 Id-D 1 ma rs 13 juillet 12 ao ût 15 jui n Date 250 350 180 250 Prix 4 3 2 1 Id-V 3 2 1 2 Id-P Patients ……. Paul e Joh n Zoe Jacq ues Prénom ……. ……. …. Valenton Perry 4 Ville Nom Id-P Paris Doe 3 Evry Troger 2 Paris Le beau 1 ………… …. …. …. 2 gouttes 3 3 2 12 8 5 12 Id-M 1 par jour 2 par jour 10 gouttes 1 par jour Pos o lo gie 2 1 2 1 Li gne 2 2 1 1 Id-V Prescriptions ……….. …….. …. Descr ip ti o n Nom Id-M ……….. Muco myst 3 ……….. Fluiséd al 2 ……….. Aspegic 1000 1 Médicaments

II

-Indépendance Physique

•

Indépendance des programmes d'applications vis à

vis du modèle physique des données

•

B

énéfices

_–

É

criture des applications par des non-spécialistes des

fichiers et des structures de stockage;

_–

P

ossibilité

de modifier les structures de stockage

(fichiers,

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

–

M

eilleure portabilité

des applications et indépendance

vis à

13

III

-Indépendance Logique

•

Les appli. peuvent définir des

vues logiques

de la BD

Gestion des médicaments

Cabinet du Dr. Masse 30 ………… ……… ………… . A speg ic 1000 1 20 ………… ……… ………… . Fl ui sé d al 2 230 ………… ……… ………… . Mucom yst 3 ….. ………… ……… ………… . ……. . …. Nombr e _M édi c a m ent s D esc ri p ti o n Nombr e Nom Id-M Vi s ite s 2 2 1 1 Id-D 1 m ar s 13 j uil let 12 aoû t 15 j uin Dat e 250 350 180 250 Pr ix 4 3 2 1 Id-V 3 2 1 2 Id-P Vi s ite s 2 2 1 1 Id-D 1 m ar s 13 j uil let 12 aoû t 15 j uin Dat e 250 350 180 250 Pr ix 4 3 2 1 Id-V 3 2 1 2 Id-P Pa ti en ts …… . Pa ul e John Zo e Ja cq ue s P ré nom …… . ……. …. Va le nto n Pe rry 4 Vi lle No m Id-P Pa ris Do e 3 Ev ry Tro ge r 2 Pa ris Leb eau 1 Pa ti en ts …… . Pa ul e John Zo e Ja cq ue s P ré nom …… . ……. …. Va le nto n Pe rry 4 Vi lle No m Id-P Pa ris Do e 3 Ev ry Tro ge r 2 Pa ris Leb eau 1 …… …… …. …. …. 2 gout tes 3 3 2 12 8 5 12 Id-M 1 pa r j our 2 pa r j our 10 gout tes 1 pa r j our Po so log ie 2 1 2 1 Li gne 2 2 1 1 Id-V Pr es cr ip ti on s …… …… …. …. …. 2 gout tes 3 3 2 12 8 5 12 Id-M 1 pa r j our 2 pa r j our 10 gout tes 1 pa r j our Po so log ie 2 1 2 1 Li gne 2 2 1 1 Id-V Pr es cr ip ti on s … … …… ……… ……… ….. …… .. …. Descr ip tio n No m Id-M … … …… ……… ……… ….. Mu co m yst 3 … … …… ……… ……… ….. Fluis éda l 2 … … …… ……… ……… ….. A spe gic 1000 1 Mé di ca me nt s … … …… ……… ……… ….. …… .. …. Descr ip tio n No m Id-M … … …… ……… ……… ….. Mu co m yst 3 … … …… ……… ……… ….. Fluis éda l 2 … … …… ……… ……… ….. A spe gic 1000 1 Mé di ca me nt s …… …… .. …. Prénom Nom Id-D Jean Masse 3 Paul Du rand 2 Pierre Dupont 1 Doct eu rs …… …… .. …. Prénom Nom Id-D Jean Masse 3 Paul Du rand 2 Pierre Dupont 1 Doct eu rs Vi site s 2 2 1 1 Id-D 1 m ars 13 ju illet 12 ao ût 15 juin Da te 250 350 180 250 Prix 4 3 2 1 Id-V 3 2 1 2 Id-P Vi site s 2 2 1 1 Id-D 1 m ars 13 ju illet 12 ao ût 15 juin Da te 250 350 180 250 Prix 4 3 2 1 Id-V 3 2 1 2 Id-P Pa tie nts Pau……. le John Zo e Jacques Prénom ……. ……. …. Va lenton Perry 4 Ville Nom Id-P Par is Do e 3 Evry Trog er 2 Par is Lebe au 1 Pa tie nts Pau……. le John Zo e Jacques Prénom ……. ……. …. Va lenton Perry 4 Ville Nom Id-P Par is Do e 3 Evry Trog er 2 Par is Lebe au 1 ………… …. …. …. 2 go uttes 3 3 2 12 8 5 12 Id-M 1 pa r jour 2 pa r jour 10 go uttes 1 pa r jour Posologi e 2 1 2 1 Ligne 2 2 1 1 Id-V P rescr ipt ions ………… …. …. …. 2 go uttes 3 3 2 12 8 5 12 Id-M 1 pa r jour 2 pa r jour 10 go uttes 1 pa r jour Posologi e 2 1 2 1 Ligne 2 2 1 1 Id-V P rescr ipt ions ……… ………. . …….. …. Descr iption Nom Id-M ……… ………. . Mucomyst 3 ……… ………. . Fluisédal 2 ……… ………. . Aspegic 10 00 1 Médi caments ……… ………. . …….. …. Descr iption Nom Id-M ……… ………. . Mucomyst 3 ……… ………. . Fluisédal 2 ……… ………. . Aspegic 10 00 1 Médi caments

Avantages de l’indépendance logique

•

P

ossibilité

pour chaque application

d'ignorer

les

besoins des autres (bien que partageant la même BD)

•

P

ossibilité

d'évolution de la base de données

sans

réécriture des applications

–

A

jout/renommage

de champs, ajout de relation

•

P

ossibilité

d'intégrer des applications existantes

sans modifier les autres

•

P

ossibilité

de limiter les conséquences du partage :

Données confidentielles

15

IV

-M

anipulation aisée

•

La manipulation se fait via un langage

déclaratif

–

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

–

Le langage suit une norme commune à

tous les SGBD

–

SQL : Structured

Query

L

angage

•

S

yntaxe (aperçu !)

_Select

<Liste de champs ou de calc

uls à

afficher>

From

<Liste de relations mises en jeu>

Where

<Liste de prédic

ats à

satisfaire>

Group By

<Groupement éventuel sur un ou plus

ieurs champs>

Order

B

y

<Tri éventuel sur un ou plusieurs champs>

Exemple de question SQL (1)

•

N

om et description des médicaments de type aspirine

_Select

Nom, Description

From

Médicaments

Where

T

ype = ‘Aspirine’

En algèbre:

Π

No m, Description

(σ

Type=aspirine

(M

édicaments))

17

Exemple de question SQL (2)

•

P

atients parisiens ayant effectués une visite le 15 juin

_Select

Patients.Nom, Patients.Prénom

From

Patients, Visites

Where

P

atients.Id-P = Visites.Id-P

and

P

atients.Ville = ’Paris’

and

V

isites.Date = ’15 juin’

En algèbre: Π Nom, Pr énom (σ Ville=paris et date = 15 juin (P atients Id-P=Id -P Visites))

Exemple de question SQL (3)

•

D

épenses effectuées par patient triées

par ordre

décroissant

Select

Patients.Id-P, Patients.Nom, sum(Prix)

From

Patients, Visites

Where

P

atients.Id-P = Visites.Id-P

GroupBy

P

atients.Id-P, Patients.Nom

OrderBy

sum(Prix) desc

En algèbre:

γ

Id-P, Nom, SUM(Prix)

(Patients

Id-P=Id-P

Visites)

19

Évaluation «

sémantique »

d’une requête SQL

1.

FROM Réalise le produit cartésien des relations

2.

WHER

E

Réalise restriction et jointures

3.

GROUP BY Constitue

les partitions

(e.g., tri sur l’intitulé

du groupe)

4.

HAVING Restreint aux partitions désirées

5.

SELECT Réaliser les projections/calc

uls

finaux

6.

ORDER BY Trier les tuples résultat

YYY ZZZ XXX XXX XXX XXX YYY ZZZ A GG2 AGG3 A GG1 ZZZ XXX A GG3 A GG1 AGG3 AGG1 XXX ZZZ

III’

–

G

estion des vues

•

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

logique en créant

des

objets virtuels

•

V

ue = Question SQL stockée

•

Le SGBD stocke la

définition

et non le résultat

•

E

xemple : la vue des patients parisiens

Create View

Parisiens

as

(

Select

Nom, Prénom

From

Patients

Where

P

atients.Ville = ’Paris’

)

21

Les vues :

des relations virtuelles !

Le SGBD

transforme

la question sur les vues en

question sur les relations de base

Questio

n Q

sur des vues

Définition des vues Gestionnaire de Vues

BD

Questio n Q ’

sur les relat

ions

de base

Les vues : Mise à

jour

•

N

on définie si la répercussion de la mise à

jour vers la

base de données est ambiguë…

–

A

jouter un tuple à

la vue «

nombre de médicaments »

?

•

R

estrictions SQL (norme):

_–

P

as de distinct, d’agrégats, ni d’expression de calcul

_–

La vue contient les clés et les attributs «

not

null

»

–

Il y a une seule table dans le «

from

»

–

C

ertains

S

GBDs supportent plus de mises à

jour

•

C

lause «

W

ith

check option

»

–

Le SGBD vérifie que les tuples insérés ou mis à

jour

correspondent à

la définition de la vue

23

Les vues : Les instantanés (snapshot)

_•

Instantané, Snapshot, vue concrète, vue matérialisée

–

R

ésultat matérialisé

sur le disque

–

A

ccessible seulement en lecture

–

P

eut être réactualisé

•E

xe

m

pl

e

–

create snapshot

Nombre_Médicaments

as

Select

Id-M, Nom, Description, count(*)

From

Médicaments

M

, Prescriptions P

Where

M.Id-M = P.Id-M

refresh every day

•

O

bjectif principal : la performance

V –Optimisation automatique

•

T

raduction

automatique

des questions déclaratives

en programmes impératifs :

Utilisation de l’algèbre relationnelle

•

O

ptimisation

automatique

des questions

exploitation des propriétés (commutativité, distributivité

_{…) des opérateurs de l’algèbre}

Gestion

centralisée des chemins d'accès (index,

hachages, …)

Techniques d’optimisation poussées

•

É

conomie de l'astuce des programmeurs

_–

M

25

Sélection

Patients de la ville de Paris, noté

en algèbre:

σ

Ville =pari s

(Patients)

Patients Paule John Zoe Jacques Prénom Valento n Perry 4 Ville Nom Id -P Paris Doe 3 Evry Troger 2 Paris Lebea u 1 Patients Paule John Zoe Jacques Prénom Valenton Perry 4 Ville Nom Id -P Paris Doe 3 Evry Troger 2 Paris Lebeau 1

σ

Projection

Patients Paule John Zoe Jacques Prénom Valenton Perry 4 Ville Nom Id -P Paris Doe 3 Evry Troger 2 Paris Lebeau 1

Nom et prénom des patients, noté

en algèbre:

Π

Nom, Pr énom

(Patients)

Patients Paule John Zoe Jacques Prénom Valenton Perry 4 Ville Nom Id -P Paris Doe 3 Evry Troger 2 Paris Lebeau 1

π

27

Jointure

Patients Paule John Zoe Jacques Prénom Valenton Perry 4 Ville Nom Id -P Paris Doe 3 Evry Troger 2 Paris Lebeau 1 Visites 2 2 1 1 Id -D 1 mars 13 juillet 12 août 15 ju in Date 250 350 180 250 Prix 4 3 2 1 Id -V 3 2 1 2 Id -P 4 3 1 2 Id -V 3 2 2 1 Id -P Paris Evry Evry Paris Ville John Zoe Zoe Jacques Prénom Doe Troger Troger Lebeau Nom 1 mars 13 juillet 15 ju in 12 août Date 250 2 3 Prix Id -D Id -P 350 2 2 250 1 2 180 1

1

_{Patients et leurs visites, noté}

en algèbre:

Patients

Id-P=Id-P

Visites

Exemple de plan d’exécution

Select

Patients.Nom, Patients.Prénom

From

Patients, Visites

Where

P

atients.Id-P

= Visites.Id-P

and

P

atients.Ville = ’Paris’

and

V

isites.Date = ’15 juin’

π

σ

Patients

Visites

En algèbre: Π Nom, Pr énom (σ Ville=p aris et da te = 15 juin (Patients Id-P=Id -P Visites))

29

Plan d’exécution optimisé

π

σ

Patients

Visites

π

π

σ

Visites

π

σ

Patients

Π Nom, Pr énom ( Π Nom, Pr énom, Id-P (σ Ville=paris (Patients)) Π Id-P (σ date = 15 ju in (Vis ite s)) Id-P=Id-P

Optimisation réellement nécessaire ?

•

U

ne question

•

P

lusieurs expressions

équivalentes en SQL

•

P

lusieurs expressions

équivalentes en algèbre

•

P

lusieurs algorithmes

équivalents

Coût Plans sémantiq

u ement éq uivalents Varia tion de performanc e de pl

usieurs ordres de magnitude

Ex: 5 tables 1620 plan s possibles 10 tab les 17 milliards de plans… 31

VI –

Intégrité

sémantique

•

C

ontrainte d'intégrité

:

– propriété

sémantique que doivent respecter les données afin

d'assurer la cohérence de la base.

•

O

bjectif : Détecter les

m

ises à

jour erronées et réagir

–

simplification du code des applic

ations

–

sécurité

renforcée par l'automatisation

–

évolutivité

des contraintes

–

C

ohérence globale des contraintes

BD

BD

Typologie des contraintes

d’intégrité

(1)

•

C

ontraintes de domaine

(mono-attribut)

– C ontrôle de types :

ex: Nom alphabétique

–

C

ontrôle de valeurs : ex: Salaire mensuel entre 1 et 10 K€

–

N

on Nullité

: ex: le Nom d’un patient doit être renseigné

•

C

ontraintes multi-attributs mono-tuple

_–R

elations entre données élémenta

ires : PrixVente > PrixAchat

–

R

elations temporelles : le

salaire d’un employé

ne peut pas

décroître

•

C

ontraintes multi-tuples mono-table

_–U

nic

ité

: le nro insee détermine un patient unique

–

C

33

Typologie des contraintes

d’intégrité

(2)

•

C

ontraintes multi-tuples multi-tables

_–C

ontrainte d’intégrité

référentielle

: une visite doit être liée à

un médec in et un patient existants – U n

électeur doit être inscrit sur au plus une

liste

électorale

–

C

ontrainte agrégative : la somme

des quantités vendues doit être

inférieure ou égale aux quantités produites

–

Le médic

ament X ne doit pas être prescrit en même temps que Y si

une contre-indic

ation est référencée dans le Vidal

•

P

roblème complexe

_–N éces site un langage de déc laration et un mécanis m e de vérification – Les

SGBD commerciaux supportent généralement peu de

contraintes (par rapport à

la norme SQL2)

•

P

rincipalement CI de domaine, unicité, référentielle

Contraintes d’intégrité

: Exemple

•

C

ontraintes d’intégrité

référentielles

…… …….. …. Prénom Nom Id-D Jea n Masse 3 Paul Durand 2 Pierre Dupont 1 Docteurs Visites 2 2 1 1 Id-D 1 ma rs 13 juillet 12 ao ût 15 jui n Date 250 350 180 250 Prix 4 3 2 1 Id-V 3 2 1 2 Id-P ………… …. …. …. 2 gouttes 3 3 2 12 8 5 12 Id-M 1 par jour 2 par jour 10 gouttes 1 par jour Pos o lo gie 2 1 2 1 Li gne 2 2 1 1 Id-V Prescriptions • V

érification lors de l’ins

ertion,

la suppression, la modification

•

P

ropagation des suppressions/modifications en cascade possible

(on delete/update cascade)

35

Contraintes d’intégrité

: Syntaxe

create

table

<nom de table> (

<attribut> <domaine>

[<contrainte d'attribut>],

(mono-attribut)

<attribut> <domaine>

[<contrainte d'attribut>], …

[<contrainte de relation>]

)

(mono ou multi-attributs)

•

Différent types de contraintes :

–

N on nullité : not null –U n ic ité : unique – V érification : check <formule> – C lé primaire : primary key – C ontrainte d’intégrité référentielle : references <relation> (<attribut>) • on delete / on update

cascade, set null, set default

•

O

n peut nommer les contraintes

Déclencheurs : Définition

•

D

éfinition : Déclencheurs ou Triggers

_–

R

èg

le

E

–C

–A

–

É

vénement

–

[Condition]

–

A

ction

•

Lorsque l’évènement se produit

–

Insert / Update / Delete

pour une relation donnée

•

si la condition est remplie

–

P

rédicat SQL optionnel

•

alors exécuter l’action

–

C

ode à

exécuter (ex. PL/SQL

sous Oracle)

–

P

our chaque tuple concerné

37

Déclencheurs : Objectifs

•

O

bjectif : une base de données ‘active’

_–

valider les données entrées

_–

créer un audit de la base de données

_–

dériver des données additionnelles

_–

m

aintenir des règles d’intégrité

complexes

–

implanter des règles métier

–

supporter des alertes (envoi de e-mails par exemple)

•G

ai

n

s

–

simplification du code des applications

–

sécurité

renforcée par l'automatisation

–

les déclencheurs sont stockées dans la base

–

C

ohérence globale des déclencheurs

Déclencheurs : Syntaxe (dans Oracle)

Create

trigger <nom de trigger>

before

| after

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

insert | delete

| update [of <attributs>]

indique l’événement

déclencheur

on <relation>

indique le nom de la tabl

e qui doit être surveillée

[referencing

old

as <var>, new as <var>]

en SQL3, O

racle utilise :new et :old

for each row

précise si l’action est ex

écuté

1 fois par

tuple touché

ou pour toute la table

[when <condition>]

permet d

’indiquer

une c

ondition pour l’exécution du trigger

DECLARE

déclaration de variables pour le bloc PL/SQL

BEGIN

bloc PL/SQL contenant le code de l’action à

exécuter

<PL/SQL bloc>

dans SLQ3, on peut indiquer une suite de commande SQL

END

•

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

39

Déclencheurs : Exemples simples

Create trigger calcul_TTC after insert on Vente Begin

update vente set Prix_TTC

= Prix_HT*1.206 End ; Create trigger Modif C ommande after update on Commande For each row Begin if :new.q te< :o ld.qte then rais e_application_error(-9996,‘ La quantité ne peut diminuer’); End ; Create trigger Modif C ommande after update on Commande For each row When (new.qte< old.qte) Begin raise_applic ation_error(-9996, ,‘ La quantité ne peut diminuer’); End ;

Déclencheurs : Remarques finales

•

C

ascade de triggers

_–

l’action d’un trigger peut déclencher d’autres triggers

•

Interactions avec les contraintes

–

l’action d’un trigger peut ca

user la vérification des

contraintes

–

les actions des contraintes référentielles peuvent déclencher

des triggers (delete

cascade, update cascade)

•

M

écanisme très (trop ?) puissant

_–

C

ascade ‘infinie’

_–

T

ables en ‘mutation’

41

VII –

T

olérance aux pannes

•

M

otivations

_–

T

ransaction Failure

: Contra

intes d'intégrité, Annulation

–

S

ystem Failure

: Panne de courant, Crash serveur

–

M

edia Failure

: Perte du disque

–

C

ommunication Failure

: Défaillance du réseau

•

O

bjectifs

_–

A

ssurer l‘Atomicité

des transactions

–

G

arantir la Durabilité

des effets des transactions commises

•

M

oyens

_–

Journal mémorisant les états successifs

des données

–

M

écanismes de reprise

Transaction

Etat cohérent Etat cohérent Incohéren c e possible... Begin C ommit Transaction

Begin

CEpargne = CEpargne

-3000

CCourant = CCourant + 3000

_{Commit T1}

43

Atomicité

et Durabilité

ATOMICITE

Begin

CEpargne = CEpargne

-3000

CCourant = CCourant + 3000

_{Commit T1}

Annuler le débit !!

Panne

DURABILITE

Begin

CEpargne = CEpargne

-3000

CCourant = CCourant + 3000

_{Commit T1}

S’assurer que le

_{virement a été}

fait !

Crash d isqu e

VIII:

Accès concurrents

aux données

— O bjectif : assurer l’Isolation des transaction, c.à.d que différentes applic ations partageant les mê

mes données doivent pouvoir

s'ignorer et tr availler de manière asynchrone. — Le S GBD garantit la sérialis abilité des accès: l'effet d'une exécution simultanée de transactions doit être

le même que celui

d'une exécution séquentielle. < T1 ||

T2 …|| Tn > ≡ < T1; T2; … T n > —

Les transactions exécutées

en parallèle ne doivent pas entrer en conflit lecture-écriture ou écriture-écriture, afin d’év iter : • des pertes de mises à jour •

des introductions d’incohérenc

e

•

45

IX –

C

onfidentialité

•

Objectif : Protéger les données de la BD contre

des accès non autorisés

•

D

eux niveaux

_–

C

onnexion restreinte aux

usagers répertoriés

(identification/authentification)

–

Privilèges

d'accès aux objets de la base

•

U

sagers : Usager,

rôles

•

O

bjets : Relation,

Vue

, autres objets

(procédures, etc.)

Puissance des droits SGBD

160 380 120 230 Salaire Paris Chartres Versailles Paris Ville 4049 5489 1254 5485 Poste Joe Zoe Jack Jim Prénom Doe Lerich Trock Ricks Nom ………. 4 Adresse Id -E ………. 3 ………. 2 ………. 1 4049 5489 1254 5485 Poste Joe Zoe Jack Jim Prénom Doe Lerich Trock Ricks Nom 4 Id -E _{1 2 3} 890 Masse _Salariale Nombre _d’employ é s 4 Servic e des ressources humaines Employés (intranet) Public (internet) 47

X

-S

tandardisation

•

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

standards

–

Langage SQL (SQL1, SQL2, SQL3)

–

C

ommunication SQL CLI (ODBC / JDBC)

–

T

ransactions (X/Open DTP, OSI-TP)

•

F

orce des standards

_–

P

ortabilité

–

Interopérabilité

–

A

pplications multisources…

Architecture des SGBD

•

Les architectures physiques de SGBD sont liées

au

mode de répartition

–

B

D centralisée

–

B

D client/serveur

–B

D

3

-t

ie

rs

–

B

D client/multiserveurs

–

B

D répartie

–

B

D hétérogène

–

B

D mobile

•

E

léments de vocabulaire …

49

Historiquement : architecture centralisée

•

D

es terminaux clients

_–sans intelligence, passifs

•

U

n réseau

•

U

n ordinateur central

_–grande puis

sance (‘mainframe’)

–

M

aintient la base et les applis

Termin aux passifs Mainframe SGBD Appli 1 Appli 2 Appli n réseau donnée s le minit el ☺

Exemple d’instance de cette architecture?

Architecture client serveur

Clients intelligents serveur SGBD Appli 1 Appli 2 Appli n réseau donnée s code Buffon

•

D

es clients intelligents

_–Font tourner les applic

ations

•

U

n réseau

•

U

n serveur

_–M aintient la base

Exemple d’instance de cette architecture?

51

Architecture 3-tiers

Serveur de données SGBD réseau donnée s code Appli Web • D es clients • U n réseau • U n serveur d’application _–E

xécute le code applicatif

• U n serveur de données _–M aintient la base – S

ur la même machine ou des machines _différentes

Exemple d’instance de cette architecture?

Appli 1

Appli 2

Appli n

Serveur

d’application

Architecture Client Multiserveurs

SGBD 2 donnée s code SGBD 1 donnée s code Appli 1 SQL SQL SQL SQL

Réservation d’un voyage

•

D

es clients intelligents

_–Font tourner l’application _–Interagissent avec les serveurs _–C

ombinent les résultats

•

U

n réseau

•

D

es serveurs

_–E

t des bases différentes

ODBC

ODBC

53

Architecture répartie

SGBD 1.1 donnée s code SGBD 1.2 donnée s code Appli 1 Appli 2 Appli n • D es clients intelligents _–F

ont tourner l’application

–

Interagissent avec ‘1 SGBD’ (l’application ne voit

pas que sa requête est

réachemi née) • U n réseau • D es serveurs _–U ne même base – G

èrent chacun une partition Agences d’une société

Exemple d’instance de cette architecture?

Architecture hétérogène

Source 1 : SGBD

donnée

s

code

Source 2 : _{serveur Web}

donnée s code Appli 1 Appli 2 Appli n Médiateur Kelkoo • D

es clients intelligents _–Interagissent avec ‘1 médiateur’

•

U

n médiateur _–Interroge les sources _–N

ettoyage, int égration, etc. • D es sources de données _–D onnées hétérogènes •T

ype, schéma, etc.

–

G

estion des données différente…

Exemple d’instance de cette architecture?

55

Architecture mobile

Clients mobiles serveur SGBD Réseau sans f il donnée s code • D

es clients mobiles intelligents _–P

ortion SGBD répliquée – Interagissent avec SGBD externe – F réquemment déconnectés • U

n réseau sans fil

• U n serveur • U n protocole de synchronisation

Exemple d’instance de cette architecture?

Représentant de commerce

Applications traditionnelles des SGBD

_•

O

LTP

(On Line Transaction Processing)

–

C

ible des SGBD depuis leur existence

–

B

anques, réservation en ligne ...

–

T

rès grand nombre de transactions en parallèle

–

T

ransactions simples

•

O

LAP

(On Line Analytical

Processing)

–

E

ntrepôts de données, DataCube, Data Mining

…

–

F

aible nombre de transactions

–

T

57

•

G

estion de données complexes

_–S

emi-structurées : stockage , indexation, interrogation de documents X ML – N

on-structurées : recherche par le contenu, index

multidimens ionnels, relations spatiales et temporelles

•

S

ystèmes de médiation

_–D e données : intégratio n de schémas, requêtes de

médiation, interrogation large échelle (requêtes continues, personnalisation, critères approximatifs, etc)

–

D

e programmes :

construction de workflows, optimisation

des flux, grilles de calcul

•

E

ntrepôts de données et fouille

_–R

afraîchissement, requêtes mu

lti-dimensionnelles (cubes)

–

R

echerche de règles associatives, de dépendances

fonctionnelles, time series …

Nouvelles problématiques (1)

•

M

obilité

_–BD de loc

a

lisation, BD embarquées, cohérence des

traitements déconnectés, réseaux de capteurs …

•

S

écurité

des bases de données

–

M

odèles de contrôle d’ac

cès

et d’usage, chiffrement

de

bases de données, anonymisation, hardware sécurisé, BD Hippocratiques, Private Information Retrieval …

•

A

rchitecture et performance

_–G

randes mémoires, caches

, nouvelles mémoires

persistantes, nouveaux processeurs …

– S GBD auto-administrables – E

ncore et toujours : indexat

ion, optimisation de requêtes,

réplication, transaction

s, benchmarks, etc …

Nouvelles problématiques (2)

59

Et comment ça marche ?

Architecture fonctionnelle d’un moteur de

SGBD

Gestion de Mémoire Gestion de Verrous Gestion des Journaux

Méthodes d’accès

aux données

Opérateurs relationnels

Evaluateur de plan d’exécution

Optimiseur

Analyseur sémantique

Interf

ace

61

Architecture opérationnelle d’un moteur de SGBD

Mémoire Données Méta-données Jour na ux Données Log Sys Process background Proces s Client Proces s serveur Proces s serveur Proces s serveur Disques Certains slides empruntés à P ascale Borlat Salamet – Oracle France 63 Contiennent les tab les, index … Contiennent les métadonné es, procédures st ockées, tr iggers …

Contiennent les journaux

Organisation des données sur disque

Database _Tablespace Segment Extent Block

Bloc OS

Datafiles

Physique

Logiqu

e

Base de données Récipient logique pour regrouper

des objets applicatifs

liés et administrés ensemble Lieu de stockage d’une structure : Table, index, par

tition de table …

65

Blocs, extents et segments

Instance

O

racle

•

3 types de processus Oracle

–

P

rocessus

clients

(exécutent les programmes d’applic

ation)

–

P

rocessus serveurs

(exécutent les commandes BD)

–

P

rocessus background

(prennent notamment en charge les I/O …)

•

E

space

m

émoire

– S

ystem Global Area (SGA)

: partagée

par tous les processus

–

P

rogram Global Area (PGA) : privée

à

chaque processus du système

•

E

xemple pour les processus serveurs –

P

rivate SQL Area

: Structures runtime liées à

l’exéc des statements SQL

: curseurs, variables de session

–

S

QL Work Area

: mémoire de travail pour l’exécution des requêtes :

zone de tri, Hash-Join, construction d’index bitmap …

–

S

oftware Code Area (SCA)

: zone de code logiciel

•

S

tocke le code Oracle

•U

ne

Instance

O

racle

:

–

1 SGA + les processus

background de cette SGA + leurs PGAs

67

Structure

de la

SGA (1)

•

S

hared

P

ool

: Structures systèmes et méta-données

–

S

tructures système, procédures

PL /SQL, dictionnaire et autre méta données liées à l’exécution de statem

ents SQL (ex: plans d’exécution,

verrous) – P aramétrage : shared_pool_size

•

B

uffer

C

ache

: Stocke les blocs

lus du disque

–

S

ert de tampon pour lire/écrire dans la BD

–

P

eut être décompos

é

en deux zones

•

K

eep Buffer Cache

: pour les blocs accédés très fréquemment

•

R

ecycle Buffer Cache

: pour les blocs pouvant être recyclés rapidement

– P aramétrage •db_cache_size, db_keep_cache_size , db_recycle_cache_size

•

R

edo

log buffer

: Stocke

les enregistrements de journaux

–

C

ontient uniquement les données m

odifiées (et pas tout le bloc)

–

U

tile pour la tolérance aux pannes

– P aramétrage : log_buffer

Structure de la SGA (2)

• E t d’autres encore… – S pecific

block size caches

: s

toc

ke les blocs

de taille particulière

•

Le DBA peut stocker certaines

tables (tablespace) dans des bloc

s

de taille différente des autres

tabl

es _–2Ko, 4Ko, 8Ko, 16Ko,

et 32Ko sont possibles

•

Les blocks de ces tables s

ont stockés dans ce

cache accommodant leur

taille particulière • P aramétrage : db_nk_cac he_size (après Oracle9i) – Large pool : Données de backup et de r

estauration, données liées à

O

ra

cle XA

•

P

aramétrage : large_pool_size (après Oracle8)

–

Java pool

: Stoc

ke des méthodes et des définitions de classes Java

• P aramétrage : java_pool_size –… • V ue

simplifiée des Buffers

69

Fonctionnement du Buffer

Cache

•

Les blocs de la liste ont 3 états possibles

–

free

: bloc libre

–

pinned

: en cours d'utilisation

ne

peut être ré-attribué

–

dirty

: modi

fié

non consistant/disque

•

S

tructures maintenues

_–

U

ne table de Hachage

_•M apping : adresse bloc sur disque entrée du bloc en RAM

–

U

ne Liste

LRU

(mélangeant blocs

free,

pinned, dirty

)

• C

haînage des bloc

s du plus récemme

nt au

moins récemment utilisé

•

N

B: utilisé

=

en consultation (SEL

ECT) ou en modification (UPD

ATE)

–

U

ne Liste

DIRTY

(blocs

dirty

)

• R

eportée sur le disque par le processus DBWR (DataBase

W Riter).

Fonctionnement du Buffer

Cache (2)

• A

lgorithme : Demande de la page Pi du disque _–H

(P

i)

entrée RAM

–

S

i la page est présente •P

age

cible trouvée...

–

S

i la page est absente •P

arcours liste

LRU

par la fin jusqu’à

rencontrer une page free – T oute page dir ty rencontrée es t ajoutée à la liste dir ty

(sans la retirer de la liste

LRU ) – S i le threshold est rencontré » A ppel à BDWR pour repor ter su

r disque des pages de la liste

DIRTY

(f

lush pages

dirty

sur disque, les retire de la liste

DIRTY , les passe à free dans LRU) »

Les pages repor

tées passent de dirty free » replace le curseur de recher

che en fin de liste LRU …

•

Lit la nouvelle page du disque vers la page

free

cib

lée

•

M

odifie la table de hachage (

retir

e la page

free

ciblée, ajoute la page lue)

•

P

age cible trouvée…

–

M

arquer la page cible comme

pinned – R etourne la page • N B : accès concurrents _–D es « latch » (verrous courts)

doivent être posés sur la table de hachage

71

Fonctionnement du Buffer

Cache (3)

P20 P17 P14 P11 P8 P5 P2 P19 P16 P13 P10 P7 P4 P1 P18 P15 P12 P9 P6 P3 P0 P5 P6 P15 P 17 P18 P 14 P3 P4 P2 P0 P9 P16 P 1 P7 P11 P 12 P20 P P8 P10 Liste LRU Liste DIRTY P13 P19 P2 0 Tab le d e Hach ag e Latches P5 P15 P6 P17 P18 P14 P3 P4 P2 P0 P9 P16 P1 P7 P11 P20 P12 P P8 P10 P P P Threshold dirty dirty Pinned (dirty à la base) free Légende Rech erche Flu sh (DBWR) Disque dirty free Lecture de P30 P13 P19 Pinned (free à la b ase)

Fonctionnement du Buffer

Cache (3)

P5 P6 P15 P 17 P18 P 14 P3 P4 P2 P0 P9 P16 P 1 P7 P11 P30 P20 P8 P10 Liste LRU Liste DIRTY P13 P19 P Tab le d e Hach ag e Latches P5 P15 P6 P17 P18 P14 P3 P4 P2 P0 P9 P16 P1 P7 P11 P20 P P8 P10 P P P Threshold dirty dirty Pinned (dirty à la base) free Légende Flu sh (DBWR) Disque dirty Après lecture de P30 P13 Pinned (free à la b ase) P20 P20 P17 P14 P11 P8 P5 P2 P19 P16 P13 P10 P7 P4 P1 P18 P15 P30 P9 P6 P3 P0 P30

73

Fonctionnement du Buffer

Cache (3)

P5 P6 P15 P 17 P18 P 14 P3 P4 P2 P0 P9 P16 P 1 P7 P11 P30 P20 P P8 P10 Liste LRU Liste DIRTY P13 P19 P Tab le d e Hach ag e Latches P5 P15 P6 P17 P18 P14 P3 P4 P2 P0 P9 P16 P1 P7 P11 P20 P P8 P10 P P P Threshold dirty dirty Pinned (dirty à la base) free Légende Flu sh (DBWR) Disque dirty free lecture de P21 P13 P19 Pinned (free à la b ase) P20 P20 P17 P14 P11 P8 P5 P2 P19 P16 P13 P10 P7 P4 P1 P18 P15 P30 P9 P6 P3 P0 P30 Rech erche

Fonctionnement du Buffer

Cache (3)

P5 P6 P15 P 17 P18 P 14 P3 P4 P2 P0 P9 P16 P 1 P7 P11 P30 P20 P8 P10 Liste LRU Liste DIRTY P dirty dirty Pinned (dirty à la base) free Légende Rech erche Flu sh (DBWR) Disque dirty free lecture de P21 P13 Pinned (free à la b ase) P20 P11 P10 P13, P19 P21 Tab le d e Hach ag e Latches P5 P15 P6 P17 P18 P14 P3 P4 P2 P0 P9 P16 P1 P7 P11 P20 P P8 P10 P P P P20 P17 P14 P11 P8 P5 P2 P21 P16 P13 P10 P7 P4 P1 P18 P15 P30 P9 P6 P3 P0 P30 Threshold P21 P P 75

Les Processus Background (1)

•

U

ne instance est partagée par plusieurs utilisateurs

il faut centraliser les tâches

(évite les problèmes de

concurrence) et les factoris

er pour ne pas gaspiller de

ressources

•

A

u démarrage de l’instance

_–

P

MON, SMON, DBWR, LGRW, CKPT, ARCH, RECO

_–

E

t d’autres processus liés aux calculs de statistiques,

déclenchement d’alertes, etc

Pour optimiser les performances. Un système performant doit utiliser les ressources au maximum en

évitant

les pics (goulots d’étranglement)…

Mais pourquoi en BACKGROUND ?

Les Processus Background (2)

–

D

BWR (DataBase

W

riter)

• R eporte les b locs modifiés ( dirty ) sur le dis

que et les libère dans le

cache –

son but est de conserver le cache propre

– D ans l’ordre indiqué par la ‘liste DIRTY ’( voir slides précédents)

–

LGRW (LoG Writer)

• R

esponsable de l’écriture du Redo

Buffer

sur le disque

–

E

n fait, écriture sur des disques mirroir

•

Il s’exécute –

à

chaque COMMIT (Force-Log at Commit)

–

toutes les 3 secondes

–

quand le buffer est

rempli au premier tiers

–

À

chaque intervention du DBWR

77

C’est quoi?

• C KPT (ChecKPoinT) _–G estion des checkpoint – E

nregistre toute les 3 secondes dans le Control File un marqueur

indiquant

quelle portion du Redo Log est déjà

reportée sur disque

•

A

RCH (ARCHiver) _–E

ffectue l’archivage du fichier REDO LOG

•

P

MON (Processus MONitor) _–N

ettoie les connexions terminées de façon anormale

–

D

éfait les transactions après une ‘transaction failure’

•

S

MON (System MONitor) _–A

ssure la reprise d’une instance après une ‘system failure’

• R ECO (RECOverer ) – T

ermine les transactions stoppées dans

une phase de validation atomique suite

à

une panne (in-doubt transactions)

–

P

résent uniquement dans une configuration distribuée

Les Processus Background (3)

Processus serveur dédiés ou partagés

Serveurs dédiés

Serveurs partagés

79

Bibliographie

•

Le Noyau Oracle

–

O

racle8, Cours ENST de Pascale Borlat

Salamet, Oracle France

http://www.infres.enst.fr /people/ saglio/bdas/00/orapbs/index.htm – O racle9 et Oracle 10, Database Concepts www.lc.leidenuniv.nl/awcourse/o ra cle/server.920/a96524/toc.htm http://www-smis.inria.fr /~ancia ux/Oracle10_Database_Concepts.pdf – R appor ts Techniques divers • T riviadis : http://www.trivadis.com • D bspecialists : http://w ww.dbspecialists.com/presentations/

•

Livres Bases de Données

–

D

atabase Management Systems

Livre de R. Ramakrishnan et J. Gehrke – B ases de Données

Livre de G. Gardarin, Editions

Eyrolles, 2003

http://g