données, modélisation, intégration et analysenegre/fichiers_joints/bi-classique.… · 3...

Post on 19-Oct-2020

5 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Entrepôts de données

Données, modélisation,

intégration et analyse

NEGRE Elsa

Université Paris-Dauphine

2020-2021

2

Contexte (1)

◼ Besoin : Prise de décisions stratégiques et tactiques

Réactivité

◼ Qui : les décideurs (non informaticiens, non statisticiens)

◼ Comment : Répondre aux demandes d’analyse de données

Dégager des informations qualitatives nouvelles

3

Contexte (2)

◼ Type de données : données opérationnelles (de production) Bases de données, Fichiers, Paye, Gestion RH, …

◼ Caractéristiques des 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 de données selon les processus fonctionnels et données trop abondantes pour l’analyse

Peu/pas adaptées à l’analyse : des requêtes lourdes peuvent bloquer le système transactionnel

Volatiles : pas d’historisation systématique

4

Problématique (1)Nous avons donc :

◼ Une grande masse de données Distribuées

Hétérogènes

Très détaillées

◼ à traiter Synthétiser / résumer

Visualiser

Analyser

◼ pour une utilisation par des Experts / analystes d’un métier

Non informaticiens

Non statisticiens

5

Problématique (2)

◼ Comment répondre aux besoins de décideurs

afin d’améliorer les performances décisionnelles

de l’entreprise?

En donnant un accès rapide et simple à l’information

stratégique

En donnant du sens aux données

En donnant une vision transversale des données de

l’entreprise (intégration de différentes bases de

données)

En extrayant, groupant, organisant, corrélant et

transformant (résumé, agrégation) les données

6

Problématique (3)

Mettre en place un SI dédié aux applications décisionnelles : un entrepôt de données (datawarehouse)

Transformer des données de production en informations stratégiques

Sources : Th. Ester, HEC Lausanne

7

Le processus de prise de décision (1)

Sources : Lydie Soler, AgroTechParis

Business Intelligence (BI) Moyens, outils et méthodes qui permettent à un décideur •d’avoir une vue d’ensemble de l’activité traitée•de trouver l'information pertinente et complète pour prendre rapidement la meilleure décision

Données, Informations, Connaissances (1)

8Sources : F. Ravat, UT1

Une valeur non

traitée, non

interprétée

Donnée traitée,

agrégée,

interprétée

Résultat de la

réflexion sur une

information

Données, Informations, Connaissances (2)

9Sources : F. Ravat, UT1

BI (1)

10Sources : F. Ravat, UT1; decizia.com

BI (2)

11Sources : F. Ravat, UT1

BI (3)

12Sources : https://fr.slideshare.net/datascienceth/business-intelligence-30-and-the-data-lake

SYSTÈME D’AIDE A LA

DÉCISION –

BI TRADITIONNELLE

Applications informatiques permettant de

transformer les données opérationnelles

en indicateurs pertinents dont la restitution

guidera la prise de décision13

14

Architecture générale

Sources : F. Ravat, UT1

Les sources

15

Données sources

◼ Caractéristiques

Volumineuses

Hétérogènes en contenu

Détaillées

Volatiles : pas d’historisation systématique ou incomplète (pour

les analyses)

Peu ou pas adaptées à l’analyse

◼ Supports

Une ou plusieurs sources

Interne ou externe

Hétérogènes en modèles et systèmes de stockage

16

ETL (1)

17

18

◼ Modèle entité-relation (BD de production)

→ Modèle à base de dimensions et de faits

◼ Outil : Offrant un environnement de développement

Offrant des outils de gestion des opérations et de maintenance

Permettant de découvrir, analyser, et extraire les données à partir de sources hétérogènes

Permettant de nettoyer et standardiser les données

Permettant de charger les données dans un entrepôt

ETL (2)

ETL (3)

◼ But : Alimentation initiale et mise à jour

périodique

◼ Outils pour automatiser ces différents

chargements

19

ETL (4) : Extraction, Transformation, Chargement

20Sources : F. Ravat, UT1

21

◼ Extraction :

Depuis différentes sources (bd, fichiers,

journaux, …)

Différentes techniques :

◼ Push : règles (triggers)

◼ Pull : requêtes (queries)

Périodique et répétée

◼ Dater ou marquer les données envoyées

Difficulté :

◼ Ne pas perturber les applications OLTP

22

◼ Transformation : Etape très importante qui garantit la cohérence et la fiabilité des données

Rendre cohérentes les données issues de différentes sources◼ Unifier les données

Ex. dates : MM/JJ/AA -> JJ/MM/AA

Ex. noms : D-Naiss, Naissance, Date-N -> « Date-Naissance »

◼ Trier, Nettoyer

Eliminer les doubles

Jointures, projection, agrégation (SUM, AVG, …)

Gestion des valeurs manquantes (NULL) (ignorer ou corriger ?)

Gestion des valeurs erronées ou inconsistantes (détection et correction)

Vérification des contraintes d’intégrité (pas de violation)

◼ Inspection manuelle de certaines données possible…

23

24

◼ Chargement : Insérer ou modifier les données dans

l’entrepôt

Alimentation incrémentale ou totale?, offline ou online?,

fréquence des chargements?, taille de l’historique?, …

Si pas de MAJ :

◼ insertion de nouvelles données

◼ Archivage des données anciennes

Sinon (attention en cas de gros volumes)

◼ Périodicité parfois longue

◼ MAJ des indexes et des résumés

25

Attention…

◼ ETL ≠ ELT

L’approche ELT (Extraction, Loading,

Transformation) génère du code SQL natif

pour chaque moteur de BD impliqué dans le

processus – sources et cibles

Cette approche profite des fonctionnalités de

chaque BD mais les requêtes de

transformation doivent respecter la syntaxe

spécifique au SGBD

Le stockage

(DW/DM)

26

27Sources : F. Ravat, UT1

28

L’entrepôt : Définition

◼ Le DW est une collection de données

orientées sujet, intégrées, non volatiles et

historisées, organisées pour le support

d’un processus d’aide à la décision.W.H. Inmon (1996)

◼ C’est une BD à des fins d’analyse !!

L’entrepôt

◼ Objectif : Préparation des données

décisionnelles

◼ Principe : Lieu de stockage centralisé d’un

extrait des sources pertinent pour les décideurs,

historisé, non volatile, disponible pour

l’interrogation décisionnelle, organisé selon un

modèle informatique facilitant la gestion des

données

29

30

Caractéristiques d’un DW (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

Sources : Lydie Soler, AgroTechParis

31

Caractéristiques d’un DW (2)

◼ Données intégrées

Normalisation des données

Définition d’un référentiel unique

Sources : Lydie Soler, AgroTechParis

32

Caractéristiques d’un DW (3)

◼ Données non volatiles

Traçabilité des informations et des décisions

prises

Copie des données de production

Sources : Lydie Soler, AgroTechParis

33

Caractéristiques d’un DW (4)

◼ Données historisées / datées

Les données persistent dans le temps

Mise en place d’un référentiel temps

Sources : Lydie Soler, AgroTechParis

34

Caractéristiques d’un DW (5)

◼ Inconvénient :

De par sa taille, le DW est rarement utilisé

directement par les décideurs car il

contient plus que nécessaire pour une

classe de décideurs

35

Le datamart

◼ Sous-ensemble d’un entrepôt de données

◼ Destiné à répondre aux besoins d’un secteur ou d’une fonction particulière de l’entreprise

◼ Point de vue spécifique selon des critères métiers

Sources : Lydie Soler, AgroTechParis

Le datamart

◼ Objectif : Présentation des données

décisionnelles

◼ Principe :

Extrait de l’entrepôt de données

Adapté aux besoins d’une classe de

décideurs

Organisé selon un modèle informatique

adapté aux outils décisionnels

36

37

Pourquoi pas un SGBD ? (1)

◼ Fonctions d’un SGBD :

Systèmes transactionnels (OLTP)

Permettre d’insérer, modifier, interroger

rapidement, efficacement et en sécurité les

données de la base

Sélectionner, ajouter, mettre à jour, supprimer

des tuples

Répondre à de nombreux utilisateurs

simultanément

38

Pourquoi pas un SGBD ? (2)

◼ Fonctions d’un DW :

Systèmes pour l’aide à la prise de décision

(OLAP)

Regrouper, organiser des informations

provenant de sources diverses

Intégrer et stocker les données pour une vue

orientée métier

Retrouver et analyser l’information

rapidement et facilement

39

Pourquoi pas un SGBD ? (4)

Sources : Lydie Soler, AgroTechParis

40

Pourquoi pas un SGBD ? (3)

OLTP DW

Utilisateurs Nombreux

Employés

Peu

Analystes

Données Alphanumériques

Détaillées / atomiques

Orientées application

Dynamiques

Numériques

Résumées / agrégées

Orientées sujet

Statiques

Requêtes Prédéfinies « one-use »

Accès Peu de données

(courantes)

Beaucoup d’informations

(historisées)

But Dépend de l’application Prise de décision

Temps d’exécution Court Long

Mises à jour Très souvent Périodiquement

41Sources : F. Ravat, UT1

MODÉLISATION

MULTIDIMENSIONNELLE

Niveau conceptuel

Niveau logique

Niveau physique

42

Niveaux d’abstraction

◼ Conceptuel

Abstraction des aspects techniques

Analyse des besoins des décideurs

◼ Logique : Mode de stockage

◼ Physique : Processus d’alimentation

43Sources : F. Ravat, UT1

NIVEAU CONCEPTUEL

44

45

Niveau conceptuel

◼ Description de la base multidimensionnelle

indépendamment des choix d'implantation

◼ Les concepts:

Dimensions et hiérarchies

Faits et mesures

46

Dimension (1)

◼ Axes d'analyse avec lesquels on veut faire l'analyse Géographique, temporel, produits, etc.

◼ Chaque dimension comporte un ou plusieurs attributs/membres

◼ Une dimension est tout ce qu'on utilisera pour faire nos analyses.

◼ Chaque membre de la dimension a des caractéristiques propres et est en général textuel

◼ Remarque importante : Taille Dimension << Taille Fait

47

Dimension (2)

Dimension produit

Clé produit (CP)

Code produit

Description du produit

Famille du produits

Marque

Emballage

Poids

Clé de substitution

Attributs de la

dimension

48

Hiérarchie (1)

◼ Les attributs/membres d'une dimension sont organisés suivant des hiérarchies Chaque membre appartient à un niveau hiérarchique

(ou niveau de granularité) particulier

Exemples :◼ Dimension temporelle : jour, mois, année

◼ Dimension géographique : magasin, ville, région, pays

◼ Dimension produit : produit, catégorie, marque, etc.

◼ Attributs définissant les niveaux de granularité sont appelés paramètres

◼ Attributs informationnels liés à un paramètre sont dits attributs faibles

Hiérarchie (2)

◼ Mono-hiérarchie

49

50

Hiérarchie (3)

◼ Hiérarchies multiples dans une dimension (plusieurs hiérarchies alternatives pour une

même dimension)

Année

Semestre

Semaine

Mois

Jour

Pays

Département

Ville

Client

Région de ventes

Secteur de ventes

51

Granularité

◼ Niveau de détail de représentation

Journée > heure du jour

Magasin > rayonnage

◼ Choix de la granularité

52

Fait◼ Sujet analysé

◼ un ensemble d'attributs appelés mesures (informations opérationnelles) les ventes (chiffre d'affaire, quantités et montants commandés, volumes des

ventes, ...)

les stocks (nombre d'exemplaires d'un produit en stock, ...),

les ressources humaines (nombre de demandes de congés, nombre de démissions, …).

◼ Un fait représente la valeur d’une mesure, calculée ou mesurée, selon un membre de chacune des dimensions

◼ Un fait est tout ce qu'on voudra analyser. Exemple : 250 000 euros est un fait qui exprime la valeur de la mesure Coût

des travaux pour le membre 2002 du niveau Année de la dimension Tempset le membre Versailles du niveau Ville de la dimension Découpage administratif.

◼ Le Fait contient les valeurs des mesures et les clés vers les dimensions

53

Mesure

◼ Élément de donnée sur lequel portent les analyses, en fonction des différentes dimensions.

◼ Ces valeurs sont le résultat d’opérations d’agrégation (SUM, AVG, …) sur les données Exemple :

◼ Coût des travaux

◼ Nombre d’accidents

◼ Ventes

◼ …

54

Clés

◼ Dimension

Clé primaire

◼ Fait

Clé composée

◼ Clés étrangères des dimensions

55

Modélisation

◼ Au niveau conceptuel, il existe 2 modèles :

en étoile (star schema)

ou en constellation (fact constellation schema)

56

Modèle en étoile (1)

◼ Le fait au centre et des dimensions autour

◼ Les dimensions n’ont pas de liaison entre elles

◼ Avantages : Facilité de navigation

Nombre de jointures limité

◼ Inconvénients : Redondance dans les dimensions

Toutes les dimensions ne concernent pas les mesures

Modèle en étoile (2)

◼ Représentation graphique

57

58

Modèle en étoile (3)

Sources : Lydie Soler, AgroTechParis

Etoile - Formalisme graphique de

Golfarelli (1)

◼ Représentation d’une dimension

59

◼ Schéma en étoile

60

Etoile - Formalisme graphique de

Golfarelli (2)

61

Constellation (1)

◼ Série d’étoiles

Fusion de plusieurs modèles en étoile qui

utilisent des dimensions communes

Plusieurs tables de fait et tables de

dimensions, éventuellement communes

62

Constellation

(2)

Sources : http://gankahhwee.com

63

Constellation - Formalisme

graphique de Golfarelli

Démarche en 5 étapes (1)

64Sources : F. Ravat, UT1

65

Démarche en 5 étapes (2)

Sources : F. Ravat, UT1

66

Démarche en 5 étapes (3)

Sources : F. Ravat, UT1

67Sources : F. Ravat, UT1

Démarche en 5 étapes (4)

68Sources : F. Ravat, UT1

Démarche en 5 étapes (5)

69Sources : F. Ravat, UT1

Démarche en 5 étapes (6)

NIVEAU LOGIQUE

70

71

Niveau logique

◼ Description de la base multidimensionnelle

suivant la technologie utilisée :

ROLAP (Relational-OLAP)

MOLAP (Multidimensional-OLAP)

HOLAP (Hybrid-OLAP)

72Sources : F. Ravat, UT1

73

ROLAP (1)

◼ Les données sont stockées dans une BD relationnelle

◼ Un moteur OLAP permet de simuler le comportement d’un SGBD multidimensionnel

◼ Avantages : Facile à mettre en place

Peu couteux

Evolution facile

Stockage de gros volumes

◼ Inconvénients : Moins performant lors des phases de calculs

◼ Exemple de moteur ROLAP : Mondrian

74

ROLAP (2)

Sources : EPFL, Lausanne

ROLAP (3)

◼ Principe : Faits et dimensions modélisés au travers

de tables [Kimball 96]

◼ Règles de transformation (données détaillées)

R1 : Toute dimension est transformée en une relation où :

◼ Attributs = tous les paramètres et attributs faibles

◼ Clé primaire = paramètre de plus bas niveau

R2 : Tout fait est transformé en une relation où :

◼ Clé primaire =

Concaténation des clés étrangères référençant les dimensions

OU

Clé synthétique

◼ Attributs = mesures + clés étrangères75

76

MOLAP (1)◼ Les données sont stockées comme des matrices à

plusieurs dimensions : Cube[1:m,1:n,1:p](mesure)

◼ Accès direct aux données dans le cube

◼ Avantages : Rapidité

◼ Inconvénients : Difficile à mettre en place

Formats souvent propriétaires

Ne supporte pas de rtès gros volumes de données

◼ Exemple de moteurs MOLAP : Microsoft Analysis Services

Hyperion

77

MOLAP (2)

Sources : EPFL, Lausanne

78

HOLAP (1)

◼ Solution hybride entre ROLAP et MOLAP

◼ Données de base stockées dans un SGBD

relationnel (tables de faits et de dimensions) +

données agrégées stockées dans un cube

◼ Avantages / inconvénients :

Bon compromis au niveau des coûts et des

performances (les requêtes vont chercher les

données dans les tables et le cube)

79

HOLAP (2)

Sources : EPFL, Lausanne

Synthèse

80

81

Modélisation

◼ Au niveau logique, il existe 1 modèle :

en flocon (snowflake schema)

82

Modèle en flocon (1)

◼ Modèle en étoile + normalisation des dimensions Une table de fait et des dimensions en sous-hiérarchies

Un seul niveau hiérarchique par table de dimension

La table de dimension de niveau hiérarchique le plus bas est reliée à la table de fait (elle a la granularité la plus fine)

◼ Avantages : Normalisation des dimensions

Economie d’espace disque (réduction du volume)

◼ Inconvénients : Modèle plus complexe (nombreuses jointures)

Requêtes moins performantes

Navigation difficile

83

Modèle en flocon (2)

Sources : Lydie Soler, AgroTechParis

NIVEAU PHYSIQUE

84

85

Niveau physique

◼ C’est l’implantation et dépend donc du logiciel utilisé.

◼ Globalement : insuffisance des instructions SQL classiques CREATE TABLE … AS … : recopie physique, à

reprendre intégralement lors de l’évolution des sources

CREATE VIEW … AS … : recalculé à chaque requête, temps de réponse inacceptable sur les volumes manipulés

◼ Optimisation : indexes, …

86

Quelques solutions commerciales

Bilan – Niveaux d’abstraction

87Sources : F. Ravat, UT1

Realisation d’un DW

88

89

Réalisation d’un DW

◼ Evolution des besoins et des sources

→ démarche itérative

◼ 3 techniques :

Top-down [Inmon]

Bottom-up [Kimball]

Middle-out

90

◼ Top-Down

Concevoir tout l’entrepôt intégralement

◼ Il faut donc connaître à l’avance toutes les dimensions et tous les faits.

Objectif : Livrer une solution technologiquement saine basée sur des méthodes et technologies éprouvées des bases de données.

Avantages :

◼ Offrir une architecture intégrée : méthode complète

◼ Réutilisation des données

◼ Pas de redondances

◼ Vision claire et conceptuelle des données de l’entreprise et du travail à réaliser

Inconvénients :

◼ Méthode lourde

◼ Méthode contraignante

◼ Nécessite du temps

91

◼ Bottom-Up (approche inverse)

Créer les datamarts un par un puis les regrouper par des niveaux intermédiaires jusqu'à obtention d'un véritable entrepôt.

Objectif : Livrer une solution permettant aux usager d’obtenir facilement et rapidement des réponses à leurs requêtes d’analyse

Avantages : ◼ Simple à réaliser,

◼ Résultats rapides

◼ Efficace à court terme

Inconvénients : ◼ Pas efficace à long terme

◼ Le volume de travail d'intégration pour obtenir un entrepôt de données

◼ Risque de redondances (car réalisations indépendantes).

92

◼ Middle-Out (approche hybride)

Concevoir intégralement l'entrepôt de données (toutes les dimensions, tous les faits, toutes les relations), puis créer des divisions plus petites et plus gérables.

Avantages : ◼ Prendre le meilleur des 2 approches

◼ Développement d’un modèle de données d’entreprise de manière itérative

◼ Développement d’une infrastructure lourde qu’en cas de nécessité

Inconvénients :◼ implique, parfois, des compromis de découpage (dupliquer

des dimensions identiques pour des besoins pratiques).

93

Ne pas oublier… (1)

◼ Le volume de données manipulées

94

Ne pas oublier… (2)

◼ Voici 5 étapes importantes pour la

réalisation d’un DW :

Conception

Acquisition des données

Définition des aspects techniques de la

réalisation

Définition des modes de restitution

Stratégies d’administration, évolution,

maintenance

95

1 - Conception

◼ Définir la finalité du DW : Quelle activité de l’entreprise faut-il piloter?

Quel est le processus de l’entreprise à modéliser?

Qui sont les décideurs?

Quels sont les faits numériques? ◼ Qu’est ce qui va être mesurer?

Quelles sont les dimensions ? ◼ Comment les gestionnaires décrivent-ils des données qui

résultent du processus concerné?

◼ Définir le modèle de données : Modèle en étoile / flocon ?

et/ou Cube?

et/ou Vues matérialisées?

96

2 – Acquisition des données

◼ Pour l’alimentation ou la mise à jour de

l’entrepôt

Mise à jour régulière

Besoin d’un outil pour automatiser les

chargements de l’entrepôt :

ETL (Extract, Transform, Load)

97

3 – Aspects techniques

◼ Contraintes

logicielles,

matérielles,

humaines,

98

4 - Restitution

◼ = But du processus d’entreposage,

◼ = Conditionne souvent le choix de l’architecture et de la construction du DW

◼ Toutes les analyses nécessaires doivent être réalisables !

◼ Types d’outils de restitution :

Requêteurs et outils d’analyse

Outils de data mining

99

5 – Administration, maintenance

◼ Toutes les stratégies à mettre en place

pour l’administration, l’évolution et la

maintenance

Ex : fréquences des rafraichissements (global

ou plus fin?)

Restitutions

décisionnelles

100

101Sources : F. Ravat, UT1

Restitutions décisionnelles (1)

◼ Résultats

Différents supports possibles

◼ Tableaux de bord : nombreux indicateurs pour

pilotage avec tableaux récapitulatifs

◼ Rapports d’activité : tableau simple ou croisé avec

graphiques

◼ Comptes-rendus : document avec de l’analyse

décisionnelle, des données chiffrées (tableaux) et

des graphiques

Contenu : global ou dédié

102

Restitutions décisionnelles (2)◼ Vision fonctionnelle

Consultation décisionnelle

Interrogation

◼ Interrogation graphique

◼ Interrogation à la demande (requêtes Ad-hoc en SQL/MDX)

Analyses personnelles

◼ Format des restitutions : tableau, graphique, …

◼ Analyses : recherche particulière, analyse multidimensionnelle, simulation, …

Analyses OLAP

◼ Compétences en modélisation multidimensionnelle

◼ Opérations OLAP (roll-up, slice, …)

Analyse prédictive (datamining / machine learning)

◼ Corrélations entre données

Outil pour un métier spécifique : RH, finance, …

103

Restitutions décisionnelles (3)

104

Restitutions décisionnelles (4)

105

REPRÉSENTATION ET

MANIPULATION

106

107

Cube (1)

◼ Le cube de données

◼ est traditionnellement représenté sous

forme de table multidimensionnelle

◼ et manipulé via différents opérateurs

108

Cube (2)

◼ Modélisation multidimensionnelle des

données facilitant l’analyse d’une quantité

selon différentes dimensions :

Temps,

Localisation géographique,

◼ Les calculs sont réalisés lors du

chargement ou de la mise à jour du cube.

109

Cube (3)

110

Table multidimensionnelle (1)

◼ La table multidimensionnelle

Présente les valeurs des mesures d'un fait en

fonction des valeurs des paramètres des dimensions

représentées en lignes et en colonnes étant données

des valeurs des autres dimensions

◼ les lignes et les colonnes sont les axes selon lesquels le

cube est exploré et chaque cellule contient la (ou les)

mesure(s) calculée(s).

correspond à une tranche du cube multidimensionnel

Table multidimensionnelle (2)

111Sources : F. Ravat, UT1

112

◼ Exemple :

113

Opérateurs OLAP

◼ Opérateurs de visualisation du cube (Cube -> Cube)

Transformation de la granularité des données

(Forage)

Sélection / projection sur les données du cube

Restructuration / réorientation du cube

114

◼ Opérations de forage (liées à la granularité)

Roll-up (forage vers le haut) :

◼ Représente les données à un niveau de granularité

supérieur selon la hiérarchie de la dimension désirée

Agréger selon une dimension

▪ Semaine -> Mois

Drill-down (forage vers le bas) :

◼ Inverse du roll-up

◼ Représente les données à un niveau de granularité

inférieur

Détailler selon une dimension

▪ Mois -> Semaine

115

Roll-Up Drill-downsur la dimension Géographie

116

◼ Opérations de sélection / projection

Slice :

◼ Sélection

◼ Tranche du cube obtenue par prédicats selon une

dimension

Mois = « Avril 2004 »

Dice :

◼ Projection selon un axe

◼ Sorte de cumuls de sélection

Projeter(Région, Produit)

117

Slice (Année = « 2005 »)

118

Dice (Département = « Loir et Cher » ou « Gironde »,

Année = « 2007 » ou « 2008 »)

119

◼ Opérations de restructuration / réorientation Pivot (ou Rotate)

◼ Tourne le cube pour visualiser une face différente (Région, Produit) -> (Région, Mois)

Switch (ou Permutation)◼ Inter-change la position des membres d’une dimension

Nest ◼ Imbrique des membres issus de dimensions différentes

Push (ou Enfoncement)◼ Combine les membres d’une dimension aux mesures (les membres

deviennent le contenu des cellules)

AddM, DelM◼ Pour l’ajout et la suppression de mesures à afficher

120

Pivot (Temps.Année, Géographie.Département

-> Temps.Année, Véhicules.Couleur)

121

Nest (Véhicules.Couleur, Temps.Année)

122

Push (Véhicules.Couleur)

Bilan

123

BI traditionnelle◼ Avantages :

Données : consolidées, unifiées, historisées

Analyses / restitutions faciles

Solution mature

Très adaptée aux données structurées voire semi-structurées

◼ Inconvénients :

Travail en amont conséquent (80% du temps et du coût) :

analyse, conception, déploiement et maintenance

Infrastructures coûteuses : nombreux outils à combiner

◼ Caractéristiques :

Forte implication des services IT

Large panel d’analyses : tableaux de bord prédéfinis mis à

disposition jusqu’à la BI en « self-service » 124

125

Quelques solutions Open source

BI 3.0

Big Data Analytics?

126

DATA LAKE

127

Data Lake : Lac de données (1)

128Sources : www.emc.com

Data Lake : Lac de données (2)

◼ Principe : Pas de connaissance a priori des besoins d’analyse

◼ Définition :

Un Data lake permet de :

Intégrer les données brutes provenant de diverses sources

◼ Données structurées provenant de BD relationnelles (BD production,

entrepôts, …)

◼ Données semi-structurées : CSV, logs, XML, JSON

◼ Données non structurées : emails, documents, PDF, …

Stocker les données dans leur format natif avec des technologies à

faible coût

Traiter les données uniquement lorsqu’elles sont utilisées

Fournir des accès à des data scientists, data analysts et BI professionals

Gérer la qualité des données, la sécurité des données et le cycle de vie

des données129

Data Lake : Lac de données (3)

130

Data Lake : Lac de données (4)

131

Data Lake : Architecture

fonctionnelle (1)

132

133

Data Lake : Architecture

fonctionnelle (2)

Data Lake : Architecture

fonctionnelle (3)

134

Data Lake : Bilan (1)◼ Avantages :

Pas de connaissance des besoins au préalable

Pas de conception initiale des schémas de données

Intégration de grands volumes de données

Intégration de tous types de données

◼ Inconvénients :

Solution non mature (concept et architecture fonctionnelle)

Infrastructures matérielles très (trop?) variées

Phase d’analyse et de restitution fastidieuses

◼ Caractéristiques :

S’adresse à un public de plus en plus large

Large panel d’analyses : reporting, interrogation, Machine learning, …135

Data Lake : Bilan (2)

136

Data Lake : Bilan (3)◼ Data Lake et Entrepôt sont complémentaires

137

LES OUTILS BI 3.0

138

Les outils BI 3.0 (1)

◼ Constat

Croissance des volumes de données disponibles :

◼ 2018 : volume total stocké (monde entier) = 33

zettaoctets.

◼ D’ici 2025 : multiplié par 5,3 = 175 Zo = 175 milliards de

téraoctets.

90% sont constitués d’images, de vidéo et de

musique : majoritairement des données « non

structurées » et hétérogènes

Ces données sont difficilement traitables avec les

techniques classiques 139

Les outils BI 3.0 (2)

◼ Besoins :

Technologies pour acquérir, stocker, combiner et diffuser

des mégadonnées (Big Data) : variées, véloces,

volumineuses, …

Effectuer des analyses, en (quasi) temps réel sur des Big

Data de manière itérative

Supporter la collaboration

◼ Nouvelles technologies émergentes :

Hadoop, Map Reduce, …

DataViz avancée,

140

141

142

Ouvrages intéressants (disponibles à la BU)

◼ « Data Warehouse Design: Modern Principles

and Methodologies » de Matteo Golfarelli et

Stefano Rizzi, 2009, Ed: Osborne/McGraw-Hill.

◼ « Olap Solutions: Building Multidimensional

Information Systems » de E. Thomsen, 2002,

Ed: John Wiley & Sons Inc.

◼ « The enterprise big data lake delivering the

promise of big data and data science » de A.

Gorelik, 2019, Ed: iO’Reilly Media

143

Exercice

On considère un entrepôt de données permettant d’observer les ventes de produits d’une entreprise. Le schéma des tables est le suivant :

◼ CLIENT (id-client, région, ville, pays, département)

◼ PRODUIT (id-prod, catégorie, coût-unitaire, fournisseur, prix-unitaire, nom-prod)

◼ TEMPS (id-tps, mois, nom-mois, trimestre, année)

◼ VENTE (id-prod, id-tps, id-client, date-expédition, prix-de-vente, frais-de-livraison)

Questions

1. Indiquer quelles sont la (les) table(s) de fait et les tables de dimension de cet entrepôt.

2. Donner pour chaque dimension, sa (multi-) hiérarchie.

3. Donner la représentation du schéma en étoile de l’entrepôt selon la notation de Golfarelli.

4. On veut transformer ce schéma en schéma en flocon. Donner la nouvelle représentation de la table TEMPS (ajouter des paramètres / attributs, si nécessaire)

top related