Bases de Données Avancées

(1)

Thierry Hamon

Bureau H202 - Institut Galilée Tél. : 33 1.48.38.35.53 Bureau 150 – LIM&BIO – EA 3969 Université Paris 13 - UFR Léonard de Vinci 74, rue Marcel Cachin, F-93017 Bobigny cedex Tél. : 33 1.48.38.73.07, Fax. : 33 1.48.38.73.55

[email protected]

http://www-limbio.smbh.univ-paris13.fr/membres/hamon/BDA- 20112012

INFO2 – BDA

(2)

Quand d´ecide-t’on d’optimiser ? Optimiser quoi ?

Qui participe, et Comment ?

Type de l’application (TP ou Batch) Int´erˆet de l’application pour l’entreprise

(3)

Application Batch

L’application n’est pas disponible `a partir d’une certaine heure Application transactionnelle

L’utilisateur constate que le temps de r´eponse est inacceptable (Agence de voyage, application interne, etc.)

(4)

Adminstrateurs de DB, Développeurs, Ingénieurs Système (IS), Chef de projet

Définition de la puissance de la machine (Nombre de processeurs, Capacité mémoire, Espace disque nécessaire en fonction du type de l’application)

Type du SGBD (Oracle, DB2, etc.) Type de l’application (Batch, TP)

Langage de programmation utilis´e (Java, PL/SQL, etc.)

(5)

(ABD ou DataBase Administrator DBA)

Double rôle de l’administrateur d’une Base de Données : rôle organisationnel

Définition du schéma conceptuel des données Partage de ces données par les utilisateurs rôle technique

Mise en œuvre ce sch´ema

partage `a l’aide des capacit´es techniques du SGBD

(6)

rˆole technique

Installation du SGBD et des outils associ´es

Création de la BD et ses composants conformément à un schéma conceptuel

Surveillance de son ´evolution en modifiant, en cr´eant ou en supprimant certaines structures

Gestion des privil`eges d’acc`es

Attribution et retrait de privilèges d’accès aux données aux différents utilisateurs de la base de données

(7)

rˆole technique

Am´elioration les performances

Choix de l’implantation optimale des donn´ees de fa¸con `a obtenir les meilleures performances

Identification et prise en compte des utilisations qui seront faites des donn´ees

Surveillance de la sécurité et la cohérence des données Mise en place de structures et de procédures permettant

de faire face `a tous les incidents

de retrouver l’intégrité et la cohérence des données

(8)

rˆole technique

Echange les donn´´ ees entre la BD et le monde extérieur Surveillance de l’intégration des données en provenance d’autres applications ou BD

Migration des donn´ees de la base vers d’autres applications ou BD

Outils `a utiliser : SQL*DBA, SQL*Loader, SQLPLUS, etc.

(9)

Les besoins en puissance machine d´efinis

Les acteurs administrateurs BD, (IS), développeurs, etc. au courant du projet (impliqués, responsable de la réussite du projet,..)

Optimisation de la base et de l’application ?

(10)

Partie N^◦1 : Conception des syst`emes d’informations et optimisation des applications

Lors de la conception des syst`emes d’informations (si pas trop tard)

Optimisation des applications

Partie N^◦2 : Pr´esentation des outils pour assurer le suivi de la base et garantir sa performance

Optimisation de la m´emoire

Optimisation des entr´ees/Sorties Disque

Identifier les contentions dans la base de donn´ees

(11)

Lors de la conception des syst`emes d’informations : (Si pas trop tard)

Système non performant : résultat d’une mauvaise définition du modèle conceptuel

Mod`ele conceptuel : au moins sous la 3`eme forme Normale (3NF)

Sauf dans quelque cas (choix volontaire) o`u la

d´e-normalisation apporte une certaine performance au syst`eme d’information (Dataware house)

Lors de la conception : tenir compte l’accès aux données Analyse de la répartition des données :

réplication de données (sur une ou plusieurs bases, etc.) agrégation des tables, pour les systèmes décisionnels

(12)

Optimisation des applications :

l’expérience montre que 80% des problèmes de performances des applications, sont résolus, par une optimisation des requêtes SQL

Ordonnancer les Batchs et ´eviter leur ex´ecution pendant des heures ou l’utilisation des machine est intense

Dispatcher les Batchs les plus consommateurs en puissance machine `a des heures diff´erentes

(13)

Optimisation de la m´emoire :

d´eterminer la bonne taille des buffers de la base

(shared_pool, buffer cache, log buffer, etc) par l’utilisation des outils tels que Utlbstat/Utlestat, ou Statpack, etc.

(14)

Optimisation des entr´ees/Sorties Disque :

Bien dimensionner les fichiers de la base de donn´ees et placer dans des disques pr´evus pour le type d’application (Batch ou TP),

pour assurer un temps de réponse acceptable des requêtes adressées à la Base.

Ne pas oublier de recenser les disques les plus sollicit´es, les tablespaces les plus fragment´es, full table scan, etc.

(15)

Identifier les contentions dans la base de donn´ees :

Etudier les locks, les latches et les wait events au niveaux de la base de donn´ees, et les ´eliminer si possible

(16)

Lors de la conception des syst`emes d’informations Optimisation des applications :

L’expérience montre que l’optimisation des requêtes SQL résout la majorité des problèmes de performances des applications

(17)

Clarifier et situer les différents paramètres internes des SGBD (relationnel ; objet-relationnel) afin d’améliorer leurs

performances.

R´e´ecrire les codes SQL ; PL/SQL etc..

Restructurer les données, indexer les données, créer des vues matérialisées

Partager les données, dupliquer les données sur plusieurs disques, créer des partitions sur les données

(18)

Intervenants :

Administrateurs de Bases de Donn´ees (ABD = DBA) Programmeurs d’Applications sur SGBD

Objectifs :

Optimiser un système existant et connaˆıtre les impacts de certains paramètres en fonction du type d’application sur le système

Choisir un SGBD en ayant comme contrainte les crit`eres de performances

(19)

Pour augmenter les performances trois grandes solutions apparaissent :

1 Premi`ere solution (d’ordre logique) : optimiser les sch´emas conceptuel et logique pour qu’il colleaux applications

2 Deuxi`eme solution (d’ordre physique) : optimiser les param`etres internes du SGBD

3 Autre solution (de type matérielle) : augmenter la puissance machine ou utiliser des ordinateurs spéciaux dédiés à la gestion des données.

Cette approche est plus connue sous le nom Machine Bases de Donn´ees

(20)

Optimisation du Sch´ema Relationnel

Schéma Conceptuel de Données (SCD), obtenu à la phase d’analyse

une ensemble d’Entit´es et d’Associations ou un ensemble de Classes selon le formalisme utilis´e

En EA, transformation en schéma relationnel (Schéma Logique de Données – SLD), qui permet

Implantation du SCD dans une BD relationnelle

(21)

Optimisation du Sch´ema Relationnel

Normalisation : processus permettant de s’assurer de la Bonne conceptiondu SLD

non redondance de ses donn´ees

Cadre formel pour effectuer la normalisation : lad´ependance fonctionnelle

les formes normales(1^`êre FN, 2^`ême FN, 3^`ême FN, FNBC, 4^`ême FN, ...)

(22)

Exemple

Avant normalisation :

R e l a t i o n 1 ( A t t r i b u t 1 , A t t r i b u t 2 , . . . )

D´ecomposition de la relation Relation1, en deux ou plusieurs relations qui contiennent moins d’anomalies de mises `a jour (peu ou pas du tout) :

On parle de

D´ecomposition sans perte d’information

D´ecomposition sans perte de d´ependance fonctionnelle (DF) ...

Apr`es normalisation :

R e l a t i o n 1 1 ( A t t r i b u t 1 1 , A t t r i b u t 1 2 , . . . )

(23)

Les relations obtenues doivent ˆetre en 3^`^eme Forme Normale, au moins

→bon rapport redondance/espace occup´e Cl´e Primaire

Pas de DF entre les attributs de la clé primaire ; Pas de DF entre un sous ensemble d’attributs de la clé primaire et les attributs qui n’appartiennent pas à la clé primaire

Pas de DF entre les attributs qui n’appartiennent pas `a la cl´e primaire

(24)

Illustration

Format d’une relation bien con¸cue

(25)

Exemple

Soit la relation :

ADRESSES ( V i l l e , Num´ero , Rue , C o d e P o s t a l ) D´ecomposition de la relation

ADRESSES ( r e l a t i o n en 3`eme FN)

en deux relations CPR et CPV (en FN de Boyce et Codd) : CPR ( C o d e P o s t a l , Rue )

CPV ( C o d e P o s t a l , V i l l e )

(26)

Exemple

ADRESSES

VILLE NUMERO RUE CODE POSTAL

Paris 6 Rue de la Rosi`ere 75015

Paris 16 Rue de la Rosi`ere 75015

Paris 51 Rue des Entrepreneurs 75015

Paris 55 Rue des Entrepreneurs 75015

Paris 8 Avenue des Champs Elys´ees 75008 Epinay sur Seine 23 Boulevard Foch 93800

CPR CPV

CODE POSTAL RUE CODE POSTAL VILLE

75015 Rue de la Rosi`ere 75008 Paris

75015 Rue des Entrepreneurs 75015 Paris

75008 Avenue des Champs Elys´ees 93800 Epinay sur Seine 93800 Boulevard Foch

(27)

Exemple

Un client a une adresse : SLD version 1

CLIENT ( C o d e C l i , NomCli , P r´e n o m C l i , Num´ero , Rue , C o d e P o s t a l , V i l l e ) SELECT ∗ FROM CLIENT ;

SLD version 2

CLIENT ( C o d e C l i , NomCli , P r´e n o m C l i , Num´ero , A d r C l i∗ )

ADRCPR ( A d r C l i , Rue , C o d e P o s t a l∗) ADRCPV ( C o d e P o s t a l , V i l l e )

SELECT ∗ FROM CLIENT , ADRCPR, ADRCPV WHERE CLIENT . A d r C l i=ADRCPR . A d r C l i

(28)

Un sch´ema relationnel normalis´e

contiendra donc un nombre plus important de relations (de tables)

pourra ainsi pénaliser certaines requêtes, qui seront obligées de procéder à des jointures plus nombreuses sur la base Or

La jointure est une opération très coûteuse

Les op´erations binaires (qui portent sur deux tables) peuvent ˆ

etre coˆuteuses

(29)

Redondance calcul´ee

Technique d’optimisation des requˆetes d’interrogation Introduction volontairement de redondances dans le sch´ema logique relationnel

Cette redondance est ditecalculée car elle tient compte des besoins des modules de traitement des données de leurs exigences en terme de temps de réponse

(30)

Redondance calcul´ee

Deux méthodes de réalisation de la redondance calculée : le stockages des données déductibles

la d´e-normalisation

(31)

Redondance calculée : stockages des données déductibles

Donn´ees d´eductibles

les résultats des requêtes les plus fréquentes des statistiques historiques

des donn´ees issues de calculs complexes

(32)

Redondance calculée : stockages des données déductibles

Dans les trois cas, stockage des donn´ees, physiquement dans la base

(sous la forme de Tables/Vues ou de Colonnes)

Avantage du stockage physique : éviter leur re-génération en cas de besoin

Inconv´enient de la redondance :

1 Place occup´ee par les donn´ees redondante

2 Nécessité de traitements supplémentaires pour les opérations de mises à jour

3 Risque d’incoh´erence

(33)

Redondance calculée : stockages des données déductibles Exemple de requête fréquente

Base de donnéesSportAct: Adhérents à des centres sportifs CENTRE ( NumC, NomC, V i l l e C , C o u t i n s c )

ESTMEMBRE ( NumA, NumC∗, D a t e i n s c )

Requˆete fr´equente : Nombre d’inscrits dans un centre c ? SELECT C . NumC, C . NomC, COUNT( E . NumA)

FROM CENTRE C , ESTMEMBRE E

WHERE C . NumC = E . NumC AND C . NumC= c GROUP BY C . NumC ;

(34)

Cr´eation d’une nouvelle colonne NbrInscrdans la table CENTRE:

CENTRE ( NumC, NomC, V i l C , C o u t i n s c , N b r I n s c r ) Nouvel ordre SQL :

SELECT NumC, NomC, N b r I n s c r FROM CENTRE WHERE NumC=c ;

→ Suppression de 2 opérations très coûteuses : Une jointure en moins

Un groupement en moins

(35)

Impact sur le reste de la base de donn´ees

Prise en compte de cette nouveauté par les opérations de mises à jours de la table ESTMEMBRE

Modification de la colonne NbrInscr`a chaque insertion ou suppression d’inscription

→La coh´erence est affect´ee si on ne le fait pas

(36)

Chaque op´erationINSERT / DELETE implique une op´eration UPDATE

INSERT INTOESTMEMBREVALUES(....) ; doit ˆetre accompagn´ee par

UPDATE CENTRE SET N b r I n s c r=N b r I n s c r +1 ; DELETE FROM ESTMEMBREWHERE... ;doit ˆetre accompagn´ee par

UPDATE CENTRE SET N b r I n s c r=N b r I n s c r−1 ;

(37)

Redondance calculée : stockages des données déductibles Exemple de Statistiques Historiques

Requˆete : Nombre d’inscrits par centre et par mois ?

Objectif : ´eviter le recalcul `a chaque fois du nombre d’inscrits par centre et par mois

Solution : cr´eation d’une nouvelle table/vue STAT_MENS_INSCR

STAT MENS INSCR ( NumC, Mois , N b r I n s c r )

Nécessité d’un nouveau traitement mensuel pour l’actualiser avec les statistiques du mois écoulé

(38)

Redondance calculée : stockages des données déductibles Résultat de calcul complexe

Soit la base de donn´ees :

CLIENT ( C o d e C l i , NomCli , . . . )

ARTICLE ( CodeArt , L i b A r t , . . . , P r i x A r t ) COMMANDE ( NumCom, C o d e C l i∗, DateCom ) DETAILCOM ( NumCom∗, C o d e A r t∗, QtéComDée ) Requête : Montant de la commande ?

(39)

Redondance calculée : stockages des données déductibles Résultat de calcul complexe

Obtention du montant de la commande :

SELECT C . NumCom, SUM(D . Qt´eComD´ee∗A . P r i x A r t ) AS Montant FROMCOMMANDE C , ARTICLE A , DETAILCOM D

WHERE C . NumCom=D . NumCom AND D . C o d e A r t=A . C o d e A r t GROUP BY C . NumCom ;

Gain d’op´eration avec la cr´eation de la colonne Montant dans la tableCOMMANDE

COMMANDE ( NumCom, C o d e C l i , DateCom , Montant ) SELECT NumCom, Montant

FROM COMMANDE ;

(40)

Redondance calcul´ee : d´e-normalisation

Autre m´ethode d’optimisation des interrogations

Transformer, si besoin est, une table de la 3ème FN en 2ème FN ou en la 1ère FN

Objectif : éviter des jointures successives pouvant être coûteuses en performances

(41)

Redondance calcul´ee : d´e-normalisation Exemple

Soit la table

ARTICLE ( CodeArt , L i b A r t , . . . , P r i x A r t ) COMMANDE ( NumCom, C o d e C l i∗, DateCom )

DETAILCOM ( NumCom, C o d e A r t∗, QtéComDée , P r i x A r t ) DETAILCOM passe de la 3ème FN à la 1ère FN

Requˆete : Montant de la commande ?

SELECT NumCom, SUM( Qt´eComD´ee∗P r i x A r t ) AS Montant FROM DETAILCOM

GROUP BY NumCom ;

(42)

Redondance calcul´ee : d´e-normalisation

Inconvénients de la dé-normalisation : identiques à ceux du stockage des données déductibles

Place suppl´ementaire

P´enalisation des traitements d’insertion et de suppression Risque d’incoh´erence

Nécessite la création de déclencheurs (triggers)

(43)

Optimisation des ordres SQL

Requête SQL : ordre passé au SGBD pour lui demander de rechercher des données spécifiées dans la requête

(sans expliciter le comment) SQL est non proc´edural

SELECT / FROM / WHERE / GROUP BY / HAVING / ORDER BY

DISTINCT SUM / MIN / MAX / AVG / COUNT

IN / NOT IN / LIKE / NOT LIKE / EXISTS / NOT EXISTS / = ANY / > ALL INSERT / DELETE / UPDATE

CREATE / TABLE / VIEW / INDEX

(44)

Traduction d’une requˆete exprim´ee en langage naturel en un ensemble d’ordres SQL

Plusieurs agencements sont souvent possibles :

au niveau de l’ordre dans lequel les conditions sont exprim´ees dans la clauseWHERE :

WHERE c o n d i t i o n 1 AND c o n d i t i o n 2 WHERE c o n d i t i o n 2 AND c o n d i t i o n 1

(45)

Traduction d’une requˆete exprim´ee en langage naturel en un ensemble d’ordres SQL

Plusieurs agencements sont souvent possibles : au niveau des op´erations alg´ebriques

Possibilité d’utiliser plusieurs méthodes différentes pour exprimer la même chose

La jointure : possibilité d’exprimer la opération de plusieurs fa¸cons différentes

R = Jointure ( R1, R2, {R1.A=R2.A} )

= Jointure ( R2, R1, {R2.A=R1.A} )

SELECT ∗ FROM R1 , R2 WHERE R1 . A = R2 . A ; SELECT ∗ FROM R2 , R1 WHERE R2 . A = R1 . A ;

(46)

Optimisation des ordres SQL Expression de la jointure

M´ethode pr´edicative

SELECT ∗ FROM R1 , R2 WHERE R1 . A=R2 . A ; M´ethodes ensemblistes

SELECT ∗ FROM R1 WHERE A IN (SELECT A FROM R2 ) ; SELECT ∗ FROM R1 WHERE A =ANY (SELECT A FROM R2 ) ; SELECT ∗ FROM R1 WHERE EXISTS

(SELECT ∗ FROM R2 WHERE R1 . A=R2 . A ) ; SELECT ∗ FROM R1 WHERE 0 <

(47)

Optimisation des ordres SQL Exemple de dur´ee d’ex´ecution – SQLPlus SETTIMINGON

Ex´ecution de la requˆete ; SELECT...FROM ...

→ Oracle vous donne le temps écoulé Méthode prédicative :

s e l e c t ∗ from a l l t a b l e s t1 , a l l c o n s t r a i n t s t 2 where t 1 . t a b l e n a m e = t 2 . t a b l e n a m e ; temps CPU : 1 091 480 u n i t é s 451 100 u n i t é s s e l e c t ∗ from a l l c o n s t r a i n t s t1 , a l l t a b l e s t 2 where t 1 . t a b l e n a m e = t 2 . t a b l e n a m e ; temps CPU : 976 790 u n i t é s 690 690 u n i t é s

(48)

Optimisation des ordres SQL Exemple de dur´ee d’ex´ecution – SQLPlus

M´ethodes ensemblistes :

s e l e c t ∗ from a l l c o n s t r a i n t s where t a b l e n a m e i n (s e l e c t t a b l e n a m e from a l l t a b l e s ) ; temps CPU : 138 350 u n i t ´e s 139 230 u n i t ´e s s e l e c t ∗ from a l l c o n s t r a i n t s where t a b l e n a m e

= any (s e l e c t t a b l e n a m e from a l l t a b l e s ) ; temps CPU : 139 630 u n i t ´e s 139 890 u n i t ´e s s e l e c t ∗ from a l l c o n s t r a i n t s t 1 where e x i s t s

(s e l e c t ∗ from a l l t a b l e s t 2 where t 1 . t a b l e n a m e = t 2 . t a b l e n a m e ) ;

(49)

Traduction d’une requˆete exprim´ee en langage naturel en un ensemble d’ordres SQL :

Plusieurs agencements sont souvent possibles

Possibilité d’utiliser plusieurs méthodes différentes pour exprimer la même chose

La diff´erence :

R = Diff´erence ( R1, R2 )

SELECT ∗ FROM R1 MINUS SELECT ∗ FROM R2 ;

(50)

Optimisation des ordres SQL Expression de la diff´erence

SELECT A FROM R1 MINUS SELECT A FROM R2 ;

SELECT A FROM R1 WHERE A NOT IN (SELECT A FROM R2 ) ; SELECT A FROM R1 WHERE NOT EXISTS

(SELECT A FROM R2 WHERE R1 . A=R2 . A ) ; SELECT A FROM R1 WHERE 0 =

(SELECT COUNT(∗) FROM R2 WHERE R1 . A=R2 . A ) ;

(51)

Optimisation des ordres SQL Utilisation des vues

Mauvais code :

S e l e c t e .∗ from EMP e where e . s a l a r y > (

s e l e c t avg( s a l a r y ) from EMP i

where i . d e p i d = e . d e p i d ) ;

Bon code

S e l e c t e .∗ from EMP e ,

(S e l e c t i . d e p i d DEP , avg( i . s a l a r y ) SAL from EMP i group by i . d e p i d ) EMP VUE where e . d e p i d = EMP VUE . d e p i d and

e . s a l a r y > EMP VUE . SAL ;

(52)

Optimisation des ordres SQL Vues mat´erialis´ees

Présentation des vues matérialisées :

Cr´eation d’une vue physique d’une table Duplication des donn´ees

Définition de vues matérialisées à partir de tables, de vues, et de vues matérialisées

Possibilité de décalage entre la table maˆıtre et la vue matérialisée : gestion de la fraicheur des données de la vue matérialisée (refresh)

(53)

Optimisation des ordres SQL Vues mat´erialis´ees

Utilisation des vues mat´erialis´ees :

Optimisation/amélioration des performances Ré-écriture de les requêtes portant sur des tables

selectparticuli`erement complexe ou lourd r´eplication de table

(54)

Optimisation des ordres SQL Exemple d’utilisation de vues mat´erialis´ees

Soit le sch´ema logique de donn´ees suivant :

(55)

Soit la requˆete Q :

Total des ventes des magasins en France ou en Belgique -pour la période de 2001 à 2003- par ville et année

s e l e c t ADRVILLEMAG , ANNEET, sum(MONTANTVENTE) a s Montant from VENTES , MAGASINS , TEMPS

where VENTES .NUMMAG=MAGASINS .NUMMAG and VENTES . IDTEMPS=TEMPS . IDTEMPS and

(upper( MAGASINS . ADRPAYSMAG)= ’FRANCE ’ o r upper( MAGASINS . ADRPAYSMAG)= ’ BELGIQUE ’ ) and TEMPS . ANNEET between 2001 and 2003

group by ADRVILLEMAG , ANNEET ;

(56)

V1 : Total des ventes des magasins `a partir de 2002, par ville et ann´ee

c r e a t e m a t e r i a l i z e d v i e w v1 ( V i l l e , Annee , Montant1 ) a s (s e l e c t ADRVILLEMAG , ANNEET, sum(MONTANTVENTE)

from VENTES , MAGASINS , TEMPS

where VENTES .NUMMAG=MAGASINS .NUMMAG and VENTES . IDTEMPS=TEMPS . IDTEMPS and TEMPS . ANNEET>= 2002

g r o u p by ADRVILLEMAG , ANNEET ) ;

(57)

V2 : Total des ventes des magasins en France par ville, ann´ee et mois

c r e a t e m a t e r i a l i z e d v i e w v2 ( V i l l e , Annee , Mois , Montant2 ) a s (s e l e c t ADRVILLEMAG , ANNEET, MOIST , sum(MONTANTVENTE)

u p p e r( MAGASINS . ADRPAYSMAG)= ’FRANCE ’ g r o u p by ADRVILLEMAG , ANNEET, MOIST ) ;

(58)

V3 : Total des ventes des magasins en Belgique – avant 2001 – par ville, ann´ee et mois

c r e a t e m a t e r i a l i z e d v i e w v3 ( V i l l e , Annee , Mois , Montant3 ) a s (s e l e c t ADRVILLEMAG , ANNEET, MOIST , sum(MONTANTVENTE)

u p p e r( MAGASINS . ADRPAYSMAG)= ’ BELGIQUE ’ and TEMPS . ANNEET<= 2001

g r o u p by ADRVILLEMAG , ANNEET, MOIST ) ;

(59)

Soit la requête Q’ qui utilise des vues matérialisées :

s e l e c t ADRVILLEMAG , a n n e e , Montant1 from v1 , (s e l e c t d i s t i n c t ADRVILLEMAG

from MAGASINS

where u p p e r( MAGASINS . ADRPAYSMAG)= ’FRANCE ’ o r u p p e r( MAGASINS . ADRPAYSMAG)= ’ BELGIQUE ’ ) s 1 where v1 . v i l l e = s 1 . ADRVILLEMAG and a n n e e <= 2003

u n i o n

s e l e c t v i l l e , a n n e e , sum( Montant2 ) from v2 where a n n e e =2001 g r o u p by v i l l e , a n n e e u n i o n

s e l e c t s 2 . ADRVILLEMAG , Annee , sum( Montant3 )

from v3 , (s e l e c t d i s t i n c t ADRVILLEMAG from MAGASINS ) s 2 where v3 . v i l l e = s 2 . ADRVILLEMAG and a n n e e = 2001

(60)

Optimisation des ordres SQL Utilisation de vues mat´erialis´ees

Inconv´enients :

Résultat de la requête stocké et valable à un instant t en fonction des paramètres, la vue matérialisée sera tenue à jour ou non quand la table change

Entretien des vues en temps r´eel : coˆuteux (et peu souvent mis en œuvre)

(61)

Optimisation des ordres SQL Utilisation de vues mat´erialis´ees

Avantages

Simple réécriture de requête et exécution de requêtes imbriquées

Lorsqu’il n’est nécessaire de disposer des données en temps réel, économie d’interrogation

Exemple : analyse de chiffres économiques de la veille données figées

intérêt à stocker des résultats (qui ne changeront pas !) Utilisation dans les datawarehouse : problématique de performances

(62)

Adaptation et enrichissement du SLD pour tenir compte des sp´ecificit´es du SGBD

des performances des traitements et de la sécurité A ce stade d’élaboration du schéma physique de données, on dispose :

du SLD normalis´e ou non

du schéma physique de traitement (description détaillée des modules)

(63)

Résultat : Schéma Physique des Données (SPD)

représentation de la structure définitive de la base de données telle qu’elle doit être implantée

prise en compte

des caract´eristiques technique du SGBD et du mat´eriel des exigences en interfaces et en performances des modules de programmation

Si le mat´eriel ou le SGBD change alors il faut changer le SPD (les exigences changent)

(64)

Etat des lieux : des tables en 3`eme FN, ou autre etc. bien con¸cues

Objectifs :

optimisation des acc`es en choisissant les colonnes qui doivent ˆ

etre index´ees

introduction (éventuellement) de redondances calculées définition de vues standards et des vues matérialisées définition des contraintes d’intégrité et des déclencheurs sur les tables

(65)

création des tables et des colonnestechniques définition des droits d’accès aux données

répartition des tables sur les sites (en cas de BD réparties) calcul des paramètres de stockage des tables et des index etc.

(66)

Colonnes `a indexer

les clés primaires (concaténées ou pas) pour garantir l’unicité et accélérer les recherches

INDEX UNIQUE

les clés étrangères (concaténées ou pas) pour accélérer les jointures

INDEX NOT UNIQUE

les colonnes servant de crit`eres de recherche (apparaissent souvent dans la clause WHERE de SQL)

INDEX NOT UNIQUE

(67)

Colonnes `a indexer

Remarque :

Un vraiSGBD se caract´erise par l’emploi d’un SEUL fichier pour y stocker la BD

(ou ´eventuellement quelques fichiers si la BD est trop importante)

Un fauxSGBD Relationnel emploie un fichier pour y stocker une table

dans ce cas la gestion physique des données est assurée par le système d’exploitation, interdisant tout paramètre

d’optimisation

(68)

Méthodes d’accès : Méthode séquentielle

Méthodes basées sur les index : Index hiérarchisé,

Arbre-B (B-tree), Arbre-B+, Arbre-B+*, ...

M´ethode de hachage Mise en cluster

(69)

Données (110 octets) Index (14 octets) Clé primaire Info. compl. Clé primaire Adresse physique

(10 octets) (100 octets) (10 octets) (4 octets)

10 info1 10 @1

15 info2 10 @2

20 info3 10 @3

30 info4 10 @4

40 info5 10 @5

50 50

55 55

77 77

80 80

10 10

150 150

250 info k 250 @k

1610 info n 1610 @n

(70)

(10 octets) (100 octets) (10 octets) (4 octets)

10 info1 30 @Bloc1

15 info2 77 @Bloc2

20 info3 150 @Bloc3

30 info4 1610 @Bloc4

40 info5

50 info6

55 info7

77 info8

80 info9

10 info10

150 info11

250 info k

(71)

Exemple

Table (110 octets par enregistrement) : Clé primaire (10 octets), Informations complémentaires (100 octets) Index (14 octets par enregistrement) : Clé primaire (10 octets), Adresse Physique (4 octets)

Bloc de 512 octets

Nombre d’enregistrements de l’ordre de 100 000

(72)

Exemple

Pour les donn´ees :

Pour un nombre entier d’enregistrements par bloc (512/110) Nombre maximal d’enregistrements par bloc est 4

Il faudrait donc (100 000/4) = 25000 blocs de donn´ees Pour les index :

Pour un nombre entier d’enregistrements par bloc (512/14) Nombre maximal d’enregistrements par bloc est 36

Il faudrait donc (100 000/36) = 2778 blocs d’index

(73)

Exemple

(74)

Diff´erents types d’index : Logique

Index simple (sur une colonne)

Index concat´en´e (sur plusieurs colonne)

Index unique (colonne ne comportant pas de doublon) Index non unique (colonne comportant des doublons) Physique

B-tree Bitmap Hash

(75)

Exemples

Index simple

c r e a t e i n d e x i d x n o f o u r on t t f o u r ( n o f o u r ) Index concat´en´e

c r e a t e i n d e x idx commande on ( n o f o u r , n c l i e n t )

(76)

Exemples

index unique

c r e a t e unique i n d e x i d x u n i q u e

on t a b ( c o l 1 ) t a b l e s p a c e t b s t a b 1 p c t f r e e 40

p c t u s e d 60 i n i t r a n s 10 m a x t r a n s 100 index non unique

c r e a t e unique i n d e x i d x u n i q u e

on t a b ( c o l 1 ) t a b l e s p a c e t b s t a b 1 p c t f r e e 40

p c t u s e d 60

(77)

manipulations

Modification d’un Index

A l t e r I n d e x schema . n a m e i n d e x i n i t r a n s i n t e g e r m a x t r a n s i n t e g e r

s t o r a g e ( i n i t i a l 100M next 20M) l o g g i n g|n o l o g g i n g

Reconstruction d’un Index A l t e r I n d e x p1 . IDX FOUR

R e b u i l d T a b l e s p a c e TBS INDEXES

(78)

Manipulation

Modification d’un Index

A l t e r I n d e x schema . n a m e i n d e x i n i t r a n s i n t e g e r m a x t r a n s i n t e g e r

s t o r a g e ( i n i t i a l 100M next 20M) l o g g i n g|n o l o g g i n g

Catalogue Oracle pour la gestion des Index et des Clusters S e l e c t ∗ from s y s . d b a u s e r s ;

S e l e c t ∗ from s y s . d b a i n d e x c o l u m n s ; S e l e c t ∗ from s y s . d b a c l u s t e r s ;

(79)

Cr´eation d’un index Bitmap (pour faible cardinalit´e) c r e a t e b i t m a p i n d e x on t t f o u r

( d t l i v r a i s o n )

t a b l e s p a c e T B S F o u r n i s s e u r ;

(80)

Cr´eation du cluster

Create c l u s t e r c l i e n t h a s h ( N u m c l i number ( 9 ) s i z e 512 HASHKEY 500

s t o r a g e ( i n i t i a l 2M next 1M) Mise en cluster d’une table

Create t a b l e C l i e n t ( N c l i number,

nom v a r c h a r 2( 5 0 ) ) C l u s t e r c l i e n t h a s h ( N c l i ) ; Cr´eation de l’index sur le cluster

(81)

Pr´eparation de l’utilisation de B-Tree

(`a utiliser dans le cas d’une forte cardinalit´e)

SQL>DESC t 1 0 m a n c o p y

NAME NULL? TYPE

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− −−−−−−−− −−−−−−−−−−−−−

EMPNO NOT NULL NUMBER

ENAME VARCHAR2( 2 0 )

JOB VARCHAR2( 1 8 )

MGR NUMBER( 4 )

HIREDATE DATE

SAL NUMBER( 7 , 2 )

COMM NUMBER( 7 , 2 )

DEPTNO NUMBER( 2 )

EMPNO r a n g e s from 1 t o 1 0 0 0 0 0 . I u s e t h i s t a b l e t o c r e a t e MGR row w i t h c a r d i n a l i t y 4 . I u s e MOD f u n c t i o n .

MOD (m, n ) f u n c t i o n r e t u r n s a r e m a i n i n g o f m d i v i d e d by n . I a l s o u s e t o c h a r t o make column l e n g t h e v e n .

∗∗∗∗∗∗∗∗∗∗ SQL t o make d a t a i n MGR row be c a r d i n a l i t y 4 ∗∗∗∗∗∗∗∗∗∗∗

SQL>CREATE TABLET10MAN COPY 4 AS

(82)

Cr´eation d’un index B-Tree

SQL>SELECTMGRFROMT10MAN COPY 4WHEREROWNUM<10 ; MGR

−−−−−−−−

0 0 0 0 0 0 1 0 0 0 0 0 0 2 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 2 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 1

∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗

SQL>CREATE INDEX BTREE 4ONT10MAN COPY 4 (MGR)

STORAGE ( I N I T I A L 2KNEXT2K PCTINCREASE 0 MAXEXTENTS UNLIMITED ) ;

(83)

Exemples d’optimisation Algorithmique

Algorithme des boucles imbriqu´ees de la jointure BI-passe Algorithme Multi-Passes de la jointure MP

(84)

Hashage de deux tables en paquets de m´emoire virtuelle

D´ebut A l g o r i t h m e BI : POUR i DE 1 `a n1 FAIRE DEBUT

LIRE Page de R1

POUR j de 1 `a n2 FAIRE DEBUT

LIRE Page de R2

S I R1 . A=R2 . A ALORS C r ´e e r r ´e s u l t a t F I N S I FIN

FIN

F i n A l g o r i t h m e BI :

(85)

D´ebut A l g o r i t h m e MP : POUR i DE 1 `a m FAIRE DEBUT

CHARGE MEMOIRE ( )

POUR j de 1 `a n2 FAIRE DEBUT

LIRE Page de R2

S I R1 . A=R2 . A ALORS C r ´e e r r ´e s u l t a t F I N S I FIN

FIN

CHARGER MEMOIRE ( ) POUR k DE 1 `a m FAIRE DEBUT

LIRE Page de R1 FIN

F i n A l g o r i t h m e MP :

(86)

Visualisation :

Expression Alg´ebrique Arbre alg´ebrique

Plan d’ex´ecution de la requˆete

(87)

Sous Oracle, possibilité de connaˆıtre pour chaque requête son plan d’exécution

Consultation du plan d’exécution selon lequel une instruction SQL sera exécutée par le SGBD Oracle dans une table

syst`eme

Stockage des plans d’ex´ecution dans une table PLAN_TABLE dont le script de cr´eation (fourni par Oracle) se trouve dans

$ORACLE_HOME/rdbms/admin/utlxplan.sql Etapes en vue de la consultation :

création la table de nomPLAN_TABLE Eventuellement la détruire et la recréer

exécuttion d’une commandeEXPLAIN PLANsur une requête Stockage (description) du plan d’exécution de cette dernière) dans la tablePLAN_TABLE

(88)

requˆ ete

EXPLAIN PLAN

SET s t a t e m e n t i d= ’ e x e m p l e 1 ’ // i d e n t i f i a n t FOR // e x e m p l e de r e q u ˆe t e

SELECT ∗∗∗ FROM ∗∗∗WHERE ∗ ∗ ∗; Exemple :

EXPLAIN PLAN

SET s t a t e m e n t i d = ’ r e q u e t e 1 ’

FOR s e l e c t ∗ from e l e v e s where nom l i k e ’DUPON% ’ ;

(89)

Interrogation de la tablePLAN_TABLE

| | ’ ’| |o b j e c t n a m e ” P l a n d ’ e x ´e c u t i o n ” FROM p l a n t a b l e

START WITH i d = 0 AND s t a t e m e n t i d = ’ r e q u e t e 1 ’ CONNECT BY PRIOR i d = p a r e n t i d

AND s t a t e m e n t i d = ’ r e q u e t e 1 ’ ; R´esultat affich´e :

Plan d’ex´ecution

--- SELECT STATEMENT

TABLE ACCESS BY INDEX ROWID ELEVES INDEX RANGE SCAN I_NOM

(90)

Repr´esentation d’une requˆete par un arbre Sous Oracle,

possibilit´e de repr´esentation et de manipulation

de données ayant une structure de données récursive (arbre) par une représentation tabulaire et avec la commande SQL : SELECT . . . FROM . . .WHERE . . .

CONNECT BY PRIOR c o l o n n e o p ´e r a t e u r c o l o n n e [CONNECT BY c o l o n n e o p ´e r a t e u r PRIOR c o l o n n e ] START WITH . . .

LEVEL . . .

(91)

structure de donn´ ees de type r´ ecursif

Structures de donn´ees r´ecursives de type Arbres Exemples :

Arbre G´en´ealogique

Nomenclature d’un produit (Compos´e, Composant) Oracle offre la commandeCONNECT BY

SELECT . . . FROM . . .WHERE . . .

CONNECT BY PRIOR c o l o n n e o p ´e r a t e u r c o l o n n e CONNECT BY c o l o n n e o p ´e r a t e u r PRIOR c o l o n n e

START WITH LEVEL

(92)

Arbre G´en´ealogique

Oracle permet la représentation et la manipulation des données ayant une structure arborescente par le modèle relationnel par exemple

c r e a t e t a b l e PERSONNES (

NUMEROnumber( 7 ) , NOM v a r c h a r( 1 5 ) , PRENOM v a r c h a r( 1 5 ) ,

DATENAISSANCE d a t e, SEXE c h a r( 1 ) , PERE number( 7 ) , MEREnumber( 7 ) , c o n s t r a i n t PK PERSONNES p r i m a r y k e y (NUMERO) ,

c o n s t r a i n t FK PERSONNES PERE PERSONNES f o r e i g n k e y( PERE ) r e f e r e n c e s PERSONNES , c o n s t r a i n t FK PERSONNES MERE PERSONNES f o r e i g n k e y(MERE) r e f e r e n c e s PERSONNES ,

(93)

Requˆete simple sur une table non index´ee DELETE p l a n t a b l e ;

// ( l a t a b l e é t a n t c r é é e une f o i s , i l s u f f i t de l a v i d e r ) EXPLAIN PLAN

FROM p l a n t a b l e

START WITH i d = 0 AND s t a t e m e n t i d = ’ r e q u e t e 1 ’

CONNECT BY PRIOR i d = p a r e n t i d AND s t a t e m e n t i d = ’ r e q u e t e 1 ’ ; Plan d’ex´ecution

(94)

Requˆete simple sur une table index´ee d r o p i n d e x i n o m ;

c r e a t e i n d e x i n o m on e l e v e s ( nom ) ; EXPLAIN PLAN

FROM p l a n t a b l e

(95)

Comparaison

Requˆete simple sur une table non index´ee :

Requˆete simple sur une table index´ee :

(96)

Requˆete avec un order by sur une table non index´ee d r o p i n d e x i n o m ;

d e l e t e p l a n t a b l e ; EXPLAIN PLAN

o b j e c t n a m e ” P l a n d ’ e x ´e c u t i o n ” FROM p l a n t a b l e

---

(97)

Requˆete avec un order by sur une table index´ee d r o p i n d e x i n o m ; c r e a t e i n d e x i n o m on e l e v e s ( nom ) ; d e l e t e p l a n t a b l e ;

EXPLAIN PLAN

o b j e c t n a m e ” P l a n d ’ e x ´e c u t i o n ” FROM p l a n t a b l e

SORT ORDER BY

TABLE ACCESS BY INDEX ROWID ELEVES

(98)

Comparaison

Requˆete avec un order by sur une table non index´ee

SORT ORDER BY

TABLE ACCESS FULL ELEVES

Requˆete avec un order by sur une table index´ee

SORT ORDER BY

TABLE ACCESS BY INDEX ROWID ELEVES