root/traduc/branches/bv803/manuel/ddl.sgml

<!-- $Header: /var/lib/cvs/pgsql-fr/sgml/ddl.sgml,v 1.11 2005/07/15 06:14:21 guillaume Exp $ -->

<chapter id="ddl">
 <title>Définition des données</title>

 <para>
  Ce chapitre couvre la création de structures de données qui contiendront
  les données de quelqu'un. Dans une base relationnelle, les données brutes
  sont stockées dans des tables. Du coup, la plus grande partie de ce chapitre
  sera consacrée à l'explication de la création et de la modification des tables 
  et des fonctions disponibles pour contrôler les données stockées dans les tables.
  Ensuite, nous discuterons de l'organisation de tables en schémas, et comment
  des droits peuvent être attribués aux tables. Enfin,
  nous verrons brièvement d'autres fonctionnalités, tel que les vues, les fonctions
  et les déclencheurs.
 </para>

 <sect1 id="ddl-basics">
  <title>Bases sur les tables</title>

  <indexterm zone="ddl-basics">
   <primary>table</primary>
  </indexterm>

  <indexterm>
   <primary>rangée</primary>
  </indexterm>

  <indexterm>
   <primary>colonne</primary>
  </indexterm>

  <para>
   Une table dans une base relationnelle ressemble beaucoup à un tableau
   sur papier&nbsp;: elle est constituée de rangées et de colonnes. Le nombre
   et l'ordre des colonnes sont fixés et chaque colonne a un nom. Le
   nombre de rangées est variable -- il représente la quantité de données
   stockées à un moment donné. SQL n'apporte aucune garantie sur l'ordre des
   rangées dans une table. Quand une table est lue, les rangées
   apparaîtront dans un ordre aléatoire sauf si un tri est demandé
   explicitement. Ceci est couvert dans <xref linkend="queries">. De plus,
   SQL n'attribue pas d'identifiant unique aux rangées. Du coup, il est possible
   d'avoir plusieurs rangées complètement identiques dans une table. Ceci
   est une conséquence du modèle mathématique sur lequel repose SQL mais
   n'est habituellement pas désiré.
   Plus tard dans ce chapitre, nous verrons comment traiter ce problème.
  </para>

  <para>
   Chaque colonne a un type de donnée. Ce type de donnée restreint la série
   de valeurs possibles qui peuvent être attribuées à une colonne et attribue
   des sémantiques à la donnée stockée dans la colonne pour qu'elles puissent
   être utilisées pour des calculs. Par exemple, une colonne déclarée comme
   étant d'un type numérique n'acceptera pas une chaîne arbitraire de texte,
   et les données stockées dans une telle table peuvent être utilisées dans
   des calculs mathématiques.
   Par opposition, une colonne déclarée comme étant de type chaîne de
   caractères acceptera pratiquement n'importe quel type de donnée mais ne
   se prêtera pas à des calculs mathématiques bien que d'autres opérations
   tel que la concaténation des chaînes sont disponibles.
  </para>

  <para>
   <productname>PostgreSQL</productname> inclut une série conséquente de types
   de données intégrés qui correspondent à plusieurs applications. Les
   utilisateurs peuvent aussi définir leurs propres types de données. La
   plupart des types de données intégrés ont des noms et des sémantiques
   évidents alors nous reportons une explication détaillée à <xref
   linkend="datatype">. Quelques-uns des types les plus utilisés sont
   <type>integer</type> pour les entiers, <type>numeric</type> pour
   les nombres pouvant être fractionnels, <type>text</type> pour les chaînes de
   caractères, <type>date</type> pour les dates, <type>time</type> pour
   les valeurs de type heure et <type>timestamp</type> pour les valeurs
   contenant et une date et une heure.
  </para>

  <indexterm>
   <primary>table</primary>
   <secondary>création</secondary>
  </indexterm>

  <para>
   Pour créer une table, il faut utiliser la commande bien nommée <command>CREATE
   TABLE</command>. Dans cette commande, vous devez spécifier au moins le nom de la
   nouvelle table, les noms des colonnes et le type de données pour chacune des
   colonnes. Par exemple&nbsp;:
<programlisting>
CREATE TABLE ma_premiere_table (
    premiere_colonne text,
    deuxieme_colonne integer
);
</programlisting>
   Ceci crée une table nommée <literal>ma_premiere_table</literal> avec
   deux colonnes. La première colonne est nommée
   <literal>premiere_colonne</literal> et a un type de données
   <type>text</type>&nbsp;; la seconde colonne porte le nom
   <literal>deuxieme_colonne</literal> et le type <type>integer</type>.
   Les noms de table et colonnes suivent la syntaxe d'identification expliquée
   dans <xref linkend="sql-syntax-identifiers">.  Les noms des types sont souvent
   aussi des identifiants mais il y a des exceptions. Notez que la liste des
   colonnes est séparée par des virgules et entourée par des parenthèses.
  </para>

  <para>
   Bien sur, l'exemple précédant est un peu tiré par les cheveux. Normalement,
   on donne aux tables et aux colonnes des noms indiquant quels types de données
   ils stockent. Alors voyons un exemple plus réaliste&nbsp;:
<programlisting>
CREATE TABLE produits (
    no_produit integer,
    nom text,
    prix numeric
);
</programlisting>
   (Le type <type>numeric</type> peut stocker des composants fractionnels
   comme on pourrait s'y attendre de montants monétaires.)
  </para>

  <tip>
   <para>
    Quand vous créez des tables liées entre elles, il est prudent de choisir
    des règles de nommage pour les tables et les colonnes. Par exemple, il
    peut y avoir le choix d'utiliser des noms au pluriel ou au singulier
    pour les noms de table, chaque choix ayant les faveurs d'un théoricien
    ou d'un autre.
   </para>
  </tip>

  <para>
   Il y a une limite sur le nombre de colonnes qu'une table peut contenir.
   Suivant le type de colonne, elle peut être entre 250 et 1600.
   Par contre, définir une table avec un nombre de colonnes proche de ceux-ci
   est très inhabituel et est souvent la preuve d'une conception douteuse.
  </para>

  <indexterm>
   <primary>table</primary>
   <secondary>suppression</secondary>
  </indexterm>

  <para>
   Si vous n'avez plus besoin d'une table, vous pouvez la retirer en utilisant
   la commande <command>DROP TABLE</command>. Par exemple&nbsp;:
<programlisting>
DROP TABLE ma_premiere_table;
DROP TABLE produits;
</programlisting>
   Tenter de supprimer une table qui n'existe pas est une erreur.
   Malgré cela, il est habituel dans des fichiers de scripts SQL d'essayer
   de supprimer chaque table avant de la créer, tout en ignorant les messages
   d'erreur.
  </para>

  <para>
   Si vous avez besoin de modifier une table qui existe déjà, regardez <xref
   linkend="ddl-alter"> plus loin dans ce chapitre.
  </para>

  <para>
   Avec les outils dont nous avons déjà discuté, vous pouvez 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 la facilité.  Si vous êtes impatients de remplir vos tables avec des données
   tout de suite, vous pouvez sauter au <xref linkend="dml"> et lire le reste de
   ce chapitre plus tard.
  </para>
 </sect1>

 <sect1 id="ddl-default">
  <title>Valeurs par défaut</title>

  <indexterm zone="ddl-default">
   <primary>valeur par défaut</primary>
  </indexterm>

  <para>
   On peut attribuer une valeur par défaut à une colonne. Quant une nouvelle
   rangée est créée et aucune valeur n'est spécifiée pour certaines de ses
   colonnes, celles-ci sont remplies avec leur valeur par défaut respective.
   Une commande de manipulation de données peut aussi demander explicitement
   qu'une colonne soit mise à sa valeur par défaut sans avoir à connaître la
   valeur en question. (Les détails sur les commandes de manipulation de données
   sont dans <xref linkend="dml">.)
  </para>

  <para>
   <indexterm><primary>valeur NULL</primary><secondary>valeur par défaut</secondary></indexterm>
   Si aucune valeur par défaut n'est déclarée explicitement, la valeur
   par défaut est la valeur NULL. Ceci est d'habitude cohérent car on
   peut considérer que la valeur NULL représente des données inconnues.
  </para>

  <para>
   Dans une définition de table, les valeurs par défaut sont listées après
   le type de donnée de la colonne. Par exemple:
<programlisting>
CREATE TABLE products (
    product_no integer,
    name text,
    price numeric <emphasis>DEFAULT 9.99</emphasis>
);
</programlisting>
  </para>

  <para>
   La valeur par défaut peut être une expression, qui
   sera évaluée à l'insertion de la valeur par défaut
   (<emphasis>pas</emphasis> à la création de la table.) Un exemple habituel
   est qu'une colonne de type timestamp pourrait avoir une valeur par défaut
   <literal>now()</>, de façon à ce qu'il obtienne la valeur de l'heure au
   moment de l'insertion. Un autre exemple habituel est la génération d'un
   <quote>numéro de série</> pour chaque ligne.
   Dans <productname>PostgreSQL</productname>, ceci se fait habituellement par
   quelque chose comme
<programlisting>
        CREATE TABLE products (
        product_no integer <emphasis>DEFAULT nextval('products_product_no_seq')</emphasis>,
        ...
        );
</programlisting>
   où la fonction <literal>nextval()</> fournit des valeurs successives à
   partir d'une <firstterm>objet séquence</> (voir <xref
   linkend="functions-sequence">). Cet arrangement est suffisamment commun
   pour qu'il y ait un raccourci pour lui&nbsp;:
<programlisting>
        CREATE TABLE products (
        product_no <emphasis>SERIAL</emphasis>,
        ...
        );
</programlisting>
   Le raccourci <literal>SERIAL</> est discuté plus tard dans <xref
   linkend="datatype-serial">.
  </para>
 </sect1>

 <sect1 id="ddl-constraints">
  <title>Contraintes</title>

  <indexterm zone="ddl-constraints">
   <primary>contrainte</primary>
  </indexterm>

  <para>
   Les types de données sont un moyen de limiter ce qui peut être stocké
   dans une table. Pour beaucoup d'applications, par contre, la contrainte
   qu'elles appliquent sont trop fortes. Par exemple, une colonne qui
   contient le prix d'un produit ne devrait accepter que des valeurs
   positives. Mais il n'y a pas de type de données qui n'acceptent que
   des valeurs positives. Un autre problème est le fait de vouloir limiter
   les données d'une colonne par rapport à d'autres colonnes ou rangées.
   Par exemple, dans une table contenant des informations de produit, il
   ne devrait y avoir qu'une rangée pour chaque numéro de produit.
  </para>

  <para>
   Dans ce but, SQL vous permet de définir les contraintes sur les colonnes
   et les tables. Les contraintes vous donnent autant de contrôle sur les
   données de vos tables que vous désirez. Si un utilisateur tente de stocker
   des données dans une colonne qui violerait un contrainte, une erreur est
   soulevée. Ceci s'applique même si la valeur vient de la définition de la
   valeur par défaut.
  </para>

  <sect2>
   <title>Contraintes de Vérification</title>

   <indexterm>
    <primary>contrainte de vérification</primary>
   </indexterm>

   <indexterm>
    <primary>contrainte</primary>
    <secondary>vérification</secondary>
   </indexterm>

   <para>
    Une contrainte de vérification est le type de contrainte le plus
    générique qui soit. Elle vous permet de spécifier l'expression
    d'une certaine colonne doit satisfaire une expression booléenne. Par
    exemple, pour obliger des prix de produits positifs, on pourrait
    utiliser&nbsp;:
<programlisting>
CREATE TABLE products (
    product_no integer,
    name text,
    price numeric <emphasis>CHECK (price &gt; 0)</emphasis>
);
</programlisting>
   </para>

   <para>
    Comme vous pouvez le voir, la définition de contrainte vient après
    le type de données comme les définitions de valeur par défaut. Les
    valeurs par défaut et les contraintes peuvent être données dans
    n'importe quel ordre. Une contrainte de vérification s'utilise avec
    le mot clé <literal>CHECK</literal> suivi d'une expression entre
    parenthèses. L'expression de contrainte de vérification peut
    impliquer la colonne ainsi contrainte, sinon la contrainte n'aurait
    pas beaucoup de sens.
   </para>

   <indexterm>
    <primary>contrainte</primary>
    <secondary>nom</secondary>
   </indexterm>

   <para>
    Vous pouvez aussi donner à la contrainte un nom diffèrent. Ceci
    clarifie les messages d'erreur et vous permet de faire référence
    à la contrainte lorsque vous avez besoin de la modifier.
    La syntaxe est:
<programlisting>
CREATE TABLE products (
    product_no integer,
    name text,
    price numeric <emphasis>CONSTRAINT positive_price</emphasis> CHECK (price &gt; 0)
);
</programlisting>
    Alors, pour spécifier une contrainte nommée, utilisez le mot-clé
    <literal>CONSTRAINT</literal> suivi d'un identifiant et de la
    définition de contrainte. (Si vous ne donnez pas de nom à la contrainte,
    le système choisira un nom pour vous.)
   </para>

   <para>
    Une contrainte de vérification peut faire référence à plusieurs
    colonnes. Admettons que vous souhaitez stocker un prix normal et un
    prix de promotion et, être sur que le prix de
    promotion soit inférieur au prix normal.
<programlisting>
CREATE TABLE products (
    product_no integer,
    name text,
    price numeric CHECK (price &gt; 0),
    discounted_price numeric CHECK (discounted_price &gt; 0),
    <emphasis>CHECK (price &gt; discounted_price)</emphasis>
);
</programlisting>
   </para>

   <para>
    Les deux premières contraintes devrait vous être familières. La troisième
    utilise une nouvelle syntaxe. Elle n'est pas attachée à une colonne
    particulière, elle apparaît comme un élément distinct dans
    la liste de colonnes séparées par des virgules. Les définitions de
    colonnes et ces définitions de contraintes peut être définies dans
    un ordre quelconque.
   </para>

   <para>
    On dit que les deux premières contraintes sont des contraintes de
    colonnes tandis que la troisième est une contrainte de table parce
    qu'elle est écrite séparément de toute définition de colonne tandis que
    l'inverse n'est pas forcément possible car une contrainte de colonne est
    supposé faire uniquement référence à la colonne à laquelle elle est
    attachée. (<productname>PostgreSQL</productname> ne force pas cette règle
    mais vous devriez la suivre si vous voulez que les définitions de votre
    table fonctionnent avec d'autres systèmes de bases de données.) 
    L'exemple ci-dessus aurait pu s'écrire&nbsp;:
<programlisting>
CREATE TABLE products (
    product_no integer,
    name text,
    price numeric,
    CHECK (price &gt; 0),
    discounted_price numeric,
    CHECK (discounted_price &gt; 0),
    CHECK (price &gt; discounted_price)
);
</programlisting>
    ou même
<programlisting>
CREATE TABLE products (
    product_no integer,
    name text,
    price numeric CHECK (price &gt; 0),
    discounted_price numeric,
    CHECK (discounted_price &gt; 0 AND price &gt; discounted_price)
);
</programlisting>
    C'est une question de goût.
   </para>

   <para>
    Des noms peuvent être affectés à des contraintes de table de la même
    façon que les contraintes de colonne&nbsp;:
     <programlisting>
       CREATE TABLE products (
       product_no integer,
       name text,
       price numeric,
       CHECK (price &gt; 0),
       discounted_price numeric,
       CHECK (discounted_price &gt; 0),
       <emphasis>CONSTRAINT valid_discount</> CHECK (price &gt; discounted_price)
     );
     </programlisting>
   </para>

   <indexterm>
    <primary>valeur NULL</primary>
    <secondary sortas="check constraints">avec contraintes de vérification</secondary>
   </indexterm>

   <para>
    Il faut noter qu'une contrainte de vérification est satisfaite si
    l'expression est évaluée à vrai ou la valeur NULL. Puisque la
    plupart des expressions seront évaluées à la valeur NULL si l'un
    des opérandes est NULL, elles n'empêchent pas les valeurs NULL
    dans les colonnes contraintes. Pour s'assurer qu'une colonne ne
    contient pas de valeurs NULL, la contrainte non-NULL décrite
    dans la section suivante peut être utilisée.
   </para>
  </sect2>

  <sect2>
   <title>Contraintes Non NULL</title>

   <indexterm>
    <primary>contrainte non NULL</primary>
   </indexterm>

   <indexterm>
    <primary>contrainte</primary>
    <secondary>NOT NULL</secondary>
   </indexterm>

   <para>
    Une contrainte non NULL dit simplement qu'une colonne ne peut
    pas prendre la valeur NULL. Un exemple de syntaxe:
<programlisting>
CREATE TABLE products (
    product_no integer <emphasis>NOT NULL</emphasis>,
    name text <emphasis>NOT NULL</emphasis>,
    price numeric
);
</programlisting>
   </para>

   <para>
    Une contrainte non NULL est toujours écrite comme une contrainte de
    colonne. Une contrainte non NULL est l'équivalente fonctionnelle de
    créer une contrainte <literal>CHECK (<replaceable>nom_colonne</replaceable>
    IS NOT NULL)</literal>, mais dans <productname>PostgreSQL</productname>,
    créer une contrainte explicitement non NULL est plus efficace.
    L'inconvénient est que vous ne pouvez pas donner de noms explicites
    à des contraintes non NULL créées de cette manière.
   </para>

   <para>
    Bien sur, une colonne peut avoir plus d'une contrainte. Écrivez juste
    les contraintes les unes après les autres:
<programlisting>
CREATE TABLE products (
    product_no integer NOT NULL,
    name text NOT NULL,
    price numeric NOT NULL CHECK (price &gt; 0)
);
</programlisting>
    L'ordre n'importe pas. Il ne détermine pas dans quel ordre les contraintes
    seront vérifiées.
   </para>

   <para>
    La contrainte <literal>NOT NULL</literal> a un opposé; la contrainte
    <literal>NULL</literal> . Ceci ne veut pas dire que la colonne doit
    être NULL, ce qui serait inutile. À la place, ceci sélectionne le comportement
    par défaut que la colonne doit être NULL. La contrainte <literal>NULL
    </literal> n'est pas définie dans le standard SQL et ne devrait pas
    être utilisé 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 car elle facilite le fait d'activer une contrainte
    dans un fichier de script. Par exemple, vous pourriez commencer avec:
<programlisting>
CREATE TABLE products (
    product_no integer NULL,
    name text NULL,
    price numeric NULL
);
</programlisting>
    et puis insérer le mot-clé <literal>NOT</literal> suivant vos besoins.
   </para>

   <tip>
    <para>
     Dans beaucoup de conceptions de bases de données, la majorité des
     colonnes devraient être marquées non NULL.
    </para>
   </tip>
  </sect2>

  <sect2>
   <title>Contraintes Uniques</title>

   <indexterm>
    <primary>contrainte unique</primary>
   </indexterm>

   <indexterm>
    <primary>contrainte</primary>
    <secondary>unique</secondary>
   </indexterm>

   <para>
    Les contraintes uniques garantissent que les données contenues dans
    la colonne ou un groupe de colonnes est unique par rapport à toutes
    les rangées dans la table. La syntaxe est:
<programlisting>
CREATE TABLE products (
    product_no integer <emphasis>UNIQUE</emphasis>,
    name text,
    price numeric
);
</programlisting>
    est écrit comme contrainte de colonne et
<programlisting>
CREATE TABLE products (
    product_no integer,
    name text,
    price numeric,
    <emphasis>UNIQUE (product_no)</emphasis>
);
</programlisting>
    est écrit comme contrainte de table.
   </para>

   <para>
    Si une contrainte unique fait référence à un groupe de colonnes,
    celles-ci sont listées séparées par des virgules:
<programlisting>
CREATE TABLE exemple (
    a integer,
    b integer,
    c integer,
    <emphasis>UNIQUE (a, c)</emphasis>
);
</programlisting>
    Ceci spécifie que la combinaison de valeurs dans les colonnes indiquées
    est unique pour toute la table bien qu'une seule des colonnes puisse ne
    pas être (et habituellement n'est pas) unique.
   </para>

   <para>
    Vous pouvez affecter votre propre nom pour une contrainte unique, de la
    façon habituelle&nbsp;:
<programlisting>
CREATE TABLE products (
    product_no integer <emphasis>CONSTRAINT must_be_different</emphasis> UNIQUE,
    name text,
    price numeric
);
</programlisting>
   </para>

   <indexterm>
    <primary>valeur NULL</primary>
    <secondary sortas="unique constraints">avec contrainte unique</secondary>
   </indexterm>

   <para>
    En général, une contrainte unique est violée lorsqu'il y a au
    moins deux rangées dans une table ou la valeur de toutes les
    colonnes inclus dans la contrainte sont
    égales. Par contre, les valeurs NULL ne sont pas assimilées
    à une égalités dans cette comparaison. Ceci veut dire qu'il est possible
    de stocker un nombre illimité de rangées qui contiennent une
    valeur NULL dans au moins l'une des colonnes contraintes. Ce
    comportement est conforme au standard SQL mais nous avons
    été informé que d'autres bases SQL ne suivent pas cette règle. Alors,
    soyez prudents en développant des applications qui sont prévues
    pour être portable.
   </para>
  </sect2>

  <sect2>
   <title>Clés Primaires</title>

   <indexterm>
    <primary>clé primaire</primary>
   </indexterm>

   <indexterm>
    <primary>contrainte</primary>
    <secondary>clé primaire</secondary>
   </indexterm>

   <para>
    Techniquement, une contrainte de clé primaire est tout
    simplement une combinaison d'une contrainte unique et
    d'une contrainte non NULL. Donc, les définitions de
    tables suivantes accepteront les mêmes données:
<programlisting>
CREATE TABLE products (
    product_no integer UNIQUE NOT NULL,
    name text,
    price numeric
);
</programlisting>

<programlisting>
CREATE TABLE products (
    product_no integer <emphasis>PRIMARY KEY</emphasis>,
    name text,
    price numeric
);
</programlisting>
   </para>

   <para>
    Les clés primaires peuvent contraindre sur plus d'une colonne; la
    syntaxe est semblable aux contraintes uniques:
<programlisting>
CREATE TABLE exemple (
    a integer,
    b integer,
    c integer,
    <emphasis>PRIMARY KEY (a, c)</emphasis>
);
</programlisting>
   </para>

   <para>
    Une clé primaire indique qu'une colonne ou un groupe de colonnes peuvent
    être utilisés comme identifiant unique pour les rangées de la table. (Ceci
    est une conséquence directe de la définition d'une clé primaire. Notez
    qu'une contrainte unique ne donne pas par elle-même, un identifiant unique
    car elle n'exclut pas les valeurs NULL.) Ceci est pratique à la fois
    pour des raisons de documentation et pour les applications clientes. Par
    exemple, une application graphique qui permet de modifier les valeurs de
    rangées a probablement besoin de connaître la clé primaire d'une table pour
    pouvoir identifier les rangées de manière unique correctement.
   </para>

   <para>
    Une table peut avoir au mieux une clé primaire (tandis qu'elle peut
    avoir plusieurs contraintes uniques et non NULL). La théorie des
    bases de données relationnelles dit que chaque table doit avoir
    une clé primaire. Cette règle n'est pas appliquée par
    <productname>PostgreSQL</productname>, mais il vaut mieux la respecter
    autant que possible.
   </para>
  </sect2>

  <sect2 id="ddl-constraints-fk">
   <title>Clés Étrangères</title>

   <indexterm>
    <primary>clé étrangère</primary>
   </indexterm>

   <indexterm>
    <primary>contrainte</primary>
    <secondary>clé étrangère</secondary>
   </indexterm>

   <indexterm>
    <primary>intégrité référentielle</primary>
   </indexterm>

   <para>
    Une contrainte de clé étrangère stipule que les valeurs dans cette
    colonne (ou un groupe de colonnes) doit correspondre aux valeurs
    apparaissant dans des rangées d'une autre table.
    Nous disons que ceci maintient l'<firstterm>intégrité
    référentielle</firstterm> entre deux tables liées.
   </para>

   <para>
    Disons que vous avez la table de produits que nous avons déjà utilisé plusieurs fois:
<programlisting>
CREATE TABLE products (
    product_no integer PRIMARY KEY,
    name text,
    price numeric
);
</programlisting>
    Disons aussi que vous avez une table stockant les commandes de
    ces produits. Nous voulons aussi nous assurer que la table des
    commandes ne contienne que des commandes concernant des produits
    qui existent réellement. Alors, nous définissons une contrainte
    de clé étrangère dans la table des commandes qui référence la
    table produit:
<programlisting>
CREATE TABLE orders (
    order_id integer PRIMARY KEY,
    product_no integer <emphasis>REFERENCES products (product_no)</emphasis>,
    quantity integer
);
</programlisting>
    Maintenant, il est impossible de créer des commandes avec une entrée
    <structfield>product_no</structfield> qui n'apparaît pas dans la table products.
   </para>

   <para>
    Nous disons que, dans cette situation, la table de commandes est la table
    <firstterm>référente</firstterm> et la table products est la table
    <firstterm>référée</firstterm>.  De la même façon, il y a des colonnes
    référentes et des colonnes référées.
   </para>

   <para>
    On peut aussi raccourcir la commande ci-dessus en
<programlisting>
CREATE TABLE orders (
    order_id integer PRIMARY KEY,
    product_no integer <emphasis>REFERENCES products</emphasis>,
    quantity integer
);
</programlisting>
    parce qu'en l'absence d'une liste de colonnes, la clé primaire de la
    table référente est utilisée comme colonne référée.
   </para>

   <para>
    Une clé étrangère peut aussi contraindre et référencer un groupe de colonnes.
    Comme d'habitude, il faut aussi l'écrire sous forme de contrainte de table.
    Voici un exemple de syntaxe:
<programlisting>
CREATE TABLE t1 (
  a integer PRIMARY KEY,
  b integer,
  c integer,
  <emphasis>FOREIGN KEY (b, c) REFERENCES other_table (c1, c2)</emphasis>
);
</programlisting>
    Bien sûr, le nombre et le type des colonnes contraintes doivent correspondre
    au nombre et au type des colonnes référées.
   </para>

   <para>
        Vous pouvez affecter votre propre nom pour une contrainte de clé
        étrangère de la façon habituelle.
   </para>

   <para>
    Une table peut contenir plus d'une contrainte de clé étrangère. Ceci peut
    être utilisé pour implémenter des relations n à n entre tables. Disons
    que vous avez des tables contenant des produits et des commandes mais vous
    voulez maintenant autoriser une commande qui contient peut-être beaucoup
    de produits (ce que la structure ci-dessus ne permet pas). On pourrait
    utiliser cette structure de table:
<programlisting>
CREATE TABLE products (
    product_no integer PRIMARY KEY,
    name text,
    price numeric
);

CREATE TABLE orders (
    order_id integer PRIMARY KEY,
    shipping_address text,
    ...
);

CREATE TABLE order_items (
    product_no integer REFERENCES products,
    order_id integer REFERENCES orders,
    quantity integer,
    PRIMARY KEY (product_no, order_id)
);
</programlisting>
    Notez aussi que la clé primaire chevauche les clés étrangères dans la dernière table.
   </para>

   <indexterm>
    <primary>CASCADE</primary>
    <secondary>action clé étrangère</secondary>
   </indexterm>

   <indexterm>
    <primary>RESTRICT</primary>
    <secondary>action clé étrangère</secondary>
   </indexterm>

   <para>
    Nous savons que les clés étrangères n'autorisent pas la création
    de commandes qui ne sont pas liés à un produit. Et si un produit
    est retiré après qu'une commande qui y réfère soit créée&nbsp;? SQL vous
    permet aussi de le gérer. Intuitivement, nous avons plusieurs options&nbsp;:
    <itemizedlist spacing="compact">
     <listitem><para>Interdire d'effacer un produit référé</para></listitem>
     <listitem><para>Effacer aussi les commandes</para></listitem>
     <listitem><para>Autre chose ?</para></listitem>
    </itemizedlist>
   </para>

   <para>
    Pour illustrer ce cas, implémentons la politique suivante sur
    l'exemple de relations n à n évoquée plus haut: Quand quelqu'un
    veut retirer un produit qui est encore référencé par un ordre
    (via <literal>ordre_items</literal>), on l'interdit. Si quelqu'un
    retire une commande, les éléments de l'ordre sont aussi retirés.
<programlisting>
CREATE TABLE products (
    product_no integer PRIMARY KEY,
    name text,
    price numeric
);

CREATE TABLE orders (
    order_id integer PRIMARY KEY,
    shipping_address text,
    ...
);

CREATE TABLE order_items (
    product_no integer REFERENCES products <emphasis>ON DELETE RESTRICT</emphasis>,
    order_id integer REFERENCES orders <emphasis>ON DELETE CASCADE</emphasis>,
    quantity integer,
    PRIMARY KEY (product_no, order_id)
);
</programlisting>
   </para>

   <para>
     Restreindre les suppressions et supprimer en cascade sont les deux
     options les plus communes. <literal>RESTRICT</literal> empêche la
     suppression d'une ligne référencée. <literal>NO ACTION</literal> signifie
     que si des lignes de références existent lors de la vérification de la 
     contrainte, une erreur est levée&nbsp; ceci est le comportement par
     défaut si vous n'avez rien spécifié. (La différence essentielle entre
     ces deux choix est que <literal>NO ACTION</literal> autorise la
     déférence de la vérification plus tard dans la transaction alors que    
     <literal>RESTRICT</literal> ne le permet pas.) <literal>CASCADE</>
     spécifie que, quand une ligne référencée est supprimée, les lignes la
     référençant devraient aussi être automatiquement supprimées. Il existe
     deux autres options&nbsp;: <literal>SET NULL</literal> et <literal>SET
     DEFAULT</literal>. Celles-ci font que les colonnes de références soient
     initialisées à NULL ou à leur valeur par défaut, respectivement quand la
     ligne référencée est supprimée. Notez qu'elles ne vous excusent pas
     d'observer les contraintes. Par exemple, si une action spécifie 
     <literal>SET DEFAULT</literal> mais que la valeur par défaut ne
     satisferait pas la clé étrangère, l'opération échouera.
   </para>

   <para>
    Sur le même principe que <literal>ON DELETE</literal>, il y a aussi
    <literal>ON UPDATE</literal> qui est évoqué lorsqu'une colonne référencée
    est modifiée (mise à jour). Les actions possibles sont les mêmes.
   </para>

   <para>
    Il y a plus d'informations sur la mise à jour et la suppression de données dans <xref
    linkend="dml">.
   </para>

   <para>
    Enfin, nous devrions dire que la clé étrangère peut référencer
    des colonnes qui sont une clé primaire ou forment une contrainte unique.
    Si la clé étrangère référence une contrainte unique, il y a des
    possibilités supplémentaires selon que l'on souhaite faire correspondre
    les valeurs NULL.
    Ceux-ci sont expliqués dans la documentation de référence pour
    <xref linkend="sql-createtable" endterm="sql-createtable-title">.
   </para>
  </sect2>
 </sect1>

 <sect1 id="ddl-system-columns">
   <title>Colonnes Systèmes</title>
   
   <para>
     Chaque table a plusieurs <firstterm>colonnes systèmes</> qui sont 
     implicitement définis par le système. De ce fait, ces noms ne peuvent
     être utilisés comme noms de colonnes définis par l'utilisateur. (Notez
     que ces restrictions sont différentes si le nom est un mot-clé ou
     pas&nbsp;; citez un nom ne vous permettra pas d'échapper à ces
     restrictions.) Vous n'avez pas vraiment besoin de vous préoccuper de
     ces colonnes, simplement savoir qu'elles existent.
   </para>
 
 <indexterm>
   <primary>colonne</primary>
   <secondary>colonne système</secondary>
 </indexterm>
 
 <variablelist>
   <varlistentry>
     <term><structfield>oid</></term>
     <listitem>
       <para>
        <indexterm>
         <primary>OID</primary>
         <secondary>colonne</secondary>
        </indexterm>
        L'identifiant objet (<foreignphrase>object ID</>) d'une rangée. Ceci
        est un numéro de série qui est automatiquement rajouté par
        <productname>PostgreSQL</productname> à toutes les rangées de tables 
        (sauf si la table a été créée avec <literal>WITHOUT OIDS</literal>,
        auquel cas cette colonne n'est pas présente). Cette colonne est de
        type oid (même nom que la colonne)&nbsp;; voir la <xref
        linkend="datatype-oid"> pour plus d'informations sur ce type.
       </para>
     </listitem>
   </varlistentry>
   
   <varlistentry>
     <term><structfield>tableoid</></term>
   <listitem>
     <indexterm>
       <primary>tableoid</primary>
     </indexterm>
     
     <para>
        L' OID de la table contenant cette rangée. Cette colonne est
        particulièrement utile pour les requêtes qui sélectionnent de
        hiérarchies héritées, puisque sans elle, il est difficile de dire de
        quelle table vient une rangée. <structfield>tableoid</structfield>
        peut être joint à la colonne <structfield>oid</structfield> de
        <structname>pg_class</structname> pour obtenir le nom de la table.
     </para>
   </listitem>
 </varlistentry>
 
 <varlistentry>
   <term><structfield>xmin</></term>
 <listitem>
   <indexterm>
     <primary>xmin</primary>
   </indexterm>
   
   <para>
      L'identité (transaction ID) de la transaction d'insertion de cette 
      version de la rangée. (Une version de rangée est un état individuel
      d'une rangée; chaque mise à jour d'une rangée crée une nouvelle
      version de rangée pour la même rangée logique.)
   </para>
 </listitem>
</varlistentry>

<varlistentry>
  <term><structfield>cmin</></term>
<listitem>
  <indexterm>
    <primary>cmin</primary>
  </indexterm>
  
  <para>
     L'identifiant de commande (à partir de zéro) au sein de la transaction
     d'insertion.
  </para>
</listitem>
</varlistentry>

<varlistentry>
  <term><structfield>xmax</></term>
<listitem>
  <indexterm>
    <primary>xmax</primary>
  </indexterm>
  
  <para>
     L'identité (transaction ID) de la transaction de suppression, ou zéro 
     pour une version de rangée non effacée. Il est possible pour cette
     colonne d'être non NULL dans une version de rangée visible: Ceci
     indique normalement que la transaction de suppression n'a pas été
     effectuée, ou qu'une tentative de suppression a été annulée.
  </para>
</listitem>
</varlistentry>

<varlistentry>
  <term><structfield>cmax</></term>
<listitem>
  <indexterm>
    <primary>cmax</primary>
  </indexterm>
  
  <para>
     L'identifiant de commande au sein d'une transaction de suppression, ou
     zéro.
  </para>
</listitem>
</varlistentry>

<varlistentry>
  <term><structfield>ctid</></term>
<listitem>
  <indexterm>
    <primary>ctid</primary>
  </indexterm>
  
  <para>
     La localisation physique de la version de rangée au sein de sa table.
     Notez que bien que le <structfield>ctid</structfield> peut être utilisé
     pour trouver la version de rangée très rapidement, le
     <structfield>ctid</structfield>  d'une rangée changera chaque fois
     qu'il est mis à jour ou déplacé par la commande <command>VACUUM FULL</>. 
     Donc, <structfield>ctid</structfield> est inutile en tant
     qu'identifiant de rangée à long terme. L'OID, ou encore mieux un numéro
     de série définie par l'utilisateur, devrait être utilisé pour
     identifier des rangées logiques.
</para>
</listitem>
</varlistentry>
</variablelist>

<para>
   Les OID sont des nombres de 32 bits et sont attribués d'un seul
   compteur. Dans une base de données grande ou vieille, il est possible que
   le compteur boucle sur lui-même. Donc il est peu pertinent de partir du
   principe que les OID sont uniques, sauf si vous prenez les précautions
   nécessaires. Si vous avez besoin d'identifier les lignes dans une table,
   l'utilisation d'un générateur de séquence est fortement recommandée.
   Néanmoins, les OID peuvent aussi être utilisés à condition que quelques
   précautions soient prises&nbsp;:
  
  <itemizedlist>
    <listitem>
      <para>
        Une contrainte unique devrait être créée sur la colonne OID de chaque
        table pour laquelle l'OID sera utilisée pour identifier les lignes.
      </para>
    </listitem>
    <listitem>
      <para>
        Les OID ne devraient jamais être supposés uniques entre tables&nbsp;;
        utilisez la combinaison de <structfield>tableoid</> et de l'OID de la
        ligne si vous avez besoin d'un identifiant sur la base complète.
      </para>
    </listitem>
    <listitem>
      <para>
      Les tables en question devraient être créées en utilisant <literal>WITH
      OIDS</literal> pour s'assurer de la compatibilité avec les versions
      futures de <productname>PostgreSQL</productname>. Il est planifié que
      <literal>WITHOUT OIDS</> deviendra l'option par défaut.
      </para>
    </listitem>
  </itemizedlist>
</para>

  <para>
    Les identifiants de transaction sont aussi des nombres de 32 bits. Dans 
    une base de données de longue vie, il est possible pour les ID de
    transaction de boucler sur eux-mêmes. Ceci n'est pas un problème fatal
    avec des procédures de maintenance appropriées; voir le <xref
    linkend="maintenance"> pour les détails. Il est, par contre, imprudent
    de dépendre de l'aspect unique des ID de transaction à long terme (plus
    d'un milliard de transactions).
  </para>
  
  <para>
     Les identifiants de commande sont aussi des nombres de 32 bits. Ceci
     crée une limite dure de 2<superscript>32</> (4 milliards) commandes
     <acronym>SQL</acronym> au sein d'une seule transaction. En pratique,
     cette limite n'est pas un problème &mdash; notez que la limite est sur
     le nombre de commandes <acronym>SQL</acronym>, pas le nombre de rangées
     traitées.
  </para>
</sect1>

 <sect1 id="ddl-inherit">
  <title>Héritage</title>

  <remark>Cette section doit être repensée. Une partie de cette
  information doit aller dans les chapitres suivants.</remark>

  <para>
   Créons deux tables. La table capitales contient les capitales
   d'état qui sont aussi des villes. Naturellement, la table
   capitales doit hériter de villes.

<programlisting>
CREATE TABLE villes (
    nom             text,
    population      float,
    altitude        int     -- (in ft)
);

CREATE TABLE capitales (
    etat           char(2)
) INHERITS (villes);
</programlisting>

   Dans ce cas, une rangée de capitales <firstterm>hérite</firstterm> de tous
   les attributs  (nom,  population, et altitude) de son parent
   villes. Les capitales d'état ont un attribut supplémentaire state qui
   donne leur état. Dans <productname>PostgreSQL</productname>,
   une table peut hériter de zéro tables ou plus et une requête peut référencer
   toutes les rangées d'une table ou toutes les rangées d'une table plus celles de
   ses descendants.

   <note>
    <para>
     La hiérarchie d'héritage est en fait un graphe acyclique dirigé.
    </para>
   </note>
  </para>

  <para>
    Par exemple, la requête suivante cherche les noms de toutes les villes,
    y compris les capitales d'état, qui se situent à une altitude de plus
    de 500 pieds:

<programlisting>
SELECT nom, altitude
    FROM villes
    WHERE altitude &gt; 500;
</programlisting>

   qui retourne:

<programlisting>
   nom     | altitude
-----------+----------
 Las Vegas |     2174
 Mariposa  |     1953
 Madison   |      845
</programlisting>
  </para>

  <para>
    D'un autre côté, la requête suivante cherche toutes
    les villes qui ne sont pas des capitales d'état et
    qui sont situés à une altitude de plus de 500 pieds:

<programlisting>
SELECT nom, altitude
    FROM ONLY villes
    WHERE altitude &gt; 500;

   nom     | altitude
-----------+----------
 Las Vegas |     2174
 Mariposa  |     1953
</programlisting>         
  </para>

  <para>
   Ici, le <quote>ONLY</quote> avant villes indique que la requête ne devrait
   être lancée que sur villes et non les tables en dessous de villes dans la
   hiérarchie d'héritage.  Beaucoup des commandes donc nous avons déjà discuté
   -- <command>SELECT</command>, <command>UPDATE</command> et <command>DELETE</command> --
   gèrent cette syntaxe <quote>ONLY</quote>.
  </para>

  <note>
    <title>Obsolète</title> 
    <para>
     Dans les précédentes versions de <productname>PostgreSQL</productname>,
     le comportement par défaut était de ne pas inclure les tables enfants
     dans les requêtes. Il a été prouvé que cela amenait facilement des
     erreurs et est aussi en violation du standard SQL:1999. Avec l'ancienne