طراحی بانک های اطلاعاتی : مبانی مدل سازی - برترین مقالات کامپیوتر
X
تبلیغات
پیکوفایل
رایتل


برترین مقالات کامپیوتر

برترین مقالات کامپیوتر

طراحی بانک های اطلاعاتی : مبانی مدل سازی
طراحی پایگاه داده و ایجاد نمودار ارتباط موجودیت ها (ERD) یکی از مهمترین بخش های چرخه حیات توسعه یک نرم افزار است که در برخی موارد از آن به عنوان مهمترین بخش نیز نام برده می شود . مدل صحیح و به هنگام (Up To Date) اطلاعات می تواند به عنوان مهمترین ابزار مرجع برای مدیران بانک اطلاعاتی (DBAs) ، پیاده کنندگان نرم افزار و سایر اعضاء تیم توسعه دهنده نرم افزار باشد . فرآیند ایجاد مدل داده به تیم توسعه دهنده کمک می کند تا به پرسش های مطرح شده توسط کاربران نهائی سیستم پاسخ دهند .همچنین طراحی کارا و موثر پایگاه داده به تیم توسعه دهنده این امکان را می دهد تا سیستم را از همان ابتدا در فرم مناسب پیاده سازی نمایند . ساخت سیستم با کیفیت فوق الذکر این امکان را به تیم توسعه دهنده خواهد داد تا زمان کلی انجام پروژه را کاهش دهند ، که در واقع این امر موجب کاهش هزینه های توسعه پروژه نیز خواهد شد .
با توجه به موارد فوق ، شعار طراحی خوب و جامع پایگاه داده این است که :

اول اندازه بگیر و بعد قیچی کن

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

* به حداقل رسانی افزونگی اطلاعات
* به حداقل رسانی تغییر ساختار اطلاعات
* به حداقل رسانی I/O سرور به منظور کاهش تعداد تراکنش ها (Transactions)
* و در نهایت حفظ یکپارچگی اطلاعات

برای طراحی بانک اطلاعاتی نرم افزار و مدل سازی آن می بایست اصول و تکنیک های ذیل را مد نظر داشت و از آنها استفاده نمود .

موجودیت (Entity) ، مجموعه ای از چیزهائی است که مربوط به بانک اطلاعاتی سیستم مورد نظر می باشد و یا به تعبیر دیگر هر آنچه که می خواهید در سیستم راجع به آن اطلاعات جمع آوری و نگهداری نمائید را شامل می شود . در مدل فیزیکی ، موجودیت تبدیل به جدول (Table) می شود .

خصلت (Attribute) یکی از مشخصه های توصیفی و یا مقداری موجودیت می باشد . در مدل فیزیکی یک خصلت به یک ستون (Column) و یا فیلد (Field) تبدیل می شود .

کلید اصلی (Primary Key) خصلت و یا ترکیبی از خصلت ها در یک موجودیت است که تضمین کننده یکتا بودن هر رخداد از موجودیت می باشد . خصلت یا خصلت های کلید اصلی نمی توانند فاقد ارزش باشند (NULL) و معمولا" کمتر تغییر می کنند . معمولا" سعی می شود جهت انتخاب کلید اصلی از خصلت هائی استفاده شود که کارائی بیشتری داشته و بهترین معرف موجودیت باشند (کارائی یک فیلد از نوع Integer به مراتب بیشتر از فیلدی از نوع Char است ) . در صورتیکه نتوان در یک موجودیت خصلت یا خصلت هائی برای کلید اصلی شدن یافت ، آنگاه کلیدهای دستی برای این کار را ایجاد می کنیم که به آنها کلید Artificial می گویند .

ارتباط ( Relationship) ، ارتباط منطقی بین دو موجودیت است . یک ارتباط در واقع نشان دهنده قوانین کاری حاکم بر پروژه و اطلاعات آن است که معمولا" به صورت جملات فعلی توصیف می گردد . مثل ارتباط بین موجودیت کارمند و دپارتمان که به صورت جمله ذیل بیان می شود :
"کارمند شاغل است در دپارتمان" در این مثال ارتباط بین موجودیت کارمند و دپارتمان با جمله "شاغل است" توصیف میگردد .
دو نوع ارتباط می تواند بین موجودیت ها وجود داشته باشد :

*

ارتباط یک به چند (One To Many) در این نوع ارتباط ، هر رخداد از موجودیت والد با چندین رخداد در موجودیت فرزند ارتباط دارد . به عنوان مثال چندین کارمند می توانند در یک دپارتمان شاغل به کار باشند .
*

ارتباط چند به چند (Many To Many) . در این نوع ارتباط ، چند رخداد از یک موجودیت با چند رخداد از موجودیت دیگر ارتباط دارند . به عنوان مثال اگر یک کارمند بتواند در چند دپارتمان شاغل به کار باشد ، آنگاه ارتباط بین موجودیت کارمند و دپارتمان یک ارتباط چند به چند است . ارتباط چند به چند در طراحی پایگاه داده پذیرفته شده نیست چراکه علاوه بر افزونگی اطلاعات موجب عدم یکپارچگی اطلاعات نیز می گردد ، از اینرو باید این ارتباط طبق فرم چهارم نرمال سازی تبدیل به دو ارتباط یک به چند شود . همانطور که د برای حل این مشکل کافی است یک موجودیت واسط که به آن موجودیت XREF می گویند ایجاد و خصلت های کلید اصلی هردو موجودیت را به این موجودیت رابط منتقل نمود . با این عمل هریک از موجودیت های اصلی به عنوان والد این موجودیت رابط تلقی شده و یک ارتباط یک به چند بین آنها برقرار خواهد شد. در نتیجه یک ارتباط چند به چند تبدیل به دو ارتباط یک به چند خواهد شد . لازم به ذکر است که بسیاری از سیستم های مدیریت بانک های اطلاعاتی رابطه ای ( نظیر MS SQL Server) از ارتباط چند به چند پشتیبانی نمی کنند .

کلید خارجی (Foreign Key) . هرگاه خصلت(های) کلید اصلی موجودیت والد در موجودیت فرزند وجود داشته باشد (بر اساس ارتباط تعریف شده بین دو موجودیت) آنگاه این خصلت ها در موجودیت فرزند ، کلید خارجی نامیده می شوند . در واقع نمی توان هیچ رخدادی در موجودیت فرزند (که دارای کلید خارجی است) ایجاد نمود که رخداد مربوط به آن (بر اساس محتوای خصلت کلید خارجی) قبلا" در موجودیت والد ایجاد نشده باشد . آنگونه که از توصیف فوق استنباط می شود کلید خارجی تضمین کننده یکپارچگی اطلاعات در داخل پایگاه داده است چرا که باعث می شود که هیچ فرزند بدون والدی در بانک اطلاعاتی نداشته باشیم .

ارتباط (RelationShip) بین دو موجودیت به دو مدل ذیل دسته بندی می گردد :

*

ارتباط تعریف شده (identifying Relationship) . اگر کلید اصلی جدول والد بخشی (یا تمام) از کلید اصلی جدول فرزند باشد و یا به تعبیر دیگر بخشی از کلید اصلی موجودیت فرزند کلید خارجی نیز باشد ، در این حالت ارتباط مابین این دو موجودیت از نوع تعریف شده است .
*

ارتباط تعریف نشده (Non-Identifying Relationship) ، برخلاف مورد فوق اگر کلید اصلی جدول والد در جدول فرزند وجود داشته باشد اما نه به عنوان بخشی از کلید اصلی آن و صرفا" به عنوان یک خصلت غیر کلید ، در این حالت ارتباط بین این دو موجودیت از نوع تعریف نشده می باشد . ارتباط تعریف نشده خود دارای دو حالت متفاوت به شرح ذیل است :
mandatory non-identifying relationship ، زمانی است که خصلت کلید خارجی در موجودیت فرزند نتواند فاقد ارزش باشد (Not Allow NULL)
non-mandatory non-identifying relationship ، زمانی است که خصلت کلید خارجی در موجودیت فرزند بتواند فاقد ارزش باشد (Allow NULL)

Cardinality ، به ما در فهم بیشتر ماهیت ارتباط مابین موجودیت والد و فرزند کمک می کند . جهت تشخیص Cardinality یک ارتباط کافی است به سئوال ذیل پاسخ داده شود :
" چه تعداد رخداد از موجودیت فرزند مرتبط است با هر رخداد از موجودیت والد؟ "
چهار نوع Cardinality مختلف به شرح ذیل وجود دارد :

*

One To Zero or Many به این معنی که هر رخداد از موجودیت والد با هیچ و یا چند رخداد از موجودیت فرزند مرتبط است . به این نوع Common Cardinality می گویند.
*

One To One Or Many به این معنی که هر رخداد از موجودیت والد با حداقل یک و یا چند رخداد از موجودیت فرزند مرتبط است . به این نوع P Cardinality می گویند .
*

One To Zero Or One ، به این معنی که هر رخداد از موجودیت والد با هیچ و یا تنها یک رخداد از موجودیت فرزند مرتبط است . به این نوع Z Cardinality می گویند .
*

One to Exactly N ، به این معنی که هر رخداد از موجودیت والد باید با N رخداد از موجودیت فرزند مرتبط باشد . به این نوع N Cardinality می گویند .

خلاصه

*

طراحی خوب بانک اطلاعاتی می تواند به تیم توسعه دهنده نرم افزار در کاهش زمان انجام پروژه و هزینه های آن کمک کند .
*

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

یکی از اهداف اصلی طراحی بانک اطلاعاتی و مدل سازی آن ، مستقل بودن آن از پلت فرم است ، بنابر این اختیار انتخاب محیط و پلت فرم پیاده سازی فیزیکی پایگاه داده با تیم توسعه دهنده بوده و در ماحصل کار هیچ تغییری ایجاد نخواهد کرد .
نوشته شده در چهارشنبه 7 شهریور‌ماه سال 1386ساعت 21:58 توسط ADMIN نظرات (0)|


Design By : Night Skin