Formats de sauvegarde

Parmi les reproches que l'on pouvait adresser à feu SIPINA, il y avait : (a) l'impossibilité de garder une trace des traitements qui ont été réalisés ; (b) et lorsqu'on a pris la peine de la décrire quelque part sur un bout de papier, la nécessité de redéfinir l'analyse déjà réalisée en cliquant dans le bon ordre sur les menus appropriés.

Avec la description des traitements sous forme de diagramme, ces deux écueils ont été facilement dépassés par un nouveau format de sauvegarde : il est dorénavant possible de conserver la succession des analyses mises en places, avec les paramètres associés ( !) ; puis de les relancer automatiquement par un simple clic de souris après avoir chargé le diagramme.

Seule la description du diagramme - le programme en quelque sorte - est sauvegardée, les résultats en revanche ne le sont pas. Deux formats sont disponibles, ils répondent à des exigences différentes.

Description binaire du diagramme de traitements (*.bdm)

Ce format binaire intègre dans la sauvegarde les données qui ont été importées. Le fichier est lisible uniquement par TANAGRA.

Son principal avantage est que les données étant importées une fois pour toutes, le chargement du diagramme en mémoire à la prochaine exécution est très rapide. Sur le fichier COVTYPE par exemple, avec 581000 individus et 55 variables, le temps de chargement est de 2 secondes (Pentium IV - 1,5 Ghz - 256 MB).

A l'opposé, le principal inconvénient est que les traitements sont définitivement définis sur l'ensemble de données qui é été importé. Si les données sont mises à jour, par adjonction de nouveaux individus par exemple, il faudra de nouveau procéder à l'importation, puis à la redéfinition du diagramme.

Ce format de sauvegarde est à privilégier si : (a) les données ne sont pas susceptibles de modifications ultérieures ; (b) si le temps de chargement est un enjeu important.

Description textuelle du diagramme de traitements (*.tdm)

Ce format, dérivé du format INI de Windows, décrit dans un fichier texte le diagramme de traitements. Le fichier est donc lisible avec un simple éditeur de texte.

Un exemple de fichier (*.tdm) sur la base IRIS
[Diagram]
Title=Default title
Database=D:\DataMining\Databases_for_mining\Iris\iris.txt

[Dataset]
MLClassGenerator=TMLGenDataset
successors=1
succ_1=Define status 1

[Define status 1]
MLClassGenerator=TMLGenFSDefStatus
target_count=0
input_count=4
input_1=sep_length
input_2=sep_width
input_3=pet_length
input_4=pet_width
illus_count=0
successors=1
succ_1=Principal Component Analysis 1

[Principal Component Analysis 1]
MLClassGenerator=TMLGenCompFactPCA
nb_axis=2
successors=0

Il y a plusieurs avantages : (a) les données sont simplement référencées dans le fichier de sauvegarde, si elles sont mises à jour, la prochaine exécution utilisera la nouvelle version des données et produira des résultats automatiquement à jour ; (b) le fichier est au standard INI , il est possible, pour les fondus de bidouille, de le manipuler directement, et ainsi de définir, hors TANAGRA, des nouvelles chaînes de traitements.

On peut voir ce format comme une sorte de script permettant de décrire les traitements. C'est néanmoins très embryonnaire et les contrôles sont inexistants. Une des extensions possibles justement est de pouvoir décrire les diagrammes à l'aide de fichiers XML. La structure arborescente s'y prÍte à merveille, et si la DTD est définie convenablement, il est dès lors possible de valider de manière externe, sans chargement dans TANAGRA, le fichier de description des diagrammes de traitements. (ndlr : avis aux amateurs...)

Le principal inconvénient de ce format de sauvegarde est la nécessité de ré-importer les données à chaque exécution de la chaîne de traitements. Si on reprend l'exemple COVTYPE, 4 minutes sont nécessaires pour importer les données, avant toute exécution des opérateurs de calculs.


Dernière modification : 12 janvier 2004.