دانلود با لینک مستقیم و پر سرعت .
بهینهسازی و پردازش پرس و جو:
در این فصل، به تکنیک‌های بکار رفته توسط DMBS برای پردازش، بهینهسازی و اجرای پرس و جوهای سطح بالا می‌پردازیم.
پرس و جوی بیان شده در زبان پرس‌و جوی سطح بالا مثل SQL ابتدا باید پویش و تجزیه . معتبر شود. پویشگر (اسکنر) علامت هر زبان، مثل لغات کلیدی SQL، اساس ویژگی، و اساس رابطه، را در متن پرس و جو شناسایی می‌کند، در عوض تجربه کننده، ساختار دستوری پرس و جو را برای تعیین اینکه آیا بر طبق قوانین دستوری زبان پرس و جو تدوین می‌شود یا خیر، چک می‌کند. پرس و جو باید همچنین معتبر شود، با چک کردن اینکه تمام اسامی رابطه و ویژگی معتبر هستند و اسامی معنی‌دار در طرح پایگاه اطلاعاتی ویژها‌ی پرس و جو می‌شوند. نمونه داخلی پرس و جو ایجاد می‌شود، که تحت عنوان ساختار داده‌های درختی بنام درخت پرس و جو می‌باشد. ارائه پرس و جو با استفاده از ساختار داده‌های گراف بنام گراف پرس و جو نیز امکان پذیر است. DOMS باید استراتژی اجرایی برای بازیابی نتیجه پرس و جو از فایل‌های پایگاه اطلاعاتی را هدایت کند. پرس و جو استراتژیهای اجرایی بسیاری دارد. و مرحلة انتخاب، مورد مناسبی برای پردازش پرس وجو تحت عنوان بهینهسازی پرس و جو شناخته شده است.
تصویر 1801، مراحل مختلف پردازش پرس و جوی سطح بالا را نشان می‌دهد. قطعه بر نامه بهینه‌ساز پرس وجو، وظیفه ایجاد طرح اجرایی را بعهده دارد و ژنراتور (تولید کننده) که ، کد را برای اجرای آن طرح ایجاد می‌کند. پردازنده پایگاه اطلاعاتی زمان اجرا وظیفه اجرای که پرس و جو را بعهده دارد، خواه در وضعیت کامپایل شده یا تفسیر شده جهت ایجاد نتیجه پرس و جو. اگر خطای زمان اجرا نتیجه شود، پیام خطا توسط پایگاه اطلاعاتی زمان اجرا ایجاد می‌شود.
اصطلاح بهینهسازی نام بی مسمایی است چون در بعضی موارد، طرح اجرایی انتخاب شده، استراتژی بهینه نمی‌باشد، آن فقط استراتژی کارآمد معقول برای اجرای پرس و جو است. یافتن استراتژی بهینه، ضامن صرف زمان زیادی است، بجز برای ساده‌ترین پرس و جوها، ممکن است به اطلاعاتی روی چگونگی اجرای فایل‌ها در فهرست‌های فایل‌ها، اطلاعاتی که ممکن است کاملاً در کاتالوگ DBMS در دسترس نباشد، نیاز باشد. از اینرو، برنامه‌ریزی استراتژی اجرا ممکن است توصیف درست‌تری نسبت به بهینهسازی پرس و جو باشد.
برای زبانهای پایگاه اطلاعاتی (دریایی) جهت‌یابی در سطح پایینتر در سیستمهای قانونی، مثل شبکه DML شبکه‌ای یا MOML سلسله مراتبی، برنامه نویس باید، استراتی اجرای پذیرش و جو را انتخاب کند ضمن اینکه برنامه پایگاه اطلاعاتی را می‌نویسد. اگر DBMS فقط زیان جهت‌یابی را ارائه دهد. فرصت و نیاز محدودی برای بهینهسازی پرس وجوی وسیع توسط DBMS وجود دارد، در عوض به برنامه نویس قابلیت انتخاب استراتژی اجرایی بهینه ارائه می‌شود. بعبارت دیگر، زبان پرس و جو در سطح بالا، مثل SQL برای DBMSهای رابطه‌ای یا OQL برای DBMSهای مقصد، در ماهیت تفریطی‌تر است. چون آنچه نتایج مورد نظر پرس و جو است بغیر از شناسایی جزئیات چگونگی بدست آمدن نتیجه، را تعیین می‌کند. بهینهسازی پرس و جو برای پرس و جوهایی ضروی است که در زبان پرس و جوی سطح بالا تعیین می شوند. ما روی توصیف بهینهسازی پرس و جو در زمینه ROBMS تمرکز می‌کنیم چون بسیاری از تکنیک‌هایی که توصیف می کنیم برای، برای ODBMSها تطبیق یافته‌اند. DBMS رابطه‌ای باید استراتژیهای اجرای پرس و جوی دیگری را ارزیابی کند و استراتژی بهینه یا کارآمد معقولی را انتخاب کند. هر DBMS ، تعدادی الگاریتم دسترسی به پایگاه اطلاعاتی کلی دارد که علامتهای رابطه‌ای مثل SELECT یا JOIN یا ترکیبی از این عملیات ها را اجرا می‌کند. تنها استراتژیهای اجرایی که می‌توانند توسط الگاریتم‌های دسترسی DBMS اجرا شوند و برای طراحی پایگاه اطلاعاتی فیزیکی ویژه و پرس و جوی خاص بکار روند، می‌توانند توسط قطعه برنامه بهینهسازی پرس و جو در نظر گرفته شوند.
ما در بخش 1801 با بحث کلی چگونگی ترجمه پرس و جوهای SQL به پرس و جوهای جبری رابطه‌ای و در بهینه‌شدن آنها کار را شروع می‌کنیم. بعد ما روی الگاریتم‌ها برای اجرای عملیاتهای رابطه‌ای در بخش 1802 بحث می‌کنیم. بدنبال این مطلب، بررسی از استراتژیهای بهینهسازی پرس و جو را ارائه می‌دهیم. دو تکنیک اصلی برای اجرای بهینهسازی پرس و جو وجود دارد. اولین تکنیک بر اساس قوانین ذهنی جهت ترتیب دادن عملیات‌ها در استراتژی اجرای پرس و جو می‌باشد. ذهن قانونی است که بخوبی در اکثر موارد عمل می‌کند ولی برای کار مناسب در هر مورد کنش تضمین نمی‌شود. قوانین عملیات‌ها را در درخت پرس وجو مجدداً ترتیب می‌دهند. دومین تکنیک شامل برآورد هزینه استراتژیهای اجرای متفاوت و انتخاب طرح اجرایی با پایین‌ترین هزینه برآورد است. دو تکنیک معمولاً در بهینه ساز پرس و جو (باهم ترکیب می‌شوند) بهم ملحق می‌گردند. ما روی بهینهسازی ذهنی در بخش 1803 و برآورد هزینه در بخش 1804 بحث می‌کنیم. بعد بررسی مختصری از عوامل در نظر گرفته شده در طول بهینهسازی پرس و جو در RDBMS بازرگانی ORACLL= در بخش 1805 را ارائه می‌دهیم. بخش 1806، نوعی بهینهسازی پرس و جوی معنایی را ارائه می‌دهد که در آن محدودیت‌های شناخته شده برای پرداختن به استراتژیهای اجرایی پرس و جوی کارآمد استفاده می‌شوند.
1801 – ترجمه پرس و جوهای SQL به پرس و جوهای رابطه‌ای:
در عمل، SQL زبان پرس وجویی است که در اکثر RDBMS های بازرگانی استفاده می‌شود. پرس وجوی SQL ، ابتدا به عبارت جبری رابطه‌ای توسعه یافته معادل، نمایانگر ساختار داروهای درخت پرس و جو، ترجمه می‌شود و بعد بهینهسازی می‌شود. پرس و جوهای SQL به بلوکهای پرس و جو تجزیه می‌شوند، که واحدهای اساسی را تشکیل می‌دهند که می‌توانند به عملکردهای جبری ترجمه شوند و بهینهسازی شوند. بلوک پرس و جو شامل عبارت SELECT- FROM-WHERE تکی و بندهای Groop By و HAVING است چنانچه این‌ها بخشی از بلوک باشند. از اینرو، پرس و جوهای تو در تو در پرس و جو بعنوان بلوکهای پرس و جوی مجزا شناسایی می‌شوند. چون SQL شامل عملکردهای گروهی، مثل MAX ، COUNT,SUM می‌باشد، این عملگرها باید در پرس و جوی جبری توسعه یافته‌ای شامل شوند، همانطوریکه در بخش 705 توصیف شد. پرس و جوی SQL در رابطه EMPLOEE در تصویر 705 را در نظر بگیرید:
این پرس و جو شامل، پرس و جوی فرعی تو در تو است و از اینرو به دو بلوک تجزیه می‌شود. بلوک درونی بدین صورت است:
و بلوک بیرونی بدین صورت می باشد:
که C نمایانگر نتیجه حاصله از بلوک درونی است. بلوک درونی به عبارت جبری رابطه‌ای توسعه یافته زیر ترجمه شده است:
و بلوک بیرونی به عبارت زیر ترجمه شده است:
بهینه‌ساز پرس و جو، طرح اجرایی را برای هر بلوک انتخاب می‌کند. ما باید اشاره کنیم به در مثال فوق، بلوک درونی نیاز به ارزیابی شدن دارد تنها زمانی که، حداکثرحقوقی که بعکار می‌رود که بعنوان ثابت C، توسط بلوک بیرونی استفاده می‌شود. ما اینرو پرس و جوی تودرتوی غیرمرتبط نامیدیم (در فصل 8). آن برای بهینهسازی پرس و جوهای تو در توی مرتبط پیچیده‌تر، خیلی سخت‌تر است، جایی که متغیر Tuple از بلوک بیرونی در بند WHERE در بلوک درونی ظاهر می‌شود.
1802- الگاریتم های انسانی برای اجرای عملیاتهای پرس و جو:
...
103 ص فایل Word
