Discussion :

[Melvine]

salut,

J'aurai aimé savoir si quelqu'un pouvait m'expliquer dans quel cas il utilise des table d'agregat et quel est leurs rôle ?

Merci

[Médiat]

J'aurai aimé savoir si quelqu'un pouvait m'expliquer dans quel cas il utilise des table d'agregat et quel est leurs rôle ?

Dans la quasi totalité des datawarehouse (entrepôts de données).
On utilise des tables d'agrégats parce que la granularité de l'information à stocker est moins fine que l'information d'origine et/ou à de fins de performances.

[Melvine]

en faite une table d'agregat c'est si par exemple je dispose d'une table localisation avec à l'interieur ville region pays
une table d'agregat c'est le faite de decomposer cette table et d 'en faire plusieurs et de le relié entre elle
je transforme ma table localisation en 3 table relié entre elle :
ville , region, pays

[Médiat]

en faite une table d'agregat c'est si par exemple je dispose d'une table localisation avec à l'interieur ville region pays
une table d'agregat c'est le faite de decomposer cette table et d 'en faire plusieurs et de le relié entre elle
je transforme ma table localisation en 3 table relié entre elle :
ville , region, pays

Ca c'est plutôt une "dimension" (la localisation)associée à une "hiérarchie" (à 3 niveaux). Pour avoir un agrégat, il faut avoir une mesure (un indicateur), en général dans une table de faits (vocabulaire du décisionnel) et pour laquelle on calcule des agrégats (par ville, par région et par pays au lieu des données individuelles).

[Melvine]

en faite comme la table de fait contient des mesures, alors c 'est aussi une table d'agregat

[Médiat]

en faite comme la table de fait contient des mesures, alors c 'est aussi une table d'agregat

Pas si c'est la granularité la plus fine.

[alpachico]

Une table d'agregat sert (je pense) avant tout à optimiser les temps de réponse d'un entrepôt ou d'un datamart.

Exemple : on a un DWH avec une table de fait vente avec les dimension temps, produit et région et ayant la granularité la plus fine, donc un produit, en un jour précis dans une région pour une vente. ( il y aura autant de ligne dans la table de fait qu'il y a de produit dans la même vente).
Si un utilisateur a besoin d'un rapport ayant toutes les ventes par mois , par région tout produit confondus, la requête qui sera faite sera très longue à sortir. donc on créera une table d'agregat qui donnera le CA par region et par mois grace au fonction SUM , et GROUP BY (region, mois).
et quand l'utilisateur lancera sa requête , il n'y aura qu'à lire cette table au lieu de faire des operation d'agregation sur la table de fait.
En faite c'est une sorte de table de fait mais qui résume les table de fait les plus fine.

[rad_hass]

salut
aller voir mon topic svp (c un peu le sujet):

http://www.developpez.net/forums/viewtopic.php?t=442397

Corriger moi si je me trompe ;

Une fonction d'agregat calculent une seul valeur résultant d'un ensemble de valeur en entrée (avg, count, max, min ...).
Et donc une vue d'agregat (probablement de même pour une table) contient des agragats dans le colonnes de la vue (table).
Je sais que dans les entreports de données on les utilise pour la réécriture de requêtes (et bien evidemment pour optimiser).

[Melvine]

personne n'aurait un exemple simple et concret SVP?

[neguib]

Il faudrait peut être fouiller le site de ce membre de dvp : abdelelomari

[abdelelomari]

Pour comprendre la notion d'aggrégation, il faut commencer par celle de hierarchie ! Je m'explique :

En général Un magasin est localisé dans un secteur, Un secteur dans une Ville, une ville dans un pays, un pays dans un continent ! Nous disposons alors de la hierarchie "Magasin" suivante :

Continent
------- Pays
-----------Ville
--------------Secteur
-----------------Magasin

Le résultat est donc selon le design que l'on a choisi :

En schéma en étoile on aurait tout mis dans une seule table de dimension comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Magasins_dim(Code_magasin, Nom_magasin, Adresse, Code_secteur, Nom_secteur, Code_Ville, Nom_ville, Code_pays, Nom_pays, Code_continent, Nom_continent)

En Flocon de neige on aurait eu 5 tables:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
Magasins_dim(Code_magasin, Nom_magasin, Adresse, Code_secteur)
Secteur_dim(Code_secteur, Nom_secteur, Code_ville)
Ville_dim(Code_ville, Nom_ville, Code_Pays)
Pays_dim(Code_Pays, Nom_pays, Code_continent)
Continent_dim(Code_continent, Nom_continent)

Nous avons la table des ventes par magasin, Notez ici que les ventes par magasins est la granularité la plus fine de notre table :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Ventes ( Code_produit, Code_magasin, Vente_total, Code_jour)

On y représente donc les ventes par produit, par jour et par magasin.

Business Intelligence veut dire répondre à des questions du genre :
Quel est le total des ventes par Ville, par jour. Indépendement du magasin, du secteur et du produit ?

Il est impensable de charger toutes les données de la table "ventes" dans un cube pour pouvoir répondre à ce genre de question ! Parfois il est tout simplement impossible de le faire, comment peut-on feuilleter toutes ces données pour enfin répondre à la question ? la réponse est dans les tables d'aggrégat :

En général une table d'agrégat permet d'alimenter un Data mart dans un certain niveau de granularité. Dans notre cas le niveau de granularité est le suivant : Ventes par Ville et par jour... On doit alors créer une table d'aggrégation qui devra contenir ces données comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Ventes_agr(Vente_total, jour, Code_ville).

Pour alimenter cette table (Dans le cas du schéma en étoile) :
Dans Oracle je le ferais comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
INSERT INTO VENTES_AGR SELECT 
SUM(VF.VENTE_TOTAL), MD.CODE_VILLE, VF.JOUR FROM VENTES VF, MAGASINS_DIM MD
WHERE VF.CODE_MAGASIN =  MD.CODE_MAGASIN
GROUP BY MD.CODE_VILLE, VF.JOUR

On pourras donc soit alimenter un cube avec cette table, ou encore l'utiliser directement afin de faire des drill-down avec évidement un outil approprié.

Il existe des mécanisme plus sophistiqué pour ce genre de table, Oracle (Que je connais) dispose de ce qu'on appelle les vues materialisées ( Materialized views) qui peuvent être rafraichies soit incrémentalement ou au complet, automatiquement ou manuellement ...

Voila !

www.systemeetl.com
Tout sur les systèmes ETL, la modélisation dimensionnelle et les entrepôts de données.