در اکثر پروژه¬های کامپیوتری انجام شده در دهه¬های اخیر از تکنولوژی¬های تمام شئ¬گرایی مانند Java و C# استفاده شده در حالی که برای ذخیره سازی داده¬ها از پایگاه¬داده¬های رابطه¬ای که در آنها اثری از شئ¬گرایی موجود نیست استفاده شده. این بدین معنا نیست که انتخاب¬های دیگری موجود نیست بلکه بسیاری زبان¬های برنامه¬نویسی Procedural شبیه COBOL موجود است همچنین بسیاری از پایگاه¬داده¬های موجود از تکنولوژی شئ¬گرا بهره می¬برند از جمله می¬توان از پایگاه¬داده¬های XML نام برد.
بین تکنولوژی¬های شئ¬گرایی و رابطه¬ای که اکثر تیم¬های نرم-افزاری در سیستم¬های خود به¬کار می¬برند یک ناهم¬خوانی ذاتی موجود است. برای رفع این ناهمخوانی یک راه ساده وجود دارد که از دو بخش تشکیل شده: ابتدا باید پروسه¬ی نگاشت اشیاء به رابطه¬های پایگاه¬داده را آموخت و سپس روشی برای پیاده¬سازی آن فرا گرفت.
1 نقش DBA
شکل 1 نشان دهنده نقش یک DBA است زمانی که نگاشت بین مدل رابطه¬ای و شئ¬گرا را انجام می¬دهد. سه عمل اولیه برای این¬کار عبارتند از:
1- نگاشت : هدف اصلی یافتن یک استراتژی مناسب و کارا برای نگاهداری داده¬های اشیاء است. این کار شامل ذخیره کردن صفات و رابطه¬های بین اشیاء از جمله رابطه¬ی ارث بری میان اشیاء است.
2- پیاده¬سازی نگاشت
3- یکسان ساختن کارایی
نکته¬ی قابل توجه در شکل1 این است که هم DBA ها و هم تولیدکنندگان نرم¬افزارها در هر سه فعالیت بالا با هم کار می¬کنند. ]1[
2 ایده اصلی
اولین چیزی که در نگاشت اشیاء به پایگاه¬داده¬های رابطه¬ای به نظر می¬رسد نگاشت بین صفات اشیاء و ستون¬های جداول است. هر صفت از یک شئ به صفر یا چند ستون در پایگاه¬داده رابطه¬ای تبدیل می¬شود. به خاطر داشته باشید که کلیه صفات یک شئ پایدار (Persistent) نیستند. به عنوان مثال صفت میانگین نمرات در یک شئ Student ممکن است فقط در برنامه استفاده شود در حالی که نیازی به ذخیره¬سازی مقدار آن در پایگاه¬داده نیست چراکه از روی مقادیر باقی صفات قابل محاسبه می¬باشد. و یا بعضی صفات در اشیاء خود یک شئ مستقل می¬تواند باشد به همین دلیل ممکن است در پایگاه¬داده رابطه¬ای مجموعه¬ای از چند ستون به عنوان جایگزینی برای یک صفت در یک شئ در نظر گرفته شود. ساده¬ترین حالت در نگاشت یک شئ زمانی است که هر صفت از یک شئ به یک ستون از یک جدول در پایگاه¬داده نگاشت شود مخصوصاً زمانی که نوع داده¬ای در مدل شئ¬گرا با نوع داده¬ای در مدل رابطه¬ای یکسان باشند. ]4[
برای سادگی می¬توان فرض کرد که کلاس¬ها به صورت یک به یک به جداول در پایگاه¬داده¬ها نگاشت می¬شوند. اما به غیر از موارد بسیار ساده و ابتدایی همانطور که در ادامه خواهیم دید این فرض اشتباه بوده و نیاز به عملیات بیشتری برای نگاشت میان کلاس¬ها و جداول در این دو مدل است. اما در این نوشته معمولاً ابتدا هر کلاس را به یک جدول نگاشت کرده و سپس سایر بهینه¬سازی¬ها را انجام می¬دهد.
شکل ۲ نشان دهنده یک نمودار کلاس ساده به همراه مدل ذخیره سازی فیزیکی معادل آن در پایگاه¬داده رابطه¬ای می¬باشد. شما در این شکل میتوانید ارتباط بین عناصر یک کلاس با ستونهای پایگاه‌داده را مشاهده کنید.
شکل 2
با وجودی که شما¬ها در شکل نشان داده شده بسیار شبیه هستند این تفاوتها بدان معنا است که انطباق کامل نخواهد بود. تفاوتها بین شماها شامل :
• چندین خصیصه برای tax در نمودار کلاس وجود دارد در صورتی که تنها یک معادل در شمای داده برای آن موجود است. این بدان معنا است که سه خصیصه tax در کلاس tax در یک ستون از جدول Order اضافه و نگهداری شوند در زمان ذخیره سازی و وقتی شیئ خوانده میشود در حافظه 3 خصیصه باید محاسبه شوند .
• شمای داده شامل کلید است در حالی که شمای شیئ این خصیصه را ندارد باید برای شناسایی و ارتباط بین کلید در کلاس سیاست و روندی اتخاذ گردد. به این اطلاعات اضافی "اطلاعات سایه" میگوییم.
• نوع های مختلفی در هر شما موجود است باید بدون از بین رفتن اطلاعات بتوان آنها را به هم تبدیل کرد. ]2[
اطلاعات سایه
اطلاعات سایه شامل هر داده ای است که اشیائ برای ساختن نیاز دارند. از قبیل کلید، کنترل همروند و ... .
شکل۳ مدل ریزتری از کلاسهای Order و Order Item را مشخص میکند.
• شامل خصوصیات سایه‌ای که کلاس برای نمایش مطبوع خودش نیاز دارد می¬باشد. در جلو اسم این خصوصیات به جای خط فاصله فاصله قرار‌گرفته و جلو آنها وا‍‍ژه کلیشه¬ای <<persistence>> قرار گرفته¬است.
• چهارچوب اطلاعات مورد نیاز برای ایفا روابط بین خصوصیات دو کلاس .چهارچوب خصوصیات، از قبیل بردار OrderItem در Order.
• تابع GetTotalTax() به کلاس Order برای محاسبه مقدار tax در جدول Order اضافه شده‌است. ]2[
شکل 3
اطلاعات سایه به طور ضروری نیازمند ایفا شدن بوسیله business object ها می‌باشند. و باید به چگونگی انها توجه شود.
انطباق Meta Data
شکل۴ Meta Data نمایش داده شده انطباق مورد نیاز جهت برقراری کلاسهای شکل۳ است. MetaData اطلاعاتی راجع به داده میباشد. ما نیاز به راههایی برای نمایش انطباق داده‌ها داریم که در شکل۴ به وضوح دیده میشود.
Property Column
Order.orderID Order.OrderID
Order.dateOrdered Order.DateOrdered
Order.dateFulfilled Order.DateFulfilled
Order.getTotalTax() Order.Tax
Order.subtotalBeforeTax Order.SubtotalBeforeTax
Order.shipTo.personID Order.ShipToContactID
Order.billTo.personID Order.BillToContactID
Order.lastUpdate Order.LastUpdate
OrderItem.ordered OrderItem.OrderID
Order.orderItems.position(orderItem) OrderItem.ItemSequence
OrderItem.item.number OrderItem.ItemNo
OrderItem.numberOrdered OrderItem.NumberOrdered
OrderItem.lastUpdate OrderItem.LastUpdate
شکل 4
شکل۴ به قسمت عمده تکنیک مقاومت غیر انطباقی بین تکنولوژی شیئ و تکنولوژی رابطه‌ای است. کلاسها رفتار وداده های و روابط جداول پایگاه داده را مشخص می¬کنند. نتیجه نهایی وقتی بدست میآید که شما یک کلاس رو به روابط پایگاه داده انطباق می‌دهید. شما باید Operation های getter و setter را هم برای هر ستون جدول به کلاس اضافه کنید.
3نگاشت ساختارهای وراثتی
پایگاه¬داده¬های رابطه¬ای به طور ذاتی وراثت را پشتیبانی نمی¬کنند، بنابر این شما مجبورید ساختارهای وراثتی را در شماهای شیئ برای شما داده ترسیم کنید.
مفهوم وراثت در چندین پیجیدگی جالب در زمان ثبت اشیا در پایگاه¬داده¬های رابطه¬ای گذاشته¬شده.ما چندین راه حل مقدماتی برای نگاشت وراثت به پایگاه¬داده رابطه¬ای ارائه¬کرده¬ایم. که این تکنیکها شامل:
• نگاشت کلاس وراثت به یک جدول تنها
• نگاشت هر کلاس واقعی با جدول خودش.
• نگاشت هر کلاس با جدول خودش.
• نگاشت کلاسها به ساختار کلی جداول. ]2[
برای توصیف هر تکنیک ما چگونگی نگاشت دو نسخه از وراثت نمایش داده شده در شکل۵ را توضیح می دهیم نسخه اول شامل ۳ کلاس است – person، کلاس انتزاعی، و دو کلاس employee , costomer – نسخه دوم وراثت کلاس دیگری را اضافه‌می‌کند بنام executive .
شکل 5
نگاشت کلاس وراثت به یک جدول تنها
تمام خصیصه¬های کلاسها را در یک جدول نگهداری می¬کنیم. شکل۶ مدل داده¬ای مورد نظر برای شکل۵ را نمایش می¬دهد. که نام این جدول person است، یک استراتژی خوب برای نام گذاری جدول استفاده از نام ریشه کلاس وراثت است که یک قانون سر¬راست است.
شکل 6
دو ستون به جدول اضافه شده¬اند ¬_PersonType , PersonPOID ستون دوم جهت مشخص¬کردن کلید است و اولی برای مشخص کردن آن است که Peson مشتری یا کارمند یا هر دو آنها میباشد. PersonPOID یک مشخص کننده پایا اشیا است. که معمولا به آن مشخص کننده شیئ میگوییم.
زمانی که executive را هم اضافه کنید آنگاه جداول به صورت شکل۷ در می¬آید. ][4
شکل 7
نگاشت هر کلاس واقعی به جدول مخصوص خود
در این زمینه هر جدول برای هر کلاس وااقعی شاخته شده است، هر جدول شامل خصوصیات ایفاشده بوسیله کلاس و خصوصیات ارث برده شده توسط آن است. شکل8 مشخص کننده مدل فیزیکی داده برای سلسله مراتب شکل5 است زمانی که این زمینه برخورد شده است.
شکل 8
نگاشت هر کلاس به جدول مخصوص آن کلاس
این استراتژی را که هر کلاس جدول مخصوص به خود را دارد در نظر میگیریم. با یک ستون برای خصوصیات تجاری و هر اطلاعات شناسایی.شکل9 مدل فیزیکی داده کلاسهای شکل5 را زمانی که هر کلاس به یک جدول نگاشته شده است را نمایش داده است. داده ها برای کلاس customer در دوکلاس نگهداری شده¬اند، Customer وPerson ، بنابر این برای دریافت این داده شما نیاز دارید دو جدول را متصل کنید.
عملیات بر روی کلیدها جالب به نظر میرسند. نکته جالب آن است که personPOID بعنوان کلید برای تمامی جداول در نظر گرفته می¬شود.برای جداول Customer,Employee,Executive ، personOID هم کلید اصلی و هم کلید خارجی است. ]3[
شکل9
نگاشت کلاس به یک ساختار نوعی جدولی
چهارمین انتخاب برای ساختار وراثتی به پایگاه داده رابطه¬ای گرفتن یک نوع ، بعضی اوقات به آن meta-data میگوییم، برای نگاشت کلاسها است. در شکل10 شما یک شما داده برای مرتب کردن مقدار صفتها و برای انتقال ساختار وراثتی است.
فرمت این مقاله به صورت Word و با قابلیت ویرایش میباشد
تعداد صفحات این مقاله 14 صفحه
پس از پرداخت ، میتوانید مقاله را به صورت انلاین دانلود کنید
دانلود مقاله نگاشت تراکنشهای پایگاه داده شی گرا به تراکنشهای رابطه ای
