Agrosup DN2A - La Data Par La Pratique

Initiation à la data
(par la pratique...)
© 2023 Atol Conseils et Développements Page 1 / 70

Objectifs
Mettre en œuvre une chaîne data de bout en bout, sur un cas d’usage simple
Intégration Stockage & Traitement Restitution

Objectifs
Intégrer / Entreposer / Restituer
Intégrer les données avec un outil ETL (PDI)

=> préparer les données afin de les rendre exploitables
Entreposer les données (PostgreSQL)

=> modéliser les données dans un format adapté
=> les insérer dans un entrepôt de données
Restituer les données (Microsoft Power BI)

=> mettre à disposition les données à des utilisateurs
métier, sous forme de dashboards interactifs, dans une
solution de dataviz

Objectifs



solution de dataviz

Le cas d’usage à traiter
Exploitation d’un jeu de données open data de l’INSEE

Données FLORES : emploi salarié en France (nb d’établissements et de postes
salariés)
https://www.insee.fr/fr/statistiques/4991205

Les données permettent d’avoir des indications précises sur le nb de salariés et
d’établissements en france, selon plusieurs axes :
➔
Axe temporel (annuel)
➔
Axe géographique (données à la commune)
➔
Axe activité professionnelle (NAF : nomenclature d’activité française)
➔
Axe tranche d’effectifs
Les fichiers sont téléchargeables sur le site de l’INSEE avec plusieurs niveaux de
consolidation disponibles pour les secteurs d’activité (A5, A17, A38, A88)

1ère étape – identifier et récupérer les fichiers nécessaires
➔
La commande de notre client : permettre aux utilisateurs métiers d’analyser les données
concernant le nb de salariés dans un tableau de bord interactif Power BI
➔
Les données doivent pouvoir être analysées selon les axes suivants :
➔
Géographique (département / région) : le niveau commune n’est pas nécessaire, les données
devront donc être agrégées au niveau département
➔
Temporel (par année)
➔
Tranche d’effectif
➔
Code d’activité A17 (possibilité d’agréger au niveau supérieur A5). Il n’est pas nécessaire d’avoir des
niveaux plus détaillés sur les codes d’activités (A38, A88…)
➔
On ne traite que les données de France métropolitaine, en excluant les données des
territoires ultra marins
➔
2 types de fichiers sont disponibles sur le site de l’INSEE : format Excel et CSV
➔
Le format CSV est plus facile à lire, car les tranches d’effectifs sont toutes présentes en colonnes,
alors que dans le fichier Excel les infos sont réparties dans plusieurs onglets (donc un peu plus de
pré-traitement).
➔
Les fichiers CSV sont moins lourds que les fichiers Excel

1ère étape – identifier et récupérer les fichiers nécessaires
Récupérer les
fichiers CSV des
années 2018,
2019, 2020.
Pour les postes
salariés, A17

2ème étape – comprendre comment est structuré le fichier CSV (prendre l’année 2020)
➔
Une analyse de la structure du fichier est nécessaire afin de voir comment sont stockées les
informations, et donc quelles règles de préparation de données doivent être mises en place
➔
Le fichier CSV comporte 163 colonnes et 34 981 lignes. Chaque ligne correspond à un COG (code
officiel géographique), soit une commune française
➔
Les 162 autres colonnes correspondent au nb de salariés, ventilé de plusieurs manières
➔
EFF_TOT : nb de salariés total pour la commune
➔
EFF_AZ à EFF_RU (17 colonnes) : nb de salariés pour chaque code A17
(Somme(EFF_AZ:EFF_RU)=EFF_TOT)

2ème étape – comprendre comment est structuré le fichier CSV
➔
Les colonnes suivantes décomposent les mêmes informations, par tranche d’effectif
➔
EFF_TOT_1_4 : nb de salariés total pour la commune et EFF_AZ_1_4 à EFF_RU_1_4 : tranche
d’effectif de 1 à 4 personnes (18 colonnes)
➔
EFF_TOT_5_9 : nb de salariés total pour la commune et EFF_AZ_5_9 à EFF_RU_5_9 : tranche
d’effectif de 5 à 9 personnes (18 colonnes)
➔
Et les tranches 10_19, 20_49, 50_99, 100_199, 200_499, 500P soit 8 tranches au total
➔
Soit 8 tranches x 18 colonnes = 144 colonnes par code A17 / par effectif

➔
Question : quelles sont les colonnes nécessaires et suffisantes pour effectuer le travail demandé ?

➔
Question : quelles sont les colonnes nécessaires et suffisantes pour effectuer le travail demandé ?
➔
Réponse : la colonne CODGEO et toutes les colonnes EFF_AZ_x_y, c’est à dire les colonnes qui
portent de l’information au niveau le plus bas (par code d’activité et par tranche d’effectif)
➔
Les colonnes de totaux sont inutiles, elles sont le résultat d’un calcul issu d’autres colonnes
➔
Totaux globaux par code A17 : on pourra les reconstituer en sommant tous les effectifs
➔
Totaux par tranche d’effectif : on peut les reconstituer en sommant tous les code A17 de la tranche
d’effectif

➔
Point à noter : les données sont stockées en colonnes, il faut donc les pivoter pour qu’un outil data
puisse les exploiter. En règle générale, les données stockées en base sont toujours normalisées.
normalisation
Détail du PIVOT :
Pivot sur l’année
Données normalisées
Données dénormalisées
dénormalisation
3ème étape – définir l’algorithme du traitement de préparation des données
Tout traitement de préparation de données correspond à l’implémentation d’un algorithme
Il est possible d’implémenter cet algorithme avec un outil ETL, un script python (ou R), du code JAVA, ou
des fonctionnalités propres à un outil de dataviz => par exemple Power Query dans Power BI
Détaillons l’algo pour notre besoin de préparation de données :
1. Définir le fichier CSV comme flux source
2. Extraire les données et récupérer les colonnes utiles
3. Extraire l’information concernant le département
4. Filtrer les données pour ne conserver que les départements de la France métropolitaine (donc
exclure les départements 971, 972, 973, 974)
5. Pivoter les données afin de constituer un data-set normalisé adapté au besoin :
➢ Code Geo (donc Dpt) / Année / Code Activité A17 / Tranche effectif / Nb salariés
6. Agréger les données par département (sommer le nb de salariés)
L’ETL Pentaho Data Integration nous permet de répondre facilement au besoin, car il dispose de toutes les
étapes de traitement nécessaires
Aucune ligne de code ne sera écrite pour effectuer le traitement !

Mise en œuvre de l’ETL
Pentaho Data Integration

ETL: Les concepts
Signification de l'acronyme "E.T.L." :

Extraction de données depuis des sources diverses : bases de données, fichiers
(xml, excel, csv), web services, progiciels...
Transformation des données

Loading: Chargement des données traitées dans des cibles diverses

ETL: Les concepts
Transformation de données :
Sélection et altération des colonnes d'un flux de données (conversion de type,
renommage des colonnes, application de patterns...)
Ajout de nouvelles colonnes (constantes, calculées...)
Jointure de données en provenance de sources homogènes où hétérogènes
Validation et filtrage de données
Routage de flux de données où fusion (merge)
Agrégation de données (count, somme, moyenne, min, max...)
Normalisation & Dénormalisation de flux de données (pivot)
Mapping sur les données (correspondances)
"Split" de colonnes (découpage)
Création de clées techniques (Surrogate keys)
Mise à jour de type Dimension Lente (Slow Changing Dimension)

ETL: Les concepts
Intérêts d'un ETL :

Aucune écriture de code (ou presque)
Approche visuelle des traitements d'intégration de données
Planification et notification des traitements
Référentiel partagé pour les équipes de développements...
Intérêts d'un ETL Open Source :

Iso-fonctionnel pour le traitement de données
Enrichissement des fonctionnalités par le client (plugins)
Coûts de licence moins élevés que des ETL propriétaires

PDI : aspects techniques
PDI (anciennement Kettle) est un moteur de transformation ETL : le code qui effectue les
traitements existe déjà sous forme compilée. Les développeurs définissent donc des flux et
l’outil se sert de leur configuration pour effectuer le travail
Les traitements sont enregistrés sous forme de fichiers au format XML :
➔
KTR pour les transformations (kettle transformations)
➔
KJB pour les jobs (kettle jobs)
PDI est multi-plateforme et s'installe facilement par la décompression d'un fichier zip en
environnement :
Linux / Unix
Windows
MacOs
De nombreux SGBD sont supportées en lecture/écriture (plus de 40) :
Oracle, MS SQL Server, IBM DB2, AS/400, PostgreSql, MySql, SAP...s

L'architecture de PDI
Traitement à exécuter
Exemple: intégration d'un fichier plat en base de
données
« Kettle Engine » :
Moteur de transformation de données (lib. Java)
Traitements conçus avec Spoon :

=> Transformations (Extraire, Transformer, Loader)
=> Tâches ("Jobs") pour séquencer et piloter les transformations
Programmes en ligne de commande :

=> Kitchen et Pan (lanceurs batch)
=> Carte (Web Listener)

Client de conception graphique Spoon
Stockage des traitements :

=> Fichiers XML
Déprécié

PDI - Installation et Prise en main
PDI nécessite l'installation d'une machine virtuelle JAVA : soit un JRE (Java Runtime
Environment), soit un JDK (Java Development Kit).
PDI 8 nécessite Java 8
Une variable d'environnement JAVA_HOME (ou PENTAHO_JAVA_HOME) doit être définie
dans le système d'exploitation, sous Windows depuis les « propriétés système » :

La mémoire allouée à Spoon peut être augmentée en modifiant le paramètre -Xmx dans le
fichier de lancement « Spoon.bat » (.sh)
Cette modification peut s'avérer nécessaire pour des traitements volumineux (pb de lenteurs
ou plantages en raison de saturation mémoire « out of memory »)

REPERTOIRES de KETTLE

Principe de déploiement avec Kettle
L'utilisation des variables d'environnement est essentielle pour assurer le passage d'un
environnement de développement vers un environnement de production :

Principe de déploiement avec Kettle
Dès qu'un paramètre doit être modifié lors du passage en production (par exemple un chemin
fichier, une configuration d'accès à un SGBD...) => créer une variable d'environnement

Transformations et Jobs
PDI permet la gestion de 2 types de traitements : les transformations et les jobs
Job (Tâche)
Transformation
Une transformation est un traitement de données Un job permet d'effectuer des tâches
qui peut toujours être représenté par l'acronyme ETL : d'administration et de séquencement non liées à un
extraction(s), transformation(s), chargement(s) traitement ETL de flux de données comme ceux gérés
dans une transformation.
Des liens ("hops") entre les étapes ("steps")
permettent la circulation de flux de données sous Un job permet d'effectuer des tâches de
forme de lignes ("records") récupération et d'envoi de fichiers, d'exécution
conditionnelle, de notification par mail, de copie,
Chaque ligne comporte toujours un nombre défini d'archivage, de vérification d'existence d'objets
de champs ("fields") dans un ordre donné et avec un (fichiers...), de lancement de scripts SQL ou shell...
type précis (String, Integer, Date...)
Un job possède un fonctionnement séquentiel. Les
L'exécution d'une transformation s'appuie sur le étapes d'un job sont toujours traitées l'une après
parallélisme. Il n'est donc par exemple pas possible de l'autre (un job possède donc un début et une fin et
définir dans une transformation un ordre de commence toujours par une étape "START")
chargement préférentiel lorsqu'il y a plusieurs cibles
La séquentialité d'un job est toujours employée pour
enchaîner des transformations dans un ordre précis.
Cet ordre est souvent déterminé par des règles métiers
(contraintes de clées étrangères entre les tables par
exemple) ou d'autres facteurs.

Installation de PDI
Fichier d'installation de PDI :
Le fichier "pdi-ce-8.3.0.0-371" (PDI 8.3) est disponible sur SourceForge :
https://sourceforge.net/projects/pentaho/files/Pentaho%208.3/client-tools/pdi-ce-8.3.0.0-371.zip/download
Installation de Kettle
Dézipper l'archive et créer un raccourci sur le bureau
Dans le répertoire extrait, double-cliquer sur Spoon.bat pour lancer le client de
conception graphique :

Infos utiles - les types de données Java
Le langage Java utilise des types de données de référence qui correspondent aux types
manipulés par les SGBD :
Chaînes de caractères : String
Nombres entiers: Integer
Nombres décimaux: Number et BigNumber
Booléens (vrai/faux) : Boolean
Dates et Heures : Date et TimeStamp
Données binaires : Binary
Certains types de données peuvent se présenter sous différents

formats de présentation (« patterns ») :
"20/12/2010", "20101220", "2010-12-20", "Lundi 12 Déc. 2010" représentent la même date
"10 586,50", "10586,5", "10,586.500" représentent le même nombre décimal

Infos utiles - les patterns dates et numériques
Données numériques
Exemple de format de sortie pour le nombre 99.55 :
Référence complète dans l'API java de Oracle :

https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/DecimalFormat.html
Données de type Date Exemple de format de sortie pour la date « 25 Décembre 2010 » :
3
dd/MM/yyyy : 25/12/2010
yyyy-MM-dd : 2010-12-25
Référence complète dans l'API java de Oracle :
https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/text/SimpleDateFormat.html

Aide en ligne
Pentaho Data Integration offre une aide contextuelle sur chaque étape de
transformation et de job :

Présentation de Spoon: le navigateur

Présentation de Spoon: la palette de création

Présentation de Spoon: le panneau de design

Présentation de Spoon: les statistiques d'exécution

Présentation de Spoon: les traces d'exécution

Présentation de Spoon: l'onglet « Prévisualiser » (nouveauté PDI 5)

Implémentation du traitement de préparation de données
Dans PDI, chaque étape a une

fonction très précise.
Ceci permet de comprendre et

maintenir facilement les
traitements, la logique étant
séquentiellement appliquée par
chacune des étapes pour
effectuer le traitement souhaité
NB : pour le traitement, on
prendra le fichier CSV de 2020

Le résultat :
La sortie du traitement doit produire ce data set.

On peut l’injecter dans excel pour effectuer
quelques vérifications par rapport au fichier
source
Notamment le contrôle du nb total de salariés !

Objectifs



solution de dataviz

Installation de la base PostgreSQL
Démarrer le serveur PostgreSQL portable en cliquant sur :
Le serveur démarre (ne pas fermer la fenêtre) :
Lancer les 2 commandes suivantes pour vérifier la présence de 4 tables dans la base de
données « agrosup » (il s’agit des tables du modèle en étoile qui va stocker les données) :
\c agrosup
\dt
Page 40 / 70
© 2023 Atol Conseils et Développements
La modélisation multidimensionnelle
La modélisation multidimensionnelle (OLAP), c'est mettre en œuvre une modélisation

spécifique permettant de relier les données et événements d'une même thématique entre
eux. Cette modélisation repose sur les « schémas en étoile » et/ou « flocons »
Un schéma en étoile permet de restituer les données à analyser (les faits) selon plusieurs
axes d'analyse (les dimensions)
Clients
Table de faits:
●
Ventes
Tables de
dimensions:
Magasins Produits ●
Clients
●
Produits
Ventes ●
Temps (qui passe..)
●
Secteurs commerciaux
●
Magasins
Réseaux
Temps
commerciaux
© 2023 Atol Conseils et Développements Page 41

Schéma en étoile
Un schéma en étoile (Star Schema) correspond à la modélisation la plus courante
d'un entrepôt de données. Un schéma en étoile comporte une ou plusieurs tables de
faits reliées à des tables de dimensions.
Les tables de dimensions possèdent des PK simples, tandis que les tables de faits ont
des PK composées (l'ensemble des FK constituées par les PK des tables de dimension)
Les données stockées dans les tables de dimension sont stockées dans la 2nde forme
normale, (donc dénormalisées avec de la redondance d'information des données)
L'avantage du modèle en étoile est sa simplicité du fait de l'absence de jointures
complexes

Schéma en flocons
Le schéma en flocon (Snowflake Schema) est similaire au schéma en étoile à ceci
près que les tables de dimensions sont modélisées sous la 3ème forme normale, le but
étant de ne plus avoir de redondance. Des tables avec des jointures apparaissent alors
avec un aspect en « flocons »
Le stockage au niveau des tables de faits est identique au schéma en étoile

"Star schema" versus "Snowflake schema"
Le modèle en étoile est simple à modéliser et à requêter, mais peut s'avérer gourmand
en terme de volumétrie et exigeant côté performances si on a des tables de dimensions
volumineuses (ce point est à modérer: c'est la taille des tables de faits qui compte)
Le modèle en flocon est plus compliqué à modéliser et à charger, mais se révèle moins
gourmand pour le stockage des données dans les tables de dimensions (3ème FN)
La décision d'employer l'un ou l'autre des schémas dépend surtout de la puissance du
système de stockage et de la typologie de l'outil de requête :
Les schémas en étoile sont préconisés si les outils de requête s'appuient directement sur le
modèle physique et si les requêtes utilisateurs peuvent être effectuées simplement
Les schémas en flocon sont plus adaptés aux outils de requête sophistiqués qui fournissent
une couche d'abstraction entre le modèle physique et le modèle métier présenté aux
utilisateurs finaux
Plus d'infos sur les avantages et limites du « snowflaking » sur Wikipedia:

http://en.wikipedia.org/wiki/Snowflake_schema#Benefits_of_.22snowflaking.22
Chez Atol CD, nous conseillons l'usage exclusif du modèle en étoile (éventuellement
avec une ou plusieurs dimensions floconnées pour certains cas de figures)

A retenir
Une table de faits peut contenir plusieurs millions de lignes.

La taille mémoire de chaque enregistrement doit donc être limitée au maximum pour des
raisons de performance. Ainsi toutes les clées étrangères de la table de faits (vers les tables
de dimensions) doivent être des nombres entiers.
Ces clées étrangères de la table de faits doivent permettre l'historisation des données. Pour
cela, on utilise le concept de ”clées techniques”, créées artificiellement et n'ayant aucun lien
avec les clées de production en provenance des applications métiers
En ce qui concerne la clée de la dimension temporelle, on utilise un nombre entier de la
forme yyyyMMdd. Cela simplifie les traitements de chargement des tables de faits et permet
rapidement d'identifier la date d'un enregistrement

Clefs techniques et dimensions lentes
Les dimensions à variation lentes (SCD) sont des dimensions du modèle en étoile qui contiennent des
attributs dont les valeurs peuvent changer au fil du temps.
Ce concept est particulièrement utile car il permet de suivre l'évolution des données descriptives des
données de la table de faits au fil du temps, particulièrement lorsque ces données ne sont pas
historisées dans les systèmes sources.
Le principe des dimensions à variation lente est de conserver un historique des changements de
valeurs des attributs d'une dimension, plutôt que de simplement les mettre à jour lorsqu'une nouvelle
valeur est disponible. Ceci permet ainsi d'avoir une vue plus complète de l'évolution des données au
fil du temps.
Il existe plusieurs types de dimensions à variation lente :

➔
Le type le plus simple est le type 1, dans lequel les anciennes valeurs sont simplement remplacées par
les nouvelles valeurs lorsque celles-ci sont disponibles (donc les anciennes valeurs sont perdues). Ce type
s’applique à des informations qui n’ont pas besoins d’être historisées (exemple : les n° de tél)
➔
Dans le type 2, une nouvelle ligne est créée chaque fois qu'une valeur change, avec une clé primaire
unique pour chaque version de la dimension.
➔
Dans le type 3 l’historisation s’effectue en colonne, avec une colonne pour stocker les anciennes valeurs
et une colonne pour les nouvelles.
Le type 2 est le plus couramment employé
Référence : https://en.wikipedia.org/wiki/Slowly_changing_dimension

Voici un exemple concret de mise en place de SCD, sur la dimension “client” du modèle en étoile
“suivi des ventes” présenté plus haut. Imaginons que le client “Michel Durand” change d'adresse.
Au début de l’année 2011 il quitte la Côte-d'Or (21) pour aller habiter dans les Alpes-Maritimes (06).
Afin que les résultats stockés dans la table de faits soient corrects, la dimension “client” doit stocker 2
lignes pour ce client, afin de conserver son historique d’adresse (soit 2 versions de ce client dans la
dimension) :
➔
une ligne lorsqu’il habitait dans le 21
➔
une autre ligne lorsqu’il habite dans le 06.
Pour chacune de ces versions est précisée la date de début et de fin de validité, ainsi qu’un numéro
de version, et éventuellement un flag “version courante : O/N”
La clef primaire de la table de dimension ne peut pas être l’identifiant métier CL-8554 issu de la base
de production (car celle-ci serait dupliquée en cas d’existence de plusieurs versions d’un client)
Une clef technique (tk pour technical key) est donc employée, et est artificiellement créée côté SID,
lors du traitement de chargement de l’entrepôt de données. Cette clef technique qui référence le
client dans la table de faits (et jamais la clef métier)

Avec ce mécanisme, les commandes pour ce client dans la table de faits seront automatiquement
catégorisées :
➔
sur la Côte d'Or (Bourgogne) jusqu'à fin 2010
➔
sur les Alpes-Maritimes (PACA) à partir de début 2011
Dans l’outil décisionnel qui va utiliser le modèle en étoile (cube, outil de dataviz…) les liens
techniques (fk de la table de fait posées sur les tk) entre la table de faits et les tables de
dimensions vont permettre une gestion automatique de l’affectation des commandes sur le bon
département, selon la date : à partir de 2011, les commandes de ce client seront bien affectées
sur le département 06 (et avant, elles le seront sur le 21)
le même client est stocké avec

2 identifiants différents dans
la table de faits
client situé en Côte-d’or

tk_client = 123
client situé dans les Alpes-Maritimes

tk_client = 124

Le schéma en étoile de notre cas d’usage
Pour la couche de stockage de nos données, voici le schéma en étoile adapté
Celui-ci comporte 4 dimensions dont une dite « dégénérée », c’est à dire incluse en tant que colonne de
la table de faits (et non comme table de dimension)
La table de fait comporte 1 mesure : « nbsal »
Les 3 clefs étrangères de la table de faits référencent les clefs primaires de chaque table de dimension,
chacune de ces clefs étant une clef technique (tk : technical key)

Habituellement, le mécanisme d’alimentation d’un schéma en étoile est le suivant :
➔
Mise à jour des dimensions, avec création automatique des clefs techniques (via un auto-incrément en
base de données sur la tk)
➔
Mise à jour de la table de faits (qui référence les lignes de dimension via les fk sur les tk)
Bonne pratique : pour toutes les dimensions, on crée un enregistrement avec tk = -1 « attribut inconnu »
afin de gérer les données insérées dans la table de faits pour lesquelles on n’aurait pas trouvé de référence
dans les tables de dimensions
Pour notre cas d’usage, il nous faut donc alimenter les 3 dimensions, comme suit :
➔
Dimension « département »
Fichiers « departement_2022.csv » et « region_2022.csv » (issus de l’Insee)
➔
Dimension « code d’activité » à partir des référentiels A17 et A5
Fichier « Codes_activités.xlsx » (construit à partir de plusieurs fichier Insee)
➔
Dimension « tranche effectif »
Sera gérée sous forme de data-set interne à PDI (étape grille de données)

Les transformations PDI à créer pour le chargement des dimensions sont les
suivantes :
Chargement de la
dimension département :
Chargement de la dimension naf
(code activité) :
Chargement de la dimension tranche effectif :

Le traitement d’alimentation de la table de faits doit permettre de récupérer les clefs
techniques à insérer dans la table, pour chaque dimension
Insertion des données

dans la table de faits
Partie déjà réalisée Récupération des tk pour chaque dimension,

avec des étapes « recherche dans base »

Une fois les tables de dimensions et de faits chargées, on doit vérifier les données
insérées : il est toujours conseillé de contrôler les données que l’on traite, à tout stade
du triptyque intégrer/stocker/restituer
Des requêtes SQL de contrôle peuvent être lancées sur la BD agrosup
select sum(nbsal) from fact_salaries :
select nom_reg, sum(nbsal) from fact_salaries f

inner join dim_dept d on (f.tk_dep = d.tk_dep) group by nom_reg order
by sum(nbsal) desc

Chargement multi-fichiers
Afin de charger plusieurs fichiers CSV, nous devons lancer notre traitement de chargement de la
table de faits sur chaque fichier en passant comme paramètre :
➔
L’emplacement du fichier à intégrer
➔
L’année qui correspond au fichier
C’est donc une boucle dont voici la méthode d’implémentation dans PDI
1/ Rendre la transformation paramétrable sur l’emplacement du fichier CSV et le champ année

➔
Implémenter les 2 variables suivantes dans le traitement : ${CHEMIN_CSV} et ${ANNEE}

2/ Les 2 variables doivent obligatoirement être déclarées en tant que paramètres de la transformation :
3/ On doit créer une nouvelle transformation « load all CSV » pour piloter les itérations à effectuer :

Dans l’étape « Grille de données », on renseigne les informations concernant les fichiers à charger,
dans l’onglet « Données » :
4/ On peut alors créer un job global qui va effectuer tout le travail demandé :
NB : L’étape RAZ permet de vider l’ensemble des tables avant leur chargement
delete from fact_salaries;
delete from dim_dept;
delete from dim_naf;
delete from dim_tranche;

Devenir autonome...
Les « samples » de Kettle :
Kettle fournit dans son installation de base des exemples de transformations et de jobs
présentant de nombreux « use case ». Ces exemples sont situés dans le répertoire Samples

Objectifs



solution de dataviz

Télécharger & installer MS Power BI
Lien de téléchargement : https://powerbi.microsoft.com/fr-fr/downloads

Télécharger & installer MS Power BI
Url : https://powerbi.microsoft.com/fr-fr/downloads
Puis ensuite lancer l’installeur PBIDesktopSetup_x64.exe

Construire le tableau de bord
Première étape : récupérer les données depuis la base postgresql

Première étape : récupérer les données stockées dans la base postgresql

Première étape : récupérer les données stockées dans la base postgresql

Seconde étape : définir les visualisations du tableau de bord
Glisser-déposer la viz

Seconde étape : définir les visualisations du tableau de bord
Configurer les champs de

données de la viz

Développer le tableau de bord suivant – onglet 1





Agrosup DN2A - La Data Par La Pratique

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Agrosup DN2A - La Data Par La Pratique

Transféré par

Droits d'auteur :

Formats disponibles

Initiation à la data

© 2023 Atol Conseils et Développements Page 1 / 70

Intégration Stockage & Traitement Restitution

© 2023 Atol Conseils et Développements Page 2 / 70

Intégrer / Entreposer / Restituer

Intégrer les données avec un outil ETL (PDI)

Entreposer les données (PostgreSQL)

Restituer les données (Microsoft Power BI)

© 2023 Atol Conseils et Développements Page 3 / 70

Intégrer / Entreposer / Restituer

Intégrer les données avec un outil ETL (PDI)

Entreposer les données (PostgreSQL)

Restituer les données (Microsoft Power BI)

© 2023 Atol Conseils et Développements Page 4 / 70

Exploitation d’un jeu de données open data de l’INSEE

© 2023 Atol Conseils et Développements Page 5 / 70

© 2023 Atol Conseils et Développements Page 6 / 70

© 2023 Atol Conseils et Développements Page 7 / 70

1ère étape – identifier et récupérer les fichiers nécessaires

© 2023 Atol Conseils et Développements Page 8 / 70

© 2023 Atol Conseils et Développements Page 9 / 70

© 2023 Atol Conseils et Développements Page 10 / 70

© 2023 Atol Conseils et Développements Page 11 / 70

© 2023 Atol Conseils et Développements Page 12 / 70

Pivot sur l’année

6. Agréger les données par département (sommer le nb de salariés)

© 2023 Atol Conseils et Développements Page 14 / 70

© 2023 Atol Conseils et Développements Page 15 / 70

Signification de l'acronyme "E.T.L." :

Transformation des données

© 2023 Atol Conseils et Développements Page 16 / 70

© 2023 Atol Conseils et Développements Page 17 / 70

Intérêts d'un ETL :

Intérêts d'un ETL Open Source :

© 2023 Atol Conseils et Développements Page 18 / 70

© 2023 Atol Conseils et Développements Page 19 / 70

Traitements conçus avec Spoon :

=> Tâches ("Jobs") pour séquencer et piloter les transformations

Programmes en ligne de commande :

=> Carte (Web Listener)

Stockage des traitements :

© 2023 Atol Conseils et Développements Page 20 / 70

© 2023 Atol Conseils et Développements Page 21 / 70

© 2023 Atol Conseils et Développements Page 22 / 70

© 2023 Atol Conseils et Développements Page 23 / 70

© 2023 Atol Conseils et Développements Page 24 / 70

© 2023 Atol Conseils et Développements Page 25 / 70

© 2023 Atol Conseils et Développements Page 26 / 70

© 2023 Atol Conseils et Développements Page 27 / 70

Certains types de données peuvent se présenter sous différents

© 2023 Atol Conseils et Développements Page 28 / 70

Exemple de format de sortie pour le nombre 99.55 :

Référence complète dans l'API java de Oracle :

© 2023 Atol Conseils et Développements Page 29 / 70

© 2023 Atol Conseils et Développements Page 30 / 70

© 2023 Atol Conseils et Développements Page 31 / 70

© 2023 Atol Conseils et Développements Page 32 / 70

© 2023 Atol Conseils et Développements Page 33 / 70

© 2023 Atol Conseils et Développements Page 34 / 70

© 2023 Atol Conseils et Développements Page 35 / 70

© 2023 Atol Conseils et Développements Page 36 / 70

Dans PDI, chaque étape a une

Ceci permet de comprendre et

© 2023 Atol Conseils et Développements Page 37 / 70