خانه / آموزش Microsoft BI / درس هشتم – Cube و مدل های طراحی انباره داده

درس هشتم – Cube و مدل های طراحی انباره داده

کیوب و مدل Multidimensional :

در بحث هوش تجاری ممکن است که کیوب یا مکعب را شنیده باشین. Cube برای دیتا مدل Multidimensional هست و در دیتا مدل Tabular چنین مفهومی نداریم.

در دیتامدل Multidimensional تعدادی کیوب داریم و کمک میکنند تا اطلاعات را سریعتر ، قویتر و بهتر از دیتابیس های رابطه ای تحلیل و بررسی کنیم.

کیوب یک ساختارچند بعدی برای نگهداری اطلاعات است که در این ساختار موضوعات تحلیل مثلا DimDate  ، DimProduct و DimSalesTerritory محور های مکعب را تشکیل میدهند.

یک کیوب میتواند N تا محور داشته (حتی ۱۰ بعدی باشد ولی در رسم سه بعدی کشیده میشود.)

برای مثال نقطه A به این شرح است : تهران / بهار ۹۹ / پراید

Cube

 

نکته بسیار مهم این استی که در Cube , نتایج از قبل محاسبه و در هارد ذخیره میشود.
برای همین به نسبت تبولار سرعت بالاتری دارد چون عملا همه چیز از قبل حساب شده ولی در مدل تبولار , ابتدا دیتا داخل RAM بارگزاری و بعد محاسبات انجام میشود .

* در تبولار کیوب نداریم و این حرف بی معنی است و اصلاح دیتابیس یا دیتامدل تبولار داریم .

در حجم دیتای بالا در حد ترابایت میرسد ، بهتر است از مدل Multidimensional استفاده کنیم.

مدل های طراحی انباره داده :

مدل طراحی تعیین کننده چگونگی ارتباط جداول Fact و Dimension با یکدیگر میباشد.

سه مدل معروف و مطرح داریم.

* مدل ستاره ای – مدل دانه برفی – مدل کهکشانی

مدل ستاره ای یا Star Schema :

در این مدل ، جدول Fact به طور مستقیم با جداول Dimension متصل می باشد.

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

از نظر کارایی سریع تر از سایر مدل ها است.

ارتباط بین جداول Dimension و جداول Fact در این مدل یک به چند یا اصطلاحا One to Many است.

یعنی به ازای یک تاریخ مشخص داخل DimDate ممکن است چندین رکورد داخل جداول Fact داشته باشیم.

Star Schema

 

مدل دانه برفی یا Snowflake Schema :

در این مدل جداول Fact به صورت غیر مستقیم با یک یا چند جدول Dimension ارتباط میگیرند.

برای مثال در تصویر زیر ، FactSale  ، از طریق DimCustomer  به DimLocation متصل شده است.

Snowflake Schema

 

 

مدل کهکشانی یا Constellation\Galaxy Schema :

اگر بخواهیم جدول Fact مان را بر اساس  Dimension یک جدول Fact دیگر تحلیل کنیم ، مدل کهکشانی داریم.

این مدل به ندرت پیش می آید. یعنی نباید طراحی مان طوری باشد که این مدل پیش بیاید.

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

Constellation Schema

 

برای جلوگیری از رخداد این مدل ، برای مثال در این تصویر میتوان بین کالا و تامین کننده Relation ایجاد کرد سپس حالت دانه برفی خواهیم داشت. (Dimension تامین کننده -> Dimension کالا -> Fact فروش) یا میتوان دو تیبل دایمنشن کالا و تامین کننده را ادغام کرد تا یک تیبل شوند.

Conformed Dimension:

* یک اصطلاح در BI وجود دارد به نام Conformed Dimension. برای مثال در این تصویر Dimension کالا و زمان.
Conformed Dimension ها آنهایی هستند که بین دو جدول Fact مشترک هستند و حضور این نوع از جداول برای سیستم BI و قدرت تحلیل پذیری ما مناسب است و کمک میکند همزمان بر مبنای یک جدول بعد مانند زمان , دو جدول Fact را با هم تحلیل کنیم.
برای مثال اینجا میتوان بررسی کرد که در هر ماه میزان فروش و میزان خرید به صورت همزمان چقدر بوده است.
در تصویر زیر جدول کالا و زمان دو جدول Conformed Dimension هستند.

Conformed Dimension

 

  تا اینجا انبار داده و مدل های داده را بررسی کردیم و نحوه کار آن ها را دیدیم.

درباره‌ی علیرضا حسن نژاد

همچنین ببینید

طراحی ساختار SSAS Tabular Model

درس سی ام – طراحی SSAS Tabular Model

ساخت و طراحی Tabular Model اصطلاحی داریم به نام SSRS یا SQL Server Reporting Server …

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

معادله امنیتی (فقط عدد بنویسید) *