S2 - Processus ETL Et Entrepôt de Données - 2

Rabaa Youssef Douss 1
Processus ETL et Entrepôt de données 2021-2022

 Besoin: prise de décisions stratégiques et tactiques
 Pourquoi: besoin de réactivité
 Qui: les décideurs (non informaticiens)
 Comment: répondre aux demandes d’analyse des données,
dégager des informations qualitatives nouvelles
Qui sont mes Pourquoi et comment le
meilleurs clients? chiffre d’affaire a baissé?
Quels citoyens
A combien s’élèvent mes
consomment le plus
ventes journalières en Q1?
de poissons? 2
 Données opérationnelles (de production)
 Bases de données (Oracle, SQL Server)
 Fichiers de tout genre…
 Paye, gestion des RH, gestion des commandes…
 Caractéristiques de ces données:

 Distribuées: systèmes éparpillés
 Hétérogènes: systèmes et structures de données différents
 Détaillées: organisation des données selon les processus
fonctionnels, données surabondantes pour l’analyse
 Peu/pas adaptées à l’analyse : les requêtes lourdes peuvent
bloquer le système transactionnel
 Volatiles: pas d’historisation systématique
3
 Comment répondre aux demandes des décideurs?
 En donnant un accès rapide et simple à l’information stratégique
⇒Hors BD opérationnel donc
 En donnant du sens aux données : Nettoyage, structuration, analyse
exploratoire, fouille de données (datamining)
Mettre en place un système d’information dédié aux
applications décisionnelles: Datawarehouse
 Le processus de prise de décision
Analyser
Définir le Rassembler Établir des
les Décider
problème les données solutions
données
Temps de prise d’une décision

Champs d’application des
systèmes décisionnels 4
Collecte de Intégration Diffusion Présentation
données : ETL
Metadata
Intégration
E Data- Prise de
T
L warehouse décision
Hypercube
Base multi -
dimensionnelle Outils de
Prédiction /
Bases de Staging simulation
production Area Datamarts
Data Sources Data Storage OLAP Engine Front End Tools
5
1. Sources diverses et disparates;
2. Sources sur différentes plateformes et OS;
3. Applications legacy utilisant des BD et autres technologies
obsolètes;
4. Historique de changement non-préservé dans les sources;
5. Qualité de données douteuse et changeante dans le temps;
6. Structure des systèmes sources changeante dans le temps;
7. Incohérence entre les différentes sources;
8. Données dans un format difficilement interprétable ou ambigu.
6
 Définition : Regroupe les processus par lesquels les données
provenant de différentes parties du SI sont déplacées, combinées et
consolidées. Ils consistent habituellement à extraire des données de
différentes sources, à leur appliquer des transformations (jointures,
lookups, déduplication, calculs, etc.), et à envoyer les données
résultantes vers les systèmes cibles : DWH dans notre cas)
 Plusieurs système d’intégration de données :
 Médiation au service de l’intégration de données d'entreprise
(EII).
 Intégration de données via les applications (EAI).
 Intégration de données via les services Web (SOA).
 Intégration de données en nuage (Data Cloud).
 L'ETL (Extract - Transform - Load) aster 7
Source: “EII - ETL – EAI What, Why, and How!”, Tom Yu, 2005
ETL EII EAI
Target /
SQL
Data
(or Content)
Warehouse
Application
Interpret
load Data Virtualization Transform
transform Route
Application
extract
Structured Legacy
Data Source Data Source
Data Data
Source Source Application
Extract, Transform and Load Enterprise Information Enterprise Application

• Intégration et livraison des Intergration Intergration
données en lot • Fédération de données • Processus d’intégration des
• Transformations appliquées provenant de plusieurs sources données d’applications
sur lesdonnées • Accès temps-réel aux données • Basé sur l’échange de messages
• Données structurées ou sur un buscommun 8
semi- structurées
EII
Caractéristiques:
SQL
 Fournit une vue unifiée des données de l'entreprise, où les (or Content)
sources de données forment une fédération;

 Sources de données consolidées à l'aide d'une BD Data Virtualization
virtuelle, de manière transparente aux applications
utilisant ces données;
Structured Legacy
 Toute requête à la BD virtuelle est décomposée en sous- Data Source Data Source
requêtes aux sources respectives, dont les réponses sont

assemblées en un résultat unifié et consolidé;
 Permet de consolider uniquement les données utilisées,
au moment où elles sont utilisées (source data pulling).
 Le traitement en ligne des données peut cependant
entraîner des délais importants.
9
EII
En fonction des choix retenus, l'utilisateur SQL

aura la possibilité : (or Content)
• Modifier les données (pas d’accès en
lecture seule) ;
• Agir en temps réel sur les données (pas
en différé) ;
• Accéder à des données structurées ; Data Virtualization
• Accéder à des données cohérentes ;
• Accéder à des services ;
• Remonter des informations jusque dans
le modèle métier (objet) ; Structured Legacy Data
Data Source Source
10
Avantages Inconvénients
 Accéder à des données  Consolidation des données plus

structurées et consolidées; complexe que dans l’ETL;
 Permet d’explorer les données  Surtaxe les système sources;
avec la création du modèle de
l’entrepôt de données;  Plus limité que l’ETL dans la
quantité de données pouvant
 Accélère le déploiement de la être traitée;
solution;
 Transformations limitées sur les
 Peut être réutilisé par le système
données;
ETL dans une itération future;
 Aucun déplacement de données  Peut consommer une grande
bande passante du réseau.
11
Définition : EAI
Processus d’intégration des données
d’applications : architecture intergicielle
permettant à des applications hétérogènes
de gérer leurs échanges sur un bus
Application
commun.
Caractéristiques : Interpret
Transform
Fournit à l'entrepôt des données provenant Route
des sources (source data pushing);
Application
Repose sur l'intégration et le partage des
fonctionnalités des applications sources à
l'aide d'une architecture SOA
L'EAI ne remplace pas le processus ETL, Application
mais permet de simplifier ce dernier.
12
 Facilite l’interopérabilité des  Support limité aux transformations et
agrégations des données
applications
 Taille des transactions limitée (en
 Permet l’accès en (quasi) nombre de lignes)
temps-réel
 Développement complexe
 Ne transfère que les données
nécessaires  Gestion complexe de l’intégrité
sémantique des données
 Contrôle du flot d’information.
 Utilise la bande passante du réseau
durant les heures de pointe.
13
Caractéristiques
ETL
Permet la consolidation des données à l’aide des trois
opérations suivantes: Target /
Data
 Extraction: identifier et extraire les données de Warehouse
sources ayant subi une modification depuis la
dernière exécution;
load
 Transformation: appliquer diverses
transformations aux données pour les nettoyer, transform
les intégrer et les agréger; extract
 Chargement: insérer les données transformées
dans l’entrepôt et gérer les changements aux Data Data
données existantes (ex: stratégies SCD). Source Source
Traite de manière programmée de grande quantités

de données en lots ou en temps réel;
Est surtout utilisé avec les entrepôts de données et les
magasins de données (DWH et DM). 14
 Optimisé pour la structure de  Processus de développement long
l’entrepôt de données
et coûteux;
 Peut traiter de grandes quantités de
données dans une même exécution  Gestion des changements
(traitement en lots) nécessaire;
 Permet des transformations
complexes et agrégations sur les  Exige de l’espace disque pour
données effectuer les transformations
(Staging area ou ODS);
 La cédule (schedule) d’exécution
peut être contrôlée par  Exécuté indépendamment du
l’administrateur
besoin réel;
 La disponibilité d’outils GUI sur le
marché permet d’améliorer la  Latence des données entre la
productivité source et l’entrepôt;
 Permet la réutilisation des processus
et transformations  Unidirectionnel (des sources vers
l’entrepôt de données).
15
ETL EII EAI
Flot de données Unidirectionnel Bidirectionnel Bidirectionnel
(sources à
l’entrepôt)
Mouvement Lots cédulés Au moment de Déclenché par
de données la requête la transaction
(data pulling) (data pushing)
Latence Journalier à mensuel Temps-réel Quasi temps-réel
Transformations/ Grande capacité Moyenne capacité Faible capacité
agré gations des
données
Volume des Grand Moyen Petit
données (millions ou (10,000 – 1,000,000 (100-1000 lignes)
milliards de de lignes)
lignes)
16
 Approche ETL: Un ETL permet les transformations et agrégations
complexes de grands volumes de données pour votre base de données
multidimensionnelle
• Consolidation d’une grande quantité de données
• Transformations complexes
 Approche EII:
• Relier un entrepôt (EDW) existant avec des données de sources spécifiques
• Données sources volatiles et accessibles à l’aide de requêtes simples (SQL).
 Approche EAI : facilite l’interopérabilité des applications en ne transférant

que leurs données nécessaires, presque en temps réel.
• Intégration de transactions
• Requêtes analytiques simples
• Sources non-accessibles directement
17
18

Un ETL peut être :
 développé ex nihilo pour un projet directement dans un
langage bas niveau (Java, SQL, PL/SQL...) ;
 ou s'appuyer sur un outil d'ETL (Talend Open Studio, Pentaho
Data Integration, Informatica PowerCenter, ...).
ETL Tool versus Hand Coding (Buy a Tool Suite or Roll Your Own?)
The answer is, “It depends.”
(Kimball, Caserta, 2004, pp10-13)
19
Les avantages offerts par l'outil ETL sont :
 De structurer et de rassembler l'ensemble des morceaux de code
nécessaires aux transferts et aux transformations des données
 D'offrir une représentation graphique des flux et opérations
 De faciliter la maintenance et l'évolution de l'ETL
 D'intégrer la gestion des métadonnées
 D'intégrer la gestion des erreurs
Les avantages offerts par une approche ex nihilo (from scratch)
 L'homogénéité technologique et la disponibilité interne des
compétences : les équipes utilisent les langages qu'elles maîtrisent
sans apprentissage et médiation d'un outil tiers.
 La flexibilité : tout est possible.
 Le traitement des fichiers plats (hors BD ) peut être plus simples et
plus performant avec des langages proches des systèmes. 20
 A votre avis, quelles sont les étapes de conception d’un
processus ETL
21
Dépendent de la ETL des tables de faits
modélisation choisie
ETL des tables de dimension
pour le DWH
Définir les procédures pour le chargement de données
Préparer le staging area et les outils d'assurance qualité
Planifier les agrégations de données
Définir les règles de transformation et de nettoyage des données
Définir les règles d'extraction des données cibles
Déterminer les sources internes et externes renfermant ces données
Déterminer les données nécessaires à la solution BI

22
EXTRACT BD Fichier CSV
Extraction
 Extraction des données de leur
environnement d’origine (base de données
Transformation
relationnelles, fichiers plats…)
 Besoin d’outils spécifiques pour accéder aux
bases de production (requêtes sur des BDs
Chargement
hétérogènes)
 Besoin d’une technique appropriée pour
n’extraire que les données nécessaires DW
Attention ! L’extraction ne doit pas perturber l’activité de production
23
EXTRACT
L’extraction des données peut se faire de trois
façons différentes : Push
 Push : la logique de chargement est dans le
système de production, il pousse les données
vers le Staging quand il en a l'occasion. E
Pull T
 Pull : le Pull tire les données de la source L
vers le Staging. Push/Pull
 Push-Pull : La source prépare les données a
envoyer et prévient le Staging qu'elle est
prête. Le Staging va récupérer les données. Bases de Staging
Si la source est occupée, le Staging fera une production Area
autre demande plus tard.
24
Extraction
I. Identification des sources :
1. Énumérer les items cibles (métriques et attributs de
Transformation
dimension) nécessaires à l'entrepôt de données;
2. Pour chaque item cible, trouver la source et l'item
correspondant de cette source;
Chargement
3. Si plusieurs sources sont trouvées, choisir la plus
pertinente;
4. Si l'item cible exige des données de plusieurs DW
sources, former des règles de consolidation;
5. Si l'item source referme plusieurs items cibles (ex: un
seul champs pour le nom et l'adresse du client),
définir des règles de découpage;
6. Inspecter les sources pour des valeurs manquantes.
25
Extraction
II. Extraction
1. Extraction complète :
Transformation
 Capture l'ensemble des données à un certain
instant (snapshot de l'état opérationnel);
 Normalement employée dans deux situations:
 Chargement initial des données; Chargement
 Rafraîchissement complet des données (ex:
modification d'une source).
 Peut être très coûteuse en temps (ex: plusieurs DW
heures/jours).
2. Extraction incrémentale:
 Capture uniquement les données qui ont changées
ou ont été ajoutées depuis la dernière extraction;
 Peut être faite de deux façons:
 Extraction temps-réel;
26
 Extraction différée (en lot).
EXTRACT
II. Extraction
3. Extraction temps-réel : S'effectue au moment où les transactions
surviennent dans les systèmes sources.
Systèmes
opérationnels BD sources Journal de
transactions
sources triggers
Option 1:
Capture à l'aide des
journaux detransactions
Fichiers Fichiers
générés par Option 2:
générés par
les triggers Capture à l'aide de
les sources
triggers
Option 3: Zone de préparation
Capture dans les de données
applications sources 27
(staging area)
EXTRACT
II. Extraction
3. Extraction temps-réel :
Option 1: Capture à l'aide du journal des transactions
 Utilise les logs de transactions de la BD servant à la récupération en cas de

panne;
 Aucune modification requise à la BD ou aux sources;
 Doit être fait avant le rafraîchissement périodique du journal;
 Pas possible avec les systèmes legacy ou les sources à base de fichiers (il
faut une BD journalisée).
28
EXTRACT
II. Extraction
Option 2: Capture à l'aide de triggers
 Des procédures déclenchées (triggers) sont définies dans la BD pour

recopier les données à extraire dans un fichier de sortie;
 Meilleur contrôle de la capture d'évènements;
 Exige de modifier les BD sources;
 Pas possible avec les systèmes legacy ou les sources à base de fichiers.
29
EXTRACT
II. Extraction
Option 3: Capture à l'aide des applications sources

 Les applications sources sont modifiées pour écrire chaque ajout et
modification de données dans un fichier d'extraction;
 Exige des modifications aux applications existantes;
 Entraîne des coûts additionnels de développement et de maintenance;
 Peut être employé sur des systèmes legacy et les systèmes à base de
fichiers.
30
EXTRACT
II. Extraction
3. Extraction différée: Extrait tous les changements survenus durant une
période donnée (ex: heure, jour, semaine, mois).
Systèmes
opérationnels Extraction Extraction
BD sources d'aujourd'hui d'hier
sources
Programme de
Programme comparaison
Fichiers
d'extraction d'extraction
utilisant les
timestamps Option 2:
Capture par Fichiers
Option 1: comparaison de d'extraction
Capture basée sur Zone de préparation fichiers utilisant la
les timestamps de données comparaison
31
Processus ETL et Entrepôt de données
(staging area) 2021-2022
EXTRACT
II. Extraction
3. Extraction différée:
Option 1: Capture basée sur les timestamps
 Un timestamp (associe une date et une heure à un événement) est ajoutée

à chaque ligne des systèmes sources;
 L'extraction se fait uniquement sur les données dont le timestamp est plus
récent que la dernière extraction;
 Fonctionne avec les vieux systèmes en entreprise (legacy system) et les
fichiers plats, mais peut exiger des modifications aux systèmes sources;
 Gestion compliquée des suppressions.
32
EXTRACT
II. Extraction
3. Extraction différée:
Option 2: Capture par comparaison de fichiers

 Compare deux snapshots successifs des données sources;
 Extrait seulement les différences (ajouts, modifications, suppressions)

entre les deux snapshots;
 Peut être employé sur des systèmes legacy et les systèmes à base de
fichiers, sans aucune modification;
 Exige de conserver une copie de l'état des données sources;
 Approche relativement coûteuse.
33
EXTRACT
Considérations pratiques de l’étape d’extraction :
1. Choisir, pour chaque source, la fenêtre temporelle durant laquelle sera
faite l'extraction;
2. Déterminer la séquence des tâches d'extraction;
3. Déterminer comment gérer les exceptions.
34
TRANSFORM BD Fichier CSV
Extraction
Transformation des données
 Homogénéisation du vocabulaire, structures,
Transformation
valeurs
 Suppression et fusion des redondances
 Suppression des données incohérentes
Chargement
 Transformation dans un format cible
DW
35
TRANSFORM
Types de transformation :
1. Révision de format :
 Ex: Changer le type ou la longueur de champs individuels.
2. Décodage de champs :
 Consolider les données de sources multiples
Ex: ['homme', 'femme'] vs ['M', 'F'] vs [1,2].
 Traduire les valeurs cryptiques
Ex: 'AC', 'IN', 'SU' pour les statuts actif, inactif et suspendu.
3. Pré-calcul des valeurs dérivées :
Ex: profit calculé à partir de ventes et coûts.
4. Découpage de champs complexes :
Ex: extraire les valeurs prénom, secondPrénom et nomFamille à partir d'une seule
chaîne de caractères nomComplet.
36
TRANSFORM
Types de transformation:
5. Fusion de plusieurs champs:
Ex: information d'un produit
Source 1: code et description;
Source 2: types de forfaits;
Source 3: coût.
6. Conversion de jeu de caractères.
Ex: EBCDIC (IBM) vers ASCII.
7. Conversion des unités de mesure.
Ex: miles to meter.
8. Conversion de dates.
9. Pré-calcul des agrégations.
Ex: Total des ventes par produit par semaine et par région.
10. Déduplication.
Ex: Plusieurs enregistrements pour un même client. 37
TRANSFORM
Problème de résolution d'entités:
 Même entité se retrouve sur différentes sources, sans qu'on ait la
correspondance entre ces sources;
Ex: clients de longue date avec différent identifiants dans les sources;
 L'intégration des données requiert de retrouver la correspondance;
 Approches basées sur des règles de résolution
Ex: les entités doivent avoir au moins N champs identiques
Problème des sources multiples:
 Survient lorsqu'une entité possède une représentation différente sur
plusieurs sources;
 Approches de sélection:
 Choisir la source la plus prioritaire;
 Choisir la source ayant l'information la plus récente.
38
TRANSFORM
Problème des changements dimensionnels
Slowly Changing Dimensions (SCDs)
 On parle d'une dimension a évolution lente (slowly changing dimension)
lorsqu'une dimension peut subir des changements de description des
membres.
 Un client peut changer d’adresse, se marier, ...
 Un produit peut changer de noms, de formulations : Raider en Twix , Yaourt à la

vanille en saveur Vanille
⇒Comment gérer cette situation dans un DWH?
⇒Préparer l'image de chargement (load image) en conséquence
39
TRANSFORM
Gestion des changements dimensionnels
 SCD Type 0 : Pas de prise en compte des SCDs;
 SCD Type 1: ancienne valeur écrasée;
40
TRANSFORM
Gestion des changements dimensionnels
 SCD Type 2: nouvelle ligne ajoutée;
 SCD Type 3: déplacement de l'ancienne valeur dans la colonne

d'historique et écriture de la nouvelle valeur dans la colonne
courante.
41
LOAD BD Fichier CSV
Extraction
 Etape Critique.
 Chargement des données dans l’entrepôt cible
Transformation
en respectant la modélisation des données
choisie (prochain cours)
 Des questions qu'il faut se poser lors de cette
Chargement
étape :
 Que faire si un chargement échoue ?
DW
 Ai-je les moyens de revenir à l'état avant le
chargement ?
 Puis-je revenir dans le temps d'un chargement
donné ?
 Comment valider mon chargement, comment
détecter les erreurs?
42
LOAD
Types de chargement :
1. Chargement initial :
• Fait une seule fois lors de l'activation de l'entrepôt de données;
• Peut prendre plusieurs heures.
2. Chargement incrémental :
• Fait une fois le chargement initial complété;
• Tient compte de la nature des changements (ex: SCD Type 1, 2 ou 3);
• Peut être fait en temps-réel ou en lot.
3. Rafraîchissement complet :
• Employé lorsque le nombre de changements rend le chargement
incrémental trop complexe;
Ex: lorsque plus de 20% des enregistrements ont changé depuis le
dernier chargement
43
LOAD BD Fichier CSV
Extraction
Considérations additionnelles:
 Faire les chargements en lot dans une période
Transformation
creuse (entrepôt de données non utilisé);
 Considérer la bande passante requise pour le
chargement;
Chargement
 Avoir un plan pour évaluer la qualité des
données chargées dans l'entrepôt;
 Commencer par charger les données des tables DW
de dimension.
 Penser à intégrer les métadonnées dans
l’information à charger
44
45
Big Data Integration
46
ETL ELT
New technology that is more focused
ETL has been in the market for long on cloud-based warehouses.
Technology
=> easier to find developers with vast Searching suitable engineers to
Adoption
experience in designing ETL systems. develop ELT pipelines are as easy as
for ETL.
Data which is required only for analytics Load anything and everything into a
or reporting is being loaded into the warehouse or a data lake from where
Data Availability
warehouse, leaving other unnecessary it can be analyzed at a later point of
data in the source systems as is. time.
Add or remove specific columns while Additional columns are directly
Calculated Fields
transforming the data in the ETL tool. We added to the existing dataset in the
and
can also add calculated columns and warehouse. Usually, there is no
Transformations
load them to the warehouse. modification of the source columns.
The more focus is given towards
analyzing highly variable structured
Transformation Implement much complex data
and unstructured data that is arriving
Complexities transformations as and when required.
at a high pace rather than
complexities.
ETL ELT
Most of the traditional ETL tools need to
Mostly cloud-based and doesn’t
Infrastructure be installed on-premises => lot of cost
require to be installed on the
to the analytics workloads. premises.
In an ETL pipeline, that is installed on-
ELT, since it is cloud-based or
Postproduction
premises, maintenance is frequently serverless, no or very little
Maintenance
required. maintenance is required.
In ELT, the transformations are
The transformations are applied in
applied once the data has been
Transformation memory in a staging layer before the
loaded into the warehouse or a data
Area data is being loaded into the data
lake.
warehouse.
No requirement for a staging layer.
Although an ETL tool can read data ELT is designed to handle all types
Support for semi- from semi-structured or unstructured of data structures from semi-
structured and data sources, it is usually transformed in structured to unstructured data in
unstructured data the staging layer and only stored as a the data lakes which can be further
proper structure in the warehouse. analyzed.
48
Collecte de Intégration Diffusion Présentation
données : ETL
Metadata
Intégration
E Data- Prise de
T
L warehouse décision
Hypercube
Base multi -
dimensionnelle Outils de
Prédiction /
Bases de Staging simulation
production Area Datamarts
Data Sources Data Storage OLAP Engine Front End Tools
49
Définition : Données servant à définir ou décrire d’autres données.
Permettent de comprendre les données en leur conférant un contexte.
Correspondent à des marqueurs que l'on introduit dans les fichiers ou
dans des langages de programmation appropriés, comme
les langages de marquage XML.
50
 But
 Améliorer l'efficacité des recherches d'information par
rapport aux recherches « plain text ».
 Faire interopérer les ressources informatiques. On peut alors
faire communiquer les BDs classiques. Ex : Consolider une
information/item à partir de plusieurs bases.
 Prolonger la durée de vie des données en permettant aux
entreprises de les réutiliser à de nombreuses reprises.
 Permettre à un utilisateur technique de déterminer quel job
ETL ou processus de base de données est utilisé pour
charger des données dans chaque attribut transformé.
51
Métadonnées techniques :
– ETL : sources et cibles pour les transferts de données, transformations,
règles d’affaires, etc.
– Stockage : tables, champs, types, indexes, partitions, dimensions, etc.
– Présentation: modèle de données, rapports, cédules, privilèges d’accès,
etc.
Métadonnées d’affaires:
– Décrit le contenu de l’entrepôt en termes compréhensibles par les
utilisateurs d’affaires;
– Ex: descripteurs de tables et champs.
Métadonnées de processus:
– Décrit le résultat de diverses opérations du système de BI;
– Ex: logs ETL (début, fin, écritures disque, …), statistiques sur les
requêtes, …
52
Bénéfices:
– Découple la dépendance entre la technologie et son
utilisation (ex: reconfigurer dynamiquement le système ETL
pour modifier ou ajouter une source)
– Permet de monitorer l'état et la performance de la solution BI
– Sert de documentation au système
– Permet de déterminer l'impact d'un changement
– Assure l'interopérabilité entre les systèmes et la
maintenabilité du système décisionnel
Idéal:
– Avoir un seul répertoire de métadonnées partagé par toutes
les composantes de la solution BI
53
54

Définition de Inmon (1992) : « Une collection de données thématiques, intégrées,
non volatiles et historisées, organisées pour le support d'un processus d'aide à la
décision»
Données :
• thématiques ou orientées sujet : données pertinentes pour un sujet ou thème et
nécessaires aux besoins d'analyse
• intégrées : données résultant de l'intégration de données provenant de différentes
sources pouvant être hétérogènes
• historisées : données représentent l'activité d'une entreprise durant une certaine
période (plusieurs années)
• non-volatiles : données essentiellement utilisées en interrogation (consultation) et
ne peuvent pas être modifiées
Principe : mettre en place une base de données utilisée à des fins d’analyse
55
Les 4 caractéristiques des Datawarehouses
1. Données orientées sujet :
 Regroupe les informations des différents métiers
 Ne tiens pas compte de l’organisation fonctionnelle des données
Ass. Vie Ass. Auto Ass. Santé
Client
Police
56
2. Données intégrées:
 Normalisation des données
 Définition d’un référentiel unique
h,f
1,0 h,f
homme, femme
GBP
EUR
CHF
USD 57
3. Données non volatiles
 Traçabilité des informations et des décisions prises
 Copie des données de production
Bases de production Entrepôts de données
Ajout
Suppression
Accès
Modification Chargement
58
4. Données datées
 Les données persistent dans le temps
 Mise en place d’un référentiel temps
Image de la base en Mai 2005 Image de la base en Juillet 2006
Base de Répertoire Répertoire
Nom Ville Nom Ville
production
Dupont Paris Dupont Marseille
Durand Lyon Durand Lyon
Calendrier Répertoire
Entrepôt de Code Année Mois
Code Nom Ville
données 1 2005 Mai
1 Dupont Paris
1 Durand Lyon
2 2006 Juillet
2 Dupont Marseille 59
• À quoi sert le plan architecturel d’une solution de BI?
• Quels sont les facteurs pouvant avoir un impact sur
l’architecture de la solution?
6 60
0
Besoins d’affaires:
 « Que doit-on faire ? »
Architecture:
 « Comment allons-nous le faire ? »
6 61
1
Encourage la satisfaction des besoins:
 Les besoins techniques dérivent des besoins d’affaires;
 Documents d’architecture.
Facilite la communication:
 Illustre les différents rôles au sein du système;
 Communique la complexité du projet aux cadres supérieurs.
Aide à la planification:
 Regroupe tous les détails techniques;
 Identifie des dépendances et de nouveaux de besoins.
Flexibilité, productivité et maintenance:

 Métadonnées, sélection d’outils, etc.
62
• L’interdépendance informationnelle entre les unités de
l’entreprise
Ex: bonne intégration (ex: MDM Master Data Management ou
gestion des données de référence) VS silos de données
• Les sources de données
Ex: 1 source VS 10 sources, ERP VS legacy, etc.
• La quantité des données
Ex: gigaoctets VS teraoctets
• La latence des données
Ex: mise-à-jour hebdomadaire VS temps-réel
• L’urgence d’obtenir une solution fonctionnelle
Ex: entrepôt d'entreprise (EDW) VS magasin de données
63
• Le nombre d'utilisateurs
Ex: 10-50 utilisateurs vs 50-200 utilisateurs
• La nature des tâches des utilisateurs finaux
Ex: rapports simples VS fouille de données
• Les contraintes sur les ressources
Ex: financières, main d'œuvre, biais technologique, etc.
• Les objectifs du projet
Ex: stratégique VS opérationnel
• Autres facteurs
Ex: politiques, habilités du personnel TI, etc.
64
 Quelles sont les différentes architectures d’entrepôts de
données?
 Quelles sont les critères permettant de comparer

différentes architectures?
65
1. Magasins de données indépendants
2. Architecture en bus de magasins de données
3. Architecture Hub-and-spoke
4. Entrepôt de données centralisé
66
Datamarts
Systèmes source ETL indépendants Reporting Utilisateurs
Staging
App 1
Area
silos de Staging
App 2
Area
données
Staging
App 3
Area
67
Caractéristiques:
– Les datamarts sont développés et opèrent de manière indépendante;
– Les données sont disposées en « silos fonctionnels »;
– Pas de dimensions conformes (ou partagées : utilisées par les faits de
+ieurs DMs)
Avantages/inconvénients:
(+) Architecture la plus simple et la moins coûteuse à développer;
(−) Incohérences et redondances entre les datamarts
(−) Il n’y a pas une seule version de la vérité;
(−) Analyse inter-fonctionnelle difficile ou impossible;
(−) Vision limitée, pas extensible.
68
Datamarts
liés par
Systèmes dimensions
source ETL conformes Reporting Utilisateurs
Infrastructure
de reporting
Staging
Area
Entrepôt de
données
conceptuel
69
Data-
warehouse
Bottom-Up
DM DM DM
Caractéristiques:
– Approche bottom-up, proposée par R. Kimball;
Data Storage
– Datamarts développés par sujet/processus d’affaires, en se basant sur des
dimensions conformes;
– Modélisation dimensionnelle, au lieu du modèle entité-relation (ex: 3FN);
– Entrepôt conceptuel, formé de datamarts inter-reliés à l’aide d’une couche
d’intergiciels (middleware).
(+) Intégration des données assurée par les dimensions conformes;
(+) Approche incrémentale (processus les plus importants d’abord);
(+) Donne des résultats rapidement;
(−) Itérations futures plus difficiles à planifier;
(−) Performance sous-optimale des analyses impliquant plusieurs datamarts.
70
Systèmes Entrepôt de Datamarts
ETL Reporting Utilisateurs
source données dépendants
d’entreprise
Infrastructure
de reporting
Staging
DWH
Area
Concentrateur Rayons
(hub) (spokes)
71
Data-
warehouse
Top-Down
DM DM DM
Caractéristiques:
–Approche top-down, proposée par B. Inmon et al. Data Storage
–Entrepôt (hub) contient les données atomiques (niveau de détail le plus fin) et
normalisées (3FN);
–Les datamarts (spokes) reçoivent les données de l’entrepôt;
–Les données des datamarts suivent le modèle dimensionnel et sont
principalement résumées (pas atomique);
–La plupart des requêtes analytiques sont faites sur les datamarts.
(+) Intégration et consolidation complète des données de l’entreprise;
(+) Approche itérative et potentiellement extensible (spokes);
(−) Peut avoir de la redondance de données entre les datamarts;
(−) Performance sous-optimale des analyses impliquant plusieurs datamarts.
72
Systèmes Entrepôt de Reporting Utilisateurs
source ETL données
d’entreprise
Infrastructure
de reporting
Staging
DWH
Area
73
Caractéristiques:
– Similaire à Hub-and-spoke, mais sans les datamarts dépendants;
– Gigantesque entrepôt de données servant l’entreprise entière;
– Les données peuvent être atomiques ou résumées.
(+) Les utilisateurs ont accès à toutes les données de l’entreprise;
(+) Intégration (ETL) et maintenance facile car les données sont à un
seul endroit;
(+) optimale (ex: Appliance warehouse, Teradata).
(−) Long et coûteux à développer;
(−) Pas incrémental;
(−) Extensibilité limitée ou très coûteuse.
74
Inmon Kimball
Commence par la conception du modèle de DWH Commence par la conception du modèle

dimensionnel pour les datamarts
Architecture composée d’un staging area Architecture qui consiste en un staging et des
permanent, d’un DWH et de datamarts datamarts, le DWH physique n’existe pas
dépendants
Le DWH est orienté entreprise et les datamarts Les DMs contiennent les données atomiques et
sont orientés processus agrégées
Le DWH contient des données atomiques, les Les DMs peuvent fournir une vue entreprise ou
datamarts les données agrégées processus
Le DWH utilise un modèle normalisé de toute Les DMs sont implémentés d’une façon
l’entreprise, les datamarts utilisent des données incrémentale et intégrée en utilisant les
dimensionnelles orientées sujét dimensions conformes
Les utilisateurs peuvent effectuer des requêtes Les requêtes sont faites directement sur les DMs
sur le DWH et les DMs puisque le DWH n’existe pas physiquement 75
Inmon Kimball
Construction Couteux en temps Rapide
Maintenance Facile Difficile redondance à
gérer
Coût Coût initial élevé Coût initial modéré
Durée de mise en œuvre Long Cours si mode
incrémental
Compétences utiles Equipe spécialisée Equipe généraliste
Intégration des données Au niveau de l’entreprise Par domaine métier
 Aucun d’entre eux n’est à privilégier

 Le choix de la meilleure approche dépend de l’activité de l’entreprise :
ses objectifs à long et court terme sur le plan décisionnel.
76
 Modélisation de données décisionnelles
77

S2 - Processus ETL Et Entrepôt de Données - 2

Transféré par

Informations du document

Titre original

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

S2 - Processus ETL Et Entrepôt de Données - 2

Transféré par

Droits d'auteur :

Formats disponibles

Rabaa Youssef Douss 1

Processus ETL et Entrepôt de données 2021-2022

 Caractéristiques de ces données:

Temps de prise d’une décision

Extract, Transform and Load Enterprise Information Enterprise Application

sources de données forment une fédération;

requêtes aux sources respectives, dont les réponses sont

En fonction des choix retenus, l'utilisateur SQL

 Accéder à des données  Consolidation des données plus

Traite de manière programmée de grande quantités

 Approche EAI : facilite l’interopérabilité des applications en ne transférant

Processus ETL et Entrepôt de données 2021-2022

Préparer le staging area et les outils d'assurance qualité

Planifier les agrégations de données

Définir les règles de transformation et de nettoyage des données

Définir les règles d'extraction des données cibles

Déterminer les sources internes et externes renfermant ces données

Déterminer les données nécessaires à la solution BI

Attention ! L’extraction ne doit pas perturber l’activité de production

 Utilise les logs de transactions de la BD servant à la récupération en cas de

 Doit être fait avant le rafraîchissement périodique du journal;

 Des procédures déclenchées (triggers) sont définies dans la BD pour

 Exige de modifier les BD sources;

Option 3: Capture à l'aide des applications sources

 Entraîne des coûts additionnels de développement et de maintenance;

 Un timestamp (associe une date et une heure à un événement) est ajoutée

Option 2: Capture par comparaison de fichiers

 Extrait seulement les différences (ajouts, modifications, suppressions)

 Approche relativement coûteuse.

 Un produit peut changer de noms, de formulations : Raider en Twix , Yaourt à la

 SCD Type 1: ancienne valeur écrasée;

 SCD Type 3: déplacement de l'ancienne valeur dans la colonne

Processus ETL et Entrepôt de données 2021-2022

Ass. Vie Ass. Auto Ass. Santé

Bases de production Entrepôts de données

Flexibilité, productivité et maintenance:

 Quelles sont les critères permettant de comparer

2. Architecture en bus de magasins de données

4. Entrepôt de données centralisé

Commence par la conception du modèle de DWH Commence par la conception du modèle

 Aucun d’entre eux n’est à privilégier

Vous aimerez peut-être aussi