تفاوت SUM و SUMX در Power BI چیست؟ آموزش SUM و SUMX با مثال‌های واقعی

یکی از اولین سؤال‌هایی که هنگام یادگیری DAX در Power BI برای بسیاری از کاربران پیش می‌آید این است که SUM و SUMX چه تفاوتی با یکدیگر دارند؟ هر دو برای محاسبه مجموع استفاده می‌شوند، اما زمانی که با داده‌های واقعی کار می‌کنید، تفاوت این دو تابع خیلی زود خودش را نشان می‌دهد.

فرض کنید مدیر فروش از شما می‌خواهد ارزش کل سفارش‌های یک فروشگاه اینترنتی را محاسبه کنید. در جدول فروش، مبلغ نهایی هر سفارش از قبل وجود دارد و فقط باید این مبالغ را با هم جمع کنید. در این حالت SUM انتخاب مناسبی است.

اما چند دقیقه بعد سؤال دیگری مطرح می‌شود:

«اگر مبلغ فروش در جدول ذخیره نشده باشد و برای هر ردیف لازم باشد تعداد کالا را در قیمت واحد ضرب کنیم، چطور؟»

اینجاست که SUMX اهمیت پیدا می‌کند.

در این مقاله با یک مثال واقعی از فروشگاه اینترنتی، تفاوت SUM و SUMX را بررسی می‌کنیم و می‌بینیم چه زمانی باید از هرکدام استفاده کنیم.

 

اگر قصد دارید ساخت داشبورد رو حرفه ای یاد بگیرید کتاب آموزش نرم افزار هوش تجاری Power Bi به شما کمک می کنه میتونیدبا کلیک یا ضربه روی تصویر کتاب اون رو سفارش بدید

SUM در Power BI چیست؟

 

تابع SUM برای جمع کردن مقادیر یک ستون استفاده می‌شود. Syntax این تابع بسیار ساده است:

SUM(<column>)

مثلاً اگر جدولی به نام Orders داشته باشیم و مبلغ نهایی هر سفارش در ستون FinalAmount ذخیره شده باشد، می‌توانیم بنویسیم:

Total Revenue =
SUM(Orders[FinalAmount])

در اینجا Power BI تمام مقادیر موجود در ستون FinalAmount را در Context فعلی جمع می‌کند. مستندات رسمی Microsoft نیز SUM را تابعی برای جمع کردن اعداد یک ستون معرفی می‌کند.

بنابراین اگر داده‌های ما چیزی شبیه این باشند:

OrderID	Customer	FinalAmount
1001	علی رضایی	3,250,000
1002	مریم احمدی	1,870,000
1003	رضا کریمی	5,420,000
1004	سارا محمدی	2,100,000

Measure زیر:

Total Revenue =
SUM(Orders[FinalAmount])

مجموع فروش را برابر با 12,640,000 محاسبه می‌کند.

تا اینجا همه‌چیز ساده است.

اما مسئله زمانی جالب می‌شود که مبلغ نهایی در جدول وجود نداشته باشد.

 

چه زمانی SUM کافی نیست؟

 

فرض کنید یک شرکت تجهیزات اداری، محصولاتش را به‌صورت تعدادی می‌فروشد و جدول فروش فقط اطلاعات زیر را ذخیره می‌کند:

InvoiceNo	Product	Quantity	UnitPrice
5001	صندلی اداری	4	8,500,000
5002	میز کار	2	14,000,000
5003	فایل سه‌کشو	5	4,200,000
5004	صندلی اداری	3	8,500,000

حالا اگر بخواهیم مبلغ هر ردیف را محاسبه کنیم، باید برای هر رکورد این کار را انجام دهیم:

Quantity × UnitPrice

مثلاً برای فاکتور 5001:

4 × 8,500,000 = 34,000,000

برای فاکتور 5002:

2 × 14,000,000 = 28,000,000

و به همین ترتیب برای سایر ردیف‌ها.

اینجا دیگر یک ستون آماده برای SUM کردن نداریم.

 

SUMX در Power BI چیست؟

 

SUMX یک تابع Iterator یا تکرارشونده در DAX است. این تابع یک جدول را دریافت می‌کند، Expression را برای هر ردیف محاسبه می‌کند و در نهایت نتایج را با هم جمع می‌کند.

Syntax:

SUMX(
    <table>,
    <expression>
)

برای مثال بالا می‌توانیم بنویسیم:

Total Revenue =
SUMX(
    Orders,
    Orders[Quantity] * Orders[UnitPrice]
)

اتفاقی که در این Measure رخ می‌دهد بسیار مهم است.

Power BI عملاً برای هر ردیف محاسبه می‌کند:

تعداد × قیمت واحد

و سپس تمام نتایج را جمع می‌کند.

یعنی:

4 × 8,500,000
+
2 × 14,000,000
+
5 × 4,200,000
+
3 × 8,500,000

نتیجه:

113,000,000

این دقیقاً همان جایی است که SUMX نسبت به SUM کاربرد متفاوتی پیدا می‌کند.

 

تفاوت اصلی SUM و SUMX در یک نگاه

 

اگر بخواهیم تفاوت را خیلی ساده بیان کنیم:

 

SUM یک ستون را جمع می‌کند.

 

SUMX یک Expression را برای ردیف‌های جدول محاسبه و سپس نتایج را جمع می‌کند.

 

مثلاً:

Total Cost =
SUM(Orders[Cost])

یعنی یک ستون آماده داریم و فقط می‌خواهیم آن را جمع کنیم.

اما:

Total Cost =
SUMX(
    Orders,
    Orders[Quantity] * Orders[UnitCost]
)

یعنی مبلغ هر ردیف باید هنگام محاسبه ساخته شود.

Microsoft نیز SUMX را به‌عنوان تابعی معرفی می‌کند که Expression را برای هر ردیف ارزیابی کرده و حاصل آن را جمع می‌کند.

 

یک مثال واقعی‌تر؛ محاسبه درآمد فروش کتاب

 

فرض کنید اطلاعات فروش یک انتشارات را در Power BI وارد کرده‌ایم. برای هر ردیف فروش، تعداد نسخه، قیمت پشت جلد و درصد تخفیف ثبت شده است.

ساختار جدول:

Date	Book	Quantity	ListPrice	Discount
1405/01/05	آموزش جامع Excel	3	850,000	10%
1405/01/06	آموزش Power BI	2	1,200,000	15%
1405/01/07	آموزش Word	5	650,000	5%
1405/01/08	Excel پیشرفته	4	920,000	12%

اگر مبلغ فروش هر ردیف از قبل در جدول ذخیره نشده باشد، نمی‌توانیم به‌سادگی از SUM استفاده کنیم.

باید ابتدا مبلغ واقعی فروش هر ردیف را محاسبه کنیم.

فرمول هر ردیف:

Quantity × ListPrice × (1 - Discount)

بنابراین Measure:

Net Revenue =
SUMX(
    BookSales,
    BookSales[Quantity]
        * BookSales[ListPrice]
        * (1 - BookSales[Discount])
)

اینجا SUMX دقیقاً برای همین مسئله ساخته شده است: محاسبه یک Expression برای هر ردیف و سپس جمع کردن نتایج.

 

آیا بهتر نیست ابتدا یک Calculated Column بسازیم؟

 

ممکن است بگویید:

«چرا یک ستون به نام NetAmount ایجاد نکنیم و بعد SUM بزنیم؟»

این هم در بعضی پروژه‌ها کاملاً ممکن است.

مثلاً یک Calculated Column:

Net Amount =
BookSales[Quantity]
    * BookSales[ListPrice]
    * (1 - BookSales[Discount])

و بعد:

Total Revenue =
SUM(BookSales[Net Amount])

اما اینجا باید بدانیم که Calculated Column و Measure یکسان نیستند.

Calculated Column هنگام Refresh مدل محاسبه می‌شود و نتیجه آن در مدل ذخیره می‌شود، در حالی که Measure هنگام اجرای گزارش و متناسب با Context محاسبه می‌شود.

بنابراین انتخاب بین این دو، فقط به «کدام فرمول کوتاه‌تر است؟» مربوط نمی‌شود؛ بلکه به مدل داده و نیاز تحلیلی پروژه بستگی دارد.

 

SUMX فقط برای ضرب دو ستون نیست

 

یکی از برداشت‌های اشتباه رایج این است که SUMX را فقط برای:

Quantity * UnitPrice

به کار ببریم.

در واقع Expression می‌تواند منطق پیچیده‌تری داشته باشد.

مثلاً فرض کنید فروشنده برای بعضی محصولات پاداش دریافت می‌کند.

قانون شرکت این است:

• تا 100 میلیون فروش: 2 درصد پورسانت
• بین 100 تا 300 میلیون: 3 درصد
• بالاتر از 300 میلیون: 5 درصد

اگر بخواهیم پورسانت هر فروش را محاسبه و سپس مجموع پورسانت را به دست آوریم، SUMX می‌تواند بسیار مناسب باشد.

مثلاً:

Total Commission =
SUMX(
    Sales,
    VAR Amount =
        Sales[Quantity] * Sales[UnitPrice]
    VAR Rate =
        SWITCH(
            TRUE(),
            Amount <= 100000000, 0.02,
            Amount <= 300000000, 0.03,
            0.05
        )
    RETURN
        Amount * Rate
)

در اینجا SUMX برای هر ردیف ابتدا مبلغ فروش را محاسبه می‌کند، سپس نرخ پورسانت مناسب را پیدا می‌کند و در نهایت مبلغ پورسانت را به نتیجه کلی اضافه می‌کند.

این نوع مثال‌ها نشان می‌دهند که SUMX صرفاً «SUM پیشرفته‌تر» نیست؛ بلکه یک Iterator است که امکان اجرای منطق ردیفی را فراهم می‌کند.

 

SUMX و FILTER در کنار یکدیگر

 

گاهی لازم است قبل از محاسبه، فقط بخشی از جدول را وارد Expression کنیم.

فرض کنید مدیر فروش می‌خواهد فقط سود سفارش‌هایی را بررسی کند که مبلغ آنها بیشتر از 20 میلیون تومان است.

می‌توانیم بنویسیم:

High Value Profit =
SUMX(
    FILTER(
        Sales,
        Sales[Quantity] * Sales[UnitPrice] > 20000000
    ),
    (Sales[Quantity] * Sales[UnitPrice])
        - Sales[Cost]
)

در اینجا ابتدا FILTER ردیف‌های موردنظر را جدا می‌کند و سپس SUMX روی جدول فیلترشده محاسبه را انجام می‌دهد.

FILTER در DAX یک زیرمجموعه از یک جدول یا Expression جدولی را برمی‌گرداند و می‌تواند در ترکیب با توابع دیگر برای محاسبات پیچیده‌تر استفاده شود.

 

آیا SUMX همیشه بهتر از SUM است؟

 

خیر.

این یکی از مهم‌ترین نکاتی است که هنگام یادگیری DAX باید به آن توجه کنید.

اگر ستون آماده‌ای دارید که فقط باید جمع شود، استفاده از SUM ساده‌تر و مناسب‌تر است:

Total Sales =
SUM(Sales[SalesAmount])

لازم نیست فقط برای اینکه Measure حرفه‌ای‌تر به نظر برسد، SUMX بنویسیم.

اما اگر باید برای هر ردیف Expression محاسبه شود، SUMX ابزار مناسبی است:

Total Sales =
SUMX(
    Sales,
    Sales[Quantity] * Sales[UnitPrice]
)

خود Microsoft نیز اشاره می‌کند که اگر نیازی به محاسبه Expression برای هر ردیف ندارید، از SUM استفاده کنید.

 

یک اشتباه مهم در SUMX

 

فرض کنید ستون زیر را داریم:

Sales[SalesAmount]

و فقط می‌خواهیم مجموع آن را حساب کنیم.

ممکن است کسی بنویسد:

Total Sales =
SUMX(
    Sales,
    Sales[SalesAmount]
)

این کد می‌تواند نتیجه موردنظر را بدهد، اما اگر هدف صرفاً جمع کردن یک ستون است، استفاده از:

Total Sales =
SUM(Sales[SalesAmount])

خواناتر و مستقیم‌تر است.

بنابراین بهتر است SUMX را زمانی به کار ببریم که واقعاً به منطق ردیفی نیاز داریم.

 

SUM یا SUMX؟ یک تصمیم ساده

 

قبل از نوشتن Measure این سؤال را از خودتان بپرسید:

آیا عددی که می‌خواهم جمع کنم از قبل در یک ستون وجود دارد؟

اگر جواب بله است:

SUM(Column)

اگر جواب خیر است و باید برای هر ردیف یک Expression محاسبه شود:

SUMX(Table, Expression)

این قاعده ساده در بسیاری از پروژه‌های Power BI راهگشاست.

 

تفاوت SUM و SUMX از نظر Syntax

 

تابع	Syntax	کاربرد
SUM	SUM(Column)	جمع یک ستون
SUMX	SUMX(Table, Expression)	محاسبه Expression برای هر ردیف و جمع نتایج

جمع‌بندی

 

SUM و SUMX هر دو برای رسیدن به یک مجموع استفاده می‌شوند، اما مسئله‌ای که حل می‌کنند یکسان نیست.

وقتی یک ستون آماده دارید و فقط باید مقادیر آن را جمع کنید، SUM انتخاب طبیعی است:

SUM(Sales[SalesAmount])

اما وقتی عدد نهایی باید برای هر ردیف محاسبه شود، SUMX وارد عمل می‌شود:

SUMX(
    Sales,
    Sales[Quantity] * Sales[UnitPrice]
)

اگر در حال یادگیری DAX هستید، پیشنهاد می‌کنم به‌جای حفظ کردن این دو Syntax، مسئله را از خودتان بپرسید:

«آیا عدد نهایی در جدول وجود دارد یا باید برای هر ردیف آن را بسازم؟»

پاسخ همین سؤال معمولاً مشخص می‌کند که باید SUM بنویسید یا SUMX.

سؤال‌های متداول

 

آیا SUMX جایگزین SUM است؟

خیر. SUM برای جمع یک ستون مناسب است و SUMX زمانی کاربرد دارد که لازم باشد یک Expression برای هر ردیف محاسبه شود.

 

آیا SUMX فقط برای ضرب Quantity در UnitPrice استفاده می‌شود؟

خیر. هر Expression معتبری که بتوان برای ردیف‌های جدول ارزیابی کرد، می‌تواند در SUMX استفاده شود.

 

آیا SUMX همیشه کندتر از SUM است؟

نباید به‌صورت مطلق چنین حکمی داد. SUMX به دلیل ارزیابی Expression برای ردیف‌ها می‌تواند هزینه محاسباتی بیشتری داشته باشد، بنابراین وقتی SUM مسئله را حل می‌کند، معمولاً دلیلی برای استفاده از SUMX وجود ندارد.

 

SUMX در Power BI چیست؟

SUMX یک Iterator در DAX است که Expression را برای هر ردیف یک جدول ارزیابی می‌کند و سپس نتایج را جمع می‌کند.

 

مقالات مرتبط آموزش Power BI و DAX

برای ادامه مسیر یادگیری پیشنهاد می‌کنیم این مقالات را نیز مطالعه کنید:

تفاوت Measure و Calculated Column در Power BI
برای آشنایی با تفاوت دو روش مهم محاسبه در Power BI.

آموزش تابع CALCULATE در Power BI
برای یادگیری تغییر Filter Context و ساخت Measureهای حرفه‌ای.

تفاوت Row Context و Filter Context در DAX چیست؟ آموزش ساده با مثال‌های عملی

آموزش تابع FILTER در Power BI (به زودی)
برای آشنایی با فیلتر کردن جدول‌ها و استفاده از FILTER در DAX.

Context Transition در DAX چیست؟ (به زودی)
موضوع بعدی این مجموعه برای درک ارتباط Row Context و Filter Context.