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

[MAHDIAR]

بانک های اطلاعاتی رابطه ای : مفاهيم و تعاريفقبل از پرداختن به موضوع بانک های اطلاعاتی رابطه ای (Relational Data Base) ، بهتر است اشاره ای به مفاهيم ذيل داشته باشيم :
<LI dir=rtl>موجوديت (Entity)
بههر چيزی (شی ، شخص ، محل و ...) که می خواهيم در يک سيستم راجع به آن اطلاعاتی را جمع آوری ، پردازش و نگهداری نمائيم ، يک موجوديت گفته می شود . تعريف فوق ، متداولترين برداشت اوليه از موجوديت می باشد . مجموعه موجوديت های يک سيستم ، ساختار اطلاعاتی آن سيستم را مشخص می كند . هر موجوديت شامل اجزاء و المان هائی است که آن موجوديت را توصيف می كند كه به آنها خصيصه و يا Attribute گفته می شود . هر موجوديت بسته به اين كه در سيستم مورد مطالعه چه ميزان اطلاعات راجع به آن می خواهيم داشته باشيم ، شامل حداقل يک و يا چند خصيصه خواهد بود. از آنجا که هر موجوديت راجع به يک موضوع به خصوص می باشد ، بنابراين يک ارتباط منطقی بين کليه خصايص موجوديت وجود خواهد داشت .در واقع ،‌ تمام خصائص يک موجوديت توصيف کننده آن موجوديت خواهد بود . برای روشن شدن موضوع بد نيست به نمونه مثال ذيل توجه نمائيد :
- موجوديت مشتری شامل خصلت های نام مشتری ، آدرس مشتری ، تلفن مشتری و ... است .
- موجوديت سفارش شامل خصلت های شماره سفارش ، تاريخ سفارش ، نام مشتری ، کالای سفارش شده ، تعداد کالای سفارش شده و ... است
همانگونه که در مثال فوق مشاهده گرديد ، تمام خصلت های موجوديت مشتری توصيف کننده يک مشتری و تمام خصلت های موجوديت سفارش توصيف کننده يک سفارش می باشند .
کليد (Key)
هر رخداد از يک موجوديت را بايد بتوان به وسيله يک و يا ترکيبی از چند خصيصه آن به صورت يکتا شناسائی نمود . به تعبير ديگر ، هر يک از رخدادهای يک موجوديت بايد يکتا باشد ، در غير اينصورت تغيير و يا حذف يک رخداد از موجوديت (در مثال فوق يک مشتری) غير ممکن خواهد بود . از اينرو از بين خصلت های يک موجوديت يک و يا ترکيبی از چند خصيصه به عنوان کليد آن موجوديت انتخاب می شود . اين خصلت (و يا ترکيب خصلت ها) بايد بتواند يکتائی هر رخداد از موجوديت را تضمين نمايد . در موجوديت سفارش مثال فوق ، خصلت شماره سفارش می تواند بعنوان کليد انتخاب شود .
توضيح : در برخی از موارد در يک موجوديت چندين کليد وجود دارد كه به هر يک از آنها يک Candidate Key يا Alternate Key گفته می شود .
در برخی از حالات نمی توان در يک موجوديت هيچ کانديدی براي کليد يافت ، مانند موجوديت مشتری در مثال فوق . در اين موجوديت هيچيك از خصلت ها و يا هيچ ترکيبی از آنها نمی تواند صد درصد تضمين کننده يکتائی آن باشد (با اينکه احتمال وجود دو مشتری هم نام در يک آدرس و با يک شماره تلفن بسيار کم است ، اما باز هم احتمال وقوع دارد) . در چنين مواردی مجبور هستيم يک خصلت به موجوديت اضافه کنيم تا تضمين کننده يکتائی رخدادهای آن باشد . در مثال فوق با اضافه کردن خصلت کد مشتری به موجوديت مشتری ، می توان يکتائی آن را تضمين نمود . به اين نکته دقت شود که بسياری از خصلت های يک موجوديت در کنترل سيستم نيست و از خارج به سيستم تحميل می گردد . به عنوان مثال ما نمی توانيم تعيين کنيم که نام مشتری های سازمان تکراری نباشد . اما عدم تکراری بودن خصلت هائی که خود ما ايجاد نموده ايم را می توان تضمين کرد ( نظير کد مشتری که توسط سيستم و يا سازمان مربوطه توليد می شود ) .

[MAHDIAR]

<LI dir=rtl>کليد اصلی (Primary Key)
از بين کليدهای يک موجوديت (Candidate Key) ، می بايست يک کليد را به عنوان کليد اصلی انتخاب نمود . معيارهای مختلفی در اين انتخاب دخيل هستند ، اما معمولا" بهترين کليدی که معرف مفهوم و ماهيت موجوديت باشد به عنوان کليد اصلی انتخاب می گردد .
<LI dir=rtl>وابستگی تابعی (Functional Dependency)
وابستگی تابعی مفهومی است که مابين خصلت های يک موجوديت تعريف می گردد . به اين معني که می گوئيم خصلت A با خصلت B وابستگی تابعی دارد ، در صورتيکه به ازای هر مقدار مشخص از خصلت B بتوان مقدار مشخص و يکتائی از خصلت A را بدست آورد ، اما عکس آن ممکن است صادق نباشد . در موجوديت مشتری مثال قبل ، به ازای هر کد مشتری می توان نام او را بدست آورد در اين صورت می گوئيم خصلت نام مشتری با خصلت کد مشتری وابستگی تابعی دارد . اما عکس آن صادق نيست چرا که به ازای يک نام مشتری مشخص ، نمی توان يک کد مشتری يکتا استخراج نمود (دو مشتری مختلف می توانند نام يکسان داشته باشند ، در اين حالت يک نام مشتری ممکن است متناظر با دو و يا حتی چند کد مشتری باشد).
<LI dir=rtl>انواع رابطه بين خصلت های يک موجوديت
بين خصلت های يک موجوديت سه نوع رابطه وجود دارد :
- رابطه يک به يک (One To One) : در حالتی اتفاق می افتد که خصلت A وابستگی تابعی به خصلت B داشته باشد و خصلت B نيز وابستگی تابعی به خصلت A داشته باشد . در اين حالت هر دو خصلت A و B کانديدای کليد شدن می باشند.
- رابطه يک به چند (One To Many) : اگر خصلت A وابستگی تابعی به خصلت B داشته باشد و عکس آن صادق نباشد ، يك ارتباط از نوع يک به چند وجود خواهد داشت . در اين حالت ، خصلت B کانديد کليد شدن است و خصلت A صرفا" يکی از توصيف گرهای موجوديت محسوب می گردد .
- رابطه چند به چند (Many To Many) : اگر دو خصلت هيچکدام وابستگی تابعی به يکديگر نداشته باشند آنگاه رابطه بين آنها چند به چند خواهد بود . در اين حالت هيچيکدام از آنها کانديد کليد شدن نبوده (ممکن است ترکيب آنها کانديد کليد شدن باشد) و صرفا" توصيف کننده موجوديت خواهند بود .
<LI dir=rtl>هنجار سازی (Normalization)
هنجار سازی ، فرآيندی است كه طی آن يك موجوديت جهت به حداقل رسانی نابهنجاری های بوجود آمده در خلال تغييرات اعمال شده بر روی رخدادهاي يک موجوديت مورد بررسی و تبديل قرار می گيرد. اگر اين فرآیند به طور صحيح بر روی يک موجوديت اعمال نگردد ، آنگاه نمی توان هيچ تضمينی در خصوص حفظ يکپارچگی اطلاعات آن موجوديت ارائه داد . فرآيند هنجار سازی به دليل اهميت و گستردگی آن در مقاله ای جداگانه تشريح خواهد شد.
<LI dir=rtl>نا بهنجاری
به پيامدهای ناخواسته تغيير اطلاعات نابهنجاری گفته می شود .
<LI dir=rtl>Relation
موجوديت ها در مدل منطقی داده های سيستم مورد بحث و بررسی قرار می گيرند و پس از طی فرآيند هنجارسازی در مرحله فيزيکی به صورت ماتريسهای دوبعدی مشتمل بر سطرها (رخدادهاي مختلف يک موجوديت) و ستون ها (خصلت های مختلف آن موجوديت) تعريف می گردند . هر يک از اين ماتريس ها را يک ارتباط يا Relation می نامند که در مدل فيزيکی معمولا" آنها را با نام جدول (Table) معرفی می کنند . همانطور که پيش از اين اشاره شد تمام خصلت های يک موجوديت با يکديگر ارتباط منطقی داشته و معرف آن موجوديت می باشند ، از اينرو به اين جداول ارتباط می گويند .
<LI dir=rtl>Tuple
هر يک از رخدادهای مختلف يک موجوديت را يک Tuple می گويند که در مدل فيزيکی معمولا" از آنها با نام رديف (Row) و يا رکورد (Record) نام برده می شود . بنابراين Tuples ، رديف های جدول دو بعدی هستند که آن را به عنوان Relation و يا Table می شناسيم .
<LI dir=rtl>Attribute
هريک از خصلت های مختلف يک موجوديت را Attribute می نامند ( نظير کد مشتری ) . معمولا" در مدل فيزيکی به جای Attribute از فيلد (Field) و يا ستون (Column) استفاده می شود . بنابراين Attributes ، ستون های جدول دو بعدی هستند که آن را به عنوان Relation و يا Table می شناسيم .
شكل زير يك Relation را به همراه اجزاء آن نشان می دهد :

http://srco.ir/Articles/images/introRDB.jpg
يك Relation به همراه اجزاء آن

[MAHDIAR]

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