63141184 Ion Des Bases de Donnees Www Videos Formation

Optimisation des bases de

Rfrence

donnes

Mise en uvre sous OracleLaurent Navarro

Rseaux et tlcom Programmation Dveloppement web Scurit Systme dexploitation

Optimisation des bases de donnesMise en uvre sous OracleLaurent 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 France 47 bis, rue des Vinaigriers 75010 PARIS Tl. : 01 72 74 90 00 www.pearson.fr Mise en pages : TyPAO ISBN : 978-2-7440-4156-3 Copyright 2010 Pearson Education France Tous 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 matiresPrface ............................................................................................................................................... propos de lauteur ...................................................................................................................... Introduction ..................................................................................................................................... 1 Introduction aux SGBDR ................................................................................................... 1.1 1.2 Quest-ce quune base de donnes? ....................................................................IX

XI 1 5 5 6 7 7 10 10 11 12 13 14 15 15 16

1.1.1 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 1.2.61.3 1.4

Systme de gestion des bases de donnes ...................................... Organisation des donnes .................................................................. Le RowID ............................................................................................... Online Redo Log et Archived Redo Log ........................................ Organisation des tables ........................................................................ Row Migration et Row Chaining ...................................................... Le cache mmoire ................................................................................

Modle de stockage des donnes .........................................................................

Intrt des index dans les SGBDR ....................................................................... Analyse du comportement du SGBDR ...............................................................

1.4.1 1.4.2

Excution dune requte SQL............................................................ Optimiseur CBO (Cost Based Optimizer) ......................................Axe 1 tude et optimisation dumodle de donnes

2

Modle relationnel ................................................................................................................ 2.1 2.2 Prsentation .............................................................................................................. Les bons rflexes sur le typage des donnes ......................................................

21 21 25 28

2.2.1

Les types sous Oracle ..........................................................................

IV

Optimisation des bases de donnes

2.2.2 2.2.33

Les types sous SQL Server ................................................................. Les types sous MySQL........................................................................

30 31 33 33 34 35 36 37 38 38 38 40 42 43

Normalisation, base du modle relationnel ................................................................... 3.1 Normalisation ..........................................................................................................

3.1.1 3.1.2 3.1.3 3.1.4 3.1.53.2

Premire forme normale (1NF) ......................................................... Deuxime forme normale (2NF) ....................................................... Troisime forme normale (3NF) ....................................................... Forme normale de Boyce Codd (BCNF) ........................................ Autres formes normales ...................................................................... La dnormalisation pour historisation ............................................. La dnormalisation pour performance et simplification en environnement OLTP ..................................................................... La dnormalisation pour performance en environnement OLAP ....................................................................

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

3.2.1 3.2.2 3.2.33.3

Notre base de test ....................................................................................................

Axe 2 tude et optimisation desrequtes 4 Mthodes et outils de diagnostic ....................................................................................... 4.1 Approche pour optimiser ....................................................................................... 49 49 50 55 61 64 64 65 66 67 72 73

4.1.1 4.1.2 4.1.34.2

Mesurer.................................................................................................... Comprendre le plan dexcution ....................................................... Identifier les requtes qui posent des problmes........................... Compteurs de performance Windows .............................................. SQL Tuning Advisor (Oracle) ........................................................... SQL Access Advisor (Oracle)............................................................ SQL Trace (Oracle)............................................................................... Outils SQL Server................................................................................. Outils MySQL .......................................................................................

Outils complmentaires .........................................................................................

4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6

Table des matires

V

5

Techniques doptimisation standard au niveau base de donnes ............................ 5.1 Statistiques sur les donnes ...................................................................................

77 77 78 78 80 85 86 99 100 101 108 111 118 118 122 132 135 146 148 153 153 154 155 156 158 159 160 161 162 163 163 163 164 164

5.1.1 5.1.2 5.1.35.2

Ancienne mthode de collecte ........................................................... Nouvelle mthode de collecte............................................................ Slectivit, cardinalit, densit .......................................................... Index B*Tree.......................................................................................... Index sur fonction ................................................................................. Reverse Index......................................................................................... Index bitmap........................................................................................... Bitmap Join Index ................................................................................. Full Text Index ....................................................................................... Paramtres de table ............................................................................... Index Organized Table ........................................................................ Cluster ...................................................................................................... Partitionnement des donnes.............................................................. Les vues matrialises ......................................................................... Reconstruction des index et des tables ............................................

Utilisation des index ...............................................................................................

5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 5.2.65.3

Travail autour des tables ........................................................................................

5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 5.3.66

Techniques doptimisation standard des requtes ....................................................... 6.1 Rcriture des requtes ..........................................................................................

6.1.1 6.1.2 6.1.3 6.1.4 6.1.5 6.1.6 6.1.7 6.1.86.2

Transformation de requtes ................................................................ IN versus jointure.................................................................................. Sous-requtes versus anti-jointures .................................................. Exists versus Count .............................................................................. Exists versus IN ..................................................................................... Clause Exists * versus constante ....................................................... Expressions sous requtes .................................................................. Agrgats: Having versus Where ....................................................... Mlange des types ................................................................................ Fonctions et expressions sur index ................................................... Impact de loprateur sur les index ............................................ Rutilisation de vue ..............................................................................

Bonnes et mauvaises pratiques .............................................................................

6.2.1 6.2.2 6.2.3 6.2.4

VI


6.2.5 6.2.6 6.2.7 6.2.8 6.2.9 6.2.10 6.2.11 6.2.12 6.2.13 6.2.14 6.2.15 6.2.16 6.2.177

Utilisation de tables temporaires....................................................... Utilisation abusive de SELECT * ...................................................... Suppression des tris inutiles ............................................................... Utilisation raisonne des oprations ensemblistes ....................... Union versus Union ALL..................................................................... Count(*) versus count(colonne) ........................................................ Rduction du nombre de parcours des donnes ............................ LMD et cls trangres........................................................................ Suppression temporaire des index et des CIR ............................... Truncate versus Delete ........................................................................ Impacts des verrous et des transactions........................................... Optimisation du COMMIT ................................................................. DBLink et vues......................................................................................

165 165 166 166 169 170 171 172 173 173 173 175 176 177 177 179 179 180 181 182 183 183 185 186 186 188 189 191 192 194 195 196 198

Techniques doptimisation des requtes avances ....................................................... 7.1 Utilisation des hints sous Oracle ..........................................................................

7.1.1 7.1.2 7.1.3 7.1.4 7.1.5 7.1.67.2 7.3

Syntaxe gnrale ................................................................................... Les hints Optimizer Goal .................................................................... Les hints Access Path ........................................................................... Les hints Query Transformation ....................................................... Les hints de jointure ............................................................................. Autres hints............................................................................................. Les hints de paralllisme..................................................................... Les Grouping Sets................................................................................. Rollup Group By.................................................................................... Cube Group By ...................................................................................... Utilisation de WITH ............................................................................. Les fonctions de classement (ranking) ............................................ Autres fonctions analytiques .............................................................. Linstruction MERGE .......................................................................... Optimisation des updates multitables .............................................. Insertion en mode Direct Path ...........................................................

Excution parallle .................................................................................................

7.2.1 7.3.1 7.3.2 7.3.3 7.3.4 7.3.5 7.3.6 7.3.7 7.3.8 7.3.9

Utilisation du SQL avanc.....................................................................................

Table des matires

VII

7.4

PL/SQL .....................................................................................................................

198 198 200 203 208 209 210 212 212

7.4.1 7.4.2 7.4.3 7.4.4 7.4.5 7.4.6 7.4.7 7.4.8

Impact des triggers ............................................................................... Optimisation des curseurs (BULK COLLECT) ............................. Optimisation du LMD (FORALL) .................................................... SQL dynamique et BULK ................................................................... Traitement des exceptions avec FORALL....................................... Utilisation de cache de donnes ........................................................ Utilisation du profiling ........................................................................ Compilation du code PL/SQL ...........................................................

Axe 3 Autres pistes doptimisation 8 Optimisation applicative (hors SQL) ............................................................................. 8.1 8.2 8.3 8.4 8.5 8.6 9 Impact du rseau sur le modle client/serveur ................................................... Regroupement de certaines requtes ................................................................... Utilisation du binding............................................................................................. Utilisation de cache local lapplication ............................................................ Utilisation du SQL procdural .............................................................................. Gare aux excs de modularit ............................................................................... 217 217 217 219 221 221 221 223 223 223 224 224 224 225 225 226 227

Optimisation de linfrastructure ...................................................................................... 9.1 Optimisation de lexcution du SGBDR .............................................................

9.1.1 9.1.29.2

Ajustement de la mmoire utilisable................................................ Rpartition des fichiers ........................................................................ Le CPU .................................................................................................... La mmoire vive (RAM)..................................................................... Le sous-systme disque ....................................................................... Le rseau .................................................................................................

Optimisation matrielle..........................................................................................

9.2.1 9.2.2 9.2.3 9.2.4

Conclusion ........................................................................................................................................

VIII


Annexes A Gestion interne des enregistrements................................................................................ A.1 A.2 B Le RowID ................................................................................................................. Row Migration et Row Chaining ......................................................................... 231 231 232 235 235 236 240 241 245 249 251

Statistiques sur les donnes plus en dtail...................................................................... B.1 B.2 B.3 B.4 Statistiques selon lancienne mthode de collecte ............................................ Statistiques selon la nouvelle mthode de collecte ........................................... Histogrammes .......................................................................................................... Facteur de foisonnement (Clustering Factor) ....................................................

C D

Scripts de cration des tables de test bigemp et bigdept.............................................. Glossaire ..................................................................................................................................

Index ...................................................................................................................................................

PrfaceLoptimisation 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 larchitecture 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 dveloppeur 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 lauteurAdolescent, 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 loccasion 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 linformatique 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++, parfois en environnement contraint du point de vue des performances. Cest probablement 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.

IntroductionPourquoi 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 conception 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 dveloppeurs, 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


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 optimisations 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 livreCet 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 problmatiques 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. Le Chapitre4 prsente les mthodes et loutillage. Il traite des diffrents outils votre disposition pour analyser les situations et explique comment comprendre les rsultats.

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

Introduction

3

Le Chapitre 5 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. 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.

La troisime partie contient dautres axes doptimisations.

Ressources en ligneAfin 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.

RemerciementsMerci 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 particulirement 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.

1Introduction aux SGBDRPour 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 commencerons, 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 relationnelles avec, parfois, une extension objet. Cet ouvrage traite exclusivement de ce type de bases.

6


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 peuvent 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/serveur 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.21.2.1

Modle de stockage des donnesOrganisation 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 appels "tablespaces". Une base de donnes est constitue de plusieurs tablespaces, lesquels sont composs dun ou de plusieurs fichiers appels "datafiles". Ces fichiers peuvent se trouver sur des disques diffrents.tablespace TBS_COMPTA d:\OracleData\ DataFileCompta1.Ora d:\OracleData\ DataFileCompta2.Ora Tablespace Espace disque logique

Table Index Index Index Index Index

Table Index Index Index

Index Index Table

data les : Fichiers de donnes

Objets stocks dans le tablespace et repartis sur les data les

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 rpartis sur plusieurs datafiles (voir Figure 1.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, "Partitionnement 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 gnralement entre 2Ko et 16Ko et, par dfaut, est de 4 ou 8Ko suivant la plateforme

8


(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 "segment". Par exemple, pour une table classique, il y a un segment pour la table ellemme, 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 Dcomposition d'un segment en extents puis en blocs.8K o Segment 256 Ko

8K

o

8K

o

8 Ko 8 Ko 8 Ko 8 Ko 8 Ko 8 Ko 8 Ko 8 Ko

8 K Extent Initial o 128 Ko 8K o 8K 8K 8K 8 Ko 8 Ko 8 Ko 8 Ko o o o 8 Ko 8 Ko

8 K Extent o 64 Ko 8K o 8K 8K 8K 8 Ko 8 Ko o o o 8 Ko 8 Ko

8 K Extent o 64 Ko 8K o 8K 8K 8K 8 Ko 8 Ko o o o 8 Ko 8 Ko

Blocs de donnes (data block)

MS SQL ServerSous 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.

Chapitre1


9

MySQLSous 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 structures de contrle. La Figure 1.3 montre un schma complet de lorganisation du stockage des donnes.Figure1.3 Schma illustrant le stockage des donnes dans une base Oracle.Data le Tablespace Segments

Table

Extent Bloc de donnes Bloc de donnes Bloc de donnes Bloc de donnes Bloc de donnes Bloc de donnes Segment (Table) Initial-Extent Next-Extent Next-Extent Next-Extent

Bloc de donnes Entte de bloc Espace libre

Enregistrement

Enregistrement dcompos Taille Taille Taille En-tte Donne Donne Donne Donne Donne Donne

10


1.2.2

Le RowID

Le RowID (identifiant de ligne) est une information permettant dadresser directement 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 enregistrement 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.

Chapitre1


11

Leur gestion a un cot en termes despace disque utilis, donc si vous nen avez pas besoin, dsactivez cette fonction.MS SQL ServerLes fichiers LDF, qui sont les journaux de transactions, jouent un rle analogue aux Online Redo Log.

MySQLLe moteur InnoDB intgre un mcanisme analogue aux Online Redo Log. Le moteur MyISAM 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 ajoutes 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 suprieur 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 enregistrements sont stocks dans lordre de la cl primaire. On dit alors que la table est organise en index (IOT, Index Organized Table). Nous tudierons ce type de table au Chapitre5, section5.3.2, "Index Organized Table".

12


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

MySQLSous 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 donnes 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 enregistrement 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 rpartir 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 mcanisme va causer des E/S supplmentaires. Voir lAnnexeA, sectionA.2, pour plus dinformations sur ces mcanismes.

Chapitre1


13

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 importante, 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 dernires resteront plus longtemps dans le cache, alors que, gnralement, les grosses tables ny seront pas charges entirement.MS SQL ServerSous SQL Server, on retrouve un mcanisme tout fait similaire.

14


MySQLSous 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 denregistrements 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.

Chapitre1


15

Lintrt des index est donc indpendant du type dorganisation de table. Nous tudierons 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.41.4.1

Analyse du comportement du SGBDRExcution 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 informatiques, ne dcrit pas la faon de dterminer le rsultat mais quil permet dexprimer 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, section4.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.

16


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.INFO 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 prsents des fins de rtrocompatibilit (depuis la version10g, le RBO nest plus support). 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.MSSQLServeretMySQLSQL Server et MySQL tant eux aussi munis d'un optimiseur de type CBO, les grands principes 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 plusieurs plans dexcution possibles, et le CBO estime pour chacun deux le cot dexcution et choisit le moins lev.

Chapitre1


17

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, calculer 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, "Statistiques 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 All_Rows

(premires lignes);

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

18


Pourtant, la meilleure solution choisie pour cet objectif peut se rvler moins intressante 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, loptimiseur 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

Axe 1tude et optimisation dumodle de donnesCette 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 substituer 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.

2Modle relationnel2.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 ARelational 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 DUPOND DURAND LEGRAND MEUNIER MEUNIER NEUVILLE

Prnom Marcel Jacques Denis Paul Paul Henry

Service Comptabilit Production Ventes Production Achats Ventes

Localisation Toulouse Agen Toulouse Agen Agen 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 5625 8541 4521 8562 7852 6214



Service Comptabilit Production Ventes Production Achats Ventes

Localisation Toulouse Agen Toulouse Agen Agen 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).

Chapitre2

Modle relationnel

23

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

IdEmploy 5625 8541 4521 8562 7852 6214



IdService 100 120 150 120 180 150

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

IdService 100 120 150 180

NomService Comptabilit Production Ventes Achats

Localisation Toulouse Agen Toulouse 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 errone du terme anglais entity-relationship model). La mthode MERISE, qui a berc

24


Axe1

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.

Figure2.1 Exemple de MCD (diagramme entit-association).

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

Chapitre2

Modle relationnel

25

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 dtracteurs 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 surpris 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.

26


Axe1

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 manipulation 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 correspondant 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 ventuellement 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 surcot 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 caractres 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;

Chapitre2

Modle relationnel

27

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 supplmentaires 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 permettant 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 environnements 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

28


Axe1

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 quapporte-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:

Chapitre2

Modle relationnel

29

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 virgule. 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 particulier. 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). et NVARCHAR pour les textes de tailles variables limits 4000caractres. VARCHAR est un synonyme de VARCHAR2.

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. est analogue TIMESTAMP

TIMESTAMP WITH TIME ZONE

mais stocke en plus la

zone horaire. Les types binaires disponibles sont: RAW,

pour les binaires de moins de 2000octets.

30


Axe1

BLOB, pour les binaires de taille variable, limits 4Go. Concernant le stockage,

il fonctionne comme les CLOB. LONG RAW, BFILE

anctre de BLOB, ne doit plus tre utilis.

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.Les types sous SQL Server

2.2.2

Les types numriques disponibles sont: BIT,

pour les boolens, stock sur 1bit; pour les entiers non signs de 8bits;

TINYINT,

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

et NUMERIC, pour les dcimaux virgule fixe, stocks sur 5 17octets suivant la prcision; dcimaux virgule flottante, stock sur 4 8octets suivant la prcision, = FLOAT(24).

Les types caractres disponibles sont: CHAR

et NCHAR, pour les textes de taille fixe limits 8000caractres; etNVARCHAR(max),

VARCHAR et NVARCHAR, pour les textes de taille variable limits 8000caractres; TEXT, NTEXT, VARCHAR(max)

pour les textes de grande taille

limits 2Go. Les types dates disponibles sont: DATE,

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

SMALLDATETIME, DATETIME,

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

Chapitre2

Modle relationnel

31

DATETIME2,

qui permet de stocker date et heure avec une rsolution en fractions de seconde jusqu 100nanosecondes, stock sur 6 8octets suivant la rsolution (depuis SQL Server 2008); qui permet de stocker une heure seule (depuis SQL Server 2008). pour les binaires de taille fixe de moins de 8000octets; pour les binaires de taille variable de moins de 8000octets;VARBINARY(max)

TIME,

Les types binaires disponibles sont: BINARY, VARBINARY, IMAGE,

pour les binaires jusqu 2 Go, remplac par SQL Server 2005).Les types sous MySQL

(depuis

2.2.3

Les types numriques disponibles sont: BOOL,

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

TINYINT,

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. dcimaux virgule flottante, stock sur 4 et 8octets.

FLOAT, DOUBLE,

Les types caractres disponibles sont: CHAR,

pour les textes de taille fixe limits 255caractres. pour les textes de taille variable limits 65535caractres.

VARCHAR,

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. Les types dates disponibles sont: DATE,

qui permet de stocker une date seule;

32


Axe1

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.

Les types binaires disponibles sont: TINYBLOB, BLOB, MEDIUMBLOB BINARY,

et LONGBLOB, pour les binaires de taille variable limits respectivement 255 octets, 64Ko, 16Mo, 4Go; pour les binaires de taille fixe de moins de 255 Octets; pour les binaires de taille variable de moins de 64Ko.

VARBINARY,

3Normalisation, base du modle relationnel3.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 des donnes (MPD) de la base de donnes initiale gre par une feuille de tableur.

34


Axe1

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 donnes" 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 spares 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.

Chapitre3

Normalisation, base du modle relationnel

35

Figure3.2 Modle physique des donnes (MPD) en premire forme normale (1NF).

INFO 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 NoCommande plus Livre. Or, les attributs Titre, Prix et ISBN ne dpendent que de lattribut 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

36


Axe1

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 physique des donnes (MPD) en deuxime forme normale (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 informations relatives au client ne sont pas dpendantes de la commande. Il faut introduire 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 directement de la cl? Apparemment oui, si on considre seulement lentit EnTeteCommandes. 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 attributs 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 LignesCommandes. Cependant, il y a un argument qui lautorise persister, cest que lattribut MontantLigne est gal Quantit Prix du livre au moment de la commande,

Chapitre3


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 CatalogueLivre. Ainsi, lattribut MontantLigne nest pas un attribut driv de lattribut Prix de lentit CatalogueLivre (voir Section 3.2.1).Figure3.4 Modle physique des donnes (MPD) en troisime forme normale (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 physique des donnes (MPD) en forme normale de Boyce Codd (BCNF).

38


Axe1

3.1.5

Autres formes normales

Il existe dautres formes normales (quatrime, cinquime et sixime formes normales). 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.ATTENTION 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 MontantLigne de lentit LignesCommandes. Les formes normales ont pour objectif dviter la redondance de linformation. Si on conoit le modle avec une vision statique, on risque de passer ct du fait que certaines valeurs vont voluer dans le temps et quil ne sera plus possible de retrouver aprs coup la valeur historique. Le prix courant dun article et le prix de ce mme article il y a six mois ne sont pas forcment les mmes. Comme nous lavons dj vu, il sagit de donnes distinctes. Mme si, certains instants, les valeurs sont identiques, elles nont pas le mme cycle de vie. La mthode la plus commune pour grer lhistorique dune valeur consiste recopier linformation dans lentit qui lutilise. Une autre manire possible, et plus

Chapitre3


39

conforme la logique des formes normales, pour grer ce besoin est de conserver lhistorique de la donne rfrence dans une entit spare et horodate plutt que de rpter la donne chaque instance la rfrenant. Si nous reprenons lexemple du prix qui varie dans le temps, la premire mthode possible consiste recopier le prix dans chaque ligne de commande (voir diagramme de gauche la Figure3.6). On peut aussi crer une entit contenant lhistorique du prix du livre. Ainsi, la donne prix nest pas rpte et on pourra tout moment la retrouver partir de la date de la commande (voir diagramme de droite).

Figure3.6 Deux solutions possibles pour implmenter une gestion des commandes avec un historique des prix.

Dans le cas prsent, mon cur balancerait plutt pour la premire solution ( gauche) car je sais quen termes dimplmentation la seconde solution ( droite) sera plus complique. En effet, quand vous aurez besoin de connatre le prix dune ligne de commande, vous devrez rechercher lenregistrement dhistorique le plus rcent qui a une date antrieure la date de la commande. Cette requte-l nest dj pas trs simple. Si on lajoute au fait quon souhaite calculer le montant total des commandes dun client pour une anne, a devient alors complexe et peu performant avec la seconde solution. La premire solution permet de rpondre cette requte de faon assez intuitive et efficace. Dans dautres contextes, la seconde solution pourrait prsenter plus davantages que la premire. Par exemple, si vous avez de nombreux attributs garder en historique, quils soient volumineux (grands textes descriptifs, photos, etc.) et voluent peu au regard des commandes. La seconde solution permet aussi de connatre les variations de prix dun produit mme si celui-ci na pas t command entre les deux variations. Comme toujours, il faut peser le pour et le contre de chaque solution plutt que chercher forcment la solution mathmatiquement la plus juste.

40


Axe1

Certains disent quil ne faut pas dnormaliser pour arranger le dveloppeur et quil faut toujours choisir la solution la plus propre sous peine de se traner des "casseroles" pendant des annes. Cest gnralement vrai, cependant, comme le montre lexemple prcdent, lapplication trop stricte de certaines rgles peut conduire complexifier une application et avoir des impacts substantiels sur les performances. Limportant est de se poser les bonnes questions et de faire vos choix en toute honntet intellectuelle.3.2.2 La dnormalisation pour performance et simplification en environnement OLTP

La normalisation a pour but, entre autres, dviter la duplication de linformation afin de renforcer la consistance des donnes. Cela peut avoir pour effet de nuire aux performances. Comme nous lavons vu, le modle de droite de la Figure3.6 nest pas adapt pour retrouver aisment lensemble des prix des lignes dune commande. Ainsi, lorsque vous avez besoin dafficher sur une facture le montant total de la commande, il faut faire une requte complique. Imaginons un instant quil y ait une politique, variable pour chaque article, de remises de prix en fonction de la quantit commande. Lajout dun champ MontantRemise pourrait tre considr comme un non-respect des formes normales car il drive des attributs Quantit et CodeArticle. Cependant, je pense que, lorsquun attribut est une valeur qui est drive de faon complexe, on peut raisonnablement ne pas respecter la lettre la troisime forme normale. Abordons prsent le cas des attributs drivs simples mais qui rendent service tels que MontantLigne qui est gal QuantitPrix MontantRemise. On ne peut pas dire que cela soit trs compliqu calculer, du coup ajouter cet attribut nest qu moiti raisonnable. Une solution possible, et mon avis fidle lesprit des formes normales, est dajouter une colonne virtuelle (ou calcule suivant le SGBDR), laquelle contient le calcul et est maintenue par le SGBDR. Ainsi, il est sr que cette information est consistante avec les informations dont elle drive. La limite de ce type de champ est quil ne peut faire des calculs que sur les champs dune mme table. Regardons maintenant un autre cas dattributs drivs simples, des drivs par agrgation, tels que lattribut MontantCommande qui est la somme des MontantLignes la Figure3.3. Sa prsence ne respecte pas la troisime forme normale,

Chapitre3


41

mais elle peut tre trs pratique pour calculer des indicateurs de chiffres daffaires (CA) en temps rel. En plus dtre pratique, cela sera plus performant que de faire la somme des lignes de chaque commande. Cependant, il faudra maintenir cette valeur, donc faire rgulirement une requte qui recalcule la somme de MontantLignes pour mettre jour lattribut MontantCommande. Cela peut tre acceptable pour le cas de MontantCommande, mais il ne faut pas trop driver, sinon il y a un risque de devoir calculer trop de donnes agrges chaque modification dune donne. En effet, afin de garantir la consistance de ces donnes, chaque fois que vous modifiez un enregistrement de LignesCommandes, vous devez recalculer les valeurs qui en drivent. Par exemple, si vous navez pas t raisonnable, vous pourriez devoir calculer toutes les valeurs suivantes: CA par jour, CA par mois, CA par jour par Livre, CA par mois par Livre, CA par client par an, CA par mois par pays, CA par mois par continent, etc. Vous risquez donc, si vous abusez de la dnormalisation, de plomber srieusement vos performances lors des mises jour des donnes de votre base, alors que votre objectif tait damliorer les performances de votre systme. Lutilisation de vues matrialises que nous tudierons au Chapitre5, section5.3.5, "Les vues matrialises", permet de maintenir ce genre de donnes de faon consistante et relativement performante car les calculs sur ces objets sont faits par variations et non pas par le recalcul complet des totaux (solution qui pourrait tre extrmement coteuse).INFO Sur la plupart des SGBDR, vous pouvez implmenter des champs calculs l'aide de dclencheurs (triggers). Certains SGBDR proposent aussi le concept de colonnes calcules qui sont, contrairement aux dclencheurs, limites des calculs portant sur la table courante. Sous SQL Server, vous disposez des colonnes calcules persistantes (stockes) ou non persistantes (recalcules la vole) en utilisant la syntaxe suivante dans l'instruction CREATE TABLE. ColCalculee as ColonneA+ColonneB PERSISTED Sous Oracle, depuis la version11g, vous pouvez utiliser les colonnes virtuelles, qui ne sont pa

63141184 Ion Des Bases de Donnees Www Videos Formation

Documents

Transcript of 63141184 Ion Des Bases de Donnees Www Videos Formation