Mis en ligne le 13/04/2005 - Publié en Juin 2004
Création de cubes, écriture de requêtes MDX, optimisation de DTS et plus encore...
Utilisation des mesures chargées pour personnaliser les agrégations
Une technique courante pour personnaliser
la méthode d’agrégation d’une mesure
consiste à définir une mesure calculée sur la
base d’une mesure chargée, puis à masquer
cette dernière. Par exemple, vous souhaitez
agréger une mesure de vente (Sales)
sous forme de somme, mais dans deux
dimensions, vous voulez l’agréger en
tant que moyenne. Dans la définition
de la mesure, vous pouvez spécifier
une mesure nommée TempSales, qui
est chargée directement à partir de la
colonne Sales de la table de faits. Vous
pouvez marquer cette mesure comme
étant masquée, de sorte qu’elle soit invisible
pour les applications client
OLAP. Vous pouvez ensuite employer la mesure TempSales
dans un calcul sans qu’elle soit accessible aux utilisateurs
d’Analysis Services. Vous utilisez alors Analysis Manager pour
créer une nouvelle mesure calculée nommée Sales, qui retournera
la valeur TempSales non modifiée, sauf si vous souhaitez
que cette valeur corresponde à une moyenne de
TempSales.
Cette technique consistant à créer des mesures calculées
et à masquer les mesures chargées est courante dans les implémentations
SQL Server 7.0 OLAP Services, car ce dernier
ne prend pas en charge les techniques de cellules calculées
ou de cumul. Toutefois, l’utilisation de mesures calculées
dans les versions 2000 et 7.0 de SQL Server présente plusieurs
inconvénients. Par exemple, vous ne pouvez pas employer
de mesures calculées pour réécrire vers des cellules
du cube. Une des raisons pour lesquelles Analysis Services et
OLAP Services n’autorisent pas cette opération est qu’une
mesure calculée n’est pas mappée directement avec une colonne
de la table de faits, de sorte qu’Analysis Services ne sait
pas quelle mesure chargée modifier.
En conséquence de quoi, les cellules calculées ne sont
pas particulièrement utiles pour les applications de budgétisation
ou de modélisation. Un autre inconvénient des
membres calculés réside dans le fait qu’ils ne peuvent aller
de pair avec la fonction MDX AGGREGATE. Cette dernière
est une fonction MDX courante, servant à agréger un ensemble de membres ou n-uplets. La mesure identifiée dans
l’ensemble détermine la méthode d’agrégation utilisée par la
fonction AGGREGATE. Si vous employez une mesure calculée
dans l’ensemble, Analysis Services (et OLAP Services)
n’est pas en mesure de déterminer la méthode d’agrégation,
ce qui entraîne l’échec de la méthode AGGREGATE. Si vous
employez une technique telle que les cellules calculées pour
modifier l’agrégation d’une mesure, la fonction AGGREGATE
fonctionne car elle est basée sur la méthode d’agrégation définie
de la mesure.
par Russ Whitney
Téléchargez cette ressource
Mac en entreprise : le levier d’un poste de travail moderne
Ce livre blanc répond aux 9 questions clés des entreprises sur l’intégration du Mac : sécurité, compatibilité, gestion, productivité, coûts, attractivité talents, RSE et IA, et l’accompagnement sur mesure proposé par inmac wstore.
Les articles les plus consultés
- Databricks lève 1 milliard de dollars !
- ActiveViam fait travailler les data scientists et les décideurs métiers ensemble
- 10 grandes tendances Business Intelligence
- L’utilisation des données pour survivre !
- Stockage autonome, Evolutivité & Gestion intelligente, Pure Storage offre de nouvelles perspectives aux entreprises
Les plus consultés sur iTPro.fr
- Cloud et IA : une maturité en retard face à l’explosion des usages
- On ne peut pas gouverner ce qu’on ne peut pas voir : pourquoi la visibilité doit-elle passer avant la gouvernance en matière de sécurité des identités ?
- L’IA amplifie les risques sur les API
- Fuites de données : la France, 2ème pays le plus touché au monde début 2026
Articles les + lus
Faire évoluer la souveraineté des données du statut d’ambition politique à son application opérationnelle
Fuites de données : la France, 2ème pays le plus touché au monde début 2026
Redéfinir la confiance à l’ère de l’IA agentique : les entreprises sont-elles prêtes pour le SOC autonome ?
Les défaillances des pipelines de données pèsent lourdement sur la performance des grandes entreprises
Les nouvelles menaces liées à l’IA obligent les entreprises à dépasser la seule stratégie de sauvegarde
À la une de la chaîne Data
- Faire évoluer la souveraineté des données du statut d’ambition politique à son application opérationnelle
- Fuites de données : la France, 2ème pays le plus touché au monde début 2026
- Redéfinir la confiance à l’ère de l’IA agentique : les entreprises sont-elles prêtes pour le SOC autonome ?
- Les défaillances des pipelines de données pèsent lourdement sur la performance des grandes entreprises
- Les nouvelles menaces liées à l’IA obligent les entreprises à dépasser la seule stratégie de sauvegarde
