Changeset 1092

Show
Ignore:
Timestamp:
07/08/08 12:52:44 (5 months ago)
Author:
sas
Message:

et de d...
--Cett, les suivantes ci-dessous, seront ignorées--

M postgresql/ddl.xml
M postgresql/docguide.xml

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved
  • traduc/trunk/postgresql/ddl.xml

    r973 r1092  
    44     par      $Author$ 
    55     révision $Revision$ --> 
    6 <!-- SAS : 20070410, PG 8.2.3 --> 
    76 
    87<chapter id="ddl"> 
     
    5150  <para> 
    5251   De plus, le SQL n'attribue pas d'identifiant unique aux lignes. Il est 
    53    donc possible 
    54    d'avoir plusieurs lignes identiques au sein d'une table. C'est une 
    55    conséquence du modèle mathématique sur lequel repose le SQL, même si 
    56    cela n'est habituellement pas souhaitable. 
     52   donc possible d'avoir plusieurs lignes identiques au sein d'une table. 
     53   C'est une conséquence du modèle mathématique sur lequel repose le SQL, 
     54   même si cela n'est habituellement pas souhaitable. 
    5755   Il est expliqué plus bas dans ce chapitre comment traiter ce problème. 
    5856  </para> 
    5957 
    6058  <para> 
    61    Chaque colonne a un type de donnée. Ce type de donnée limite l'ensemble 
     59   Chaque colonne a un type de données. Ce type limite l'ensemble 
    6260   de valeurs qu'il est possible d'attribuer à une colonne. Il attribue 
    6361   également une sémantique aux données stockées dans la colonne pour 
     
    142140  </tip> 
    143141 
    144 <!-- Par contre, utilisé par Céline dans un souci de provocation, n'est à 
    145 l'évidence pas une construction grammaticale préconisée par l'Académie 
    146 Française. On lui préférera "En revanche", "Cependant", "Au contraire"... --> 
     142<!-- Par contre, utilisé par Céline (pas Dion, mais Louis-Ferdinand) dans un 
     143souci de provocation, n'est à l'évidence pas une construction grammaticale 
     144préconisée par l'Académie Française. On lui préférera "En revanche", 
     145"Cependant", "Au contraire"... --> 
    147146  <para> 
    148147   Le nombre de colonnes d'un table est limité. En fonction du type de 
     
    168167   d'erreur sont alors ignorés afin que le script fonctionne que la table 
    169168   existe ou non. (La variante <literal>DROP TABLE IF EXISTS</literal> peut 
    170    aussi être utilisée pour 
    171    éviter les messages d'erreur mais elle ne fait pas partie du 
     169   aussi être utilisée pour éviter les messages d'erreur mais elle ne fait pas partie du 
    172170   standard SQL.) 
    173171  </para> 
     
    182180   fonctionnelles. Le reste de ce chapitre est consacré à l'ajout de fonctionnalités 
    183181   à la définition de tables pour garantir l'intégrité des données, la sécurité 
    184    ou l'ergonomie. Le lecteur impatient d'insérer des données dans ses tables 
     182   ou l'ergonomie. Le lecteur impatient d'insérer des données dans ses tables 
    185183   peut sauter au <xref linkend="dml"/> et lire le reste de 
    186184   ce chapitre plus tard. 
     
    296294    générique qui soit. Elle permet d'indiquer que la valeur 
    297295    d'une colonne particulière doit satisfaire une expression booléenne 
    298     (valeur de vérité). Par 
    299     exemple, pour obliger les prix des produits à être positifs, on peut 
    300     utiliser&nbsp;: 
     296    (valeur de vérité). Par exemple, pour obliger les prix des produits 
     297    à être positifs, on peut utiliser&nbsp;: 
    301298<programlisting>CREATE TABLE produits ( 
    302299    no_produit integer, 
     
    363360   <para> 
    364361    Les deux premières contraintes sont appelées contraintes de 
    365     colonnes tandis que la troisième est appelée contrainte de table parce 
     362    colonne tandis que la troisième est appelée contrainte de table parce 
    366363    qu'elle est écrite séparément d'une définition de colonne particulière. 
    367     Les contraintes de colonnes peuvent être écrites comme des contraintes de 
    368     tables, mais l'inverse n'est pas forcément possible puisqu'une contrainte de colonne est 
     364    Les contraintes de colonne peuvent être écrites comme des contraintes de 
     365    table, mais l'inverse n'est pas forcément possible puisqu'une contrainte de colonne est 
    369366    supposée ne faire référence qu'à la colonne à laquelle elle est 
    370367    attachée (<productname>PostgreSQL</productname> ne vérifie pas cette règle 
     
    455452 
    456453   <para> 
    457     Une colonne peut évidemment avoir plus d'une contrainte. Il suffit 
     454    Une colonne peut évidemment avoir plusieurs contraintes. Il suffit 
    458455    d'écrire les contraintes les unes après les autres&nbsp;: 
    459456<programlisting>CREATE TABLE produits ( 
     
    470467    <literal>NULL</literal>. Elle ne signifie pas que la colonne doit 
    471468    être NULL, ce qui est assurément inutile, mais sélectionne le comportement 
    472     par défaut, à savoir que la colonne peut être NULL. La contrainte <literal>NULL 
    473     </literal> n'est pas présente dans le standard SQL et ne doit pas 
     469    par défaut, à savoir que la colonne peut être NULL. La contrainte 
     470    <literal>NULL</literal> n'est pas présente dans le standard SQL et ne doit pas 
    474471    être utilisée dans des applications portables (elle n'a été ajoutée 
    475472    dans <productname>PostgreSQL</productname> que pour assurer la 
    476473    compatibilité avec d'autres bases de données). Certains utilisateurs 
    477474    l'apprécient néanmoins car elle permet de basculer aisément d'une 
    478     contrainte à l'autre dans un ficheir de script. On peut, par exemple, commencer avec&nbsp;: 
     475    contrainte à l'autre dans un fichier de script. On peut, par exemple, commencer avec&nbsp;: 
    479476<programlisting>CREATE TABLE produits ( 
    480477    no_produit integer NULL, 
     
    487484   <tip> 
    488485    <para> 
    489      Dans la plupart des bases de données, la majorité des 
    490      colonnes peut être marquée NOT NULL. 
     486     Dans la plupart des bases de données, il est préférable que la majorité des 
     487     colonnes soient marquées NOT NULL. 
    491488    </para> 
    492489   </tip> 
     
    620617 
    621618       <para> 
    622         Une table a au plus une clé primaire. (Le nombre de contraintes UNIQUE NOT NULL, 
     619        Une table a, au plus, une clé primaire. (Le nombre de contraintes UNIQUE NOT NULL, 
    623620        qui assurent la même fonction, n'est pas limité, mais une seule 
    624621        peut être identifiée comme clé primaire.) La théorie des 
     
    699696        Une clé étrangère peut aussi contraindre et référencer un groupe de colonnes. 
    700697        Comme cela a déjà été évoqué, il faut alors l'écrire sous forme d'une contrainte de table. 
    701         Voici un exemple de syntaxe&nbsp;: 
     698        Exemple de syntaxe&nbsp;: 
    702699    <programlisting>CREATE TABLE t1 ( 
    703700      a integer PRIMARY KEY, 
     
    985982   compteur unique sur le cluster. Dans une base de données volumineuse ou 
    986983   agée, il est possible que le compteur boucle. Il est de ce fait peu 
    987    pertinent de 
    988    considérer que les OID puissent être uniques&nbsp;; pour identifier les 
    989    lignes d'une table, il est fortement 
    990    recommandé d'utiliser un générateur de séquence. 
    991    Néanmoins, les OID peuvent également être utilisés sous réserve que quelques 
    992    précautions soient prises&nbsp;: 
     984   pertinent de considérer que les OID puissent être uniques&nbsp;; pour 
     985   identifier les lignes d'une table, il est fortement recommandé d'utiliser 
     986   un générateur de séquence. Néanmoins, les OID peuvent également être 
     987   utilisés sous réserve que quelques précautions soient prises&nbsp;: 
    993988   
    994989  <itemizedlist> 
     
    10421037    De plus, à partir de <productname>PostgreSQL</productname> 8.3, seules les 
    10431038    commandes qui modifient réellement le contenu de la base de données 
    1044     consommeront un identifiant de commande. 
     1039    consomment un identifiant de commande. 
    10451040  </para> 
    10461041 </sect1> 
     
    11091104 
    11101105   <para> 
    1111     La commande d'ajout d'une colonne ressemble à celle-ci&nbsp;: 
     1106    La commande d'ajout d'une colonne ressemble à&nbsp;: 
    11121107<programlisting>ALTER TABLE produits ADD COLUMN description text;</programlisting> 
    11131108    La nouvelle colonne est initialement remplie avec la valeur par défaut 
     
    11951190   <indexterm> 
    11961191    <primary>contrainte</primary> 
    1197     <secondary>retirer</secondary> 
     1192    <secondary>supprimer</secondary> 
    11981193   </indexterm> 
    11991194 
     
    13631358  <para> 
    13641359   La commande <command>GRANT</command> est 
    1365    utilisée pour accorder des privilèges (on dit aussi granter un privilège). 
     1360   utilisée pour accorder des privilèges (on dit aussi « granter un privilège »). 
    13661361   Par exemple, si <literal>joe</literal> 
    13671362   est un utilisateur et <literal>comptes</literal> une table, le 
     
    14171412  <para> 
    14181413   Un cluster de bases de données <productname>PostgreSQL</productname> 
    1419    contient une ou plusieurs bases nommées. Si les utilisateurs et groupes 
     1414   contient une ou plusieurs base(s) nommée(s). Si les utilisateurs et groupes 
    14201415   d'utilisateurs sont partagés sur l'ensemble du cluster, aucune 
    1421    autre donnée n'est partagée. Une connexion cliente 
    1422    donnée sur le serveur ne peut accéder qu'aux données d'une seule base, celle 
     1416   autre donnée n'est partagée. Toute connexion cliente 
     1417   au serveur ne peut accéder qu'aux données d'une seule base, celle 
    14231418   indiquée dans la requête de connexion. 
    14241419  </para> 
     
    14341429  </note> 
    14351430 
    1436   <para> 
    1437    Une base de données contient un ou plusieurs <firstterm>schémas</firstterm> 
    1438    nommés qui, eux, contiennent des tables. Les schémas contiennent aussi d'autres 
     1431<!-- Je ne sais pas si coller le (s) à la suite de la balise fermante passe... 
     1432--> 
     1433  <para> 
     1434   Une base de données contient un ou plusieurs 
     1435   <firstterm>schéma</firstterm>(s) nommé(s) qui, eux, contiennent des 
     1436   tables. Les schémas contiennent aussi d'autres 
    14391437   types d'objets nommés (types de données, fonctions et opérateurs, par 
    14401438   exemple). 
     
    14541452    <listitem> 
    14551453     <para> 
    1456       pour autoriser de nombreux utilisateurs à utiliser une base de données 
    1457       sans interférences entre eux&nbsp;; 
     1454      autoriser de nombreux utilisateurs à utiliser une base de données 
     1455      sans interférer avec les autres&nbsp;; 
    14581456     </para> 
    14591457    </listitem> 
     
    14611459    <listitem> 
    14621460     <para> 
    1463       pour organiser les objets de la base de données en groupes logiques afin de faciliter 
     1461      organiser les objets de la base de données en groupes logiques afin de faciliter 
    14641462      leur gestion&nbsp;; 
    14651463     </para> 
     
    15031501 
    15041502   <para> 
    1505     Pour créer ou accéder aux objets d'un schéma, on écrit un 
     1503    Pour créer les objets d'un schéma ou y accéder, on écrit un 
    15061504    <firstterm>nom qualifié</firstterm> constitué du nom du schéma et 
    15071505    du nom de la table séparés par un point&nbsp;: 
    15081506<synopsis><replaceable>schema</replaceable><literal>.</literal><replaceable>table</replaceable></synopsis> 
    1509     Cela fonctionne partout où un nom de table est attendu, ce qui inclue les 
     1507    Cela fonctionne partout où un nom de table est attendu, ce qui inclut les 
    15101508    commandes de modification de la table et les commandes d'accès aux données 
    15111509    discutées dans les chapitres suivants. (Pour des raisons de 
    1512     simplification, il n'est question que de tables, mais les mêmes principes  
    1513     s'appliquent à d'autres types d'objets nommés, comme les types et les 
     1510    simplification, seules les tables sont évoquées, mais les mêmes principes  
     1511    s'appliquent aux autres objets nommés, comme les types et les 
    15141512    fonctions.) 
    15151513   </para> 
    15161514    
    15171515   <para> 
    1518     En fait, la syntaxe encore plus générale 
     1516    La syntaxe encore plus générale 
    15191517<synopsis><replaceable>base</replaceable><literal>.</literal><replaceable>schema</replaceable><literal>.</literal><replaceable>table</replaceable></synopsis> 
    15201518    peut aussi être utilisée, mais à l'heure actuelle, cette syntaxe n'existe 
     
    16071605    liste de schémas dans lesquels chercher. La première table correspondante 
    16081606    est considérée comme la table voulue. S'il n'y a pas de correspondance, une 
    1609     erreur est remontée, même si des noms de table correspondant existent dans 
    1610     d'autres schémas de la base. 
     1607    erreur est remontée, quand bien même il existerait des tables dont le nom 
     1608    correspond dans d'autres schémas de la base. 
    16111609   </para> 
    16121610 
     
    16401638 
    16411639   <para> 
    1642     C'est, par défaut, dans le premier schéma du chemin de recherche qui existe que sont 
    1643     créés les nouveaux objets. C'est la raison 
     1640    C'est, par défaut, dans le premier schéma du chemin de recherche qui 
     1641    existe que sont créés les nouveaux objets. C'est la raison 
    16441642    pour laquelle les objets sont créés, par défaut, dans le schéma public. 
    16451643    Lorsqu'il est fait référence à un objet, dans tout autre contexte, sans 
     
    16541652<programlisting>SET search_path TO mon_schema,public;</programlisting> 
    16551653    (<literal>$user</literal> est omis à ce niveau car il n'est pas 
    1656     immédiatement nécessaire.) Il est alors possible d'à la table sans 
    1657     qualification par un schéma&nbsp;: 
     1654    immédiatement nécessaire.) Il est alors possible d'accéder à la table 
     1655    sans qu'elle soit qualifiée par un schéma&nbsp;: 
    16581656<programlisting>DROP TABLE ma_table;</programlisting> 
    16591657    Puisque <literal>mon_schema</literal> est le premier élément du 
     
    16781676    Le chemin de recherche fonctionne de la même façon pour les noms de type de 
    16791677    données, les noms de fonction et les noms d'opérateur que pour les noms de 
    1680     tables. Les noms des types de données et des fonctions peuvent être qualifiés de la 
     1678    table. Les noms des types de données et des fonctions peuvent être qualifiés de la 
    16811679    même façon que les noms de table. S'il est nécessaire d'écrire un nom 
    16821680    d'opérateur qualifié dans une expression, il y a une condition 
    16831681    spéciale. Il faut écrire&nbsp;: 
    16841682<synopsis><literal>OPERATOR(</literal><replaceable>schéma</replaceable><literal>.</literal><replaceable>opérateur</replaceable><literal>)</literal></synopsis> 
    1685     Cela afin d'éviter toute ambiguïté syntaxique. En voici un 
    1686     exemple 
     1683    Cela afin d'éviter toute ambiguïté syntaxique. Par exemple&nbsp;: 
    16871684<programlisting>SELECT 3 OPERATOR(pg_catalog.+) 4;</programlisting> 
    16881685    En pratique, il est préférable de s'en remettre au chemin de recherche pour les opérateurs, 
     
    17041701    propriétaire du schéma doit granter le droit <literal>USAGE</literal> sur 
    17051702    le schéma. Pour autoriser les utilisateurs à manipuler les objets d'un 
    1706     schéma, des privilèges supplémentaires doivent peut-être être accordés, en 
     1703    schéma, des privilèges supplémentaires doivent éventuellement être accordés, en 
    17071704    fonction de l'objet. 
    17081705   </para> 
    17091706 
    17101707   <para> 
    1711     Un utilisateur peut aussi être autorisé à créer des objets dans 
    1712     schéma de quelqu'un d'autre. Pour cela, le privilège 
     1708    Un utilisateur peut aussi être autorisé à créer des objets dans le 
     1709    schéma d'un d'autre. Pour cela, le privilège 
    17131710    <literal>CREATE</literal> sur le schéma doit être accordé. Par défaut, 
    17141711    tout le monde bénéficie des droits <literal>CREATE</literal> et 
     
    17771774       ont implicitement accès au schéma public. Cela permet de simuler une 
    17781775       situation dans laquelle les schémas ne sont pas disponibles. 
    1779        Cette situation est essentiellement recommandée pour les utilisateurs 
    1780        seuls ou quelques d'utilisateurs concurents au sein d'une base de 
    1781        données. Cette configuration permet aussi une transition 
    1782        en douceur depuis un monde où les schémas sont inconnus&nbsp;; 
     1776       Cette situation est essentiellement recommandée lorsqu'il n'y a qu'un 
     1777       utilisateur, ou un très petit nombre d'utilisateurs qui coopèrent au 
     1778       sein d'une base de données. Cette configuration permet aussi d'opérer  
     1779       une transition en douceur depuis un monde où les schémas sont inconnus&nbsp;; 
    17831780      </para> 
    17841781     </listitem> 
     
    17861783     <listitem> 
    17871784      <para> 
    1788        un schéma peut être créé pour chaque utilisateur, avec un 
    1789        nom identique à celui de l'utilisateur. Le 
    1790        chemin de recherche par défaut commence par 
    1791        <literal>$user</literal>, ce qui correspond au nom de l'utilisateur. 
    1792        Si chaque utilisateur dispose d'un schéma distinct, tout utilisateur accède, par 
    1793        défaut, à son propre schéma. 
     1785       pour chaque utilisateur, un schéma, de nom identique à celui de 
     1786       l'utilisateur, peut être créé. Le chemin de recherche par défaut 
     1787       commence par <literal>$user</literal>, soit le nom de l'utilisateur. 
     1788       Si tous les utilisateurs disposent d'un schéma distinct, ils accèdent, par 
     1789       défaut, à leur propre schéma. 
    17941790     <!--  </para> 
    17951791 
     
    17971793       Dans cette configuration, il est possible de révoquer l'accès 
    17981794       au schéma public (voire de supprimer ce schéma) 
    1799        pour contraindre les utilisateurs à leur propre schéma&nbsp;; 
     1795       pour confiner les utilisateurs dans leur propre schéma&nbsp;; 
    18001796      </para> 
    18011797     </listitem> 
     
    18091805       pour permettre aux autres utilisateurs d'y accéder. Les utilisateurs 
    18101806       peuvent alors se référer à ces objets additionnels en qualifiant 
    1811        leurs noms du nom de schéma ou ajouter les schémas 
     1807       leur nom du nom de schéma ou ajouter les schémas 
    18121808       supplémentaires dans leur chemin de recherche, au choix. 
    18131809      </para> 
     
    18211817 
    18221818   <para> 
    1823     Dans le standard SQL, la notion d'objets du même schéma 
     1819    Dans le standard SQL, la notion d'objets d'un même schéma 
    18241820    appartenant à des utilisateurs différents n'existe pas. De plus, 
    18251821    certaines implantations ne permettent pas de créer des 
    1826     schémas qui ont un nom différent de celui de leur propriétaire. 
     1822    schémas de nom différent de celui de leur propriétaire. 
    18271823    En fait, les concepts de schéma et d'utilisateur sont presque 
    18281824    équivalents dans un système de base de données qui n'implante 
     
    18471843    <foreignphrase>namespace</foreignphrase> en 
    18481844    autorisant (peut-être de façon limitée) l'accès inter-bases 
    1849     de données. Dans ce cas, la portabilité maximale sera obtenue en n'utilisant 
     1845    de données. Dans ce cas, la portabilité maximale est obtenue en n'utilisant 
    18501846    pas les schémas. 
    18511847   </para> 
     
    18791875   sont pas des capitales. Mais, que se passe-t'il dans le cas où toutes 
    18801876   les données d'une ville doivent être récupérées, qu'elle soit une capitale 
    1881    ou non&nbsp;? 
    1882    L'héritage peut aider à résoudre ce problème. La 
     1877   ou non&nbsp;? L'héritage peut aider à résoudre ce problème. La 
    18831878   table <structname>capitales</structname> est définie pour hériter de 
    18841879   <structname>villes</structname>&nbsp;: 
     
    19021897  <para> 
    19031898   Dans <productname>PostgreSQL</productname>, une table peut hériter de zéro 
    1904    à plusieurs autres tables et une requête faire référence à toutes 
    1905    les lignes d'une table ou à toutes les lignes d'une table plus celles 
     1899   à plusieurs autres tables et une requête faire référence aux 
     1900   lignes d'une table ou à celles d'une table et de ses 
    19061901   des descendantes. Ce dernier comportement est celui par défaut. 
    19071902  </para> 
    19081903  <para> 
    1909    Par 
    1910    exemple, la requête suivante retourne les noms et altitudes de toutes les villes, y compris 
    1911    les capitales, situées à une altitude supérieure à 500 pieds&nbsp;: 
     1904   Par exemple, la requête suivante retourne les noms et altitudes de toutes 
     1905   les villes, y compris les capitales, situées à une altitude supérieure 
     1906   à 500 pieds&nbsp;: 
    19121907 
    19131908<programlisting>SELECT nom, altitude 
     
    19151910    WHERE altitude &gt; 500;</programlisting> 
    19161911 
    1917    Étant donné les données du tutoriel de <productname>PostgreSQL</productname> 
     1912   Avec les données du tutoriel de <productname>PostgreSQL</productname> 
    19181913   (voir <xref linkend="tutorial-sql-intro"/>), ceci renvoie&nbsp;: 
    19191914 
     
    19521947 
    19531948  <para> 
    1954   Dans certain cas, il peut être intéressant de savoir de quelle table provient une ligne 
     1949  Dans certains cas, il peut être intéressant de savoir de quelle table provient une ligne 
    19551950  donnée. Une colonne système appelée <structfield>TABLEOID</structfield> 
    19561951  présente dans chaque table donne la table d'origine&nbsp;: 
     
    19681963   139798 | Madison   |      845</programlisting> 
    19691964 
    1970    (La reproduction de cet exemple conduira probablement à des 
     1965   (Reproduire cet exemple conduit probablement à des 
    19711966   OID numériques différents). Une jointure avec 
    19721967   <structname>pg_class</structname>, permet d'obtenir les noms réels des tables&nbsp;: 
     
    19931988<programlisting>INSERT INTO villes (nom, population, altitude, etat) 
    19941989VALUES ('New York', NULL, NULL, 'NY');</programlisting> 
    1995    On peut espérer que les données soient magiquement routées vers la table 
    1996    <structname>capitales</structname> mais cela n'arrive pas&nbsp;: 
     1990   On pourrait espérer que les données soient magiquement routées vers la table 
     1991   <structname>capitales</structname> mais ce n'est pas le cas&nbsp;: 
    19971992   <command>INSERT</command> insère toujours dans la table indiquée. Dans 
    19981993   certains cas, il est possible de rediriger l'insertion en utilisant une 
     
    20132008  <para> 
    20142009   Une table peut hériter de plusieurs tables, auquel cas elle possède 
    2015    l'union des colonnes définies par les tables parents. Toute colonne déclarée 
    2016    dans la définition de la table enfant est ajoutée à celles-ci. Si le même nom 
    2017    de colonne apparaît dans plusieurs tables parent, ou à la fois dans une 
    2018    table parent et dans la définition de la table enfant, alors ces colonnes sont 
     2010   l'union des colonnes définies par les tables mèress. Toute colonne déclarée 
     2011   dans la définition de la table enfant est ajoutée à cette dernière. Si le même nom 
     2012   de colonne apparaît dans plusieurs tables mères, ou à la fois dans une 
     2013   table mère et dans la définition de la table enfant, alors ces colonnes sont 
    20192014   <quote>assemblées</quote> pour qu'il n'en existe qu'une dans la table 
    20202015   enfant. Pour être assemblées, les colonnes doivent avoir le même type de 
     
    20252020 
    20262021  <para> 
    2027    L'héritage de table est typiquement établi lors de la création de la table 
    2028    enfant en utilisant la clause <literal>INHERITS</literal> de l'instruction 
     2022   L'héritage de table est établi à la création de la table 
     2023   enfant, à l'aide de la clause <literal>INHERITS</literal> de l'instruction 
    20292024   <xref linkend="sql-createtable" endterm="sql-createtable-title"/>. 
    2030    Alternativement, il est possible d'ajouter à une table déjà définie de façon 
    2031    compatible une nouvelle relation de parenté à l'aide de la clause 
     2025   Alternativement, il est possible d'ajouter à une table, définie de façon 
     2026   compatible, une nouvelle relation de parenté à l'aide de la clause 
    20322027   <literal>INHERIT</literal> de 
    20332028   <xref linkend="sql-altertable" endterm="sql-altertable-title"/>. Pour cela, 
     
    20552050   <literal>INCLUDING CONSTRAINTS</literal> de <literal>LIKE</literal> doit 
    20562051   être indiquée car le nouvel enfant doit avoir des contraintes qui 
    2057    correspondent à celles du parent pour être considéré compatible. 
    2058   </para> 
    2059  
    2060   <para> 
    2061    Une table parent ne peut pas être supprimée tant qu'elle a des enfants. 
     2052   correspondent à celles du parent pour être considérée compatible. 
     2053  </para> 
     2054 
     2055  <para> 
     2056   Une table mère ne peut pas être supprimée tant qu'elle a des enfants. 
    20622057   Pas plus que les colonnes de tables enfants ne peuvent être supprimées ou 
    2063    modifiées si elles sont héritées d'une table parent
     2058   modifiées si elles sont héritées
    20642059   La suppression d'une table et de tous ces descendants peut être aisément 
    2065    obtenue en supprimant la table parent avec l'option 
     2060   obtenue en supprimant la table mère avec l'option 
    20662061   <literal>CASCADE</literal>. 
    20672062  </para> 
     
    20712066   propage toute modification dans les définitions des colonnes et  
    20722067   contraintes de vérification à travers la hiérarchie d'héritage. Là encore, 
    2073    supprimer des colonnes ou des contraintes sur des tables parentes n'est possible 
     2068   supprimer des colonnes ou des contraintes sur des tables mèrees n'est possible 
    20742069   qu'avec l'option <literal>CASCADE</literal>. <command>ALTER TABLE</command> 
    20752070   suit les mêmes règles d'assemblage de colonnes dupliquées et de rejet que  
     
    20772072  </para> 
    20782073 
    2079 <!-- caveats != hints --> 
     2074<!-- caveats != hints  
     2075    Je parlerai de chausse-trappe --> 
    20802076 <sect2 id="ddl-inherit-caveats"> 
    20812077  <title>Restrictions</title> 
     
    20922088  <para> 
    20932089    Il existe une réelle limitation à la fonctionnalité d'héritage&nbsp;: les index 
    2094     (ce qui inclue les contraintes d'unicité) et les contraintes de clés étrangères 
    2095     ne s'appliquent qu'aux tables, pas à leurs héritiers. Cela 
    2096     est vrai pour le côté référençant et le côté référencé d'une contrainte 
     2090    (dont les contraintes d'unicité) et les contraintes de clés étrangères 
     2091    ne s'appliquent qu'aux tables mères, pas à leurs héritiers. Cela 
     2092    est valable pour le côté référençant et le côté référencé d'une contrainte 
    20972093    de clé étrangère. Ce qui donne, dans les termes de l'exemple ci-dessus&nbsp;: 
    20982094 
     
    21052101          <structname>capitales</structname> de posséder des lignes 
    21062102          avec des noms dupliqués dans <structname>villes</structname>. Et ces lignes 
    2107           dupliquées s'affichent par défaut dans les requêtes sur 
    2108           <structname>villes</structname>. En fait, par défaut, 
    2109           <structname>capitales</structname> n'a pas de contrainte 
    2110           d'unicité du tout et, du coup, peut contenir plusieurs lignes avec le 
    2111           même nom. Une contrainte d'unicité peut être ajoutée à 
    2112           <structname>capitales</structname> mais cela n'empêche pas la duplication 
    2113           avec <structname>villes</structname>&nbsp;; 
     2103          upliquées s'affichent par défaut dans les requêtes sur 
     2104          <structname>villes</structname>. En fait, par défaut, 
     2105          <structname>capitales</structname> n'a pas de contrainte 
     2106          d'unicité du tout et, du coup, peut contenir plusieurs lignes avec le 
     2107          même nom. Une contrainte d'unicité peut être ajoutée à 
     2108          <structname>capitales</structname> mais cela n'empêche pas la duplication 
     2109          avec <structname>villes</structname>&nbsp;; 
    21142110        </para> 
    21152111      </listitem> 
     
    21172113      <listitem> 
    21182114        <para> 
    2119           de façon similaire, s'il faut préciser que 
     2115          de façon similaire, si 
    21202116          <structname>villes</structname>.<structfield>nom</structfield> fait référence 
    21212117          (<literal>REFERENCES</literal>) à une autre table, cette contrainte 
     
    21302126      <listitem> 
    21312127        <para> 
    2132           l'indication que la colonne d'une autre table <literal>REFERENCES 
    2133           villes(nom)</literal> autorise l'autre table à contenir les noms des 
    2134           villes mais pas les noms des capitales. Il n'existe pas de 
    2135           contournement efficace de ce cas. 
     2128          si une autre table indique <literal>REFERENCES villes(nom)</literal>, 
     2129          cela l'autorise à contenir les noms des villes mais pas les noms des 
     2130          capitales. Il n'existe pas de contournement efficace de ce cas. 
    21362131        </para> 
    21372132      </listitem> 
     
    21472142   <para> 
    21482143     Dans les versions de <productname>PostgreSQL</productname> antérieures à 
    2149      la 7.1, le comportement par défaut consistait à ne pas inclure les tables enfants dans les 
     2144     7.1, le comportement par défaut consistait à ne pas inclure les tables enfants dans les 
    21502145     requêtes. Il s'est avéré que cela était source d'erreur et violait le 
    21512146     standard SQL. Ce comportement peut être retrouvé en désactivant le 
     
    21572152  </sect1> 
    21582153 
    2159 <!-- ICI --> 
    21602154  <sect1 id="ddl-partitioning"> 
    21612155   <title>Partitionnement</title> 
     
    22002194     <para> 
    22012195      lorsque les requêtes ou les mises à jour accèdent à un important pourcentage 
    2202       d'une unique partition, les performances peuvent être grandement améliorées 
     2196      d'une seule partition, les performances peuvent être grandement améliorées 
    22032197      par l'utilisation avantageuse de parcours séquentiels sur cette 
    22042198      partition plutôt que d'utiliser un index et des lectures aléatoires 
     
    22562250      <listitem> 
    22572251       <para> 
    2258         La table est partitionnée en <quote>groupes</quote> (ou échelles) définis par une 
     2252        La table est partitionnée en <quote>intervalles</quote> (ou échelles) 
     2253        définis par une 
    22592254        colonne clé ou par un ensemble de colonnes, sans recouvrement entre 
    22602255        les échelles de valeurs affectées aux différentes partitions. Il est 
     
    23742369     Soit la base de données d'une grande fabrique de glaces. La compagnie 
    23752370     mesure le pic de température journalier ainsi que les ventes de glaces 
    2376      dans chaque région. Conceptuellement, la table ressemble à cela&nbsp;: 
     2371     dans chaque région. Conceptuellement, la table ressemble à&nbsp;: 
    23772372 
    23782373<programlisting>CREATE TABLE mesure ( 
     
    24322427      <listitem> 
    24332428       <para> 
    2434         Nous devons fournir des contraintes de table qui interdisent les 
     2429        Il est nécessaire de fournir des contraintes de table qui interdisent les 
    24352430        recouvrements. Plutôt que de simplement créer les tables de la 
    2436         partition comme ci-dessus, le script de création de tables devrait 
    2437         ressembler à ceci&nbsp;: 
     2431        partition comme ci-dessus, le script de création de tables ressemble 
     2432        à&nbsp;; 
    24382433 
    24392434<programlisting>CREATE TABLE mesure_a2006m02 ( 
     
    24732468      <listitem> 
    24742469       <para> 
    2475         Nous voulons que notre application soit capable de dire 
    2476         <literal>INSERT INTO mesure...</literal> et que les données soient 
    2477         redirigées dans la table de partition appropriée. Nous pouvons 
    2478         arranger cela en attachant une fonction trigger à la table maître. 
     2470        L'application doit dire <literal>INSERT INTO mesure...</literal> et les 
     2471        données être redirigées dans la table de partition appropriée. Pour 
     2472        cela une fonction déclencheur est attachée à la table maître. 
    24792473        Si les données ne sont ajoutées que dans la dernière partition, 
    2480         nous pouvons utiliser une fonction trigger très simple. 
     2474        la fonction est très simple. 
    24812475 
    24822476<programlisting> 
     
    24912485</programlisting> 
    24922486 
    2493         Après avoir créé la fonction, nous pouvons créer un trigger qui 
    2494         appelle la fonction trigger&nbsp;: 
     2487        Le déclencheur qui appelle la fonction est créé à sa suite&nbsp;: 
    24952488 
    24962489<programlisting> 
     
    25002493</programlisting> 
    25012494 
    2502         Nous devons redéfinir la fonction trigger chaque mois pour qu'il 
    2503         pointe toujours sur partition en cours. Par contre, la définition du 
    2504         trigger n'a pas besoin d'être mise à jour
     2495        La fonction déclencheur doit être redéfinie chaque mois pour qu'elle 
     2496        pointe toujours sur la partition active. La définition du déclencheur 
     2497        n'a pas besoin d'être redéfinie
    25052498       </para> 
    25062499 
     
    25082501        Il est également possible de laisser le serveur localiser la partition 
    25092502        dans laquelle doit être insérée la ligne proposée en entrée. Une 
    2510         fonction trigger permet d'obtenir ce résultat&nbsp;: 
     2503        fonction déclencheur plus complexe peut être utilisée pour cela&nbsp;: 
    25112504 
    25122505<programlisting> 
     
    25302523</programlisting> 
    25312524 
    2532         La définition du trigger est la même qu'avant. Notez que chaque 
     2525        La définition du déclencheur ne change pas. Chaque 
    25332526        test <literal>IF</literal> doit correspondre exactement à la 
    2534         contrainte <literal>CHECK</literal> pour cette partition. 
    2535        </para> 
    2536  
    2537        <para> 
    2538         Bien que cette fonction soit plus complexe que le cas du mois seul, 
    2539         elle n'a pas besoin d'être mise à jour aussi fréquemment car les 
    2540         branches peuvent être ajoutées avant le besoin
     2527        contrainte <literal>CHECK</literal> de cette partition. 
     2528       </para> 
     2529 
     2530       <para> 
     2531        Bien que cette fonction soit plus complexe que celle du mois seul, 
     2532        il n'est pas nécessaire de l'actualiser aussi fréquemment, les branches 
     2533        pouvant être ajoutées avant d'être utiles
    25412534       </para> 
    25422535 
    25432536       <note> 
    25442537        <para> 
    2545          En pratique, il pourrait être mieux de vérifier en premier la 
    2546          dernière partition créée si la plupart des insertions vont dans 
    2547          cette partition. Pour des raisons de simplicité, nous avons 
    2548          montré les tests du trigger dans le même ordre que les autres 
    2549          parties de cet exemple. 
     2538         En pratique, il pourrait préférable de vérifier prioritairement la 
     2539         dernière partition créée si la plupart des insertions lui sont 
     2540         destinées. Pour des raisons de simplicité, les tests du déclencheur 
     2541         sont présentés dans le même ordre que les autres parties de l'exemple. 
    25502542        </para> 
    25512543       </note> 
     
    25722564     d'en ajouter périodiquement de nouvelles pour de nouvelles données. 
    25732565     Un des principaux avantages du partitionnement est précisément qu'il 
    2574      autorise une exécution quasi-instantanée de cette tâche, autrement bien 
    2575      plus difficile, en permettant la manipulation de la structure de la 
     2566     autorise une exécution quasi-instantanée de cette tâche, bien 
     2567     plus difficile autrement, en permettant la manipulation de la structure de la 
    25762568     partition, plutôt que de déplacer physiquement de grands volumes de données. 
    25772569   </para> 
     
    25952587     pour sauvegarder les données en utilisant <command>COPY</command>, 
    25962588     <application>pg_dump</application> ou tout autres outil. C'est aussi le 
    2597      moment d'agréger des données en des formats plus petits, de réaliser d'autres 
     2589     moment d'agréger des données en des formats plus denses, de réaliser d'autres 
    25982590     opérations sur les données ou de créer des rapports. 
    25992591   </para> 
     
    27152707    <para> 
    27162708     Une approche différente pour la redirection des insertions dans la 
    2717      table fille appropriée est de configurer des règles, au lieu d'un 
    2718      trigger, sur la table maître. Par exemple&nbsp;: 
     2709     table fille appropriée est de configurer des règles, à la place d'un 
     2710     déclencheur, sur la table maître. Par exemple&nbsp;: 
    27192711 
    27202712<programlisting> 
     
    27252717    INSERT INTO mesure_a2006m02 VALUES (NEW.*); 
    27262718... 
    2727 CREATE RULE mesure_insert_y2008m01 AS 
     2719CREATE RULE mesure_insert_a2008m01 AS 
    27282720ON INSERT TO mesure WHERE 
    27292721    ( date_trace &gt;= DATE '2008-01-01' AND date_trace &lt; DATE '2008-02-01' ) 
     
    27322724</programlisting> 
    27332725 
    2734      Une règle est plus coûteuse qu'un trigger mais ce coût est payé une fois 
    2735      par requête au lieu d'une fois par ligne, donc cette méthode peut être 
    2736      avantageuse pour de grosses insertions. Néanmoins, dans la majorité des 
     2726     Une règle est plus coûteuse qu'un déclencheur mais ce coût est payé une fois 
     2727     par requête au lieu d'une fois par ligne, cette méthode peut donc s'avérer 
     2728     avantageuse lors de grosses insertions. Néanmoins, dans la majorité des 
    27372729     cas, la méthode du trigger offre de meilleures performances. 
    27382730    </para> 
    27392731 
    27402732    <para> 
    2741      Faites attention au fait que les règles ignorent la commande 
    2742      <command>COPY</command>. Si vous voulez utiliser 
    2743      <command>COPY</command> pour insérer des données, vous aurez besoin 
    2744      d'exécuter cette requête dans la bonne table fille plutôt que dans 
    2745      la table maître. <command>COPY</command> exécute les triggers, donc 
    2746      vous pouvez les utiliser normalement si vous passez par l'approche 
    2747      proposée par les triggers. 
     2733     La commande <command>COPY</command> ignore les règles. Si 
     2734     <command>COPY</command> est utilisé pour insérer des données,  
     2735     la copie doit être effectuée sur la partition adéquate plutôt que dans 
     2736     la table maître. <command>COPY</command> active les déclencheurs. Elle 
     2737     peut donc être utilisée normalement lorsque cette approche est choisie. 
    27482738    </para> 
    27492739 
    27502740    <para> 
    27512741     Un autre inconvénient de la méthode des règles est qu'il n'existe pas 
    2752      de moyens simples pour forcer une erreur si l'ensemble des règles 
    2753      ne couvre pas la date d'insertion. La donnée ira silencieusement dans 
    2754      la table maître. 
     2742     de moyens simples de forcer une erreur si l'ensemble des règles 
     2743     ne couvre pas la date d'insertion. La donnée est alors silencieusement 
     2744     insérée dans la table maître. 
    27552745    </para> 
    27562746 
    27572747    <para> 
    2758      Partitioning can also be arranged using a <literal>UNION ALL</literal> 
    2759      view, instead of table inheritance.  For example, 
     2748     Le partitionnement peut aussi être arrangé à l'aide d'une vue  
     2749     <literal>UNION ALL</literal>, en lieu et place de l'héritage.  Par 
     2750     exemple&nbsp;: 
    27602751 
    27612752<programlisting> 
     
    27692760</programlisting> 
    27702761 
    2771      Néanmoins, le besoin de créer de nouveau la vue ajoute une étape 
     2762     Néanmoins, le besoin de recréer la vue ajoute une étape 
    27722763     supplémentaire à l'ajout et à la suppression de partitions individuelles 
    27732764     de l'ensemble des données. En pratique, cette méthode a peu d'intérêt 
    2774      par rapport à l'héritage. 
     2765     au regard de l'héritage. 
    27752766    </para> 
    27762767 
     
    27872778      il n'existe pas de moyen automatique de vérifier que toutes les 
    27882779      contraintes de vérification (<literal>CHECK</literal>) sont mutuellement 
    2789       exclusives. Il est plus sûr de créer un code qui génère les 
     2780      exclusives. Il est plus sûr de créer un code qui fabrique les 
    27902781      partitions et crée et/ou modifie les objets associés plutôt que de les 
    2791       créer chacun manuellement&nbsp;; 
     2782      créer manuellement&nbsp;; 
    27922783     </para> 
    27932784    </listitem> 
     
    27952786    <listitem> 
    27962787     <para> 
    2797       Les schémas montrés ici supposent que les colonnes clés du 
     2788      les schémas montrés ici supposent que les colonnes clés du 
    27982789      partitionnement d'une ligne ne changent jamais ou, tout du moins, ne 
    27992790      changent pas suffisamment pour nécessiter un déplacement vers une 
    28002791      autre partition. Une commande  <command>UPDATE</command> qui 
    2801       tente de le faire échouera à cause des contraintes 
    2802       <literal>CHECK</literal>. Si vous avez besoin de gérer ce type de cas, 
    2803       vous pouvez placer des triggers convenables pour la mise à jour sur 
     2792      tente de le faire échoue à cause des contraintes 
     2793      <literal>CHECK</literal>. Pour gérer ce type de cas, 
     2794      des déclencheurs peuvent être convenablement positionnés pour la mise à jour sur 
    28042795      les tables de partition mais cela rend la gestion de la structure 
    28052796      beaucoup plus complexe. 
     
    28092800    <listitem> 
    28102801     <para> 
    2811       Si vous utilisez manuellement <command>VACUUM</command> ou 
    2812       <command>ANALYZE</command>, n'oubliez pas de les utiliser sur chaqu
    2813       partition. Une commande comme&nbsp;: 
     2802      si <command>VACUUM</command> ou 
     2803      <command>ANALYZE</command> sont lancés manuellement, il est obligatoir
     2804      de les utiliser sur chaque partition. Une commande comme&nbsp;: 
    28142805<programlisting> 
    28152806ANALYZE mesure; 
    28162807</programlisting> 
    2817       ne traitera que la table maître. 
     2808      ne traite que la table maître. 
    28182809     </para> 
    28192810    </listitem> 
     
    28382829    <listitem> 
    28392830     <para> 
    2840       faites en sorte que les contraintes du partitionnement restent simples. 
    2841       Dans le cas contraire, le planificateur peut avoir des difficultés à 
    2842       s'assurer que certaines partitions n'ont pas besoin d'être parcourues. 
    2843       Utilisez des conditions simples d'égalité pour le partitionnement de 
    2844       liste ou des tests d'échelle simple, comme illustré dans les exemples 
    2845       précédents. Une bonne règle est que les contraintes de partitionnement 
    2846       doivent seulement contenir des comparaisons entre les colonnes de 
    2847       partitionnement et des constantes en utilisant des opérateurs 
     2831      les contraintes de partitionnement doivent rester simples. 
     2832      Dans le cas contraire, le planificateur peut rencontrer des difficultés à 
     2833      déterminer les partitions qu'il n'est pas nécessaire de parcourir. 
     2834      Des conditions simples d'égalité pour le partitionnement de 
     2835      liste ou des tests d'échelle simples lors de partitionnement d'échelle 
     2836      sont recommandées, comme cela est illustré dans les exemples 
     2837      précédents. Une bonne règle consiste à s'assurer que les comparaisons 
     2838      entre colonnes de partitionnement et constantes utilisées par les 
     2839      contraintes de partitionnement se fassent uniquement à l'aide d'opérateurs 
    28482840      utilisables par les index B-tree. 
    28492841     </para> 
     
    28542846      toutes les contraintes de toutes les partitions de la table maître sont 
    28552847      examinées lors de l'exclusion de contraintes. De ce fait, un grand nombre 
    2856       de partitions a tendance à augmenter considérablement le temps de 
    2857       planification de la requête. Partitionner en utilisant ces 
    2858       techniques fonctionnera bien avec moins de cent partitions&nbsp;; 
    2859       n'essayez pas d'utiliser plusieurs milliers de partitions. 
     2848      de partitions augmente considérablement le temps de 
     2849      planification de la requête. Un partitionnement qui utilise ces 
     2850      techniques fonctionne assez bien jusqu'environ une centaine de partitions&nbsp;; 
     2851      il est impensable de vouloir atteindre des milliers de partitions. 
    28602852     </para> 
    28612853    </listitem> 
     
    29252917 
    29262918  <para> 
    2927    Lorsque des structures de base complexes sont créés qui impliquent 
     2919   Lorsque des structures de base complexes sont créées qui impliquent 
    29282920   beaucoup de tables avec des contraintes de clés étrangères, des 
    29292921   vues, des déclencheurs, des fonctions, etc., un réseau de dépendances entre 
     
    29622954   lancer 
    29632955<screen>DROP TABLE produits CASCADE;</screen> 
    2964    et tous les objets dépendants seront ainsi effacés. Dans ce cas, cela n'efface pa
    2965    la table des commandes mais seulement la contrainte de clé étrangère. 
    2966    (pour vérifier ce que <command>DROP ... CASCADE</command> fait, 
     2956   et tous les objets dépendants sont ainsi effacés. Dans ce cas, la table de
     2957   commandes n'est pas supprimée, mais seulement la contrainte de clé étrangère. 
     2958   (Pour vérifier ce que fait <command>DROP ... CASCADE</command>, on peut 
    29672959   lancer <command>DROP</command> sans <literal>CASCADE</literal> et lire les messages 
    2968    <literal>NOTICE</literal>). 
     2960   <literal>NOTICE</literal>.) 
    29692961  </para> 
    29702962 
     
    29942986    Les dépendances de contraintes de clés étrangères et de colonnes 
    29952987    <foreignphrase>serial</foreignphrase> des versions de <productname>PostgreSQL</productname> 
    2996     antérieures à 7.3 ne sont <emphasis>pas</emphasis> maintenues ou 
     2988    antérieures à 7.3 <emphasis>ne</emphasis> sont <emphasis>pas</emphasis> maintenues ou 
    29972989    créées pendant le processus de mise à jour. Tout autre type de 
    29982990    dépendance est proprement créé pendant une mise à jour à partir d'une 
  • traduc/trunk/postgresql/docguide.xml

    r973 r1092  
    44     par      $Author$ 
    55     révision $Revision$ --> 
    6 <!-- SAS 20070511, PG624 --> 
    76 
    87<appendix id="docguide"> 
     
    7877  documentation FreeBSD</ulink> utilise également DocBook et fournit 
    7978  également de bonnes informations, incluant un certain nombre de 
    80   lignes directrices qu'il peut être bon de prendre en 
    81   considération. 
     79  lignes directrices qu'il peut être bon de prendre en considération. 
    8280  </para> 
    8381 </sect1>