<Desc/Clms Page number 1>
PROCEDES POUR PRODUIRE ET FAIRE FONCTIONNER DES SYSTEMES
DE BASES DE DONNEES
La présente invention concerne des procédés pour produire et faire fonctionner des systèmes de bases de données qui comprennent des structures de mise en mémoire pour les données et des processeurs pour mettre en mémoire, reprendre et traiter les données et établir une interface avec un utilisateur.
Certains des impératifs les plus importants pour un système de bases de données comprennent les éléments suivants : 1. Il ne peut pas y avoir d'erreurs de programme provoquant une interruption du fonctionnement du système ou la dégradation des données.
2. Si des défauts se produisent, par exemple par une utilisation incorrecte du système, ces défauts doivent être facilement détectés et éliminés.
3. Il doit être possible de mettre le système facilement à jour, afin d'y inclure des matériels et des logiciels récemment mis au point.
<Desc/Clms Page number 2>
4. Le texte affiché pendant le fonctionnement doit être clair pour un utilisateur, et la production de systèmes de bases de données à utiliser dans des pays ayant des langues différentes doit pouvoir être effectuée de manière précise et efficace.
Les procédés pour produire un système de bases de données doivent satisfaire à ces impératifs, tout en permettant d'utiliser efficacement le temps de mise au point par les techniciens.
Jusqu'à présent, les systèmes de bases de données ont été mis au point en subdivisant une structure de dispositif de mise en mémoire et en attribuant des parties de la structure à la mise en mémoire de différentes bases de données. Les programmes sont rédigés ensuite afin de mettre en mémoire, de reprendre et de traiter les données en accédant au dispositif de mise en mémoire. Si un nouveau système de bases de données est mis au point ultérieurement et constitue une amélioration du système initial, la mise à jour du système initial implique le déplacement de toutes les données vers un dispositif de mise en mémoire séparé et la reconfiguration des données en vue de la mise en mémoire, conformément à la nouvelle structure du dispositif de mise en mémoire. Ceci peut provoquer la dégradation des données.
Pour ce qui concerne les programmes, ceux-ci sont généralement simplement remplacés par le nouvel ensemble de programmes. Ceci est une opération qui prend du temps et donne souvent lieu à un système qui ne semble pas familier pour l'utilisateur et nécessite donc un certain degré de remise au courant. Compte tenu de ces difficultés pour mettre les systèmes de bases de données à jour, ce travail n'est souvent pas effectué. Par
EMI2.1
1
<Desc/Clms Page number 3>
EMI3.1
e conséquent, un utilisateur ne profite pas souvent du bénéfice complet de ces améliorations.
Si un défaut se produit par suite d'un circuit mal fabriqué ou d'une erreur de programme, un système de détection d'erreur tel celui décrit dans le brevet européen n 180299B (ICL) peut être utilisé. Toutefois, lorsque les techniciens recherchent le défaut, il est très difficile d'identifier exactement où celui-ci se produit, afin de permettre sa réparation. Par exemple, si un appareil d'affichage est vérifié en utilisant le procédé décrit dans le brevet européen n 52,684B (IBM), il faudra beaucoup de temps pour identifier le défaut.
Les systèmes de bases de données sont généralement produits en vue de l'affichage et de l'impression d'un texte dans la langue d'un pays déterminé et, pour pouvoir utiliser efficacement le système de bases de données dans un pays différent, le texte doit être traduit. Si le texte affiché est traduit par la . machine, la signification exacte du texte original n'est souvent pas exactement rendue. Si le texte est traduit manuellement, il peut se produire des discordances et cette opération de traduction manuelle demande beaucoup de temps. Quoique le texte affiché n'affecte pas directement le fonctionnement d'un système de bases de données, il est extrêmement important parce qu'il permet aux utilisateurs (dont beaucoup ne sont pas compétents en électronique) d'ordonner l'exécution de la gamme des fonctions disponibles en utilisant le système de bases de données.
Si le texte affiché n'est pas clair, le système de bases de données sera fortement sous-utilisé.
L'invention vise à proposer des procédés pour produire et faire fonctionner des systèmes de bases de données à mettre à jour, en surmontant au moins certaines de ces-difficultés.
Conformément à l'invention, il est prévu un
<Desc/Clms Page number 4>
procédé pour produire et faire fonctionner un système de bases de données, qui comprend les étapes suivantes : détermination des impératifs propres au système de bases de données ; conception d'une structure de mise en mémoire de la base de données et utilisation de cette conception pour produire une structure de mise en mémoire de bases de données de référence en effectuant les opérations suivantes : produire et mettre en mémoire une structure de cellules de mémoire vierges pour chacune des différentes zones de données et mise en mémoire d'un indicateur indiquant quels sont les types de caractères autorisés pour la mise en mémoire des données dans les cellules ; produire et mettre en mémoire un fichier d'adresses pour les structures de zones ;
afficher une représentation d'une structure de mise en mémoire de bases de données qui comprend plusieurs structures de zones de données et vérifier celle-ci après modification si nécessaire ; et mettre en mémoire la structure de base de données vérifiée comme structure de base de données de référence dans un dispositif de mémoire permanente ; duplication de la structure de la base de données de référence afin d'obtenir une structure de mise
<Desc/Clms Page number 5>
en mémoire de base de données active ; production d'une liste de fonctions de bases de données pour mettre en mémoire, reprendre et traiter les données dans la structure de mise en mémoire de la base de données de référence ; enregistrement des conditions autorisées régissant les opérations de mise en mémoire, de reprise et de traitement ;
enregistrement des événements requis pour mettre le système à l'arrêt en cas de défaut grave, tel que déterminé par l'ensemble des conditions autorisées ; production d'un code pour définir une structure de point de rupture pour traiter les contenus de l'état et de la mémoire ; production d'un code pour mettre en mémoire un fichier des données de points de rupture ; conformément à la liste des fonctions, production de plusieurs modules de code de source général sans texte ; insertion d'un texte dans la langue du pays de destination dans le code de source général, afin de produire un code de source final ; compilation du code de source final ; intégration des modules ;
<Desc/Clms Page number 6>
vérification du code de machine ;
et après utilisation du système de bases de données, modification de celui-ci pour améliorer ses performances en utilisant le matériel et le logiciel disponibles.
L'étape de modification du système comprend de préférence les sous-étapes suivantes : modification de la structure de mise en mémoire de la base de données de référence ; comparaison de la structure de référence modifiée avec la structure active ; production de données de différence ; et modification automatique de la structure active afin de la mettre en conformité avec la structure de référence modifiée.
L'étape de modifier le système comprend de préférence les sous-étapes suivantes : modifier la structure de mise en mémoire de la base de données de référence ; comparer la structure de référence modifiée à la structure active ; produire des données de différence ; et modifier automatiquement la structure active pour la mettre en conformité avec la structure
<Desc/Clms Page number 7>
de référence modifiée.
Dans un mode de réalisation, l'étape de production des modules de code de source général comprend les sous-étapes suivantes : insertion d'un indicateur dans le code de source indiquant la présence d'un texte ; insertion d'une marque indiquant que le texte ne doit pas être traduit : affichage séquentiel de chaque élément de texte à traduire ; optimisation de la disposition du texte ; vérification de la disposition du texte ; exécution des opérations suivantes sur chacune des lignes du code de source : vérification de la présence d'une marque de texte ; conformément à cette constatation, extraction du texte à traduire, s'il y a lieu ; comparaison du texte avec tous les textes préalablement extraits ; assignation d'un nouveau code de texte si celui- ci n'a pas déjà été extrait ;
reprise d'un code de texte associé s'il a déjà
<Desc/Clms Page number 8>
été extrait ; et insertion du code de texte repris et assigné dans la ligne de code de source.
Dans un autre mode de réalisation, l'étape d'insertion du texte dans le module de code de source général comprend les sous-étapes suivantes : production d'une base de données de traduction ayant un enregistrement de texte traduit pour chaque code de texte, une base de données de traduction existant pour chaque langue ; production d'un ensemble de codes de machines pour un programme dans une langue, en exécutant les étapes suivantes : filtrage de chaque ligne de code de source et extraction d'un code de texte, s'il existe ; utilisation du code de texte pour reprendre le texte traduit correspondant pour la base de données de traduction appropriée ; insertion du texte traduit dans la ligne de code de source à la place du code de texte ; et compilation du code de source.
L'invention sera mieux comprise à l'examen de la description ci-après de certains de ses modes de réalisation préférés, donnés uniquement à titre d'exemple et en se référant aux figures en annexe, qui représentent
<Desc/Clms Page number 9>
respectivement :
La figure 1, un diagramme synoptique montrant un procédé de production et de fonctionnement d'un système de bases de données ;
La figure 2, un diagramme synoptique montrant une partie du procédé avec plus de détails ;
La figure 3, un diagramme synoptique montrant des procédés pour faire fonctionner, et notamment pour mettre à jour le système produit ;
Les figures 4 (a) et 4 (b), des diagrammes synoptiques plus détaillés pour une partie du procédé de production du système ;
et
Les figures 5 (a), 5 (b) et 5 (c), des illustrations d'exemples de lignes de code de source préliminaires, générales et finales produites par le procédé de la présente invention.
Si on examine la figure 1, on peut y voir un
EMI9.1
procédé pour produire un système de bases de données. ede pour pro e Le procédé est généralement désigné par le numéro de référence 1 et comprend une étape initiale 2 consistant à déterminer les impératifs pour le système de bases de données. Plus particulièrement, cette étape comprend la détermination des données à mettre en mémoire dans le système et les index pour lesquels des recherches doivent être effectuées afin de reprendre et de trier les données. Ceci conduit à l'étape 3 pour la conception d'une structure de mise en mémoire de bases de données qui est conforme à tous les impératifs. La conception de la structure de mise en mémoire comprend des spécifications pour le disque fixe, le circuit de mémoire, la largeur de bus et le microprocesseur.
Après l'étape 3, une structure de mise en mémoire de bases de données de référence est produite à l'étape 4, cette structure comprenant des valeurs de
<Desc/Clms Page number 10>
paramètres définissant les structures des zones de données pour la mise en mémoire dans un dispostiif de mise en mémoire. L'étape 4 sera décrite plus en détail ci-après.
A l'étape 5, un code de détection d'erreur est produit et est incorporé à des signaux qui concernent la structure de mise en mémoire de la base de données de référence.
L'étape 5 sera également décrite plus en détail ci-après.
Parallèlement avec l'étape 5, on effectue l'étape 8 qui comprend la production de modules de code de source
EMI10.1
e e général. Un module est un groupe de lignes de code de source correspondant qui ne sont pas propres au texte et à la langue d'un pays particulier. D'une manière générale, chaque module concerne un traitement particulier tel que la reprise de données, la mise en mémoire des données, le triage, l'affichage ou certaines autres opérations. Après les étapes 5 et 8, le texte pour la langue d'un pays déterminé est inséré à l'étape 9 dans les modules de code de source général. A l'étape 10, le code de source de chaque module est compilé afin de produire un code de machine.
A l'étape 11, les modules sont intégrés les uns aux autres par mise en mémoire dans des emplacements d'un dispositif de mise en mémoire, si bien qu'ils peuvent subir une vérification croisée et être incorporés au matériel et au logiciel. A l'étape 12, le code de machine compilé est vérifié et le système est alors prêt à être utilisé. A une certaine date ultérieure à l'étape 13, le système est modifié afin d'y incorporer le matériel et le logiciel améliorés.
A la figure 1, les sous-étapes 20 à 24 représentent l'étape 5 comprenant la production d'un code de détection d'erreurs défini plus en détail. A l'étape 20, on enregistre un ensemble de conditions autorisées pour le fonctionnement du système de bases de données. Ces conditions autorisées comprennent les dimensions des registres de mémoire, une gamme de vitesses
<Desc/Clms Page number 11>
de traitement, des capacités de mémoire souhaitées et d'autres conditions. Ces conditions sont produites conformément aux paramètres de la structure de référence produite à l'étape 4. A l'étape 21, on enregistre des événements d'arrêt prédéterminés, ces événements étant ceux en réponse auxquels le système de bases de données devrait cesser de fonctionner.
Un exemple d'évènement de ce genre est une erreur de parité qui indique la dégradation des données ou un défaut répété empêchant l'accès à un dispositif de mise en mémoire particulier.
A l'étape 22, le code de distribution du point de rupture est produit afin d'ordonner à un processeur d'enregistrer le contenu du circuit de mémoire et l'emplacement de l'indicateur de programme si une erreur se produit. Le code produit à l'étape 22 entre uniquement en fonctionnement s'il se produit une erreur peu importante qui, par exemple, ne peut pas produire une dégradation des données. A l'étape 23, un manipulateur de fichier de point de rupture est produit afin de permettre la mise en mémoire des données de distribution de point de rupture dans un fichier unique mis en mémoire dans une mémoire permanente. L'étape 24 comprend la production d'instructions de mise à l'arrêt pour un processeur, afin d'interrompre le fonctionnement du système si on détecte un évènement enregistré a l'étape 21.
Le code de détection d'erreur produit aux étapes 20 à 24 est incorporé à un ou plusieurs des modules de code de source général.
L'effet du code produit à l'étape 5 consiste en ce que, s'il se produit une erreur grave donnant lieu à dégradation des données, le système de bases de données est automatiquement mis à l'arrêt d'une manière contrôlée (en utilisant le code des étapes 21 et 24), ce qui ne provoque pas la perte d'autres données que celles qui ont déjà été perdues. Le code produit à l'étape 22 ordonne
<Desc/Clms Page number 12>
a un processeur de mettre en mémoire tout le contenu de la mémoire et des registres d'un microprocesseur dans un dispositif de mise en mémoire, si bien que celui-ci peut être recherché à une date ultérieure. Ces instructions sont données avant la mise à l'arrêt du système.
Toutefois, si une erreur sans gravité se produit, telle que la mise en mémoire de données dans un dispositif de mise en mémoire non autorisé, le processeur du système de bases de données recevra ordre de produire des données de point de rupture qui donnent une image du contenu de la mémoire et du fonctionnement du programme au moment où l'erreur s'est produite. Ces données de point de rupture sont mises en mémoire dans un fichier unique (en utilisant le code de l'étape 23) dans une mémoire permanente, de façon à pouvoir être facilement retrouvées à une date ultérieure en vue de leur examen par les techniciens. De cette manière, la source d'une erreur peut être immédiatement identifiée sans effectuer des opérations d'analyse compliquées.
Ceci constitue un aspect extrêmement important de la présente invention vu que ceci permet l'identification immédiate d'erreurs relativement peu importantes, si bien que celles-ci peuvent être éliminées avec une courte interruption du fonctionnement du système de bases de données et tout en assurant en même temps la mise à l'arrêt du système d'une manière contrôlée si une erreur grave se produit.
Si on examine maintenant la figure 2, on peut y voir plus en détail l'étape 4 pour la production de la structure de mise en mémoire de bases de données de référence. A l'étape 3, on met en mémoire une structure de mémoire des cellules de mémoire vierges pour chaque zone de données. La structure de mémoire comprend des bytes de mémoire pour chaque zone de données, l'adresse souhaitée des bytes et l'emplacement des bytes par rapport à d'autres zones de la structure de la base de données.
<Desc/Clms Page number 13>
A l'étape 31, on met en mémoire dans le dispositif de mise en mémoire une indication des caractères de données autorisés pouvant être introduits dans la structure de la mémoire de zone. Dans la plupart des cas, cette indication est alphanumérique. A l'étape 32, on produit un fichier d'adresses qui est également mis en mémoire dans le dispositif de mise en mémoire et qui indique les adresses de tous les groupes des zones correspondantes dans une base de données. A l'étape 33, la structure de bases de données est vérifiée par vérification manuelle quant à la cohérence et aux références correctes et quant à l'aptitude à la mise en mémoire du type particulier de données qui est requis. A l'étape 4, toutes les structures de mémoire sont mises en mémoire ensemble sous forme d'une structure de bases de données de référence, désignée par le numéro 35.
La structure de bases de données est ensuite reproduite de façon à ce qu'une structure soit mise en mémoire pour les références futures, tandis que l'autre est utilisée comme structure active pour le système en cours de préparation. A l'étape 36, qui est effectuée en parallèle avec l'étape 34, on produit une liste fonctionnelle indiquant les fonctions des programmes requis pour la mise en mémoire, la reprise et le traitement des données mises en mémoire dans la structure de la base de données de référence. C'est d'après la liste fonctionnelle que les modules de code de source général sont produits à l'étape 8.
La structure de mise en mémoire de la base de données actives qui a été produite est celle qui est utilisée pour le système de bases de données en cours de préparation. En enregistrant successivement chaque structure de mémoire de zone et en interconnectant ultérieurement les structures de zones et en vérifiant la structure de bases de données résultante, on obtient que la structure de la base de données s'adapte
<Desc/Clms Page number 14>
généralement de manière idéale aux impératifs de l'utilisateur et permet une utilisation très efficace de la mémoire.
Cette solution s'est avérée particulièrement appropriée pour utiliser efficacement tout l'espace de mémoire, parce que des réserves peuvent être prévues pour enregistrer des structures de mémoire de zones supplémentaires sans nécessiter la mise en mémoire d'une structure de bases de données dans plus d'un dispositif de mise en mémoire.
La figure 3 représente plus en détail l'étape 13 de la modification du système mis au point. La modification sera effectuée après une utilisation considérable du système. Comme mentionné ci-dessus, si la structure de bases de données de référence produite est redoublée, on prévoit une structure a utiliser comme structure de bases de données actives du système et l'autre structure comme structure de bases de données de référence.
A l'étape 40, la structure de bases de données de référence est modifiée afin de s'adapter aux nouveaux impératifs de l'utilisateur et au matériel et aux programmes nouvellement disponibles. A l'étape 41, si une instruction est reçue pour le système afin de mettre à jour la base de données actives et de référence, les structures mises en mémoire sont automatiquement comparées par un processeur. Ceci implique la comparaison des paramètres utilisés pour établir les structures de bases de mémoire, y compris l'espace de mémoire et les types de caractères autorisés. A l'étape 43, on produit un fichier indiquant les différences entre les structures de mise en mémoire des bases de données actives et de référence.
Parallèlement à l'étape 43, les données de la structure de mise en mémoire de la base de données actives sont transférées à l'étape 42 à une unité de disque séparée. Le processeur met temporairement en
<Desc/Clms Page number 15>
mémoire le fichier des différences et modifie automatiquement la structure de mise en mémoire de la base de données actives, si bien que celle-ci est semblable à la structure de référence. A l'étape 45, les listes fonctionnelles sont comparées et, à l'étape 46, les données qui ont été transférées préalablement sont alors stockées dans la structure de mise en mémoire de la base de données actives modifiée. Toutes modifications requises aux programmes sont également effectuées en fonction de la comparaison entre les listes fonctionnelles.
On comprendra que. si on modifie de cette manière le système de bases de données, on peut maintenir une seule structure de mise en mémoire de bases de données de référence à un emplacement central, tandis que des structures de mises en mémoire actives identiques sont utilisées par différents utilisateurs en différents emplacements. Lorsque le système est modifié, cette opération est réalisée à l'emplacement central en modifiant la structure de référence. La structure de mise en mémoire nouvelle de la base de données de référence est ensuite comparée à toutes les structures actives et les modifications sont effectuées automatiquement. De cette manière, on peut obtenir que toutes les structures de bases de données actives soient automatiquement mises à jour et mises en conformité avec la dernière version.
On a constaté que la structure de mise en mémoire de bases de données constitue un élément clé essentiel pour la modification du système de bases de données et, grâce à une comparaison automatique et à la régénération d'une nouvelle structure de mise en mémoire active, les défauts sont éliminés. Il est évidemment bien important également de veiller à ce que les programmes soient modifiés automatiquement, parallèlement avec cette opération. En pratique, si une
<Desc/Clms Page number 16>
erreur se produit dans un système de bases de données actives, le système est automatiquement mis à jour si ceci n'a pas déjà été fait, si bien que l'appareillage de vérification peut être utilisé pour ce système particulier. Ceci évite la nécessité de disposer d'un grand nombre de systèmes de vérification et de reconfigurer ceux-ci.
Si on examine maintenant simultanément les figures 4 (a) et 4 (b), on peut y voir plus en détail les
EMI16.1
e étapes 8 et 9 du processus représenté a la figure 3.
Ces étapes impliquent la production de modules de code de source général et l'insertion du texte d'un pays déterminé dans les modules. A l'étape 50, on enregistre des instructions pour une ligne de code de source. Ces instructions peuvent concerner la reprise des données ou certaines autres opérations effectuées, comme indiqué par la liste fonctionnelle produite à l'étape 36. A l'étape 51, on décide si un texte est requis ou non pour la ligne de code de source et, si ce n'est pas le cas, des instructions sont mises en mémoire à l'étape 57 sous forme de ligne de code de source préliminaire et le processus est répété pour la ligne de code de source suivante. Toutefois, si un texte est requis, le texte est inséré à l'étape 53 dans la ligne de code de source avec un indicateur indiquant que le texte est présent dans la ligne.
A l'étape 54, on décide si le texte doit être utilisé ou non pour un panneau d'affichage dans un système de bases de données, c'est-à-dire s'il doit être examiné par un utilisateur. Dans la majorité des cas, le texte sera examine par un utilisateur et, dans ces cas, l'étape 5 consistant à optimiser la ligne de code de source et à la vérifier est mise en oeuvre.
L'optimisation de la ligne implique l'affichage du texte dans le contexte des autres données qui seront affichées sur l'écran. Ceci permet à un concepteur de s'assurer
<Desc/Clms Page number 17>
que le texte sera clairement affiché et sera en accord avec le reste de l'affichage sur écran, quelle que soit la langue du texte. Toutefois, si le texte ne doit pas être affiché, une marque est insérée à l'étape 56 dans la ligne de code de source pour indiquer cette situation.
Les étapes 50 a 57 sont répétées pour chaque ligne de code de source requise pour chaque module.
La figure 5 (a) représente un exemple de certaines lignes de code de source préliminaires mises au point maintenant. Le texte est en langue anglaise parce que le système est produit dans un pays de langue anglaise. Les indicateurs de texte sont TEXT et
ENDTEXT et la marque indiquant qu'une traduction n'est pas requise est (SYSTEXT). La marque est dans la section de"commentaires"de la ligne, tandis que les indicateurs de texte sont des instructions de programmation dans la partie principale de la ligne.
A ce stade, on met en mémoire un ensemble de lignes de code de source préliminaires et, a l'étape 60, la première de ces lignes est introduite dans la mémoire, est vérifiée automatiquement pour détecter la présence du texte et, à l'étape 61, on décide si le texte, au cas où il existe, doit être traduit ou non. Ceci implique une vérification de l'existence ou de l'absence d'un indicateur de texte. Si celui-ci existe, on vérifie s'il existe une marque. S'il n'y a pas de marque, c'est alors que le texte doit être traduit. Toutefois, s'il existe une marque, le texte n'est pas à traduire et est prêt à être utilisé par les techniciens de développement.
A l'étape 62, la ligne de code de source est mise en mémoire sous forme de ligne de source générale et le processus est répété ultérieurement jusqu'à l'étape de décision 63. Si le texte est destiné à la traduction, un processeur extrait automatiquement le texte à l'étape 64, en détectant les indicateurs de texte et en
<Desc/Clms Page number 18>
enregistrant sur un fichier séparé tous les bytes contenus dans les indicateurs. A l'étape 65, le processeur produit un code pour cette partie de texte. L'étape 65 est assez complexe car elle implique la comparaison de la ligne de texte en cours avec toutes les lignes de texte extraites précédemment. Si elle n'a pas été extraite
EMI18.1
précédemment, un nouveau code lui est assigné. Si elle prece e a été extraite précédemment, le code qui avait été utilisé antérieurement est utilisé à nouveau.
A l'étape 66, le code de texte nouvellement produit ou repris est inséré dans la ligne de code de source afin de produire une
EMI18.2
e ligne de code de source générale qui est mise en mémoire à l'étape 62. Cette opération est répétée à nouveau pour chacune des lignes de code de source préliminaires. A la fin de ces opérations, il existe un ensemble de lignes de code de source générales qui ne comprennent aucun texte destiné à l'affichage mais simplement une série de codes correspondant à ce texte. Des exemples sont donnés à la figure 5 (b), dans laquelle le code de texte est f001415+, les indicateurs de texte sont conservés et la marque de traduction reste également dans la colonne de commentaires. Il convient de noter que les lignes vides sont traitées par le processeur comme un texte et reçoivent un code de texte.
Si on examine maintenant la figure 4 (b), on peut voir que toutes les lignes ont été vérifiées de cette manière et, à l'étape 70, une liste de tous les codes de texte est préparée. A l'étape 71, le texte correspondant à chaque code de texte est affiché avec d'autres données, qui seront affichées avec celles-ci sur le même écran. Un traducteur introduit alors une traduction dans une langue particulière et, à l'étape 72, le processeur établit des références croisées du code de texte avec un emplacement de mise en mémoire dans une base de données de traduction pour cette langue.
<Desc/Clms Page number 19>
La base de données de traduction est indiquée par le numéro 73. Ces étapes sont répétées pour chaque ligne de code de source général, jusqu'à la production d'une base de données de traduction complète. L'opération est répétée à nouveau pour chaque langue, si bien qu'on obtient une base de données de traduction pour chaque langue souhaitée.
A l'étape 74, une ligne de code de source général est introduite dans la mémoire et, à l'étape 75, elle est vérifiée pour s'assurer qu'il existe un code de texte inséré dans la ligne. Si c'est le cas, le code de texte est extrait à l'étape 76 et est utilisé à l'étape 77 pour reprendre le texte correspondant dans la base de données de traduction 73.
A l'étape 78, le processeur enregistre automatiquement le texte traduit repris dans la base de données de traduction 73 dans la ligne de code de source générale, afin de produire une ligne de code de source finale qui est mise en mémoire a l'étape 79. Des exemples de lignes de code de source finales sont donnés à la figure 5 (c), dans laquelle il convient de constater que le code de texte a été remplacé par un texte provenant d'une base de données en langue
EMI19.1
e allemande. Les lignes de code de source générales qui ne comprennent pas un code de texte sont également mises en mémoire à l'étape 79 sous forme de lignes de code de source finales. Suivant la vérification effectuée à l'étape 80, ce processus est répété pour chaque ligne de code de source générale.
Enfin, l'étape 10 de la figure 4 (b) constitue l'étape de compilation de toutes les lignes de code de source finales.
On comprendra que la production de modules de code de source effectuée de cette manière avec le texte dans la langue souhaitée permet de produire un système de bases de données pour de nombreuses langues différentes, et cela d'une manière simple, économique,
<Desc/Clms Page number 20>
précise et cohérente. Il faut assez bien de travail pour produire les bases de données de traduction mais, une fois que ceci a été effectué, des systèmes de bases de données pour différents pays peuvent être préparés très rapidement. Le texte qui est affiché en utilisant le système de bases de données est généralement clair et s'accorde bien aux autres données affichées, et il existe une cohérence complète entre les traduction des différents éléments du texte.
Ce qui a été réalisé grâce à la présente invention est l'optimisation du travail humain pour le texte de traduction conformément au contexte d'un écran ainsi que l'élimination simultanée des incohérences entre les traductions, qui se produiraient sinon dans le cas où le code de texte ne serait pas produit automatiquement.
On comprendra donc que l'invention permet la préparation d'un système de bases de données d'une manière efficace, celui-ci étant généralement exempt d'erreurs et permettant une détection facile des erreurs.
L'invention n'est pas limitée aux modes de réalisation décrits ci-dessus mais peut subir des variations de construction et de détail.
<Desc / Clms Page number 1>
METHODS FOR PRODUCING AND OPERATING SYSTEMS
DATABASES
The present invention relates to methods for producing and operating database systems that include data storage structures and processors for storing, retrieving and processing data and interfacing with a user.
Some of the most important requirements for a database system include the following: 1. There can be no program errors causing system operation interruption or data degradation.
2. If faults occur, for example through improper use of the system, these faults must be easily detected and eliminated.
3. It should be possible to easily update the system to include newly developed hardware and software.
<Desc / Clms Page number 2>
4. The text displayed during operation must be clear to a user, and the production of database systems for use in countries with different languages must be able to be performed accurately and efficiently.
The processes for producing a database system must meet these requirements, while allowing efficient use of the development time by technicians.
To date, database systems have been developed by subdividing a storage device structure and assigning parts of the structure to the storage of different databases. The programs are then written in order to store, resume and process the data by accessing the storage device. If a new database system is developed later and is an improvement on the initial system, updating the initial system involves moving all of the data to a separate memory device and reconfiguring the data in order to of storage, in accordance with the new structure of the storage device. This can degrade the data.
As far as programs are concerned, these are usually simply replaced by the new set of programs. This is a time consuming operation and often results in a system which does not seem familiar to the user and therefore requires a certain degree of familiarization. Given these difficulties in updating database systems, this work is often not done. By
EMI2.1
1
<Desc / Clms Page number 3>
EMI3.1
therefore, a user does not often benefit from the full benefit of these improvements.
If a fault occurs as a result of a poorly manufactured circuit or a program error, an error detection system such as that described in European Patent No. 180299B (ICL) can be used. However, when technicians look for the fault, it is very difficult to identify exactly where it occurs, in order to allow its repair. For example, if a display device is checked using the method described in European Patent No. 52,684B (IBM), it will take a long time to identify the defect.
Database systems are generally produced for the display and printing of text in the language of a particular country and, in order to be able to use the database system in a different country effectively, text must be translated. If the displayed text is translated by the. machine, the exact meaning of the original text is often not exactly rendered. If the text is translated manually, there may be discrepancies and this manual translation operation is time consuming. Although the text displayed does not directly affect the operation of a database system, it is extremely important because it allows users (many of whom are not proficient in electronics) to order the execution of the range functions available using the database system.
If the text displayed is not clear, the database system will be greatly underused.
The invention aims to provide methods for producing and operating database systems to be updated, by overcoming at least some of these difficulties.
According to the invention, there is provided a
<Desc / Clms Page number 4>
a method for producing and operating a database system, which comprises the steps of: determining requirements specific to the database system; design of a database storage structure and use of this design to produce a reference database storage structure by performing the following steps: producing and storing a memory cell structure blank for each of the different data areas and storage of an indicator indicating which types of characters are authorized for storing data in the cells; generate and store an address file for area structures;
display a representation of a database storage structure which includes several data area structures and check it after modification if necessary; and storing the verified database structure as a reference database structure in a permanent memory device; duplication of the structure of the reference database in order to obtain a layout structure
<Desc / Clms Page number 5>
in active database memory; producing a list of database functions for storing, retrieving and processing the data in the storage structure of the reference database; recording of the authorized conditions governing the operations of storage, recovery and processing;
recording of events required to shutdown the system in the event of a serious fault, as determined by all of the authorized conditions; producing code to define a breakpoint structure for processing state and memory contents; production of a code for storing a file of break point data; in accordance with the list of functions, production of several modules of general source code without text; insertion of a text in the language of the destination country in the general source code, in order to produce a final source code; compilation of final source code; integration of modules;
<Desc / Clms Page number 6>
machine code verification;
and after using the database system, modifying it to improve its performance using the available hardware and software.
The step of modifying the system preferably comprises the following sub-steps: modification of the storage structure of the reference database; comparison of the modified reference structure with the active structure; production of difference data; and automatic modification of the active structure in order to bring it into conformity with the modified reference structure.
The step of modifying the system preferably comprises the following sub-steps: modifying the storage structure of the reference database; compare the modified reference structure to the active structure; generate difference data; and automatically modify the active structure to bring it into conformity with the structure
<Desc / Clms Page number 7>
modified reference.
In one embodiment, the step of producing the general source code modules comprises the following sub-steps: insertion of an indicator in the source code indicating the presence of a text; insertion of a mark indicating that the text must not be translated: sequential display of each element of text to be translated; text layout optimization; verification of text layout; performing the following operations on each line of the source code: checking for the presence of a text mark; in accordance with this observation, extraction of the text to be translated, if necessary; comparison of the text with all the texts previously extracted; assignment of a new text code if it has not already been extracted;
resumption of an associated text code if it already has
<Desc / Clms Page number 8>
been checked out; and insertion of the text code used and assigned in the line of source code.
In another embodiment, the step of inserting the text into the general source code module comprises the following substeps: production of a translation database having a record of translated text for each text code , an existing translation database for each language; production of a set of machine codes for a program in a language, by performing the following steps: filtering each line of source code and extracting a text code, if it exists; use of the text code to retrieve the corresponding translated text for the appropriate translation database; insertion of the translated text in the line of source code in place of the text code; and compilation of source code.
The invention will be better understood on examining the description below of some of its preferred embodiments, given solely by way of example and with reference to the appended figures, which represent
<Desc / Clms Page number 9>
respectively :
Figure 1, a block diagram showing a method of producing and operating a database system;
Figure 2, a block diagram showing part of the process in more detail;
FIG. 3, a block diagram showing methods for operating, and in particular for updating the product system;
Figures 4 (a) and 4 (b), more detailed block diagrams for part of the system production process;
and
Figures 5 (a), 5 (b) and 5 (c), illustrations of examples of preliminary, general and final source code lines produced by the method of the present invention.
If we look at Figure 1, we can see a
EMI9.1
process for producing a database system. ede pour pro e The method is generally designated by the reference number 1 and comprises an initial step 2 consisting in determining the requirements for the database system. More particularly, this step includes determining the data to be stored in the system and the indexes for which searches must be carried out in order to retrieve and sort the data. This leads to step 3 for the design of a database storage structure which meets all requirements. The design of the storage structure includes specifications for the fixed disk, memory circuit, bus width, and microprocessor.
After step 3, a structure for storing reference databases is produced in step 4, this structure comprising values of
<Desc / Clms Page number 10>
parameters defining the structures of the data areas for storage in a storage device. Step 4 will be described in more detail below.
In step 5, an error detection code is produced and is incorporated into signals which relate to the storage structure of the reference database.
Step 5 will also be described in more detail below.
In parallel with step 5, we perform step 8 which includes the production of source code modules
EMI10.1
e general. A module is a group of lines of corresponding source code that are not specific to the text and language of a particular country. In general, each module relates to a specific processing such as data recovery, data storage, sorting, display or certain other operations. After steps 5 and 8, the text for the language of a specific country is inserted in step 9 in the general source code modules. In step 10, the source code for each module is compiled to produce machine code.
In step 11, the modules are integrated with each other by storage in locations of a storage device, so that they can be cross-checked and incorporated into hardware and software. In step 12, the compiled machine code is checked and the system is then ready for use. On a certain date subsequent to step 13, the system is modified in order to incorporate the improved hardware and software.
In FIG. 1, the sub-steps 20 to 24 represent the step 5 comprising the production of an error detection code defined in more detail. In step 20, a set of authorized conditions for the operation of the database system is recorded. These permitted conditions include the dimensions of the memory registers, a range of speeds
<Desc / Clms Page number 11>
processing, desired memory capacities and other conditions. These conditions are produced in accordance with the parameters of the reference structure produced in step 4. In step 21, predetermined stop events are recorded, these events being those in response to which the database system should stop function.
An example of such an event is a parity error which indicates data degradation or a repeated fault preventing access to a particular memory device.
In step 22, the breakpoint distribution code is produced to order a processor to record the contents of the memory circuit and the location of the program indicator if an error occurs. The code produced in step 22 only enters into operation if a minor error occurs which, for example, cannot produce data degradation. In step 23, a breakpoint file manipulator is produced to allow storage of breakpoint distribution data in a single file stored in permanent memory. Step 24 includes the production of shutdown instructions for a processor, in order to interrupt the operation of the system if an event recorded in step 21 is detected.
The error detection code produced in steps 20-24 is incorporated into one or more of the general source code modules.
The effect of the code produced in step 5 is that, if there is a serious error leading to data degradation, the database system is automatically shutdown in a controlled manner ( using the code in steps 21 and 24), which does not cause the loss of data other than that which has already been lost. The code produced in step 22 orders
<Desc / Clms Page number 12>
has a processor to store all the contents of the memory and registers of a microprocessor in a memory device, so that it can be retrieved at a later date. These instructions are given before the system is shut down.
However, if a minor error occurs, such as storing data in an unauthorized memory device, the database system processor will be instructed to generate breakpoint data that gives an image memory contents and program operation at the time the error occurred. This breakpoint data is stored in a single file (using the code from step 23) in a permanent memory, so that it can be easily found at a later date for examination by the technicians. In this way, the source of an error can be immediately identified without carrying out complicated analysis operations.
This is an extremely important aspect of the present invention since it allows the immediate identification of relatively unimportant errors, so that these can be eliminated with a short interruption in the operation of the database system and while ensuring at the same time shutting down the system in a controlled manner if a serious error occurs.
If we now examine Figure 2, we can see in more detail step 4 for the production of the storage structure for reference databases. In step 3, a memory structure of the blank memory cells for each data area is stored. The memory structure includes bytes of memory for each data area, the desired address of the bytes, and the location of the bytes relative to other areas of the database structure.
<Desc / Clms Page number 13>
In step 31, an indication of the authorized data characters that can be entered into the structure of the zone memory is stored in the memory device. In most cases, this indication is alphanumeric. In step 32, an address file is produced which is also stored in the memory device and which indicates the addresses of all the groups of the corresponding areas in a database. In step 33, the database structure is checked by manual checking for consistency and correct references and for the ability to store the particular type of data that is required. In step 4, all the memory structures are stored together in the form of a reference database structure, designated by the number 35.
The database structure is then reproduced so that one structure is stored for future reference, while the other is used as the active structure for the system being prepared. In step 36, which is carried out in parallel with step 34, a functional list is produced indicating the functions of the programs required for storing, retrieving and processing the data stored in the database structure. reference data. It is from the functional list that the general source code modules are produced in step 8.
The storage structure of the active database that was produced is the one that is used for the database system being prepared. By successively registering each zone memory structure and subsequently interconnecting the zone structures and verifying the resulting database structure, the database structure is obtained
<Desc / Clms Page number 14>
generally ideally suited to user requirements and allows very efficient use of memory.
This solution has proven to be particularly suitable for efficiently using all the memory space, because reserves can be provided for saving memory structures of additional zones without requiring the storage of a database structure in more a memory device.
Figure 3 shows in more detail step 13 of the modification of the developed system. The modification will be made after considerable use of the system. As mentioned above, if the reference database structure produced is duplicated, one structure is used as the active database structure of the system and the other structure as the reference database structure.
In step 40, the structure of reference databases is modified in order to adapt to the new requirements of the user and to the hardware and to the newly available programs. In step 41, if an instruction is received for the system to update the active and reference database, the structures stored in memory are automatically compared by a processor. This involves comparing the parameters used to establish memory base structures, including memory space and the types of characters allowed. In step 43, a file is produced indicating the differences between the storage structures of the active and reference databases.
In parallel with step 43, the data of the storage structure of the active database is transferred in step 42 to a separate disk drive. The processor temporarily turns on
<Desc / Clms Page number 15>
memory the difference file and automatically changes the storage structure of the active database, so that it is similar to the reference structure. In step 45, the functional lists are compared and, in step 46, the data which has been transferred beforehand is then stored in the storage structure of the modified active database. Any required modifications to the programs are also made based on the comparison between the functional lists.
We will understand that. if you modify the database system in this way, you can maintain a single reference database storage structure in a central location, while identical active storage structures are used by different users. different locations. When the system is modified, this operation is carried out at the central location by modifying the reference structure. The new storage structure of the reference database is then compared with all the active structures and the modifications are carried out automatically. In this way, it can be obtained that all active database structures are automatically updated and brought into conformity with the latest version.
It has been found that the database storage structure is an essential key element for modifying the database system and, through automatic comparison and regeneration of a new active storage structure, faults are eliminated. It is obviously also very important to ensure that the programs are changed automatically, in parallel with this operation. In practice, if a
<Desc / Clms Page number 16>
error occurs in an active database system, the system is automatically updated if this has not already been done, so the verification apparatus can be used for this particular system. This avoids the need to have a large number of verification systems and to reconfigure them.
If we now examine Figures 4 (a) and 4 (b) simultaneously, we can see in more detail the
EMI16.1
e steps 8 and 9 of the process shown in Figure 3.
These steps involve the production of general source code modules and the insertion of the text of a specific country into the modules. In step 50, instructions are recorded for a line of source code. These instructions can relate to data recovery or certain other operations carried out, as indicated by the functional list produced in step 36. In step 51, it is decided whether or not a text is required for the line of source code and , if not, instructions are stored in step 57 as a line of preliminary source code and the process is repeated for the next line of source code. However, if text is required, the text is inserted in step 53 in the line of source code with an indicator indicating that the text is present in the line.
In step 54, it is decided whether or not the text should be used for a display panel in a database system, i.e. if it should be examined by a user. In the majority of cases, the text will be examined by a user and, in these cases, step 5 consisting in optimizing the line of source code and in verifying it is implemented.
Line optimization involves displaying the text in the context of other data that will be displayed on the screen. This allows a designer to ensure
<Desc / Clms Page number 17>
that the text will be clearly displayed and will be consistent with the rest of the screen display, regardless of the language of the text. However, if the text is not to be displayed, a mark is inserted in step 56 in the line of source code to indicate this situation.
Steps 50 to 57 are repeated for each line of source code required for each module.
Figure 5 (a) shows an example of some lines of preliminary source code developed now. The text is in English because the system is produced in an English speaking country. Text indicators are TEXT and
ENDTEXT and the mark indicating that a translation is not required is (SYSTEXT). The mark is in the "comments" section of the line, while the text indicators are programming instructions in the main part of the line.
At this stage, a set of lines of preliminary source code is stored in memory and, in step 60, the first of these lines is entered into the memory, is automatically checked for the presence of the text and, when step 61, it is decided whether the text, if it exists, should be translated or not. This involves checking the existence or absence of a text indicator. If it exists, we check if there is a mark. If there is no mark, then the text must be translated. However, if there is a mark, the text is not to be translated and is ready for use by development technicians.
In step 62, the source code line is stored in the form of a general source line and the process is repeated later until decision step 63. If the text is intended for translation, a processor automatically extracts the text in step 64, detecting the text indicators and
<Desc / Clms Page number 18>
recording in a separate file all the bytes contained in the indicators. In step 65, the processor produces a code for this part of text. Step 65 is quite complex since it involves comparing the current line of text with all the lines of text previously extracted. If it has not been extracted
EMI18.1
previously, a new code is assigned to it. If it prece e was extracted previously, the code which had been used previously is used again.
In step 66, the newly produced or resumed text code is inserted into the line of source code in order to produce a
EMI18.2
The general source code line which is stored in step 62. This operation is repeated again for each of the preliminary source code lines. At the end of these operations, there is a set of general source code lines which do not include any text intended for display but simply a series of codes corresponding to this text. Examples are given in Figure 5 (b), where the text code is f001415 +, the text flags are kept and the translation mark also remains in the comments column. Note that blank lines are treated by the processor as text and given a text code.
If we now examine Figure 4 (b), we can see that all the lines have been checked in this way and, in step 70, a list of all text codes is prepared. In step 71, the text corresponding to each text code is displayed with other data, which will be displayed with these on the same screen. A translator then enters a translation into a particular language and, in step 72, the processor establishes cross-references of the text code with a storage location in a translation database for this language.
<Desc / Clms Page number 19>
The translation database is indicated by the number 73. These steps are repeated for each line of general source code, until the production of a complete translation database. The operation is repeated again for each language, so that a translation database for each desired language is obtained.
In step 74, a line of general source code is entered into the memory and, in step 75, it is checked to ensure that there is a text code inserted in the line. If this is the case, the text code is extracted in step 76 and is used in step 77 to retrieve the corresponding text in the translation database 73.
In step 78, the processor automatically stores the translated text included in the translation database 73 in the general source code line, in order to produce a final source code line which is stored in the step 79. Examples of final source code lines are given in Figure 5 (c), where it should be noted that the text code has been replaced by text from a language database
EMI19.1
e German. General source code lines that do not include text code are also stored in step 79 as final source code lines. Following the verification performed in step 80, this process is repeated for each line of general source code.
Finally, step 10 in Figure 4 (b) is the step of compiling all of the final source code lines.
It will be understood that the production of source code modules carried out in this way with the text in the desired language makes it possible to produce a database system for many different languages, and this in a simple, economical manner,
<Desc / Clms Page number 20>
precise and consistent. It takes quite a bit of work to produce the translation databases but, once this has been done, database systems for different countries can be prepared very quickly. The text that is displayed using the database system is generally clear and fits well with the other data displayed, and there is complete consistency between the translations of the different elements of the text.
What has been achieved with the present invention is the optimization of human work for the translation text in accordance with the context of a screen as well as the simultaneous elimination of inconsistencies between the translations, which would otherwise occur in the case where the text code would not be generated automatically.
It will therefore be understood that the invention allows the preparation of a database system in an efficient manner, this system being generally free of errors and allowing easy detection of errors.
The invention is not limited to the embodiments described above but can undergo variations in construction and detail.