root/traduc/trunk/postgresql/advanced.xml

<?xml version="1.0" encoding="ISO-8859-15"?>
<!-- Dernière modification
     le       $Date$
     par      $Author$
     révision $Revision$ -->
<!-- SAS : 20070311 -->

 <chapter id="tutorial-advanced">
  <title>Fonctionnalités avancées</title>

  <sect1 id="tutorial-advanced-intro">
   <title>Introduction</title>

   <para>
    Le chapitre précédant couvre les bases de l'utilisation
    de <acronym>SQL</acronym> pour le stockage et l'accès aux données avec
    <productname>PostgreSQL</productname>. Il est temps d'aborder
    quelques fonctionnalités avancées du <acronym>SQL</acronym>
    qui simplifient la gestion et empêchent la perte ou la corruption des
    données. Quelques extensions de <productname>PostgreSQL</productname> sont
    également abordées.
   </para>

   <para>
    Ce chapitre fait occasionnellement référence aux exemples disponibles dans le
    <xref linkend="tutorial-sql"/> pour les modifier ou les améliorer. Il est donc
    préférable d'avoir lu ce chapitre. Quelques exemples de ce
    chapitre sont également disponibles dans <filename>advanced.sql</filename>
    situé dans le répertoire du tutoriel. Ce fichier contient, de plus, quelques
    données à charger pour utiliser l'exemple. Cela n'est pas repris ici 
    (on peut se référer à la <xref linkend="tutorial-sql-intro"/> pour savoir comment
    utiliser ce fichier).
   </para>
  </sect1>


  <sect1 id="tutorial-views">
   <title>Vues</title>

   <indexterm zone="tutorial-views">
    <primary>vue</primary>
    <secondary>view</secondary>
   </indexterm>

   <para>
    Se référer aux requêtes de la <xref linkend="tutorial-join"/>.
    Si la liste des enregistrements du temps et des villes est d'un
    intérêt particulier pour l'application considérée mais qu'il devient
    contraignant de saisir la requête à chaque utilisation, il est possible
    de créer une <firstterm>vue</firstterm> avec la requête. De ce fait, la
    requête est nommée et il peut y être fait référence de la même façon
    qu'il est fait référence à une table&nbsp;:

<programlisting>CREATE VIEW ma_vue AS
    SELECT ville, t_basse, t_haute, prcp, date, emplacement
        FROM temps, villes
        WHERE ville = nom;

SELECT * FROM ma_vue;</programlisting>
   </para>

   <para>
    L'utilisation des vues est un aspect clé d'une bonne
    conception des bases de données SQL. Les vues permettent
    d'encapsuler les détails de la structure des tables. Celle-ci peut
    alors changer avec l'évolution de l'application, tandis que l'interface reste
    constante.
   </para>

   <para>
    Les vues peuvent être utilisées dans quasiment toutes les situations
    où une vraie table est utilisable. Il n'est, de plus, pas
    inhabituel de construire des vues reposant sur d'autres vues.
   </para>
  </sect1>


  <sect1 id="tutorial-fk">
   <title>Clés étrangères</title>

   <indexterm zone="tutorial-fk">
    <primary>clé étrangère</primary>
    <secondary>foreign key</secondary>
   </indexterm>

   <indexterm zone="tutorial-fk">
    <primary>intégrité référentielle</primary>
    <secondary>referential integrity</secondary>
   </indexterm>

   <para>
    Soient les tables 
    <classname>temps</classname> et <classname>villes</classname> définies
    dans le <xref linkend="tutorial-sql"/>.
    Il s'agit maintenant de s'assurer que personne
    n'insère de ligne dans la table <classname>temps</classname> qui ne
    corresponde à une entrée dans la table <classname>villes</classname>.
    On appelle cela maintenir l'<firstterm>intégrité
    référentielle</firstterm> des données. Dans les systèmes de bases de
    données simplistes, lorsqu'au moins c'est possible, cela est parfois
    obtenu par la vérification préalable de l'existence d'un enregistrement
    correspondant dans la table <classname>villes</classname>, puis par
    l'insertion, ou l'interdiction, du nouvel enregistrement dans 
    <classname>temps</classname>. Puisque cette approche, peu pratique, 
    présente un certain nombre d'inconvénients, 
    <productname>PostgreSQL</productname> peut se charger du maintien de
    l'<firstterm>intégrité référentielle</firstterm>.
   </para>

   <para>
    La nouvelle déclaration des tables ressemble alors à ceci&nbsp;:

<programlisting>CREATE TABLE villes (
        ville       varchar(80) primary key,
        emplacement point
);

CREATE TABLE temps (
        ville      varchar(80) references villes,
        t_haute int,
        t_basse int,
        prcp       real,
        date       date
);</programlisting>

    Lors d'une tentative d'insertion d'enregistrement non valide&nbsp;:

<programlisting>INSERT INTO temps VALUES ('Berkeley', 45, 53, 0.0, '1994-11-28');</programlisting>

<screen>ERROR:  insert or update on table "temps" violates foreign key constraint "temps_ville_fkey"
DETAIL : Key (ville)=(a) is not present in table "villes".</screen>

<!-- SAS 20061109
Pourquoi ne pas traduire les messages d'erreur ?
<screen>ERROR:  insert or update on table "temps" violates foreign key constraint "temps_ville_fkey"
DETAIL:  Key (ville)=(Berkeley) is not present in table "villes".</screen>
-->
   </para>

<!-- SAS 20080225
Clé secondaire ? -->
   <para>
    Le comportement des clés étrangères peut être adapté très finement à
    une application particulière. Ce tutoriel ne va pas plus loin que cet exemple simple.
    De plus amples informations sont accessibles dans le <xref linkend="ddl"/>.
    Une utilisation efficiente des clés étrangères améliore la
    qualité des applications accédant aux bases de données. Il est donc
    fortement conseillé d'apprendre à les utiliser.
   </para>
  </sect1>


  <sect1 id="tutorial-transactions">
   <title>Transactions</title>

   <indexterm zone="tutorial-transactions">
    <primary>transaction</primary>
   </indexterm>

   <para>
    Les <firstterm>transactions</firstterm> sont un concept fondamental de tous les
    systèmes de bases de données. Une transaction assemble plusieurs étapes
    en une seule opération tout-ou-rien.
    Les états intermédiaires entre les étapes ne sont pas visibles par les
    transactions concurrentes. De plus, si un échec survient qui empêche le
    succès de la transaction, alors aucune des étapes n'affecte la base
    de données.
   </para>

   <para>
    Si l'on considère, par exemple, la base de données d'une banque qui
    contient le solde de différents comptes clients et le solde total des
    dépôts par branches et que l'on veuille enregistrer un virement de
    100 euros du compte d'Alice vers celui de Bob, 
    les commandes SQL peuvent ressembler à cela (après simplification)&nbsp;:

<programlisting>UPDATE comptes SET balance = balance - 100.00
    WHERE nom = 'Alice';
UPDATE branches SET balance = balance - 100.00
    WHERE nom = (SELECT nom_branche FROM comptes WHERE nom = 'Alice');
UPDATE comptes SET balance = balance + 100.00
    WHERE nom = 'Bob';
UPDATE branches SET balance = balance + 100.00
    WHERE nom = (SELECT nom_branche FROM comptes WHERE nom = 'Bob');</programlisting>
   </para>

   <para>
    Ce ne sont pas les détails des commandes qui importent ici&nbsp;; le point
    important est la nécessité de plusieurs mises à jour séparées pour
    accomplir cette opération assez simple. Les employés de la banque
    veulent être assurés que, soit toutes les commandes sont effectuées,
    soit aucune ne l'est. Il n'est pas envisageable que, suite à une erreur
    du système, Bob reçoive 100 euros qui n'ont pas été débités du compte
    d'Alice. De la même façon, Alice ne restera pas longtemps une cliente fidèle
    si elle est débitée du montant sans que celui-ci ne soit crédité sur le compte
    de Bob.
   </para>
   <para>
    Il est important de garantir que si quelque chose se
    passe mal, aucune des étapes déjà exécutées n'est prise en compte. Le
    regroupement des mises à jour au sein d'une <firstterm>transaction</firstterm>
    apporte cette garantie.
    Une transaction est dite <firstterm>atomique</firstterm>&nbsp;:
    du point de vue des autres transactions, elle passe complètement ou pas du tout.
   </para>

   <para>
    Il est également nécessaire de garantir qu'une fois la transaction
    terminée et validée par la base de données, les transactions sont
    enregistrées définitivement et ne peuvent être perdues, même si une
    panne survient peu après.
   </para>
   <para>
    Ainsi, si un retrait d'argent est effectué par Bob, il ne faut
    absolument pas que le débit de son compte disparaisse avec l'apparition
    d'une panne juste après son départ de la banque. 
   </para>
   <para>
    Une base de données transactionnelle garantit que toutes les mises à jour
    faites lors d'une transaction sont stockées de manière persistante
    (c'est-à-dire sur disque) avant que la transaction ne soit déclarée validée.
   </para>

   <para>
    Une autre propriété importante des bases de données transactionnelles est
    en relation étroite avec la notion de mises à jour atomiques&nbsp;: quand
    plusieurs transactions sont lancées en parallèle, aucune d'entre elles
    ne doit être capable de voir les modifications incomplètes effectuées
    par les autres.
   </para>
   <para>
    Ainsi, si une transaction calcule le total de toutes les branches,
    inclure le débit de la branche d'Alice sans le crédit de la branche de
    Bob, ou vice-versa, est une véritable erreur.
   </para>
   <para>
    Les transactions doivent donc être tout-ou-rien, non seulement pour leur
    effet persistant sur la base de données, mais aussi pour leur visibilité
    au moment de leur exécution. Les mises à jour faites jusque-là par une
    transaction ouverte sont invisibles aux autres transactions jusqu'à la fin
    de celle-là. À ce moment toutes les mises à jours deviennent
    simultanément visibles.
   </para>

   <para>
    Sous <productname>PostgreSQL</productname>, une transaction est déclarée 
    en entourant les commandes SQL de la transaction par les commandes
    <command>BEGIN</command> et <command>COMMIT</command>. 
   </para>
   <para>
    La transaction bancaire ressemble alors à ceci&nbsp;:

<programlisting>BEGIN;
UPDATE comptes SET balance = balance - 100.00
    WHERE nom = 'Alice';
-- etc etc
COMMIT;</programlisting>
   </para>

   <para>
    Si, au cours de la transaction, il est décidé de ne pas valider
    (peut-être la banque s'aperçoit-elle que la balance d'Alice passe en 
    négatif), la commande <command>ROLLBACK</command> peut être utilisée à
    la place de <command>COMMIT</command>. Toutes les mises à jour réalisées
    jusque-là sont alors annulées.
   </para>

   <para>
    En fait, <productname>PostgreSQL</productname> traite chaque instruction SQL comme
    si elle était exécutée dans une transaction. En l'absence de commande
    <command>BEGIN</command> explicite, chaque instruction individuelle se trouve
    implicitement entourée d'un <command>BEGIN</command> et (en cas de succès) d'un
    <command>COMMIT</command>. 
   </para>
   <para>
    Un groupe d'instructions entourées par 
    <command>BEGIN</command> et <command>COMMIT</command> est parfois appelé 
    <firstterm>bloc transactionnel</firstterm>.
   </para>

   <note>
    <para>
     Quelques bibliothèques clientes lancent les commandes
     <command>BEGIN</command> et <command>COMMIT</command> automatiquement.
     L'utilisateur bénéficie alors des effets des blocs transactionnels
     sans les demander. Ces informations se trouvent en général dans la
     documentation de l'interface utilisée.
    </para>
   </note>
   
   <para>
    Il est possible d'augmenter la granularité du contrôle des instructions
    au sein d'une transaction en utilisant des 
    <firstterm>points de retournement</firstterm>
    (<foreignphrase>savepoint</foreignphrase>). Ceux-ci permettent d'annuler des
    parties de la transaction tout en validant le reste.
   </para>
   <para>
    Après avoir défini un point de retournement à l'aide de
    <command>SAVEPOINT</command>, les instructions exécutées depuis ce point
    peuvent, au besoin, être annulées avec <command>ROLLBACK TO</command>. 
    Toutes les modifications de la base de données effectuées par la
    transaction entre le moment où le point de retournement a été défini et
    celui où l'annulation est demandée sont annulées mais les modifications
    antérieures à ce point sont conservées.
   </para> 

   <para>
    Le retour à un point de retournement ne l'annule pas. Il reste défini et
    peut donc être utilisé plusieurs fois. À l'inverse, lorsqu'il n'est plus
    nécessaire de revenir à un point de sauvegarde pariculier, il peut être
    relâché, ce qui permet de libérer des ressources systèmes. Il faut
    savoir toutefois que relâcher un point de retournement, ou y revenir
    relâche tous les points de sauvegarde qui ont été définis après.
   </para> 

   <para>
    Tout ceci survient à l'intérieur du bloc de transaction, et n'est donc pas
    visible par les autres sessions en cours sur la base de données. Si le
    bloc est validé, et à ce moment-là seulement, toutes les actions validées
    deviennent immédiatement visibles par les autres sessions, tandis que
    les actions annulées ne le seront jamais.
   </para> 

   <para>
    Reconsidérant la base de données de la banque, on peut supposer vouloir
    débiter le compte d'Alice de $100.00, somme à créditer sur le compte de Bob,
    mais considérer plus tard que c'est le compte de Wally qu'il convient de
    créditer. À l'aide des points de retournement, cela peut-être réalisé
    ainsi&nbsp;:

<programlisting>BEGIN;
UPDATE comptes SET balance = balance - 100.00
    WHERE nom = 'Alice';
SAVEPOINT mon_pointdesauvegarde;
UPDATE comptes SET balance = balance + 100.00
    WHERE nom = 'Bob';
-- oups ... oublions ça et créditons le compte de Wally
ROLLBACK TO mon_pointdesauvegarde;
UPDATE comptes SET balance = balance + 100.00
    WHERE nom = 'Wally';
COMMIT;</programlisting>
   </para>

   <para>
    Cet exemple est bien sûr très simplifié mais de nombreux contrôles sont
    réalisables au sein d'un bloc de transaction grâce à l'utilisation des points de
    retournement. Qui plus est, <command>ROLLBACK TO</command> est le seul moyen
    de regagner le contrôle d'un bloc de transaction placé dans un état
    d'annulation par le système du fait d'une erreur. C'est plus rapide que
    de tout annuler pour tout recommencer.
   </para>
  </sect1>


  <sect1 id="tutorial-inheritance">
   <title>Héritage</title>

   <indexterm zone="tutorial-inheritance">
    <primary>héritage</primary>
    <secondary>inheritance</secondary>
   </indexterm>

   <para>
    L'héritage est un concept issu des bases de données orientées objet.
    Il ouvre de nouvelles possibilités intéressantes en conception de
    bases de données.
   </para>

   <para>
    Soient deux tables&nbsp;: une table <classname>villes</classname> et une
    table <classname>capitales</classname>. Les capitales étant également
    des villes, il est intéressant d'avoir la possibilité d'afficher
    implicitement les capitales lorsque les villes sont listées. Un
    utilisateur particulièrement brillant peut écrire ceci&nbsp;

<programlisting>CREATE TABLE capitales (
  nom        text,
  population real,
  altitude   int,    -- (en pied)
  etat       char(2)
);

CREATE TABLE non_capitales (
  nom        text,
  population real,
  altitude   int     -- (en pied)
);

CREATE VIEW villes AS
  SELECT nom, population, altitude FROM capitales
    UNION
  SELECT nom, population, altitude FROM non_capitales;</programlisting>

    Cela fonctionne bien pour les requêtes, mais la mise à jour d'une même
    donnée sur plusieurs lignes devient vite un horrible casse-tête.
   </para>

   <para>
    Une meilleure solution peut-être&nbsp;:

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

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

   <para>
    Dans ce cas, une ligne de <classname>capitales</classname>
    <firstterm>hérite</firstterm> de toutes les colonnes (<structfield>nom</structfield>,
    <structfield>population</structfield> et <structfield>altitude</structfield>) de son
    <firstterm>parent</firstterm>, <classname>villes</classname>. Le type de la
    colonne <structfield>nom</structfield> est <type>text</type>, un type natif
    de <productname>PostgreSQL</productname> pour les chaînes de caractères à
    longueur variable. Les capitales d'état ont une colonne supplémentaire,
    <structfield>etat</structfield>, qui affiche l'état dont elles sont la
    capitale. Sous <productname>PostgreSQL</productname>,
    une table peut hériter de zéro à plusieurs autres tables.
   </para>

   <para>
    La requête qui suit fournit un exemple de récupération des noms de
    toutes les villes, en incluant les capitales des états, situées à une
    altitude de plus de 500 pieds&nbsp;:

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

    ce qui renvoie&nbsp;:

<screen>   nom     | altitude
-----------+----------
 Las Vegas |     2174
 Mariposa  |     1953
 Madison   |      845
(3 rows)</screen>
   </para>

   <para>
    À l'inverse, la requête qui suit récupère toutes les villes qui ne sont pas des
    capitales et qui sont situées à une altitude d'au moins 500 pieds&nbsp;:

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

<screen>   nom     | altitude
-----------+----------
 Las Vegas |     2174
 Mariposa  |     1953
(2 rows)</screen>
   </para>

   <para>
    Ici, <literal>ONLY</literal> avant <literal>villes</literal>
    indique que la requête ne doit être exécutée que sur la table
    <classname>villes</classname>, et non pas sur les tables en dessous de
    <classname>villes</classname> dans la hiérarchie des héritages. La plupart
    des commandes déjà évoquées &mdash;
    <command>SELECT</command>, <command>UPDATE</command> et
    <command>DELETE</command> &mdash; supportent cette
    notation (<literal>ONLY</literal>).
   </para>

   <note>
    <para>
     Bien que l'héritage soit fréquemment utile, il n'a pas été intégré avec
     les contraintes d'unicité et les clés étrangères, ce qui limite son utilité.
     Voir la <xref linkend="ddl-inherit"/> pour plus de détails.
    </para>
   </note>
  </sect1>


  <sect1 id="tutorial-conclusion">
   <title>Conclusion</title>
 
   <para>
    <productname>PostgreSQL</productname> dispose d'autres fonctionnalités
    non décrites dans ce tutoriel d'introduction orienté vers
    les nouveaux utilisateurs de <acronym>SQL</acronym>. Ces fonctionnalités
    sont discutées plus en détails dans le reste de ce livre.
   </para>

   <para>
    Si une introduction plus approfondie est nécessaire, le lecteur peut
    visiter le <ulink url="http://www.postgresql.org">site web</ulink>
    de PostgreSQL qui fournit des liens vers d'autres ressources.
   </para>
  </sect1>
 </chapter>