FR2764719A1 - Dispositif d'analyse et d'organisation de donnees - Google Patents

Abstract

L'invention concerne un dispositif de traitement de données comprenant un système de gestion de bases de données (470). Le système de gestion (470) peut coopérer avec un système d'exploitation pour permettre à l'utilisateur la création/ saisie et/ ou l'usage d'une base de données comprenant au moins une table de données (475), décomposable en lignes et colonnes. Selon l'invention le dispositif comporte en outre : - un méta-dictionnaire autonome (510), pour mémoriser dynamiquement des informations choisies relatives à la structure de chaque table de la base de données, et aux liens entre tables,- un moyen d'analyse (530) capable de déterminer et de mémoriser au moins temporairement une représentation de groupes de colonnes liées entre elles, et- un module de re-structuration (580, 590) coopérant avec le moyen d'analyse et le méta-dictionnaire en vue d'établir pour l'utilisateur une présentation de la base de données qui tienne compte d'au moins un groupe de colonnes ainsi liées.

Description

I H 2764719

Dispositif d'analyse et d'organisation de données La présente invention concerne les systèmes de traitement et

de stockage de l'information du type bases de données.

De tels systèmes peuvent être rendus accessibles à des utilisateurs non initiés, à l'aide d'outils de développement appropriés. Ces outils sont très souvent utilisés par les professionnels (les hommes du métier), car ils allègent considérablement les coûts de développement des applications

articulées sous la forme base de données.

Par ailleurs, on sait que la qualité d'une application est fortement tributaire de la qualité de l'étude initiale des besoins à satisfaire, et par conséquent du budget qui y a été consacré. Or, du fait de leur élaboration "mécanique", les modules obtenus à l'aide des outils précités sont généralement peu souples. En fait, leur souplesse est orientée davantage sur l'aménagement de l'interface utilisateur, que sur

d'éventuelles variations des besoins plus fondamentaux.

Pour ces raisons, et aussi en fonction de l'évolution natu-

relle des besoins, il est fréquemment nécessaire de modifier par la suite une telle application. Une telle modification ultérieure est une tâche très lourde, dont le poids croit beaucoup plus vite que la complexité de l'application considérée. Actuellement, elle est pratiquement inaccessible aux non-spécialistes, tandis que, faite par les spécialistes, elle entraîne des coûts qui croissent très vite, au point

qu'il est souvent moins onéreux de tout refaire à chaque fois.

Cette situation, qui sera illustrée plus loin sur un exemple

très simple, n'est évidemment pas satisfaisante.

La présente invention a notamment pour but d'apporter une

solution à ce problème.

Le dispositif de traitement de données proposé à cet effet est du type comprenant au moins un ordinateur, muni d'une unité "r 2764719 centrale avec un processeur, au moins un périphérique

utilisateur, et une mémoire, animés par un système d'exploi-

tation, ainsi qu'un système de gestion de bases de données, stocké dans cet ordinateur, et propre à coopérer avec le système d'exploitation pour permettre à l'utilisateur la création/saisie et/ou l'usage d'une base de données comprenant par exemple au moins une table de données, décomposable en

lignes et colonnes.

Par "système de gestion de bases de données", on entend ici couvrir tout système de fichiers informatiques permettant de gérer des tables, quel que soit le mode de stockage physique

de celles-ci.

L'invention inclut dans ce dispositif des moyens que l'on peut

appeler un outil de développement et d'assistance.

La fonction d'assistance est réalisée par le fait que, dans un moyen formant méta-dictionnaire autonome, on mémorise dynamiquement des informations choisies relatives à la structure de la base de données, typiquement les tables et les

liens entre tables, ou des informations équivalentes.

Il s'y ajoute une fonction d'analyse, qui détermine et mémorise (au moins temporairement) une représentation de groupes de colonnes dont les contenus sont liés (des colonnes liées sont des colonnes interdépendantes, ou, plus

généralement, dépendantes les unes des autres).

En pratique, la fonction d'analyse peut faire intervenir un outil statistique, propre à déterminer des interdépendances, et de préférence également des dépendances, entre des jeux de données, par dénombrement d'occurrences distinctes, et un

module (pilote) d'analyse capable de coopérer avec le méta-

dictionnaire et avec cet outil statistique, pour obtenir et

mémoriser ladite représentation de groupes de colonnes liées.

Avantageusement, l'outil statistique est fondé sur un moyen de comptage, lequel opère de préférence directement sur les colonnes de chaque table, d'une manière que l'on décrira plus loin. Le module d'analyse peut être agencé pour réitérer la présentation de sous-groupes d'au moins deux colonnes, jusqu'à trouver au moins un sous-groupe dont les colonnes soient liées, ou jusqu'à épuisement des possibilités. De préférence,

il réalise systématiquement la présentation de tous les sous-

groupes de colonnes différents possibles pour ladite table, de préférence aussi pour toutes les tables de la base de données. A partir de l'analyse, on peut procéder à une restructuration, afin d'établir pour l'utilisateur, au moins en création/saisie, une présentation (ou "vue") de la base de données qui tienne compte d'au moins un groupe de colonnes liées. Le module de re-structuration, avantageusement associé à un module d'interface utilisateur, commence par sélectionner une table de départ à traiter, des colonnes à traiter parmi au moins un groupe de colonnes liées, et une clé primaire de lien

pour ce groupe de colonnes.

La restructuration peut s'effectuer par construction d'une nouvelle table avec les données d'un groupe de colonnes liées,

ainsi qu'avec une clé de lien avec la table considérée.

Elle peut aussi s'effectuer par le fait qu'en mode saisie de données (formulaire), on restreint par défaut l'accès en modification à une partie seulement des colonnes d'un groupe de colonnes liées, les autres étant simplement accessibles en

lecture, voire inaccessibles.

Le moyen d'analyse et ses moyens de mémorisation peuvent opérer de différentes manières, notamment: à la demande et/ou sur satisfaction de certains critères (qui peuvent comprendre une analyse partielle), ou bien, à l'opposé, en permanence, de façon dynamique (éventuellement pour l'analyse partielle, seulement). L'invention peut aussi s'exprimer sous la forme d'un procédé appliqué à un ordinateur, ou bien sous la forme du produit

industriel nouveau que constitue l'outil de développement.

D'autres caractéristiques et avantages de l'invention

apparaîtront à l'examen de la description détaillée ci-après,

de ses annexes, et des dessins annexés, sur lesquels: - les figures 1 et 2 illustrent deux exemples d'architecture de systèmes de traitement d'information utilisables selon l'invention, - la figure 3 illustre la combinaison de moyens dans laquelle se manifeste l'invention, - la figure 4 illustre graphiquement un lien entre deux

tables,

- les figures 5 et 5A illustrent le contenu de deux tables, Composants et Produits, - la figure 6 illustre un rapport relatif aux deux tables des figures 5 et 5A, - la figure 7 illustre une table unique correspondant aux deux tables des figures 5 et 5A, et la figure 7A illustre la même table unique, mais avec des anomalies de saisie, - la figure 8 représente l'allure à l'écran d'un formulaire de saisie d'informations, relatives aux composants et aux produits, gérées sur une seule et même table,

- la figure 9 représente le résultat d'une requête d'interro-

gation à partir de la structure monotable de la figure 7, - la figure 10 est le schéma bloc détaillé des moyens d'analyse selon l'invention, - la figure 11 illustre la signification des graphismes de blocs utilisés ici dans les organigrammes, - la figure 12 (découpée en 12A et 12B) illustre l'organigramme de fonctionnement du constructeur de requêtes, - la figure 13 illustre l'organigramme de fonctionnement du module d'analyse, et la figure 13A illustre un organigramme complémentaire optionnel de fonctionnement du module d'analyse, - la figure 14 représente le résultat d'une requête de recherche de fausse dépendance à partir de la structure monotable de la figure 7A, - la figure 15 montre l'écran de sélection en vue de la réorganisation, - la figure 16 (découpée en 16A et 16B) illustre l'organigramme de fonctionnement des modules de sélection et de réorganisation, - la figure 17 représente les jointures de la structure avec trois tables Composants, Produits et Catégories, - la figure 18 représente le formulaire de saisie des composants après la réorganisation des informations relatives aux produits, et la figure 18A représente un formulaire simplifié de saisie des composants après la réorganisation des informations relatives aux produits,

- la figure 19 représente le résultat de la requête d'inter-

rogation après la réorganisation des informations relatives aux produits, et la figure 19A représente le résultat de la requête d'interrogation après une nouvelle réorganisation des informations relatives à la catégorie de produit, et - la figure 20 illustre l'organigramme de fonctionnement de

la variante de réorganisation virtuelle.

En fin de description:

- l'annexe I rappelle certaines notions connues, utiles à la

compréhension de la description,

- l'annexe II détaille sous forme de texte certains éléments de l'invention, et - l'annexe III est essentiellement constituée d'ordres SQL

intervenant dans un exemple de mise en oeuvre de l'invention.

Les dessins et annexes à la description sont, pour

l'essentiel, de caractère certain.

En conséquence, ils pourront non seulement servir à mieux

faire comprendre la description, mais aussi contribuer à la

définition de l'invention, le cas échéant.

Le système informatique de la Figure 1 comporte: - au moins un ordinateur 100, dit client, avec une unité centrale 110 (CPU, mémoire vive etc.), un écran 120, un clavier 130, une mémoire de masse 140 (disque dur par exemple), un périphérique de pointage 150 (souris par

exemple), une imprimante 160, et un périphérique 170 permet-

tant d'accéder à un réseau (local ou distant) ainsi que le logiciel correspondant, et - un ordinateur 200, dit serveur, comportant une unité centrale 210 (CPU, mémoire vive etc.), un écran 220, un clavier 230, un système de stockage de fichiers 240 (disque dur par exemple), éventuellement un système de pointage 250, un périphérique 260 permettant d'accéder au réseau (local ou

distant) ainsi que le logiciel correspondant.

La mémoire de masse (ou une autre mémoire) des deux ordina-

teurs loge un système d'exploitation. Pour le "client", on prendra par exemple un système d'exploitation à interface graphique, tel que Windows, OS/2 ou MOTIF par exemple (Marques déposées). Pour le serveur, l'interface graphique est moins utile dans certains cas, et l'on peut prendre Windows NT, OS/2, Unix, ou Novell par exemple (Marques déposées). Le système d'exploitation est lancé, de façon connue, en général

au démarrage de l'ordinateur.

Une base de données est installée sur le système de stockage du serveur. Chaque donnée ("item" de données) est matérialisée par une suite ordonnée d'empreintes (magnétiques, optiques, magnéto-optiques ou autres) sur le support de stockage (disque ou autre), accessible par exemple via un langage de type SQL, et à l'aide d'un moteur de base de données, installé sur le système de stockage. Du côté du ou des ordinateurs "client", il suffit de prévoir des programmes, enregistrés sur le système de stockage, permettant d'accéder à la base de données

via un langage approprié, par exemple le langage SQL.

La figure 2 illustre une configuration "monoposte" intégrant certains de ces éléments sur un seul ordinateur. Il n'y a alors qu'un périphérique de stockage (140+240), et le

périphérique permettant d'accéder au réseau (170) est inutile.

Bien que l'invention puisse s'appliquer à de nombreux systèmes de gestion de bases de données, ou s'appuyer sur un simple système de fichiers, on admettra dans un premier temps de la

description que le système informatique est muni d'un moteur

de bases de données relationnelles. Sur ce plan, il est fait mention à toutes fins utiles des ouvrages suivants, qui sont incorporés aux présentes à titre de référence: - "Les bases de données relationnelles", par André FLORY et Frédérique LAFOREST, édité chez ECONOMICA, 1996, notamment en son chapitre 2, pour ce qui concerne les fondements et les objectifs du modèle relationnel pour les bases de données, et en son chapitre 4 pour la théorie de la normalisation des bases de données relationnelles, - "Relational Databases and Knowledge Bases", par Georges GARDARIN et Patrick VALDURIEZ, édité chez ADDISON WESLEY, 1989, notamment en son chapitre 4, pour ce qui concerne les fondements et les objectifs du modèle relationnel pour les bases de données, et en son chapitre 5 pour la théorie de la normalisation des bases de données relationnelles, "Concevoir et développer avec Oracle et Case", par Hatem SMINE édité chez Eyrolles, 1994, notamment en ses chapitres 9 et 10, pour les techniques et outils de développement

d'applications s'articulant sur une base de données relation-

nelles, dans le cas exemplaire de la base de données Oracle

et de ses outils de développement.

- "Using the Oracle toolset", par Mike KROHN édité chez Addison-Wesley, 1993, notamment en ses chapitres 6, 7 et 11, pour les techniques et outils de développement d'applications s'articulant sur une base de données relationnelles, dans le cas exemplaire de la base de données Oracle et de ses outils

de développement.

La chaîne de traitement de l'information est illustrée sur la figure 3, avec: - en 410, une unité de traitement, par exemple l'une au moins des unités 110 et 210 (Figures 1 et/ou 2); - en 440, la mémoire de masse, par exemple l'un au moins des disques durs 140 et 240; - en 450, le système d'exploitation qui permet d'accéder aux informations physiques de la mémoire de masse, sous la forme d'un système de fichiers 460. On notera que les liens physiques sont en trait plein, tandis que les liens logiques sont en trait tireté. Le reste de la figure 3 dépend essentiellement du système de fichiers, par conséquent de la mémoire de masse 440 et de l'unité de traitement 410, à

travers le système d'exploitation 450.

- en 470, le moteur de la base de données, qui accède aux

données logiques 475.

- en 471, un "dictionnaire interne" (c'est le nom généralement donné, dans les bases de données relationnelles, aux informations sur la structure de la base de données, qui sont stockées de façon accessible au moteur de bases de données,

mais inaccessible en modification directe par l'usager -

lecture seulement).

- en 500, l'outil de développement (partie générale) qui accède à la base de données 475 (tables, formulaires, états, notamment). Comme on le verra plus loin, l'outil de développement 500 travaille avec un générateur de tables, formulaires et états 505, un méta-dictionnaire 510, un module d'analyse 530, un module de sélection 570, ainsi qu'un module de réorganisation

physique 580, et/ou un module de réorganisation virtuelle 590.

Les éléments fondamentaux d'une base de données sont les "tables". Chaque table est un ensemble de lignes; chaque ligne est organisée en une ou plusieurs colonnes; et chaque colonne correspond à un type de données. Chaque ligne comprend une et une seule valeur (la "donnée") pour chaque colonne de la table. Physiquement, le stockage des données peut correspondre à cette structure en table, ou bien être différent. Chaque table comprend généralement au moins une colonne qui ne contient que des valeurs uniques (est "unique" une valeur que l'on ne trouve qu'une seule fois dans la colonne de la table considérée), ou bien un moyen équivalent, numéro de ligne par exemple, agencé ou non en colonne de la table. Cette

colonne (ou l'une d'entre elles) est alors appelée clé pri-

maire. La valeur de la clé primaire permet de retrouver de

façon univoque la ligne correspondante, d'o son intérêt.

Toutes les colonnes qui ne contiennent que des valeurs uniques

peuvent servir de clé primaire.

Il est très fréquent qu'une table "de détails" doive référencer les informations d'une autre table ("maître"). A cet effet, on peut prévoir dans la table de détails une colonne dite "clé externe", qui contient la clé primaire de la table maître. Lors d'un accès conjoint aux données de deux tables, ces deux tables sont liées par une "jointure" (relation maître-détails): lors d'un accès à la table maître, on utilise la clé externe pour faire apparaître en même temps tous les détails correspondants contenus dans la table de détails; inversement, lors d'un accès à la table de détails, on peut utiliser la clé primaire de la table maître pour faire apparaitre en même temps des données complémentaires contenues dans la table maître. Cette notion de jointure ou lien entre tables est illustrée par le diagramme de la figure 4, avec une table de Clients, et une table de Factures, dans le cas d'une

gestion de facturation.

La présente description détaillée s'appuiera sur un autre

exemple concernant une chaîne de production d'ordinateurs (les produits), fabriqués par assemblage de composants. On verra qu'on peut élaborer deux tables "Produits" et "Composants",

ayant par exemple les contenus illustrés aux figures 5 et 5A.

Ici, la clé primaire de la table "Composants" est la colonne C_SN (le numéro de série du composant); c'est également la clé externe de la table "Produits". Par le biais de la liaison entre les deux tables, on peut déterminer, par exemple, que les composants dont les CSN sont "11", "13" et "14" font partie du produit dont le numéro de série du produit P_SN est "USi".

Le couple de tables Produits-Composants est du type maître-

détails car: - à un produit, il correspond de zéro à n composants (le cas zéro correspondrait à un produit dont les composants ne sont pas encore définis ou pas encore présents dans la table des composants), et

- a un composant, il correspond un et un seul produit.

Une telle jointure entre deux tables implique certaines contraintes d'intégrité quant aux valeurs de la clé primaire et de la clé externe correspondante: à chaque valeur de la clé externe, il doit correspondre une et une seule valeur de

la clé primaire.

L'ensemble des jointures pour lier deux tables entre elles est appelé chemin. Certaines structures de bases de données sont telles qu'il peut exister plusieurs chemins entre deux des tables qu'elles contiennent. Par exemple deux tables Clients et Fournisseurs peuvent être liées par un chemin passant par une table Commandes ou par un chemin passant par une table Pays. Inversement, il peut ne pas exister de chemin entre deux tables. Par exemple, deux tables "Production" et "Historique de production" bien qu'ayant la même structure et contenant des données de même essence n'ont aucun lien (au

sens de la structure des données) entre elles.

L'usage de jointures ou liens permet de réduire les redondances d'informations. Dans une base de données idéalement conçue, une information pertinente particulière n'est stockée qu'une seule fois (sauf les couples clé primaire - clé externe nécessaires aux liens). Cela offre un gain de place. En outre, les mises à jour sont facilitées. Ainsi (figures 5 et 5A), la modification du nom du produit (PNAME) ayant un numéro de série du produit PSN égal à USl n'implique la modification que d'une seule ligne (dans la table Produits)

alors qu'il est constitué de trois composants.

L'accès aux données d'une table s'effectue par un formulaire affiché à l'écran. Un formulaire est composé de champs, dont chacun correspond à une colonne d'une table. Il permet d'insérer des nouvelles lignes dans la table (création), de modifier les lignes existantes, de supprimer des lignes. Un formulaire qui permet d'accéder à plusieurs tables doit alors respecter les contraintes d'intégrité de la structure concernée. Un rapport (voir exemple en figure 6) présente des colonnes choisies d'une table, pour des lignes sélectionnées par une requête (parfois pour toute la table). Le résultat est affiché à l'écran et/ou imprimé. Un rapport peut interroger et présenter les données de plusieurs tables, mais il doit alors connaître la structure correspondante (clés externes, clés primaires et jointures). En plus des rapports, il est possible

de définir des graphiques affichés à l'écran et/ou imprimés.

Les rapports et les graphiques sont communément appelés états.

Les formulaires et les états sont communément appelés programmes. Et les programmes accèdent aux données via des

requêtes.

Les états sont accompagnés de requêtes d'interrogation.

Suivant la manière dont sont conçus les outils générateurs d'états, on peut considérer que la requête d'interrogation est incluse dans l'état et/ou séparée de l'état. On connaît aussi les requêtes d'insertion, les requêtes de mise à jour et les requêtes de suppression, qui sont en principe réservées aux formulaires.

Dans cette description détaillée, on utilisera le langage de

requêtes dit SQL (Structured Query Langage). Le langage SQL a fait l'objet de plusieurs normalisations, dont la dernière est la norme SQL- 92 ANSI/ISO. Les mots-clés des ordres SQL sont présumés compris du lecteur. Le cas échéant, ils pourront être trouvés dans la norme susvisée. Pour une chaîne de caractères, on utilise comme délimiteur soit les guillemets

("), soit l'apostrophe ('). L'Annexe I de la description

illustre les principales autres notions dont il faut disposer

pour comprendre la présente description, à savoir:

- en A-11, les colonnes calculées, - en A-12, les conditions restrictives, - en A-13, le principe général d'une requête (ordre SELECT de SQL).

Le langage SQL permet d'accéder aux bases de données rela-

tionnelles en respectant une indépendance entre la façon dont les données sont physiquement stockées et la façon de manipuler logiquement ces données. Par sa puissance, le langage SQL permet d'exprimer simplement des traitements complexes, incluant notamment des boucles imbriquées (par le biais de jointures): voir les exemples A-13-1 et A-13- 2. Mais le recours au langage SQL n'est nullement limitatif, et la présente invention peut tout aussi bien s'appliquer à l'aide d'un langage de plus bas niveau, qui attaquerait directement le système de fichiers du périphérique de stockage, par

exemple.

De façon générale, une application regroupe un ensemble de programmes s'articulant autour d'une structure donnée (tables et contraintes d'intégrité). Un menu permet de sélectionner, au sein d'une application, le programme avec lequel on veut travailler. Le développement d'applications s'articulant autour de moteurs de base de données a été plus ou moins automatisé par les outils de développement. Un outil de développement est un logiciel qui offre au programmeur une bibliothèque de générateurs de programmes. Ces générateurs de programmes

permettent de diminuer notablement les temps de développe-

ment: lors de l'utilisation d'un générateur de programmes, le programmeur saisit des paramètres plutôt que d'écrire du code source; ces paramètres sont ensuite interprétés pour engendrer un programme en code source que le programmeur peut modifier ou enrichir manuellement, dans la mesure o il

maîtrise le code source.

Le développement d'applications s'articulant autour de moteurs de base de données suit en principe la démarche méthodologique suivante: le programmeur effectue une analyse

des besoins. Il peut utiliser pour cela une méthode de concep-

tion (Merise par exemple) dont l'ensemble ordonné des règles opératoires le guide en systématisant le processus de réflexion et en évitant les erreurs de conception. L'analyse permet de définir un "modèle de données" qui exprime de façon pertinente la sémantique des données. (Un modèle de données

peut être représenté graphiquement par un diagramme Entité-

Relation.). La phase d'analyse des besoins demande au programmeur une bonne connaissance de l'algèbre relationnelle

et de la normalisation de la structure d'une base de données.

Avec un outil de développement élémentaire, la structure physique des données doit être implantée dans la base de données à partir du "modèle de données". Après cela, l'outil de développement permet de définir des formulaires et des états s'articulant sur la structure (en s'appuyant sur le dictionnaire interne) ainsi que des menus. L'utilisateur peut

alors enrichir ces formulaires, états et menus.

Avec un outil de développement évolué (plus complexe), la structure des données est saisie et stockée dans un autre dictionnaire, propre à l'outil de développement. Les données que l'on saisit à ce stade, et celles des traitements correspondants s'appellent "méta- données". Cet autre dictionnaire, ou "méta-dictionnaire" (510, figure 3), est distinct du dictionnaire interne. Il s'articule sur un système de fichiers indépendants ou sur des tables de la base de données elle-même (accessibles en modification, seulement via

l'outil de développement).

Le méta-dictionnaire fait l'objet d'éventuels contrôles de cohérence par l'outil de développement et peut même intégrer certaines règles opératoires d'une méthode d'analyse (Outils du type CASE). A partir de ce méta-dictionnaire, le générateur 505 (figure 3) de l'outil de développement prend en charge les tâches suivantes: - la structure physique de la base de données est créée, à l'aide du méta-dictionnaire (le dictionnaire interne est mis à jour en conséquence); - les programmes et les menus (éventuels) sont générés par

l'outil de développement.

- le générateur de rapports compose plusieurs requêtes d'interrogation (généralement une par ensemble de tables), et

construit un rapport-type pour chaque requête.

L'utilisateur peut alors les enrichir.

Ainsi, la complexité de l'accès à la base de données est plus ou moins masquée à l'utilisateur, en fonction de la qualité

(niveau de complexité) de l'outil de développement.

Tout ceci permet d'exploiter une base de données. Une fois l'exploitation démarrée, il peut être nécessaire de modifier le modèle de données et donc la structure de données, et ce pour différentes raisons, par exemple: - le besoin applicatif peut avoir évolué (évolution du métier

par exemple),

- le besoin initial était mal défini (cahier des charges

inadéquat), ou traité par un non initié.

Une modification ponctuelle de la structure des données (ajout d'une colonne dans une table par exemple) est diversement bien acceptée par les outils de développement: - s'agissant d'un outil "rustique", l'utilisateur doit modifier manuellement la structure des données, ainsi que les

requêtes dans les formulaires et états concernés.

- Par contre, avec un outil de haute performance, plus complexe, il suffit de mettre à jour le méta-dictionnaire de

l'outil de développement, et cela est répercuté automa-

tiquement sur la structure physique des données ainsi que sur

les requêtes des formulaires et états.

Une modification plus conséquente de la structure des données (ajout de tables, séparation d'une table en plusieurs tables par exemple) est très lourde, si l'on désire conserver les données déjà saisies. Et l'utilisateur va se heurter à plusieurs difficultés: a) la nouvelle structure, même si elle respecte l'intégrité relationnelle, n'est peutêtre plus en adéquation avec les besoins de l'application. Les données peuvent devenir inexploitables. b) la syntaxe des langages (procéduraux ou non) d'accès aux données est complexe et beaucoup de modifications non prises en compte par l'outil de développement sont à faire manuellement. c) les modifications à effectuer aux requêtes des formulaires

et états sont complexes. d) la modification de la structure est elle-même délicate et complexe si

l'on désire conserver les données existantes (un exemple très simple: ayant une colonne numéro d'article, on veut faire passer celle-ci du type numérique au type caractère). La génération par l'outil de développement d'une nouvelle version (basée sur la nouvelle structure) redonne les versions de départ des formulaires, états et menus. On perd donc tout l'enrichissement apporté par la suite à ceux-ci. Dans tous les cas, il n'est pas facile, sous l'action d'un outil de développement, de modifier physiquement la structure de données, et de modifier l'application pour satisfaire un

besoin non envisagé aux origines.

Ce qui précède montre l'importance du problème posé. On

procédera maintenant à la description de l'invention, qui se

propose de résoudre ce problème technique d'une manière

élégante et fiable.

L'invention permet de partir dans tous les cas d'une structure monotable. Elle permet ensuite à l'utilisateur lui-même de modifier la structure des données, une fois la production démarrée, en fonction de ses nouveaux besoins. Elle ne nécessite en effet aucune connaissance particulière de la technique d'accès aux données (langage SQL par exemple), ni des principes régissant les structures de données relationnelles. Elle permet ainsi des économies de temps d'analyse, de temps de développement et de temps de modification ultérieure. Elle est adaptée à toutes les bases de données relationnelles du marché, de même qu'à d'autres

systèmes de gestion de données.

L'invention fournit un moyen ou outil de développement perfectionné, que l'on peut aussi considérer comme un

interface d'environnement utilisateur.

Cet outil s'appuie sur un méta-dictionnaire particulier 510 (figure 10), dont le contenu minimal (pour le mode de

réalisation préférentiel) est donné en A-21.

Le méta-dictionnaire répète certaines informations déjà contenues dans le dictionnaire interne, comme le nom et le type de chaque colonne de chaque table. Il en contient beaucoup plus. Ce méta-dictionnaire 510 est entretenu par un automate de mémorisation, qui surveille tout événement relatif aux conditions données en A-21. Cette surveillance peut être limitée aux moments o l'outil de développement fonctionne (dans la mesure o il a l'exclusivité des modifications desdites conditions). Elle peut être plus large. Elle est de

préférence permanente.

L'invention s'appuie aussi sur un constructeur de requêtes 520 (figure 10). Les requêtes construites obéissent à un format général bien défini, nommé ici forme canonique, dont la version actuellement préférée est indiquée en A-22, tandis que des exemples de requêtes canoniques sont donnés en A-23. La manière dont le constructeur de requêtes travaille, en liaison avec le méta-dictionnaire, est illustrée sur la figure 12. On trouvera sur la figure 11 la signification des

graphismes de blocs utilisés dans les organigrammes.

Après le début 900, l'étape 910 présente à l'usager différentes possibilités (disponibles) de sélection de colonnes, simples et calculées, ainsi que de fonctions ensemblistes. Par fonction ensembliste, on entend une fonction portant sur plusieurs lignes, comme SOMME(), COMPTAGE(), MOYENNE(), par exemple. En 911, l'usager peut construire des expressions à partir des colonnes, et/ou fonctions ensemblistes. A partir de là, il peut: - en 912, créer et lier des conditions restrictives,

- en 913, définir un ou des critères de tri (ordonnés).

Ces étapes 910 à 913 constituent l'initialisation du constructeur de requêtes. Elles sont décrites comme faites par l'usager. Mais le constructeur de requêtes peut tout aussi bien opérer automatiquement, en recevant cette initialisation à son lancement, sous la forme de paramètres, qui définissent respectivement les éléments saisis en 911, 912, 913. Il est important de noter que ce concepteur de requêtes peut mémoriser, sous forme de chaines de caractères, la définition

des requêtes qu'il a permis d'écrire.

L'étape 920 détermine l'ensemble des tables auxquelles appartiennent les colonnes et expressions définies en 911 à 913. Ceci est effectué sélectivement pour chacune des expressions intervenant dans la requête canonique A-22. Si une colonne appartient à deux tables, elle est la clé primaire de l'une et une clé externe de l'autre. Le générateur de requêtes peut associer cette colonne à l'une ou l'autre des deux tables (le résultat de la requête sera le même). On prend de

préférence la table o la colonne est clé primaire.

Les étapes 921 à 925 et 929 déterminent le chemin reliant ces tables (s'il y en a plusieurs). Eventuellement, l'étape 923 rajoute une ou des tables pour qu'un tel chemin existe, en partant du méta-dictionnaire. On notera cependant que, dès lors que la mise en oeuvre de l'invention part d'une table unique, toutes les tables créées ensuite sont forcément

reliées par un et un seul chemin.

En 930 et 931, on construit donc les deux premières lignes de la requête A-22 (et la troisième ligne optionnelle, si les lignes suivantes appellent des colonnes dont les tables

n'apparaissent pas dans la seconde ligne).

A l'étape 940, on traite de manière similaire le "suivi" du chemin (éventuel), et la satisfaction des conditions restrictives. Ceci sert à décider (941) d'écrire la clause WHERE, avec une liste de jointures (943) et/ou une liste de

conditions restrictives (949).

Ensuite, la clause GROUP BY est écrite en 961, si le test 960 l'indique: existence de fonctions ensemblistes dans les

expressions et/ou conditions restrictives.

La clause ORDER BY est écrite en 971, si le test 970 l'indique (les critères de tri peuvent comporter des fonctions

ensemblistes).

La clause HAVING est écrite en 981, si le test 980 l'indique: existence de fonctions ensemblistes dans les conditions restrictives.

On observera que ce constructeur de requêtes se charge lui-

même de tous les contrôles. Il suffit de lui donner, par saisie, ou bien par passation de paramètres, la liste

sélective des expressions à traiter.

A partir de la définition du formulaire stockée dans le méta-

dictionnaire, l'invention prévoit aussi de créer

automatiquement (dynamiquement) un ou des formulaires.

Ce formulaire est donc adapté à la structure des données. Il permet la consultation, l'insertion, la modification et la suppression de lignes dans la ou les tables concernées. Il respecte l'intégrité des données en imposant les contraintes suivantes: - la valeur d'une colonne doit toujours être en adéquation avec son type (par exemple, ce qui est saisi dans une colonne

de type date doit être une donnée reconnue comme une date).

- une colonne clé primaire ne doit comporter que des valeurs uniques. une colonne clé externe doit avoir un ensemble de valeurs incluses dans l'ensemble des valeurs de la clé primaire

correspondante.

Toujours à partir du méta-dictionnaire, l'invention prévoit la génération automatique de rapports et de graphiques, par

le module 505.

Un rapport est établi à partir d'une requête d'interrogation.

Il est possible dans un rapport de définir: - des formats de présentation ou "enrichissement" (comme: gras, italique, gros caractères), - des calculs de groupe effectués sur les données de la table (comme: totaux, dénombrement), - des ruptures qui conditionnent la remise à zéro des calculs de groupe. Ces ruptures sont organisées en niveaux. Le niveau

le plus haut dit niveau zéro est celui du rapport tout entier.

Le niveau 1 correspond à la première rupture (la plus générale) et le dernier niveau correspond aux informations de

la rupture de dernier rang.

- des conditions restrictives ou "filtres", comme: nom du

produit (PNAME) = "COMPi", coût (COST) > 1500.

- certains critères de tri.

Selon un aspect de l'invention, les ruptures sont proposées en fonction de la structure de l'application: soient une

colonne COL2 qui appartient à un ensemble de tables {TAB21...

TAB2p}, et la colonne précédente COL1 qui appartient un ensemble de tables {TAB11,... TABln}; ces deux colonnes sont présentées dans le même niveau de rupture, si, pour toute valeur de i, de 1 à n, et pour toute valeur de j, de 1 à p, le chemin pour aller de TABli à TAB2j ne comporte aucune jointure de sens maître-détails. Ces ruptures correspondent à la décomposition en niveaux de la structure et proposent donc à l'utilisateur une présentation par défaut qui est parlante. L'utilisateur peut cependant les modifier à son gré et ne définir certains calculs de groupe que pour certains niveaux de rupture de même qu'insérer ou supprimer des ruptures. La figure 6 illustre un rapport présentant le nom du produit, le numéro série du composant, le coût avec: - comme condition restrictive: le nom du produit (P_NAME) doit être différent de "COMPi", - une rupture sur le nom du produit, - un total des coûts (COST) des composants,

- un comptage du nombre de composants.

Un graphique correspond à une interrogation et à une présentation graphique de valeurs de colonnes pour certaines lignes. De façon générale, un graphique est déterminé par des paramètres comme: - le type de présentation (histogramme, camembert...) - le format de présentation (couleur...) - un ou des critères de tri - des calculs (somme...) Selon un autre aspect de l'invention, un graphique est établi à partir d'une requête d'interrogation comportant de zéro à plusieurs colonnes de type libellé et une ou plusieurs colonnes de type numérique. Il comprend: - Le format de la colonne de type libellé. - Le format du graphique. Certains formats de graphique n'acceptent qu'un nombre précis de colonnes de type libellé et de colonnes de type numérique. Par exemple: Le camembert ne supporte qu'une colonne de type libellé

et qu'une colonne de type numérique.

Le graphique en XY (communément appelé courbe) ne supporte pas de colonne de type libellé et ne supporte que deux colonnes de type numérique (éventuellement des

graphiques tri-dimensionnels).

Si dans la requête d'interrogation, il y a plus de colonnes de type libellé que ne le supporte le format du graphique, le module 505 génère autant de graphiques éclatés que nécessaire

en utilisant un mécanisme similaire à celui des ruptures.

Exemple: soit une requête d'interrogation qui renvoie le

chiffre d'affaires (égal à la somme des montants des comman-

des) par produit et par région (le chemin entre les tables

Produits et Régions comporte une jointure de sens maître-

détails). Si le format du graphique choisi est le camembert, on va générer un camembert produit / chiffre d'affaires pour chaque région, et un camembert produit / chiffre d'affaires

pour toutes les régions confondues.

A l'aide du méta-dictionnaire, l'invention permet d'assurer que la relation entre la requête et l'état (rapport ou

graphique) demeure cohérente après toute réorganisation.

L'exemple des figures 5 et 5A donne une version déjà aménagée de la structure de tables. En réalité, s'il cherche à

développer une base de données pour ce même exemple, un non-

initié va généralement tout mettre dans une seule table. Avec l'invention, l'utilisateur peut toujours commencer avec une seule table, que l'on dénommera ici "Composants_et_Produits" (Figure 7). Pour ce faire, il définit simplement le nom et le type des données qu'il veut saisir. L'outil de développement a mis le méta-dictionnaire à jour, créé une structure de données monotable en accord avec le nom et le type des colonnes indiqués par l'utilisateur, et créé un formulaire par

défaut permettant d'accéder à la table, et des états.

Ainsi, l'utilisateur peut démarrer quasi instantanément, sans devoir réfléchir à la structure d'interaction entre ses données: il va, de suite, saisir des données via le formulaire, et éditer des états. La figure 8 représente le formulaire de saisie des informations dans la table "ComposantsetProduits". La figure 9 représente le résultat d'une requête d'interrogation à partir de la structure

monotable (sans filtrage).

Même si elle permet de commencer avec une seule table, l'invention peut aussi s'appliquer au cas o un développeur expérimenté va faire des choix initiaux de structure des tables qui sont guidés par son analyse formelle et des considérations pratiques, dès lors que ces choix doivent être reconsidérés au cours de l'exploitation ultérieure (avec de

plus en plus de données).

On note en effet que les données d'une table ayant aussi peu

de lignes que celle de la figure 7 sont déjà redondantes.

L'observateur averti remarque immédiatement des dépendances

entre colonnes: CATEG dépend de C_SN, PSN, P_NAME.

Mais, au niveau des données, CATEG semble aussi dépendre de C_ID et de C_DESC, d'après les critères précités; en effet: - les composants SCR17, P166, HD1.2 et SCR15 ne rentrent que dans la fabrication de produits de la catégorie USER, et - les composants SCR14, P200 et HD2 ne rentrent que dans la

* fabrication de produits de la catégorie SERVER.

Cette dépendance (fausse, car illogique) est due au fait que l'échantillon de données est trop étroit pour être représentatif. Si on fabrique par exemple un produit de catégorie USER avec un disque dur de référence HD2, la dépendance disparaîtra. De façon générale, la structure courante de la base de données ne convient plus lorsque certaines données sont redondantes au sein de la table. Autrement dit l'utilisateur est confronté à des anomalies car le modèle de données ne respecte pas ou

plus les différentes formes normales du modèle relationnel.

Dans le cas de la figure 7, l'utilisateur pourrait se trouver confronté aux anomalies suivantes: - Suppression: la suppression de l'unique composant d'un

produit supprime aussi les informations relatives au produit.

- Mise à jour: la mise à jour des informations d'un produit (son nom par exemple) doit se faire sur toutes les lignes de la table correspondant à ses composants. Il y a donc autant de modification à faire que le produits est constitué de composants. - Insertion: on ne peut pas créer de produit sans lui

affecter immédiatement au moins un composant.

Devant la nécessité de réorganiser la structure de la base de données, l'utilisateur serait normalement astreint à opérer à la main. La présente invention lui fournit à cet effet des moyens que l'on peut décomposer en trois parties (figure 3): i) l'analyse des données (530), ii) la sélection par l'utilisateur (570) des colonnes d'une table qui vont être isolées; durant cette phase,

l'utilisateur est encadré par des contrôles de cohérences.

iii) l'exécution (580) de la réorganisation de la structure

des données.

Les phases ii) et surtout iii) sont optionnelles. On verra en effet qu'il est également possible, en variante, ou en complément, de mettre en oeuvre l'invention sans réorganiser

physiquement la base de données (590).

L'aspect de l'invention considéré actuellement comme essentiel est l'analyse. Elle s'appuie ici sur le méta-dictionnaire

donné en A-21 (510, figure 10), ou sur un moyen équivalent.

Elle s'appuie aussi sur un outil statistique (520, figure 10), qui, dans une forme de réalisation, consiste en un jeu de requêtes SQL données en Annexe III, et adaptées à différentes opérations de dénombrement systématique, en fonction de la structure courante de la base de données, telle qu'elle figure dans le méta-dictionnaire. Ces dénombrements ne portent pour la plupart que sur des "valeurs distinctes". Les requêtes SQL

interrogent directement la ou les tables concernées.

La phase d'analyse, comprend tout ou partie des opérations que l'on va maintenant décrire, en référence à l'annexe III. Elle

est pilotée par un module 530 (figure 10).

De façon générale, les colonnes "courantes" notées Ci et Cj

dans la description sont notées COL1 et COL2 dans l'annexe

III, conformément à la pratique habituelle des hommes du métier. Le procédé comprend d'abord une analyse (de préférence exhaustive) des répétitions des valeurs des colonnes des tables de données. On décrira cette analyse, en référence à

la figure 13, et à l'annexe III.

A partir du début (1000), on détermine les tables de la base de données, ou mieux celles utilisées dans l'application

(1010).

Pour chaque table, l'analyse consiste à déterminer: - en 1012, le nombre de lignes, N. En langage SQL, le nombre de lignes d'une table (étape 1012) s'obtient par la requête A-31-1, o TAB1 est le nom

de la table considérée.

- en 1020, les noms des colonnes de la table, Cela s'obtient par lecture du méta-dictionnaire (en

variante, du dictionnaire interne).

- Pour chaque colonne Ci, le nombre de valeurs distinctes Ni,

en 1024-1026.

Le nombre de valeurs distinctes d'une colonne d'une table (étape 1024) s'obtient par la requête SQL A-31-2, o COL1

est le nom de la colonne.

- puis déterminer et parcourir les couples de deux colonnes différentes que l'on peut former pour la table (1030) Cela s'obtient par lecture du méta-dictionnaire (en variante, du dictionnaire interne), sous la forme d'une

boucle simple à concevoir.

- Pour chaque couple de colonnes (Ci, Cj), faire des opérations (détaillées plus bas) permettant de calculer:

le rapport de dépendance entre elles.

20. le nombre de couples de valeurs qui bloquent la dépendance. - Pour chaque groupe de colonnes d'une table (Ci, Cj... Cn), les éventuelles clés candidates (de jointure ou lien) pour le groupe. On revient maintenant sur le calcul du rapport de dépendance de deux colonnes d'une même table. Soient Ni et Nj le nombre respectif de valeurs distinctes des deux colonnes Ci et Cj (calculés en 1024-1026). En 1034, on obtient P, le nombre

de couples distincts de valeurs de Ci et Cj, par la requête A-

31-3, o COL1 et COL2 sont les noms des colonnes Ci et Cj, tandis que: "xyz" est une chaine de caractère inexistante dans la colonne COL1. Le mieux est de prendre une chaîne de caractères a priori invraisemblable. L'absence de la chaine "xyz" dans COL1 peut être vérifiée par la réponse zéro à la

requête A-31-4.

I est le symbole de concaténation des valeurs de deux

colonnes, supporté par le moteur de base de données.

Selon la valeur de P par rapport à Ni et Nj, les situations possibles sont: - cas 1042, avec P > Max(Ni, Nj)

il n'y a pas de dépendance entre les deux colonnes (1043).

Ci et Cj sont dites indépendantes. On calculera alors éventuellement le nombre de couples de valeurs qui bloquent

la dépendance (cas d'une presque dépendance).

- cas 1046+1047, avec P = Ni et P > Nj

alors Ci détermine Cj. La colonne Ci est dite mère de Cj.

La colonne Cj est dite fille de Ci.

- cas 1046+1049, avec P = Nj et P > Ni,

alors Cj détermine Ci. La colonne Cj est dite mère de Ci.

La colonne Ci est dite fille de Cj.

- cas 1044+1045, avec P = Ni et P = Nj alors Ci et Cj sont dites équivalentes du point de vue des dépendances, ou interdépendantes. Ci et Cj sont dites

soeurs.

- le cas P < Min (Ni, Nj) est impossible.

Les étapes 1050 et 1052 assurent respectivement le bouclage sur toutes les paires de colonnes et toutes les tables jusqu'à

la Fin 1059.

Les requêtes mentionnées peuvent être élaborées à l'aide du constructeur de requêtes SQL déjà cité (A-22, et 520, figure ). Cependant, il sera souvent plus simple de les préparer individuellement à l'avance, sous la forme de chaînes de caractères, dont certains éléments sont variables. Dans les requêtes A-31, les éléments variables sont TAB1, COL1, "xyz" (ou, ce qui est équivalent 'xyz'), et COL2. En liaison avec le métadictionnaire, l'étape 1024 (par exemple) de la figure 13, va recomposer la requête A-31-2, en y remplaçant les noms COL1 et TAB1 par le nom de la colonne et celui de la table, respectivement. L'écriture de programmes susceptibles d'implémenter les boucles décrites sur la figure 13 est considérée comme accessible à l'homme du métier à partir de la présente

description, et d'un langage procédural comme le langage C et

ses variantes (C++ par exemple), ou encore SMALLTALK. On examine maintenant le cas d'une "presque dépendance", en référence à la figure 13A. Il s'agit d'un couple de colonnes COL1, COL2 d'une même table, pour lequel chaque valeur de COL1 permet de déterminer de façon univoque la valeur de COL2 "à

quelques exceptions près". Un exemple est donné en A-24.

De façon générale, le nombre de couples de valeurs, B, qui bloquent la dépendance mère-fille entre deux colonnes Ci et Cj s'obtient (étape 1210, figure 13A) par la requête A-32-1, o a et b sont des alias définis sur la table TAB1, et les autres variables sont définies comme précédemment. (un alias de table permet d'accéder à celle-ci sous un autre nom que le sien; plusieurs alias sur la même table permettent d'accéder

à celle-ci de deux manières indépendantes).

Si B est faible, il pourra être intéressant de forcer la dépendance; l'utilisateur devra alors normaliser les deux colonnes. Les colonnes Ci et Cj sont dites respectivement pseudo-mère et pseudo-fille. On parle aussi de "pseudo-soeurs" dans le cas particulier o chacune des deux colonnes joue vis

à vis de l'autre le rôle de pseudo-mère et de pseudo-fille.

Cette normalisation de deux colonnes pour forcer la dépendance

sera maintenant décrite.

Il faut d'abord identifier les couples de valeurs, qui bloquent la dépendance mère-fille entre deux colonnes Ci et Cj. Ceci est fait à l'étape 1230 (figure 13A), à laquelle correspond la requête A-32-2. Cela permet d'apprécier, pour une valeur de la colonne pseudo-mère, les fréquences des

différentes valeurs de la colonne pseudo-fille correspondante.

La requête A-32-2 comprend un ordre SELECT imbriqué, qui compte le nombre d'occurrences (supérieur à 1) du couple de valeurs au sein de la table. On recherche d'abord les valeurs de COL1 qui bloquent la dépendance. Il s'agit des valeurs de COL1 telles que le nombre de valeurs distinctes de

COLll 'xyz'lICOL2 soit supérieur à 1.

La requête A-32-2 construit là-dessus un ordre SELECT principal, qui renvoie les couples de valeurs trouvés, donnés en figure 14, pour l'exemple considéré. Pour chaque élément de l'ensemble des valeurs de COL1 qui bloquent la dépendance (selon la requête imbriquée), on recherche maintenant les valeurs de COL2 correspondantes ainsi que leur fréquence. De même pour la valeur NULL de COL1 (NULL est le cas o l'on n'a

rien saisi).

On notera qu'il est possible de passer directement à l'étape

1230, sans faire le comptage préliminaire de l'étape 1210.

Le forçage proprement dit (étape 1250, figure 13A) s'effectue par l'ordre SQL donné en A-32-3, o: - TAB1 est le nom de la table, - COL1 et COL2 sont deux colonnes de la table dont on cherche à forcer la dépendance dans le sens o COL1 déterminera COL2, - VALEUR2 est la nouvelle valeur attribuée à COL2, - VALEUR1 est la valeur de COL1 pour les lignes à modifier, - VALEUR2_1, VALEURS2_2,... VALEURS2_n sont les valeurs de

COL2 pour les lignes à modifier.

Toutefois, en cas de valeurs non saisies en COL1, le forçage

s'effectue par l'ordre SQL donné en A-32-4.

Le forçage peut comporter aussi l'ordre SQL donné en A-32-5, o: - TAB1 est le nom de la table, - COL1 et COL2 sont deux colonnes de la table dont on cherche à forcer la dépendance dans le sens o COL1 déterminera COL2, VALEUR1B est la nouvelle valeur attribuée à COL1, - VALEUR1 est la valeur de COL1 pour les lignes à modifier, - VALEUR2_1, VALEURS2_2,... VALEURS2_n sont les valeurs de

COL2 pour les lignes à modifier.

On reprend maintenant la structure monotable, mais selon la figure 7A (avec un contenu un peu différent, pour l'illustration). La relation de dépendance entre le numéro de produit et le nom du produit peut être cassée (erreur de saisie par exemple). Le résultat de la requête permettant de déterminer les couples qui bloquent la dépendance pourrait être (figure 14), exprimé en clair: "Il y a deux composants pour le produit COMP1-USER COMPUTER et un composant pour le produit COMP1-USER COMPUTER BIS; un même numéro de produit a été utilisé pour deux produits différents." Pour forcer la dépendance, il faut au choix:

Attribuer un autre numéro de produit à l'un des deux (A-

32-5). Dans ce cas l'analyse des fréquences indique que c'est plus probablement la ligne USER COMPUTER BIS qui n'a

pas le bon numéro de produit.

Remplacer "USER COMPUTER BIS" par "USER COMPUTER" (A-32-

3). De plus, il faut saisir un numéro de produit pour le

produit de numéro de série SRV1 (A-32-4).

Les éventuelles clés candidates pour un groupe de colonnes doivent respecter la contrainte: Chaque clé candidate doit être, vis à vis de toutes les autres colonnes du groupe, soit mère, soit soeur. Pour qu'une colonne devienne clé candidate d'un groupe de colonnes, il est nécessaire de forcer la dépendance avec toutes les pseudo-filles du groupe (en cas de presque-dépendance). De préférence, on exprime et mémorise le résultat de l'analyse sous la forme d'un groupe de colonnes, comprenant: - le sous-groupe des clés candidates, et - les sous-groupes de leurs colonnes-filles, rangés par niveau de parenté (filles des filles, et ainsi de suite), d'une

manière arborescente.

Les contrôles de cohérence se font conformément aux principes régissant les structures relationnelles; ils dépendent surtout du résultat de l'analyse des données déjà saisies, niveaux de parenté notamment. Ils garantissent l'utilisateur contre des données inexploitables et lui permettent de s'affranchir de toute connaissance et compréhension de l'accès aux données, et des principes régissant les structures de données

(relationnelles par exemple).

Le résultat de l'analyse permet de: - suggérer quelles colonnes vont pouvoir être isolées d'une

table,

- déterminer les éventuelles clés candidates d'un groupe de colonnes, permettre de bénéficier d'un mode de saisie assisté

utilisant les dépendances (éventuellement virtuel).

L'une des mises en oeuvre de l'invention consiste alors à

réorganiser physiquement la structure des tables.

Elémentairement, cette fonction de réorganisation de la structure consiste à éclater une table en deux tables, qui

seront en relation maître-détails.

Bien que l'on puisse procéder autrement, il est aujourd'hui jugé préférable de laisser à l'utilisateur le choix parmi les

différentes possibilités éventuellement issues de l'analyse.

Ce choix va porter à chaque fois sur une table (TAB1), et sur un groupe de colonnes Sl, S2...Sn de cette table (qui va former la nouvelle table, tandis qu'on note Ri, R2... Rp les colonnes qui vont rester dans la table TAB1), en respectant les contraintes suivantes: - le groupe de colonnes sélectionné Sl, S2...Sn ne doit pas inclure la clé primaire de la table (de départ), - les dépendances entre les colonnes sélectionnées permettent

de déterminer les clés candidates; l'utilisateur en sélec-

tionne éventuellement une.

Cette phase s'effectue par exemple à l'aide d'une interface utilisateur àfenêtres comme celle de la figure 15, avec une fenêtre 91 de sélection des tables (ici une seule), puis fenêtre 95 de sélection des colonnes à isoler de la table choisie, puis sélection en 96 d'une clé candidate pour la nouvelle table (en option). On saisit en 92 le nom de cette nouvelle table, qui sera noté TAB2 ci-après. Les phases de sélectionréorganisation sont illustrées sous forme d'étapes à la figure 16, dans le cas d'une interaction avec

l'utilisateur, avec l'écran de la figure 15.

A partir du début 2000, l'étape 2010 utilise le méta-

dictionnaire pour connaître la liste des tables utilisées par l'application, liste qui est affichée en 2012. L'utilisateur

choisit en 2014 la table TAB1 à réorganiser. A partir du méta-

dictionnaire, le système fournit en 2020 la liste des colonnes de TAB1. En 2022, ces colonnes sont affichées, à l'exception de la clé primaire de TAB1, et l'usager choisit en 2030 les

colonnes Sj à isoler.

Ces choix s'effectuent par une boucle sur les étapes 2032 à 2036. A chaque sélection d'une colonne, on détermine si cette colonne peut servir de clé candidate (2034), en mémorisant

cette information.

Ensuite, on passe à la réorganisation proprement dite, qui est un peu différente, suivant que l'utilisateur a, ou n'a pas, choisi une clé candidate. On admet que les formulaires définis au départ attaquaient tous les champs de la table unique dont

on est parti.

i) Si, aux étapes 2042 à 2046, l'utilisateur a sélectionné une clé candidate, que l'on suppose être (Sl), la réorganisation proprement dite s'effectue par les étapes 2048, 2049 et 2060, conformément aux ordres SQL A-33; La création de la table maître se fait en exécutant l'ordre A- 33-1. Cet ordre SQL crée une table nommée TAB2, avec le résultat d'un ordre SELECT, imbriqué dans l'ordre

CREATE.

La modification de la table d'origine TAB1 se fait par l'enchaînement des 3 ordres donnés en A-33-2. On crée une table temporaire TEMPO avec les colonnes non transférées, plus la clé primaire choisie Sl (TEMPO est un nom disponible au niveau de la base de données: il n'y a pas d'autre table ou vue ayant ce nom). Ensuite on efface TAB1,

et l'on renomme TEMPO en TAB1.

ii) sinon, dans le deuxième cas, o l'utilisateur n'a pas sélectionné de clé candidate (et il n'y a peut-être aucune clé candidate pour le groupe de colonnes sélectionnées), la réorganisation proprement dite s'effectue par les étapes 2056,

2058 et 2060, conformément aux ordres A-34.

Il faut alors introduire ou créer une colonne qui sera la

clé primaire dans la table maître.

La création de la table de détails suit l'enchaînement des étapes A-34-1, o CODETAB2 est le nom de la clé primaire de la table TAB2. CODE TAB2 et TEMPO sont des noms qui

doivent être disponibles au niveau de la base de données.

La première ligne est très semblable à la requête A-33-1, sauf qu'au lieu de créer directement la table TAB2, on passe par une vue TEMPO. C'est la seconde ligne qui crée TAB2, en ajoutant à la vue TEMPO une colonne calculée CODE_TAB2, dont la valeur est ROWNUM, c'est à dire le rang

de ligne dans la table, après quoi TEMPO est effacé.

L'aménagement de la table d'origine TAB1 s'effectue comme

indiqué en A-34-2.

Comme la clé primaire n'existe pour le moment qu'en TAB2, il faut partir d'une jointure entre TAB1 (ancienne) et TAB2, qui vient d'être créée. D'o le premier ordre CREATE

plus élaboré.

Par l'enchaînement des 3 ordres donnés en A-34-2, on crée une table temporaire TEMPO avec les colonnes non transférées, plus la clé primaire choisie Sl (TEMPO est un nom disponible au niveau de la base de données: il n'y a pas d'autre table ou vue ayant ce nom). Ensuite on efface

TAB1, et l'on renomme TEMPO en TAB1.

Dans les deux cas, le méta-dictionnaire est mis à jour (étape

2065):

a) la table maître nouvelle TAB2 formée des colonnes Sl, S2,

Sn est prise en compte.

b) dans le cas de la création d'une clé primaire pour TAB2, la création de la colonne CODETAB2 dans TAB1 est notée; la création de la colonne CODETAB2 dans TAB2 est notée. Les formulaires permettant d'attaquer la table TAB1 sont enrichis de la colonne CODE_TAB2, et ne permettent plus d'attaquer

(saisie) les colonnes Sl, S2,... Sn.

c) dans le cas o la colonne Si a été choisie comme clé primaire de la table TAB2, les formulaires permettant d'attaquer la table TAB1 ne permettent plus d'attaquer les colonnes Sl, S2,... Sn, sauf Si qui demeure attaquée (mais doit respecter les contraintes d'intégrité dues à son nouveau rôle).

d) la clé primaire de TAB2 est référencée comme telle.

e) la clé externe de TAB1 est référencée comme telle.

f) les informations du lien maître-détails entre les tables sont insérées. En outre, il peut être nécessaire de mettre à jour les jointures préexistantes concernant des colonnes de

la table nouvellement créée.

Le processus qui vient d'être décrit de façon élémentaire permet de garantir que le méta-dictionnaire de données demeure cohérent et synchronisé avec la structure physique des données; ainsi la génération dynamique des formulaires,

requêtes d'interrogation et états est assurée sans interven-

tion de l'utilisateur, et ceux-ci sont adaptés automatiquement

à la nouvelle structure, comme on le verra ci-après.

L'utilisateur peut alors continuer son travail sur la base de

la nouvelle structure.

A côté de cela, il est connu de conférer à un champ d'un formulaire des propriétés comme: "saisie", "modification autorisée", "modification interdite", ou encore "modifiable seulement si", avec une condition qui peut être notamment une restriction relative à certaines contraintes, voire l'action de l'utilisateur sur une touche définie du clavier, ou sur une icône définie avec la souris. Dans un outil de développement, ceci peut se faire au niveau de la partie générateur de formulaire, travaillant par exemple avec un fichier de

définition de formulaire.

A partir du moment o, selon l'invention, la table unique a été découpée pour définir une table maître séparée, le formulaire qui attaquait cette table unique va être modifié, ou remplacé par un nouveau formulaire, en respectant la règle suivante: dès lors qu'un formulaire comprend des champs appartenant à une table maître et des champs appartenant à une table de détails, on ne peut modifier que les champs appartenant à la table de détails; et les valeurs prises par la colonne clé externe doivent appartenir à l'ensemble des valeurs prises par la clé primaire de la table maître. Un

formulaire séparé est engendré pour attaquer la table maître.

Ainsi, la figure 18 représente le formulaire de saisie des composants utilisés dans la production après la réorganisation des informations relatives aux produits. On note que les champs P_NAME, P_ID et CATEG ne sont plus accessibles directement car ils n'appartiennent pas à la table Composants alors qu'ils appartenaient à la table Composants_et_Produits; ils sont déterminés par la valeur du champ numéro de série du produit (P_SN) qui est la clé externe de la table Composants

qui est liée à la clé primaire de la table Produits.

Pour obtenir ce formulaire à partir du précédent, on fait passer en "non modifiable" tous les champs (colonnes) qui ont

été transférés dans la table maître, sauf la clé externe.

Concrètement, on peut utiliser un automate qui va: - recueillir la liste des colonnes du groupe qui a servi à

définir la table maître (tirée de la mémoire 550, ou du méta-

dictionnaire 510, dans la mise à jour qui en découle); - retirer de cette liste la clé de lien, - rechercher chaque nom de colonne de cette liste dans la définition du formulaire, pour assortir le champ concerné de la propriété "non modifiable", et - assortir le champ relatif à la clé de lien d'une propriété "modifiable si et seulement si la nouvelle valeur existe dans la table maître". La liste des valeurs existantes est donnée par la requête de recherche A-37 dans la table maître TAB2, dont COL1 est la clé primaire (Le mot-clé DISTINCT est

optionnel).

En variante, ou en complément, la figure 18A représente un formulaire simplifié de saisie des composants utilisés. Les champs PID et CATEG qui étaient renseignés automatiquement dans le formulaire de la figure 18 ont été supprimés du formulaire. Seul le champ Nom du produit (PNAME) a été conservé pour vérifier que le numéro de série du produit saisi est bien celui souhaité. Concrètement, le processus est le même que ci- dessus, sauf qu'au lieu d'assortir les champs de la propriété "non modifiable", on les supprime purement et

simplement de la définition du formulaire concerné.

On trouvera en A-23 quelques exemples de requêtes écrites pour la structure réorganisée en deux tables (Composants et

Produits).

La figure 19 représente le résultat de la requête d'interro-

gation après la réorganisation des informations relatives aux Produits. Une rupture (c'est une façon d'illustrer la nouvelle structure) a été prévue automatiquement par le générateur de rapport, en réponse à la présence d'une nouvelle table. A l'instar des formulaires, une telle rupture peut être simplement déterminée par la propriété "Rupture" associée à la colonne considérée, dans la définition du rapport considéré. D'autres illustrations que la rupture sont envisageables. En pratique, le cycle sélection/réorganisation (ou bien le cycle analyse/sélection/réorganisation) peut être répété autant de fois que nécessaire, tout du moins tant qu'il reste

un groupe de colonnes liées à traiter.

Dans l'exemple considéré, on peut procéder ensuite à une nouvelle réorganisation des informations relatives à la catégorie. La figure 17 représente les relations de jointure de la structure avec les trois tables Composants, Produits et Catégories. La figure 19A représente le résultat de la requête d'interrogation sur ces trois tables. Une deuxième rupture a

été effectuée automatiquement.

Dans le mode de réalisation décrit ci-dessus, la réorganisation physique des tables a l'effet suivant: - en mode saisie de données (formulaire), on restreint l'accès en saisie (modification, création, suppression) à une partie seulement des colonnes d'un groupe de colonnes liées, les autres étant simplement accessibles en lecture, ou inaccessibles; - pour accéder à ces autres colonnes en écriture, il faut utiliser un formulaire différent, traitant la nouvelle table créée. Cet autre formulaire peut être rendu accessible à partir du premier, notamment dans les conditions suivantes: - en cas de saisie d'une clé externe qui n'existe pas dans la

table maitre,

- lorsque l'utilisateur souhaite modifier l'enregistrement de la table maitre qui correspond à la valeur de la clé externe,

actionnant par exemple une touche de fonction au clavier.

Toutefois, on pourrait envisager, après réorganisation physique des tables, des solutions différentes pour l'aménagement des formulaires, en particulier si l'on accepte (en s'affranchissant de la règle précitée) que, dans un formulaire qui comprend des champs appartenant à une table maître et des champs appartenant à une table de détails, on peut modifier des champs appartenant à la table de détails et

des champs appartenant à la table maître.

Selon une variante intéressante, au lieu de restructurer physiquement les tables, l'analyse effectuée peut servir seulement à modifier le fonctionnement des formulaires de saisie, en faisant comme si la structure de base de données avait été réorganisée ("réorganisation virtuelle" de la base de données). Comme le ou les groupes de colonnes liées ne sont pas reflétés par une modification de la structure des tables dans le méta-dictionnaire, l'aménagement des formulaires s'effectue alors à partir de la mémoire de dépendances (et de

clés) 550.

L'aménagement tient compte des niveaux de parenté entre les colonnes liées de chaque groupe. on part d'une clé de lien, qui est l'une des clés candidates, sélectionnée par

l'utilisateur, ou choisie automatiquement.

Dans un outil de développement (partie générateur de formulaire, travaillant par exemple avec un fichier de définition de formulaire), il est également connu de conférer à un champ d'un formulaire une propriété "valeur si vide", assortie d'une expression, ou d'une fonction, dont le résultat sera pris comme valeur du champ s'il est vide (un peu comme une "valeur par défaut"). De même, on connaît aussi la

propriété "la valeur a été modifiée par l'usager".

On va alors prendre comme expression une requête recherchant, dans la même table, au moins une ligne préexistante ayant la même valeur pour la clé de lien. Cette requête peut se fonder sur le constructeur de requêtes, ou bien être reconstruite à chaque fois, sur une base préparée à l'avance par morceaux,

et mémorisée.

Dans ce mode de réorganisation virtuelle, un formulaire peut travailler comme suit: - Lors de la saisie dans le champ de la clé de lien, les champs vides dépendants de cette clé (soeurs et filles) sont automatiquement renseignés par défaut. Ainsi dans le formulaire de la figure 8 (structure monotable) la saisie de "US1" comme numéro de série du produit (P_SN) provoque la saisie automatique du champ Référence du produit (P_ID) qui est une colonne soeur et des champs Nom du Produit (P_NAME) et catégorie (CATEG) qui

sont des colonnes filles.

Le champ PID (COL2) est renseigné automatiquement par le résultat de la requête A-36 cherchant "US1" dans la colonne P_SN (COL1) des lignes déjà existantes. Le mot-clé DISTINCT est optionnel dans la requête A-36, dès lors que toute ligne trouvée contient le résultat recherché pour COL2

(P_ID).

- L'utilisateur peut à loisir écraser les valeurs renseignées par défaut. Il peut ainsi casser la dépendance entre deux colonnes et le fonctionnement du mode réorganisation virtuelle

s'interrompt alors pour ce couple de colonnes.

Par exemple dans la structure monotable, il y a une dépendance entre les colonnes Coût (COST) et catégorie (CATEG): La saisie d'un coût renseigne automatiquement le champ catégorie. Si l'utilisateur change la valeur (automatique) du champ Catégorie, la dépendance entre Coût et Catégorie est cassée: la saisie du champ Coût ne renseignera plus automatiquement le champ Catégorie. La mémoire de dépendances 550 est mise à jour en conséquence,

et le fonctionnement du formulaire est modifiée.

C'est en quelque sorte un couplage dynamique entre l'analyse et les formulaires de saisie. Alors que la structure des tables n'est pas modifiée, par contre, demeurent physiquement modifiées les données relatives au fonctionnement du ou des formulaires de saisie, d'une manière qui simule la

restructuration des tables.

Ceci peut être effectué systématiquement, selon les étapes de la figure 20. A la validation 2200 d'un champ, et si celui-ci a été saisi manuellement (2210), on place la valeur saisie dans une zone mémoire du type liste, ou conteneur, à l'étape 2220. Tant que ce conteneur contient au moins un élément (2230), on extrait en 2240 son premier élément (qui disparaît du conteneur), pour déterminer en 2250 ses colonnes dépendantes (soeurs et filles directes du champ considéré en 2200). Les champs relatifs aux colonnes soeurs sont remplis automatiquement, s'ils sont vides, en 2260. A l'étape 2270, on fait de même pour les colonnes filles directes, que l'on va en outre placer dans le conteneur. (A est fille directe de B s'il n'existe pas de colonne C, autre que A et B, telle que B soit mère de C et C soit mère de A). Et l'on retourne alors en 2230. Le processus se termine en 2290 lorsque le conteneur est vide. Ceci permet de traiter les soeurs du champ visé en 2200, ainsi que de parcourir complètement l'arborescence de ses filles, petites-filles (et leurs soeurs), et ainsi de suite. En mode saisie de données (formulaire), on pourra astreindre (par défaut ou fermement) les données présentes dans des colonnes liées d'une ligne à rester cohérentes avec des données au moins partiellement identiques déjà existantes dans

d'autres lignes, à l'aide d'une requête du même type que ci-

dessus. L'astreinte par défaut vise à simplifier la saisie par

suggestion des valeurs dépendantes de valeurs déjà saisies.

L'astreinte ferme correspond au cas o l'on souhaite verrouiller la dépendance ou l'interdépendance entre les

colonnes d'un groupe.

On peut rendre l'analyse dynamique, avec mise à jour en temps réel ou presque, de la manière suivante: - s'il s'agit d'une ligne créée, on peut se servir de la requête A-32-1, effectuée pour toutes les paires de colonnes, pour déterminer s'il y a quelque chose de changé dans les groupes de colonnes liées. Si oui, on refait l'analyse. En variante, on peut aussi décider directement de refaire toujours l'analyse sur une création de ligne. En pratique, cette analyse pourra être simplifiée, puisqu'il n'y a qu'une

ligne nouvelle à comparer à toutes les autres.

- s'il s'agit d'une ligne supprimée, il suffit de rechercher si sa disparition rétablit la dépendance. - enfin, une modification équivaut à une suppression suivie

d'une création.

En pratique, ce qui précède pourra être simplifié, puisqu'il

n'y a qu'une ligne nouvelle à comparer à toutes les autres.

Avant la phase d'analyse, il peut être utile de procéder à une étape préalable de pré-normalisation des données de chaque colonne, ou de certaines au moins des colonnes (en particulier de type caractère). En effet l'utilisateur peut avoir saisi deux valeurs différentes ayant des sémantiques identiques (par exemple les villes 'Paris' et 'PARIS' sont sémantiquement identiques bien que différentes du point de vue de leur chaîne

de caractères).

La présente invention modifie en profondeur le cycle habituel de développement: Les dépendances fonctionnelles sont déduites d'après les dépendances entre les données. Cela réduit au minimum la phase d'analyse. Cela permet aussi de faire apparaître des dépendances non envisagées ou non présentes aux origines. La présente invention peut donc aussi être utilisée comme outil de recherche de corrélations entre les données et

comme outil de partition des données en domaines.

L'invention propose ainsi un moyen permettant notamment de réorganiser une base de données, au bout d'un certain temps d'exploitation. Ce moyen peut être mis en oeuvre à la seule initiative de l'usager. Il peut être proposé à des intervalles réguliers, dans le temps, ou bien en fonction de la croissance de la base de données. Avant une telle proposition, ou bien de façon générale, la partie analyse peut être mise en oeuvre automatiquement, au moins partiellement, afin de déterminer

s'il y a effectivement quelque chose à faire.

On pourrait aussi concevoir que cette partie analyse soit tenue à jour en arrière plan. Plus généralement, le moyen d'analyse et ses moyens de mémorisation opèrent alors en permanence, de façon dynamique (plutôt que de temps à autre, à la demande de l'utilisateur, ou sur incitation de l'outil de développement). Ainsi, le poste (ou l'un d'entre eux) peut être muni d'un automate ("trigger"), qui enclenche la mise à jour de l'analyse dès que se produit un événement susceptible d'influencer cette analyse. Pour ce faire, il peut être nécessaire de garder trace en permanence (directement ou indirectement) de toutes les variables traitées durant la

phase d'analyse.

On notera que, même si elle indique qu'une réorganisation physique est souhaitable, la phase d'analyse n'est pas forcément suivie d'une telle réorganisation. L'utilisateur peut en effet refuser la réorganisation pour différentes raisons, comme le temps qu'elle prendra, ou le fait qu'il n'est pas convaincu de l'utilité de découper sa table en deux

parties, par exemple.

La présente invention s'applique de façon générale à tout type de donnée, tout type de relation entre les données, tout type de base de données (non nécessairement relationnelles), tout type de langage d'accès aux bases de données, tout type d'architecture de base de données, tout type de système d'exploitation, tout type de support de stockage et de système

de stockage.

L'invention étendre donc ses effets à tout système de gestion de fichiers, accessible par un langage de programmation qui permettrait d'écrire l'équivalent détaillé des ordres SQL

mentionnés dans la description. La puissance du constructeur

de requêtes SQL décrit fait que celui-ci peut engendrer (notamment) toutes les requêtes statistiques voulues. Avec d'autres langages, il peut être nécessaire de créer un module (procédure) pour chacune de ces requêtes statistiques. En pareil cas, la structure de la figure 10 peut se trouver modifiée: l'outil statistique 520 recevrait uniquement des données à traiter, tandis que l'interrogation des tables pour accéder aux colonnes serait faite directement par le module

d'analyse 530.

Sur un autre plan, avec l'outil statistique décrit, chaque opération statistique est menée sur toutes les lignes, pour une ou deux colonnes choisies. Une variante des SELECT COUNT des annexes A-31 (éventuellement A-32) consisterait à parcourir les valeurs de la colonne considérée, en faisant une détection de nouvelle valeur: si la valeur a déjà été rencontrée, on passe à la suivante; sinon on référence cette valeur comme étant une des valeurs prises par la colonne, on incrémente un compteur et on passe à la valeur suivante. A la fin, la valeur du compteur donne le nombre d'occurrences distinctes prises par la colonne. Pour COLll '"xyz"ll COL2 on fait la même chose en considérant la concaténation de COL1, "xyz" et COL2 comme une simple colonne (en considérant comme précédemment que "xyz" est choisi de façon à ne pas créer de confusion possible). En traitant cela dans une procédure, il serait concevable de traiter en même temps plusieurs variables sur une ligne (par exemple, considérer COL1, COL2 et leurs concaténations telles que COL1 I l"xyz" '' COL2), puis de balayer ensuite toutes les lignes en traitant sélectivement ces variables. On peut même traiter d'un seul coup toutes les variables (du genre COLt, COL2 et COLll "xyz'"l COL2) que l'on

peut définir à partir de toutes les colonnes de la table.

Selon une autre variante intéressante, on peut utiliser des ensembles ou "listes", rangés, dans chacun desquels on recense, pour chaque valeur d'une donnée d'une colonne, les lignes (désignées par exemple par un numéro) utilisant cette valeur. On décrira ceci en référence à deux colonnes notées COL1 et COL2 (Annexe A-25). Pour chaque valeur de chaque colonne on détermine les lignes utilisant cette valeur. On compare les ensembles obtenus pour les deux colonnes: - s'ils sont rigoureusement identiques, les deux colonnes sont soeurs. - si chaque ensemble pour une première colonne est égal à la un ensemble pour la seconde colonne, ou bien à la réunion de plusieurs ensembles pour la seconde colonne, alors la première

colonne est fille de la seconde.

- s'il n'existe pas de combinaison d'ensembles pour une colonne telle que leur réunion donne un ensemble identique à un des ensembles pour l'autre colonne, les colonnes sont

indépendantes.

Dans l'annexe A-25-1, on remarque que E21 = Ell U E13 et que E22 = E12

donc COL2 est fille de COL1.

Dans l'exemple de l'annexe A-25-2 (une ligne ajoutée), on remarque qu'il n'existe aucune combinaison de Ell, E12 et E13

dont la réunion soit E21; COL2 n'est donc pas fille de COL1.

De même, il n'existe aucune combinaison de E21 et E22 dont la réunion soit E12; donc COL1 n'est pas fille de COL2. COL1 et

COL2 sont par conséquent indépendantes.

Une opération de comparaison entre des réunions et/ou intersections de listes rangées (d'un format prédéfini) est accessible à l'homme du métier. A partir de là, la réalisation d'un automate effectuant les fonctions ci-dessus pour réaliser l'analyse l'est également. Cet automate est plus efficace que les ordres SELECT précités, au moins pour certaines applications.

De même le stockage sous forme de ligne n'est pas obligatoire.

On peut par exemple imaginer, pour chaque colonne, de ne stocker une valeur qu'une seule fois physiquement et de stocker parallèlement la liste des numéros de lignes ("index")

o cette valeur apparaît (ou une mémorisation équivalente).

La reconstitution d'une ligne se fait alors dynamiquement en retrouvant les différentes valeurs des colonnes de cette ligne par recherche du numéro de ligne dans les listes affectées à

chaque colonne.

Soit la table constituée de trois colonnes COL1, COL2 et COL3 illustrées en A-26-1. Pour cette table, on peut construire les ensembles d'index (numéro de lignes) pour chaque valeur, comme indiqué en A-26-2. On note maintenant X l'ensemble des numéros

*de lignes de la valeur "X".

Les relations A-26-3 montrent que COL1 détermine COL2. De la même manière, on déduit que COL2 détermine COL3 et que COL1

détermine COL3 (ne serait-ce que par transitivité).

Mais COL2 ne détermine pas COL1 car

A n a a.

Il est souhaité de réorganiser cette table pour aboutir à la structure suivante: TABi(COL1,COL2)

TAB2(COL2,COL3)

COL2 va devenir une clé externe de TAB1 et la clé primaire de TAB2. Pour réorganiser, on définit une autre série d'ensembles d'index pour la clé primaire de la nouvelle table (COL2) et on met à jour les ensembles d'index des autres colonnes de la nouvelle table. La nouvelle structure est donc celle donnée en A-26-4, o les numéros de ligne dans la table TAB2 sont

distingués par "bis".

La jointure se fait en établissant la correspondance entre les deux ensembles d'index pour la colonne charnière (qui est une

clé externe d'une table et la clé externe de l'autre table).

Par exemple si l'on cherche la valeur de COL3 correspondant à COL] = "C", le cheminement est le suivant: valeur C pour COL1 > index 4 de TAB1 = valeur b pour COL2

index 2bis de TAB2 valeur a pour COL3.

De même, si l'on cherche à connaître les valeurs de COL1 pour COL3 = a, le cheminement est le suivant: valeur a pour COL3 > index ibis et 2bis de TAB2 X valeurs a et b pour COL2 X index 1, 2, 3 et 4 de TABl=valeurs A, B, C pour COL3. On revient maintenant à la table de départ pour montrer le

fonctionnement du suivi d'une dépendance lors de la saisie/-

modification/suppression d'une ligne. Par ajout d'une ligne, la table devient celle illustrée en A-27-1. Les ensembles d'index d'appartenance pour chaque valeur deviennent ceux

données en A-27-2.

Pour vérifier si la relation de dépendance entre COL1 et COL2 n'a pas été cassée, il suffit de vérifier si l'ensemble des index correspondant à la valeur de COL1 nouvellement saisie est toujours inclus (au sens large) dans l'ensemble des index correspondant à la valeur de COL2 nouvellement saisie:

Il faut donc vérifier si {1,2,6} n {5,6} = {1,2,6}.

Ce n'est pas le cas, donc la dépendance a été cassée.

Les index des lignes qui bloquent la dépendance sont obtenus facilement en considérant les intersections vides des ensembles d'index qui ne sont ni vides, ni égaux à l'ensemble

des index de la colonne presque fille.

Ainsi, l'annexe A-27-3 montre que la dépendance est bloquée par l'ensemblede deux ensembles d'index suivant:

{{1,2},{6}}.

Lors de la suppression d'une ligne, la dépendance n'est rétablie que si l'ensemble des ensembles des index qui bloque

la dépendance ne contient qu'un élément.

Ainsi la suppression de la ligne 1 donne {{2},{6}}. Il y a

plus d'un ensemble, la dépendance n'est donc pas rétablie.

Mais la suppression de la ligne 2 donne {{6}}. La dépendance

est rétablie.

Comme déjà indiqué, la modification d'une ligne peut être traitée par exemple comme l'enchaînement d'une suppression et

d'une création dans un ordre quelconque.

Etant articulée sur des moyens matériels qui réalisent des opérations, l'invention pourrait aussi être exprimée sous

forme de procédé. Elle aboutit aussi à un outil de développe-

ment nettement amélioré.

La version la plus simple de cet outil de développement comporte les moyens permettant de réaliser les fonctions suivantes:

- création d'une application à structure monotable.

- création des formulaires de saisie en fonction de la

structure courante.

- génération de requêtes d'interrogation et d'états adaptés

à la structure courante.

à quoi s'ajoute, selon l'invention:

- en option, la pré-normalisation des données (analyse).

- l'analyse des redondances et des dépendances des données entre elles (analyse), et - la réorganisation physique de la structure des données en fonction du résultat de l'analyse ainsi que les formulaires, états et rapports (réorganisation), ou bien la réorganisation

"virtuelle" décrite plus haut.

Dans une version plus évoluée, ledit outil va comporter les moyens permettant de réaliser les opérations suivantes, afin d'accueillir (importation) un fichier déjà existant: - création d'une structure monotable permettant d'accueillir

les données d'un fichier au format tabulaire.

- détermination pour le fichier du délimiteur de colonnes: On compte sur chaque ligne le nombre d'occurrences de chaque caractère. Le délimiteur appartient à l'ensemble des caractères ayant la même fréquence, non nulle, sur chaque ligne du fichier. Si l'ensemble est vide, le fichier n'est pas acceptable. Si l'ensemble comporte plus d'un élément, un choix de délimiteur est demandé à l'utilisateur. Une fois le délimiteur déterminé, éventuellement après avoir accepter des signaux de l'utilisateur via l'interface

utilisateur, chaque ligne est divisée en un nombre identi-

que de colonnes.

- détermination du format de chaque colonne du fichier: Pour simplifier, on admet que les données ne peuvent être qu'au format numérique, alphanumérique ou date: Pour qu'une colonne soit au format numérique, il faut que toutes les valeurs de cette colonne soient au format numériques. Pour qu'une colonne soit au format date, il faut que toutes les valeurs de cette colonne soient au format date. Si ce n'est pas le cas, la colonne est au format alphanumérique. Pour

le format numérique, on détermine la largeur et la préci-

sion de la colonne: La largeur est égale à la somme du nombre maximal de chiffres situé devant le séparateur décimal et du nombre maximal de chiffres situé derrière le séparateur décimal. La précision est égale au nombre

maximal de chiffres situé derrière le séparateur décimal.

Pour le format alphanumérique, on détermine la largeur de la colonne. La largeur est égale à au nombre de caractères

maximal de la colonne.

- création d'une table aux formats déterminés précédemment.

L'ordre SQL est de la forme donnée en A-35, o TAB1 est le nom de la table à créer, COLi... COLn le nom des colonnes de la table et FORMAT1... FORMATn les formats correspondants; FORMATi est d'une des formes suivantes: VARCHAR2 (L) pour le format alphanumérique o L est la largeur de la colonne. Certaines bases de données ne supportent pas le format VARCHAR2 de la norme SQL92, on

utilise alors le format CHAR.

NUMBER(L, P) pour le format numérique o L est la largeur

de la colonne et P sa précision.

DATE pour le format date.

L'outil peut aussi comporter les moyens permettant de réaliser les opérations suivantes: - la création de formulaires permettant d'accéder aux données contenues dans les tables, tandis que la validation de l'insertion, de la suppression ou de la modification d'une ligne ne pouvant se faire que si les contraintes suivantes sont respectées: 10. La valeur d'une colonne doit toujours être en adéquation

avec son format.

Une colonne clé primaire ne doit comporter que des

valeurs uniques.

Une colonne clé externe doit avoir un ensemble de valeurs inclus dans l'ensemble des valeurs de la clé primaire correspondante. Il peut encore comporter les moyens permettant de réaliser la création de requêtes d'interrogation o l'utilisateur précise simplement la liste ordonnée de colonnes simples ou de colonnes calculées, la liste de conditions restrictives, et

la liste d'ordres de tri.

Ceci correspond au constructeur de requêtes, dont on notera qu'il présente un intérêt intrinsèque, indépendamment de l'usage qui en est fait ici. Cette remarque s'applique à

d'autres des éléments de la présente invention.

En plus, l'outil de développement comporte avantageusement des moyens générateurs d'états, avec: - un générateur de rapports pour présenter le résultat des requêtes d'interrogation, o l'utilisateur précise simplement la requête d'interrogation, la définition de ruptures, les éventuels calculs de groupe, les formats de présentations des colonnes et des éventuels calculs de groupe, et/ou - un générateur de graphiques pour présenter le résultat des requêtes d'interrogation o l'utilisateur précise simplement la requête d'interrogation comportant de zéro à plusieurs colonnes de type libellé et une ou plusieurs colonnes de type

numérique, le format de la colonne de type libellé (éventuel-

lement), le format du graphique.

Dans ce qui précède, on a défini un outil de développement, destiné à travailler avec un système de gestion de bases de

données pré-existant. Une variante intéressante, en particu-

lier avec la gestion de listes (annexes A-25 et suivantes, et

leur description), consiste en un système intégré qui comprend

la gestion des tables et les outils d'analyse et/ou réorgani-

sation décrits.

Dans tous les modes de réalisation décrits ou envisagés, il est possible de remplacer ou de compléter la réorganisation physique des tables par le mode de structure de base de données virtuellement réorganisée, pour la saisie sur formulaires. Au lieu d'opérer de façon exhaustive, le module d'analyse pourrait s'arrêter en fonction de critères choisis, incluant le fait qu'il a déjà trouvé un groupe de colonnes liées (sans fausses dépendances). On pourrait également enchaîner directement sur la re-structuration, sans sélection par l'usager, dès lors que l'analyse donne un groupe de colonnes liées. La clé de lien pourrait alors être choisie, parmi les clés candidates, comme: - la colonne la plus courte de ce groupe, ou - une colonne numérique, ou

- on pourrait créer systématiquement une clé nouvelle.

Avec des précautions adéquates, on pourrait également automatiser le forçage de dépendance, au moins dans les cas

flagrants, ou bien faire une proposition par défaut corres-

pondante à l'usager.

Enfin, bien que l'on préfère actuellement que le traitement et le stockage des données soient proches l'un de l'autre, il est possible d'envisager un stockage déporté, par exemple à

la manière des ordinateurs de réseau ("INetwork Computers").

ANNEXE I

A-11 - Colonnes calculées Une colonne calculée est une formule constituée:

- de colonnes simples ou de colonnes calculées.

- d'opérateurs et de fonctions mathématiques.

- d'opérateurs ensemblistes (somme, moyenne, comptage par exemple).

Exemples:

PRIX HT * 1.206

o * est le symbole de la multiplication et PRIX_HT une colonne d'une

table correspondant à un prix hors taxe.

PRIXHT * TAUXTVA

o TAUX_TVA est une colonne d'une table correspondant à un taux de TVA. Comptage(NOFACTURE) o comptage() est un opérateur de dénombrement, et NOFACTURE est la colonne clé primaire d'une table comportant des données relatives à

des factures.

Somme(PRIX_UNITAIRE * QUANTITEÉ_COMMANDÉE) o Somme() est un opérateur de sommation, PRIXUNITAIRE est la colonne de prix unitaire d'une table d'articles et QUANTITÉ_COMMANDÉE, la

colonne de quantité commandée d'une table de commandes.

A-12 - Conditions restrictives Une condition restrictive est composée:

- d'une colonne simple ou d'une colonne calculée.

- d'un opérateur de comparaison.

- éventuellement, d'une valeur ou d'un ensemble de valeurs de comparaison

Exemples:

VILLE = "Paris" La colonne correspondant à une ville doit être égale à la valeur "Paris". VILLE parmi( "Paris", "Londres","Washington") o parmi() est un opérateur d'appartenance

PRIX HT * TAUXTVA < 1000

Comptage(FACTURE) > 3.

A-13 - Requêtes - principe De son côté, une requête d'interrogation consiste en:

- une liste ordonnée de colonnes simples ou de colonnes calculées.

- une liste de conditions restrictives.

- une liste d'ordres de tri.

La liste des colonnes simples et calculées vérifie les contraintes suivantes: elle ne contient pas de clé externe ni directement (cas de la colonne simple) ni indirectement (dans la définition d'une

colonne calculée).

Les conditions restrictives sont liées par les opérateurs booléens AND' et 'OR', ainsi qu'éventuellement l'opérateur de négation noté NOT'.

Exemples

Les deux exemples ci-après sont fondés sur deux tables "ETUDIANTS" (n lignes) et "UNIVERSITES" (p lignes). Elles sont liées par une jointure

sur un identifiant de l'université concernée à chaque fois, CODEUNI-

VERSITE, qui est clé externe dans "ETUDIANTS" et clé primaire dans

"UNIVERSITES".

A-13-1

SELECT * FROM ETUDIANTS, UNIVERSITES

renvoie un produit cartésien des deux tables (n fois p lignes), que l'on peut considérer comme une table nouvelle passant en revue toutes

les universités pour chaque étudiant.

A-13-2

SELECT * FROM ETUDIANTS, UNIVERSITES

WHERE ETUDIANTS.CODEUNIVERSITE = UNIVERSITE.CODEUNIVERSITE

renvoie n lignes seulement (1 par étudiant). Le moteur SQL a créé une boucle pour arriver à ce résultat: on boucle sur la table ETUDIANTS

et pour chaque étudiant on recherche les informations de son univer-

sité grâce au CODEUNIVERSITE.

ANNEXE II

A-21 - Méta-Dictionnaire Le méta-dictionnaire (de l'outil de développement), qui est stocké dans la base de données, contient, au minimum: - les informations relatives à la structure de données:

les noms des tables.

À les noms des colonnes de chaque table.

À le type de chaque colonne (caractère, numérique, date par

exemple).

pour chaque table, l'indication de la colonne qui est la clé primaire. pour chaque table, les colonnes qui sont des clés externes

(éventuellement aucune).

- les liens entre les tables avec leur lien de cardinalité (sens du

lien maitre-détail).

- les définitions des formulaires: la référence de la table (ou des tables) à modifier grâce au formulaire. les références des colonnes appartenant à d'autres tables liées

a la table.

- les définitions des rapports:

la référence des colonnes incluses dans le rapport.

À les calculs éventuels à effectuer sur ces colonnes.

les conditions restrictives sur certaines colonnes.

les formats d'affichage de chaque colonne.

d'autres paramètres (ordres de tri, ruptures, titre du rapport - les définitions des graphiques:

* la référence des colonnes incluses dans le graphique.

* les calculs éventuels à effectuer sur ces colonnes.

À les conditions restrictives sur certaines colonnes. le type du graphique (histogramme par exemple).

d'autres paramètres (titre du graphique...).

A-22 - Requite: Forme canonique Elle est: (N ligne) SELECT Coll, Co012,.

Coln (1)..DTD: FROM TAB1, TAB2,... TAB (2)

TAB21, TAB22,... TAB2q (3) WHERE COLa = COLb AND COLc = COLd... AND COLr = COLs (4) AND COND NONENS1 AND CONDNONENS2... COND_NON_ENSt. (5) GROUP BY COLNON_ENSl,... COLNON_ENSu (6) HAVING CONDENSl,... COND_ENSV (7)

ORDER BY ORD1,... ORDW. (8)

Cet ordre SELECT de SQL est décomposé sur plusieurs lignes (Ici, sauf exceptions mentionnées ou manifestes, des lignes en indentation font

en principe partie du même ordre SQL que la ligne précédente).

La première ligne de la requête indique en "Col1, Col2,... Coln" la liste de colonnes (simples ou calculées) qui vont être extraites par

la requête.

La seconde ligne détermine en {TAB1, TAB2,... TABp} l'ensemble des tables auxquelles appartiennent les colonnes simples et les composants des colonnes calculées, d'abord pour la liste des colonnes, mais aussi

pour la suite de l'ordre SQL, essentiellement les conditions restric-

tives. Il faut remarquer qu'il s'agit d'un ensemble: une table n'y figure qu'une seule fois quand bien même plusieurs colonnes de cette table

font partie de la liste des colonnes (par exemple).

Viennent en troisième ligne les conditions restrictives dont les colonnes (simples ou calculées) ne comportent pas, directement ou indirectement, de fonctions ensemblistes (somme, moyenne...); ces conditions CONDi sont de la forme: COLi OPi VALi o COLi est une colonne (simple ou calculée), OPi est un opérateur du langage SQL (Par exemple = égalité,!=

différence, < inférieur à, IN parmi, IS NULL n'est pas renseigné).

VALi une valeur, un ensemble de valeurs ou rien selon le choix de

l'opérateur OPi.

Les conditions sont liées par les opérateurs booléens.

Elles peuvent être encadrées de parenthèses pour lever toute ambiguïté

sur la priorité des opérateurs: par exemple COND1 ET (COND2 OU -

COND3).

Grâce à la connaissance de la structure des tables, on fabrique les jointures entre les tables: COLa = COLb o COLa est la clé primaire d'une table et COLb la clé externe correspondante d'une autre table, de telle sorte que l'ensemble des jointures constitue le chemin minimal mais complet passant par toutes les tables de l'ensemble {TAB1, TAB2,... TAB}. D'autres tables {TAB21, TAB22,... TAB2q} que celles appartenant a {TAB1, TAB2,... TABp} peuvent être impliquées dans la constitution du chemin. Plusieurs colonnes d'une même table peuvent être impliquée dans les jointures constituant le chemin. Un

tel chemin existe toujours.

La quatrième ligne de la requête concerne les conditions restrictives pour les colonnes (simples ou calculées) qui ne contiennent pas, directement ou indirectement, de fonction ensembliste; elle est de la forme: CONDNON ENS1 AND COND NON ENS2... CONDNON_ENSt Les troisièmes et quatrièmes lignes (si l'une au moins existe) sont précédées du mot clé 'WHERE' et sont liées, si les deux existent par

le mot clé 'AND'.

La cinquième ligne de la requête concerne les colonnes (simples ou calculées) qui ne contiennent pas, directement ou indirectement, de fonction ensembliste; Soient COL_NON_ENS1,... COL_NON_ENSU ces colonnes. Viennent ensuite en sixième ligne les conditions restrictives sur les colonnes calculées qui contiennent toutes au moins une fonction

ensembliste notées COLENSi.

Viennent enfin en septième ligne les ordres de tris notés ORDi. Un ordre de tri comporte une colonne (simple ou calculée) et un sens ASC

(ascendant) ou DESC (descendant).

Seules les parties 1 et 2 sont toujours présentes.

La troisième partie est présente dès que deux tables (au moins) sont

impliquées dans la liste des colonnes ou des conditions.

Le reste est optionnel.

A-23 - Exemples de Requêtes canoniques

A-23-1:

SELECT PSN, PNAME FROM PRODUITS

Donne la liste des colonnes {Numéro de série du Produit, Nom du Produit}. Les colonnes PSN et P NAME appartiennent à la même table PRODUITS. Il n'y a donc qu'une seule table impliquée et donc pas de

troisième partie (voir A-22, plus haut).

Il n'y a ni condition restrictive sur des colonnes calculées ne comportant aucune fonction ensembliste, ni colonnes calculées comportant des fonctions ensemblistes, ni condition restrictive sur des colonnes calculées comportant des fonctions ensemblistes, et

enfin, ni tri.

A-23-2:

SELECT P SN, PNAME FROM PRODUITS

WHERE P SN <> 'USI'

ORDER BY PNAME ASC

Liste des colonnes {Numéro de série du Produit, Nom du Produit}.

Condition restrictive: Le Numéro de série du Produit est différent de USl'

Ordre de tri: Nom du Produit, ascendant.

A-23-3:

SELECT PRODUITS.P_SN, PNAME, SUM(COST)

FROM PRODUITS, COMPOSANTS

WHERE PRODUITS.PSN = COMPOSANTS.PSN

AND PRODUITS. PSN <> 'US]'

GROUP BY PRODUITS.PSN, P_NAME

HAVING SUM(COST) > 1000

ORDER BY PNAME ASC

Liste des colonnes {Numéro de série du Produit, Nom du Produit, Somme(Coût)} Conditions restrictives: Le Numéro de série du Produit est différent de 'USl' Somme(Coût) > 1000

Ordre de tris: P NAME ascendant.

Les colonnes Numéro de série du produit et Nom du produit appartien-

nent à la même table PRODUITS. La colonne Coût appartient à la table COMPOSANTS. Il y a donc deux tables impliquées et la troisième partie

de la requête est 'PRODUITS.PSN = COMPOSANTS.P_SN '.

Lorsqu'il y a ambiguïté sur le nom d'une colonne, SQL demande de lever l'ambiguïté en précisant devant le nom de colonnes qui pourraient porter à confusion le nom de la table auxquelles elles se rapportent

(suivi d'un séparatif prévu, en SQL un point).

Il y a une colonne calculée comportant une fonction ensembliste (somme) donc la cinquième partie de la requête est: 'GROUP BY

PRODUITS.P_SN, P_NAME '.

Il y a une condition restrictive sur une colonne calculée comportant une fonction ensembliste donc la sixième partie de la requête est:

HAVING SUM(COST) > 1000'.

A-24 - "Presque-dépendance" On considère une table à deux colonnes et sept lignes:

COL1 COL2

A 1

B 2

A 1

C 2

D 3

D 4

D 4

La ligne D3 ou les lignes D4 bloquent la dépendance, car D ne peut

déterminer à la fois 3 et 4, s'il y a dépendance.

A-25 - Dépendance par listes A-25-1 - Exemple 1

COL1 COL2

A a B b C a A a les ensembles sont pour COL1: pour "A", Ell = {ligne 1, ligne 4}, pour "B", El2 = {ligne 2},

pour "C", El3 = {ligne 3}.

les ensembles sont pour COL2: pour "a", E21 = {ligne 1, ligne 3, ligne 4}, pour "b", E22 = {ligne 2} Ces ensembles peuvent être manipulés par exemple comme des variables tableau (ARRAY) à deux dimensions, la première pour la valeur concernée, et la seconde pour la liste des lignes, une chaîne de caractères sans espace, o les lignes sont désignées par leur simple numéro, séparées par une virgule, et triées par ordre croissant). Si El et E2 sont les noms de ces tableaux pour COL1 et COL2, on écrira

par exemple:

El[1,1] = "A" et El[l,2] = "1,4" El[2,1] = "B" et El[2,2] = "2" El[3, 1] = "C" et El[3,2] = "3" E2[1,1] = "a" et E2[1,2] = "1,3,4" E2[2,1] = "b" et E2[2,2] = "2" Une notation encore plus simple (non informatique) consistera ici à désigner chaque ensemble par la valeur qu'il concerne, soit:

A = "1,4"

B = "2"

C = "3"

a = "1,3,4" b = "2" A-25-2 - Exemple 2

COL1 COL2

A a B b C a A a C b Les ensembles sont maintenant pour COL1: Ell = {ligne 1, ligne 4}, E12 = {ligne 2},

E13 = {ligne 3, ligne 5}.

les ensembles sont maintenant pour COL2: E21 = {ligne 1, ligne 3, ligne 4}, E22 = {ligne 2, ligne 5} A-26

A-26-1

COL1 COL2 COL3

Ligne 1 A a a Ligne 3 A a a Ligne 3 B a a Ligne 4 C b a Ligne 5 D c B

*A-26-2

A:{1,2} a:{1,2,3} a:{1,2,3,4} B:{3} b:{4} 13:{5} C:{4} c:{5} D:{5}

A-26-3

A a = A B n a = B C n a = 0 D n a 0 Anb=0 Bnb=0 C nb=C Dnb=0 A n c =0 B n c =0 c n c 0 D n c = D

A-26-4

TAB1 TAB2

A:{1,2} a:{1,2,3} {lbis} a:{lbis,2bis} B:{3} b:{4} {2bis} B:{3biS} C:{4} c:{5} {3bis} D:{5} A- 27

A-27-1

COL1 COL2 COL3

Ligne 1 A a a Ligne 3 A a a Ligne 3 B a a Ligne 4 C b a Ligne 5 D c B13 Ligne 6 A c B

A-27-2

A:{1,2,6} a:{1,2,3} a:{1,2,3,4} B:{3} b:{4} B:{5} C:{4} c:{5,6} D:{5}

A-27-3

A n a = {1,2} A B n a= B C n a = 0 D n a = 0 A n b 0 B n b 0 C n b C D n b 0 A n c = {6} A B n c = C n c = 0 D n c = D

ANNEXE III

A-31

A-31-1:

SELECT COUNT (*) FROM TAB1

A-31-2:

SELECT COUNT (DISTINCT COL1) FROM TAB1

A-31-3:

SELECT COUNT (DISTINCT COL1 I 'xyz' I, COL2) FROM TAB1 A-31-4: SELECT COUNT (DISTINCT COL1) FROM TAB1 WHERE COL1 LIKE "%xyz" A-32 A-32-1: SELECT COUNT (DISTINCT a.COL1 i 'xyz' l a.COL2) FROM TAB1 a WHERE a. COL1 IN (SELECT b.COL1 FROM TAB1 b GROUP BY b.COL1 HAVING COUNT(DISTINCT b.COL1 'xyz', b.COL2) > 1)

OR COL1 IS NULL'

A-32-2: SELECT a.COL1, a.COL2, COUNT(a.COL1 ' 'xyz' l a.COL2) FROM TAB1 a WHERE a.COL1 IN (SELECT b.COL1 FROM TAB1 b GROUP BY b.COL1 HAVING COUNT(DISTINCT b.COL1 l 'xyz' ',I b.COL2) > 1) OR a.COL1 IS NULL GROUP BY a.COL1, a.COL2 ORDER BY a.COL1,COUNT ( a.COL1 I, 'xyz' I a.COL2) DESC

A-32-3: UPDATE TAB1 SET COL2 = 'VALEUR2' WHERE COL2 IN ( 'VALEUR2_1',

VALEUR2_2',... 'VALEUR2_n') AND COL1 = 'VALEUR1'

A-32-4:

UPDATE TAB1 SET COL1 = 'VALEURi' WHERE COL2 IN ( 'VALEUR2_1', VALEUR2_2',

. 'VALEUR2_n') AND COL1 IS NULL A-32-5: UPDATE TAB1 SET COL1 = 'VALEURlA' WHERE COL2 IN ( 'VALEUR2_1', VALEUR_2',... 'VALEUR2_n') AND COL1 = 'VALEUR1' A-33 A-33-1: CREATE TABLE TAB2 AS SELECT DISTINCT Sl, S2,... Sn FROM TAB1 A-33-2: CREATE TABLE TEMPO AS SELECT R1, R2,... Rp, S1 FROM TAB1 zgv Noua 1O [TD NI.ISI],T IDgSS SLl. = 103 HHM ISÉV WOLI tODO [mDNISIa] 0%IS LE-Y 9ú-V uivvoa UIOD ' v ** lOaI ZIOD Tl O. d TrIOD) rav alavl avauD SE-V Iglvi OJ1 Offlai alNa Tgvl SUENI doua..DTD: US'*ZVL = US'TIL GNV

IS *ZSV TS= 'T9V CNHM

ztr ' oD 'du ", ao lla 'j ' a 'l TOI8SVI SElv Z8Am--tOD ' dH ' ''* ' ZI ' E Og. IS.T g.T.

: Z-ú-V

O&f.L M.IA douaI Od&aR iou. zagv--aaoD RgNnMOI 'us.. 'S 'IS OlD'I.gS Sv IWL NOML US 'S ''S IS LDNILSIG IDrqIRS SV OcIJW MSIA S.VMD

: -ú-Y

Tgv alevi do-a

Claims (19)

Revendications

1. Dispositif de traitement de données, du type comprenant: - au moins un ordinateur (100,200), muni d'une unité centrale (410) avec un processeur, au moins un périphérique

utilisateur, et une mémoire (440), animés par un système d'ex-

ploitation (450), - un système de gestion de bases de données (470), stocké dans cet ordinateur, et propre à coopérer avec le système d'exploitation pour permettre à l'utilisateur la création/saisie et/ou l'usage d'une base de données comprenant au moins une table de données (475), décomposable en lignes et colonnes, caractérisé en ce qu'il comporte en outre (500): - un moyen formant méta- dictionnaire autonome (510), pour mémoriser dynamiquement, en référence à une base de données, des informations choisies relatives à la structure de chaque table de la base de données, et aux liens entre tables, - un moyen d'analyse (520,530,550) capable de déterminer et de mémoriser au moins temporairement une représentation de groupes de colonnes liées entre elles, et - un module de re-structuration (580,590) capable de coopérer avec le moyen d'analyse et le méta-dictionnaire en vue d'établir pour l'utilisateur, au moins en création/saisie, une présentation ou vue de la base de données qui tienne compte

d'au moins un groupe de colonnes ainsi liées.

2. Dispositif selon la revendication 1, caractérisé en ce que les moyens d'analyse comprennent: - un outil statistique (520), propre à recevoir au moins deux jeux rangés de données qui lui sont présentés, afin de déterminer des liens entre ces jeux de données, par dénombrement d'occurrences distinctes, et - un module pilote d'analyse (530) capable de coopérer avec le méta-dictionnaire pour présenter les données d'au moins deux colonnes différentes de ladite table à cet outil statistique, afin de déterminer leur éventuel lien, avec des moyens (550) pour mémoriser au moins temporairement une représentation de groupes de colonnes liées, ce module d'analyse (530) étant agencé pour réitérer la présentation de paires de colonnes, jusqu'à en trouver au moins une dont les deux colonnes soient liées, ou jusqu'à épuisement des

possibilités.

3. Dispositif selon la revendication 2, caractérisé en ce que le module d'analyse (530) réalise systématiquement la présentation de toutes les paires de colonnes différentes

possibles pour ladite table.

4. Dispositif selon l'une des revendications 1 à 2, caracté-

risé en ce que le module d'analyse (530) opère pour toutes les

tables de la base de données.

5. Dispositif selon l'une des revendications 1 à 4, caracté-

risé en ce que l'outil statistique (520) est apte à définir: - un moyen (1024) pour compter le nombre de valeurs distinctes (Ni,Nj) de chacun des deux jeux de données, - un moyen (1034) pour compter le nombre de valeurs distinctes (P) des couples formés par les données de même rang de l'un et l'autre jeu, et - un moyen (1042-1049) pour retourner une information à au moins deux états, représentative d'une comparaison entre les comptages Ni, Nj et P.

6. Dispositif selon la revendication 5, caractérisé en ce que l'outil statistique (520) est apte à définir aussi un moyen (1012) pour compter le nombre total de valeurs distinctes (N) sur un groupe de colonnes considéré, et en ce que le module d'analyse (530) mémorise (550) les colonnes pour lesquelles N = Ni, en tant que clés candidates d'un lien partant de la

table en cours.

7. Dispositif selon l'une des revendications 5 et 6, caracté-

risé en ce que l'outil statistique (520) est agencé pour retourner quatre états différents (1043,1045,1047,1049), en fonction des conditions (Ni = Nj ET Nj = P), (Ni = P ET Ni > Nj), (Ni = P ET Nj > Ni), (NI Ni = Nj NI Ni = P), respectivement, et en ce que le module d'analyse (530), quand il présente les données d'une paire de colonnes (COL1 et COL2) d'une table à l'outil statistique, est agencé pour réagir à chacun des quatre états, en mémorisant (550) que Si Ni = Pet Nj = P alors COL1 et COL2 se déterminent

mutuellement (interdépendance).

Si Ni = Nj et Ni > P alors COL1 détermine COL2.

Si Ni > Nj et Ni = P alors COL2 détermine COL1.

Sinon COL1 et COL2 n'ont pas de relation de dépendance.

8. Dispositif selon l'une des revendications 5 à 7, caracté-

risé en ce que l'outil statistique (520) est également apte à fournir un moyen (1210) pour compter le nombre total de couples de valeurs distinctes de deux jeux de données qui bloquent la relation de dépendance entre ces deux jeux, et, le cas échéant, un moyen (1230) pour compter le nombre d'occurrences de chacun de ces couples "bloquants" de valeurs distinctes, et pour les identifier, tandis que le moyen d'analyse (530) est agencé pour proposer ou effectuer (1250) des modifications propres à forcer la dépendance entre les colonnes.

9. Dispositif selon l'une des revendications précédentes,

caractérisé en ce que les moyens de re-structuration (580) sont associés à un module d'interface utilisateur (570), permettant à ce dernier de sélectionner une table de départ à traiter, des colonnes à traiter parmi au moins un groupe de colonnes liées, et une clé primaire de nouvelle table à choisir parmi lesdites colonnes interdépendantes et une clé

nouvelle créée à cet effet.

10. Dispositif selon la revendication 9, caractérisé en ce que les moyens de re-structuration (580) sont agencés pour exclure

la clé primaire de la table de départ desdites sélections.

11. Dispositif selon l'une des revendications précédentes,

caractérisé en ce que les moyens de re-structuration (580) sont aptes à construire une nouvelle table avec les données d'un groupe de colonnes liées, ainsi qu'une clé de lien avec

la table considérée.

12. Dispositif selon la revendication 11, caractérisé en ce que la clé de lien est une colonne qui demeure dans la table considérée, laquelle est réduite pour ne conserver que cette

clé de lien, parmi lesdites colonnes liées.

13. Dispositif selon la revendication 11, caractérisé en ce que la clé de lien est une colonne créée à la fois dans la nouvelle table et dans la table considérée, laquelle est

réduite pour ne conserver aucune desdites colonnes liées.

14. Dispositif selon l'une des revendications 9 à 13, caracté-

risé en ce que les moyens de re-structuration (580) sont agencés pour opérer la construction d'une nouvelle table en réponse au fait qu'un groupe d'au moins deux colonnes liées

(COL1,COL2) a été identifié par le module d'analyse.

15. Dispositif selon l'une des revendications précédentes,

caractérisé en ce qu'il comprend, en mode saisie de données (formulaire), des moyens actifs pour restreindre par défaut l'accès en modification à une partie seulement des colonnes d'un groupe de colonnes liées, les autres étant simplement

accessibles en lecture.

16. Dispositif selon l'une des revendications précédentes,

caractérisé en ce qu'il comprend, en mode saisie de données (formulaire), des moyens actifs pour astreindre par défaut les données présentes dans des colonnes liées d'une ligne à rester cohérentes avec des données au moins partiellement identiques

déjà existantes dans d'autres lignes.

17. Dispositif selon l'un des revendications précédentes,

caractérisé en ce que le moyen d'analyse et ses moyens de

mémorisation opèrent en permanence, de façon dynamique.

18. Dispositif selon l'une des revendications précédentes,

caractérisé en ce qu'il comprend deux ordinateurs, dont un

serveur et au moins un "client" reliés en réseau.

19. Dispositif selon l'une des revendications précédentes,

caractérisé en ce que le moteur de gestion de bases de données

est un moteur relationnel, pilotable en langage SQL.