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

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

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

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

   <para>
    Dans le précédent chapitre, 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 discuter de
    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 base 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érencielle</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érencielle</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>ville</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 simple, 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 "$1"
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, une 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 fin
    réussie de la transaction, 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 officiels de la banque
    voudront être assurés que soit toutes les commandes sont effectuées
    soit aucune ne l'ait. 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 garantie 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 en faisant le
    total de toutes les branches, il ne serait pas bon d'inclure le débit de la
    branche d'Alice mais 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>
  </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. Beaucoup
    des commandes dont nous avons déjà discutées -- <command>SELECT</command>,
    <command>UPDATE</command> et <command>DELETE</command> -- supportent cette
    notation (<literal>ONLY</literal>).
   </para>
  </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:
-->