پشتیبانی: 09131253620
ارتباط با ما
تلگرام: 09131253620

برجسته ترین ها
گروه های مقاله ها
HyperLink


بررسی انباره داده بخش شانزدهم تاریخ درج: ١٣٩۴/٠٩/١٠

 تعداد ركودهاي كمتر: يك جدول بعد عموما تعداد ركوردها يا سطرهايي كمتر از جدول fact دارد. يك جدول بعد براي يك سازنده خودکار مي‌تواند فقط 500 سطر داشته باشد. از طرف ديگر جدول fact مي‌تواند حاوي ميليونها سطر باشد.

- درون يک جدول fact 
 اجازه دهيد كه به درون يك جدول fact برويم و اجزاآن را بيشتر بررسي كنيم. به ياد داريد اين همان محلی است كه معيارهای سنجش نگهداري مي‌شود. مي‌توان جزئيات را در پايين‌ترين سطح ممكن نيز نگهداري كرد. در جدول fact ذخيره دپارتمان براي تحليل فروشها، مي‌توان واحدهاي فروش را با تراکنشهای مجزا در وارسی صندوقدار نگهداري كرد. بعضي از جداول fact مي‌توانند فقط حاوي داده خلاصه شده باشند. به اين جداول، جداول fact تجميع گفته مي‌شود. شكل زیر ليست خصوصيات يك جدول fact است. درزير اين خصوصيات را مروري می كنيم:
- كليد اتصال
يك سطر در جدول fact با تركيبی از سطرهای جدول بعد ارتباط دارد. مثلا يك جدول fact را درنظر بگيريد که تعداد سفارشات را به عنوان يک صفت دارا می باشد. درنتيجه جداول بعد که بايد درنظر گرفته شوند محصول، زمان، مشتري، نمايش فروش‌ها  هستند. براي اين جداول بعد، فرض بر اين است كه پايين‌ترين سطح در سلسله مراتب بعد محصول مجزا، يك تقويم ، يك مشتري ويژه و يك نمايش فروش جداگانه هستند. پس يك سطر تنها در جدول fact بايد با يك محصول ويژه، يك تاريخ ويژه، يك مشتري ويژه و يك نمايش فروش جداگانه ارتباط داشته باشد. اين به معني آن است كه سطر در جدول fact بايد به وسيله كليدهاي اصلي از اين چهار جدول بعد مشخص شده باشد. بنابراين، كليد اصلي جدول fact بايد كليدهاي اصلي همه اين جداول بعد باشد.
انباره داده
- جزئی سازی داده .
اين يک مشخصه مهم از جدول Fact است. همانطور كه مي‌دانيد، جزئی سازی داده ، سطح جزئي براي سنجشها  و معيارها است. در اين مثال، معيارها در سطح جزئي شده هستند. تعداد سفارشات با تعداد يک محصول خاص در يك سفارش در يك تاريخ معين، براي يك مشتري خاص و توليد شده به وسيله يك نماينده فروش خاص ارتباط دارد. اگر ما تعداد سفارشات به عنوان تعداد يک محصول ويژه براي هرماه نگهداری كرده باشيم پس سطح جزئی سازی داده متفاوت است و در يك سطح بالاتری خواهد بود.

- مقياسهای کاملا افزاينده
صفات order_dollars و extended_cost وquantity_ordered رادرنظر بگيريد. هركدام از اينها با يك محصول ويژه و يك تاريخ معين براي مشتري خاص توليد شده به وسيله يك نماينده  فروش خاص  ارتباط دارد. در يك درخواست معين، فرض کنيد كه كاربر كل محصول خاص در يك تاريخ معين، نه براي مشتري خاص اما براي مشتريان در يك منطقه خاص را مي‌خواهد. پس نياز به يافتن همه سطرها در جدول fact مرتبط با همه مشتريان واقع در آن منطقه داريم و به علاوه صفات order_dollars و extended_cost وquantity_ordered تا به مجموع اضافه شوند.
مقادير اين صفات مي‌تواند با جمع ساده بدست آيد. بعضي مقياسها به عنوان مقياسهاي جمعي كامل شناخته مي‌شود. تجميع مقياسهاي جمعي كامل با جمع ساده انجام مي‌شود. وقتي ما درخواستها را براي تجميع مقياسها در جدول fact اجرا مي‌كنيم، بايد مطمئن باشيم كه اين مقياسها جمع كامل هستند، در غير اين صورت برطبق تعداد تخمين زده شده به درستي  نشان داده نمی شوند.
- مقياسهای نه کاملا افزاينده 
درمورد صفت margine_dollars در جدول Fact بحث خواهيم کرد. براي مثال اگر، order_dollars ،120  و صفات extended_cost 100 است، margin_percentage 20 خواهد بود. اين يك معيار محاسبه شونده و به دست آمده از order_dollars و extended_cost است. اگر تعداد سطرها در جدول Fact مرتبط با همه مشتريان در يك منطقه خاص تجميع شود، نمي‌توان به margin_percentage از همه اين سطرها اضافه كرد و نتيجه را با تعداد تجميع شده جمع بست. صفات محاسباتی مثل صفات margin_percentage قابل اضافه شدن نمی باشند. آنها به عنوان مقياسهاي نه کاملا افزاينده شناخته مي‌شود. تمايز مقياسهاي نه کاملا افزاينده نسبت به کاملا افزاينده وقتي نمايان می شود که در درخواستها اعمال تجميعی انجام می دهيد.
- عمق جدول، نه پهنا 
عموما يك جدول fact حاوي صفاتي كمتر از يك جدول بعد است. معمولا ده صفت يا كمتر. اما تعداد ركوردها در يك جدول fact خيلي بيشتر است . به يك مثال ساده از 3 محصول، 5 مشتري، 30 روز و 10 فروشنده به عنوان سطرها در يك جدول بعدتوجه کنيد. در اين مثال، تعداد سطرهاي جدول fact مي‌تواند 4500 باشد. اين تعداد در مقايسه با تعداد سطرها در جدول بعد خيلي بيشتر است. اگر يک تصوير از جدول Fact به عنوان جدول دوبعدي، مجسم کنيد ،متوجه می شويد كه جدول fact، با تعداد كمتر ستون ،تقريبا باريك است اما با تعداد بيشتر سطرها خيلي عميق است.
- داده پراکنده :
در بالا ذکر شد كه يك سطر در جدول fact با يك محصول خاص، يك تاريخ خاص، يك مشتري خاص و يك فروشنده خاص ارتباط دارد. به بيان ديگر، براي محصول ويژه، يك تاريخ خاص، يك مشتري خاص و يك فروشنده خاص، همزمان يك سطر در جدول fact وجود دارد. چه اتفاقاتي مي‌افتد وقتي با تاريخ يك تعطيلي مواجه شويم؟ سطرهاي جدول Fact براي هر تاريخ ممکن است فاقد مقدار باشد. همچنين، تركيبات ديگر از صفات جدول بعد نيزمي‌تواند وجود داشته باشد كه مقادير براي آن سطرهاي جدول Fact به صورتnull باشد. آيا نياز به نگهداري هر سطر با مقياسهاي null در جدول Fact هستيم؟ بايد بگوييم نيازي به اين نيست .بنابراين، مهم است كه اين نوع از پراکندگی داده ای ، محقق شود و جدول Fact نيز مي‌تواند داراي gap هايی از اين نوع باشد. 
- ابعاد فاسد شونده
با دقت به مثال جدول fact توجه کنيد تاصفات order_number و order_line را بيابيد. اينها نه  جزو مقياسها يا نه جزو معيارها يا fact هستند. پس چرا اين صفات در جدول fact هستند؟ وقتي صفات را براي جداول بعد و جداول Fact از سيستمهاي عملياتي وارد مي‌كنيم، بعضي اجزا داده در سيستم‌هاي عملياتي را كه نه fact  هستندنه به صورت صفات بعدی ، باقی می گذاريم. مثالهايی از اين نوع صفات می تواند تعداد سفارشات تعداد فاکتور و تعداد خطوط سازش و غيره باشند. براي مثال  مي‌توان ميانگين تعداد محصولات هر سفارش را جستجو كرد. پس بايد تعداد محصولات براي سفارشات وجود داشته باشد تا ميانگين به راحتی محاسبه شود. صفاتي مثل order_number و order_line در مثال ابعاد فاسد شدنی هستند و اينها به عنوان صفات جدول Fact نگهداري مي‌شود.
 
- جدول Fact فاقد حقيقت
بغير از كليد اصلي اتصال ، جدول fact حاوي fact ها و مقياسهاست. با يک مثال يك جدول fact را براي بخشی از موارد مربوط به دانشجويان ايجاد می کنيم. براي تحليل اين مورد،ابعاد ممکن می تواند دانشجو ، مقطع، تاريخ، اتاق و استاد باشد.جدول fact درنطر گرفه شده مي‌تواند ازهر يک از اين ابعاد متاثر شود. وقتي قصد داريد يک حضور مرتبط با يک مقطع ، تاريخ، اتاق و استاد ويژه را مشخص كنيد،چه مقياسي بايد به منظور ثبت اتفاق داريد مورد توجه قرارگرفته و در جدول Fact آورده شود؟ در سطر جدول حضور باشماره يك تعيين خواهد شد. هر سطر  جدول fact با شماره يك به عنوان حضور شامل می شود. اگر اين چنين باشد، چرا براي ثبت شماره يك در هر سطر جدول fact، به خود زحمت دهيم؟ لازم نيست چنين کاری انجام دهيم. خيلی از موارد سطرهای جدول Fact می تواند مثل حضور در جدول fact مورد نظر ما باشد.اين موقعيتها زمانی رخ می دهد که جدول fact اتفاقات را نمايش دهد.هر جدول fact در حقيقت نيازی به شامل شدن به حقايق ندارد. اين همان مفهموم جدول Fact "فاقد حقيقت" است.
 
 مزاياي شماي STAR
وقتي شماي STAR را درنظر می گيريم، درمی يابيم كه کليه ارتباطات بين هر جدول بعد و جدول Fact يك به n است. چه ويژگي درباره تركيب شماي STAR وجود دارد؟ چرا اين شما به عنوان  يک مدل مفيد براي انبار داده به کار می رود؟ چه دلايلي براي كاربرد وسيع آن و موقعيت مناسبش در ايجاد بهينه سازي براي پردازش درخواستها وجود دارد؟
اگرچه شماي STAR يك مدل رابطه‌اي است، در عين حال يك مدل غيرنرمال می باشد. جداول بعد عمدا غيرنرمال شده اند. اين تفاوت اصلي بين شمای STAR  و شمای رابطه‌اي براي سيستمهاي  OLTP است.
قبل از اينكه درمورد چند مزيت مهم شمای STAR بحث كنيم، بايد به اين مورد نيز توجه داشته باشيم كه تبعيت از شمای STAR براي اين تركيب هميشه بهترين گزينه نيست. براي مثال اگر جدول مشتری يکی از ابعاد است و اگط دارای مقدار بسيار زيادی مشتری هستيم يک جدول بعد مشتری غير نرمال مطمئنا مناسب نخواهد بود. جدول بعد طولاني مي‌تواند به طور مشابه اندازه جدول Fact را افزايش دهد. 
هرچند مزاياي زياد آن مهمتر از ضعف آن است. پس اجازه دهيد مزاياي شماي star را مرور كنيم.
 
1- فهم آسان كاربران 
كاربران سيستمهاي OLTP با نرم‌افزارها از طريق نمايشگرهای از قبل تعريف شده يا الگوهاي درخواست از پيش ايجاد شده در ارتباط هستند. کمتر براي كاربران لازم است تا ساختارهاي داده ای را درك كنند. ساختارهاي داده و شماي بانک اطلاعاتی در قلمرو افراد حرفه‌اي در IT  باقي مي‌مانند.

تگها: data warehouse   استخراج اطلاعات   انبار داده   انباره داده   پردازش اطلاعات   مدیریت داده ها   
 

HyperLink

ارسال نظر در مورد این مطلب
نام :  
آدرس ایمیل :  
متن پیام :  
کد امنیتی :  
   
   
نظری برای نمایش وجود ندارد
 
این مطلب را به اشتراک بگذارید: