بانک های اطلاعاتی رابطه ای : مفاهیم و تعاری

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

*

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

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

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

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

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

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

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

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

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

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

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

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

*

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

پس از تشریح برخی از مفاهیم اولیه و در عین حال مهم بانک های اطلاعاتی رابطه ای ، به اختصار می توان گفت که یک بانک اطلاعات رابطه ای مجموعه ای از رابطه ها (Relations) و یا جداول به همراه تمامی ارتباط هائی (Relationship) است که بین آنها وجود دارد . هر بانک اطلاعاتی در خصوص یک سیستم مورد نظر طراحی و ایجاد می گردد ، اما در برخی از سازمان های بزرگ که بین سیستم های مختلف آن ارتباط وجود دارد (نظیر سیستم پرسنلی ، حقوق و دستمزد و مالی و ...) ممکن است بانک های اطلاعاتی با یکدیگر تجمیع و پس از طی فرآیند یکپارچه سازی به صورت یک بانک اطلاعاتی جامع و یکپارچه برای آن سازمان تعریف و ایجاد گردد .
امروزه سیستم های مدیریتی بانک های اطلاعاتی رابطه ای مختلفی وجود دارد که هر یک ویژگی ها و قابلیت هایی خاص خود را دارند . به این سیستم ها و یا نرم افزارها اختصارا" RDBMS گفته می شود . MS ACCESS ، MS SQL ، ORACLE ، SYBASE ، نمونه هائی متداول در این زمینه می باشند .
تمامی سیستم های مدیریت بانک های اطلاعاتی رابطه ای به منظور ارائه قابلیت های خود و استفاده از آنها از زبان مشترکی که به آن SQL ( برگرفته شده از Structured Query Language ) گفته می شود ، استفاده می نمایند . تمامی نیازها و انتظارات کاربران از بانک های اطلاعاتی نظیر جستجوی اطلاعات ، ایجاد ، تغییر و یا حذف اطلاعات حتی ایجاد بانک اطلاعاتی و یا سایر اجزاء مرتبط با آن توسط زبان فوق تعریف و تحویل RDBMS داده خواهد شد تا پس از بررسی بر روی بانک اعمال گردد.