Datawarehouse

1
 Plan

 Ce qu’est le datawarehouse ?

 Un modèle multidimensionnel

 Architecture d’un datawarehouse

 Implémentation d’un datawarehouse

 Autres développements de la technologie data cube

2
 Ce qu’est le datawarehouse ?

 Différentes définitions pas très rigoureuses

 Une BD d’aide à la décision qui est maintenue

séparément de la base opérationnelle de

l’organisation
 “Un datawarehouse est une collection de
données concernant un sujet particulier, varie
dans le temps, non volatile et où les données
sont intégrées.”—W. H. Inmon
 Datawarehousing:
 Le processus qui permet de construire un

data warehouse
3
 Sujet

 Organisé autour d’un sujet bien précis, ex: client,

produit, ventes.
 S’intéresse à la modélisation et l’analyse des données
pour aider les décideurs, non pas pour des activités
quotidiennes ou traitement transactionnel
 Fournit une vue simple et concise concernant un sujet
particulier en excluant les données qui ne servent pas à
la prise de décision

4
 Données intégrées
 Construit en intégrant plusieurs sources de données
possiblement hétérogènes
 BD’s relationnelles, fichiers plats, …
 Les techniques d’intégration et de nettoyage des
données sont utilisées
 Garantir la consistance des conventions de

nommage (les attributs Nom et Nom_Famille dans

BD1 et BD2 désignent la même chose)
 structures de codage (l’attribut Nom est sur 15 char

et 20 char sur BD1 et BD2; NSS est une chaîne dans

BD1 et c’est un entier long dans BD2),
 domaines des attributs (ex: cm vs pouce), etc.

 C’est au moment où les données sont copiées dans

le data warehouse qu’elles sont traduites

5
 Varie dans le temps
 La portée temporelle des données dans un
datawarehouse est plus longue que celle des bases
opérationnelles
 Base opérationnelle: valeur courante des données.
 Datawarehouse: fournit des infos sous une perspective
historique (ex: 5 à 10 dernières années)
 Dans un datawarehouse, en général, chaque donnée fait
référence au temps
 Mais dans une base opérationnelle les données
peuvent ne pas faire référence au temps

6
 Datawarehouse est Non-Volatile
 Un support de stockage séparé
 Les mises à jour de la base opérationnelle n’ont pas lieu
au niveau de la datawarehouse
 N’a pas besoin de modules de gestion de transactions
(concurrence, reprise sur panne …)
 N’a besoin que de deux opérations pour accéder aux
données :
 Chargement initial des données et interrogation
(lecture).

7
 Datawarehouse vs. SGBD hétérogènes
 Traditionnellement, l’intégration de BD’s hétérogènes se
fait par le biais de:
 mediateurs au dessus des BD’s hétérogènes
 Approche orientée requête
 Quand une requête est posée par un site client, un méta-
dictionnaire est utilisé pour la traduire en plusieurs requêtes
appropriées à chacune des BD’s. Le résultat est l’intégration
des réponses partielles.
 L’exécution des requêtes demande donc beaucoup de
ressources
 Datawarehouse: Approche orientée mise à jour
 Les infos sont intégrées et stockées pour une interrogation
directe. Plus efficace en coût d’exécution des requêtes

8
 Datawarehouse vs. BD Opérationnelle
 OLTP (On-Line Transaction Processing)
 Exécution en temps réel des transactions, pour l’ enregistrement des
opérations quotidiennes: inventaire, commandes, paye, comptabilité
 Par opposition aux traitements en batch
 OLAP (On-Line Analytical Processing)
 Traitement efficace des requêtes d’analyse pour la prise de décision
qui sont en général assez complexes (bien qu’a priori, elles peuvent
être réalisées par les SGBD classiques)
 OLTP vs. OLAP :
 Données: courantes, détaillées vs. historiques, consolidées
 Conception : modèle ER + application vs. Modèle en étoile + sujet
 Vue : courante, locale vs. évolutive, intégrée
 Modes d’accès: mise à jour vs. lecture seule mais requêtes
complexes

9
 OLTP vs. OLAP
OLTP OLAP
utilisateurs Tout le monde décideurs
fonction Opérations journalières Aide à la décision
DB design Orienté applications Orienté sujet
data courante, à jour, relationnel plat historiques, résumés,
multidimensionnelle
intégrées
usage répétitive ad-hoc
accès read/write Beaucoup de scans
index/hash sur clés
Unité de travail Transactions courtes Requêtes complexes
# enregistrement dizaines millions
# utilisateurs Centaine(s) Dizaine(s)
Taille BD 100MB-GB 100GB-TB
métrique Exécution des transactions Temps de réponse aux requêtes

10
 Pourquoi pas des BD’s pour
datawarehouses
 Les 2 systèmes sont performants
 SGBD— calibrés pour l’OLTP: méthodes d’accès, index,

contrôle de concurrence, reprise

 Warehouse—calibrés pour l’OLAP: requêtes OLAP

complexes, vue multidimensionnelle, consolidation.

 Fonctions et données différentes:
 Données manquantes: l’aide à la décision a besoin des

données historiques qui ne se trouvent pas dans les

BD’s opérationnelles
 Consolidation: l’AD a besoin de données consolidées

(agrégats) alors qu’elles sont brutes dans les BD’s

opérationnelles
11
 Technologie OLAP

 Ce qu’est le data warehouse ?

 Un modèle multidimensionnel

 Architecture d’un data warehouse

 Implémentation d’un data warehouse

 Autres développements de la technologie data cube

 Data warehousing et data mining

12
 Des Tables aux Data cubes
 Le datawarehouse est basé sur un modèle multidimensionnel où les
données sont vues comme des data cubes
 Un data cube, ex: ventes, permet de voir les données selon
plusieurs dimensions
 Les tables de dimension ex: item (nom_item, marque, type), ou
temps(jour, semaine, mois, trimestre, année)
 La table de faits contient des mesures (ex: unités_vendues) et
les clés externes faisant référence à chaque table de dimension
 Dans la littérature du datawarehousing, un cube de dimension n
est dit un cuboïde. Le treillis des cuboïdes d’un datawarehouse
forme un data cube.

13
 Cube: Un treillis de
cuboïdes

tous
0-D cuboïde

temps item lieu fournisseur

1-D cuboïdes

temps,item temps,lieu item,lieu Lieu, fournisseur

2-D cuboïdes
Temps, fournisseur item,fournisseur

temps,lieu, fournisseur
temps,item,lieu 3-D cuboïdes
Temps, item, fournisseur item,lieu, fournisseur

4-D cuboïde
Temps, item,lieu,fournisseur
14
 Modélisation Conceptuelle
des Data Warehouses
 Dimensions & mesures
 Schéma en étoile: Au milieu, une table de faits
connectée à un ensemble de tables de dimensions
 Schéma flocon de neige (snowflake): Un raffinement
du précédent où certaines tables de dimensions sont
normalisées (donc décomposées)
 Constellation de faits: Plusieurs tables de faits
partagent quelques tables de dimension (constellation
d’étoiles)

15
 Exemple de schéma en étoile
temps
Id_temps item
jour Id_item
Jour_semaine Table de faits “ventes” Nom_item
mois marque
trimestre id_time type
année Type_fournisseur
id_item
id_branche
branche lieu
id_lieu
Id_branche Id_lieu
Nom_branche unités_vendues rue
Type_branche ville
montant_ventes département
pays
moyenne_ventes
Mesures

16
 Exemple de schéma Snowflake
temps fournisseur
item
Id_temps Id_fournisseur
Id_item
jour Type_fournisseur
Jour_semaine Table de faits “Vente” Nom_item
Marque
mois type
trimestre Id_temps
Id_fournisseur
année Id_item
Id-branch
lieu
branche Id_lieu
Id_lieu
Id_branche
unités_vendues rue
Nom_branche
Id_ville ville
Type_branche
montant_vente
Id_ville
moyenne_vente ville
département
Mesures pays

17
 Exemple de Constellation de faits
temps
Table de faits Transport
Id_temps item
jour Table de faits Vente Id_item Id_temps
Jour_semaine Nom_item
mois Id_temps marque Id_item
trimestre type Id_transporteur
année Id_item Id_fourniseur
Id-branche id_départ

Id_lieu lieu id_arrivée

branche
Id_lieu coût
Id_branche unités_vendues
rue
Nom_branche Unités_transportées
montant_vente ville
Type_branche département
moyenne_vente pays transporteur
Meesures Id_Transporteur
Nom_transporteur
Id_lieu
Type_transporteur 18
 Hiérarchie de la Dimension Lieu

tous all

continent Europe ... Amérique

pays Allemagne ... Espagne Canada ... Mexique

ville Frankfurt ... Vancouver ... Toronto

magasin L. Chan ... M. Wind

19
Une vue d’une warehouse et ses hiérarchies

Specification des hiérarchies

 Hiérarchie dans le schéma
jour < {mois < semestre;
semaine} < année
 Hiérarchie d’ensembles
{1..10} < pas_chère

20
 Données multidimensionnelles
 Montant des ventes comme une fonction des
paramètres produit, mois, région
Dimensions: Produit, Lieu, Temps
on

Chemins de consolidation hiérarchiques

gi
Ré

Industrie Région Année

Produit

Catégorie Pays Trimestre

Produit Ville Mois Semaine

Magasin Jour
Mois
21
 Un exemple de Data Cube
Total annuel des ventes
Date de TV aux U.S.A.
1Trim 2Trim 3Trim 4Trim sum
t

TV
ui

100 200 300 100 700

od

PC U.S.A
Pr

DVD
sum
Canada

Pays
Mexique

sum

22
 Cuboïdes Correspondants au Cube

tous
Cuboïde 0-D(apex)
produit date pays
Cuboïde 1-D

produit,date produit,pays date, pays

Cuboïde 2-D

cuboïde3-D(base)
produit, date, pays

23
 Opérations typiques de l’OLAP

 Roll up : consolider (résumer) les données

 Passer à un niveau supérieur dans la hiérarchie
d’une dimension
 Drill down : l’inverse du Roll-up
 descendre dans la hiérarchie d’une dimension
 Slice et Dice:
 Projection et sélection du modèle relationnel
 Pivot (rotate):
 Réoriente le cube pour visualisation

24
 Un Modèle pour représenter
les requêtes
COMMANDES CLIENTS
MODE TRANSPORT
CLIENT
Contrats
AIR-EXPRESS

Commande
Camion
Catégorie Groupe
TEMPS
Année Trimestre Jour Item PRODUIT
Ville
Vendeur
Pays
Rayon

Contient
Magasin
LIEU
ORGANISME
25
 Ce qu’est le data warehouse ?

 Un modèle multidimensionnel

 Architecture d’un data warehouse

 Implémentation d’un data warehouse

 Autres développements de la technologie data cube

 Data warehousing et data mining

26
 Trois modèles de datawarehouse
 Entreprise warehouse
 Collecte de toutes les informations concernant les sujets

traités au niveau de l’organisation

 Data Mart
 Un sous ensemble d’un entreprise warehouse. Il est

spécifique à un groupe d’utilisateurs (ex: data mart du

marketing)
 Datawarehouse virtuel
 Un ensemble de vues définies à partir de la base

opérationnelle
 Seulement un sous ensemble des vues sont

matérialisées

27
 Architecture des serveurs OLAP
 Relational OLAP (ROLAP)
 Utilise un SGBD relationnel pour stocker les données ainsi

qu’un middle-ware pour implémenter les opérations

spécifiques de l’OLAP (Oracle, SQL Server,..)
 Multidimensional OLAP (MOLAP)
 Basé sur un stockage par tableaux (techniques des

matrices creuses)
 Indexation rapide de données calculées (Hyperion

Essbase)

28
 Ce qu’est le data warehouse ?

 Un modèle multidimensionnel

 Architecture d’un data warehouse

 Implémentation d’un data warehouse

 Autres développements de la technologie data cube

 Data warehousing et data mining

29
 Calcul efficace d’un data cube

 Un data cube peut être vu comme un treillis de cuboïdes

 Le plus bas dans la hiérarchie est le cuboïde de base
 Le plus haut contient une seule cellule (appelé apex)
 Combien de cuboïdes y-a-il dans un cube à n
n
dimensions avec Li niveaux chacune? T   ( Li 1)
i 1
 Matérialisation du data cube
 Matérialiser chaque cuboïde (matérialisation totale),
aucun , ou quelques (matérialisation partielle)
 Sélection des cuboïdes à matérialiser
 Basé sur la taille, partage, fréquence d’accès, etc.

30
 Opérations sur les cubes

 l’opérateur cube by est ajouté à SQL

SELECT item, ville, année, SUM (montant)
FROM VENTES
CUBE BY item, ville, année ()
 C’est équivalent aux Group-By suivants
(item, ville, année), (item) (ville) (année)
(item, ville),(item, année), (ville, année),
(item), (ville), (année)
() (item,ville) (item, année) (ville, année)

(item, ville, année)

31
 Exemple: Matérialisation partielle

 Comme données de base, nous avons des

informations sur des produits proposés par des
fournisseurs et vendus à des clients à un prix
PV. Les informations s’étalent sur 10 ans.
 Les analystes voudraient poser des requêtes
sur une table où chaque (p,f,c) est associé à
une mesure TV (total ventes)
 Le produit p proposé par f a été vendu à c pour
un montant global TV (sur les 10 ans)

32
 Exemple
 On considère un ensemble de requêtes, un ensemble de vues
possibles. La question: quelles vues matérialiser pour répondre à
toutes les requêtes, si le nombre de vues ne doit pas dépasser un
certain seuil

 Les requêtes considérées sont de la forme

SELECT <g-attributs>, SUM (<mesure>)
FROM <la table de base>
WHERE <attribut = valeur>
GROUP BY <g-attributs>

 SELECT Produit, Client, SUM(TV)

FROM Table
WHERE Client=‘Toto’
GROUP BY (Produit, Client)

33
 Exemple
 Les vues considérées sont de la forme
SELECT <g-attributs>, SUM(<mesure>)
FROM Table
GROUP BY <g-attributs>

 Dans l’exemple, il y a 8 vues:

 Produit, fournisseur, client (6M tuples)

 Produit, client (6M)

 Produit, fournisseur (0,8M)

 Fournisseur, Client (6M)

 Produit (0,2M)

 Fournisseur (0,01)

 Client (0,1M)

 Ø (1)

34
 Exemple

PFC 6M

PC 6M PF 0,8M FC 6M

P 0,2 M F 0,01 C 0,1

Ø
35
 Exemple
 V l’ensemble des vues et Vk ={W de 2V : |W| = k }
Trouver W tel que
Gain(W) = Max (Gains Wi avec |Wi |=k)
 On définit un pré-ordre sur les vues: v  w si v peut être calculée à
partir de w
 A chaque fois que l’on décide de matérialiser une vue w, les vues v
telles v  w ont un bénéfice B
 Bénéfice(v, S) = somme B(w,v,S) avec w v avec B(w,v,S)=le gain
qu’on aura pour calculer w en rajoutant v à S
 Gain (W)=somme(Bénéfice(v): v élément de W)
 Si n est le nombre total de vues, alors on a n! / (n-k)!k! ensembles de
vues à k éléments qu’il faut tester. L’algorithme de recherche de la
solution optimal est en temps exponentiel

 Algorithme approchée
S= {top view}
For i=1 to k
S=S union {v} t.q Bénéfice (v,S) soit maximale
Return s
36
 Exemple
a 100

b 50 c 75

d 20 e 30 f 40

g1 h 10
Initialisation : S={a}
Étape 1:
Bénéfice(b,S)=50*5=250 Bénéfice(c,S)=25*5=125
Bénéfice(d,S)=80*2=160 Bénéfice(e,S)=70*3=210
Bénéfice(f,S)=60*2=120 Bénéfice(g,S)=99*1=99
Bénéfice(h,S)=90*1=90 S=S+={b}

37
 Exemple

a 100

b 50 c 75

d 20 e 30 f 40

g1 h 10

Initialisation : S={a,b}
Étape 2:
Bénéfice(c,S)=25*2=50 Bénéfice(d,S)=30*2=60
Bénéfice(e,S)=20*3=60 Bénéfice(f,S)=60+10=70
Bénéfice(g,S)=49*1=49 Bénéfice(h,S)=40*1=40

S=S+={f}

38
 Exemple
a 100

b 50 c 75

d 20 e 30 f 40

g1 h 10

Initialisation : S={a,b,f}
Étape 3:
Bénéfice(c,S)=25*1=50 Bénéfice(d,S)=30*2=60
Bénéfice(e,S)=20+20+10=50 Bénéfice(g,S)=49*1=49
Bénéfice(h,S)=30*1=30 c,d,f c=50 d=135 f=70

S=S+={d}

39
 Exemple
 S={a,b,d,f}
 Bénéfice(b,S)=50*2=100

 Bénéfice(d,S)=30*2=60

 Bénéfice(f,S)=60+10=70

Gain(S)=230
 S*={a,c,d,f }
 Bénéfice(c,S*)=50

 Bénéfice(d,S*)=135

 Bénéfice(f,S*)=70

Gain(S*)=255
 Théorème : Soit S* la solution optimale et S la solution
retournée par l’algorithme. Alors, Gain(S)  63% de
Gain(S*) (e-1)/e
40
 Matérialisation totale: Multi-way Array
Aggregation for Cube Computation
 Partitionner les tableaux en des portions (chunk : un petit sous-cube qui peut être chargé
en mémoire)
 Adressage de tableaux creux compressés : (chunk_id, offset)
 Calculer les agrégats en “multiway” en visitant les cellules du cube de sorte à (i) minimiser
le # de fois que chaque cellule est visitée et (ii) réduire les coûts d’accès et de stockage

C c3 61
c2 45
62 63 64
46 47 48
c1 29 30 31 32 Quel est l’ordre
c0
b3 B13 14 15 16 60 préférentiel
44
9
28 56 pour parcourir
b2
B 40
24 52 le cube dans le
b1 5 36 cadre d’une
20
b0 1 2 3 4 agrégation?
a0 a1 a2 a3
A 41
 Exemple
 On doit calculer les cuboïdes A, B, C, AB, BC, AC, ABC et Ø
 Supposons que les dimensions A,B et C ont les tailles 40, 400, 4000. La taille de
chaque partition de A,B et C est donc 10, 100 et 1000. Ex: A:magasins, B: Date,C:
Produit et la mesure: #produits vendus
 La portion a0b0c0 correspond à 1, a1b0c0 correspond à 2, …
 Supposons que l’on veuille calculer le cuboïde BC. Ceci peut se faire en calculant les
cuboïdes bicj .
 Pour calculer b0c0, il faut parcourir les portions 1,2,3,4. Pour b 1c0, on lit 5,6,7,8. Au
total, Pour BC, on doit scanner les 64 portions.
 Pour calculer les cuboïdes AC et AB, faut-il rescanner les 64? NON
 Quand la portion 1 (a0b0c0) est scannée, on peut en profiter pour entamer le
calcul de a0b0 et a0c0 d’où le terme Multi-way aggregation.
 Donc, en scannant les 64 portions une seule fois chacune, on peut calculer les 3
cuboïdes AB, AC et BC
42
 Exemple
 Les tailles de AB, AC et BC sont resp. 16.103, 16.104 et 16.105

 En parcourant les portions de 1 à 64 dans cet ordre, b0c0 est calculé en

lisant 1,2,3,4 ; b1c0 calculé en lisant 5,6,7,8 …
a0b0 est calculé en utilisant 1, 17, 33 et 49 (49 portions)
a0c0 est calculé en utilisant 1, 5, 9 et 13 (13 portions)

 Pour éviter qu’une portion ne soit chargée plus d’une fois, l’espace tampon
minimum doit être: 40*400 (plan AB)+40*1000 (une ligne du plan AC) +
100*1000(une portion de BC)=156 000

 Supposons que l’ordre de parcours est 1, 17, 33, 49, 5, 21, 37, 53, …
agrégation selon AB, puis AC puis BC. L’espace mémoire requis est
400*4000(plan BC)+40*4000(une ligne de AC)+10*100(portion de AB)=1
641 000

 Conclusion: L’ordre de prise en compte des dimensions est important. Il

faut trier les plans dans l’ordre croissant de leur taille (AB est le plus petit)
puis parcourir les portions en tenant compte de cet ordre. 43
Multi-way Array Aggregation for
Cube Computation

C c3 61
c2 45
62 63 64
46 47 48
c1 29 30 31 32
c0
B13 14 15 16 60
b3 44
B 28 56
b2 9
40
24 52
b1 5
36
20
b0 1 2 3 4
a0 a1 a2 a3
A

44
Multi-way Array Aggregation for
Cube Computation

C c3 61
c2 45
62 63 64
46 47 48
c1 29 30 31 32
c0
B13 14 15 16 60
b3 44
B 28 56
b2 9
40
24 52
b1 5
36
20
b0 1 2 3 4
a0 a1 a2 a3
A

45
 Pas de matérialisation: Indexation de
données OLAP: Index Bitmap
 Index sur une colonne particulière
 Chaque valeur dans la colonne a un vecteur de bits : opérations
sur les bits sont rapides
 La longueur du vecteur de bits: # de la table de base
 Le i-ème bit=1 si la i-ème ligne de la table de base possède la
valeur de la colonne indexée
 Ne convient que pour les domaines de faible cardinalité

Table de base Index sur Région Index sur Type

Cust Region Type RowIdAsie EuropeAmérique RecID Gross Détaill
C1 Asie Gross 1 1 0 0 1 1 0
C2 Europe Détaill 2 0 1 0 2 0 1
C3 Asie Détaill 3 1 0 0 3 0 1
C4 AmériqueGross 4 0 0 1 4 1 0
C5 Europe Détaill 5 0 1 0 5 0 1
46
 Indexing OLAP Data: Index de jointure
 Index de jointure : JI(R-id, S-id) où
R (R-id, …)  S (S-id, …)
 En général, un index associe une valeur à
une liste d’Id d’enregistrements
 matérialise la jointure dans un fichier JI

pour accélérer l’exécution de la jointure

 Dans les data warehouses, un index de
jointure relie des valeurs de dimensions à
des lignes de la table de faits.
 Ex. Table de faits: Sales et 2

dimensions ville et produit

 Un index de jointure sur ville

maintient pour chaque ville une liste

de ID-enreg’s de tuples concernant
des ventes dans la ville en question
 Les index de jointure peuvent être

partagés par plusieurs dimensions

47
 Traitement efficace des requêtes
OLAP

 Déterminer quelles sont les opérations à effectuer sur les

cuboïdes disponibles :
 transformer drill, roll, etc. en des requêtes SQL et/ou
opérations OLAP, ex, dice = sélection + projection
 Déterminer sur quel cuboïde matérialisé l’opération doit
être exécutée.
 Exploiter les structures d’index disponibles

48
 Data Warehouse : Utilitaires
 Extraction :
 Récupérer les données à partir des sources
 Nettoyage :
 détecter les erreurs et les corriger si possible
 Transformation :
 Convertir les formats
 Charger:
 Trier, consolider, calculer des vues, vérifier des
contraintes, construire des index, vérifier des
contraintes
 Rafraîchir
 Propager les mises à jour des sources sur le data
warehouse

49
 Résumé
 Data warehouse
 Données orientées sujet, intégrées, dépendant du temps, et non-
volatiles pour la prise de décision
 Un modèle multidimensionnel pour les data warehouses
 Schéma en étoile, schéma snowflake, constellation
 Un data cube est decrit par des dimensions et des mesures
 Opérations OLAP : drilling, rolling, slicing, dicing and pivoting
 OLAP servers: ROLAP, MOLAP, HOLAP
 Implémentation des data cubes
 Matérialisation Partielle vs. totale vs. nulle
 Sélection des cuboïdes à matérialiser

 Multiway array aggregation

 Implémentation avec Bitmap index et join index

50