Thep Excel
RELATEDTABLEคืนตารางฝั่ง Many ที่สัมพันธ์กับแถวปัจจุบัน (One → Many)
RELATEDTABLE ทำ context transition คืนตารางของแถวฝั่ง Many ที่เกี่ยวข้องกับแถวปัจจุบัน โดยใช้ Relationship ในโมเดล เป็นทางลัดของ CALCULATETABLE แต่ Microsoft ไม่แนะนำใช้แล้ว
Syntax & Arguments
| อาร์กิวเมนต์ | ชนิด | คำอธิบาย |
|---|---|---|
| Table | table | ชื่อตารางฝั่ง Many ที่ต้องการคืนแถวที่เกี่ยวข้อง (ต้องมี Relationship กับตารางปัจจุบัน) |
Additional Notes
RELATEDTABLE คืน “ตารางของแถวที่เกี่ยวข้อง” จากตารางฝั่ง Many โดยอาศัย Relationship ในโมเดล ใช้เมื่อคุณอยู่บนตารางฝั่ง One (เช่น Product Category) แล้วต้องการดึงแถวที่เกี่ยวข้องจากตารางฝั่ง Many (เช่น Sales) เพื่อใช้กับ iterator อย่าง SUMX/COUNTROWS
Technical Detail: RELATEDTABLE ทำ “context transition” – เปลี่ยนจาก row context เป็น filter context โดยใช้ Relationship เป็นตัวกำหนดตัวกรอง ฟังก์ชันนี้เป็นทางลัดของ CALCULATETABLE(table) แบบไม่มีเงื่อนไขเพิ่มเติม
หลังสำคัญ: Microsoft ไม่แนะนำใช้ RELATEDTABLE แล้ว แนะนำให้ใช้ CALCULATETABLE แทน เพราะมีความยืดหยุ่นกว่า สามารถเพิ่มเงื่อนไขตัวกรองได้ และสื่อความหมายชัดเจนกว่า ถ้าเห็น RELATEDTABLE ในโค้ดเก่า ให้พิจารณาแปลงเป็น CALCULATETABLE
ส่วนตัวผมว่า RELATEDTABLE ยังมีประโยชน์ในการอ่านและทำความเข้าใจ context transition ของ DAX แต่ไม่ควรเขียนโค้ดใหม่ด้วยมันแล้ว ใช้ CALCULATETABLE นั่นแหละถ้าจะเก่ง DAX ต้องเข้าใจ context transition ก่อนเพราะมันคือ “ปัญญา” ของ DAX เลยก็ว่าได้ 😎
How it works
นับจำนวนรายการที่เกี่ยวข้องต่อ 1 รายการในตารางฝั่ง One
เช่นจำนวนธุรกรรมต่อหนึ่งลูกค้า
รวมยอดจากตารางฝั่ง Many ต่อแถวในฝั่ง One
เช่นรวมยอดขายต่อหนึ่งลูกค้าโดยใช้ SUMX บน RELATEDTABLE(Sales)
Examples
ตัวอย่างที่ 1: จำนวนรายการขายต่อหนึ่งลูกค้าจำนวนธุรกรรม/ลูกค้า = AVERAGEX( Customer, COUNTROWS(RELATEDTABLE(Sales)) )
AVERAGEX วนลูกค้าแต่ละราย แล้วใช้ RELATEDTABLE(Sales) คืนแถว Sales ที่เกี่ยวข้อง จากนั้น COUNTROWS เพื่อนับจำนวน
ตัวอย่างที่ 2: รวมยอดขายต่อหมวดหมู่สินค้าTotal Sales by Category = SUMX( RELATEDTABLE(InternetSales_USD), InternetSales_USD[SalesAmount_USD] )
ใช้ SUMX วนแถวใน InternetSales_USD ที่เกี่ยวข้องกับ ProductCategory แล้วรวม SalesAmount_USD
ตัวอย่างที่ 3: RELATEDTABLE vs CALCULATETABLE# RELATEDTABLE – ใช้ Relationship เพียงอย่างเดียว Total = SUMX(RELATEDTABLE(Sales), Sales[Amount]) # CALCULATETABLE – ยืดหยุ่นกว่า เพิ่มเงื่อนไขได้ Total = SUMX…
RELATEDTABLE ใช้ Relationship ในโมเดลเท่านั้น ไม่สามารถเพิ่มเงื่อนไขอื่น แต่ CALCULATETABLE ทำได้ ดังนั้น CALCULATETABLE เป็นทางเลือกที่ดีกว่า
FAQs
ทำไม Microsoft ไม่แนะนำใช้ RELATEDTABLE?+
RELATEDTABLE เป็นฟังก์ชันเก่าและเป็นทางลัดของ CALCULATETABLE ที่ไม่มีความยืดหยุ่น ใช้ CALCULATETABLE แทนจะเขียนได้ชัดเจนกว่าและสามารถเพิ่มเงื่อนไขเพิ่มเติมได้ Microsoft แนะนำให้ใช้ CALCULATETABLE ในแทนใหม่ทั้งหมด
RELATEDTABLE ต่างจาก RELATED อย่างไร?+
RELATED คืนค่าเดี่ยวจากตารางฝั่ง One (Many → One) ส่วน RELATEDTABLE คืน "ตารางของแถว" จากตารางฝั่ง Many (One → Many)
ใช้ RELATEDTABLE ใน Measure ได้ไหม?+
ทำได้เมื่อมี row context ที่เหมาะสม (เช่นอยู่ภายใน iterator อย่าง AVERAGEX/SUMX) เพราะ RELATEDTABLE อาศัย context transition จากแถวปัจจุบัน
RELATEDTABLE vs CALCULATETABLE – ควรใช้อะไร?+
ให้ใช้ CALCULATETABLE เสมอในโค้ดใหม่ RELATEDTABLE เป็นเพียงทางลัดแบบ CALCULATETABLE() โดยไม่มีเงื่อนไขเพิ่มเติม ถ้าต้องการความชัดเจนและความยืดหยุ่น ใช้ CALCULATETABLE ทั้งหมด
Resources & Related
ฟังก์ชันที่ผู้เขียนโยงไว้กับ RELATEDTABLE จัดกลุ่มตามหมวด · ชี้ที่ชื่อใดชื่อหนึ่ง แล้วฟังก์ชันที่ใช้คู่กันจะมีจุดทอง
CROSSFILTER กำหนดทิศทางการกรองข้ามความสัมพันธ์ระหว่าง 2 คอลัมน์ชั่วคราว (มักใช้ใน CALCULATE) เพื่อควบคุมการไหลของตัวกรองหรือปิดการกรองข้ามในบางการคำนวณ
RELATED คืนค่า scalar value (ค่าเดี่ยว) จากคอลัมน์ในตารางที่มีความสัมพันธ์แบบ many-to-one โดยอาศัย relationship ที่กำหนดไว้ในโมเดล ฟังก์ชันนี้ต้องการ row context และสามารถ traverse relationship chain ข้ามหลายขั้นได้ตราบใดที่ทุก relationship อยู่ในทิศทางเดียวกัน
CALCULATETABLE evaluate table expression ภายใต้ filter context ที่ถูกปรับเปลี่ยน แล้วคืนค่าเป็น table (ตาราง) ซึ่งแตกต่างจาก CALCULATE ที่คืนค่าเป็น scalar value รองรับ filter arguments 3 รูปแบบ: Boolean expression, table expression, และ filter modifier functions (REMOVEFILTERS, ALL, KEEPFILTERS, USERELATIONSHIP, CROSSFILTER) มีพฤติกรรมเหมือน CALCULATE ในทุกแง่มุมของการจัดการ filter context รวมถึง context transition แต่เหมาะสำหรับการสร้าง intermediate table ที่ถูกกรองแล้วส่งต่อให้ iterator functions หรือใช้ใน calculated table มักมี performance ดีกว่า FILTER ใน simple filtering scenarios เพราะ DAX engine สามารถทำ cardinality estimation และ optimization ได้ดีกว่า
ยังไม่มีบทความที่เกี่ยวข้องกับฟังก์ชันนี้
Comments
อีเมลของคุณจะไม่ถูกเผยแพร่