بانک های اطلاعاتی رابطه ای

[FriendlyGhost 998]

قبل از پرداختن به موضوع بانک های اطلاعاتی رابطه ای (Relational Data Base) ، بهتر است اشاره ای به مفاهیم ذیل داشته باشیم :

موجودیت (Entity)

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

- موجودیت مشتری شامل خصلت های نام مشتری ، آدرس مشتری ، تلفن مشتری و … است .

- موجودیت سفارش شامل خصلت های شماره سفارش ، تاریخ سفارش ، نام مشتری ، کالای سفارش شده ، تعداد کالای سفارش شده و … است

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

کلید (Key)

 

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

توضیح : در برخی از موارد در یک موجودیت چندین کلید وجود دارد که به هر یک از آنها یک Candidate Key یا Alternate Key گفته می شود .

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

[FriendlyGhost 998]

کلید اصلی (Primary Key)

 

از بین کلیدهای یک موجودیت (Candidate Key) ، می بایست یک کلید را به عنوان کلید اصلی انتخاب نمود . معیارهای مختلفی در این انتخاب دخیل هستند ، اما معمولا” بهترین کلیدی که معرف مفهوم و ماهیت موجودیت باشد به عنوان کلید اصلی انتخاب می گردد .

 

وابستگی تابعی (Functional Dependency)

 

وابستگی تابعی مفهومی است که مابین خصلت های یک موجودیت تعریف می گردد . به این معنی که می گوئیم خصلت A با خصلت B وابستگی تابعی دارد ، در صورتیکه به ازای هر مقدار مشخص از خصلت B بتوان مقدار مشخص و یکتائی از خصلت A را بدست آورد ، اما عکس آن ممکن است صادق نباشد . در موجودیت مشتری مثال قبل ، به ازای هر کد مشتری می توان نام او را بدست آورد در این صورت می گوئیم خصلت نام مشتری با خصلت کد مشتری وابستگی تابعی دارد . اما عکس آن صادق نیست چرا که به ازای یک نام مشتری مشخص ، نمی توان یک کد مشتری یکتا استخراج نمود (دو مشتری مختلف می توانند نام یکسان داشته باشند ، در این حالت یک نام مشتری ممکن است متناظر با دو و یا حتی چند کد مشتری باشد).

[FriendlyGhost 998]

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

 

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

 

- رابطه یک به یک (One To One) : در حالتی اتفاق می افتد که خصلت A وابستگی تابعی به خصلت B داشته باشد و خصلت B نیز وابستگی تابعی به خصلت A داشته باشد . در این حالت هر دو خصلت A و B کاندیدای کلید شدن می باشند.

 

- رابطه یک به چند (One To Many) : اگر خصلت A وابستگی تابعی به خصلت B داشته باشد و عکس آن صادق نباشد ، یک ارتباط از نوع یک به چند وجود خواهد داشت . در این حالت ، خصلت B کاندید کلید شدن است و خصلت A صرفا” یکی از توصیف گرهای موجودیت محسوب می گردد .

 

- رابطه چند به چند (Many To Many) : اگر دو خصلت هیچکدام وابستگی تابعی به یکدیگر نداشته باشند آنگاه رابطه بین آنها چند به چند خواهد بود . در این حالت هیچیکدام از آنها کاندید کلید شدن نبوده (ممکن است ترکیب آنها کاندید کلید شدن باشد) و صرفا” توصیف کننده موجودیت خواهند بود

هنجار سازی (Normalization)

 

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

نا بهنجاری

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

[FriendlyGhost 998]

Relation

موجودیت ها در مدل منطقی داده های سیستم مورد بحث و بررسی قرار می گیرند و پس از طی فرآیند هنجارسازی در مرحله فیزیکی به صورت ماتریسهای دوبعدی مشتمل بر سطرها (رخدادهای مختلف یک موجودیت) و ستون ها (خصلت های مختلف آن موجودیت) تعریف می گردند . هر یک از این ماتریس ها را یک ارتباط یا Relation می نامند که در مدل فیزیکی معمولا” آنها را با نام جدول (Table) معرفی می کنند . همانطور که پیش از این اشاره شد تمام خصلت های یک موجودیت با یکدیگر ارتباط منطقی داشته و معرف آن موجودیت می باشند ، از اینرو به این جداول ارتباط می گویند .

 

Tuple

 

هر یک از رخدادهای مختلف یک موجودیت را یک Tuple می گویند که در مدل فیزیکی معمولا” از آنها با نام ردیف (Row) و یا رکورد (Record) نام برده می شود . بنابراین Tuples ، ردیف های جدول دو بعدی هستند که آن را به عنوان Relation و یا Table می شناسیم .

Attribute

هریک از خصلت های مختلف یک موجودیت را Attribute می نامند ( نظیر کد مشتری ) . معمولا” در مدل فیزیکی به جای Attribute از فیلد (Field) و یا ستون (Column) استفاده می شود . بنابراین Attributes ، ستون های جدول دو بعدی هستند که آن را به عنوان Relation و یا Table می شناسیم .

 

شکل زیر یک Relation را به همراه اجزاء آن نشان می دهد :

 

 

یک Relation به همراه اجزاء آن

 

ارتباط (Relationship)

منظور ارتباط بین دو Relation و یا جدول است که بر اساس برابری فیلدهای یکسان در هر جدول تعریف و دارای انواع مختلفی است . ( به دلیل اهمیت و گستردگی ، در مقاله ای جداگانه تشریح خواهد شد) . این ارتباط ها در مدل منطقی مابین موجودیت ها (خصوصا” موجودیت های نرمال شده ) تعیین می گردند و به آن Entity Relation یا ER سیستم می گویند . مدل ER سیستم توسط ابزارهای مستند سازی جهت درک بهتر مدل داده ای سیستم ترسیم می گردد که به آنها ERD می گویند .

 

پس از تشریح برخی از مفاهیم اولیه و در عین حال مهم بانک های اطلاعاتی رابطه ای ، به اختصار می توان گفت که یک بانک اطلاعات رابطه ای مجموعه ای از رابطه ها (Relations) و یا جداول به همراه تمامی ارتباط هائی (Relationship) است که بین آنها وجود دارد . هر بانک اطلاعاتی در خصوص یک سیستم مورد نظر طراحی و ایجاد می گردد ، اما در برخی از سازمان های بزرگ که بین سیستم های مختلف آن ارتباط وجود دارد (نظیر سیستم پرسنلی ، حقوق و دستمزد و مالی و …) ممکن است بانک های اطلاعاتی با یکدیگر تجمیع و پس از طی فرآیند یکپارچه سازی به صورت یک بانک اطلاعاتی جامع و یکپارچه برای آن سازمان تعریف و ایجاد گردد .

امروزه سیستم های مدیریتی بانک های اطلاعاتی رابطه ای مختلفی وجود دارد که هر یک ویژگی ها و قابلیت هایی خاص خود را دارند . به این سیستم ها و یا نرم افزارها اختصارا” RDBMS گفته می شود . MS ACCESS ، MS SQL ، ORACLE ، SYBASE ، نمونه هائی متداول در این زمینه می باشند .

تمامی سیستم های مدیریت بانک های اطلاعاتی رابطه ای به منظور ارائه قابلیت های خود و استفاده از آنها از زبان مشترکی که به آن SQL ( برگرفته شده از Structured Query Language ) گفته می شود ، استفاده می نمایند . تمامی نیازها و انتظارات کاربران از بانک های اطلاعاتی نظیر جستجوی اطلاعات ، ایجاد ، تغییر و یا حذف اطلاعات حتی ایجاد بانک اطلاعاتی و یا سایر اجزاء مرتبط با آن توسط زبان فوق تعریف و تحویل RDBMS داده خواهد شد تا پس از بررسی بر روی بانک اعمال گردد.

[FriendlyGhost 998]

نرمال سازی ( Normalization ) يا به تعبيری هنجار سازی فرآيندی است در رابطه با بانك های اطلاعاتی كه با دو هدف عمده زير انجام می شود :

 

کاهش افزونگی اطلاعات ، به اين معنی که اطلاعات فقط در يک مكان (جدول) ذخيره و در تمام بانک با استفاده از روابط منطقی تعريف شده (RelationShip) قابل دسترسی باشد .

حفظ يکپارچگی اطلاعات ، به اين معنی که اعمال تغييرات بر روی اطلاعات ( نظير ايجاد ، بهنگام سازی و حذف ) در يك مكان انجام و به دنبال آن آثار تغييرات در تمام بانك مشاهده گردد . برای روشن شدن مفهوم يکپارچگی بد نيست به مثال ذيل توجه نمائيد :

فرض كنيد در يك بانك اطلاعاتی دارای دو موجوديت كتاب و نويسنده باشيم . هر يك از موجوديت های فوق دارای المان های اطلاعاتی (Attribute) مختص به خود می باشند . به عنوان نمونه موجوديت "كتاب" دارای المان اطلاعاتی نام نويسنده و موجوديت "نويسنده " دارای المان های اطلاعاتی متعددی نظير نام نويسنده ، آدرس نويسنده و ... باشد . در صورتی كه در موجوديت "کتاب" يک رخداد (رکورد) ايجاد نمائيم بدون اينکه نام نويسنده آن را در موجوديت "نويسنده" ايجاد کرده باشيم ، دچار يک ناهمگونی اطلاعات خواهيم شد .

با توجه به اهداف فوق می توان گفت كه فرآيند نرمال سازی از ناهنجاری های بوجود آمده به دليل بروز تغييرات در بانك جلوگيری خواهد نمود . با اعمال فرآيند نرمال سازی ، يك بانك اطلاعاتی كارآ و مطمئن را خواهيم داشت .

فرآيند نرمال سازی ، فرم های متفاوتی دارد كه انواع متداول آن به شرح ذيل است :

 

فرم اول نرمال سازی 1NF

 

فرم دوم نرمال سازی 2NF

 

فرم سوم نرمال سازی 3NF

 

فرم بويس کد نرمال سازی BCNF

 

فرم چهارم نرمال سازی 4NF

[FriendlyGhost 998]

فرم اول نرمال 1NF

 

موجوديت و يا جدولی در فرم اول نرمال است كه تمامی المان های اطلاعاتی آن ( منظور Attribute است )

 

يكتا و يا اصطلاحا" atomic باشند . برای روشن شدن اين موضوع فرض كنيد دارای موجوديتی با نام "فاكتور فروش " باشيم .

 

با مشاهده موجوديت فوق متوجه اين موضوع خواهيم شد كه المان های كالا ، تعداد كالا و قيمت واحد كالا بيش از يك مرتبه در موجوديت وجود داشته و اصطلاحا" يك گروه تكرار را تشكيل می دهند . برای اجرای مدل فيزيكی اين موجوديت ناچار خواهيم بود در طراحی جدول آرايه ای به طول ثابت ( به عنوان نمونه با ده عضو ) تعريف و در آن به ترتيب كالای 1 تا 10 را تعريف نمائيم .

 

مشکل : طراحی فوق ما را با دو مشکل عمده روبرو خواهد ساخت : اول اين كه کارائی بانک اطلاعاتی پائين خواهد آمد (اگر در آينده تعداد کالاهای فاکتور فروش بيش از 10 کالا باشد ، آنگاه مجبور خواهيم بود طراحی جدول مربوطه و متعاقب آن نرم افزارهائی که از آن استفاده می كنند را تغيير دهيم ) و مشکل دوم اين كه بسياري از فاکتورها لزوما" دارای 10 کالا نيستند و بنابراين محتوی بسياری از فيلدها در جدول فوق خالی (داراي ارزش Null) خواهد ماند و حجم زيادی از فضای ديسک هدر خواهد رفت .

 

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

مجددا" به موجوديت "فاكتور فروش " مثال قبل پس از تبديل به فرم اول نرمال توجه نمائيد :

 

 

به طور خلاصه می توان گفت كه هدف از فرم اول نرم سازی حذف گروه های تكرار و آرايه ها از موجوديت يا جدول است . فرآيند فوق ، می بايست بر روی تمامی موجوديت های بانك اطلاعاتی اعمال گردد تا بتوان گفت بانك اطلاعاتی نرمال شده در فرم اول است .

[FriendlyGhost 998]

فرم دوم نرمال 2NF

موجوديتی در فرم دوم نرمال است که اولا" در فرم اول نرمال باشد و ثانيا" تمامی آيتم های (Attribute) غير کليدی آن وابستگی تابعی به تمام کليد اصلی‌ موجوديت داشته باشند نه به بخشی از آن .همانگونه كه از تعريف فوق استنباط می گردد ، فرم دوم نرمال سازی در خصوص موجوديت هائی بررسی و اعمال می شود كه دارای كليد اصلی مركب هستند ( بيش از يك جزء ) . بنابراين در مثال فوق موجوديت "فاكتور فروش " به خودی خود در فرم دوم نرمال است ولی موجوديت "رديف های فاكتور فروش " كه دارای كليد اصلی مركب است ، نياز به بررسی دارد .

 

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

 

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

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

 

[FriendlyGhost 998]

فرم سوم نرمال 3NF

موجوديت و يا جدولی در فرم سوم نرمال است که اولا" در فرم دوم نرمال بوده و ثانيا" تمام آيتم های غير کليد آن وابستگی تابعی به کليد اصلی داشته باشند ، نه به يک آيتم غير کليد .

 

مشکل : در صورتی كه موجوديتی در فرم سوم نرمال نباشد ، آنگاه با تغيير آيتم يا آيتم های اطلاعاتی غير وابسته به کليد اصلی در يک رکورد، تغييرات در ساير رکوردها اعمال نخواهد شد و دچار دوگانگی اطلاعات خواهيم شد (مثلا" يک مشتري با دو نام متفاوت) .

راه حل : کافی است آيتم های غير کليدی به هم وابسته را به موجوديت جديدی منتقل و کليد اصلی موجوديت جديد را تعيين نمائيم ، آنگاه کليد اصلی موجوديت جديد را در موجوديت نرمال شده به عنوان يک کليد خارجی (Foreign Key) در نظر گرفت . در موجوديت "فاکتور فروش" مثال فوق آيتم نام مشتری وابستگی تابعی به آيتم کد مشتری دارد که خود يک آيتم غير کليد است بنابر اين بايد نرمال سازی فرم سوم در خصوص آن اعمال شود . شکل ذيل نحوه انجام اين كار را نشان می دهد :

[FriendlyGhost 998]

فرم بويس کد نرمال BCNF

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

 

فرم چهارم نرمال 4NF

اين فرم در خصوص موجوديت هائی است که ارتباط بين المان های آن يک ارتباط چند ارزشه و يا چند به چند باشد . به عنوان مثال ، موجوديت کلاس درس می تواند شامل چندين دانش آموز و چندين معلم باشد. در چنين مواردی ارتباط بين معلم و دانش آموز يک ارتباط چند به چند می باشد . در اين حالت با ايجاد يك موجوديت رابط مابين موجوديت های مذكور، مشکل ارتباط چند به چند حل خواهد شد (بسياری از سيستم های مديريت بانک های رابطه ای نظير MSSQL از رابطه چند به چند پشتيبانی نمی نمايند ، يعنی نمی توان بين دو جدول يک رابطه چند به چند ايجاد نمود). معمولا" تمام المان های موجوديت رابط ايجاد شده بخشی از كليد اصلی است .

[FriendlyGhost 998]

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

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

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

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

 

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

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

[FriendlyGhost 998]

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

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

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

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

"کارمند شاغل است در دپارتمان" در اين مثال ارتباط بين موجوديت کارمند و دپارتمان با جمله "شاغل است" توصيف ميگردد .

دو نوع ارتباط می تواند بين موجوديت ها وجود داشته باشد :

 

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

[FriendlyGhost 998]

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

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

 

 

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

 

 

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

mandatory non-identifying relationship ، زمانی است که خصلت کليد خارجی در موجوديت فرزند نتواند فاقد ارزش باشد (Not Allow NULL)

non-mandatory non-identifying relationship ، زمانی است که خصلت کليد خارجی در موجوديت فرزند بتواند فاقد ارزش باشد (Allow NULL)

[FriendlyGhost 998]

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

" چه تعداد رخداد از موجوديت فرزند مرتبط است با هر رخداد از موجوديت والد؟ "

چهار نوع Cardinality مختلف به شرح ذيل وجود دارد :

 

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

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

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

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