Une alternative au modèle relationnelCe document expose les grandes lignes du modèle d'organisation des données dans Storga, ainsi que les conséquences pratiques qui en découlent. Description du modèleLes fichesLa principale entité de stockage dans Storga est la fiche. Une fiche est très semblable à un formulaire papier. Par exemple, une fiche peut contenir une facture. Contrairement à un tableur, le programme n'est pas une formule associée à chaque champ, mais un programme global pour la fiche, ce qui facilite la relecture. Les étatsUn état est un tableau obtenu en spécifiant le type de fiches à collecter, la ou les zones de l'arborescence où les chercher, une éventuelle formule de filtrage pour spécifier plus finement quelles fiches doivent être collectées, les champs à collecter, éventuellement certains champs à calculer au moment de la collecte, une formule permettant de spécifier dans quel ordre afficher le résultat, etc. Les états peuvent aussi contenir en tête des champs permettant de paramétrer l'affichage. La mécanique : Un modèle par propagation des changementsTout d'abord, une fiche Storga contient à la fois les données et la mise en page, et le ou les programmes qui définissent les automatismes. Avec Storga, une fiche est complète, comme dans le cas d'un document papier ; elle n'a pas besoin d'une application extérieure pour l'afficher ou l'éditer. Ensuite, avec Storga, les états stockent en permanence leur contenu. Analyse comparativeLe véritable challenge pour un modèle de base de données : les relations n-nC'est là que les bases de données non relationnelles se cassent habituellement le nez. C'est ce qui justifie le succès historique du modèle relationnel, qui a évincé tous les autres, et qui est le reflet d'une supériorité technique objective, par opposition aux nombreux cas où le succès est le résultat de paramètres non techniques. Pour compendre ce qu'est une relation n-n, reprenons le cas des factures. Avec une base de donnée non relationnelle, construire une fiche article nécessite de reparcourir l'ensemble des factures, donc effondre très rapidement le système. La beauté du modèle relationnel, c'est que pour pouvoir obtenir efficacement les fiches articles, il suffit d'ajouter (ce que le système fait généralement tout seul) un index secondaire sur la table. Avec Storga, on va créer un état de tous les articles commandés dans toutes les factures, puis on va définir des fiches articles, et le programme de chaque fiche article va la remplir en parcourant l'état. La réduction de la complexitéAvec Storga, les données affichées à l'écran sont en correspondance directe avec ce qui est stocké. C'est le résultat de ce qui a été décrit plus haut : une fiche Storga contient à la fois les données et les informations de présentation, donc ne dépend pas d'un programme extérieur, et un état stocke ce qu'il affiche. De ce fait, si un utilisateur désire automatiser ce qu'il sait faire à la main, en quelques clics il va pouvoir déterminer le nom des champs qu'il souhaite utiliser, le code du formulaire dont il veut extraire des données, etc. À l'inverse, avec le modèle relationnel, quand on voit un champ a l'écran, pour pouvoir l'utiliser dans un nouvel automatisme, il faut trouver le programme qui affiche le dit formulaire, le comprendre, et éventuellement comprendre aussi les sous programmes qui ont servi à calculer le dit champ. Ainsi, avec Storga, le dialogue entre un utilisateur et un développeur est simple et immédiat puisqu'ils parlent de la même chose quand l'utilisateur montre à l'écran et que le développeur note les références des champs. Tandis que dans le modèle relationnel, il y a tout un travail de transposition : l'utilisateur continue à monter à l'écran, mais le développeur doit traduire cela en plongée dans le modèle relationnel, ou en calculs à effectuer pour reconstruire la donnée vue. En corollaire, avec Storga, un utilisateur formé à Storga peut adapter sans problème un système existant, car ce qu'il voit est la base pour programmer de nouveaux automatismes, ou modifier la structure. Avec le modèle relationnel, il faut comprendre l'architecture de l'application et le modèle relationnel sous-jacent, qui ne sont visibles ni l'un ni l'autre par l'utilisateur, et peuvent être très complexes même si au final l'automatisme ou la modification souhaitée sont mineurs. Migration des donnéesEncore une fois, avec Storga, une fiche contient à la fois les données et la structure de la fiche permettant de les afficher. De fait, quand on veut faire évoluer une activité, bien souvent on modifie la structure des fiches qui seront créées à l'avenir, sans pour autant modifier les fiches existantes. C'est encore plus vrai dans le cas de la réunion de deux sites. Avec Storga, on pourra faire évoluer progressivement les fiches utilisées de part et d'autre, sans pour autant avoir à effectuer une impossible conversion de l'existant. À la fin, on aura des anciennes fiches, des nouvelles, exactement comme avec une organisation papier, et cela ne posera pas de problème majeur. La niveau fonctionnel : évènements contre transactionsPour finir, prenons de la hauteur en décrivant le modèle de description de l'activité implicite pour chaque modèle de stockage des données. Avec le modèle relationnel (stockage), la modélisation naturelle de l'activité est le stockage de la position actuelle. Ceci est à la fois le résultat d'une fonction très puissante et une limite du modèle relationnel. La fonction très puissante, c'est la notion de transaction qui permet par exemple de débiter un compte et en créditer un autre de manière atomique, c'est à dire que soit rien, soit tout sera effectué, mais pas la moitié. Cela permet de garantir la cohérence de la position actuelle. Avec le modèle Storga (stockage), la modélisation naturelle de l'activité est le stockage de l'ensemble des fiches ou chaque fiche est le compte rendu direct d'un évènement. Ce qui rend cette approche naturelle en Storga, c'est que si l'on a besoin de définir des centaines de type de fiches pour modéliser directement les centaines de type d'opérations possibles au cours du temps, cela ne pose pas de problème particulier, alors qu'avec le modèle relationnel, ce serait un cauchemard de devoir maintenir les centaines de programmes pour pouvoir éditer les centaines de type de fiches. Dit autrement, c'est parce que réaliser et surtout maintenir les programmes qui permettent d'éditer les différents types de fiches coûte très cher qu'avec le modèle relationnel, on a tendance, pour limiter la quantité de programmes à écrire, à chercher à coder la position actuelle plutôt que l'ensemble de l'historique des opérations. ConclusionLe modèle de données de Storga présente deux avantages majeurs par rapport au modèle relationnel :
|