 |
||||||
|
||||||
Le terme ISAM vient des bases de données Indexées Séquentielles (Indexed Sequential Acces Method). Dans le cadre de SCR/AL1, les systèmes utilisés sont plus nombreux : ils incorporent dorénavant une série de bases de données relationnelles.
Si dans la version actuelle, un seul système de base de données est utilisable dans un même programme, les versions ultérieures permettront d'en incorporer plusieurs.
La suite de cette section est une énumération des différents mots-clés utilisables dans le cadre des ISAM, avec pour chacun le détail de son domaine d'utilisation.
Ordre de définition
Dans la définition d'un ISAM, il faudra toujours commencer par le nom de la database. Dans la suite, l'ordre des définitions n'a pas d'importance, mais les FIELDS seront définis avant les INDEX.
Il est cependant conseillé de s'en tenir à l'ordre de la syntaxe pour permettre une lisibilité plus grande par les autres utilisateurs.
Nom de la database
Le nom de la database doit apparaître en première position dans la définition d'un ISAM entre doubles quotes. Il détermine le nom du fichier physique contenant la base de données. Suivant le système, ce nom peut être la racine du nom de plusieurs fichiers (.dat, .idx, .num par exemple).
Le nom du fichier doit correspondre à une racine valable pour le système d'exploitation sous-jacent. Dans le cas contraire, scr4 serait incapable de créer la base de données.
Les / compris dans le nom sont remplacés en DOS par des \\. De cette façon, une application pourra être plus facilement portée en UNIX.
Exemple
ISAM ex1 {
"files/clients"
...
}
donnera lieu (en DOS et CTREE) à 2 ou 3 fichiers :
files\\clients.dat
files\\clients.idx
files\\clients.num
et en UNIX aux fichiers
files/clients.dat
files/clients.idx
files/clients.num
CTREE | CISAM | INFORMIX | ORACLE | SYBASE | POSTGRES | MYSQL
Le système de base de données dans lequel l'ISAM défini devra être construit et géré est déterminé par ce mot clé.
Chaque système a ses caractérisqtiques et ses limites propres.
NO_OBJ et DEF_OBJ
Le programme scr4_e génère par défaut des structures OBJ pour chaque champ et chaque index de chaque ISAM (sauf si le paramètre -noobj indique le contraire). Pour éviter de surcharger les programmes, on peut supprimer ces définitions pour un ISAM par l'instruction NO_DEF dans la définition de l'ISAM. DEF_OBJ indique que tous les objets doivent être générés.
Pour plus de détail, consulter le chapitre "Utilisation des ISAMS en C" plus bas dans ce manuel.
CRYPT
Le mot-clé CRYPT peut être placé dans la définition d'un ISAM. Dans ce cas, toutes les informations écrites dans les fichiers associés sont cryptées et donc inutilisables sans passer par l'application. Du point de vue du programmeur, un fichier crypté se comporte exactement comme un autre : les records lus sont décryptés avant d'être repassés au programme.
Ce mot-clé ne s'applique qu'aux bases de données CTREE.
NO_HIST
Ce mot-clé s'applique dans les applications qui exploitent les fonctions IS_init_history() et IS_end_history() pour enregistrer et reproduire par la suite toutes les modifications apportées aux ISAM.
On retrouve dans ce cas les lignes suivantes dans le programme principal:
IS_init_history()
SCR_transfile = "fichier des modifs";
...
IS_end_history()
Les bases de données qui ne doivent pas faire l'objet d'un enregistrement sont identifiées par le mot-clé NO_HIST.
En effet, toutes les modifications aux bases de données sont par défaut enregistrées dès que IS_init_history() est exécutée.
WRITE_FN, REWRITE_FN, DELETE_FN, READ_FN
Ces mots-clés permettent de définir des actions qui seront exécutées au moment des écritures, lectures, etc dans la base de données. Ces mots-clés ont chacun la syntaxe suivante :
WRITE_FN {action}
Exemple
WRITE_FN {C_FN return(Verify());}
avant l'écriture d'un nouveau record dans le fichier, la fonction utilisateur Verify() sera appelée. Si elle retourne 0, l'écriture aura lieu, sinon, l'écriture ne sera rejetée.
Ces actions s'effectuent aux moments suivants :
MODIFY_CATG, CREATE_CATG, DELETE_CATG, SEARCH_CATG
Ces mots-clés permettent de spécifier pour chaque opération de base (WRITE, REWRITE, DELETE et READ) un niveau d'autorisation.
Si la catégorie de l'utilisateur (défini soit par une variable d'environnement, soit par la variable SCR_USER_CATG, qui par défaut vaut -1) est inférieure ou égale à celle spécifiée, l'opération peut avoir lieu. Dans le cas contraire, l'opération est rejetée.
Exemple
CREATE_CATG 10
Seuls les utilisateurs pour lesquels SCR_USER_CATG est plus petit ou égal à 10 pourront créer un record dans la database.
VARLEN
Ce mot-clé permet de spécifier que le fichier de données peut contenir des champs de longueur variable. Si une des définitions des champs commence par VFIELD, ce mot-clé est inutile. Par contre, si on prévoit que dans le futur un tel champ va pouvoir être défini, on doit le préciser dès le départ.
Il est à remarquer qu'un fichier VARLEN a l'avantage d'accepter des nouveaux champs sans avoir à reconstruire la base de données. En effet, certains records peuvent contenir plus de champs que d'autres.
BUF_SEARCH
Ce mot-clé permet à la fonction IS_search() de ne pas rechercher deux fois de suite le même record. Par exemple, lors d'un scan sur le ficher client où le code pays est presque toujours BEL - BELGIQUE, la requête SQL ne sera traîtée que si la recherche change.
Attention : n'utiliser ce mot clé que si les bases de données ne changent presque pas ou ne sont changées que par une seule personne.
ISAM : DEF_MAX
Les defines pour les valeurs directes du type is_max_NUM sont générés seulement si le mot-clè DEF_MAX est défini dans l'isam.
FIELD ou VFIELD
La distinction entre FIELD et VFIELD est évidente : elle permet de spécifier si le champ est un champ de longueur variable (le système de base de données doit le supporter!) ou non.
Pour le reste, la syntaxe est la même.
Les champs définissent la structure des enregistrements de la base de données. L'ordre de définition sera aussi l'ordre physique des champs.
Dans certains systèmes (notamment CTREE), le premier byte du record indique si le record est détruit ou actif. Evitez donc d'utiliser comme premier champ un champ pouvant contenir le caractère -1 (0xFF), comme par exemple un champ de type long ou double. Il est préférable de perdre ce premier champ en plaçant un champ "perdu" de type CHAR en première position.
Chaque définition de champ est composé de 3 parties :
Ces données peuvent être introduites dans n'importe quel ordre, mais l'ordre habituel (et donc préférable pour des raisons de lisibilité) est le suivant :
FIELD {external_isf | field_type} [NAME name] [isf_attr]
Champs externes
Pour éviter d'introduire plusieurs définitions pour des champs liés, on peut remplacer la définition d'un champ par une référence à un champ préalablement défini dans la DBD.
Ainsi :
ISAM is_post {
...
FIELD string 5 NAME code
...
}
ISAM is_client {
...
FIELD ISAM is_post code NAME codepost
...
}
Permet d'éviter de définir le champ code de deux façons différentes dans deux ISAM liés.
Noms des champs
Les noms des champs permettent de référencer les valeurs dans les programmes C ou dans les autres objets référençant les ISAMS (PAGES par exemple). Ils servent également dans la spécification des INDEX de l'ISAM.
Le nom du champ est toujours précédé du mot-clé NAME :
FIELD string 20 NAME nom
Types de champs
Les types de champs reconnus sont les suivants :
FIELD NAME langue MENU mn_test {
TITLE "LANGUE"
OPTION "Français"
OPTION "Néerlandais"
OPTION "Anglais"
}
Autres informations
Une série d'autres informations peuvent optionnellement être spécifiées au niveau de chaque champ. Elles serviront à définir plus facilement tous les champs des PAGES qui seront liées au champ de l'ISAM. Ainsi, un champ défini UPPER au niveau de l'ISAM héritera dans tous les champs de cet attribut.
Un seul attribut à un effet direct au niveau de l'ISAM : REQUIRED. Si la valeur du champ est vide au moment de l'écriture dans la base de données, (nulle dans le cas de valeurs numériques ou blanc dans le cas des champs de type caractère (STRING, ZSTRING et CHAR)), l'écriture sera rejetée.
Tous les autres attributs sont uniquement placés dans la définition pour la facilité lors de la création des PAGES.
Les attributs possibles et leur significations sont exposées ci-dessous. Pour plus de détail, il faut se reporter à la définition des champs dans les PAGES. Tous ces attributs sont optionnels.
Exemple
FIELD string 8 NAME client CODE is_client code = nom
La PAGE générée par scr4_e -i contiendra les champs :
FIELD ISF client CODE is_client code /* Champ habituel */
FIELD ISAM is_client nom line = col + 10 /* Champ secondaire */
INDEX
Les bases de données doivent pouvoir être consultées de différentes façons. Pour permettre un recherche rapide dans un ISAM, on lui adjoindra des INDEX, qui indiquent les ordres de classements des enregistrements en nommant successivement les champs sur lesquels un classement sera effectué.
Les INDEX peuvent être modifiés pour une base de données existante. Il suffira de "reconstruire" le fichier à l'aide de la commande
scr4 -ir isam
pour obtenir un nouveau fichier d'index, classé suivant les nouveaux index.
La syntaxe des définitions d'index est très simple
INDEX index_defn [NAME name] [ASC | DES] [DUP | NODUP]
où
index_defn ::= {
field_name[:length] [SQZ | UPPER | LOWER]
...
}
Chaque index est donc un suite de noms de champs complétés par des qualificatifs. Par exemple :
FIELD string 6 NAME user
FIELD date NAME date
FIELD time NAME time
INDEX {user upper date time} ASC DUP NAME user
définit un index de 3 champs : user, date et time. Cet index est classé en ordre ascendant (ASC) et des valeurs multiples sont permises (DUP). Le nom de l'index est "user". Le champ user est mis en majuscules avant le classement.
Définition des champs dans un index
Les champs qui composent l'index sont mis entre accolades ({}). Chacun des noms de champs peut être suivi d'une longueur à utiliser précédée du caractère deux points.
INDEX {name:10}
Dans ce cas, seuls les 10 premiers caractères du champ name seront utilisés pour le classement (VANDENBROECK, VANDENBROEK, VANDENBROECKE, etc, seront perçus comme identiques du point de vue de la recherche par cet index).
De plus, chaque champ de l'index peut être modifié pour le classement. Trois valeurs exclusives sont permises :
Ces valeurs n'ont pas d'effet au niveau du champ. Simplement, lors de la construction de l'index qui a lieu à chaque recherche, écriture ou réécriture, les champs concernés sont modifiés au sein de l'index. La valeur SQZ par exemple permet de rendre identiques deux noms comme "VANDAMME" et "Van Damme" au sens du classement.
Ordre de classement
Un index peut être construit en ordre croissant ou décroissant. Un des deux mots-clés ci-dessous sera donc adjoint à la définition d'un index pour indiquer au système dans quel ordre il doit classer les enregistrements.
Unicité de l'index
Si l'index contient des champs qui ne peuvent exister qu'une seule fois dans la base de données, comme un numéro de client dans la database des clients, l'index est dit NODUP et une tentative d'écriture d'un second record avec un numéro existant sera rejetée par le système de fichier.
Il est fortement conseillé, et souvent indispensable de définir au moins un index NODUP dans une base de données : en effet, cela permet d'identifier chaque record par un champ et de le retrouver en une opération.
Exemple
FIELD string 6 Name Code Title "Code client" UPPER
FIELD string 30 Name nom Title "Nom client"
...
INDEX {code} NODUP ASC
INDEX {nom:20 sqz} DUP ASC
Le code client ne peut exister qu'une seule fois dans la base de données : c'est l'identifiant des clients. Cet index est donc NODUP.
Par contre, deux clients peuvent avoir le même nom. L'index basé sur le nom (limité ici au 20 premiers caractères) est donc DUP.
NO_OBJ et DEF_OBJ
Le programme scr4_e génère par défaut des structures OBJ pour chaque chaque index de chaque ISAM (sauf si le paramètre -noobj indique le contraire). Pour forcer la définition de l'objet correspondant à l'index, on indiquera DEF_OBJ. NO_OBJ supprime la définition de l'INDEX comme objet (OBJ).
Pour plus de détail, consulter le chapitre "Utilisation des ISAMS en C" plus bas dans ce manuel.
Intégrité référentielle
Les contraintes sont exprimées au niveau des champs et des index de l'ISAM référant. L'ISAM référant est celui qui contient un champ devant exister dans l'ISAM référé.
Exemple
Dans le cas d'un fichier client et d'un fichier de bons de commandes, le numéro de client est défini dans le fichier client et référencé dans celui des bons de commandes. L'ISAM référé est le fichier client, l'ISAM référant le fichier des bons de commandes.
Syntaxe :
FIELD ... FOREIGN_KEY isam_defn idx_name [DELETE] [UPDATE] (à éviter ?)
INDEX ... FOREIGN_KEY isam_defn idx_name [DELETE] [UPDATE]
Sémantique :
La seule différence entre une définition au niveau du champ ou de l'index est que dans le second cas, on peut référencer un index composite.
Lorsqu'on indique qu'un champ (ou un index) est une clé étrangère, les contraintes suivantes en découlent:
Exemple : on ne peut créer un bon de commande si le numéro de client n'existe pas dans le fichier des clients.
Exemple : on ne peut attribuer un bon de commande à un client qui n'existe pas
Exemple : on modifie le numéro du client dans tous les bons de commandes si le numéro de client est modifié.
Exemple : on détruit les bons de commandes du client qu'on détruit. On détruit également toutes les lignes des bons de commandes par récursivité (pas implémenté).
Copyright © 1998-2015 Jean-Marc Paul and Bernard PAUL - Envoyez vos remarques ou commentaires à bernard@xon.be