Correction orthographique du tutoriel.

postgresql/advanced.xml

@@ -38,7 +38,7 @@
   <para>
    Se référer aux requêtes de la <xref linkend="tutorial-join"/>. Si la liste
    des enregistrements du temps et des villes est d'un intérêt particulier
-   pour l'application considérée mais qu'il devient contraignant de saisir la
+   pour l'application considérée, mais qu'il devient contraignant de saisir la
    requête à chaque utilisation, il est possible de créer une
    <firstterm>vue</firstterm> avec la requête. De ce fait, la requête est
    nommée et il peut y être fait référence de la même façon qu'il est fait
@@ -81,7 +81,7 @@ SELECT * FROM ma_vue;</programlisting>
    </indexterm>
 
    <para>
-    Soient les tables <classname>temps</classname> et
+    Soit les tables <classname>temps</classname> et
     <classname>villes</classname> définies dans le <xref
     linkend="tutorial-sql"/>. Il s'agit maintenant de s'assurer que personne
     n'insère de ligne dans la table <classname>temps</classname> qui ne
@@ -141,7 +141,7 @@ DETAIL : Key (ville)=(a) is not present in table "villes".</screen>
    <para>
     Les <firstterm>transactions</firstterm> sont un concept fondamental de tous
     les systèmes de bases de données. Une transaction assemble plusieurs étapes
-    en une seule opération tout-ou-rien. Les états intermédiaires entre les
+    en une seule opération tout ou rien. Les états intermédiaires entre les
     étapes ne sont pas visibles par les transactions concurrentes. De plus, si
     un échec survient qui empêche le succès de la transaction, alors aucune des
     étapes n'affecte la base de données.
@@ -150,7 +150,7 @@ DETAIL : Key (ville)=(a) is not present in table "villes".</screen>
    <para>
     Si l'on considère, par exemple, la base de données d'une banque qui
     contient le solde de différents comptes clients et le solde total des
-    dépôts par branches et que l'on veuille enregistrer un virement de 100
+    dépôts par branches et que l'on veut enregistrer un virement de 100
     euros du compte d'Alice vers celui de Bob, les commandes SQL peuvent
     ressembler à cela (après simplification)&nbsp;:
 
@@ -201,11 +201,11 @@ UPDATE branches SET balance = balance + 100.00
     autres. Ainsi, si une transaction calcule le total de toutes les branches,
     inclure le débit de la branche d'Alice sans le crédit de la branche de Bob,
     ou vice-versa, est une véritable erreur. Les transactions doivent donc être
-    tout-ou-rien, non seulement pour leur effet persistant sur la base de
+    tout ou rien, non seulement pour leur effet persistant sur la base de
     données, mais aussi pour leur visibilité au moment de leur exécution. Les
     mises à jour faites jusque-là par une transaction ouverte sont invisibles
     aux autres transactions jusqu'à la fin de celle-ci. À ce moment, toutes les
-    mises à jours deviennent simultanément visibles.
+    mises à jour deviennent simultanément visibles.
    </para>
 
    <para>
@@ -259,15 +259,15 @@ COMMIT;</programlisting>
     peuvent, au besoin, être annulées avec <command>ROLLBACK TO</command>.
     Toutes les modifications de la base de données effectuées par la
     transaction entre le moment où le point de retournement a été défini et
-    celui où l'annulation est demandée sont annulées mais les modifications
+    celui où l'annulation est demandée sont annulées, mais les modifications
     antérieures à ce point sont conservées.
    </para>
 
    <para>
     Le retour à un point de retournement ne l'annule pas. Il reste défini et
     peut donc être utilisé plusieurs fois. À l'inverse, lorsqu'il n'est plus
     nécessaire de revenir à un point de retournement particulier, il peut être
-    relâché, ce qui permet de libérer des ressources systèmes. Il faut savoir
+    relâché, ce qui permet de libérer des ressources système. Il faut savoir
     toutefois que relâcher un point de retournement ou y revenir relâche tous
     les points de retournement qui ont été définis après.
    </para>
@@ -301,7 +301,7 @@ COMMIT;</programlisting>
    </para>
 
    <para>
-    Cet exemple est bien sûr très simplifié mais de nombreux contrôles sont
+    Cet exemple est bien sûr très simplifié, mais de nombreux contrôles sont
     réalisables au sein d'un bloc de transaction grâce à l'utilisation des
     points de retournement. Qui plus est, <command>ROLLBACK TO</command> est le
     seul moyen de regagner le contrôle d'un bloc de transaction placé dans un
@@ -520,7 +520,7 @@ SELECT salaire, sum(salaire) OVER (ORDER BY salaire) FROM salaireemp;
   <para>
    Les fonctions window ne sont autorisées que dans la liste
    <literal>SELECT</literal> et la clause <literal>ORDER BY</literal> de la
-   requête. Elles sont interdites ailleurs, comme par exemple dans les clauses
+   requête. Elles sont interdites ailleurs, comme  dans les clauses
    <literal>GROUP BY</literal>,<literal>HAVING</literal> et
    <literal>WHERE</literal>. La raison en est qu'elles sont exécutées après le
    traitement de ces clauses. Par ailleurs, les fonctions de fenêtrage
@@ -588,7 +588,7 @@ SELECT sum(salaire) OVER w, avg(salaire) OVER w
   </para>
 
   <para>
-   Soient deux tables&nbsp;: une table <classname>villes</classname> et une
+   Soit deux tables&nbsp;: une table <classname>villes</classname> et une
    table <classname>capitales</classname>. Les capitales étant également des
    villes, il est intéressant d'avoir la possibilité d'afficher implicitement
    les capitales lorsque les villes sont listées. Un utilisateur
@@ -705,7 +705,7 @@ CREATE TABLE capitales (
     <productname>PostgreSQL</productname> dispose d'autres fonctionnalités non
     décrites dans ce tutoriel d'introduction orienté vers les nouveaux
     utilisateurs de <acronym>SQL</acronym>. Ces fonctionnalités sont discutées
-    plus en détails dans le reste de ce livre.
+    plus en détail dans le reste de ce livre.
    </para>
 
    <para>

postgresql/query.xml

@@ -68,10 +68,10 @@
     <firstterm>relations</firstterm>. Relation est essentiellement un terme
     mathématique pour <firstterm>table</firstterm>. La notion de stockage de
     données dans des tables est si commune aujourd'hui que cela peut sembler en
-    soi évident mais il y a de nombreuses autres manières d'organiser des bases
+    soi évident, mais il y a de nombreuses autres manières d'organiser des bases
     de données. Les fichiers et répertoires dans les systèmes d'exploitation de
     type Unix forment un exemple de base de données hiérarchique. Un
-    développement plus moderne est une base de données orientée objets.
+    développement plus moderne est une base de données orientée objet.
    </para>
 
    <para>
@@ -138,8 +138,8 @@
     différemment ou même sur une seule ligne. Deux tirets
     (<quote><literal>--</literal></quote>) introduisent des commentaires. Ce
     qui les suit est ignoré jusqu'à la fin de la ligne. SQL est insensible à
-    la casse pour les mots-clés et les identifiants excepté quand les
-    identifiants sont entre double guillemets pour préserver leur casse (non
+    la casse pour les mots-clés et les identifiants, excepté quand les
+    identifiants sont entre doubles guillemets pour préserver leur casse (non
     fait ci-dessus).
    </para>
 
@@ -159,11 +159,11 @@
     <type>real</type>, <type>double precision</type>,
     <type>char(<replaceable>N</replaceable>)</type>,
     <type>varchar(<replaceable>N</replaceable>)</type>, <type>date</type>,
-    <type>time</type>, <type>timestamp</type> et <type>interval</type> ainsi
+    <type>time</type>, <type>timestamp</type> et <type>interval</type>, ainsi
     que d'autres types d'utilité générale et un riche ensemble de types
     géométriques. <productname>PostgreSQL</productname> peut être personnalisé
     avec un nombre arbitraire de types de données définis par l'utilisateur. En
-    conséquence, les noms des types ne sont pas des mots-clé dans la syntaxe
+    conséquence, les noms des types ne sont pas des mots-clés dans la syntaxe
     sauf lorsqu'il est requis de supporter des cas particuliers dans la norme
     <acronym>SQL</acronym>.
    </para>
@@ -205,16 +205,16 @@
 
 <programlisting>INSERT INTO temps VALUES ('San Francisco', 46, 50, 0.25, '1994-11-27');</programlisting>
 
-    Notez que tous les types utilisent des formats d'entrées plutôt évident.
+    Notez que tous les types utilisent des formats d'entrées plutôt évidents.
     Les constantes qui ne sont pas des valeurs numériques simples doivent être
     habituellement entourées par des guillemets simples (<literal>'</literal>)
     comme dans l'exemple. Le type <type>date</type> est en réalité tout à fait
-    flexible dans ce qu'il accepte mais, pour ce tutoriel, nous collerons au
+    flexible dans ce qu'il accepte, mais, pour ce tutoriel, nous collerons au
     format non ambigu montré ici.
    </para>
 
    <para>
-    Le type <type>point</type> demande une paire de coordonnées en entrée comme
+    Le type <type>point</type> demande une paire de coordonnées en entrée, comme
     cela est montré ici&nbsp;:
 <programlisting>INSERT INTO villes VALUES ('San Francisco', '(-194.0, 53.0)');</programlisting>
    </para>
@@ -246,14 +246,14 @@
 
     Vous auriez pu aussi utiliser <command>COPY</command> pour charger de
     grandes quantités de données depuis des fichiers texte. C'est habituellement
-    plus rapide car la commande <command>COPY</command> est optimisée pour cet
-    emploi mais elle est moins flexible que <command>INSERT</command>. Par
+    plus rapide, car la commande <command>COPY</command> est optimisée pour cet
+    emploi, mais elle est moins flexible que <command>INSERT</command>. Par
     exemple&nbsp;:
 
 <programlisting>COPY temps FROM '/home/utilisateur/temps.txt';</programlisting>
 
     où le nom du fichier source doit être disponible sur la machine qui exécute
-    le processus serveur car le processus serveur lit le fichier directement.
+    le processus serveur, car le processus serveur lit le fichier directement.
     Vous avez plus d'informations sur la commande <command>COPY</command> dans
     <xref linkend="sql-copy"/>.
    </para>
@@ -283,7 +283,7 @@
      <para>
       Alors que <literal>SELECT *</literal> est utile pour des requêtes rapides,
       c'est généralement considéré comme un mauvais style dans un code en
-      production car l'ajout d'une colonne dans la table changerait les
+      production, car l'ajout d'une colonne dans la table changerait les
       résultats.
      </para>
     </footnote>
@@ -376,7 +376,7 @@ ORDER BY ville, t_basse;</programlisting>
  San Francisco
 (2 rows)</screen>
 
-    De nouveau, l'ordre des lignes résultats pourrait varier. Vous pouvez vous
+    De nouveau, l'ordre des lignes résultat pourrait varier. Vous pouvez vous
     assurer des résultats cohérents en utilisant <literal>DISTINCT</literal>
     et <literal>ORDER BY</literal> ensemble&nbsp;:
     <footnote>
@@ -411,17 +411,17 @@ ORDER BY ville;</programlisting>
     même table de façon à ce que plusieurs lignes de la table soient traitées
     en même temps. Une requête qui consulte plusieurs lignes de la même ou de
     différentes tables en même temps est appelée requête de
-    <firstterm>jointure</firstterm>. Comme exemple, supposez que vous souhaitez
+    <firstterm>jointure</firstterm>. Comme exemple, supposez que vous souhaitiez
     comparer la colonne <structfield>ville</structfield> de chaque ligne de la
     table <structname>temps</structname> avec la colonne
     <structfield>nom</structfield> de toutes les lignes de la table
-    <structname>villes</structname> et que vous choisissez les paires de lignes
+    <structname>villes</structname> et que vous choisissiez les paires de lignes
     où ces valeurs correspondent.
     <note>
      <para>
       Ceci est uniquement un modèle conceptuel. La jointure est habituellement
       exécutée d'une manière plus efficace que la comparaison de chaque paire
-      de lignes mais c'est invisible pour l'utilisateur.
+      de lignes, mais c'est invisible pour l'utilisateur.
      </para>
     </note>
     Ceci sera accompli avec la requête suivante&nbsp;:
@@ -455,7 +455,7 @@ ORDER BY ville;</programlisting>
 
     <listitem>
      <para>
-      Il y a deux colonnes contenant le nom des villes. C'est correct car les
+      Il y a deux colonnes contenant le nom des villes. C'est correct, car les
       listes des colonnes des tables <structname>temps</structname> et
       <structname>villes</structname> sont concaténées. En pratique, ceci est
       indésirable, vous voudrez probablement lister les colonnes explicitement
@@ -502,7 +502,7 @@ ORDER BY ville;</programlisting>
 <programlisting>SELECT *
     FROM temps INNER JOIN villes ON (temps.ville = villes.nom);</programlisting>
 
-    Cette syntaxe n'est pas aussi couramment utilisée que les précédentes mais
+    Cette syntaxe n'est pas aussi couramment utilisée que les précédentes, mais
     nous la montrons ici pour vous aider à comprendre les sujets suivants.
    </para>
 
@@ -511,14 +511,14 @@ ORDER BY ville;</programlisting>
 <indexterm><primary>jointure</primary><secondary>externe</secondary></indexterm>
 
     Maintenant, nous allons essayer de comprendre comment nous pouvons avoir
-    les entrées de Hayward. Nous voulons que la requête parcourt la table
+    les entrées de Hayward. Nous voulons que la requête parcoure la table
     <structname>temps</structname> et que, pour chaque ligne, elle trouve la
     (ou les) ligne(s) de <structname>villes</structname> correspondante(s). Si
     aucune ligne correspondante n'est trouvée, nous voulons que les valeurs des
     colonnes de la table <structname>villes</structname> soient remplacées par
     des <quote>valeurs vides</quote>. Ce genre de requêtes est appelé
     <firstterm>jointure externe</firstterm> (outer join). (Les jointures que
-    nous avons vus jusqu'ici sont des jointures internes &mdash; inner joins).
+    nous avons vues jusqu'ici sont des jointures internes &mdash; inner joins).
     La commande ressemble à cela&nbsp;:
 
 <programlisting>SELECT *
@@ -534,7 +534,7 @@ ORDER BY ville;</programlisting>
     Cette requête est appelée une <firstterm>jointure externe à
     gauche</firstterm> (left outer join) parce que la table mentionnée à la
     gauche de l'opérateur de jointure aura au moins une fois ses lignes dans
-    le résultat tandis que la table sur la droite aura seulement les lignes qui
+    le résultat, tandis que la table sur la droite aura seulement les lignes qui
     correspondent à des lignes de la table de gauche. Lors de l'affichage d'une
     ligne de la table de gauche pour laquelle il n'y a pas de correspondance
     dans la table de droite, des valeurs vides (appelées NULL) sont utilisées
@@ -562,8 +562,8 @@ ORDER BY ville;</programlisting>
 
     Nous pouvons également joindre une table avec elle-même. Ceci est appelé
     une <firstterm>jointure réflexive</firstterm>. Comme exemple, supposons
-    que nous voulons trouver toutes les entrées de temps qui sont dans un
-    intervalle de température d'autres entrées de temps. Nous avons donc besoin
+    que nous voulions trouver toutes les entrées de temps qui sont dans un
+    intervalle de températures d'autres entrées de temps. Nous avons donc besoin
     de comparer les colonnes <structfield>t_basse</structfield> et
     <structfield>t_haute</structfield> de chaque ligne de
     <structname>temps</structname> aux colonnes
@@ -585,9 +585,9 @@ ORDER BY ville;</programlisting>
 (2 rows)</programlisting>
 
     Dans cet exemple, nous avons renommé la table temps en <literal>T1</literal>
-    et en <literal>T2</literal> pour être capable de distinguer respectivement
-    le côté gauche et droit de la jointure. Vous pouvez aussi utiliser ce genre
-    d'alias dans d'autres requêtes pour économiser de la frappe,
+    et en <literal>T2</literal> pour être capables de distinguer respectivement
+    le côté gauche et le côté droit de la jointure. Vous pouvez aussi utiliser
+    ce genre d'alias dans d'autres requêtes pour économiser de la frappe,
     c'est-à-dire&nbsp;:
 <programlisting>SELECT *
     FROM temps t, villes v
@@ -653,7 +653,7 @@ ORDER BY ville;</programlisting>
  San Francisco
 (1 row)</screen>
 
-    Ceci est correct car la sous-requête est un calcul indépendant qui traite
+    Ceci est correct, car la sous-requête est un calcul indépendant qui traite
     son propre agrégat séparément à partir de ce qui se passe dans la requête
     externe.
    </para>
@@ -693,7 +693,7 @@ ORDER BY ville;</programlisting>
 (1 row)</screen>
 
     ce qui nous donne le même résultat uniquement pour les villes qui ont
-    toutes leurs valeurs de  <structfield>t_basse</structfield> en-dessous de
+    toutes leurs valeurs de  <structfield>t_basse</structfield> en dessous de
     40. Pour finir, si nous nous préoccupons seulement des villes dont le nom
     commence par <quote><literal>S</literal></quote>, nous pouvons faire&nbsp;:
 
@@ -720,15 +720,15 @@ ORDER BY ville;</programlisting>
     <literal>WHERE</literal> et <literal>HAVING</literal> est que
     <literal>WHERE</literal> sélectionne les lignes en entrée avant que les
     groupes et les agrégats ne soient traités (donc, cette clause contrôle les
-    lignes qui se retrouvent dans le calcul de l'agrégat) tandis que
+    lignes qui se retrouvent dans le calcul de l'agrégat), tandis que
     <literal>HAVING</literal> sélectionne les lignes groupées après que les
-    groupes et les agrégats aient été traités. Donc, la clause
+    groupes et les agrégats ont été traités. Donc, la clause
     <literal>WHERE</literal> ne doit pas contenir de fonctions d'agrégat&nbsp;;
     cela n'a aucun sens d'essayer d'utiliser un agrégat pour déterminer les
     lignes en entrée des agrégats. D'un autre côté, la clause
     <literal>HAVING</literal> contient toujours des fonctions d'agrégat (pour
     être précis, vous êtes autorisés à écrire une clause
-    <literal>HAVING</literal> qui n'utilise pas d'agrégats mais c'est rarement
+    <literal>HAVING</literal> qui n'utilise pas d'agrégat, mais c'est rarement
     utilisé. La même condition pourra être utilisée plus efficacement par un
     <literal>WHERE</literal>).
    </para>
@@ -784,7 +784,7 @@ ORDER BY ville;</programlisting>
 
    <para>
     Les lignes peuvent être supprimées de la table avec la commande
-    <command>DELETE</command>. Supposez que vous n'êtes plus intéressé par le
+    <command>DELETE</command>. Supposez que vous ne soyez plus intéressé par le
     temps de Hayward. Vous pouvez faire ce qui suit pour supprimer ses lignes
     de la table&nbsp;:
 <programlisting>DELETE FROM temps WHERE ville = 'Hayward';</programlisting>