تفاوت Measure و Calculated Column در Power BI چیست؟ آموزش کامل با مثال عملی

یکی از اولین چیزهایی که بعد از شروع یادگیری DAX در Power BI ذهن کاربران را درگیر می‌کند، تفاوت Measure و Calculated Column است.

هر دو با DAX ساخته می‌شوند، هر دو برای محاسبه در Power BI کاربرد دارند و حتی ممکن است در نگاه اول فرمولشان شبیه هم باشد. اما این دو دقیقاً برای یک کار ساخته نشده‌اند.

فرض کنید در یک گزارش فروش، ستون‌های Quantity و UnitPrice را دارید و می‌خواهید مبلغ هر سفارش را به دست بیاورید.

از طرف دیگر مدیر فروش از شما می‌خواهد:

«حالا مجموع فروش را برای هر ماه، هر شهر و هر فروشنده هم محاسبه کن.»

این دو درخواست ظاهراً به هم نزدیک هستند، اما راه‌حلشان می‌تواند کاملاً متفاوت باشد.

برای محاسبه مبلغ هر ردیف، Calculated Column می‌تواند انتخاب مناسبی باشد.

برای محاسبه مجموع فروش متناسب با فیلترهای گزارش، معمولاً Measure انتخاب بهتری است.

اگر این تفاوت را درست متوجه نشوید، در پروژه‌های Power BI خیلی زود با Measureهایی مواجه می‌شوید که عددشان درست نیست، مدل داده بیش از حد بزرگ می‌شود یا نمی‌توانید از یک محاسبه در Slicer و Filter استفاده کنید.

در این مقاله قرار است دقیقاً همین تفاوت را با مثال‌های واقعی بررسی کنیم.

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

 

Measure و Calculated Column در یک جمله چه تفاوتی دارند؟

 

اگر بخواهیم کل بحث را خیلی ساده کنیم:

Calculated Column برای محاسبه و تولید یک مقدار برای هر ردیف جدول است.

Measure برای محاسبه یک نتیجه پویا بر اساس Context فعلی گزارش است.

Microsoft نیز Calculated Column را محاسبه‌ای می‌داند که Expression را ردیف‌به‌ردیف ارزیابی می‌کند و نتیجه آن در مدل ذخیره می‌شود؛ در مقابل، Measure هنگام نیاز محاسبه می‌شود و به انتخاب‌های کاربر در گزارش پاسخ می‌دهد.

همین تفاوت، پایه اصلی انتخاب بین این دو است.

 

Calculated Column چیست؟

 

Calculated Column ستونی است که خودمان با استفاده از DAX به یکی از جدول‌های مدل اضافه می‌کنیم.

فرض کنید جدول فروش چنین ساختاری دارد:

InvoiceNo	Product	Quantity	UnitPrice
1001	لپ‌تاپ	2	45,000,000
1002	مانیتور	3	12,000,000
1003	کیبورد	5	2,500,000
1004	لپ‌تاپ	1	45,000,000

می‌خواهیم برای هر فاکتور مبلغ فروش را محاسبه کنیم.

در Power BI یک Calculated Column ایجاد می‌کنیم:

Sales Amount =
Sales[Quantity] * Sales[UnitPrice]

حالا جدول ما یک ستون جدید خواهد داشت:

InvoiceNo	Product	Quantity	UnitPrice	Sales Amount
1001	لپ‌تاپ	2	45,000,000	90,000,000
1002	مانیتور	3	12,000,000	36,000,000
1003	کیبورد	5	2,500,000	12,500,000
1004	لپ‌تاپ	1	45,000,000	45,000,000

اینجا Calculated Column کاملاً منطقی است، چون ما برای هر ردیف یک مقدار مستقل ساخته‌ایم.

Microsoft هم اشاره می‌کند که Calculated Column با DAX بر اساس داده‌های موجود در مدل ساخته می‌شود و Expression آن برای هر ردیف ارزیابی می‌شود.

 

Measure چیست؟

 

Measure نیز با DAX ساخته می‌شود، اما فلسفه آن متفاوت است.

فرض کنید همان جدول فروش را داریم و حالا می‌خواهیم مجموع فروش را نمایش دهیم.

می‌توانیم Measure زیر را ایجاد کنیم:

Total Sales =
SUM(Sales[Sales Amount])

حالا اگر این Measure را روی یک Card قرار دهیم، مجموع فروش را می‌بینیم.

اما نکته مهم اینجاست:

اگر کاربر در گزارش فقط سال ۱۴۰۵ را انتخاب کند، Measure دوباره در Context جدید محاسبه می‌شود.

اگر شهر تهران را انتخاب کند، نتیجه تغییر می‌کند.

اگر فقط محصولات لپ‌تاپ را انتخاب کند، نتیجه دوباره تغییر می‌کند.

به همین دلیل Measure برای تحلیل‌های پویا بسیار مناسب است.

Microsoft تصریح می‌کند که Measureها در صورت نیاز محاسبه می‌شوند و نتیجه آنها به انتخاب‌ها و تعاملات کاربر با گزارش پاسخ می‌دهد.

 

تفاوت اصلی را با یک مثال ببینیم

 

این قسمت شاید مهم‌ترین بخش مقاله باشد.

فرض کنید جدول زیر را داریم:

Product	Quantity	UnitPrice
لپ‌تاپ	2	45M
مانیتور	3	12M
کیبورد	5	2.5M

اگر بنویسیم:

Sales Amount =
Sales[Quantity] * Sales[UnitPrice]

داریم درباره هر ردیف صحبت می‌کنیم.

اما اگر بنویسیم:

Total Sales =
SUM(Sales[Sales Amount])

داریم درباره کل فروش در Context فعلی صحبت می‌کنیم.

پس:

Calculated Column
        ↓
یک مقدار برای هر ردیف

Measure
        ↓
یک نتیجه برای Context فعلی گزارش

این تفاوت ساده، بسیاری از ابهامات اولیه DAX را برطرف می‌کند.

 

چرا Calculated Column به فیلترهای گزارش واکنش نشان نمی‌دهد؟

 

فرض کنید Calculated Column زیر را ساخته‌ایم:

Profit =
Sales[Sales Amount] - Sales[Cost]

برای هر ردیف، یک مقدار Profit محاسبه شده است.

اگر کاربر در گزارش سال ۱۴۰۵ را انتخاب کند، مقدار Profit هر ردیف دوباره به خاطر این انتخاب تغییر نمی‌کند.

اگر کاربر یک شهر خاص را انتخاب کند، فرمول Calculated Column مجدداً برای آن شهر محاسبه نمی‌شود.

مقدار ستون در زمان Refresh داده محاسبه شده و در مدل ذخیره می‌شود. بنابراین تعامل کاربر با گزارش، مقدار ذخیره‌شده در آن ستون را تغییر نمی‌دهد.

البته Visual می‌تواند فقط ردیف‌های مربوط به فیلتر را نمایش دهد؛ این موضوع با تغییر مقدار خود Calculated Column فرق دارد.

 

چرا Measure پویاست؟

 

حالا همان محاسبه را به شکل Measure در نظر بگیریم:

Total Profit =
SUM(Sales[Profit])

فرض کنید در کل شرکت:

Total Profit = 8.4 Billion

کاربر استان تهران را انتخاب می‌کند:

Total Profit = 2.1 Billion

کاربر فقط گروه «لوازم اداری» را انتخاب می‌کند:

Total Profit = 1.7 Billion

کاربر سال ۱۴۰۵ را انتخاب می‌کند:

Total Profit = 4.9 Billion

Measure به Context گزارش واکنش نشان می‌دهد.

همین ویژگی باعث شده Measureها برای KPIها، داشبوردهای مدیریتی و تحلیل‌های تعاملی بسیار مهم باشند.

 

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

 

فرض کنید فروشگاه برای هر سفارش درصد تخفیف متفاوتی دارد.

جدول:

OrderID	Product	Quantity	UnitPrice	Discount
501	صندلی	4	8M	10%
502	میز	2	15M	5%
503	فایل	3	6M	15%

می‌خواهیم مبلغ نهایی هر سفارش را محاسبه کنیم.

فرمول:

Quantity × UnitPrice × (1 - Discount)

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

بنابراین یک Calculated Column می‌تواند چنین باشد:

Net Amount =
Sales[Quantity]
    * Sales[UnitPrice]
    * (1 - Sales[Discount])

اما بعد مدیر می‌پرسد:

«مجموع مبلغ نهایی سفارش‌ها چقدر شده؟»

اینجا Measure مناسب است:

Total Net Sales =
SUM(Sales[Net Amount])

این مثال به‌خوبی نشان می‌دهد که این دو رقیب هم نیستند؛ حتی در یک مدل می‌توانند در کنار یکدیگر استفاده شوند.

 

آیا می‌توان این محاسبه را فقط با Measure انجام داد؟

 

بله، در بسیاری از سناریوها می‌توان مبلغ فروش را مستقیماً با Measure محاسبه کرد.

مثلاً:

Total Net Sales =
SUMX(
    Sales,
    Sales[Quantity]
        * Sales[UnitPrice]
        * (1 - Sales[Discount])
)

در این حالت دیگر نیازی به Calculated Column برای Net Amount نداریم.

اینجا یکی از نکات مهم طراحی مدل مطرح می‌شود:

هر محاسبه ردیفی الزاماً به Calculated Column نیاز ندارد.

اگر هدف شما فقط رسیدن به یک شاخص تحلیلی است، ممکن است بتوانید آن را به‌صورت Measure و با Iteratorهایی مانند SUMX محاسبه کنید.

در مقاله «تفاوت SUM و SUMX در Power BI» دقیقاً همین موضوع را با مثال‌های مختلف بررسی کرده‌ایم.

 

پس چه زمانی Calculated Column بسازیم؟

 

Calculated Column زمانی انتخاب مناسبی است که واقعاً به یک ویژگی یا مقدار در سطح ردیف نیاز داشته باشیم.

مثلاً:

دسته‌بندی مشتری

Customer Segment =
IF(
    Customers[TotalPurchase] >= 100000000,
    "مشتری ویژه",
    "مشتری عادی"
)

حالا می‌توانیم Customer Segment را در Slicer قرار دهیم.

کاربر می‌تواند بین:

• مشتری ویژه
• مشتری عادی

انتخاب کند.

این دقیقاً یکی از مواردی است که Calculated Column کاربرد خوبی دارد.

Microsoft نیز اشاره می‌کند که Calculated Column را می‌توان در Slicer، Filter و همچنین Rows و Columns ویژوال‌ها استفاده کرد.

 

یک مثال دیگر؛ گروه‌بندی سنی

 

فرض کنید جدول مشتریان شامل سن است.

می‌خواهیم مشتریان را در سه گروه قرار دهیم:

Age Group =
SWITCH(
    TRUE(),
    Customers[Age] < 25, "زیر 25 سال",
    Customers[Age] < 40, "25 تا 39 سال",
    "40 سال به بالا"
)

حالا می‌توانیم این ستون را در Slicer قرار دهیم و گزارش را بر اساس گروه سنی فیلتر کنیم.

این یک کاربرد کاملاً متفاوت از Measure است.

 

چرا برای این کار Measure مناسب نیست؟

 

چون Measure اساساً برای تولید یک مقدار تحلیلی در زمان اجرای Visual طراحی شده است و استفاده معمول آن به‌عنوان یک فیلد دسته‌بندی‌شده در Slicer یا Rows/Columns نیست.

Microsoft نیز در مقایسه رسمی Calculation Options توضیح می‌دهد که Calculated Column را می‌توان در Slicer، Filter، Rows و Columns استفاده کرد، در حالی که Measure برای مقدار Visual و فیلتر سطح Visual استفاده می‌شود.

بنابراین اگر چیزی قرار است نقش یک ویژگی قابل دسته‌بندی را بازی کند، Calculated Column می‌تواند انتخاب مناسبی باشد.

 

چه زمانی Measure بسازیم؟

 

اگر سؤال شما چیزی شبیه این است:

• فروش کل چقدر است؟
• سود چقدر است؟
• میانگین فروش چقدر است؟
• تعداد مشتریان فعال چقدر است؟
• سهم هر محصول از فروش چقدر است؟
• فروش امسال نسبت به سال قبل چقدر رشد کرده؟
• میانگین مبلغ سفارش چقدر است؟

احتمال بسیار زیادی وجود دارد که به Measure نیاز داشته باشید.

مثلاً:

Total Sales =
SUM(Sales[Sales Amount])

یا:

Average Order Value =
AVERAGE(Sales[Sales Amount])

یا:

Total Orders =
DISTINCTCOUNT(Sales[OrderID])

اینها شاخص‌هایی هستند که قرار است با Context گزارش تغییر کنند.

 

یک مثال مهم؛ فروش سرپرست فروش

 

فرض کنید جدول فروش شامل فروشندگان مختلف است.

مدیر می‌خواهد در داشبورد یک نمودار داشته باشد که فروش هر فروشنده را نمایش دهد.

Measure:

Total Sales =
SUM(Sales[Sales Amount])

اگر Salesperson را روی محور نمودار قرار دهیم، Power BI همین Measure را برای هر فروشنده در Context مربوط به همان فروشنده محاسبه می‌کند.

برای مثال:

فروشنده	فروش
احمدی	1.8 میلیارد
کریمی	1.4 میلیارد
رضایی	2.2 میلیارد
محمدی	1.1 میلیارد

نکته جالب این است که ما برای هر فروشنده Measure جداگانه نساخته‌ایم.

فقط یک Measure نوشته‌ایم:

Total Sales =
SUM(Sales[Sales Amount])

این قدرت اصلی Measure است.

 

اگر بخواهیم فروش هر فروشنده را Calculated Column کنیم چه می‌شود؟

 

این سؤال کمی گمراه‌کننده است.

فروش هر فروشنده یک ویژگی ردیف نیست.

هر تراکنش یک مبلغ دارد و فروشنده مشخص است؛ اما «فروش کل احمدی» نتیجه تجمیع چندین ردیف است.

بنابراین بهتر است فروش کل فروشنده را به‌عنوان Measure محاسبه کنیم، نه اینکه برای هر ردیف یک مقدار تکراری از فروش کل فروشنده ذخیره کنیم.

این همان نقطه‌ای است که تشخیص تفاوت Row-Level Calculation و Aggregation اهمیت پیدا می‌کند.

 

تفاوت Measure و Calculated Column از نظر زمان محاسبه

 

این موضوع از نظر عملکرد و طراحی مدل هم اهمیت دارد.

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

Measure در زمان نیاز محاسبه می‌شود و نتیجه آن به Context گزارش وابسته است. Microsoft این تفاوت را در جدول مقایسه Calculation Options نیز مشخص کرده است.

بنابراین اگر یک جدول چند میلیون ردیف داشته باشد، اضافه کردن Calculated Columnهای متعدد می‌تواند حجم مدل را افزایش دهد.

به همین دلیل نباید هر محاسبه‌ای را فقط به این دلیل که «فرمولش ساده است» به Calculated Column تبدیل کنیم.

 

آیا Calculated Column همیشه بد است؟

 

خیر؛ اصلاً.

این یکی از اشتباهات رایج در آموزش Power BI است که گفته شود:

«هیچ‌وقت Calculated Column استفاده نکنید و همیشه Measure بسازید.»

چنین قانون مطلقی وجود ندارد.

Calculated Column در بسیاری از سناریوها کاملاً ضروری و منطقی است.

مثلاً:

گروه مشتری
نوع محصول
رده سنی
کد ترکیبی
پرچم وضعیت
طبقه‌بندی سفارش

اگر این مقادیر باید به‌عنوان ویژگی هر ردیف یا فیلد دسته‌بندی در گزارش استفاده شوند، Calculated Column می‌تواند انتخاب مناسبی باشد.

 

یک مثال کاربردی؛ وضعیت سفارش

 

فرض کنید سفارش‌ها دارای تعداد روز تأخیر هستند.

می‌خواهیم هر سفارش را در یکی از دو گروه قرار دهیم:

Delivery Status =
IF(
    Orders[DelayDays] > 3,
    "تحویل با تأخیر",
    "تحویل به‌موقع"
)

حالا می‌توانیم Delivery Status را در Slicer قرار دهیم و کاربران گزارش را بر اساس وضعیت تحویل فیلتر کنند.

اینجا Calculated Column انتخاب طبیعی‌تری است.

 

یک مثال برای Measure؛ نرخ تحویل به‌موقع

 

حالا سؤال مدیر تغییر می‌کند:

«چند درصد سفارش‌ها به‌موقع تحویل شده‌اند؟»

این دیگر یک ویژگی ردیف نیست؛ یک شاخص تحلیلی است.

می‌توانیم Measure ایجاد کنیم:

On Time Orders =
CALCULATE(
    DISTINCTCOUNT(Orders[OrderID]),
    Orders[Delivery Status] = "تحویل به‌موقع"
)

و سپس:

On Time Delivery % =
DIVIDE(
    [On Time Orders],
    DISTINCTCOUNT(Orders[OrderID])
)

حالا اگر کاربر ماه، شهر یا نوع محصول را تغییر دهد، نرخ تحویل نیز متناسب با Context جدید تغییر می‌کند.

این یک نمونه خوب از همکاری Calculated Column و Measure در یک گزارش واقعی است.

 

Row Context و Filter Context چه نقشی دارند؟

 

برای اینکه تفاوت Measure و Calculated Column را عمیق‌تر بفهمیم، باید دو مفهوم مهم DAX را بشناسیم:

Row Context

و

Filter Context

Calculated Column ذاتاً با محاسبات ردیفی سروکار دارد.

مثلاً:

Profit =
Sales[Sales Amount] - Sales[Cost]

برای هر ردیف، مقدار مربوط به همان ردیف در اختیار فرمول است.

اما Measure معمولاً در Filter Context ارزیابی می‌شود.

مثلاً:

Total Sales =
SUM(Sales[Sales Amount])

اگر Visual بر اساس شهر، ماه یا محصول فیلتر شده باشد، Measure در Context مربوط به همان فیلتر محاسبه می‌شود.

به همین دلیل یادگیری این دو Context، قدم بعدی مهم برای ورود به DAX حرفه‌ای است.

 

Measure یا Calculated Column؟ این جدول را به خاطر بسپارید

 

ویژگی	Calculated Column	Measure
زبان	DAX	DAX
سطح محاسبه	ردیف	Context گزارش
زمان محاسبه	Refresh	هنگام نیاز
نتیجه	در مدل ذخیره می‌شود	به‌صورت پویا محاسبه می‌شود
واکنش مستقیم به Slicer	خیر	بله
استفاده در Slicer	بله	به‌صورت معمول خیر
استفاده برای دسته‌بندی	مناسب	مناسب نیست
KPI و شاخص مدیریتی	معمولاً انتخاب اول نیست	بسیار مناسب
افزایش حجم مدل	بله، می‌تواند افزایش دهد	نتیجه Measure ذخیره نمی‌شود
مناسب برای محاسبات تجمیعی	معمولاً نه	بله

این تفاوت‌ها مطابق مقایسه رسمی Microsoft بین Calculation Options در Power BI است.

 

یک قانون ساده برای انتخاب

 

قبل از ساختن DAX، سؤال خودتان را این‌طور مطرح کنید:

آیا می‌خواهم برای هر ردیف یک مقدار جدید داشته باشم؟

اگر بله، احتمالاً Calculated Column گزینه مناسبی است.

مثلاً:

Profit =
Sales[Sales Amount] - Sales[Cost]

اما اگر سؤال شما این است:

«در شرایط فعلی گزارش، نتیجه این شاخص چقدر است؟»

احتمالاً به Measure نیاز دارید.

مثلاً:

Total Profit =
SUM(Sales[Profit])

یا:

Profit Margin =
DIVIDE(
    [Total Profit],
    [Total Sales]
)

یک اشتباه رایج؛ تبدیل همه چیز به Calculated Column

 

فرض کنید کاربر تازه‌کار برای هر محاسبه‌ای یک ستون ایجاد می‌کند:

Sales Amount
Profit
Profit Margin
Total Sales
Average Sales
Sales Share
Rank

اگر همه اینها به شکل Column ساخته شوند، مدل می‌تواند به‌مرور بی‌دلیل بزرگ و پیچیده شود.

در حالی که بسیاری از موارد بالا ماهیت Measure دارند.

به‌خصوص مواردی مانند:

Total Sales
Average Sales
Profit Margin
Sales Share
Growth %

معمولاً شاخص‌های تحلیلی هستند و باید بررسی کنیم که آیا بهتر است به شکل Measure پیاده‌سازی شوند.

Microsoft نیز در توضیح Calculated Column اشاره می‌کند که چون نتایج ستون در مدل ذخیره می‌شوند، Calculated Columnها زمان Refresh و اندازه مدل را تحت تأثیر قرار می‌دهند.

 

یک اشتباه دیگر؛ ساخت Measure برای دسته‌بندی

 

حالت برعکس هم وجود دارد.

فرض کنید می‌خواهید مشتریان را به گروه‌های:

طلایی
نقره‌ای
برنزی

تقسیم کنید و این گروه را در Slicer قرار دهید.

در چنین شرایطی، ساختن یک Measure معمولاً انتخاب مناسبی نیست.

شما به یک فیلد دسته‌بندی نیاز دارید که بتواند در Slicer و Filter مورد استفاده قرار بگیرد.

اینجا Calculated Column یا حتی بهتر از آن، در بسیاری از پروژه‌ها، ایجاد این ویژگی در Power Query یا منبع داده می‌تواند منطقی باشد.

 

Calculated Column یا Power Query؟

 

یک نکته مهم دیگر هم وجود دارد.

Calculated Column تنها راه ساخت ستون محاسباتی در Power BI نیست.

می‌توانیم بعضی محاسبات را در Power Query با زبان M انجام دهیم.

بنابراین هنگام طراحی مدل، گاهی سه انتخاب داریم:

منبع داده → Power Query → Calculated Column

و برای محاسبات تحلیلی:

Measure

Microsoft نیز Power BI را دارای چند گزینه برای ایجاد Calculation معرفی می‌کند و بین Custom Column در Power Query، Calculated Column در DAX و Measure تفاوت قائل می‌شود.

قاعده عملی این است که اگر چیزی ماهیت تبدیل و آماده‌سازی داده دارد، بررسی Power Query ارزشمند است؛ اگر ویژگی باید در مدل وجود داشته باشد، Calculated Column می‌تواند مطرح باشد؛ و اگر شاخصی باید با Context گزارش تغییر کند، Measure معمولاً انتخاب اصلی است.

آیا Measure بهتر از Calculated Column است؟

 

نه.

این سؤال اساساً با عبارت «بهتر» قابل پاسخ نیست.

این دو ابزار برای دو مسئله متفاوت ساخته شده‌اند.

مثل این است که بپرسیم:

«پیچ‌گوشتی بهتر است یا آچار؟»

باید اول ببینیم قرار است چه کاری انجام دهیم.

اگر هدف شما ساخت یک ویژگی برای هر سفارش باشد، Calculated Column می‌تواند مناسب باشد.

اگر هدف محاسبه KPI پویا باشد، Measure معمولاً انتخاب بهتری است.

یک سناریوی کامل از ابتدا تا انتها

 

فرض کنید شرکت یک سامانه فروش دارد و داده‌ها به شکل زیر وارد Power BI شده‌اند:

OrderID	City	Product	Quantity	Price	Cost	DelayDays
1001	تهران	لپ‌تاپ	2	45M	38M	1
1002	مشهد	مانیتور	3	12M	9M	5
1003	تهران	پرینتر	2	18M	14M	0
1004	شیراز	لپ‌تاپ	1	45M	38M	4

مرحله اول: مبلغ هر سفارش

Calculated Column:

Sales Amount =
Sales[Quantity] * Sales[Price]

مرحله دوم: سود هر سفارش

Calculated Column:

Profit =
Sales[Sales Amount] - (Sales[Quantity] * Sales[Cost])

مرحله سوم: وضعیت تحویل

Calculated Column:

Delivery Status =
IF(
    Sales[DelayDays] > 3,
    "با تأخیر",
    "به‌موقع"
)

مرحله چهارم: فروش کل

Measure:

Total Sales =
SUM(Sales[Sales Amount])

مرحله پنجم: سود کل

Measure:

Total Profit =
SUM(Sales[Profit])

مرحله ششم: حاشیه سود

Measure:

Profit Margin =
DIVIDE(
    [Total Profit],
    [Total Sales]
)

مرحله هفتم: تعداد سفارش‌های با تأخیر

Measure:

Delayed Orders =
CALCULATE(
    DISTINCTCOUNT(Sales[OrderID]),
    Sales[Delivery Status] = "با تأخیر"
)

اینجا دقیقاً می‌بینیم که Measure و Calculated Column چگونه می‌توانند کنار هم یک مدل تحلیلی واقعی بسازند.

اگر فقط یک نکته از این مقاله یادتان بماند

فرمول را قبل از اینکه بنویسید، نوع سؤال را مشخص کنید.

اگر سؤال شما این است:

«برای این ردیف چه مقداری باید محاسبه شود؟»

به Calculated Column فکر کنید.

اگر سؤال این است:

«با توجه به انتخاب‌های فعلی گزارش، مقدار این شاخص چقدر است؟»

به Measure فکر کنید.

این دو سؤال ساده، در بسیاری از مواقع انتخاب شما را مشخص می‌کنند.

تمرین عملی

برای تمرین، یک جدول فروش با ستون‌های زیر ایجاد کنید:

OrderID
Date
City
Product
Quantity
UnitPrice
Cost
Discount
DelayDays

حالا خودتان تصمیم بگیرید کدام موارد باید Column باشند و کدام Measure:

تمرین ۱

مبلغ خالص هر سفارش بعد از تخفیف.

تمرین ۲

مجموع فروش.

تمرین ۳

سود هر سفارش.

تمرین ۴

حاشیه سود کل.

تمرین ۵

گروه‌بندی سفارش‌ها به «به‌موقع» و «با تأخیر».

تمرین ۶

درصد سفارش‌های تحویل‌شده به‌موقع.

تمرین ۷

فروش هر شهر.

نکته مهم تمرین این است که فقط فرمول را ننویسید؛ قبل از آن مشخص کنید چرا Column یا Measure را انتخاب کرده‌اید.

سؤالات متداول

تفاوت Measure و Calculated Column در Power BI چیست؟

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

آیا Measure با فیلترها تغییر می‌کند؟

بله. Measureها به Context گزارش پاسخ می‌دهند؛ بنابراین انتخاب‌های کاربر در Slicer، Filter و سایر بخش‌های گزارش می‌تواند نتیجه Measure را تغییر دهد.

آیا Calculated Column با تغییر Slicer تغییر می‌کند؟

خود مقدار Calculated Column با تعامل کاربر با گزارش تغییر نمی‌کند. این مقدار هنگام Refresh محاسبه و در مدل ذخیره می‌شود. البته Visual می‌تواند ردیف‌های مربوط به فیلتر را نمایش دهد.

برای محاسبه فروش کل Measure بهتر است یا Calculated Column؟

اگر مبلغ فروش در سطح ردیف وجود دارد، برای فروش کل معمولاً Measure انتخاب مناسب‌تری است:

Total Sales =
SUM(Sales[Sales Amount])

آیا می‌توان Calculated Column را در Slicer استفاده کرد؟

بله. یکی از کاربردهای مهم Calculated Column ایجاد ویژگی‌های دسته‌بندی‌شده‌ای است که بتوان آنها را در Slicer یا Filter استفاده کرد.

آیا Measure حجم فایل Power BI را زیاد می‌کند؟

نتیجه Measure مانند Calculated Column برای هر ردیف در مدل ذخیره نمی‌شود؛ Measure در زمان نیاز محاسبه می‌شود. در مقابل، Calculated Column نتیجه خود را در مدل ذخیره می‌کند و می‌تواند اندازه مدل را افزایش دهد.

آیا همیشه باید از Measure استفاده کنیم؟

خیر. Calculated Column برای بسیاری از محاسبات ردیفی و ویژگی‌های دسته‌بندی بسیار کاربردی است. مسئله اصلی این است که ابزار مناسب را بر اساس نوع محاسبه انتخاب کنیم.

جمع‌بندی

 

تفاوت Measure و Calculated Column یکی از مفاهیم پایه‌ای اما بسیار مهم در Power BI است.

اگر قرار است برای هر ردیف یک مقدار جدید ایجاد کنید، Calculated Column می‌تواند انتخاب مناسبی باشد:

Profit =
Sales[Sales Amount] - Sales[Cost]

اما اگر قرار است یک شاخص پویا بر اساس Context گزارش محاسبه کنید، معمولاً Measure انتخاب مناسب‌تری است:

Total Profit =
SUM(Sales[Profit])

Calculated Column می‌تواند برای مواردی مانند:

• گروه‌بندی مشتریان
• دسته‌بندی محصولات
• وضعیت سفارش
• محاسبات ردیفی
• ایجاد ویژگی‌های قابل استفاده در Slicer

مناسب باشد.

Measure نیز برای مواردی مانند:

• فروش کل
• سود
• میانگین
• تعداد
• درصد
• رشد فروش
• KPI
• سهم از کل

کاربرد بسیار زیادی دارد.

مهم‌تر از حفظ کردن تفاوت این دو، این است که هنگام طراحی یک Measure یا Column ابتدا از خودتان بپرسید:

«این مقدار متعلق به هر ردیف است یا نتیجه‌ای است که باید بر اساس شرایط فعلی گزارش محاسبه شود؟»

اگر پاسخ این سؤال را درست بدهید، در بسیاری از مواقع انتخاب بین Measure و Calculated Column دیگر سخت نخواهد بود.

 

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

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

تفاوت SUM و SUMX در Power BI
برای درک بهتر Iteratorها و محاسبات ردیف‌به‌ردیف.

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

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

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

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