تحقیق مقاله نگاشت تراکنش های پایگاه داده شی گرا به تراکنش های رابطه ای

در اکثر پروژه­ های کامپیوتری انجام شده در دهه­های اخیر از تکنولوژی­های تمام شئ­گرایی مانند Java و C# استفاده شده در حالی که برای ذخیره سازی داده­ها از پایگاه­داده­های رابطه­ای که در آنها اثری از شئ­گرایی موجود نیست استفاده شده. این بدین معنا نیست که انتخاب­های دیگری موجود نیست بلکه بسیاری زبان­های برنامه­نویسی Procedural شبیه COBOL موجود است همچنین بسیاری از پایگاه­داده­های موجود از تکنولوژی شئ­گرا بهره می­برند از جمله می­توان از پایگاه­داده­های XML نام برد.

بین تکنولوژی­های شئ ­گرایی و رابطه­ای که اکثر تیم­های نرم­افزاری در سیستم­های خود به­کار می­برند یک ناهم­خوانی ذاتی موجود است. برای رفع این ناهمخوانی یک راه ساده وجود دارد که از دو بخش تشکیل شده: ابتدا باید پروسه­ی نگاشت اشیاء به رابطه­های پایگاه­داده را آموخت و سپس روشی برای پیاده­سازی آن فرا گرفت.

نقش DBA

شکل 1 نشان دهنده نقش یک DBA است زمانی که نگاشت بین مدل رابطه­ ای و شئ­گرا را انجام می­دهد. سه عمل اولیه برای این­کار عبارتند از:

1- نگاشت [1]: هدف اصلی یافتن یک استراتژی مناسب و کارا برای نگاهداری داده­های اشیاء است. این کار شامل ذخیره کردن صفات و رابطه­های بین اشیاء از جمله رابطه­ی ارث بری میان اشیاء است.

2- پیاده­سازی نگاشت [2]

3- یکسان ساختن کارایی [3]

(تصاویر در فایل اصلی موجود است)

نکته­ی قابل توجه در شکل1 این است که هم DBA ها و هم تولیدکنندگان نرم­افزارها در هر سه فعالیت بالا با هم کار می­کنند.  ]‎1[

ایده اصلی

اولین چیزی که در نگاشت اشیاء به پایگاه­داده­های رابطه­ای به نظر می­رسد نگاشت بین صفات اشیاء و ستون­های جداول است. هر صفت از یک شئ به صفر یا چند ستون در پایگاه­داده رابطه­ای تبدیل می­شود. به خاطر داشته باشید که کلیه صفات یک شئ پایدار (Persistent) نیستند. به عنوان مثال صفت میانگین نمرات در یک شئ Student ممکن است فقط در برنامه استفاده شود در حالی که نیازی به ذخیره­سازی مقدار آن در پایگاه­داده نیست چراکه از روی مقادیر باقی صفات قابل محاسبه می­باشد. و یا بعضی صفات در اشیاء خود یک شئ مستقل می­تواند باشد به همین دلیل ممکن است در پایگاه­داده رابطه­ای مجموعه­ای از چند ستون به عنوان جایگزینی برای یک صفت در یک شئ در نظر گرفته شود. ساده­ترین حالت در نگاشت یک شئ زمانی است که هر صفت از یک شئ به یک ستون از یک جدول در پایگاه­داده نگاشت شود مخصوصاً زمانی که نوع داده­ای در مدل شئ­گرا با نوع داده­ای در مدل رابطه­ای یکسان باشند. ]‎4[

برای سادگی می­توان فرض کرد که کلاس­ها به صورت یک به یک به جداول در پایگاه­داده­ها نگاشت می­شوند. اما به غیر از موارد بسیار ساده و ابتدایی همانطور که در ادامه خواهیم دید این فرض اشتباه بوده و نیاز به عملیات بیشتری برای نگاشت میان کلاس­ها و جداول در این دو مدل است. اما در این نوشته معمولاً ابتدا هر کلاس را به یک جدول نگاشت کرده و سپس سایر بهینه­سازی­ها را انجام می­دهد.

(تصاویر در فایل اصلی موجود است)

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

(تصاویر در فایل اصلی موجود است)

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

چندین خصیصه برای tax  در نمودار کلاس وجود دارد در صورتی که تنها یک معادل در شمای داده برای آن موجود است. این بدان معنا است که سه خصیصه tax در کلاس tax در یک ستون از جدول Order اضافه و نگهداری شوند در زمان ذخیره سازی  و وقتی شیئ خوانده می‌شود در حافظه 3 خصیصه باید محاسبه شوند .

شمای داده شامل کلید است در حالی که شمای شیئ این خصیصه را ندارد باید برای شناسایی و ارتباط بین کلید در کلاس سیاست و روندی اتخاذ گردد. به این اطلاعات اضافی "اطلاعات سایه"[4] میگوییم.

نوع های مختلفی  در هر شما موجود است باید بدون از بین رفتن اطلاعات بتوان آنها را به هم تبدیل کرد. ]‎2[

اطلاعات سایه

اطلاعات سایه شامل هر داده ای است که اشیائ برای ساختن نیاز دارند. از قبیل کلید، کنترل همروند و ... .

شکل۳ مدل ریزتری از کلاسهای  Order و Order Item را مشخص میکند.

شامل خصوصیات سایه‌ای که کلاس برای نمایش مطبوع خودش نیاز دارد  می­باشد. در جلو اسم این خصوصیات به جای خط فاصله فاصله قرار‌گرفته و جلو آنها وا‍‍ژه کلیشه­ای <> قرار گرفته­است.

چهارچوب اطلاعات مورد نیاز برای ایفا روابط بین خصوصیات دو کلاس .چهارچوب خصوصیات، از قبیل بردار OrderItem  در Order.

تابع GetTotalTax() به کلاس Order برای محاسبه مقدار tax در جدول Order اضافه شده‌است. ]‎2[

(تصاویر در فایل اصلی موجود است)

اطلاعات سایه به طور ضروری نیازمند ایفا شدن بوسیله business object ها می‌باشند. و باید به چگونگی انها توجه شود.

(تصاویر در فایل اصلی موجود است)

شکل۴  به قسمت عمده تکنیک مقاومت غیر انطباقی[1] بین تکنولو‍‍‍‍‍‍ژی شیئ و تکنولوژی رابطه‌ای است. کلاسها  رفتار وداده های و روابط جداول پایگاه داده را مشخص می­کنند. نتیجه نهایی وقتی بدست میآید که شما یک کلاس رو به روابط پایگاه داده انطباق می‌دهید. شما باید Operation   های getter و setter را هم برای هر ستون جدول  به کلاس اضافه کنید.

3نگاشت ساختارهای وراثتی

پایگاه­داده­های رابطه­ای به طور ذاتی وراثت را پشتیبانی نمی­کنند، بنابر این شما مجبورید ساختارهای وراثتی را در شماهای شیئ برای شما داده ترسیم کنید.

مفهوم وراثت در چندین پیجیدگی جالب در زمان ثبت اشیا در پایگاه­داده­های رابطه­ای گذاشته­شده.ما  چندین راه حل مقدماتی برای نگاشت وراثت به پایگاه­داده رابطه­ای ارائه­کرده­ایم. که این تکنیکها شامل:

نگاشت کلاس وراثت به یک جدول تنها

نگاشت هر کلاس واقعی با جدول خودش.

نگاشت هر کلاس با جدول خودش.

نگاشت کلاس ها به ساختار کلی جداول. ]‎2[

برای توصیف هر تکنیک ما چگونگی نگاشت دو نسخه از وراثت نمایش داده شده در شکل۵ را توضیح می دهیم نسخه اول شامل ۳ کلاس است – person، کلاس انتزاعی، و دو کلاس employee , costomer – نسخه دوم وراثت کلاس دیگری را اضافه‌می‌کند بنام executive

(تصاویر در فایل اصلی موجود است)