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

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


پایگاه داده های هوشمند بخش چهارم تاریخ درج: ١٣٩۶/٠٧/١۶

 قابلیت اتصال منطقی 

یکی دیگر از ویژگی های مهم IDI سهولت تلفیق آن با سیستم های مختلف AI است. گذشته از استفاده از Lisp به عنوان زبان پیاده سازی IDI ، این کار توسط یک زبان منطقی دیگر به عنوان زبان پرس و جو برای IDI نیز ممکن است. زبان IDIL می تواند به عنوان یک زبان پرس و جوی مستقل استفاده شود. این زبان به خوبی با زبان ارائه دانش سیستم AI منطقی تلفیق شده است. در مورد آخر، نکته کلیدی این است به IDI اجازه دهیم که متغیرهای منطقی را همانند سیستم AI به اشتراک بگذارد. اگر این کار به خوبی انجام گیرد می توان به سادگی مجموعه کوچکی از توابعی را که IDI از آنها برای تشخیص و ساخت متغیرهای منطقی استفاده می کند، تعریف کرد. 
زبان پرس و جوی IDIL1 زیرمجموعه محدودی از عبارات Horn است که سرآیند یک عبارت بیانگر لیست هدف (یعنی فرم رابطه های نتیجه شده) و بدنه عبارت اجتماع علائمی است که رابطه ها و عملیات روی رابطه ها و توصیفگرهای آنها را نشان می دهند. (منفی سازی، اجتماع و عملیات حسابی). شکل 2 چند نمونه پرس و جو را نشان می دهد. 
ساختار IDI 
همان طور که شکل 3 نشان می دهد، چهار قسمت اصلی وجود دارد  که عبارتند از: مدیر شِمای IDI ، مدیر اتصال به DBMS ، مدیر پرس وجو، مدیر حافظه نهان و کش). سه قانون نیز وجود دارد: 
نام تولید کننده را برای تولیدکنندگانی که قطعه P2 را تولید نکرده اند، پیدا کن. 
((ans-sname) 
<- 
(supplier-sno-sname-status-city) 
(not(supplier-part-sno”P2-Qty)))
نام تولید کننده و تعداد قطعات تولیدی را برای تولیدکنندگانی که بیش از 300 واحد از قطعه P2 تولید کرده اند، را پیدا کن. 
((ans-sname-Qty) 
<- 
(supplier –sno-sname-status-city)
(supplier-part-sno”P2”-Qty) 
(>-Qty300)
>
شکل 2: دو نمونه پرس و جوی IDIL با استفاده از پایگاه داده “\suppliers” «تولیدکنندگان» نمادهایی که با کاراکتر “\” شروع می شوند متغیرهای منطقی هستند. سه دسته ورودی یا درخواست برای IDI وجود دارد: (a) اعلان پایگاه داده؛ (b) یک پرس و جوی IDIL و درخواست های بازیابی نتایج یک پرس و جوی IDIL و (c) مشاور با مدیر حافظه نهان (کش). اعلان پایگاه داده اطلاعات ابتدایی پایگاه داده را بیان می کند، یعنی نوع DBMS ای که پایگاه داده در آن قرار دارد و host machine (ماشین میزبان) DBMS IDI برای هر پرس و جوی IDIL یک تولید کننده  را بر می گرداند که از آن برای بازیابی نتایج پرس و جوی IDIL به صورت یک تاپل در هر بار استفاده می شود. IDI انواع دیگر درخواست ها یعنی درخواست اطلاعات دسترسی به شِما که در جای دیگری شرح داده شده را پشتیبانی می کند. 
مدیر شِما (SM) مسئول مدیریت اطلاعات شِما برای پایگاه داده های اعلان شده است و اطلاعات شِما را برای رابطه های مجزای پایگاه داده فراهم می‌آورد و به مدیر پرس و جو می دهد. این اطلاعات عبارتند از اعلان پایگاه داده های در حال پردازش، اطلاعات مربوط به دستیابی و ذخیره سازی شماها برای پایگاه داده های اعلان شده، مدیریت نام های مستعار رابطه ها که زمانی که دو یا چند پایگاه داده شامل رابطه های هم نام هستند از آنها استفاده می‌شود. 
وقتی یک اتصال به پایگاه داده ساخته شد، SM به طور اتوماتیک به لیست نام های رابطه هایی که در پایگاه داده وجود دارند دسترسی پیدا می کند. سپس این لیست برای دسترسی های بعدی در زمانی که اتصال بسته و در زمانی بعد دوباره باز شود، کش می شود. در حافظه نهان نگهداری می گردد. در این زمان SM فقط به اطلاعات شِمای DBMS دسترسی دارد، در غیر اینصورت، لیست نام های رابطه ها که در حافظه نهان نگهداری شده اند، مورد استفاده قرار می گیرد. 
مدیر ارتباطات (DCM) DBMS همه اتصالات پایگاه داده به DBMS های راه دور را مدیریت می کند. این شامل پردازش درخواست های اتصالات باز و بسته پایگاه داده و اجرای همه عملیات سطح پایین مرتبط با اتصالات است. در IDI ، هر پایگاه داده حداکثر یک اتصال فعال مرتبط دارد که در آن هر اتصال صفر یا چند رشته نتیجه پرس و جو یا تولیدکنندگان مرتبط (اما فقط یک تولید کننده می تواند فعال باشد) قرار دارد. 
مدیر پرس و جو (QM) مسئول پردازش پرس و جوهای IDIL و مدیریت نتایج آنها است. پرس و جوهای IDIL با ترجمه آنها SQL مدیریت و پردازش می شوند. 
(شکل 3: IDI شامل چهار جزء اصلی است: مدیر شما اطلاعات شِما را برای پایگاه داده های اعلان شده، مدیریت می کند. مدیر اتصالات، به DBMS های راه دور را اداره می نماید. مدیر پرس و جو مسئول پردازش پرس و جوهای IDIL و نتایج آن ها است و مدیر حافظه نهان، کش نگهدارنده نتایج پرس‌وجوها را کنترل می کند.)
QM برای پردازش پرس و جوهای IDIL ، آنها را به زبان SQL ترجمه می کند و سپس به DBMS مربوط می فرستد. اگر پرس و جو به طور موفقیت آمیز توسط DBMS اجرا شد سپس QM یک تولید کننده (generator) برای پرس و جو بر می گرداند. 
به طور ساده یک تولید کننده یک نوع داده انتزاعی است که برای نشان دادن نتایج یک پرس و جوی IDIL به کار می رود. دو نوع عملیات توسط تولیدکننده انجام می شوند: (a) گرفتن تاپل (سطر) بعدی از رابطه های نتایج و (b) خاتمه دادن (حذف تاپل های باقیمانده). تولیدکننده ها توسط DCM تولید و مدیریت می شوند زیرا بیش از یک نمایش و ارائه، برای هر رابطه نتیجه ممکن است. یعنی هر رابطه نتیجه می تواند از DBMS یا یک عنصر کش (حافظه نهان) به دست آید. 
در طول درخواست برای تاپل بعدی یا خاتمه عملیات، QM صرفاً generator (تولید کننده) ها را به QCM می فرستد. مدیر حافظه نهان (کش) مسئول مدیریت کشِ نتایج پرس و جو است. این کار شامل تشخیص پرس‌وجوهای IDIL برای نتایجی که در کش موجودند، کش کردن نتایج پرس‌وجو، و جایگزینی عناصر کش می شود. علاوه بر این، طراحی ما به سیستم AI اجازه می دهد تا مدیر حافظه نهانی ایجاد کند که کمک کند تا تصمیم بگیرد چگونه کش خود را مدیریت کند و تصمیمات بحرانی که در زیر به آنها اشاره شده است را اتخاذ کند: 
- واکشی اولیه: با پیش بینی نیاز به رابطه ها، مشخص کنیم که چه رابطه‌هایی و در چه زمانی واکشی خواهند شد؟ این باعث افزایش سرعت قابل توجهی خواهد شد زیرا سرور پایگاه داده به صورت یک فرآیند مجزا اجرا می‌شود. این کار همچنین در محیط هایی که بانک های اطلاعاتی از طریق شبکه‌هایی که لینک های آنها غیر قابل اطمینان است مورد دسترسی قرار می‌گیرند، مفید است. 
(رابطه های بحرانی یک بانک اطلاعاتی به طور پیشرفته مورد دسترسی قرار می گیرند تا از در دسترس بودن آنها در هنگام نیاز، مطمئن شویم.) 
- کش کردن نتایج: کدام نتایج پرس و جو باید در کش ذخیره شوند؟ رابطه‌های اصلی و مشتق شده از نظر کاربرد و استفاده متفاوتند. کش کردن بعضی از آنها نادرست است زیرا نسبت به بقیه خیلی زودتر مورد استفاده قرار خواهند گرفت. 
- تولید پرس و جو: چه پرس و جوهایی را می توان قبل از ارائه آنها به DBMS به طور موثر تولید کرد؟ تولید پرس و جو یک روش مفید برای کاهش تعداد پرس و جوهایی که در بسیاری از سیستم های خبره رضایت بخش، ایجاد می شود، است. همچنین یک روش کلی برای اداره کردن پرس و جوهای مورد انتظار بعد از یک جوای \null (تهی)، می باشد. 
- جایگزینی: وقتی که کش پر می شود، چه رابطه هایی را باید از آن خارج کنیم و حذف نماییم؟ برحسب نوع سیستم مبتنی بر کش، یکی از انواع بسیار مشکل طراحی، مشکل اعتبارسنجی کش را حل می کند. در این حالت، مشخص می کنیم که چه زمانی ورودی های نامعتبرکش در نتیجه به روز رسانی داده‌های مرتبط در DBMS ایجاد شده اند. این پیاده سازی ها، به قصد اعتبارسنجی کش نیست و در تحقیقات آینده بر روی آن متمرکز خواهیم شد. برنامه های زیادی برای تعیین اعتبارسنجی کش وجود دارد و بنابراین اعتبارسنجی کش یک مشکل نیست. این شامل دسترسی به پایگاه داده هایی که کاملاً محافظت شده اند و به ندرت به روزرسانی می شوند، مثل پایگاه داده Official Airline Gourde (راهنمنای خطوط هوایی)، و پایگاه داده هایی که با گستره زمانی که برنامه های کاربردی AI به آنها دسترسی می یابند، مرتبط می شوند. این مشکل در هر سیستم AI که بخشی از داده های خود را از منابع خارجی می گیرد و آنها را در منبع دانش خود ذخیره می کند بسیار معمول (رایج) است. 
اغلب interface (واسط) های موجود که در بین پایگاه داده و سیستم های AI قرار دارند، اصلاً از این مسئله نگران نیستند. راهکار ما، برای حداقل سازی کپی کردن سیستم های AI پایگاه داده به دو طریق تلاش می کند. 
اول، با فراهم ساختن دسترسی های موثر و مناسب به اطلاعات پایگاه داده، تولیدکنندگان سیستم AI نیاز کمتری به ایجاد یک کپی محلی از داده، دارند. دوم اینکه همه اطلاعات پایگاه داده که کپی شده اند در یک مکان جمع آوری می‌شوند و بنابراین خیلی راحت مدیریت می گردند. راهکارهای متعددی برای مسئله اعتبارسنجی وجود دارند که از نظر کامل بودن و سادگی پیاده سازی متفاوتند. نمونه هایی از اجزای ممکن در یک سیستم اعتبارسنجی کش عبارتند از: فقط کش کردن رابطه های ثابت و پایدار، فقط کش کردن داده بین به روزرسانی های زمانبندی شده DB ، استفاده از منحنی زوال (و توابع هیوریستیک) برای تخمین اعتبار داده ها، و پیاده سازی “a\snoopy cache” که بر تراکنش های پایگاه داده نظارت می کند و مراقب به روزرسانی هایی که داده های کش را نامعتبر می کنند، است. 
(شکل 4: کل زمان پردازش به سه مرحله اصلی از پردازش تقسیم می شود: ترجمه، اجرا، و جمع آوری. برای هر مرحله از پردازش، مینیمم، متوسط و ماکزیمم زمان نشان داده شده است.) 
وضعیت های جاری 
کارایی 
IDI همان طور که در اینجا شرح داده شد، به کمک زبان Common Lisp پیاده سازی شده و به عنوان یک پردازشگر پرس و جوی مستقل در برابر دو پایگاه داده مختلف روی RTIINGRES تست شده و همچنین به عنوان یک سرور پرس و جو در پروژه های زبان Unisys استفاده شده است. نتایج بدست آمده از کارایی آن، زیادند که بهترین آنها عبارتند از: 
اندازه رشته آزمایشی نسبتاً کوچک بوده و در حال حاضر IDI با یک سیستم AI تلفیق شده است. هر چند، نتایج دلگرم کننده بوده و زمینه هایی از امکان دسترسی موثر به پایگاه داده به کمک IDI را نشان می دهد. در ادامه تعدادی از نتایج کارآمد و جالب این آزمایش را ذکر می کنیم: 
یک مجموعه آزمایشی از پرس و جوهای IDIL که شامل 48 پرس و جو بود و از این میان 22 پرس و جوی منحصر به فرد وجود داشت (یعنی هر پرس و جو حداقل یک بار در مجموعه آزمایشی تکرار شده بود). پرس‌وجوها از دسته های ساده (یعنی آنهایی که فقط از عملیات select (انتخاب) و project (عمل پرتو یا انتخاب ستون) استفاده می کنند) تا پیچیده (آنهایی که علاوه بر عملیات select و انتخاب سطر) و project (انتخاب ستون) از 4 نوع الحاق (join) هم استفاده می کنند.) را پوشش می داد. اندازه رابطه های نتیجه بین صفر تا 17 تاپل (سطر) جواب بود. آمارهایی که در اینجا ذکر شده براساس متوسط زمان پردازش برای 20 بار تکرار روی پرس و جوهای مجموعه آزمایش است. شکل 4، تقسیم زمان پردازش به سه مرحله اساسی پردازش را نشان می دهد. این مراحل عبارتند از: ترجمه (زمان لازم برای ترجمه پرس‌وجوی IDIL به زبان SQL)، اجرا (زمان صرف شده بین ارسال پرس‌وجوی SQL به DBMS و به دست آوردن اولین تاپل (سطر) از جواب) و جمع آوری زمان لازم برای جمع آوری همه تاپل های جواب و تبدیل آن ها به یک فرم داخلی). برای هر مرحله پردازش، ببینیم، متوسط و ماکزیمم زمان پردازش نشان داده شده است. کش برای چنین اندازه گیری هایی نمی تواند استفاده شود، بنابراین یک تصویر بسیار دقیق از زمان های پردازش برای هر مرحله چاپ شده است. 
(شکل 5: کارایی کش در سه مورد، مورد بررسی قرار می گیرد: 
(a) نداشتن کش یا حالت اصلی غیر فعال بودن Caching. (b) حالتی که کش خالی باشد که Caching فعال است اما کش قبل از هر تکرار مجموعه تست‌ها پاک می شود. (c) حالتی که کش خالی نیست و کش حاوی نتایج پرس‌وجوهای مجموعه تست است.) 
تفاوت در زمان لازم برای ترجمه، تفاوت در تعداد رابطه های پرس‌وجوی IDIL را منعکس می کند. به همین ترتیب، زمان لازم برای جمع آوری تابعی از تعداد تاپل های موجود در رابطه جواب است. در هر دوی این موارد، زمان پردازش به طور مشخصی از زمان اجرا کمتر است، که این در نتیجه پیچیدگی پرس‌وجوی SQL ، سربار ارتباطات و بارگذاری در میزبان DBMS راه دور می باشد. (زیرا فقط زمان سپری شده ثبت می گردد) 
شکل 5 اثرات کش کردن نتایج بر کارایی را نشان می دهد. نتایج، میانگین زمان پردازش برای همه پرس و جوها را بر حسب ثانیه نشان می دهند. سه حالت مختلف ممکن است رخ دهد (a) نداشتن کش یا حالت اصلی غیر فعال بودن caching (b) حالتی که کش خالی باشد، اما caching فعال است و کش قبل از هر تکرار مجموعه تست، پاک می شود، (c) حالتی که کش خالی نیست و کش حاوی نتایج پرس و جوهای مجموعه تست است. 
تفاوت بین حالت اصلی و حالت کش خالی در تعداد پرس و جوهای تکرار شده است. (یعنی 26 از 48 پرس و جو، تکرار شده اند.) این حقیقت که حالت اصلی بیش از دو برابر حالت کش خالی رخ می دهد، نشان می دهد که سربار مورد نیاز برای کش کردن نتایج، اهمیتی ندارد. 
حالتی که در آن کش خالی نیست، ماکزیمم پتانسیل مثبت کش کردن نتایج را نشان می دهد. (یعنی نزدیک به 2 برابر کارایی). واضح است که این فقط در صورتی رخ می دهد که کش به صورت \stacked” در تست باشد. هر چند، این کمک می کند تا حد بالایی برای میزان افزایش کارایی توسط کش کردن نتایج، به دست آوریم. روشن است که هر گاه تعداد پرس و جوهای تکرار شده افزایش یابد، کارایی نیز افزایش می یابد. 
کاربردهای IDI 
واضح است که نتایج با کارایی بیشتر، برای به دست آوردن مجموعه تست‌های جامع و کامل لازم است. این، به خصوص برای تلفیق IDI با سیستم AI و اندازه گیری کارایی آن در برنامه های مختلف، اهمیت دارد. معمولاً از IDI برای فراهم ساختن یک سرورِ پایگاه داده برای سیستم تشخیص زبان Unisys استفاده می کنیم و تلفیق IDI با سرور سیستم هوشمند و بیان Protem  را مورد بررسی قرار می دهیم. 
ISS , IDI 
Protem یک سیستم مرکب است که همزمان شامل یک سیستم ارائه مبتنی بر فریم و یک عنصر پاسخگوی منطقی می باشد. تلفیق یک سیستم ارائه مبتنی بر فریم با یک سیستم مدیریت پایگاه داده رابطه ای، درست نیست. راهکار معمول ما، برچسب گذاری بعضی از کلاس های موجود در سیستمِ فرم به عنوان \data base classes” (کلاس های پایگاه داده) است. هر فعالیت مبتنی بر دانش که به دنبال نمونه هایی از این کلاس می گردد، به رشته ای از \data base instances” (نمونه های پایگاه داده) که نتیجه فرستادن پرس و جو به پایگاه داده از طریق IDI است، دست می یابد. به منظور اجتناب از پر شدن حافظ مبتنی بر دانش از اطلاعات پایگاه داده، این نمونه ها به عنوان اشیاء اصلی پایگاه دانش نصب نمی شوند اما به عنوان \light weight objects” (اشیاء سبک وزن) که فرآیند آزادسازی حافظه  برای آنها به راحتی انجام می‌گیرد، وجود دارند. همچنین آنها \fully instantiated” نیستند. 
بنابراین، مقادیر مربوط به وظایف فریم ها، لزوماً نصب نمی شوند. به جای آن، اگر تلاشی برای دستیابی به وظایف فریم ها صورت گیرد، پرس‌وجوهای افزوده شده به پایگاه داده برای بازیابی اطلاعات، به طور اتوماتیک تولید می‌گردند. به همین ترتیب، این اطلاعات هم به داده های ثابت پایگاه دانش اضافه نمی شوند، بلکه فقط فرآیند جاری از آنها استفاده می کند. 
این راهکار سه مزیت دارد: پیاده سازی آن آسان است، برای کاربر شفاف و واضح است و کلیدی برای حل مشکل جداسازی کپی داده به منظور اعتبارسنجی کش است. حال که ارتباط بین یک کلاس پایگاه داده و جدول پایگاه داده مربوط به آن مشخص شده کلاس و نمونه های مربوط به آن می‌توانند مانند دیگر اشیاء پایگاه دانش عمل کنند. هر چند، بدون پیاده سازی کش IDI ، این عمل بسیار کند انجام می گرفت. 

سرور IDI ATIS 

دومین سیستم AI که IDI از آن برای پشتیبانی استفاده می کند یک واسط زبانِ به کار رفته در پایگاه داده «سیستم اطلاعات مسافرت هوایی»است. در این پروژه، پرس و جوهای به کار رفته، توسط یک سیستم تشخیص صدا پردازش می شوند و با سیستم زبان طبیعی Unisys Pundit تفسیر می گردند. تفسیر حاصل شده، به پرس و جوی IDIL تبدیل می شود و سپس برای ارزیابی به سرور ATIS فرستاده می شود. این سرور رویه مجزایی را بر روی IDI اجرا می کند. به این ترتیب که پرس و جوهای SQL را به سرور پایگاه داده INGRES ارائه می کند. دامنه \travel agent” ، یک منبع غنی از اطلاعات روزمره است که برای استنباط اهداف کاربران از پرس و  جوهای آنان به کار می رود. از این اهداف برای ایجاد گزینه های هوشمند درباره تولید پرس و جو، واکشی و جایگزینی در مدیر کش (حافظه نهان) استفاده می گردد. معمولاً ما یک سرور AIIS در حال اجرا داریم و آمارهایی از تعاملات و تراکنش های آن جمع آوری می کنیم تا بعداً از آنها برای تعریف استراتژی های پیشنهادی موثر استفاده نماییم. 
 
نتیجه گیری:
گرچه پیاده سازی IDI تمام نشد، اما شالوده محکمی برای ساخت آسان یک واسط پیچیده برای DBMS های موجود فراهم آورد. خصوصیات کلیدی IDI عبارتند از: کارایی، استفاده آسان و قابلیت حمل و نقل بالا که آن را انتخاب ایده آلی برای پشتیبانی از AI و برنامه های مرتبط با آن که نیاز به دسترسی به DBMS های راه دور دارند، ساخته است. در طول توسعه و تکمیل IDI که برای آینده برنامه ریزی شده است، قسمت مدیریت کش  اهمیت زیادی دارد. در حال حاضر، پیاده سازی CM بر کش کردن کارآمد نتایج و دیگر عملیات مدیریتی کش که پیاده سازی شده اند، متمرکز است. مراحل اولیه این کار، مشخص کردن اندازه ای محدود برای کش و پیاده سازی استراتژی جایگزینی کش هستند. مراحل بعدی تکمیل CM عبارتند از: اعتبارسنجی کش و توانایی ایجاد عملیات بر روی DBMS در عناصر کش. 
اگر IDI تکمیل شود، می تواند عملیات DBMS مانند را بر روی محتویات کش خود اجرا کند، سپس یک پرس و جوی IDIL را بگیرد و برای تولید نتایج، سه دسته عملیات انجام دهد: (a) کل پرس و جوی IDIL می تواند به زبان SQL ترجمه شود و برای اجرا به DBMS راه دور فرستاده شود. (b) کل پرس و جوی IDIL به طور محلی توسط IDI اجرا شود (شامل بازیابی از کش) و (c) پرس و جوی IDIL می تواند تجزیه شود و قسمتی از آن در DBMS راه دور و قسمت دیگر به طور محلی توسط IDI اجرا شود.
 تصمیم گیری در مورد اینکه چه کاری باید انجام گیرد، بستگی به فاکتورهایی مثل محتویات موجود در کش و تخمین هزینه برای هر گزینه دارد. 

تگها: SQl Server   پرس و جوی هوشمند SQL   ساختار DBMS   مدیریت پایگاه داده   
 

HyperLink

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