PDA

View Full Version : حرفه ای: نگاشات اشیاء به جداول



دانش آموز
یک شنبه 06 مرداد 1392, 09:23 صبح
نگاشات اشیاء به جداول
بخش اول

چکیده
نگاشت اشیاء به جداول مشکلی است و از وقتی طراحان و توسعه دهندگان نرم افزار خواستند به زبانهای شی گرا برنامه بنویسند به وجود آمد، و بنا به دلایلی مجبورند از پایگاه داده های ارتباطی به جای پایگاه داده های شی گرا استفاده کنند.
مقدمه
شی گرایی و مدل ارتباطی دو نمونه متفاوت از برنامه نویسی هستند. هنگامی که نیاز به ذخیره سازی اشیاء در پایگاه داده های ارتباطی داریم باید یک پل ارتباطی میان نگرش های شی گرایی و ارتباطی برقرار کرد. اگر تنها مدل های انتزاعی از داده ها به یک پایگاه داده رابطه-ای نگاشت شود، مهندسی نرم افزار به طور قابل ملاحضه ای آسان می شود. گسترده ای از مفاهیم برنامه نویسی شی گرا لازم است تا به ساختار جداول ارتباطی نگاشت شود این مفاهیم عبارتند از:


تجمیع
ارث بری و چندریختی
ارتباط میان کلاس ها
نوع داده ها


هر کدام از مفاهیم ذکر شده ممکن است با استفاده از روش های مختلف برای کاربردهای یکسانی نگاشته شوند. ما در اینجا راه حل های مختلفی را با استفاده از یک الگوی جداگانه توصیف می کنیم. به این طریق به وضوح پیامد های استفاده از راه حل های مختلف را برروی اهداف عمومی ارائه شده در ادامه بررسی می نماییم.

اهداف عمومی




کارایی:

یکی از اهداف عمده که در هنگام نگاشت اشیاء به جداول که باید در نظر گرفت کارایی است. تعداد دسترسی به پایگاه داده در هنگام نگاشت اشیاء به جداول، باید در نظر گرفته شود. پایگاه داده باالجبار از دیسک سخت یا سایر رسانه های خارجی استفاده می کند تا اجرا شود. سرعت دسترسی این رسانه ها با واحد میلی ثانیه (10-3 Sec) اندازه گیری می شود، از طرفی دیگر چرخه پردازشگر در واحد نانو ثانیه (10-9 Sec) اندازه گیری می شود. از اینرو ایده خوبی است تا زمان کمتری در چرخه پردازشگر و حافظه RAM و دستگاه های ورودی و خروجی صرفه جویی شود.



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



هزینه نگهداری و انعطاف پذیری: گاهی مواقع شما می خواهید از یک نگاشت اولیه در پایگاه داده استفاده کنید. در این موارد انعطاف پذیری از عملکرد آن مهمتر است. زیرا غالبا شما صفت هایی را حذف یا اضافه می کنید، کلاسهایی را اضافه یا پاک می کنید و ارث بری کلاسهایتان را از نو شکل می دهید. موقعی که ارث بری و کلاس ها حالت پایداری به دست آوردند آنگاه شما ممکن است بخواهید به نگاشت با عملکرد بهینه توجه نمایید.



افزونگی و کارایی در مقابل نرمال سازی و هزینه نگهداری: محاسبات ارتباطی به شما کمک می کنند تا افزونگی را با استفاده از نرمال سازی و فاکتورگیری از بین ببرید. از طرفی دیگر برنامه های پایگاه داده های ارتباطی بهترین کارایی را با کمترین تعداد دسترسی به پایگاه داده ارائه می دهند. فاکتور مهم برای یک رکورد مشخص، زمان جستجو است و پهنای باند برای یکبار خواندن داده از یک دیسک مهم نیست. اگر این برنامه ها قادر باشند تمام داده های مورد نیاز یک Use Case را در یکبار دسترسی به پایگاه داده به دست آورند عملکرد بهتری دارند.



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



به هدر دادن فضا در مقابل کارایی: : در اینجا نگاشت هایی است که هیچگونه فضای پایگاه داد ه ای اضافه ای را مصرف نمی کنند، (فیلدهایی با مقادیر NULL و مانند آن) و سایر نگاشت ها بخش های عظیمی از یک پا یگاه داده را بدون استفاده می گذارند. این امر باعث تعجب نیست زیرا برنامه هایی که بیشترین فضا را به کار میبرند معمولاً سریعترین کارایی را دارند.



پردازش Query: در اینجا دو روش متضاد وجود دارد که سیستم های اطلاعاتی تجاری مجبورند یکی از آنها را به کار گیرند.

داده، جهت کار با پردازش تراکنشها باید کارایی خوبی داشته باشد. این بر دوباره سازماندهی کردن داده ها جهت بهینه کردن کارایی دلالت دارد.
داده، برای اهداف ذخیره سازی باید آماده باشد. در این روش در شکلی باید نمایش داده شوند که برای پرس و جوهای خاص مناسب باشد.



ساختن یک منبع داده که نیاز به پردازش های سریع آنلاین را دارد جداگانه ساخته می شوند. اگر شما یک نگاشت برای اشیا با استفاده از جدول طراحی می کنید این روش را در نظر بگیرید، آیا برنامه یک مخزن داده است یا یک برنامه پردازش آنلاین؟
الگوهای نگاشت اشیاء به جدول


این الگوها بر طبق چهارچوب مسئله سازمان یافته است. در اینجا راه حل های متفاوتی جهت نگاشت تجمیع، وراثت و مشارکت وجود دارد.


http://www.karingroup.ir/uploads/Article/Object2Table/ObjectToTable.jpg
دانلود مثال (http://www.4shared.com/rar/eE0Q3O8v/MappingObject2Tables.html)

منبع (http://karingroup.ir/fa/Article/72-%D9%86%DA%AF%D8%A7%D8%B4%D8%A7%D8%AA-%D8%A7%D8%B4%DB%8C%D8%A7%D8%A1-%D8%A8%D9%87-%D8%AC%D8%AF%D8%A7%D9%88%D9%84brsmalll%D8%A8%D8%AE %D8%B4-%D8%A7%D9%88%D9%84small)

دانش آموز
پنج شنبه 10 مرداد 1392, 08:20 صبح
نگاشات اشیاء به جداول بـخـش دوم

الگوهای نگاشت تجمیع

در سطح مدل سازی شی گرا پاسخ به سوال چه هنگام از تجمیع و چه هنگام از مشارکت استفاده کنیم بسیار مشکل است. پاسخ به این سوال اساساً تحت تاثیر ملاحضات کارایی یا انعطاف پذیری قرار می گیرد. ممکن است شما از یک جدول منفرد برای نگاشت تجمیع استفاده کنید که این یک راه حل طبیعی در جهت نگاشت تجیع است. و ممکن است شما از کلید خارجی استفاده کنید که این راه حلی معمول برای نگاشت مشارکت های 1:n است که در مشارکت کلید خارجی در قسمت نگاشت مشارکت ها مورد بحث قرار خواهد گرفت.
الگو: تجمیع با استفاده از یک جدول منفرد

چکیده
الگو به شما نشان می دهد که چگونه تجمیع را به یک مدل داده رابطه ای نگاشت کنید. بدین صورتکه تمام صفات شی تجمیع شده را به یک جدول منفرد نگاشت کنید. مثال: مدل شی زیر را در نظر بگیرید
http://www.karingroup.ir/uploads/Article/Object2Table/aggregatemaptotable1.png
شکل 1: یک AddressType با بیش از یک نوع شی تجمیع شده طرح مسئله
چگونه تجمیع را به جدول رابطه ای نگاشت می کنید؟
اهداف



کارایی: برای نیل به کارایی بهینه، راهکار ارائه شده باید این اجازه را بدهد که یک شی را با یکبار دسترسی به پایگاه داده و بدون هیچگونه عملیات تلفیق جداول بازیابی کرد. جهت صرفه جویی در پهنای باند عملیات ورودی و خروجی دسترسی به پایگاه داده باید کمترین تعداد صفحات را واکشی نماید.
قابلیت نگهداری: برای قابلیت نگهداری بهتر، انواع تجمیع شده آنهایی هستند که در بیشتر از یک نوع شی تجمیع شده اند باید به یک مجموعه از جداول نگاشت شده باشند به جای اینکه بطور یکسان در سرتاسر نقاط بسیار متفاوت در مدل فیزیکی داده سرگردان بمانند. نرمال سازی باید در سطح مدل داده ای استفاده شده باشد تا نگهداری و اجرای ad hoc queryها سهل و آسان شود.
پایداری پایگاه داده: تجمیع بر این دلالت دارد که چرخه حیات شی تجمیع شده به چرخه حیات شی تجمیعی وابسته است. این پایداری به تضمین پایگاه داده یا کد برنامه وابسته است.


راهکار
صفات شی تجمیع شده را در همان جدول شی تجمیعی قرار دهید.
ساختار

http://www.karingroup.ir/uploads/Article/Object2Table/aggregatemaptotable2.png
شی تجمیعی(AggregatingObject) به یک جدول از مدل داده فیزیکی تبدیل می شود. صفات شی تجمیع شده (AggregatedObject) در همان جدول شی تجمیعی گنجانده می شوند. حل کردن مثال
برای حل کردن مثال بالایی به جدول ایجاد شده برای شی Customer نگاه می کنیم.
InvoiceAddress, DeliveryAddress هر دو در جدول پایگاه داده ی Customer گنجانده می شوند.
http://www.karingroup.ir/uploads/Article/Object2Table/aggregatemaptotable3.png
تصویر 2: نگاشت یک شی تجمیع شده در جدول شی تجمیعی از یک پیشوند جهت متمایز کردن صفات استفاده شده است. دست آورد



کارایی: راه کار بر حسب کارایی بهینه است. تنها یک جدول برای دستیابی و بازیابی شی تجمیعی به همراه همه اشیاء تجمیع شده اش نیاز است. از طرف دیگر، فیلدهایی برای صفات تجمیع شده شبیه به افزایش تعداد صفحات بازیابی شده در هر دسترسی به پایگاه داده است. نتیجه اش این است که امکان به هدر رفتن پهنای باند I/O وجود دارد.
نگهداری و انعطاف پذیری: اگر نوع شی تجمیع شده در بیشتر از یک نوع شی تجمیع شده باشد. نتیجه طراحی در قابلیت نگهداری ضعیف است. بدلیل اینکه با هر تغییر در نوع تجمیع شده یک تطبیق در همه جداول پایگاه داده انواع شی تجمیعی صورت می گیرد.
Ad-hoc quries: اگر بخواهید یک query بنویسید که تمام اشیاء AddressType در پایگاه داده را پویش کند، این کار به سختی فرموله می شود.


پیاده سازی



قرارداد نام گزاری: شما به یک نام گذاری جدید یا یک پیشوند برای صفات شی تجمیع شده نیاز دارید. در مثال بالا ما از یک پیشوند کوتاه که از نام صفت اقتباس شده است استفاده کرده ایم.
اندازه فیزیکی صفحه پایگاه داده: : اگر صفات شی تجمیع شده با کسر کمی از صفحه پایگاه داده آغاز کند تاثیر مثبت تجمیع یک شی در همان جدول می-تواند اندکی تصحیح شود. به جای جایگزینی دو صفحه پایگاه داده نیاز به یک خواندن دارد.


الگو: تجمیع با استفاده از کلید خارجی

چکیده
الگو نشان می دهد که چگونه تجمیع را با استفاده از کلید خارجی به مدل داده ای ارتباطی نگاشت کرد
سوابق
دوباره مثال تجمیع به وسیله جدول منفرد را بررسی کنید. (شکل 1 را ببیند). با فرض اینکه شما می خواهید به گونه ای راه حلی ارائه دهید که AddressType به عنوان یک شی کلاس رفتار کند و راه کار شما قابلیت نگهداری بهتری نسبت به تجمیع با استفاده از یک جدول منفرد را مهیا نماید.
طرح مسئله
چگونه تجمیع به جدول ارتباطی نگاشت شود؟
اهداف
به الگوی تجمیع با استفاده از یک جدول منفرد رجوع کنید.
راهکار
از یک جدول جداگانه برای نوع تجمیع شده استفاده کنید. یک فیلد شناسایی شی را در جدول شی تجمیع شده درج کنید و از آن به عنوان شناسایی شی تجمیع شده استفاده کنید. در جدول شی تجمیعی از فیلد شناسایی شی تجمیع شده استفاده کنید. این فیلد یک کلید خارجی به شی تجمیع شده است
ساختار
http://www.karingroup.ir/uploads/Article/Object2Table/aggregatemaptotable4.png
شی تجمیعی (AggregatingObject) به یک جدول نگاشت شده است. شی تجمیع شده (AggregatedType) نیز به جدول دیگری نگاشت شده است. جدول شی تجمیع شده شامل یک فیلد شناسایی شی است. فیلد AggregatedObjectID در جدول شی تجمیعی (Aggregating Object’s Table) کلید خارجی است که به فیلد متناظرش در جدول Aggregated Object ارجاع می دهد.
حل دوباره مثال اگر این راه حل را بر روی مثال قبل اعمال کنیم، تک جدول Customer شامل 2 کلید خارجی است که به جدول AddressType ارجاع می دهند. جدول AddressType شامل یک فیلد شناسایی شی است که از آن برای ارتباط میان دو جدول استفاده می شود.
http://www.karingroup.ir/uploads/Article/Object2Table/aggregatemaptotable3.png
هزینه بازیابی یک شی Customer از پایگاه داده نیاز به سه بار عمل دسترسی به پایگاه را دارد.( یکبار برای Customer و یکبار برای هریک از AddressTypeها یکبار برای InvoiceAddress و بار دیگر برای DeliveryAddress) و این در ازای یکبار دسترسی در حالت تجمیع با استفاده از یک جدول منفرد می باشد.
دست آورد



کارایی: تجمیع با استفاده از کلید خارجی به یک عمل تلفیق یا حداقل 2 بار دسترسی به پایگاه داده نیاز دارد در حالی که تجمیع با استفاده از یک جدول منفرد تنها نیاز به یک عمل دسترسی به پایگاه داده را دارد. اگر دسترسی به اشیاء تجمیع شده از لحاظ آماری حالتی نادر است؛ این تلفیق قابل قبول است. اگر اشیاء تجمیع شده دائماً به همراه شی تجمیعی بازیابی می شوند، شما مجبورید کارایی را نیز در نظر داشته باشید.
نگهداری: با فاکتور گیری از اشیاء شبیه به AddressType و قراردادن آن ها در جداول مربوط به خودشان نگهداری ساده تر و نگاشت پذیری منعطف تر می گردد.
پایداری پایگاه داده: اشیاء تجمیع شده در صورت حذف اشیاء تجمیعی به صورت اتوماتیک حذف نمی شوند. جهت انجام این کار شما باید از طریق کد نویسی برنامه یا از طریق تریگر این کار را انجام دهید. همچنین این کار یک موضوع پیاده سازی است. شما مجبورید یک از این دو گزینه را انتخاب کنید.
Ad-hoc queries: : با فاکتورگیری از اشیاء تجمیع شده و قراردادن آن ها در جداول جداگانه این امکان به وجود می آید تا queryهای نوشته شده برای این جداول ساده باشند.


پیاده سازی



استفاده از domain keysها را به جای شناسایی شی در نظر بگیرید. Domain keys دارای ایراداتی هستند. از آن-ها نمی توان برای اشارات بازگشتی به مالک یک شی استفاده کرد. بدین صورتکه یک شی مالک شی نمی تواند از همه انواع اشیاءی که هرگز مالک آن ها نبوده آگاهی پیدا کند
برقراری یک ارتباط از شی تجمیع شده به شی تجمیعی را در نظر بگیرید. در مثال آدرس ما این ارتباط به وسیله قراردادن یک فیلد در داخل جدول آدرس که نشان دهنده مالک شی AddressType انجام گرفته است. یک مالک ممکن یک Employee یک Customer یا ممکن است سایر انواع دیگر باشد که AddressTypeها را مجتمع می کند. شما مجبورید از یک شناساننده شی به عنوان نوع ارتباطی استفاده کنید. ارتباط های یک طرفه برخی مزایا را برای queryها ، بررسی پایداری و یا سایر اهداف ارائه می دهند. شما مجبور نیستید برای پیداکردن مالک یک شی تجمیع شده جدول شی تجمیعی را جستجو کنید. از طرف دیگر ارتباط های بازگشتی بر حسب پایگاه داده بسیار پر هزینه هستند. عملیات پایگاه داده نیاز دارد تا آن ها را به روز رسانی کند.

منبع (http://www.karingroup.ir/fa/Article/73-%D9%86%DA%AF%D8%A7%D8%B4%D8%A7%D8%AA-%D8%A7%D8%B4%DB%8C%D8%A7%D8%A1-%D8%A8%D9%87-%D8%AC%D8%AF%D8%A7%D9%88%D9%84--%D8%A8%D9%80%D8%AE%D9%80%D8%B4-%D8%AF%D9%88%D9%85)