مبانی مدل سازی در طراحی بانک های اطلاعاتی New Page 1



ساير




 

 

 

SAKHA RAVESH CO.

 ا مروز

 سه شنبه  5  ارديبهشت  1396  2017  Apr.  25   Tuesday ToDay
صفحه اصلی  مقالات نکته هادايره المعارف خودآموزها | تازه ها خود آزمون ها    
  نسخه قابل چاپ  

    5 4 3 2 1 

 عنوان

 نويسنده

  مشاهده

 تعداد آراء

 امتياز

 طراحی بانک های اطلاعاتی : مبانی مدل سازی

 مديريت نرم افزار

21444

40

3.8

با توجه به جایگاه داده در عصر حاضر و  لزوم نگاه جامع به این مقوله مهم ، بر آن شدیم تا محوریت فعالیت های خود را بر  روی این موضوع متمرکز نمائیم . از این رو گروه فابک با شعار فناوری اطلاعات برای کسب وکار شکل گرفت و  خدمات خود  را از طریق  سایت www.fabak.ir  به مخاطبان محترم عرضه می نماید

 

طراحی بانک های اطلاعاتی : مبانی مدل سازی

طراحی بانک های اطلاعاتی : مبانی مدل سازی
طراحی پايگاه داده و ايجاد نمودار ارتباط موجوديت ها (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 می گويند .

 خلاصه

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

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

  •  يكی از اهداف اصلی طراحی بانک اطلاعاتی و مدل سازی آن ، مستقل بودن آن از پلت فرم است ، بنابر اين اختيار انتخاب محيط و پلت فرم پياده سازی فيزيكی پايگاه داده با تيم توسعه دهنده بوده و در ماحصل کار هيچ تغييری ايجاد نخواهد کرد .

 ساير مطالب مرتبط :
- بانک های اطلاعاتی رابطه ای : مفاهيم و تعاريف
- نرمال سازی بانك های اطلاعاتی



جستجو

مقالات                 
دايره المعارف       
دوره های آموزشی


 

 

مشاهده گروه ها



              

 

 تهيه شده در شرکت سخا روش -  1382