پاور BI ڈیٹا ماڈلنگ: بزنس انٹیلی جنس کے لیے اسٹار اسکیما ڈیزائن

ڈیٹا ماڈل ہر پاور BI رپورٹ کی بنیاد ہے۔ ایک اچھی طرح سے ڈیزائن کیا گیا ماڈل DAX کی پیمائش کو آسان، استفسار کی کارکردگی کو تیز، اور رپورٹ کی ترقی کو بدیہی بناتا ہے۔ ایک ناقص ڈیزائن کردہ ماڈل ہر چیز کو مشکل بنا دیتا ہے --- اقدامات کے لیے پیچیدہ کام کی ضرورت ہوتی ہے، سوالات آہستہ آہستہ چلتے ہیں، اور ڈویلپرز بصیرت کی تعمیر کے بجائے ماڈل سے لڑنے میں زیادہ وقت صرف کرتے ہیں۔

سٹار سکیما تجزیاتی ڈیٹا ماڈلز کے لیے سونے کا معیار ہے، اور یہ کئی دہائیوں سے ہے۔ متعلقہ ڈیٹا بیس جو آپ کے ERP اور CRM سسٹم کو طاقت دیتے ہیں درجنوں باہم جڑے ہوئے ٹیبلز کے ساتھ نارملائزڈ اسکیموں کا استعمال کرتے ہوئے لین دین کی کارکردگی کے لیے ڈیزائن کیے گئے ہیں۔ یہ ڈیزائن انفرادی لین دین کو ریکارڈ کرنے کے لیے بہترین ہے لیکن جمع، موازنہ اور رجحان کے تجزیہ کے لیے خوفناک ہے۔ سٹار سکیما تجزیاتی کارکردگی کے لیے اسی ڈیٹا کو فیکٹ ٹیبلز (کیا ہوا) اور ڈائمینشن ٹیبلز (جو ہوا اس کے ارد گرد سیاق و سباق) میں الگ کر کے اسے ری اسٹرکچر کرتا ہے۔

یہ گائیڈ خاص طور پر پاور BI کے لیے ستارہ سکیما کے ڈیزائن کے اصولوں کا احاطہ کرتا ہے، بشمول حقائق اور طول و عرض کی میزیں کیسے بنائیں، تعلقات کو ترتیب دیں، موثر DAX اقدامات کیسے لکھیں، حسابی گروپوں کا فائدہ اٹھائیں، ٹائم انٹیلی جنس کو نافذ کریں، اور متعدد ڈیٹا ذرائع سے مربوط ہونے کے لیے جامع ماڈلز کا استعمال کریں۔

اہم ٹیک ویز

• اسٹار اسکیما ڈیٹا کو فیکٹ ٹیبلز (عددی اقدامات، غیر ملکی کیز) اور ڈائمینشن ٹیبلز (تفصیلی صفات) میں الگ کرتا ہے --- یہ ڈھانچہ Power BI کے VertiPaq انجن کے لیے موزوں ہے۔
• پاور BI ماڈل میں ہر تعلق کو صرف ایک سمت میں کراس فلٹرنگ کے ساتھ طول و عرض سے حقیقت (ایک سے کئی) تک بہنا چاہئے۔
• DAX اقدامات سٹار اسکیموں پر ڈرامائی طور پر بہتر کارکردگی کا مظاہرہ کرتے ہیں کیونکہ VertiPaq طول و عرض کے کالموں کو مؤثر طریقے سے کمپریس کر سکتا ہے اور تعلقات کے ذریعے حقائق کو فلٹر کر سکتا ہے۔
• حسابی گروپ درجنوں بے کار اقدامات (YTD، QTD، MTD، سال سے پہلے) کو ایک ہی پیٹرن کے ساتھ بدل دیتے ہیں جو تمام بنیادی اقدامات پر لاگو ہوتے ہیں۔
• وقت کی ذہانت کے لیے ایک وقف شدہ تاریخ کے طول و عرض کی جدول کی ضرورت ہوتی ہے --- کبھی بھی خود کار تاریخ/وقت کا استعمال نہ کریں یا حقیقت کے جدولوں میں تاریخ کے کالموں پر انحصار نہ کریں۔
• جامع ماڈلز آپ کو درآمد شدہ ڈیٹا کو DirectQuery کنکشن کے ساتھ جوڑنے دیتے ہیں، جس سے آپ کو لائیو سوالات کی تازگی کے ساتھ ان میموری کی کارکردگی ملتی ہے۔
• کردار ادا کرنے کے طول و عرض (متعدد رشتہ دار کرداروں میں استعمال ہونے والی ایک میز) کے لیے DAX کے USERELATIONSHIP فنکشن کی ضرورت ہوتی ہے

---

اسٹار اسکیما کے بنیادی اصول

پاور BI کے لیے اسٹار اسکیما کیوں؟

پاور BI کا ان میموری انجن، VertiPaq، ڈیٹا کو ذخیرہ کرنے کے لیے کالم کمپریشن کا استعمال کرتا ہے۔ یہ ہر کالم کو آزادانہ طور پر کمپریس کرتا ہے، اور کم کارڈنالٹی (کچھ منفرد اقدار) والے کالم ڈرامائی طور پر کمپریس کرتے ہیں --- 10 ملین قطاروں میں 40 منفرد اقدار کے ساتھ ایک "ملک" کالم تقریباً کچھ بھی نہیں کمپریس کرتا ہے۔ لین دین کی IDs یا ٹائم اسٹیمپ جیسے ہائی کارڈنلٹی (بہت سی منفرد اقدار) والے کالم بری طرح کمپریس ہوتے ہیں۔

سٹار سکیما تنگ فیکٹ ٹیبلز میں ہائی کارڈنلٹی ٹرانزیکشن ڈیٹا (تاریخ، مقدار، مقدار) کو الگ کر کے اور کم کارڈنالٹی وضاحتی ڈیٹا (نام، زمرہ جات، علاقے) کو علیحدہ ڈائمینشن ٹیبلز میں رکھ کر اس کا فائدہ اٹھاتا ہے۔ نتیجہ ایک ڈیٹا ماڈل ہے جو میموری میں چھوٹا اور استفسار کرنے میں تیز ہے۔

فرق پر غور کریں۔ خوردہ کاروبار کے لیے ایک غیر معمولی فلیٹ ٹیبل میں 50 کالم ہو سکتے ہیں: OrderDate، CustomerName، CustomerEmail، CustomerCity، CustomerCountry، Customer Segment، ProductName، Product Category، Productsubcategory، Brand، Supplier، SupplierCountry، Quantity، Unit Country، Discount Price اور To A. ہر قطار "امریکہ" کو ہزاروں بار، "الیکٹرانکس" کو سینکڑوں بار دہراتی ہے، اور ہر اس آرڈر کے لیے مکمل گاہک کا نام جو گاہک نے کبھی دیا ہے۔

ستارہ سکیما کے برابر اس کو الگ کرتا ہے:

فیکٹ سیلز (تنگ، ایک قطار فی آرڈر لائن): OrderDateKey، CustomerKey، ProductKey، مقدار، یونٹ کی قیمت، ڈسکاؤنٹ، کل رقم۔

DimCustomer: CustomerKey، کسٹمر کا نام، ای میل، شہر، ملک، طبقہ۔

کم پروڈکٹ: پروڈکٹ کی، پروڈکٹ کا نام، زمرہ، ذیلی زمرہ، برانڈ۔

ڈیم ڈیٹ: ڈیٹ کی، تاریخ، سال، سہ ماہی، مہینہ، مہینے کا نام، ہفتہ کا دن۔

فیکٹ ٹیبل میں 50 کے بجائے صرف 7 کالم ہیں۔ ہر ڈائمینشن ٹیبل ہر منفرد قدر کو بالکل ایک بار اسٹور کرتا ہے۔ VertiPaq اس ڈھانچے کو فلیٹ ٹیبل سے 3-5x بہتر کمپریس کرتا ہے، اور سوالات 2-10x تیزی سے چلتے ہیں کیونکہ انجن چھوٹے ڈائمینشن ٹیبلز کو فلٹر کرتا ہے اور پھر فیکٹ ٹیبل میں صرف مماثل قطاروں کو حل کرتا ہے۔

حقائق کی میزیں: ڈیزائن کے اصول

حقائق کی میزیں کاروباری واقعات کو ریکارڈ کرتی ہیں --- سیلز، آرڈرز، شپمنٹس، سپورٹ ٹکٹس، ویب وزٹ، مینوفیکچرنگ رنز۔ ہر قطار ایک ایونٹ یا ایونٹ کی ایک لائن آئٹم کی نمائندگی کرتی ہے۔

اناج کی تعریف۔ اناج حقائق کی جدول میں تفصیل کی سطح ہے۔ اس کی درست وضاحت کریں اور اسے مستقل طور پر نافذ کریں۔ سیلز فیکٹ ٹیبل میں "ایک قطار فی آرڈر لائن آئٹم" یا "ایک قطار فی یومیہ پروڈکٹ سیلز سمری" ہو سکتی ہے۔ ایک فیکٹ ٹیبل میں اناج کو ملانے سے (کچھ قطاریں انفرادی لین دین ہوتی ہیں، کچھ روزانہ کی مجموعی ہوتی ہیں) حساب کی غلطیاں پیدا کرتی ہیں جنہیں ڈیبگ کرنا انتہائی مشکل ہوتا ہے۔

صرف غیر ملکی کلیدیں۔ حقائق کے جدول میں طول و عرض کی جدولوں کی غیر ملکی کلیدیں ہوتی ہیں، نہ کہ وضاحتی صفات۔ فیکٹ ٹیبل میں "CustomerName" یا "ProductCategory" --- جن کا تعلق طول و عرض کی جدولوں میں نہیں ہونا چاہیے۔ فیکٹ ٹیبل میں CustomerKey اور ProductKey ہیں، جو ان ڈائمینشنز سے منسلک ہوتے ہیں جہاں وضاحتی تفصیلات رہتی ہیں۔

اضافی اقدامات۔ فیکٹ ٹیبل میں عددی کالم اضافی ہونے چاہئیں --- قدریں جن کا کسی بھی جہت میں معنی خیز خلاصہ کیا جاسکتا ہے۔ آمدنی، مقدار، لاگت، اور رعایت اضافی ہیں۔ فیصد، تناسب، اور یونٹ کی قیمتیں اضافی نہیں ہیں (آپ پروڈکٹس میں یونٹ کی قیمتوں کو جمع نہیں کر سکتے ہیں)۔ فیکٹ ٹیبل میں اجزاء (عدد اور ڈینومینیٹر) کو ذخیرہ کریں اور DAX پیمائش میں تناسب کا حساب لگائیں۔

حقائق کے حساب سے کالموں سے پرہیز کریں۔ فیکٹ ٹیبل میں حسابی کالموں کو شامل کرنے سے ٹیبل کے میموری فوٹ پرنٹ میں اضافہ ہوتا ہے اور ریفریش کے دوران پروسیسنگ کا وقت بڑھ جاتا ہے۔ اس کے بجائے DAX اقدامات میں اخذ کردہ قدروں کا حساب لگائیں، جو استفسار کے وقت حساب کرتے ہیں اور اسٹوریج استعمال نہیں کرتے ہیں۔

طول و عرض کی میزیں: ڈیزائن کے اصول

طول و عرض کی میزیں کاروباری واقعات کی "کون، کیا، کہاں، کب، کیوں" کی وضاحت کرتی ہیں۔ ان میں وہ اوصاف ہوتے ہیں جن کے ذریعے صارف فلٹر، گروپ اور سلائس کرتے ہیں۔

سروگیٹ کیز۔ انٹیجر سروگیٹ کیز (CustomerKey، ProductKey) کو ڈائمینشن ٹیبلز میں بنیادی کلید کے طور پر استعمال کریں، قدرتی کلیدوں کے نہیں (کسٹمر ای میل، پروڈکٹ SKU)۔ سروگیٹ کیز چھوٹی ہوتی ہیں، بہتر طور پر کمپریس کرتی ہیں، اور ماخذ سسٹم کیز میں ہونے والی تبدیلیوں سے ماڈل کو محفوظ رکھتی ہیں۔

**طول و عرض کو غیر معمولی بنائیں۔ ** ستارے کے اسکیما میں، طول و عرض کی میزیں جان بوجھ کر غیر معمولی کی جاتی ہیں۔ ایک DimProduct ٹیبل میں زمرہ، ذیلی زمرہ، اور برانڈ ایک ہی ٹیبل میں کالموں کے طور پر شامل ہوتا ہے، نہ کہ ان کی اپنی کلیدوں کے ساتھ علیحدہ نارملائزڈ ٹیبلز کے طور پر۔ یہ ٹرانزیکشنل ڈیٹا بیس ڈیزائن کے برعکس ہے، اور یہ جان بوجھ کر ہے۔ غیر معمولی طول و عرض تیز تر استفسارات اور آسان DAX پیدا کرتے ہیں کیونکہ VertiPaq انجن متعدد ٹیبلز میں شامل ہونے کے بجائے ایک ٹیبل کو اسکین کرتا ہے۔

تفصیلی درجہ بندی شامل کریں۔ اگر صارف زمرہ سے ذیلی زمرہ سے پروڈکٹ تک ڈرل ڈاؤن کریں گے، تو تینوں سطحیں DimProduct میں کالم ہونے چاہئیں۔ پاور BI ماڈل میں ایک درجہ بندی آبجیکٹ بنائیں جو اس ڈرل پاتھ کی وضاحت کرے۔

آہستہ آہستہ بدلتے ہوئے طول و عرض۔ جب طول و عرض کی خصوصیات وقت کے ساتھ بدلتی ہیں (ایک صارف شہروں کو منتقل کرتا ہے، ایک پروڈکٹ زمرہ جات کو تبدیل کرتا ہے)، آپ کو حکمت عملی کی ضرورت ہوتی ہے۔ ٹائپ 1 (اوور رائٹ) سب سے آسان ہے --- طول و عرض کی قطار کو نئی قدر کے ساتھ اپ ڈیٹ کریں۔ قسم 2 (نئی قطار شامل کریں) تاریخ کو محفوظ رکھتی ہے --- ایک مؤثر تاریخ کی حد کے ساتھ ایک نئی قطار شامل کریں، لہذا تاریخی لین دین ان انتساب کی قدروں سے وابستہ ہیں جو اس وقت موجودہ تھیں۔ ٹائپ 2 زیادہ پیچیدہ لیکن ضروری ہے جب تاریخی درستگی کا معاملہ ہو (مالی آڈٹ، ریگولیٹری رپورٹنگ)۔

---

تعلقات کو ترتیب دینا

پاور BI کے لیے تعلقات کے اصول

پاور BI تعلقات اس بات کی وضاحت کرتے ہیں کہ میزیں کس طرح مربوط ہوتی ہیں اور فلٹرز کیسے پھیلتے ہیں۔ تعلقات کو درست کرنا اہم ہے --- غلط تعلقات خاموشی سے غلط نمبر پیدا کرتے ہیں، جو کہ غلطیاں پیدا کرنے سے بھی بدتر ہے۔

صرف ایک سے کئی۔ اسٹار اسکیما میں ہر رشتہ ایک ڈائمینشن ٹیبل (ایک طرف) کو فیکٹ ٹیبل (کئی سائیڈ) سے جوڑتا ہے۔ ڈائمینشن ٹیبل کی کلیدی کالم میں منفرد قدریں ہیں۔ فیکٹ ٹیبل میں دہرائی گئی قدریں ہیں۔ پاور BI اس کی توثیق کرتا ہے اور خلاف ورزیوں کو نشان زد کرتا ہے۔ اگر پاور BI متعدد سے کئی تعلق کا پتہ لگاتا ہے، تو آپ کو حل کرنے کے لیے ماڈلنگ کا مسئلہ ہے۔

سنگل سمت کراس فلٹرنگ۔ تمام رشتوں پر کراس فلٹر کی سمت کو "سنگل" پر سیٹ کریں۔ اس کا مطلب ہے کہ فلٹرز طول و عرض سے حقیقت کی طرف روانہ ہوتے ہیں (جب آپ کسی گاہک کو سلائسر میں منتخب کرتے ہیں تو صرف وہی گاہک کی قطاریں فیکٹ ٹیبل ویژول میں ظاہر ہوتی ہیں) لیکن حقیقت سے جہت کی طرف نہیں۔ دو طرفہ فلٹرنگ متعدد فیکٹ ٹیبلز والے ماڈلز میں مبہم فلٹر پاتھ بناتی ہے اور ان سے اجتناب کیا جانا چاہیے سوائے انتہائی مخصوص منظرناموں کے۔

فعال بمقابلہ غیر فعال تعلقات۔ پاور BI کسی بھی دو جدولوں کے درمیان صرف ایک فعال تعلق کی اجازت دیتا ہے۔ اگر فیکٹ ٹیبل میں متعدد تاریخ کے کالم ہیں (OrderDate, ShipDate, Delivery Date) تو ایک فعال رشتہ بنائیں (عام طور پر OrderDate to DimDate) اور دوسروں کے لیے غیر فعال تعلقات۔ ضرورت پڑنے پر غیر فعال تعلق کو چالو کرنے کے لیے DAX اقدامات میں USERELATIONSHIP فنکشن کا استعمال کریں:

Shipped Revenue =
CALCULATE(
    [Total Revenue],
    USERELATIONSHIP(FactSales[ShipDateKey], DimDate[DateKey])
)

کردار ادا کرنے کے طول و عرض

ایک رول پلےنگ ڈائمینشن ایک سنگل ڈائمینشن ٹیبل ہے جو ماڈل میں ایک سے زیادہ کردار ادا کرتی ہے۔ تاریخ کا طول و عرض سب سے عام مثال ہے --- یہ فیکٹ ٹیبل میں OrderDate، ShipDate، اور DeliveryDate سے جوڑتا ہے، ہر تعلق میں ایک مختلف "کردار" ادا کرتا ہے۔

پاور BI میں، آپ کردار ادا کرنے کے طول و عرض کو دو طریقوں سے سنبھال سکتے ہیں:

**غیر فعال تعلقات + یوزریلیشن شپ (تجویز کردہ)۔ ** ایک فعال رشتہ (آرڈر ڈیٹ سے) اور دوسرے تاریخ کے کالموں کے ساتھ غیر فعال تعلقات کے ساتھ ایک واحد DimDate ٹیبل رکھیں۔ ایسے اقدامات بنائیں جو تاریخ کے متبادل نقطہ نظر کے لیے USERELATIONSHIP کا استعمال کریں۔ یہ ماڈل کو کمپیکٹ رکھتا ہے اور ڈیٹا ڈپلیکیشن سے بچتا ہے۔

ڈپلیکیٹ ڈائمینشن ٹیبلز۔ DimDate (DimOrderDate، DimShipDate، DimDeliveryDate) کی الگ الگ کاپیاں بنائیں، ہر ایک اپنے متعلقہ حقائق کے کالم سے فعال تعلق کے ساتھ۔ یہ نقطہ نظر DAX کے نقطہ نظر سے آسان ہے (صارف کی ضرورت نہیں ہے) لیکن ماڈل کے سائز اور دیکھ بھال کے بوجھ کو بڑھاتا ہے۔

زیادہ تر نفاذ کے لیے، غیر فعال تعلقات کے نقطہ نظر کو ترجیح دی جاتی ہے۔ یہ قدرے زیادہ وربوز DAX کی قیمت پر ایک کلینر ماڈل اور چھوٹا میموری فوٹ پرنٹ تیار کرتا ہے۔

بہت سے رشتے

کچھ کاروباری منظرناموں میں حقیقی طور پر کئی سے کئی رشتوں کی ضرورت ہوتی ہے۔ ایک گاہک متعدد حصوں سے تعلق رکھتا ہے، ایک پروڈکٹ متعدد پروموشنل مہمات میں ہو سکتا ہے، ایک سیلز پرسن متعدد علاقوں کا احاطہ کر سکتا ہے۔ سٹار سکیما ان کو برج ٹیبل کے ذریعے ہینڈل کرتا ہے۔

ایک برج ٹیبل دو میزوں کے درمیان کئی سے کئی رشتے میں بیٹھتا ہے اور اس میں ہر ایک کے لیے ایک قطار ہوتی ہے:

BridgeCustomer Segment: CustomerKey، SegmentKey

DimCustomer BridgeCustomerSegment سے جڑتا ہے (کسٹمرکی پر ایک سے کئی)۔ DimSegment BridgeCustomerSegment سے جڑتا ہے (SegmentKey پر ایک سے کئی)۔ برج ٹیبل سیگمنٹ کے لحاظ سے فیکٹ سیلز کو فلٹر کرنے کے قابل بناتا ہے جبکہ متعدد حصوں میں صارفین کو صحیح طریقے سے ہینڈل کرتا ہے۔

برج ٹیبلز کے ساتھ محتاط رہیں --- وہ دوہری گنتی پیدا کر سکتے ہیں اگر مناسب DAX اقدامات کے ساتھ جوڑا نہ بنایا جائے جو کئی سے زیادہ مختص کو سنبھالتے ہیں۔ معلوم اعداد و شمار کے ساتھ اچھی طرح جانچیں تاکہ یہ معلوم ہو سکے کہ ٹوٹل درست ہیں۔

---

DAX اقدامات: پیٹرن اور کارکردگی

بنیادی اقدامات

ہر تجزیاتی ماڈل کو بنیادی اقدامات کے ایک سیٹ کی ضرورت ہوتی ہے جو حقائق کے جدول کے کالموں پر سادہ مجموعوں کو انجام دیتے ہیں۔ پہلے ان کی وضاحت کریں --- یہ زیادہ پیچیدہ حسابات کے لیے تعمیراتی بلاکس کے طور پر کام کرتے ہیں۔

Total Revenue = SUM(FactSales[TotalAmount])
Total Quantity = SUM(FactSales[Quantity])
Total Cost = SUM(FactSales[CostAmount])
Order Count = COUNTROWS(FactSales)
Average Order Value = DIVIDE([Total Revenue], [Order Count])
Gross Margin = DIVIDE([Total Revenue] - [Total Cost], [Total Revenue])

نوٹ کریں کہ اوسط آرڈر ویلیو اور مجموعی مارجن جمع منطق کو دہرانے کے بجائے دیگر اقدامات کا حوالہ دیتے ہیں۔ یہ جان بوجھ کر ہے --- اگر کل محصول کی تعریف بدل جاتی ہے (مثال کے طور پر، واپسی کو خارج کرنے کے لیے)، تو بہاو کے اقدامات خود بخود تبدیلی کی عکاسی کرتے ہیں۔

حساب کریں: DAX کا بنیادی

CALCULATE سب سے اہم DAX فنکشن ہے۔ یہ ایک ترمیم شدہ فلٹر سیاق و سباق میں اظہار کا اندازہ کرتا ہے۔ CALCULATE کو سمجھنا DAX کو سمجھنا ہے۔

Revenue Last Year =
CALCULATE(
    [Total Revenue],
    SAMEPERIODLASTYEAR(DimDate[Date])
)

یہ پیمانہ کل آمدنی کا پیمانہ لیتا ہے اور اس کا فلٹر سیاق و سباق میں جائزہ لیتا ہے جہاں تاریخ کی حد کو ایک سال پیچھے منتقل کیا جاتا ہے۔ اگر موجودہ فلٹر کا سیاق و سباق "جنوری 2026" ہے، تو CALCULATE اسے "جنوری 2025" میں تبدیل کرتا ہے اور اس ترمیم شدہ سیاق و سباق میں کل آمدنی کا اندازہ کرتا ہے۔

CALCULATE متعدد فلٹر دلائل کو قبول کرتا ہے، اور وہ اپنی قسم کے لحاظ سے مختلف طریقے سے تعامل کرتے ہیں:

ٹیبل فلٹرز (جیسے SAMEPERIODLASTYEAR) اس ٹیبل کے کالموں پر موجود فلٹر کو بدل دیتے ہیں۔ اگر بصری میں پہلے سے ہی ایک مہینے کا فلٹر ہے، تو SAMEPERIODLASTYEAR اسے پچھلے سال کے اسی مہینے کے ساتھ اوور رائیڈ کر دیتا ہے۔

بولین فلٹرز (جیسے DimProduct[Category] = "Electronics") موجودہ سیاق و سباق میں اضافہ کرتے ہیں۔ اگر بصری کو 2026 میں فلٹر کیا جاتا ہے، تو CALCULATE کا نتیجہ 2026 Electronics revenue کو ظاہر کرتا ہے۔

** ہٹانے والے فلٹرز** موجودہ فلٹرز کو صاف کرتے ہیں۔ CALCULATE([Total Revenue], REMOVEFILTERS(DimProduct[Category])) تمام زمروں میں کل آمدنی لوٹاتا ہے قطع نظر اس کے کہ کس قسم کے فلٹرز فعال ہیں۔

پڑھنے کی اہلیت اور کارکردگی کے لیے متغیرات

متغیرات (VAR) ایک قدر کی ایک بار گنتی کرتے ہیں اور متعدد بار اس کا حوالہ دیتے ہیں۔ وہ پیچیدہ اقدامات کو پڑھنے کے قابل بناتے ہیں اور بے کار حسابات کو ختم کرتے ہیں:

Revenue YoY Growth =
VAR CurrentRevenue = [Total Revenue]
VAR PriorRevenue = [Revenue Last Year]
VAR Growth = CurrentRevenue - PriorRevenue
VAR GrowthPct = DIVIDE(Growth, PriorRevenue)
RETURN
    GrowthPct

متغیرات کے بغیر، یہ پیمانہ [کل آمدنی] اور [گزشتہ سال کی آمدنی] کو متعدد بار (ایک بار گھٹانے کے لیے، ایک بار تقسیم کے لیے)، حسابی لاگت کو دوگنا کرے گا۔ متغیر اس بات کو یقینی بناتے ہیں کہ ہر ایک کا حساب بالکل ایک بار کیا جائے۔

Iterator کے افعال: انہیں کب استعمال کرنا ہے۔

Iterator فنکشنز (SUMX, AVERAGEX, MAXX, MINX, COUNTX, RANKX) ٹیبل پر قطار در قطار اظہار کا اندازہ لگاتے ہیں۔ وہ طاقتور لیکن مہنگے ہیں --- وہ مخصوص ٹیبل میں ہر قطار کو اسکین کرتے ہیں۔

جب آپ کو جمع کرنے سے پہلے قطار کی سطح کے حساب کتاب کی ضرورت ہو تو تکرار کرنے والوں کا استعمال کریں:

Weighted Average Price =
DIVIDE(
    SUMX(FactSales, FactSales[Quantity] * FactSales[UnitPrice]),
    SUM(FactSales[Quantity])
)

یہ سادہ SUM کے ساتھ حاصل نہیں کیا جا سکتا ہے کیونکہ آپ کو رقم جمع کرنے سے پہلے ہر قطار پر یونٹ پرائس سے ضرب کرنی ہوگی۔ تکرار کرنے والا SUMX اس قطار در قطار ضرب کو ہینڈل کرتا ہے۔

جب ایک سادہ مجموعی کافی ہو تو تکرار کرنے والوں سے گریز کریں۔ SUMX(FactSales, FactSales[TotalAmount]) فعلی طور پر SUM(FactSales[TotalAmount]) کے برابر ہے لیکن آہستہ ہے کیونکہ تکرار کرنے والا قطار در قطار اسکین کرتا ہے جبکہ SUM کالم کمپریشن کا فائدہ اٹھاتا ہے۔

---

حسابی گروپس

کیلکولیشن گروپس کیا حل کرتے ہیں۔

کیلکولیشن گروپس سے پہلے، 10 بنیادی اقدامات (آمدنی، مقدار، لاگت، مارجن، وغیرہ) اور 5 وقتی انٹیلی جنس تغیرات (YTD، QTD، MTD، پرائیور ایئر، پرائر ایئر YTD) والے ڈیٹا ماڈل کے لیے 50 الگ الگ اقدامات کی ضرورت ہوتی ہے۔ ایک نیا بنیادی پیمانہ شامل کرنے کا مطلب ہے 5 مزید وقتی انٹیلی جنس مختلف قسمیں بنانا۔ ایک نئے وقت کے انٹیلی جنس پیٹرن کو شامل کرنے کا مطلب ہے 10 مزید اقدامات۔ اس مشترکہ دھماکے نے ماڈلز کو برقرار رکھنا مشکل بنا دیا۔

کیلکولیشن گروپس اس کو ایک بار ٹائم انٹیلی جنس پیٹرن کی وضاحت کرکے اور انہیں کسی بھی پیمائش پر متحرک طور پر لاگو کرکے حل کرتے ہیں۔

ٹائم انٹیلی جنس کیلکولیشن گروپ بنانا

پاور BI ڈیسک ٹاپ میں، ماڈل ویو کے ذریعے یا ٹیبلر ایڈیٹر (جو زیادہ کنٹرول فراہم کرتا ہے) جیسے بیرونی ٹولز کا استعمال کرتے ہوئے کیلکولیشن گروپ بنائیں۔

ہر بار انٹیلی جنس پیٹرن کے لیے حساب کتاب کی اشیاء کی وضاحت کریں:

موجودہ: کوئی ترمیم نہیں --- پیمائش کو ویسے ہی لوٹاتا ہے۔

SELECTEDMEASURE()

YTD (سال تا تاریخ):

CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD(DimDate[Date])
)

پچھلا سال:

CALCULATE(
    SELECTEDMEASURE(),
    SAMEPERIODLASTYEAR(DimDate[Date])
)

پچھلے سال YTD:

CALCULATE(
    SELECTEDMEASURE(),
    DATESYTD(SAMEPERIODLASTYEAR(DimDate[Date]))
)

YoY تبدیلی:

VAR CurrentValue = SELECTEDMEASURE()
VAR PriorValue = CALCULATE(SELECTEDMEASURE(), SAMEPERIODLASTYEAR(DimDate[Date]))
RETURN CurrentValue - PriorValue

YY% تبدیلی:

VAR CurrentValue = SELECTEDMEASURE()
VAR PriorValue = CALCULATE(SELECTEDMEASURE(), SAMEPERIODLASTYEAR(DimDate[Date]))
RETURN DIVIDE(CurrentValue - PriorValue, PriorValue)

ایک بار تعریف ہو جانے کے بعد، صارف حسابی گروپ کو بصری کالم یا قطار کے محور میں رکھتا ہے، اور پاور BI ہر حسابی آئٹم کو جو بھی پیمانہ قدروں میں اچھی طرح سے ہے لاگو کرتا ہے۔ 6 آئٹمز کے ساتھ ایک حسابی گروپ 60 انفرادی اقدامات کی جگہ لے لیتا ہے (10 بنیادی اقدامات کے لیے)۔

اسٹرنگ ایکسپریشنز کو فارمیٹ کریں۔

ہر حسابی آئٹم میں ایک فارمیٹ سٹرنگ ایکسپریشن ہو سکتا ہے جو کہ حساب کی بنیاد پر نمبر کی شکل کو متحرک طور پر تبدیل کرتا ہے:

مطلق اقدامات کے لیے (موجودہ، YTD، سال سے پہلے): بنیادی پیمائش کا فارمیٹ استعمال کریں۔ فیصد کے اقدامات کے لیے (YoY % تبدیلی): فیصد کے طور پر فارمیٹ کریں۔

// Format string for YoY % Change
"0.0%;-0.0%;0.0%"

یہ یقینی بناتا ہے کہ جب صارف "موجودہ" ($1,234,567 دکھا رہا ہے) اور "YoY % تبدیلی" (12.5% ​​دکھا رہا ہے) کے درمیان سوئچ کرتا ہے، تو فارمیٹنگ دستی مداخلت کے بغیر درست ہے۔

---

وقت کی ذہانت

تاریخ کے طول و عرض کا جدول

پاور BI میں وقت کی ذہانت کے لیے ایک وقف شدہ تاریخ کے طول و عرض کی جدول کی ضرورت ہوتی ہے۔ خودکار تاریخ/وقت کی خصوصیت پر بھروسہ نہ کریں (اسے فائل → اختیارات → ڈیٹا لوڈ میں غیر فعال کریں) --- یہ ہر تاریخ کے کالم کے لیے پوشیدہ تاریخ کی میزیں بناتا ہے، آپ کے ماڈل کو پھولتا ہے اور آپ کے کنٹرول کو محدود کرتا ہے۔

تاریخ کے طول و عرض کی میز بنائیں جو آپ کے ڈیٹا کی پوری رینج کے علاوہ ہر طرف کم از کم ایک سال کا احاطہ کرے۔ اگر آپ کا ابتدائی لین دین جنوری 2020 ہے، تو تاریخ کا جدول جنوری 2019 سے شروع کریں۔ اگر آپ کے تجزیے میں 2027 کی پیشن گوئیاں شامل ہوں گی، تو دسمبر 2027 پر ختم ہو جاتی ہیں۔

تاریخ کے طول و عرض کی میز کے لیے ضروری کالم:

پاور کوئری میں یا DAX کیلکولیٹڈ ٹیبل کے طور پر ڈیٹ ٹیبل بنائیں:

DimDate =
VAR StartDate = DATE(2019, 1, 1)
VAR EndDate = DATE(2027, 12, 31)
RETURN
ADDCOLUMNS(
    CALENDAR(StartDate, EndDate),
    "DateKey", YEAR([Date]) * 10000 + MONTH([Date]) * 100 + DAY([Date]),
    "Year", YEAR([Date]),
    "Quarter", "Q" & QUARTER([Date]),
    "MonthNumber", MONTH([Date]),
    "Month", FORMAT([Date], "MMMM"),
    "DayOfWeek", FORMAT([Date], "dddd"),
    "IsWeekend", WEEKDAY([Date], 2) >= 6
)

پاور BI میں ٹیبل کو ڈیٹ ٹیبل کے بطور نشان زد کریں (ٹیبل ٹولز → بطور ڈیٹ ٹیبل نشان زد کریں → تاریخ کا کالم منتخب کریں)۔ یہ بلٹ ان ٹائم انٹیلی جنس افعال کو قابل بناتا ہے۔

کامن ٹائم انٹیلی جنس پیٹرن

مناسب تاریخ کے طول و عرض کے ساتھ، پاور BI کے وقت کی ذہانت کے افعال عام ترین وقتی حسابات کو سنبھالتے ہیں:

سال سے تاریخ: DATESYTD(DimDate[Date]) سہ ماہی سے تاریخ: DATESQTD(DimDate[Date]) ماہ تا تاریخ: DATESMTD(DimDate[Date]) گزشتہ سال اسی مدت: SAMEPERIODLASTYEAR(DimDate[Date]) رولنگ 12 مہینے: DATESINPERIOD(DimDate[Date], MAX(DimDate[Date]), -12, MONTH) متوازی مدت: PARALLELPERIOD(DimDate[Date], -1, QUARTER) (ایک ہی سائز کی ونڈو پیچھے منتقل ہو گئی)

CALCULATE کے اندر استعمال ہونے پر یہ فنکشنز ڈیٹ فلٹر کے سیاق و سباق میں ترمیم کرتے ہیں۔ وہ صرف اس وقت صحیح طریقے سے کام کرتے ہیں جب تاریخ کا کالم کسی ٹیبل سے آتا ہے جس میں ڈیٹ ٹیبل کے طور پر نشان زد ایک متصل، مکمل تاریخ کی حد ہوتی ہے۔

مالی کیلنڈر سپورٹ

اگر آپ کی تنظیم کا مالی سال کیلنڈر کے سال کے مطابق نہیں ہے، تو مالیاتی کیلنڈر کو استعمال کرنے کے لیے وقت کی ذہانت کے حسابات میں ترمیم کریں:

Fiscal YTD Revenue =
CALCULATE(
    [Total Revenue],
    DATESYTD(DimDate[Date], "6/30")  -- Fiscal year ends June 30
)

DATESYTD کی دوسری دلیل مالی سال کے اختتام کی تاریخ بتاتی ہے۔ YTD کے تمام حسابات پھر 31 دسمبر کے بجائے مالی سال کی حد استعمال کرتے ہیں۔

---

جامع ماڈلز

کمپوزٹ ماڈلز کب استعمال کریں۔

جامع ماڈلز ایک ہی ماڈل میں درآمد شدہ ڈیٹا (ورٹی پیک میں محفوظ) کو DirectQuery ڈیٹا (ماخذ سے براہ راست پوچھے گئے) کے ساتھ ملاتے ہیں۔ جب آپ کو تاریخی تجزیہ کے لیے درآمد شدہ ڈیٹا کی کارکردگی اور آپریشنل میٹرکس کے لیے لائیو ڈیٹا کی تازگی کی ضرورت ہو تو یہ ہائبرڈ نقطہ نظر قابل قدر ہے۔

عام منظرنامے:

**تاریخی + حقیقی وقت۔ ** رجحان کے تجزیہ کے لیے 3 سال کا تاریخی سیلز ڈیٹا درآمد کریں (تیز سوالات، ماخذ ڈیٹا بیس پر کوئی اثر نہیں)۔ اپ ٹو دی منٹ آپریشنل ویوز کے لیے DirectQuery کے ذریعے موجودہ مہینے کے ڈیٹا سے جڑیں۔

مرکزی ماڈل + مقامی افزودگی۔ DirectQuery کے ذریعے مرکزی طور پر منظم ڈیٹاسیٹ سے جڑیں (اس بات کو یقینی بناتے ہوئے کہ آپ تنظیم کی زیر انتظام تعریفیں استعمال کرتے ہیں)۔ محکمہ کے مخصوص ڈیٹا (بجٹ کے اہداف، حسب ضرورت درجہ بندی) کے لیے مقامی درآمد شدہ جدولیں شامل کریں جو مرکزی ماڈل میں موجود نہیں ہیں۔

متعدد سورس سسٹمز۔ کلاؤڈ ڈیٹا گودام (Snowflake, Azure Synapse) سے ڈیٹا درآمد کریں اور ایک ہی رپورٹ میں DirectQuery کے ذریعے ایک آپریشنل ڈیٹا بیس (PostgreSQL, SQL Server) سے جڑیں، بغیر انہیں مضبوط کرنے کے لیے علیحدہ ETL پائپ لائن بنائے۔

کمپوزٹ ماڈل آرکیٹیکچر

ایک جامع ماڈل میں، ہر ٹیبل میں اسٹوریج موڈ ہوتا ہے:

درآمد: ڈیٹا VertiPaq میموری میں لوڈ کیا جاتا ہے۔ سب سے تیز استفسار کی کارکردگی لیکن اپ ڈیٹ کرنے کے لیے شیڈول ریفریش کی ضرورت ہے۔

DirectQuery: ڈیٹا کا براہ راست ذریعہ سے استفسار کیا جاتا ہے۔ ہمیشہ موجودہ لیکن ماخذ ڈیٹا بیس کی کارکردگی پر منحصر ہے۔

دوہری: ٹیبل درآمد شدہ اور DirectQuery کے لیے دستیاب ہے۔ ڈائمینشن ٹیبلز کے لیے استعمال کیا جاتا ہے جن کا Import اور DirectQuery فیکٹ ٹیبلز دونوں سے تعلق ہونا ضروری ہے۔

ڈائمینشن ٹیبل سیٹ کریں جو Import اور DirectQuery کے حقائق کو "Dual" موڈ میں لے جائیں۔ یہ VertiPaq انجن کو امپورٹ حقائق کو فلٹر کرتے وقت میموری میں موجود کاپی استعمال کرنے اور DirectQuery حقائق کو فلٹر کرتے وقت SQL سوالات پیدا کرنے کی اجازت دیتا ہے۔

کارکردگی کے تحفظات

جامع ماڈل پیچیدگی کو متعارف کراتے ہیں۔ درآمد اور DirectQuery ٹیبلز پر محیط سوالات کے لیے پاور BI کو دو مختلف انجنوں سے نتائج ضم کرنے کی ضرورت ہوتی ہے، جو DirectQuery سورس کو بہتر نہ ہونے کی صورت میں سست ہو سکتا ہے۔

اپنے ماڈل کی ساخت بنا کر کراس سورس جوائن کو کم سے کم کریں تاکہ زیادہ تر تجزیاتی استفسارات امپورٹ ٹیبل پر آئیں۔ DirectQuery کا استعمال صرف ان مخصوص ٹیبلز کے لیے کریں جن کے لیے حقیقی وقت کی تازگی کی ضرورت ہوتی ہے۔ تعلقات اور فلٹرز میں استعمال ہونے والے کالموں پر DirectQuery سورس ٹیبلز کو انڈیکس کریں۔

پیچیدہ Power BI ڈیٹا ماڈلز بنانے والی تنظیموں کے لیے، ECOSIRE کی ڈیٹا ماڈلنگ سروسز اسٹار اسکیما ڈیزائن، DAX آپٹیمائزیشن، اور آپ کے مخصوص ڈیٹا لینڈ اسکیپ اور کارکردگی کی ضروریات کے مطابق کمپوزٹ ماڈل آرکیٹیکچر کے بارے میں ماہرانہ رہنمائی فراہم کرتی ہے۔

---

ماڈل آپٹیمائزیشن

ماڈل کا سائز کم کرنا

بڑے ماڈل زیادہ میموری استعمال کرتے ہیں، زیادہ آہستہ سے ریفریش کرتے ہیں، اور کم جوابی سوال کرتے ہیں۔ ان تکنیکوں کے ذریعے ماڈل کے سائز کو بہتر بنائیں:

غیر استعمال شدہ کالموں کو ہٹا دیں۔ اگر کوئی کالم کسی بصری، پیمائش، تعلق، یا RLS اصول میں استعمال نہیں ہوتا ہے، تو اسے ہٹا دیں۔ ہر کالم میموری استعمال کرتا ہے چاہے کوئی بصری حوالہ نہ ہو۔ عام مجرموں میں خود کار طریقے سے تیار کردہ کالم، آڈٹ کالم (CreatedBy، ModifiedDate) اور تکنیکی شناخت کنندہ شامل ہیں جو کسی تجزیاتی مقصد کو پورا نہیں کرتے ہیں۔

کارڈینلٹی کو کم کریں۔ لاکھوں منفرد قدروں والے کالم (ٹائم اسٹیمپ، GUIDs، مفت ٹیکسٹ فیلڈز) خراب کمپریس ہوتے ہیں۔ گول ٹائم اسٹیمپ مناسب گرانولریٹی (روزانہ، فی گھنٹہ)۔ GUIDs کو انٹیجر سروگیٹ کیز سے تبدیل کریں۔ فری ٹیکسٹ فیلڈز کو ایک علیحدہ تفصیلی ٹیبل پر منتقل کریں جس سے صرف ڈرلنگ کے دوران سوال کیا جاتا ہے۔

مناسب ڈیٹا کی قسمیں استعمال کریں۔ پاور BI "پورے نمبر" کو "اعشاریہ نمبر" سے زیادہ مؤثر طریقے سے اسٹور کرتا ہے۔ اگر کسی کالم میں صرف عدد (مقدار، شمار) ہوں تو اس کی قسم کو مکمل نمبر پر سیٹ کریں۔ ٹیکسٹ کالم اسی کارڈینیلیٹی کے عددی کالموں سے زیادہ میموری استعمال کرتے ہیں --- جہاں ممکن ہو، ٹیکسٹ کیٹیگریز کو تلاش کے طول و عرض کے ساتھ انٹیجرز کے طور پر انکوڈ کریں۔

خودکار تاریخ/وقت کو غیر فعال کریں۔ خودکار تاریخ/وقت کی خصوصیت ماڈل میں ہر تاریخ کے کالم کے لیے ایک پوشیدہ ڈیٹ ٹیبل بناتی ہے۔ 10 تاریخ کے کالموں والے ماڈل کے لیے، یہ 10 پوشیدہ تاریخ کی میزیں ہیں جو میموری استعمال کرتی ہیں۔ اس خصوصیت کو غیر فعال کریں اور اس کے بجائے ایک واضح تاریخ کا جہت استعمال کریں۔

استفسار کی کارکردگی کی تشخیص

پاور BI کا بلٹ ان پرفارمنس اینالائزر جو دکھاتا ہے اس سے آگے استفسار کی کارکردگی کا تجزیہ کرنے کے لیے DAX اسٹوڈیو کا استعمال کریں۔ DAX اسٹوڈیو سے پتہ چلتا ہے:

اسٹوریج انجن کے سوالات۔ VertiPaq انجن کو کتنے سوالات بھیجے جاتے ہیں اور وہ کتنا ڈیٹا اسکین کرتے ہیں۔ کم ڈیٹا کو اسکین کرنے سے کم سوالات کا مطلب بہتر کارکردگی ہے۔

فارمولہ انجن کی سرگرمی۔ فارمولا انجن کتنا کام کرتا ہے (قطار بہ قطار حسابات، پیچیدہ تاثرات)۔ ہائی فارمولہ انجن کا وقت ان اقدامات کی نشاندہی کرتا ہے جنہیں اسٹوریج انجن پر مزید کام کرنے کے لیے دوبارہ لکھا جانا چاہیے۔

استفسار کا منصوبہ۔ DAX استفسار کے لیے منطقی اور جسمانی عمل درآمد کا منصوبہ، یہ دکھاتا ہے کہ پاور BI کس طرح اسٹوریج انجن کے سوالات اور فارمولہ انجن کے آپریشنز میں ایک پیمائش کو ختم کرتا ہے۔

انٹرایکٹو ویژولز کے لیے 500ms سے کم استفسار کے اوقات کو ہدف بنائیں۔ 2 سیکنڈ سے زیادہ کے سوالات سست محسوس کرتے ہیں اور ڈیش بورڈ کے استعمال کی حوصلہ شکنی کرتے ہیں۔ اگر کوئی مخصوص بصری مستقل طور پر 2 سیکنڈ سے زیادہ ہے، تو اس کے DAX کو آسان بنائیں، ڈیٹا کی مقدار کو کم کریں جس پر یہ عمل کرتا ہے، یا اسے ڈرل تھرو صفحہ پر منتقل کریں جہاں صارفین ایک مختصر انتظار قبول کرتے ہیں۔

---

اکثر پوچھے گئے سوالات

کیا مجھے پاور BI میں اسٹار اسکیما یا سنو فلیک اسکیما استعمال کرنا چاہیے؟

پاور BI کے لیے اسٹار اسکیما تقریباً ہمیشہ ہی بہتر انتخاب ہوتا ہے۔ Snowflake سکیما طول و عرض کی میزوں کو ذیلی جدولوں (زمرہ → ذیلی زمرہ → پروڈکٹ) میں معمول بناتا ہے، جو کہ متعلقہ ڈیٹا بیس میں اچھی طرح کام کرتا ہے لیکن Power BI کے VertiPaq انجن میں غیر ضروری شمولیت پیدا کرتا ہے۔ VertiPaq غیر معمولی طول و عرض کے کالموں کو انتہائی مؤثر طریقے سے کمپریس کرتا ہے، اس لیے اسنو فلکنگ سے خلائی بچت نہ ہونے کے برابر ہے جبکہ اضافی تعلقات کی کارکردگی کی لاگت حقیقی ہے۔ اپنے طول و عرض کو ستارہ اسکیما میں ہموار کریں جب تک کہ آپ کے پاس نہ کرنے کی کوئی خاص تکنیکی وجہ نہ ہو (جیسے کہ ایک بہت بڑی ڈائمینشن ٹیبل جس میں شاذ و نادر ہی استعمال ہونے والا ہائی کارڈنلٹی کالم ہے جسے آپ الگ کرنا چاہتے ہیں)۔

Power BI میں ڈیٹا سیٹ کا زیادہ سے زیادہ سائز کیا ہے؟

پاور BI پرو 1GB تک کمپریسڈ ڈیٹا سیٹس کو سپورٹ کرتا ہے۔ پریمیم فی صارف 100GB تک سپورٹ کرتا ہے۔ پریمیم صلاحیت (P1 اور اس سے اوپر) 400GB تک سپورٹ کرتا ہے بڑے ڈیٹا سیٹ اسٹوریج کے ساتھ۔ یہ حدود کمپریسڈ ان میموری سائز کا حوالہ دیتے ہیں، ماخذ ڈیٹا کے سائز کا نہیں۔ VertiPaq عام طور پر 10:1 کے تناسب سے ڈیٹا کو کمپریس کرتا ہے، لہذا ایک 1GB کمپریسڈ ڈیٹاسیٹ 10GB سورس ڈیٹا کی نمائندگی کر سکتا ہے۔ ان حدود تک پہنچنے والے ڈیٹاسیٹس کے لیے، تفصیلی سطح کے ڈیٹا کے لیے ڈائریکٹ کیوری کے ساتھ مجموعوں، انکریمنٹل ریفریش، یا جامع ماڈلز پر غور کریں۔

میں اسٹار اسکیما میں کئی سے زیادہ رشتوں کو کیسے ہینڈل کروں؟

برج ٹیبل کا استعمال کریں (جسے فیکٹ لیس فیکٹ ٹیبل یا جنکشن ٹیبل بھی کہا جاتا ہے)۔ برج ٹیبل میں کئی سے کئی رشتے میں ہر امتزاج کے لیے ایک قطار ہوتی ہے --- مثال کے طور پر، ہر صارف کے حصے کے تفویض کے لیے ایک قطار۔ ہر جہت سے پل ٹیبل تک ایک سے کئی رشتے بنائیں۔ آگاہ رہیں کہ پل کی میزیں دوہری گنتی کا سبب بن سکتی ہیں۔ انہیں DISTINCTCOUNT اقدامات کے ساتھ جوڑیں یا فلٹر کے پھیلاؤ کو کنٹرول کرنے کے لیے DAX میں CROSSFILTER استعمال کریں۔ معلوم ڈیٹا کے ساتھ اچھی طرح جانچیں تاکہ یہ یقینی بنایا جا سکے کہ ٹوٹل درست ہیں۔

کیا مجھے حسابی کالم یا DAX اقدامات بنانے چاہئیں؟

تقریباً تمام معاملات میں حسابی کالموں پر اقدامات کو ترجیح دیں۔ پیمائش استفسار کے وقت کی جاتی ہے اور اسٹوریج استعمال نہیں کرتی ہے۔ حسابی کالم ریفریش کے دوران شمار کیے جاتے ہیں اور ماڈل کے سائز میں اضافہ کرتے ہوئے میموری میں محفوظ کیا جاتا ہے۔ حسابی کالم صرف اس وقت استعمال کریں جب آپ کو فلٹرنگ، چھانٹنے، یا تعلقات کے لیے دستیاب قدر کی ضرورت ہو (آپ سلیسر میں پیمائش کے مطابق فلٹر نہیں کر سکتے، لیکن آپ حسابی کالم کے ذریعے فلٹر کر سکتے ہیں)۔ ایک عام رعایت قطار کی سطح کے لیبلز (FullName = FirstName + " " + LastName) کے لیے ایک مربوط کالم ہے جس کی صارفین کو سلائسرز یا ٹیبل ویژول میں ضرورت ہوتی ہے۔

کیلکولیشن گروپس موجودہ اقدامات کے ساتھ کیسے تعامل کرتے ہیں؟

کیلکولیشن گروپس کیلکولیشن آئٹم کے اظہار میں پیمائش کو لپیٹ کر پیمائش کی تشخیص کو روکتے ہیں۔ جب ایک بصری میں ایک پیمائش اور ایک کیلکولیشن گروپ ہوتا ہے، تو Power BI SELECTEDMEASURE() فنکشن کے ذریعے کیلکولیشن آئٹم کو پیمائش پر لاگو کرتا ہے۔ اس کا مطلب ہے کہ آپ کے بنیادی اقدامات میں ترمیم کرنے کی ضرورت نہیں ہے۔ تاہم، ایسے اقدامات جن میں پہلے سے ہی وقت کی ذہانت ہوتی ہے (جیسے ایک ہارڈ کوڈڈ YTD پیمائش) میں حسابی گروپ کو سب سے اوپر لاگو کیا جائے گا، جو ممکنہ طور پر ڈبل ایپلیکیشن تیار کرتا ہے۔ اس سے بچنے کے لیے، صرف بنیادی اقدامات (سادہ جمع) کی وضاحت کریں اور کیلکولیشن گروپس کو خصوصی طور پر ہمہ وقتی ذہانت اور موازنہ منطق کے لیے استعمال کریں۔