طرح ستاره و اهمیت Power BI را درک کنید

این مقاله مدل سازهای داده Power BI Desktop را هدف قرار می دهد. این طراحی طرح‌واره ستاره‌ای و ارتباط آن با توسعه مدل‌های داده Power BI بهینه‌سازی شده برای عملکرد و قابلیت استفاده را توصیف می‌کند.

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

نمای کلی طرحواره ستاره

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

جداول ابعاد، موجودیت های تجاری را توصیف می کند - چیزهایی که شما مدل می کنید. موجودیت ها می توانند شامل محصولات، افراد، مکان ها و مفاهیم از جمله خود زمان باشند. منسجم ترین جدولی که در طرح ستاره ای می بینید، جدول بعد تاریخ است. جدول ابعاد شامل یک ستون (یا ستون) کلیدی است که به عنوان یک شناسه منحصر به فرد عمل می کند و ستون های توصیفی.

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

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

عادی سازی در مقابل غیر عادی سازی

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

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

با این حال، اگر جدول فروش جزئیات محصول را فراتر از کلید ذخیره کند، غیرعادی تلقی می شود. در تصویر زیر توجه کنید که ProductKey و سایر ستون های مربوط به محصول محصول را ثبت می کنند.

هنگامی که داده‌ها را از یک فایل صادراتی یا استخراج داده منبع می‌گیرید، احتمالاً مجموعه‌ای از داده‌های غیرعادی‌شده را نشان می‌دهد. در این مورد، از Power Query برای تبدیل و شکل دادن به داده های منبع به چندین جدول نرمال شده استفاده کنید.

همانطور که در این مقاله توضیح داده شد، باید تلاش کنید تا مدل‌های داده Power BI بهینه‌سازی شده را با جداولی که داده‌های واقعی و ابعاد عادی شده را نشان می‌دهند، توسعه دهید. با این حال، یک استثنا وجود دارد که در آن ابعاد دانه برف باید غیرعادی شود تا یک جدول مدل واحد تولید شود.

ارتباط طرحواره ستاره ای با مدل های Power BI

طراحی طرحواره STAR و بسیاری از مفاهیم مرتبط با آن در این مقاله برای توسعه مدلهای قدرت BI که برای عملکرد و قابلیت استفاده بهینه شده اند بسیار مرتبط هستند.

در نظر بگیرید که هر Visual Power BI Visual یک پرس و جو را ایجاد می کند که به مدل Power BI ارسال می شود (که سرویس Power BI آن را یک مجموعه داده می نامد). این نمایش داده ها برای فیلتر کردن ، گروه بندی و خلاصه کردن داده های مدل استفاده می شود. بنابراین ، یک مدل خوب طراحی شده ، نمونه هایی است که جداول برای فیلتر و گروه بندی و جداول برای خلاصه کردن ارائه می دهد. این طرح به خوبی با اصول طرحواره ستاره متناسب است:

• جداول بعد از فیلتر و گروه بندی پشتیبانی می کند
• جداول واقعیت از خلاصه پشتیبانی می کند

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

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

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

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

معیارهای

در طراحی STAR SCHEMA ، یک اندازه گیری یک ستون جدول واقعیت است که مقادیر را برای خلاصه کردن ذخیره می کند.

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

درک این نکته مهم است که مدلهای قدرت BI از روش دوم برای دستیابی به خلاصه پشتیبانی می کنند. هر ستون و به طور معمول عددی - می توان با گزارش بصری یا پرسش و پاسخ خلاصه شد. به این ستون ها به عنوان اقدامات ضمنی گفته می شود. آنها به عنوان یک توسعه دهنده مدل ، راحتی شما را ارائه می دهند ، زیرا در بسیاری از موارد شما نیازی به ایجاد اقدامات ندارید. به عنوان مثال ، ستون مبلغ فروش فروشنده Adventure Works می تواند به روش های مختلفی (جمع ، تعداد ، متوسط ، متوسط ، حداقل ، حداکثر و غیره) خلاصه شود ، بدون نیاز به ایجاد یک اندازه گیری برای هر نوع تجمع احتمالی.

با این حال ، سه دلیل قانع کننده برای ایجاد اقدامات ، حتی برای خلاصه های ساده در سطح ستون وجود دارد:

• هنگامی که می دانید نویسندگان گزارش خود با استفاده از عبارات چند بعدی (MDX) مدل را پرس و جو می کنند ، این مدل باید شامل اقدامات صریح باشد. اقدامات صریح با استفاده از DAX تعریف می شود. این رویکرد طراحی بسیار مهم است که یک مجموعه داده BI با استفاده از MDX پرس و جو شود ، زیرا MDX نمی تواند به خلاصه مقادیر ستون برسد. نکته قابل توجه ، از MDX هنگام انجام تجزیه و تحلیل در اکسل استفاده می شود ، زیرا Pivottables نمایش داده های MDX را صادر می کند.
• هنگامی که می دانید نویسندگان گزارش شما با استفاده از طراح Query MDX گزارش های PAGAGINATION POWER BI را ایجاد می کنند ، این مدل باید شامل اقدامات صریح باشد. فقط طراح Query MDX از سنگدانه های سرور پشتیبانی می کند. بنابراین ، اگر نویسندگان گزارش نیاز به اقدامات ارزیابی شده توسط Power BI (به جای موتور گزارش صفحه بندی) داشته باشند ، آنها باید از طراح پرس و جو MDX استفاده کنند.
• هنگامی که شما باید اطمینان حاصل کنید که نویسندگان گزارش شما فقط می توانند ستون ها را به روش های خاص خلاصه کنند. به عنوان مثال ، ستون قیمت واحد فروش نمایندگی فروش (که نشان دهنده یک نرخ واحد است) می توان خلاصه کرد ، اما فقط با استفاده از توابع تجمیع خاص. هرگز نباید خلاصه شود ، اما مناسب است که با استفاده از سایر توابع تجمیعی مانند حداقل ، حداکثر ، متوسط و غیره خلاصه شود. در این مثال ، مدل ساز می تواند ستون قیمت واحد را پنهان کند و برای کلیه عملکردهای مناسب جمع آوری اقدام کند.

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

کلیدهای جانشین

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

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

شما باید این پرس و جو را با پرس و جو در کنار "بسیاری" ادغام کنید تا بتوانید ستون فهرست را نیز به آن اضافه کنید. هنگامی که این نمایش داده ها را به مدل بارگذاری می کنید ، می توانید بین جداول مدل یک رابطه یک به بیش از حد ایجاد کنید.

ابعاد گل برف

ابعاد برف برفی مجموعه ای از میزهای عادی شده برای یک نهاد تجاری واحد است. به عنوان مثال ، Adventure Works محصولات را بر اساس طبقه بندی و زیر مجموعه طبقه بندی می کند. محصولات به زیر شاخه ها اختصاص داده می شوند و زیر شاخه ها به نوبه خود به دسته بندی ها اختصاص می یابد. در Warehouse Data Data Adventure Works ، ابعاد محصول در سه جدول مرتبط با آن عادی شده و ذخیره می شود: DimproductCategor ، DimProductSubCategation و Dimproduct.

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

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

هنگامی که شما تصمیم می گیرید از طراحی ابعاد برفی تقلید کنید:

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

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

به آرامی ابعاد را تغییر می دهد

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

تئوری طراحی طرحواره STAR به دو نوع SCD رایج اشاره دارد: نوع 1 و نوع 2. یک جدول از نوع ابعاد می تواند نوع 1 یا نوع 2 باشد ، یا هر دو نوع را همزمان برای ستون های مختلف پشتیبانی می کند.

نوع 1 SCD

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

یک تازه کردن غیر قابل انعطاف از یک جدول ابعاد مدل BI Model به نتیجه یک SCD نوع 1 می رسد. برای اطمینان از بارگیری آخرین مقادیر ، داده های جدول را تازه می کند.

نوع 2 SCD

یک SCD نوع 2 از نسخه های اعضای Dimension پشتیبانی می کند. اگر سیستم منبع نسخه ها را ذخیره نکند ، معمولاً فرآیند بار انبار داده است که تغییرات را تشخیص می دهد و به طور مناسب تغییر در یک جدول بعد را مدیریت می کند. در این حالت ، جدول ابعاد باید از یک کلید جانشین استفاده کند تا یک مرجع منحصر به فرد به نسخه عضو ابعاد ارائه شود. همچنین شامل ستون هایی است که اعتبار محدوده تاریخ نسخه (به عنوان مثال ، StartDate و EndDate) و احتمالاً یک ستون پرچم (به عنوان مثال ، ISCurrent) را تعریف می کند تا به راحتی توسط اعضای بعد فعلی فیلتر شود.

به عنوان مثال ، Adventure Works فروشندگان را به یک منطقه فروش اختصاص می دهد. هنگامی که یک فروشنده منطقه را جابجا می کند ، باید نسخه جدیدی از فروشنده ایجاد شود تا اطمینان حاصل شود که واقعیت های تاریخی با منطقه سابق در ارتباط هستند. برای پشتیبانی از تجزیه و تحلیل دقیق تاریخی فروش توسط فروشنده ، جدول ابعاد باید نسخه های فروشندگان و منطقه (های) مرتبط با آنها را ذخیره کند. جدول همچنین باید شامل مقادیر شروع و پایان تاریخ برای تعریف اعتبار زمان باشد. نسخه های فعلی ممکن است تاریخ پایان خالی (یا 12/31/9999) را تعریف کند ، که نشان می دهد ردیف نسخه فعلی است. جدول همچنین باید یک کلید جانشین را تعریف کند زیرا کلید تجاری (در این مورد ، شناسه کارمندان) بی نظیر نخواهد بود.

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

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

برای دستیابی به این نیاز ، جدول نوع ابعاد Power BI Model باید شامل ستونی برای فیلتر کردن فروشنده و یک ستون متفاوت برای فیلتر کردن یک نسخه خاص از فروشنده باشد. مهم است که ستون نسخه توضیحی غیر مبهم ، مانند "مایکل Blythe (12/15/2008-06/26/2019)" یا "مایکل Blythe (فعلی)" ارائه دهد. همچنین آموزش نویسندگان و مصرف کنندگان گزارش در مورد اصول اولیه SCD نوع 2 و نحوه دستیابی به طرح های گزارش مناسب با استفاده از فیلترهای صحیح مهم است.

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

ابعاد نقش آفرینی

بعد نقش آفرینی ابعادی است که می تواند حقایق مرتبط را متفاوت فیلتر کند. به عنوان مثال ، در Adventure Works ، جدول Date Dimension دارای سه رابطه با حقایق فروش فروشنده است. از همان جدول ابعاد می توان برای فیلتر کردن حقایق با تاریخ سفارش ، تاریخ کشتی یا تاریخ تحویل استفاده کرد.

در یک انبار داده ، رویکرد طراحی پذیرفته شده برای تعریف یک جدول ابعاد تاریخ واحد است. در زمان Query ، "نقش" بعد از تاریخ با کدام ستون واقعیت برای پیوستن به جداول استفاده می شود. به عنوان مثال ، هنگامی که فروش را بر اساس تاریخ سفارش تجزیه و تحلیل می کنید ، جدول پیوستن به ستون تاریخ سفارش فروش فروشنده مربوط می شود.

در مدل Power BI، این طرح با ایجاد روابط متعدد بین دو جدول قابل تقلید است. در مثال Adventure Works، جداول فروش تاریخ و فروشنده سه رابطه دارند. در حالی که این طراحی ممکن است، درک این نکته مهم است که فقط یک رابطه فعال بین دو جدول مدل Power BI وجود دارد. همه روابط باقیمانده باید روی غیرفعال تنظیم شوند. داشتن یک رابطه فعال واحد به این معنی است که یک فیلتر پیش‌فرض از تاریخ تا فروش فروشنده وجود دارد. در این مثال، رابطه فعال روی رایج ترین فیلتری تنظیم می شود که توسط گزارش ها استفاده می شود، که در Adventure Works رابطه تاریخ سفارش است.

تنها راه برای استفاده از یک رابطه غیر فعال، تعریف عبارت DAX است که از تابع USERELATIONSHIP استفاده می کند. در مثال ما، توسعه‌دهنده مدل باید اقداماتی را برای فعال کردن تجزیه و تحلیل فروش فروشندگان بر اساس تاریخ ارسال و تاریخ تحویل ایجاد کند. این کار می تواند خسته کننده باشد، به خصوص زمانی که جدول فروشندگان معیارهای زیادی را تعریف می کند. همچنین با انبوهی از اندازه گیری ها، به هم ریختگی صفحه Fields را ایجاد می کند. محدودیت های دیگری نیز وجود دارد:

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

برای غلبه بر این محدودیت‌ها، یک تکنیک رایج مدل‌سازی Power BI، ایجاد یک جدول از نوع ابعاد برای هر نمونه نقش‌آفرینی است. شما معمولاً جداول ابعاد اضافی را به عنوان جداول محاسبه شده با استفاده از DAX ایجاد می کنید. با استفاده از جداول محاسبه‌شده، مدل می‌تواند شامل یک جدول تاریخ، یک جدول تاریخ ارسال و یک جدول تاریخ تحویل باشد که هر کدام یک رابطه واحد و فعال با ستون‌های جدول فروش فروشنده مربوطه دارند.

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

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

• اطمینان حاصل کنید که نام ستون ها خود توصیفی هستند. در حالی که ممکن است یک ستون سال در تمام جدول‌های تاریخ وجود داشته باشد (نام ستون‌ها در جدول آن‌ها منحصربه‌فرد است)، با عناوین بصری پیش‌فرض خود توصیف نمی‌شود. تغییر نام ستون‌ها را در جدول نقش‌های بعدی در نظر بگیرید، به طوری که جدول تاریخ ارسال یک ستون سال به نام سال کشتی و غیره داشته باشد.
• در صورت لزوم، اطمینان حاصل کنید که توضیحات جدول بازخوردی را برای نویسندگان گزارش (از طریق نکات ابزار صفحه فیلدها) در مورد نحوه پیکربندی انتشار فیلتر ارائه می دهد. این وضوح زمانی مهم است که مدل دارای جدولی با نام عمومی باشد، مانند تاریخ، که برای فیلتر کردن بسیاری از جداول نوع واقعیت استفاده می شود. در موردی که این جدول، به عنوان مثال، رابطه فعالی با ستون تاریخ سفارش فروش فروشنده دارد، توضیح جدولی مانند «فیلترهای فروش فروشنده بر اساس تاریخ سفارش» را در نظر بگیرید.

ابعاد آشغال

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

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

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

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

ابعاد انحطاط

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

در مدل Power BI ، می تواند مناسب باشد که ستون شماره سفارش فروش را به جدول نوع واقعیت اضافه کنید تا فیلتر یا گروه بندی با شماره سفارش فروش امکان پذیر شود. این یک قاعده مستثنی است که قبلاً معرفی شده است که شما نباید انواع جدول را مخلوط کنید (به طور کلی ، جداول مدل باید از نوع ابعاد یا نوع واقعیت باشد).

با این حال ، اگر جدول فروش فروشندگان Adventure Works دارای ستون های شماره سفارش و شماره خط سفارش باشند ، و برای فیلتر کردن آنها لازم است ، یک جدول ابعاد انحطاطی طراحی خوبی خواهد بود. برای اطلاعات بیشتر ، به راهنمایی روابط یک به یک (ابعاد انحطاط) مراجعه کنید.

جداول واقعیت بی واقعیت

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

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

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

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

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

مراحل بعدی

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