SUMMARIZECOLUMNS
S’applique à : 
Colonne calculée Table calculée Mesure 
Calcul de visuel
Retourne une table récapitulative sur un ensemble de groupes.
Syntaxe
SUMMARIZECOLUMNS( <groupBy_columnName> [, < groupBy_columnName >]…, [<filterTable>]…[, <name>, <expression>]…)
Paramètres
| Terme | Définition |
|---|---|
| groupBy_columnName | Référence de colonne complète (Table[Column]) à une table de base pour laquelle les valeurs distinctes sont incluses dans la table retournée. Chaque colonne groupBy_columnName est soumise à une jointure croisée (tables différentes) ou existe automatiquement (même table) avec les colonnes spécifiées suivantes. |
| filterTable | Expression de table qui est ajoutée au contexte de filtre de toutes les colonnes spécifiées en tant qu’arguments groupBy_columnName. Les valeurs présentes dans la table de filtres sont utilisées pour filtrer avant que la jointure croisée/l’existence automatique ne soit effectuée. |
| name | Chaîne représentant le nom de colonne à utiliser pour l’expression suivante spécifiée. |
| expression | Toute expression DAX qui retourne une seule valeur (et non une table). |
Valeur de retour
Table qui contient des combinaisons de valeurs des colonnes fournies en fonction du regroupement spécifié. Seules les lignes pour lesquelles au moins une des expressions fournies retourne une valeur non vide sont incluses dans la table retournée. Si toutes les expressions ont la valeur BLANK/NULL pour une ligne, cette ligne n’est pas incluse dans la table retournée.
Remarques
Cette fonction ne garantit aucun ordre de tri des résultats.
Une colonne ne peut pas être spécifiée plusieurs fois dans le paramètre groupBy_columnName. Par exemple, la formule suivante n’est pas valide.
SUMMARIZECOLUMNS( Sales[StoreId], Sales[StoreId] )Cette fonction n’est pas prise en charge pour une utilisation en mode DirectQuery quand elle est utilisée dans des colonnes calculées ou des règles de sécurité au niveau des lignes (RLS).
Contexte de filtre
Considérez la requête suivante :
SUMMARIZECOLUMNS (
'Sales Territory'[Category],
FILTER('Customer', 'Customer' [First Name] = "Alicia")
)
Dans cette requête, sans mesure, les colonnes groupBy ne contiennent aucune colonne de l’expression FILTER (par exemple, la table Customer). Le filtre n’est pas appliqué aux colonnes groupBy. Les tables Sales Territory et Customer peuvent être indirectement liées par le biais de la table de faits Reseller Sales. Étant donné qu’elles ne sont pas directement liées, l’expression de filtre ne présente aucune opération et les colonnes groupBy ne sont pas affectées.
Toutefois, avec cette requête :
SUMMARIZECOLUMNS (
'Sales Territory'[Category], 'Customer' [Education],
FILTER('Customer', 'Customer'[First Name] = "Alicia")
)
Les colonnes groupBy contiennent une colonne qui est affectée par le filtre et ce filtre est appliqué aux résultats des colonnes groupBy.
Avec IGNORE
La syntaxe IGNORE peut être utilisée pour modifier le comportement de la fonction SUMMARIZECOLUMNS en omettant des expressions spécifiques de l’évaluation BLANK/NULL. Les lignes pour lesquelles toutes les expressions qui n’utilisent pas IGNORE retournent BLANK/NULL sont exclues, indépendamment du fait que les expressions qui utilisent IGNORE sont ou non évaluées à la valeur BLANK/NULL. IGNORE peut uniquement être utilisé dans une expression SUMMARIZECOLUMNS.
Exemple
SUMMARIZECOLUMNS(
Sales[CustomerId], "Total Qty",
IGNORE( SUM( Sales[Qty] ) ),
"BlankIfTotalQtyIsNot3", IF( SUM( Sales[Qty] )=3, 3 )
)
Cela cumule la colonne Sales[CustomerId], ce qui crée un sous-total pour tous les clients du regroupement donné. Sans IGNORE, le résultat est le suivant :
| CustomerId | Total Qty | BlankIfTotalQtyIsNot3 |
|---|---|---|
| A | 5 | |
| B | 3 | 3 |
| C | 3 | 3 |
Avec IGNORE,
| CustomerId | Total Qty | BlankIfTotalQtyIsNot3 |
|---|---|---|
| B | 3 | 3 |
| C | 3 | 3 |
Toutes les expressions ignorées,
SUMMARIZECOLUMNS(
Sales[CustomerId], "Blank",
IGNORE( BLANK() ), "BlankIfTotalQtyIsNot5",
IGNORE( IF( SUM( Sales[Qty] )=5, 5 ) )
)
Même si les deux expressions retournent des valeurs vides pour certaines lignes, elles sont incluses, car il n’y a pas d’expressions non ignorées qui retournent des valeurs vides.
| CustomerId | Vide | BlankIfTotalQtyIsNot5 |
|---|---|---|
| A | 5 | |
| B | ||
| C |
Avec NONVISUAL
La fonction NONVISUAL marque un filtre de valeur dans la fonction SUMMARIZECOLUMNS comme n’affectant pas les valeurs de mesure, mais uniquement comme s’appliquant à des colonnes groupBy. NONVISUAL peut uniquement être utilisé dans une expression SUMMARIZECOLUMNS.
Exemple
DEFINE
MEASURE FactInternetSales[Sales] = SUM(FactInternetSales[Sales Amount])
EVALUATE
SUMMARIZECOLUMNS
(
DimDate[CalendarYear],
NONVISUAL(TREATAS({2007, 2008}, DimDate[CalendarYear])),
"Sales", [Sales],
"Visual Total Sales", CALCULATE([Sales], ALLSELECTED(DimDate[CalendarYear]))
)
ORDER BY [CalendarYear]
Retourne le résultat où [Visual Total Sales] correspond au total sur toutes les années :
| DimDate[CalendarYear] | [Sales] | [Visual Total Sales] |
|---|---|---|
| 2007 | 9 791 060,30 | 29 358 677,22 |
| 2008 | 9 770 899,74 | 29 358 677,22 |
En revanche, la même requête sans la fonction NONVISUAL :
DEFINE
MEASURE FactInternetSales[Sales] = SUM(FactInternetSales[Sales Amount])
EVALUATE
SUMMARIZECOLUMNS
(
DimDate[CalendarYear],
TREATAS({2007, 2008}, DimDate[CalendarYear]),
"Sales", [Sales],
"Visual Total Sales", CALCULATE([Sales], ALLSELECTED(DimDate[CalendarYear]))
)
ORDER BY [CalendarYear]
Retourne le résultat où [Visual Total Sales] correspond au total sur les deux années sélectionnées :
| DimDate[CalendarYear] | [Sales] | [Visual Total Sales] |
|---|---|---|
| 2007 | 9 791 060,30 | 19 561 960,04 |
| 2008 | 9 770 899,74 | 19 561 960,04 |
Avec ROLLUPADDISSUBTOTAL
L’ajout de la syntaxe ROLLUPADDISSUBTOTAL modifie le comportement de la fonction SUMMARIZECOLUMNS en ajoutant des lignes de cumul/sous-total au résultat basé sur les colonnes groupBy_columnName. ROLLUPADDISSUBTOTAL peut uniquement être utilisé dans une expression SUMMARIZECOLUMNS.
Exemple avec un sous-total unique
DEFINE
VAR vCategoryFilter =
TREATAS({"Accessories", "Clothing"}, Product[Category])
VAR vSubcategoryFilter =
TREATAS({"Bike Racks", "Mountain Bikes"}, Product[Subcategory])
EVALUATE
SUMMARIZECOLUMNS
(
ROLLUPADDISSUBTOTAL
(
Product[Category], "IsCategorySubtotal", vCategoryFilter,
Product[Subcategory], "IsSubcategorySubtotal", vSubcategoryFilter
),
"Total Qty", SUM(Sales[Qty])
)
ORDER BY
[IsCategorySubtotal] DESC, [Category],
[IsSubcategorySubtotal] DESC, [Subcategory]
Retourne la table suivante :
| Category | Sous-catégorie | IsCategorySubtotal | IsSubcategorySubtotal | Total Qty |
|---|---|---|---|---|
| True | True | 60398 | ||
| Accessories | False | True | 36092 | |
| Accessories | Porte-vélos | False | False | 328 |
| Bikes | VTT | False | False | 4970 |
| Clothing | False | True | 9101 |
Exemple avec plusieurs sous-totaux
SUMMARIZECOLUMNS (
Regions[State], ROLLUPADDISSUBTOTAL ( Sales[CustomerId], "IsCustomerSubtotal" ),
ROLLUPADDISSUBTOTAL ( Sales[Date], "IsDateSubtotal"), "Total Qty", SUM( Sales[Qty] )
)
Les ventes sont regroupées par région, par client, par date, avec des sous-totaux pour 1. Ventes par région, par date 2. Ventes par région, par client 3. Regroupement sur le client et la date qui aboutit aux ventes par région.
Retourne la table suivante :
| CustomerID | IsCustomerSubtotal | State | Total Qty | Date | IsDateSubtotal |
|---|---|---|---|---|---|
| A | FAUX | WA | 5 | 7/10/2014 | |
| B | FAUX | WA | 1 | 7/10/2014 | |
| B | FAUX | WA | 2 | 7/11/2014 | |
| C | FAUX | OR | 2 | 7/10/2014 | |
| C | FAUX | OR | 1 | 7/11/2014 | |
| TRUE | WA | 6 | 7/10/2014 | ||
| TRUE | WA | 2 | 7/11/2014 | ||
| TRUE | OR | 2 | 7/10/2014 | ||
| TRUE | OR | 1 | 7/11/2014 | ||
| A | FAUX | WA | 5 | TRUE | |
| B | FAUX | WA | 3 | TRUE | |
| C | FAUX | OR | 3 | VRAI | |
| VRAI | WA | 8 | VRAI | ||
| VRAI | OR | 3 | TRUE |
Avec ROLLUPGROUP
Comme avec la fonction SUMMARIZE, la fonction ROLLUPGROUP peut être utilisée avec ROLLUPADDISSUBTOTAL pour spécifier les groupes/précisions de synthèse (sous-totaux) à inclure, et réduire ainsi le nombre de lignes de sous-total retournées. ROLLUPGROUP peut uniquement être utilisé dans une expression SUMMARIZECOLUMNS ou SUMMARIZE.
Exemple avec plusieurs sous-totaux
SUMMARIZECOLUMNS(
ROLLUPADDISSUBTOTAL( Sales[CustomerId], "IsCustomerSubtotal" ),
ROLLUPADDISSUBTOTAL(ROLLUPGROUP(Regions[City], Regions[State]), "IsCityStateSubtotal"),"Total Qty", SUM( Sales[Qty] )
)
Toujours avec un regroupement par ville et région, mais calculés ensemble pour le sous-total ; retourne la table suivante
| State | CustomerId | IsCustomerSubtotal | Total Qty | City | IsCityStateSubtotal |
|---|---|---|---|---|---|
| WA | A | FAUX | 2 | Bellevue | FALSE |
| WA | B | FAUX | 2 | Bellevue | FALSE |
| WA | A | FAUX | 3 | Redmond | FALSE |
| WA | B | false | 1 | Redmond | FALSE |
| OR | C | FAUX | 3 | Portland | FALSE |
| WA | TRUE | 4 | Bellevue | FALSE | |
| WA | TRUE | 4 | Redmond | FALSE | |
| OR | TRUE | 3 | Portland | FALSE | |
| A | false | 5 | FAUX | ||
| B | FAUX | 3 | TRUE | ||
| C | FAUX | 3 | VRAI | ||
| TRUE | 11 | VRAI |
SummarizeColumns contextuels
Background
Jusqu’en février 2023, SUMMARIZECOLUMNS ne prenait pas du tout en charge l’évaluation dans le cadre d’une transition de contexte. Dans les produits publiés avant ce mois, cette limitation a rendu SUMMARIZECOLUMNS inutile dans la plupart des mesures ; il n’était possible d’appeler une mesure SUMMARIZECOLUMNS dans aucun cas de transition de contexte, y compris d’autres instructions SUMMARIZECOLUMNS.
Depuis février 2023, la transition de contexte a été prise en charge dans quelques scénarios, mais pas dans toutes les conditions. Les cas pris en charge et restreints sont les suivants :
| Type SummarizeColumns | Filtre externe avec une seule colonne | Filtre externe avec plusieurs colonnes | Colonnes GroupBy externes |
|---|---|---|---|
| SummarizeColumns avec GroupBy uniquement | OK | OK | OK |
| SummarizeColumns avec des filtres ou des mesures | OK | ERROR | ERROR |
Depuis juin 2024, nous activons les SummarizeColumns contextuels qui permettent à SummarizeColumns d’être évalués dans toute transition de contexte. SummarizeColumns dans les mesures est désormais entièrement pris en charge :
| Type SummarizeColumns | Filtre externe avec une seule colonne | Filtre externe avec plusieurs colonnes | Colonnes GroupBy externes |
|---|---|---|---|
| SummarizeColumns avec GroupBy uniquement | OK | OK | OK |
| SummarizeColumns avec des filtres ou des mesures | OK | OK | OK |
Toutefois, cette mise à jour inclut également des modifications apportées au comportement de SummarizeColumns, ce qui peut modifier les résultats d’expressions existantes :
Sémantique SelfValue pour les filtres externes
Nous introduisons un concept sémantique nommé SelfValue, qui modifie la façon dont les filtres des tables externes interagissent avec les colonnes GroupBy dans SummarizeColumns. Cette modification interdit aux filtres d’une autre table d’affecter les colonnes GroupBy, même si les tables sont associées via une relation de filtre par relation. Un exemple illustrant l’impact de cette modification implique l’expression suivante :
CalculateTable(
SummarizeColumns(
'Reseller Sales'[ResellerKey],
'Reseller Sales'[ProductKey]
),
Treatas({(229)}, 'Product'[Product Key])
)
Avant cette mise à jour, le filtre TreatAs s’appliquait à l’opération GroupBy dans SummarizeColumns, en exploitant la relation entre « Product » [Product Key] et « Reseller Sales » [ProductKey]. Par conséquent, les résultats de la requête incluaient uniquement les lignes où « Reseller Sales » [ProductKey] est égal à 229. Toutefois, après la mise à jour, les colonnes GroupBy dans SummarizeColumns ne seront plus filtrées par colonnes depuis des tables externes, même si une relation existe entre elles. Par conséquent, dans l’exemple ci-dessus, la colonne GroupBy « Reseller Sales » [ProductKey] ne sera pas filtrée par la colonne « Product » [ProductKey]. Par conséquent, la requête inclura les lignes où « Reseller Sales » [ProductKey] n’est pas égal à 229.
Si vous préférez conserver le comportement précédent, vous pouvez réécrire l’expression en utilisant Summarize au lieu de SummarizeColumns, comme indiqué ci-dessous :
CalculateTable(
SUMMARIZE(
'Reseller Sales',
[ResellerKey],
[ProductKey]
),
Treatas({(229)}, 'Product'[Product Key])
)
Cette expression réécrite conserve la sémantique d’origine où l’opération GroupBy n’est pas affectée par la restriction SelfValue introduite par la mise à jour.
Validation de ligne pour les colonnes GroupBy entièrement couvertes par Treatas
Avant cette mise à jour, dans une fonction SummarizeColumns, si toutes les colonnes GroupBy d’une table spécifique étaient entièrement couvertes par un filtre Treatas unique de cette même table, comme indiqué ci-dessous :
SummarizeColumns(
Geography[Country],
Geography[State],
Treatas(
{("United States", "Alberta")},
Geography[Country],
Geography[State]
)
)
Le résultat de la requête ci-dessus inclurait toutes les lignes spécifiées dans le filtre Treatas, qu’elles soient valides ou non. Par exemple, le résultat serait une table à une seule ligne (« États-Unis », « Alberta »), même si aucune ligne n’est associée à [Country] = « États-Unis » et [State] = « Alberta » n’existait dans la table « Géographie ».
Ce problème était connu et a été résolu par la mise à jour. Après la mise à jour, ces lignes non valides seront filtrées et seules les lignes valides de la table GroupBy seront retournées. Par conséquent, le résultat de la requête ci-dessus serait vide, car il n’existe aucune ligne valide correspondant aux valeurs [Pays] et [État] spécifiées dans la table « Géographie ».
Interdire les keepfilters/overridefilters mixtes sur la même table ou le même cluster
La mise à jour récente a introduit une restriction temporaire qui déclenche un message d’erreur indiquant :
"SummarizeColumns filters with keepfilters behavior and overridefilters behavior are mixed within one cluster, which is not allowed. Consider adding keepfilters() to all filters of summarizecolumns."
Cette erreur se produit lorsque les filtres normaux (qui remplacent les filtres existants) et les filtres avec KeepFilters spécifiés existent dans la même table ou le même cluster. Par exemple :
Evaluate CalculateTable(
SummarizeColumns(
Product[Color],
KeepFilters(
TreatAs(
{( "Washington")}
, Geography[State]
)
),
TreatAs(
{("United States"), ("Canada")}
, Geography[Country]
)
)
,TreatAs({("Alberta")}, Geography[State])
,TreatAs({("Canada")}, Geography[Country])
)
Dans l’expression ci-dessus, il existe deux filtres sur la table « Géographie » : un avec KeepFilters spécifiés et un sans. Ces filtres se chevauchent avec des filtres externes sur différentes colonnes. Actuellement, cette configuration n’est pas autorisée car, en interne, les deux filtres sont regroupés en un seul et le système ne peut pas déterminer le comportement de substitution de filtre correct pour le filtre en cluster dans de tels cas.
Notez que cette restriction est temporaire. Nous développons activement des solutions pour supprimer cette limitation dans les prochaines mises à jour. Si vous rencontrez cette erreur, nous vous conseillons d’ajuster les filtres dans SummarizeColumns en ajoutant ou en supprimant KeepFilters si nécessaire, pour garantir un comportement de substitution cohérent sur chaque table.