[Trad] [svn:pgfr] r1092 - traduc/trunk/postgresql
svncommit at kryskool.org
svncommit at kryskool.org
Mar 8 Juil 12:52:44 CEST 2008
Auteur: sas
Date: 2008-07-08 12:52:44 +0200 (mar, 08 jui 2008)
Nouvelle Révision: 1092
Modification:
traduc/trunk/postgresql/ddl.xml
traduc/trunk/postgresql/docguide.xml
Log:
et de d...
--Cett, les suivantes ci-dessous, seront ignorées--
M postgresql/ddl.xml
M postgresql/docguide.xml
Modified: traduc/trunk/postgresql/ddl.xml
===================================================================
--- traduc/trunk/postgresql/ddl.xml 2008-07-08 10:00:50 UTC (rev 1091)
+++ traduc/trunk/postgresql/ddl.xml 2008-07-08 10:52:44 UTC (rev 1092)
@@ -3,7 +3,6 @@
le $Date$
par $Author$
révision $Revision$ -->
-<!-- SAS : 20070410, PG 8.2.3 -->
<chapter id="ddl">
<title>Définition des données</title>
@@ -50,15 +49,14 @@
</para>
<para>
De plus, le SQL n'attribue pas d'identifiant unique aux lignes. Il est
- donc possible
- d'avoir plusieurs lignes identiques au sein d'une table. C'est une
- conséquence du modèle mathématique sur lequel repose le SQL, même si
- cela n'est habituellement pas souhaitable.
+ donc possible d'avoir plusieurs lignes identiques au sein d'une table.
+ C'est une conséquence du modèle mathématique sur lequel repose le SQL,
+ même si cela n'est habituellement pas souhaitable.
Il est expliqué plus bas dans ce chapitre comment traiter ce problème.
</para>
<para>
- Chaque colonne a un type de donnée. Ce type de donnée limite l'ensemble
+ Chaque colonne a un type de données. Ce type limite l'ensemble
de valeurs qu'il est possible d'attribuer à une colonne. Il attribue
également une sémantique aux données stockées dans la colonne pour
permettre les calculs sur celles-ci. Par exemple, une colonne déclarée dans un
@@ -141,9 +139,10 @@
</para>
</tip>
-<!-- Par contre, utilisé par Céline dans un souci de provocation, n'est à
-l'évidence pas une construction grammaticale préconisée par l'Académie
-Française. On lui préférera "En revanche", "Cependant", "Au contraire"... -->
+<!-- Par contre, utilisé par Céline (pas Dion, mais Louis-Ferdinand) dans un
+souci de provocation, n'est à l'évidence pas une construction grammaticale
+préconisée par l'Académie Française. On lui préférera "En revanche",
+"Cependant", "Au contraire"... -->
<para>
Le nombre de colonnes d'un table est limité. En fonction du type de
colonnes, il oscille entre 250 et 1600.
@@ -167,8 +166,7 @@
de supprimer chaque table avant de la créer. Les messages
d'erreur sont alors ignorés afin que le script fonctionne que la table
existe ou non. (La variante <literal>DROP TABLE IF EXISTS</literal> peut
- aussi être utilisée pour
- éviter les messages d'erreur mais elle ne fait pas partie du
+ aussi être utilisée pour éviter les messages d'erreur mais elle ne fait pas partie du
standard SQL.)
</para>
@@ -181,7 +179,7 @@
Les outils précédemment décrits permettent de créer des tables
fonctionnelles. Le reste de ce chapitre est consacré à l'ajout de fonctionnalités
à la définition de tables pour garantir l'intégrité des données, la sécurité
- ou l'ergonomie. Le lecteur impatient d'insérer des données dans ses tables
+ ou l'ergonomie. Le lecteur impatient d'insérer des données dans ses tables
peut sauter au <xref linkend="dml"/> et lire le reste de
ce chapitre plus tard.
</para>
@@ -295,9 +293,8 @@
La contrainte de vérification est la contrainte la plus
générique qui soit. Elle permet d'indiquer que la valeur
d'une colonne particulière doit satisfaire une expression booléenne
- (valeur de vérité). Par
- exemple, pour obliger les prix des produits à être positifs, on peut
- utiliser :
+ (valeur de vérité). Par exemple, pour obliger les prix des produits
+ à être positifs, on peut utiliser :
<programlisting>CREATE TABLE produits (
no_produit integer,
nom text,
@@ -362,10 +359,10 @@
<para>
Les deux premières contraintes sont appelées contraintes de
- colonnes tandis que la troisième est appelée contrainte de table parce
+ colonne tandis que la troisième est appelée contrainte de table parce
qu'elle est écrite séparément d'une définition de colonne particulière.
- Les contraintes de colonnes peuvent être écrites comme des contraintes de
- tables, mais l'inverse n'est pas forcément possible puisqu'une contrainte de colonne est
+ Les contraintes de colonne peuvent être écrites comme des contraintes de
+ table, mais l'inverse n'est pas forcément possible puisqu'une contrainte de colonne est
supposée ne faire référence qu'à la colonne à laquelle elle est
attachée (<productname>PostgreSQL</productname> ne vérifie pas cette règle
mais il est préférable de la suivre pour s'assurer que les définitions de
@@ -454,7 +451,7 @@
</para>
<para>
- Une colonne peut évidemment avoir plus d'une contrainte. Il suffit
+ Une colonne peut évidemment avoir plusieurs contraintes. Il suffit
d'écrire les contraintes les unes après les autres :
<programlisting>CREATE TABLE produits (
no_produit integer NOT NULL,
@@ -469,13 +466,13 @@
La contrainte <literal>NOT NULL</literal> a un contraire ; la contrainte
<literal>NULL</literal>. Elle ne signifie pas que la colonne doit
être NULL, ce qui est assurément inutile, mais sélectionne le comportement
- par défaut, à savoir que la colonne peut être NULL. La contrainte <literal>NULL
- </literal> n'est pas présente dans le standard SQL et ne doit pas
+ par défaut, à savoir que la colonne peut être NULL. La contrainte
+ <literal>NULL</literal> n'est pas présente dans le standard SQL et ne doit pas
être utilisée dans des applications portables (elle n'a été ajoutée
dans <productname>PostgreSQL</productname> que pour assurer la
compatibilité avec d'autres bases de données). Certains utilisateurs
l'apprécient néanmoins car elle permet de basculer aisément d'une
- contrainte à l'autre dans un ficheir de script. On peut, par exemple, commencer avec :
+ contrainte à l'autre dans un fichier de script. On peut, par exemple, commencer avec :
<programlisting>CREATE TABLE produits (
no_produit integer NULL,
nom text NULL,
@@ -486,8 +483,8 @@
<tip>
<para>
- Dans la plupart des bases de données, la majorité des
- colonnes peut être marquée NOT NULL.
+ Dans la plupart des bases de données, il est préférable que la majorité des
+ colonnes soient marquées NOT NULL.
</para>
</tip>
</sect2>
@@ -619,7 +616,7 @@
</para>
<para>
- Une table a au plus une clé primaire. (Le nombre de contraintes UNIQUE NOT NULL,
+ Une table a, au plus, une clé primaire. (Le nombre de contraintes UNIQUE NOT NULL,
qui assurent la même fonction, n'est pas limité, mais une seule
peut être identifiée comme clé primaire.) La théorie des
bases de données relationnelles impose que chaque table ait
@@ -698,7 +695,7 @@
<para>
Une clé étrangère peut aussi contraindre et référencer un groupe de colonnes.
Comme cela a déjà été évoqué, il faut alors l'écrire sous forme d'une contrainte de table.
- Voici un exemple de syntaxe :
+ Exemple de syntaxe :
<programlisting>CREATE TABLE t1 (
a integer PRIMARY KEY,
b integer,
@@ -984,12 +981,10 @@
Les OID sont des nombres de 32 bits et sont attribués à partir d'un
compteur unique sur le cluster. Dans une base de données volumineuse ou
agée, il est possible que le compteur boucle. Il est de ce fait peu
- pertinent de
- considérer que les OID puissent être uniques ; pour identifier les
- lignes d'une table, il est fortement
- recommandé d'utiliser un générateur de séquence.
- Néanmoins, les OID peuvent également être utilisés sous réserve que quelques
- précautions soient prises :
+ pertinent de considérer que les OID puissent être uniques ; pour
+ identifier les lignes d'une table, il est fortement recommandé d'utiliser
+ un générateur de séquence. Néanmoins, les OID peuvent également être
+ utilisés sous réserve que quelques précautions soient prises :
<itemizedlist>
<listitem>
@@ -1041,7 +1036,7 @@
traitées.
De plus, à partir de <productname>PostgreSQL</productname> 8.3, seules les
commandes qui modifient réellement le contenu de la base de données
- consommeront un identifiant de commande.
+ consomment un identifiant de commande.
</para>
</sect1>
@@ -1108,7 +1103,7 @@
</indexterm>
<para>
- La commande d'ajout d'une colonne ressemble à celle-ci :
+ La commande d'ajout d'une colonne ressemble à :
<programlisting>ALTER TABLE produits ADD COLUMN description text;</programlisting>
La nouvelle colonne est initialement remplie avec la valeur par défaut
précisée (NULL en l'absence de clause <literal>DEFAULT</literal>).
@@ -1194,7 +1189,7 @@
<indexterm>
<primary>contrainte</primary>
- <secondary>retirer</secondary>
+ <secondary>supprimer</secondary>
</indexterm>
<para>
@@ -1362,7 +1357,7 @@
<para>
La commande <command>GRANT</command> est
- utilisée pour accorder des privilèges (on dit aussi granter un privilège).
+ utilisée pour accorder des privilèges (on dit aussi « granter un privilège »).
Par exemple, si <literal>joe</literal>
est un utilisateur et <literal>comptes</literal> une table, le
privilège d'actualiser la table <literal>comptes</literal> peut être accordé
@@ -1416,10 +1411,10 @@
<para>
Un cluster de bases de données <productname>PostgreSQL</productname>
- contient une ou plusieurs bases nommées. Si les utilisateurs et groupes
+ contient une ou plusieurs base(s) nommée(s). Si les utilisateurs et groupes
d'utilisateurs sont partagés sur l'ensemble du cluster, aucune
- autre donnée n'est partagée. Une connexion cliente
- donnée sur le serveur ne peut accéder qu'aux données d'une seule base, celle
+ autre donnée n'est partagée. Toute connexion cliente
+ au serveur ne peut accéder qu'aux données d'une seule base, celle
indiquée dans la requête de connexion.
</para>
@@ -1433,9 +1428,12 @@
</para>
</note>
+<!-- Je ne sais pas si coller le (s) à la suite de la balise fermante passe...
+-->
<para>
- Une base de données contient un ou plusieurs <firstterm>schémas</firstterm>
- nommés qui, eux, contiennent des tables. Les schémas contiennent aussi d'autres
+ Une base de données contient un ou plusieurs
+ <firstterm>schéma</firstterm>(s) nommé(s) qui, eux, contiennent des
+ tables. Les schémas contiennent aussi d'autres
types d'objets nommés (types de données, fonctions et opérateurs, par
exemple).
Le même nom d'objet peut être utilisé dans différents schémas sans conflit ; par exemple,
@@ -1453,14 +1451,14 @@
<itemizedlist>
<listitem>
<para>
- pour autoriser de nombreux utilisateurs à utiliser une base de données
- sans interférences entre eux ;
+ autoriser de nombreux utilisateurs à utiliser une base de données
+ sans interférer avec les autres ;
</para>
</listitem>
<listitem>
<para>
- pour organiser les objets de la base de données en groupes logiques afin de faciliter
+ organiser les objets de la base de données en groupes logiques afin de faciliter
leur gestion ;
</para>
</listitem>
@@ -1502,20 +1500,20 @@
</indexterm>
<para>
- Pour créer ou accéder aux objets d'un schéma, on écrit un
+ Pour créer les objets d'un schéma ou y accéder, on écrit un
<firstterm>nom qualifié</firstterm> constitué du nom du schéma et
du nom de la table séparés par un point :
<synopsis><replaceable>schema</replaceable><literal>.</literal><replaceable>table</replaceable></synopsis>
- Cela fonctionne partout où un nom de table est attendu, ce qui inclue les
+ Cela fonctionne partout où un nom de table est attendu, ce qui inclut les
commandes de modification de la table et les commandes d'accès aux données
discutées dans les chapitres suivants. (Pour des raisons de
- simplification, il n'est question que de tables, mais les mêmes principes
- s'appliquent à d'autres types d'objets nommés, comme les types et les
+ simplification, seules les tables sont évoquées, mais les mêmes principes
+ s'appliquent aux autres objets nommés, comme les types et les
fonctions.)
</para>
<para>
- En fait, la syntaxe encore plus générale
+ La syntaxe encore plus générale
<synopsis><replaceable>base</replaceable><literal>.</literal><replaceable>schema</replaceable><literal>.</literal><replaceable>table</replaceable></synopsis>
peut aussi être utilisée, mais à l'heure actuelle, cette syntaxe n'existe
que pour des raisons de conformité avec le standard SQL. Si un nom de base de
@@ -1606,8 +1604,8 @@
la table appelée en suivant un <firstterm>chemin de recherche</firstterm>,
liste de schémas dans lesquels chercher. La première table correspondante
est considérée comme la table voulue. S'il n'y a pas de correspondance, une
- erreur est remontée, même si des noms de table correspondant existent dans
- d'autres schémas de la base.
+ erreur est remontée, quand bien même il existerait des tables dont le nom
+ correspond dans d'autres schémas de la base.
</para>
<indexterm>
@@ -1639,8 +1637,8 @@
</para>
<para>
- C'est, par défaut, dans le premier schéma du chemin de recherche qui existe que sont
- créés les nouveaux objets. C'est la raison
+ C'est, par défaut, dans le premier schéma du chemin de recherche qui
+ existe que sont créés les nouveaux objets. C'est la raison
pour laquelle les objets sont créés, par défaut, dans le schéma public.
Lorsqu'il est fait référence à un objet, dans tout autre contexte, sans
qualification par un schéma (modification de table, modification de
@@ -1653,8 +1651,8 @@
Pour ajouter un schéma au chemin, on écrit :
<programlisting>SET search_path TO mon_schema,public;</programlisting>
(<literal>$user</literal> est omis à ce niveau car il n'est pas
- immédiatement nécessaire.) Il est alors possible d'à la table sans
- qualification par un schéma :
+ immédiatement nécessaire.) Il est alors possible d'accéder à la table
+ sans qu'elle soit qualifiée par un schéma :
<programlisting>DROP TABLE ma_table;</programlisting>
Puisque <literal>mon_schema</literal> est le premier élément du
chemin, les nouveaux objets sont, par défaut, créés dans ce schéma.
@@ -1677,13 +1675,12 @@
<para>
Le chemin de recherche fonctionne de la même façon pour les noms de type de
données, les noms de fonction et les noms d'opérateur que pour les noms de
- tables. Les noms des types de données et des fonctions peuvent être qualifiés de la
+ table. Les noms des types de données et des fonctions peuvent être qualifiés de la
même façon que les noms de table. S'il est nécessaire d'écrire un nom
d'opérateur qualifié dans une expression, il y a une condition
spéciale. Il faut écrire :
<synopsis><literal>OPERATOR(</literal><replaceable>schéma</replaceable><literal>.</literal><replaceable>opérateur</replaceable><literal>)</literal></synopsis>
- Cela afin d'éviter toute ambiguïté syntaxique. En voici un
- exemple
+ Cela afin d'éviter toute ambiguïté syntaxique. Par exemple :
<programlisting>SELECT 3 OPERATOR(pg_catalog.+) 4;</programlisting>
En pratique, il est préférable de s'en remettre au chemin de recherche pour les opérateurs,
afin de ne pas avoir à écrire quelque chose d'aussi étrange.
@@ -1703,13 +1700,13 @@
dans les schémas qui ne leur appartiennent pas. Pour le permettre, le
propriétaire du schéma doit granter le droit <literal>USAGE</literal> sur
le schéma. Pour autoriser les utilisateurs à manipuler les objets d'un
- schéma, des privilèges supplémentaires doivent peut-être être accordés, en
+ schéma, des privilèges supplémentaires doivent éventuellement être accordés, en
fonction de l'objet.
</para>
<para>
- Un utilisateur peut aussi être autorisé à créer des objets dans
- schéma de quelqu'un d'autre. Pour cela, le privilège
+ Un utilisateur peut aussi être autorisé à créer des objets dans le
+ schéma d'un d'autre. Pour cela, le privilège
<literal>CREATE</literal> sur le schéma doit être accordé. Par défaut,
tout le monde bénéficie des droits <literal>CREATE</literal> et
<literal>USAGE</literal> sur le schéma <literal>public</literal>.
@@ -1776,27 +1773,26 @@
si aucun schéma n'est créé, alors tous les utilisateurs
ont implicitement accès au schéma public. Cela permet de simuler une
situation dans laquelle les schémas ne sont pas disponibles.
- Cette situation est essentiellement recommandée pour les utilisateurs
- seuls ou quelques d'utilisateurs concurents au sein d'une base de
- données. Cette configuration permet aussi une transition
- en douceur depuis un monde où les schémas sont inconnus ;
+ Cette situation est essentiellement recommandée lorsqu'il n'y a qu'un
+ utilisateur, ou un très petit nombre d'utilisateurs qui coopèrent au
+ sein d'une base de données. Cette configuration permet aussi d'opérer
+ une transition en douceur depuis un monde où les schémas sont inconnus ;
</para>
</listitem>
<listitem>
<para>
- un schéma peut être créé pour chaque utilisateur, avec un
- nom identique à celui de l'utilisateur. Le
- chemin de recherche par défaut commence par
- <literal>$user</literal>, ce qui correspond au nom de l'utilisateur.
- Si chaque utilisateur dispose d'un schéma distinct, tout utilisateur accède, par
- défaut, à son propre schéma.
+ pour chaque utilisateur, un schéma, de nom identique à celui de
+ l'utilisateur, peut être créé. Le chemin de recherche par défaut
+ commence par <literal>$user</literal>, soit le nom de l'utilisateur.
+ Si tous les utilisateurs disposent d'un schéma distinct, ils accèdent, par
+ défaut, à leur propre schéma.
<!-- </para>
<para> -->
Dans cette configuration, il est possible de révoquer l'accès
au schéma public (voire de supprimer ce schéma)
- pour contraindre les utilisateurs à leur propre schéma ;
+ pour confiner les utilisateurs dans leur propre schéma ;
</para>
</listitem>
@@ -1808,7 +1804,7 @@
Il faut alors accorder des privilèges appropriés
pour permettre aux autres utilisateurs d'y accéder. Les utilisateurs
peuvent alors se référer à ces objets additionnels en qualifiant
- leurs noms du nom de schéma ou ajouter les schémas
+ leur nom du nom de schéma ou ajouter les schémas
supplémentaires dans leur chemin de recherche, au choix.
</para>
</listitem>
@@ -1820,10 +1816,10 @@
<title>Portabilité</title>
<para>
- Dans le standard SQL, la notion d'objets du même schéma
+ Dans le standard SQL, la notion d'objets d'un même schéma
appartenant à des utilisateurs différents n'existe pas. De plus,
certaines implantations ne permettent pas de créer des
- schémas qui ont un nom différent de celui de leur propriétaire.
+ schémas de nom différent de celui de leur propriétaire.
En fait, les concepts de schéma et d'utilisateur sont presque
équivalents dans un système de base de données qui n'implante
que le support basique des schémas tel que spécifié dans le standard.
@@ -1846,7 +1842,7 @@
tout les schémas, ou fournissent le support de
<foreignphrase>namespace</foreignphrase> en
autorisant (peut-être de façon limitée) l'accès inter-bases
- de données. Dans ce cas, la portabilité maximale sera obtenue en n'utilisant
+ de données. Dans ce cas, la portabilité maximale est obtenue en n'utilisant
pas les schémas.
</para>
</sect2>
@@ -1878,8 +1874,7 @@
capitales et une pour les villes qui ne
sont pas des capitales. Mais, que se passe-t'il dans le cas où toutes
les données d'une ville doivent être récupérées, qu'elle soit une capitale
- ou non ?
- L'héritage peut aider à résoudre ce problème. La
+ ou non ? L'héritage peut aider à résoudre ce problème. La
table <structname>capitales</structname> est définie pour hériter de
<structname>villes</structname> :
@@ -1901,20 +1896,20 @@
<para>
Dans <productname>PostgreSQL</productname>, une table peut hériter de zéro
- à plusieurs autres tables et une requête faire référence à toutes
- les lignes d'une table ou à toutes les lignes d'une table plus celles
+ à plusieurs autres tables et une requête faire référence aux
+ lignes d'une table ou à celles d'une table et de ses
des descendantes. Ce dernier comportement est celui par défaut.
</para>
<para>
- Par
- exemple, la requête suivante retourne les noms et altitudes de toutes les villes, y compris
- les capitales, situées à une altitude supérieure à 500 pieds :
+ Par exemple, la requête suivante retourne les noms et altitudes de toutes
+ les villes, y compris les capitales, situées à une altitude supérieure
+ à 500 pieds :
<programlisting>SELECT nom, altitude
FROM villes
WHERE altitude > 500;</programlisting>
- Étant donné les données du tutoriel de <productname>PostgreSQL</productname>
+ Avec les données du tutoriel de <productname>PostgreSQL</productname>
(voir <xref linkend="tutorial-sql-intro"/>), ceci renvoie :
<programlisting> nom | altitude
@@ -1951,7 +1946,7 @@
</para>
<para>
- Dans certain cas, il peut être intéressant de savoir de quelle table provient une ligne
+ Dans certains cas, il peut être intéressant de savoir de quelle table provient une ligne
donnée. Une colonne système appelée <structfield>TABLEOID</structfield>
présente dans chaque table donne la table d'origine :
@@ -1967,7 +1962,7 @@
139793 | Mariposa | 1953
139798 | Madison | 845</programlisting>
- (La reproduction de cet exemple conduira probablement à des
+ (Reproduire cet exemple conduit probablement à des
OID numériques différents). Une jointure avec
<structname>pg_class</structname>, permet d'obtenir les noms réels des tables :
@@ -1992,8 +1987,8 @@
<command>INSERT</command> suivante échoue :
<programlisting>INSERT INTO villes (nom, population, altitude, etat)
VALUES ('New York', NULL, NULL, 'NY');</programlisting>
- On peut espérer que les données soient magiquement routées vers la table
- <structname>capitales</structname> mais cela n'arrive pas :
+ On pourrait espérer que les données soient magiquement routées vers la table
+ <structname>capitales</structname> mais ce n'est pas le cas :
<command>INSERT</command> insère toujours dans la table indiquée. Dans
certains cas, il est possible de rediriger l'insertion en utilisant une
règle (voir <xref linkend="rules"/>). Néanmoins, cela n'est d'aucune aide
@@ -2012,10 +2007,10 @@
<para>
Une table peut hériter de plusieurs tables, auquel cas elle possède
- l'union des colonnes définies par les tables parents. Toute colonne déclarée
- dans la définition de la table enfant est ajoutée à celles-ci. Si le même nom
- de colonne apparaît dans plusieurs tables parent, ou à la fois dans une
- table parent et dans la définition de la table enfant, alors ces colonnes sont
+ l'union des colonnes définies par les tables mèress. Toute colonne déclarée
+ dans la définition de la table enfant est ajoutée à cette dernière. Si le même nom
+ de colonne apparaît dans plusieurs tables mères, ou à la fois dans une
+ table mère et dans la définition de la table enfant, alors ces colonnes sont
<quote>assemblées</quote> pour qu'il n'en existe qu'une dans la table
enfant. Pour être assemblées, les colonnes doivent avoir le même type de
données, sinon une erreur est levée. La colonne assemblée hérite de toutes les
@@ -2024,11 +2019,11 @@
</para>
<para>
- L'héritage de table est typiquement établi lors de la création de la table
- enfant en utilisant la clause <literal>INHERITS</literal> de l'instruction
+ L'héritage de table est établi à la création de la table
+ enfant, à l'aide de la clause <literal>INHERITS</literal> de l'instruction
<xref linkend="sql-createtable" endterm="sql-createtable-title"/>.
- Alternativement, il est possible d'ajouter à une table déjà définie de façon
- compatible une nouvelle relation de parenté à l'aide de la clause
+ Alternativement, il est possible d'ajouter à une table, définie de façon
+ compatible, une nouvelle relation de parenté à l'aide de la clause
<literal>INHERIT</literal> de
<xref linkend="sql-altertable" endterm="sql-altertable-title"/>. Pour cela,
la nouvelle table enfant doit déjà inclure des colonnes de mêmes nom et
@@ -2054,15 +2049,15 @@
<literal>CHECK</literal> définies sur la table source, l'option
<literal>INCLUDING CONSTRAINTS</literal> de <literal>LIKE</literal> doit
être indiquée car le nouvel enfant doit avoir des contraintes qui
- correspondent à celles du parent pour être considéré compatible.
+ correspondent à celles du parent pour être considérée compatible.
</para>
<para>
- Une table parent ne peut pas être supprimée tant qu'elle a des enfants.
+ Une table mère ne peut pas être supprimée tant qu'elle a des enfants.
Pas plus que les colonnes de tables enfants ne peuvent être supprimées ou
- modifiées si elles sont héritées d'une table parent.
+ modifiées si elles sont héritées.
La suppression d'une table et de tous ces descendants peut être aisément
- obtenue en supprimant la table parent avec l'option
+ obtenue en supprimant la table mère avec l'option
<literal>CASCADE</literal>.
</para>
@@ -2070,13 +2065,14 @@
<xref linkend="sql-altertable" endterm="sql-altertable-title"/>
propage toute modification dans les définitions des colonnes et
contraintes de vérification à travers la hiérarchie d'héritage. Là encore,
- supprimer des colonnes ou des contraintes sur des tables parentes n'est possible
+ supprimer des colonnes ou des contraintes sur des tables mèrees n'est possible
qu'avec l'option <literal>CASCADE</literal>. <command>ALTER TABLE</command>
suit les mêmes règles d'assemblage de colonnes dupliquées et de rejet que
l'instruction <command>CREATE TABLE</command>.
</para>
-<!-- caveats != hints -->
+<!-- caveats != hints
+ Je parlerai de chausse-trappe -->
<sect2 id="ddl-inherit-caveats">
<title>Restrictions</title>
@@ -2091,9 +2087,9 @@
<para>
Il existe une réelle limitation à la fonctionnalité d'héritage : les index
- (ce qui inclue les contraintes d'unicité) et les contraintes de clés étrangères
- ne s'appliquent qu'aux tables, pas à leurs héritiers. Cela
- est vrai pour le côté référençant et le côté référencé d'une contrainte
+ (dont les contraintes d'unicité) et les contraintes de clés étrangères
+ ne s'appliquent qu'aux tables mères, pas à leurs héritiers. Cela
+ est valable pour le côté référençant et le côté référencé d'une contrainte
de clé étrangère. Ce qui donne, dans les termes de l'exemple ci-dessus :
<itemizedlist>
@@ -2104,19 +2100,19 @@
(<literal>PRIMARY KEY</literal>), cela n'empêche pas la table
<structname>capitales</structname> de posséder des lignes
avec des noms dupliqués dans <structname>villes</structname>. Et ces lignes
- dupliquées s'affichent par défaut dans les requêtes sur
- <structname>villes</structname>. En fait, par défaut,
- <structname>capitales</structname> n'a pas de contrainte
- d'unicité du tout et, du coup, peut contenir plusieurs lignes avec le
- même nom. Une contrainte d'unicité peut être ajoutée à
- <structname>capitales</structname> mais cela n'empêche pas la duplication
- avec <structname>villes</structname> ;
+ upliquées s'affichent par défaut dans les requêtes sur
+ <structname>villes</structname>. En fait, par défaut,
+ <structname>capitales</structname> n'a pas de contrainte
+ d'unicité du tout et, du coup, peut contenir plusieurs lignes avec le
+ même nom. Une contrainte d'unicité peut être ajoutée à
+ <structname>capitales</structname> mais cela n'empêche pas la duplication
+ avec <structname>villes</structname> ;
</para>
</listitem>
<listitem>
<para>
- de façon similaire, s'il faut préciser que
+ de façon similaire, si
<structname>villes</structname>.<structfield>nom</structfield> fait référence
(<literal>REFERENCES</literal>) à une autre table, cette contrainte
n'est pas automatiquement propagée à
@@ -2129,10 +2125,9 @@
<listitem>
<para>
- l'indication que la colonne d'une autre table <literal>REFERENCES
- villes(nom)</literal> autorise l'autre table à contenir les noms des
- villes mais pas les noms des capitales. Il n'existe pas de
- contournement efficace de ce cas.
+ si une autre table indique <literal>REFERENCES villes(nom)</literal>,
+ cela l'autorise à contenir les noms des villes mais pas les noms des
+ capitales. Il n'existe pas de contournement efficace de ce cas.
</para>
</listitem>
</itemizedlist>
@@ -2146,7 +2141,7 @@
<title>Obsolète</title>
<para>
Dans les versions de <productname>PostgreSQL</productname> antérieures à
- la 7.1, le comportement par défaut consistait à ne pas inclure les tables enfants dans les
+ 7.1, le comportement par défaut consistait à ne pas inclure les tables enfants dans les
requêtes. Il s'est avéré que cela était source d'erreur et violait le
standard SQL. Ce comportement peut être retrouvé en désactivant le
paramètre <xref linkend="guc-sql-inheritance"/>.
@@ -2156,7 +2151,6 @@
</sect2>
</sect1>
-<!-- ICI -->
<sect1 id="ddl-partitioning">
<title>Partitionnement</title>
@@ -2199,7 +2193,7 @@
<listitem>
<para>
lorsque les requêtes ou les mises à jour accèdent à un important pourcentage
- d'une unique partition, les performances peuvent être grandement améliorées
+ d'une seule partition, les performances peuvent être grandement améliorées
par l'utilisation avantageuse de parcours séquentiels sur cette
partition plutôt que d'utiliser un index et des lectures aléatoires
réparties sur toute la table ;
@@ -2255,7 +2249,8 @@
<!-- overlap ? Recouvrement, chevauchement... -->
<listitem>
<para>
- La table est partitionnée en <quote>groupes</quote> (ou échelles) définis par une
+ La table est partitionnée en <quote>intervalles</quote> (ou échelles)
+ définis par une
colonne clé ou par un ensemble de colonnes, sans recouvrement entre
les échelles de valeurs affectées aux différentes partitions. Il est
possible, par exemple, de partitionner par échelles de date ou par
@@ -2373,7 +2368,7 @@
<para>
Soit la base de données d'une grande fabrique de glaces. La compagnie
mesure le pic de température journalier ainsi que les ventes de glaces
- dans chaque région. Conceptuellement, la table ressemble à cela :
+ dans chaque région. Conceptuellement, la table ressemble à :
<programlisting>CREATE TABLE mesure (
id_ville int not null,
@@ -2431,10 +2426,10 @@
<listitem>
<para>
- Nous devons fournir des contraintes de table qui interdisent les
+ Il est nécessaire de fournir des contraintes de table qui interdisent les
recouvrements. Plutôt que de simplement créer les tables de la
- partition comme ci-dessus, le script de création de tables devrait
- ressembler à ceci :
+ partition comme ci-dessus, le script de création de tables ressemble
+ à ;
<programlisting>CREATE TABLE mesure_a2006m02 (
CHECK ( date_trace >= DATE '2006-02-01' AND date_trace < DATE '2006-03-01' )
@@ -2472,12 +2467,11 @@
<listitem>
<para>
- Nous voulons que notre application soit capable de dire
- <literal>INSERT INTO mesure...</literal> et que les données soient
- redirigées dans la table de partition appropriée. Nous pouvons
- arranger cela en attachant une fonction trigger à la table maître.
+ L'application doit dire <literal>INSERT INTO mesure...</literal> et les
+ données être redirigées dans la table de partition appropriée. Pour
+ cela une fonction déclencheur est attachée à la table maître.
Si les données ne sont ajoutées que dans la dernière partition,
- nous pouvons utiliser une fonction trigger très simple.
+ la fonction est très simple.
<programlisting>
CREATE OR REPLACE FUNCTION mesure_insert_trigger()
@@ -2490,8 +2484,7 @@
LANGUAGE plpgsql;
</programlisting>
- Après avoir créé la fonction, nous pouvons créer un trigger qui
- appelle la fonction trigger :
+ Le déclencheur qui appelle la fonction est créé à sa suite :
<programlisting>
CREATE TRIGGER insert_mesure_trigger
@@ -2499,15 +2492,15 @@
FOR EACH ROW EXECUTE PROCEDURE mesure_insert_trigger();
</programlisting>
- Nous devons redéfinir la fonction trigger chaque mois pour qu'il
- pointe toujours sur partition en cours. Par contre, la définition du
- trigger n'a pas besoin d'être mise à jour.
+ La fonction déclencheur doit être redéfinie chaque mois pour qu'elle
+ pointe toujours sur la partition active. La définition du déclencheur
+ n'a pas besoin d'être redéfinie.
</para>
<para>
Il est également possible de laisser le serveur localiser la partition
dans laquelle doit être insérée la ligne proposée en entrée. Une
- fonction trigger permet d'obtenir ce résultat :
+ fonction déclencheur plus complexe peut être utilisée pour cela :
<programlisting>
CREATE OR REPLACE FUNCTION mesure_insert_trigger()
@@ -2529,24 +2522,23 @@
LANGUAGE plpgsql;
</programlisting>
- La définition du trigger est la même qu'avant. Notez que chaque
+ La définition du déclencheur ne change pas. Chaque
test <literal>IF</literal> doit correspondre exactement à la
- contrainte <literal>CHECK</literal> pour cette partition.
+ contrainte <literal>CHECK</literal> de cette partition.
</para>
<para>
- Bien que cette fonction soit plus complexe que le cas du mois seul,
- elle n'a pas besoin d'être mise à jour aussi fréquemment car les
- branches peuvent être ajoutées avant le besoin.
+ Bien que cette fonction soit plus complexe que celle du mois seul,
+ il n'est pas nécessaire de l'actualiser aussi fréquemment, les branches
+ pouvant être ajoutées avant d'être utiles.
</para>
<note>
<para>
- En pratique, il pourrait être mieux de vérifier en premier la
- dernière partition créée si la plupart des insertions vont dans
- cette partition. Pour des raisons de simplicité, nous avons
- montré les tests du trigger dans le même ordre que les autres
- parties de cet exemple.
+ En pratique, il pourrait préférable de vérifier prioritairement la
+ dernière partition créée si la plupart des insertions lui sont
+ destinées. Pour des raisons de simplicité, les tests du déclencheur
+ sont présentés dans le même ordre que les autres parties de l'exemple.
</para>
</note>
</listitem>
@@ -2571,8 +2563,8 @@
inhabituel de supprimer d'anciennes partitions de données et
d'en ajouter périodiquement de nouvelles pour de nouvelles données.
Un des principaux avantages du partitionnement est précisément qu'il
- autorise une exécution quasi-instantanée de cette tâche, autrement bien
- plus difficile, en permettant la manipulation de la structure de la
+ autorise une exécution quasi-instantanée de cette tâche, bien
+ plus difficile autrement, en permettant la manipulation de la structure de la
partition, plutôt que de déplacer physiquement de grands volumes de données.
</para>
@@ -2594,7 +2586,7 @@
avant qu'elles ne soient supprimées. Par exemple, c'est souvent le bon moment
pour sauvegarder les données en utilisant <command>COPY</command>,
<application>pg_dump</application> ou tout autres outil. C'est aussi le
- moment d'agréger des données en des formats plus petits, de réaliser d'autres
+ moment d'agréger des données en des formats plus denses, de réaliser d'autres
opérations sur les données ou de créer des rapports.
</para>
@@ -2714,8 +2706,8 @@
<para>
Une approche différente pour la redirection des insertions dans la
- table fille appropriée est de configurer des règles, au lieu d'un
- trigger, sur la table maître. Par exemple :
+ table fille appropriée est de configurer des règles, à la place d'un
+ déclencheur, sur la table maître. Par exemple :
<programlisting>
CREATE RULE mesure_insert_a2006m02 AS
@@ -2724,39 +2716,38 @@
DO INSTEAD
INSERT INTO mesure_a2006m02 VALUES (NEW.*);
...
-CREATE RULE mesure_insert_y2008m01 AS
+CREATE RULE mesure_insert_a2008m01 AS
ON INSERT TO mesure WHERE
( date_trace >= DATE '2008-01-01' AND date_trace < DATE '2008-02-01' )
DO INSTEAD
INSERT INTO mesure_a2008m01 VALUES (NEW.*);
</programlisting>
- Une règle est plus coûteuse qu'un trigger mais ce coût est payé une fois
- par requête au lieu d'une fois par ligne, donc cette méthode peut être
- avantageuse pour de grosses insertions. Néanmoins, dans la majorité des
+ Une règle est plus coûteuse qu'un déclencheur mais ce coût est payé une fois
+ par requête au lieu d'une fois par ligne, cette méthode peut donc s'avérer
+ avantageuse lors de grosses insertions. Néanmoins, dans la majorité des
cas, la méthode du trigger offre de meilleures performances.
</para>
<para>
- Faites attention au fait que les règles ignorent la commande
- <command>COPY</command>. Si vous voulez utiliser
- <command>COPY</command> pour insérer des données, vous aurez besoin
- d'exécuter cette requête dans la bonne table fille plutôt que dans
- la table maître. <command>COPY</command> exécute les triggers, donc
- vous pouvez les utiliser normalement si vous passez par l'approche
- proposée par les triggers.
+ La commande <command>COPY</command> ignore les règles. Si
+ <command>COPY</command> est utilisé pour insérer des données,
+ la copie doit être effectuée sur la partition adéquate plutôt que dans
+ la table maître. <command>COPY</command> active les déclencheurs. Elle
+ peut donc être utilisée normalement lorsque cette approche est choisie.
</para>
<para>
Un autre inconvénient de la méthode des règles est qu'il n'existe pas
- de moyens simples pour forcer une erreur si l'ensemble des règles
- ne couvre pas la date d'insertion. La donnée ira silencieusement dans
- la table maître.
+ de moyens simples de forcer une erreur si l'ensemble des règles
+ ne couvre pas la date d'insertion. La donnée est alors silencieusement
+ insérée dans la table maître.
</para>
<para>
- Partitioning can also be arranged using a <literal>UNION ALL</literal>
- view, instead of table inheritance. For example,
+ Le partitionnement peut aussi être arrangé à l'aide d'une vue
+ <literal>UNION ALL</literal>, en lieu et place de l'héritage. Par
+ exemple :
<programlisting>
CREATE VIEW mesure AS
@@ -2768,10 +2759,10 @@
UNION ALL SELECT * FROM mesure_a2008m01;
</programlisting>
- Néanmoins, le besoin de créer de nouveau la vue ajoute une étape
+ Néanmoins, le besoin de recréer la vue ajoute une étape
supplémentaire à l'ajout et à la suppression de partitions individuelles
de l'ensemble des données. En pratique, cette méthode a peu d'intérêt
- par rapport à l'héritage.
+ au regard de l'héritage.
</para>
</sect2>
@@ -2786,21 +2777,21 @@
<para>
il n'existe pas de moyen automatique de vérifier que toutes les
contraintes de vérification (<literal>CHECK</literal>) sont mutuellement
- exclusives. Il est plus sûr de créer un code qui génère les
+ exclusives. Il est plus sûr de créer un code qui fabrique les
partitions et crée et/ou modifie les objets associés plutôt que de les
- créer chacun manuellement ;
+ créer manuellement ;
</para>
</listitem>
<listitem>
<para>
- Les schémas montrés ici supposent que les colonnes clés du
+ les schémas montrés ici supposent que les colonnes clés du
partitionnement d'une ligne ne changent jamais ou, tout du moins, ne
changent pas suffisamment pour nécessiter un déplacement vers une
autre partition. Une commande <command>UPDATE</command> qui
- tente de le faire échouera à cause des contraintes
- <literal>CHECK</literal>. Si vous avez besoin de gérer ce type de cas,
- vous pouvez placer des triggers convenables pour la mise à jour sur
+ tente de le faire échoue à cause des contraintes
+ <literal>CHECK</literal>. Pour gérer ce type de cas,
+ des déclencheurs peuvent être convenablement positionnés pour la mise à jour sur
les tables de partition mais cela rend la gestion de la structure
beaucoup plus complexe.
</para>
@@ -2808,13 +2799,13 @@
<listitem>
<para>
- Si vous utilisez manuellement <command>VACUUM</command> ou
- <command>ANALYZE</command>, n'oubliez pas de les utiliser sur chaque
- partition. Une commande comme :
+ si <command>VACUUM</command> ou
+ <command>ANALYZE</command> sont lancés manuellement, il est obligatoire
+ de les utiliser sur chaque partition. Une commande comme :
<programlisting>
ANALYZE mesure;
</programlisting>
- ne traitera que la table maître.
+ ne traite que la table maître.
</para>
</listitem>
</itemizedlist>
@@ -2837,14 +2828,15 @@
<listitem>
<para>
- faites en sorte que les contraintes du partitionnement restent simples.
- Dans le cas contraire, le planificateur peut avoir des difficultés à
- s'assurer que certaines partitions n'ont pas besoin d'être parcourues.
- Utilisez des conditions simples d'égalité pour le partitionnement de
- liste ou des tests d'échelle simple, comme illustré dans les exemples
- précédents. Une bonne règle est que les contraintes de partitionnement
- doivent seulement contenir des comparaisons entre les colonnes de
- partitionnement et des constantes en utilisant des opérateurs
+ les contraintes de partitionnement doivent rester simples.
+ Dans le cas contraire, le planificateur peut rencontrer des difficultés à
+ déterminer les partitions qu'il n'est pas nécessaire de parcourir.
+ Des conditions simples d'égalité pour le partitionnement de
+ liste ou des tests d'échelle simples lors de partitionnement d'échelle
+ sont recommandées, comme cela est illustré dans les exemples
+ précédents. Une bonne règle consiste à s'assurer que les comparaisons
+ entre colonnes de partitionnement et constantes utilisées par les
+ contraintes de partitionnement se fassent uniquement à l'aide d'opérateurs
utilisables par les index B-tree.
</para>
</listitem>
@@ -2853,10 +2845,10 @@
<para>
toutes les contraintes de toutes les partitions de la table maître sont
examinées lors de l'exclusion de contraintes. De ce fait, un grand nombre
- de partitions a tendance à augmenter considérablement le temps de
- planification de la requête. Partitionner en utilisant ces
- techniques fonctionnera bien avec moins de cent partitions ;
- n'essayez pas d'utiliser plusieurs milliers de partitions.
+ de partitions augmente considérablement le temps de
+ planification de la requête. Un partitionnement qui utilise ces
+ techniques fonctionne assez bien jusqu'environ une centaine de partitions ;
+ il est impensable de vouloir atteindre des milliers de partitions.
</para>
</listitem>
@@ -2924,7 +2916,7 @@
</indexterm>
<para>
- Lorsque des structures de base complexes sont créés qui impliquent
+ Lorsque des structures de base complexes sont créées qui impliquent
beaucoup de tables avec des contraintes de clés étrangères, des
vues, des déclencheurs, des fonctions, etc., un réseau de dépendances entre
les objets est implicitement créé.
@@ -2961,11 +2953,11 @@
supprimer individuellement chaque objet dépendant, on peut
lancer
<screen>DROP TABLE produits CASCADE;</screen>
- et tous les objets dépendants seront ainsi effacés. Dans ce cas, cela n'efface pas
- la table des commandes mais seulement la contrainte de clé étrangère.
- (pour vérifier ce que <command>DROP ... CASCADE</command> fait,
+ et tous les objets dépendants sont ainsi effacés. Dans ce cas, la table des
+ commandes n'est pas supprimée, mais seulement la contrainte de clé étrangère.
+ (Pour vérifier ce que fait <command>DROP ... CASCADE</command>, on peut
lancer <command>DROP</command> sans <literal>CASCADE</literal> et lire les messages
- <literal>NOTICE</literal>).
+ <literal>NOTICE</literal>.)
</para>
<para>
@@ -2993,7 +2985,7 @@
<para>
Les dépendances de contraintes de clés étrangères et de colonnes
<foreignphrase>serial</foreignphrase> des versions de <productname>PostgreSQL</productname>
- antérieures à 7.3 ne sont <emphasis>pas</emphasis> maintenues ou
+ antérieures à 7.3 <emphasis>ne</emphasis> sont <emphasis>pas</emphasis> maintenues ou
créées pendant le processus de mise à jour. Tout autre type de
dépendance est proprement créé pendant une mise à jour à partir d'une
base de données antérieure à la 7.3.
Modified: traduc/trunk/postgresql/docguide.xml
===================================================================
--- traduc/trunk/postgresql/docguide.xml 2008-07-08 10:00:50 UTC (rev 1091)
+++ traduc/trunk/postgresql/docguide.xml 2008-07-08 10:52:44 UTC (rev 1092)
@@ -3,7 +3,6 @@
le $Date$
par $Author$
révision $Revision$ -->
-<!-- SAS 20070511, PG624 -->
<appendix id="docguide">
<title>Documentation</title>
@@ -77,8 +76,7 @@
<ulink url="http://www.freebsd.org/docproj/docproj.html">projet de
documentation FreeBSD</ulink> utilise également DocBook et fournit
également de bonnes informations, incluant un certain nombre de
- lignes directrices qu'il peut être bon de prendre en
- considération.
+ lignes directrices qu'il peut être bon de prendre en considération.
</para>
</sect1>
@@ -152,8 +150,7 @@
<para>
Ce paquetage est utilisé pour créer les pages de manuel. Un
certain nombre d'autres paquetages sont nécessaires pour le
- faire fonctionner. Pour plus d'informations, vérifier sur le
- site web.
+ faire fonctionner. Pour plus d'informations, vérifier sur le site web.
</para>
</listitem>
</varlistentry>
@@ -190,7 +187,7 @@
distributions empaquetées de ces outils. Tout
changement du statut d'un paquetage peut être rapportée auprés de
la liste de discussion de la
- documentation, afin d'inclurees ces informations ici-même.
+ documentation, afin d'inclure ces informations ici-même.
</para>
<sect2>
@@ -248,10 +245,9 @@
<para>
Il est probable que les portages ne mettent pas à jour le fichier de
- catalogue général dans
- <filename>/usr/local/share/sgml/catalog.ports</filename> ou que l'ordre ne
- soit pas le bon. Assurez-vous que les lignes suivantes figurent au
- début :
+ catalogue général dans
+ <filename>/usr/local/share/sgml/catalog.ports</filename> ou que l'ordre ne
+ soit pas le bon. Les lignes suivantes doivent figurent au début :
<programlisting>CATALOG "openjade/catalog"
CATALOG "iso8879/catalog"
CATALOG "docbook/dsssl/modular/catalog"
@@ -343,7 +339,7 @@
<step>
<para>
- Enfin, le fichier
+ Enfin, le fichier
<filename>/usr/local/share/sgml/catalog</filename> doit être créé pour
y ajouter la ligne suivante :
<programlisting>CATALOG "dsssl/catalog"
@@ -386,8 +382,7 @@
<para>
Décompresser l'archive.
<screen><prompt>$ </prompt><userinput>unzip -a ...../docbook-4.2.zip</userinput></screen>
- (L'archive décompresse ses fichier dans le répertoire
- courant.)
+ (L'archive décompresse ses fichier dans le répertoire courant.)
</para>
</step>
@@ -479,8 +474,8 @@
<productname>hyperref</productname>,
<productname>minitoc</productname>,
<productname>url</productname> et enfin
- <productname>ot2enc</productname>. Tous ceux-ci peuvent être
- trouvé sur le
+ <productname>ot2enc</productname>. Tous peuvent être
+ trouvés sur le
<ulink url="http://www.ctan.org">site web du <acronym>CTAN</acronym></ulink>.
L'installation du système <application>TeX</application> de base est en
dehors du périmètre de cette introduction. Des paquetages binaires sont
@@ -569,8 +564,8 @@
<para>
Pour créer un bon index, la construction doit se faire en plusieurs étapes
- identiques. Si vous n'avez pas l'utilité de l'index et que vous voulez
- seulement vérifier le résultat, utilisez <literal>draft</literal> :
+ identiques. Si l'index n'est pas utile et qu'il s'agit simplement de
+ vérifier le résultat, on peut utiliser <literal>draft</literal> :
<screen>
<prompt>doc/src/sgml$ </prompt><userinput>gmake draft</userinput>
</screen>
@@ -579,7 +574,7 @@
<para>
Pour simplifier la manipulation de la distribution
finale de la documentation, l'ensemble des fichiers, dont la
- documentation HTML, peut être stocké dans une archive tar qui est
+ documentation HTML, peut être stocké dans une archive tar
décompressée à l'installation. Pour créer le
paquetage <acronym>HTML</acronym>, on utilise les commandes :
<programlisting>cd doc/src
@@ -611,9 +606,9 @@
<para>
Afin de produire des pages man de qualité, il peut
être nécessaire d'utiliser une version modifiée de
- l'utilitaire de conversion ou de faire des modification manuelles
- post-production. Toutes les pages man doivent être manuellement
- vérifiées avant toute distribution.
+ l'utilitaire de conversion ou de faire des modifications manuelles
+ post-production. L'ensemble des pages man doit être manuellement
+ vérifié avant toute distribution.
</para>
</sect2>
@@ -653,7 +648,7 @@
<para>
Lors de l'utilisation de JadeTeX pour la construction de la documentation
- PostgreSQL, vous aurez probablement besoin d'augmenter la valeur de certains
+ PostgreSQL, il est probablement nécessaire d'augmenter la valeur de certains
paramètres internes de TeX. Ils sont configurables dans le fichier
<filename>texmf.cnf</filename>. Les paramètres suivants ont fonctionné
quand ce texte a été écrit :
@@ -679,7 +674,7 @@
Une version imprimable de la documentation de
<productname>PostgreSQL</productname> peut être obtenue en la convertissant en RTF et en y
appliquant des corrections de formatage mineures à l'aide d'une suite de logiciels
- de bureau. En fonction des capacité de cette dernière, la documentation
+ de bureau. En fonction des capacités de cette dernière, la documentation
peut ensuite être convertie dans les formats PostScript et/ou
<acronym>PDF</acronym>. La procédure ci-dessous décrit cette procédure
pour <productname>Applixware</productname>.
@@ -719,12 +714,12 @@
<step performance="required">
<para>
- Réparer le fichier RTF afin de spécifier correctement tous les
+ Réparer le fichier RTF afin de préciser correctement tous les
styles et en particulier le style par défaut (default). Si le document
contient des sections <sgmltag>refentry</sgmltag>, il faut remplacer les
éléments de formatage qui relient le paragraphe précédent au
paragraphe courant par un lien entre le paragraphe courant
- et paragraphe suivant. Un utilitaire, <command>fixrtf</command>, est
+ et le paragraphe suivant. Un utilitaire, <command>fixrtf</command>, est
disponible dans <filename>doc/src/sgml</filename> afin de permettre ces
corrections :
<screen><prompt>doc/src/sgml$ </prompt><userinput>./fixrtf --refentry postgres.rtf</userinput>
@@ -865,7 +860,7 @@
<step>
<para>
- sélectionnez le menu <menuchoice><guimenu>Tools</guimenu><guisubmenu>Book
+ sélectionner le menu <menuchoice><guimenu>Tools</guimenu><guisubmenu>Book
Building</guisubmenu><guimenuitem>Create Table of
Contents</guimenuitem></menuchoice> ;
</para>
@@ -949,7 +944,7 @@
<para>
<acronym>SGML</acronym> et <productname>DocBook</productname> ne souffrent
- pas du foisonnement d'outils d'édition open-source. Le plus commun
+ pas du foisonnement d'outils d'édition OpenSource. Le plus commun
d'entre eux est l'éditeur
<productname>Emacs</productname>/<productname>XEmacs</productname> qui
dispose d'un mode d'édition approprié. Sur certains systèmes, ces outils
@@ -1059,7 +1054,6 @@
</sect1>
-<!-- ICI -->
<sect1 id="docguide-style">
<title>Guide des styles</title>
@@ -1075,7 +1069,7 @@
<productname>PostgreSQL</productname>, mais également pour les pages de
références fournies par le système d'exploitation et les autres paquetages.
C'est pour cela que les règles suivantes ont été développées. Elles sont, pour la
- plupart cohérentes avec les règles similaires établies pour
+ plupart, cohérentes avec les règles similaires établies pour
différents systèmes d'exploitation.
</para>
@@ -1261,7 +1255,7 @@
n'est nécessaire que si la commande renvoie autre chose
qu'un complément de commande par défaut. La section
<quote>Compatibilité</quote> doit
- expliquer dans quelle mesure une commande se conforme au(x) standard(s) SQL,
+ expliquer dans quelle mesure une commande se conforme au standard SQL,
ou avec quel autre système de gestion de base de données elle est
compatible. La section <quote>Voir aussi</quote> des commandes SQL doit lister les
commandes SQL avant de faire de faire référence aux programmes.
More information about the Trad
mailing list