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

بخشی از مقاله

نگاشت تراکنشهای پايگاه داده شی گرا به تراکنشهای رابطه ای

Mapping object-oriented database transactions into relational transactions

در اكثر پروژه¬هاي كامپيوتري انجام شده در دهه¬هاي اخير از تكنولوژي¬هاي تمام شئ¬گرايي مانند 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 شما يک شما داده براي مرتب کردن مقدار صفتها و براي انتقال ساختار وراثتي است.

شکل10

مقدار ObjectPOID نگهداشته شده در يکتا شناخته شده براي يک شيء مشخص است. جدول AttributeType شامل سطرهايي براي نوعهاي داده¬اي اصلي ازقبيل data،string،money،integer و غيره.اين اطلاعات براي پوشش دادن مقدار خصوصيات نگهداري شده در مقدار لازم شده¬اند.
براي نگاشت ساختار بين Person وCustomer ، در شکل5، در اين شما. جدول وراثت يک کليد براي نگاشت وراثت است. هر کلاس بوسيله يک جدول کلاس نشان داده خواهد شد. همچنين يک رديف در جدول Inheritance است. در Inheritance يک رديف وجود خواهد داشت که مقدار Inheritance.SuperClassPOID به يک رديف در کلاس Person و Inheritance.SubClassPOID به کلاس Customer اشاره ميکند. براي نگاشت الباقي سلسله مرتب نيازداريد يک رديف در Inheritance براي هر رابطه وراثتي نياز است. ]‎3[

نگاشت وراثت چندگانه

گاهي اوقات نياز داريم که سلسله مراتب چندگانه را به پايگاه داده رابطه¬اي تبديل کنيم.
شکل11 نشان¬دهنده سه شماي داده است که نتيجه¬اي براي استعمال هر سه استراتژي نگاشت وراثت است. شما ميتوانيد نگاشت وراثت جندگانه را در شکل11 ببينيد. يکي ازمهارتها مشخص کردن نام مناسب در زمان نگاشت در يک جدول است.

شکل 11
4نگاشت رابطه هاي اشيا
در مجموع براي نگاشت وراثت و غيره شما به هنر نگاشت رابطه ها نياز داريد . 3 نوع رابطه وجود دارد

انواع رابطه ها

دو نوع دسته بندي براي رابطه ها وجود دارد گروه اول دسته بندي رابطه ها از نظر تعداد است که روابط به سه دسته روابط يک به يک ما نند را بطه Employee و Position درmployee و Task ،روابط چند به چند تقسيم مي شوند گروه ديگر دسته بندي از بر اساس جهت استوار است که بر اين اساس دو نوع دسته داريم يک جهته و يا دو جهته داريم روابط دو جهته روابطي هستند که يک شيئ اطلاعاتي در رابطه با شيئ ديگه داره در حالي که شيئ ديگه اطلاعاتي در رابطه با شيئ مورد نظر نداره مانند رابطه holds بين Employee و Position در شکل 12 در حالي که روابط دو جهته روابطي هستند که دو طرف روابط همديگر را مي¬شناسند همانند رابطه works در بين Employee و Division.

شکل 12
يک قانون کلي براي Mapping آن است که شما بايد قانون تکثر را رعايت کنيد بدان معنا که روابط يک به يک در اشيائ به روابط يک به يک تبديل مي¬شوند و روابط يک به چند به روابط يک به چند و همين امر در رابطه با روابط چند به چند نيز برقرار است يعني به روابط چند به چند تبديل مي شوند. شکل 13 روابط را در پايگاه داده رابطه اي متناظر با شکل 12 نمايش داده است . ]‎1[

شکل 13
يکي از مسائل موجود در نگاشت، نگاشت رابطه هاي بازگشتي است. که اين روابط نيز بايد به گونه اي در نگاشت ما لحاظ گردند.

5 ميزان سازي نگاشت
راههاي زيادي براي انطباق موجود است و شما مي-توانيد انتخاب کنيد و انتخاب هر راه مزاي

و معايب مخصوص به خود را دارا مي باشد. و انتخاب شما هم وابسته به application است و انتخاب در جهت بالا بردن کيفيت کار است . در اينجا دانستن اين نکته ضروري است که زماني که استراتژي انطباق را تغيير مي دهيد نياز است که هر دوي شماي داده و اشيا را تغيير دهيد.]‎1[

منابع و مراجع :

1. Luca Cabibbo, Antonio Carosi, " Managing Inheritance Hierarchies in Object/Relational Mapping Tools " Journal of Systems and Software, Volume 77, Issue 2, August 2005, Pages 193-207

2. Wolfgang Keller, " Mapping Objects to Tables A Pattern Language " Proceedings EuroPLoP 1997

3. Ronald Bourret, Christof Bornh, Alejandro P. Buchmann, " A Generic Load/Extract Utility for Data Transfer Between XML Documents and Relational Databases" Information and Software Technology, Volume 42, Issue 3, 25 February 2000, Pages 197-210

4. Martin Snyder, Ted O'Connor. " Obj

ect-Relational Mapping in Java with Simple ORM " Dr. Dobb's Journal. San Mateo: Dec 2005. Vol. 30, Iss. 12; p. 34 (3 pages)