Base de données relationnelle

Je suis en train de réaliser une petite base de données relationnelle. Elle se présentera sous forme d'une DLL séparée, indépendante de KGF.dll. Ca prend forme et je suis en train d'attaquer la partie intéressante: la recherche des relations.

Le principe:

1. On donne un nom de fichier (éventuellement avec un chemin), et avec ce chemin, on appelle une fonction d'ouverture. Le programme détecte automatiquement si la base existe déjà, et la charge en mémoire dans ce cas. Sinon, il crée une base vide avec 4 fichiers du même nom placés au même endroit, mais avec des extensions différentes: *.hdr pour une entête, *.nam pour une liste de noms,; *.dat pour les données associées aux noms, et *.rel pour les informations de liens entre les noms.

2. On travaille avec des "entités". Chaque entité porte un nom et peut avoir des données libres.

3. On peut créer des liens entre 3 entités, dont une est considérée comme "relation" et les deux autres comme origine et cible. Si l'on crée des entités <mange>, <chat>, <souris>, <busard>, <fromage>, on peut créer par exemple les relations:
<chat> <mange> <souris>
<busard> <mange> <souris>
<souris> <mange> <fromage>
etc.
Ensuite, on peut interroger, du genre
- "qui mange la souris ?" Réponse: chat et busard
- "qui mange ?" Réponse: chat, busard et souris
- "que mange le chat ?" Réponse: souris
etc.
Je sais, l'exemple est trivial. Et il n'y a qu'une seule relation. Mais dans la base, le nombre d'entités n'est pas limité, et le nombre de relations non plus. Le nombre de relations qui peuvent toucher une même entité n'est pas limité non plus, etc. Cela permet de construire des réseaux relationnels très complexes qu'on peut parcourir avec quelques appels à des fonctions d'interrogation. Et on a bien sûr accès aux données de ces entitées à tout moment.

Ce qui marche déjà:
1. création d'une nouvelle base, chargement d'une bas existante, changement de base
2. création d'entités avec ou sans données
3. ajout de données à une entité sans données, suppression des données d'une entité
4. remplacement des données d'une entité
5. suppression d'une entité avec ses données
6. recherche d'entités en lecture par nom, ou séquentiellement en avant et en arrière
7. lecture des données d'une entité
8. création d'une relation (A,R,B) entre les entités A et B et la relation R

Ce qui est en cours:
1. suppression des liens relationnels en cas de suppression d'une entité liée
2. suppression d'un lien (A,R,B) sans toucher aux entités et aux autres liens touchant ces entités
3. recherche relationnelle du type (A,R B): est-ce que A est en relation R avec B ?
4. recherches relationnelles du type
- (A,R,?): A est lié à qui par le relation R ?
- (A,?,R): par quelle relation sont liées A et B ?
- (?,R,B): qui est lié à B par la relation R ?
5. recherches relationnelles du type
- (A,?,?): quels sont les liens de A ?
- (?,R,?): qui est lié par la relation R ?
- (?,?,B): quels sont les liens ciblant B ?
6. recherche relationnelle du type (?,?,?): quels sont les liens existants ?

Ce système peut être utilisé comme un simple fichier ISAM (fichier en accès indexé séquentiel) mono-clé, permettant d'enregistrer par exemple des livres, des clients etc, avec une clé d'accès (titre, nom, numéro de téléphone, ...). Mais on peut aussi lier un client à l'ensemble de ses factures, un auteur à l'ensemble de ses livres dans la bibliothèque, etc. C'est extrêmement souple et puissant.

Je vais avoir bientôt un premier ensemble montrable.

Et bien bonne chance, mais je suis hors du coup. En tout cas tu montres tes capacités avec ce genre de programme, et on reconnait là le professionnalisme de ton travail.

Bon chance Klaus, beau projet Plein de possibilités en effet

salut
@ Klaus
Ca me parait assez pointu, ton projet.
Question:
Est- il applicable à la gestion de bases de données contenant des programmes Panoramic de type .bas ou .exe ,et établissant des relations entre eux ?
J’utilise MakeHLP de Nardo26 qui structure, PANORAMIC: MANUEL DE REFERENCE, et regroupe par catégories ,les commandes
Est-ce ,ce que tu veux faire (en élargissant à d'autres objets) ?
On s'apercoit que vu le nombre des codes publies sur le forum on est oblige de les regrouper en un meme endroit et sutout de pouvoir les retrouver
losque on veux les utiliser
J'attends avec impatience ce nouvel outil

Pourqoui pas ? Cet outil permettra de
- mémoriser des entités avec un nom et des données associées, sous forme de chaines de caractères
- établir de multiples liens entre les objets, sachant qu'un lien est une sorte de "vecteur" portant un nom (le nom de l'entité représentant le lien), et qui relie une entité "source" à une entite "cible". Une même entité peut être, de multiples fois, et simultanément, "source" et "cible" de multiples relations. On peut donc construire des réseaux relationnels très complexes.
- rien n'empêche de placer dans les données, des noms de fichiers, des répertoires, du commentaire, ou toute autre information textuelle nécessaire.

Le tout sera disponible sous forme de fonctions d'une DLL, et il revient au programmeur de lui donner une interface visuelle adaptée au domaine d'application envisagé.

Bon courage, Klaus!

Je suis en train de mettre au point la fonction de recherche de lien entre entités - c'est le véritable coeur du programme.

La recherche des relations fonctionne.

J'ai tout fait par une DLL, et un wrapper plus convivial style KGF_SUB.bas a été réalisé.

Maintenant, je fais la purge des liens devenus obsolètes lors de la suppression d'une entité. Puis, ce sera la rupture ou la suppression d'un lien ARB comme s'il n'avait jamais été établi. Après cela, je publierai une première version.

J'ai déjà une idée pour ton programme si je ne me suis pas trompé sur ses possibilités: Une bdd relationnelle de connaissances. Pour mon usage perso voir pro si ça marche bien ...
Une connaissance est liée à une entité et des mots clés. On pourrait donc lister les connaissances par société, par un des mots clés ou en combinant les 2 dans le moteur de recherche...

La suppression des liens obsolètes suite à la suppression d'une entité marche bien maintenant. Il manque encore la fonction de suppression d'un lien sans suppression des entités, mais ça viendra prochainement.

Pour l'heure, je ne résiste pas au plaisir de vous montrer une toute première version. Toutes les fonctions sont accessibles via un wrapper. Il faut "lire" le wrapper pour voir comment on s'en sert. Un mini-programme de démo montre quelques fonctions.

J'ai donc mis une première version "alpha" en ligne sur MyDrive. C'est dans le dossier BDR (Base de Données Relationnelle).

Il y a un fichier lisez-moi.txt qui donne quelques infos de base, la DLL qui fait le travail, un mini-programme de démo et une mini-base montrant quelques possibilités.

Nouvelle version. BDR.dll et BDR_SUB.bas ont été modifiés:
- correction de diverses anomalies
- ajout d'une nouvelle fonctionnalité: BDRmacro(memo1%,memo2%)

La fonction "macro" permet de "jouer" une suite de commandes sous forme d'un srcipt. Toutes les fonctions actuellement disponibles peuvent être scriptées, y compris l'ouverture et la fermeture de la BDR. Cela permet de construire des fichiers de texte contenant des commandes de peuplement, par exemple, et de les rejouer à volonté. La procédure BDRmacro prend deux numéros d'objets MEMO e, paramètre. Le premier contient le texte qui représente le script, et le deuxième recevra la trace d'exécution et les résultats. Toutes les commandes sont documentées dans le fichier lisez-moi.txt.

Klaus dans BDR_SUB (pdf ou doc), il y a une faute de frappe je pense, mais comme elle change le sens du mot, je te l'indique. 4ème paragraphe :
Une BDR représente un petit système de gestion de Bases de Données Delationnelles (Mettre Relationnelles à la place ...)

La correction est faite.

Nouvelle version.

Une nouvelle procédure dans BDR_SUB:
BDR_status() crée une variable BDRstatus dont la valeur est 0 si la BDR est actuellement fermée, ou 1 si elle est actuellement ouverte.

ET surtout: à la fermeture d'une BDR ou lors de sa sauvegarde, on ne réécrit plus systematiquement la totalite. On ne réécrit que les parties qui ont été modifiées. Et cela est suffisamment sélectif pour distinguer les changements de référence de ceux des données et encore ceux des liens.

salut
J'ai un message d'erreur " not correct expression line 56"
Avec la derniere version ainsi que celle qui precede
Pourtant la ligne 56 es vide!
Je suis sous vista

oui, ça correspond à la ligne 23 de BDR_SUB.bas
(une ligne qui devrait être un dim mais qui n'a pas le dim devant mais un , et une virgule à la fin. Si tu remplace la , du début par dim et que tu supprime la virgule de la fin, ça marche )

Oups.... C'est corrigé. mes excuses - j'ai voulu aller plus vite que la musique.

Juste une petite note:
la nouvelle fonction BDRmacro peut être utile pour exécuter rapidement des séquences d'ordes à la BDR sans être obligé de les coder en dur. Placez 2 mémos dans la form 0, et un bouton. Dans le on_click du bouton, executez:
BDRmacro(no_memo1%,no_memo2%)
où les deux paramètres sont les numéros d'objet de ces deux mémos.
Saisissez les commandes documentées dans lisez-moi.txt dans le premier mémo.
Cliquez sur le bouton.
Vois avez la trace et le résultat dans le second mémo.

Exemple:

Citation :

opn,"xxxx\test.dat"
sta
lae
fdr,rapace,mange
cls
sta

à la place de xxx, vous mettez le chemin d'accès complet de la base de démo fourni dans MyDrive.
Voici ce que ça fait:
1. ouverture de la base existante
2. affichate de l'état de le base (1 = ouvert)
3. affichage des noms de toutes les entités définies dans la base
4. répondre à la question "que mange le rapace ?" (réponse: souris,lapin)
5. Fermeture de la base
6. affichage de l'état de la base (0 = fermé)

Sympa, non ?

C'est clair que tu as bien avancé

Je fais une brève pause sur la DLL, pour réaliser une petite appli parlante avec cet outil. C'est une n-ième version d'un logiciel de carnet d'adresse qui va utiliser la BDR comme fichier ISAM (trouver un contact par son nom, immédiatement), avec des données associées (téléphone, adresse mail et postale). Il y aura des entités spécifiques qui seront au nombre de 3: professionnel, famille, amis, et une relation: appartient_a. On pourra ainsi, par des cases à cocher, déterminer si un contact appartient à une ou plusieurs de ces catégories, et le programme va créer automatiquement la relation appropriée. On pourra alors utiliser cela pour filtrer les recherches, lister les groupes, etc. Mais je pense que ceci pourra intéresser Pan59, car cette recherche d'un nom d'un contact se fait en Delphi, par dichotomie, de façon ultra-rapide dans des listes automatiquement triées. Je suis certain qu'il pourra en tirer un gain de temps énorme au niveau de la recherche de ses mots. Bien sûr pas sous forme de "contacts", mais en utilisant une BDR comme fichier indexé sur le nom. D'ailleurs, ça marcherait déjà maintenant, mais sans qu'il y ait un exemple concret.

Puis cela continuera. Voici ce qui est dans les cartons:

- outre la possibilité de gérer des entités dont certaines servent de "relation" pour créer des liens entre entités, je vais créer la notion d'ensembles dans le sens mathématique du terme. Ce seront des regroupements NON ORDONNEES d'entités, dont la seule propriété commune sera d'être justement élément d'un ensemble. Les ensembles étant eux-mêmes des entités, chaque entité pourra être, ou devenir, un ensemble, tout comme actuellement, chaque peut être, ou devenir, une relation.

- avec les ensembles, on pourra faire les opérations d'ensembles: union, intersection, différence, complément. On pourra lister les éléments d'un ensemble, tester si une entité est membre ou non d'un ensemble, et puis, le plus important de tout, on pourra lancer des traitements en boucle automatique sur tous les éléments d'un ensemble.

- on pourra constituer un ensemble manuellement, en ajoutant des éléments individuellement ou par liste d'éléments. Mais un pourra surtout spécifier une entité comme "ensemble de résultat" pour certaines fonctions, comme BDRfindrelation par exemple. Ceci permet d'avoir, en une seule opération, un ensemble contenant la liste de toutes les entités trouvées par la fonction de recherche. Exemple:
BDRfindrelation,rapace,mange,,nourriture_du_rapace
transformera l'entité nourriture_du_rapace en ensemble et luui donnera comme élément les noms de toutes les entités qui satisfont la recherche (dans ce cas, souris et lapin).

J'ai fait mon petit programme de démo d'une liste de contacts. C'est en ligne sur MyDrive dans le sous-dossier contacts_avec_BDR dans le dossier BDR. Il y a contacts_avec_BDR.bas et les 5 volets d'une petite base avec 3 noms. pour chaque nom, on gère téléphone, mail et adresse, ainsi que les cases à cocher Professionnel, Famille et Amis.

On peut créer de nouveaux contacts. Les cases à cocher sont prise en compte au moment de la création, pour memoriser les liens par une relation cachée "contact_appartient_a". Les 3 autres entités cachées sont "contact_professionnel", "contact_famille" et "contact_amis". Si je dis "caché", c'est que je les élimine volontairement de la liste d'affichage. La BDR elle-même ne fait aucune distinction entre les entités.

Pour des raisons techniques, j'ai un mémo caché par HIDE dont le numéro est dans no_memo%, et ne liste visible dont le numéro est dans no_liste%. BDR ne peut écrire (pour le moment) son résultat que dans un mémo. Or, on ne peut pas savoir sur quelle ligne on a cliqué dans un mémo. Et je eux utiliser le clic sur un nom pour le sélectionner et l'afficher dans les cases à droite. Je cache donc le mémo et montre un list à la place, dans lequel je copie le contenu du mémo dès que ce dernier est chargé par la BDR. De cette manière, mon affichage est toujours à jour, et on peut l'utiliser pour sélectionner en cliquant sur un nom.

On peut supprimer un contact. Les zones à droite restent affichées. On peut alors modifier les cases à cocher et le recréer. Si l'on veut modifier autre chose que les cases à cocher, il suffit d'utiliser le bouton Modifier.

Le menu Aide et A-propos n'est pas rempli - il est juste la pour exemple.

Pour exécuter, copier l'ensemble des fichiers du sous-répertoire contacts_avec_BDR à un endroit où il y a DBR_SUB.bas et DBR.dll, ou ajoutés ces deux fichiers dans un répertoire neuf, avant ou après y avoir ajouté
Les 6 nouveaux fichiers. Le menu Fichiers offre 2 choix: Ouvrir ouvre un dialogue permettant de choisir la base d'exemple fournie, ou de saisir son propre nom du genre essai.dat, essai.txt, essai.xxx etc. L'extension sera ignorée. Si (nom_de_fichier).hdr n'existe pas, les 5 volets seront céés avec le nom de fichier que vous spécifiez, et les 4 entités cachées seront créées automatiquement.

Tout d'abord bravo pour l'exemple qui fonctionne bien.
Juste un petit reproche... Quand on fait modifier, on ne peut pas modifier le nom sinon il dit que le contact n'existe pas. Il faut donc créer un autre contact et supprimer l'ancien. Ce n'est pas top.
Pour la base téléphonique, c'est dommage aussi de ne pas pouvoir séparer le nom du prénom.

Bonsoir,

@Klaus : en causant de SGBDR, connais-tu SQLite ?

Si j'ai le temps, je ferai un petit programme en basic Panoramic qui utilisera sqlite.
Cela serait un bon départ pour ceux qui veulent apprendre les bases du langage SQL...

@Nardo26:
Oui, je connais SQLite. Et il y a des DLLs permettant d'utiliser SQLite, mais ce n'est pas si évident à partir de Panoramic. Et le langage SQL, bien que très répandu dans des applications de gestion, n'est pas évident à maîtriser.

J'ai voulu prendre le problème par un autre bout. Qu'est-ce qui manque vraiment à Panoramic au niveau de la gestion de fichiers ? Un vrai accès par une clé alpha, à un fichier contenant des données de longueur variable. C'est exactement ce que j'ai fait. Une clé (le nom de l'entité) et des données optionnelles de longueur variable. Avec ça, on peut stocker toutes sortes de données, comme des factures, des descriptions de photos, des notes personnelles, des listes d'URL, de sources Panoramic, que sais-je. Et la cerise sur le gâteau, c'est de pouvoir créer des réseaux de liens (optionnels) entre certaines ou toutes les entités. Pour hiérarchiser, structurer, regrouper, catégoriser, ... Rien que ça, cela donne un énorme champ d'application.

J'avais déjà fait une tentative d'un fichier ISAM, mais j'ai dû m'aider de Excel. Cela marche parfaitement, mais tout le monde n'a pas une licence Excel. Cette fois, je suis totalement indépendant. La dll est écrite entièrement par moi, en Delphi 6, et lorsque le code sera dans une version suffisamment complet et stable, je mettrai également tout le code en ligne. Il est abondamment commenté.

Et, entre nous, si tu regardes attentivement le code source du programme de contacts, tu vois aisément la puissance de ces fonctions.

@Jicehel:
De ce que je viens de répondre à Nardo26, il en découle ce que j'ai déjà décrit dans les posts précédents: je pars de l'idée d'une entité portant un nom (et un seul) et pouvant avoir optionnellement des données de longueur variable. On voit immédiatement que le nom et le prénom d'un contact doivent être attachée ensemble d'une manière ou d'une autre, pour former le nom de l'entité. Sinon, il y aurait en permanence des doublons sur des personnes du même nom de famille.

Bien sûr, j'aurais pu prévoir deux champs de saisie, un pour le nom, l'autre pour le prénom, et derrière l'écran concaténer ces deux champs pour en faire une seule chaîne servant de "nom" à l'entité. Mais mon but n'était pas de faire un n-ième programme de gestion de contacts damant le pion à tous les autres ! Je voulais juste prendre un exemple parlant pour montrer les capacités du module BDR. Et je pense que c'est réussi. Regarde l'emploi de BDRlistallentities, ou de BDRsetrelation etc. Quand on a vraiment compris l'aspect fonctionnel, on pourra imaginer de vraies applications de gestion.

Et, en particulier pour des applications utilisant des dictionnaires comme celle de Pan59, c'est idéal. Qu'est-ce qu'un dictionnaire ? C'est une liste triée dont une partie des données sert de clé et l'autre sert de descriptif. Exeactement ce que font les entités. Toute la BDR est basée sur des TStringList triées de Delphi, dans lesquelles les recherches se font par Delphi (en non par mon propre pauvre code), en utilisant un algorithme de dichotomie. Il n'y a pas vraiment de méthode de recherche plus rapide, sauf à utiliser des des arbres binaires, ce qui est beaucoup plus complexe à maintenir.

Et pour donner une idée de ce qui va venir, au-delà de la notion des ensembles que j'ai déjà décrite, il y aura la possibilité de plusieurs BDR ouvertes simultanément. Ce n'est pas le cas maintenant, mais c'est dans la TO-DO-List.

Il faut bien voir que, comme Panoramic, Delphi 6 n'a pas non plus de système de gestion de fichiers autres que l'accès séquentiel ou l'accès direct par adresse binaire. Insuffisant pour des applications de gestion. Pour ma part, je me servirai maintenant de BDR pour mes programmes de gestion, tant en Panoramic qu'en Delphi.

Bonjour Klaus !


beau boulot, c'est vrai que cela manquait...

Je viens de tester ta démo contact et il y a un petit problème :
Je charge ton fichier dat et je crée un nouveau contact que je déclare en "amis".
Le flag "Amis" se retrouve sur le premier enregistrement de la base -> Denise....

PS :
Je viens de regarder les fichiers générés : il y a pas mal de données redondantes entre les fichiers.
il n'y aurait pas moyen de simplifier la chose (en stockant par exemple les données brutes dans un fichier et jouer ensuite qu'avec des index) ?

ALONSO Denise a au départ les flags "Professionnel" ET "Amis". La présence de cette cas pour Denise est donc normale. J'ai remplacé les fichiers de la BDR contact sur MyDrive par une nouvelle version contenant un nom supplémentaire que j'ai créé avec juste le flag "Amis".

Les 3 flags sont des cases à cocher, pas des options. Dans ce programme, un même contact peut ne pas avoir de flags du tout, un seul flag, deux flags au choix ou alors les 3 flags. Pour chaque flag, la relation adéquate sera créée et gérée par le programme.

En ce qu concerne les données redondantes: chaque fichier contient les données d'une TStringList triée de Delphi. Or, une telle liste a systématiquement une partie "name" qui sert de clé, et une partie "value" qui sert de données. Il est donc normal et indispensable que les noms des entitées soient répétées dans chacun de ces volets de la BDR, car sinon, l'ordre de tri serait différent pour chaque volet et varierait en plus avec la modification des données. Autant dire qu'il sera impossible de s'y retrouver.

Quant à l'utilisation d'indices: je l'avais essayé au début, mais c'est impossible. Justement, puisque ces listes sont triées, un ajout d'une entité intercale la nouvelle entité à l'endroit déterminé par l'ordre de tri. Donc, tous les indices des entités suivantes se décalent. Impossible à gérer. J'ai donc choisi d'avoir une notion d'identifiant que j'appelle ID. Dans le fichier *.hdr (entête), il y a une ligne qui donne le dernier identifiant utilisé. Chaque création incrémente cette valeur et crée l'entité avec cet identifiant. On voit l'identifiant dans le volet *.nam comme donnée derrière le nom de l'entité, et dals le volet *.id (indexe inverse) comme clé avec le nom de l'identité comme donnée.

Pour établir les relations, cela se passe dans le volet *.rel. On y trouve pour chaque entité, la liste des triades décrivant le lien par rapport aux deux autres entités concernées. Et ce sont les ID des entités qui y sont utilisés, pas les indices.

L'avantage des volets différents, c'est de pouvoir sauvegarder seulement les parties ayant été modifiées, sans avoir à tout réécrire. Ce sera sensible pour des bases plus larges. Evidemment, pour 3 ou 4 entités, cela reste transparent.

Je suis en train de rajouter un volet supplémentaire pour gérer les ensembles. Ce sera similaire au volet *.rel: le nom des entités suivi de la liste des IDs de entités élément.