جداول اولیه و ارائه شده ، جداول مبنا (base table) نامیده می شوند .
جدولی که توسط بعضی از عبارات رابطه ای از این جداول مبنا بدست می آید ، جدول مشتق شده (driven) نامیده می شود .
بنابراین طبق تعریف ، جداول مبنا دارای وجود و موجودیت مستقل بوده (independent existence) درحالی که جداول مشتق دارای این تعریف نیستند ( جداول مشتق متکی به جداول مبنا هستند ) .
بنابراین مشاهده می شود که یک جدول مشتق دقیقا جدولی است که برحسب جداول دیگری تعریف می شود و واضح است که یک جدول مبنا دقیقا یک جدول مشتق نمی باشد .
اکنون ، سیستم های رابطه ای به طور مشخص باید درمرحله اول امکانی را برای ایجاد جداول مبنا فراهم سازند، برای مثال در SQL این مورد توسط عبارت CREATE TABLE انجام می شود ( توجه کنید دراینجا منظور از TABLE دقیقا جدول مبنا می باشد ) و به طور مشخص جداول مبنا باید نامگذاری شوند ( درواقع نام آنها درعبارت و دستوری که آنها را ایجاد می کند ، قید خواهد شد .
برعکس ، اکثر جداول مشتق دارای نام نیستند ، بهرحال سیستم های رابطه ای معمولا نوع خاصی از جدول مشتق به نام دیدگاه (view) که دارای نام و اسم بوده را پشتیبانی می کنند .
بنابراین یک دیدگاه (view) ، جدول دارای نامی است که برخلاف یک جدول مبنا ، بخودی خود دارای موجودیت مستقلی نمی باشد ، بلکه در عوض برحسب یک یا چند جدول دارای نام مربوطه ( جداول مبنا یا سایر دیدگاه ها ) تعریف شده است .
چنانچه عبارت تعریف دیدگاه بطور واقعی ارزیابی شود ، جدول مربوطه منتج خواهد شد ولی در واقع ، منظورابدا به این صورت نیست که آن جداول به یک نسخه مجزا(separate copy) اشاره می کند .یعنی هدف ما این نیست که پیشنهاد کنیم که واقعا عبارت تعریف دیدگاه ارزیابی می شود .
درحقیقت ، دیدگاه بطور موثری تنها یک پنجره (window) بر روی جدول EMP مربوط می باشد .
البته ، مسلما هر تغییری بر روی جدول مربوطه به طور خودکار خیلی فوری از طریق پنجره قابل رویت خواهد بود ( البته این تغییرات درقسمت بدون سایه جدول EMP قرار میگیرد) .
به طور مشابهی ، تغییرات بر روی TOPEMPS البته به طور خودکار و بلافاصله بر جدول واقعی EMP اعمال می گردد .و لذا قابل رویت از طریق پنجره خواهد بود .
یک نکته نهایی وجود دارد که نیاز است درخصوص موضوع جداول مبنا و دیدگاه مطرح گردد .
تفاوت جدول مبنا و دیدگاه غالبا به صورت زیر تعریف می گردد .
جداول مبنا واقعا وجود دارند بدین مفهوم که آنها داده هایی را نشان می دهند که به طور واقعی در بانک اطلاعاتی ذخیره می شوند .
برعکس دیدگاه ها واقعا وجود ندارند اما آنها صرفا روشهای مختلف نگاه نمودن به داده های واقعی را فراهم می کنند .
هرچند این توصیف در یک حالت غیر رسمی یک بحث مفید است ولی دقیقا وضعیت درست مطالب را منعکس نمی کند .
این مسئله درست است که کاربران می توانند جداول مبنا را همانگونه که آنها به طور فیزیکی وجود دارند ، درنظر بگیرند .
درواقع نکته اصلی و مهم شیوه رابطه ای این است که به کاربران این اجازه را می دهد تا آنها جداول مبنا را به عنوان یک موجودیت فیزیکی درنظر بگیرند.
درحالی که مجبور نیستند به این مسئله توجه و دقت کنند که چگونه این جداول به طور فیزیکی درحافظه ذخیره می شوند .
ولی این مطلب یک اشکال بزرگ دارد بدین مفهوم که این روش تفکر نباید به عنوان مفهومی که یک جدول مبنا یک جدول ذخیره شده فیزیکی است ، درنظر گرفته شود ( یعنی ، مجموعه ای از رکوردهای همجوار فیزیکی و فیزیکی ذخیره شده که هرکدام شامل یک کپی مستقیم از یک جدول مبنا هستند ) جداول مبنا بهترین ایده و اندیشه به عنوان مجردسازی (abstraction) مجموعه ای از داده های ذخیره شده می باشند ( مجردسازی که در آن تمام جزئیات سطح – حافظه پنهان می باشد ) درعمل ، درجه دلخواهی از اختلاف بین یک جدول مبنا و جدول ذخیره شده وجود دارد .
1.
معماری سه سطحی
از آنجا که درچگونگی معماری پایگاه داده ها حداقل درسالهای آغازین ایجاد این تکنولوژی ، بین کارشناسان ( از محافل مختلف علمی و تکنیکی ) اتفاق نظر نبود ، لذا ANSI/SPARC با توجه به اهمیت محیط انتزاعی ، معماری پایگاه داده ها را ( به عنوان یک معماری استانده (استاندارد)) ، پیشنهاد کرد ، این معماری به معماری سه سطحی موسوم است .
نکته 1: باید توجه داشت که این سه سطح اساسا سه سطح تعریف داده ها هستند : دوسطح درمحیط انتزاعی و سطح سوم در محیط فایلینگ منطقی .
داده های ذخیره شده ( درمحیط فیزیکی ) طبعا درفایلهای فیزیکی جای دارند و هم از اینروست که پیشتر گفتیم : ساده ترین و کلی ترین تعریف پایگاه داده ها این است که گفته شود : مجموعه ای است از فایلهای ....
.
حال نمای کاملتر معماری پیشنهادی ANSI رانشان داده ، به شرح هریک از سطوح معماری می پردازیم .
دراین معماری علاوه بر سه سطح ، اجزای دیگر هم دیده می شود که درواقع جزسیستم پایگاه داده ها هستند .
دراینجا سه سطح و نیز اجزا دیگر را نام می بریم :
1.
کاربر 2.
زبان میزبان 3.
زبان داده ای فرعی 4.
دید خارجی 5.
دید ادراکی 6.
دید داخلی 7.
فایل های فیزیکی 8..سیستم مدیریت پایگاه داده ها 9.
مدیر پایگاه داده ها 2.
شرح سطوح سه گانه ازمهمترین سطح این معماری ( حداقل از نظر طراح و پیاده ساز ) شروع می کنیم : 2-1 دید ( نمای ) ادراکی ( مفهومی ) دید طراح پایگاه داده هاست نسبت به داده های ذخیره شدنی درپایگاه این دید جامع ( سرتاسری) است دربرگیرنده تمام نیازهای کاربران در محیط عملیاتی( درخرد جهان واقع ) این دید در یک محیط انتزاعی مطرح است : بنابراین مبتنی است بر یک ساختار داده ای مشخص ( از یک مدل داده ای که انتزاع لازم را تامین می کند ) .
این دید ، با استفاده از عناصر ساختاری اساسی همان ساختار داده ای ، طراحی می شود .
این دید باید ( پس از طراحی طبعا ) توصیف شود .
به وصف یا شرح دید ادراکی ، شمای ادراکی می گوییم ، شمای ادراکی نوعی "برنامه" است حاوی" دستورات داده ها" و "کنترل داده ها" ( و نه دستورات عملیات در داده ها ) سطح ادراکی درواقع همین شمای ادراکی است .
شمای ادراکی به سیستم داده می شود و در کاتالوگ سیستم نگهداری می شود .
تاکید : پس پایگاه داده ها از نظر طراح آن در سطح انتزاعی ، همان دیدادراکی است.
2-2 دید ( نمای ) خارجی دیدکاربر خاص است نسبت به داده های ذخیره شده در پایگاه داده ها این دید جزیی است و نه جامع : نشان دهنده محدوده ای از "پایگاه داده ها" که به نیازهای اطلاعاتی یک کاربر خاص پاسخ می دهد .
این دید هم درسطح انتزاعی مطرح است ، بنابراین مبتنی است که بریک ساختار داده ای مشخص و معمولا همان ساختار داده ای که دید ادراکی براساس آن طراحی و تعریف می شود .
این دید روی دید ادراکی طراحی و تعریف می شود ( به همین دلیل به جدولهای سطح ادراکی ، جدولهای مبنا یا پایه می گویند ) .
به وصف یا تعریف دید خارجی ، شمای خارجی می گوییم .
نوعی برنامه که کاربر سطح خارجی می نویسد حاوی دستورات" تعریف داده ها "و گاه "کنترل داده ها "درهمان سطح خارجی ، شمای خارجی هم به سیستم داده می شود ودرکاتالوگ آن نگهداری می شود .
نکته 1 : حداقل از لحاظ نظری می توان گفت که ساختار (مدل) داده ای دردو سطح انتزاعی یعنی سطح خارجی و سطح ادراکی میتواند یکسان نباشد .
دراین صورت ، طبعا یک واحد نرم افزاری خاص برای تبدیل یک ساختار به ساختار دیگر لازم است .
اصطلاحا می گوییم که سیستم "دوساختاره" است .
به تعریف مجموعه دیدهای خارجی کاربر ، سطح خارجی گفته می شود .
یک کاربر میتواند تعدادی دید داشته باشد .
چندکاربر میتوانند دریک دید مشترک باشند .
نکته 2 : دیدهای V1 از U1 و V1 از U2 روی جدولSTT ، دید V2 از U1 روی جدول COT ، دید V2 از U2 روی جدولهای STT ، STCOT و COT تعریف می شوند .
ضمنا دید V1 از U3 نیز روی جدولهای STT و STCOT تعریف می شود و می بینیم دارای یک ستون (صفت ) مجازی است (AVG : معدل دانشجو درهرترم ).
نکته 3 : کاربر در نامیدن ستونهای دید خود آزاد است ( بارعایت ضوابط خاص هر سیستم ) کاربر U1 در دید V2 ستون شماره درس را با CONUM ، کاربر U2 شماره دانشجو را در دید V1 ، STNUM و ...
انتخاب کرده است .
نکته 4 : می بینیم که دید ادراکی ، جدولی است و دیدخارجی کاربر نیز جدولی است ، اما دید خارجی یک جدول مجازی است ، به این معنا که داده ذخیره شده خاص خود را ندارد .
پس در هردید جدولی، ستونها و سطرهایی از یک ( یا بیش از یک ) جدول وجود دارند .
بنابراین در تعریف این نوع جدول ، به نحوی باید همان عملگرهای RESTRICT ، PROJECT ،JOIN و ...
را متناسبا بکار برد که خواهیم دید .
توجه داشته باشیم که مفهوم دید اساسا نوعی پنجره است که از آن ، کاربر می تواند محدوده پایگاه خود را ببیند و خارج از این محدوده ، هیچ نمی بیند .
نکته 5: آنچه بعد از فراکرد WHERE می آید شرط (شرایط) تعریف دید نام دارد .
تمرین 1: یک تعریف ممکن برای هر یک از دیدهای کاربران U2 و U3 ارائه کنید .
نکته 6 : دستور SELECT درتعریف دید ، یک دستور اجرایی نیست ( بازیابی انجام نمی دهد ) بلکه تنها مکانیسم تعریف دید روی جدول ( های) مبنا را نشان میدهد ( چه ستونهایی و چه سطرهایی ) .
کنجکاوی 1 : اگرکاربربخواهد داده های دید خود را ببیند ، چه باید بکند ؟
تاکید : دید خارجی هرکاربر، نشان دهنده "پایگاه داده های" همان کاربر است .
پس منطقا کاربر، پس از تعریف" پایگاه خود"، باید بتواند درآن عملیات انجام دهد :بازیابی، درج ، حذف و بهنگام سازی.
اما خواهیم دید که عملیات ذخیره سازی دردیدها همیشه امکان پذیر نیست .
تمرین 2 : درمورد دستورهای لا زم برای انجام عملیات ذخیره سازی درسطح خارجی و چگونگی انجام آنها از هم اینک اندیشه کرده ، مثالهایی با TDS قید کنید ، ( توجه داریم که دید در TDS بهرحال نوعی جدول است ) .
موضوع درجای خود بررسی خواهد شد .
کنجکاوی 2 : مفهوم دید خارجی چه مزایا و چه معایبی دارد ، درچه شرایطی میتوان از این مفهوم صرفنظر کرد ( طبعا درسطح طراحی پایگاه داده ها و درنتیجه درتولید برنامه های کاربردی) ؟
2-3 دید( نمای ) داخلی دید DBMS ( و نیز طراح پایگاه داده ها ) است درسطحی پائین تر از سطح ادراکی ، نسبت به کل داده های ذخیره شدنی درپایگاه داده ها .
این دید در سطح فایلینگ منطقی ( وگاه مجازی ) پایگاه داده ها مطرح است .
این دید مبتنی است بر یک ( و گاه بیش از یک ) ساختار فایل که معمولا بانظر و دخالت طراح پایگاه داده ها طراحی می شود ، این طراحی اصطلاحا به طراحی فیزیکی موسوم است .
سطح داخلی پایگاه داده ها ، درواقع سطحی است که درآن فایلهای منطقی پایگاه داده ها تعریف میشود.
به شرح یا تعریف دید داخلی ، شمای داخلی گفته می شود : نوعی" برنامه" که توسط خود یا وصف فایلینگ منطقی پایگاه است که درواقع همان سطح داخلی است .
نکته 7: میزان دخالت طراح و پیاده ساز پایگاه داده درتعیین جنبه های سطح داخلی پایگاه داده ها در سیستم های امروزی، نسبت به سیستم های قدیم تر ، کمتر است .
نکته 8 : همانطور که گاه ممکن است یک برنامه ساز ، درسطح پایین، برنامه سازی کند ( به زبان اسمبلی) دراستفاده و یاکنترل پایگاه داده ها هم ممکن است گاهی بعضی از برنامه ها مستقیما درسطح داخلی( به جای سطح خارجی یا ادراکی ) عمل کنند ، هرچند این کار، این برنامه ها را به محیط فایلینگ پایگاه داده ها تا حدی وابسته می کند (DATE2000) .
توجه داریم که درشمای داخلی ، انواع رکوردها تعریف می شوند و دستورهای لازم جهت ایجاد فایلها و کنترل آنها نیز دراین شما وجود دارد .
توجه : به تفاوت بین نام بعضی ستونهای جدول و فیلدهای رکوردهای متناظر درسطح داخلی دقت شود .از نظر تئوریک ، جنبه های مختلف داده ها می توانند در هر سه سطح معماری متفاوت باشند .
نکته 9: درتعریف رکوردهای سطح داخلی دراین مثال فرض کرده ایم که تناظر بین جدولهای مبنا درسطح ادراکی و فایلهای سطح داخلی یک به یک است .
دربرخی از سیستم های رابطه ای لزوما چنین نیست .
یعنی ممکن است سیستم برای یک رابطه بیش از یک فایل ایجاد کند و یا بیش از یک رابطه را در یک فایل ذخیره کند .
نکته 10: درمقایسه بامحیط ناپایگاهی ( در مشی فایلینگ ) می توان گفت که نقش DBMS درتعریف سطح داخلی کم و بیش همان است که نقش برنامه ساز فایل پرداز در محیط برنامه سازی فایل پردازی ، البته تا آنجا که به تعریف ، ایجاد و کنترل فایلهایش مربوط می شود .
نکته 11: یک تفاوت بسیار اساسی بین معماری پایگاه داده ها و معماری محیط ناپایگاهی دیده می شود : وجود معمولا دو سطح انتزاعی ( دوسطح تعریف داده ها در محیط انتزاعی ) درمعماری پایگاه داده ها که درمعماری محیط ناپایگاهی وجود ندارد .
DBMS می داند : چه فایلهایی وجود دارد ؟
نگاشت سطح ادراکی به سطح داخلی چگونه است ؟
فضای پایگاه داده های کاربر چه صفحاتی دارد.
فرمت هرنوع رکورد چیست ؟
ساختار هر فایل چیست ؟
استراتژی دستیابی به رکوردهای هرفایل چگونه است ؟
صفت نظم کدام است ؟
توالی منطقی رکوردها در صفحات چگونه است ؟
اندازه جاری هرفایل چیست ؟
پیوندهای منطقی بین فایلها چگونه است ؟
اما: DBMS نمی داند : فایلها چگونه درمحیط فیزیکی ذخیره شده اند ؟
لوکالیتی یا خوشه واری رکوردها چگونه است ؟
خوشه واری درون فایلی و بین فایلها ( به ] روحا-79 الف[ مراجعه شود ) استراتژی دستیابی ( مثلا شاخص ها ) چگونه پیاده سازی شده اند ؟
اندازه بلاک چیست ؟
نگاشت صفحات دربلاکها چگونه است ؟
توالی منطقی رکوردها چگونه پیاده سازی شده است ؟
نکته 12: دربعضی از سیستم های جدید DBMS کل فضای پایگاه داده ها را به صورت مجموعه ای از مجموعه صفحات می بیند ، یعنی نوع نمای مجازی از داده های ذخیره شده در پایگاه دارد ، این نمای مجازی بالاتر از سطح فایلینگ منطقی جای دارد .
درواقع بین سطح نمای مجازی و سطح فایلینگ فیزیکی ، یک سطح فایلینگ منطقی واسط است [DATE95] .
توجه : مابیش از این به سطح داخلی و نیز فیزیکی پایگاه داده ها نمی پردازیم ، برای اطلاع از انواع ساختار فایلها و نیز عملیات سیستم فایل به منابع مربوطه مراجعه شود ، تقریبا درتمام منابع کلاسیک پایگاه داده ها فصل یا فصلهایی درمورد ساختارهای فایل وجود دارد ( شاید فقط غیر از DATE2000 ) .
اما در این منابع به "مهندسی فایلها" بویژه ارزیابی کارایی ساختارها پرداخته نمی شود .
غالبا شرح و توصیف ساختارها و استراتژیهای دستیابی به رکوردها درساختارها را میتوان دراین منابع یافت .
نکته 13 : آگاهی از جنبه های سطح داخلی – فیزیکی پایگاه داده هایی که DBMS ایجاد مدیریت می کند ، بسیار حائز اهمیت است ، زیرا کارایی سیستم بیشتر به وضع فایلینگ پایگاه داده ها بستگی دارد .
اما کاربران سطح خارجی معمولا نیازی ندارند که از جنبه های سطح داخلی – فیزیکی پایگاه داده ها اطلاعاتی داشته باشند .درعوض کاربر سطح ادراکی ( طراح ، پیاده ساز و اعضا تیم مدیریت پایگاه داده ها ) باید از این جنبه ها اطلاعات کافی داشته باشند ، تابتوانند کارایی سیستم مدیریت پایگاه داده ها و نیز کارایی" سیستم کاربردی" را کنترل و درصورت لزوم بهتر کنند .
البته درسیستم های جدید مدیریت پایگاه داده ها ، تاآنجا که به طراحی منطقی ( ادراکی) پایگاه داده ها ، تعریف شمای ادراکی پایگاه داده ها و انجام عملیات در پایگاه ، به ویژه دراسلوب تعاملی ( اندرکنشی) مربوط می شود .
پیاده ساز پایگاه داده ها چندان به جنبه های سطح داخلی – فیزیکی نمی پردازد ، این جنبه ها در مرحله طراحی فیزیکی پایگاه داده ها و ایجاد آن مطرح می شوند .
مرحله ای که درآن درمورد ساختار فایلها ، استراتژی دستیابی به رکوردها و جایدهی فایلها روی رسانه و برخی جنبه های دیگر تصمیم گیری می شود .همانطور که گفته شد ، میزان دخالت طراح و پیاده ساز در ایجاد و مدیریت سطح داخلی پایگاه داده ها در سیستم های جدید کمتر از سیستم های قدیمی تر است .
اما باید توجه داشت که در هر DBMS واقعی باید امکانات و ابزارهایی برای کنترل کارایی سیستم مدیریت پایگاه داده ها و تنظیم آن و نیز بهینه سازی کارایی سیستم کاربردی وجود داشته باشد .
هرچه امکانات و ابزارهای لازم برای این فعالیت ها بیشتر باشد ، آن DBMS مطلوب تراست .
گاه لا زم است که ابزارهای خاصی هم برای انجام فعالیت های مدیریتی و کنترل ، توسط تیم طراح پیاده ساز پایگاه داده ها طراحی و تولید شوند .
تاکید دوباره : باتوجه به آنچه که درمورد سه سطح معماری پایگاه داده ها گفته شد ، می بینیم که درواقع ، معماری سه سطحی ، از سه سطح تعریف داده ها – کنترل داده ها تشکیل شده است ، از اینرو این معماری را معماری سه شِمایی نیز می گویند ، روشن است که داده های کاربران فقط درهمان سطح فیزیکی پایگاه ، به صورت مجموعه ای از فایلها ، ذخیره می شوند .( اما هر مجموعه ای از فایلها ، پایگاه داده ها نیست ).
3.
شرح اجزای دیگر درمعنای عام ، هر استفاده کننده از پایگاه داده ها را کاربر میگوییم .
نکته 14: برنامه ساز "سیستم"، برنامه های ایجاد و کنترل پایگاه داده ها را می نویسد ، اما برنامه ساز "کاربردی " معمولا برنامه های بهره برداری از پایگاه داده ها را می نویسد .
توجه : اصطلاح کاربرپایانی درمعنای عام ، به هردوگونه کاربر نابرنامه ساز ( که از طریق یک واسط غیر زبانی از سیستم استفاده میکند ) وکاربر برنامه ساز کاربردی گفته می شود .
اما معمولا برنامه ساز بهره بردار (کاربرد ساز ) است : هرکاربری که کارش نیاز به دستیابی به پایگاه داده ها به منظور بازیابی یا ذخیره سازی دارد و گزارشهایی تولید می کند .
نکته 15 : برنامه ساز کاربردی ممکن است از یک زبان پرسش و یا از یک زبان برنامه سازی ( از هر نسل ) همراه با یک زبان پرسش استفاده کند .
نکته 16 : کاربر موردی ممکن است برنامه ساز و یا نابرنامه ساز باشد ، اما معمولا برنامه ساز است .
تمرین 4: درمورد هریک از گونه های کاربر نابرنامه ساز بیشتر مطالعه شود 3-2 زبان میزبان یکی از زبانهای برنامه سازی ( از هر نسل ) است : کوبول، پی ال وان ، فرترن ، پاسکال ، سی ، و زبانهایی مثل ایدا ، لیسپ ، جاوا و نیز زبان اسمبلی.
دربعضی کاربردها لازم است که از یکی از زبانها استفاده شود .
زیرا به شرحی که خواهیم دید ، با زبانهای پایگاهی موجود نمی توان به معنای متعارف برنامه سازی کرد ، بلکه این زبانها به صورت زبان میهمان همراه با یک زبان میزبان استفاده می شوند .
نکته 17 : هرچه تعداد زبانهای میزبان مورد پذیرش DBMS بیشتر با شد ، آن DBMS از این نظر مطلوبتر است ، زیرا ؛ تنوع کاربردها امکان پذیر می شود .
تنوع کاربران تامین می شود .
هزینه سازمان کا هش می یابد .
زیرا نیازی به آموزش افراد برای کسب مهارت برنامه سازی به زبان خاصی نیست .
سیستم انعطاف پذیرتر می شود .
3-3 زبان داده ای فرعی این زبان از سه دسته دستور تشکیل شده است : دستورات تعریف داده ها دستورات عملیات روی داده ها دستورات کنترل داده ها ازنظر ANSI ، این سه دسته دستور باید برای هر یک از سه سطح معماری پایگاه وجود داشته باشند .
به DDL خارجی ، VDL ( زبان تعریف دید ) و به DDL داخلی، SDL ( زبان تعریف ذخیره سازی ) هم گفته می شود [ELMA2000] .
نکته 18: زبان داده ای فرعی از نظر نیاز به زبان میزبان یا عدم نیاز به آن ، به دو رده تقسیم می شود: مستقل یا خودکفا ادغام شدنی ( ادغام شده ) زبان مستقل ، زبانی است که نیاز به زبان میزبان ندارد و خود به صورت تعاملی ( اندرکنشی )استفاده می شود و آن را L.DSL گوییم .
این گونه زبان ، درواقع یک زبان پرسش ( پرس و جو ) است یعنی با دستورهایش می توان انواع پرسشها را تنظیم کرد ( برای انجام چهار عمل اصلی یعنی بازیابی ، درج ، حذف و بهنگام سازی ) .
زبان ادغام شدنی ، زبانی است که دستورهایش ( به نحوی) درمتن برنامه ای به زبان میزبان بکار می روند ومستقلا قابل استفاده نیستند و آن را E.DSL گوییم .
البته زبان داده ای فرعی ممکن است هم مستقل و هم ادغام شدنی باشد (I/E.DSL) .
توجه داشته باشیم که در حالت E.DSL لزوما زبان میزبان نباید یک زبان برنامه سازی متعارف باشد.
میتوان از زبانهای جدیدتر مثلا جاوا و جاوا – اسکریپت یا وی – بی – اسکریپت ، نیز استفاده کرد .
مثلا می توان با استفاده از ASP که یک امکان تولید برنامه در محیط اینترنت است .
در محیط جاوا ، اسکریپت یا وی – بی – اسکریپت دستورهای SQL را به صورت یک رشته داد و عملیات مورد نظر را در پایگاه داده ای رابطه ای انجام داد ، یا از امکانات دیگر از جمله شیئی های داده ای فعال استفاده کرد .
درحال حاضر گروهی متشکل از بهترین فروشندگان RDBMS درکادر پروژه ای موسوم به SQLJ تلاش دارند تا ادغام SQL درجاوا و برعکس را عملی سازند .
این پروژه درچند قسمت تعریف شده است .
ازجمله درقسمت اول به ادغام SQL درجاوا، درقسمت دوم به ادغام جاوا در SQL پرداخته می شود [DATE2000] .
نکته 19.
چگونگی ادغام ممکن است صریح یا ضمنی باشد .
درحالت ادغام صریح ، عین دستور زبان داده ای فرعی در برنامه به زبان میزبان نوشته می شود ، ولی در حالت ادغام ضمنی ،دستورهای زبان داده ای فرعی به صورت توابع کتابخانه ای ، فراخوانده می شوند .
به این توابع کتابخانه ای گاه" واسط برنامه سازی کاربرد" گفته می شود .
این توابع کارهایی مانند متصل شدن به پایگاه داده ، اجرای دستورات DSL ، بازیابی رکورد(ها) و ...
را انجام دهند .
نکته 20.
درحالت ادغام صریح ، محیط برنامه سازی، دوزبانی است و برای کامپایل کردن آن ، به دو کامپایلرنیاز است ، پیش کامپایلر برای دستورات E.DSL و کامپایلر برای زبان میزبان.درشکل 5-8 روند کلی مرحله کامپایل برنامه دوزبانی دیده می شود : توجه داریم که سیستم پس از جداسازی دو برنامه پیوند بین آنها را به نحوی برپا می دارد تادرمرحله اجرا مشکلی دراجرای برنامه ها بروز نکند .
3-3-1 برخی ویژگیهای زبان داده ای فرعی تعداد دستورهایش باید کم باشد ( به ویژه DML,DDL ).
دستورهایش باید شبه زبان طبیعی باشند .
یادگیری و استفاده از آن باید آسان باشد .
درطراحی آن اصل وحدت دستور باید رعایت شده باشد ، یعنی برای عمل منطقا واحد ، دستور واحد ( و نه چند دستور ) داشته باشد .
دستورهایش باید مبتنی بر عناصر ساختاری اساسی ساختار داده ای طراحی شوند و عمل کنند .
بهتر است نارویه ای ( ناروشمند ) باشد و نه رویه ای .
نکته 21 : زبان رویه ای زبانی است که در برنامه سازان با آن ، برنامه ساز خود ، رویه ( روش) انجام عمل موردنظرش را بنویسد .
مثلا در بازیابی، نه تنها باید بگوید "چه داده ای" می خواهد ، بلکه رویه بازیابی آن را نیز باید مشخص کند ، اما در زبان نارویه ای ، برنامه ساز در"سطح بالاتر" برنامه می نویسد و رویه انجام عمل مورد نظرش را بیان نمی کند .
مثلا درعمل بازیابی تنها به نحوی می گوید "چه داده ای" میخواهد و روش بازیابی داده ها ( ناوش درپایگاه داده ) رامشخص نمی کند .
بنابراین در زبان ناروشمند ، برنامه ساز الگوریتم دستیابی به داده را مشخص نمی کند .
درواقع زبان رویه ای حالت دستوری و زبان نارویه ای حالت توصیفی دارد درسیستمی که زبان آن نارویه ای است ، ناوش درپایگاه داده ها ( ازنظر کاربر) بطور خودکار انجام می شود ، اما در سیستم با زبان رویه ای ، ناوش خودکار نیست ، البته در سیستم با ناوش خودکار مسئله بهینه سازی پرسش مطرح می شود ، درچنین سیستمی ، بهینه ساز پر سش باید قطعه برنامه دستیابی به داده مورد نظر کاربر را چنان تولید کند که ناوش در پایگاه داده های فیزیکی با بیشترین کارایی ( از نظر عملیات ورودی / خروجی لازم ) ا نجام پذیرد .
توجه داشته باشیم که مفهوم رویه ای یا نارویه ای بودن مفهوم مطلقی نیست .
بهتر است گفته شود که زبان L1 از زبان L2 رویه ای تر است یا نیست [DATE2000) .
درواقع زبانهای نارویه ای در سطح انتزاعی بالاتری قرار دارند .
نارویه ای بودن زبان سبب می شود تا ایجاد برنامه های کاربردی به طور قابل ملاحظه ای بهبود یابد و افزایش تعداد کاربران پایانی تسهیل شود [OZSU99] .
کنجکاوی 9 : درچه وضعی سیستم با DSL کامپایلری ، کارایی بهتر دارد ؟
و در چه وضعی سیستم با DSL مفسری؟
بهتر است از نظر ساختاری کامل باشد ( به بیان نظری ، می گوییم کمال ساختاری داشته باشد ) .
یعنی امکان دهد تا همه عناصر ساختاری مدل داده ای و بویژه گونه های عنصر ( عناصر) ساختاری اساسی تعریف، کنترل و پردازش شود ، ( برای توضیح این نکته مهم به بحث مفاهیم اساسی رابطه ای ، گفتاردهم مراجعه شود ) .
به رای برخی پژوهشگران ، زبان پایگاهی باید از نظر برنامه سازی و محاسباتی کامل باشد ( به بیان نظری ، می گوییم کمال برنامه سازی و یا کمال محاسباتی داشته باشد ).
یعنی تمام ساختهای اصلی یک زبان برنامه سازی را داشته باشد .
اما برخی دیگر بر این عقیده اند که زبان پاایگاهی باید در حد یک زبان پرسش باشد و نه یک زبان برنامه سازی .
تمرین : ساختهای اصلی زبان برنامه سازی کدامند ؟
اگر یک زبان داده ای فرعی از نظر برنامه سازی کامل باشد ، دیگر نمی توان آن را به یک" زبان داده ای فرعی" دانست ، بلکه یک زبان برنامه سازی با امکانات پایگاهی است و درنتیجه ، وحدت زبان ، ( داشتن محیط برنامه سازی تک زبانی ) تامین می شود .
گاه در این وضع گفته می شود که زبان داده ای فرعی با زبان میزبان ، پیوند قوی (تنگاتنگ ) دارد و غایت این پیوند همان "یکی شدن" است .
دربیشتر سیستم های موجود ( که عمدتا رابطه ای هستند و زبان آنها SQL است ).
هنوز محیط برنامه سازی ، دوزبانی است ( اگرچه مثلا در سیستم اوراکل PL/SQL هم وجود دارد ) اما سیستم های شیئی گرا (OODBMS) به این هدف بسیار مهم ، یعنی رسیدن به "وحدت زبان و محیط تک زبانی "نایل شده اند .
اگرچه در این سیستم ها ، مفهوم بسیار اساسی ، مدل داده ای هنوز وضع روشنی ندارد ( درمقایسه با RDM که اساسا یک ساخت ریاضی منسجم و محکم دارد ) و بنابراین با توجه به ویژگی شماره 5 دراین بحث هنوز پرسشها و تردیدهایی درباره زبانهای پایگاهی شیئی گرا درمعنای دقیق وجود دارد ، هرچند زبان پرسش گرایی هم طراحی و پیشنهاد شده است .
10.
زبان باید از نظر تعداد دستورهای کنترل داده ها و عملکرد هر دستور ، غنی و قوی باشد .
11.
زبان داده ای فرعی با ید از نظر انواع داده ای و به ویژه انواع داده ای انتزاعی ( مجر) و انواع داده ای پیچیده غنی باشد .
منابع مفاهیم بنیادی پایگاه داده ها تألیف سید محمد تقی روحانی رانکوهی سیستم های بانک اطلاعاتی ترجمه جناب آقای مهندس علیخانزاده