در اكثر پروژههاي كامپيوتري انجام شده در دهههاي اخير از تكنولوژيهاي تمام شئگرايي مانند Java و C# استفاده شده در حالي كه براي ذخيره سازي دادهها از پايگاهدادههاي رابطهاي كه در آنها اثري از شئگرايي موجود نيست استفاده شده. اين بدين معنا نيست كه انتخابهاي ديگري موجود نيست بلكه بسياري زبانهاي برنامهنويسي Procedural شبيه COBOL موجود است همچنين بسياري از پايگاهدادههاي موجود از تكنولوژي شئگرا بهره ميبرند از جمله ميتوان از پايگاهدادههاي XML نام برد.
بين تكنولوژيهاي شئ گرايي و رابطهاي كه اكثر تيمهاي نرمافزاري در سيستمهاي خود بهكار ميبرند يك ناهمخواني ذاتي موجود است. براي رفع اين ناهمخواني يك راه ساده وجود دارد كه از دو بخش تشكيل شده: ابتدا بايد پروسهي نگاشت اشياء به رابطههاي پايگاهداده را آموخت و سپس روشي براي پيادهسازي آن فرا گرفت.
1 نقش DBA
شكل 1 نشان دهنده نقش يك DBA است زماني كه نگاشت بين مدل رابطهاي و شئگرا را انجام ميدهد. سه عمل اوليه براي اينكار عبارتند از:
1- نگاشت [1]: هدف اصلي يافتن يك استراتژي مناسب و كارا براي نگاهداري دادههاي اشياء است. اين كار شامل ذخيره كردن صفات و رابطههاي بين اشياء از جمله رابطهي ارث بري ميان اشياء است.
2- پيادهسازي نگاشت [2]
3- يكسان ساختن كارايي [3]
نكتهي قابل توجه در شكل1 اين است كه هم DBA ها و هم توليدكنندگان نرمافزارها در هر سه فعاليت بالا با هم كار ميكنند. ]1[
2 ايده اصلي
اولين چيزي كه در نگاشت اشياء به پايگاهدادههاي رابطهاي به نظر ميرسد نگاشت بين صفات اشياء و ستونهاي جداول است. هر صفت از يك شئ به صفر يا چند ستون در پايگاهداده رابطهاي تبديل ميشود. به خاطر داشته باشيد كه كليه صفات يك شئ پايدار (Persistent) نيستند. به عنوان مثال صفت ميانگين نمرات در يك شئ Student ممكن است فقط در برنامه استفاده شود در حالي كه نيازي به ذخيرهسازي مقدار آن در پايگاهداده نيست چراكه از روي مقادير باقي صفات قابل محاسبه ميباشد. و يا بعضي صفات در اشياء خود يك شئ مستقل ميتواند باشد به همين دليل ممكن است در پايگاهداده رابطهاي مجموعهاي از چند ستون به عنوان جايگزيني براي يك صفت در يك شئ در نظر گرفته شود. سادهترين حالت در نگاشت يك شئ زماني است كه هر صفت از يك شئ به يك ستون از يك جدول در پايگاهداده نگاشت شود مخصوصاً زماني كه نوع دادهاي در مدل شئگرا با نوع دادهاي در مدل رابطهاي يكسان باشند. ]4[
براي سادگي ميتوان فرض كرد كه كلاسها به صورت يك به يك به جداول در پايگاهدادهها نگاشت ميشوند. اما به غير از موارد بسيار ساده و ابتدايي همانطور كه در ادامه خواهيم ديد اين فرض اشتباه بوده و نياز به عمليات بيشتري براي نگاشت ميان كلاسها و جداول در اين دو مدل است. اما در اين نوشته معمولاً ابتدا هر كلاس را به يك جدول نگاشت كرده و سپس ساير بهينه سازيها را انجام ميدهد.
شكل ۲ نشان دهنده يك نمودار كلاس ساده به همراه مدل ذخيره سازي فيزيكي معادل آن در پايگاهداده رابطهاي ميباشد. شما در اين شكل ميتوانيد ارتباط بين عناصر يك كلاس با ستونهاي پايگاهداده را مشاهده كنيد.
با وجودي كه شماها در شكل نشان داده شده بسيار شبيه هستند اين تفاوتها بدان معنا است كه انطباق كامل نخواهد بود. تفاوتها بين شماها شامل :
- چندين خصيصه براي tax در نمودار كلاس وجود دارد در صورتي كه تنها يك معادل در شماي داده براي آن موجود است. اين بدان معنا است كه سه خصيصه tax در كلاس tax در یک ستون از جدول Order اضافه و نگهداري شوند در زمان ذخيره سازي و وقتي شيئ خوانده ميشود در حافظه 3 خصيصه بايد محاسبه شوند .
- شماي داده شامل كليد است در حالي كه شماي شيئ اين خصيصه را ندارد بايد براي شناسايي و ارتباط بين كليد در كلاس سياست و روندي اتخاذ گردد. به اين اطلاعات اضافي “اطلاعات سايه”[4] ميگوييم.
- نوع هاي مختلفي در هر شما موجود است بايد بدون از بين رفتن اطلاعات بتوان آنها را به هم تبديل كرد. ]2[
اطلاعات سايه
اطلاعات سايه شامل هر داده اي است كه اشيائ براي ساختن نياز دارند. از قبيل كليد، كنترل همروند و … .
شكل۳ مدل ريزتري از كلاسهاي Order و Order Item را مشخص ميكند.
- شامل خصوصيات سايهاي كه كلاس براي نمايش مطبوع خودش نياز دارد ميباشد. در جلو اسم اين خصوصيات به جاي خط فاصله فاصله قرارگرفته و جلو آنها واژه كليشهاي <<persistence>> قرار گرفتهاست
- چهارچوب اطلاعات مورد نياز براي ايفا روابط بين خصوصيات دو كلاس .چهارچوب خصوصيات، از قبيل بردار OrderItem در Order.
- تابع GetTotalTax() به كلاس Order براي محاسبه مقدار tax در جدول Order اضافه شدهاست. ]2[
اطلاعات سايه به طور ضروري نيازمند ايفا شدن بوسيله 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
شكل۴ به قسمت عمده تكنيك مقاومت غير انطباقي[5] بين تكنولوژي شيئ و تكنولوژي رابطهاي است. كلاسها رفتار وداده هاي و روابط جداول پايگاه داده را مشخص ميكنند. نتيجه نهايي وقتي بدست ميآيد كه شما يك كلاس رو به روابط پايگاه داده انطباق ميدهيد. شما بايد Operation هاي getter و setter را هم براي هر ستون جدول به كلاس اضافه كنيد.
3نگاشت ساختارهاي وراثتي
پايگاهدادههاي رابطهاي به طور ذاتي وراثت را پشتيباني نميكنند، بنابر اين شما مجبوريد ساختارهاي وراثتي را در شماهاي شيئ براي شما داده ترسيم كنيد.
مفهوم وراثت در چندين پيجيدگي جالب در زمان ثبت اشيا در پايگاهدادههاي رابطهاي گذاشتهشده.ما چندين راه حل مقدماتي براي نگاشت وراثت به پايگاهداده رابطهاي ارائهكردهايم. كه اين تكنيكها شامل:
- نگاشت كلاس وراثت به يك جدول تنها
- نگاشت هر كلاس واقعي با جدول خودش.
- نگاشت هر كلاس با جدول خودش.
- نگاشت كلاسها به ساختار كلي جداول. ]2[
براي توصيف هر تكنيك ما چگونگي نگاشت دو نسخه از وراثت نمايش داده شده در شكل۵ را توضيح مي دهيم نسخه اول شامل ۳ كلاس است – person، كلاس انتزاعي، و دو كلاس employee , costomer – نسخه دوم وراثت كلاس ديگري را اضافهميكند بنام executive .
نگاشت كلاس وراثت به يك جدول تنها
تمام خصيصههاي كلاسها را در يك جدول نگهداري ميكنيم. شكل۶ مدل دادهاي مورد نظر براي شكل۵ را نمايش ميدهد. كه نام اين جدول person است، يك استراتژي خوب براي نام گذاري جدول استفاده از نام ريشه كلاس وراثت است كه يك قانون سرراست است.
دو ستون به جدول اضافه شدهاند _PersonType , PersonPOID ستون دوم جهت مشخصكردن كليد است و اولي براي مشخص كردن آن است كه Peson مشتري يا كارمند يا هر دو آنها ميباشد. PersonPOID يك مشخص كننده پايا اشيا است. كه معمولا به آن مشخص كننده شيئ[6] ميگوييم.
زماني كه executive را هم اضافه كنيد آنگاه جداول به صورت شكل۷ در ميآيد. ][4
نگاشت هر کلاس واقعي به جدول مخصوص خود
در اين زمينه هر جدول براي هر کلاس وااقعي شاخته شده است، هر جدول شامل خصوصيات ايفاشده بوسيله کلاس و خصوصيات ارث برده شده توسط آن است. شکل8 مشخص کننده مدل فيزيکي داده براي سلسله مراتب شکل5 است زماني که اين زمينه برخورد شده است.
نگاشت هر کلاس به جدول مخصوص آن کلاس
اين استراتژي را که هر کلاس جدول مخصوص به خود را دارد در نظر ميگيريم. با يک ستون براي خصوصيات تجاري و هر اطلاعات شناسايي.شکل9 مدل فيزيکي داده کلاسهاي شکل5 را زماني که هر کلاس به يک جدول نگاشته شده است را نمايش داده است. داده ها براي کلاس customer در دوکلاس نگهداري شدهاند، Customer وPerson ، بنابر اين براي دريافت اين داده شما نياز داريد دو جدول را متصل کنيد.
عمليات بر روي کليدها جالب به نظر ميرسند. نکته جالب آن است که personPOID بعنوان کليد براي تمامي جداول در نظر گرفته ميشود.براي جداول Customer,Employee,Executive ، personOID هم کليد اصلي و هم کليد خارجي است. ]3[
نگاشت کلاس به يک ساختار نوعي جدولي
چهارمين انتخاب براي ساختار وراثتي به پايگاه داده رابطهاي گرفتن يک نوع ، بعضي اوقات به آن meta-data ميگوييم، براي نگاشت کلاسها است. در شکل10 شما يک شما داده براي مرتب کردن مقدار صفتها و براي انتقال ساختار وراثتي است.
مقدار ObjectPOID نگهداشته شده در يکتا شناخته شده براي يک شيء مشخص است. جدول AttributeType شامل سطرهايي براي نوعهاي دادهاي اصلي ازقبيل data،string،money،integer و غيره.اين اطلاعات براي پوشش دادن مقدار خصوصيات نگهداري شده در مقدار لازم شدهاند.
براي نگاشت ساختار بين Person وCustomer ، در شکل5، در اين شما. جدول وراثت يک کليد براي نگاشت وراثت است. هر کلاس بوسيله يک جدول کلاس نشان داده خواهد شد. همچنين يک رديف در جدول Inheritance است. در Inheritance يک رديف وجود خواهد داشت که مقدار Inheritance.SuperClassPOID به يک رديف در کلاس Person و Inheritance.SubClassPOID به کلاس Customer اشاره ميکند. براي نگاشت الباقي سلسله مرتب نيازداريد يک رديف در Inheritance براي هر رابطه وراثتي نياز است. ]3
نگاشت وراثت چندگانه[7]
گاهي اوقات نياز داريم که سلسله مراتب چندگانه را به پايگاه داده رابطهاي تبديل کنيم.
شکل11 نشاندهنده سه شماي داده است که نتيجهاي براي استعمال هر سه استراتژي نگاشت وراثت است. شما ميتوانيد نگاشت وراثت جندگانه را در شکل11 ببينيد. يکي ازمهارتها مشخص کردن نام مناسب در زمان نگاشت در يک جدول است.
4نگاشت رابطه هاي اشيا [8]
در مجموع براي نگاشت وراثت و غيره شما به هنر نگاشت رابطه ها نياز داريد . 3 نوع رابطه[9] وجود دارد
انواع رابطه ها
دو نوع دسته بندي براي رابطه ها وجود دارد گروه اول دسته بندي رابطه ها از نظر تعداد [10] است که روابط به سه دسته روابط يک به يک[11] ما نند را بطه Employee و Position در شکل 12 مانند رابطه Employee Division در شکل 12 ، روابط يک به چند [12] همچون رابطه Employee و Task ،روابط چند به چند [13] تقسيم مي شوند گروه ديگر دسته بندي از بر اساس جهت استوار است که بر اين اساس دو نوع دسته داريم يک جهته[14] و يا دو جهته[15] داريم روابط دو جهته روابطي هستند که يک شيئ اطلاعاتي در رابطه با شيئ ديگه داره در حالي که شيئ ديگه اطلاعاتي در رابطه با شيئ مورد نظر نداره مانند رابطه holds بين Employee و Position در شکل 12 در حالي که روابط دو جهته روابطي هستند که دو طرف روابط همديگر را ميشناسند همانند رابطه works در بين Employee و Division.
يک قانون کلي براي Mapping آن است که شما بايد قانون تکثر را رعايت کنيد بدان معنا که روابط يک به يک در اشيائ به روابط يک به يک تبديل ميشوند و روابط يک به چند به روابط يک به چند و همين امر در رابطه با روابط چند به چند نيز برقرار است يعني به روابط چند به چند تبديل مي شوند. شکل 13 روابط را در پايگاه داده رابطه اي متناظر با شکل 12 نمايش داده است . ]1[
يکي از مسائل موجود در نگاشت، نگاشت رابطه هاي بازگشتي[16] است. که اين روابط نيز بايد به گونه اي در نگاشت ما لحاظ گردند.
5 ميزان سازي نگاشت
راههاي زيادي براي انطباق موجود است و شما ميتوانيد انتخاب کنيد و انتخاب هر راه مزايا و معايب مخصوص به خود را دارا مي باشد. و انتخاب شما هم وابسته به application است و انتخاب در جهت بالا بردن کيفيت کار است . در اينجا دانستن اين نکته ضروري است که زماني که استراتژي انطباق را تغيير مي دهيد نياز است که هر دوي شماي داده و اشيا را تغيير دهيد.]1[
[1] Mapping
[2] Implement mapping
[3] Performance tuning
[4] Shadow information
[5] Impedance mismatch
[6] Object identifier (OID)
[7] Multiple Inheritance
[8] Object Relationships
[9] Association, Aggregation, Composition
[10]Multiplicity
[11] One-to-one relationships
[12] One-to-many relationships
[13] Many-to-many relationships
[14] Uni-directional relationships
[15] Bi-directional relationships
[16] Recursive