30
1 La Modélisation Les ntrepôts de onnées (Data Warehouses) 2 Les Faits La défini-on Un fait est la plus pe-te informa-on analysable. C'est une informa-on qui con-ent les données observables (les faits) que l'on possède sur un sujet et que l'on veut étudier, selon divers axes d'analyse (les dimensions). Les « faits » dans un entrepôt de données, sont normalement numériques , puisque d'ordre quan-ta-f. Il peut s'agir du montant en argent des ventes, du nombre d'unités vendues d'un produit, etc.

3-Modelisation.ppt

  • Upload
    omar-ah

  • View
    11

  • Download
    1

Embed Size (px)

DESCRIPTION

modelisation

Citation preview

1

La Modélisation

Les ntrepôts de onnées

(Data Warehouses)

2

Les$Faits

La$défini-on$!

Un!fait!est!la!plus!pe-te!informa-on!analysable.!C'est!une!informa-on!qui!con-ent!les!données!observables!(les$faits)!que!l'on!possède!sur!un!sujet!et!que!l'on!veut!étudier,!selon!divers!axes!d'analyse!(les$dimensions).! !Les!«!faits!»!dans!un!entrepôt!de!données,!sont!normalement!numériques,!!puisque!d'ordre!quan-ta-f.!!Il!peut!s'agir!du!montant-en-argent-des-ventes,!du!nombre-d'unités-vendues-d'un-produit,!etc.

3

Les$Faits$$(suite)

La$défini-on$(suite)$!

Les!faits!représentent!des!associa-ons!dont!l'existence!d'une!occurrence!dépend!de!l'existence!des!occurrences!correspondantes!parmi!les!descripteurs!dimensionnels.!!C'estGàGdire,! la! ''table''! de! faits! con-ent! l'ensemble! des! mesures! correspondant! aux!informa-ons!de!l'ac-vité!à!analyser.!!!Mais$certaines$tables$de$faits$peuvent$ne$contenir$aucun$a;ribut$et$représentent$des$liaisons$

entre$tables$dimensionnelles.! !!Tous!les!éléments!qui!pointent!sur!la!table!de!faits!sont!liés!à!une!séman-que!exprimable!par!une!phrase.!Par!conséquent,!la!''table''!de!faits!est!la!matérialisa-on!d'une!associa-on!entre!n!en-tés.!!

4

Structure$de$base$d'une$''table''$de$faits$$!

Une!''table''!de!faits!devrait!avoir!la!structure!suivante!:!!

Les$Faits$(suite)

Date%cal.%(FK)

Id%Dim1%(FK)

Id%Dim2%(FK)

Id%Dimn%(FK)

Code%Dim%Dég%1%(DD)

Code%Dim%Dég%2%(DD)

Code%Dim%Dég%m%(DD)

Mesure%1

Mesure%2

Mesure%n

Clef%étrangères%vers%les%dimensions

Dimensions%dégénérées

Mesures%

5

Caractéris-ques$d'une$''table''$des$faits$

! Une!''table''!de!faits!con-ent!les!valeurs!numériques!de!ce!qu'on!désire!mesurer

! Une!''table''!de!faits!con-ent!les!clés!associées!aux!dimensions.!Il!s'agit!de!!clés!étrangères!vers!les!dimensions

! En!général!une!''table''!de!faits!con-ent!un!pe-t!nombre!de!colonnes!

! Une!''table''!de!faits!con-ent!plus!d'enregistrements!qu'une!''table''!de!dimension

! !Les!informa-ons!dans!une!''table''!de!faits!sont!caractérisées!: " !!Elles!sont!numériques!et!sont!u-lisées!pour!faire!des!SUM,-AVG... " !!Les!données!doivent!être!addi-ves!ou!semiGaddi-ves!

Les!mesures! (Mes1,-Mes2-…-Mesn)!doivent! référer!et!avoir!un! lien!direct!avec! les!clés!des!dimensions! (Date-Cal,- Id-Dim1,--Id-Dim2-,-...,-Id-Dimn-)!dans!la!même!table.

Les$Faits$(suite)

6

Exemple$d'une$''table''$de$faits$

Les$Faits$(suite)

Mesures$

Clef$ (clés étrangères vers les dimensions)

VENTES$Id_Cde!Id_Client!

Id_Vendeur!Id_Produit!Id_Date!Id_Ville!5!Quantité!Prix5Total!5!

7

Dimension

La$défini-on$

# Une!dimension!est!une! ''table''!qui!représente!un!axe$d'analyse$selon! lequel!on!veut!étudier! des! données! observables! (les$ faits)! qui,! soumises! à! une! analyse!mul-dimensionnelle,! donnent! aux! u-lisateurs! des! renseignements! nécessaires! à! la! prise!de!décision.!

!

# On!appelle!donc!''dimension''!un!axe!d'analyse.!Il!peut!s'agir!des!Clients!ou!des!Produits!d'une! entreprise,! d'une! Période! de! temps! comme! un! exercice! financier,! des! ac-vités!menées!au!sein!d'une!société,!etc.!

8

Structure de base d'une dimension

Une dimension devrait avoir la structure suivante :

Dimension$$(suite)

Attribut1

(((.(.(.

Attributn

Date(effective

Date(de(retrait

Indicateur(effectif

Clé(primaire((PK)

Clé(naturelle((NK)

Clé(de(substitution((Surrogate(key)

Clé(d'affaire((natural(key(ou(buisness(key)((peut_être(composée(de(plusieurs(

attributs

Clés(spéciales(pour(la(gestion(de(l'historique(de(la(dimension

Attributs(de(la(dimension

9

Caractéris-ques$d'une$dimension$

#  !Une!"table''!de!dimension!con-ent!le!détail!sur!les!faits

# Une!''table''!de!dimension!con-ent!les!informa-ons!descrip-ves!des!valeurs!numériques!de!la!table!des!faits

#  Vu!que!les!données!dans!la!''table''!de!dimension!sont!normalisées,!elle!con-ent!un!plus!grand!nombre!de!colonnes

#  !Une!''table''!de!dimension!con-ent!en!général!beaucoup!moins!d'enregistrements!qu'une!''table''!des!faits

#  Les!aSributs!d'une!''table''!de!dimension!sont!souvent!u-lisés!comme!«Tête-de-lignes»!et!«Tête-de-colonne»!dans!un!rapport!ou!résultat!de!requête.!

Dimension$$(suite)

10

Dimension$D$composantes

Composante$1!:!surrogate-key--ou!clé!de!subs-tu-on!

Composantes$2$:!aSributs!

Composantes$3$:!clés!spéciales!

11

Dimension$–$composantes$(suite)

$Exemple!

Composante$1$:$surrogate$key$$ou$clé$de$subs-tu-on$

!PRODUITCode_ProduitDésignationDescription33Prix3unitaire….

Dim.%PRODUIT

Id#Produit

Nom#Produit

Description#Produit

Sous3catégorie

Famille#Produit

Description#Catégorie

Prix#unitaire

Clef$naturelle$

(clé artificielle)$

Surrogate$Clef$ (clé de substitution )

- Table d'une BD de production

- Table d'une BD multidimensionnelle

12

Dimension$–$composantes$(suite)

$La$Défini-on$

!  Une!clé!de!subs-tu-on!(Surrogate-key)!est!une!clé!non!significa-ve!u-lisée!afin!de!subs-tuer!la!clé!naturelle!(Business-Key)!qui!provient!des!systèmes!opéra-onnels.!!

!  !La!clé!naturelle!est,!en!général,!composée!de!plusieurs!colonnes.

!  Dans!un!système!opéra-onnel,!on!u-lise!une!clé!ar-ficielle!afin!d'iden-fier!d'une!façon!unique!un!élément!de!l'en-té!:!(client_id!pour!l'en-té!Client,!emp_id!pour!l'en-té!Employé).!!

!  La!clé!de!subs-tu-on!ne!doit!pas!être!confondue!avec!la!clé!ar-ficielle!aSribuée!par!les!systèmes!opéra-onnels.!

!  La!clé!de!subs-tu-on!est!alors!u-lisée!dans!un!entrepôt!de!données!pour!remplacer!et!compléter!la!clé!ar-ficielle!du!système!opéra-onnel!afin!de!rendre!un!élément!unique!dans!la!dimension.!

Composante$1$:$surrogate$key$$ou$clé$de$subs-tu-on$

13

Dimension$–$composantes$(suite)

Les$Fonc-onnalités$$

# Remplacer$ la$ clé$ ar-ficielle$ ou$ naturelle$ :$ Effec-vement! une! clé! de! subs-tu-on!remplace!la!clé!ar-ficielle!en!terme!d'u-lisa-on,!ce!n'est!plus!la!clé!naturelle!qui!sera!u-lisée!pour!faire!les!jointures!avec!les!tables!de!faits!et!les!autres!tables!de!dimension.!

# Compléter$l'informa-on$:$La!clé!de!subs-tu-on!n'a!aucun!sens!en!terme!d'affaire,!elle!est!u-lisée!dans!l'ED!seulement!!!!

!La! clé! ar-ficielle! ou! naturelle! dans! la! dimension! est! toujours! nécessaire! pour! pouvoir! faire! la!correspondance!entre!l'élément!de!dimension!(un!client!par!exemple)!dans!l'ED!et!l'élément!de!la!table!des!clients!dans!le!système!opéra-onnel.

Composante$1$:$surrogate$key$$ou$clé$de$subs-tu-on$

14

Dimension$–$composantes$(suite)

Les$avantages$$$$

#  Performance! :! Accélère! l'accès! aux! données! du! moment! ou! l'on! va! u-liser! un! index!numérique!vu!que!le!type!de!données!de!la!clé!de!subs-tu-on!est!numérique.

#  Indépendance$du$système$source! :!On!ne!peut!garan-r!que! la!clé!d'affaire!ne!change!pas!dans!les!systèmes!sources.

#  Historique$ des$ changements$ et$ granularité$ infinie! :! Si! l'on! désire! garder! l'historique! des!changements!de!la!dimension!selon!certains!critères,!on!doit!gérer!la!clé!de!subs-tu-on.!On!se!retrouve! facilement! avec! plusieurs! enregistrements! de! la! même! clé! d'affaire! dans! la!dimension.

Composante$1$:$surrogate$key$$ou$clé$de$subs-tu-on$

15

Dimension$–$composantes$(suite)

Composantes$2$$$:$$$a;ributs$$En!plus!de!la!clé!de!subs-tu-on!ou!de!la!clé!naturelle,!d'autres!aSributs!sont!ajoutés!à!la!dimension.!Ces!aSributs!sont!descrip-fs!et!représente!l'informa-on!u-le!sur!la!dimension!(Le-salaire-d'un-employé,-l'adresse-d'un-client...)!

Dim.%PRODUIT

Id#Produit

Nom#Produit

Description#Produit

Sous3catégorie

Famille#Produit

Description#Catégorie

Prix#unitaire

Surrogate$Clef$ (clé de substitution )

A;ributs$$(descripteurs )

16

Dimension$–$composantes$(suite)

!Composantes$3$$$:$$$clés$spéciales$$Date$effec-ve!:!Date!à!la!quelle!l'enregistrement!à!été!créé,!de!préférence!dans!le!système!d'enregistrements!

(System!of!records).

Date$retrait!!:!Date!à!laquelle!l'enregistrement!a!été!re-ré!du!système!d'enregistrements. Indicateur$effec-f!:!En!général!est!'O'!si!l'enregistrement!est!toujours!ac-f!(Date!retrait!est!nulle),!'N'!sinon.!

Dim.%PRODUITId#ProduitNom#ProduitDescription#ProduitSous3catégorieFamille#ProduitDescription#CatégoriePrix#unitairedate#effectiveDate#retraitIndicateur#effectif

Surrogate$Clef$ (clé de substitution )

A;ributs$$(descripteurs )

Clés$spéciales

17

Différents$types$de$dimensions$

Dimension$dégénérée$(Degenerate/dimension)$$La!dimension$dégénérée$est!une!clé!de!dimension!dans!la!''table''!de!faits!qui!est!en!général!sans!aSribut.!!

Exemple!:!!!N°-de-bon-de-Cde,!!!!!N°-d'interrupPon-de-service!...!!!!!!

Vu! qu'il! s'agit! d'une! seule! clé! de! dimension,! nous! évitons! alors! de! créer! une! ''table''! de!dimension,!ce!qui!fait!que!ceSe!''table''!de!dimension!a!dégénéré!dans!la!''table''!des!faits!:!c'est!pour!ceSe!raison!que!ceSe!clé!est!appelée!!«dimension!dégénérée»!

18

Différents$types$de$dimensions$

Dimension$dégénérée$(Degenerate/dimension)$$La! dimension$ dégénérée$ est! une! clé! de! dimension! dans! la! ''table''! de! faits! qui! est! en!général!sans!aSribut.!!

Exemple!:!No-de-bon-de-Cde,!No-d'interrupPon-de-service!...!

19

Différents$types$de$dimensions$(suite)

Junk$dimension$

La!dimension!de!genre!«!Junk/dimension/»!est!une!dimension!qui!con-ent!toutes!sorte!de!flags,!statuts,!codes!qui!ne!font!par-e!d'aucune!dimension!régulière.!!!Dans! le!domaine!de! la!distribu-on!de! l'énergie,!une! interrup-on!de!service!peut!être!de!type!«Basse-tension»!ou!«Moyenne-tension».!!!Ce!genre!de!code!est!donc!stocké!dans!une!table!spéciale!appelée!!«Junk-dimension».

20

Différents$types$de$dimensions$(suite)

Dimension$à$évolu-on$lente$(SCD/:/Slowly/Changing/Dimension)$

Une!dimension!peut!subir!des!changements!de!descrip-on!des!membres!!

•!Un!client!peut!changer!d'adresse,!se!marier,!...!•!Un!produit!peut!changer!de!noms,!de!formula-ons!;!!!!!!!exemple!:!!«Tree's»!en!«M&M»!;!!«Raider»!en!«Twix»!;!«Yaourt-à-la-vanille»!en!«Yaourt-saveur-Vanille»!

!CeSe!situa-on!peutGêtre!gérée!en!choisissant!entre!3!solu-ons!:!!!!•!Écrasement!de!l'ancienne!valeur!!•!Versionnement!

•!Valeur!d'origine!/!valeur!courante!-

Remarque-:-Dans!certain!cas!la!transi-on!n'est!pas!immédiate!:!il!reste!pendant!un!certain!temps!des!anciens!produits!en!rayon.!Il!est!alors!conseillé!de!les!traiter!comme!deux!membres!différents.

21

Différents$types$de$dimensions$(suite)

Dimension$à$évolu-on$rapide$(RCD/:/Rapid/Changing/Dimension)$

Une!dimension$à$changement$rapide!est!une!dimension!qui!subit!des!changements!très!fréquents!des!aSributs!dont!on!veut!préserver!l'historique.!

!  Solution: isoler les attributs qui changent rapidement !

Exemple!:!Si!l'on!veut!préserver!l'historique!des!changements!d'adresse!dans!la!dimension!«Clients»!dans!un!pays!où!70%!de!la!popula-on!déménage!une!fois!par!année!(le!1ier!juillet!par!exemple!au!Canada),!!

!!La!dimension!«Clients»!devient!dans!ce!cas!une!dimension!à!évolu-on!rapide!(RCD)!

22

Différents$types$de$dimensions$(suite)

Dimension$à$évolu-on$rapide$(RCD/:/Rapid/Changing/Dimension)$

23

Différents$types$de$dimensions$(suite)

Dimension$causale$(Causal/dimension)$!

Il!s'agit!d'une!dimension!qui!provoque!des!faits.!!

• Exemple!:!la!dimension!«Promo=on»!peut!en!général!provoquer!des!ventes!

!

•  ! Autre! exemple! dans! le! domaine! de! la! distribu-on! de! l'énergie! la! dimension! ! ! ! «CondiPon-climaPque»!peut!provoquer!des!«InterrupPons-de-service».!La!dimension!«CondiPon-climaPque»!est!donc!une$dimension$causale.

24

Différents$types$de$dimensions$(suite)

Dimension$conforme$(Conformed/dimension)$!!Une!dimension$conforme!ou!partagée!est!une!dimension!u-lisée!par!les!faits!de!plusieurs!datamarts.!!!!

Exemple!:!la!dimension!«Produit»!est!u-lisée!par!différents!datamarts!«Finance»,!«Marke-ng!»!…!!

25

Différents$types$de$dimensions$(suite)

Mini$dimension$

$

Dans!tout!entrepôt!de!données,!il!existe!au!moins!une!grande!dimension,!que!ce!soit!en!terme!d'enregistrements!ou!d'aSributs.!!-

Exemple!!:!!La!dimension!«Clients»!peut!contenir!des!millions!d'enregistrements.!Le!plus!souvent,!on!gère!l'évolu-on!lente!(Voir!même!l'évolu-on!rapide)!sur!ce!genre!de!dimension!ce!qui!augmente!encore!plus!leurs!tailles.!!

!Un!moyen!de!réduire!la!taille!de!ce!genre!de!dimension!est!soit!de!recourir!à!la!technique!de!«flocon!de!neige»!si!la!dimension!est!hiérarchique,!!soit!de!créer!une!mini$dimension,!qui!con-ent!tous!les!aSributs!sur!lesquels!on!gère!l'évolu-on!lente.!!

26

Différents$types$de$dimensions$(suite)

Mini$dimension$

$

Exemple!!:!La!dimension!«Clients»!d'un!système!de!distribu-on!d'énergie!con-ent!plusieurs!millions!d'enregistrements,!dont!les!aSributs!sont!:!

$ !!ID!client!(Iden-fiant!du!client,!surrogate!key) $ !Code!du!client!(La!clé!d'affaire!du!client,!provenant!du!système!source) $ !Nom!du!client. $ !Adresse!du!client. $ !Transformateur!associé.!(transformateur!électrique!qui!alimente!le!client) $ !Code!incidence!(code!d'incidence!du!client!:!Ma!pour!Majeur,!Mo!pour!Moyen,!Mi!pour!mineur,!Ge!pour!Grande!Entrepris) $ !!…!

27

Différents$types$de$dimensions$(suite)

Mini$dimension$

Supposons!que!pour!des!besoins!d'affaires,!les!u-lisateurs!décident!de!préserver!l'historique!des!changements!des!aSributs!suivants!:!«Transformateur-associé»!et!«Code-d'incidence».!!Nous!créons!donc!une!mini!dimension!qui!con-ent!les!colonnes!suivantes!:

$ !!ID!SCD!Client!$ !!Transformateur!associé!$ !!Code!d'incidence!

Et!dans!la!dimension!«Clients»,!nous!ajoutons!une!nouvelle!clé!de!dimension!!!!!«ID-SCD-client»!pour!faire!le!lien!entre!la!dimension!«Clients»!et!la!miniGdimension!!«SCD-Client»!-

Remarque!:!la!dimension!«Clients»!con-nue!de!contenir!tous!les!aSributs!même!ceux!sur!lesquels!nous!gérons!l'évolu-on!lente.

28

La$modélisa-on$en$3FN$Vs$La$Modélisa-on$mul-dimensionnelle$:

!

La$Modélisa-on$Mul-dimensionnelle

Dimension(TEMPSDimension(MAGASIN ID#TempsID#Magasin DescriptionDescription FAITS AnnéeVille ID#Magasin …Provincr ID#Prrpoduit

ID#Temps#(Date#Cde)ID#ClientID#Client#Demog Dimension(Démogrphie(Client

ID#Clien#DemogVentes Id#ClientProfits Date

Dimension(PRODUIT Attributs#clientID#PrrpoduitNomProduitTypeProduit Dimension(CLIENTDescProduit ID#ClientID#Categorie NomDescCategorie …

29

"  Le!modèle!mul-dimensionnel!n'adhère!pas!la!règle!de!la!3FN,!en!apla-ssant!tous!les!niveaux!de!la!dimension.!!

Dans!notre!exemple,!la!''table''!«Produit»!est!apla-e!et!les!niveaux!TypeProduit,!IdCategorie!sont!avec!tous!les!aSributs!dans!la!même!''table''!de!dimension!«Produit»!.!

"  Il!viole!la!règle!de!la!le!2FN!dans!la!table!des!faits.!!La!colonne!Id-Temps-(Date-Cde)-fait!par-e!de!la!commande!et!est!reprise!dans!la!table!des!faits.!

"  Il!ne!suit!pas!la!règle!de!BCFN!(Boyce[Codd-normal-form)!en!permeSant!la!redondance!des!données.!!Tout!comme!dans!la!table!«Client»!et!la!mini!dimension!«Démographie-client».

La$Modélisa-on$Mul-dimensionnelle

30

"  Il!existe!3!formes!de!modèles!mul-dimensionnels!:!

1.  Le!modèle!en!étoile!(Star-schema)!

2.  Le!modèle!en!flocon!de!neige!(Snowflake-schema)!

3.  Le!modèle!en!constella-on!(Fac`lake-schema)!

La$Modélisa-on$Mul-dimensionnelle

Le$modèle$en$étoile$

31

COMMANDE N° Cde Date Cde

PRODUIT Code produit Nom Produit Description Produit Catégorie Description catégorie Prix unitaire CLIENT

N° Client Nom Client Adresse Client Ville

DATE Clef date Date Mois Année

VENDEUR Code vendeur Nom Vendeur Ville Vendeur Quota

VILLE Nom Ville Région Pays

TABLE DE FAITS

Quantité

Prix total

N° Cde

Code vendeur N° Client

Clef date Code produit

Nom Ville

Le$modèle$en$étoile$

%  Une!''table''$de$faits$:!iden-fiants!des!tables!de!dimension!;!une!ou!plusieurs!mesures!!

%  Plusieurs!tables$de$dimension!:!descripteurs!des!dimensions!

!!!Une!granularité!définie!par!les!iden-fiants!dans!la!table!des!faits.!!

Avantages/:////♦ !!Facilité!de!naviga-on!♦ !!Performances!:!nombre!de!jointures!limité!;!ges-on!des!données!creuses.!♦ !!Ges-on!des!agrégats!♦ !!Fiabilité!des!résultats!!

Inconvénients/:/♦ !!Toutes!les!dimensions!ne!concernent!pas!les!mesures!♦ !!Redondances!dans!les!dimensions!♦ !!Alimenta-on!complexe.!

32!

Propriétés$des$mesures$

33!

Addi-vité!:!somme sur toutes les dimensions !  Quantités vendues, chiffre d’affaire

! Peut être le résultat d’un calcul

! Bénéfice = montant vente – coût

SemiDaddi-vité!:!somme sur certaines dimensions

! Solde d’un compte bancaire

! Pas de sens d’additionner les dates car cela représente des instantanés d’un niveau

! Σ sur les comptes: on connaît ce que nous possédons en banque

Non$addi-f$: fait non additionnable quelque soit la dimension

! Prix unitaire: l’addition sur n’importe quelle dimension donne un nombre dépourvu de sens

$Dans$la$grande$distribu-on$:!Quelques!''tables''!de!faits!:!détaillées!et!volumineuses!''Tables''!de!dimensions!:!

Classiques!:!Produit,--Fournisseur,--Temps,--Etablissement-(structure!géographique,!fonc-onnelle)...!Stratégiques!:!Client,-PromoPons,…!

-

Remarque-!:!Obtenir!le!plus!d'enregistrements!possibles.!!

$Dans$le$secteur$des$banques$:!''Tables''!des!faits!:!nombreuses,!dédiées!à!chaque!produit,!peu!détaillées!et!peu!volumineuses.!''Tables''!de!dimensions!:!!

Classiques!:!Produit,--Temps,--Etablissement-(structure!géographique,!fonc-onnelle)...!Stratégiques!:!Client,...!

!Remarque-:-Obtenir!le!plus!de!données!(champs)!possibles.!

Exemples$de$modèles$mul-dimensionnels$$$

34!

Le modèle de l' ED doit être simple à comprendre. On peut augmenter sa lisibilité en regroupant certaines dimensions. On définit ainsi des hiérarchies. Celles-ci peuvent être géographiques ou organisationnelles.

Le modèle en flocons de neige

Exemple : Commune, Département, Région, Pays, Continent

Client Commune Département Region Pays ContinentPepone Lyon 1° Rhône Rhône-Alpes France EuropeTestut Lyon 2° Rhône Rhône-Alpes France EuropeSoinin Lyon 3° Rhône Rhône-Alpes France EuropeVepont Paris 1° Paris Ile-de-France France EuropeMartin Paris 2° Paris Ile-de-France France EuropeElvert Versailles Yvelines Ile-de-France France Europe

35

PRODUITCOMMANDE Code produit

N° Cde Nom ProduitDate Cde Description Produit

TABLE DE FAITS CatégorieN° Cde Description catégorie

CLIENT N° Client Prix unitaireN° Client Code vendeurNom Client Code produit DATE Adresse Client Clef date Clef dateVille Nom Ville Date

Quantité MoisVENDEUR Prix total Année

Code vendeurNom Vendeur VILLEVille Vendeur Nom VilleQuota Région

Pays

PRODUIT CATEGORIECOMMANDE Code produit Catégorie

N° Cde Nom Produit Desc. CatDate Cde Desc. Produit

TABLE DE FAITS CatégorieN° Cde Prix unitaire

CLIENT N° ClientN° Client Code vendeur ANNEENom Client Code produit DATE MOIS AnnéeAdresse Client Clef date Clef date MoisVille Nom Ville Date Année

Quantité MoisVENDEUR Prix total

Code vendeurNom Vendeur VILLE REGION PAYSVille Vendeur Nom Ville Région PaysQuota Région Pays

Pays

Le modèle en flocons de neige

36

Le modèle en flocons de neige

37

Id#Marque

Id#Famille !MARQUEId#Produit

Nom#ProduitId#Cde Description#Produit Famille

! ANNEEDate#Cde Sous9catégorieId#Année Famille#Produit

Description#CatégorieSEMESTRE Prix#unitaire

###Id#SemestreCOMMANDE SOUS4CATEGORIE

SEMAINE MOIS PRODUITId#Semaine Id#Mois VENTES CATEGORIE

DATE Id#Cde Id#Sous9catégorieId#Client

!!!JOUR Id#Vendeur Id#Sous9catégorieId#Produit

##Id#Mois Id#DateId#Client CLIENT Id#Ville

Nom#Client VILLE DEPARTEMENTAdresse#Client Quantité MAGASIN

Ville#Client Prix+total ###Id#DépartementVENDEUR Id#Ville##

Id#Magasin ZONE!GEO.Id#Vendeur## Ville#Mag. Id#Zone#géo.

Ville#Vendeur#### Département#Mag.Quota# Zone#géographique

Région#Mag.Pays#Mag.

Le$modèle$en$flocons$de$neige$

38

Schéma en arbre d'attributs

! ANNEECOMMANDE

Famille !MARQUESEMESTRE VENTES

Id#CdeId#Client PRODUIT

SEMAINE MOIS DATE Id#Vendeur SOUS7CATEGORIE CATEGORIEId#ProduitId#Date

CLIENT Id#Ville VILLE DEPARTEMENT REGION PAYSJOUR MAGASIN

QuantitéPrix+total

VENDEUR ZONE!GEO.

Lorsque les tables sont trop volumineuses Avantages :

•  réduction du volume • permettre des analyse par pallier (drill down) sur la dimension hiérarchisée

Inconvénients :

•  navigation difficile  •  nombreuses jointures

Modèle en flocons de neige = Modèle en étoile + normalisation des dimension

Le$modèle$en$flocons$de$neige$

39

Les$hiérarchies$

Les différents types d'hiérarchies

40

"  Les hiérarchies strictes et simples

Les$hiérarchies$

Les différents types d'hiérarchies

41

"  Les hiérarchies multiples alternatives

Les$hiérarchies$

Les différents types d'hiérarchies

42

"  Les hiérarchies multiples parallèles

Les hiérarchies

Les différents types d'hiérarchies

43

"  Les hiérarchies multiples parallèles

Les$hiérarchies$

Les différents types d'hiérarchies

44

"  Les hiérarchies multiples parallèles

Propaga-on$virus$du$Nil$

occidental!

Ville$

Etat$

Pays$

Province$

Territoire$

&  Les diagramme UML de SOLAP

$Représenta-on$$des$données$mul-dimensionnelles$

45

Dim.%ANNEEId#Année Dim.%PAYS

Id#Pays

Dim.%SEMESTREId#Semestre

Dim.%MARQUE Dim.%CATEGORIE Dim.%REGION Dim.%ZONE%GEO.Id#Marque Id#Région Id#Région Id#Zone#géo.

Dim.%MOISId#Mois

Dim.%Famille Dim.%SOUS:CATEGORIE Dim.%DEPARTEMENT Dim.%VILLEDim.%JOUR Id#Famille Id#Sous;catégorie Id#Département Id#Ville

Id#JourVENTES

Id#CdeId#Client Dim.%PRODUIT

Dim%DATE Id#Vendeur Id#Produit Dim.%MAGASINId#Date Id#Produit Nom#Produit Id#Magasin Dim.%CLIENTJour Id#Date Description#Produit Ville#Mag. Id#ClientSemaine Id#Ville Sous;catégorie Département#Mag. Nom#Client Dim.%VENDEUR Dim.%COMMANDEMois Famille#Produit Zone#géographique Adresse#Client Id#Vendeur Id#CdeSemestre Quantité Description#Catégorie Région#Mag. Ville#Client Ville#Vendeur Date#CdeAnnée Prix+total Prix#unitaire Pays#Mag. Quota

Le!modèle$en$constella-on$(FactDflaked)$

"  La modélisation en constellation consiste à fusionner plusieurs modèles en étoile qui peuvent utiliser des dimensions communes.

" Un modèle en constellation comprend donc plusieurs tables de faits et des tables de dimensions communes ou non à ces tables de faits.

46

Dim.%ANNEEId#Année Dim.%PRODUCTION Dim.%USINE

Id#Production Id#UsineId#Produit

Dim.%SEMESTRE Id#DateId#Semestre Dim.%COMMANDE Id#Usine

Dim.%SEMAINE Id#Cde #Id#Semaine Date#Cde Qté$produite

Dim.%MOIS Dim.%PRODUITId#Mois Dim%DATE Id#Produit

Id#Date Nom#Produit Dim.%Famille Dim.%MARQUEJour Description#Produit Id#Famille Id#Marque

Dim.%JOUR Semaine VENTES Sous=catégorieId#Jour Mois Id#Cde Famille#Produit

Semestre Id#Client Description#Catégorie Dim.%SOUS9CATEGORIE Dim.%CATEGORIEAnnée Id#Vendeur Prix#unitaire Id#Sous=catégorie Id#Région

Id#ProduitId#Date

Dim.%CLIENT Id#Ville Dim.%REGION Dim.%PAYSId#Client Id#Région Id#PaysNom#Client Quantité Dim.%DEPARTEMENTAdresse#Client Prix$total Id#DépartementVille#Client

Dim.%MAGASINId#MagasinVille#Mag. Dim.%VILLE Dim.%ZONE%GEO.

Dim.%VENDEUR Département#Mag. Id#Ville Id#Zone#géo.Id#Vendeur Zone#géographiqueVille#Vendeur Région#Mag.Quota Pays#Mag.

47

Le!modèle$en$constella-on$(FactDflaked)$

Calculer ou estimer le nombre d'enregistrements Prendre en compte :

#  La ''table'' de faits #  Les dimensions significatives #  Les agrégats #  Les index #  Saisonnalité des ventes #  Croissance du CA, des encours, du nombre de points de ventes

Es-mer$le$volume$du$DW$$

48

Grandes distribution : CA annuel : 80 000 M$ Prix moyen d'un article d'un ticket : 5$ Nbre d'articles vendus pour un an : 80 * 109 / 5 = 16 * 109 Volume du DW :

16*109 *3 ans * 24 octets = 1,54 To (1,54*1012 = 1 540 Go )

Téléphonie : Nbre d'appels quotidiens : 100 millions Historique : 3 ans * 365 jours= 1 095 jours Volume du DW :

100 millions * 1 095 jours * 24 octets = 3,94 To

Cartes de crédit : Nbre de clients : 50 millions Nbre moyen mensuel de transactions : 30 Volume :

50 millions * 26 mois * 30 transactions * 24 octets = 1,73 To

Exemples 

49

Les données sont perçues à travers plusieurs dimensions. Elles sont qualifiées de multidimensionnelles, indépendamment de leur support (tables relationnelles ou tableaux multidimensionnels)

Produit Region VentesClous Est 50Clous Ouest 60Clous Centre 100Vis Est 40Vis Ouest 70Vis Centre 80Boulons Est 90Boulons Ouest 120Boulons Centre 140Nettoyeurs Est 20Nettoyeurs Ouest 10Nettoyeurs Centre 30

Est Ouest Centre

Clous, 50 60 100Vis 40 70 80Boulons 90 120 140N ettoyeurs 20 10 30

Représentation des données dans une table relationnelle

Représentation des données dans un tableau multidimensionnel

Modélisa-on$logique$ou$Représenta-on$des$données$

50

�Quelle est le total des ventes dans la région Est ?� On peut calculer divers totaux.

#  Tables relationnelles : on peut traiter quelques centaines de tuples par seconde.

#  Tableau multidimensionnel : on peut rajouter en lignes et en colonnes plus de 10000 valeurs par seconde.

Pour accélérer les temps de réponses, il est préférable de pré-calculer des sous totaux.

51

Les$requêtes$décisionnelles$

Produit Region Ventes

Clous Est 50Clous Ouest 60Clous Centre 100Clous Total 210

Vis Est 40Vis Ouest 70Vis Centre 80Vis Total 190

Boulons Est 90Boulons Ouest 120Boulons Centre 140Boulons Total 350

Nettoyeurs Est 20Nettoyeurs Ouest 10Nettoyeurs Centre 30Nettoyeurs Total 60

Total Est 200Total Ouest 260Total Centre 350

Total Total 810

Est Ouest Centre Total

Clous 50 60 100 210Vis 40 70 80 190Boulons 90 120 140 350Nettoyeurs 20 10 30 60Total 200 260 350 810

Pour le calcul de ces totaux : 28 accès en lecture et 8 accès en écriture.

  Un SGBDR lit 200 enregist/s et en écrit environ 20/s.

OLAP consolide entre 20 000 et 30 000 cellules/s

52

Les$requêtes$décisionnelles$

La valeur ALL remplace une colonne ou une valeur d'agrégats. Magasin Date Rayon CA Ventes

Mag1 1/2/96 010 3500 Mag1 6/2/96 010 2500 Mag1 10/2/96 010 2900 Mag1 ALL 010 8900 Mag2 … … …

S'il y a N attributs concourant à la construction du cube, il y aura :

Dans la tables VENTES si on a 2*3*3 = 18 enregist. dans le cube on aura 3*4*4* = 48 enregist.

Soit C1, C2, … ,CN les cardianlités des N attributs, le cube aura :

∏(Ci +1) enregistrements

2N-1 agrégations

53

Les$requêtes$décisionnelles$

L'ensemble des données est stocké dans une BDR. Les données sont sous forme d'enregistrements (tuples).

VENTES (Magasin, Rayon, Date, CA Ventes, Nb Client)

Select Magasin, Date , Sum(CA Ventes) From VENTES Group By Magasin, Date

Opérateurs d'agrégation : cube , rollup.

' J.Gray, A. Bosworth, A. Leyman, H. Pirahesh, “Data Cube : A relationnal Aggregation Operator Generalizing Group-By, Cross-Tab, and Sub-Total”, in Data Mining and Knowledge Discovery Journal, 1(1), 1997]

L'approche relationnelle (ROLAP) (MicroStrategy MS ; Informix's Metacube MC , Information Advantage IA)

Les$différentes$approches$d'OLAP$

54

Select ALL, ALL, ALL, Sum(CA Ventes) From VENTES UNION Select Magasin, ALL, ALL, Sum(CA Ventes) From VENTES Group-By Magasin ; UNION Select Magasin, Date, ALL, Sum(CA Ventes) From VENTES Group-By Magasin, Date ; UNION Select Magasin, Date, Rayon, Sum(CA Ventes) From VENTES Group-By Magasin, Date, Rayon ;

Select Magasin, date, Rayon, Sum(CA Ventes) From VENTES Group-By Cube Magasin, Date, Rayon ;

L'opérateur cube est une généralisation N-dimensionnelle de fonctions d'agrégations simples . C'est un opérateur relationnel.

L'union de plusieurs group-by donne naissance à un cube :

55

Les$requêtes$décisionnelles$

Il s'agit de stocker les données dans des tableaux multidimensionnels.

Ces tableaux peuvent être éparses.

On y stocke dans les cellules les mesures (valeurs à observer), les données représentant

les dimensions sont les coordonnées de ces valeurs : f = (d1, d2, …, dn, m1, m2, …, mp)

[Zhao Yihong, Deshpande Prasad M., Naughton Jeffrey F., «An Array-Based Algorithm for Simultaneous Multidimensional Aggregates», in SIGMOD Record n° 26, Vol 2, 1997.]

L'approche multidimensionnelle (MOLAP) Arbor Software : hyperion (Codd & co…), Express Oracle , LightShip (de Pilot)

56

Les$différentes$approches$d'OLAP$

#  Plus on a de dimensions plus on a de cellules. Seulement une partie des produits peut être vendue ( des cellules sans

valeur : données éparses.

BD éparse

#  Une BD est considérée comme éparse si elle a moins de 40% de ses cellules � peuplées �.

#  Techniques de compression des données

Exemple : On dispose de 100 000 données (eq. tuples) 4 dimensions ayant une cardinalité de 30 modalités chacune:

30 * 30 * 30 * 30 = 810 000 cellules (dont 710 000 vides : 12,3% seulement sont pleines)

57

Les$différentes$approches$d'OLAP$

L'approche hybride (HOLAP)

50 000 Clients

500 Villes

5 Régions

1 Pays

BDR

BDM

Approche relationnelle : 30% du temps est consacré aux I/O

Approche multidimensionnelle : 20% (70% calculs et 10% décompression)

La 3° voie préconisée consiste à utiliser les tables comme structure permanente de stockage des données et les tableaux comme structure des requêtes.

La démarche consisterait en 3 étapes :

1. Charger les données d'une table vers un tableau.

2. Calculer le cube de ce tableau selon les méthodes initialement présentées.

3. Stocker les résultats (données agrégées) dans un table.

58

Les$différentes$approches$d'OLAP$

&  Simples  �magasins de données� (Data Marts), on y stockera des données portant sur une seule des activités de l'entreprise

&  Ceux sont en quelque sorte des vues métier

&  Exemple : Data Mart Comptabilité, Data Mart RH,.....

&  Ces mini ED peuvent alors être considérés comme des espaces d'analyse, du fait que les données sont bien moins nombreuses et surtout qu'elles sont thématiques et modélisées en multidimensionnel

&  Ils peuvent également servir de bases de construction à des cubes de données

"  Les magasins de données (data marts)

59

Les$différentes$structures$mul-dimensionnelles$

Entrepôts,$Magasins$et$Cubes$de$données$

Data Mining

Analyses statistiques

OLAP Reporting

Entrepôt$$

de$$

données$

Magasins de données

MD

MD

MD

MD

MD

MD

Cube

Cube

Cube

Cubes de données

60