مدل سازی روابط در Power BI

روابط مدل در Power BI

هدف از این مقاله وارد کردن مدل سازهای داده ای است که با Power BI کار می کنند. این یک موضوع مهم طراحی مدل است که برای ارائه مدل های بصری، دقیق و بهینه ضروری است.

هدف رابطه

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

بیایید ببینیم چگونه روابط فیلترها بر روی جداول اعمال می شود

 

در این مثال، این مدل از چهار جدول، دسته بندی، محصول، سال، فروش تشکیل شده است. جدول Category مربوط به جدول Product و جدول Product مربوط به جدول Sales است. جدول Year نیز مربوط به جدول Sales است. یک کوئری _ که احتمالا توسط کارت Power BI بوجود آمده است مقدار کل فروش سفارشات فروش انجام شده برای یک دسته، Cat-A و برای یک سال CY2018 را درخواست می کند. به همین دلیل می توانید فیلترهای اعمال شده روی جدول های دسته و سال را مشاهده کنید. فیلتر موجود در جدول Category برای جدا کردن دو محصولی که به گروه Cat-A اختصاص داده می شوند، به جدول product انتشار می یابد. سپس فیلترهای جدول Product به جدول فروش منتقل می شوند تا فقط دو ردیف فروش برای این محصولات جدا شود. این دو ردیف فروش نشان دهنده فروش محصولات اختصاص یافته به دسته Cat-A  است. مقدار تقریبی آنها 14 واحد است. در یک زمان فیلتر جدول Year برای فیلتر کردن جدول فروش گسترش می یابد و در نتیجه فقط یک ردیف فروش مربوط به محصولات اختصاص داده شده به دسته Cat-A است که در سال CY2018 سفارش داده شده است. مقدار که توسط کوئری برگردانده شده است 11 واحد است. توجه داشته باشید که وقتی چندین فیلتر بر روی یک جدول اعمال می شود (مانند جدول فروش) این همیشه یک عمل AND است و لازم است همه شرایط درست باشد.

جدول های جدا شده

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

ویژگی های رابطه

یک رابطه مدل یک ستون در یک جدول به یک ستون در جدول دیگر ارتباط دارد.

قدرتمندی

هر مدل رابطه باید با یک Cardinality تعریف شود. چهار مدل Cardinality وجود داردکه نشان می دهد مشخصات داده های ستون مربوط "از" و "به" است. سمت یک به این معنی است که ستون شامل مقادیر منحصر به فرد است. سمت بسیار به این معنی است که ستون شامل مقادیر تکراری است.

چهار گزینه با علامت های اختصاصی به شرح ذیل است:

  • One-to-many (1:*)
  • Many-to-one (*:1)
  • One-to-one (1:1)
  • Many-to-many (*:*)

هنگامی که رابطه ای را در Power BI Desktop ایجاد می کنید طراح به صورت اتوماتیک نوع  Cardinality  را تشخیص و تنظیم می کند. طراح مدل را بررسی می کند تا متوجه شود کدام ستون شامل مقادیر منحصر به فرد می شود. برای وارد کردن مدل ها از آمار ذخیره سازی داخلی استفاده می کند برای مدل های DirectQuery درخواست های نمایه سازی(Profiling) را به منبع داده ارسال می کند اما گاهی ممکن است ان را اشتباه انجام دهد. این اتفاق می افتد به دلیل اینکه جدول هنوز بارگیری داده نمی شود یا ستون های که انتظار دارید که حاوی مقادیر تکراری باشند در حال حاضر شامل مقادیر منحصر به فرد می باشند. در هر صورت شما می توانید نوع Cardinality را به روزرسانی کنید به شرطی که ستون های جانبی "یک" شامل مقادیر منحصر به فرد باشند.

گزینه های یک به خیلی و خیلی به یک Cardinality اساساً یکسان هستند و رایج ترین نوع Cardinality  هستند.

 هنگام ساختن یک رابطه یک به خیلی یا خیلی به یک  رابطه ای را انتخاب می کنید که با نظم مربوط به ستون ها مطابقت داشته باشد. در نظر بگیرید که چگونه می توانید رابطه را از جدول Product به جدول Sales با استفاده از ستون ProductID موجود در هر جدول بسازید. نوع Cardinality یک به یک است زیرا ستون ProductID در جدول Product شامل مقادیر منحصر به فرد می باشد. اگر جدول را به صورت معکوس فروش را به محصول مرتبط کنید نوع Cardinality خیلی به یک خواهد بود.

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

یک رابطه Many to Many به این معنی است که هر دو ستون شامل مقادیر تکراری باشند این نوع Cardinality به ندرت استفاده می شود و بیشتر در طراحی مدل های پیچیده مورد استفاده قرار می گیرد.

جهت فیلتر

هر رابطه مدل باید با جهت فیلتر متقابل تعریف شود. انتخاب شما جهت انتشار فیلترها را مشخص می کند. گزینه های فیلتر به نوع Cardinality بستگی دارد.

 

جهت فیلتر تک به معنای جهت واحد است و هر دو به معنای هر دو جهت است. رابطه ای که در هر دو جهت فیلتر می شود معمولاً دو جهت توصیف می شود. برای رابطه یک به چند جهت فیلتر متقابل همیشه از طرف یک و به صورت اختیاری از طرف بسیاری است. برای رابطه یک به یک جهت فیلتر متقابل همیشه از هر دو جدول است برای رابطه Many to Many جهت فیلتر متقابل می تواند هم از طرف یک جدول و هم از طرف دو جدول باشد. توجه داشته باشید که وقتی نوع Cardinality شامل یک طرف "یک" باشد فیلترها همیشه از همان طرف پخش می شوند.

وقتی جهت فیلتر روی هر دو تنظیم شود یک ویژگی اضافی در دسترس است. هنگامی قوانین امنیتی سطح RLS می شوند می تواند فیلتر دو طرفه را اعمال کند. تغییر جهت فیلتر شامل: غیر فعال کردن انتشار فیلتر نیز می تواند توسط یک برآرود مدل انجام شود. با استفاده از عملکرد CrossFilter DAX به دست می آید.

روابط دو جهته می تواند تاثیر منفی بر عملکرد داشته باشد. همچنین تلاش برای ساختن یه رابطه دو جهته می تواند منجر به مسیرهای مبهم انتشار فیلتر شود. در این مورد Power BI Desktop ممکن است در ایجاد تغییر رابطه عمل نکند و با یک پیام خطا شما را آگاه می کند. با این حال بعضاً Power BI Desktop ممکن است به شما اجازه دهد مسیرهای ارتباط مبهم بین جداول را تعیین کنید. قوانین اولویت بر تشخیص ابهام و حل مسیر تاثیر می گذارند.

این رابطه را فعال کنید

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

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

تمامیت ارجاع را فرض کنید

خاصیت فرضیه یکپارچگی مرجع فقط برای روابط یک به یک و یک به خیلی بین دو جدول حالت ذخیره سازی DirectQuery که بر مبنای همان منبع داده هستند در دسترس است. در صورت فعال بودن ، کوئری های بومی ارسال شده به منبع داده با استفاده از INNER JOIN به جای OUTER JOIN ، دو جدول را به هم پیوند می دهند. به طور کلی ، فعال کردن این ویژگی عملکرد پرس و جو را بهبود می بخشد، اگرچه به مشخصات منبع داده بستگی دارد همیشه هنگامی که محدودیت کلید خارجی پایگاه داده بین دو جدول وجود دارد، این ویژگی را فعال کنید. وقتی محدودیت کلید خارجی وجود ندارد، تا زمانی که مطمئن باشید یکپارچگی داده وجود دارد، می توانید ویژگی را فعال کنید.

توابع DAX مربوط

چندین عملکرد DAX وجود دارد که به روابط مدل مربوط می شوند. هر عملکرد به طور خلاصه در لیست ذیل شرح داده شده است:

  • RELATED: مقدار را از "یک" طرف بازیابی می کند.
  • RELATEDTABLE: جدول ردیف ها را از سمت "بسیاری" بازیابی کنید.
  • USERELATIONSHIP: استفاده از یک رابطه مدل غیرفعال خاص را مجبور می کند.
  • CROSSFILTER: جهت فیلتر متقاطع رابطه را تغییر می دهد (به یک یا هر دو) ، یا انتشار فیلتر را غیرفعال می کند (هیچکدام).
  • COMBINEVALUES: دو یا چند رشته متن را به یک رشته متن متصل می کند. هدف از این عملکرد پشتیبانی از روابط چند ستونی در مدلهای DirectQuery است.
  • TREATAS: نتیجه عبارت جدول را به عنوان فیلتر روی ستونهای جدول غیر مرتبط اعمال می کند
  • توابع والدین و کودک: خانواده ای از توابع مرتبط که می تواند تولید کند ستون های محاسبه شده برای طبیعی سازی سلسله مراتب والدین و کودک استفاده شود. سپس می توان از این ستون ها برای ایجاد یک سلسله مراتب در سطح ثابت استفاده کرد.

ارزیابی روابط

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

اول، برای درک کامل ارزیابی روابط، برخی از تئوری های مدل سازی لازم است مدل Import یا DirectQuery تمام داده های خود را از حافظه نهان Vertipaq یا پایگاه داده منبع تأمین می کند. در هر دو مورد، Power BI می تواند تعیین کند که یک طرف رابطه وجود دارد. 

با این حال، یک مدل ترکیبی می تواند شامل جداول با استفاده از حالت های مختلف ذخیره سازی (Import ، DirectQuery یا Dual) یا چندین منبع DirectQuery باشد. هر منبع ، از جمله حافظه پنهان داده های وارداتی Vertipaq، به عنوان یک گروه منبع در نظر گرفته می شود. روابط مدل را می توان به عنوان گروه درون منبع یا گروه منبع متقابل طبقه بندی کرد. رابطه گروه درون منبع رابطه ای است که دو جدول را در یک گروه مبدا مرتبط می کند، در حالی که رابطه گروه منبع مبدأ بین جداول مربوط به گروه منبع مختلف است. توجه داشته باشید که روابط در مدلهای Import یا DirectQuery همیشه گروه منبع داخلی است.

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

 

در این مثال، مدل Composite شامل دو گروه منبع می شود: یک گروه منبع Vertipaq و یک گروه منبع DirectQuery. گروه منبع Vertipaq شامل سه جدول و گروه منبع DirectQuery شامل دو جدول است. یک رابطه متقابل منبع برای ارتباط یک جدول در گروه منبع Vertipaq به یک جدول در گروه منبع DirectQuery وجود دارد.

روابط منظم

وقتی مدل جستجوگر می تواند "یک" طرف رابطه را تعیین کند، رابطه مدل منظم است. این تأییددارد که ستون "یک طرف" حاوی مقادیر منحصر به فردی است. همه روابط گروهی درون منبع یک به چند روابط منظم است در مثال زیر، دو رابطه منظم وجود دارد، هر دو به عنوان R. مشخص شده است. روابط شامل رابطه یک به چند شامل گروه منبع Vertipaq و رابطه یک به چند شامل در منبع DirectQuery است.

برای مدل های Import، جایی که همه داده ها در حافظه نهان Vertipaq ذخیره می شوند، برای هر رابطه منظم در زمان تازه سازی داده ها، یک ساختار داده ایجاد می شود. ساختارهای داده ها از نگاشت های نمایه شده تمام مقادیر ستون به ستون تشکیل شده اند و هدف آنها تسریع در پیوستن به جداول در زمان جستجو است. در زمان پرس و جو ، روابط منظم اجازه می دهد تا جدول گسترش یابد. گسترش جدول منجر به ایجاد یک جدول مجازی با درج ستونهای بومی جدول پایه و سپس گسترش در جداول مرتبط می شود. برای وارد کردن جداول، این کار در موتور جستجو انجام می شود. برای جداول DirectQuery این کار در پرس و جو بومی ارسال شده به پایگاه داده انجام می شود (تا زمانی که خاصیت Asset ارجاعی ارجاع فعال نباشد). سپس موتور پرس و جو بر روی جدول منبسط شده عمل می کند، فیلترها را اعمال می کند و براساس مقادیر ستون های جدول گسترش یافته گروه بندی می شود.

برای روابط یک به چند، گسترش جدول از طرف "بسیاری" به "یک" با استفاده از معناشناسی LEFT OUTER JOIN انجام می شود. وقتی یک مقدار تطبیق از "بسیاری" به سمت "یک" وجود ندارد، یک ردیف مجازی خالی به جدول سمت "یک" اضافه می شود.

گسترش جدول همچنین برای روابط گروهی درون منبع یک به یک رخ می دهد، اما با استفاده از معانی معنای FULL OUTER JOIN. این تضمین می کند که در صورت لزوم ردیف های خالی مجازی در هر دو طرف اضافه می شوند. ردیف های مجازی خالی در واقع اعضای موثر ناشناخته ای هستند. اعضای ناشناخته نقض یکپارچگی ارجاع را نشان می دهند در حالی که مقدار جانبی "بسیاری" هیچ مقدار "یک" طرف مطاقبت ندارد. در حالت ایده آل، این موارد خالی نباید وجود داشته باشد و می توان آنها را با پاکسازی یا ترمیم داده های منبع از بین برد.

بیایید ببینیم که جدول با یک مثال متحرک چگونه کار می کند

در این مثال، این مدل شامل سه جدول طبقه بندی، محصول و فروش می شود. جدول طبقه بندی مربوط به جدول محصول با رابطه یک به چند و جدول محصول مربوط به جدول فروش با رابطه یک به چند است. جدول طبقه بندی شامل دو ردیف، جدول محصول شامل سه ردیف و جدول فروش شامل پنج ردیف است. مقادیر منطبقی در هر دو طرف همه روابط وجود دارد به این معنی که هیچ نقض یکپارچگی مرجع وجود ندارد. یک جدول گسترش یافته برای زمان پرسش نشان داده می شود. جدول از ستونهای هر سه جدول تشکیل شده است. این در واقع یک چشم انداز غیر عادی از داده های موجود در سه جدول است. یک ردیف جدید به جدول فروش اضافه می شود و دارای یک مقدار شناسه تولید (9) است که هیچ ارزش مطابقی در جدول محصول ندارد. این یک نقض یکپارچه است. در جدول گسترش یافته، سطر جدید دارای مقادیر (Blank) برای ستون های جدول Category و Product است.

 

روابط محدود

رابطه مدل محدود می شود وقتی در هیچ یک از طرف ها تضمینی وجود نداشته باشد و این می تواند دو علت داشته باشد:

1. این رابطه از نوع کاردینالیته بسیاری به بسیاری استفاده می کند (حتی اگر یک یا هر دو ستون شامل مقادیر منحصر به فرد باشند)

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

در مثال زیر، دو رابطه محدود وجود دارد ، هر دو به عنوان L مشخص شده اند. این دو رابطه شامل رابطه بسیاری به بسیاری که در گروه منبع Vertipaq است ورابطه یک به چند که در گروه منبع متقابل است.

 

برای مدلهای Import، ساختارهای داده هرگز برای روابط محدود ایجاد نمی شوند. به این معنی است که پیوندهای جدول باید در زمان پرس و جو حل شوند. گسترش جدول هرگز برای روابط محدود رخ نمی دهد. پیوستن به جدول با استفاده از معناشناسی INNER JOIN حاصل می شود و به همین دلیل، ردیف های خالی مجازی برای جبران نقض یکپارچگی مرجع اضافه نمی شوند.

محدودیت های اضافی مربوط به روابط محدود وجود دارد

  • از تابع RELATED DAX برای بازیابی مقادیر ستون سمت "یک" نمی توان استفاده کرد.
  • اجرای RLSمحدودیت های توپولوژی دارد.

قوانین اولویتروابط دو جهته می تواند مسیرهای انتشار فیلترهای متعدد و در نتیجه مبهم را بین جداول مدل معرفی کند. لیست زیر قوانین اولویتی را ارائه می دهد که Power BI برای تشخیص ابهام و وضوح مسیر استفاده می کند:

  1. روابط بسیاری به یک و یک به یک ،شامل روابط محدودمی شوند.
  2. روابط بسیاری به بسیاری
  3. روابط دو جهته در جهت معکوس

اولویت عملکرد

لیست زیر عملکرد انتشار فیلتر را از سریعترین تا کمترین عملکرد سفارش می دهد

1.روابط یک به چند گروهی درون منبع

2. بسیاری از روابط مدل با یک جدول واسطه حاصل می شود و این شامل حداقل یک رابطه دو جهته است

3.روابط کاردینالیتی خیلی به خیلی

4.روابط گروه متقابل منبع

 

 

 

متن اصل

 

آخرین مطالب