optimisation des bases de données

Proprit de Albiri Sigue customer 27921 at Fri Mar 11 19:20:10 +0100 2011

Rfr

ence

Rseauxet tlcom

Scurit

Systme dexploitation

bases de donnes

Optimisation des

Mise en uvre sous Oracle

Laurent Navarro

Programmation

Dveloppementweb


Optimisation des bases de donnesMise en uvre sous Oracle

Laurent Navarro

Avec la contribution technique

dEmmanuel Lecoester


Pearson Education France a apport le plus grand soin la ralisation de ce livre afin de vous fournir une information complte et fiable. Cependant, Pearson Education France nassume de responsabilits, ni pour son utilisation, ni pour les contrefaons de brevets ou atteintes aux droits de tierces personnes qui pourraient rsulter de cette utilisation.

Les exemples ou les programmes prsents dans cet ouvrage sont fournis pour illustrer les descriptions thoriques. Ils ne sont en aucun cas destins une utilisation commerciale ou professionnelle.

Pearson Education France ne pourra en aucun cas tre tenu pour responsable des prjudices oudommages de quelque nature que ce soit pouvant rsulter de lutilisation de ces exemples ou programmes.

Tous les noms de produits ou marques cits dans ce livre sont des marques dposes par leurs propritaires respectifs.

Publi par Pearson Education France47 bis, rue des Vinaigriers75010 PARISTl. : 01 72 74 90 00www.pearson.fr

Mise en pages : TyPAO

ISBN : 978-2-7440-4156-3Copyright 2010 Pearson Education FranceTous droits rservs

Aucune reprsentation ou reproduction, mme partielle, autre que celles prvues larticle L. 122-5 2 et 3 a) du code de la proprit intellectuelle ne peut tre faite sans lautorisation expresse de Pearson Education France ou, le cas chant, sans le respect des modalits prvues larticle L. 122-10 dudit code.


Table des matires

Prface ............................................................................................................................................... IX

propos de lauteur ...................................................................................................................... XI

Introduction ..................................................................................................................................... 1

1 Introduction aux SGBDR ................................................................................................... 5

1.1 Quest-ce quune base de donnes? .................................................................... 5

1.1.1 Systme de gestion des bases de donnes ...................................... 6

1.2 Modle de stockage des donnes ......................................................................... 7

1.2.1 Organisation des donnes .................................................................. 7

1.2.2 Le RowID ............................................................................................... 10

1.2.3 Online Redo Log et Archived Redo Log ........................................ 10

1.2.4 Organisation des tables ........................................................................ 11

1.2.5 Row Migration et Row Chaining ...................................................... 12

1.2.6 Le cache mmoire ................................................................................ 13

1.3 Intrt des index dans les SGBDR ....................................................................... 14

1.4 Analyse du comportement du SGBDR ............................................................... 15

1.4.1 Excution dune requte SQL ............................................................ 15

1.4.2 Optimiseur CBO (Cost Based Optimizer) ...................................... 16

Axe 1

tude et optimisation dumodle de donnes

2 Modle relationnel ................................................................................................................ 21

2.1 Prsentation .............................................................................................................. 21

2.2 Les bons rflexes sur le typage des donnes ...................................................... 25

2.2.1 Les types sous Oracle .......................................................................... 28


IV Optimisation des bases de donnes

2.2.2 Les types sous SQL Server ................................................................. 30

2.2.3 Les types sous MySQL........................................................................ 31

3 Normalisation, base du modle relationnel ................................................................... 33

3.1 Normalisation .......................................................................................................... 33

3.1.1 Premire forme normale (1NF) ......................................................... 34

3.1.2 Deuxime forme normale (2NF) ....................................................... 35

3.1.3 Troisime forme normale (3NF) ....................................................... 36

3.1.4 Forme normale de Boyce Codd (BCNF) ........................................ 37

3.1.5 Autres formes normales ...................................................................... 38

3.2 Dnormalisation et ses cas de mise en uvre .................................................... 38

3.2.1 La dnormalisation pour historisation ............................................. 38

3.2.2 La dnormalisation pour performance et simplification en environnement OLTP ..................................................................... 40

3.2.3 La dnormalisation pour performance en environnement OLAP .................................................................... 42

3.3 Notre base de test .................................................................................................... 43

Axe 2

tude et optimisation desrequtes

4 Mthodes et outils de diagnostic ....................................................................................... 49

4.1 Approche pour optimiser ....................................................................................... 49

4.1.1 Mesurer .................................................................................................... 50

4.1.2 Comprendre le plan dexcution ....................................................... 55

4.1.3 Identifier les requtes qui posent des problmes ........................... 61

4.2 Outils complmentaires ......................................................................................... 64

4.2.1 Compteurs de performance Windows .............................................. 64

4.2.2 SQL Tuning Advisor (Oracle) ........................................................... 65

4.2.3 SQL Access Advisor (Oracle) ............................................................ 66

4.2.4 SQL Trace (Oracle) ............................................................................... 67

4.2.5 Outils SQL Server................................................................................. 72

4.2.6 Outils MySQL ....................................................................................... 73


Table des matires V

5 Techniques doptimisation standard au niveau base de donnes ............................ 77

5.1 Statistiques sur les donnes ................................................................................... 77

5.1.1 Ancienne mthode de collecte ........................................................... 78

5.1.2 Nouvelle mthode de collecte ............................................................ 78

5.1.3 Slectivit, cardinalit, densit .......................................................... 80

5.2 Utilisation des index ............................................................................................... 85

5.2.1 Index B*Tree .......................................................................................... 86

5.2.2 Index sur fonction ................................................................................. 99

5.2.3 Reverse Index ......................................................................................... 100

5.2.4 Index bitmap........................................................................................... 101

5.2.5 Bitmap Join Index ................................................................................. 108

5.2.6 Full Text Index ....................................................................................... 111

5.3 Travail autour des tables ........................................................................................ 118

5.3.1 Paramtres de table ............................................................................... 118

5.3.2 Index Organized Table ........................................................................ 122

5.3.3 Cluster ...................................................................................................... 132

5.3.4 Partitionnement des donnes .............................................................. 135

5.3.5 Les vues matrialises ......................................................................... 146

5.3.6 Reconstruction des index et des tables ............................................ 148

6 Techniques doptimisation standard des requtes ....................................................... 153

6.1 Rcriture des requtes .......................................................................................... 153

6.1.1 Transformation de requtes ................................................................ 154

6.1.2 IN versus jointure .................................................................................. 155

6.1.3 Sous-requtes versus anti-jointures .................................................. 156

6.1.4 Exists versus Count .............................................................................. 158

6.1.5 Exists versus IN ..................................................................................... 159

6.1.6 Clause Exists * versus constante ....................................................... 160

6.1.7 Expressions sous requtes .................................................................. 161

6.1.8 Agrgats: Having versus Where ....................................................... 162

6.2 Bonnes et mauvaises pratiques ............................................................................. 163

6.2.1 Mlange des types ................................................................................ 163

6.2.2 Fonctions et expressions sur index ................................................... 163

6.2.3 Impact de loprateur sur les index ............................................ 164

6.2.4 Rutilisation de vue .............................................................................. 164


VI Optimisation des bases de donnes

6.2.5 Utilisation de tables temporaires ....................................................... 165

6.2.6 Utilisation abusive de SELECT * ...................................................... 165

6.2.7 Suppression des tris inutiles ............................................................... 166

6.2.8 Utilisation raisonne des oprations ensemblistes ....................... 166

6.2.9 Union versus Union ALL ..................................................................... 169

6.2.10 Count(*) versus count(colonne) ........................................................ 170

6.2.11 Rduction du nombre de parcours des donnes ............................ 171

6.2.12 LMD et cls trangres........................................................................ 172

6.2.13 Suppression temporaire des index et des CIR ............................... 173

6.2.14 Truncate versus Delete ........................................................................ 173

6.2.15 Impacts des verrous et des transactions ........................................... 173

6.2.16 Optimisation du COMMIT ................................................................. 175

6.2.17 DBLink et vues ...................................................................................... 176

7 Techniques doptimisation des requtes avances ....................................................... 177

7.1 Utilisation des hints sous Oracle .......................................................................... 177

7.1.1 Syntaxe gnrale ................................................................................... 179

7.1.2 Les hints Optimizer Goal .................................................................... 179

7.1.3 Les hints Access Path ........................................................................... 180

7.1.4 Les hints Query Transformation ....................................................... 181

7.1.5 Les hints de jointure ............................................................................. 182

7.1.6 Autres hints............................................................................................. 183

7.2 Excution parallle ................................................................................................. 183

7.2.1 Les hints de paralllisme ..................................................................... 185

7.3 Utilisation du SQL avanc ..................................................................................... 186

7.3.1 Les Grouping Sets ................................................................................. 186

7.3.2 Rollup Group By.................................................................................... 188

7.3.3 Cube Group By ...................................................................................... 189

7.3.4 Utilisation de WITH ............................................................................. 191

7.3.5 Les fonctions de classement (ranking) ............................................ 192

7.3.6 Autres fonctions analytiques .............................................................. 194

7.3.7 Linstruction MERGE .......................................................................... 195

7.3.8 Optimisation des updates multitables .............................................. 196

7.3.9 Insertion en mode Direct Path ........................................................... 198


Table des matires VII

7.4 PL/SQL ..................................................................................................................... 198

7.4.1 Impact des triggers ............................................................................... 198

7.4.2 Optimisation des curseurs (BULK COLLECT) ............................. 200

7.4.3 Optimisation du LMD (FORALL) .................................................... 203

7.4.4 SQL dynamique et BULK ................................................................... 208

7.4.5 Traitement des exceptions avec FORALL ....................................... 209

7.4.6 Utilisation de cache de donnes ........................................................ 210

7.4.7 Utilisation du profiling ........................................................................ 212

7.4.8 Compilation du code PL/SQL ........................................................... 212

Axe 3

Autres pistes doptimisation

8 Optimisation applicative (hors SQL) ............................................................................. 217

8.1 Impact du rseau sur le modle client/serveur ................................................... 217

8.2 Regroupement de certaines requtes ................................................................... 217

8.3 Utilisation du binding ............................................................................................. 219

8.4 Utilisation de cache local lapplication ............................................................ 221

8.5 Utilisation du SQL procdural .............................................................................. 221

8.6 Gare aux excs de modularit ............................................................................... 221

9 Optimisation de linfrastructure ...................................................................................... 223

9.1 Optimisation de lexcution du SGBDR ............................................................. 223

9.1.1 Ajustement de la mmoire utilisable ................................................ 223

9.1.2 Rpartition des fichiers ........................................................................ 224

9.2 Optimisation matrielle .......................................................................................... 224

9.2.1 Le CPU .................................................................................................... 224

9.2.2 La mmoire vive (RAM) ..................................................................... 225

9.2.3 Le sous-systme disque ....................................................................... 225

9.2.4 Le rseau ................................................................................................. 226

Conclusion ........................................................................................................................................ 227


VIII Optimisation des bases de donnes

Annexes

A Gestion interne des enregistrements ................................................................................ 231

A.1 Le RowID ................................................................................................................. 231

A.2 Row Migration et Row Chaining ......................................................................... 232

B Statistiques sur les donnes plus en dtail...................................................................... 235

B.1 Statistiques selon lancienne mthode de collecte ............................................ 235

B.2 Statistiques selon la nouvelle mthode de collecte ........................................... 236

B.3 Histogrammes .......................................................................................................... 240

B.4 Facteur de foisonnement (Clustering Factor) .................................................... 241

C Scripts de cration des tables de test bigemp et bigdept .............................................. 245

D Glossaire .................................................................................................................................. 249

Index ................................................................................................................................................... 251


Prface

Loptimisation des applications est un sujet bien vaste, souvent objet des dbats d'experts et gnrateur de quiproquos notamment sur les causes gnrant les effets constats (lenteur daffichage, fort trafic rseau, saturation du serveur de donnes).

Loptimisation se prsente sous de multiples facettes:

Tantt, elle est purement applicative et touche la mthode de programmation.

Tantt, les drives proviennent dun manque au niveau de la modlisation des donnes, plus gnralement dun problme d'index ou de paramtrage du serveur de donnes.

Parfois mme, loptimisation est tout simplement lie une limite de larchitec-ture physique du systme.

Dans chacun de ces trois cas de figure majeurs, il est important de mesurer ce manque doptimisation et de choisir les mtriques les plus discriminantes afin de pouvoir mesurer les bnfices exacts de loptimisation apporte.

Dans cet ouvrage, Laurent Navarro apporte un lot de rponses concrtes et dtailles au dveloppeur dapplication, dans une vision rsolument cible sur laccs aux donnes. Jinsiste bien sur ce point: ce livre nest pas un catalogue des techniques doptimisation propres chaque serveur de donnes destin aux administrateurs ou autres experts mais bien un premier pas vers une sensibilisation des dveloppeurs de tous bords aux contacts avec un serveur de donnes.

Ce livre parcourt les principales techniques doptimisation disponibles pour le dve-loppeur dapplication: modle de donnes, techniques standard daccs aux donnes jusqu des techniques trs avances permettant dexploiter au mieux les possibilits offertes par les principaux diteurs de bases de donnes du march.

Emmanuel Lecoester

Responsable des rubriques SGBD & WinDev de developpez.com


propos de lauteur

Adolescent, je mamusais avec des bases de donnes DBase II & III, puis jai dbut ma carrire dans l'industrie avec des bases en fichiers partags Paradox. La nature des applications a volu, et en 1994 jai commenc travailler sur des bases Oracle (Version 7). lpoque, cela ncessitait un serveur Unix et un DBA bard de certifications. Au fil du temps, les SGBDR client/serveur se sont dmocratises. Des alternatives au leader sont apparues, contribuant pour une grande part cette dmocratisation. Cest ainsi quen 2000 jai fait la connaissance de MySQL (3.2 lpoque) pour ma premire application web dveloppe en PHP. Puis jai eu locca-sion dutiliser dautre bases, telles que SQL Server de Microsoft, Firebird la version open-source dInterbase ou encore PostgreSQL, autre alternative open-source qui ne rencontre malheureusement pas le succs quelle mriterait.

Paralllement, les clients aussi se sont diversifis, et je constatais que le primtre dutilisation des bases de donnes stendait. Au dbut rserv linformatique de gestion, les bases de donnes sont petit petit apparues dans les secteurs de linfor-matique industrielle et de linformatique mobile. Ces secteurs ntant pas forcment coutumiers de ces technologies, ils ont fait appel des gens comme moi pour les conseiller dans leur volution.

Aimant varier les plaisirs, outre les bases de donnes, je dveloppe en C/C++, par-fois en environnement contraint du point de vue des performances. Cest proba-blement de l que me vient cette curiosit qui me pousse comprendre comment fonctionnent les choses et qui a pour suite naturelle loptimisation. Ajoutez cela le plaisir de partager ses connaissances et vous comprendrez comment est n ce livre, qui jespre vous aidera dans votre travail.

Laurent Navarro, dveloppeur dapplications, est bas Toulouse et travaille depuis quinze ans avec des bases de donnes Oracle mais aussi quelques autres (SQL Server, MySQL,etc.).

Il anime des formations SQL, PL/SQL, Pro*C et Tuning SQL depuis une dizaine dannes.


Introduction

Pourquoi ce livre, qui s'adresse-t-il?

Loptimisation de bases de donnes est un problme la fois simple et compliqu.

Jinterviens souvent auprs de structures qui nont aucune notion doptimisation et, dans ces cas-l, les choses sont plutt simples car lapplication de principes de base doptimisation amliore rapidement la situation. En revanche, lorsque ces principes de base ont dj t appliqus, la tche peut tre plus ardue

Lobjectif de cet ouvrage est de fournir les bases de loptimisation. Il explique ce qui se passe dans la base de donnes afin que vous puissiez comprendre ce qui se passe sous le capot de votre SGBDR et, ainsi, vous permettre de choisir des solutions doptimisation en ayant conscience des impacts de vos choix.

Il existe dj des livres couvrant ce domaine, mais la plupart sont en anglais et sadressent des DBA (administrateurs de base de donnes). Ces ouvrages sont soit tellement pointus quun non-expert peut sy noyer, soit tellement lgers quon ne comprend pas forcment pourquoi les choses sont censes samliorer. Cela rend dlicate la transposition votre environnement. Jespre avoir trouv un juste milieu avec cet ouvrage.

Pour moi, il est primordial daborder le problme de loptimisation ds la concep-tion dun logiciel. Il est donc ncessaire que les dveloppeurs sapproprient ces comptences plutt que de demander aux DBA de trouver des solutions aprs la mise en production.

Ce livre sadresse donc en premier lieu aux quipes de dveloppement dve-loppeurs, chefs de projet, architectes mais aussi, bien sr, aux DBA qui seront toujours les interlocuteurs naturels des quipes de dveloppement ds quune base de donnes sera utilise.


2 Optimisation des bases de donnes

Quels sont les prrequis?

Pour lire cet ouvrage, il vous suffit de savoir ce quest une base de donnes relationnelle.

Une connaissance du SQL sera un plus.

Quel est le primtre de ce livre?

Ce livre couvre les cas les plus frquents, cest--dire des applications ayant au plus quelques gigaoctets de donnes sur des serveurs classiques. Il ne couvre donc pas des sujets comme lutilisation de GRID, de RAC ou des bases OLAP, mme si de nombreux thmes abords ici sont prsents dans ce type dapplication aussi.

Cet ouvrage se focalise sur loptimisation autour du dveloppement. Les optimi-sations au niveau de linfrastructure de la base de donnes ne seront que trs peu abordes. Dautres livres plus orients sur lexploitation traitent dj ce sujet bien mieux que je ne saurais le faire.

Organisation du livre

Cet ouvrage sarticule autour de neuf chapitres, regroups dans trois parties:

Le Chapitre 1 est une introduction visant prsenter brivement quelques mcanismes internes des SGBDR qui seront ncessaires la comprhension des chapitres suivants.

La premire partie concerne le premier axe doptimisation : celle du modle de donnes.

Le Chapitre2 rappelle ce quest le modle relationnel et traite les problma-tiques lies au typage des donnes.

Le Chapitre3 traite de lintrt de la normalisation des bases de donnes et de lutilit que peut prsenter la dnormalisation applique bon escient.

La deuxime partie concerne le deuxime axe doptimisation: celle des requtes.

Le Chapitre4 prsente les mthodes et loutillage. Il traite des diffrents outils votre disposition pour analyser les situations et explique comment comprendre les rsultats.


Introduction 3

Le Chapitre5 dcrit lensemble des objets doptimisation et le cadre de leur utilisation. Il dcrit les diffrents types dindex et dorganisation des tables ainsi que leurs cas dusage.

Le Chapitre6 prsente les impacts des variantes dcriture et dcrit quelques bonnes et mauvaises pratiques.

Le Chapitre7 introduit les hints quil faut utiliser avec parcimonie, un ensemble de techniques SQL avances ainsi que des optimisations du PL/SQL.

La troisime partie contient dautres axes doptimisations.

Le Chapitre8 traite des optimisations applicatives autres que loptimisation des requtes elles-mmes.

Le Chapitre 9 aborde brivement quelques optimisations envisageables au niveau de linfrastructure.

Ressources en ligne

Afin dillustrer les concepts prsents tout au long de ce livre, nous allons les appliquer une base de test.

Cette base (structure et donnes) est disponible pour les SGBDR Oracle, SQL Server et MySQL sur le site de lauteur, ladresse http://www.altidev.com/livres.php.

Remerciements

Merci ma femme Bndicte et mon fils Thomas pour leur soutien et leur patience durant lcriture de ce livre. Merci ma mre Ginette pour ses relectures. Merci mes relecteurs, Emmanuel et Nicole. Merci mon diteur, Pearson France, et parti-culirement Patricia pour mavoir fait confiance et Amandine pour ses prcieux conseils. Merci lquipe dIris Technologies pour mavoir donn lide de ce livre en me permettant danimer des formations sur ce sujet.


1

Introduction aux SGBDR

Pour optimiser une base Oracle, il est important davoir une ide de la manire dont elle fonctionne. La connaissance des lments sous-jacents son fonctionnement permet de mieux comprendre ses comportements. Cest pourquoi nous commen-cerons, ce chapitre, par vous prsenter ou vous rappeler brivement ce quest un SGBDR et quelques-uns des lments qui le composent. Ces notions vous seront utiles tout au long du livre. Le but ici nest pas de faire de vous un spcialiste du fonctionnement interne dOracle, mais de vous donner quelques explications sur des concepts que nous rfrencerons ultrieurement.

Si vous tes DBA, vous pouvez vous rendre directement au Chapitre2.

1.1 Qu'est-ce qu'une base de donnes?

Une base de donnes est un ensemble dinformations structures. Elle peut tre de nature:

hirarchique;

relationnelle;

objet;

documentaire;

Actuellement, le march est principalement compos de bases de donnes relation-nelles avec, parfois, une extension objet. Cet ouvrage traite exclusivement de ce type de bases.



Dans les bases de donnes relationnelles, les donnes sont organises dans des tables deux dimensions, conformment au modle relationnel que nous tudierons au Chapitre 2.

1.1.1 Systme de gestion des bases de donnes

Un SGBDR (systme de gestion de base de donnes relationnelle) est un systme (logiciel) qui permet de grer une base de donnes relationnelle. Les SGBDR peu-vent tre soit de type client/serveur (Oracle, SQL Server, MySQL, PostgreSQL, etc.), soit de type fichiers partags (Access, SQL Server CE, Paradox, DBase, etc.). Dans le milieu professionnel, on retrouve principalement des SGBDR client/ser-veur mme si les solutions en fichiers partags ont eu leur heure de gloire et sont encore utilises dans certaines applications. Lapparition de SGBDR client/serveur gratuits a fortement contribu populariser ce modle ces dernires annes. Le modle client/serveur ncessite gnralement la prsence dun serveur, qui traite les requtes transmises par le client et lui retourne le rsultat. Le principal intrt dun SGBDR est quil va fournir les services suivants (tous les SGBDR ne proposent pas tous ces services):

implmentation du langage d'interrogation des donnes SQL (Structured Query Language);

gestion des structures des donnes et de leur modification;

gestion de lintgrit des donnes;

gestion des transactions;

gestion de la scurit, contrle daccs;

abstraction de la plateforme matrielle et du systme dexploitation sous-jacent;

du point de vue logique, abstraction de lorganisation du stockage sous-jacent;

tolrance aux pannes et administration du systme;

rpartition de la charge.


Chapitre1 Introduction aux SGBDR 7

1.2 Modle de stockage des donnes

1.2.1 Organisation des donnes

Les tables sont les objets logiques de base du modle relationnel. Or, un systme dexploitation ne connat que la notion de fichiers. Le SGBDR permet de faire le lien entre la reprsentation logique et le stockage physique dans les fichiers. Nous allons voir comment en tudiant le SGBDR Oracle.

Les objets logiques (tables, index, etc.) sont stocks dans des espaces logiques appe-ls "tablespaces". Une base de donnes est constitue de plusieurs tablespaces, les-quels sont composs dun ou de plusieurs fichiers appels "datafiles". Ces fichiers peuvent se trouver sur des disques diffrents.

tablespaceTBS_COMPTA

d:\OracleData\DataFileCompta1.Ora

d:\OracleData\DataFileCompta2.Ora

datales : Fichiers de donnes

Objets stocks dansle tablespace et repartis

sur les datales

TablespaceEspace disque logiqueTable

Index

Index

Index

Index

Table

Index

Index

Index

Table

Index

Index

Index

Figure1.1

Organisation des objets dans un tablespace compos de deux datafiles.

Les objets sont attachs un seul tablespace mais ils peuvent, par contre, tre rpar-tis sur plusieurs datafiles (voir Figure1.1). Il ny a aucun moyen dinfluer sur la localisation des objets au niveau des datafiles, il est seulement possible de dfinir le tablespace associ un objet. (Les objets partitionns peuvent, eux, tre attachs plusieurs tablespaces. Nous les tudierons au Chapitre5, section5.3.4, "Partition-nement des donnes".)

Les datafiles, et donc les tablespaces, sont constitus de blocs de donnes (data block), dont la taille est configure la cration du tablespace. Ce paramtre varie gnra-lement entre 2Ko et 16Ko et, par dfaut, est de 4 ou 8Ko suivant la plateforme



(au long de louvrage, nous retiendrons une taille de 8Ko qui est une valeur assez communment utilise).

Chaque objet ou constituant dobjet ayant besoin de stockage sappelle un "seg-ment". Par exemple, pour une table classique, il y a un segment pour la table elle-mme, un segment pour chacun de ses index et un segment pour chacun de ses champs LOB (voir Chapitre 2, section 2.2.1, "Les types sous Oracle").

Quand un segment a besoin despace de stockage, il alloue un extent, cest--dire un ensemble de blocs de donnes contigus. Un segment est donc compos dun ensemble dextents qui nont pas forcment tous la mme taille. (Les clauses INITIAL et NEXT spcifies dans linstruction de cration de lobjet associ au segment permettent dinfluer sur ces paramtres.) La Figure1.2 prsente la dcomposition hirarchique dun segment en blocs de donnes. Il est noter que, si un segment na plus besoin de lespace quil a prcdemment allou, il ne le libre pas ncessairement.

Figure1.2

Dcompositiond'un segment en extentspuis en blocs.

8 K

8 K

8 K

8 K

8 K

8 K

8 Ko

8 Ko

8 Ko

8 Ko

o

o

o

o

o

o

8 Ko

8 Ko

8 K

8 K

8 K

8 K

8 K

8 K

8 Ko

8 Ko

o

o

o

o

o

o

8 Ko

8 Ko

8 K

8 K

8 K

8 K

8 K

8 K

8 Ko

8 Ko

o

o

o

o

o

o

8 Ko

8 Ko

8 Ko

8 Ko

8 Ko

8 Ko

8 Ko

8 Ko

8 Ko

8 Ko

Blocs de donnes(data block)

Extent Initial128 Ko

Extent64 Ko

Extent64 Ko

Segment256 Ko

MS SQL Server

Sous SQL Server, la logique est relativement proche, sauf qu'un niveau supplmentaire est intgr, le niveau base de donnes (database). la diffrence d'Oracle, une instance SQL Server contient plusieurs bases de donnes, qui ont chacune leurs espaces logiques nomms data file group (quivalents des tablespaces) eux-mmes composs de data file.



MySQL

Sous MySQL, l'organisation du stockage est dlgue au moteur de stockage. Plusieurs moteurs sont supports, MyISAM et InnoDB le plus frquemment.

Le moteur MyISAM attribue plusieurs fichiers chaque table.

Un fichier .frm pour dcrire la structure de la table. Ce fichier est gr par MySQL et non pas par le moteur de stockage. Un fichier .myd qui contient les donnes.

Un fichier .myi qui contient les index.

Le moteur InnoDB implmente le concept de tablespace qui contient tous les lments de la base de donnes (tables, index, etc.). Les fichiers .frm grs par MySQL sont prsents en plus du tablespace.

Les blocs de donnes contiennent les enregistrements (lignes ou row) et des struc-tures de contrle. La Figure1.3 montre un schma complet de lorganisation du stockage des donnes.

Figure1.3

Schma illustrant le stockagedes donnes dans une baseOracle.

Datale

Segment (Table)

Initial-Ex

tent

Nex

t-Ex

tent

Nex

t-Ex

tent

Nex

t-Ex

tent

Extent

Bloc de donne

s

Bloc de donne

s

Bloc de donne

s

Bloc de donne

s

Bloc de donne

s

Bloc de donne

s

Bloc de donnes

Espace libre

Enregistrement

En-ttedebloc

Enregistrement dcompos

En-tte TailleDonne DonneTaille

Donne DonneTaille

Donne Donne

Table

Tablespace Segments



1.2.2 Le RowID

Le RowID (identifiant de ligne) est une information permettant dadresser direc-tement un enregistrement, sans avoir parcourir aucune liste. Cest une sorte de pointeur. Il est compos de:

lidentifiant de lobjet;

lidentifiant du datafile;

lidentifiant du bloc dans le datafile;

lidentifiant de la ligne dans le bloc.

Cette information sera rarement manipule directement par vos applications. Elle est surtout destine un usage interne au SGBDR. Cependant, dans certains cas, il peut tre intressant dy recourir depuis une application, par exemple pour dsigner un enregistrement nayant pas de cl primaire ou pour adresser plus rapidement un enregistrement pour lequel vous avez rcupr le RowID. Le RowID dun enregis-trement sobtient en interrogeant la pseudo-colonne rowid.

SQL> select nocmd, noclient, datecommande, rowid from cmd; NOCMD NOCLIENT DATECOMMANDE ROWID---------- ---------- ------------ ------------------ 14524 106141 16/04/2004 AAARnUAAGAAASIfAAG 14525 131869 16/04/2004 AAARnUAAGAAASIfAAH 14526 83068 16/04/2004 AAARnUAAGAAASIfAAI 14527 120877 16/04/2004 AAARnUAAGAAASIfAAJ 14528 34288 16/04/2004 AAARnUAAGAAASIfAAK 14529 103897 16/04/2004 AAARnUAAGAAASIfAAL 6 rows selected

Voir lAnnexeA, sectionA.1, pour plus dinformations sur les RowID.

1.2.3 Online Redo Log et Archived Redo Log

Les fichiers Online Redo Log sont des fichiers binaires qui contiennent toutes les modifications appliques aux datafiles rcemment. Ils permettent notamment de rparer les datafiles en cas darrt brutal de la base.

Les fichiers Archived Redo Log sont des fichiers Redo Log archivs. Ils sont crs uniquement si le mode archivelog est actif. Ils permettent de rparer les datafiles, de complter une restauration, de maintenir une base de secours en attente (stand by database) et sont aussi ncessaires pour certaines fonctions Oracle Warehouse.



Leur gestion a un cot en termes despace disque utilis, donc si vous nen avez pas besoin, dsactivez cette fonction.

MS SQL Server

Les fichiers LDF, qui sont les journaux de transactions, jouent un rle analogue aux Online Redo Log.

MySQL

Le moteur InnoDB intgre un mcanisme analogue aux Online Redo Log. Le moteur MyI-SAM n'a pas d'quivalent.

1.2.4 Organisation des tables

Les donnes sont organises dans des tables deux dimensions: les colonnes, ou champs, qui ne sont pas supposes voluer diffremment du modle de donnes, et les lignes, enregistrements qui varient au fil du temps quand des donnes sont ajou-tes ou modifies. Par dfaut, dans de nombreux SGBDR, la structure de stockage adopte est une structure dite de "tas" (heap).

Ce type de structure stocke les enregistrements en vrac, sans ordre particulier, dans une zone de donnes. Quand un enregistrement est dtruit, il libre de lespace quun autre enregistrement pourra ventuellement rutiliser.

Sous Oracle, en mode MSSM (Manual Segment Space Management), les blocs contenant de lespace libre, cest--dire dont le pourcentage despace libre est sup-rieur au paramtre PCTFREE de la table, sont lists dans une zone de la table nomme FREELIST. Les blocs dans lesquels de lespace a t libr la suite de suppressions denregistrements et dont le pourcentage despace utilis repasse en dessous de la valeur du paramtre PCTUSED sont, eux aussi, rpertoris dans la FREELIST.

Lorganisation des tables sous forme dindex est assez commune, les enregistre-ments sont stocks dans lordre de la cl primaire. On dit alors que la table est orga-nise en index (IOT, Index Organized Table). Nous tudierons ce type de table au Chapitre5, section5.3.2, "Index Organized Table".



MS SQL Server

Les tables sans index clustered sont organises en tas, celles ayant un index clustered ont une organisation de type IOT.

MySQL

Sous MySQL, les tables utilisant le moteur MyISAM sont organises en tas, celles utilisant le moteur InnoDB ont une organisation de type IOT.

1.2.5 RowMigration et RowChaining

La migration denregistrement (Row Migration) est le mcanisme qui dplace un enregistrement qui ne tient plus dans son bloc, aprs une mise jour de ses don-nes ayant entran un accroissement de sa taille. Lors de la migration, le SGBDR insre un pointeur lemplacement initial de lenregistrement qui dsigne le nouvel emplacement que le SGBDR alloue pour y placer les donnes. Ainsi, on pourra toujours accder lenregistrement en utilisant le RowID initial qui reste valide. Cependant, il faut noter que lutilisation de ce pointeur sera source dE/S (entres/sorties) supplmentaires. En effet, laccs un enregistrement au moyen de son RowID se fait habituellement en une lecture de bloc, alors que celui un enregistre-ment ayant migr ncessite de lire deux blocs (celui qui est point par le RowID plus celui qui est dsign par le pointeur). Afin de limiter lapparition de ce phnomne, Oracle ninsre des lignes dans un bloc que si un certain pourcentage despace libre demeure lissue de cette opration (paramtre PCTFREE de la table; par dfaut, il vaut 10%).

Le chanage denregistrement (Row Chaining) est le mcanisme qui gre le fait quun enregistrement ne peut pas tenir dans un unique bloc de donnes (8Ko par dfaut) car sa taille est suprieure. Le processus va scinder les donnes et les rpar-tir dans plusieurs blocs en plaant dans chaque bloc un pointeur vers les donnes situes dans le bloc suivant. Comme lors de la migration denregistrement, ce mca-nisme va causer des E/S supplmentaires.

Voir lAnnexeA, sectionA.2, pour plus dinformations sur ces mcanismes.



1.2.6 Le cache mmoire

Les accs disque sont trs lents compars aux accs en mmoire vive (RAM). Approximativement et en simplifiant : un disque dur a un temps daccs qui se compte en millisecondes, alors que celui de la mmoire se compte en nanosecondes. La mmoire vive est donc un million de fois plus rapide que les disques durs.

Par ailleurs, la quantit de mmoire vive sur les serveurs tant de plus en plus impor-tante, une optimisation assez vidente consiste implmenter un systme de cache mmoire dans les SGBDR.

Le but du cache mmoire est de conserver en mmoire une copie des informations les plus utilises afin de rduire les accs au disque dur. Sous Oracle, ces caches mmoire se trouvent dans SGA (System Global Area), une zone mmoire principale, qui englobe diverses zones, parmi lesquelles:

Database Buffer Cache. Contient les blocs manipuls le plus rcemment.

Shared Pool. Contient les requtes rcentes ainsi que le plan dexcution qui leur est associ. Cette zone contient aussi un cache du dictionnaire des donnes.

Le buffer cache contient une copie mmoire des blocs les plus manipuls afin de rduire le nombre daccs disque. Cela aura pour effet damliorer notablement les performances. Dans de nombreux cas, la quantit de mmoire disponible pour le buffer cache sera plus faible que celle des donnes manipules. De fait, il faudra choisir quelles sont les donnes conserver dans le cache et quelles sont celles qui doivent cder leur place de nouvelles donnes. Ce choix sera fait par un algorithme de type MRU (Most Recently Used) qui privilgiera le maintien en mmoire des blocs les plus utiliss rcemment. Afin dviter que le parcours dune grosse table entrane un renouvellement complet du cache, laccs ce type de tables est pondr dfavorablement au profit des petites tables, pondres, elles, positivement. Ces der-nires resteront plus longtemps dans le cache, alors que, gnralement, les grosses tables ny seront pas charges entirement.

MS SQL Server

Sous SQL Server, on retrouve un mcanisme tout fait similaire.



MySQL

Sous MySQL, les choses sont un peu diffrentes. On retrouve bien un mcanisme de cache, mais d'une nature diffrente. Le cache de requte permet de garder en cache le rsultat des requtes prcdemment excutes.

Le cache mmoire correspondant au buffer cache d'Oracle est, lui, de la responsabilit du moteur de stockage:

Le moteur MyISAM n'en a pas. Il part du principe que le systme d'exploitation en possde un et qu'il sera tout aussi efficace d'utiliser celui-l. Cette solution est un peu moins intressante mais elle a l'avantage de simplifier le moteur de stockage.

Le moteur InnoDB intgre, lui, un cache mmoire similaire, sur le principe au buffer cache d'Oracle.

1.3 Intrt des index dans les SGBDR

Nous avons vu prcdemment que, dans une table organise en tas, les donnes nont pas dordre particulier. Lorsque le SGBDR cherche une information suivant un critre particulier (on parle de cl de recherche), il na pas dautre choix que de parcourir lensemble des enregistrements pour trouver ceux qui rpondent au critre demand. Vous imaginez aisment que, lorsquil y a beaucoup denregistrements, cette mthode nest pas trs intressante. Cest pour rpondre plus efficacement ce genre de besoin que la notion dindex a t introduite dans les SGBDR. Un index de base de donnes ressemble un peu lindex de ce livre. Il contient une liste ordonne de mots et une rfrence vers la page qui les contient. De plus, lindex est bien plus petit que le livre.

Si nous retranscrivons cela en termes de base de donnes, un index contient la cl de recherche et une rfrence vers lenregistrement. Son principal avantage est quil est ordonn. Cela permet dy appliquer des techniques de recherche par dichotomie, beaucoup plus efficaces que les recherches linaires ds que le nombre denregis-trements slve.

Les index sont intressants avec les tables organises en tas. Cependant, le besoin est le mme avec les tables organises suivant des index (IOT) qui sont dj tries. En effet, si lordre de la table nest pas celui de la cl de recherche, le problme reste entier. Par exemple, si vous grez une liste de personnes trie par numro de Scurit sociale, lorsque vous faites une recherche sur le nom, vous ntes pas plus avanc que la liste soit trie par numro de Scurit sociale ou pas trie du tout.



Lintrt des index est donc indpendant du type dorganisation de table. Nous tu-dierons en dtail au Chapitre5, section5.2.1, "Index B*Tree", les index B*Tree, les plus communs. Par la suite, nous aborderons les principaux types dindex disponibles.

1.4 Analyse du comportement du SGBDR

1.4.1 Excution d'une requte SQL

Toute requte SQL envoye au SGBDR suit le mme parcours afin dtre excute. Nous allons tudier ici ce cheminement afin de comprendre comment le SGBDR passe dune requte SQL un ensemble de donnes rsultat.

Il faut bien avoir en tte que le SQL, contrairement la plupart des langages infor-matiques, ne dcrit pas la faon de dterminer le rsultat mais quil permet dexpri-mer un rsultat attendu. Ainsi, il nexplique pas comment manipuler les tables, mais les liens quil y a entre elles et les prdicats appliquer sur les donnes. Le SGBDR doit trouver le meilleur moyen de rpondre une requte SQL.

tape1:Parsingettraductionenlangageinterne

Cette tape consiste interprter le texte de la requte (parsing) et effectuer des contrles syntaxiques. Le SGBDR vrifie si la requte respecte la grammaire dune requte SQL et si les mots cls sont bien placs. Cette tape inclut aussi les contrles smantiques, cest--dire que le SGBDR vrifie si la requte manipule bien des tables et des colonnes qui existent et si lutilisateur possde les droits permettant de faire ce qui est demand dans la requte.

tape2:tablissementd'unpland'excution

Le plan dexcution est la faon dont le SGBDR parcourt les diffrents ensembles de donnes afin de rpondre la requte. Nous tudierons au Chapitre 4, sec-tion4.1.2, "Comprendre le plan dexcution", les lments primaires constituant un plan dexcution.

Lors de cette tape, le SGBDR tablit plusieurs plans dexcution possibles. En effet, tout comme il y a plusieurs algorithmes possibles pour crire un programme, il y a plusieurs plans dexcution possibles pour rpondre une requte.



Ensuite, loptimiseur (voir section 1.4.2) choisi le plan dexcution quil estime tre le meilleur pour excuter la requte, parmi les diffrents plans dexcution possibles.

tape3:Excutiondelarequte

Cette tape consiste excuter le plan dexcution dfini ltape prcdente, cest--dire aller chercher les informations dans les tables en passant par les chemins dfinis par le plan dexcution et en extraire le rsultat demand.

La technique du binding que nous tudierons au Chapitre8, section8.3, "Utilisation du binding" permet, lorsqu'une mme requte est excute plusieurs fois avec des paramtres diffrents, de n'excuter qu'une seule fois les tapes1 et2 et ainsi de passer directement l'tape3 lors des excutions suivantes.

1.4.2 Optimiseur CBO (CostBasedOptimizer)

Le rle de loptimiseur est de trouver le plan dexcution le plus performant pour excuter une requte. Oracle est depuis la version7 (dbut des annes 1990) pourvu de deux optimiseurs de requtes:

celui qui est bas sur des rgles (RBO, Rule Based Optimizer, introduit en V6);

celui qui est bas sur les cots (CBO, Cost Based Optimizer, introduit en V7).

Sur les versions rcentes dOracle, loptimiseur bas sur les rgles nexiste plus vraiment. Les mots cls permettant la manipulation du RBO sont seulement pr-sents des fins de rtrocompatibilit (depuis la version10g, le RBO nest plus sup-port). Oracle recommande, depuis plusieurs versions, de ne plus utiliser le RBO et concentre tous ses efforts sur le CBO, cest donc celui-l que nous allons tudier.

MSSQLServeretMySQL

SQL Server et MySQL tant eux aussi munis d'un optimiseur de type CBO, les grands prin-cipes tudis ici seront communs.

Le CBO est un optimiseur qui est bas sur lestimation des cots dexcution des oprations des plans dexcution. Pour une requte donne, le SGBDR tablit plu-sieurs plans dexcution possibles, et le CBO estime pour chacun deux le cot dexcution et choisit le moins lev.

INFO



Comment estimer le cot dun plan dexcution ? Le SGBDR value le cot en ressources utilises pour excuter ce plan. Ces ressources sont:

le temps CPU;

le nombre dE/S (entres/sorties) disque dur (I/O en anglais);

la quantit de mmoire vive (RAM) ncessaire.

Le cot sera une synthse entre lutilisation du CPU et le cot des E/S, selon quil sagit daccs squentiels (lecture de plusieurs blocs contigus) ou daccs alatoires (lecture monobloc).

Cependant, vous imaginerez aisment que ce cot dpend non seulement de la requte elle-mme, mais aussi des donnes sur lesquelles elle porte. En effet, cal-culer le salaire moyen dune table contenant 10personnes sera moins coteux que de calculer la mme moyenne sur une table dun million de personnes alors que la requte sera la mme.

Pour estimer le cot dune requte, le SGBDR a besoin de dterminer, pour chacune des tapes du plan dexcution, le nombre denregistrements concerns, cest--dire la cardinalit de lopration. Cette cardinalit dpend des donnes elles-mmes mais aussi de limpact de chacune des conditions. Par exemple, une condition qui filtre sur un numro de Scurit sociale naura pas le mme impact sur la cardinalit quune condition portant sur un dpartement ou une anne de naissance. Ce principe se nomme la slectivit, nous ltudierons au Chapitre5, section5.1.3, "Slectivit, cardinalit, densit".

Loptimiseur dtermine le cot de chaque plan daction dexcution. Pour cela, sans excuter aucun deux, ni parcourir les donnes, il dfinit les cardinalits de chaque opration partir de statistiques sur les donnes (voir Chapitre5, section5.1, "Statis-tiques sur les donnes").

Loptimiseur cherche dterminer le meilleur plan ; cependant, la notion de "meilleur" peut, dans certains cas, diffrer en fonction de lobjectif, lOptimizer Goal, qui peut tre de deux types:

First_Rows (premires lignes);

All_Rows (toutes les lignes).

First_Rows privilgie le temps de rponse pour retourner les premires lignes. Cela peut tre intressant dans le cadre dapplications interagissant avec des utilisateurs.



Pourtant, la meilleure solution choisie pour cet objectif peut se rvler moins int-ressante si, finalement, on ramne toutes les lignes.

All_Rows, lui, privilgie lutilisation optimale des ressources. Il considre le temps de rponse pour retourner lensemble des lignes.

Il existe aussi des variantes lobjectif First_Rows, ce sont les objectifs First_Rows_n, o n est une des valeurs suivantes: 1,10, 100, 1000. Dans ce cas, loptimi-seur privilgie le temps de rponse permettant de retourner les n premires lignes.

Lobjectif de loptimiseur (Optimizer Goal) peut se dfinir diffrents niveaux:

celui de la configuration de linstance, travers le paramtre dinitialisation OPTIMIZER_MODE.

celui de la session utilisateur, en agissant sur le mme paramtre:

ALTER SESSION SET optimizer_mode = first_rows_10;

celui dune requte, en utilisant les hints que nous tudierons plus tard:

Select /*+FIRST_ROWS(10) */ * from commandes

Openmirrors.com


Axe 1

tude et optimisation dumodle de donnes

Cette partie aborde laspect conception des bases de donnes en replaant les bases de donnes relationnelles dans le contexte du modle relationnel.

Elle a pour but de vous rappeller quelques rgles, mais ne prtend nullement se subs-tituer des ouvrages traitant de la conception de bases de donnes tels que:

Cration de bases de donnes de Nicolas Larrousse (Pearson, 2006);

SQL de Frdric Brouard, Rudi Bruchez, Christian Soutou (Pearson, 2008, 2010) (les deux premiers chapitres traitent de la conception de bases de donnes).

Lapplication de mthodes de conception, telles que Merise, permettra davoir une dmarche de conception structure et contribuera obtenir un modle de donnes pertinent et sans cueils de performances majeurs.


Openmirrors.com


2

Modle relationnel

2.1 Prsentation

Les bases de donnes relationnelles que nous tudions sont fondes sur le modle relationnel invent par Edgar Frank Codd en 1970 (dcrit dans la publication ARela-tional Model of Data for Large Shared Data Banks) et largement adopt depuis.

Ce modle sappuie sur lorganisation des donnes dans des relations (aussi appeles "entits"), qui sont des tables deux dimensions:

Les colonnes. Ce sont les attributs qui caractrisent la relation.

Les lignes. Aussi nommes "tuples", elles contiennent les donnes.

Lordre des tuples na aucune importance ni signification.

Tableau2.1: Exemple d'une relation contenant des employs

Nom Prnom Service Localisation

DUPOND Marcel Comptabilit Toulouse

DURAND Jacques Production Agen

LEGRAND Denis Ventes Toulouse

MEUNIER Paul Production Agen

MEUNIER Paul Achats Agen

NEUVILLE Henry Ventes Toulouse


22 tude et optimisation dumodle de donnes Axe1

Le modle relationnel tablit quil doit tre possible didentifier un tuple de faon unique partir dun attribut ou dun ensemble dattributs, lesquels constituent la cl de la relation. Une cl est dite "naturelle" si un attribut ou un ensemble dattributs la constituent. Dans lexemple prcdent, on constate quil est dlicat den trouver une car se pose le problme des homonymes qui, dans le pire des cas, pourraient travailler dans le mme service. Lorsquune cl naturelle nexiste pas, on introduit un nouvel attribut identifiant qui en fera office. Il sagit, dans ce cas, dune cl technique. Cet identifiant peut tre un numro affect squentiellement. On recourt aussi lutilisation de cl technique quand la cl naturelle est trop grande ou pour des raisons techniques, par exemple des problmes de changement de valeur de la cl lorsquil y a des relations matre/dtails et que le SGBDR ne gre pas la mise jour en cascade.

Labsence de cl primaire dans une relation doit tre exceptionnelle (moins de 1% des tables). Lorsque rien ne sy oppose, il faut privilgier lutilisation de cl naturelle.

On peut parfois avoir plusieurs cls pour identifier un tuple (cest systmatique si vous ajoutez une cl technique alors quil y a une cl naturelle). Toutes ces cls sont dites "candidates" et celle qui a t retenue pour identifier la relation est dite "primaire".

Tableau2.2: Exemple d'une relation contenant des employs avec un identifiant

Identifiant Nom Prnom Service Localisation

5625 DUPOND Marcel Comptabilit Toulouse

8541 DURAND Jacques Production Agen

4521 LEGRAND Denis Ventes Toulouse

8562 MEUNIER Paul Production Agen

7852 MEUNIER Paul Achats Agen

6214 NEUVILLE Henry Ventes Toulouse

Un des grands intrts du modle relationnel est quil rpartit lensemble des donnes dans diffrentes relations et tablit des associations entre ces relations au moyen de leur cl primaire. Ce principe permet dviter la duplication dinformation et donc davoir des donnes plus consistantes (voir Tableaux 2.3 et 2.4).

Openmirrors.com


Chapitre2 Modle relationnel 23

Tableau2.3: Exemple d'une relation "Employ", contenant des employs, avec une association un service

IdEmploy Nom Prnom IdService

5625 DUPOND Marcel 100

8541 DURAND Jacques 120

4521 LEGRAND Denis 150

8562 MEUNIER Paul 120

7852 MEUNIER Paul 180

6214 NEUVILLE Henry 150

Tableau2.4: Exemple d'une relation "Service"

IdService NomService Localisation

100 Comptabilit Toulouse

120 Production Agen

150 Ventes Toulouse

180 Achats Agen

Le modle relationnel a t conu pour tre utilis avec une algbre relationnelle qui permet deffectuer des oprations sur les entits. Les principales sont:

La jointure. Relie deux entits par leur association.

La slection. Filtre les tuples dont les attributs rpondent un prdicat.

La projection. Slectionner seulement certains attributs dune entit.

Cette algbre a t implmente puis tendue dans les SGBDR au moyen du langage SQL. Nous nallons pas nous tendre sur la thorie de lalgbre relationnelle qui, mme si elle en constitue les bases, est par moments assez loigne de ce quon peut faire avec du SQL.

En termes de gnie logiciel, il est plutt question de modle conceptuel des donnes (MCD). Lorsque celui-ci est bas sur le modle relationnel, on parle alors de modle entit/association (et non pas de modle entit/relation, qui est une traduction erro-ne du terme anglais entity-relationship model). La mthode MERISE, qui a berc



des gnrations dinformaticiens, utilise gnralement ce modle pour reprsenter le MCD. Ainsi, en France, on dsigne souvent par MCD le modle entit/association. La mthode MERISE parle aussi de modle logique des donnes (MLD) qui est trs proche de limplmentation finale en base de donnes. Le MLD est une version indpendante du SGBDR du MPD (modle physique des donnes). Le MLD et le MPD sont souvent confondus, dautant plus quand la base reprsente nest prvue que pour tre implmente sur un SGBDR.

Le MCD et le MPD sont deux modles la fois redondants et complmentaires. Ils dcrivent tous deux une base de donnes, mais avec des niveaux de dtail et dabstraction diffrents. Le MCD se veut plus conceptuel, par exemple:

Il dsigne les entits par leur nom logique et non pas par le nom de la table.

Les associations sont nommes par un verbe.

Il peut contenir des associations entre les entits qui ne seront pas implmentes par la suite sous forme de cl trangre dans la base de donnes.

Il ne rpte pas les cls ncessaires aux associations et ne fait pas apparatre le fait quune table est ncessaire pour implmenter une relationM-N.

Le MCD se veut indpendant des bases de donnes, il utilise donc des types de donnes "universels". La plupart des outils de modlisation peuvent convertir automatiquement des MCD en MPD mais, gnralement, le rsultat ncessite dtre retouch. Si vous convertissez sans aucune prcaution un MCD en MPD, vous risquez davoir des tables qui sappellent "compose", par exemple, ou un autre

Figure2.1

Exemple de MCD(diagrammeentit-association).

Openmirrors.com



verbe qui a toute sa place dans un MCD mais qui est moins indiqu comme nom de table.

Figure2.2

Exemple de MPD (modle physique des donnes).

Le MPD est propre une base de donnes et permet de gnrer automatiquement les scripts de cration des tables. Il contient les noms des tables, lensemble des champs (qui sappelaient "attributs" dans le MCD) avec leurs types et prcisions, les contraintes dintgrit rfrentielle, les index, etc. Si votre base doit tre importante, prvoyez de passer un peu de temps pour affiner le MPD, laide, entre autres, de ce que nous allons tudier au cours de cet ouvrage.

Les partisans du MCD disent que cest une phase indispensable, alors que ses dtrac-teurs affirment quil ne sert rien. Personnellement, je pense que la vrit doit tre quelque part entre les deux. Cela dpend des habitudes de chaque organisation, de la taille de la base, des outils dont vous disposez et du niveau dabstraction souhait.

2.2 Les bons rflexes sur le typage des donnes

Le typage des donnes parat tre un sujet anodin mais il ne lest pas, et je suis sur-pris parfois de voir des bases de donnes avec des types incorrectement choisis. La conversion automatique du MCD en MPD peut tre une source de mauvais typage, car les types "universels" ne proposent pas forcment la finesse disponible avec le SGBDR.

Il y a principalement quatre familles de types de champs:

numriques;

textes;

dates et heures;

binaires.



Pour les donnes alphanumriques, il ny aura pas trop dambigut. Le nom dune personne devra tre mis dans un champ de type texte. Il existe gnralement trois variantes de types textes qui peuvent avoir des incidences sur le stockage et la mani-pulation des champs:

les types textes de longueur fixe (gnralement dsigns par char);

les types textes de longueur variable (gnralement dsigns par varchar);

les types textes de grande capacit (dsigns par text, bigtext ou CLOB).

Les champs de type texte de longueur fixe utilisent systmatiquement lespace cor-respondant la longueur pour laquelle ils sont dfinis (hormis sur certains SGBDR o le fait dtre NULL noccupe pas despace). Si la chane est plus petite que la longueur de la colonne, elle sera complte par des espaces qui seront ventuelle-ment supprims par le SGBDR ou par la couche daccs aux donnes. Ces champs sont assez peu utiliss mais ils peuvent prsenter un intrt sur des colonnes qui contiennent des valeurs de taille fixe. Lavantage de ce type est quil vite le sur-cot li la gestion dun champ de longueur variable. Par contre, sa manipulation provoque parfois des comportements droutants pour les dveloppeurs habitus aux types varchar.

Le type texte de longueur variable (varchar) est le plus utilis. Il noccupe que lespace ncessaire la donne plus quelques octets pour dfinir la longueur de celle-ci.

Les types textes de grande capacit sont rserver aux champs qui en ont vraiment besoin, cest--dire qui ont besoin de contenir plus de 4000caractres (cela dpend des bases). Il en dcoule parfois une gestion du stockage trs spcifique qui peut peser sur les performances et lespace utilis. De plus, certaines oprations sont parfois interdites sur ces types.

Tous ces types existent gnralement aussi en version Unicode. Cependant, avec la perce dUNICODE, certaines bases arrivent prsent grer le jeu de carac-tres UNICODE comme nimporte quel autre jeu de caractres, rendant lintrt des variantes UNICODE des types caractres moins vidents.

Concernant les donnes numriques, les SGBDR donnent plus ou moins de choix. Ilsera judicieux de se poser quelques questions sur la nature et ltendue des valeurs manipuler dans ces champs afin de choisir le type le plus appropri. Les principaux types numriques sont:

les types entiers signs ou non signs, sur 8, 16, 32 ou 64bits;

Openmirrors.com



les types dcimaux virgule flottante 32 ou 64bits;

les types dcimaux virgule fixe.

Chacun deux occupe plus ou moins despace. Il faut penser que les types virgule flottante font des approximations qui peuvent introduire des dcimales supplmen-taires ou en supprimer. Veillez garder de la cohrence avec le type des variables qui manipuleront les donnes dans votre application (si votre application gre un float, il ne faut pas que la base dfinisse un entier 64bits et vice versa).

Concernant les identifiants numriques, les types numriques ne sont pas toujours le bon choix. Pour les identifiants numriques squentiels, un type entier est un choix adquat (prendre un type dcimal ne serait pas pertinent). Par contre, pour des identifiants tels que des numros de Scurit sociale (1551064654123), ce nest pas forcment le meilleur choix, car:

Cest une valeur trop grande pour tenir sur un entier 32bits.

Les types flottants risquent de lapproximer.

Vous navez a priori aucune raison den faire la somme ou la moyenne.

Lordre alphabtique des identifiants est le mme que lordre numrique car il y a toujours 13chiffres.

Pour un tel identifiant, je conseille plutt lusage dun type texte de longueur fixe. La prsence de zros en tte didentifiant peut tre un autre problme: ils seront effacs si vous utilisez un type numrique. Par exemple, la valeur 000241 sera stocke, et donc restitue, sous la forme 241 si vous utilisez un type numrique au lieu dun type texte.

Concernant les donnes date et heure, il existe, suivant les SGBDR, des types per-mettant de stocker une date seule ou une date et une heure avec une prcision plus ou moins grande sur la rsolution, allant de quelques secondes des fractions de seconde. Jai vu assez rgulirement des dveloppeurs ne pas utiliser ces types pour stocker des dates mais prfrer des types textes. Largument avanc est que les types date et heure sont parfois pnibles manier aussi bien en SQL que dans les envi-ronnements de dveloppement. Je leur concde que cest souvent vrai. En effet, une date est plus difficile manipuler quun entier, mais ce nest cependant pas insurmontable. Il faut juste sy pencher une bonne fois pour toutes, se faire une feuille rcapitulative avec des exemples et, gnralement, aprs tout va bien. Reste nanmoins le problme des fonctions de transformations en SQL qui ne sont pas



portables dun SGBDR lautre. Si votre application doit fonctionner sur diffrents SGBDR, il faudra faire une petite couche dabstraction.

Cela montre que le type date complique parfois un peu les oprations, mais quap-porte-t-il par rapport un type texte? Si vous stockez dans la base avec une notation ISO (AAAAMMJJ), vous conservez la facult de trier chronologiquement et de travailler sur des intervalles. Par contre, si vous utilisez un format plus franais (ex: JJ/MM/AAAA), le tri et le filtrage par plage seront beaucoup plus compliqus. Bien videmment, le type date vous permettra deffectuer ce genre dopration et aussi des choses quaucun de ces modes de stockage textuel ne permet en SQL, comme soustraire des dates entre elles, ajouter ou soustraire des intervalles de temps. De plus, en termes despace requis pour le stockage des donnes, les types dates seront systmatiquement plus avantageux que leurs quivalents en format texte. Dernier avantage, avec les types dates, vous avez la garantie de navoir que des dates valides dans la base. Ce point est parfois considr comme un inconvnient: il peut arriver que des applications rcuprent des chanes contenant des dates errones, ce qui provoque des erreurs lors du chargement de la base de donnes. Par exprience, je sais quavoir des dates invalides dans les tables pose des problmes; il vaut donc mieux, le plus en amont possible, avoir des donnes valides.

Lutilisation dun entier pour stocker une date au format julien (nombre de jours depuis le 1er janvier 4713 av. J.-C.) allie la plupart des atouts du format date (ordre, intervalles, taille) mais prsente linconvnient de ne pas tre trs lisible (2524594 = 1/1/2000). Il nest pas support de faon native par tous les SGBDR et ne permet pas toujours de grer lheure. Lutilisation dun timestamp type unix prsente les mmes caractristiques.

Les SGBDR grent gnralement dautres types de donnes, tels que les types binaires permettant de manipuler des images, des sons ou des fichiers, des types XML permettant de stocker du XML et de faire des requtes dessus, et quelques autres types plus spcifiques chaque SGBDR.

2.2.1 Les types sous Oracle

Pour grer les valeurs numriques sous Oracle, on utilise gnralement le type NUMBER avec des prcisions variables suivant que lon souhaite un entier ou une grande valeur dcimale. Sous Oracle, la taille du stockage dpend de la valeur et non pas de la dfinition du champ. Ainsi, stocker la valeur1 prend moins de place que stocker la valeur 123456789,123. Le type NUMBER peut prendre deux paramtres:

Openmirrors.com



precision, qui correspond au nombre de chiffres significatifs maximal que les valeurs du champ pourront avoir. Il peut prendre une valeur entre1 et38, ce qui correspond aux chiffres de part et dautre du sparateur dcimal. Le symbole* est quivalent la valeur38.

scale, qui correspond au nombre de chiffres significatifs maximal aprs la vir-gule. Il vaut0 sil nest pas spcifi: cest alors un moyen de dfinir un type entier.

Le type FLOAT est un sous-type du type NUMBER et ne prsente pas un intrt parti-culier. Les types BINARY_FLOAT et BINARY_DOUBLE sont, eux, calqus sur les types flottants"C" et occupent respectivement 4et8octets. Les types ANSI (INT, INTEGER, SMALLINT) sont en fait des synonymes de NUMBER(38) qui reprsente un entier. DECIMAL est un synonyme de NUMBER.

Les types caractres disponibles sont:

CHAR et NCHAR pour les textes de tailles fixes limit 2000caractres (NCHAR est la version Unicode).

VARCHAR2 et NVARCHAR pour les textes de tailles variables limits 4000carac-tres. VARCHAR est un synonyme de VARCHAR2.

CLOB et NCLOB pour les textes de grande taille, limits 4Go. Ces types sont trai-ts comme un LOB (Large OBject). Les donnes sont stockes dans un segment spar, mais sil y en a peu pour un enregistrement et que le stockage en ligne est actif (voir Chapitre 5, section 5.3.1, "Gestion des LOB"), la donne pourra tre stocke comme un VARCHAR. Le type LONG, anctre des CLOB, est obsolte et ne doit plus tre utilis.

Les types dates disponibles sont:

DATE, qui permet de stocker date et heure avec une rsolution la seconde, occupe un espace de 7octets. Il nexiste pas de type date seule, on utilise donc le type date sans spcifier dheure, labsence dheure est traduite par minuit.

TIMESTAMP, qui permet de stocker date et heure avec une rsolution en fractions de seconde jusqu une nanoseconde.

TIMESTAMP WITH TIME ZONE est analogue TIMESTAMP mais stocke en plus la zone horaire.

Les types binaires disponibles sont:

RAW, pour les binaires de moins de 2000octets.



BLOB, pour les binaires de taille variable, limits 4Go. Concernant le stockage, il fonctionne comme les CLOB.

LONG RAW, anctre de BLOB, ne doit plus tre utilis.

BFILE est analogue BLOB si ce nest que les donnes sont stockes dans le systme de fichier du serveur gr par le systme dexploitation et non pas dans un tablespace.

2.2.2 Les types sous SQL Server

Les types numriques disponibles sont:

BIT, pour les boolens, stock sur 1bit;

TINYINT, pour les entiers non signs de 8bits;

SMALLINT, INT, BIGINT, pour les entiers signs de respectivement 16, 32 et 64bits;

DECIMAL et NUMERIC, pour les dcimaux virgule fixe, stocks sur 5 17octets suivant la prcision;

FLOAT, dcimaux virgule flottante, stock sur 4 8octets suivant la prcision, REAL = FLOAT(24).


CHAR et NCHAR, pour les textes de taille fixe limits 8000caractres;

VARCHAR et NVARCHAR, pour les textes de taille variable limits 8000caractres;

TEXT, NTEXT, VARCHAR(max) et NVARCHAR(max), pour les textes de grande taille limits 2Go.


DATE, qui permet de stocker une date seule (depuis SQL Server 2008);

SMALLDATETIME, qui permet de stocker date et heure avec une rsolution dune minute, stock sur 4octets;

DATETIME, qui permet de stocker date et heure avec une rsolution de trois quatre secondes, stock sur 8octets;

Openmirrors.com



DATETIME2, qui permet de stocker date et heure avec une rsolution en fractions de seconde jusqu 100nanosecondes, stock sur 6 8octets suivant la rso-lution (depuis SQL Server 2008);

TIME, qui permet de stocker une heure seule (depuis SQL Server 2008).


BINARY, pour les binaires de taille fixe de moins de 8000octets;

VARBINARY, pour les binaires de taille variable de moins de 8000octets;

IMAGE, pour les binaires jusqu 2Go, remplac par VARBINARY(max) (depuis SQL Server 2005).

2.2.3 Les types sous MySQL

Les types numriques disponibles sont:

BOOL, pour les boolens, stock sur 8bits.

TINYINT, pour les entiers non signs, stock sur 8bits.

SMALLINT, MEDIUMINT, INT, BIGINT, pour les entiers signs de respectivement 16, 24, 32 et 64bits. Il est possible dajouter le mot cl UNSIGNED pour manipuler des entiers non signs. INTEGER est un synonyme de INT.

DECIMAL et DEC, dcimaux virgule fixe ayant une prcision jusqu 65chiffres significatifs.

FLOAT, DOUBLE, dcimaux virgule flottante, stock sur 4 et 8octets.


CHAR, pour les textes de taille fixe limits 255caractres.

VARCHAR, pour les textes de taille variable limits 65535caractres.

TINYTEXT, TEXT, MEDIUMTEXT et LONGTEXT, pour les textes de taille variable limi-ts respectivement 255octets, 64Ko, 16Mo, 4Go. Le choix du type permet de fixer la taille du champ interne qui dfinit la taille de la donne.


DATE, qui permet de stocker une date seule;



DATETIME, qui permet de stocker date et heure avec une rsolution dune seconde, stock sur 8octets;

TIMESTAMP, qui permet de stocker date et heure avec une rsolution dune seconde sur une plage de 1970 2038, stock sur 4octets;

TIME, qui permet de stocker une heure seule.


TINYBLOB, BLOB, MEDIUMBLOB et LONGBLOB, pour les binaires de taille variable limits respectivement 255 octets, 64Ko, 16Mo, 4Go;

BINARY, pour les binaires de taille fixe de moins de 255 Octets;

VARBINARY, pour les binaires de taille variable de moins de 64Ko.

Openmirrors.com


3

Normalisation, base du modle relationnel

3.1 Normalisation

Le but de la normalisation est davoir un "bon" modle de donnes dans lequel les donnes seront bien organises et consistantes. Un des grands principes est que chaque donne ne doit tre prsente quune seule fois dans la base, sinon un risque dincohrence entre les instances de la donne apparat.

Figure3.1

Modle physique desdonnes (MPD) de la basede donnes initiale grepar une feuille de tableur.



La normalisation dun modle relationnel sappuie sur des rgles dfinies dans les diffrentes formes normales que nous allons tudier ci-aprs.

Nous allons mettre en pratique la normalisation en partant dune petite base de donnes qui a pour but de grer une librairie. Celle-ci, au fil du temps, est devenue une grande librairie et traite des centaines de commandes par jour. La "base de don-nes" initiale tait gre sous un tableur et nest donc pas du tout normalise (voir Figure 3.1).

3.1.1 Premire forme normale (1NF)

Pour qu'une entit soit en premire forme normale (1NF), elle doit:

avoir une cl primaire;

tre constitue de valeurs atomiques;

ne pas contenir d'attributs ou d'ensembles d'attributs qui soient des collections de valeurs.

Un attribut qui a des valeurs atomiques nest pas dcomposable en sous-attributs. Par exemple, un attribut NomPrenom nest pas considr comme atomique, puisquil peut tre dcompos en deux attributs: Nom et Prnom.

Ne pas contenir dattributs ou densembles dattributs qui soient des collections de valeurs signifie que:

Il ne doit pas y avoir dattributs qui contiennent, en fait, plusieurs valeurs spa-res par des caractres comme des espaces ou des virgules tels que "Dupond, Durand, Leclerc".

Il ne doit pas y avoir densembles dattributs qui soient en fait des listes de valeurs, tels que les attributs Article1, Article2, Article3, etc., de notre exemple.

De tels attributs doivent tre mis dans une entit spare qui aura une association de type1-N avec celle qui contenait ces attributs.

Mettons en pratique la premire forme normale sur notre base exemple. Nous allons crer une entit des lignes de commandes pour rsoudre le problme des collections sur les attributs (Livre, Titre, Quantit, Prix) et atomiser les attributs NomPrenom et Adresse. Cela donnera le rsultat suivant qui peut, raisonnablement, tre considr comme 1NF. Nous profitons de cette tape pour enrichir un peu notre modle en ajoutant lattribut ISBN.

Openmirrors.com


Chapitre3 Normalisation, base du modle relationnel 35

Figure3.2

Modle physiquedes donnes (MPD)en premire formenormale (1NF).

Il existe plusieurs notations graphiques des modles relationnels. Chaque outil choisit une des notations en prenant parfois des ides d'une autre notation.

Les diagrammes prsents ce chapitre sont des MPD sans affichage des types, raliss avec l'outil Toad Data Modeler, avec la notation IE qui utilise les conventions suivantes:

Ligne association pleine: association identifiant dpendante;

Ligne association discontinue: association non-identifiant dpendante;

L'extrmit rond plus triangle dsigne le ct fille de la relation;

Rectangle angles droits: table;

Rectangle angles arrondis: table fille d'une association identifiant dpendante.

3.1.2 Deuxime forme normale (2NF)

Pour qu'une entit soit en deuxime forme normale (2NF), il faut:

qu'elle soit en premire forme normale (1NF);

que tous les attributs ne faisant pas partie de ses cls dpendent des cls candidates compltes et non pas seulement d'une partie d'entre elles.

Cette forme ne peut poser de difficults quaux entits ayant des cls composites (composes de plusieurs attributs). Si toutes les cls candidates sont simples et que lentit est 1NF, alors lentit est 2NF. Attention, la rgle sapplique toutes les cls candidates et pas seulement la cl primaire.

la Figure3.2, lentit lignescommandes nest pas 2NF car la cl est NoCom-mande plus Livre. Or, les attributs Titre, Prix et ISBN ne dpendent que de lattri-but Livre, donc, seulement dune partie de la cl. Pour transformer ce modle en deuxime forme normale, nous allons crer une nouvelle entit qui contiendra les

INFO



informations relatives aux livres. Lapplication de cette forme normale permet de supprimer les inconsistances possibles entre les titres dun mme livre qui aurait t command plusieurs fois, car le modle prcdent permettait davoir des valeurs de Titre diffrentes pour une mme valeur de Livre.

Figure3.3

Modle physiquedes donnes (MPD)en deuxime formenormale (2NF).

3.1.3 Troisime forme normale (3NF)

Pour qu'une entit soit en troisime forme normale (3NF), il faut:

qu'elle soit en deuxime forme normale (2NF);

que tous les attributs ne faisant pas partie de ses cls dpendent directement des cls candidates.

la Figure3.3, lentit EnTeteCommandes nest pas en 3NF car toutes les infor-mations relatives au client ne sont pas dpendantes de la commande. Il faut intro-duire une nouvelle entit, qui contiendra les informations relatives aux clients.

Il devrait donc rester dans lentit EnTeteCommandes les attributs DateCommande et MontantCommande. Mais est-ce que lattribut MontantCommande dpend direc-tement de la cl? Apparemment oui, si on considre seulement lentit EnTeteCom-mandes. Par contre, si on considre aussi ses associations, alors on saperoit que cet attribut est en fait la somme des MontantLigne et ne dpend donc pas seulement de la cl mais de lentit LignesCommandes. Cest ce quon appelle un "attribut driv", cest une redondance dinformation. Pour tre en 3NF, il ne doit pas y avoir dattributs drivs, il faut donc supprimer lattribut MontantCommande. Les attri-buts calculs partir des colonnes de la mme entit sont eux aussi des attributs drivs et ne sont pas admis dans la troisime forme normale.

On pourrait faire la mme remarque pour lattribut MontantLigne de lentit Lignes-Commandes. Cependant, il y a un argument qui lautorise persister, cest que lat-tribut MontantLigne est gal Quantit Prix du livre au moment de la commande,

Openmirrors.com


Chapitre3 Normalisation, base du modle relationnel 37

or, lattribut Prix de lentit CatalogueLivre est le prix actuel du livre. Ce prix est susceptible de changer dans le temps, linformation de prix intgre dans lattribut MontantLigne nest donc pas la mme information que le Prix de lentit Cata-logueLivre. Ainsi, lattribut MontantLigne nest pas un attribut driv de lattribut Prix de lentit CatalogueLivre (voir Section 3.2.1).

Figure3.4

Modle physiquedes donnes (MPD)en troisime formenormale (3NF).

3.1.4 Forme normale de Boyce Codd (BCNF)

La forme normale de Boyce Codd est une version plus contraignante de la troisime forme normale.

Pour qu'une entit soit en forme normale de Boyce Codd (BCNF), il faut:

qu'elle soit en troisime forme normale (3NF);

que tous les attributs ne faisant pas partie de ses cls dpendent exclusivement des cls candidates.

la Figure3.4, lentit Clients nest pas en BCNF car lattribut Continent dpend certes du client, mais il dpend aussi de lattribut Pays. Pour tre conformes, nous devons crer une nouvelle entit permettant dassocier chaque Pays son Continent.

Figure3.5

Modle physiquedes donnes (MPD)en forme normale deBoyce Codd (BCNF).



3.1.5 Autres formes normales

Il existe dautres formes normales (quatrime, cinquime et sixime formes nor-males). Cependant, elles sont un peu plus spcifiques. Tendre vers une troisime forme normale ou une forme normale de Boyce Codd est dj un excellent objectif.

3.2 Dnormalisation et ses cas de mise en uvre

La normalisation est une bonne intention quil est plus que souhaitable dappliquer. Cependant, tout comme lenfer est pav de bonnes intentions, il faut savoir prendre un peu de recul par rapport aux rgles afin de ne pas tomber dans certains excs. Si la normalisation fournit de bons guides, je pense quil faut savoir les remettre en cause sil y a de bonnes raisons de le faire. Le plus important est de se poser les bonnes questions plutt que dappliquer aveuglment des rgles. Lobjet de cette section est de donner quelques rgles pour ne pas respecter celles de la normalisation.

Nous abordons ici la notion de dnormalisation. C'est--dire que nous allons tudier comment enfreindre certaines rgles sur un modle qui les applique.

Avant de dnormaliser un modle, il faut d'abord le normaliser.

3.2.1 La dnormalisation pour historisation

Cette premire forme de dnormalisation nen est pas vraiment une. Nous lavons dj aborde, lors de ltude de la troisime forme normale avec lattribut Montant-Ligne de lentit LignesCommandes.

Les formes normale

optimisation des bases de données

Documents