ddl.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
     le       $Date$
     par      $Author$
     révision $Revision$ -->

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

 <para>
  Ce chapitre couvre la création des structures de données amenées à contenir
  les données. Dans une base relationnelle, les données brutes
  sont stockées dans des tables. De ce fait, une grande partie de ce chapitre
  est consacrée à l'explication de la création et de la modification des tables 
  et aux fonctionnalités disponibles pour contrôler les données stockées dans les tables.
  L'organisation des tables dans des schémas et l'attribution de privilèges
  sur les tables sont ensuite décrits. Pour finir, d'autres fonctionnalités,
  telles que l'héritage, les vues, les fonctions et les déclencheurs sont
  passées en revue.
 </para>

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

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

  <indexterm>
   <primary>ligne</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 lignes et de colonnes. Le nombre
   et l'ordre des colonnes sont fixes et chaque colonne a un nom. Le
   nombre de lignes est variable &mdash; il représente le nombre de données
   stockées à un instant donné.
  </para>
  <para>
   Le SQL n'apporte aucune garantie sur l'ordre des
   lignes dans une table. Quand une table est lue, les lignes
   apparaissent dans un ordre aléatoire, sauf si un tri est demandé
   explicitement. Tout cela est expliqué dans le <xref linkend="queries"/>.
  </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.
   Il est expliqué plus bas dans ce chapitre comment traiter ce problème.
  </para>

  <para>
   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
   type numérique n'accepte pas les chaînes textuelles&nbsp;; les données
   stockées dans une telle colonne peuvent être utilisées dans des
   calculs mathématiques.
   Par opposition, une colonne déclarée de type chaîne de
   caractères accepte pratiquement n'importe quel type de donnée mais ne
   se prête pas aux calculs mathématiques. D'autres types d'opérations,
   telle la concaténation de chaînes, sont cependant disponibles.
  </para>

  <para>
   <productname>PostgreSQL</productname> inclut un ensemble conséquent de types
   de données intégrés pour s'adapter à diverses applications. Les
   utilisateurs peuvent aussi définir leurs propres types de données.
  </para>
  <para>
   La plupart des types de données intégrés ont des noms et des sémantiques
   évidents. C'est pourquoi leur explication détaillée est reportée au
   <xref linkend="datatype"/>.
  </para>
<!-- fractional : fraction -->
  <para>
   Parmi les types les plus utilisés, on trouve
   <type>integer</type> pour les entiers, <type>numeric</type> pour
   les éventuelles fractions, <type>text</type> pour les chaînes de
   caractères, <type>date</type> pour les dates, <type>time</type> pour
   les heures et <type>timestamp</type> pour les valeurs
   qui contiennent à la fois une date et une heure.
  </para>

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

<!-- identifier : identifiant ou indicateur. Voire identificateur -->
  <para>
   Pour créer une table, on utilise la commande bien nommée
   <xref linkend="sql-createtable" endterm="sql-createtable-title"/>. Dans cette
   commande, il est nécessaire d'indiquer, au minimum, le nom de la
   table, les noms des colonnes et le type de données de chacune d'elles.
   Par exemple&nbsp;:
<programlisting>CREATE TABLE ma_premiere_table (
    premiere_colonne text,
    deuxieme_colonne integer
);</programlisting>
   Cela crée une table nommée <literal>ma_premiere_table</literal> avec
   deux colonnes. La première colonne, nommée
   <literal>premiere_colonne</literal>, est de type <type>text</type>&nbsp;;
   la seconde colonne, nommée <literal>deuxieme_colonne</literal>, est de type
   <type>integer</type>.
   Les noms des table et colonnes se conforment à la syntaxe des identifiants expliquée
   dans la <xref linkend="sql-syntax-identifiers"/>. Les noms des types sont souvent
   aussi des identifiants mais il existe des exceptions. Le séparateur de la
   liste des colonnes est la virgule. La liste doit être entre parenthèses.
  </para>

<!-- capillo-tracté s'il s'agit donc de cheveux de traie ou simplifié à l'extrême -->
  <para>
   L'exemple qui précède est à l'évidence extrêmement simpliste. On donne
   habituellement aux tables et aux colonnes des noms qui indiquent les
   données stockées. L'exemple ci-dessous est un peu plus réaliste&nbsp;:
<programlisting>CREATE TABLE produits (
    no_produit integer,
    nom text,
    prix numeric
);</programlisting>
   (Le type <type>numeric</type> peut stocker des fractions 
   telles que les montants.)
  </para>

  <tip>
   <para>
    Quand de nombreuses tables liées sont créées, il est préférable de définir
    un motif cohérent pour le nommage des tables et des colonnes. On a ainsi
    la possibilité d'utiliser le pluriel ou le singulier des noms, chacune
    ayant ses fidèles et ses détracteurs.
   </para>
  </tip>

<!-- 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.
   Définir une table avec un nombre de colonnes proche de cette limite est,
   cependant, très inhabituel et doit conduire à se poser des questions quant
   à la conception du modèle.
  </para>

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

  <para>
   Lorsqu'une table n'est plus utile, elle peut être supprimée à l'aide de la
   commande <xref linkend="sql-droptable" endterm="sql-droptable-title"/>. Par exemple&nbsp;:
<programlisting>DROP TABLE ma_premiere_table;
DROP TABLE produits;</programlisting>
   Tenter de supprimer une table qui n'existe pas lève une erreur.
   Il est, néanmoins, habituel dans les fichiers de scripts SQL d'essayer
   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
   standard SQL.)
  </para>

  <para>
   Pour la procéduure de modification d'une table qui existe déjà, voir la 
   <xref linkend="ddl-alter"/> plus loin dans ce chapitre.
  </para>

  <para>
   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
   peut 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>
   Une valeur par défaut peut être attribuée à une colonne. Quand une nouvelle
   ligne est créée et qu'aucune valeur n'est indiquée pour certaines de ses
   colonnes, celles-ci sont remplies avec leurs valeurs par défaut respectives.
   Une commande de manipulation de données peut aussi demander explicitement
   que la valeur d'une colonne soit positionnée à la valeur par défaut, sans
   qu'il lui soit nécessaire de connaître cette valeur (les détails concernant les
   commandes de manipulation de données sont donnés dans le <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. Cela a un sens dans la mesure où l'on
   peut considérer que la valeur NULL représente des données inconnues.
  </para>

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

  <para>
   La valeur par défaut peut être une expression, alors évaluée à l'insertion
   de cette valeur (<emphasis>pas</emphasis> à la création de la
   table). Un exemple commun est la colonne de type <type>timestamp</type>
   dont la valeur par défaut est <literal>now()</literal>. Elle se voit ainsi
   attribuée l'heure d'insertion. Un autre exemple est
   la génération d'un <quote>numéro de série</quote> pour chaque ligne.
   Dans <productname>PostgreSQL</productname>, cela s'obtient habituellement par
   quelque chose comme
<programlisting>CREATE TABLE produits (
    no_produit integer <emphasis>DEFAULT nextval('produits_no_produit_seq')</emphasis>,
    ...
);</programlisting>
   où la fonction <literal>nextval()</literal> fournit des valeurs successives à
   partir d'un <firstterm>objet séquence</firstterm> (voir la <xref
   linkend="functions-sequence"/>). Cet arrangement est suffisamment commun
   pour qu'il ait son propre raccourci&nbsp;:
<programlisting>CREATE TABLE produits (
    no_produit <emphasis>SERIAL</emphasis>,
    ...
);</programlisting>
   Le raccourci <literal>SERIAL</literal> est discuté plus tard dans la <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 restreindre la nature des données qui
   peuvent être stockées dans une table. Pour beaucoup d'applications,
   toutefois, la contrainte fournie par ce biais est trop grossière.
   Par exemple, une colonne qui
   contient le prix d'un produit ne doit accepter que des valeurs
   positives. Mais il n'existe pas de type de données standard qui n'accepte que
   des valeurs positives. Un autre problème peut provenir de la volonté de
   contraindre les données d'une colonne par rapport aux autres colonnes ou lignes.
   Par exemple, dans une table contenant des informations de produit, il
   ne peut y avoir qu'une ligne par numéro de produit.
  </para>

  <para>
   Pour cela, SQL permet de définir des contraintes sur les colonnes
   et les tables. Les contraintes donnent autant de contrôle sur les
   données des tables qu'un utilisateur peut le souhaiter. Si un utilisateur
   tente de stocker des données dans une colonne en violation d'une contrainte, une erreur est
   levée. Cela 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>
    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&nbsp;:
<programlisting>CREATE TABLE produits (
    no_produit integer,
    nom text,
    prix numeric <emphasis>CHECK (prix &gt; 0)</emphasis>
);</programlisting>
   </para>

   <para>
    La définition de contrainte vient après
    le type de données, comme pour 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 la contrainte implique habituellement la
    colonne à laquelle elle s'applique, la contrainte n'ayant dans le cas
    contraire que peu de sens.
   </para>

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

   <para>
    la contrainte peut prendre un nom distinct. Cela
    clarifie les messages d'erreur et permet de faire référence
    à la contrainte lorsqu'elle doit être modifiée.
    La syntaxe est&nbsp;:
<programlisting>CREATE TABLE produits (
    no_produit integer,
    nom text,
    prix numeric <emphasis>CONSTRAINT prix_positif</emphasis> CHECK (prix &gt; 0)
);</programlisting>
    Pour indiquer une contrainte nommée, on utilise le mot-clé
    <literal>CONSTRAINT</literal> suivi d'un identifiant et de la
    définition de la contrainte (si aucun nom n'est précisé,
    le système en choisit un).
   </para>

   <para>
    Une contrainte de vérification peut aussi faire référence à plusieurs
    colonnes. Dans le cas d'un produit, on peut vouloir stocker le prix normal
    et un prix réduit en s'assurant que le prix réduit soit bien inférieur au
    prix normal.
<programlisting>CREATE TABLE produits (
    no_produit integer,
    nom text,
    prix numeric CHECK (prix &gt; 0),
    prix_promotion numeric CHECK (prix_promotion &gt; 0),
    <emphasis>CHECK (prix &gt; prix_promotion)</emphasis>
);</programlisting>
   </para>

   <para>
    Si les deux premières contraintes n'offrent pas de nouveauté, la troisième
    utilise une nouvelle syntaxe. Elle n'est pas attachée à une colonne
    particulière mais apparaît comme un élément distinct dans
    la liste des colonnes. Les définitions de
    colonnes et ces définitions de contraintes peuvent être définies dans
    un ordre quelconque.
   </para>

   <para>
    Les deux premières contraintes sont appelées contraintes de
    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 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 
    tables fonctionnent avec d'autres systèmes de bases de données). 
    L'exemple ci-dessus peut aussi s'écrire&nbsp;:
<programlisting>CREATE TABLE produits (
    no_produit integer,
    nom text,
    prix numeric,
    CHECK (prix &gt; 0),
    prix_promotion numeric,
    CHECK (prix_promotion &gt; 0),
    CHECK (prix &gt; prix_promotion)
);</programlisting>
    ou même&nbsp;:
<programlisting>CREATE TABLE produits (
    no_produit integer,
    nom text,
    prix numeric CHECK (prix &gt; 0),
    prix_promotion numeric,
    CHECK (prix_promotion &gt; 0 AND prix &gt; prix_promotion)
);</programlisting>
    C'est une question de goût.
   </para>

   <para>
    Les contraintes de table peuvent être nommées, tout comme
    les contraintes de colonne&nbsp;:
<programlisting>CREATE TABLE produits (
    no_produit integer,
    nom text,
    prix numeric,
    CHECK (prix &gt; 0),
    prix_promotion numeric,
    CHECK (prix_promotion &gt; 0),
    <emphasis>CONSTRAINT promo_valide</emphasis> CHECK (prix &gt; prix_promotion)
);</programlisting>
   </para>

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

   <para>
    Une contrainte de vérification est satisfaite si
    l'expression est évaluée vraie ou NULL. Puisque la
    plupart des expressions sont évaluées NULL si l'une
    des opérandes est nulle, elles n'interdisent pas les valeurs NULL
    dans les colonnes contraintes. Pour s'assurer qu'une colonne ne
    contient pas de valeurs NULL, la contrainte NOT NULL décrite
    dans la section suivante peut être utilisée.
   </para>
  </sect2>

  <sect2>
   <title>Contraintes de non nullité (NOT NULL)</title>

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

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

   <para>
    Une contrainte NOT NULL indique simplement qu'une colonne ne peut
    pas prendre la valeur NULL. Par exemple&nbsp;:
<programlisting>CREATE TABLE produits (
    no_produit integer <emphasis>NOT NULL</emphasis>,
    nom text <emphasis>NOT NULL</emphasis>,
    prix numeric
);</programlisting>
   </para>

   <para>
    Une contrainte NOT NULL est toujours écrite comme une contrainte de
    colonne. Elle est fonctionnellement équivalente à la création d'une
    contrainte de vérification <literal>CHECK (<replaceable>nom_colonne</replaceable>
    IS NOT NULL)</literal>. Toutefois, dans <productname>PostgreSQL</productname>,
    il est plus efficace de créer explicitement une contrainte NOT NULL.
    L'inconvénient est que les contraintes de non-nullité ainsi créées ne
    peuvent pas être explicitement nommées.
   </para>

   <para>
    Une colonne peut évidemment avoir plusieurs contraintes. Il suffit
    d'écrire les contraintes les unes après les autres&nbsp;:
<programlisting>CREATE TABLE produits (
    no_produit integer NOT NULL,
    nom text NOT NULL,
    prix numeric NOT NULL CHECK (prix &gt; 0)
);</programlisting>
    L'ordre n'a aucune importance. Il ne détermine pas l'ordre de vérification
    des contraintes.
   </para>

   <para>
    La contrainte <literal>NOT NULL</literal> a un contraire&nbsp;; 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
    ê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 fichier de script. On peut, par exemple, commencer avec&nbsp;:
<programlisting>CREATE TABLE produits (
    no_produit integer NULL,
    nom text NULL,
    prix numeric NULL
);</programlisting>
    puis insérer le mot-clé <literal>NOT</literal> en fonction des besoins.
   </para>

   <tip>
    <para>
     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>

  <sect2>
   <title>Contraintes d'unicité</title>

   <indexterm>
    <primary>contrainte d'unicité</primary>
   </indexterm>

   <indexterm>
    <primary>contrainte</primary>
    <secondary>unicité</secondary>
   </indexterm>

   <para>
    Les contraintes d'unicité garantissent l'unicité des données contenues dans
    une colonne ou un groupe de colonnes par rapport à toutes
    les lignes de la table. La syntaxe est&nbsp;:
<programlisting>CREATE TABLE produits (
    no_produit integer <emphasis>UNIQUE</emphasis>,
    nom text,
    prix numeric
);</programlisting>
    lorsque la contrainte est écrite comme contrainte de colonne et&nbsp;:
<programlisting>CREATE TABLE produits (
    no_produit integer,
    nom text,
    prix numeric,
    <emphasis>UNIQUE (no_produit)</emphasis>
);</programlisting>
    lorsqu'elle est écrite comme contrainte de table.
   </para>

   <para>
    Lorsqu'une contrainte d'unicité fait référence à un groupe de colonnes,
    celles-ci sont listées séparées par des virgules&nbsp;:
<programlisting>CREATE TABLE exemple (
    a integer,
    b integer,
    c integer,
    <emphasis>UNIQUE (a, c)</emphasis>
);</programlisting>
    Cela précise que la combinaison de valeurs dans les colonnes indiquées
    est unique sur toute la table. Sur une colonne prise isolément ce
    n'est pas nécessairement le cas (et habituellement cela ne l'est pas).
   </para>

   <para>
    Une contrainte d'unicité peut être nommée, de la
    façon habituelle&nbsp;:
<programlisting>CREATE TABLE produits (
    no_produit integer <emphasis>CONSTRAINT doit_etre_different</emphasis> UNIQUE,
    nom text,
    prix numeric
);</programlisting>
   </para>

   <indexterm>
    <primary>valeur NULL</primary>
    <secondary sortas="unique constraints">avec contrainte d'unicité</secondary>
   </indexterm>

   <para>
	En général, une contrainte d'unicité est violée lorsqu'au moins deux
	lignes de la table possèdent des valeurs identiques sur toutes les
	colonnes de la contrainte. En revanche, deux valeurs NULL ne sont pas
	considérées égales. Cela signifie qu'il est possible
	de stocker des lignes dupliquées contenant une valeur NULL
	dans au moins une des colonnes contraintes. Ce comportement est conforme
	au standard SQL, mais d'autres bases SQL n'appliquent pas cette règle.
	Il est donc préférable d'être prudent lors du développement d'applications
	portables.
       </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 n'est
	que la combinaison d'une contrainte d'unicité et
	d'une contrainte NOT NULL. Les définitions de
	table suivantes acceptent de ce fait les mêmes données&nbsp;:
    <programlisting>CREATE TABLE produits (
	no_produit integer UNIQUE NOT NULL,
	nom text,
	prix numeric
    );</programlisting>

    <programlisting>CREATE TABLE produits (
	no_produit integer <emphasis>PRIMARY KEY</emphasis>,
	nom text,
	prix numeric
    );</programlisting>
       </para>

       <para>
	Les clés primaires peuvent également contraindre plusieurs colonnes&nbsp;; la
	syntaxe est semblable aux contraintes d'unicité&nbsp;:
    <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 peut
	être utilisé(e) comme identifiant unique des lignes de la table. (C'est
	une conséquence directe de la définition d'une clé primaire. Une
	contrainte d'unicité ne suffit pas à fournir un identifiant unique
	car elle n'exclut pas les valeurs NULL). Ceci est utile à la fois
	pour des raisons documentaires et pour les applications clientes. Par
	exemple, une application graphique qui permet de modifier les valeurs de
	lignes a probablement besoin de connaître la clé primaire d'une table pour
	pouvoir identifier les lignes de manière unique.
       </para>

       <para>
	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
	une clé primaire. Cette règle n'est pas forcée par
	<productname>PostgreSQL</productname>, mais il est préférable de la
	respecter.
       </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 d'une
	colonne (ou d'un groupe de colonnes) doivent correspondre aux valeurs
	qui apparaissent dans les lignes d'une autre table.
	On dit que cela maintient l'<firstterm>intégrité référentielle</firstterm>
	entre les deux tables.
       </para>

       <para>
	Soit la table de produits, déjà utilisée plusieurs fois&nbsp;:
    <programlisting>CREATE TABLE produits (
	no_produit integer PRIMARY KEY,
	nom text,
	prix numeric
    );</programlisting>
	Soit également une table qui stocke les commandes de
	ces produits. Il est intéressant de s'assurer que la table des
	commandes ne contient que des commandes de produits
	qui existent réellement. Pour cela, une contrainte
	de clé étrangère est définie dans la table des commandes qui référence la
	table produit&nbsp;:
    <programlisting>CREATE TABLE commandes (
	id_commande integer PRIMARY KEY,
	no_produit integer <emphasis>REFERENCES produits (no_produit)</emphasis>,
	quantite integer
    );</programlisting>
	Il est désormais impossible de créer des commandes pour lesquelles
	<structfield>no_produit</structfield> n'apparaît pas dans la table
	produits.
       </para>
    <!-- referencing/referenced 
	 référençant/référencée ? -->
       <para>
	Dans cette situation, on dit que la table des commandes est la table
	<firstterm>qui référence</firstterm> et la table des produits est la table
	<firstterm>référencée</firstterm>.  De la même façon, il y a des colonnes
	qui référencent et des colonnes référencées.
       </para>

       <para>
	La commande précédente peut être raccourcie en
    <programlisting>CREATE TABLE commandes (
	id_commande integer PRIMARY KEY,
	no_produit integer <emphasis>REFERENCES produits</emphasis>,
	quantite integer
    );</programlisting>
	parce qu'en l'absence de liste de colonnes, la clé primaire de la
	table de référence est utilisée comme colonne de référence.
       </para>

       <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.
	Exemple de syntaxe&nbsp;:
    <programlisting>CREATE TABLE t1 (
      a integer PRIMARY KEY,
      b integer,
      c integer,
      <emphasis>FOREIGN KEY (b, c) REFERENCES autre_table (c1, c2)</emphasis>
    );</programlisting>
	Le nombre et le type des colonnes contraintes doivent correspondre
	au nombre et au type des colonnes référencées.
       </para>

       <para>
	Une contrainte de clé étrangère peut être nommée de la façon habituelle.
       </para>

       <para>
	Une table peut contenir plusieurs contraintes de clé étrangère. Les
	relation n-n entre tables sont implantées ainsi. Soient 
	des tables qui contiennent des produits et des commandes, avec la
	possibilité d'autoriser une commande à contenir plusieurs produits
	(ce que la structure ci-dessus ne permet pas). On peut pour cela
	utiliser la structure de table suivante&nbsp;:
    <programlisting>CREATE TABLE produits (
	no_produit integer PRIMARY KEY,
	nom text,
	prix numeric
    );

    CREATE TABLE commandes (
	id_commande integer PRIMARY KEY,
	adresse_de_livraison text,
	...
    );

    CREATE TABLE commande_produits (
	no_produit integer REFERENCES produits,
	id_commande integer REFERENCES commandes,
	quantite integer,
	PRIMARY KEY (no_produit, id_commande)
    );</programlisting>
	La clé primaire de la dernière table recouvre les clés étrangères.
       </para>

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

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

       <para>
	Les clés étrangères interdisent désormais la création
	de commandes qui ne soient pas liées à un produit. Qu'arrive-t-il si un produit
	est supprimé alors qu'une commande y fait référence&nbsp;? SQL
	permet aussi de le gérer. Intuitivement, plusieurs options existent&nbsp;:
	<itemizedlist spacing="compact">
	 <listitem><para>interdire d'effacer un produit référencé&nbsp;;</para></listitem>
	 <listitem><para>effacer aussi les commandes&nbsp;;</para></listitem>
	 <listitem><para>autre chose ?</para></listitem>
	</itemizedlist>
       </para>

       <para>
	Pour illustrer ce cas, la politique suivante est implantée sur
	l'exemple de relations n-n évoqué plus haut&nbsp;:
	<itemizedlist spacing="compact">
	 <listitem><para>quand quelqu'un veut retirer un produit qui est encore
	  référencé par une commande
	  (au travers de <literal>commande_produits</literal>), on
	  l'interdit&nbsp;;</para></listitem>
	 <listitem><para>si quelqu'un supprime une commande, les éléments
	  de la commande sont aussi supprimés.</para></listitem>
	</itemizedlist>

    <programlisting>CREATE TABLE produits (
	no_produit integer PRIMARY KEY,
	nom text,
	prix numeric
    );

    CREATE TABLE commandes (
	id_commande integer PRIMARY KEY,
	adresse_de_livraison text,
	...
    );

    CREATE TABLE commande_produits (
	no_produit integer REFERENCES produits <emphasis>ON DELETE RESTRICT</emphasis>,
	id_commande integer REFERENCES commandes <emphasis>ON DELETE CASCADE</emphasis>,
	quantite integer,
	PRIMARY KEY (no_produit, id_commande)
    );</programlisting>
       </para>

    <!-- CASCADE : cascader ? -->
       <para>
	 Restreindre les suppressions et les cascader 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> impose
	 la levée d'une erreur si des lignes référençant existent lors de la
	 vérification de la contrainte. Il s'agit du comportement par
	 défaut en l'absence de précision. La différence entre
	 <literal>RESTRICT</literal> et <literal>NO ACTION</literal> 
	 est l'autorisation par
	 <literal>NO ACTION</literal> du report de la vérification à la fin de la
	 transaction, ce que <literal>RESTRICT</literal> ne permet pas.
	 <literal>CASCADE</literal> indique que, lors de la suppression d'une ligne
	 référencée, les lignes la référençant doivent être automatiquement
	 supprimées. Il existe deux autres options&nbsp;:
	 <literal>SET NULL</literal> et <literal>SET DEFAULT</literal>.
	 Celles-ci imposent que les colonnes qui référencent soient
	 réinitialisées à NULL ou à leur valeur par défaut, respectivement, lors
	 de la suppression d'une ligne référencée. Elles ne dispensent pas pour
	 autant d'observer les contraintes. Par exemple, si une action précise 
	 <literal>SET DEFAULT</literal> mais que la valeur par défaut ne
	 satisfait pas la clé étrangère, l'opération échoue.
       </para>

       <para>
	À l'instar de <literal>ON DELETE</literal>, existe 
	<literal>ON UPDATE</literal>, évoqué lorsqu'une colonne référencée
	est modifiée (actualisée). Les actions possibles sont les mêmes.
       </para>

       <para>
	Le <xref linkend="dml"/> contient de plus amples informations sur
	l'actualisation et la suppression de données.
       </para>

       <para>
	Une clé étrangère peut faire référence à des colonnes qui constituent une clé
	primaire ou forment une contrainte d'unicité. Si la clé étrangère référence
	une contrainte d'unicité, des possibilités supplémentaires sont offertes
	concernant la correspondance des valeurs NULL. Celles-ci sont expliquées
	dans la documentation de référence de
	<xref linkend="sql-createtable" endterm="sql-createtable-title"/>.
       </para>
      </sect2>
     </sect1>

 <sect1 id="ddl-system-columns">
   <title>Colonnes système</title>

   <para>
     Chaque table contient plusieurs <firstterm>colonnes système</firstterm>
     implicitement définies par le système. De ce fait, leurs noms ne peuvent
     pas être utilisés comme noms de colonnes utilisateur (ces restrictions sont
     distinctes de celles sur l'utlisation de mot-clés&nbsp;; mettre le nom
     entre guillemets ne permet pas d'échapper à cette règle). Il n'est pas
     vraiment utile de se préoccuper de ces colonnes, mais au minimum de
     savoir qu'elles existent.
   </para>

 <indexterm>
   <primary>colonne</primary>
   <secondary>colonne système</secondary>
 </indexterm>

 <variablelist>
   <varlistentry>
     <term><structfield>oid</structfield></term>
     <listitem>
       <para>
        <indexterm>
         <primary>OID</primary>
         <secondary>colonne</secondary>
        </indexterm>
	L'identifiant objet (<foreignphrase>object ID</foreignphrase>) d'une ligne. Cette
	colonne n'est présente que si la table a été créée en précisant
	<literal>WITH OIDS</literal> ou si la variable de configuration 
	<xref linkend="guc-default-with-oids"/> était activée à ce moment-là.
	Cette colonne est de type oid (même nom que la colonne)&nbsp;; voir la
	<xref linkend="datatype-oid"/> pour obtenir plus d'informations sur ce type.
       </para>
     </listitem>
   </varlistentry>
   
   <varlistentry>
     <term><structfield>tableoid</structfield></term>
   <listitem>
     <indexterm>
       <primary>tableoid</primary>
     </indexterm>
     
     <para>
        L' OID de la table contenant la ligne. Cette colonne est
	particulièrement utile pour les requêtes qui utilisent des hiérarchies
	d'héritage (voir <xref linkend="ddl-inherit"/>). Il est, en effet,
	difficile, en son absence, de savoir de quelle table provient une ligne.
	<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</structfield></term>
 <listitem>
   <indexterm>
     <primary>xmin</primary>
   </indexterm>
   
   <para>
      L'identifiant (ID de transaction) de la transaction qui a inséré cette
      version de la ligne. (Une version de ligne est un état individuel
      de la ligne&nbsp;; toute mise à jour d'une ligne crée une nouvelle
      version de ligne pour la même ligne logique.)
   </para>
 </listitem>
</varlistentry>

<varlistentry>
  <term><structfield>cmin</structfield></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</structfield></term>
<listitem>
  <indexterm>
    <primary>xmax</primary>
  </indexterm>
  
  <para>
     L'identifiant (ID de transaction) de la transaction de suppression, ou zéro
     pour une version de ligne non effacée. Il est possible que la colonne ne
     soit pas nulle pour une version de ligne visible&nbsp;; cela
     indique habituellement 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</structfield></term>
<listitem>
  <indexterm>
    <primary>cmax</primary>
  </indexterm>
  
  <para>
     L'identifiant de commande au sein de la transaction de suppression, ou
     zéro.
  </para>
</listitem>
</varlistentry>

<varlistentry>
  <term><structfield>ctid</structfield></term>
<listitem>
  <indexterm>
    <primary>ctid</primary>
  </indexterm>
  
  <para>
     La localisation physique de la version de ligne au sein de sa table.
     Bien que le <structfield>ctid</structfield> puisse être utilisé
     pour trouver la version de ligne très rapidement, le
     <structfield>ctid</structfield>  d'une ligne change si
     la ligne est actualisée ou déplacée par un <command>VACUUM FULL</command>.
     <structfield>ctid</structfield> est donc inutilisable comme
     identifiant de ligne sur le long terme. Il est préférable d'utiliser l'OID,
     ou, mieux encore, un numéro
     de série utilisateur, pour identifier les lignes logiques.
</para>
</listitem>
</varlistentry>
</variablelist>

  <para>
   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&nbsp;; 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&nbsp;:
  
  <itemizedlist>
    <listitem>
      <para>
       une contrainte d'unicité doit être ajoutée sur la colonne OID de chaque
       table dont l'OID est utilisé pour identifier les lignes.
       Dans ce cas (ou dans celui d'un index d'unicité), le système
       n'engendre pas d'OID qui puisse correspondre à celui d'une ligne
       déjà présente. Cela n'est évidemment possible que si la table contient
       moins de 2<superscript>32</superscript> (4 milliards) lignes&nbsp;; en pratique, la
       taille de la table a tout intérêt à être bien plus petite que ça, dans
       un souci de performance&nbsp;;
      </para>
    </listitem>
    <listitem>
      <para>
       l'unicité inter-tables des OID ne doit jamais être envisagée&nbsp;;
       pour obtenir un identifiant unique sur l'ensemble de la base, il faut
       utiliser la combinaison du <structfield>tableoid</structfield> et de l'OID de
       ligne&nbsp;;
      </para>
    </listitem>
    <listitem>
      <para>
       les tables en question doivent être créées avec l'option
       <literal>WITH OIDS</literal>. Depuis <productname>PostgreSQL</productname> 8.1,
       <literal>WITHOUT OIDS</literal> est 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 agée, il est possible que les ID de
    transaction bouclent. Cela n'est pas un problème fatal
    avec des procédures de maintenance appropriées&nbsp;; voir le <xref
    linkend="maintenance"/> pour les détails. Il est, en revanche, imprudent
    de considérer l'unicité des ID de transaction sur le long terme (plus
    d'un milliard de transactions).
  </para>

  <para>
    Les identifiants de commande sont aussi des nombres de 32 bits. Cela
    crée une limite dure de 2<superscript>32</superscript> (4 milliards)
    commandes <acronym>SQL</acronym> au sein d'une unique transaction. En
    pratique, cette limite n'est pas un problème &mdash; la limite est sur
    le nombre de commandes <acronym>SQL</acronym>, pas sur le nombre de lignes
    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
    consomment un identifiant de commande.
  </para>
 </sect1>

 <sect1 id="ddl-alter">
  <title>Modification des tables</title>

  <indexterm zone="ddl-alter">
   <primary>table</primary>
   <secondary>modification</secondary>
  </indexterm>

  <para>
   Lorsqu'une table est créée et qu'une erreur a été commise ou que les
   besoins de l'application changent, il est alors possible de la supprimer et
   de la récréer. Cela n'est toutefois pas pratique si la table contient
   déjà des données ou qu'elle est référencée par d'autres objets de la base
   de données (une contrainte de clé étrangère, par exemple). C'est pourquoi
   <productname>PostgreSQL</productname> offre une série de commandes
   permettant de modifier une table existante. Cela n'a rien à voir 
   avec la modification des données contenues dans la table&nbsp;; il ne
   s'agit ici, que de modifier la définition, ou structure, de la table.
  </para>

  <para>
   Il est possible
   <itemizedlist spacing="compact">
    <listitem>
     <para>d'ajouter des colonnes&nbsp;;</para>
    </listitem>
    <listitem>
     <para>de supprimer des colonnes&nbsp;;</para>
    </listitem>
    <listitem>
     <para>d'ajouter des contraintes&nbsp;;</para>
    </listitem>
    <listitem>
     <para>de supprimer des contraintes&nbsp;;</para>
    </listitem>
    <listitem>
     <para>de modifier des valeurs par défaut&nbsp;;</para>
    </listitem>
    <listitem>
     <para>de modifier les types de données des colonnes&nbsp;;</para>
    </listitem>
    <listitem>
     <para>de renommer des colonnes&nbsp;;</para>
    </listitem>
    <listitem>
     <para>de renommer des tables.</para>
    </listitem>
   </itemizedlist>

   Toutes ces actions sont réalisées à l'aide de la commande 
   <xref linkend="sql-altertable" endterm="sql-altertable-title"/>, 
   dont la page de référence est bien plus détaillée.
  </para>

  <sect2>
   <title>Ajouter une colonne</title>

   <indexterm>
    <primary>colonne</primary>
    <secondary>ajouter</secondary>
   </indexterm>

   <para>
    La commande d'ajout d'une colonne ressemble à&nbsp;:
<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>).
   </para>

   <para>
    Des contraintes de colonne peuvent être définies dans la même commande,
    à l'aide de la syntaxe habituelle&nbsp;:
<programlisting>ALTER TABLE produits ADD COLUMN description text CHECK (description &lt;&gt; '');</programlisting>
    En fait, toutes les options applicables à la description d'une colonne
    dans <command>CREATE TABLE</command> peuvent être utilisées ici. Il ne
    faut toutefois pas oublier que la valeur par défaut doit satisfaire les contraintes
    données. Dans le cas contraire, <literal>ADD</literal> échoue. Il est
    aussi possible d'ajouter les contraintes ultérieurement (voir ci-dessous) après 
    avoir rempli la nouvelle colonne correctement.
   </para>

  <tip>
   <para>
    Ajouter une colonne avec une valeur par défaut nécessite la mise à jour
    de chaque ligne de la table pour stocker la valeur de la nouvelle colonne.
    Cependant, si aucune valeur par défaut n'est précisée,
    <productname>PostgreSQL</productname> peut éviter la mise à jour physique.
    Il est, de ce fait, préférable, si la colonne doit être remplie en majorité
    avec des valeurs différentes de la valeur par défaut, d'ajouter
    la colonne sans valeur par défaut, d'insérer les bonnes valeurs avec une
    commande <command>UPDATE</command> puis d'ajouter la valeur par défaut désirée
    comme décrit ci-dessus.
   </para>
  </tip>

  </sect2>

  <sect2>
   <title>Retirer une colonne</title>

   <indexterm>
    <primary>colonne</primary>
    <secondary>retirer</secondary>
   </indexterm>

   <para>
    La commande de suppression d'une colonne ressemble à celle-ci&nbsp;:
<programlisting>ALTER TABLE produits DROP COLUMN description;</programlisting>
    Toute donnée dans cette colonne disparaît. Les contraintes de table
    impliquant la colonne sont également supprimées. Néanmoins, si la colonne est
    référencée par une contrainte de clé étrangère d'une autre table,
    <productname>PostgreSQL</productname> ne supprime pas silencieusement
    cette contrainte. La suppression de tout ce qui     
    dépend de la colonne peut être autorisée en ajoutant <literal>CASCADE</literal>&nbsp;:
<programlisting>ALTER TABLE produits DROP COLUMN description CASCADE;</programlisting>
    Voir la <xref linkend="ddl-depend"/> pour une description du mécanisme général.
   </para>
  </sect2>

  <sect2>
   <title>Ajouter une contrainte</title>

   <indexterm>
    <primary>contrainte</primary>
    <secondary>ajouter</secondary>
   </indexterm>

   <para>
    Pour ajouter une contrainte, la syntaxe de contrainte de table est utilisée.
    Par exemple&nbsp;:
<programlisting>ALTER TABLE produits ADD CHECK (nom &lt;&gt; '');
ALTER TABLE produits ADD CONSTRAINT autre_nom UNIQUE (no_produit);
ALTER TABLE produits ADD FOREIGN KEY (id_groupe_produit) REFERENCES groupes_produits;</programlisting>
    Pour ajouter une contrainte NOT NULL, qui ne peut pas être écrite
    sous forme d'une contrainte de table, la syntaxe suivante est utilisée&nbsp;:
<programlisting>ALTER TABLE produits ALTER COLUMN no_produit SET NOT NULL;</programlisting>
   </para>

   <para>
    La contrainte étant immédiatement vérifiée, les données de la
    table doivent satisfaire la contrainte avant qu'elle ne soit ajoutée.
   </para>
  </sect2>

  <sect2>
   <title>Supprimer une contrainte</title>

   <indexterm>
    <primary>contrainte</primary>
    <secondary>supprimer</secondary>
   </indexterm>

   <para>
    Pour supprimer une contrainte, il faut connaître son nom. Si elle a été
    explicitement nommé, il n'y a aucune difficulté. Dans le cas contraire, 
    le système a engendré et attribué un nom qu'il faut découvrir. La commande
    <literal>\d <replaceable>table</replaceable></literal>
    de <application>psql</application> peut être utile ici&nbsp;; d'autres interfaces
    offrent aussi la possibilité d'examiner les détails de table. La commande est&nbsp;:
<programlisting>ALTER TABLE produits DROP CONSTRAINT un_nom;</programlisting>
    (Dans le cas d'un nom de contrainte engendré, comme <literal>$2</literal>,
    il est nécessaire de l'entourer de guillemets doubles pour en faire
    un identifiant valable.)
   </para>

   <para>
    Comme pour la suppression d'une colonne, <literal>CASCADE</literal> peut
    être ajouté pour supprimer une contrainte dont dépendent d'autres objets.
    Une contrainte de clé étrangère, par exemple, dépend d'une contrainte de
    clé primaire ou d'unicité sur la(les) colonne(s) référencée(s).
   </para>

   <para>
    Cela fonctionne de la même manière pour tous les types de contrainte,
    à l'exception des contraintes NOT NULL. Pour supprimer une contrainte NOT NULL,
    on écrit&nbsp;:
<programlisting>ALTER TABLE produits ALTER COLUMN no_produit DROP NOT NULL;</programlisting>
    (Les contraintes NOT NULL n'ont pas de noms.)
   </para>
  </sect2>

  <sect2>
   <title>Modifier la valeur par défaut d'une colonne</title>

   <indexterm>
    <primary>valeur par défaut</primary>
    <secondary>modifier</secondary>
   </indexterm>

   <para>
    La commande de définition d'une nouvelle valeur par défaut de colonne
    ressemble à celle-ci&nbsp;:
<programlisting>ALTER TABLE produits ALTER COLUMN prix SET DEFAULT 7.77;</programlisting>
    Cela n'affecte pas les lignes existantes de la table, mais uniquement la valeur
    par défaut pour les futures commandes <command>INSERT</command>.
   </para>

   <para>
    Pour retirer toute valeur par défaut, on écrit&nbsp;:
<programlisting>ALTER TABLE produits ALTER COLUMN prix DROP DEFAULT;</programlisting>
    C'est équivalent à mettre la valeur par défaut à NULL. En conséquence,
    il n'y a pas d'erreur à retirer une valeur par défaut qui n'a pas été définie
    car NULL est la valeur par défaut implicite.
   </para>
  </sect2>

  <sect2>
   <title>Modifier le type de données d'une colonne</title>

   <indexterm>
    <primary>type de données d'une colonne</primary>
    <secondary>modification</secondary>
   </indexterm>

   <para>
    La commande de conversion du type de données d'une colonne ressemble à celle-ci&nbsp;:
    <programlisting>ALTER TABLE produits ALTER COLUMN prix TYPE numeric(10,2);</programlisting>
    Elle ne peut réussir que si chaque valeur de la colonne peut être
    convertie dans le nouveau type par une conversion implicite. Si une
    conversion plus complexe est nécessaire, une clause
    <literal>USING</literal> peut être ajoutée qui indique comment calculer
    les nouvelles valeurs à partir des anciennes.
   </para>
  
   <para>
    <productname>PostgreSQL</productname> tente de convertir la valeur par défaut de la
    colonne le cas échéant, ainsi que toute contrainte impliquant la colonne. Mais ces
    conversions peuvent échouer ou produire des résultats surprenants. Il est
    souvent préférable de supprimer les contraintes de la colonne avant d'en
    modifier le type, puis d'ajouter ensuite les contraintes convenablement modifiées.
   </para>
  </sect2>

  <sect2>
   <title>Renommer une colonne</title>

   <indexterm>
    <primary>colonne</primary>
    <secondary>renommer</secondary>
   </indexterm>

   <para>
    Pour renommer une colonne&nbsp;:
<programlisting>ALTER TABLE produits RENAME COLUMN no_produit TO numero_produit;</programlisting>
   </para>
  </sect2>

  <sect2>
   <title>Renommer une table</title>

   <indexterm>
    <primary>table</primary>
    <secondary>renommer</secondary>
   </indexterm>

   <para>
    Pour renommer une table&nbsp;:
<programlisting>ALTER TABLE produits RENAME TO elements;</programlisting>
   </para>
  </sect2>
 </sect1>
 
 <sect1 id="ddl-priv">
  <title>Droits</title>

  <indexterm zone="ddl-priv">
   <primary>droit</primary>
  </indexterm>

  <indexterm>
   <primary>permission</primary>
   <see>droit</see>
  </indexterm>

<!-- privilege : privilège ou droit ?
     Un privilège est donné à un utilisateur afin qu'il dispose de droits sur
     un objet.
     to grant : granter dans le cas de l'action, attribuer -->
  <para>
   Tout utilisateur qui crée un objet dans la base de données en devient le
   propriétaire. Par défaut, seul le propriétaire peut l'utiliser.
   Pour que d'autres utilisateurs puissent l'utiliser, des
   <firstterm>privilèges</firstterm> doivent être
   accordés (les superutilisateurs ont, toutefois, accès à tout objet,
   toujours).
  </para>

  <para>
   Il existe un certain nombre de droits différents&nbsp;: <literal>SELECT</literal>,
   <literal>INSERT</literal>, <literal>UPDATE</literal>, <literal>DELETE</literal>,
   <literal>REFERENCES</literal>, <literal>TRIGGER</literal>,
   <literal>CREATE</literal>, <literal>CONNECT</literal>, <literal>TEMPORARY</literal>,
   <literal>EXECUTE</literal> et <literal>USAGE</literal>.
   Les droits applicables à un objet particulier varient
   selon le type d'objet (table, fonction...). La page de référence
   <xref linkend="sql-grant" endterm="sql-grant-title"/> fournit une
   information complète sur les différents types de droits gérés par
   <productname>PostgreSQL</productname>.  La section et
   les chapitres suivants présentent l'utilisation de ces droits.
  </para>

  <para>
   Le droit de modifier ou de détruire un objet est le privilège du seul propriétaire.
  </para>

  <note>
   <para>
    Pour modifier le propriétaire d'une table, d'un index, d'une séquence ou
    d'une vue, on utilise la commande
    <xref linkend="sql-altertable" endterm="sql-altertable-title"/>.
    Il existe des commandes <literal>ALTER</literal> correspondantes pour les autres types 
    d'objets.
   </para>
  </note>
  
  <para>
   La commande <command>GRANT</command> est
   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é
   à <literal>joe</literal> avec&nbsp;:
<programlisting>GRANT UPDATE ON comptes TO joe;</programlisting>
   Écrire <literal>ALL</literal> à la place d'un droit spécifique accorde tous
   les droits applicables à ce type d'objet.
  </para>

  <para>
   Le nom d'<quote>utilisateur</quote> spécial <literal>PUBLIC</literal> peut
   être utilisé pour donner un privilège à tous les utilisateurs du système. De plus,
   les rôles de type <quote>group</quote> peuvent être configurés pour aider à
   la gestion des droits quand il y a beaucoup d'utilisateurs dans une base
   &mdash; pour les détails, voir <xref linkend="user-manag"/>.
  </para>

  <para>
   Pour révoquer un privilège, on utilise la commande bien-nommée
   <command>REVOKE</command>, comme dans l'exemple ci-dessous&nbsp;:
<programlisting>REVOKE ALL ON comptes FROM PUBLIC;</programlisting>
   Les privilèges spéciaux du propriétaire de l'objet (c'est-à-dire, le droit
   d'exécuter <command>DROP</command>, <command>GRANT</command>, 
   <command>REVOKE</command>, etc.) appartiennent toujours implicitement au
   propriétaire. Il ne peuvent être ni
   accordés ni révoqués. Mais le propriétaire de l'objet peut choisir
   de révoquer ses propres droits ordinaires pour, par exemple, mettre
   une table en lecture seule pour lui-même et pour les autres.
  </para>

  <para>
   Habituellement, seul le propriétaire de l'objet (ou un superutilisateur)
   peut granter ou révoquer les droits sur un objet. Néanmoins, il est possible
   de donner un privilège <quote>avec possibilité de transmission</quote>
   (<foreignphrase><quote>with grant option</quote></foreignphrase>), qui donne
   à celui qui le reçoit la permission de le donner à d'autres. Si cette option est ensuite
   révoquée, alors tous ceux qui ont reçu ce privilège par cet utilisateur
   (directement ou indirectement via la chaîne des dons) perdent ce privilège.
   Pour les détails, voir les pages de références
   <xref linkend="sql-grant" endterm="sql-grant-title"/> et
   <xref linkend="sql-revoke" endterm="sql-revoke-title"/>.
  </para>
 </sect1>

 <sect1 id="ddl-schemas">
  <title>Schémas</title>

  <indexterm zone="ddl-schemas">
   <primary>schéma</primary>
  </indexterm>

  <para>
   Un cluster de bases de données <productname>PostgreSQL</productname>
   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. 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>

  <note>
   <para>
    Les utilisateurs d'un cluster n'ont pas obligatoirement le droit d'accéder à
    toutes les bases du cluster. Le partage des noms d'utilisateur signifie
    qu'il ne peut pas y avoir plusieurs utilisateurs nommés <literal>joe</literal>,
    par exemple, dans deux bases du même cluster&nbsp;; mais le système peut être
    configuré pour n'autoriser <literal>joe</literal> à accéder qu'à certaines bases.
   </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é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&nbsp;; par exemple,
   <literal>schema1</literal> et <literal>mon_schema</literal> peuvent tous les deux
   contenir une table nommée <literal>ma_table</literal>. À la différence des
   bases de données, les schémas ne sont pas séparés de manière rigide&nbsp;:
   un utilisateur peut accéder aux objets de n'importe quel schéma de la
   base de données à laquelle il est connecté, sous réserve qu'il en ait le
   droit.
  </para>

  <para>
   Il existe plusieurs raisons d'utiliser les schémas&nbsp;:

   <itemizedlist>
    <listitem>
     <para>
      autoriser de nombreux utilisateurs à utiliser une base de données
      sans interférer avec les autres&nbsp;;
     </para>
    </listitem>

    <listitem>
     <para>
      organiser les objets de la base de données en groupes logiques afin de faciliter
      leur gestion&nbsp;;
     </para>
    </listitem>

    <listitem>
     <para>
      les applications tiers peuvent être placées dans des schémas séparés
      pour éviter les collisions avec les noms d'autres objets.
     </para>
    </listitem>
   </itemizedlist>

   Les schémas sont comparables aux répertoires du système d'exploitation, à
   ceci près qu'ils ne peuvent pas être imbriqués.
  </para>

  <sect2 id="ddl-schemas-create">
   <title>Créer un schéma</title>

   <indexterm zone="ddl-schemas-create">
    <primary>schéma</primary>
    <secondary>créer</secondary>
   </indexterm>

   <para>
    Pour créer un schéma, on utilise la commande
    <xref linkend="sql-createschema" endterm="sql-createschema-title"/>.
    Le nom du schéma est libre. Par exemple&nbsp;:
<programlisting>CREATE SCHEMA mon_schema;</programlisting>
   </para>

   <indexterm>
    <primary>nom qualifié</primary>
   </indexterm>

   <indexterm>
    <primary>nom</primary>
    <secondary>qualifié</secondary>
   </indexterm>

   <para>
    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&nbsp;:
<synopsis><replaceable>schema</replaceable><literal>.</literal><replaceable>table</replaceable></synopsis>
    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, 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>
    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
    données est précisé, ce doit être celui de la base à laquelle
    l'utilisateur est connecté.
   </para>

   <para>
    Pour créer une table dans le nouveau schéma, on utilise&nbsp;:
<programlisting>CREATE TABLE mon_schema.ma_table (
 ...
);</programlisting>
   </para>

   <indexterm>
    <primary>schéma</primary>
    <secondary>suppression</secondary>
   </indexterm>

   <para>
    Pour effacer un schéma vide (tous les objets qu'il contient ont été
    supprimés), on utilise&nbsp;:
<programlisting>DROP SCHEMA mon_schema;</programlisting>
    Pour effacer un schéma et les objets qu'il contient, on utilise&nbsp;:
<programlisting>DROP SCHEMA mon_schema CASCADE;</programlisting>
    La <xref linkend="ddl-depend"/> décrit le mécanisme général sous-jacent.
   </para>

   <para>
    Il n'est pas rare de vouloir créer un schéma dont un autre utilisateur est
    propriétaire (puisque c'est l'une des méthodes de restriction de l'activité des
    utilisateurs à des <foreignphrase>namespaces</foreignphrase> pré-définis).
    La syntaxe en est&nbsp;:
<programlisting>CREATE SCHEMA <replaceable>nom_schema</replaceable> AUTHORIZATION <replaceable>nom_utilisateur</replaceable>;</programlisting>
    Le nom du schéma peut être omis, auquel cas le nom de l'utilisateur est
    utilisé. Voir la <xref linkend="ddl-schemas-patterns"/> pour en connaître
    l'utilité.
   </para>

   <para>
    Les noms de schéma commençant par <literal>pg_</literal> sont réservés pour
    les besoins du système et ne peuvent être créés par les utilisateurs.
   </para>
  </sect2>

  <sect2 id="ddl-schemas-public">
   <title>Le schéma public</title>

   <indexterm zone="ddl-schemas-public">
    <primary>schéma</primary>
    <secondary>public</secondary>
   </indexterm>

   <para>
    Dans les sections précédentes, les tables sont créées sans qu'un nom de
    schéma soit indiqué. Par défaut, ces tables (et les autres objets) sont
    automatiquement placées dans un schéma nommé <quote>public</quote>. Toute
    nouvelle base de données contient un tel schéma. Les instructions
    suivantes sont donc équivalentes&nbsp;:
<programlisting>CREATE TABLE produits ( ... );</programlisting>
    et&nbsp;:
<programlisting>CREATE TABLE public.produits ( ... );</programlisting>
   </para>
  </sect2>

  <sect2 id="ddl-schemas-path">
   <title>Chemin de parcours des schémas</title>

   <indexterm>
    <primary>chemin de recherche</primary>
   </indexterm>

   <indexterm>
    <primary>nom non qualifié</primary>
   </indexterm>

   <indexterm>
    <primary>nom</primary>
    <secondary>non qualifié</secondary>
   </indexterm>

   <para>
    Non seulement l'écriture de noms qualifiés est contraignante, mais il est, 
    de toute façon, préférable de ne pas fixer un nom de schéma dans les
    applications. De ce fait, les tables sont souvent appelées par des
    <firstterm>noms non-qualifiés</firstterm>, soit le seul nom de la table.
    Le système détermine
    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, quand bien même il existerait des tables dont le nom
    correspond dans d'autres schémas de la base.
   </para>

   <indexterm>
    <primary>schéma</primary>
    <secondary>courant</secondary>
   </indexterm>

   <para>
    Le premier schéma du chemin de recherche est appelé schéma courant.
    En plus d'être le premier schéma parcouru, il est aussi le schéma dans lequel
    les nouvelles tables sont créées si la commande <command>CREATE TABLE</command>
    ne précise pas de nom de schéma.
   </para>

   <indexterm>
    <primary>search_path</primary>
   </indexterm>

   <para>
    Le chemin de recherche courant est affiché à l'aide de la commande&nbsp;:
<programlisting>SHOW search_path;</programlisting>
    Dans la configuration par défaut, ceci renvoie&nbsp;:
<screen> search_path
--------------
 "$user",public</screen>
    Le premier élément précise qu'un schéma de même nom que l'utilisateur
    courant est recherché. En l'absence d'un tel schéma, l'entrée est ignorée. 
    Le deuxième élément renvoie au schéma public précédemment évoqué.
   </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
    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
    données ou requêtes), le chemin de recherche est traversé jusqu'à ce qu'un objet
    correspondant soit trouvé. C'est pourquoi, dans la configuration par défaut,
    tout accès non qualifié ne peut que se référer au schéma public.
   </para>

   <para>
    Pour ajouter un schéma au chemin, on écrit&nbsp;:
<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'accéder à la table
    sans qu'elle soit qualifiée par un schéma&nbsp;:
<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.
   </para>

   <para>
    On peut aussi écrire&nbsp;:
<programlisting>SET search_path TO mon_schema;</programlisting>
    Dans ce cas, le schéma public n'est plus accessible sans qualification explicite.
    Hormis le fait qu'il existe par défaut, le schéma public n'a rien de
    spécial. Il peut même être effacé.
   </para>

   <para>
    On peut également se référer à la <xref linkend="functions-info"/>
    qui détaille les autres façons
    de manipuler le chemin de recherche des schémas.
   </para>

   <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
    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&nbsp;:
<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. Par exemple&nbsp;:
<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.
   </para>
  </sect2>

  <sect2 id="ddl-schemas-priv">
   <title>Schémas et privilèges</title>

   <indexterm zone="ddl-schemas-priv">
    <primary>privilèges</primary>
    <secondary sortas="schemas">sur les schémas</secondary>
   </indexterm>

   <para>
    Par défaut, les utilisateurs ne peuvent pas accéder aux objets présents
    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 éventuellement être accordés, en
    fonction de l'objet.
   </para>

   <para>
    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>.
    Cela permet à tous les utilisateurs qui peuvent se connecter
    à une base de données de créer des objets dans son schéma
    <literal>public</literal>. Si cela ne doit pas être le cas, ce privilège
    peut être révoqué&nbsp;:
<programlisting>REVOKE CREATE ON SCHEMA public FROM PUBLIC;</programlisting>
    Le premier <quote>public</quote> est le schéma, le second
    <quote>public</quote> signifie <quote>tout utilisateur</quote>. Dans le
    premier cas, c'est un identifiant, dans le second, un mot clé,
    d'où la casse différente. (Se reporter aux règles de la
    <xref linkend="sql-syntax-identifiers"/>.)
   </para>
  </sect2>

  <sect2 id="ddl-schemas-catalog">
   <title>Le schéma du catalogue système</title>

   <indexterm zone="ddl-schemas-catalog">
    <primary>catalogue système</primary>
    <secondary>schéma</secondary>
   </indexterm>

   <para>
    En plus du schéma <literal>public</literal> et de ceux créés par les
    utilisateurs, chaque base de données contient un schéma
    <literal>pg_catalog</literal>. Celui-ci contient
    les tables systèmes et tous les types de données, fonctions et opérateurs
    intégrés. <literal>pg_catalog</literal> est toujours dans le chemin
    de recherche. S'il n'est pas nommé explicitement dans le chemin, il est
    parcouru implicitement <emphasis>avant</emphasis> le parcours des schémas
    du chemin. Cela garantit que les noms internes sont toujours accessibles.
    En revanche, <literal>pg_catalog</literal> peut être explicitement placé à la
    fin si les noms utilisateur doivent surcharger les noms internes.
   </para>

   <para>
    Dans les versions de <productname>PostgreSQL</productname> antérieures à la 7.3,
    les noms de table commençant par <literal>pg_</literal> étaient réservés.
    Cela n'est plus vrai&nbsp;: une telle table peut être créée
    dans n'importe quel schéma qui n'est pas un schéma système. En revanche,
    il est préférable de continuer à éviter d'utiliser de tels noms pour
    se prémunir d'éventuels conflits si une version ultérieure devait définir
    une table système qui porte le même nom que la table créée. (Le chemin de recherche par
    défaut implique qu'une référence non qualifiée à cette table pointe sur la table système).
    Les tables systèmes continueront de suivre la convention qui leur impose
    des noms préfixés par <literal>pg_</literal>. Il n'y a donc pas de
    conflit possible avec des noms de table utilisateur non qualifiés, sous
    réserve que les utilisateurs évitent le préfixe <literal>pg_</literal>.
   </para>
  </sect2>

  <sect2 id="ddl-schemas-patterns">
   <title>Utilisation</title>

   <para>
    Les schémas peuvent être utilisés de différentes façons pour organiser
    les données. Certaines d'entre elles, recommandées, sont facilement supportés par la
    configuration par défaut&nbsp;:
    <itemizedlist>
     <listitem>
      <para>
       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 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&nbsp;;
      </para>
     </listitem>

     <listitem>
      <para>
       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 confiner les utilisateurs dans leur propre schéma&nbsp;;
      </para>
     </listitem>

     <listitem>
      <para>
       l'installation d'applications partagées (tables utilisables
       par tout le monde, fonctionnalités supplémentaires fournies par
       des applications tiers, etc) peut se faire dans des schémas distincts.
       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
       leur nom du nom de schéma ou ajouter les schémas
       supplémentaires dans leur chemin de recherche, au choix.
      </para>
     </listitem>
    </itemizedlist>
   </para>
  </sect2>

  <sect2 id="ddl-schemas-portability">
   <title>Portabilité</title>

   <para>
    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 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.
    De ce fait, beaucoup d'utilisateurs considèrent les noms
    qualifiés comme correspondant en réalité à
    <literal><replaceable>utilisateur</replaceable>.<replaceable>table</replaceable></literal>.
    C'est comme cela que <productname>PostgreSQL</productname> se comporte
    si un schéma utilisateur est créé pour chaque utilisateur.
   </para>

   <para>
    Le concept de schéma <literal>public</literal> n'existe pas non plus dans le
    standard SQL. Pour plus de conformité au standard, le schéma
    <literal>public</literal> ne devrait pas être utilisé (voire être
    supprimé).
   </para>

   <para>
    Certains systèmes de bases de données n'implantent pas du
    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 est obtenue en n'utilisant
    pas les schémas.
   </para>
  </sect2>
 </sect1>

 <sect1 id="ddl-inherit">
  <title>L'héritage</title>

  <indexterm>
   <primary>héritage</primary>
  </indexterm>

  <indexterm>
   <primary>table</primary>
   <secondary>héritage</secondary>
  </indexterm>

  <para>
   <productname>PostgreSQL</productname> implante l'héritage des tables,
   qui peut s'avérer très utile pour les concepteurs de bases de données. (SQL:1999 et
   les versions suivantes définissent une fonctionnalité d'héritage de
   type qui diffère par de nombreux aspects des fonctionnalités décrites ici.)
  </para>

  <para>
   Soit l'exemple d'un modèle de données de villes. Chaque état comporte
   plusieurs villes mais une seule capitale. Pour récupérer rapidement la
   ville capitale d'un état donné, on peut créer deux tables, une pour les
   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&nbsp;? 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>&nbsp;:

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

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

   Dans ce cas, la table <structname>capitales</structname> <firstterm>hérite</firstterm> de
   toutes les colonnes de sa table parent, <structname>villes</structname>. Les capitales
   ont aussi une colonne supplémentaire, <structfield>etat</structfield>, qui
   indique l'état dont elles sont capitales.
  </para>

  <para>
   Dans <productname>PostgreSQL</productname>, une table peut hériter de zéro
   à 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&nbsp;:

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

   Avec les données du tutoriel de <productname>PostgreSQL</productname>
   (voir <xref linkend="tutorial-sql-intro"/>), ceci renvoie&nbsp;:

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

  <para>
   D'un autre côté, la requête suivante retourne les noms et altitudes
   de toutes les villes, qui ne sont
   pas des capitales, situées à une altitude supérieure à 500 pieds&nbsp;:

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

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

  <para>
   Le mot clé <literal>ONLY</literal> indique que la requête s'applique
   uniquement
   aux <structname>villes</structname>, et non pas à toutes les tables en-dessous
   de <structname>villes</structname> dans la hiérarchie de l'héritage. Un
   grand nombre des commandes déjà évoquées &mdash;
   <command>SELECT</command>, <command>UPDATE</command> et
   <command>DELETE</command> &mdash; supportent le mot clé
   <literal>ONLY</literal>.
  </para>

  <para>
  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&nbsp;:

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

   qui renvoie&nbsp;:

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

   (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&nbsp;:

<programlisting>SELECT p.relname, v.nom, v.altitude
FROM villes v, pg_class p
WHERE v.altitude &gt; 500 and v.tableoid = p.oid;</programlisting>

   ce qui retourne&nbsp;:

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

  <para>
   L'héritage ne propage pas automatiquement les données des commandes
   <command>INSERT</command> ou <command>COPY</command> aux autres tables de
   la hiérarchie de l'héritage. Dans l'exemple considéré, l'instruction
   <command>INSERT</command> suivante échoue&nbsp;:
<programlisting>INSERT INTO villes (nom, population, altitude, etat)
VALUES ('New York', NULL, NULL, 'NY');</programlisting>
   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&nbsp;:
   <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
   dans le
   cas ci-dessus car la table <structname>villes</structname> ne contient pas la
   colonne <structfield>etat</structfield>. La commande est donc rejetée avant que la
   règle ne soit appliquée.
  </para>

  <para>
   Toutes les contraintes de vérification et toutes les contraintes NOT NULL
   sur une table parent sont automatiquement héritées par les tables enfants.
   Les autres types de contraintes (unicité, clé primaire, clé étrangère)
   ne sont pas hérités.
  </para>

  <para>
   Une table peut hériter de plusieurs tables, auquel cas elle possède
   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
   contraintes de vérification en provenance de chaque définition de colonnes
   dont elle provient, et est marquée NOT NULL si une d'entre elles l'est.
  </para>

  <para>
   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é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
   type que les colonnes de la table parent. Elle doit aussi contenir
   des contraintes de vérification de mêmes nom et expression que celles
   de la table parent.
  </para>
  <para>
   De la même façon, un lien d'héritage peut être supprimé
   d'un enfant à l'aide de la variante <literal>NO INHERIT</literal>
   d'<command>ALTER TABLE</command>. Ajouter et supprimer dynamiquement des liens
   d'héritage de cette façon est utile quand cette relation d'héritage est
   utilisée pour le partitionnement des tables (voir
   <xref linkend="ddl-partitioning"/>).
  </para>

  <para>
   Un moyen pratique de créer une table compatible en vue d'en faire
   ultérieurement une table enfant est d'utiliser la clause
   <literal>LIKE</literal> dans <command>CREATE TABLE</command>. Ceci crée
   une nouvelle table avec les même
   colonnes que la table source. S'il existe des contraintes
   <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ée compatible.
  </para>

  <para>
   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.
   La suppression d'une table et de tous ces descendants peut être aisément
   obtenue en supprimant la table mère avec l'option
   <literal>CASCADE</literal>.
  </para>

  <para>
   <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 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 
    Je parlerai de chausse-trappe -->
 <sect2 id="ddl-inherit-caveats">
  <title>Restrictions</title>

  <para>
   Les droits d'accès des tables ne sont pas automatiquement hérités. De ce
   fait, un utilisateur qui tente d'accéder à une table parent doit, soit
   avoir les permissions pour réaliser l'opération sur toutes les tables
   enfants, soit utiliser le mot clé <literal>ONLY</literal>. Lors de l'ajout
   d'une nouvelle table enfant à un héritage existant, il faut s'assurer
   que tous les droits s'y appliquant soient accordés.
  </para>

  <para>
    Il existe une réelle limitation à la fonctionnalité d'héritage&nbsp;: les index
    (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&nbsp;:

    <itemizedlist>
      <listitem>
        <para>
          si <structname>villes</structname>.<structfield>nom</structfield>
	  est déclarée <literal>UNIQUE</literal> ou clé primaire
	  (<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
          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>&nbsp;;
        </para>
      </listitem>

      <listitem>
        <para>
          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 à
	  <structname>capitales</structname>. Il est facile de contourner ce
	  cas de figure en ajoutant manuellement la même contrainte
	  <literal>REFERENCES</literal> à
	  <structname>capitales</structname>&nbsp;;
        </para>
      </listitem>

      <listitem>
        <para>
          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>

    Ces déficiences seront probablement corrigées dans une version future,
    mais, en attendant, il est obligatoire de réfléchir consciencieusement à l'utilité
    de l'héritage pour un problème donné.
  </para>

  <note>
   <title>Obsolète</title>
   <para>
     Dans les versions de <productname>PostgreSQL</productname> antérieures à
     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"/>.
   </para>
  </note>

   </sect2>
  </sect1>

  <sect1 id="ddl-partitioning">
   <title>Partitionnement</title>

   <indexterm>
    <primary>partitionnement</primary>
   </indexterm>

   <indexterm>
    <primary>table</primary>
    <secondary>partitionnement</secondary>
   </indexterm>

   <para>
    <productname>PostgreSQL</productname> offre un support basique du
    partitionnement de table. Cette section explique pourquoi et comment
    implanter le partitionnement lors de la conception de la base
    de données.
   </para>

   <sect2 id="ddl-partitioning-overview">
     <title>Aperçu</title>

   <para>
    Le partitionnement fait référence à la division d'une table logique
    volumineuse en plusieurs parties physiques plus petites. Le partitionnement comporte
    de nombreux avantages&nbsp;:
   <itemizedlist>
    <listitem>
     <para>
     <!-- substitutes for ? -->
      les performances des requêtes peuvent être significativement améliorées
      dans certaines situations, particulièrement lorsque la plupart des lignes
      fortement accédées d'une table se trouvent sur une seule partition ou sur un
      petit nombre de partitions. Le partitionnement se substitue aux colonnes
      principales des index, réduisant ainsi la taille des index et facilitant
      la tenue en mémoire des parties les plus utilisées de l'index&nbsp;;
     </para>
    </listitem>

    <listitem>
     <para>
      lorsque les requêtes ou les mises à jour accèdent à un important pourcentage
      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&nbsp;;
     </para>
    </listitem>

    <listitem>
     <para>
      les chargements et suppressions importants de données peuvent être
      obtenus par l'ajout ou la suppression de partitions, sous réserve que ce
      besoin ait été pris en compte lors de la conception du partitionnement.
      <command>ALTER TABLE</command> est bien plus rapide qu'une opération de
      masse. Cela supprime également la surcharge dû au <command>VACUUM</command>
      causé par un <command>DELETE</command> massif&nbsp;;
     </para>
    </listitem>

    <listitem>
     <para>
      les données peu utilisées peuvent être déplacées sur un média de
      stockage moins cher et plus lent.
     </para>
    </listitem>
   </itemizedlist>

    Les bénéfices ne sont réellement intéressants que si cela permet d'éviter une
    table autrement plus volumineuse. Le point d'équilibre exact à partir
    duquel une table tire des bénéfices du partitionnement dépend de
    l'application. Toutefois, le partitionnement doit être envisagé si
    la taille de la table peut être amenée à dépasser la taille de la
    mémoire physique du serveur.
   </para>

   <para>
    Actuellement, <productname>PostgreSQL</productname> supporte le
    partitionnement à travers l'héritage de tables. Chaque partition doit être
    créée comme une table enfant d'une unique table parent. La table parent
    est, elle, habituellement vide&nbsp;; elle n'existe que pour
    représenter l'ensemble complet des données. Il est impératif de maîtriser
    les concepts de l'héritage (voir <xref linkend="ddl-inherit"/>) avant de tenter
    d'implanter le partitionnement.
   </para>

   <para>
    Les formes suivantes de partitionnement peuvent être implantées dans
    <productname>PostgreSQL</productname>&nbsp;:

    <variablelist>
     <varlistentry>
<!-- range ? Echelle -->
      <term>Partitionnement par échelon</term>

<!-- overlap ? Recouvrement, chevauchement... -->
      <listitem>
       <para>
        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
	échelles d'identifiants pour des objets métier particuliers.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>Partitionnement par liste</term>

      <listitem>
       <para>
        La table est partitionnée en listant explicitement les valeurs clés
	qui apparaissent dans chaque partition.
       </para>
      </listitem>
     </varlistentry>	
    </variablelist>

   </para>
   </sect2>

   <sect2 id="ddl-partitioning-implementation">
     <title>Partitionner</title>

    <para>
     Pour partionner une table, la procédure est la suivante&nbsp;:
     <orderedlist spacing="compact">
      <listitem>
       <para>
        Créer la table <quote>maître</quote>. C'est de celle-ci qu'héritent toutes
	les partitions.
       </para>
       <para>
        Cette table ne contient pas de données. Les contraintes
	de vérification ne doivent être définies sur cette table que si elles
	sont appliquées à toutes les partitions. Il n'y a de plus aucune raison de
	définir des index ou des contraintes d'unicité sur cette table.
       </para>
      </listitem>

      <listitem>
       <para>
        Créer plusieurs tables <quote>filles</quote> (ou enfants) qui héritent chacune de la
	table maître. Normalement, ces tables n'ajoutent pas de colonnes
	à l'ensemble hérité du maître.
       </para>

       <para>
        Par la suite, les tables enfants sont appelées partitions, bien
	qu'elles soient, en tout point, des tables <productname>PostgreSQL</productname>
	normales.
       </para>
      </listitem>

      <listitem>
       <para>
        Ajouter les contraintes de tables aux tables de partitions pour définir
	les valeurs des clés autorisées dans chacune.
       </para>

       <para>
        Quelques exemples typiques&nbsp;:
<programlisting>CHECK ( x = 1 )
CHECK ( comté IN ( 'Oxfordshire', 'Buckinghamshire', 'Warwickshire' ))
CHECK ( ID &gt;= 100 AND ID &lt; 200 )</programlisting>
        Les contraintes doivent garantir qu'il n'y a pas
	de recouvrement entre les valeurs clés autorisées dans les différentes
	partitions. Une erreur commune est de configurer des contraintes
	d'échelle de cette façon&nbsp;:
<programlisting>CHECK ( comté BETWEEN 100 AND 200 )
CHECK ( comté BETWEEN 200 AND 300 )</programlisting>
        Il est dans ce cas difficile de savoir à quelle partition
	appartient la clé 200.
       </para>

       <para>
        Il n'y a aucune différence entre les syntaxes de partitionnement
	par échelon et de partitionnement par liste&nbsp;; ces termes ne sont
	que descriptifs.
       </para>
      </listitem>

      <listitem>
       <para>
        Pour chaque partition, créer un index sur la (ou les) colonne(s) clé(s),
        ainsi que tout autre index nécessaire. (L'index clé n'est pas vraiment
	nécessaire mais, dans la plupart des scénarios, il est utile. Si 
	les valeurs clés doivent être uniques, alors il faut
	toujours créer une contrainte d'unicité ou de clé primaire pour chaque
	partition.)
       </para>
      </listitem>

      <listitem>
       <para>
        Optionnellement, définir un déclencheur ou une règle pour rediriger les
        données insérées dans la table maître vers la partition appropriée.
       </para>
      </listitem>

      <listitem>
       <para>
        S'assurer que le paramètre de configuration
	<xref linkend="guc-constraint-exclusion"/> est activé dans
	<filename>postgresql.conf</filename>. Dans le cas contraire, les requêtes ne sont
	pas optimisées.
       </para>
      </listitem>

     </orderedlist>
    </para>

    <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 à&nbsp;:

<programlisting>CREATE TABLE mesure (
    id_ville        int not null,
    date_trace      date not null,
    temperature     int,
    ventes          int
);</programlisting>

     La plupart des requêtes n'accèdent qu'aux données de la dernière
     semaine, du dernier mois ou du dernier trimestre car cette table est
     essentiellement utilisée pour préparer des rapports en ligne pour la
     direction. Pour réduire le nombre de données anciennes à stocker,
     seules les trois dernières années sont conservées. Au début
     de chaque mois, les données du mois le plus ancien sont supprimées.
    </para>

    <para>
     Dans cette situation, le partitionnement permet de répondre aux
     différents besoins identifiés sur la table des mesures. En suivant les
     étapes indiquées ci-dessus, le partitionnement peut être configuré de la
     façon suivante&nbsp;:
    </para>

    <para>
     <orderedlist spacing="compact">
      <listitem>
       <para>
        la table maître est la table <structname>mesure</structname>, déclarée exactement
	comme ci-dessus&nbsp;;
       </para>
      </listitem>

      <listitem>
       <para>
        une partition est ensuite créée pour chaque mois actif&nbsp;:

<programlisting>CREATE TABLE mesure_a2006m02 ( ) INHERITS (mesure);
CREATE TABLE mesure_a2006m03 ( ) INHERIT (mesure);
...
CREATE TABLE mesure_a2007m11 ( ) INHERITS (mesure);
CREATE TABLE mesure_a2007m12 ( ) INHERITS (mesure);
CREATE TABLE mesure_a2008m01 ( ) INHERITS (mesure);</programlisting>

        Chaque partition est une table à part entière mais
	sa définition est héritée de la table <structname>mesure</structname>.
       </para>

       <para>
	Ceci résoud un des problèmes&nbsp;: la suppression d'anciennes données.
	Chaque mois, il suffit d'effectuer un <command>DROP TABLE</command> sur
	la table enfant la plus ancienne et de créer une nouvelle table
	enfant pour les données du nouveau mois.
       </para>
      </listitem>

      <listitem>
       <para>
	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 ressemble
	à&nbsp;;

<programlisting>CREATE TABLE mesure_a2006m02 (
    CHECK ( date_trace &gt;= DATE '2006-02-01' AND date_trace &lt; DATE '2006-03-01' )
) INHERITS (mesure);
CREATE TABLE mesure_a2006m03 (
    CHECK ( date_trace &gt;= DATE '2006-03-01' AND date_trace &lt; DATE '2006-04-01' )
) INHERITS (mesure);
...
CREATE TABLE mesure_a2007m11 (
    CHECK ( date_trace &gt;= DATE '2007-11-01' AND date_trace &lt; DATE '2007-12-01' )
) INHERITS (mesure);
CREATE TABLE mesure_a2007m12 (
    CHECK ( date_trace &gt;= DATE '2007-12-01' AND date_trace &lt; DATE '2007-01-01' )
) INHERITS (mesure);
CREATE TABLE mesure_a2008m01 (
    CHECK ( date_trace &gt;= DATE '2008-01-01' AND date_trace &lt; DATE '2008-02-01' )
) INHERITS (mesure);</programlisting>
       </para>
      </listitem>

      <listitem>
       <para>
        Des index sur les colonnes clés sont probablement nécessaires&nbsp;:

<programlisting>CREATE INDEX mesure_a2006m02_date_trace ON mesure_a2006m02 (date_trace);
CREATE INDEX mesure_a2006m03_date_trace ON mesure_a2006m03 (date_trace);
...
CREATE INDEX mesure_a2007m11_date_trace ON mesure_a2007m11 (date_trace);
CREATE INDEX mesure_a2007m12_date_trace ON mesure_a2007m12 (date_trace);
CREATE INDEX mesure_a2008m01_date_trace ON mesure_a2008m01 (date_trace);</programlisting>

        À ce stade, c'est suffisant.
       </para>
      </listitem>

      <listitem>
       <para>
        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,
	la fonction est très simple.

<programlisting>
CREATE OR REPLACE FUNCTION mesure_insert_trigger()
RETURNS TRIGGER AS $$
BEGIN
    INSERT INTO mesure_a2008m01 VALUES (NEW.*);
    RETURN NULL;
END;
$$
LANGUAGE plpgsql;
</programlisting>

        Le déclencheur qui appelle la fonction est créé à sa suite&nbsp;:

<programlisting>
CREATE TRIGGER insert_mesure_trigger
    BEFORE INSERT ON mesure
    FOR EACH ROW EXECUTE PROCEDURE mesure_insert_trigger();
</programlisting>

        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 déclencheur plus complexe peut être utilisée pour cela&nbsp;:

<programlisting>
CREATE OR REPLACE FUNCTION mesure_insert_trigger()
RETURNS TRIGGER AS $$
BEGIN
    IF ( NEW.date_trace &gt;= DATE '2006-02-01' AND NEW.date_trace &lt; DATE '2006-03-01' ) THEN
        INSERT INTO mesure_a2006m02 VALUES (NEW.*);
    ELSIF ( NEW.date_trace &gt;= DATE '2006-03-01' AND NEW.date_trace &lt; DATE '2006-04-01' ) THEN
        INSERT INTO mesure_a2006m03 VALUES (NEW.*);
    ...
    ELSIF ( NEW.date_trace &gt;= DATE '2008-01-01' AND NEW.date_trace &lt; DATE '2008-02-01' ) THEN
        INSERT INTO mesure_a2008m01 VALUES (NEW.*);
    ELSE
        RAISE EXCEPTION 'Date en dehors de l''échelle. Corrigez la fonction mesure_insert_trigger() !';
    END IF;
    RETURN NULL;
END;
$$
LANGUAGE plpgsql;
</programlisting>

        La définition du déclencheur ne change pas. Chaque
	test <literal>IF</literal> doit correspondre exactement à la
	contrainte <literal>CHECK</literal> de cette partition.
       </para>

       <para>
        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 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>
     </orderedlist>
    </para>

    <para>
     Un schéma complexe de partitionnement peut amener à écrire une grande
     quantité de DDL. Dans l'exemple ci-dessus, une
     nouvelle partition est écrite chaque mois. Il est donc conseillé d'écrire un script qui
     engendre automatiquement la DDL requise.
    </para>

   </sect2>

   <sect2 id="ddl-partitioning-managing-partitions">
   <title>Gérer les partitions</title>

   <para>
     Généralement, l'ensemble des partitions établies lors de la définition
     initiale de la table n'a pas pour but de rester statique. Il n'est pas
     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, 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>

   <para>
     L'option la plus simple pour supprimer d'anciennes données consiste à
     supprimer la partition qui n'est plus nécessaire&nbsp;:
<programlisting>DROP TABLE mesure_a2006m02;
</programlisting>
     Cela permet de supprimer très rapidement des millions d'enregistrements
     car il n'est nul besoin de supprimer séparément chaque enregistrement.
   </para>

   <para>
     Une autre option, souvent préférable, consiste à supprimer la partition de la
     table partitionnée mais de conserver l'accès à la table en tant que telle&nbsp;:
<programlisting>ALTER TABLE mesure_a2006m02 NO INHERIT mesure;
</programlisting>
     Ceci permet la réalisation d'opérations ultérieures sur les données
     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 denses, de réaliser d'autres
     opérations sur les données ou de créer des rapports.
   </para>

   <para>
     De façon similaire, une nouvelle partition peut être ajoutée pour
     gérer les nouvelles données. Une partition vide peut être créée dans la
     table partitionnée de la même façon que les partitions individuelles
     créées plus haut&nbsp;:

<programlisting>
CREATE TABLE mesure_a2008m02 (
    CHECK ( date_trace &gt;= DATE '2008-02-01' AND date_trace &lt; DATE '2008-03-01' )
    ) INHERITS (mesure);
</programlisting>

     Alternativement, il est parfois plus intéressant de créer la
     nouvelle table en dehors de la structure de partitionnement et de
     la transformer en une partition adéquate plus tard. Cela permet de
     charger les données, les vérifier et les transformer avant leur apparition
     dans la table partitionnée&nbsp;:

<programlisting>
CREATE TABLE mesure_a2008m02
  (LIKE mesure INCLUDING DEFAULTS INCLUDING CONSTRAINTS);
ALTER TABLE mesure_a2008m02 ADD CONSTRAINT y2008m02
   CHECK ( date_trace &gt;= DATE '2008-02-01' AND date_trace &lt; DATE '2008-03-01' );
\copy mesure_a2008m02 from 'mesure_a2008m02'
-- quelques travaux de préparation des données
ALTER TABLE mesure_a2008m02 INHERIT mesure;
</programlisting>

    </para>
   </sect2>

   <sect2 id="ddl-partitioning-constraint-exclusion">
   <title>Partitionnement et exclusion de contrainte</title>

   <indexterm>
    <primary>exclusion de contrainte</primary>
   </indexterm>

   <para>
    L'<firstterm>exclusion de contrainte</firstterm> est une technique d'optimisation des
    requêtes pour améliorer les performances sur les tables partitionnées
    telles que décrites plus haut. Par exemple&nbsp;:

<programlisting>SET constraint_exclusion = on;
SELECT count(*) FROM mesure WHERE date_trace &gt;= DATE '2008-01-01';</programlisting>

    Sans exclusion de contrainte, la requête ci-dessus parcourt chacune
    des partitions de la table <structname>mesure</structname>. Avec l'exclusion de
    contrainte activée, le planificateur examine les contraintes de chaque
    partition et tente de prouver que la partition n'a pas besoin d'être
    parcourue parce qu'elle ne peutt pas contenir de lignes correspondant à
    la clause <literal>WHERE</literal> de la requête. Quand le planificateur peut le
    prouver, il exclut la partition du plan de requête.
   </para>

   <para>
    La commande <command>EXPLAIN</command> permet d'afficher la
    différence entre un plan avec <varname>constraint_exclusion</varname>
    activé (<foreignphrase>on</foreignphrase>) et un plan avec ce paramètre désactivé
    (<foreignphrase>off</foreignphrase>). Un plan typique par défaut pour ce type de
    table est&nbsp;:

<programlisting>SET constraint_exclusion = off;
EXPLAIN SELECT count(*) FROM mesure WHERE date_trace &gt;= DATE '2008-01-01';

                                          QUERY PLAN
-------------------------------------------------------------------------------------
 Aggregate  (cost=158.66..158.68 rows=1 width=0)
   -&gt;  Append  (cost=0.00..151.88 rows=2715 width=0)
         -&gt;  Seq Scan on mesure  (cost=0.00..30.38 rows=543 width=0)
               Filter: (date_trace &gt;= '2008-01-01'::date)
         -&gt;  Seq Scan on mesure_a2006m02 mesure  (cost=0.00..30.38 rows=543 width=0)
               Filter: (date_trace &gt;= '2008-01-01'::date)
         -&gt;  Seq Scan on mesure_ay2006m03 mesure  (cost=0.00..30.38 rows=543 width=0)
               Filter: (date_trace &gt;= '2008-01-01'::date)
...
         -&gt;  Seq Scan on mesure_a2007m12 mesure  (cost=0.00..30.38 rows=543 width=0)
               Filter: (date_trace &gt;= '2008-01-01'::date)
         -&gt;  Seq Scan on mesure_a2008m01 mesure  (cost=0.00..30.38 rows=543 width=0)
               Filter: (date_trace &gt;= '2008-01-01'::date)
</programlisting>

    Quelques partitions, voire toutes, peuvent utiliser des parcours d'index
    à la place des parcours séquentiels de la table complète mais le fait est
    qu'il n'est pas besoin de parcourir les anciennes partitions pour répondre
    à cette requête. Lorsque l'exclusion de contrainte est activée, 
    un plan significativement réduit est obtenu, qui délivre la même
    réponse&nbsp;:

<programlisting>SET constraint_exclusion = on;
EXPLAIN SELECT count(*) FROM mesure WHERE date_trace &gt;= DATE '2008-01-01';
                                          QUERY PLAN
-------------------------------------------------------------------------------------
 Aggregate  (cost=63.47..63.48 rows=1 width=0)
   ->  Append  (cost=0.00..60.75 rows=1086 width=0)
         ->  Seq Scan on mesure  (cost=0.00..30.38 rows=543 width=0)
               Filter: (date_trace &gt;= '2008-01-01'::date)
         ->  Seq Scan on mesure_a2008m01 mesure  (cost=0.00..30.38 rows=543 width=0)
               Filter: (date_trace &gt;= '2008-01-01'::date)</programlisting>
   </para>

   <para>
    L'exclusion de contraintes n'est pilotée que par les contraintes
    <literal>CHECK</literal>, pas par la présence d'index. Il n'est donc pas
    nécessaire de définir des index sur les colonnes clés. Le fait qu'un index
    doive être créé pour une partition donnée dépend de ce que les requêtes qui
    parcourent la partition parcourent en général une grande partie de la partition
    ou seulement une petite partie. Un index est utile dans le dernier cas, pas dans le premier.
   </para>
   </sect2>

   <sect2 id="ddl-partitioning-alternatives">
   <title>Autre méthode de partitionnement</title>

    <para>
     Une approche différente pour la redirection des insertions dans la
     table fille appropriée est de configurer des règles, à la place d'un
     déclencheur, sur la table maître. Par exemple&nbsp;:

<programlisting>
CREATE RULE mesure_insert_a2006m02 AS
ON INSERT TO mesure WHERE
    ( date_trace &gt;= DATE '2006-02-01' AND date_trace &lt; DATE '2006-03-01' )
DO INSTEAD
    INSERT INTO mesure_a2006m02 VALUES (NEW.*);
...
CREATE RULE mesure_insert_a2008m01 AS
ON INSERT TO mesure WHERE
    ( date_trace &gt;= DATE '2008-01-01' AND date_trace &lt; DATE '2008-02-01' )
DO INSTEAD
    INSERT INTO mesure_a2008m01 VALUES (NEW.*);
</programlisting>

     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>
     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 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>
     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&nbsp;:

<programlisting>
CREATE VIEW mesure AS
          SELECT * FROM mesure_a2006m02
UNION ALL SELECT * FROM mesure_a2006m03
...
UNION ALL SELECT * FROM mesure_a2007m11
UNION ALL SELECT * FROM mesure_a2007m12
UNION ALL SELECT * FROM mesure_a2008m01;
</programlisting>

     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
     au regard de l'héritage.
    </para>

   </sect2>

   <sect2 id="ddl-partitioning-caveats">
   <title>Restrictions</title>

   <para>
    Les restrictions suivantes s'appliquent aux tables partitionnées&nbsp;:
   <itemizedlist>
    <listitem>
     <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 fabrique les
      partitions et crée et/ou modifie les objets associés plutôt que de les
      créer manuellement&nbsp;;
     </para>
    </listitem>

    <listitem>
     <para>
      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 é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>
    </listitem>

    <listitem>
     <para>
      si <command>VACUUM</command> ou
      <command>ANALYZE</command> sont lancés manuellement, il est obligatoire
      de les utiliser sur chaque partition. Une commande comme&nbsp;:
<programlisting>
ANALYZE mesure;
</programlisting>
      ne traite que la table maître.
     </para>
    </listitem>
   </itemizedlist>
   </para>

   <para>
    Les restrictions suivantes s'appliquent à l'exclusion de contraintes&nbsp;:

   <itemizedlist>
    <listitem>
     <para>
      l'exclusion de contrainte ne fonctionne que si la clause
      <literal>WHERE</literal> de la requête contient des constantes. Une requête avec
      paramètre n'est pas optimisée car le planificateur ne peut avoir
      connaissance au préalable des partitions sélectionnées par la valeur du
      paramètre à l'exécution. Pour la même raison, il faut éviter les fonctions
      <quote>stable</quote>s comme <function>CURRENT_DATE</function>&nbsp;;
     </para>
    </listitem>

    <listitem>
     <para>
      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>

    <listitem>
     <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 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&nbsp;;
      il est impensable de vouloir atteindre des milliers de partitions.
     </para>
    </listitem>

   </itemizedlist>
   </para>
  </sect2>
 </sect1>

 <sect1 id="ddl-others">
  <title>Autres objets de la base de données</title>

  <para>
   Les tables sont les objets centraux dans une structure de base de
   données relationnelles, car ce sont elles qui stockent les données.
   Mais ce ne sont pas les seuls objets qui
   existent dans une base de données. De nombreux autres types d'objets
   peuvent être créés afin de rendre l'utilisation et la gestion
   des données plus efficace ou pratique. Ils ne sont pas abordés
   dans ce chapitre mais une liste en est dressée à titre d'information.
  </para>

  <itemizedlist>
   <listitem>
    <para>
     Vues
    </para>
   </listitem>

   <listitem>
    <para>
     Fonctions et opérateurs
    </para>
   </listitem>

   <listitem>
    <para>
     Types de données et domaines
    </para>
   </listitem>

   <listitem>
    <para>
     Déclencheurs et règles de réécriture
    </para>
   </listitem>
  </itemizedlist>

  <para>
   Des informations détaillées sur ces sujets apparaissent dans la <xref
   linkend="server-programming"/>.
  </para>
 </sect1>

 <sect1 id="ddl-depend">
  <title>Gestion des dépendances</title>

  <indexterm zone="ddl-depend">
   <primary>CASCADE</primary>
   <secondary sortas="DROP">with DROP</secondary>
  </indexterm>

  <indexterm zone="ddl-depend">
   <primary>RESTRICT</primary>
   <secondary sortas="DROP">with DROP</secondary>
  </indexterm>

  <para>
   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éé.
   Par exemple, une table avec une contrainte de clé étrangère dépend
   de la table à laquelle elle fait référence.
  </para>

  <para>
   Pour garantir l'intégrité de la structure entière de la base,
   <productname>PostgreSQL</productname> s'assure qu'un objet dont d'autres
   objets dépendent ne peut pas être supprimé. Ainsi, toute 
   tentative de suppression de la table des produits 
   utilisée dans la <xref linkend="ddl-constraints-fk"/>, sachant que la
   table des commandes en dépend, lève un message d'erreur
   comme celui-ci&nbsp;:
<screen>DROP TABLE produits;

NOTICE:  constraint commandes_no_produit_fkey on table commandes depends on table
produits
ERROR:  cannot drop table produits because other objects depend on it
HINT:  Use DROP ... CASCADE to drop the dependent objects too.</screen>

ou en français&nbsp;:
<screen>DROP TABLE produits;

NOTICE:  la contrainte commandes_no_produit_fkey sur la table commandes dépend
de la table produits
ERREUR:  la table produits ne peut pas être supprimée, car d'autre objets en
dépendent
HINT:  Utiliser DROP ... CASCADE pour supprimer également les objets
dépendants.</screen>

   Le message d'erreur contient un indice utile&nbsp;: pour ne pas avoir à
   supprimer individuellement chaque objet dépendant, on peut
   lancer
<screen>DROP TABLE produits CASCADE;</screen>
   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>.)
  </para>

  <para>
   Toutes les commandes de suppression dans
   <productname>PostgreSQL</productname> supportent l'utilisation de
   <literal>CASCADE</literal>. La nature des dépendances
   est évidemment fonction de la nature des objets. On peut aussi écrire
   <literal>RESTRICT</literal> au lieu de <literal>CASCADE</literal>
   pour obtenir le comportement par défaut, à savoir interdire les
   suppressions d'objets dont dépendent d'autres objets.
  </para>

  <note>
   <para>
    D'après le standard SQL, il est nécessaire d'indiquer
    <literal>RESTRICT</literal> ou <literal>CASCADE</literal>.
    Aucun système de base de donnée ne force cette règle, en réalité,
    mais le choix du comportement par défaut,
    <literal>RESTRICT</literal> ou <literal>CASCADE</literal>,
    varie suivant le système.
   </para>
  </note>

  <note>
   <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 <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.
   </para>
  </note>
 </sect1>

</chapter>