راهنمای مدل DirectQuery در Power BI Desktop

راهنمای مدل DirectQuery در Power BI Desktop

این مقاله، مدل‌سازان داده‌ای را که مدل‌های Power BI DirectQuery را توسعه می‌دهند و با استفاده از Power BI Desktop یا سرویس Power BI توسعه می‌دهند، هدف قرار می‌دهد. این مقاله موارد استفاده، محدودیت‌ها و راهنمایی‌های DirectQuery را شرح می‌دهد. به طور خاص، این راهنما برای کمک به شما در تعیین اینکه آیا DirectQuery حالت مناسبی برای مدل شما است یا خیر، و همچنین برای بهبود عملکرد گزارش‌های شما بر اساس مدل‌های DirectQuery طراحی شده است. این مقاله در مورد مدل‌های DirectQuery میزبانی شده در سرویس Power BI یا Power BI Report Server کاربرد دارد.

این مقاله، استفاده از DirectQuery در سرویس‌های تحلیل SQL Server را شرح می‌دهد. با این حال، بسیاری از مطالب هنوز برای مدل‌های Power BI DirectQuery قابل استفاده هستند.

درک این نکته مهم است که مدل‌های DirectQuery بار کاری متفاوتی را بر محیط Power BI (سرویس Power BI یا Power BI Report Server) و همچنین بر منابع داده زیربنایی تحمیل می‌کنند. اگر تشخیص می‌دهید که DirectQuery رویکرد طراحی مناسبی است، توصیه می‌کنیم افراد مناسب را در پروژه درگیر کنید. ما اغلب می‌بینیم که استقرار موفق مدل DirectQuery نتیجه همکاری نزدیک تیمی از متخصصان فناوری اطلاعات است. این تیم معمولاً متشکل از توسعه‌دهندگان مدل و مدیران پایگاه داده منبع است. همچنین می‌تواند شامل معماران داده، توسعه‌دهندگان انبار داده و ETL باشد. اغلب، برای دستیابی به نتایج عملکرد خوب، بهینه‌سازی‌ها باید مستقیماً بر روی منبع داده اعمال شوند.

بهینه‌سازی عملکرد منبع داده

منبع پایگاه داده رابطه‌ای را می‌توان به روش‌های مختلفی بهینه کرد، همانطور که در لیست زیر توضیح داده شده است.

• اطمینان از کامل بودن یکپارچگی داده‌ها: به ویژه مهم است که جداول بُعد حاوی ستونی از مقادیر منحصر به فرد (کلید بُعد) باشند که به جدول(های) واقعیت نگاشت می‌شوند. همچنین مهم است که ستون‌های بُعد جدول واقعیت حاوی مقادیر کلید بُعد معتبر باشند. آن‌ها امکان پیکربندی روابط مدل کارآمدتری را فراهم می‌کنند که انتظار مقادیر منطبق در هر دو طرف روابط را دارند. هنگامی که داده‌های منبع فاقد یکپارچگی هستند، توصیه می‌شود یک رکورد بُعد “ناشناخته” برای ترمیم مؤثر داده‌ها اضافه شود. به عنوان مثال، می‌توانید یک ردیف به جدول محصول اضافه کنید تا یک محصول ناشناخته را نشان دهد و سپس یک کلید خارج از محدوده، مانند -1، به آن اختصاص دهید. اگر ردیف‌های جدول فروش حاوی یک مقدار کلید محصول گمشده هستند، آن‌ها را با -1 جایگزین کنید. این تضمین می‌کند که هر مقدار کلید محصول جدول فروش یک ردیف مربوطه در جدول محصول دارد.
• اضافه کردن شاخص‌ها: شاخص‌های مناسب – روی جداول یا نماها – را برای پشتیبانی از بازیابی کارآمد داده‌ها برای فیلتر کردن و گروه‌بندی بصری گزارش مورد انتظار، تعریف کنید. برای منابع SQL Server، Azure SQL Database یا Azure Synapse Analytics (که قبلاً SQL Data Warehouse نام داشت).
• طراحی جداول توزیع‌شده: برای منابع Azure Synapse Analytics (که قبلاً SQL Data Warehouse نام داشت)، که از معماری پردازش موازی انبوه (MPP) استفاده می‌کنند، پیکربندی جداول واقعیت بزرگ را به صورت توزیع هش و جداول ابعاد را برای تکرار در تمام گره‌های محاسباتی در نظر بگیرید.

DirectQuery model

• اطمینان از تحقق تبدیل‌های داده‌های مورد نیاز: برای منابع پایگاه داده رابطه‌ای SQL Server (و سایر منابع پایگاه داده رابطه‌ای)، ستون‌های محاسبه‌شده را می‌توان به جداول اضافه کرد. این ستون‌ها بر اساس یک عبارت، مانند Quantity ضرب در UnitPrice هستند. ستون‌های محاسبه‌شده می‌توانند ماندگار (متمرکز) باشند و مانند ستون‌های معمولی، گاهی اوقات می‌توانند شاخص‌گذاری شوند.

همچنین نماهای شاخص‌گذاری‌شده‌ای را در نظر بگیرید که می‌توانند داده‌های جدول واقعیت را با دقت بالاتری از قبل تجمیع کنند. به عنوان مثال، اگر جدول فروش داده‌ها را در سطح خط سفارش ذخیره می‌کند، می‌توانید یک نما برای خلاصه کردن این داده‌ها ایجاد کنید. این نما می‌تواند بر اساس یک دستور SELECT باشد که داده‌های جدول فروش را بر اساس تاریخ (در سطح ماه)، مشتری، محصول گروه‌بندی می‌کند و مقادیر اندازه‌گیری مانند فروش، مقدار و غیره را خلاصه می‌کند. سپس می‌توان این نما را شاخص‌گذاری کرد.

• یک جدول تاریخ را به واقعیت تبدیل کنید: یک الزام مدل‌سازی رایج شامل اضافه کردن یک جدول تاریخ برای پشتیبانی از فیلترینگ مبتنی بر زمان است. برای پشتیبانی از فیلترهای مبتنی بر زمان شناخته‌شده در سازمان خود، یک جدول در پایگاه داده منبع ایجاد کنید و مطمئن شوید که با طیف وسیعی از تاریخ‌ها که شامل تاریخ‌های جدول واقعیت هستند، بارگذاری شده است. همچنین مطمئن شوید که شامل ستون‌هایی برای دوره‌های زمانی مفید، مانند سال، فصل، ماه، هفته و غیره است.

بهینه‌سازی طراحی مدل

یک مدل DirectQuery را می‌توان از بسیاری جهات بهینه کرد، همانطور که در لیست زیر توضیح داده شده است.

• از پرس‌وجوهای پیچیده Power Query اجتناب کنید: با حذف نیاز به اعمال هرگونه تبدیل توسط پرس‌وجوهای Power Query، می‌توان به یک طراحی مدل کارآمد دست یافت. این بدان معناست که هر پرس‌وجو به یک جدول یا نمای منبع پایگاه داده رابطه‌ای واحد نگاشت می‌شود. می‌توانید با انتخاب گزینه View Native Query، پیش‌نمایشی از عبارت پرس‌وجوی SQL واقعی را برای یک مرحله اعمال‌شده توسط Power Query مشاهده کنید.

• استفاده از ستون‌های محاسبه‌شده و تغییرات نوع داده را بررسی کنید: مدل‌های DirectQuery از اضافه کردن محاسبات و مراحل Power Query برای تبدیل انواع داده پشتیبانی می‌کنند. با این حال، عملکرد بهتر اغلب با تحقق نتایج تبدیل در منبع پایگاه داده رابطه‌ای، در صورت امکان، حاصل می‌شود.
• از فیلترینگ نسبی تاریخ Power Query استفاده نکنید: می‌توان فیلترینگ نسبی تاریخ را در یک پرس‌وجوی Power Query تعریف کرد. به عنوان مثال، برای بازیابی سفارشات فروش ایجاد شده در سال گذشته (نسبت به تاریخ امروز). این نوع فیلتر به یک پرس‌وجوی بومی ناکارآمد تبدیل می‌شود، به شرح زیر:

…
from [dbo].[Sales] as [_]
where [_].[OrderDate] >= convert(datetime2, '2018-01-01 00:00:00') and [_].[OrderDate] < convert(datetime2, '2019-01-01 00:00:00'))

یک رویکرد طراحی بهتر، گنجاندن ستون‌های زمان نسبی در جدول تاریخ است. این ستون‌ها مقادیر انحرافی را نسبت به تاریخ فعلی ذخیره می‌کنند. به عنوان مثال، در یک ستون RelativeYear، مقدار صفر نشان دهنده سال جاری، -1 نشان دهنده سال قبل و غیره است. ترجیحاً، ستون RelativeYear در جدول تاریخ نمایش داده می‌شود. اگرچه کارایی کمتری دارد، اما می‌تواند به عنوان یک ستون محاسبه شده مدل، بر اساس عبارت با استفاده از توابع TODAY و DATE DAX نیز اضافه شود.

• اندازه‌ها را ساده نگه دارید: حداقل در ابتدا، توصیه می‌شود اندازه‌ها را به مجموع‌های ساده محدود کنید. توابع مجموع شامل SUM، COUNT، MIN، MAX و AVERAGE هستند. سپس، اگر اندازه‌ها به اندازه کافی پاسخگو باشند، می‌توانید با اندازه‌های پیچیده‌تر آزمایش کنید، اما به عملکرد هر کدام توجه کنید. در حالی که می‌توان از تابع CALCULATE DAX برای تولید عبارات اندازه پیچیده‌ای که زمینه فیلتر را دستکاری می‌کنند استفاده کرد، می‌توانند پرس‌وجوهای بومی پرهزینه‌ای ایجاد کنند که عملکرد خوبی ندارند.
• از روابط روی ستون‌های محاسبه شده خودداری کنید: روابط مدل فقط می‌توانند یک ستون واحد در یک جدول را به یک ستون واحد در جدول دیگری مرتبط کنند. با این حال، گاهی اوقات لازم است جداول را با استفاده از چندین ستون به هم مرتبط کنید. به عنوان مثال، جداول فروش و جغرافیا توسط دو ستون مرتبط هستند: CountryRegion و City. برای ایجاد رابطه بین جداول، یک ستون واحد مورد نیاز است و در جدول جغرافیا، ستون باید حاوی مقادیر منحصر به فرد باشد. اتصال کشور/منطقه و شهر با جداکننده خط تیره می‌تواند به این نتیجه برسد.

DirectQuery Power BI

ستون ترکیبی را می‌توان با یک ستون سفارشی Power Query یا در مدل به عنوان یک ستون محاسبه شده ایجاد کرد. با این حال، باید از آن اجتناب کرد زیرا عبارت محاسبه در کوئری‌های منبع جاسازی می‌شود. این کار نه تنها ناکارآمد است، بلکه معمولاً از استفاده از شاخص‌ها جلوگیری می‌کند. در عوض، ستون‌های مادی را در منبع پایگاه داده رابطه‌ای اضافه کنید و آنها را شاخص‌گذاری کنید. همچنین می‌توانید اضافه کردن ستون‌های کلید جایگزین به جداول ابعاد را در نظر بگیرید، که یک روش رایج در طراحی‌های انبار داده رابطه‌ای است.

یک استثنا برای این راهنما وجود دارد و مربوط به استفاده از تابع COMBINEVALUES DAX است. هدف این تابع پشتیبانی از روابط مدل چند ستونی است. به جای تولید عبارتی که رابطه از آن استفاده می‌کند، یک گزاره پیوند SQL چند ستونی تولید می‌کند.

فروش لایسنس پاور بی آی

• از روابط روی ستون‌های «شناسه منحصر به فرد» اجتناب کنید: Power BI به طور طبیعی از نوع داده شناسه منحصر به فرد (GUID) پشتیبانی نمی‌کند. هنگام تعریف رابطه بین ستون‌هایی از این نوع، Power BI یک پرس‌وجوی منبع با یک اتصال شامل تبدیل نوع داده (cast) ایجاد می‌کند. این تبدیل داده در زمان پرس‌وجو معمولاً منجر به عملکرد ضعیف می‌شود. تا زمانی که این مورد بهینه نشود، تنها راه حل، تحقق ستون‌هایی از یک نوع داده جایگزین در پایگاه داده اصلی است.
• ستون یک طرفه روابط را پنهان کنید: ستون یک طرفه یک رابطه باید پنهان باشد. (معمولاً ستون کلید اصلی جداول بُعد است.) وقتی پنهان باشد، در پنجره داده در دسترس نیست و بنابراین نمی‌توان از آن برای پیکربندی یک تصویر استفاده کرد. ستون چند طرفه می‌تواند در صورت مفید بودن برای گروه‌بندی یا فیلتر کردن گزارش‌ها بر اساس مقادیر ستون، قابل مشاهده باقی بماند. به عنوان مثال، مدلی را در نظر بگیرید که در آن رابطه‌ای بین جداول فروش و محصول وجود دارد. ستون‌های رابطه حاوی مقادیر SKU محصول (واحد نگهداری موجودی) هستند. اگر SKU محصول باید به تصاویر اضافه شود، باید فقط در جدول فروش قابل مشاهده باشد. وقتی از این ستون برای فیلتر کردن یا گروه‌بندی در یک ویژوال استفاده می‌شود، Power BI یک کوئری تولید می‌کند که نیازی به اتصال به جداول فروش و محصول ندارد.

DirectQuery

• تنظیم روابط برای اعمال یکپارچگی: ویژگی Assume Referenceal Integrity در روابط DirectQuery تعیین می‌کند که آیا Power BI کوئری‌های منبع را با استفاده از INNER JOIN به جای OUTER JOIN تولید می‌کند یا خیر. این ویژگی عموماً عملکرد کوئری را بهبود می‌بخشد، اگرچه به مشخصات منبع پایگاه داده رابطه‌ای بستگی دارد.
• از استفاده از فیلترینگ رابطه دو طرفه خودداری کنید: استفاده از فیلترینگ رابطه دو طرفه می‌تواند منجر به دستورات کوئری شود که عملکرد خوبی ندارند. فقط در صورت لزوم از این ویژگی رابطه استفاده کنید و معمولاً هنگام پیاده‌سازی یک رابطه چند به چند در یک جدول پل زدن این اتفاق می‌افتد.

لایسنس power bi

• محدود کردن کوئری‌های موازی: می‌توانید حداکثر تعداد اتصالاتی را که DirectQuery برای هر منبع داده‌ی اصلی باز می‌کند، تنظیم کنید. این تعداد کوئری‌هایی را که همزمان به منبع داده ارسال می‌شوند، کنترل می‌کند.
  • • این تنظیم فقط زمانی فعال می‌شود که حداقل یک منبع DirectQuery در مدل وجود داشته باشد. این مقدار برای همه منابع DirectQuery و هر منبع DirectQuery جدیدی که به مدل اضافه شده است، اعمال می‌شود.
    • افزایش مقدار Maximum Connections per Data Source تضمین می‌کند که می‌توان پرس‌وجوهای بیشتری (تا حداکثر تعداد مشخص‌شده) به منبع داده اصلی ارسال کرد، که زمانی مفید است که تصاویر متعددی در یک صفحه واحد وجود داشته باشند، یا بسیاری از کاربران همزمان به یک گزارش دسترسی داشته باشند. پس از رسیدن به حداکثر تعداد اتصالات، پرس‌وجوهای بیشتر در صف قرار می‌گیرند تا زمانی که یک اتصال در دسترس قرار گیرد. افزایش این محدودیت منجر به بار بیشتر روی منبع داده اصلی می‌شود، بنابراین تضمینی برای بهبود عملکرد کلی توسط این تنظیم وجود ندارد.
    • هنگامی که مدل در Power BI منتشر می‌شود، حداکثر تعداد پرس‌وجوهای همزمان ارسال‌شده به منبع داده اصلی نیز به محیط بستگی دارد. محیط‌های مختلف (مانند Power BI، Power BI Premium یا Power BI Report Server) هر کدام می‌توانند محدودیت‌های توان عملیاتی متفاوتی را اعمال کنند.

بهینه‌سازی طراحی گزارش‌ها

گزارش‌های مبتنی بر مدل معنایی DirectQuery را می‌توان از بسیاری جهات بهینه کرد، همانطور که در لیست زیر توضیح داده شده است.

• فعال کردن تکنیک‌های کاهش پرس‌وجو: Power BI Desktop Options and Settings شامل یک صفحه کاهش پرس‌وجو است. این صفحه سه گزینه مفید دارد. می‌توان به طور پیش‌فرض برجسته‌سازی متقاطع و فیلتر متقاطع را غیرفعال کرد، اگرچه می‌توان با ویرایش تعاملات آن را لغو کرد. همچنین می‌توان دکمه اعمال را روی برش‌دهنده‌ها و فیلترها نشان داد. گزینه‌های برش‌دهنده یا فیلتر تا زمانی که کاربر گزارش روی دکمه کلیک نکند، اعمال نمی‌شوند. اگر این گزینه‌ها را فعال کنید، توصیه می‌کنیم هنگام ایجاد گزارش، این کار را انجام دهید.
• ابتدا فیلترها را اعمال کنید: هنگام طراحی اولیه گزارش‌ها، توصیه می‌کنیم قبل از نگاشت فیلدها به فیلدهای بصری، هرگونه فیلتر قابل اجرا – در سطح گزارش، صفحه یا بصری – را اعمال کنید. به عنوان مثال، به جای کشیدن معیارهای CountryRegion و Sales و سپس فیلتر کردن بر اساس یک سال خاص، ابتدا فیلتر را روی فیلد Year اعمال کنید. دلیل این امر این است که هر مرحله از ساخت یک بصری، یک پرس‌وجو ارسال می‌کند و اگرچه می‌توان قبل از تکمیل پرس‌وجوی اول، تغییر دیگری ایجاد کرد، اما همچنان بار غیرضروری را بر روی منبع داده اصلی وارد می‌کند. با اعمال زودهنگام فیلترها، معمولاً پرس‌وجوهای میانی کم‌هزینه‌تر و سریع‌تر می‌شوند. همچنین، همانطور که در مورد DirectQuery توضیح داده شد، عدم اعمال زودهنگام فیلترها می‌تواند منجر به عبور از محدودیت ۱ میلیون ردیف شود.

• تعداد تصاویر در یک صفحه را محدود کنید: وقتی یک صفحه گزارش باز می‌شود (و وقتی فیلترهای صفحه اعمال می‌شوند) تمام تصاویر در یک صفحه تازه‌سازی می‌شوند. با این حال، همانطور که در بالا توضیح داده شد، محدودیتی در تعداد پرس‌وجوهایی که می‌توانند به صورت موازی ارسال شوند، وجود دارد که توسط محیط Power BI و تنظیمات مدل Maximum Connections per Data Source اعمال می‌شود. بنابراین، با افزایش تعداد تصاویر صفحه، احتمال تازه‌سازی آنها به صورت سریالی بیشتر می‌شود. این امر زمان لازم برای تازه‌سازی کل صفحه را افزایش می‌دهد و همچنین احتمال نمایش نتایج متناقض توسط تصاویر (برای منابع داده ناپایدار) را افزایش می‌دهد. به همین دلایل، توصیه می‌شود تعداد تصاویر در هر صفحه را محدود کنید و در عوض صفحات ساده‌تری داشته باشید. جایگزینی چندین تصویر کارت با یک تصویر کارت چند ردیفه می‌تواند به طرح‌بندی صفحه مشابهی دست یابد.
• غیرفعال کردن تعامل بین تصاویر: تعاملات برجسته‌سازی متقاطع و فیلتر کردن متقاطع مستلزم ارسال پرس‌وجوها به منبع اصلی هستند. مگر اینکه این تعاملات ضروری باشند، توصیه می‌شود در صورتی که زمان پاسخگویی به انتخاب‌های کاربران به طور غیرمنطقی طولانی باشد، غیرفعال شوند. این تعاملات را می‌توان برای کل گزارش (همانطور که در بالا برای گزینه‌های کاهش پرس‌وجو توضیح داده شد) یا به صورت موردی غیرفعال کرد.

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

• فیلترهای معیار/Measure: می‌توان فیلترهایی را برای تصاویر حاوی معیارها (یا مجموعه‌ای از ستون‌ها) اعمال کرد. برای مثال، تصویر زیر فروش را بر اساس دسته‌بندی نشان می‌دهد، اما فقط برای دسته‌بندی‌هایی با بیش از ۱۵ میلیون دلار فروش.

directquery model – measure filte

این ممکن است منجر به ارسال دو پرس‌وجو به منبع اصلی شود:

• پرس‌وجوی اول، دسته‌بندی‌هایی را که با شرط مطابقت دارند (فروش > 15 میلیون دلار) بازیابی می‌کند.
• پرس‌وجوی دوم سپس داده‌های لازم برای تصویر را بازیابی می‌کند و دسته‌بندی‌هایی را که با شرط مطابقت دارند به عبارت WHERE اضافه می‌کند.

اگر صدها یا هزاران دسته وجود داشته باشد، مانند این مثال، معمولاً عملکرد خوبی دارد. با این حال، اگر تعداد دسته‌ها بسیار بیشتر باشد، عملکرد می‌تواند کاهش یابد (و در واقع، اگر بیش از 1 میلیون دسته با شرط مطابقت داشته باشند، به دلیل محدودیت 1 میلیون ردیف که در بالا مورد بحث قرار گرفت، پرس‌وجو با شکست مواجه خواهد شد).

• فیلترهای TopN: فیلترهای پیشرفته را می‌توان طوری تعریف کرد که فقط N مقدار بالا (یا پایین) رتبه‌بندی شده توسط یک معیار را فیلتر کنند. به عنوان مثال، فقط پنج دسته برتر در نمودار بالا را نمایش دهند. مانند فیلترهای معیار، این کار منجر به ارسال دو کوئری به منبع داده اصلی نیز می‌شود. با این حال، کوئری اول تمام دسته‌ها را از منبع اصلی برمی‌گرداند و سپس N عدد برتر بر اساس نتایج برگشتی تعیین می‌شوند. بسته به تعداد ستون‌های مورد نظر، می‌تواند منجر به مشکلات عملکردی (یا عدم موفقیت کوئری به دلیل محدودیت ۱ میلیون ردیف) شود.

TopN filters

• Median: به طور کلی، هر تجمیعی (Sum، Count Distinct و غیره) به منبع اصلی منتقل می‌شود. با این حال، این برای میانه صادق نیست، زیرا این تجمیع توسط منبع اصلی پشتیبانی نمی‌شود. در چنین مواردی، داده‌های جزئی از منبع اصلی بازیابی می‌شوند و Power BI میانه را از نتایج برگشتی ارزیابی می‌کند. وقتی قرار است میانه روی تعداد نسبتاً کمی از نتایج محاسبه شود، خوب است، اما اگر کاردینالیتی زیاد باشد، مشکلات عملکردی (یا خرابی پرس‌وجو به دلیل محدودیت ۱ میلیون ردیف) رخ خواهد داد. برای مثال، میانه جمعیت کشور/منطقه ممکن است منطقی باشد، اما میانه قیمت فروش ممکن است منطقی نباشد.

• برش‌دهنده‌های چند انتخابی: فعال کردن چند انتخابی در برش‌دهنده‌ها و فیلترها می‌تواند باعث مشکلات عملکردی شود. دلیل این امر این است که وقتی کاربر موارد برش‌دهنده اضافی را انتخاب می‌کند (مثلاً، ایجاد حداکثر 10 محصول مورد علاقه‌اش)، هر انتخاب جدید منجر به ارسال یک پرس‌وجوی جدید به منبع اصلی می‌شود. در حالی که کاربر می‌تواند قبل از تکمیل پرس‌وجو، مورد بعدی را انتخاب کند، این امر منجر به بار اضافی بر روی منبع اصلی می‌شود. با نمایش دکمه اعمال، همانطور که در تکنیک‌های کاهش پرس‌وجو در بالا توضیح داده شد، می‌توان از این وضعیت جلوگیری کرد.
• مجموع‌های ویژوال: به طور پیش‌فرض، جداول و ماتریس‌ها مجموع‌ها و زیرمجموعه‌ها را نمایش می‌دهند. در بسیاری از موارد، پرس‌وجوهای اضافی باید به منبع اصلی ارسال شوند تا مقادیر مجموع‌ها به دست آید. این مورد هر زمان که از مجموع‌های Count Distinct یا Median استفاده می‌شود و در همه موارد هنگام استفاده از DirectQuery بر روی SAP HANA یا SAP Business Warehouse اعمال می‌شود. در صورت عدم لزوم، چنین مجموع‌هایی باید (با استفاده از پنل Format) غیرفعال شوند.

تبدیل به یک مدل ترکیبی

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

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

 

 

برای خرید لایسنس نرم افزار Power BI ، می‌توانید از خدمات ما استفاده نموده و درخواست خود را از طریق فرم زیر ثبت نمایید.

فرم درخواست لایسنس Power BI

میتوانید پاور بی آی دسکتاپ رایگان را دانلود کنید : Power BI desktop download