وب کاوی

استفاده از وب داده های  وب یکی از گام های کلیدی در کشف دانش در پایگاه داده، ایجاد یک مجموعه داده مناسب جهت انجام داده کاوی می باشد.در وب کاوی این داده می تواند از سمت سرور، مشتری، پروکسی سرور یا از یک پایگاه داده سازمان جمع آوری شود. هر کدام از این داده ها نه تنها از نظ منابع داده متفاوت می باشند بلکه از نظر انواع داده های موجود و محدوده مکانی که آن داده از آنجا جمع آوری می شود و متد پیاده سازی آن انواع داده ای که در وب کاوی استفاده می شود شامل:محتوا: داده واقعی در صفحات وب، داده ای که صفحه وب برای نمایش آن به کاربران طراحی شده است.که معمولاً از متن و گرافیک تشکیل شده ولی به آن محدود نمی شود.ساختار: داده ای که سازمان دهی محتوا را مشخص می سازد. اطلاعات ساختار درون صفحات شامل ترتیب انواع تگ های XML  یا HTML در یک صفحه داده شده می باشد و می تواند به صورت یک ساختار درختی نمایش داده شود که تگ ریشه درخت می باشد. اصلی ترین نوع از اطلاعات ساختاری بین صفحات، هایپرلینک است که یک صفحه را به دیگری مرتبط می کند.استفاده: داده ای که الگوی استفاده از صفحات وب را مشخص می سازد، مثل آدرس های IP، رجوع به صفحات و تاریخ و زمان دسترسی پروفایل کاربر: داده ای که اطلاعات آماری درباره کاربران وب سایت فراهم می سازد که شامل داده ثبت نام و اطلاعات پروفایل مشتری می باشد.منابع داده داده های استفاده که از منابع مختلفی جمع آوری می شود، الگوهای راهبری از بخش های مختلفی از کل ترافیک وب را نمایش می دهد.  جمع آوری در سطح سرورلاگ های وب سرور یک منبع مهم برای اجرای وب کاوی استفاده از وب محسوب می شود زیرا به طور صریح رفتار مرورگری تمام مشاهده کنندگان سایت را ثبت می کند. داده ای که در لاگ سرور ثبت می شود، دسترسی به یک وب سایت که از سوی  تمام کاربران صورت می گیرد را منعکس می کند. این فایل های لاگ به فرمت های گوناگونی چون Common log یا Extended log ذخیر می شوند.جمع آوری در سطح مشتریجمع آوری داده در سطح مشتری می تواند با بکارگیری یک عامل از راه دور( مثل اپلت های جاوا یا جاوا اسکریپت) یا با تغییر کد مرجع یک مرورگر موجود( مثل Mozilla یا Mosaic)  پیاده سازی شود.پیاده سازی این نوع روش  جمع آوری داده در سطح مشتری به همکاری کاربر در هر دو مورد ذکر شده نیاز دارد.جمع آوری در سطح پروکسییک پروکسی وب به عنوان یک سطح میانی از ذخیره سازی بین مرورگر سمت مشتری و وب سرور محسوب می شود تا زمان بارگذاری  صفحه وبی که توسط کاربر تجربه شده را کاهش دهد همانطور که بار ترافیکی در سمت مشتری و سرور را کاهش می دهد.داده های لاگ مربوط به وب معمولاً حجیم و گسترده هستند وبه منظور کشف الگو،  این داده ها باید در یک دید یکپارچه، سازگار و جامع جمع آوری شوند . در بیشتر کاربردهای داده کاوی پیش پردازش داده با حذف و فیلتر کردن داده های افزونه و بی ربط  و حذف نویزو تبدیل و رفع  هر ناسازگاری   سروکار دارد. پیش پردازش داده  نقش اساسی در کاربردهای کشف دانش در  داده  استفاده از وب دارا هستند و مهمترین مساله در بیشتر روش های کشف الگو، مشکل آن ها در اداره داده های استفاده از وب در مقیاس بزرگ است . به همین خاطر اکثر فرایندهای KDWUD   به طور غیر بر خط انجام می شوند . تحلیل داده استفاده بدون روش پیش پردازش مناسب نتایج ضعیف و یا حتی خرابی را بدنبال خواهد داشت . بنابراین متودولوژی برای پیش پردازش باید به کار گرفته شود تا هر مجموعه ای از فایل های لاگ وب سرور را به مجموعه ساختاریافته ای از جداول در مدل پایگاه داده رابطه ای تبدیل کند . فایل های لاگ از وی سایت های مختلف یک سازمان با هم ادغام می شوند تا رفتار کاربرانی که از طریقی ملموس راهبری داشته اند را نمایش دهد . بنابراین این فایل ها باید با حذف درخواست هایی که مورد نیاز نیستند، پاک می شوند مانند درخواست های ضمنی برای آبجکت های تعبیه شده در صفحات وب و یا درخواست هایی که بوسیله مشتری های غیر انسانی وب سایت ها یجاد می شود . درخواست های باقیمانده  با کاربر، نشست های کاربر و مشاهدات و مشاهده  صفحات،  گروه بندی می شود . و در نهایت مجموعه های پاک و تبدیل شده از درخواست های کاربران در یک مدل پایگاه داده رابطه ای ذخیره می شود . از فیلتر هایی برای فیلتر کردن داده های بدون استفاده، بی ربط و ناخواسته استفاده می شود تحلیلگر می تواند فایل های لاگ را از وب سرورهای متفاوت جمع آوری کند و تصمیم گیری کند که کدامیک از ورودی ها مطلوب هستند . در واقع هدف این است که اندازه بزرگ داده های استفاده از وب موجود به طور قابل توجهی کاهش یابد  و در عین حال کیفیت آن با سازمان دهی آن و فراهم سازی متغیر های یکپارچه  اضافی برای تحلیل  داده کاوی افزایش یابد .فرمول بندی مسالهفرض کنید مجموعه R={r1,r2,r3,…,rn}   مجموعه تمام منابع وباز یک وب سایت باشد . اگرU={u1,u2,…,um}  مجموعه تمام کاربرانی که به سایت دسترسی داشتند،  باشد؛ عنصر لاگ بصورت li=   تعریف می شود که  ui Є U ; ri ЄRاست و t  زمان دسترسی را نمایش می دهد،  s  وضعیت درخواست وref i  صفحه مورد مراجعه را نمایش می دهد . ref i در برخی ازفرمت های لاگ های وب مثل CLF در حالی که صفحه مورد مراجعه ثبت نشده،  اختیاری است . s یک کد سه رقمی است که موفقیت یا شکست درخواست مورد نظر را نشان می دهد . همچنین در موارد دیگر دلیل شکست را نیز بیان می کند . یک وضعیت با مقدار s=200 نشان می دهد که درخواست  موفق است در حالی که وضعیت با مقدار s=404  نشان دهنده این است که فایل مورد درخواست  در محل مورد نظر یافت نشده است . li={li1,li2,…,lim}  به ترتیب صعودی ذخیره می شوند که یک لاگ وب سرور را تشکیل می دهند . در صورت داشتن N وب سرور، مجموعه فایل های لاگ,…,LN}  Log={L1, L2 است .با بکارگیری این علائم مسئله پیش پردازش به صورت زیر فرمول بندی می شود . " با دریافت یک مجموعه از فایل های لاگ مربوط به لاگ های وب سایت های مختلف، کاربر، نشست های کاربر، مشاهده  و مشاهدات صفحات کاربران وب سایت در یک بازه زمانی مشخص ∆t  استخراج می شود ."پیش پردازش داده همانطور که در شکل نشان داده شده است فرایند پیش پردازش گام های زیر را در بر می گیرد :ادغام فایل های لاگ از وب سرورهای گوناگونپاک کردن داده شناسایی کاربران، نشست ها و مشاهده  هافرمت بندی داده و خلاصه سازی آنادغامدر ابتدای پیش پردازش داده، درخواست از تمام فایل های لاگ در Log در یک فایل لاگ الحاقی £همراه  با نام وب سرور جهت تشخیص بین درخواست های ایجاد شده مربوط به وب سرورهای مختلف  وهمچنین توجه به همگام سازی کلاک های وب سرورهای مختلف که از لحاظ  زمانی متفاوت اند . در شکل 2 شبه کد مربوط  به این عمل نشان داده شده است . به خاطر دلایل محرمانگی، فایل لاگ نتیجه f را بی نام کرده  بطوریکه وقتی که فایل های لاگ  به اشتراک گذاشته می شود یا نتایج  منتشر می شوند،  نام  میزبان یا آدرس های IP ، از بین می روند . بنابراین  نام اصلی میزبان با یک شناسنده ای که اطلاعاتی درباره محدوده دامنه ( کد کشور یا نوع سازمان مثل .edu , .com ,.org) نگهداری می کند، جایگزین می شود . مسئله ادغام به صورت زیر فرمولبندی می شود:با دریافت یک مجموعه فایل های لاگ Log={L1,L2,…,Ln}  این فایل های لاگ در یک فایل لاگ مجزا و منفرد ادغام می شود ( فایل لاگ الحاقی ) فرض کنید Li، i امین فایل لاگ می باشد . Li.c را به عنوان اشاره گر بر روی درخواست های Li در نظر بگیرید وLi.1 عنصر لاگ جاری از Li است که با Li.c نشان داده می شود و Li.1.time، زمان t مربوط به عنصرلاگ  جاری از Li می باشد و همچنین  S=(w1,w2,…,wn) آرایه ای از اسامی وب سرورها می باشد به طوری که S[i]  نام وب سرور مربوط به لاگ L i.1 می باشد .مراحل :1.     مقداردهی اولیه اشاره گر فایل لاگ الحاقی  £2.     اسکن عناصر لاگ از هر فایل لاگ Li در Log  و افزودن  آن به £3.     مرتب سازی عناصر £ به طور صعودی بر اساس زمان دسترسی آن هابرگرداندن مقدار £پاک کردن داده ·         گام دوم در پیش پردازش داده حذف درخواست های بدون استفاده  از فایل های لاگ می باشد . بطوریکه اگر تمام ورودی های لاگ معتبر نباشند، باید ورودی های بیربط را حذف کنیم .معمولاً این فرایند تمام درخواستهایی که منابع غیر قابل تحلیل مثل تصاویر، فایل های چندرسانه ای و فایل های مربوط به سبک صفحات را در بر می گیرند، را حذف می کند . برای مثال درخواستهای مربوط  به  محتوای صفحات گرافیکی ( تصاویر *.jpg & *.gif) و همچنین درخواستهای مربوط  به هر فایل دیگر در یک صفحه وب یا حتی نشست های راهبری که توسط رباط ها و اسپا یدر های وب انجام می شود .  با فیلتر کردن داده های بی استفاده، می توانیم سایز فایل لاگ را کاهش داده تا از فضای ذخیره سازی کوچکتری  استفاده کرده و نیز کارهای بعدی را آسان تر  کنیم .برای نمونه، با فیلتر کردن درخواست های تصاویر، سایز فایل های لاگ وب سرور نسبت به سایز اولیه اش تا 50 درصد کاهش می یابد . بنابراین پاک کردن داده حذف ورودی  های بی ربطی چون موارد زیر می باشد:   درخواستهایی که توسط برنامه های خودکار انجام می شود مثل : Web Robot ,Spiders و Crawler ها .این برنامه ها ترافیکی بر روی وب سایت ایجاد می کنند که می توانند بر روی  آمار سایت  تاثیر بگذارند و همچنین در بررسی هایی که توسط KDWUD انجام می شود مطلوب نیستند .·  درخواستهای مربوط به فایل های تصویری که  به صفحات  مشخصی اختصاص داده می شود . درخواست یک کاربر برای مشاهده یک صفحه خاص معمولاً در چندین در چندین عنصر از لاگ منعکس می شود زیرا هر صفحه گرافیک هایی را شامل می شود که فقط آنهایی برای ما مهم هستند که کاربر صریحاً آنها را درخواست کرده که معمولاً فایل های منتی هسنتد .·  عناصر با کدهای وضعیت HTTP  نا موفق . کدهای وضعیت HTTP  برای نشان دادن موفقیت یا شکست یک درخواست بکار می روند که در اینجا ما فقط عناصر با کد بین 200 تا 299 که با موفقیت انجام شده اند در نظر می گیریم .·   عناصری که متدی به غیر از GET  و POST  دارند .شناسایی در این گام درخواستهای غیر ساختیافته یک فایل لاگ به صورت کاربر(user) ، نشست کاربر(user session) ، مشاهدات و ملافات صفحات(page view ,visit)   گروه بندی می شود . در پایان این گام فایل لاگ به صورت یک مجموعه از تراکنش ها خواهد بود (نشست کاربر یا مشاهدات )کاربردر بیشتر موارد فایل لاگ فقط آدرس های کامپیوتر ( نام یا IP)  و عامل کاربر را فراهم می سازد ( به عنوان مثال فایل های لاگ ECLF ) . برای وب سایتهایی که نیازمند ثبت کاربرهستند، فایل لاگ همچنین  User login را شامل می شود ( به عنوان سومین رکورد در یک عنصر لاگ ) که برای شناسایی کاربر استفاده می شود . وقتی که user login موجود نباشد هر IP  به عنوان کابر در نظر گرفته می شود . با این حال این واقعیت وجود دارد که یک آدرس IP  توسط چندین کاربر استفاده می شود واین  برای KDWUD جهت شناسایی کاربر کافی نیست . به هر حال هنوز هم  مکانیزمی برای تشخیص و تمایز بین کاربران برای تحلیل رفتار دسترسی کاربر مورد نیاز است .نشست کاربر شناسایی نشست کاربر از فایل لاگ بدلیل پروکسی سرورها، آدرس های پویا و مواردی که چندین کاربر از طریق یک کامپیوتر دسترسی پیدا می کنند ( در کتابخانه، کافی نت و...) یا یک کابر از چندین مرورگر یا کامپیوتر استفاده می کند، امکان پذیر نمی باشد . یک نشست کاربر به صورت ترتیبی از درخواست ها که بوسیله یک کاربرمنفرد  در یک دوره زمانی مشخص تعریف می شود . یک کاربر می تواند یک (یا چند) نشست در طول یک دوره زمانی داشته باشد .شناسایی نشست عبارت است از فرایند قطعه بندی لاگ دسترسی هر کاربر به نشست های دسترسی مجزا .دو روش بر اساس زمان وجود دارد که شامل روش مبتنی بر طول نشست (Session-duration)  و روش مبتنی بر page-stay-time . همچنین می توانیم از یک  آستانه زمانی timeout  استفاده می کنیم . در ادامه شبه کد مربوط به فرایند شناسایی نشست آورده شده است و بررسی می کند که آیا نشست به پایان رسیده یا اینکه فایل مورد رجوع در هیچ یک از نشست های باز قبلی وجود ندارد . در این صورت یک نشست جدید باز می شود .از آنجاییکه Log بوسیله IP address/Agent  ذخیره می شود تمام نشست های باز کاندیدهای بالقوه ای برای دسترسی به فایل پردازش شده هستند . تابع Session_ Gen   تابع Distance را فراخوانی می کند که این تابع history  مربوط به فایل هایی که اخیراً به فایل f دسترسی داشته اند را پیدا می کند .نمای صفحات(page view)  گام مربوط به شناسایی نمای صفحه تعیین می کند کدام درخواست فایل صفحه بخشی از همان نمای صفحه است و اینکه چه محتوایی ارائه شده است .این گام  لازم است  تا نتایج معناداری  برای  فاز تحلیل الگو فراهم شود و اگر این گام اجرا نشود الگوهای کشف شده تحت تاثیر فایل های صفحه که یک نمای صفحه معروف و مشخص را تشکیل می دهد قرار می گیرد . نمای صفحه با بکارگیری زمان درخواست مشخص می شود . برای درخواست هایی که در یک لحظه ایجاد شده اند تنها اولین درخواست حفظ می شود و بقیه دور ریخته می شوند . بعد از شناسایی نمای صفحه، فایل لاگ به طور نرمال فقط یک درخواست برای هر عمل کاربر در بر می گیرد . هر نشست باید با یک نمای صفحه ابتدایی شروع شود . یک فایل صفحه آغازین یا یک مجموعه از فایل های صفحه از تمام نمای صفحات بعدی مشتق می شود . در اکثر موارد، نمای صفحه آغازین از یک فایل تشکیل می شود یا با یک فایل منفرد که ساختار قاب را مشخص می سازد و بلافاصله منجر به درخواست فایل های صفحه بعدی می شود .خیلی به ندرت اتفاق می افتد که یک سایت غیر مرتبط به بیش از یک فایل صفحه ازیک  سایت دیگر از طریق یک ابر متن منفرد متصل شود .  در هر صورت چنین امری امکان پذیر است و برای چنین مواردی تمام فایل های صفحه که در نمای صفحه آغازین شرکت دارد، باید صراحتاً وارد الگوریتم شود . خلاصه سازی و فرمت بندی داده   این گام، آخرین گام پیش پردازش داده است . فایل ساختاریافته نشست ها و مشاهداتی را شامل می شود که به یک مدل پایگاه داده رابطه ای تبدیل می شود . سپس یک متد تجمیع  داده در سطح درخواست  اعمال شده و با مشاهدات و نشست های کاربر یکپارچه گشته بطور کامل پایگاه داده را پر کند . دو جدول در مدل پایگاه داده رابطه ای طراحی می شود؛ یکی برای ذخیره داده لاگ و دیگری برای ذخیره نشست ها . خلاصه سازی داده بر روی محاسبه متغیر های تجمیع شده در سطوح مختلف انتزاع دلالت دارد ( درخواست، مشاهده و نشست کاربر) .این متغیرهای جمع آوری شده بعداً در گام  داده کاوی مورد استفاده قرار می گیرد و مقادیر آماری را نمایش می دهند که اشیاء آنالیز شده را مشخص می سازند. برای نمونه، اگر شی مورد تحلیل یک نشست کاربر باشد، در داده جمع آوری شده در فرایند محاسباتی، متغیرهای زیر محاسبه می شوند:·         تعداد ملاقات ها در هر نشست طول هر نشست در ثانیه( اختلاف بین تاریخ  آخرین و اولین نشست) یا در صفحات مشاهده شده( تعداد کل مشاهدات صفحه) تعداد مشاهدات برای یک دوره زمانی مشخص، که می تواند یک روز، هفته یا یک ماه باشد.اگر شی مورد تحلیل یک مشاهده باشد، متغیرهای زیر محاسبه می شوند:·        طول مشاهدات بر حسب  زمان و صفحه مشاهده شده فاکتور تکراری در مشاهده·        درصد درخواست های موفقیت آمیز· میانگین زمان سپری شده بر روی یک صفحه  به طور مشابه، سایر متغیرهای جمع آوری شده که می توانند محاسبه شوند:· درصد درخواست ها یی که به هر وب سرور اختصاص یافته· تعداد مشاهده کنندگان و میزبان های منحصر به فرد در هر ساعت، هفته و ماه·  تعداد عاملان کاربر منحصر به فرد در هر ساعت،روز، هفته و ماه

09367292276
09367292276
azsoftir@gmail.com
azsoftir.com09367292276
09367292276
azsoftir@gmail.com
azsoftir.com09367292276
09367292276
azsoftir@gmail.com
azsoftir.com09367292276
09367292276
azsoftir@gmail.com
azsoftir.com09367292276
09367292276
azsoftir@gmail.com
azsoftir.com09367292276
09367292276
azsoftir@gmail.com
azsoftir.com09367292276
09367292276
azsoftir@gmail.com
azsoftir.com