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

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

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

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

   <para>
    Dans le chapitre précédent, nous avons couvert les bases de l'utilisation
    de <acronym>SQL</acronym> pour stocker et accéder à vos données avec
    <productname>PostgreSQL</productname>. Nous allons maintenant aborder
    quelques fonctionnalités avancées de <acronym>SQL</acronym>
    simplifiant la gestion et empêchant la perte ou la corruption de vos
    données. Enfin, nous regarderons quelques extensions de
    <productname>PostgreSQL</productname>.
   </para>

   <para>
    Ce chapitre se référera occasionnellement aux exemples disponibles dans le
    <xref linkend="tutorial-sql"> pour les modifier ou les améliorer, donc il
    serait avantageux d'avoir lu ce chapitre. Quelques exemples de ce
    chapitre sont aussi disponibles dans <filename>advanced.sql</filename>
    placé dans le répertoire du tutoriel. Ce fichier contient aussi quelques
    données à charger pour l'exemple, ce qui ne sera pas répété ici.
    (Référez-vous à 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>
    Référez-vous aux requêtes de la <xref linkend="tutorial-join">.
    Supposons que la liste des enregistrements du temps et des villes soit d'un
    intérêt particulier pour votre application mais que vous ne voulez pas
    saisir la requête à chaque fois que vous en avez besoin. Vous pouvez créer
    une <firstterm>vue</firstterm> avec la requête, ce qui donne un nom à la
    requête à laquelle vous pouvez vous référer comme dans le cas d'une table
    ordinaire.

<programlisting>
CREATE VIEW mavue AS
    SELECT ville, temp_basse, temp_haute, prcp, date, emplacement
        FROM temps, villes
        WHERE ville = nom;

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

   <para>
    Avoir une utilisation libérale des vues est un aspect clé d'une bonne
    conception des bases de données avec SQL. Les vues vous permettent
    d'encapsuler les détails de la structure de vos tables, qui pourraient
    changer lors de l'évolution de votre application, tout en restant
    consistant au niveau de l'interface.
   </para>

   <para>
    Les vues peuvent être utilisées pratiquement partout où une vraie table est
    utilisable. Construire des vues basées sur d'autres vues n'est pas
    inhabituel.
   </para>
  </sect1>


  <sect1 id="tutorial-fk">
   <title>Clés secondaires</title>

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

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

   <para>
    Souvenez-vous des tables <classname>temps</classname> et
    <classname>villes</classname> du <xref linkend="tutorial-sql">.
    Considérez le problème suivant&nbsp;: vous voulez vous assurer que personne
    n'insère de lignes dans la table <classname>temps</classname> qui ne
    correspondraient pas à une entrée dans la table
    <classname>villes</classname>. Ceci maintient l'<firstterm>intégrité
    référentielle</firstterm> de vos données. Dans les systèmes de bases de
    données simples, ceci serait implémenté (si possible) en vérifiant en
    premier lieu que la table <classname>villes</classname> dispose bien d'un
    enregistrement correspondant, puis en insérant ou en empêchant l'insertion
    du nouvel enregistrement dans <classname>temps</classname>. Cette approche
    présente un certain nombre de problèmes et n'est pas très pratique, donc
    <productname>PostgreSQL</productname> peut s'en charger pour vous.
   </para>

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

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

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

    Maintenant, essayons d'insérer un 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)=(Berkeley) is not present in table "villes".
</screen>
   </para>

   <para>
    Le comportement des clés secondaires peut être précisé très finement pour
    votre application. Nous n'irons pas plus loin que cet exemple simple dans
    ce tutoriel mais référez-vous simplement au <xref linkend="ddl"> pour plus
    d'informations. Utiliser correctement les clés secondaires améliore la
    qualité de vos applications de bases de données, donc vous êtes fortement
    encouragé à les connaître.
   </para>
  </sect1>


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

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

   <para>
    Les <firstterm>transactions</> sont un concept fondamental de tous les
    systèmes de bases de données. Le point essentiel d'une transaction est
    qu'il assemble plusieurs étapes en une seule opération tout-ou-rien.
    Les états intermédiaires entre les étapes ne sont pas visibles pour les
    autres transactions concurrentes, et si un échec survient empêchant la
    transaction de bien se terminer, alors aucune des étapes n'affecte la base
    de données.
   </para>

   <para>
    Par exemple, considérez la base de données d'une banque qui contiendrait la
    balance pour différents comptes clients, ainsi que les balances du total du
    dépôt par branches. Supposez que nous voulons enregistrer un virement de
    100 euros du compte d'Alice vers celui de Bob. En simplifiant énormément,
    les commandes SQL pour ceci ressembleraient à ça

<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>
    Les détails de ces commandes ne sont pas importants ici&nbsp;; le point
    important est que cela nécessite plusieurs mises à jour séparées pour
    accomplir cette opération assez simple. Les employés de la banque
    voudront être assurés que soit toutes les commandes sont effectuées
    soit aucune ne l'est. Il ne serait pas acceptable 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 si
    elle est débitée du montant sans que celui-ci ne soit crédité sur le compte
    de Bob. Nous avons besoin d'une garantie comme quoi si quelque chose se
    passe mal, aucune des étapes déjà exécutées ne prendra effet. Grouper les
    mises à jour en une <firstterm>transaction</> nous donne cette garantie.
    Une transaction est dite <firstterm>atomique</>&nbsp;: du point de vue des autres
    transactions, cela se passe complètement ou pas du tout.
   </para>

   <para>
    Nous voulons aussi la garantie qu'une fois une transaction terminée et
    validée par le système de base de données, les modifications seront
    enregistrées de façon permanente et ne seront pas perdues même si un arrêt
    brutal arrive peu après. Par exemple, si nous enregistrons un retrait
    d'argent par Bob, nous ne voulons surtout pas que le débit de son compte
    disparaisse lors d'un crash à sa sortie de la banque. Une base de données
    transactionnelle garantit que toutes les mises à jour faites lors d'une
    transaction sont enregistrées dans un stockage permanent (c'est-à-dire sur
    disque) avant que la transaction ne soit 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
    de multiples transactions sont lancées en parallèle, chacune d'entre elles
    ne doit pas être capable de voir les modifications incomplètes faites
    par les autres. Par exemple, si une transaction est occupée à calculer le
    total de toutes les branches, il ne serait pas bon d'inclure le débit de la
    branche d'Alice sans le crédit de la branche de Bob, ou vice-versa.
    Donc, les transactions doivent être tout-ou-rien non seulement pour leur
    effet permanent sur la base de données, mais aussi pour leur visibilité
    au moment de leur exécution. Les mises à jour faites ainsi par une
    transaction ouverte sont invisibles aux autres transactions jusqu'à la fin
    de celle-ci, moment qui rendra visible toutes les mises à jours
    simultanément.
   </para>

   <para>
    Avec <productname>PostgreSQL</>, une transaction est réalisée en entourant
    les commandes SQL de la transaction avec les commandes <command>BEGIN</>
    et <command>COMMIT</>. Donc, notre transaction pour la banque ressemblera à
    ceci

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

   <para>
    Si, au cours de la transaction, nous décidons que nous ne voulons pas
    valider (peut-être nous sommes-nous aperçu que la balance d'Alice devenait
    négative), nous pouvons envoyer la commande <command>ROLLBACK</> au lieu de
    <command>COMMIT</>, et toutes nos mises à jour jusqu'à maintenant seront
    annulées.
   </para>

   <para>
    En fait, <productname>PostgreSQL</> traite chaque instruction SQL comme
    étant exécutée dans une transaction. Si vous ne lancez pas une commande
    <command>BEGIN</>, alors chaque instruction individuelle se trouve
    enveloppée avec un <command>BEGIN</> et (en cas de succès) un
    <command>COMMIT</> implicites.  Un groupe d'instructions entouré par un
    <command>BEGIN</> et un <command>COMMIT</> est quelque fois appelé un
    <firstterm>bloc transactionnel</>.
   </para>

   <note>
    <para>
     Quelques bibliothèques clients lancent les commandes <command>BEGIN</> et
     <command>COMMIT</> automatiquement, de façon à ce que vous bénéficiiez des
     effets des blocs transactionnels sans les demander. Vérifiez la
     documentation de l'interface que vous utilisez.
    </para>
   </note>
   
   <para>
    Il est possible de contrôler les instructions dans une transaction d'une
    façon plus granulaire avec l'utilisation des <firstterm>points de
    sauvegarde</>. Les points de sauvegarde vous permettent d'annuler des
    parties de la transaction tout en validant le reste. Après avoir défini un
    point de sauvegarde avec <command>SAVEPOINT</>, vous pouvez, si nécessaire,
    annuler jusqu'au point de sauvegarde avec <command>ROLLBACK TO</>. Toutes
    les modifications de la transaction dans la base de données entre le moment
    où le point de sauvegarde est défini et celui où l'annulation est demandée
    sont annulées mais les modifications antérieures au point de sauvegarde sont
    conservées.
   </para> 

   <para>
    Après avoir annulé jusqu'à un point de sauvegarde, il reste défini, donc
    vous pouvez de nouveau annuler plusieurs fois et rester au même point. Par
    contre, si vous êtes sûr de ne plus avoir besoin d'annuler jusqu'à un point
    de sauvegarde particulier, il peut être libéré pour que le système puisse
    récupérer quelques ressources. Gardez à l'esprit que libérer un point de
    sauvegarde ou annuler les opérations jusqu'à ce point de sauvegarde libérera
    tous les points de sauvegarde définis après lui.
   </para> 

   <para>
    Tout ceci survient à l'intérieur du bloc de transaction, donc ce n'est pas
    visible par les autres sessions de la base de données. Quand et si vous
    validez le bloc de transaction, les actions validées deviennent visibles en
    un seul coup aux autres sessions, alors que les actions annulées ne
    deviendront jamais visibles.
   </para> 

   <para>
    Rappelez-vous la base de données de la banque. Supposons que nous débitons
    le compte d'Alice de $100.00, somme que nous créditons au compte de Bob,
    pour trouver plus tard que nous aurions dû créditer le compte de Wally. Nous
    pouvons le faire en utilisant des points de sauvegarde comme ceci&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 il y a beaucoup de contrôle
    possible dans un bloc de transaction grâce à l'utilisation des points de
    sauvegarde. De plus, <command>ROLLBACK TO</> est le seul moyen pour regagner
    le contrôle d'un bloc de transaction qui a été placé dans un état
    d'annulation par le système à cause d'une erreur, plutôt que de tout annuler
    et de 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 provenant des bases de données orientées objet.
    Il ouvre de nouvelles possibilités intéressantes dans la conception de
    bases de données.
   </para>

   <para>
    Créons deux tables&nbsp;: une table <classname>villes</classname> et une
    table <classname>capitales</classname>. Naturellement, les capitales sont
    aussi des villes, donc vous voulez un moyen pour afficher implicitement les
    capitales lorsque vous listez les villes. Si vous êtes réellement
    intelligent, vous pourriez inventer 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>

    Ceci fonctionne bien pour les requêtes, mais c'est horrible lorsque vous
    avez besoin de mettre à jour plusieurs lignes par exemple.
   </para>

   <para>
    Voici une meilleure solution&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>population</> et <structfield>altitude</>) 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,
    etat, qui affiche leur état. Dans <productname>PostgreSQL</productname>,
    une table peut hériter d'aucune ou de plusieurs autres tables.
   </para>

   <para>
    Par exemple, la requête suivante trouve les 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>
    Autrement, la requête suivante trouve 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 lancée que sur la table
    <classname>villes</classname>, et non pas sur les tables sous
    <classname>villes</classname> suivant la hiérarchie des héritages. La plupart
    des commandes dont nous avons déjà discuté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 uniques ou les clés étrangères, ce qui limite leur utilité.
     Voir <xref linkend="ddl-inherit"> pour plus de détails.
    </para>
   </note>
  </sect1>


  <sect1 id="tutorial-conclusion">
   <title>Conclusion</title>
 
   <para>
    <productname>PostgreSQL</productname> a bien plus de fonctionnalités que
    celles aperçues lors de ce tutoriel d'introduction, qui a été orienté vers
    les nouveaux utilisateurs de <acronym>SQL</acronym>. Ces fonctionnalités
    sont discutées avec plus de détails dans le reste de ce livre.
   </para>

   <para>
    Si vous sentez que vous avez besoin d'une introduction plus approfondie,
    merci de visiter le <ulink url="http://www.postgresql.org">site web
    PostgreSQL</ulink> pour des liens vers d'autres ressources.
   </para>
  </sect1>
 </chapter>

<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"./reference.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:("/usr/lib/sgml/catalog")
sgml-local-ecat-files:nil
End:
-->