Difference between revisions of "FR/Documentation/HSQLDB Guide/ch01"

From Apache OpenOffice Wiki
Jump to: navigation, search
m (Exécution des outils (Running Tools))
(Note)
Line 79: Line 79:
 
Pendant l'exécution de la base de données "test", le fichier <tt>test.log</tt> est utilisé pour écrire les changements faits aux données. Ce fichier est supprimé après une fermeture normale (voir SHUTDOWN). Autrement (après une fermeture anormale), ce fichier est relu au démarrage suivant pour rétablir les changements. Un fichier <tt>test.lck </tt>est également utilisé pour enregistrer le fait que la base de données est ouverte. Il est effaçé après une fermeture normale. Dans certaines circonstances, un fichier <tt>test.data.old</tt> est créé et supprimé par la suite.
 
Pendant l'exécution de la base de données "test", le fichier <tt>test.log</tt> est utilisé pour écrire les changements faits aux données. Ce fichier est supprimé après une fermeture normale (voir SHUTDOWN). Autrement (après une fermeture anormale), ce fichier est relu au démarrage suivant pour rétablir les changements. Un fichier <tt>test.lck </tt>est également utilisé pour enregistrer le fait que la base de données est ouverte. Il est effaçé après une fermeture normale. Dans certaines circonstances, un fichier <tt>test.data.old</tt> est créé et supprimé par la suite.
  
=== Note ===
+
'''Note'''
 
Lorsque le moteur ferme la base de données, il créé des fichiers temporaires avec l'extension <tt>.new</tt>, qu'il renomme ensuite en une de celles listées ci-dessus.
 
Lorsque le moteur ferme la base de données, il créé des fichiers temporaires avec l'extension <tt>.new</tt>, qu'il renomme ensuite en une de celles listées ci-dessus.
  

Revision as of 13:02, 18 March 2009

Chapitre 1. Installer et utiliser Hsqldb

Fred Toussi HSQLDB Development Group

<ft@cluedup.com>

Copyright 2002-2005 Fred Toussi. Permission is granted to distribute this document without any alteration under the terms of the HSQLDB license. Additional permission is granted to the HSQLDB Development Group to distribute this document with or without alterations under the terms of the HSQLDB license.

$Date: 2007/05/30 18:34:46 $

Contents

Introduction
Running Tools
Running Hsqldb
Server Modes
Hsqldb Server
Hsqldb Web Server
Hsqldb Servlet
In-Process (Standalone) Mode
Memory-Only Databases
General
Closing the Database
Using Multiple Databases in One JVM
Creating a New Database
Using the Database Engine
Different Types of Tables
Constraints and Indexes
SQL Support
JDBC Support

Introduction

Le paquet HSQLDB jar est stocké dans le dossier /lib et contient plusieurs composants et programmes. Pour chaque programme, différentes commandes sont disponibles.

Composants du paquet Hsqldb jar

  • HSQLDB RDBMS
  • Pilote HSQLDB JDBC
  • Gestionnaire de bases de données (Database Manager) (versions Swing et AW)
  • Outil de requêtes (Query Tool) (AWT)
  • Sql Tool (ligne de commande)

Les composants HSQLDB RDBMS et Pilote JDBC fournissent les fonctionnalités de base. Les autres sont des outils de base de données généraux pouvant être utilisés avec n'importe quel moteur de base de données ayant un pilote JDBC.

Exécution des outils

(Running Tools)

Tous les outils peuvent être exécutés de façon standard pour les classes Java archivées. Dans l'exemple suivant la version AWT du gestionnaire de base de données, le fichier hsqldb.jar est dans le dossier ../lib relatif au dossier courant.

    java -cp ../lib/hsqldb.jar org.hsqldb.util.DatabaseManager

Si le fichier hsqldb.jar était dans le dossier courant, la commande changerait en:

    java -cp hsqldb.jar org.hsqldb.util.DatabaseManager

Classes principales pour les outils Hsqldb

  • org.hsqldb.util.DatabaseManager
  • org.hsqldb.util.DatabaseManagerSwing
  • org.hsqldb.util.Transfer
  • org.hsqldb.util.QueryTool
  • org.hsqldb.util.SqlTool

Certains outils, comme le gestionnaire de base de données ou SQL Tool, peuvent utiliser des arguments en ligne de commande ou entièrement dépendre d'elles. Vous pouvez ajouter l'argument -? à  la ligne de commande pour obtenir une liste de tous les arguments disponibles pour ces outils. Parmi les fonctionnalités du gestionnaire de base de données figure une interface utilisateur graphique pour explorer celle-ci de façon interactive.

Exécution de Hsqldb

HSQLDB peut-être exécuté de différentes façons. Ces dernières sont en général réparties entre les modes serveurs et les modes "In-Process" (aussi appelés modes "Standalone"). Le fichier jar utilise un sous programme différent pour exécuter HSQLDB dans chacun des modes.

Chaque base de données HSQLDB est constituées de 2 à  5 fichiers, tous nommés à  l'identique mais avec des extensions différentes, et situés dans le même dossier. Par exemple, la base nommée "test" est constituée des fichiers suivants:

  • test.properties
  • test.script
  • test.log
  • test.data
  • test.backup

Le fichier des propriétés contient des réglages généraux de la base de données. Le fichier script contient la définition des tables et d'autres objets de la base de données, plus les données pour les tables non en cache. (non-cached tables) Le fichier log contient les changements récents de la base de données. Le fichier data contient les données pour les tables en cache et le fichier backup est un backup compressé (zip) du dernier état stable (consistent state) du fichier data. Tous ces fichiers sont essentiels et ne doivent jamais être enlevés. Si la base de données n'a pas de tables en cache, les fichiers test.data et test.backup ne seront pas présents. En plus de ces fichiers, une base de données HSQLDB peut être relié à  tout fichier texte formaté, telles des listes CSV, (CSV = Comma Separated Value = Données séparées par une virgule) n'importe ou sur le disque.

Pendant l'exécution de la base de données "test", le fichier test.log est utilisé pour écrire les changements faits aux données. Ce fichier est supprimé après une fermeture normale (voir SHUTDOWN). Autrement (après une fermeture anormale), ce fichier est relu au démarrage suivant pour rétablir les changements. Un fichier test.lck est également utilisé pour enregistrer le fait que la base de données est ouverte. Il est effaçé après une fermeture normale. Dans certaines circonstances, un fichier test.data.old est créé et supprimé par la suite.

Note Lorsque le moteur ferme la base de données, il créé des fichiers temporaires avec l'extension .new, qu'il renomme ensuite en une de celles listées ci-dessus.

Modes de serveur

Les modes de serveur fournissent une accessibilité maximale. Le moteur de la base de données s'exécute dans une JVM (Machine Virtuelle Java) et écoute les connexions de programmes sur le même ordinateur, ou d'autres sur le réseau. Plusieurs programmes différents peuvent se connecter au serveur et récupérer ou mettre à  jour l'information. Les programmes clients (Applications programs (clients)) se connectent au serveur en utilisant le pilote HSQLDB JDBC. Dans la plupart des modes de serveur, le serveur peut traiter jusqu'à  dix base de données simultanément. (the server can serve up to 10 databases that are specified at the time of running the server.)

Les modes de serveur peuvent utiliser des présélections de propriétés ou des arguments en ligne de commande, comme détaillé dans le chapitre Considérations avancées. Il y a trois modes de serveur, basés sur les protocoles de communication Client / Serveur.

Serveur Hsqldb

C'est la méthode préférée pour exécuter un serveur de bases de données. C'est également la plus rapide. Un protocole de communication propriétaire est utilisé dans ce mode. Une commande similaire à  celles utilisées pour exécuter les outils (ou Running Tools ?) et décrite plus haut est utilisée pour lancer le serveur. L'exemple suivant de la commande pour lancer le serveur le démarre avec une base de données (par défaut) constituée de fichiers nommés « mydb.* Â».

    java -cp ../lib/hsqldb.jar org.hsqldb.Server -database.0 file:mydb -dbname.0 xdb

L'argument de ligne de commande -? fournit une liste des arguments disponibles.

Serveur Web Hsqldb

Ce mode est utilisé quand l'accès à  l'ordinateur hébergeant le serveur de bases de données est restreint au protocole HTTP. L'unique raison pour utiliser le mode Serveur Web tient dans les restrictions imposées par les « firewalls Â» sur des machines client ou serveur. Il ne devrait pas être utilisé quand il n'y a pas de telles restrictions. Le Serveur Web HSQLDB est un serveur web particulier qui permet aux clients JDBC de se connecter via HTTP. Depuis la version 1.7.2 ce mode supporte également les transactions.

Pour exécuter un serveur web, dans la ligne de commande ci-dessus, remplacez la classe principale pour le serveur par la suivante :

    org.hsqldb.WebServer

L'argument de ligne de commande -? fournit une liste des arguments disponibles.

Servlet Hsqldb

Voir sur Wikipédia : http://fr.wikipedia.org/wiki/Servlet 

Ce dernier mode utilise le même protocole que le mode Serveur Web. Il est utilisé quand une servlet d'un moteur séparé (ou du serveur de l'application) comme par exemple Tomcat ou Resin fournit un accès à  la base de données. Le mode Servlet ne peut être démarré indépendamment de l'application servlet. La classe Servlet, dans le fichier HSQLDB.jar, doit être installé sur l'application du serveur pour fournir la connexion. La base de données est spécifiée par le biais d'une propriété de l'application coté serveur. Voir le fichier source org.hsqldb.Servlet.java pour plus de détails.

On ne peut accéder aux deux modes Serveur Web et Servlet qu'en utilisant le pilote JDBC càŽté client. Ils ne fournissent pas un frontal Web à  la base de données. Le mode Servlet ne peut servir qu'une base de données.

Veuillez noter que vous ne pouvez pas normalement vous servir de ce mode si vous utilisez un moteur de base de données dans un serveur d'applications.

Se connecter à  une base de données exécutée comme un serveur.

Un fois qu'un serveur HSQLDB est actif, les programmes clients peuvent s'y connecter en utilisant le pilote GSQLDB JDBC contenu dans hsqldb.jar. L'information complète de « comment se connecter à  un serveur Â» est fournie dans la documentation Java jdbcConnection[1](située dans le dossier /doc/src de la distribution HSQLDB. Un exemple courant est la connexion au port par défaut (9001) utilisé par le protocole hsql sur une machine en local (the same machine).

Exemple 1.1. Code Java pour se connecter au serveur local ci-dessus mentionné

    try {
        Class.forName("org.hsqldb.jdbcDriver" );
    } catch (Exception e) {
        System.out.println("ERROR: failed to load HSQLDB JDBC driver.");
        e.printStackTrace();
        return;
    }
    Connection c = DriverManager.getConnection("jdbc:hsqldb:hsql://localhost/xdb", "sa", "");

Dans certaines circonstances, vous devrez utiliser la ligne suivante pour vous connecter au pilote :

    Class.forName("org.hsqldb.jdbcDriver").newInstance();

A noter que dans l'URL de la connexion ci-dessus, il n'est pas fait mention du fichier de la base de données, comme c'était le cas pour démarrer le serveur. Au lieu de cela on utilise la valeur définie pour dbname.0. Aussi veuillez vous référer au chapitre Considérations avancées pour l'URL de la connexion quand il y a plus d'une base de données par instance de serveur.

Considérations de sécurité

Quand HSQLDB est exécuté comme serveur, l'accès réseau doit être protégé en conséquence. Les adresses IP sources doivent être restreintes par l'usage de filtrage TCP, de programmes Pare-Feu ou de pare-feus indépendents. Si le trafic doit passer à  travers un réseau non protégé (comme Internet), le flux doit être crypté (par exemple par VPN, ssh tunneling, ou TLS en utilisant les variantes SSL enabled HSQLS et HTTPS des modes Serveur et Serveur Web). Seuls les mots de passe sécurisés doivent être employés, et d'une façon plus importante, le mot de passe de l'utilisateur par défaut doit être changé depuis la chaà®ne vide par défaut. Si vous fournissez intentionnellement des données au public, la connexion réseau largement ouverte au public (wide-open public network connection) doit être utilisée exclusivement pour accéder aux données publiques par des comptes en lecture seule. (c.-à -d. Que ni les données sécurisées ni les compte privilégiés ne doivent utiliser cette connexion). Ces considérations s'appliquent aussi aux serveurs HSQLDB exécutés avec le protocole HTTP.

Mode « In-Process » (Stand-alone)

Ce mode exécute le moteur de base de données comme une partie de votre programme d'application dans la même Machine Virtuelle Java (JVM). Pour la plupart des applications ce mode est plus rapide, puisque les données ne sont pas converties et envoyées sur le réseau. L'inconvénient principal est qu'il n'est pas possible par défaut de se connecter à  la base de données en dehors de l'application. En conséquence vous ne pouvez vérifier le contenu de la base de données avec des outils externes comme un gestionnaire de base de données pendant que votre application « tourne Â». Depuis la version 1.8.0, vous pouvez lancer une instance de serveur dans un processus depuis la même machine virtuelle que votre application et ménager ainsi un accès externe à  votre base de données « In-Process Â».

La manière préconisée d'utiliser le mode In-Process dans une application est d'utiliser une instance de serveur HSQLDB pour la base de données tout en développant l'application, et ensuite basculer dans le mode In-Process pour le déploiement.

Une base de données dans le mode In-Process est exécutée depuis JDBC, avec le chemin du fichier de la base de données spécifié dans l'URL de connexion. Par exemple, si le nom de la base de données est testdb et que ses fichiers sont situés dans le même dossier que la commande délivrée pour lancer l'application, le code suivant sera utilisé pour la connexion :

    Connection c = DriverManager.getConnection("jdbc:hsqldb:file:testdb", "sa", "");

Le format du chemin de fichier de la base de données peut être spécifié en utilisant le caractère slash (/) indifféremment sous les plates-formes Windows ou Linux. Ainsi les chemins relatifs ou les chemins qui se réfèrent au même dossier sur le même disque peuvent être identiques. Par exemple si le chemin sous Linux de votre base de données est /opt/db/testdb et que vous créez une arborescence identique sur le disque C: d'une plate-forme Windows, vous pouvez utiliser la même URL pour les deux systèmes.

    Connection c = DriverManager.getConnection("jdbc:hsqldb:file:/opt/db/testdb", "sa", "");

Lors de l'utilisation des chemins relatifs, ces derniers seront pris en compte depuis l'emplacement o๠la commande shell de démarrage de la JVM aura été exécutée. Se référer à  la documentation javadoc avec jdbcConnection[2]pour plus de détails.

Bases de données en mémoire seule

Il est possible de lancer HSQLDB d'une manière ou la base de données n'est pas persistante et existe seulement dans la RAM (Random Access Memory ou mémoire vive). Comme aucune information n'est écrite sur le disque, ce mode ne devrait servir qu'aux calculs internes des données de l'application, dans des applets ou certaines applications spécialisées. Ce mode est spécifié par le protocole mem: .

    Connection c = DriverManager.getConnection("jdbc:hsqldb:mem:aname", "sa", "");

Vous pouvez également lancer une instance de serveur en mémoire seule en spécifiant la même URL dans server.properties. Cet usage est extraordinaire et limité à  des applications spécifiques ou le serveur de base de données est utilisé uniquement pour échanger des informations entre les clients, ou pour des données non-persistantes.

Généralités

Fermer la base de données

Toutes les bases de données exécutées dans les différents modes peuvent être fermées avec la commande SHUTDOWN, traitée comme une commande SQL. Depuis la version 1.7.2, les bases de données « In-Process Â» ne sont plus fermées quand la dernière connexion à  la base de donnée est explicitement fermée via JDBC, une commande SHUTDOWN est requise. Dans la 1.8.0, une propriété de connexion, shutdown=true, peut être spécifiée à  la première connexion à  la base de données (la connexion qui ouvre la base de données) pour forcer un shutdown quand la dernière connexion s'est fermée.

Quand une commande SHUTDOWN est transmise, toutes les transactions actives sont annulées (rolled back). Une méthode particulière de fermeture de la base de données est via la commande SHUTDOWN COMPACT. Cette commande ré-écrit le fichier .data qui qui contient l'information stockée dans les tables « CACHED Â» (mises en cache – voir Cache) et les compacte à  leur taille minimum. Cette commande devrait être transmise périodiquement,et plus spécialement quand beaucoup d'insertions, de mises à  jour ou de suppressions ont été réalisées sur les tables en cache. Les changements de structure de la base de données, comme supprimer ou modifier des tables en cache déjà  peuplées d'enregistrements, ou effectuer des opérations sur les index créent également de larges espaces inutilisés dans les fichiers qui peuvent être récupérés par l'utilisation de cette commande.

Utiliser de multiples bases de données dans une machine virtuelle Java

Dans les exemples ci-dessus chaque serveur fournit seulement une base de données et seulement une base de données en mémoire peut être créée. Toutefois, depuis la version 1.7.2, HSQLDB peut servir plusieurs bases de données dans plusieurs modes de serveur et permet les accès simultanés à  de multiples bases de données « in-process Â» et en mémoire seule. Ces possibilités sont décrites dans le chapitre Considérations avancées.

Créer une nouvelle base de données

Quand une instance de serveur est lancée, ou quand une connexion est faite à  une base de données « in-process Â», une nouvelle base de données vide est créée s'il n'existe pas de base de données au chemin donné.

Cette caractéristique a pour effet secondaire de troubler de nouveaux utilisateurs. S'il y a une erreur dans la spécification du chemin à  une base de données existante, une connexion est malgré tout établie à  une nouvelle base de données. A des fins de dépannage, vous pouvez spécifier la propriété de connexion ifexists=true pour permettre seulement la connexion à  une base de données existante et éviter d'en créer une nouvelle. Dans ce cas, si la base de données n'existe pas, la méthode getConnection() retournera une exception.

Utiliser le moteur de la base de données

Une fois la connexion établie à  une base de données et quel que soit le mode, on utilise les méthodes JDBC pour interagir avec la base de données. La documentation Java pour jdbcConnection[3], jdbcDriver[4], jdbcDatabaseMetadata[5], jdbcResultSet[6], jdbcStatement[7], et jdbcPreparedStatement[8]liste toutes les méthodes JDBC supportées ensemble et l'information spécifique à  HSQLDB. Les méthodes JDBC sont grossièrement réparties ainsi : Méthodes relatives à  la connexion, méthodes de métadonnées et méthodes d'accès à  la base de données. Ces dernières utilisent les commandes SQL pour agir sur la base de données et retournent les résultas soit comme un type primitif Java (? Java primitive type) ou comme une instance de la classe java.sql.ResultSet .

Vous pouvez utiliser un gestionnaire de base de données ou d'autre outils Java d'accès aux bases de données pour consulter votre base de données et la mettre à  jour par des commandes SQL. Ces programmes utilisent un pilote JDBC interne pour envoyer vos commandes au moteur de la base de données et afficher les résultats dans un format intelligible.

Essai - traduction incorrecte :Le langage SQL utilisé dans HSQLDB est aussi proche des standards SQL92 et SQL200n que ce qu'il a été possible d'atteindre aussi loin dans une légère empreinte de moteur de base de données.

Essai - archiifk :Le langage SQL utilsé par HSQLDB est le combiné des standarts SQL92 et SQL2000as it has been possible to achieve so far in a small-footprint database engine.

Phrase originale :(The SQL dialect used in HSQLDB is as close to the SQL92 and SQL200n standards as it has been possible to achieve so far in a small-footprint database engine.)Merci à  qui saura corriger et nettoyer ce paragraphe

La liste complète des commandes SQL est traitée au chapitre Syntaxe SQL.

Les différents types de tables

HSQLDB supporte les tables temporaires TEMP et trois types de tables persistantes.

Les tables TEMP ne sont écrites sur disque que pendant la durée de vie de l'objet Connexion. Le contenu de chaque table TEMP est visible uniquement depuis la connexion utilisée. Depuis la 1.8.0 la définition des tables TEMP est conforme au type GLOBAL TEMPORARY du standard SQL. La définition de la table persiste mais toutes les nouvelles connexions ne voient que leurs propres copies de cette table (qui est vide au départ). Lorsque la connexion est lancée, le contenu est nettoyé par défaut. Si les déclarations de définition de table incluent ON COMMIT PRESERVE ROWS, le contenu sera préservé lors de l'exécution d'un commit.

Les trois types de tables persistantes sont : MEMORY , CACHED et TEXT, appelés également ici "table mémoire", "table en cache" ou "table texte".

Le type par défaut de la commande CREATE TABLE génère des tables mémoire. Le contenu de ces dernières est entièrement en mémoire vive mais chaque changement à la structure ou aux données est immédiatement reflété dans le fichier <NomDeLaBase>.script . Le fichier de script est lu à l'ouverture de la base de données, et les tables mémoire sont recréées avec tout leur contenu. Contrairement aux tables temporaires, les tables mémoire (la valeur par défaut) sont persistantes.

Les tables en cache sont créées par la commande CREATE CACHED TABLE. Seule une partie des données ou des index réside en mémoire, permettant de grandes tables qui occuperaient autrement plusieurs centaines de méga-octets de mémoire. Un autre avantage des tables en cache est que le moteur de la base de données met moins de temps à démarrer dans le cas de grandes tables. Le désavantage des tables en cache est la réduction de vitesse. N'utilisez pas de tables en cache si l'ensemble de vos données est relativement petit. Dans une application constituée de grandes et de petites tables, il est plus efficient d'utiliser la valeur par défaut (le mode MEMORY) pour les petites tables.

Les tables texte sont prises en charge depuis la version 1.7.0 et utilisent le format CSV (Comma Separated Value = Valeurs séparées par une virgule) ou un autre fichier texte délimité comme source de données. Vous pouvez choisir un fichier CSV existant, tel un export d'une autre base de données ou d'un programme, comme source de la table texte. Vous pouvez également créer un fichier vide qui sera peuplé par le moteur de la base de données. Les tables texte sont performantes en termes d'usage de la mémoire puisqu'elles mettent en cache seulement une partie des données texte et tous les index. La source de données de la table texte peut toujours être réassignée à un autre fichier si nécessaire. Deux commandes sont requises pour installer une table texte, comme détaillé dans le chapitre Tables texte.

Avec les base de données en mémoire seule (voir plus haut), les deux déclarations de tables MEMORY et CACHED sont traitées comme des déclarations de tables mémoire non persistantes. Les déclarations de tables texte ne sont pas permises dans ce mode.

Contraintes et Index

HSQLDB prend en charge les contraintes PRIMARY KEY, NOT NULL, UNIQUE, CHECK et FOREIGN KEY. De plus, il supporte les index UNIQUE ou ordinaires.

HSQLDB supports PRIMARY KEY, NOT NULL, UNIQUE, CHECK and FOREIGN KEY constraints. In addition, it supports UNIQUE or ordinary indexes. This support is fairly comprehensive and covers multi-column constraints and indexes, plus cascading updates and deletes for foreign keys.

HSQLDB creates indexes internally to support PRIMARY KEY, UNIQUE and FOREIGN KEY constraints: a unique index is created for each PRIMARY KEY or UNIQUE constraint; an ordinary index is created for each FOREIGN KEY constraint. Because of this, you should not create duplicate user-defined indexes on the same column sets covered by these constraints. This would result in unnecessary memory and speed overheads. See the discussion in the SQL Issues chapter for more information.

Indexes are crucial for adequate query speed. When queries joining multiple tables are used, there must be an index on each joined column of each table. When range or equality conditions are used e.g. SELECT ... WHERE acol >10 AND bcol = 0, an indexe is required on the acol column used in the condition. Indexes have no effect on ORDER BY clauses or some LIKE conditions.

As a rule of thumb, HSQLDB is capable of internal processing of queries at over 100,000 rows per second. Any query that runs into several seconds should be checked and indexes should be added to the relevant columns of the tables if necessary.

SQL Support

The SQL syntax supported by HSQLDB is essentially that specified by the SQL Standard (92 and 200n). Not all the features of the Standard are supported and there are some proprietary extensions. In 1.8.0 the behaviour of the engine is far more compliant with the Standards than with older versions. The main changes are

  • correct treatment of NULL column values in joins, in UNIQUE constraints and in query conditions
  • correct processing of selects with JOIN and LEFT OUTER JOIN
  • correct processing of aggregate functions contained in expressions or containing expression arguments

The supported commands are listed in the SQL Syntax chapter. For a well written basic guide to SQL with examples you can consult PostgreSQL: Introduction and Concepts by Bruce Momjian, which is available on the web. Most of the SQL coverage in the book applies also to HSQLDB. There are some differences in keywords supported by one and not the other engine (OUTER, OID's, etc.) or used differently (IDENTITY/SERIAL, TRIGGER, SEQUENCE, etc.).

JDBC Support

Since 1.7.2, support for JDBC2 has been significantly extended and some features of JDBC3 are also supported. The relevant classes are thoroughly documented. See the JavaDoc for org.hsqldb.jdbcXXXX classes.

Personal tools