دانلود تحقیق پایگاه داده فعال

پایگاه‌های داده فعال با هدف ایجاد تعامل در پایگاه‌های داده ایجاد شدند.

در این نوع پایگاه داده با تعریف قوانین و بدون نیاز به کدنویسی، سیستم قادر به عکس‌العمل مناسب در مقابل رویدادهای مهم در شرایط خاص می‌باشد.

تعریف قوانین ساده‌ترین نوع بیان محدودیت‌ها بوده که برای متخصصین محیط نیز قابل درک می‌باشد.

اما در بیان تجربیات اغلب از کلمات فازی استفاده می‌شود که ترجمه آن‌ها به مقادیر دقیق منجر به کاهش ارزش معنایی دانش می‌شود.

فازی‌سازی پایگاه‌های داده فعال با هدف نزدیک‌تر نمودن زبان بیان قوانین به زبان طبیعی انسان مطرح شد.

این امر کمک می‌کند دانش متخصصین، مستقیماً به پایگاه داده منتقل شود.

ضمن اینکه تغییرات نیز با کمترین هزینه، بر قوانین تعریف شده اعمال می‌شود.

در اولین گام از فازی‌سازی پایگاه‌های داده فعال ولسکی و بوازیز به فازی نمودن رویداد، شرط و واکنش در تعریف قوانین پرداخته‌اند و طی سه مقاله نتایج آن را ارائه نمودند، آن‌ها در پروژه Tempo به پیاده‌سازی فازی این سه بخش پرداخته‌اند.

این پایان‌نامه به فازی نمودن سایر بخش‌های پایگاه‌های داده فعال می‌پردازد.

این بخش‌ها شامل رویدادهای مرکب، انتخاب فازی اجزاء رویدادهای مرکب، انتخاب فازی زمان بررسی شرط و اجرای واکنش قوانین می‌باشد.

همچنین راه‌حل‌هایی برای دو مشکل پایان‌ناپذیری اجرای قوانین و یکتایی پاسخ در پایگاه‌های داده فعال فازی ارائه شده است.

فازی نمودن پایگاه‌های داده فعال با هدف کاربردی‌تر نمودن پایگاه‌های داده مطرح شد.

مدل اجرایی پایگاه‌های داده فعال در بسیاری موارد نظیر زمان بررسی شرط و یا تعیین اولویت قوانین از پیش فرض سیستم استفاده می‌نماید.

فازی نمودن این نوع پایگاه داده کمک می‌کند تا سیستم سیاست‌های اجرایی پایگاه داده را در زمان اجرا و با استفاده از شدت وقوع رویدادها (به صورت معنایی و پویا) تعیین نماید.

در ادامه این پایان‌نامه یک معماری ساده از پایگاه داده فعال ارائه می‌شود و در پایان با یک نمونه پیاده‌سازی شده از پایگاه داده فعال فازی موارد پیشنهادی ارزیابی می‌گردد.

با ایجاد سیستم‌های مدیریت پایگاه داده عمده مشکلات ساختار، پشتیبانی و مدیریت داده‌های حجیم در سیستم‌های فایلی برطرف شد اما توجهی به جنبه‌های رفتاری پایگاه داده نشد.

به این معنا که با استفاده از قیود جامعیت شاید بتوان از منفی شدن مبلغ حقوق کارمندان جلوگیری نمود اما نمی‌توان مانع از بیشتر شدن حقوق آن‌ها از مدیرانشان شد.

در چنین مواردی کاربران پایگاه داده با اجرای یک پرس و جو موارد نقض محدودیت‌هایی از این قبیل را پیدا نموده و خود اقدام به اصلاح آن‌ها می‌نمایند.

مواردی این چنین و نیز گزارشات مدیریتی در آغاز ماه از جمله کارهای مشخص و دارای ضابطه‌ای می‌باشند که انجام آن‌ها تکراری و قابل تفویض به سیستم است.

کاربران غیرمجاز با استفاده از یک سر گزارش، غیرمستقیم به اطلاعات کلیدی دست یافته و اقدام به تغییر آن‌ها می‌نمایند.

پیدا نمودن چنین تغییراتی که معمولاً بعد از گزارشات اتفاق می‌افتند، به راحتی امکان‌پذیر نیست.

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

در گام اول برای فراهم کردن امکان تعامل پایگاه داده با کاربر سیستم‌های محرک نظیر Oracle به وجود آمدند.

اما این نوع سیستم‌ها تنها قادر به تشخیص رویدادهای ساختاری نظیر اضافه، حذف و تغییر مقادیر در پایگاه داده می‌باشند.

به عبارت دیگر این سیستم‌ها با ایجاد تغییر در یک قلم داده عکس‌العمل نشان می‌دهند و این برای کاربران پایگاه داده کافی نیست.

برای این کاربران ممکن است رویدادهایی نظیر نخواندن حساب‌ها در آغاز ماه و یا یک رویداد خارجی نظیر فشردن یک کلید نیز مهم باشد که در این موارد سیستم‌های محرک، پاسخگو نیستند [2].

درگام بعد پایگاه داده فعال با افزودن قوانین به پایگاه‌های داده امکان تعامل (کنش و واکنش) بین سیستم و پایگاه داده را ایجاد نمود.

این نوع پایگاه داده دارای دو بخش مدیریت داده و مدیریت قوانین می‌باشد.

بخش مدیریت داده مسئول حفظ خواص پایگاه داده در سیستم‌های کاربردی بوده و بخش دوم با مدیریت قوانین مسئول واکنش به رویدادهای سیستم می‌باشد.

در این نوع پایگاه داده طراحان سیستم قادرند با تعریف قوانین که نزدیکترین بیان به زبان طبیعی می‌باشد، سیستم را وادار به عکس‌العمل مناسب در مقابل رویدادهای مهم نمایند [21].

پایگاه داده فعال با استفاده از قوانین قادر به «پشتیبانی گسترده‌تر قیود جامعیت و سازگاری داده‌ها، واکنش در مقابل رخدادهای سیستم کاربردی، عدم اجرای تقاضاهای مشکوک، ردیابی رویدادها، گزارشات ماهانه و...» می‌باشد.

همانطور که گفته شد آن‌چه که به طور معمول باعث می‌شود یک پایگاه داده را فعال بدانیم، عکس‌العمل سیستم در مقابل وضعیت‌هایی است که در پایگاه داده و یا حتی خارج از آن به وجود می‌آید.

این وضعیت‌ها می‌تواند شامل یک حذف غیرمجاز و یا بالا رفتن فشار محیط باشد.

باید توجه داشت که داشتن تعامل برای یک پایگاه داده لازم اما کافی نیست.

بسیاری سیستم‌های پایگاه داده بدون رعایت اصول پایه‌ای که در زیر به آن اشاره می‌شود به طور عام پایگاه داده فعال نامیده شوند [3].

اینگونه سیستم‌ها باید یک پایگاه داده باشند، یعنی در صورتی که کاربر فراموش کرد، سیستم مورد نظر پایگاه داده فعال است بتواند از آن به عنوان یک پایگاه داده معمولی استفاده نماید (در صورت لزوم بتوان به عنوان یک پایگاه داده معمولی از آن استفاده نمود).

در اینگونه سیستم‌ها باید امکان تعریف و مدیریت قوانین وجود داشته باشد.

این قوانین در پایگاه داده فعال دارای سه جزء رویداد، شرط و واکنش می‌باشند.

این سیستم‌ها باید دارای یک مدل اجرایی باشند.

به این ترتیب که با بروز رویداد و صحت شرط، واکنش قانون اجرا شود.

یک پایگاه داده فعال باید قادر به آشکارسازی رویدادها و بررسی شرط قوانین فعال و اجرای فرامین واکنش باشد.

علاوه بر موارد فوق، بهتر است در این سیستم‌ها محیط مناسبی برای تعریف و امکان کامپایل کردن قوانین فراهم شود که به کاربر در تعریف قوانین کمک کند.

فازی‌سازی پایگاه‌های داده فعال با هدف نزدیکتر نمودن زبان بیان قوانین به زبان طبیعی طراحان مطرح شد.

اغلب تقاضاهای کاربران پایگاه داده فعال، فازی می‌باشد.

به عنوان نمونه در تقاضاهایی نظیر عدم تعلق پاداش به کارمندان «کم‌کار»، «افزایش» فشارخون، محاسبه حقوق کارمندان در «پایان» هر ماه و...

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

تفاوت اصلی در فازی‌سازی پایگاه داده فعال با سایر سیستم‌های فازی، در نوع تعریف قوانین می‌باشد.

به این ترتیب که در تعریف قوانین در اینجا از سه جزء اصلی رویداد، شرط و واکنش استفاده می‌شود در صورتی که سیستم‌های مبتنی بر قانون عموماً از دو جزء شرط و واکنش تشکیل شده‌اند اما فازی نمودن شرط و واکنش قوانین در پایگاه‌های داده فعال تفاوت چندانی با شرط و واکنش فازی در سیستم‌های مبتنی بر قانون ندارد و در فازی نمودن رویداد نیز می‌توان از همان سیاق رویدادهای فازی استفاده نمود این بحث توسط ولسکی و بوازیز در [12] مطرح شده است.

در این پایان‌نامه سعی شده است بحث‌های مطرح شده در پایگاه‌های داده فعال فازی، با یک نمونه پیاده‌سازی شده بررسی شود.

همچنین سایر موارد قابل فازی‌سازی در یک پایگاه داده فعال بررسی شده است که از آن جمله می‌توان به فازی‌سازی وضعیت‌های زمانبندی و اولویت‌دهی فازی رویدادها اشاره نمود.

1-2 مروری بر فصول پایان‌نامه در ادامه این پایان‌نامه در فصل دوم مفاهیم پایگاه داده فعال ارائه شده است.

همچنین مدل اجرایی، نمونه‌هایی از این نوع پایگاه داده و برخی کاربردهای پایگاه داده فعال در ادامه این فصل آمده است.

در فصل سوم مختصری از مفاهیم فازی ارائه شده است.

فصل چهارم شامل چگونگی پشتیبانی مفاهیم فازی در بخش‌های مختلف یک پایگاه داده فعال می‌باشد.

فصل پنجم به ارزیابی پایگاه داده فعال فازی می‌پردازد و مزایا و معایب استفاده از پایگاه‌های داده فعال فازی نسبت به پایگاه‌های داده فعال با یک نمونه پیاده‌سازی شده و مقایسه آن با نمونه غیرفازی ارائه شده است.

در فصل ششم نتیجه فازی نمودن پایگاه داده فعال و مشکلاتی که حل شده است و آن‌چه باقی مانده ذکر شده است.

فصل دوم: پایگاه داده فعال پایگاه داده فعال با هدف افزودن تعامل به پایگاه داده و با استفاده از تعریف قوانین ایجاد شد.

اولین پایگاه داده فعال، توسط Dayal و همکارانش در یک پروژه دانشگاهی به نام [4]Hipac مطرح شد.

پایگاه داده این نرم‌افزار همانند [7]Reach، [8]Samos، [9]Exact، [10]Chimera شی‌ءگرا می‌باشد.

علاوه بر پایگاه‌های داده فعال شی‌ءگرا سیستم‌هایی با پایگاه داده‌ی فعال رابطه‌ای نیز ایجاد شده‌اند که از جمله آن‌ها می‌توان [5]Starburst و [6]Arial را نام برد، این نوع پایگاه‌های داده به جای واکنش در مقابل فراخوانی متد یا تغییر خصیصه‌ها به تغییر، حذف و اضافه در جداول پایگاه داده حساس می‌باشند [11].

از اواخر دهه هشتاد مبحث بانک اطلاعاتی مورد توجه قرار گرفت که ظهور محصولات تجاری نظیر [34]Versant و [34]Interbase موید این مطلب است.

بخش مدیریت داده مسئول حفظ خواص پایگاه داده نظیر سازماندهی، مدیریت و پشتیبانی داده‌های حجیم می‌باشد.

بخش دوم یا مدیریت قوانین مسئول واکنش به رویدادهایی است که در سیستم اتفاق می‌افتند.

2-1 مدیریت داده این بخش مسئول حفظ خواص پایگاه داده می‌باشد، به طوری که طراحان می‌توانند بدون ترجمه به قابلیت‌های پایگاه داده فعال و همانند یک پایگاه داده معمولی از آن استفاده نمایند.

ضمن اینکه خواص پایگاه داده را در یک پایگاه داده فعال می‌توان به صورت مطلوب‌تری ایجاد نمود.

برقراری قیود جامعیت توسط قوانین در پایگاه داده محدود می‌باشد.

این قیود در یک پایگاه داده معمولی فقط روی یک جدول قابل تعریف می‌باشند در حالی که با استفاده از قوانین پایگاه داده فعال، امکان تعریف محدودیت بر روی چندین جدول نیز وجود دارد.

همچنین سازگاری بین داده‌ها و امنیت با استفاده از قوانین به صورت گسترده‌تری پشتیبانی می‌شود.

2-2 مدیریت قوانین پایگاه داده فعال با استفاده از قوانین تعامل را به پایگاه داده می‌افزایند.

این امر باعث می‌شود بدون استفاده از کدهای نرم‌افزار به رویدادهای سیستم پاسخ داده شود، در نتیجه تغییر در ضوابط سیستم کاربردی با کمترین هزینه و با تغییر قوانین به راحتی امکان‌پذیر است.

در این فصل انواع تعریف و پیچیدگی‌های رفتاری قوانین در این نوع سیستم‌ها و مدل‌های اجرایی متفاوت (با توجه به تعریف یک قانون) ارائه خواهد شد.

2-2-1 تعریف قانون در پایگاه داده فعال هر قانون دارای سه بخش رویداد، شرط و واکنش می‌باشد و قانونی دارای هر سه جزء فوق باشد اصطلاحاً ECA نامیده می‌شود.

Rule Rule_Name [ON Event] [IF Condition] THEN Action به طور کلی وجود دو جزء رویداد و شرط در تعریف قوانین می‌تواند اختیاری و یا اجباری باشد.

در برخی نمونه‌های پیاده‌سازی شده پایگاه داده فعال تنها تعریف یکی از دو جزء اختیاری است یعنی امکان عدم تعریف رویداد در قانون وجود دارد و حضور شرط اجباری است.

در زبان‌هایی که تعریف هر دو جزء اختیاری باشد، تعریف یکی از آن‌ها در هر قانون الزامی است در غیر این صورت تبدیل به یک قانون همیشه درست می‌شود.

در صورت حذف شرط (EA Rule) با بروز رویداد، واکنش آن اجرا می‌شود و با حذف رویداد (CA Rule) در صورت برقراری شرط، واکنش قانون مربوطه به اجرا درمی‌آید.

در این قسمت ابتدا به شرح مختصری از هر سه جزء قانون و نکاتی که در استفاده از ECA باید رعایت شوند می‌پردازیم و سپس انواع رفتارهای مدل اجرایی پایگاه داده فعال بیان می‌شود.

2-2-1-1 رویداد رویدادها در نقطه‌ای از زمان اتفاق می‌افتند و به سه صورت تقسیم‌بندی می‌شوند.

در نوع اول با توجه به منبع به وجود آورنده خود به هشت گروه ساختاری، انتزاعی، تراکنش، کاربر، استثناء، زمان، خارجی و زیرمجموعه تقسیم می‌شوند.

در نوع دوم با توجه به اینکه از یک رویداد ساده تشکیل شده‌اند یا از ترکیب جبری منطقی رویدادهای ساده به وجود آمده‌اند به دو گروه ساده و مرکب تقسیم می‌شوند.

در نوع سوم با توجه به زمان بروز نمونه‌های یک رویداد به سه گروه آغازین، مبانی و پایانی تقسیم می‌شوند که در ادامه به شرح مختصری از انواع رویدادها در این سه گروه می‌پردازیم.

انواع رویدادها با توجه به منبع به وجود آورنده آن‌ها عبارتند از [13][14]: ساختاری: یک رویداد به دلیل انجام عملیاتی روی ساختار پایگاه داده فعال می‌شود (در مدل رابطه‌ای تغییر و حذف و اضافه یک رکورد و در مدل شی‌ءگرا تغییر خصیصه‌ها، فراخوانی متد و ارسال پیام).

ON Update emp.id انتزاعی: رویداد به صورت واضح توسط طراح یا برنامه کاربردی فعال می‌شود (طراح می‌تواند گرفتن یک گزارش خاص را یک رویداد معرفی کند که در صورتی که یک مجموعه تهی تولید نکند یک رویداد انتزاعی است).

تراکنش: رویدادها، دستورالعمل‌های تراکنشی نظیر Start و Abort و Commit می‌باشند.

ON Begin Transaction Emergency کاربر: رویداد به دلیل عملکردها و مکانیزم‌های برنامه‌نویسی فعال می‌شود (دادن پیام مناسب به کاربری که مشغول وارد کردن داده می‌باشد).

استثناء: انجام عملیات غیرمجاز در سیستم موجب بروز این نوع رویداد می‌شود (دستیابی غیرمجاز کاربران به اطلاعاتی که مجوز مناسب آن را ندارند).

زمان: این نوع رویدادها در نقطه‌ای از زمان فعال می‌شوند (مثلاً اول هر ماه).

خارجی: رویدادهایی که به دلیل وقوع رویدادی در خارج از سیستم بروز می‌کنند در این گروه قرار می‌گیرند (فشردن کلید).

زیرمجموعه: بیانگر زیرمجموعه‌ای از اطلاعات و یا اعضای خاصی از مجموعه می‌باشند (همه، به استثنای اهالی تهران و یا همه کسانی که مجوز حذف داده روی جدول اشخاص را دارند).

در نوع دوم رویدادها به دو دسته ساده و مرکب تقسیم می‌شوند.

رویدادی که تنها از یک جزء تشکیل شده است ساده و رویدادهایی که از ترکیب جبری و منطقی رویدادهای ساده به دست می‌آیند مرکب نامیده می‌شوند.

این عملیات‌های جبری عبارتند از [3]: And : رخ دادن هر دو رویداد (E1 And E2) OR : رخ دادن یکی از دو رویداد (E1 Or E2) Not : عدم رخ دادن رویداد در فاصله زمانی معین.

(E1; not E2;E3) به معنی عدم بروز رویداد دوم در فاصله زمانی بین بروز رویداد اول و سوم SEQ : نشان‌دهنده ترتیب اجرای دو رویداد می‌باشد.

(Seq (E1,E2) : به این معنا است که رخ دادن رویداد دوم باید پس از رویداد اول انجام یافته باشد از نماد ":" نیز استفاده می‌شود.

Times : بیانگر نمونه معین یک رویداد می‌باشد Times (n.E) یعنی نمونه nام رویداد E رویدادها در پایگاه داده فعال ممکن است به دفعات رخ دهند.

به رویدادهایی که اتفاق افتاده‌اند و از یک نوع می‌باشند، نمونه‌های یک رویداد گفته می‌شود.

در نوع سوم تقسیم‌بندی، بسته به زمان رخ دادن یک نمونه از رویداد، نمونه‌ها به سه نوع آغازین، میانی و پایانی تقسیم می‌شوند.

نمونه‌ای از یک رویداد که دارای کمترین مرتبه زمانی در بین نمونه‌های همان رویداد باشد نمونه آغازین و نمونه‌ای که دارای بیشترین مرتبه زمانی باشد نمونه نهایی رویداد نامیده می‌شود به سایر نمونه‌ها، نمونه‌های میانی گفته می‌شود [13].

در مثال زیر E1(1) یک نمونه آغازین و E1(4) یک نمونه پایانی رویداد E1 می‌باشند.

E1(1); E1(2); E1(3); E1(4) امکان وقوع همزمان نمونه‌های یک رویداد موجب ایجاد ناسازگاری در تعیین نوع نمونه‌ها می‌شود.

بحث همزمانی رویدادها در یک سیستم متمرکز تنها در دو صورت امکان‌پذیر است.

یکی از رویدادها زمانی و دیگری غیرزمانی باشد.

یک رویداد ساده با حداقل یک رویداد مرکب می‌توانند همزمان رخ دهند.

لازم به ذکر است دو رویداد ساختاری همزمان اتفاق نمی‌افتند به عبارت دیگر رخ دادن رویداد اضافه همزمان با رویداد حذف امکانپذیر نیست [15].

علاوه بر مرتبه رخ دادن نمونه‌ها ترتیب رخ دادن نمونه‌های یک نوع رویداد و نمونه‌های رویدادهای دیگر نیز قابل توجه است که آغازین و نهایی شدن نمونه‌ها را تحت تأثیر قرار می‌دهد.

مثلاً در توالی دو رویداد، انتخاب نمونه نهایی رویداد اول، می‌تواند نمونه رویدادی باشد که قبل از کلیه نمونه‌های رویداد دوم اتفاق افتاده است: Exclusive و با نمونه رویدادی باشد که قبل از آخرین نمونه رویداد دوم اتفاق افتاده است: Shared [13].

E1(1); E1(2); E2(1); E1(3) E1(2) Last Exclusive E(3) Last Shared 2-2-1-2 شرط بخش دوم قانون شرط می‌باشد.

پس از بروز یک رویداد نوبت به بررسی شرط قوانین رویداد مربوطه می‌رسد و در صورت صحت شرط، قانون مربوط در صف اجرا قرار می‌گیرد.

در قسمت شرط، یک مقایسه و یا یک پرس و جو می‌تواند قرار بگیرد، در صورتی که نتیجه پرس و جو تهی نباشد، شرط برقرار است.

انتخاب زمان بررسی شرط یک قانون پس از بروز رویداد آن از سیاست‌هایی است که توسط سیستم تعیین می‌شود.

این زمان می‌تواند فوری، تأخیری و یا مجزا باشد.

برخی سیستم‌ها تنها یک سیاست را پشتیبانی می‌کنند (نظیر NAOS) و برخی نیز همه سیاست‌ها را پشتیبانی می‌کنند (Hipac).

در چنین سیستم‌هایی در هر قانون سیاست مورد نظر طراح تعریف می‌شود و در صورت عدم تعریف، یک سیاست به عنوان پیش‌فرض برای همه قوانین در نظر گرفته می‌شود.

در تعیین شرط هر قانون، طراح باید بتواند برای ارزیابی شرط از مقادیر قبل و یا بعد از رویداد استفاده نماید.

نام تراکنشی که رویداد در آن اتفاق افتاده است و یا نام کاربری که باعث بروز رویداد شده نیز ممکن است در قسمت شرط استفاده شود.

این مقادیر به همراه رویداد ارسال می‌شود و پارامترهای رویداد نامیده می‌شود [16].

2-2-1-3 واکنش واکنش هر قانون کلیه عملیاتی است که در صورت وقوع رویداد و صحت شرط باید اجرا شود.

این عملیات عبارتند از اضافه، حذف و تغییر داده‌ها در پایگاه داده، تغییر مجموعه‌ای از قوانین، فراخوانی خارجی، ارسال پیام به مسئول و یا کاربران سیستم، انصراف از اتمام کار یک تراکنش و در نهایت به جای فرامین واکنش یک سری فرامین دیگر اجرا شود (به عنوان نمونه به جای انجام عملیات حذف پیامی به مسئول سیستم ارسال شود).

برخی زبان‌ها قادر به تعریف دو نوع متفاوت از اجرای واکنش یک قانون می‌باشند.

در نوع اول، ارزیابی و اجرا قبل از اجرای فرمان رویداد صورت می‌گیرد به عنوان مثال در SAMOS با استفاده از کلمه کلیدی Before انجام رویداد به بعد از اجرای فرامین واکنش موکول می‌شود و کلمه کلیدی After به معنای اجرای واکنش پس از اجرای رویداد می‌باشد [11].

به عنوان مثال با رسیدن فرمان حذف یک رکورد ابتدا یک پشتیبان تهیه و سپس عمل حذف انجام شود.

قابل ذکر است که تشخیص بروز یک رویداد قبل از رخ دادن آن در برخی از حالات نظیر تقاضای تغییر یک مقدار امکانپذیر است و در صورتی که یک رویداد خارجی باشد غیرممکن است (دادن اخطار قبل از فشرده شدن یک کلید).

انتخاب زمان اجرای واکنش یک قانون پس از ارزیابی شرط آن از سیاست‌هایی است که توسط سیستم تعیین می‌شود.

برخی سیستم‌ها تنها یک سیاست را پشتیبانی می‌کنند و برخی نیز همه سیاست‌ها را پشتیبانی می‌کنند.

در این صورت برای هر قانون این سیاست تعیین می‌شود.

هر یک از این سیاست‌ها در بخش بعد تشریح خواهد شد [3].

2-2-2 مدل اجرایی این مدل چگونگی اجرای مجموعه قوانین را در زمان اجرا نشان می‌دهد.

اگرچه این مدل با جنبه‌های زیربنایی پایگاه داده (ساختار، محیط و مدیریت اجرایی) مرتبط است اما به طور کلی چندین مرحله در ارزیابی عمومی قوانین وجود دارد که در ادامه شرح داده خواهد شد.

سیگنال: یک منبع بروز رویداد، منجر به وقوع رویداد می‌شود.

فعال‌سازی: بررسی رویدادها و یافتن قوانین نظیر رویدادی که در مرحله قبل سیگنال داده شده است.

ارزیابی: بررسی شرط قوانین فعال در این مرحله انجام می‌شود.

قوانینی که شرط آن‌ها برقرار است، مجموعه‌ای به نام Rule Conflict را تشکیل می‌دهند.

واکنش کلیه قوانین این مجموعه باید اجرا شود.

اجرا: واکنش قوانین مجموعه RC دراین مرحله اجرا می‌شود.

اجرای فرامین واکنش منجر به بروز رویدادهای جدیدی شده و به مرحله سیگنال وارد می‌شوند و این روند به صورت آبشاری ادامه خواهد داشت.

زمانبندی : زمان بررسی شرط و اجرای واکنش قوانین مجموعه RC در این مرحله تعیین می‌شود.

برای زمانبندی قوانین سیاست‌های متفاوتی وجود دارد که در ادامه شرح داده خواهد شد.

مراحل بالا الزاماً نباید پشت سر هم اجرا شوند اما به بروز رویداد و صحت شرط وابسته می‌باشند.

یعنی برای ارزیابی شرط لزوماً باید رویداد قانون اتفاق افتاده و برای اجرای واکنش مربوط به قانون باید ارزیابی شرط انجام شده باشد.

زمان بررسی و اجرای رویداد –شرط- واکنش بستگی به سیاست اتخاذ شده توسط سیستم دارد.

برخی سیستم‌های پایگاه داده فعال همه این سیاست‌ها را پشتیبانی نموده و طراح در تعریف قوانین خود زمان بررسی شرط و زمان اجرای فرامین واکنش را نیز تعریف می‌نماید.

این زمان و مقادیر ارسالی به شرط و واکنش (نام تراکنش، نام کاربر، مقادیر داده) از جمله موارد تمایز سیستم‌ها می‌باشند.

این سیستم‌ها (موقعیت‌های زمانبندی) عبارتند از: فوری: یعنی بلافاصله بعد از بروز رویداد (ارزیابی شرط) ارزیابی شرط (اعمال واکنش) انجام می‌شود.

تأخیری: در این حالت ارزیابی شرط (اجرای فرامین و واکنش) در همان تراکنش می‌باشد اما لزوماً در اولین فرصت نیست (معمولاً در پایان تراکنش)، این زمان قابل تعریف توسط طراح نیز می‌باشد.

مجزا: در این حالت بروز رویداد و ارزیابی شرط (ارزیابی شرط و اجرای فرامین واکنش) در دو تراکنش مجزا صورت می‌گیرد.

در چنین حالتی اجرای واکنش می‌تواند وابسته یا مستقل از به سرانجام رسیدن تراکنش باشد، ولی به هر حال رویداد اتفاق افتاده است و ارزیابی شرط انجام شده است و در صورت صحت شرط، فرامین واکنش در تراکنش دیگری اجرا می‌شود.

ارتباط بین رویداد و قانون می‌تواند یک به یک و یا یک به چند باشد.

در حالت اول به ازاء هر رویداد فقط یک قانون فعال می‌شود ولی در حالت دوم بروز یک رویداد می‌تواند چند قانون را فعال نماید.

از جمله مشکلاتی که سیستم‌های مبتنی بر قانون با آن مواجه هستند حصول نتایج متفاوت، در زمان‌های اجرایی مختلف می‌باشد.

این امر ناشی از اجرای قوانین با توجه به ترتیب نوشته شدن آن‌ها می‌باشد.

مشکل دیگر فعال نمودن قوانین توسط یکدیگر می‌باشد.

این امر زمانی مشکل‌آفرین می‌شود که یک سری از قوانین در یک حلقه، یکدیگر را برای اجرا فعال نمایند.

در ادامه این دو مشکل و راه‌حل‌هایی برای آن‌ها، ارائه می‌شود.

آخرین خصوصیتی که در مدل اجرایی باید در نظر گرفته شود پشتیبانی مدیریت خطا توسط سیستم می‌باشد.

اکثر سیستم‌ها به راحتی سیاست انصراف از تراکنش را در پیش می‌گیرند.

برخی سیستم‌ها نیز با حذف قانون به ادامه پردازش قوانین دیگر می‌پردازند، در صورت پشتیبانی پایگاه داده، مکان مدیریت استثنا نیز وجود دارد.

2-2-2-1 اولویت اجرایی در قوانین زمانی که چند قانون همزمان با هم فعال می‌شوند سیستم باید سیاستی را برای ترتیب فعال نمودن آن‌ها اتخاذ نماید.

انواع این سیاست‌ها در یک پایگاه داده فعال همانند سیاست‌هایی است که معمولاً در سیستم‌های خبره استفاده می‌شود.

ساده‌ترین روش برای فعال نمودن قوانین، انتخاب آن‌ها با همان ترتیب نوشته شدن قوانین توسط طراح می‌باشد.

امکان تعیین اولویت در هنگام تعریف قانون، روش دیگری است که روش قبل نیز حالت خاصی از همین روش می‌باشد.

در این روش مقادیر عددی به قوانین نسبت داده می‌شوند و قوانین مهمتر دارای اولویت بالاتری هستند.

در صورت عدم تعریف اولویت، برای قوانین پیش‌فرض صفر در نظر گرفته می‌شود و برای انتخاب قوانین هم اولویت روش اول جایگزین می‌شود.

حالت خاص دیگر دادن ارتباط است یعنی اگر دو قانون R1 و R2 با هم فعال شوند ابتدا قانون R1 اجرا شود و سپس قانون R2.

در غیر این صورت ترتیب مهم نیست.

در واقع تعیین اولویت برای برخی از قوانین انجام می‌شود.

مشخص کردن برخی قوانین که حتماً قبل از هر قانون دیگری اجرا شوند از دیگر سیاست‌ها می‌باشد و آخرین سیاست اینکه فقط یکی یا بعضی از آن‌ها را برای اجرا انتخاب کنیم [6].

انتخاب هر یک از این سیاست‌ها به نوع سیستم نیز بستگی دارد.

در یک سیستم توزیع شده این معیارها قابل پیاده‌سازی نیستند.

از طرفی در پایگاه داده فعال معمولاً اولویت زمانی نمونه‌ها نیز در نظر گرفته می‌شود.

2-2-2-2 پایان‌پذیری در قوانین در پایان‌پذیری قوانین هدف پیدا کردن قوانینی است که به تعداد نامحدود اجرا شده و موجب بروز پایان‌ناپذیری در اجرا و ایجاد وضعیت تکراری در پایگاه داده می‌شوند این مسأله به روش‌های مختلفی مورد بررسی قرار گرفته است [24][31].

تکرار دسته‌ای از قوانین در صورتی وضعیت تکراری ایجاد می‌کند که در محاسبه داده‌ها از مقادیر پایگاه داده استفاده شود و عملیات ریاضی روی مقادیر صورت نگیرد (در صورت تعریف قوانین ریاضی، تکرار اجرای دسته‌ای از قوانین وضعیت تکراری ایجاد نمی‌کند)[17].

در مدل ارائه شده توسط [17] Baralis، Ceri فرض بر این است که قوانین محاسباتی نیستند و هیچ چیزی از خارج پایگاه داده وارد نمی‌شود و ایجاد مقدار جدید فقط به واسطه بازیافتی از خود پایگاه داده می‌باشد.

همچنین قوانین خود غیرفعال فرض می‌شوند، یعنی هر قانون پس از اجرا، شرط خود را غیرفعال می‌سازد، در غیر این صورت منجر به ایجاد یک حلقه بی‌پایان به واسطه اجرای یک قانون می‌شود.

الگوریتم پردازش قوانین شامل گام‌های زیر می‌باشد: اگر هیچ قانونی برای فعال شدن وجود ندارد "خروج" یکی از قوانین مجموعه RC برای اجرا انتخاب می‌شود.

شرط قانون انتخاب شده ارزیابی می‌شود در صورت صحت شرط، واکنش قانون مربوطه اجرا می‌شود.

برای تعیین چگونگی کار قوانین، می‌توان از رسم گراف استفاده نمود.

این گراف‌ها پیدا کردن حلقه را آسان‌تر می‌کنند (وجود حلقه در گراف، بیانگر پایان‌ناپذیری در اجرای قوانین می‌باشد).

در قوانین ECA فعال شدن یک قانون به واسطه بروز رویداد و برقراری شرط می‌باشد و وقتی یک دسته قانون منجر به فعال شدن یک قانون می‌شوند که وقوع رویداد و برقراری شرط هر دو ناشی از اجرای واکنش این قوانین باشد.

در گراف به ازای هر گره یک قانون وجود دارد و قوانین، دارای کمان‌های ورودی ناشی از برقراری شرط و یا فعال شدن رویداد خود می‌باشند.

قوانینی که دارای یکی از این دو نوع کمان باشند حتماً به تعداد محدودی اجرا می‌شوند به دلیل آن‌که لازمه اجرا شدن قانون، برقراری هر دو (رویداد و شرط) می‌باشد و چنانچه یکی از این دو توسط رویدادی در خارج از سیستم برقرار شود اجرای قانون محدود خواهد بود (هیچ رویدادی در خارج از سیستم به تعداد نامحدود اجرا نمی‌شود).

با توجه به موارد مذکور می‌توان با یک الگوریتم، قوانینی که به تعداد نامحدود اجرا می‌شوند را پیدا نموده و آن‌ها را تغییر داده یا اجرای آنان را کنترل نمود.

چنانچه یک قانون که به تعداد محدود اجرا می‌شود، قانون دیگری را فعال کند، فعال‌سازی‌ها نیز محدود بوده و در نتیجه قانون فعال شده به تعداد محدود اجرا می‌شود، به این ترتیب الگوریتم به صورت بازگشتی قوانین را حذف کرده و مجموعه قوانینی را که اجرای نامحدود دارند پیدا می‌کند.

با این روش می‌توان در زمان کامپایل قوانینی که دارای اجرای نامحدود می‌باشند را یافته و در زمان اجرا آن‌ها را کنترل نمود.

در روش دوم در زمان اجرا، با مقایسه وضعیت‌هایی که در پایگاه داده ایجاد می‌شود.

می‌توان در صورت بروز پایان‌ناپذیری، اجرای قوانین را متوقف نمود.

چنانچه مجموعه مقادیر خوانده و نوشته شده توسط یک قانون تکرار شود، یعنی به وضعیتی برود که قبلاً در همان وضعیت بوده است حالت جدیدی به وجود نیامده و در نتیجه یک حلقه بی‌پایان ایجاد شده است (این فرضیه تنها در صورتی درست است که عملیات محاسباتی یا رویدادی با منبع خارجی وجود نداشته باشد)، با پیدا کردن وضعیت‌های تکراری می‌توان از اجرای واکنش قانون جلوگیری نمود و این کار منجر به جلوگیری از پایان‌ناپذیری می‌شود [5].

به این ترتیب الگوریتم پردازش قوانین به صورت زیر تغییر می‌کند: اگر هیچ قانونی برای فعال شدن وجود ندارد "خروج" اگر این حالت اجرایی قبلاً به وجود آمده است "اتمام کار" درغیر این صورت ذخیره حالت اجرایی (می‌توان در صورت تکرار حالت اجرایی، سیگنال حلقه داد) انتخاب یکی از قوانین فعال شده و غیرفعال کردن آن ارزیابی شرط قانون انتخاب شده اگر شرط آن برقرار است اجرای واکنش قانون انتخاب شده همانطور که مشاهده می‌شود قسمت دوم تغییر یافته است که برای بهبود کارآیی می‌توان فقط حالت اجرایی قوانینی را ذخیره کرد، که منجر به پایان‌ناپذیری می‌شوند و در بررسی هنگام کامپایل به دست آمدند.

برای بهبود کارآیی از شبکه Lattice نیز می‌توان استفاده نمود که جزئیات آن در [17] آمده است.

2-2-2-3 معماری پایگاه داده فعال در این بخش یک معماری ساده برای سیستم‌های پایگاه داده فعال که قادر به پردازش قوانین و پاسخ به تقاضاهای کاربر روی پایگاه داده باشد ارائه خواهد شد.

شکل 2-1 ساختار یک معماری ساده برای پایگاه داده فعال می‌باشد این ساختار بر پایه ساختار ارائه شده در [11] می‌باشد.

این ساختار برای پایگاه‌های داده فعال متمرکز می‌باشد.

معماری پایگاه‌های داده فعال توزیع شده در [23]، [25] و [28] ارائه شده است.

؟؟؟

2-1 معماری پایگاه داده فعال این سیستم شامل چهار بخش اصلی آشکارساز رویداد، بررسی شرط، زمانبند و اجرا می‌باشد که در ادامه به شرح هر یک از این بخش‌ها می‌پردازیم.

بخش آشکارساز رویداد خود شامل دو بخش مجزا برای تشخیص رویدادهای «ساده» و «مرکب» می‌باشد.

در بخش بررسی شرط به مقادیر متفاوتی (قبل و بعد از وقوع رویداد نیاز است).

بخش اجرا شامل دو بخش اجرای واکنش قوانین و پاسخ به پرس‌وجوهای پایگاه داده می‌باشد.

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

این ساختار ساده پایه یک پایگاه داده فعال می‌باشد.

در ادامه به شرح مختصر هر یک از این بخش‌ها می‌پردازیم.

این معماری بر پایه مدلی است که در [11] ارائه شده است.

2-2-2-4 آشکارساز رویداد رویداد قوانین را می‌توان به صورت ساده یا مرکب تعریف نمود.

رویداد مرکب از ترکیب جبری رویدادهای ساده به وجود می‌آید در نتیجه رویدادی که اتفاق می‌افتد ساده بوده و هیچ رویدادی به صورت مرکب بروز نمی‌کند.

در قسمت آشکارسازی رویدادهای ساده، به دلیل آنکه هر رویدادی در داخل یا خارج از سیستم، یک رویداد ساده است مدیریت کلیه رویدادهایی که اتفاق می‌افتند با این قسمت است.

ضمن اینکه ثبت تاریخچه رویدادها برای استفاده آشکارساز رویداد مرکب نیز در همین بخش انجام می‌شود این تفکیک موجب سهولت و خاص شدن وظایف هر یک از این دو بخش می‌شود.

بخش دیگر آشکارساز رویدادهای مرکب می‌باشد که با استفاده از تاریخچه رویدادهای ساده، رویدادهای مرکبی که همه آن‌ها به وقوع پیوسته‌اند شناسایی نموده و برای بررسی شرط معرفی می‌شوند (معمولاً در یک صف برای بررسی شرط در زمان مناسب قرار می‌گیرند).

هر رویداد مرکب نیز می‌توان بخشی از یک رویداد مرکب دیگر باشد.

هر دو بخش آشکارساز رویداد (ساده و مرکب) دو وظیفه عمده دارد.

یکی ارسال پارامترهای مربوط به رویداد آشکار شده و دیگری ثبت بروز رویداد مربوطه برای استفاده رویدادهای مرکب، که پارامترها و نوع اطلاعاتی که ثبت می‌شود به سیاست سیستم بستگی دارد.

زمان بررسی شرط نیز توسط زمانبند و با توجه به نوع سیاست زمانبندی تعیین می‌شود.

در صورت امکان تعریف همه انواع زمانبندی، در هر قانون نوع زمانبندی توسط طراح تعیین شده و در همان زمان بررسی انجام می‌شود.

از دیگر سیاست‌هایی که در سیستم‌ها متغیر هستند، امکان عدم تعریف شرط می‌باشد که در صورت وجود چنین امکانی، اجرای قوانین پس از بروز رویداد باید محقق شود.

بسته به سیاست سیستم، پارامترها و روش ارسال اطلاعات متفاوت است.

در سیستمی نظیر starburst این اطلاعات در یک جدول ثبت می‌شود در بخش بعد این سیستم معرفی خواهد شد.

2-2-2-5 ارزیابی شرط در قسمت آشکارساز صحت شرط (CD)، از جمله نیازهای طراح مقادیر در وضعیت‌های متفاوت پایگاه داده می‌باشد.

در یک پایگاه داده فعال چهار وضعیت برای داده‌ها در پایگاه داده به وجود می‌آید.