ABIS Infor - 2014-03

Concernant les formats - et l'importance des métadonnées

Kris Van Thillo (ABIS) - 01 Mars 2014

Abstrait

Sans doute, vous avez déjà dû exporter des données d'une application vers une autre. Comment l'avez-vous fait? Quelles sont les hypothèses de travail que vous avez observées, et donc, les choix que vous avez faits? Est-ce que vous avez par exemple pensé au métadonnées?

Le contexte

Il est souvent utile - il est nécessaire - de transférer des données générées par une application vers une autre; considérez par exemple vos extraits banquaires hebdomadaires. Vous les sauvegardez sur papier, sous forme électronique (pdf) ou peut-être dans un format utile pour les intégrer dans une structure feuille de calcul pour pouvoir ainsi mieux analyser vos dépenses?

Dans un monde idéal, toutes les données peuvent être échangées entre différentes applications sans problèmes; le format ou la structure des fichiers utilisés par une première application est donc compatible - voire identique - au format utilisé par une deuxième application! Mais un monde idéal n'existe pas!

L'importance des métadonnées

Pour échanger des données entre applications spécifiques - c.à.d faire interpréter ces données par une application externe, tierce - il est d'abord nécessaire de bien décrire d'une façon détaillée la signification de telles données. C'est en se basant sur cette description que l'application tierce doit en effet interpréter (et si nécessaire convertir) les données vers un format interne. La création d'une telle description de données - la documentation des données - est la responsabilité de l'application source; l'application source est donc responsable pour créer des métadonnées.

Une métadonnée est donc une donnée servant à définir ou décrire les caractéristiques d'une autre donnée quel que soit son support (papier ou électronique). Notez bien que des métadonnées ne sont pas utiles uniquement dans un contexte par exemple d'échange de données; elles sont aussi nécessaires pour faciliter la recherche de données et fichiers (une recherche sur un nom d'auteur, sur une date de création, ...).

Une distinction peut être faite entre des métadonnées de nature 'descriptives' et 'techniques':

  • descriptives, c.à.d. liées à la signification, la description sémantique, d'une donnée - sa définition;
  • techniques, c.à.d. liées à l'interprétation technique d'une donnée, les conventions (d'encodage) et les formats utilisés - description technique donc des données. Ceci peut par exemple inclure une indication du codepage utilisé.

Voici quelques exemples.

Exemple 1.

Donnée - '07:02:02'

  • métadonnée descriptive: il s'agit d'une date de journalisation d'une vente
  • métadonnée technique: description d'encodage de l'élément #mois:#jour:#années après 2005

Il n'est pas possible d'interpréter correctement cette date de journalisation - le deux juillet 2007 - si on ne dispose pas des métadonnées techniques décrites ci-dessus.

Exemple 2.

Ligne de données - '01/02/2004;G;700000 ;VENTES;Cours 100;0.00 ;3 500.00 ; ;; '

Supposons qu'on dispose uniquement de métadonnées descriptives - la ligne représente une écriture d'une journalisation comptable. Il est maintenant important de bien interpréter soigneusement les données.

Il s'agit apparemment d'une journalisation écrite le premier février 2004, liée à une vente d'un cours, valeur hors-TVA de 3500 EUR. On a apparemment choisi comme séparateur décimal le point, et non pas une virgule. En plus, comme séparateur de groupe, on a retenu un blanc, et non pas un point, ou rien. Une notation plutôt anglo-saxonne, n'est-ce pas? N'est-il donc pas nécessaire, dans ce contexte-ci, de réévaluer la date de journalisation au début de la ligne? Est-ce qu'on est encore vraiment sûr qu'il s'agit du premier février, et non pas du deuxième janvier? Ou est-ce que la présence des '/' au lieu des '-' est assez 'européenne' pour nous permettre de conclure qu'il s'agit bien du premier février?

Conclusion: en réalité, nous ne savons pas interpréter la date sans métadonnées techniques.

Formats d'échange de données

Dans la réalité, le nombre de formats utilisés pour échanger des données - exportation et importation de données - est assez limité. Il est important de bien considérer la relation existant entre le choix du format spécifique d'échange et la préservation - ou non - de métadonnées. Concrètement: est-ce que après exportation des données les métadonnées nécessaires pour une importation automatique et effective sont bien disponibles dans le fichier d'exportation (ou dans un autre fichier externe).

Quelques formats fréquemment rencontrés sont introduits dans ce qui suit.

  • le format XLS(X) - structure feuille de calcul MS Excel

Utilisation fréquente, facile - si ce n'est que parce que le résultat de l'exportation est typiquement disponible en MS Excel automatiquement (lecture et interprétation automatiques). Métadonnées de l'application source sont typiquement considérées au moment de la création du fichier d'exportation: en-têtes de colonnes, définitions et structures des champs - types de données.

  • le format CSV - format séparateur de champs/lignes

Format probablement le plus fréquemment rencontré. Format très difficile à utiliser dû à la présence minimale de métadonnées (probablement limité aux en-têtes de colonnes). Le manquement de toutes métadonnées techniques nécessite une interprétation individuelle et manuelle du contenu (des données) avant l'importation même.

Difficulté additionnelle: le choix du séparateur (champs, ligne) à utiliser, ainsi que la problématique de l'interprétation du séparateur. Choix logique: la barre verticale '|'.

  • le format texte - champs à longueur fixe

L'interprétation du contenu des fichiers texte n'est pas évidente du tout - présence des métadonnées probablement limitée aux en-têtes de colonnes. L'interprétation du contenu doit se faire manuellement; il est difficile de faire la différence entre des données de taille fixe et les données de taille variable. Evitez ce format; préférez le format CSV si possible.

  • le format PDF - format d'affichage

Format inapprorié pour l'échange de données entre applications.

  • le format XML - 'Extensibe Markup Language'

Format intéressant; la présence de données et métadonnées - c.à.d. les tags - nous permet de charger des données comme s'il s'agissait de fichiers CSV. En plus, le format XML est assez ouvert pour nous permettre de générer de l'information additionnelle concernant la description technique du contenu (les données) du fichier. Il dépend des fonctionnalités de l'utilitaire si cette option est disponible ou non.

Fichiers XMLs sont typiquement plus larges.

Typiquement, d'autres formats d'échange de données sont disponibles. Ceci dépend surtout des technologies utilisées, et de la façon dont l'exportation et l'importation des données est organisée.

Pour conclure

La qualité des données et du processus d'échange des données entre vos applications dépend surtout des facilités offertes pour décrire et documenter la signification de vos données. Choisissez toujours - si possible - des formats d'échange de données avec perte minimale de métadonnées. Ceci facilite le traitement des données après l'exportation.

Pour plus d'information concernant la qualité des données traitées par les applications, et une discussion approfondie traitant l'importance des métadonnées, nous vous invitons à suivre le cours 'Concepts data warehouse'.