Le Petit Journal du Linuxien Novice
© 1999-2007 César Alexanian. Hébergé officiellement chez Linux-France. Serveur principal tournant sous GNU/Linux chez NFrance Conseil
À SUIVRE...
Aucun lien
STATS

[ Nedstat ]
Dernière mise à jour : vendredi 30 novembre 2007

Débuter avec Adabas sous StarOffice 5.2

Ce texte et les réalisations décrites ci-dessous ont été entièrement réalisés par le très prolifique Jean-Michel Oltra que je remercie de tout coeur ici. Tout le texte a été modélisé avec LyX (reposant sur LATEX) et la page html a été générée avec LATEX2html. Avant d'aller plus loin, voyez la fiche concernant l'installation d'Adabas.

Sommaire

Sommaire

1 Quelques généralités

Adabas est un serveur de bases de données relationnelles (que l'on appellera BD, pour bases de données).

Une BD relationnelle est créée pour archiver et analyser des données, au moyen de requêtes. Ces données, enregistrées dans des tables, peuvent être reliées entre elles grâce aux clés qui sont définies lors de la construction des tables de la BD. Le principe même de la création d'une bonne BD relationnelle est la segmentation des enregistrements puisque ceux-ci sont reliables. Ainsi, en évitant la multiplication d'enregistrements semblables, on gagne du temps à la saisie et de l'espace disque pour le stockage de l'information.

Exemple : si, lors de la saisie d'une livraison, je dois enregistrer les coordonnées complètes de mon client, je ne suis pas sorti de l'auberge ! C'est pourquoi les coordonnées de mes clients sont enregistrées dans une table distincte (la table "coordonnées") qui peut être reliée à d'autres tables par l'intermédiaire d'un code (code client à 4 chiffres, rapide à saisir).

Dans le jargon des BD, les tables, formulaires, requêtes, états, macros sont appelés des objets.

L'aide en ligne d'Adabas sous StarOffice est plutôt bien faite : s'en priver serait donc dommage.

L'architecture d'une BD est essentielle pour une saisie optimale ainsi que pour la réalisation de requêtes pertinentes ; avant de créer sa BD, il convient donc de savoir précisément à quoi elle va servir. Personnellement je crée d'abord ma BD sur le papier avec les noms des tables, leurs champs en colonnes, ainsi que les relations entre les différentes tables symbolisées par des traits comme le font Access ou StarOffice dans les fenêtres de relations.

2 Les tables

2.1 À quoi ça sert ?

Les tables sont les piliers de la BD. Elles sont constituées de champs de données (les champs). Chaque enregistrement de la table renseigne une valeur par champ. Si il n'y a pas de valeur renseignée dans le champ, alors le champ est nul (EST NULL ou IS NULL) : dans ce cas-là, il n'y a pas de valeur car on ne la connaît pas, mais elle pourrait exister. Si le champ ne possède pas de valeur, on peut le renseigner par une chaîne vide (" "). Dans ce cas-là, la valeur n'existe pas.

Graphiquement, une table sera donc un tableau : un enregistrement par ligne, chaque colonne étant un champ.

On peut mettre n'importe quoi dans une table ! C'est pourquoi les champs ont des formats différents en fonction des valeurs que l'on veut y renseigner : des formats de nombre (un nombre est sujet à des opérations, un numéro de téléphone peut être renseigné dans un champ de texte), de texte, de date/heure, format oui/non sous StarOffice (champ booléen). La taille que l'on déterminera pour les champs aura une influence sur l'affichage des données ainsi que sur l'espace de stockage requis pour celles-ci.

2.2 L'ébauche de table

Attention : Adabas ne permet pas de modifier l'ordre des colonnes, il faut donc bien y réfléchir avant d'enregistrer sa table (par exemple il est plus malin de mettre un champ "code_postal" avant un champ "ville"). De plus, Adabas demande une clé primaire ou un champ indexé de manière unique pour permettre l'enregistrement de données ; ce qui signifie que vous devez posséder un champ univoque au moins dans une table. Si il n'existe pas, créez un champ d'identification des enregistrements (je les appelle "id", nombre entier, autovaleur, c'est à dire qu'il s'incrémente tout seul comme un grand...).

Voici un exemple de table tout bête :

clé nom du champ type de champ observations
  societe texte Adabas n'accepte pas les é
  adresse texte  
  code_postal texte fixe je préfère qu'il n'y ait pas d'espace dans le nom
  ville texte  
  telephone texte fixe  
  telecopie texte fixe  
  contact texte  
primaire code texte  

Pour créer une table sous Starbase : clic droit sur "tables" après avoir développé l'arborescence de la BD. Sélectionner "nouveau" puis "ébauche de table". Indiquer les noms de champs, leur type, et, dans la fenêtre inférieure, leurs caractéristiques propres : saisie obligatoire ou non, longueur du champ, donc de la donnée (par exemple pour des numéros de téléphone nationaux, j'ai choisi une longueur de 10), autovaleur ou non, valeur par défaut si l'une d'entre elle revient souvent (ça peut être oui ou non dans un champ oui/non), format (ce qui est parfois un peu plus complexe à définir, mais quand c'est fait au niveau de la table on n'a pas à y revenir). On passe de la fenêtre haute à la basse par deux fois [F6], inversement par [F6].

Les champs oui/non : ce type de champ me paraît poser un problème (mais je n'ai peut-être pas tout compris). Lors d'une requête, je n'ai réussi à différencier que le "indéterminé" (coche grisée dans la table ou le formulaire) relativement au "oui/non" (tous deux confondus, le "oui" étant symbolisé par une coche noire). Dans l'état actuel de mes connaissances, je préconise donc l'option "saisie"=non, en affectant le "non" à l'option "indéterminé". Je préciserai tout ça lors de mon exposé sur les formulaires.

Les champs texte (fixe) : ce type de champ permet la mise en place d'un compteur qui s'incrémente tout seul si on choisit l'option "autovaleur" dans les propriétés du champ. Je conseille de déterminer une taille de champ élevée (15) car je pense avoir eu des soucis d'enregistrements dus à une valeur faible (5). Ce qui permet de définir une clé primaire pour qu'Adabas soit satisfait... même si on n'en a pas l'utilité...

Les champs décimal : la longueur de ce type de champ se détermine en additionnant le nombre de zéros non significatifs, la virgule qui compte pour un et le nombre de décimales. Par exemple, un champ de longueur 8 peut représenter un format 0000,000.

Adabas semble garder une mémoire des champs inscrits dans l'ébauche. Ainsi, si on modifie un type de "texte" à "nombre" on aura un message d'erreur à l'enregistrement de la table. Dans ce cas je préconise d'effacer la table et de recommencer...

Quand la saisie de la table est achevée, on la ferme ou on l'enregistre (icône), ce qui ouvrira la boîte de dialogue de saisie du nom.

2.3 Les clés

Un champ auquel on associe une clé primaire doit être un champ qui identifiera de manière univoque un enregistrement. Mais ce champ permettra également de lier deux tables ; la table liée possédera alors un champ identique, qui ne sera pas univoque, et que l'on appellera clé externe. Il est très important de définir les clés primaires avant les clés externes, sinon, il ne sera pas possible d'établir la relation entre les tables.

Exemple : prenons la table "livraisons" suivante.

clé nom du champ type de champ observations
primaire n_livraison nombre,integer  
  facture texte  
  lot texte  
  code_client texte c'est l'homologue du champ "code" de ma table précédente "coordonnées".
  date_livraison date  

Bien évidemment, je fais sur une année plusieurs livraisons au même client. Le contraire serait mauvais pour mon chiffre d'affaire ! Le champ "code_client" sera utilisé comme clé externe de ma clé primaire "code" dans ma table "coordonnées". Ainsi on voit qu'une clé externe ne possède pas forcément le même nom que la clé primaire ; mais les types de champs doivent être identiques, ainsi que les enregistrements que l'on y a fait. Identiques signifie également qu'à un champ de type "nombre,Integer" ne pourra pas correspondre un champ de type "nombre,Smallint". A chaque enregistrement dans la table "coordonnées" pourra correspondre plusieurs enregistrements dans la table "livraisons" par l'intermédiaire de la relation entre les deux tables.

2.4 Les relations

Il est très facile d'établir les relations entre les tables. Clic droit sur le volet "tables" (appelé conteneur de tables dans la documentation StarOffice) choisir "relations".

Un clic sur le bouton situé en haut à gauche de cette fenêtre ouvre une boîte de dialogue qui permet de faire glisser des tables dans cette fenêtre (clic sur le nom de la table puis ajouter ou double clic sur ce nom). Ensuite par "glissé-déposé" : clic gauche maintenu sur le champ de clé primaire vers le champ de clé externe. Les types de champs doivent être identiques.

Autre moyen, plus complet : utiliser le bouton "nouvelle relation", à côté du bouton précédent. La boîte qui s'ouvre permet de naviguer entre les tables (tables impliquées) puis entre les champs, ce qui définira une relation entre deux tables de manière identique. On peut cependant mieux définir par ce biais les propriétés de la relation, par les options proposées. Si vous n'avez aucune référence (c'est le cas de le dire puisque "référence" est le terme SQL), il est impératif que vous consultiez la doc avant de modifier les options par défaut.

3 Les formulaires

L'expérience de mes déboires avec Adabas me montre qu'avant d'attaquer la réalisation d'un formulaire il est pertinent de tenter d'enregistrer des données directement dans la table. Ce qui donne moins de travail si quelque chose ne va pas.

3.1 Créer un formulaire en document texte

Utiliser le menu contextuel du conteneur de formulaires, rubrique "nouveau" puis "formulaire" puis "Document texte". S'affiche une page blanche que l'on peut agrémenter grâce au menu général "Format" puis "page".

3.2 Disposer ses contrôles et ses étiquettes

Quand on a fait quelque chose de joli, il est temps de disposer dans son formulaire les éléments qui permettront de le remplir.

3.2.1 La barre d'outils flottante

On l'affiche par le bouton "Formulaire" (5e en partant du haut sur la barre d'outil fixe du cadre gauche). Les étiquettes et autres champs se fabriquent en cliquant sur le bouton adéquat puis en dessinant avec la souris la forme du champ dans le formulaire.

3.2.2 Les étiquettes

Les étiquettes sont des légendes relatives aux champs de saisie des données. On les crée avec le bouton "An" de la barre. Personnellement je les fabrique toutes d'un coup, en m'aidant du vernier en bas à droite pour les dimensions. Peu importe leur position. La première étiquette est ancrée "au caractère", on modifie l'ancrage avec son menu contextuel pour pouvoir la déplacer.

Je les positionne à peu près et je mets en face les champs de données. Le menu des propriétés (en bas à gauche de la barre, après un clic sur l'étiquette) permet de donner un nom à celle-ci, par exemple "code postal", et de lui attribuer une couleur, un jeu de caractère... pour le graphisme du formulaire.

On peut sélectionner des blocs d'étiquettes en cliquant sur la première, puis sur les suivantes en gardant la touche [Maj] (shift) enfoncée. Ce qui peut s'utiliser pour aligner plusieurs étiquettes à la fois (par le menu contextuel) et pour attribuer les même propriétés à un groupe avec la fenêtre des propriétés. En affichant cette fenêtre pour une étiquette sélectionnée, des clics successifs sur les étiquettes suivantes permettront les saisies successives de propriétés sans réafficher la fenêtre (utile pour saisir les noms les uns à la suite des autres).

3.2.3 Les propriétés du formulaire

On y accède par le bouton "Propriétés du formulaire", 2e à gauche en bas de la barre, après avoir dessiné au moins un champ. Il est important de renseigner dans l'onglet "données" les champs "Base de données" et, en déroulant la zone de liste, "source de données". Sélectionner le nom de la table sur laquelle est basée le formulaire. En déroulant cette liste on voit qu'il est possible de bâtir un formulaire à partir d'une requête où d'une requête SQL. Dans le cas du choix "Commande SQL", il faudra taper la commande dans le champ "source de données" (SELECT "champ1","champ2" FROM "nom-de-table").Quand les deux points précédents ont été renseignés, il est possible de commencer à positionner ses champs de contrôle.

3.2.4 Champs de texte

On y accède par le bouton "abl" de la barre. En activant les "Propriétés du champ de contrôle", bouton qui se situe en bas à gauche toute, on va pouvoir définir, dans l'onglet "Données", le champ auquel se rattache ce champ de formulaire (à condition que le formulaire ait été rattaché à une table comme vu précédemment).

Dans l'onglet "Général" de cette fenêtre, il y a quelques points qu'il peut être utile de renseigner pour améliorer la saisie :

  • Tabstop et Ordre permettent de déterminer s'il y aura arrêt de tabulation (à l'utilisation de la touche [TAB]) et, si oui, dans quel ordre au sein du formulaire.
  • Jeu de caractères et Couleur d'arrière plan pour mieux visualiser l'enregistrement
  • Saisie à plusieurs lignes : utile pour des saisies plus claires, d'adresses par exemple. On passera d'une ligne à l'autre avec la touche [Entrée].

3.2.5 Autres champs

  1. Les champs "nombre" dans la table doivent être formatés en "Champs numériques" dans le formulaire. On peut régler les décimales et la vérification de format dans l'onglet "Général". Les réglages effectués dans les Propriétés du champ de contrôle affectent l'affichage dans le formulaire. En revanche, c'est le formatage au niveau de l'ébauche de table qui va déterminer l'affichage dans la table.
  2. Les champs "décimal" peuvent également se formater en "numérique". Les mêmes remarques que précédemment prévalent. C'est une virgule, et non pas le point, qui sépare la partie entière de la partie décimale (notation française).
  3. Les champs monétaires se formatent en... "monétaires". Utilisez la virgule comme indiqué précédemment, sinon ça fait des choses bizarres...
  4. il existe des champs de date et des champs horaires. Dans un champ de date, l'activation du "compteur" et/ou de la "déroulante" peut être intéressant pour des saisies régulières.

3.2.6 Champs de sélection

Les cases à cocher
sont activées par le bouton prévu à cet effet. Elles possèdent leur propre étiquette (champ "titre" de l'onglet "général"). On peut leur attribuer une étiquette distincte en les dessinant en tant que zone de texte, attribuant alors une étiquette à la zone, puis en les transformant, par le biais du menu contextuel "remplacer par", en case à cocher. Personnellement, je leur donne l'attribut "statut triple". Lors d'une requête, je relève les "indéterminés" avec le critère "est vide" (is null), les champs activés (coche noire) et inactivés (pas de coche) sont relevés avec "est pas vide" (is not null).
Les boutons radio
permettent d'effectuer une sélection exclusive au sein d'une zone de groupe.
Exemple :
On peut créer une zone de groupe que l'on appellera "paiement" dans le champ "titre", onglet "général" des propriétés de la zone de groupe. Au sein de cette zone, il est possible de dessiner deux boutons radio, l'un appelé "espèces", l'autre chèque". Ces boutons se référeront, dans l'onglet "données" de leur propriétés, à un champ de texte que l'on aura nommé "reglement" (pas de 'è', Adabas n'aime pas...). On saisira dans le champ "valeur référentielle" du premier "espèces", et "chèque" dans celui du second. Lors de la saisie en mode données dans le formulaire, il ne sera pas possible de cocher les deux boutons à la fois, ce qui est compréhensible. Lors de la requête, on pourra sélectionner les enregistrements comportant un paiement par chèque en saisissant "chèque" en tant que critère.
Les zones de liste
peuvent récupérer les données à partir de tables, requêtes ou listes de valeurs tapées directement dans les propriétés. On dessine sa zone de liste directement dans le formulaire après un clic sur le bouton "Zone de liste". C'est ensuite dans les propriétés de la zone que tout se passe.

Étudions le cas d'une table intitulée "détails_livraisons". Dans le cadre d'une vente (de fromages puisque je suis producteur de fromages de chèvre bio), je vais livrer différents type de produits sur la même livraison. Ma table "détails_livraisons" comportera les champs "n_livraison", "produit", "quantité", "prix", "n_lot". Le champ "n_livraison" est une clé externe de ma table "livraisons" précédente. Je vais créer une table "produits" avec les champs suivants : "produit" (clé primaire), "uv", "conditionnement". Pour ne pas me fatiguer à la saisie des livraisons, je vais associer une zone de liste dans mon formulaire "détails_livraisons".

Sous l'onglet "général", sélectionner oui pour "déroulante". Sous l'onglet "données", sélectionner le nom du champ associé, en l'occurence "produit". Le "type du contenu de liste" est "table" et je sélectionne le nom de ma table associée (produits) dans "contenu de liste". Le "champ lié" est le numéro 0. Il correspond au premier champ de ma table "produits" (le second sera le numéro 1 et ainsi de suite). C'est l'équivalent de row[0] en php avec MySQL. Et le tour est joué. Je sélectionnerai à la saisie le nom du produit vendu, car ceux-ci s'afficheront dans la zone de liste.

J'aurai pu avoir le même résultat en sélectionnant 0 pour "champ lié", puis "liste de valeurs" pour "type du contenu de liste". Il aurait fallu alors inscrire le nom de mes produits sous l'onglet "général" champ "entrées de liste", en tapant les entrées les unes sous les autres, le changement de ligne se faisant par les touches [Maj]-[Entrée].

Plus vicieux, si j'entre de la même manière que précedemment des valeurs sous l'onglet "données" dans le champ "contenu de liste" (tout en conservant mes entrées précédentes) ce sont ces dernières qui seront inscrites dans la table alors que les entrées dans la zone de liste ne seront pas modifiées.

D'une autre manière, le "type du contenu de liste" peut-être une requête dont on choisira le nom dans le "contenu de liste". Ça fonctionne ensuite de la même manière qu'avec une table.

Les zones combinées
sont plus délicates. Il me semble que le "type du contenu de liste" ne puisse être que du SQL, l'instruction elle même étant écrite dans "Contenu de liste". Adabas demande des instructions de la forme select "champ1" from "ma_table" : guillemets doubles impératifs encadrant les noms, des virgules séparant les champs et les tables. S'il y a une clause WHERE, la définition de la clause est entre guillemets simples : WHERE "paiement"='chèque' par exemple.

4 Les sous-formulaires

Ça ne me paraît pas une technique très intéressante (à première vue) mais je vous livre le procédé tel que je le vois.

Ma table "détails_livraisons" enregistre en fait les différents éléments d'une livraison. Les champs "n_livraison" de mes tables "livraisons" et "détails_livraison" étant reliables, je peux faire afficher le formulaire "détails_livraisons" en tant que sous-formulaire. Il faut pour cela créer le formulaire "détails_livraisons" (juste le créer, manière de pouvoir ouvrir ses propriétés). Puis ouvrir les propriétés du formulaire. Puisque je veux faire afficher les éléments d'une livraison précise qui s'identifie par son numéro dans le champ "n_livraison", je vais indiquer, sous l'onglet "Données", le terme "livraison"."n_livraison" (ne pas oublier le point entre le nom de table et celui du champ, ni les guillemets doubles) dans le champ de saisie "établir un lien depuis". Puis, en dessous, dans "établir un lien avec", je vais inscrire le nom d'une variable, par exemple "livre" (sans les guillemets). En dernier lieu, je sélectionne "Commande SQL" comme "type de source de données" et je tape ma commande dans le champ "source de données" : select * (c'est l'étoile du signe "multiplié par", qui symbolise "tous les champs') from "détails_livraisons" where "détails_livraisons"."n_livraison"=:livre (ne pas oublier les deux points qui attestent de la variable). Je pourrai alors trouver tous mes noms de champs au garde à vous dans les "champs de données" des propriétés des champs de contrôle que je vais dessiner sur le formulaire. Au lieu de mettre * j'aurai pu indiquer des champs plus particuliers. A l'ouverture de ce sous-formulaire, une boîte de dialogue me demandera la valeur de ma variable pour ouvrir celui-ci aux endroits où n_livraison=livre. Ce qui est bien nébuleux !

5 Les requêtes

On verra ça plus tard...

À propos de ce document...

Débuter avec Adabas sous StarOffice 5.2

Ce document a été généré grâce à l'utilisation du convertisseur LaTeX2HTML Version 99.2beta8 (1.42).

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

Les arguments de la ligne de commande étaient :
latex2html -no_subdir -split 0 -show_section_numbers /home/cesar/Adabas1.tex

La conversion a été faite par César Alexanian le 4 février 2001

[ Retour ]

Remonter

Site réalisé sous Gnu-Linux en PHP mis en forme avec Quanta et mis en ligne grâce à gFTP sous la Mandrake 9.1