Une architecture d'une élégance rare
A la différence d'une base de données classique qui est modélisée en fonction du problème à
résoudre, notre BDCG (Base de Données à Concept Générique) est capable de gérer "a priori" toutes les données provenant des événements
et transactions de la vie réelle.
On cherchera ainsi en vain une table "Clients" dans notre base de données générique, puisqu'on ne saurait figer ainsi
la notion de "Client". Cette notion étant très fluctuante selon le contexte, on parlera plutôt de "Partenaire" ayant
un ou plusieurs "Arrangements" avec un autre "Partenaire", "Arrangements" conclus sous certaines "Directives" et "Conditions",
liés à certaines "Ressources" et "Adresses".
Pour ce qui est de l'identification des "Partenaires" ou "Ressources", on utilise un assemblage ordonné de composants de types identiques ou
différents. Ainsi, un "Partenaire" de type «Individu», peut avoir un nom officiel composé de
plusieurs noms de famille, d'un prénom usuel et de plusieurs prénoms, voire d'un surnom. L'historique
de toutes les modifications de noms est conservé, donnant ainsi la possibilité de retrouver les "Partenaires"
par leurs noms actuels ou anciens. Cette façon particulière de gérer les noms est une des caractéristiques de notre base de
données à modèle générique. Elle permet d'appréhender, sans modification de la structure de la base de
données, toutes les manières de nommer une personne dans le monde réel.
La conception d'une telle base de données repose ainsi sur moins
d'une dizaine d'entités.
Les principales sont :
- le Partenaire est l'acteur principal de la vie réelle. S'il est souvent
une personne, il peut tout aussi bien être une organisation, une entreprise, une
association, un État ou une collectivité.
- l'Arrangement est à la base de toutes relations formelles ou informelles entre
Partenaires. Il peut représenter aussi bien un mariage qu'un contrat de vente,
une commande d'un client qu'un pacte successoral.
- la Ressource représente tous les objets
que nous côtoyons dans la réalité. Ce peut-être un pétrolier ou une feuille de
papier, un catalogue de produits, une habitation, une image ou un son.
- l'Événement est la seule entité qui est
en relation avec toutes les autres. C'est normal, car tout dans la vie est
«Événement». Par ex. arrivée d'un courrier, demande d'un tiers, impression d'une facture, communication, etc..
- l'Adresse est prise au sens large et
permet de décrire les situations géographiques d'un Partenaire ou
d'une Ressource (domicile, lieu de stockage) aussi bien que leurs situations
logiques (no de téléphone, chemin d'accès à un fichier, etc..).
Les principales caractéristiques d'une telle base de données sont:
- Une structure indépendante des données à traiter, partant une structure stable
- La possibilité de représenter des données très complexes avec un modèle de données
simple
- Une notion très puissante de préexistence des adresses. Une adresse (par ex. une
habitation), tout comme dans la réalité, n'existe qu'une seule fois dans la base données
- Une notion, tout aussi puissante, d'aires géographiques permettant de décrire des
quartiers, aires de représentant et de stockage, etc.
- Des relations qualifiées, c'est-à-dire la possibilité de non seulement lier les entités, mais
encore de décrire le type de lien, sa durée de vie, voire son intensité
- L'existence de relations récursives sur les entités de base. On peut ainsi par ex. décrire
la généalogie complète d'une famille de façon très simple
- Une notion d'unité de mesure utilisant elle aussi des relations récursives enrichies de
possibilités de conversion et pouvant servir à créer, par exemple, une puissante tabelle
des cours
- L'implémentation des noms et des adresses permet de créer à l'intérieur d'une
entreprise une gestion cohérente de toutes les «adresses» (au sens où on l'entend en
général), et ce indépendamment de la structure adoptée pour ces dernières par les
différents départements de l'entreprise
- L'introduction de distinctions importantes : par ex., dans la gestion des ventes, on fait la
distinction entre le produit (description d'un article avec ses caractéristiques nominales
telles que poids, dimensions, volume, etc.) et l'article que l'on vend, qui lui, possède ses
caractéristiques propres (poids mesuré, no de série, etc.). Cet article hérite cependant
du produit les caractéristiques non redéfinies !
