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

( اینجا فقط تکه ای از متن فایل پایان نامه درج شده است. برای خرید متن کامل پایان نامه با فرمت ورد می توانید به سایت feko.ir مراجعه نمایید و کلمه کلیدی مورد نظرتان را جستجو نمایید. )

شکل ۲۵معماری عمومی انبار داده
همانطور که قبلا توضیح داده شد برای ساخت انبار داده نیاز می‌باشد که داده‌ها از منابع اطلا عاتی مختلف که در اینجا ما فرض را بر این بنا کرده‌ایم که منابع اطلاعاتی ما سیستمهای اطلاعاتی میباشند به پایگاه داده‌های واسط و در نهایت پایگاه داده‌های ,DDS ODS و MDB انتقال خواهد شد که برای کنترل این فرایند از ETL استفاده می‌شود.
با بهره گرفتن از data profiler مشخصات داده‌های موجود در منابع اطلاعاتی نگهداری می‌شود.در واقع data profiler ابزاری است برای آنالیز داده‌های منابع اطلاعاتی.
در ادامه ETL داده‌های موجود در منابع اطلاعاتی را پس از واکشی و انتقال به پایگاه داده موقت بارگذاری میکند.
در مرحله بعد نوع دیگری از ETL کار یکپارچگی،انتقال و بارگذاری داده‌ها را از پایگاه داده موقت به پایگاه داده DDS را انجام می‌دهد.
همانطور که قبلا گفته شد DDS یک نوع پایگاه داده است که داده‌ها را با فرمتی متفاوت با پایگاه داده‌های سیستمهای عملیاتی OLTP نگهداری میکند.دلیلی که باعث انتقال داده‌ها از منابع اطلاعاتی متفاوت به DDS و اجرای پرس جو بروی آن‌ها در DDS بجای پایگاه داده سیستمهای OLTPمیشود این است که داده‌ها در DDS با فرمت چندبعدی نگهداری میشوند که برای پرس و جوهای تحلیلی بسیار مناسب است و دلیل دوم یکپارچگی اطلاعاتی است که از منابع متفاوت جمع‌ آوری نموده است.
در مرحله بعد ماژول DQ داده‌های موجود در DDS را از جنبه کیفیت بررسی نموده و داده‌های خراب را جهت گزارش و اصلاح داده‌ها به پایگاه داده DQ انتقال می‌دهد.داده‌های خراب را ممکن است که بتوان در یک بازه زمانی قابل قبول بصورت اتوماتیک اصلاح نمود.
سیستم ETL بوسیله سیستم کنترلی که برپایه ترتیب ،نقش و منطقی که در فراداده ذخیره شده است هماهنگ و مدیریت می‌شود. فراداده یک پایگاه داده است که شامل داده‌های از ساختار داده‌ها،معانی داده‌هاو همه اطلاعات مربوط به داده‌هاست.
ارزیاب سیستم همه عملیات سیستم را جهت کاربرد فراداده ثبت میکند.در واقع بخشی از سیستم ETL است که عملیات بخش‌های مختلف آنرا کنترل و مانیتور میکند.
در نهایت کاربران از ابزارهایی چون excel ،ابزارهای گزارش ساز وغیره برای بازیابی و تحلیل داده‌ها از DDS استفاده مینمایند.برخی از این ابزارها نیاز به داده‌هایی با فرمت چندبعدی دارند که این منجر به انتقال اطلاعات از DDS به یک پایگاه داده چندبعدی ( (MDBs می‌شود.
در این معماری برای کنترل کیفیت داده‌ها، ماژول DQ پیش‌بینی شده است که داده‌های انتقال‌یافته را از جنبه کیفی بررسی کرده و در صورت وجود داده‌ها مشکل دار پس از تلاش برای اصلاح آن‌ها ، آنرا در LOG های مربوطه ثبت می کند.پیشنهاد ارائه شده بنوعی بسط ماژول DQ میاشد چرا که ماژول DQ داده‌های انتقالی را بر اساس قوانین تعیین شده داخلی کنترل می کند و در مورد داده‌های انتقال نیاقته و داده‌های منبع هیچگونه اطلاعاتی ندارد.
همانطور که در معماری فوق مشاهده میکنید در این معماری هیچگونه پیش‌بینی برای شناسایی خطا و سناریوهای برخورد با خطا مشاهده نمیشود فقط یک مازول DQ موجود است که داده‌های خراب را بر اساس الگوهایی تعریف شده شناسایی میکند و در ادامه Log در این سیستم موجود است که بوسیله ابزارهایی بتوان آنرا بررسی و وجود خطای داده‌های انتقالی را بررسی کرد.توجه به این نکته ضروری می‌باشد که دامنه کاربرد این ماژولها فقط داده‌های انتقالی می‌باشد و هیچگونه تحلیلی از داده‌های انتقال نیافته ارائه نمیکند.
در روش پیشنهادی که در نهایت بصورت یک ماژول تشخیص خطا عمل خواهد کرد به این صورت است که در گام اول شاخص‌های عملکردی سازمان که در سیستمهای اطلاعاتی منبع موجود میباشند را شناسایی کرده و گزارش‌های پریودیکی بعنوان مثال روزانه برای اندازه گیری آن‌ها ایجاد مینماییم . سپس در بخش مربوط به ماژول تشخیص خطا یک Mapper که جداول موجود در منابع اطلاعاتی را با جداول موجود در مقصد یا Stage ها نگاشت میکنیم و گزارشاتی معادل گزارش‌های منبع جهت اندازه گیری شاخصهای عملکردی تعریف مینماییم با توجه به اینکه این شاخص‌ها برایند مجموعه ای از اطلاعات و داده‌های موجود در سیستمها میباشند با مقایسه این شاخص‌ها با یکدیگر با مرجع قرار دادن مقادیر موجود در سمت منبع هرگونه اختلافی نشان دهنده عدم انتقال صحیح داده‌ها می‌باشد که با توجه به نگاشت موجود میتوان برای بارگذاری موجود و همچنین تفسیر علت عدم انتقال به مشکل رخ داده رسید.این تفاسیر دامنه ای از تغییر یک داده بر اثر خطای سخت‌افزاری گرفته تا عدم دسترسی به سیستم منبع ،خرابی احتمالی شبکه و… را شناسایی خواهد کرد.یعنی در این ماژول با ترکیب بخش‌های مختلف مانیتورینگ و گام به گام پس از تست هر گام در صورت موفقیت وارد مرحله بعدی خواهد شد و در صورت بروز خطا در هر مرحله خطای مربوطه صادر و راه‌کار مناسب در نظر گرفته می‌شود بعنوان نمونه اگر فرض کنیم سناریوی کنترل گام به گام مانند این باشد که در مرحله اول درستی و در دسترس بودن پایگاه داده مقصد(انبار داده) باشد و در مرحله دوم کنترل شبکه ارتباطی بین سیستم منبع و سیستم مقصد باشد و در مرحله سوم دسترسی به سیستم منبع باشد و یا بصورت کلی میتوان خطاهای موجود در شبکه و معماری ساخت انبار داده را دسته بندی نموده و برای هرکدام از آن‌ها ابزار کنترلی را در ماژول مربوطه ایجاد مینماییم و متناسب با هرکدام از این‌گونه خطاها روال بازیابی و عکس العمل متناسب را تعریف مینماییم.
ماا در اینجا پیشنهاد میکنیم که ماژول تشخیص خطای (ED) به معماری فوق اضافه گردد که در صورت بروز هرگونه خطایی آنرا تشخیص می‌دهد که با بهره گرفتن از آن میتوان در جاهاییکه با افزونگی سخت‌افزاری نسبت به ارتقاء قابلیت اطمینان سیستم اقدام کرده‌ایم با بهره گرفتن از آن ماژول سالم را انتخاب کنیم و یا از این ماژول بعنوان تست پذیرش استفاده نمود.شکل ذیل اضافه شدن ماژول جدید ED را به معماری ساخت انبار داده نشان می‌دهد.
شکل ۲۶ ساخت انبار داده پس از افزودن ماژول ED
که اگر نمای داخلی ماژول ED را بخواهیم پیشنهاد کنیم میتواند بعنوان مثال میتواند بصورت ذیل باشد:
جدول ۳ بخش‌های پیشنهادی ماژول ED