Index: trunk/workshop-foss4g/indexing.rst
===================================================================
--- trunk/workshop-foss4g/indexing.rst	(revision 40)
+++ trunk/workshop-foss4g/indexing.rst	(revision 47)
@@ -4,7 +4,7 @@
 =================================
 
-Rapellez-vous que les indexes spatiaux sont l'une des trois fonctionnalitÃ©s clÃ©s d'une base de donnÃ©es spatiales. Les indexes rendent possible l'utilisation de grandes quantitÃ©s de donnÃ©es dans une base. Sans indexation, chaque recherche d'une entitÃ© nÃ©cessitera d'accÃ©der sÃ©quentiellement Ã  tout les enregistrement de la base de donnÃ©es. L'indexation rend plus rapide les recherche en organisant les donnÃ©es dans des arbres de recherche qui peuvent Ãªtre parcouru efficacement pour retrouver une entitÃ© particuliÃšre.
+Rapellez-vous que l'indexation spatiale est l'une des trois fonctionnalitÃ©s clÃ©s d'une base de donnÃ©es spatiales. Les indexes permettent l'utilisation de grandes quantitÃ©s de donnÃ©es dans une base. Sans l'indexation, chaque recherche d'entitÃ© nÃ©cessitera d'accÃ©der sÃ©quentiellement Ã  tout les enregistrements de la base de donnÃ©es. L'indexation accÃ©lÃšres les recherche en organisant les donnÃ©es dans des arbres de recherche qui peuvent Ãªtre parcouru efficacement pour retrouver une entitÃ© particuliÃšre.
 
-Les indexes spatiaux sont l'un des plus grands atouts de PostGIS. Dans les exemples prÃ©cÃ©dents, nous construissions nos jointures spatiales en comparant la totalitÃ© des tables. Ceci peut s'averrer trÃšs coÃ»teux : rÃ©aliser la jointure de deux tables de 10000 enregistrements sans index nÃ©cessitera de comparer 100000000 valeurs, avec les indexes les comparaisons requises seront 20000.
+L'indexation spatiale l'un des plus grands atouts de PostGIS. Dans les exemples prÃ©cÃ©dents, nous avons construit nos jointures spatiales en comparant la totalitÃ© des tables. Ceci peut parfois s'averrer trÃšs coÃ»teux : RÃ©aliser la jointure de deux tables de 10000 enregistrements sans indexation nÃ©cessitera de comparer 100000000 valeurs, les comparaisons requises ne seront plus que 20000 avec l'indexation.
 
 Lorsque nous avons chargÃ© la table  ``nyc_census_blocks``, l'outils pgShapeLoader crÃ©e automatiquement un indexe spatial appelÃ© ``nyc_census_blocks_the_geom_gist``.
@@ -12,5 +12,5 @@
 Pour dÃ©montrer combien il est important d'indexer ses donnÃ©es pour la performance des requÃªtes, essayons de requÃªter notre table ``nyc_census_blocks`` **sans** utiliser notre indexe.
 
-La premiÃšre Ã©tapt consiste a supprimer l'index.
+La premiÃšre Ã©tape consiste Ã  supprimer l'index.
 
 .. code-block:: sql
@@ -22,5 +22,5 @@
    La commande ``DROP INDEX`` supprime un index existant de la base de donnÃ©es. Pour de plus amples informations Ã  ce sujet, consultez la `documentation officielle de PostgreSQL <http://docs.postgresql.fr/9.1/sql-dropindex.html>`_.
    
-Maintenant, regardons le temps d'exÃ©cution dans le coin en bas Ã  droite de l'interface de requÃªtage de pgAdmin et lanÃ§ons la commande suivante. Notre requÃªte recherche les blocs de la rue Broad.
+Maintenant, regardons le temps d'exÃ©cution dans le coin en bas Ã  droite de l'interface de requÃªtage de pgAdmin, puis lanÃ§ons la commande suivante. Notre requÃªte recherche les blocs de la rue Broad.
 
 .. code-block:: sql
@@ -40,5 +40,5 @@
 La table ``nyc_census_blocks`` est trÃšs petite (seulement quelque millier d'enregistrements) donc mÃªme sans l'index, la requÃªte prends **55 ms** sur l'ordinateur de test.
 
-Maintenant remettons en place l'indexe et lanÃ§ons de nouveau la requÃªte.
+Maintenant remettons en place l'index et lanÃ§ons de nouveau la requÃªte.
 
 .. code-block:: sql
@@ -46,5 +46,5 @@
   CREATE INDEX nyc_census_blocks_the_geom_gist ON nyc_census_blocks USING GIST (the_geom);
 
-.. note:: l'utilisation de la clause ``USING GIST`` spÃ©cifie Ã  PostgreSQL de crÃ©er une structure (GIST) pour cet indexe. Si vous recevez un message d'erreur ressemblant Ã  ``ERROR: index row requires 11340 bytes, maximum size is 8191`` lors de la crÃ©ation, cela signifie sans doute que vous avez omis la clause ``USING GIST``.
+.. note:: l'utilisation de la clause ``USING GIST`` spÃ©cifie Ã  PostgreSQL de crÃ©er une structure (GIST) pour cet index. Si vous recevez un message d'erreur ressemblant Ã  ``ERROR: index row requires 11340 bytes, maximum size is 8191`` lors de la crÃ©ation, cela signifie sans doute que vous avez omis la clause ``USING GIST``.
 
 Sur l'rdinateur de test le temps d'exÃ©cution se rÃ©duit Ã  **9 ms**. Plus votre table est grande, plus la diffÃ©rence de temps d'exÃ©cution pour une requÃªte utilisant les indexes augmentera.
@@ -53,5 +53,5 @@
 -----------------------------------------
 
-Les indexes des base de donnÃ©es standards crÃ©e un arbre hierarchique basÃ© sur les valeurs de la colonne Ã  indexer. Les indexes spatiaux sont un peu diffÃ©rents - ils ne sont pas capables d'indexer des entitÃ©s gÃ©omÃ©triques elles-mÃªme mais indexe leur Ã©tendues.
+Les indexes des base de donnÃ©es standards crÃ©ent des arbres hierarchiques basÃ©s sur les valeurs des colonnes Ã  indexer. Les indexes spatiaux sont un peu diffÃ©rents - ils ne sont pas capables d'indexer des entitÃ©s gÃ©omÃ©triques elles-mÃªme mais indexe leur Ã©tendues.
 
 .. image:: ./indexing/bbox.png
@@ -59,5 +59,5 @@
 Dans la figure ci-dessus, le nombre de lignes qui intersectent l'Ã©toile jaune est *unique*, la ligne rouge. Mais l'Ã©tendue des entitÃ©s qui intersectent la boÃ®te jaune sont *deux*, la boÃ®te rouge et la boÃ®te bleue.
 
-La maniÃšre dont les bases de donnÃ©es rÃ©pondent de maniÃšre efficaces Ã  la questions "quelle ligne intersectent l'Ã©toile jaune ?" correspond Ã  d'abort rÃ©pondre Ã  question ; "quelle Ã©tendue intersecte l'Ã©tendue jaune" en utilisant les indexes (ce qui est trÃšs rapide) puis rÃ©alise le calcul exacte de "quelles lignes intersectent l'Ã©toile jaune" **seulement en utilisant les entitÃ©s retournÃ© par le premier test**.
+La maniÃšre dont les bases de donnÃ©es rÃ©pondent de maniÃšre efficace Ã  la question "Quelles lignes intersectent l'Ã©toile jaune ?" correspond premiÃšrement Ã  rÃ©pondre Ã  la question "Quelle Ã©tendue intersecte l'Ã©tendue jaune" en utilisant les indexes (ce qui est trÃšs rapide) puis Ã  calculer le rÃ©sultat exact de la question "Quelles lignes intersectent l'Ã©toile jaune ?" **seulement en utilisant les entitÃ©s retournÃ© par le premier test**.
 
 Pour de grandes tables, il y a un systÃšme en "deux Ã©tapes" d'Ã©valuation en utilisant dans un premier temps l'approximation Ã  l'aide d'indexes, puis en rÃ©alisant le test exact sur une quantitÃ© bien moins importante de donnÃ©es ce qui rÃ©duit drastiquement le temps de calcul nÃ©cessaire Ã  cette deuxiÃšme Ã©tape.
@@ -74,5 +74,5 @@
 Pour utiliser une recherche par Ã©tendue utilisant les indexes (et pas de filtres), vous pouvez utiliser l'opÃ©rateur :command:`&&`. Pour les gÃ©omÃ©tries, l'opÃ©rateur :command:`&&` signifie "l'Ã©tendue recouvre ou touche" de la mÃªme maniÃšre que l'opÃ©rateur :command:`=` sur des entiers signifie que les valeurs sont Ã©gales.
 
-Essayons de comparer une requÃªte avec seulement un indexe pour la population du quartier 'West Village'. En utilisant la commande :command:`&&` notre requÃªte ressemble Ã  ce qui suit :
+Essayons de comparer une requÃªte avec seulement un indexe pour la population du quartier 'West Village'. En utilisant la commande :command:`&&` notre requÃªte ressemble Ã  cela :
 
 .. code-block:: sql
@@ -102,5 +102,5 @@
   27141
 
-Un plus faible nombre de rÃ©sultats ! La premiÃšre requÃªte nous renvoit tout les bloqcs qui intersectent l'Ã©tendue du quartier, la seconde nous renvoit seulement les blocs qui intersectent le quartier lui-mÃªme.
+Un plus faible nombre de rÃ©sultats ! La premiÃšre requÃªte nous renvoit tout les blocs qui intersectent l'Ã©tendue du quartier, la seconde nous renvoit seulement les blocs qui intersectent le quartier lui-mÃªme.
 
 Analyse
@@ -126,7 +126,7 @@
 Le nettoyage des donnÃ©es est tellement important pour une utilisation efficace du serveur de base de donnÃ©es PostgreSQL qu'il existe maintenant une option "autovacuum".
 
-ActivÃ©e par dÃ©faut, le processus autovacuum Ã  la fois nettoit (rÃ©cupÃšre l'espace libre) et analyse (met Ã  jour les statistiques) de vos tables suivant un interval donnÃ©e dÃ©terminÃ© par l'activitÃ© des bases de donnÃ©es. Bien que cela soit pour les bases de donnÃ©es hautement transactionnelles, il n'est pas supportable de devoir attendre que le processus autovacuum se lance lors de la mise Ã  jour ou la suppression massive de donnÃ©es. Dans ce cas, il faut lancer la commande ``VACUUM`` manuellement.
+ActivÃ©e par dÃ©faut, le processus autovacuum nettoie (rÃ©cupÃšre l'espace libre) et analyse (met Ã  jour les statistiques) vos tables suivant un interval donnÃ© dÃ©terminÃ© par l'activitÃ© des bases de donnÃ©es. Bien que cela fonctionne avec les bases de donnÃ©es hautement transactionnelles, il n'est pas supportable de devoir attendre que le processus autovacuum se lance lors de la mise Ã  jour ou la suppression massive de donnÃ©es. Dans ce cas, il faut lancer la commande ``VACUUM`` manuellement.
 
-Le nettoyage et l'analyse de la base de donnÃ©es peut Ãªtre rÃ©alisÃ© sÃ©parÃ©ment si nÃ©cessaire. Utiliser la commande ``VACUUM`` ne mettra pas Ã  jour les statistiques alors que lancer la commande ``ANALYZE`` ne rÃ©cupÃšrera pas l'espace libre des lignes d'une table. Chacune de ces commandes peut Ãªtre lancÃ© sur l'intÃ©gralitÃ© de la base de donnÃ©es, sur une table ou sur une seule colonne.
+Le nettoyage et l'analyse de la base de donnÃ©es peut Ãªtre rÃ©alisÃ© sÃ©parÃ©ment si nÃ©cessaire. Utiliser la commande ``VACUUM`` ne mettra pas Ã  jour les statistiques alors que lancer la commande ``ANALYZE`` ne rÃ©cupÃšrera pas l'espace libre des lignes d'une table. Chacune de ces commandes peut Ãªtre lancÃ©e sur l'intÃ©gralitÃ© de la base de donnÃ©es, sur une table ou sur une seule colonne.
 
 .. code-block:: sql
