تجمع های تعریف شده توسط کاربر

تجمع در Power BI می تواند عملکرد پرس و جو را در مجموعه داده های بسیار بزرگ DirectQuery بهبود بخشد. با استفاده از تجمع ، داده های ذخیره شده در سطح جمع شده در حافظه را ذخیره می کنید. جمع آوری در Power BI می تواند به صورت دستی در مدل داده ، همانطور که در این مقاله توضیح داده شده است ، یا برای اشتراک های حق بیمه ، به طور خودکار با فعال کردن ویژگی جمع آوری خودکار در تنظیمات مجموعه داده ها تنظیم شود.

ایجاد جداول تجمیع

بسته به نوع منبع داده ، می توان یک جدول جمع آوری را در منبع داده به عنوان یک جدول یا نمای ، به عنوان یک پرس و جو بومی یا برای بیشترین عملکرد به عنوان جدول وارداتی ایجاد شده در پرس و جو ایجاد کرد. سپس از گفتگوی مدیریت تجمع در دسک تاپ Power BI استفاده می کنید تا تجمع ستونهای تجمع با خلاصه ، جدول جزئیات و خصوصیات ستون جزئیات را تعریف کنید.

منابع داده بعدی ، مانند انبارهای داده و مارت های داده ، می توانند از تجمع مبتنی بر روابط استفاده کنند. منابع بزرگ داده های مبتنی بر Hadoop غالباً جمع آوری های پایه را در ستون های Groupby قرار می دهند. در این مقاله تفاوت های مدل سازی داده های BI معمولی برای هر نوع منبع داده شرح داده شده است.

تجمع ها را مدیریت کنید

در صفحه زمینه از هر نمای دسک تاپ قدرت BI ، روی جدول جمع آوری راست کلیک کرده و سپس مدیریت مصالح را انتخاب کنید.

گفتگوی Manage Eggregations یک ردیف برای هر ستون در جدول نشان می دهد ، جایی که می توانید رفتار جمع را مشخص کنید. در مثال زیر ، نمایش داده شدگان به جدول جزئیات فروش از نظر داخلی به جدول جمع آوری Agg Sales هدایت می شوند.

در این مثال تجمع مبتنی بر رابطه ، ورودی های Groupby اختیاری هستند. به جز مجزا ، آنها بر رفتار تجمع تأثیر نمی گذارند و در درجه اول برای خوانایی هستند. بدون ورود گروه های گروهی ، بر اساس روابط ، جمع آوری ها همچنان مورد ضرب و شتم قرار می گیرند. این با مثال داده های بزرگ بعداً در این مقاله متفاوت است ، جایی که به ورودی های Groupby نیاز است.

اعتبار سنجی

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

• ستون جزئیات باید دارای همان مجموعه ای از ستون جمع آوری باشد ، به جز توابع جمع آوری ردیف های شمارش و شمارش. ردیف های جدول شمارش و شمارش فقط برای ستون های جمع آوری عدد صحیح در دسترس هستند و نیازی به یک داده تطبیق ندارند.
• جمع های زنجیره ای که سه یا چند میز را پوشش می دهد مجاز نیست. به عنوان مثال ، تجمع در جدول A نمی تواند به جدول B مراجعه کند که دارای تجمع های مربوط به جدول c است.
• تجمع های تکراری ، که در آن دو مدخل از همان عملکرد جمع بندی استفاده می کنند و به جدول جزئیات و ستون جزئیات یکسان مراجعه می کنند ، مجاز نیستند.
• جدول جزئیات باید از حالت ذخیره سازی DirectQuery استفاده کند ، نه واردات.
• گروه بندی توسط یک ستون کلید خارجی که توسط یک رابطه غیرفعال استفاده می شود و با تکیه بر عملکرد کاربر برای بازدیدهای تجمع ، پشتیبانی نمی شود.
• تجمع های مبتنی بر ستون های GroupBy می تواند روابط بین جداول تجمیع را افزایش دهد اما تألیف روابط بین جداول تجمع در دسک تاپ قدرت BI پشتیبانی نمی شود. در صورت لزوم ، می توانید با استفاده از یک ابزار شخص ثالث یا یک راه حل اسکریپت از طریق نقاط پایانی XMLA ، بین جداول تجمع برقرار کنید.

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

جداول تجمیع پنهان است

کاربران با دسترسی فقط خواندنی به مجموعه داده نمی توانند جداول جمع آوری را پرس و جو کنند. این از نگرانی های امنیتی در هنگام استفاده از امنیت سطح ردیف (RLS) جلوگیری می کند. مصرف کنندگان و نمایش داده ها به جدول جزئیات و نه جدول جمع آوری اشاره دارند و نیازی به دانستن در مورد جدول جمع آوری ندارند.

به همین دلیل ، جداول تجمع از نمای گزارش پنهان است. اگر جدول از قبل پنهان نشده باشد ، گفتگوی مدیریت جمع آوری هنگام انتخاب همه ، آن را پنهان می کند.

حالتهای ذخیره سازی

ویژگی جمع آوری با حالت های ذخیره سازی سطح جدول تعامل دارد. جداول Power BI می تواند از حالت های DirectQuery ، Import یا Dual Storage استفاده کند. DirectQuery پرس و بخش را به طور مستقیم پرس و جو می کند ، در حالی که داده های ذخیره را در حافظه ذخیره می کند و نمایش داده ها را به داده های ذخیره شده ارسال می کند. تمام واردات BI Power BI و منابع داده غیرقانونی غیرقانونی می توانند با تجمع کار کنند.

برای تنظیم حالت ذخیره سازی یک جدول جمع شده برای واردات برای سرعت بخشیدن به نمایش داده ها ، جدول جمع شده را در نمای مدل دسک تاپ Power BI انتخاب کنید. در صفحه Properties ، پیشرفته را گسترش دهید ، انتخاب را در حالت ذخیره سازی پایین بیاورید و واردات را انتخاب کنید. توجه داشته باشید که این عمل غیرقابل برگشت است.

برای کسب اطلاعات بیشتر در مورد حالت های ذخیره سازی جدول ، به مدیریت حالت ذخیره سازی در دسک تاپ Power BI مراجعه کنید.

RL برای جمع آوری

برای کار صحیح برای جمع آوری ، عبارات RLS باید هم جدول جمع آوری و هم جدول جزئیات را فیلتر کند.

در مثال زیر ، بیان RLS در جدول جغرافیا برای تجمع کار می کند ، زیرا جغرافیا در سمت فیلتر روابط با جدول فروش و جدول فروش AGG قرار دارد. نمایش داده شده هایی که به جدول جمع آوری رسیده اند و مواردی که هر دو RL را با موفقیت اعمال نمی کنند.

عبارت RLS در جدول Product فقط جدول فروش جزئیات را فیلتر می کند، نه جدول فروش انبوه. از آنجایی که جدول تجمیع نمایش دیگری از داده ها در جدول جزئیات است، اگر فیلتر RLS نمی تواند اعمال شود، پاسخگویی به پرسش های جدول تجمیع ناامن است. فیلتر کردن فقط جدول جزئیات توصیه نمی شود، زیرا درخواست های کاربر از این نقش از بازدیدهای تجمیع سودی نخواهند برد.

عبارت RLS که فقط جدول تجمیع Sales Agg و نه جدول جزئیات فروش را فیلتر می کند، مجاز نیست.

برای تجمیع های مبتنی بر ستون های GroupBy، یک عبارت RLS اعمال شده در جدول جزئیات می تواند برای فیلتر کردن جدول تجمیع استفاده شود، زیرا تمام ستون های GroupBy در جدول تجمیع توسط جدول جزئیات پوشش داده می شوند. از طرف دیگر، یک فیلتر RLS در جدول تجمیع نمی تواند در جدول جزئیات اعمال شود، بنابراین غیرمجاز است.

تجمیع بر اساس روابط

مدل های بعدی معمولاً از تجمیع بر اساس روابط استفاده می کنند. مجموعه داده های Power BI از انبارهای داده و مارت های داده شبیه طرح واره های ستاره/دانه برف، با روابط بین جداول ابعاد و جداول واقعیت است.

در مثال زیر، مدل داده ها را از یک منبع داده دریافت می کند. جداول از حالت ذخیره سازی DirectQuery استفاده می کنند. جدول واقعیت فروش شامل میلیاردها ردیف است. تنظیم حالت ذخیره سازی Sales روی Import برای ذخیره سازی حافظه و منابع قابل توجهی را مصرف می کند.

در عوض، جدول تجمیع Sales Agg را ایجاد کنید. در جدول Sales Agg، تعداد ردیف ها برابر است با مجموع SalesAmount گروه بندی شده توسط CustomerKey، DateKey و ProductSubcategoryKey. جدول Sales Agg از جزئیات بالاتری نسبت به Sales برخوردار است، بنابراین به جای میلیاردها، ممکن است حاوی میلیون ها ردیف باشد که مدیریت آنها بسیار آسان تر است.

اگر جداول ابعاد زیر بیشترین استفاده را برای جستارهایی با ارزش تجاری بالا دارند، می توانند Sales Agg را با استفاده از روابط یک به چند یا چند به یک فیلتر کنند.

• جغرافیا
• مشتری
• تاریخ
• زیر مجموعه محصول
• رده محصولات

تصویر زیر این مدل را نشان می دهد.

جدول زیر تجمیع جدول فروش Agg را نشان می دهد.

جدول Sales Agg ، مانند هر جدول ، انعطاف پذیری بارگذاری شده به روش های مختلف را دارد. تجمع را می توان در پایگاه داده منبع با استفاده از فرآیندهای ETL/ELT یا با بیان M برای جدول انجام داد. جدول جمع آوری شده می تواند از حالت ذخیره واردات ، با یا بدون تجدید افزایشی برای مجموعه داده ها استفاده کند ، یا می تواند از DirectQuery استفاده کند و برای نمایش سریع با استفاده از شاخص های ستون بهینه سازی شود. این انعطاف پذیری باعث می شود معماری های متعادل که می توانند بار پرس و جو را برای جلوگیری از تنگناها گسترش دهند.

تغییر حالت ذخیره سازی جدول فروش جمع شده AGG برای وارد کردن یک کادر گفتگو را باز می کند و می گوید جداول ابعاد مرتبط را می توان روی حالت ذخیره سازی دوگانه تنظیم کرد.

تنظیم جداول ابعاد مرتبط به دوگانه ، بسته به زیرمجاز ، به آنها اجازه می دهد تا به عنوان واردات یا کارگردانی عمل کنند. در مثال:

• نمایش داده شدی که معیارهای کل از جدول فروش حالت واردات AGG و گروه را بر اساس ویژگی (ها) از جداول دوگانه مربوطه ، از حافظه نهان حافظه باز می گردانند.
• نمایش داده شدی که معیارهای جمع شده از جدول فروش DirectQuery و گروه بر اساس ویژگی (ها) از جداول دوگانه مربوطه ، می توانند در حالت DirectQuery برگردانده شوند. منطق پرس و جو ، از جمله عملیات Groupby ، به پایگاه داده منبع منتقل می شود.

برای کسب اطلاعات بیشتر در مورد حالت ذخیره سازی دوگانه ، به مدیریت حالت ذخیره سازی در دسک تاپ Power BI مراجعه کنید.

روابط منظم در مقابل محدود

بازدیدهای تجمع بر اساس روابط نیاز به روابط منظم دارد.

روابط منظم شامل ترکیبات حالت ذخیره سازی زیر است ، جایی که هر دو جدول از یک منبع واحد هستند:

تنها موردی که یک رابطه متقاطع به طور منظم در نظر گرفته می شود ، در صورت قرار دادن هر دو جدول برای واردات است. روابط بسیاری به بسیاری همیشه محدود تلقی می شود.

برای بازدیدهای جمع آوری منبع متقابل که به روابط بستگی ندارند ، به جمع آوری های مبتنی بر ستون های Groupby مراجعه کنید.

نمونه های پرس و جو جمع آوری مبتنی بر روابط

پرس و جو زیر به تجمع می رسد ، زیرا ستون های جدول تاریخ در دانه ای قرار دارند که می توانند به تجمع ضربه بزنند. ستون SalesAmount از جمع جمع استفاده می کند.

پرس و جو زیر به تجمع نمی رسد. علیرغم درخواست مبلغ SalesAmount ، این پرس و جو در حال انجام یک عملیات Groupby بر روی یک ستون در جدول محصول است که در این دانه نیست که می تواند به جمع آوری برسد. اگر روابط موجود در مدل را رعایت کنید ، یک زیر مجموعه محصول می تواند چندین ردیف محصول داشته باشد. پرس و جو قادر به تعیین کدام محصول برای جمع آوری نیست. در این حالت ، پرس و جو به DirectQuery باز می گردد و یک پرس و جو SQL را به منبع داده ارسال می کند.

تجمع فقط برای محاسبات ساده نیست که مبلغ ساده ای را انجام می دهند. محاسبات پیچیده همچنین می تواند سود ببرد. از نظر مفهومی ، یک محاسبه پیچیده برای هر مبلغ ، حداقل ، حداکثر و شمارش به زیرمجموعه ها تقسیم می شود و هر زیرمجموعه برای تعیین اینکه آیا می تواند به جمع برخورد کند ، ارزیابی می شود. این منطق در همه موارد به دلیل بهینه سازی برنامه پرس و جو صادق نیست ، اما به طور کلی باید اعمال شود. مثال زیر به جمع می رسد:

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

عملکرد متوسط می تواند از تجمع بهره مند شود. پرس و جو زیر به تجمع می رسد زیرا میانگین داخلی به مبلغی تقسیم می شود که توسط یک شمارش تقسیم می شود. از آنجا که ستون UnitPrice دارای تجمع های تعریف شده برای جمع و تعداد است ، جمع آوری شده است.

در بعضی موارد ، عملکرد متمایز می تواند از تجمع بهره مند شود. پرس و جو زیر به تجمع می رسد زیرا یک گروه Groupby برای CustomerKey وجود دارد ، که متمایز بودن کلید مشتری را در جدول جمع آوری حفظ می کند. این تکنیک هنوز هم ممکن است به آستانه عملکرد ضربه بزند که در آن بیش از دو تا پنج میلیون ارزش متمایز می تواند بر عملکرد پرس و جو تأثیر بگذارد. با این حال ، می تواند در سناریوهایی که در جدول جزئیات میلیاردها ردیف وجود دارد ، مفید باشد ، اما دو تا پنج میلیون مقدار مجزا در ستون. در این حالت ، متمایز می تواند سریعتر از اسکن جدول با میلیاردها ردیف عمل کند ، حتی اگر در حافظه ذخیره شود.

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

تجمع بر اساس ستون های Groupby

مدل های بزرگ داده مبتنی بر Hadoop دارای ویژگی های متفاوتی نسبت به مدل های بعدی هستند. برای جلوگیری از پیوستن بین جداول بزرگ ، مدل های داده بزرگ اغلب از روابط استفاده نمی کنند ، اما ویژگی های ابعاد را به جداول واقعیت تبدیل می کنند. شما می توانید با استفاده از تجمع بر اساس ستون های Groupby ، چنین مدل های داده بزرگی را برای تجزیه و تحلیل تعاملی باز کنید.

جدول زیر شامل ستون عددی حرکتی است که جمع می شود. تمام ستون های دیگر ویژگی های گروهی هستند. جدول شامل داده های IoT و تعداد زیادی ردیف است. حالت ذخیره سازی DirectQuery است. نمایش داده شد در مورد منبع داده ای که در کل مجموعه داده ها جمع می شوند به دلیل حجم کامل ، کند هستند.

برای فعال کردن تجزیه و تحلیل تعاملی در این مجموعه داده ، می توانید یک جدول تجمع را اضافه کنید که توسط بیشتر ویژگی ها گروه ها را گروه بندی می کند ، اما ویژگی های مربوط به سایت بالا مانند طول و عرض جغرافیایی را حذف نمی کند. این امر به طرز چشمگیری تعداد ردیف ها را کاهش می دهد و به اندازه کافی کوچک است که به راحتی در حافظه نهان حافظه قرار می گیرد.

شما نگاشتهای تجمیع را برای جدول AGG فعالیت درایور در گفتگوی مدیریت تجمع تعریف می کنید.

در تجمع های مبتنی بر ستون های Groupby ، ورودی های Groupby اختیاری نیستند. بدون آنها ، جمع بندی ها مورد ضرب و شتم قرار نمی گیرند. این متفاوت از استفاده از تجمع مبتنی بر روابط است ، جایی که ورودی های Groupby اختیاری هستند.

در جدول زیر ، جمع بندی های مربوط به فعالیت درایور جدول AGG نشان داده شده است.

می توانید حالت ذخیره سازی فعالیت درایور جمع شده جدول AGG را وارد کنید.

مثال پرس و جو جمع آوری گروه

پرس و جو زیر به تجمع می رسد ، زیرا ستون تاریخ فعالیت توسط جدول تجمع پوشانده شده است. عملکرد Countrows از جمع آوری ردیف های جدول Count استفاده می کند.

به خصوص برای مدلهایی که حاوی ویژگی های فیلتر در جداول در واقع هستند ، استفاده از تجمع ردیف های جدول شمارش خوب است. Power BI ممکن است در مواردی که به صراحت توسط کاربر درخواست نشده است ، نمایش داده شد. به عنوان مثال ، گفتگوی فیلتر تعداد ردیف ها را برای هر مقدار نشان می دهد.

تکنیک های جمع آوری ترکیبی

شما می توانید روابط و تکنیک های ستون های Groupby را برای جمع آوری ترکیب کنید. تجمع مبتنی بر روابط ممکن است نیاز به جداول ابعاد denormalized به چند جدول داشته باشد. اگر این برای جداول ابعاد خاص پرهزینه یا غیر عملی است ، می توانید ویژگی های لازم را در جدول جمع آوری برای آن ابعاد تکرار کنید و از روابط برای دیگران استفاده کنید.

به عنوان مثال ، مدل زیر در جدول فروش AGG ماه ، سه ماه ، ترم و سال را تکرار می کند. هیچ ارتباطی بین فروش AGG و جدول تاریخ وجود ندارد ، اما روابط با زیر مجموعه مشتری و محصول وجود دارد. شیوه ذخیره سازی فروش Agg واردات است.

در جدول زیر مطالب تعیین شده در گفتگوی مدیریت جمع آوری جدول AGG نمایش داده شده است. گروه های گروهی که در آن تاریخ جدول جزئیات اجباری است ، برای جمع آوری تعداد نمایش داده هایی که توسط ویژگی های تاریخ گروه می شوند ، اجباری است. همانطور که در مثال قبلی ، ورود Groupby برای CustomerKey و ProductUbcategorkey به دلیل وجود روابط ، بر بازدیدهای تجمع تأثیر نمی گذارد.

نمونه های پرس و جو جمع آوری ترکیبی

پرس و جو زیر به تجمع می رسد ، زیرا جدول جمع آوری Calendarmonth را شامل می شود ، و نام طبقه بندی از طریق روابط یک به یک در دسترس است. SalesAmount از جمع جمع استفاده می کند.

پرس و جو زیر به تجمع نمی رسد ، زیرا جدول جمع آوری تقویم را پوشش نمی دهد.

پرس و جو اطلاعاتی در زمان بعد به تجمع نمی رسد ، زیرا عملکرد DateYTD یک جدول از مقادیر تقویم ایجاد می کند ، و جدول جمع آوری تقویم را پوشش نمی دهد.

تقدم تجمیع

تقدم تجمیع اجازه می دهد تا جداول تجمیع چندگانه توسط یک زیرمجموعه واحد در نظر گرفته شود.

مثال زیر یک مدل کامپوزیت است که حاوی چندین منبع است:

• جدول DirectQuery فعالیت راننده شامل بیش از یک تریلیون ردیف داده های IoT است که از یک سیستم داده بزرگ تهیه شده است. این به نمایش داده های مته برای مشاهده خوانش های IoT فردی در زمینه های فیلتر کنترل شده خدمت می کند.
• جدول فعالیت درایور AGG یک جدول جمع آوری میانی در حالت DirectQuery است. این ماده حاوی بیش از یک میلیارد ردیف در تجزیه و تحلیل Azure Synapse (قبلاً انبار داده SQL) است و با استفاده از شاخص های ستونی در منبع بهینه می شود.
• جدول واردات Agg2 فعالیت راننده در یک دانه بندی بالا قرار دارد ، زیرا ویژگی های گروهی به صورت کم و کم کاردینال است. تعداد ردیف ها می تواند به اندازه هزاران نفر باشد ، بنابراین می تواند به راحتی در حافظه نهان حافظه قرار بگیرد. این ویژگی ها توسط یک داشبورد اجرایی با مشخصات بالا مورد استفاده قرار می گیرد ، بنابراین نمایش داده شدگان با اشاره به آنها باید به همان سرعت ممکن باشد.

جداول تجمیع DirectQuery که از یک منبع داده متفاوت از جدول جزئیات استفاده می کنند ، فقط در صورتی پشتیبانی می شوند که جدول جمع آوری از یک سرور SQL ، Azure SQL یا Azure Synapse Analytics (قبلاً انبار داده SQL) باشد.

ردپای حافظه این مدل نسبتاً کوچک است ، اما یک مجموعه داده عظیم را باز می کند. این یک معماری متعادل را نشان می دهد زیرا بار پرس و جو را در اجزای معماری گسترش می دهد و بر اساس نقاط قوت آنها از آنها استفاده می کند.

گفتگوی مدیریت تجمع برای فعالیت درایور AGG2 زمینه تقدم را به 10 تنظیم می کند ، که بالاتر از فعالیت راننده AGG است. تنظیم برتری بالاتر به معنای نمایش داده هایی است که از تجمع استفاده می کنند ، فعالیت راننده را ابتدا AGG2 در نظر می گیرند. زیرمجموعه هایی که در گرانول بودن نیستند که با فعالیت راننده AGG2 قابل پاسخ است ، فعالیت راننده را به جای آن در نظر می گیرد. نمایش داده شدگان جزئیات که توسط هر یک از جدول جمع آوری قابل پاسخ نیست ، به فعالیت راننده هدایت می شود.

جدول مشخص شده در ستون جزئیات ، فعالیت درایور است ، نه فعالیت درایور AGG ، زیرا تجمع زنجیر شده مجاز نیست.

در جدول زیر ، جمع بندی های مربوط به فعالیت درایور AGG2 جدول نشان داده شده است.

تشخیص دهید که آیا نمایش داده شد یا تجمع

SQL Profiler می تواند تشخیص دهد که آیا نمایش داده ها از موتور ذخیره سازی حافظه نهان در حافظه بازگردانده می شوند یا توسط DirectQuery به منبع داده منتقل می شوند. شما می توانید از همان فرآیند استفاده کنید تا تشخیص دهید که آیا تجمع مورد اصابت قرار می گیرد. برای اطلاعات بیشتر ، به نمایش داده هایی که در حافظه نهان زده یا از دست می دهند ، مراجعه کنید.

SQL Profiler همچنین پردازش پرس و جو جدول بازنویسی بازنویسی پرس و جو را ارائه می دهد.

قطعه JSON زیر نمونه ای از خروجی این رویداد را هنگام استفاده از تجمع نشان می دهد.

• تطبیق دهنده نشان می دهد که زیرمجموعه از تجمع استفاده می کند.
• DataRequest ستون (ها) و ستون (های) جمع شده را نشان می دهد که زیرمجموعه مورد استفاده قرار می گیرد.
• نقشه برداری ستون های موجود در جدول تجمع را نشان می دهد که در آن نقشه برداری شده اند.

انبارها را در همگام نگه دارید

تجمع هایی که با ترکیب حالت های DirectQuery ، Import و/یا Dual Storage ممکن است داده های مختلفی را بازگرداند مگر اینکه حافظه نهان حافظه در همگام سازی با داده های منبع نگه داشته شود. به عنوان مثال ، اجرای Query با فیلتر کردن نتایج DirectQuery برای مطابقت با مقادیر ذخیره شده ، سعی در ماسک مشکلات داده نخواهد کرد. در صورت لزوم تکنیک هایی برای رسیدگی به چنین مواردی در منبع وجود دارد. بهینه سازی عملکرد فقط باید به روش هایی استفاده شود که توانایی شما در برآورده کردن نیازهای تجاری را به خطر نمی اندازد. این وظیفه شماست که جریان داده های خود را بدانید و بر این اساس طراحی کنید.

ملاحظات و محدودیت ها

• تجمع از پارامترهای پرس و جو پویا پشتیبانی نمی کند.
• با شروع اوت 2022 ، به دلیل تغییر در عملکرد ، Power BI جداول تجمع حالت واردات را با منابع داده با قابلیت SSO به دلیل خطرات امنیتی بالقوه نادیده می گیرد. برای اطمینان از عملکرد بهینه پرس و جو با جمع ، توصیه می شود SSO را برای این منابع داده غیرفعال کنید.

انجمن

Power BI دارای یک جامعه پر جنب و جوش است که در آن MVP ها ، BI Pros و همسالان در گروه های بحث ، فیلم ها ، وبلاگ ها و موارد دیگر تخصص دارند. هنگام یادگیری در مورد تجمع ، حتماً این منابع اضافی را بررسی کنید:

• جامعه قدرت
• "جمع آوری قدرت دو" را در بینگ جستجو کنید