پاور BI میں جامع ماڈلز: امپورٹ اور ڈائریکٹ کوری کو ملانا

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

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

اہم ٹیک ویز

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

---

سٹوریج موڈز: امپورٹ، ڈائریکٹ کیوری، اور ڈوئل

جامع ماڈل کو سمجھنے سے پہلے، ہر اسٹوریج موڈ کو انفرادی طور پر سمجھنا ضروری ہے۔

درآمد موڈ سورس سسٹم سے ڈیٹا کو Power BI کے ان میموری VertiPaq اسٹوریج انجن میں لوڈ کرتا ہے۔ ڈیٹا کو کمپریس کیا جاتا ہے (اکثر 10:1 یا اس سے بہتر) اور کالم ڈیٹا کے طور پر ذخیرہ کیا جاتا ہے جو تجزیاتی سوالات کو انتہائی تیزی سے انجام دیتا ہے — عام طور پر ڈیٹا سیٹس پر سیکڑوں لاکھوں قطاروں تک کے زیادہ تر سوالات کے لیے ملی سیکنڈ۔ حد: ڈیٹا صرف اتنا ہی تازہ ہے جتنا آخری شیڈول یا مینوئل ریفریش۔

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

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

---

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

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

مکمل ماڈلز استعمال کریں جب:

مکمل ماڈل استعمال نہ کریں جب:

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

---

اسٹوریج کے طریقوں کو ترتیب دینا

پاور BI ڈیسک ٹاپ میں، اسٹوریج موڈ فی ٹیبل سیٹ کیا جاتا ہے۔ ماڈل ویو → پراپرٹیز → ایڈوانسڈ → اسٹوریج موڈ میں ٹیبل پر دائیں کلک کریں۔

DirectQuery میں ایک بڑے فیکٹ ٹیبل کے ساتھ ایک عام کمپوزٹ ماڈل کے لیے اور امپورٹ میں ڈائمینشنز:

1. سیٹ کریں FactSales → اسٹوریج موڈ: DirectQuery
2. DimDate → سٹوریج موڈ سیٹ کریں: Dual (درآمد اور DirectQuery دونوں سوالات کو پیش کرتا ہے)
3. DimProduct → سٹوریج موڈ سیٹ کریں: درآمد کریں (چھوٹی میز، مکمل طور پر کیشڈ)
4. سیٹ کریں DimCustomer → اسٹوریج موڈ: Dual (کراس سورس تعلقات میں استعمال کیا جاتا ہے)
5. سیٹ کریں RealtimeSales (آج کا ڈیٹا) → اسٹوریج موڈ: DirectQuery

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

---

جامع ماڈلز میں تعلقات

مختلف سٹوریج طریقوں کی جدولوں کے درمیان تعلقات ایک ہی موڈ کے تعلقات سے مختلف طریقے سے برتاؤ کرتے ہیں، اور ان اختلافات کو سمجھنا ایسے ماڈلز کی تعمیر کے لیے اہم ہے جو درست نتائج پیدا کرتے ہیں۔

باقاعدہ تعلقات دو جدولوں کو جوڑتے ہیں جہاں "متعدد" سائیڈ فلٹر کرنے کے لیے "ایک" سائیڈ کا استعمال کر سکتی ہے۔ درآمدی ماڈلز میں، دونوں میزیں میموری میں ہیں اور رشتہ میموری میں انجام دیتا ہے — تیز۔ ایک امپورٹ ٹیبل اور ایک DirectQuery ٹیبل والے کمپوزٹ ماڈلز میں، تعلق ایک ٹیبل کے ٹیبل اسکین کا سبب بنتا ہے جسے پھر دوسرے کو فلٹر کرنے کے لیے استعمال کیا جاتا ہے — ممکنہ طور پر بڑے کراس موڈ سوالات پیدا کرنا۔

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

کراس سورس تعلقات بالکل مختلف ڈیٹا ذرائع سے ٹیبلز کو جوڑتے ہیں (مثال کے طور پر، SQL سرور سے ایک ٹیبل DirectQuery کے ذریعے منسلک ہوتا ہے اور Salesforce سے ایک ٹیبل کسی دوسرے DirectQuery کنکشن کے ذریعے منسلک ہوتا ہے)۔ ان رشتوں کے لیے ایک طرف کا ڈوئل موڈ ٹیبل ہونا ضروری ہوتا ہے — پاور BI کی ضرورت ہوتی ہے کہ وہ رشتے کے ایک رخ کو دوسرے سے جوڑنے کے لیے میموری میں موجود ہو۔

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

---

جمع کرنے کی میزیں: بنیادی جامع ماڈل پیٹرن

سب سے قیمتی کمپوزٹ ماڈل پیٹرن ایک بڑے DirectQuery فیکٹ ٹیبل کو امپورٹ موڈ ایگریگیشن ٹیبل کے ساتھ جوڑتا ہے جو پہلے سے ڈیٹا کا خلاصہ کرتا ہے۔

مسئلہ: DirectQuery میں ایک 500 ملین قطار سیلز فیکٹ ٹیبل زیادہ تر سورس سسٹمز کے لیے انٹرایکٹو طریقے سے استفسار کرنے کے لیے بہت بڑا ہے — ہر چارٹ میں 10+ سیکنڈ لگتے ہیں کیونکہ سورس مہنگے مجموعی سوالات کو انجام دیتا ہے۔

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

مجموعوں کو ترتیب دینا:

سب سے پہلے، اپنے ڈیٹا گودام میں ایگریگیشن ٹیبل بنائیں:

CREATE TABLE SalesByDayProduct AS
SELECT
    SaleDateKey,
    ProductKey,
    CustomerSegmentKey,
    RegionKey,
    SUM(SalesAmount) as SalesAmount,
    SUM(Quantity) as Quantity,
    SUM(Cost) as Cost,
    COUNT(*) as TransactionCount
FROM FactSales
GROUP BY SaleDateKey, ProductKey, CustomerSegmentKey, RegionKey;

اس ٹیبل کو پاور BI میں درآمد کریں اور اسٹوریج موڈ کو درآمد پر سیٹ کریں۔

پھر، پاور BI میں جمع کو ترتیب دیں:

• دائیں کلک کریں SalesByDayProduct → مجموعوں کا نظم کریں۔
• ہر کالم کو تفصیلی جدول اور خلاصہ فنکشن کے ساتھ اس کے تعلق کے مطابق نقشہ بنائیں (رقم، اوسط، شمار، وغیرہ)
• "خلاصہ" کالم سیٹ کریں (SalesAmount → Sum Maps to FactSales[SalesAmount] → Sum)

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

کارکردگی کا نتیجہ ڈرامائی ہے: زمرہ کی سطح اور وقت کی سطح کے مجموعے جو پہلے 15 سیکنڈ لیتے تھے اب 1 سیکنڈ سے کم میں واپس آتے ہیں، جبکہ انفرادی لین دین کے لیے ڈرل کرنے کا اختیار دستیاب رہتا ہے۔

---

پاور BI ڈیٹاسیٹس کے لیے DirectQuery

Power BI نے Power BI ڈیٹاسیٹس کے لیے DirectQuery متعارف کرایا (جسے "مشترکہ ماڈلز کے ساتھ لائیو کنکشن" یا صرف "مشترکہ ڈیٹاسیٹس پر جامع ماڈلز" بھی کہا جاتا ہے)۔ یہ ایک ڈویلپر کو ایک نئی رپورٹ یا ڈیٹاسیٹ بنانے کی اجازت دیتا ہے جو موجودہ شائع شدہ Power BI ڈیٹاسیٹ کو DirectQuery ماخذ کے طور پر استعمال کرتا ہے — نئے ٹیبلز، حسابی اقدامات، اور مقامی درآمدی ڈیٹا شامل کرتے ہوئے۔

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

یہ ایک زیر انتظام تجزیاتی فن تعمیر کو قابل بناتا ہے جہاں:

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

حدودات: Power BI ڈیٹاسیٹس کے لیے DirectQuery کو باقاعدہ DirectQuery کی تمام حدود وراثت میں ملتی ہیں — کچھ DAX فنکشنز محدود ہیں، جامع ماڈل کے ذریعے پروپیگنڈے کے لیے قطار کی سطح کی سیکیورٹی کو مناسب طریقے سے کنفیگر کیا جانا چاہیے، اور ماخذ ڈیٹاسیٹ سے کنکشن استفسار کی پروسیسنگ کی ایک پرت کو جوڑتا ہے۔

---

جامع ماڈلز کے لیے کارکردگی کی اصلاح

کمپوزٹ ماڈلز کو خالص درآمدی ماڈلز کے مقابلے زیادہ محتاط کارکردگی ٹیوننگ کی ضرورت ہوتی ہے۔ درج ذیل اصلاحیں سب سے زیادہ مؤثر ہیں:

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

ماخذ پر پہلے سے جمع کریں: DirectQuery ماخذ سے وہ مجموعے کرنے کے لیے نہ کہیں جو Power BI زیادہ مؤثر طریقے سے کر سکتا ہے۔ ماخذ ڈیٹابیس میں آراء یا مادی نظریات بنائیں جو آپ کی رپورٹوں کو درحقیقت درکار اناج پر پہلے سے جمع کریں۔

پرفارمنس اینالائزر کے ساتھ استفسار کے پلان کی نگرانی کریں: پاور BI ڈیسک ٹاپ میں، View → پرفارمنس اینالائزر ہر بصری کے DAX استفسار اور اس کے بعد کے سورس استفسار (اگر DirectQuery ہو) کے لیے لگنے والے وقت کو ریکارڈ کرتا ہے۔ اس سے پتہ چلتا ہے کہ کون سے بصری سست ہیں اور آیا سست استفسار DAX پرت میں ہے یا سورس استفسار پرت میں۔

استفسار میں کمی کی ترتیبات کا استعمال کریں: پاور BI ڈیسک ٹاپ → اختیارات → سوال میں کمی، سلائسرز اور فلٹرز میں اپلائی بٹن شامل کرنے کے لیے آپشنز کو فعال کریں۔ یہ ہر سلیسر کے تعامل کو فوری طور پر سورس استفسار کو فائر کرنے سے روکتا ہے — خاص طور پر DirectQuery رپورٹس کے لیے اہم جہاں ہر استفسار میں نیٹ ورک اور سورس ایگزیکیوشن میں تاخیر ہوتی ہے۔

DirectQuery کنکشنز کی تعداد کو محدود کریں: جامع ماڈل میں ہر مختلف DirectQuery ذریعہ ایک علیحدہ کنکشن پول بناتا ہے۔ جہاں ممکن ہو 1–2 DirectQuery ذرائع تک محدود رکھیں۔ 3 سے زیادہ ماڈل کی پیچیدگی اور ممکنہ کارکردگی کے مسائل کو نمایاں طور پر بڑھاتا ہے۔

---

جامع ماڈلز میں قطار کی سطح کی سیکیورٹی

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

جب RLS فلٹر والا صارف کسی رپورٹ سے استفسار کرتا ہے، پاور BI فلٹر کو مناسب ٹیبل پر لاگو کرتا ہے۔ اگر فلٹر شدہ ٹیبل امپورٹ موڈ میں ہے اور اس کا تعلق DirectQuery ٹیبل سے ہے، تو Power BI کو امپورٹ فلٹر کو فلٹر میں ترجمہ کرنا چاہیے جسے DirectQuery سورس کو بھیجا جا سکتا ہے۔ یہ زیادہ تر معاملات میں کام کرتا ہے لیکن پیچیدہ فلٹر درجہ بندی کے ساتھ غیر متوقع نتائج پیدا کر سکتا ہے۔

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

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

---

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

کیا میں ایک جامع ماڈل میں مکمل طور پر مختلف ڈیٹا بیس پلیٹ فارمز سے ڈیٹا ملا سکتا ہوں؟

جی ہاں ایک جامع ماڈل میں بیک وقت SQL سرور (DirectQuery)، Salesforce (DirectQuery)، Azure Blob Storage فائل (Import) اور Snowflake (DirectQuery) کی میزیں شامل ہوسکتی ہیں۔ ہر ذریعہ اپنا تعلق برقرار رکھتا ہے۔ مختلف ذرائع سے جدولوں کے درمیان تعلقات میں کم از کم ایک ڈوئل موڈ ٹیبل ہونا ضروری ہے تاکہ کراس سورس جوائن کرنے میں آسانی ہو۔ ہر اضافی ماخذ کے ساتھ کارکردگی اور پیچیدگی میں اضافہ ہوتا ہے — 2–3 ذرائع تک محدود کرنا زیادہ تر نفاذ کے لیے عملی ہے۔

جامع ماڈلز میں کون سے DAX فنکشنز کام نہیں کرتے؟

کچھ DAX فنکشنز محدود ہیں یا DirectQuery ٹیبلز والے جامع ماڈلز میں مختلف طریقے سے برتاؤ کرتے ہیں۔ وہ فنکشنز جو محدود رشتوں کے ساتھ کام نہیں کرتے ہیں ان میں SUMMARIZE (مخصوص سیاق و سباق میں)، TOPN (DirectQuery ٹیبلز پر)، اور کچھ وقت کے انٹیلی جنس فنکشنز شامل ہیں۔ USERELATIONSHIP کام کرتا ہے لیکن کراس موڈ سوالات کا سبب بن سکتا ہے۔ حدود کی مکمل فہرست مائیکروسافٹ کے پاور BI دستاویزات میں "DirectQuery حدود" کے تحت درج ہے۔ DirectQuery ٹیبلز کو شامل کرنے کے بعد تمام اہم اقدامات کی جانچ کی سختی سے سفارش کی جاتی ہے۔

کمپوزیٹ ماڈلز کے ساتھ اضافی ریفریش کیسے کام کرتا ہے؟

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

جامع ماڈلز بمقابلہ خالص درآمد کی کارکردگی کا کیا اثر ہے؟

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

کیا مجھے کمپوزٹ ماڈل استعمال کرنے چاہئیں یا زیادہ بار بار ریفریشز کا شیڈول بنانا چاہیے؟

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

---

اگلے اقدامات

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

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