مبانی و اصول نرمال سازی پایگاه داده در خلال طراحی به کار خواهد آمد. نرمال سازی فرآیندی در خلال طراحی پایگاه داده است که با چهار هدف عمده ذیل دنبال می‌شود :
- به حداقل رسانی افزونگی اطلاعات
- به حداقل رسانی تغییر ساختار اطلاعات
- به حداقل رسانی 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 می‌گویند .
خلاصه
طراحی خوب بانک اطلاعاتی می‌تواند به تیم توسعه دهنده نرم افزار در کاهش زمان انجام پروژه و هزینه‌های آن کمک کند .
طراحی بانک اطلاعاتی و مدل سازی آن به تیم توسعه دهنده نرم افزار کمک خواهد کرد تا درک بهتر و عمیقتری نسبت به نیازمندیهای کاربران نرم افزار پیدا کرده و در نتیجه نرم افزاری را توسعه دهند که در برگیرنده قوانین کاری و خواسته آنها باشد .
یکی از اهداف اصلی طراحی بانک اطلاعاتی و مدل سازی آن، مستقل بودن آن از پلت فرم است، بنابر این اختیار انتخاب محیط و پلت فرم پیاده سازی فیزیکی پایگاه داده با تیم توسعه دهنده بوده و در ماحصل کار هیچ تغییری ایجاد نخواهد کرد .
منبع انتزاعی: مبانی مدل سازی در طراحی بانک‌های اطلاعاتی
