یِاهو مارکت
فروشگاه یاهویِاهو مارکت
فروشگاه یاهومقاله25- تریگر های فازی در پایگاه داده فعال
 مقاله25- تریگر های فازی در پایگاه داده فعالفهرست مطالب بخش اول: مفاهیم و تعاریف، کارهای انجام شده1 1-2 مروری بر فصول پایان‌نامه. 5
2-3 نمونه‌های پیادهسازی شده21 2-3-3 NAOS.. 23 3-5 نتیجه. 30 فصل چهارم : پایگاه دادة فعال فازی ......................................................................... 31 4-1 تعریف فازی قوانین ..................................................................................... 32 4-1-1 رویداد فازی .................................................................................... 33
4-1-2 شرط فازی ....................................................................................... 37 4-1-3 واکنش فازی .................................................................................... 39.... 4-1-4 تعیین فازی موقعیت زمانبندی ............................................................ 40 4-2 معماری و مدل اجرایی قوانین ....................................................................... 42 4-2-1 آشکارساز رویداد .............................................................................. 43 4-2-2 بررسی شرط .................................................................................... 44 4-2-3 اجرا ................................................................................................ 44 4-2-4 زمانبندی .......................................................................................... 44 4-3 نتیجه ........................................................................................................... 46 بخش دوم: کاربردی جدید از تریگر فازی، رونوشت برداری فازی، نتایج آزمایشات ..... 47 فصل پنجم: رونوشت برداری فازی ........................................................................... 48 5-1 رونوشت برداری .......................................................................................... 49 5-1-1 رونوشت برداری همگام .................................................................... 49 5-1-2 رونوشت برداری ناهمگام .................................................................. 50 5-1-3 ماشین پایه رونوشت برداری داده......................................................... 51 5-1-4 مقایسه دو روش همگام و ناهمگام...................................................... 52 5-2 رونوشت برداری فازی................................................................................... 55 5-2-1 استفاده از تریگرها برای فازی نمودن رونوشت برداری.......................... 56 5-3 کمیت سنج های فازی................................................................................... 58 5-3-1 روش محاسبه کمیت سنج های فازی................................................... 59 5-3-2 کمیت سنج عمومی............................................................................ 60 5-3-3 کمیت سنج جزئی.............................................................................. 63 5-3-4 کمیت سنج جزئی توسعه یافته............................................................. 66 5-4 روش جدید محاسبه حد آستانه در تریگرهای فازی برای رونوشت برداری فازی.............. 68 5-5 معماری ماشین رونوشت بردار فازی............................................................... 70 5-6 مثال............................................................................................................. 72 5-7 کارایی.......................................................................................................... 76 5-7-1 ترافیک در رونوشت برداری مشتاق..................................................... 78 5-7-2 ترافیک در رونوشت برداری تنبل........................................................ 79 5-7-3 ترافیک در رونوشت برداری فازی....................................................... 79 5-7-4 مقایسه تئوری هزینه رونوشت برداری فازی و تنبل............................... 80 5-8 جمع بندی.................................................................................................... 82 فصل ششم: پیاده سازی ........................................................................................... 83 6-1 Fuzzy SQL Server..................................................................................... 83 6-2 عملکرد اجزایFuzzy SQL Server............................................................... 84 6-3 پیاده سازی تریگرهای فازی در پایگاه داده غیر فازی........................................ 85 6-4 اجزاء تریگر فازی در پایگاه داده غیر فازی...................................................... 86 6-5 جداول سیستمی مورد نیاز.............................................................................. 86 6-6 مثال............................................................................................................. 88 6-7 کارهای آتی.................................................................................................. 93 مراجع و منابع ........................................................................................................ 94 واژه نامه لاتین ........................................................................................................ 96 واژه نامه فارسی ...................................................................................................... 98
بخش اول
مفاهیم و تعاریف
کارهای انجام شده
فصل اول: کلیات1-1 مقدمهبا ایجاد سیستم‌های مدیریت پایگاه داده عمده مشکلات ساختار، پشتیبانی و مدیریت داده‌های حجیم در سیستم‌های فایلی برطرف شد اما توجهی به جنبه‌های رفتاری پایگاه داده نشد. به این معنا که با استفاده از قیود جامعیت[1] شاید بتوان از منفی شدن مبلغ حقوق کارمندان جلوگیری نمود اما نمی‌توان مانع از بیشتر شدن حقوق آن‌ها از مدیرانشان شد. در چنین مواردی کاربران پایگاه داده با اجرای یک پرس و جو[2] موارد نقض محدودیت‌هایی از این قبیل را پیدا نموده و خود اقدام به اصلاح آن‌ها می‌نمایند. مواردی این چنین و نیز گزارشات مدیریتی در آغاز ماه از جمله کارهای مشخص و دارای ضابطه‌ای می‌باشند که انجام آن‌ها تکراری و قابل تفویض به سیستم است. کاربران غیرمجاز با استفاده از یک سری گزارشات، غیرمستقیم به اطلاعات کلیدی دست یافته و اقدام به تغییر آن‌ها می‌نمایند. پیدا نمودن چنین تغییراتی که معمولاً بعد از گزارشات اتفاق می‌افتند، به راحتی امکانپذیر نیست. همانطور که مشاهده میشود در یک پایگاه داده معمولی ردیابی رویدادهایی که در سیستم اتفاق افتاده‌اند (رخدادها) نیز ممکن نبوده و نیاز به یک سیستم با پشتیبانی جنبه‌های رفتاری می‌باشد. یک پایگاه داده فعال نظیر Oracle قادر به تشخیص رویدادهای نظیر اضافه، حذف و تغییر مقادیر در پایگاه داده می‌باشد. به عبارت دیگر این سیستم‌ها با ایجاد تغییر در یک قلم داده عکس‌العمل نشان می‌دهند. پایگاه دادة فعال با افزودن قوانین به پایگاه‌های داده امکان تعامل (کنش و واکنش) بین سیستم و پایگاه داده را ایجاد نمود. این نوع پایگاه داده دارای دو بخش مدیریت داده و مدیریت قوانین می‌باشد. بخش مدیریت داده مسئول حفظ خواص پایگاه داده در سیستم‌های کاربردی بوده و بخش دوم با مدیریت قوانین مسئول واکنش به رویدادهای سیستم می‌باشد. در این نوع پایگاه داده طراحان سیستم قادرند با تعریف قوانین که نزدیکترین بیان به زبان طبیعی می‌باشد، سیستم را وادار به عکس‌العمل مناسب در مقابل رویدادهای مهم نمایند [13]. پایگاه داده فعال با استفاده از قوانین قادر به «پشتیبانی گسترده‌تر قیود جامعیت و سازگاری داده‌ها، واکنش در مقابل رخدادهای سیستم کاربردی، عدم اجرای تقاضاهای مشکوک، ردیابی رویدادها، گزارشات ماهانه و...» می‌باشد. همانطور که گفته شد آنچه که به طور معمول باعث میشود یک پایگاه داده را فعال بدانیم، عکس‌العمل سیستم در مقابل وضعیت‌هایی است که در پایگاه داده و یا حتی خارج از آن به وجود می‌آید. این وضعیت‌ها می‌تواند شامل یک حذف غیرمجاز و یا تغییر وضعیت پایگاه داده باشد. باید توجه داشت که داشتن تعامل برای یک پایگاه داده لازم اما کافی نیست. بسیاری از سیستم‌های پایگاه داده با رعایت اصول پایه‌ای که در زیر به آن اشاره میشود به طور عام پایگاه دادة فعال نامیده میشوند [14]. اینگونه سیستم‌ها باید یک پایگاه داده باشند، یعنی در صورتی که کاربر فراموش کرد، سیستم مورد نظر پایگاه دادة فعال است بتواند از آن به عنوان یک پایگاه داده معمولی استفاده نماید (در صورت لزوم بتوان به عنوان یک پایگاه دادة معمولی از آن استفاده نمود). در اینگونه سیستم‌ها باید امکان تعریف و مدیریت قوانین وجود داشته باشد. این قوانین در پایگاه داده فعال دارای سه جزء رویداد[3]، شرط[4] و واکنش[5] می‌باشند. این سیستم‌ها باید دارای یک مدل اجرایی باشند. به این ترتیب که با بروز رویداد و صحت شرط، واکنش قانون اجرا شود. یک پایگاه داده فعال باید قادر به آشکارسازی رویدادها و بررسی شرط قوانین فعال و اجرای فرامین واکنش باشد. علاوه بر موارد فوق، بهتر است در این سیستم‌ها محیط مناسبی برای تعریف و امکان کامپایل کردن قوانین فراهم شود که به کاربر در تعریف قوانین کمک کند. فازی‌سازی پایگاه‌های داده فعال با هدف نزدیکتر نمودن زبان بیان قوانین به زبان طبیعی طراحان مطرح شد. اغلب تقاضاهای کاربران پایگاه داده فعال، فازی می‌باشد. به عنوان نمونه در تقاضاهایی نظیر عدم تعلق پاداش به کارمندان «کم‌کار»، «افزایش» فشارخون، محاسبة حقوق کارمندان در «پایان» هر ماه و... از کلمات فازی استفاده شده است که عدم پشتیبانی مفاهیم فازی و به کار بردن مقادیر دقیق منجر به حصول نتایج نامطلوب در برخی سیستم‌های کاربردی میشود. تفاوت اصلی در فازی‌سازی پایگاه دادة فعال با سایر سیستم‌های فازی، در نوع تعریف قوانین می‌باشد. به این ترتیب که در تعریف قوانین در اینجا از سه جزء اصلی رویداد، شرط و واکنش استفاده میشود در صورتی که سیستم‌های مبتنی بر قانون عموماً از دو جزء شرط و واکنش تشکیل شده‌اند اما فازی نمودن شرط و واکنش قوانین در پایگاه‌های داده فعال تفاوت چندانی با شرط و واکنش فازی در سیستم‌های مبتنی بر قانون ندارد و در فازی نمودن رویداد نیز می‌توان از همان سیاق رویدادهای فازی استفاده نمود این بحث توسط ولسکی و بوازیز در [7] مطرح شده است. در این پایان‌نامه سعی شده است بحث‌های مطرح شده در پایگاه‌های داده فعال فازی بطور خلاصه بررسی شود. همچنین در ادامه با معرفی عمل رونوشت برداری و بکارگیری قوانین فازی(تریگرهای فازی) در عمل رونوشت برداری روش بهبود یافته جدیدی معرفی میشود. 1-2 مروری بر فصول پایاننامهدر ادامه این پایان‌نامه در فصل دوم مفاهیم پایگاه دادة فعال ارائه شده است. همچنین مدل اجرایی، نمونه‌هایی از این نوع پایگاه داده و برخی کاربردهای پایگاه دادة فعال در ادامة این فصل آمده است. در فصل سوم مختصری از مفاهیم فازی ارائه شده است. فصل چهارم شامل چگونگی پشتیبانی مفاهیم فازی در بخش‌های مختلف یک پایگاه داده فعال می‌باشد. فصل پنجم به بیان طرح استفاده از تریگرهای فازی در پایگاه دادة فعال جهت ارائه روش جدید رونوشت برداری فازی می‌پردازد و مزایای استفاده از روش رونوشت برداری فازی نسبت به روشهای مرسوم قدیمی غیر فازی با یک نمونه پیادهسازی شده مقایسه میگردد. فصل ششم به بیان چگونگی پیادهسازی تریگرهای فازی در پایگاه دادة فعال غیر فازی و نیز پیاده سازی رونوشت برداری فازی بوسیله آن می پردازد.
فصل دوم: پایگاه داده فعال
پایگاه داده فعال با هدف افزودن تعامل به پایگاه داده و با استفاده از تعریف قوانین ایجاد شد. اولین پایگاه داده فعال، توسط Dayal و همکارانش در یک پروژه دانشگاهی به نام [15]Hipac مطرح شد. پایگاه داده این نرم‌افزار همانند [16]Samos شی‌ءگرا می‌باشد. علاوه بر پایگاه‌های داده فعال شی‌ءگرا سیستم‌هایی با پایگاه داده‌ی فعال رابطه‌ای نیز ایجاد شده‌اند که از جملة آن‌ها می‌توان [17]Starburst و [18]Arial را نام برد، این نوع پایگاه‌های داده به جای واکنش در مقابل فراخوانی متد یا تغییر خصیصه‌ها به تغییر، حذف و اضافه در جداول پایگاه داده حساس می‌باشند [19].
پایگاه داده فعال دارای دو بخش مدیریت داده و مدیریت قوانین می‌باشد. بخش مدیریت داده مسئول حفظ خواص پایگاه داده نظیر سازماندهی، مدیریت و پشتیبانی داده‌ها می‌باشد. بخش دوم یا مدیریت قوانین مسئول واکنش به رویدادهایی است که در سیستم اتفاق می‌افتند.
2-1 مدیریت دادهاین بخش مسئول حفظ خواص پایگاه داده می‌باشد، به طوری که طراحان می‌توانند از قابلیت‌های پایگاه داده فعال همانند یک پایگاه داده معمولی استفاده نمایند. ضمن اینکه می‌توان خواص پایگاه داده را در یک پایگاه داده فعال به صورت مطلوب‌تری ایجاد نمود. برقراری قیود جامعیت پشرفتهتر در پایگاه داده: این قیود در یک پایگاه داده معمولی فقط روی یک جدول قابل تعریف می‌باشند در حالی که با استفاده از قوانین پایگاه داده فعال، امکان تعریف محدودیت بر روی چندین جدول نیز وجود دارد. سازگاری بیشتر: سازگاری بین داده‌ها با استفاده از قوانین به صورت گسترده‌تری پشتیبانی میشود. 2-2 مدیریت قوانینپایگاه دادة فعال با استفاده از قوانین تعامل را به پایگاه داده می‌افزایند. این امر باعث میشود بدون استفاده از کدهای نرم‌افزارهای خارجی به رویدادهای سیستم در درون پایگاه داده پاسخ داده شود، در نتیجه تغییر در ضوابط سیستم کاربردی با کمترین هزینه و با تغییر قوانین به راحتی امکانپذیر است. در این فصل انواع تعریف و پیچیدگی‌های رفتاری قوانین در این نوع سیستم‌ها و مدل‌های اجرایی متفاوت (با توجه به تعریف یک قانون) ارائه خواهد شد. 2-2-1 تعریف قانوندر پایگاه داده فعال هر قانون دارای سه بخش رویداد، شرط و واکنش می‌باشد و قانونی دارای هر سه جزء فوق باشد اصطلاحاً ECA[6] نامیده میشود. Rule Rule_Name [ON Event] [IF Condition] THEN Action به طور کلی وجود دو جزء رویداد و شرط در تعریف قوانین می‌تواند اختیاری[7] و یا اجباری[8] باشد. در برخی نمونه‌های پیادهسازی شده پایگاه داده فعال تنها تعریف یکی از دو جزء اختیاری است یعنی امکان عدم تعریف رویداد در قانون وجود دارد و حضور شرط اجباری است. در زبان‌هایی که تعریف هر دو جزء اختیاری باشد، تعریف یکی از آن‌ها در هر قانون الزامی است در غیر این صورت تبدیل به یک قانون همیشه درست میشود. در صورت حذف شرط (EA[9] Rule) با بروز رویداد، واکنش آن اجرا میشود و با حذف رویداد (CA[10] Rule) در صورت برقراری شرط، واکنش قانون مربوطه به اجرا درمی‌آید. در این قسمت ابتدا به شرح مختصری از هر سه جزء قانون و نکاتی که در استفاده از ECA باید رعایت شوند می‌پردازیم و سپس انواع رفتارهای مدل اجرایی پایگاه داده فعال بیان میشود.
1) رویداد:رویدادها در نقطه‌ای از زمان اتفاق می‌افتند و به سه صورت تقسیم‌بندی میشوند. در نوع اول با توجه به منبع به وجود آورندة خود به هفت گروه ساختاری، انتزاعی، تراکنش، کاربر، استثناء، زمان، خارجی تقسیم میشوند. در نوع دوم با توجه به اینکه از یک رویداد ساده تشکیل شده‌اند یا از ترکیب جبری منطقی رویدادهای ساده به وجود آمده‌اند به دو گروه ساده و مرکب تقسیم میشوند. در نوع سوم با توجه به زمان بروز نمونه‌های یک رویداد به سه گروه آغازین، میانی و پایانی تقسیم میشوند که در ادامه به شرح مختصری از انواع رویدادها در این سه گروه می‌پردازیم. انواع رویدادها با توجه به منبع به وجود آورندة آن‌ها عبارتند از [20][21]:ساختاری: یک رویداد به دلیل انجام عملیاتی روی ساختار پایگاه داده فعال میشود (در مدل رابطه‌ای تغییر و حذف و اضافة یک رکورد و در مدل شی‌ءگرا تغییر خصیصه‌ها، فراخوانی متد و ارسال پیام). ON Update emp.id انتزاعی: رویداد به صورت واضح توسط طراح یا برنامة کاربردی فعال میشود (طراح می‌تواند گرفتن یک گزارش خاص را یک رویداد معرفی کند که در صورتی که یک مجموعة تهی تولید نکند یک رویداد انتزاعی است). تراکنش: رویدادها، دستورالعمل‌های تراکنشی نظیر Start و Abort و Commit می‌باشند. ON Begin Transaction Emergency کاربر: رویداد به دلیل عملکردها و مکانیزم‌های برنامه‌نویسی فعال میشود (دادن پیام مناسب به کاربری که مشغول وارد کردن داده می‌باشد). استثناء: انجام عملیات غیرمجاز در سیستم موجب بروز این نوع رویداد میشود (دستیابی غیرمجاز کاربران به اطلاعاتی که مجوز مناسب آن را ندارند). زمان: این نوع رویدادها در نقطه‌ای از زمان فعال میشوند (مثلاً اول هر ماه). خارجی: رویدادهایی که به دلیل وقوع رویدادی در خارج از سیستم بروز می‌کنند در این گروه قرار می‌گیرند (فشردن کلید).
در نوع دوم رویدادها به دو دستة ساده و مرکب تقسیم میشوند. رویدادی که تنها از یک جزء تشکیل شده است ساده و رویدادهایی که از ترکیب جبری و منطقی رویدادهای ساده به دست می‌آیند مرکب نامیده میشوند. این عملیات‌های جبری عبارتند از [14]:And : رخ دادن هر دو رویداد (E1 And E2) OR : رخ دادن یکی از دو رویداد (E1 Or E2) Not : عدم رخ دادن رویداد در فاصلة زمانی معین. (E1; not E2;E3) به معنی عدم بروز رویداد دوم در فاصلة زمانی بین بروز رویداد اول و سوم SEQ : نشان‌دهندة ترتیب اجرای دو رویداد می‌باشد. Seq (E1,E2) : به این معنا است که رخ دادن رویداد دوم باید پس از رویداد اول انجام یافته باشد از نماد ":" نیز استفاده میشود. Times : بیانگر نمونة معین یک رویداد می‌باشد Times (n.E) یعنی نمونة nام رویداد E رویدادها در پایگاه دادة فعال ممکن است به دفعات رخ دهند. به رویدادهایی که اتفاق افتاده‌اند و از یک نوع می‌باشند، نمونه‌های یک رویداد گفته میشود. در نوع سوم تقسیم‌بندی، بسته به زمان رخ دادن یک نمونه از رویداد، نمونه‌ها به سه نوع آغازین[11]، میانی[12] و پایانی[13] تقسیم میشوند. نمونه‌ای از یک رویداد که دارای کمترین مرتبة زمانی در بین نمونه‌های همان رویداد باشد نمونة آغازین و نمونه‌ای که دارای بیشترین مرتبة زمانی باشد نمونة نهایی رویداد نامیده میشود به سایر نمونه‌ها، نمونه‌های میانی گفته میشود [20]. در مثال زیر E1(1) یک نمونة آغازین و E1(4) یک نمونة پایانی رویداد E1 می‌باشند. E1(1); E1(2); E1(3); E1(4) امکان وقوع همزمان نمونه‌های یک رویداد موجب ایجاد ناسازگاری در تعیین نوع نمونه‌ها میشود. بحث همزمانی رویدادها در یک سیستم متمرکز تنها در دو صورت امکانپذیر است. یکی از رویدادها زمانی و دیگری غیرزمانی باشد. یک رویداد ساده با حداقل یک رویداد مرکب می‌توانند همزمان رخ دهند. لازم به ذکر است دو رویداد ساختاری همزمان اتفاق نمی‌افتند به عبارت دیگر رخ دادن رویداد اضافه همزمان با رویداد حذف امکانپذیر نیست [22]. Last Exclusive وLast Shared : علاوه بر مرتبة رخ دادن نمونه‌ها ترتیب رخ دادن نمونه‌های یک نوع رویداد و نمونه‌های رویدادهای دیگر نیز قابل توجه است که آغازین و نهایی شدن نمونه‌ها را تحت تأثیر قرار می‌دهد. مثلاً در توالی دو رویداد، انتخاب نمونة نهایی رویداد اول، می‌تواند نمونه رویداداول دیگری باشد که قبل از کلیة نمونه‌های رویداد دوم اتفاق افتاده است (Exclusive) و یا نمونه رویداد اولی باشد که به عنوان آخرین نمونة رویداد اول اتفاق افتاده است حتی اگر بین آن رویداد اول آخر و رویداد اول آغازین رویدادهای دوم و سوم دیگری اتفاق افتاده باشد (Shared) [20]. E1(1); E1(2); E2(1); E1(3) E1(2) Last Exclusive E1(3) Last Shared 2) شرط:بخش دوم قانون شرط می‌باشد. پس از بروز یک رویداد نوبت به بررسی شرط قوانین رویداد مربوطه می‌رسد و در صورت صحت شرط، قانون مربوط در صف اجرا قرار می‌گیرد. در قسمت شرط، یک مقایسه و یا یک پرس و جو[14] می‌تواند قرار بگیرد، در صورتی که نتیجة پرس و جو تهی نباشد، شرط برقرار است. انتخاب زمان بررسی شرط یک قانون پس از بروز رویداد آن از سیاست‌هایی است که توسط سیستم تعیین میشود. این زمان می‌تواند فوری[15]، تأخیری[16] و یا مجزا[17] باشد. برخی سیستم‌ها تنها یک سیاست را پشتیبانی می‌کنند (نظیر NAOS) و برخی نیز همة سیاست‌ها را پشتیبانی می‌کنند (Hipac). در چنین سیستم‌هایی در هر قانون سیاست مورد نظر طراح تعریف میشود و در صورت عدم تعریف، یک سیاست به عنوان پیش‌فرض برای همة قوانین در نظر گرفته میشود. در تعیین شرط هر قانون، طراح باید بتواند برای ارزیابی شرط از مقادیر قبل و یا بعد از رویداد استفاده نماید. نام تراکنشی که رویداد در آن اتفاق افتاده است و یا نام کاربری که باعث بروز رویداد شده نیز ممکن است در قسمت شرط استفاده شود. این مقادیر به همراه رویداد ارسال میشود و پارامترهای رویداد نامیده میشود [23].
3) واکنش:واکنش هر قانون کلیة عملیاتی است که در صورت وقوع رویداد و صحت شرط باید اجرا شود. این عملیات عبارتند از اضافه، حذف و تغییر داده‌ها در پایگاه داده، تغییر مجموعه‌ای از قوانین، فراخوانی خارجی، ارسال پیام به مسئول و یا کاربران سیستم، انصراف از اتمام کار یک تراکنش و در نهایت به جای فرامین واکنش یک سری فرامین دیگر اجرا شود (به عنوان نمونه به جای انجام عملیات حذف پیامی به مسئول سیستم ارسال شود). برخی زبان‌ها قادر به تعریف دو نوع متفاوت از اجرای واکنش یک قانون می‌باشند. در نوع اول، ارزیابی و اجرا قبل از اجرای فرمان رویداد صورت می‌گیرد به عنوان مثال در SAMOS با استفاده از کلمة کلیدی Before انجام رویداد به بعد از اجرای فرامین واکنش موکول میشود و کلمة کلیدی After به معنای اجرای واکنش پس از اجرای رویداد می‌باشد [19]. به عنوان مثال با رسیدن فرمان حذف یک رکورد ابتدا یک پشتیبان تهیه و سپس عمل حذف انجام شود. قابل ذکر است که تشخیص بروز یک رویداد قبل از رخ دادن آن در برخی از حالات نظیر تقاضای تغییر یک مقدار امکانپذیر است و در صورتی که یک رویداد خارجی باشد غیرممکن است (دادن اخطار قبل از فشرده شدن یک کلید). انتخاب زمان اجرای واکنش یک قانون پس از ارزیابی شرط آن از سیاست‌هایی است که توسط سیستم تعیین میشود. این زمان می‌تواند فوری، تأخیری و یا مجزا باشد. برخی سیستم‌ها تنها یک سیاست را پشتیبانی می‌کنند و برخی نیز همة سیاست‌ها را پشتیبانی می‌کنند که در این صورت می باید برای هر قانون این سیاست تعیین میشود. هر یک از این سیاست‌ها در بخش بعد تشریح خواهد شد [14].
2-2-2 مدل اجراییاین مدل چگونگی اجرای مجموعة قوانین را در زمان اجرا نشان می‌دهد. اگرچه این مدل با جنبه‌های زیربنایی پایگاه داده (ساختار، محیط و مدیریت اجرایی) مرتبط است اما به طور کلی چندین مرحله در ارزیابی عمومی قوانین وجود دارد که در ادامه شرح داده خواهد شد. سیگنال[18]: یک منبع بروز رویداد، منجر به وقوع رویداد میشود. فعال‌سازی[19]: بررسی رویدادها و یافتن قوانین نظیر رویدادی که در مرحلة قبل سیگنال داده شده است. ارزیابی[20]: بررسی شرط قوانین فعال در این مرحله انجام میشود. قوانینی که شرط آن‌ها برقرار است، مجموعه‌ای به نام Rule Conflict را تشکیل می‌دهند. واکنش کلیة قوانین این مجموعه باید اجرا شود. اجرا[21]: واکنش قوانین مجموعة RC دراین مرحله اجرا میشود. اجرای فرامین واکنش منجر به بروز رویدادهای جدیدی شده و به مرحلة سیگنال وارد میشوند و این روند به صورت آبشاری ادامه خواهد داشت. زمانبندی [22]: زمان بررسی شرط و اجرای واکنش قوانین مجموعة RC در این مرحله تعیین میشود. برای زمانبندی قوانین سیاست‌های متفاوتی وجود دارد که در ادامه شرح داده خواهد شد. مراحل بالا الزاماً نباید پشت سر هم اجرا شوند اما به بروز رویداد و صحت شرط وابسته می‌باشند. یعنی برای ارزیابی شرط لزوماً باید رویداد قانون اتفاق افتاده و برای اجرای واکنش مربوط به قانون باید ارزیابی شرط انجام شده باشد. زمان بررسی و اجرای رویداد –شرط- واکنش بستگی به سیاست اتخاذ شده توسط سیستم دارد. برخی سیستم‌های پایگاه دادة فعال همة این سیاست‌ها را پشتیبانی نموده و طراح در تعریف قوانین خود زمان بررسی شرط و زمان اجرای فرامین واکنش را نیز تعریف می‌نماید. این زمان و مقادیر ارسالی به شرط و واکنش (نام تراکنش، نام کاربر، مقادیر داده) از جمله موارد تمایز سیستم‌ها می‌باشند. این سیستم‌ها (موقعیت‌های زمانبندی[23]) عبارتند از: فوری: یعنی بلافاصله بعد از بروز رویداد ، ارزیابی شرط و بعد از ارزیابی شرط، اعمال واکنش انجام میشود. تأخیری: در این حالت ارزیابی شرط (اجرای فرامین و واکنش) در همان تراکنش می‌باشد اما لزوماً در اولین فرصت نیست (معمولاً در پایان تراکنش)، این زمان قابل تعریف توسط طراح نیز می‌باشد. مجزا: در این حالت بروز رویداد و ارزیابی شرط (ارزیابی شرط و اجرای فرامین واکنش) در دو تراکنش مجزا صورت می‌گیرد. در چنین حالتی اجرای واکنش می‌تواند وابسته یا مستقل از به سرانجام رسیدن تراکنش باشد، ولی به هر حال رویداد اتفاق افتاده است و ارزیابی شرط انجام شده است و در صورت صحت شرط، فرامین واکنش در تراکنش دیگری اجرا میشود. ارتباط بین رویداد و قانون می‌تواند یک به یک و یا یک به چند باشد. در حالت اول به ازاء هر رویداد فقط یک قانون فعال میشود ولی در حالت دوم بروز یک رویداد می‌تواند چند قانون را فعال نماید. از جمله مشکلاتی که سیستم‌های مبتنی بر قانون با آن مواجه هستند حصول نتایج متفاوت، در زمان‌های اجرایی مختلف می‌باشد. این امر ناشی از اجرای قوانین با توجه به ترتیب نوشته شدن آن‌ها می‌باشد. مشکل دیگر فعال نمودن قوانین توسط یکدیگر می‌باشد. این امر زمانی مشکل‌آفرین میشود که یک سری از قوانین در یک حلقه، یکدیگر را برای اجرا فعال نمایند آخرین خصوصیتی که در مدل اجرایی باید در نظر گرفته شود پشتیبانی مدیریت خطا[24] توسط سیستم می‌باشد. اکثر سیستم‌ها به راحتی سیاست انصراف از تراکنش را در پیش می‌گیرند. برخی سیستم‌ها نیز با حذف قانون به ادامة پردازش قوانین دیگر می‌پردازند.
· اولویت اجرایی قوانین:زمانی که چند قانون همزمان با هم فعال میشوند سیستم باید سیاستی را برای ترتیب فعال نمودن آن‌ها اتخاذ نماید. انواع این سیاست‌ها در یک پایگاه داده فعال همانند سیاست‌هایی است که معمولاً در سیستم‌های خبره استفاده میشود. ساده‌ترین روش برای فعال نمودن قوانین، انتخاب آن‌ها با همان ترتیب نوشته شدن قوانین توسط طراح می‌باشد. امکان تعیین اولویت در هنگام تعریف قانون، روش دیگری است. در این روش مقادیر عددی به قوانین نسبت داده میشوند و قوانین مهمتر دارای اولویت بالاتری هستند. در صورت عدم تعریف اولویت، برای قوانین پیش‌فرض صفر در نظر گرفته میشود و برای انتخاب قوانین هم اولویت روش اول جایگزین میشود. حالت خاص دیگر دادن ارتباط است یعنی اگر دو قانون R1 و R2 با هم فعال شوند ابتدا قانون R1 اجرا شود و سپس قانون R2. در غیر این صورت ترتیب مهم نیست. در واقع تعیین اولویت برای برخی از قوانین انجام میشود. مشخص کردن برخی قوانین که حتماً قبل از هر قانون دیگری اجرا شوند از دیگرسیاستها می‌باشد[18]. · معماری پایگاه دادة فعال:در این بخش یک معماری ساده از پایگاه دادة فعال که قادر به پردازش قوانین و پاسخ به تقاضاهای کاربر باشد ارائه خواهد شد. شکل (1-2) ساختار یک معماری ساده برای پایگاه دادة فعال می‌باشد این ساختار بر پایة ساختار ارائه شده در [19] می‌باشد شکل (1-2): معماری پایگاه داده فعال[19]. این سیستم شامل چهار بخش اصلی آشکارساز رویداد، بررسی شرط، زمانبند و اجرا می‌باشد که در ادامه به شرح هر یک از این بخش‌ها می‌پردازیم. بخش آشکارساز رویداد خود شامل دو بخش مجزا برای تشخیص رویدادهای «ساده»[25] و «مرکب»[26] می‌باشد. در بخش بررسی شرط به مقادیر متفاوتی (قبل و بعد از وقوع رویداد نیاز است). بخش اجرا شامل دو بخش اجرای واکنش قوانین و پاسخ به پرس‌وجوهای پایگاه داده[27] می‌باشد. بخش زمانبندی نیز به دلیل وجود تعیین دو زمان متفاوت برای ارزیابی شرط و اجرای واکنش قانون به دو بخش اصلی تقسیم میشود. این ساختار ساده پایة یک پایگاه دادة فعال می‌باشد. بخش زمانبندی نیز به دلیل وجود تعیین دو زمان متفاوت برای ارزیابی شرط و اجرای واکنش قانون به دو بخش اصلی تقسیم میشود. این ساختار ساده پایة یک پایگاه دادة فعال می‌باشد. در ادامه به شرح مختصر هر یک از این بخش‌ها می‌پردازیم. این معماری بر پایة مدلی است که در [19] ارائه شده است.
[1] - Integrity Constraints [2] - Query [3] - Event [4] - Condition [5] - Action [6] - Event Condition Action [7] - Optional [8] - Mandatory [9] - Event Action [10] - Condition Action [11] - Initiator [12] - Mediator [13] - Terminator [14] - Query [15] - Immediate [16] - Deferred [17] - Detached [18] - Signaling [19] - Triggering [20] - Evaluation [21] - Execution [22] - Scheduling [23] - coupling Mode [24] - Error Handing [25] - Primitive Event Detector [26] - Composite Event Detector [27] - Query Database یاهومارکت |