Editions ENI Livres | Vidéos | e-Formations
Manipulation de données
Introduction
Ce chapitre n’était pas franchement prévu au départ, ce n’est qu’en cours de rédaction qu’un langage tel que Python a semblé utile pour effectuer ce genre de chose. Il est consacré, comme son titre l’indique, à la manipulation de données d’un format vers un autre ou d’une base de données vers une autre.
Bien souvent, il faut lire des données quelque part pour les transmettre dans un autre format reconnu par les utilisateurs et/ou les développeurs. Et quand les outils d’origine ne le permettent pas, Python comble ce manque.
Remarque de l’auteur : « Au siècle dernier, je codais beaucoup de scripts pour transformer des fichiers EBCDIC en ASCII, à vérifier des fichiers générés par des "MainFrames" utilisant le langage COBOL ou ces bons vieux fichiers interbancaires. De nos jours, c’est du JSON vers le CSV, du XML vers du HTML ou de base PostGreSQL à base Oracle. »
SQLite en mémoire
SQLite est une petite base de données, mais elle a tout d’une grande. Et donc, tant que vous n’avez pas besoin de gérer des accès concurrents, cette petite base de données peut rendre de nombreux services.
D’abord, elle est intégrée à Python, ce qui facilite les choses. Mais en plus, il n’y a rien à installer, il suffit de créer le fichier de la base de données, et ce dernier peut très bien être stocké en mémoire. D’ailleurs, il suffit d’ouvrir la base avec le nom ":memory:" pour ne plus avoir besoin de fichiers sur disque.
Cela suppose que l’on dispose d’un peu de mémoire RAM si l’on doit traiter de gros volumes, mais cela peut se révéler très pratique quand, par exemple, on veut traduire des données d’un format vers un autre.
L’origine de cet exemple prend sa source dans l’environnement professionnel de l’auteur où ont été extraites des informations provenant d’un outil : JIRA Service Desk (qui sert à gérer un support client), pour les formater dans un format acceptable pour les collègues de bureau : le format CSV.
JIRA Service Desk est un outil payant et il est difficile de trouver un accès sur une base de données de test, si jamais cela existe. Donc, après quelques recherches, pour illustrer ce chapitre, il a été décidé de transformer des données JSON en format CSV en passant par une base de données SQLite en mémoire.
Ce qui est quasiment le même principe que l’origine de cet exemple.
1. La mission
La source des données est une base de données lisible par tous : https://fr.openfoodfacts.org/
C’est une base collaborative et elle contient 652 046 produits au moment où ces lignes sont écrites.
Notre mission, si vous l’acceptez, est de trouver les produits français contenant un ingrédient précis et de nous fournir des informations sur ces produits.
L’ingrédient est la taurine, ingrédient bien connu du fait de sa présence dans certaines boissons, et nous voulons des informations telles que :
-
Le code EAN du produit
-
Son nom
-
La quantité de vente
-
La marque...
SMS vers HTML (ou autre)
S’il y a bien un domaine dans lequel les choses ont évolué trop vite, c’est bien la téléphonie mobile (le terme smartphonie est aussi appréciable).
Ces petites machines, appelées "smartphones", contiennent énormément de données essentiellement personnelles. Parmi ces données se trouvent les SMS (Short Message Service ou Service de message court).
Ces SMS contiennent beaucoup d’informations, et parfois il peut être intéressant de les extraire pour les trier et les convertir vers un format plus pratique informatiquement parlant.
Attention, cela ne concerne que les SMS et non les MMS (Multimedia Messaging Service ou Service de messagerie multimédia), qui apparemment sont gérés différemment par le téléphone et/ou l’opérateur.
Le but de cette section est de vous décrire une méthode qui fonctionne essentiellement avec les smartphones Android, mais celle-ci est sans doute également applicable à d’autres types de smartphones.
Cette méthode repose sur trois étapes :
-
Étape 1 : extraction des SMS de l’appareil
-
Étape 2 : transformation de ces SMS
-
Étape 3 : conversion
1. Extraction des SMS
Pour le coup, nous avons utilisé un outil très pratique pour sauvegarder certaines données du téléphone : l’application ’SuperBackup’ que l’on trouve sur le Google Store.
Celle-ci permet tout simplement de sauvegarder les SMS sur le cloud (Google Drive) ou d’envoyer le fichier généré par courrier électronique.
2. Transformation des SMS
Le fichier généré est au format XML :
<?xml version="1.0" encoding="UTF-8"?>
<allsms count="3507">
<sms address="+3355512345" time="11 janv. 2020 08:57:12"
date="1578729432385" type="2" body="Ok" read="1" service_center=
"" name="DARK VADOR" />
...
<allsms> et il est structuré comme ceci :
<allsms count="nombre de sms dans le fichier">
<sms address = "" time = "" date = "" type = "" body =""...D’une base à l’autre
L’avantage d’un langage comme SQL est qu’il est à peu près standard. Il est tout à fait possible de générer du code SQL et de s’en servir pour transférer des données d’une base à une autre.
Si les bases sont du même éditeur, cela ne pose pas de problème. Mais quand il s’agit de bases différentes, ce n’est plus la même chose. Et c’est là qu’un langage comme Python peut s’avérer très utile.
En effet, pourquoi ne pas utiliser la capacité de Python à se connecter sur différentes bases de données pour transférer directement des données d’une base à l’autre ?
Voici un exemple qui illustre ce principe. Il faut cependant décrire un peu le contexte et les acteurs de cet épisode.
1. Le contexte
D’un côté, un logiciel de gestion des incidents (JIRA Service Desk) où se trouve le détail du temps passé par les collaborateurs sur les tickets clients.
De l’autre, un ERP de gestion sous Oracle, qui ne connaît que très peu de formats d’importation et utilise un langage spécifique développé par l’éditeur, langage fortement orienté vers l’informatique de gestion, mais très peu ouvert sur le monde et encore moins sur les bases de données libres.
Résultat : les développeurs ne peuvent qu’utiliser l’ancestrale technique de génération du fichier ASCII pour exporter puis importer les données. Cela a au moins le mérite de fonctionner sans surprise, mais maintenant que l’on connaît Python, il y a peut-être une autre solution, plus subtile, dont voici le principe de base.
D’un côté, nous avons une table sous PostgreSQL et aimerions en faire une copie régulièrement sur la base Oracle, afin que les développeurs puissent effectuer des mises à jour sur d’autres tables de la gestion de l’entreprise.
Nous ne faisons que lire la base PostgreSQL, donc pas de souci. Par contre, pour la base Oracle, il faudra passer par une table intermédiaire dédiée, avec un utilisateur dédié (ou schéma) dédié...
Résumé
La manipulation de données devient de plus en plus une nécessité de nos jours. Pendant des années, nos serveurs ont stocké et archivé des volumes considérables de données qui bien souvent ne sont pas utilisées. C’est un grand classique de l’informatique de gestion. Trop souvent, les données sont laissées dans l’outil principal, alors qu’il est évident que cela coûte cher de ne pas les archiver correctement.
Beaucoup de personnes se sont fait piéger par le volume des données. Au début, les tables ne font que quelques milliers de lignes, puis quelques centaines de milliers… et au bout de quelques années, des millions de lignes. Et là, il faut penser les traitements autrement.
En moyenne, une société conserve un ERP pendant sept ans et il faut parfois de un à trois ans pour migrer, entre la prise de décision et la mise en exploitation, d’une version à l’autre ou d’un ERP à l’autre. Et pendant ce temps, les données continuent de grossir.
Fut un temps, les outils de "business intelligence" étaient très chers et ne se justifiaient que dans une structure de société importante.Bien utilisés, ils permettent de synthétiser ou d’agréger certaines données en créant...
