Discussion :

[marchand_de_sable]

Bonjour à tous.

Dans de la doc sur l'OLAP et la modélisation multidimensionnelle, je suis tombé sur la notion de table d'agrégat, qui fait manifestement défaut à mes connaissances du domaine.

Or, je travaille actuellement sur une base de données issue de la gestion des payes de salariés, et on me demande régulièrement d'extraire des statistiques, comme les montants moyen/global versés selon une multitude de dimensions (age, CSP, l'ancienneté dans l'entreprise, etc).
Le modèle de la base se prête plutôt bien à ce genre de requête, sauf que vu la volumétrie (+/- 100 millions d'enregistrements de paye), les performances sont médiocres.
Je me suis donc dit qu'une table d'agrégat devait être faite pour ce genre de situation, non ?

Sauf qu'après reflexion, je ne vois pas ce que je peux précalculer, étant donné que je ne sais pas à l'avance selon quelles dimensions il me faudra calculer les statistiques... En fait, à part un aggrégat sur le temps (moyenne et somme payée à un employé par mois et par an), je ne vois ce que je calculer d'autre à l'avance sans être confronté par la suite à un soucis de granularité.
Suis-je à côté de la plaque ?
Est-ce le domaine dans lequel je travaille qui ne se prête pas à ça ?

D'une manière plus générale, il me semble que dans la modélisation d'un entrepôt de données, on choisit justement une granularité fine pour satisfaire à toute demande. Donc j'en arrive à la question du titre : que mettre dans une table d'agrégat ??

[nuke_y]

Souvent, une table d'agrégats s'applique sur un périmètre connu. Si tous les jours tes utilisateurs te sortent une nouvelle demande qui n'a aucun point commun avec les précédentes, ça me parait difficile.

Par contre si tu arrives à déceler que 50% des demandes qu'on te fait nécessitent toujours 2 ou 3 dimensions, alors tu pourras créer une table d'agrégats qui permet de répondre à ces cas là, c'est toujours ça de pris. Sinon ça me parait difficile. Encore qu'il existe des techniques avancées pour répondre à ce genre de problématiques :
- cube qui permet de pré-calculer toutes les possibilités,
- diviser les indicateurs par niveau d'agrégation différents et multiplier les tables d'agrégats pour choisir dans chaque cas celle qui est la plus adaptée,
- diverses techniques et feintes que j'ai déjà croisées mais dont je ne pourrais pas te parler de manière sérieuse. Quelqu'un d'autre pourra peut-être.

[Jean_Paul_XX]

Bonjour

Agrégat est un terme générique, et ce que vous décrivez réprend la problématique de mise en oeuvre d'un Datamart :
On met effectivement en oeuvre un DWH avec une granularité fine, dont l'une des fonctions de base est l'historisation.
A partir de ce DWH, qui est source de données réféférente, on peut construire des Datamarts répondant à des problématiques de granularité plus grossière (donc en agrégeant encore les données contenues dans le DWH), ou bien construire des faits (d'autres agrégats) pour répondre à une problématique "métier" orientée et spécifique (d'ou le terme mart = marché).
Votre table d'agrégats est donc dans ce cas ni plus ni moins qu'une table de faits complémentaire, liée à vos dimensions par des clés de substitution.

Ensuite, comme le cite nuke_y, il est difficile de répondre à priori à la demande de vos utilisateurs, et une anticipation ne peut s'acquérir dans ce contexte que de manière empirique en recensant les demandes les plus fréquentes (80/20). On répond ainsi parfaitement bien aux 80% de demandes récurrentes, les autres 20% étant assurés à partir du DWH, sans pénaliser la majorité.

[ygrim]

Je me permet d'ajouter un élément :
Les agrégats ne sont que rarement des modélisations effectives (physiques)... La conception en dimension et en fait, puis l'exploitation avec OLAP permettent de ne pas "prévoir" les demandes des utilisateurs, c'est ça la beauté du décisionnel : on prévoit (conçoit) les axes d'analyses (dimensions) et quoi analyser (les faits), ensuite, le modèle multi dimensionnel sur lequel se base OLAP va traiter les données selon ce qu'on demande (si on veut le cumul de la paye d'une personne depuis ses débuts dans l'entreprise, une requête MDX sera générée pour ce faire...
On agrège physiquement les données QUE lorsque cette solution pose des problèmes de performances aussi (on rentre dans le très très gros volume de données ou les très petits serveurs ), dans ce cas on à la possibilité de créer des agrégats sur les dimensions (modélisation en flocon) ou créer des agrégats sur les tables de faits. Ce à quoi il faut faire attention pour les tables de faits, c'est que les utilisateurs veulent toujours passer du gros au détail, donc il faut trouver un moyen de passer de la table agrégée à la table de détail...des heures de plaisir ! Si l'environnement ne fait pas ça, il n'obeira pas à une des régles de CODD, sa ne sera pas du ON LINE Analytical Processing.

Note : les outils OLAP permettent aussi de faire du "tunning" sur des cubes OLAP : partitionner, simuler du OLAP avec des tables agrégées automatiquement (microsoft), etc. Tu peux aussi voir de ce coté

[yphilogene]

Je rejoins ce qui a été répondu jusque là. D'après les bouquins, les tables d'aggrégats ne sont rien d'autre que des tables de faits avec des niveaux de granularité moins fins sur des axes d'analyse choisis. Pour moi, cela implique de la redondance d'information, car il sera alors possible d'obtenir la valeur de l'indicateur choisi de deux façons:

1) En passant par la table de faits détaillée au plus fin et en aggrégeant via GROUP BY sur le niveau de détail souhaité.

2) En interrogeant la table de faits déjà aggrégé au niveau de détail souhaité.


Hors sujet, l'organisation des tables de dimensions en flocons devrait améliorer très sensiblement les performances en réduisant le nombre de lignes requêtées par rapport à des tables de dimension dénormalisées. Cela dit, je ne l'ai jamais testé et beaucoup de spécialistes de tuning de base de données que je cotoie sont sceptiques sur le sujet.



En gros, pour booster le système, il n'y a pas trop de secret, il faut réduire le nombre de lignes à parcourir:
>> En général, tuner la base de données via la création d'index, de partitionnements, etc...
>> Pour des besoins de rapports très spécifiques, requêter des tables de faits aggrégées. Sur Oracle, penser aux vues matérialisées.

[ygrim]

C'est un regard très orienté BD que nous avons la !!
Il ne faut pas oublier que dans des environnements BI (surtout avec l'orientation commerciale actuelle), la plupart des gens utilisent l'entrepot de données pour alimenter un (ou des) cube OLAP, d'ou la confusion entre data warehouse et OLAP.
Le tuning peut se faire au niveau de l'entrepot, mais il est tout aussi important au niveau OLAP : choix de la technologie (ROLAP, MOLAP, HOLAP), partitionnement des données selon les axes et les données elles mêmes, mise en cache des requêtes les plus fréquentes, etc.
En fait, il faudrait voir l'architecture de la suite que tu utilises (Oracle, microsoft, BO, etc) et voir ou il faut agir pour de meilleurs performances

[Duc Lebowski]

Je rejoins ygrim, tout l'art de la BI consiste justement à déterminer quels sont les axes qui seront les plus consultées, à communiquer avec les métiers pour ajuster au mieux des datamarts fonction de leurs besoins et des contraintes techniques, anayser leurs requêtes, ...

S'il existait une recette de cuisine toute faite le métier en prendrait un certain coup

yphilogene : concernant l'organisation en flocon, dans certains cas il sera meilleur car tu auras moins de lignes à requêter, maintenant dès que tu voudras obtenir toutes les informations, il faudra que tu fasses des jointures qui risquent d'être très coûteuses...

La BI c'est l'art de faire des compromis (techniques/fonctionnels) pour arriver à un niveau de satisfaction maximal de diffusion de l'information.

[yphilogene]

Effectivement, je donne une vue très orientée base de données, car les données sont avant tout dans les tables et que ce soit pour en faire des cubes ou ajouter une couche logique R-OLAP, on passe forcément par des requêtes qui détermineront le temps de génération du cube ou le temps d'affichage du rapport basé sur du R-OLAP.

Au final, d'un point de vue performance pure, je suis d'avis que nous ne trouvons notre salut qu'avec des solutions intégrées aux bases de données (par exemple les vues matérialisées d'Oracle). Au niveau modélisation, on peut toujours s'arranger pour faire du flocon par ci, du dénormalisé par là, mais quand il s'agit de présenter le tout dans un outil où l'utilisateur construit en direct (et en temps réel, à H+1...) son rapport, c'est un peu peine perdue de leur expliquer "oui, dans tel cas tu dois utiliser cette table, pour éviter une jointure trop gourmande, mais ici tu peux faire ça...".

C'est pourquoi, l'idée même des tables d'aggrégation me rébute un peu tellement elle peut embrouiller l'utilisateur un peu avare d'efforts. Mais s'il s'agit de construire un rapport important et statique, pourquoi pas.

[marchand_de_sable]

Merci pour vos réponses intéressantes et désolé pour la mienne un peu tardive...
Je n'ai pas trop de temps à cette heure, mais je poserais une question subsidiaire plus tard

Au final, d'un point de vue performance pure, je suis d'avis que nous ne trouvons notre salut qu'avec des solutions intégrées aux bases de données (par exemple les vues matérialisées d'Oracle). Au niveau modélisation, on peut toujours s'arranger pour faire du flocon par ci, du dénormalisé par là, mais quand il s'agit de présenter le tout dans un outil où l'utilisateur construit en direct (et en temps réel, à H+1...) son rapport, c'est un peu peine perdue de leur expliquer "oui, dans tel cas tu dois utiliser cette table, pour éviter une jointure trop gourmande, mais ici tu peux faire ça...".

En fait, dans mon cas, quelques utilisateurs "avertis" auraient accès aux 2 tables (aggrégée, non aggrégée), mais surtout, seule la table d'aggrégat serait accessible au plus grand nombre qui ne sauraient que faire des détails les plus fins.

[marchand_de_sable]

Je reviens à la charge
En fait, le sujet de ce post vient pour moi du flou artistique qui semble règner dans le vocabulaire de l'analyse OLAP du fait, notamment, de la confusion entre concepts et implémentations techniques.

Donc pour reformuler ma question : 1) une table d'agrégats a-t-elle sa place dans la théorie de l'analyse OLAP, ou 2) est-ce simplement une manière (parmis d'autres) :
- d'implémenter une table de fait plus "grossière" dans la mise en place d'un datamart;
ET/OU
- d'implémenter un cube ?

Dans mes connaissances initiales en OLAP, je n'avais pas entendu parler de tables d'agrégats (pour moi, les agrégats étaient placés dans la/les table(s) de fait(s) ou étaient calculés dans des cubes), et je pencherais a priori pour la réponse 2). Mais je m'en vaudrais de passer à côté d'un concept fondamental...

Encore qu'il existe des techniques avancées pour répondre à ce genre de problématiques :
- cube qui permet de pré-calculer toutes les possibilités

As-tu un exemple de ces "techniques" ? Ca ressemble à de l'artillerie lourde, non ? Tu parles de fonctionnalités qu'on retrouve dans certains SQBG comme Oracle (avec options OLAP) ou M$ IIS par exemple ? Mes connaissances dans le domaine se limitent aux fonctionnalités relationnelles des SGBD. Sachant que je travaille sur du Oracle 9.2 avec OLAP, savez-vous si cet outil propose ce type de fonctionnalité avancée ?

Il ne faut pas oublier que dans des environnements BI (surtout avec l'orientation commerciale actuelle), la plupart des gens utilisent l'entrepot de données pour alimenter un (ou des) cube OLAP, d'ou la confusion entre data warehouse et OLAP.

Vous pourriez m'éclairer là-dessus ?
J'imagine que je fais parti de ceux qui font cette confusion, vu que pour moi, DataWarehousing et OLAP ne font qu'un (ou plutôt, font parti d'un même processus). L'entrepôt (tout comme les datamarts qui en sont l'extension) est l'espace de stockage de données, et l'OLAP, l'ensemble des techniques d'analyse que l'on veut/peut appliquer à ces données. Les cubes sont une des étapes possibles de l'analyse : ils permettent de passer à du multidimensionnel à proprement parlé par un 1er traitement des données, mais pas de cube sans données, donc sans entrepôt...
Je dirais, pour préciser ma manière de voir, qu'un cube n'est qu'un concept d'analyse. Après tout, un tableau croisé dans Excel est un cube, et ils étaient utilisés bien avant qu'on parle d'OLAP. Le fait que certains outils permettent de stocker des données sous forme de cube n'est qu'une question de choix d'implémentation des éditeurs (et de progrès technique), mais une vue matérialisée peut très bien faire office de cube, non ? De plus, rien n'empêche de faire de l'OLAP sans passer par des cubes (requête SQL avec GROUP BY).

En bref, je vois mal comment on peut faire des cubes (plus aboutis que des tableaux Excel ) et/ou de l'OLAP sans entrepôts derrière pour stocker les données.
Voyez-vous des erreurs dans mon raisonnement ? Des lacunes ? Des confusions ?

Question subsidiaire : nuke_y, ygrim, yphilogene : c'est une coïncidence, ou vous composez le gang des y ??

[yphilogene]

Euh... c'est une coïncidence je pense .

Pour moi, ce qu'on appelle un "cube" est un fichier physique, pas un concept. On parlera ainsi d'un cube Microsoft, d'un cube Cognos, etc... qui sont physiquement générés suivant la technologie propriétaire de chacun (tout comme une table Oracle est généré suivant un code différent d'une table SQL Server).

Le concept, c'est OLAP. Le cube, c'est le fichier qui contient les données structurées de façon à pouvoir les interroger avec le langage MDX. Donc, pour moi, dire qu'un TBD Excel est un cube est erroné.

Maintenant, pour définir le concept OLAP, c'est assez compliqué, comme tout concept . Pour rester simple, disons que OLAP = Analyse, c'est-à-dire présentation des données sous une forme qui ressemble effectivement le plus souvent à un TBD Excel (des groupements en ligne, des groupements en colonnes, des filtres en contexte).

Pour implémenter l'OLAP, on peut:
- construire un cube et l'interroger avec un outil adéquat.
- créer un datamart, avec une modélisation en étoile et une couche logicielle permettant de faire du R-OLAP et interroger avec un outil adéquat.

Pour prendre l'exemple de Cognos:

- Cognos permet de construire des cubes via l'outil Transformer. Ces cubes sont interrogeables par Analysis Studio (ou Powerplay dans les anciennes versions). Il y a la possibilité lors de la génération du cube (qui se fait généralement durant un process de nuit) de demander à ce que tous les calculs à tous les niveaux soit précalculés et stockés. Dans ce cas, lors des requêtes MDX, les résultats arrivent ultra rapidement, mais bon il faut du temps pour générer ces énormes cubes.

- Cognos permet de construire des modèles dit DMR (Dimensionally Modeled Relational) avec l'outil Framework Manager. Ces modèles sont interrogeables par Analysis Studio également. En fait, techniquement, les tables sont interrogées et un mini cube est généré à la volée. C'est ça le R-OLAP. Il n'y a pas de secret, pour implémenter OLAP, il faut passer par le langage MDX, et pour ce faire, il faut structurer la donnée sous la forme d'un cube. Avec le DMR, on fait en quelque sorte du "cube temps réel". Ce sont les tables qui sont raffraichies durant un process de nuit et le cube est générée à la volée suivant la requête demandée. Les calculs sont alors eux aussi fait en temps réel (bref, c'est lent quoi...).

Et on en vient aux tables d'aggrégations qui pour moi a du sens dans le cas du R-OLAP. Si tu ne veux pas que les calculs soient effectuées pendant la requête (via GROUP BY), tu n'as d'autres choix que de calculer et stocker les aggrégations (via les tables d'aggrégations). Autrement dit, tu fais à la main ce que certains outils de modélisation de cubes proposent via des fonctionnalités.


En résumé:

- Soit tu fais du cube, alors il y a de forte chance que ton outil propose des fonctionnalités pour précalculer les données à tous les niveaux pour les stocker dans le cube.

- Soit tu fais du R-OLAP (ou même du SQL sur modèle en étoile), alors tu dois utiliser des tables d'aggrégation si tu veux stocker les calculs aux niveaux aggrégés, pour éviter que ces calculs se fassent au moment de la requête sur les données les plus détaillées.

[ygrim]

Re salut tout le monde !
Bien vu pour le gang des Y Tu nous as démasqués !!!! non c'est une blague

On va essayer de mettre les choses à plat. Je propose de définir les notions de OLAP et de cubes (décisionnel) en les confrontant à leur homologues traditionnels (opérationnels) :
- OLAP, pour OnLine Analytical Processing désigne une suite de régles définies par Monsieur CODD (voir OLAP dans wikipedia). Ces régles, que tout outils se disant en mode 'OLAP' doit réspecter, permettent de faire (comme le nom l'indique) de l'analyse de données en ligne : pouvoir naviguer dans les données d'une entreprise et en faire à peu près tout ce que l'on veut (sommes, agrégats, croisements, confrontations, tendances, etc.).
- OLTP, pour OnLine Transactional Processing est l'alter ego opérationnel du OLAP. les systemes OLTP permettent de gérer des opérations élémentaires (transactions) : entrer une facture, interroger une commande, entrer un nouveau client. Ces opérations, qui font vivre l'entreprise, nourissent les entrepot de données et les systèmes OLAP de par ce fait.
-Cubes : les cubes sont une nomination "grand public" de ce que l'on appele le modèle multi-dimensionnel. C'est une façon de représenter les données que l'on modélise pour analyser(comme le modèle relationnel mais orienté analyse plutot que transaction). On appèle ce modèle dimensionnel car il se base sur des dimensions et des faits (contrairement au relationnel qui se base sur des entités et des relations). La nomination "cube" viens d'un modèle dimensionnel à trois dimensions, plus visualisable par un esprit humain, mais il existe des modèles à 4, 5, 6, 10 dimensions, sans problème.
Donc, pour résumer, on fait de l'OLAP sur des cubes On fait de l'analyse de données sur un modèle multi-dimensionnel. Aussi simple que ça
C'est vrai que les fabriquants de logiciels ne nous facilitent pas la tache. OLAP, cube, dataMining, entrepôts sont si facilement sortis de leur bouche que la confusion n'est que logique.
AH ! petit point à préciser. Un entrepôt de données, et bien c'est simplement un modèle multi dimensionnel avec plusieurs dimensions et plusieurs faits. Si je veut parler comme un commercial, je dirais que c'est plusieurs cubes entrelacés.

J'espère que mon discours aura été plus éclairant qu'autre chose Je suit cette discussion à fond et je répondrais à toutes vos questions et remarques.

Merci pour votre implication

[Paul_S]

Bonjour et félécitations pour la clarté de vos discours,

J'ajouterai ces précisions :

ygrim : "... Ces régles, que tout outils se disant en mode 'OLAP' doit réspecter, permettent de faire (comme le nom l'indique) de l'analyse de données en ligne : pouvoir naviguer dans les données d'une entreprise et en faire à peu près tout ce que l'on veut (sommes, agrégats, croisements, confrontations, tendances, etc.)..."

Pour rester concret et sortir un peu la tête de la théorie de Codd, ce qui est primordial dans le concept OLAP, c'est effectivement les possibilités de Navigation offertes (déplacements de type Drill down, Slice-Dice...) sous tendues par au choix : la présence physique des données dans le DWH (M-OLAP), ou bien par les calculs à la volée mis en oeuvre par le moteur de restitution (R-OLAP), ce qui représente effectivement l'implémentation du concept.
Ce sont ces déplacements qui permettent les possibilités d'analyse.

J'ajouterais (pour revenir à nos moutons), que le terme Agrégat comme le cite Jean_Paul_XX (non non, ce n'est pas le gang des Paul ... ) est effectivement générique : les tables de faits sont générées à partir d'Agrégations effectuées sur la base de données transactionnelle par groupage sur les dimensions à mettre en ligne.

ygrim : "... Un entrepôt de données, et bien c'est simplement un modèle multi dimensionnel avec plusieurs dimensions et plusieurs faits..."

Bon nombre d'organisations possèdent des entrepôts de données, et des solutions de reporting qui ne font pas appel aux concepts multidimensionnels. En d'autres termes : DWH ne signifie pas obligatoirement OLAP. On peut tès bien construire des Dahboards à partir de données préparées et mises en ligne dans un DWH.



Enfin, pour la petit histoire et compléter votre propos

ygrim : "... La nomination "cube" viens d'un modèle dimensionnel à trois dimensions, plus visualisable par un esprit humain..."

le concept de Cube doit son nom au Rubik's cube, par analogie aux déplacements possibles sur ce dernier (notamment le Slice-Dice qui permet de pivoter une tranche du cube)

[ygrim]

Merci pour tes précisions Paul,
Effectivement tu as raison pour les entrepôts de données. J'ai voulu simplifié les choses mais j'ai donné une fausse info à la place
Un entrepôt de donnée c'est tout ce qui regroupe les données d'une entreprise, c'est la mémoire de l'entreprise. Peu importe le moyen utilisé pour la stocker.
Ce que j'entendais par ma définition est que le modèle à base de dimensions et de faits est le meilleur moyen, à date, qu'on ai trouvé pour représenter ces données pour des fins analytiques.

[nuke_y]

As-tu un exemple de ces "techniques" ? Ca ressemble à de l'artillerie lourde, non ? Tu parles de fonctionnalités qu'on retrouve dans certains SQBG comme Oracle (avec options OLAP) ou M$ IIS par exemple ? Mes connaissances dans le domaine se limitent aux fonctionnalités relationnelles des SGBD. Sachant que je travaille sur du Oracle 9.2 avec OLAP, savez-vous si cet outil propose ce type de fonctionnalité avancée ?

Oui le cube c'est de l'artillerie lourde, personnellement je n'ai effleuré ça qu'au début de ma carrière et depuis j'ai tjs eu la chance (malchance ?) de ne pas en recroiser. Encore qu'il y a un cube ESSBASE de l'autre côté du couloir de mon bureau mais je n'ai pas mis le nez dedans...

[yphilogene]

Euh... sur ce dernier point, je ne suis pas trop d'accord. Construire un cube, ce n'est pas sortir l'artillerie lourde. Enfin, bien entendu, tout dépend du besoin exprimé et de l'adéquation d'une solution cube à ce besoin.

Mais voilà, construire un cube permet d'obtenir très rapidement une structure physique exploitable pour l'analyse des données, ie. slice&dice, drill up/down, grâce au MDX.

Obtenir les mêmes fonctionnalités, la même souplesse, avec des requêtes SQL peut être un vrai défi et amener à justement à sortir l'artillerie lourde: pivots, multiples jointures, table d'aggrégations...

nuke_y, en tant que membre du clan des Y, tu te dois de te réconcilier avec les cubes!

[nuke_y]

Disons qu'il me semble qu'un cube facilite énormément l'exploitation des données mais sa création peut être assez complexe, particulièrement à cause des règles d'intégrité à respecter. Enfin j'en ai jamais vraiment fait, mais je croise parfois les mecs du cube ESSBASE qui m'en parlent.

Ps : je suis nuke_y, du clan des y. A la fin, il ne peut en rester qu'un

[Paul_S]

Essbase est une techno assez ancienne et révolue. Ca, c'est de l'usine à gaz .
Je me demande d'ailleurs si Oracle a fait une bonne affaire dans ce deal ...

Bref,
Pour la simplicité, l'évolutivité et l'Agilité, il faut regarder du côté R-OLAP (Cognos MDR de yphilogène, Latitudes-BI de Jean_Paul_XX, et certaines solutions libres...). Là effectivement, on construit un cube à partir de multiples sources de données en deux coups de cuiller à pot !

Pour l'artillerie lourde, effectivement il y a le M-OLAP avec le MDX. Là, pour rajouter une colonne à un rapport, il faut remonter à l'alimentation du DWH pour intégrer la donnée dans une table de faits.
Comme souplesse ... Mais c'est parfois nécessaire.

[marchand_de_sable]

Ca ressemble à de l'artillerie lourde, non ?

En fait, vu qu'à l'origine je m'interrogeait sur la création d'une table contenant quelques aggrégats (en fait, je me posait notamment la question en comparaison avec la création d'un vue matiérialisée, donc le tout étant jouable en une grosse requête), il me semblait que les "techniques spécifiques" pour construire un cube (ou quelque chose d'équivalent) dont parle nuke_y était exagérées dans mon cas...

Pour ce qui est des cubes à proprement parlé, j'en ai construit une fois ou deux avec Transformer de Cognos pour voir comment l'outil fonctionne, mais je ne suis jamais allé jusqu'à l'interrogation de ces mêmes cubes avec Powerplay.
Vous parler du MDX pour les interroger. Or j'ai cru voir qu'à l'origine, c'est un langage M$ spécifique à SQLServer (vous confirmez ?). Ce langage est-il normalisé entre éditeur, ou chacun a-t-il son propre langage de requête (ou sa propre implémentation du MDX ?

[nuke_y]

En fait, vu qu'à l'origine je m'interrogeait sur la création d'une table contenant quelques aggrégats (en fait, je me posait notamment la question en comparaison avec la création d'un vue matiérialisée, donc le tout étant jouable en une grosse requête), il me semblait que les "techniques spécifiques" pour construire un cube (ou quelque chose d'équivalent) dont parle nuke_y était exagérées dans mon cas...

Oui, c'est exagéré pour ta problématique. J'ai parlé du cube pour des cas où tes utilisateurs voudraient une certaine flexibilité dans le niveau d'aggrégation de la table, ce qui est compliqué à faire avec une simple table.