جدول دایمنشن چیست؟ بررسی کامل 9 نوع Dimension Table در Data Warehouse و BI
در طراحی Data Warehouse یا همان انبار داده، دو نوع جدول اصلی وجود دارد: جدول دایمنشن (Dimension Table) و جدول فکت (Fact Table). این دو جدول در کنار هم هستهی اصلی یک Data Model یا مدل داده را تشکیل میدهند و تقریباً در تمام راهکارهای هوش تجاری (BI) مورد استفاده قرار میگیرند. هر دیتا مدل استاندارد بر پایهٔ حدود ۲ الگوی شناختهشده در معماری کیمبال بنا شده و محور اصلی آن را بعدها (Dimensions) تشکیل میدهند. بنابراین شناخت دقیق Dimension Table یکی از مهمترین موضوعات در طراحی انبار داده است.
مروری بر جدول دایمنشن های رایج مانند DimProduct و DimDate
برای ورود به بحث انواع جدول دایمنشن، بهتر است ابتدا چند نمونهٔ واقعی و رایج از جدول دایمنشن را بررسی کنیم. یکی از عمومیترین دایمنشنها، جدول DimDate است. در تمام پروژههای BI و انبار داده، این جدول دایمنشن برای مدیریت تاریخ، روز، ماه، سال، فصل، هفته و حتی تقویم شمسی مورد استفاده قرار میگیرد. این جدول دایمنشن برخلاف ظاهر سادهاش نقش بسیار مهمی در تحلیلهای زمانمحور دارد، زیرا در جدول فکت معمولاً تاریخ بهصورت یک کلید ذخیره میشود و Attributeهای زمانی باید از DimDate خوانده شوند. ستون کلیدی آن معمولاً تاریخ شمسی یا میلادی بهصورت عددی (مثل 20250131) است که بهعنوان Surrogate Key به کار میرود.
جدول دایمنشن رایج دیگر DimProduct است که اطلاعات محصولات را نگهداری میکند. این جدول دایمنشن شامل کلید Surrogate، کد محصول بهعنوان Business Key، دستهبندی، برند، وزن، رنگ، اندازه و سایر ویژگیهاست. Fact Table در بخش فروش یا سفارشات معمولاً از DimProduct بهعنوان مرجع استفاده میکند. وجود DimProduct کمک میکند تا مدل داده از تغییرات محصول مانند تغییر قیمت، تغییر برند یا ادغام دستهها محافظت شود و تحلیلها یکپارچه باقی بمانند.
این دو مثال نشان میدهند که جدول دایمنشن، ساختار توصیفی مدل داده را تشکیل میدهد و پایهٔ تحلیل در هوش تجاری است.
ساختار کلی جدول دایمنشن در یک مدل داده استاندارد
یک جدول دایمنشن یا همان Dimension Table معمولاً سه گروه ستون دارد. اولین گروه، ستونهای کلیدی هستند که شامل Surrogate Key و Business Key میشوند. Surrogate Key یک کلید عددی بدون معنی تجاری است که برای اتصال Fact Table به Dimension Table بهصورت امن، پایدار و بدون وابستگی به سیستمهای منبع طراحی شده است. Business Key همان کد منبع است، مانند شماره محصول، شماره مشتری یا کد فروشنده.
دومین گروه ستونها، Attributeها هستند. این ستونها ویژگیهای توصیفی دایمنشن را نگه میدارند. برای مثال Attributeهای DimCustomer مانند جنسیت، وضعیت تأهل، شهر، استان و سطح وفاداری هستند. در DimProduct نیز Attributeهایی مثل رنگ، برند، وزن و دستهبندی وجود دارند. Attributeها قلب تحلیل در BI هستند، زیرا Slice & Dice در داشبوردها بر اساس همین ستونها انجام میشود.
گروه سوم، ستونهایی هستند که به منظور SCD یا Slowly Changing Dimension استفاده میشوند. این ستونها شامل تاریخ شروع، تاریخ پایان، IsCurrent یا VersionNumber هستند. این اطلاعات کمک میکند بتوانیم تاریخچهٔ تغییرات را نگه داریم و تحلیلهای دقیقتری ارائه دهیم.
جدول دایمنشن معمولاً کمتناوبتر از Fact Table تغییر میکند و حجم آن بسیار کوچکتر از Fact است. اما نقش آن در مدل داده حیاتی است، زیرا تمام ویژگیهای توصیفی، دستهبندیها و متادیتا از این جدول خوانده میشود.
انواع دایمنشنها در Data Warehouse
در ادامه بهطور کامل انواع جدول دایمنشن Dimension Table را معرفی میکنیم، کاربرد آنها را توضیح میدهیم و برای هر مورد مثال و ساختار ارائه میگردد.
به طور کلی می توان ۹ نوع مهم از دایمنشها را نام برد که لیست آنا در ادامه امده است.
- Junk Dimension
- Role Playing Dimension
- Conformed Dimension
- Degenerate Dimension
- Slowly Changing Dimension (SCD)
- Outrigger Dimension
- Shrunken Dimension
- Static Dimension
- Inferred Dimension
۱. Conformed Dimension
یکی از مهمترین انواع دایمنشنها، Conformed Dimension است. این نوع دایمنشن بین چند Fact Table مشترک است و معنای یکسانی در کل مدل داده دارد. مثلاً DimCustomer ممکن است بین FactSales، FactOrders و FactSupport مشترک باشد. وجود Conformed Dimension باعث میشود گزارشها از چند دامنهٔ کسبوکاری بتوانند بهصورت یکپارچه تحلیل شوند.
ساختار این نوع دایمنشن کاملاً مشابه یک Dimension Table معمولی است؛ شامل Surrogate Key، Business Key و Attributeها. تنها ویژگی مهم آن، استانداردسازی است. برای مثال اگر جنسیت در DimCustomer تعریف شده باشد، تمام فکتها برای تحلیل مشتری از همین جدول استفاده میکنند. اگر در پروژهای چند منبع مشتری وجود داشته باشد، ابتدا باید همه را به یک Conformed Dimension تبدیل کرد.
کاربرد اصلی آن در یکپارچهسازی مدل داده و ساخت داشبوردهای Cross-Domain است.
۲. Junk Dimension
در بسیاری از سیستمهای منبع، تعداد زیادی فیلد کماهمیت، کدهای وضعیت، فلگها و متغیرهای کوچک وجود دارد که قرار نیست برای تحلیلهای پیچیده استفاده شوند، اما حذف آنها نیز ممکن نیست. اینجاست که Junk Dimension وارد میشود. این نوع جدول دایمنشن ترکیبی از چند Attribute ریز و کمحجم است.
مثال معمول Junk Dimension در فروشگاههای آنلاین شامل ستونهایی مثل IsReturnable، IsGift, CouponUsed و OrderChannel است. این ستونها اگر مستقیماً وارد Fact Table شوند باعث شلوغی مدل داده میشوند، اما وقتی در قالب یک Dimension Table کوچک قرار بگیرند، هم ساختار روشنتری ایجاد میشود و هم کلید خارجی Fact سبکتر خواهد شد.
ساختار Junk Dimension معمولاً شامل یک Surrogate Key و چند ستون کوچک است. حجم این جدول کم است و استفاده از آن مدل داده را خواناتر میکند.
۳. Degenerate Dimension
در بعضی از تحلیلها نیاز به یک شناسه وجود دارد که ویژگی توصیفی ندارد و فقط برای ردیابی استفاده میشود. این نوع ستون، Degenerate Dimension نام دارد. برای مثال شماره فاکتور یا شماره سفارش معمولاً یک Degenerate Dimension است. این مقدار در Fact Table ذخیره میشود، اما چون Attribute ندارد، دایمنشن جداگانه برای آن ساخته نمیشود.
Degenerate Dimension معمولاً زمانی کاربرد دارد که نیاز به گروهبندی بر اساس شماره سند وجود دارد. ساختارش ساده است و فقط یک فیلد در Fact Table محسوب میشود.
۴. Role-Playing Dimension
گاهی یک Dimension Table در چند نقش مختلف مورد استفاده قرار میگیرد. DimDate یک مثال معروف از Role-Playing Dimension است. در FactSales ممکن است تاریخ سفارش، تاریخ ارسال، تاریخ تحویل و تاریخ پرداخت وجود داشته باشد. بهجای ساخت چند نسخه از DimDate، همان جدول در چند نقش بازی میکند.
ساختار DimDate همان است، ولی در Fact Table چند کلید به آن اشاره میکنند. در مدلسازی BI معمولاً این نقشها با Alias مدیریت میشوند.
۵. Slowly Changing Dimension (SCD)
یکی از مهمترین انواع Dimension Table، دایمنشن با تغییرات تدریجی یا SCD است. سه نوع اصلی SCD در انبار داده استفاده میشود:
SCD نوع ۱
در این حالت تغییرات تاریخچه ندارند و مقدار Attribute فقط بهروزرسانی میشود. برای مثال تغییر شماره تلفن مشتری. ساختار خاصی لازم ندارد، فقط Attribute جدید ذخیره میشود.
SCD نوع ۲
مهمترین نوع SCD است. در این روش، تاریخچهٔ تغییرات نگهداری میشود. مثلاً اگر مشتری شهر خود را تغییر دهد، رکورد جدیدی در DimCustomer ساخته میشود و رکورد قدیمی با تاریخ پایان مشخص میشود. ستونهای StartDate، EndDate و IsCurrent در این ساختار استفاده میشوند.
SCD نوع ۳
در این نوع، فقط مقدار قبلی نگه میشود. معمولاً دو ستون به نام CurrentValue و PreviousValue داریم. حجم جدول کم میماند و تاریخچهٔ خلاصه فراهم میشود.
انواع ۴ و ۶ نیز وجود دارند اما استفادهشان محدودتر است.
۶. Outrigger Dimension
گاهی یک Dimension Table نیاز دارد به دایمنشن دیگری متصل شود. مثلاً DimProduct به DimCategory وصل باشد. در این حالت DimCategory یک Outrigger Dimension محسوب میشود. در مدلسازی استاندارد ترجیح داده میشود که دایمنشنها Flat باشند، اما گاهی ساختار داده ناچاراً این نوع وابستگی را ایجاد میکند.
ساختار Outrigger شامل Surrogate Key خودش و کلید خارجی به دایمنشن دیگر است. استفاده از این نوع دایمنشن زمانی مناسب است که دستهبندی یا سلسلهمراتب بهصورت مستقل مدیریت شود.
۷. Shrunken Dimension
این نوع دایمنشن نسخهٔ کوچکشدهٔ یک دایمنشن بزرگتر است. مثلاً از DimDate یک نسخهٔ Shrunken ساخته میشود که فقط سال و ماه را دارد و برای FactForecast مورد استفاده قرار میگیرد.
ساختار آن فیلترشده یا سادهشده است. کاربردش معمولاً در طراحی مدلهای Aggregate است.
۸. Static Dimension
این نوع دایمنشن تغییر نمیکند. مثل جدول واحد پول، جدول شرایط آبوهوایی، جدول نوع مشتری یا جدول Category ثابت. Static Dimension معمولاً SCD ندارد و بهصورت Read-Only استفاده میشود.
۹. Inferred Dimension
گاهی در Fact Table رکوردی وارد میشود که کلید دایمنشن آن هنوز در سیستم منبع ثبت نشده است. در این زمان از Inferred Dimension استفاده میکنیم. یک رکورد ناقص در دایمنشن ساخته میشود تا فرآیند ETL شکست نخورد و بعداً Attributeهای آن کامل میشود.
ساختار آن شامل یک Surrogate Key و مقادیر NULL برای Attributeهاست. کاربردش زمانی است که نیاز داریم تعادل مدل داده حفظ شود.
چه زمانی از هر نوع Dimension Table استفاده میکنیم؟
Conformed Dimension زمانی استفاده میشود که چند فکت نیاز به یک دایمنشن مشترک داشته باشند.
Junk Dimension زمانی کاربرد دارد که چند فیلد ریز و پراکنده وجود دارد و نمیخواهیم مدل داده شلوغ شود.
Role-Playing Dimension زمانی استفاده میشود که یک دایمنشن مثل DimDate چند نقش ایفا کند.
SCD زمانی لازم است که تاریخچهٔ تغییرات اهمیت داشته باشد.
Degenerate Dimension زمانی کاربرد دارد که کلید تحلیلی نیاز داریم اما Attribute ندارد.
Outrigger زمانی مناسب است که دایمنشن دیگری نیاز به ارتباط سلسلهمراتبی داشته باشد.
Shrunken Dimension معمولاً برای مدلهای خلاصهسازی شده یا دادههای کمجزئیات استفاده میشود.
Static Dimension برای دادههایی مناسب است که تقریباً هرگز تغییر نمیکنند.
Inferred Dimension زمانی لازم است که در ETL با رکوردهای ناقص مواجه میشویم.
جمعبندی
جدول دایمنشن یکی از اساسیترین اجزای Data Warehouse و مدلهای BI است. نقش آن در کنار Fact Table تکمیلکنندهٔ مدل داده است و بدون Dimension Table امکان ساخت داشبوردهای حرفهای در هوش تجاری وجود ندارد. شناخت انواع دایمنشنها مانند Conformed، Junk، SCD، Role-Playing، Static، Outrigger، Inferred و سایر الگوها باعث میشود بتوانیم یک Data Model اصولی، دقیق، پایدار و قابل توسعه بسازیم.
آیا این نوشته برایتان مفید بود؟
