سه Dimension حیاتی در طراحی انبار داده
در مدل‌سازی ستاره‌ای (Star Schema) برای انبار داده، همه‌ی ما با جدول‌های Fact و Dimension سروکار داریم. اما برخی Dimensionها کاربردهای خاص‌تری دارند.
1️⃣ Degenerate Dimension (بُعد تباه‌شده)
جدولی که هیچ ویژگی توصیفی ندارد، ولی برای شناسایی رکوردها به کار می‌رود. یک فیلد در جدول فکت است که مانند کلید اصلی عمل میکند، اما جدول بعدی مستقل ندارد!
مثال:
– در سیستم فروش، شماره فاکتور (مثل INV-1001) در جدول فکت ذخیره میشود، اما جدول جداگانهای برای آن وجود ندارد، چون اطلاعات تکمیلی (مانند تاریخ یا مشتری) در ابعاد دیگر موجود است.
Fact_Sales:
| Sale_ID | Order_Number | Customer_ID | Product_ID | Amount |
🔸کاربرد:
– برای حفظ امکان ردیابی دقیق رکوردها و ایجاد لینک مستقیم به تراکنش‌های خاص
– جلوگیری از ایجاد ابعاد بی مورد
– کاهش پیچیدگی مدل
– نگهداری کلیدهای تراکنش بدون نیاز به JOIN های اضافه
2️⃣ Role-Playing Dimension (بُعد چندنقشی)
یک جدول Dimension که می‌تواند در نقش‌های مختلف در یک جدول Fact ظاهر شود.
مثال:
جدول تاریخ در انباره داده ممکن است همزمان به عنوان:
– تاریخ سفارش
– تاریخ ارسال
– تاریخ تحویل
در مدل استفاده شود. در واقع، یک جدول وجود دارد، اما چندین بار با نامهای مختلف به فکت متصل میشود.
Fact_Orders:
| Order_ID | Order_Date_ID | Ship_Date_ID | Return_Date_ID | Amount |
🔸کاربرد:
– استفاده مجدد از یک منبع داده برای اهداف مختلف زمانی یا مکانی بدون تکرار داده
– یکپارچگی داده‌ها (همه تاریخ‌ها از یک منبع می‌آیند)
3️⃣ Junk Dimension (بُعد زائد/ترکیبی)
ترکیبی از چندین فیلد پراکنده (عمدتاً flag و indicatorها) که به‌تنهایی ارزش ساخت یک بعد مجزا ندارند، ولی وقتی با هم ترکیب می‌شوند به عنوان یک بعد معنا دارند.
مثال:
در سیستم فروش، به جای ذخیره مستقیم این فیلدها در فکت:
– وضعیت سفارش (در حال پردازش/تکمیلشده/لغوشده)
– روش پرداخت (نقدی/اعتباری/کارت)
– آیا تخفیف داشت؟ (بله/خیر)
همه را در یک جدول Junk Dimension با نام DimOrderAttributes جمع میکنیم.
🔸کاربرد:
– کاهش تعداد ستون‌های فکت
– بهبود عملکرد کوئری‌ها (کاهش حجم فکت)
– سازماندهی بهتر فیلدهای کم‌مصرف
این سه Dimension حیاتی در طراحی انبار داده باعث می‌شن مدل داده‌ای شما هم بهینه‌تر بشه، هم ساده‌تر مدیریت بشه، هم گزارش‌گیری بهتری ارائه بده.