برچسب: پایگاه داده

مدلسازی پایگاه داده از روی نمودار کلاس UML

رابطه وراثت((inheritance :

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

روش اول:

در این روش برای کل سلسله مراتب کلاس، یک جدول در نظر می گیریم. که ساختار جدول به صورت زیر خواهد بود.

{صفات سوپر کلاس، صفات مختص زیر کلاس ها و یک فیلد نوع کلاس (موجودیت)}

فیلد نوع برای ذخیره اینکه رکورد مورد نظر مربوط به اطلاعات کدام کلاس است به کار می رود.

برای مثال برای نمودار بالا، ساختار زیر را خواهیم داشت:

{شماره شناسایی، نام، نام خانوادگی، مقطع، رشته، درجه، سابقه تحصیل و نوع}

همانطوریکه مشاهده می شود در جدولی با شمای بالا بعضی از فیلد برای نمونه ای از دانشجو و هم برای نمونه ای از استاد دارای مقدار NULL  خواهند بود. که یک عیب برای این روش محسوب می شود. همچنین با تغییر در صفات هر یک از کلاس ها مجبوریم جدول را دستکار کنیم که باعث خواهد شد در کلاس های دیگر نیز تغییراتی دهیم. این روش به نظر من یک روش ناکارامد می باشد. و بهتر است از این روش استفاده نشود.

 

روش دوم:

در این روش برای هر زیر کلاس یک جدول در نظر می گیریم. که شمای هر جدول به صورت زیر خواهد بود:

{صفات سوپر کلاس و صفات مختص زیر کلاس}

برای مثال برای همان نمودار مثال قبل دو جدول زیر را خواهیم داشت:

استاد{شماره شناسایی، نام، نام خانوادگی،درجه، سابقه تحصیل }

دانشجو{شماره شناسایی، نام، نام خانوادگی، مقطع، رشته }

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

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

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

اما مزیت این روش نسبت به روش اول اینست که در این روش دیگر ستونهای با مقادیر Null را نخواهیم داشت.

 

روش سوم:

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

برای مثال برای نمودار مثال اول، اگر صفت شماره شناسایی را برای هر شخص منحصر بفرد در نظر بگیریم.خواهیم داشت:

شخص{شماره شناسایی، نام، نام خانوادگی}

استاد{شماره شناسایی، درجه، سابقه تحصیل}

دانشجو{شماره شناسایی، مقطع، رشته}

این روش بهترین گزینه برای ما می باشد.زیرا دقیقا هر کلاس را به یک جدول جداگانه و مستقل نگاشت می کند. و هر تغییری در یک کلاس فقط در جدول مربوط به آن کلاس تاثیر خواهد گذاشت و بر خلاف دو روش قبلی، روی جدول های دیگر تاثیر نخواهد گذاشت. در این روش نه افزونگی داده داریم و نه ستونی با مقدار Null.

 

رابطه association:

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

اما برای نگاشت این رابطه بین دو کلاس به رابطه بین دو جدول(برای هر کلاس یک جدول در نظر می گیریم.) چه کاری باید انجام دهیم؟

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

 

برای مثال برای نمودار شکل بالا جدول های زیر را خواهیم داشت.

آدرس{کد پست ده رقمی، شهر، خیابان و …}

شخص{کد پستی ده رقمی و صفات کلاس شخص}

 

رابطه تجمع (aggregation) و رابطه ترکیب (composition):

رابطه تجمع، یک رابطه بین یک واحد کل و جزء است. در این رابطه، بزای موجودیت کل، یک جدول و برای هر یک از کلاس های جزء نیز یک جدول طراحی می کنیم. در هر کدام از جدول های مربوط به اجزاء جزء، کلید اصلی (یا یکی از کلید های کاندید) جدول مربوط به واحد کل را می آوریم.

 

برای نمونه برای شکل بالا خواهیم داشت:

ماشین{صفات مربوط به ماشین}

تایر{کلید اصلی جدول ماشین و صفات مربوط به تایر}

موتور{کلید اصلی جدول ماشین و صفات مربوط به موتور}

در رابطه تجمع، شی جز به شی کل وابسته نیست. پس با حذف شی کل، اجزاء تشکیل دهنده آن از بین نمی روند. بلکه باید مقدار مربوط به صفت کلید شی کل در اشیاء جزء پاک شوند.

تبدیل رابطه ترکیب نیز شبیه رابطه تجمع است اما به یک تفاوت. چون در رابطه تجمع اشیاء تشکیل دهنده کل به واحد کل وابسته هستند ونمی توانند بدون آن به حیاتشان ادامه بدهند. با حدف شی کل، اشیاء جزء نیز باید حذف شوند. در واقع ما در اینجا باید یکپارچکی ارجاعی (Referential Integrity) را رعایت کنیم.

در اینجا من به در خواست یکی از دوستان فقط به بررسی روابط بین کلاس ها پرداختم. ولی دوستانی که به این موضوع علاقه دارند می توانند به مقاله Database Modelling in UML در سایت www.sparxsystems.com.au مراجعه کنند.