آذر ۱۸۱۳۹۳
 

جلسه ۱الی ۵

جلسه ۶

جلسه ۷

جلسه ۸

جلسه ۹

جلسه ۱۰

جلسه ۱۱

جلسه ۱۲

جلسه ۱۳

پایگاه حضوری ۱۷ دی

جلسه ۱۵

 باتشکر از زحمات , سرکار خانم مهندس ایلناز راست خدیو و جناب آقای مهندس مهران غنی زاده

خرداد ۱۶۱۳۹۳
 

 

ﻭﺍﺑﺴﺘﮕﻲ ﻭ ﻧﺮﻣﺎﻝ ﺳﺎﺯﻱ

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

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

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

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

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

  • فرم اول نرمال سازی ۱NF

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

  • فرم سوم نرمال سازی ۳NF

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

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

فرم اول نرمال  ۱NF
موجودیت و یا جدولی در فرم اول نرمال است که تمامی المان های اطلاعاتی آن ( منظور Attribute است ) یکتا و یا اصطلاحا”atomic باشند . برای روشن شدن این موضوع فرض کنید دارای موجودیتی با نام “فاکتور فروش ” باشیم . 

فاکتور فروش

شماره فاکتور(کلید اصلی)
تاریخ فاکتور
کد مشتری
نام مشتری
کالای ۱
تعداد کالای ۱
قیمت واحد کالای ۱
.
.
.
کالای n
تعداد کالای n
قیمت واحد کالای n

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

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

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

ردیف های فاکتور فروش



ارتباط بین موجودیت پدر و فرزند بر اساس کلید اصلی موجودیت پدر
(فاکتور فروش)
فاکتور فروش
شماره فاکتور(قسمت اول کلید اصلی)
کالا (قسمت دوم کلید اصلی)
تعداد
قیمت واحد
شماره فاکتور(کلید اصلی)
تاریخ فاکتور
کد مشتری
نام مشتری

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

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

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

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

ردیف های فاکتور فروش



ارتباط بین موجودیت پدر و فرزند بر اساس کلید اصلی موجودیت پدر (فاکتور فروش)
فاکتور فروش
شماره فاکتور(قسمت اول کلید اصلی)
کالا (قسمت دوم کلید اصلی)
تعداد
شماره فاکتور(کلید اصلی)
تاریخ فاکتور
کد مشتری
نام مشتری
ارتباط بین موجودیت پدر و فرزند بر اساس کلید اصلی موجودیت پدر (کالا)
کالا
کالا (کلید اصلی)
قیمت واحد

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

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

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

ردیف های فاکتور فروش



ارتباط بین موجودیت پدر و فرزند بر اساس کلید اصلی موجودیت پدر (فاکتور فروش)
فاکتور فروش
شماره فاکتور(قسمت اول کلید اصلی)
کالا (قسمت دوم کلید اصلی)
تعداد
شماره فاکتور(کلید اصلی)
تاریخ فاکتور
کد مشتری (کلید خارجی)
ارتباط بین موجودیت پدر و فرزند بر اساس کلید اصلی موجودیت پدر (کالا) ارتباط بین موجودیت پدر
( مشتری ) و فرزند بر اساس کلید خارجی 
کالا مشتری
کالا (کلید اصلی)
قیمت واحد
کدمشتری (کلید اصلی)
نام مشتری

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

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

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

———————–

normalsazi

———————–

*جدول آنرمال

اگر در جدولی مانند جدول زیر به ازای هر شماره دانشجویی و نام دانشجو ؛ بجای یک شماره تلفن ، چند شماره تلفن وجود داشته باشد جدول آنرمال است.(یعنی اگر شماره ۷۸۰۱ ؛ مورد جستجو قرار گرفت ، دانشجوی آرش با ۲ شماره تلفن بدست می آید؛ در صورتی که باید یکی از دو حالت زیر رخ دهد:

۱: نتیجه جستجو یک رکورد باشد که در آن نام آرش با یک شماره تلفن بدست بیاید

۲: نتیجه جستجو۲  رکورد متفاوت باشد که در اولی نام آرش با شماره تلفن اول و در رکورد دوم نام آرش با شماره تلفن دوم بیاید   )

تلفن

نام دانشجو

شماره داشجویی

۶۲۶۲۷۷۸-۰۳۱۱

۰۹۱۳۳۱۱۵۲۳۴

آرش

جدول آنرمال۷۸۰۱

۲۹۵۶۶۷۷-۰۲۱

۰۹۱۲۳۱۴۴۵۳۲

علی

۷۸۰۲

*نرمال سازی سطح ۱

جدولی نرمال سطح ۱ است که در برخورد هر سطر با ستون به یک مقدار تجزیه ناپدیر برسیم

مثلا در جدول بالا در سطر اول (آرش    ۷۸۰۱) و ستون سوم (تلفن) به ۲ شماره دست می یابیم (بخشی که با قرمز پر رنگ مشخص شده) ؛ پس برای تبدیل جدول به نرمال سطح ۱ آن را بصورت زیر در می آوریم

تلفن

نام دانشجو

شماره داشجویی

۶۲۶۲۷۷۸-۰۳۱۱

آرش

نرمال سطح ۱ ۷۸۰۱

۰۹۱۳۳۱۱۵۲۳۴

آرش

۷۸۰۱

۲۹۵۶۶۷۷-۰۲۱

علی

۷۸۰۲

۰۹۱۲۳۱۴۴۵۳۲

علی

۷۸۰۲

تعریف نرمال سطح ۱ : زمانی یک جدول نرمال سطح ۱ است که در برخورد هر سطر با هر ستون فقط و فقط به یک مقدار واحد و نجزیه ناپذیر برسیم (مثلا در برخورد سطر اول با ستون تلفن فقط به یک شماره تلفن می رسیم ؛ و همین طور برای سطرهای بعدی )

نرمال سطح ۲ (زمانی برای یک جدول نرمال سازی سطح ۲و ۳و… انجام می دهیم که کلید اصلی آن چند بخشی باشد یعنی چند فیلد باهم کلید اصلی باشند)

مثال : جدول زیر نرمال سطح ۱ بوده ولی نرمال سطح ۲ نیست//« علامت #  یعنی کلید»

چون اگر بخواهیم دانشجوی علی با شماره ۷۸۰۱ را از جدول حذف کنیم ؛ اطلاعات درس ریاضی هم ناخواسته حذف می شود و اگر دانشجوی جدیدی ثبت نام کند که هنوز هیچ درسی را نگرفته ؛ نمی توان فیلد شماره درس که جزیی از کلید است را خالی رها کرد.

#ترم

نمره گرفته شده

واحد درس

نام درس

#شماره درس

نام

#شماره دانشجویی

۲

۲۰

۳

پایگاه داده

۱۴۰۰

علی

۷۸۰۱

۱

۱۰

۳

ریاضی ۱

۱۵۰۰

علی

۷۸۰۱

۱

۲۰

۳

تجزیه و تحلیل

۱۶۰۰

علی

۷۸۰۱

۱

۷

۳

پایگاه داده

۱۴۰۰

آرش

۷۹۰۲

۱

۲۰

۱

تربیت بدنی

۱۷۰۰

آرش

۷۹۰۲

 یک جدول نرمال سطح ۲ است اگر:

۱-     نرمال یک باشد

۲-     در آن جدول هیچ وابستگی جزیی به کلید اصلی وجود نداشته باشد(هیچ یک از ویژگی های جدول تنها به قسمتی از کلید اصلی وابستگی نداشته باشد) یعنی جستجوی مقداری در جدول به کلیه فیلدهایی که کلید هستند وابستگی داشته باشد.

۳-      (وابستگی جزیی : حالتی است که بدست آوردن مقداری در جدول به قسمتی از کلید «نه کل کلید» وابستگی دارد ؛ حالت زیر:

#ترم

نمره گرفته شده

واحد درس

نام درس

#شماره درس

نام

#شماره دانشجویی

۲

۲۰

۳

پایگاه داده

۱۴۰۰

علی

۷۸۰۱

۱

۱۰

۳

ریاضی ۱

۱۵۰۰

علی

۷۸۰۱

۱

۲۰

۳

تجزیه و تحلیل

۱۶۰۰

علی

۷۸۰۱

۱

۷

۳

پایگاه داده

۱۴۰۰

آرش

۷۹۰۲

۱

۲۰

۱

تربیت بدنی

۱۷۰۰

آرش

۷۹۰۲

بدست آوردن نام درس فقط به فیلد شماره درس که قسمتی از کلید است وابستگی دارد چون اگر شماره درسی را داشته باشیم میتوان نام آن را بدست آورد و به چیز دیگری نیاز نیست .

)

تبدیل به نرمال سطح۲ : ص ۲۱۰ کتاب اصول و طراحی پایگاه داده ها ؛ تالین ساهاکیان

نرمال سازی سطح۳ :

جدولی نرمال سطح ۳ است که :

۱-     نرمال سطح۲ باشد.

۲-     در آن جدول ؛ ویژگی هایی که کلید نیستند به هم وابستگی تابعی نداشته باشند

یعنی اگر جدولی نرمال سطح۲ بود و  ویژگی های غیر کلیدی آن ؛ به هم وابستگی نداشتند، آن جدول نرمال سطح ۳ است.

تبدیل به نرمال سطح ۳ و مثال : ص ۲۱۳ کتاب اصول و طراحی پایگاه داده ها

dr-shiri-example-test-1

اردیبهشت ۲۹۱۳۹۳
 

خلاصه درس پایگاه داده پیشرفته – دکتر شیری ۹۳/۰۲/۲۹
انواع بن بست
بن بست حالتی است که دو یا بیش از دو تراکنش هر کدام منتظر پایان دیگریست

دو راه حل برای بن بست وجود دارد
۱- روشهای کشف بن بست
۲- روشهای جلوگیری از بن بست

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

۲- استفاده از مهر زمانی برای حل مشکل بن بست

مهر زمانی مقدار منحصر به فردی است که سیستم برای هر تراکنش در نظر می گیرد که می تواند ترکیبی از ID و زمان شروع تراکنش باشد

هر زمانی تراکنش Ti را با Ts(Ti) نشان می دهیم

دو الگوریتم در این رابطه مطرح می کنیم

۱- الگوریتم منتظر گذاشتن و پس راندن :
اگر Ts(Ti)<Ts(Tj) و Ti خواهان قفل کردن داده ای Tj ۀنرا قفل کرده و منتظر می ماند که کار Tj تمام شود . در غیر اینصورت طرد می شود

 

2- الگوریتم زخمی کردن و منتظر گذاشتن :
اگر Ts(Ti)<Ts(Tj) و Ti خواهان قفل کردن داده ای است که Tj قفل کرده ، Ti زخمی می شود ( طرد می شود ) و داده از آن گرفته می شود و در اختیار Ti قرار می گیرد . در غیر اینصورت باید منتظر بماند

۳- عدم انتظار :
اگر ترامنشی ، داده مورد نیاز خود را نتواند قفل کند ، بدون درنگ ( بدون انتظار ) طرد می شود

۴- انتظار محتاطانه :
اگر تراکنش Ti خواهان قفل کردن داده ای است که Tj آنرا قفل کرده اگر Tj خود منتظر باز شده قفلی داده ای نباشد Ti منتظر می ماند ، در غیر اینصورت طرد می شود
————————————–
روشهای کشف مشکل بن بست

این روش های خوشبینانه هستند
فرض می کنند بن بست به ندرت رخ میدهد و اجازه می دهند تراکنش ها آزادانه اعمال خود را انجام دهند و اگر احساس کردند که لن بست رخ داده آنرا کشف و برطرف می کنند

۱- مهلت زمانی :
سیستم یک مهلت زمانی تعیین می کند و اگر تراکنش نتوانست در این مهلت زمانی به داده مورد نظر خود را قفل کند ، طرد می شود

۲- بررسی متناوب درخواست های قفل گذاری
در این روش سیستم به منظور کشف بن بست به طور متناوب درخواستهای قفل گذاری تراکنش ها را بررسی می کند
این کار را با رسم گراف انتظار انجام میدهد

گراف انتظار یک گراف جهت دار است که رئوس آن تراکنش ها هستند و یال جهت دار Ti–>Tj در این گراف وجود دارد .
اگر Ti خواهان قفل داده ای باشد که Tj قفل کرده باشد

اگر در این سیکل یا دور وجود داشته باشد یعنی بن بست رخ داده و سیستم باید بن بست را رفع کند (با طرد بعضی از تراکنش ها )

——————————-
سیاست های مختلفی برای طرد تراکنش هست
- تراکنشی که کمترین کار را انجام داده، طرد شود
- تراکنشی که زمان بیشتری تا پایان آن مانده، طرد شود
- تراکنشی که باعت loop شده
- تراکنشی که بیشترین داده را قفل کرده

——————
روش مهر زمانی
برای کنترل همروندی
در این روش غیر از مهر زمانی تراکنش ها که با Ts (T) نشان میدهیم برای هر فقره داده مانند D دو نوع مهر زمانی داریم

مهر زمانی خواندن Ts-r (D) که برابر است با بزرگترین مهر زمانی تراکنش ها مه داده D را خواندن

مهر زمانی نوشتن : Ts-W(D) برابر است با بزرگترین مهر زمانی که تراکنش هایی که داده D را تغییر داده یا نوشته
پروتکل To
1- در عمل خواندن ، تراکنش Ti دستور R(D) صادر می کند آنگاه

الف ) اگر زمان مهر این تراکنش کوچکتز ار زمان مهر نوشتن داده D بود
Ts(Ti)>Ts-W(D) درخواست رد می شود و تراکنش طرد می شود
ب) در غیر اینصورت درخواست به سایت می شود
Ts-R(D)=Max{Ts-R(D),Ts(Ti){

2- در عمل نوشتن ترانش Ti دستور W(D) را صادر می کند
در این حالت
الف ) Ts(Ti)<Ts-RD) درخواست رد می شود و تراکنش طرد می شود
ب) اگر Ts(Ti)<Ts-W(D) درخواست رد می شود و تراکنش طرد می شود چون نتیجه از دست رفته رخ میدند
ج) در غیر اینصورت درخواست اجابت می شود و قرار میدهیم

Ts-W(D)=Max {Ts-W(D), Ts(Ti)}
کتاب روحانی رانکوهی جلد دوم سیستم های مدیریت پایگاه داده ، یا حق جو – جلد دوم ، یا دیت – جلد دوم را بخوانید
سوال در این روش کدام یک از مشکلاتی ک مطرح شد رخ می دهد
۱- تضعیف همروندی
۲- طرد تسلسلی
۳- مشکل بن بست
۴- مشکل گرسنگی یا قحطی زدگی

۵- آیا این روش همروندی را تضمین می کند ؟
پروتکل مهر زمانی نوع دوم برای همروندی
یک زمان مهر ساختگی برای تراکنش با کمی اختلاف ایجاد کنیم
در اینصورت ممکن است خیلی از طرد شدن ها برطرف شود مشکل این اختلاف چقدر بگیریم
پروتکل مهر زمانی شدید برای همروندی
در عمل نوشتن دیدیم که اگر Ts(Ti)>Ts-R(D) عمل توشتن اجرا می شود
در این پروتکل این اجازه را وقتی می دهد که تراکنش داده را خوانده به ترتیب برسد

اردیبهشت ۲۲۱۳۹۳
 

خلاصه درس پایگاه داده پیشرفته – دکتر شیری ۹۳/۰۲/۲۲

۲pl قفل گذاری دو مرحله ای

تضعیف همروندی : کند شدن همروندی
طرد تسلسلی
مشکل بن بست : دو یا چند تراکنش منتظر پایان یافتن تراکنش دیگری است
قحطی زدگی ( گرسنگی )

۲pl محافظه کار
صفحه ۱۰ – قفل های انحصاری

————————–
۲pl جسورانه :
قفل کردن داده ها را در لحظه نیاز انجام می دهد

تضعیف همروندی نداریم
طرد تسلسلی داریم
بن بست هم داریم
قحطی زدگی هم دچار می شود
————————–
۲pl دقیق
قفل گشایی کلیه قفل ها هم انحصاری و هم اشتراکی را در لحظه پایانی انجام می دهد

تضعیف همروندی +
طرد تسلسلی -
بن بست +
قحطی زدگی +
————————–

کلاس جبرانی : چهارشنبه کلاس حضوری ساعت ۳:۳۰ تا ۵:۳۰

———————-
همروندی – قسمت دوم

مشکل بن بست در ۲pl ها پیش می آمد

پیش بینی و اجتناب

روش خوشبینانه

—————–
برای هر تراکنش به مهر زمانی اختصاص می دهیم time stamp

مهر زمانی می تواند ترکیبی از چند چیز باشد
۱- ID تراکنش
۲- زمان شروع تراکنش
….
بنابراین هر time stamp منحصر به فرد است

بر اساس این مهر زمانی می توانیم نظمی ایجاد کنیم که بر اساس این نظم تراکنش ها همل کنند تا مشکل بن بست رخ ندهد

 

اردیبهشت ۱۵۱۳۹۳
 

همروندی :
اگر تراکنش ها به صورت متوالی انجام شوند
در سیستم چند کاربره بایستی بصورت همروند انجام شود
که باید کنترل شود
مشکلات همروندی :
۱- نتیجه از دست رفته
۲- خواندن داده ناجور
۳- تحلیل ناسازگار

استفاده از تکنیک قفل کردن
قفل : امتیازی است برای دستیابی به
اندازه واحد داده قفل شدنی باید متفاوت باشد تا تراکنش ها بر اساس
نیازشان داده را قفل کنند
انواع قفل :
۱- قفل دوگانه Binary
2- قفل چندگانه

هر تراکنش می تواند داده را Lock و یا UnLock کند
نکته : قفل دوگانه بسیار محدود کننده است

قفل چندگانه :

۱- قفل خواندن (اشتراکی) : تراکش ها همزمان می توانند داده ها را
بخوانند
۲- قفل نوشتن (انحصاری ) : برای تغییر یا نوشتن داده لازم است
ایا قفل چند گانه همروندی را تضمین می کند ؟
خیر تضمین نمی کند ، در واقع همان سه مشکلی که مطرح کردیم پیش
می آید

قفل دو مرحله ای پایه :
انواع قفل دو مرحله ای
۱- ۲pl محافظه کار
۲- ۲pl جسورانه ( تا زمانی که به داده نیاز ندارد قفل نمی کند )
ولی ۴ مشکل دیگر مطرح می شود
۱- تضعیف همروندی
۲- بن بست
۳- طرد تسلسلی
۴- گرسنگی یا قحطی زدگی

 

 

فروردین ۱۶۱۳۹۳
 

تاریخ تحویل : ۳۰ فروردین

 

 

 

adb-ex1-1

 

جواب این سه مساله را می توان در منابع زیر یافت :

http://www.codeproject.com/Articles/673293/Calculate-exponential-function-with-Taylor-series

http://stackoverflow.com/questions/124417/is-there-a-max-function-in-sql-server-that-takes-two-values-like-math-max-in-ne

http://www.sqlservercentral.com/Forums/Topic1231697-392-1.aspx

 

adb-ex1-2

adb-tamrin-mis1

 

 

 

adb-ex1-3

جواب : در روش دوم تعداد پرسنل حتی اگر واحدی برایشان تعریف نشده باشد را نمایش میدهد

ولی در روش اول نام تمام واحد ها نمایش داده می شود حتی اگر پرسنلی  برای آن واحد ها وجود نداشته باشد

هر دو جدول بدست آمده از هردو روش دارای ۳ ستون است

ستون اول در روش اول نام واحد ها را نمایش می دهد مرتب شده بر اساس نام واحد ولی در روش دوم بر اساس پرسنل نام واحد ها را نمایش می دهدکه مرتب شده بر اساس اولین فیلد که نام واحد هست و بر اساس شماره واحد گروه بندی شده است

 

ستون دوم تعداد پرسنل که در روش اول بر اساس واحد ها از جدول پرسنل بدست می آید ولی در روش دوم تعداد تمام رکورد ها که از جدول پرسنل گروه بندی شده بر اساس unitid هست نمایش داده میشود

ستون سوم تعداد فرزندان پرسنل آن واحد هست که در روش اول از جدول child  بر اساس پرسنل که unitid انها با unitid واحد ها برابر است ولی در روش دوم تعداد child که unidid در جدول پرسنل شمارش می شوند

adb-tamrin-mis23

تاریخ تحویل ۱۶ اردیبهشت

adb-ex2

 

 

اسفند ۱۲۱۳۹۲
 

 

فصل اول:

مفاهیم پایگاه داده

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

تعاریف اولیه:

سیستم‌ ذخیره و بازیابی اطلاعات:

هر سیستمی که به کاربر عادی یا برنامه نویس امکان دهد تا اطلاعات خود را ذخیره، بازیابی و پردازش کند.

تعریف داده:

تعریف اول- هر مجموعه‌ای از داشته ‌ها (دانستنیها)

تعریف دوم- نمایش ذخیره‌شده اشیاء فیزیکی، چیزهای مجرد، داشته‌ها، رویدادها یا چیزهای قابل مشاهده که در تصمیم‌سازی بکار می‌آیند.

تعریف سوم- دانستنیهای خام که معنای اندکی دارند؛ مگر اینکه به صورت منطقی سازمان‌دهی شده باشند.

تعریف چهارم (از دیدگاه ANSI) – نمایش پدیده‌ها، مفاهیم یا شناخته‌ها به طرزی صوری و مناسب برای برقراری ارتباط، تفسیر یا پردازش توسط انسان یا بطور خودکار

البته تعاریف دیگری هم برای داده ارائه شده است که به همین موارد اکتفا می­کنیم.

 

تعریف اطلاعات (اطلاع)

بطور خیلی ساده اطلاعات، داده پردازش‌شده است. یعنی بر خلاف داده خام، اطلاعات داده سازمان‌ یافته‌ای است که شناختی را منتقل می‌کند و برای تصمیم‌گیری نیز بکار می‌رود.

تعریف پایگاه داده‌ها (بانک اطلاعات)

مجموعه‌ای است از داده‌های ذخیره شده و پایا، به صورت مجتمع(یکپارچه) (نه لزوما فیزیکی، بلکه حداقل به طور منطقی)، بهم مرتبط، با کمترین افزونگی، تحت مدیریت یک سیستم کنترل متمرکز٫ پایگاه داده می­تواند مورد استفاده یک یا چند کاربر به طور همزمان و اشتراکی قرار گیرد.

تعریف سیستم مدیریت پایگاه داده‌ها (DBMS)

یک نرم‌افزار واسط بین محیط فیزیکی ذخیره و بازیابی اطلاعات و محیط منطقی برنامه‌سازی در سیستم بانک اطلاعات است که هرگونه ارتباط بین کاربر و داده را کاملا کنترل و مدیریت می­کند.

DBMS به کاربر امکان می‌دهد تا پایگاه داده‌های خود را تعریف کند، در پایگاه داده‌های خود عملیات انجام دهد و روی پایگاه داده‌های خود تا حدی کنترل داشته باشد.

پایگاه داده در مقابل فایل

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

اما روش دوم روش پایگاهی است. در این روش از پایگاه داده­ها جهت ذخیره و بازیابی داده­ها استفاده می­کنیم و عملیات خود را تحت کنترل یک سیستم مدیریتی قدرتمند بنام سیستم مدیریت بانک اطلاعات (DBMS) انجام می­دهیم.

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

برای روشن­تر شدن بحث، در ادامه مهمترین تفاوت­های این دو نوع سیستم ذخیره و بازیابی را شرح می دهیم.

معایب روش فایلینگ (پرونده ای) نسبت به روش پایگاهی

۱- عدم وجود محیط مجتمع ذخیره‌سازی اطلاعات و عدم وجود سیستم یکپارچه

در سیستم فایلینگ، یک ساختار واحد و یکپارچه برای ذخیره تمام فایل­های مورد نیاز وجو ندارد و فایلهایی که تعریف می­شوند، بصورت مجزا بر روی دیسک ذخیره می­شوند. اما در روش پایگاهی اطلاعات بصورت یکپارچه و مرتبط ذخیره می­شوند.

۲- افزونگی داده و عدم وجود سیستم کنترل متمرکز

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

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

برای مثال، یک نرم افزار اتوماسیون دانشگاه را در نظر بگیرید که شامل قسمتهای مختلف، مانند بخش آموزش، امور مالی و امور رفاهی است. هریک از این بخشها در یکی از قسمتهای دانشگاه توسط توسط کاربر جداگانه­ای استفاده می شود. واضح است که هریک از این بخشها نیاز دارند به اطلاعات دانشجویان دسترسی داشته باشند. بنابراین اگر از روش فایلینگ استفاده شود، یک فایل برای ذخیره اطلاعات دانشجویان در هریک از این بخشها نیاز است. پس هر بخش فایل اطلاعات دانشجویان را بصورت تکراری و نیز تعدادی فایل مربوط به خود دارد که فایلهای بخشهای مختلف ارتباطی با یکدیگر ندارند و تحت کنترل یک مدیریت واحد نیز قرار نمی­گیرند. اما در روش پایگاهی، اطلاعات دانشجو تنها یکبار ذخیره می­شود و کل اطلاعات سیستم نیز بصورت یکپارچه و تحت مدیریت کامل DBMS ذخیره می شوند. شکل ۱و۲ ارتباط بین برنامه کاربردی و داده­ها را در دو نوع سیستم نشان می دهند.

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

db1

db2

۳- عدم وجود ضوابط ایمنی کارا و مطمئن

یکی از نگرانی­های اصلی کاربر هنگامی که داده­های خود را در یک فایل معمولی ذخیره می­کند، بحث عدم امنیت داده­ها و امکان استفاده افراد غیر مجاز از داده­ها می­باشد.  سیستم­های مدیریت بانک اطلاعات، از قابلیتهای امنیتی قدرتمندی برخوردار است. امکان تعریف سطوح دسترسی مختلف برای کاربران مختلف بر روی هر بخشی از داده­ها و استفاده از روش­های رمزگذاری پیشرفته بر روی اطلاعات موجب می­شود که تنها راه استفاده از داده­های ذخیره شده بر روی دیسک از طریق DBMS باشد. در نتیجه امنیت اطلاعات در سطح بسیار بالایی تضمین می­شود.

همچنین بر خلاف سیستم فایل، سیستمهای مدیریت بانک اطلاعات معمولا از امکانات ویژه­ای جهت پشتیبان گیری داده­ها برخوردارند. عملیات پشتیبان گیری خودکار نیز معمولا وجود دارد تا در صورت بروز حادثه­ای که منجر به از بین رفتن اطلاعات یا خرابی داده­ها می­شود، نسخه­های پشتیبان را در اختیار داشته باشیم. همچنین در صورت خرابی داده­ها خود DBMS اقدام به ترمیم داده­ها می­کند که این کار با استفاده از داده­های پشتیبان و نیز فایل حاوی گزارش تراکنش­های صورت گرفته بر روی داده­ها (فایل log) صورت می­گیرد.

۴- خطر بروز پدیده ناسازگاری داده‌ها (عدم مدیریت تراکنش)

تراکنش به عملیاتی اطلاق می شود که می خواهد روی داده های بانک اطلاعات پردازشی انجام دهد. یکی از وظایف مهم DBMS مدیریت تراکنشها است بنحویکه چهار ویژگی اصلی زیر همواره برای تراکنشها حفظ شود:

- یکپارچگی (Atomicity): هر تراکنش می تواند خود از یکسری عملیات جزئی­تر تشکیل شده باشد. گاهی یک تراکنش در حالیکه تنها چند دستور اول آن اجرا شده، بدلیلی (مانند قطع برق) اجرای ادامه دستوراتش متوقف می­شود. در روش فایلینگ و حتی در پایگاه داده­های فاقد DBMS در چنین مواقعی داده ها دچار ناهمخوانی می شوند و عملا داده­ها نامعتبر می­گردند. برای مثال فرض کنیم در یک نرم افزار بانک دستوری را اجرا کرده­ایم که قرار است ۱۰۰۰۰ تومان از حسابی به حساب دیگر منتقل کند. در اینجا تراکنشی داریم که شامل ۲ عملیات اصلی است. اول کسر ۱۰۰۰۰ تومان از حساب اول و سپس افزودن آن به حساب دوم. حال اگر بعد از اجرای دستور اول و قبل از اینکه دستور دوم اجرا شود برق قطع شود، چه اتفاقی می­افتد؟ روشن است که اطلاعات ما دچار اشکال می شوند. اما DBMS با مکانیزمهای مطمئن خود تضمین می کند که یک تراکنش یا بطور جامع اجرا شود و یا اینکه اصلا اجرا نشود (در واقع تغییرات اعمال شده طوری خنثی گردد که گویی تراکنش اصلا اجرا نشده است).

- همخوانی (Consistency): اجرای صحیح یک تراکنش باید سیستم را همواره از یک حالت صحیح به حالت صحیح دیگری ببرد.

- انزوا (Isolation): اجرای همروند چند تراکنش نباید تاثیری روی یکدیگر داشته باشد. در واقع اجرای دو تراکنش بطور همروند همان نتایجی را باید داشته باشد که اجرای پشت سرهم آنها خواهد داشت.

- مانایی (Durability): نتایج اجرای یک تراکنش بر روی داده­ها نباید موقتی باشد و بایستی پایدار بماند.

۵- عدم امکان اشتراکی شدن داده‌ها

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

۶- حجم زیاد برنامه‌سازی

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

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

۷- وابستگی برنامه‌های کاربردی به محیط ذخیره‌سازی داده‌ها

قبل از توضیح این مطلب و بحث در مورد استقلال داده­ای در پایگاه داده، معماری سیستم پایگاه داده­ها را معرفی می­کنیم.

معماری پشنهادی ANSI برای پایگاه داده‌ها یک معماری سه لایه است. این سطوح در حقیقت به دیدهای مختلفی مربوط می­شود که بر روی پایگاه داده وجود دارد که شامل سه نوع دید داخلی، ادراکی و خارجی است.

دید خارجی

۱- دید یک کاربر خاص نسبت به داده‌های ذخیره‌شده در پایگاه داده است و بنابراین از کاربری به کاربر دیگر می تواند متفاوت باشد. بعنوان مثال در شکل ۲ دیدیم که سه نوع کاربر مختلف با سیستم اتوماسیون دانشگاه کار می کردند. با توجه به اینکه حیطه کاری هر کاربر متفاوت است، دیدی متفاوت نسبت به داده­ها دارد. در واقع دید هر کاربر یک دید جزئی روی بخشی از داده های بانک می باشد. به مجموع دید تمام کاربران، سطح خارجی بانک اطلاعات گفته می­شود.

 

دید ادراکی (مفهومی)

۱- دید طراح پایگاه داده‌ها نسبت به ساختار داده‌های ذخیره‌شده است. بر مبنای این دید است که طراح ساختارهای مورد نیاز برای داده­ها را تعریف و بانک اطلاعات را بوجود می­آورد. طراح بانک، دیدی کامل نسبت به ساختار کل بانک اطلاعات دارد و در حقیقت دید طراح جامع دید همه کاربران است. ساختار داده­ها در این سطح شمای ادراکی نامیده می­شود. سازنده شمای ادراکی طراح بانک اطلاعات است.

db3

دید داخلی

این دید در سطح فیزیکی و محیط ذخیره سازی مطرح می شود. در این سطح به داده­ها با دیدی سطح پایین­تر نگاه می­کنیم و مسائلی از قبیل شکل داده­های ذخیره شده بر روی دیسک، نحوه خوشه بندی، نوع شاخص­گذاری، روش رمزگذاری و … در این سطح مطرح است. ساختار داده­ها در این سطح شمای فیزیکی نامیده می شود که توسط DBMS ساخته می­شود.

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

استقلال داده‌ای

استقلال داده­ای یعنی وابسته نبودن برنامه‌های کاربردی به داده‌های ذخیره‌شده. برای ذخیره داده­ها در فایل، ابتدا ساختاری در خود برنامه تعریف می شود و سپس فایلی با این ساختار ساخته می­شود. در این حالت ساختار داده­ها از محیط برنامه مجزا نیست و هر تغییری در ساختار داده ناگزیر در داخل خود برنامه بایستی صورت گیرد. اما در سیستم بانک اطلاعات داده از برنامه جداست. ساختار داده­ها (همان شمای ادراکی) در محیط بانک اطلاعات تعریف می­شود. سپس از طریق برنامه با ساختارهای تعریف شده ارتباط برقرار می­گردد.

db4

انواع استقلال داده‌ای

- استقلال داده‌ای فیزیکی

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

- استقلال داده‌ای منطقی

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

نقطه ضعف سیستم پایگاه داده نسبت به سیستم پرونده ای:

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

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

برای برنامه نویسی بانک اطلاعات دو رده از زبانها مورد استفاده قرار می­گیرند:

۱) زبان میزبان (HL)

یکی از زبانهای برنامه‌سازی متداول مانند کوبول، PL1، فرترن، پاسکال، C، C# و زبانهایی مثل ADA، LISP، JAVA و نیز زبان اسمبلی است. پس زبان میزبان را از قبل می­شناسیم و چیز جدید و نامتعارفی نیست. اما تنها چیزی که ممکن است سوال برانگیز باشد این است که به چه دلیل در این مبحث به آنها زبان میزبان می­گوییم؟! جواب این سوال بعد از معرفی نوع دوم زبانهای کار با بانک اطلاعات مشخص خواهد شد.

همانطور که می­دانیم، زبان­های میزبان زبان­های خاص منظوره نیستند، بلکه معمولا زبانهای چند منظوره هستند. مثلا زبان C در زمینه­های مختلف از جمله برنامه نویسی سیستمی، برنامه نویسی گرافیکی، برنامه نویسی بانک اطلاعات و … کاربرد دارد.

زبان­های میزبان در دسته بندی زبانهای برنامه نویسی از دسته زبان­های رویه­ای می­باشند. دلیل این نامگذاری این است که برای هر عملیاتی که در این زبانها می خواهیم انجام دهیم، باید رویه انجام آنرا با جزئیات کامل ذکر کنیم.

۲) زبان داده‌ای فرعی (DSL)

زبان­هایی هستند که بر خلاف زبان­های میزبان تک منظوره هستند؛ یعنی فقط شامل دستوراتی برای کار با پایگاه داده می­باشند و اساسا به همین منظور ساخته شده­اند.

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

زبان­های DSL بر حسب نوع دستوراتشان سه نوع مختلف می­توانند باشند:

۱- زبان تعریف داده‌ها (DDL): این زبان­ها شامل دستورات لازم جهت تعریف و کار با ساختارهای داده­ای می­باشند.

۲- زبان عملیات روی داده‌ها (DML): این زبان­ها شامل دستوراتی هستند که برای کار با داده­های بانک اطلاعات استفاده می­شوند و به ساختار بانک اطلاعات کاری ندارند. عملیات اصلی DML عبارتند از: ورود داده جدید، ویرایش داده­های قبلا وارد شده، حذف داده­ها و بازیابی داده­ها.

۳- زبان کنترل داده‌ها (DCL): این زبان­ها شامل دستورات کنترلی هستند که برای کنترل صحت داده­ها، جامعیت عملیات روی داده­ها و … استفاده می­شوند.

البته برخی از زبان­های DSL نیز هستند که هر سه نوع امکانات را شامل می­شوند. SQL معروفترین و متداولترین زبان DSL است که شامل هر سه نوع این دستورات می­باشد.

حال باید ببینیم که آیا زبانهای DSL نیز مانند زبانهای میزبان محیط برنامه نویسی خاص خودشان را دارند یا نه. بر این اساس، زبانهای DSL به دو دسته تقسیم می­شوند:

۱- توکار (E.DSL): دستورات این ربانها بطور مستقل قابل اجرا نیست؛ بلکه باید برنامه ای به یک زبان میزبان نوشته شده باشد و در متن ن برنامه در جایی که نیاز هست، دستوری از زبان DSL (بصورت توکار) قرار داده شده باشد. مثل زبان Btrieve در C یا SQL در دلفی.

با این تعریف، دلیل نامگذاری زبانهای میزبان به این نام هم مشخص شد. در واقع این زبانها میزبان زبانهای DSL هستند.

۲- مستقل (I.DSL): این زبانها به زبان میزبان نیاز ندارد و به صورت مستقل استفاده می‌شوند. مثل زبان Foxpro که دارای یک محیط برنامه نویسی مستقل است و در آن می توان برنامه­های کاربردی بانک اطلاعات را بدون نیاز به زبان دیگری بوجود آورد.

البته برخی از زبانهای DSL هم هستند که می توانند به هردو صورت مستقل و توکار بکار روند.

زمانی که در یک برنامه زبان میزبان دستورات زبانهای DSL بصورت توکار استفاده شده، عمل کامپایل دستورات اصلی زبان میزبان و دستورات زبان DSL بصورت جداگانه توسط کامپایلرهای خاص هریک از این دو زبان انجام می­شود. اما در نهایت نتایج این دو عملیات کامپایل با هم تلفیق می­شوند تا برنامه بطور یکپارچه اجرا شود. مراحل کامپایل این نوع برنامه­ها در شکل *** نشان داده شده­است.

  db5

در شکل ** قسمتی از یک برنامه نوشته شده به زبان C# آورده شده است. کار این قطعه کد این است که اطلاعات ذخیره شده تمام دانشجویان را از بانک اطلاعات بازیابی کند. در خط سوم، یک دستور SQL در بطن دستور C# و در قالب یک رشته نوشته شده است. ساختار دستورات SQL در بخش ۵ بطور کامل مورد بحث قرار خواهد گرفت. در این مثال زبان میزبان C# و زبان DSL زبان SQL است که بصورت توکار استفاده شده است. برای تست کردن این برنامه­ها از لحظ نحوی، کامپایل کردن صرف کافی نیست. با توجه به اینکه دستور SQL بصورت رشته در یک زبان میزبان استفاده می­شود، در کامپایلر زبان میزبان تنها دستورات خود زبان بررسی می­شوند. اما با اجرای برنامه، دستور SQL به DBMS مربوطه ارسال می­شود تا در آنجا با استفاده ازکامپایلر خودش کامپایل و در صورت صحت، اجرا گردد.   

Conn.Open()   ;

DataTable  tbl  = new DataTable()  ;

SqlDataAdapter   da  =  new SqlDataAdapter(“Select * From Students”,conn) ;

Da.Fill(tbl);

Conn.Close();

اجزای DBMS

DBMS از قسمتهای مختلفی تشکیل می­شود که هر بخش وظیفه خاصی را انجام می­دهد. اصلی­ترین اجزای تشکیل دهنده DBMS عبارتند از:

  • DML Processor: این واحد دستورات DML (جهت تغییر در داده­ها) را که از سوی کاربران و برنامه ها ارسال می­شود، پردازش و کامپایل کرده و در صورت مجاز بودن و صحت دستورات آن را برای اجرا مهیا می­کند.
  • DDL Compiler: مشابه واحد قبلی است، اما برای زمانی که یک دستور DDL (جهت تعریف یک ساختار داده جدید در شمای ادراکی) از سوی کاربر ارسال می­شود و کامپایل دستور بر عهده این واحد است.
  • File Manager: این واحد با سطح فیزیکی بانک اطلاعات ارتباط دارد و وظیفه مدیریت فایلهایی را بعهده دارد که در سطح فیزیکی ذخیره می­شوند. همچنین یکی از ارکان اصلی در نگاشت داده­ها بین شمای ادراکی و داخلی است.
  • Database Manager: این قسمت بیشتر با لایه ادراکی بانک اطلاعات مرتبط است. در واقع نمایش اطلاعات ذخیره شده در قالب شمای ادراکی (در نگاشت بین شمای داخلی و ادراکی) و نمایش منطقی داده­ها و همچنین عملیات کنترلی مختلف روی بانک اطلاعات، مدیریت عملیات پشتیبان گیری و … را بعده دارد.
  • Query Processor: پردازنده پرس و جوهای کاربران است. بعبارت دیگر تنها پردازش دستوراتی را بعهده دارد که هیچ تغییری در ساختار بانک یا داده­ها بوجود نمی­آورند، بلکه صرفا برای بازیابی اطلاعات و گزارشگیری بکار می­روند.
  • Catalog Manager: وظیفه مدیریت و بروز رسانی اطلاعات موجود در بخش مهمی از پایگاه داده ها بنام کاتالوگ سیستم را بعهده دارد.

کاتالوگ سیستم شامل اطلاعات جامع در مورد سیستم پایگاه داده ها از قبیل حق دسترسی کاربران مختلف، مشخصات کاربران، تاریخ ایجاد و تغییر داده ها، سایز جداول و … است. دیکشنری داده­ها نیز جزئی از کاتالوگ سیستم است. دیکشنری داده ها شامل تمام نامهایی است که برای اشیاء مختلف در سیستم انتخاب می شود. به کاتالوگ سیستم اصطلاحا فراداده (متادیتا) گفته می شود؛ زیرا کاتالوگ سیستم شامل خود داده­های اصلی ما نیست، بلکه شامل اطلاعاتی است در مورد داده­های اصلی (فراداده یعنی داده در مورد داده)

هر تغییری که در ساختار و کلیات پایگاه داده ایجاد می­کنیم (مثلا هنگام تعریف یک کاربر جدید)، باید این تغییر در کاتالوگ سیستم ثبت شود. این وظیفه بعهده catalog manager می باشد.

نمای بیرونی (ساده‌شده) DBMS

db6


با توجه به قابلیتهایی که در این بخش برای DBMS ها برشمردیم، باید این نکته را نیز خاطرنشان سازیم که همه سیستم های پایگاه داده­ معروفی که تامنون تولید شده­اند، از یک سیستم مدیریتی قوی برخوردار نیستند؛ بلمه صرفا دارای یک رابط کاربر برای اجرای دستورات او بر روی داده­ها می­باشند. اما وظایف مهمی از قبیل کنترل جامعیت اجرای تراکنشها یا ایجاد امکان استفاده همزمان کاربران زیاد از داده­ها را انجام نمی­دهند. از معروفترین DBMS ها می­توان از MS SQL Server، MySQL و Oracle نام برد. اما پایگاه داده­های معروفی مانند Access و Foxpro در واقع DBMS نیستند و فقط یک سیستم بانک اطلاعاتی ساده تلقی می­شوند.

——————————————————————–

فصل دوم:

مدلسازی معنایی داده ها

 

داده‌هایی که قرار است در پایگاه داده ذخیره شوند، ابتدا باید با یک دید سطح بالا از لحاظ معنایی و مفهومی مدلسازی شوند. حاصل عملیات مدلسازی معنایی، ساختار منطقی بانک اطلاعات و در واقع همان شمای ادراکی است.

مدلها و روش­های مختلفی برای مدلسازی معنایی داده­ها وجود دارند که از معروفترین آنها می­توان از مدل موجودیت- ارتباط (ER)، مدل Niam، مدل زبان یکپارچه مدلسازی (UML) و تکنیک مدلسازی شیئی (OMT) نام برد.

مدل ER و نمودار ER

مدل ER در اواسط دهه ۸۰ میلادی در دانشگاه MIT توسط فردی بنام چن پیشنهاد شد. این مدل بمرور زمان پیشرفت کرد و کم کم به EER (ER توسعه یافته) معروف شد. اما هنوز هم در خیلی جاها با همان نام ER از آن نام برده می­شود. در این فصل به شرح کامل این مدل می پردازیم.

در مدل ER سه مفهوم اصلی وجود دارد که عبارتند از: موجودیت، صفت و ارتباط. نمودار ER هم نموداری است برای مدلسازی معنایی داده­ها بر پایه مدل ER و در واقع سه مفهوم اساسی مدل ER، یعنی نوع موجودیت، صفت و ارتباط را بصورت شماتیک نمایش می­دهد. قبل از هرچیز بهتر است با این سه مفهوم آشنا شویم.

 

تعریف موجودیت

مفهوم کلی شیئ، پدیده و به طور کلی هر آنچه که می‌خواهیم در موردش اطلاعاتی در بانک اطلاعات داشته باشیم و با استفاده از آن اطلاعات شناخت خود را در موردش افزایش دهیم.

بعنوان مثال، برای یک سیستم آموزشی که قرار است در یک دانشگاه استفاده شود، موجودیتهای دانشجو، استاد، دانشکده و درس را می­توان نام برد.

همانطور که می­بینیم موجودیت یک مفهوم کلی و یا یک نوع داده مجرد است. اما هر موجودیت می­تواند نمونه هایی داشته باشد. نمونه­های یک موجودیت، مصداق­های آن موجودیت هستند و در واقع نمونه­ها هستند که وجود خارجی دارند. بعنوان مثال، درس پایگاه داده­ها با یکسری ویژگی­های خاص خودش یک نمونه از موجودیت درس است.

اولین گام در مدلسازی معنایی بانک اطلاعات، شناسایی موجودیتهای مساله است. اما سوالی که ممکن است پیش بیاید این است که مثلا در مثال فوق، چرا خود دانشگاه را بعنوان یکی از موجودیتها در نظر نگرفتیم؟ یا بطور کلی بر چه اساسی اقدام به شناسایی موجودیتها می­کنیم؟

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

نکته دیگر در مورد موجودیتها این است که یک موجودیت معمولا بیش از یک ویژگی دارد که باید ذخیره شود. اما همانطور که خواهیم دید، این قانون همیشه صادق نیست.

در نمودار ER هر موجودیت در قالب یک مستطیل ساده نمایش داده می­شود.

 

موجودیت مستقل و وابسته

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

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

برای تمایز موجودیتهای وابسته از موجودیتهای مستقل، در نمودار ER موجودیتهای وابسته با دو خط نشان داده می­شوند.

 

تعریف صفت خاصه

خصیصه یا ویژگی یک نوع موجودیت است. هر نوع موجودیت مجموعه‌ای از صفات خاصه دارد. هر صفت یک نام، یک نوع و یک معنای مشخص دارد. در نمودار ER هریک از صفات خاصه یک موجودیت با یک بیضی نشان داده شده و به موجودیت متصل می­شوند.

انواع صفت خاصه

۱- صفت ساده یا مرکب

صفت ساده صفتی است که مقدار آن از لحاظ معنایی تجزیه‌نشدنی یا اتومیک است.

صفت مرکب صفتی است که از چند صفت ساده تشکیل شده است و به هر جزء آن بتوان بطور مستقیم دسترسی داشت.

صفت آدرس که خود شامل صفات جزئی­تر شهر، خیابان و … است، می­تواند یک صفت مرکب باشد، در صورتیکه ساختار آن در شمای ادراکی به­گونه­ای باشد که بتوان به این اجزا بطور مجزا و مستقیما دسترسی داشت. اما اگر ویژگی آدرس برای یک موجودیت بصورت یک رشته معمولی در نظر گرفته شود، دیگر یک صفت مرکب محسوب نمی­شود؛ چون دسترسی مستقیم به هر جزء آن نداریم.

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

۲- صفت تک‌مقداری یا چندمقداری

صفت تک‌مقداری، صفتی است که برای یک نمونه از یک نوع موجودیت حداکثر یک مقدار از دامنه مقادیر را می‌گیرد.

صفتی که برای بعضی از نمونه­های موجودیت ممکن است بیش از یک مقدار داشته باشد، یک صفت چندمقداری است. بعنوان مثال، صفت شماره دانشجویی، نام خانوادگی و … برای موجودیت دانشجو صفات تک مقداری محسوب می­شوند؛ چون هر دانشجو تنها یک نام خانوادگی و یک شماره دانشجویی دارد. اما صفتی مانند شماره تلفن برای موجودیت دانشجو یک صفت چند مقداری است. زیرا بعضی از دانشجویان بیش از یک شماره تلفن دارند.

نمایش صفات چندمقداری در نمودار ER بصورت زیر است.

در بانک اطلاعات رابطه­ای امکان تعریف صفات چندمقداری وجود ندارد. پس اگر بخواهیم صفتی چندمقداری مثل شماره تلفن داشته باشیم چه باید بکنیم؟ راه حل کلی برای این مساله این است که برای هر صفت چندمقداری جدولی جداگانه طراحی کنیم و کلید موجودیت اصلی (مثل دانشجو) را بعنوان کلید خارجی در آن قرار دهیم.

۳- صفت کلید یا غیرکلید

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

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

صفتی که قرار است بعنوان شناسه اصلی یک موجودیت (وجه تمایز اصلی بین نمونه­های موجودیت) استفاده شود بهتر است حتی الامکان طول مقادیرش کوتاه باشد.

در نمودار ER شناسه اول یک موجودیت با کشیدن یک خط و شناسه دوم با کشیدن دو خط در زیر عنوان آن مشخص می­شود.

گاهی اوقات، یک موجودیت صفت تکرار ناپذیری ندارد تا بعنوان کلید آن در نظر گرفته شود. یک راه برای حل این مشکل استفاده از کلیدهای ترکیبی است. یعنی باید ترکیبی از صفات را بیابیم که آن ترکیب بین نمونه­های آن موجودیت تکرار نشود. مثلا فرض کنیم موجودیت دانشجو اصلا صفاتی بنام شماره دانشجویی و کد ملی نداشت. در این حالت با این فرض که ترکیب سه صفت نام، نام خانوادگی و شماره شناسنامه بین دانشجویان امکان تکرار ندارد، می­توان ترکیب این سه صفت را بعنوان کلید موجودیت دانشجو معرفی کرد. به چنین کلیدهایی کلید ترکیبی گفته می­شود. روش نمایش کلیدهای ترکیبی در نمودار ER بصورت زیر است:

در فصل بعد، مفاهیم مربوط به کلید بطور کامل­­تر مورد بحث قرار خواهد گرفت.

۴- صفت هیچ‌مقدارپذیر یا ناپذیر

هیچ مقدار یعنی مقدار ناشناخته، مقدار غیرقابل اعمال یا مقدار تعریف نشده که معمولا با واژه Null نشان داده می­شود.

اگر مقدار یک صفت در یک یا بیش از یک نمونه از یک موجودیت، بتواند برابر با هیچ‌مقدار باشد، آن صفت هیچ‌مقدارپذیر است.

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

۵- صفت ذخیره‌شده یا مشتق

صفت ذخیره‌شده صفتی از یک موجودیت است که مقادیرش برای نمونه­های آن موجودیت در پایگاه داده‌ها ذخیره شود.

صفت مشتق، صفتی است که مقادیرش در پایگاه داده‌ها ذخیره نشده باشد، بلکه از روی داده‌های ذخیره شده قابل اشتقاق یا محاسبه باشد. بعنوان مثال، اگر تاریخ تولد هر دانشجو (بعنوان یکی از صفات خاصه) در سیستم ذخیره شود، دیگر نیازی به ذخیره صفت سن دانشجو نیست و این ویژگی با توجه به تاریخ تولد قابل محاسبه است. پس در اینجا تاریخ تولد یک صفت ذخیره شده و سن یک صفت مشتق است.

برای نمایش صفات مشتق در نمودار ER می توان یا بیضی مربوط به آن صفت و یا خط اتصال آن صفت به موجودیت را بصورت نقطه چین رسم کرد.

 

 

ارتباط

تعریف- تعامل و وابستگی بین دو یا بیش از دو نوع موجودیت است.

ارتباط بین دو موجودیت در حقیقت ارتباط بین نمونه­های آن دو موجودیت است. هر ارتباط دارای یک عنوان و یک مفهوم مشخص است. بعنوان مثال، بین دو موجودیت دانشجو و درس ارتباط “انتخاب” وجود دارد. یعنی نمونه­های موجودیت دانشجو، نمونه­هایی از موجودیت درس را انتخاب می­کنند.

در نمودار ER ارتباط با نماد لوزی نشان داده می­شود.

 

 

اگر نمونه­هایی از یک موجودیت بتوانند با نمونه­هایی از همان موجودیت ارتباط داشته باشند، باید یک ارتباط از موجودیت به خودش رسم شود. مثلا، بین نمونه­های موجودیت درس، ارتباط پیش نیازی برقرار است.

 

 

ماهیت ارتباط

چندی ارتباط یا بعبارتی نوع تناظر بین نمونه­های دو موجودیت حاضر در ارتباط را نشان می­دهد. ماهیت ارتباط می­تواند یک به یک (۱:۱)، یک به چند (۱:n) یا چند به چند (m:n) باشد.

ارتباط ۱:۱: هر نمونه از موجودیت اول می­تواند فقط با یک نمونه از موجودیت دوم ارتباط داشته باشد. هر نمونه از موجودیت دوم نیز فقط می­تواند با یک نمونه از موجودیت اول ارتباط داشته باشد. در واقع همان مفهوم تناظر یک بیک در نظریه مجموعه­ها است.

بعنوان مثال، اگر درجه ارتباط بین موجودیت­های دانشجو و درس ۱:۱ باشد (مطابق شکل زیر)، مفهوم ارتباط چنین است:

 

 

هر دانشجو می­تواند فقط یک درس را بگیرد. هر درس هم می­تواند فقط توسط یک دانشجو گرفته شود.

ارتباط ۱:n: هر نمونه از موجودیت اول می­تواند با چند نمونه از موجودیت دوم ارتباط داشته باشد. اما هر نمونه از موجودیت دوم فقط می­تواند با یک نمونه از موجودیت اول ارتباط داشته باشد.

اما اگر درجه ارتباط بین موجودیت­های دانشجو و درس ۱:n باشد (مطابق شکل زیر)، مفهوم ارتباط چنین است:

 

 

هر دانشجو می­تواند چند درس را بگیرد. اما هر درس می­تواند فقط توسط یک دانشجو گرفته شود.

ارتباط m:n: هر نمونه از موجودیت اول می­تواند با چند نمونه از موجودیت دوم ارتباط داشته باشد. هر نمونه از موجودیت دوم نیز می­تواند با چند نمونه از موجودیت اول ارتباط داشته باشد.

حال اگر درجه ارتباط بین موجودیت­های دانشجو و درس m:n باشد (مطابق شکل زیر)، مفهوم ارتباط چنین است:

 

 

هر دانشجو می­تواند چند درس را بگیرد. هر درس هم می­تواند توسط چند دانشجو گرفته شود.

روشهای نمایش دیگری نیز برای نشان دادن ماهیت ارتباط ها وجود دارد، از جمله ارتباط ۱:n فوق به اشکال زیر نیز نمایش داده می شود:

 

حد  ارتباط

برای هریک از موجودیت­های شرکت کننده در یک ارتباط می­توان یک حد مشخص کرد. این حد نشان دهنده حداقل و حداکثر تعداد نمونه­های آن موجودیت است که می توانند در ارتباط شرکت کنند.

بعنوان مثال، حدود نشان داده شده در شکل زیر برای دو موجودیت دانشجو و درس بیانگر مفاهیم زیر هستند:

هر دانشجو حداقل ۱ و حداکثر ۵ درس را می تواند انتخاب کند.

هر درس می تواند توسط هیچ دانشجویی انتخاب نشود و یا حداکثر توسط ۲۰ دانشجو انتخاب شود.

 

 

 

شرکت اجباری و اختیاری در ارتباط

موجودیتهایی که در یک ارتباط شرکت دارند، نوع ارتباطشان می­تواند اجباری یا اختیاری باشد. اگر مقدار حداقل حد یک موجودیت در یک ارتباط ۰ باشد، به این معنی است که نمونه ای از این موجودیت می تواند وجود داشته باشد که اصلا در ارتباط شرکت نکند. در این حالت شرکت موجودیت را اختیاری می­گوییم. در غیر اینصورت، شرکت موجودیت در ارتباط اجباری است.

اگر شرکت موجودیت دانشجو در ارتباط انتخاب درس اجباری و شرکت درس در این رابطه اختیاری باشد، این دو مفهوم به شکل زیر در نمودار این دو موضوع به شکل زیر در نمودار ER نشان داده می­شوند.

 

 

روش دیگر نمایش ارتباط اجباری با استفاده از دو خط است:

روش سومی هم برای نمایش شرکت اجباری و اختیاری موجودیتها وجود دارد و آن به شکل زیر است:

 

از نمادهای دایره و خط در این نوع نمایش می توان به ۰ و ۱ (بعنوان نقاط شروع حد ارتباط) تعبیر کرد.

 

نکته مهم:

در یک ارتباط ۱:n اگر نوع مشارکت موجودیت سمت n اجباری باشد، این موجودیت یک موجودیت وابسته است که وابستگی آن به موجودیت سمت ۱ است.

 

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

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

۱- بازاء هر موجودیت یک جدول طراحی می کنیم که ستونهای آن صفات خاصه موجودیت بوده و هر سطر آن یک نمونه از آن موجودیت است.

۲- هر ارتباط بین موجودیتها در نمودار ER بسته به ماهیت آن باید در جدائل لحاظ شود. طبق قوانین زیر:

- ارتباط ۱:۱: در این حالت می توان دو موجودیت را در قالب یک جدول ادغام کرد و نیازی به جدا کردن دو جدول نیست.

- ارتباط ۱:n : پس کلید اصلی موجودیت سمت ۱ را بعنوان کلید خارجی به جدول مربوط به موجودیت سمت n نیز اضافه می­کنیم.

- ارتباط m:n : برای برقراری ارتباط بین دو جدول، یک جدول دیگر بعنوان جدول واسط طراحی می کنیم. در این جدول واسط، کلیدهای اصلی مربوط به هر دو موجودیت بعنوان کلیدهای خارجی قرار می­گیرند.

پس همانگونه که می بینیم در ارتباط m:n خود ارتباط بین دو موجودیت نیز به یک موجودیت تبدیل می­شود. از اینرو گاهی در نمودار ER ارتباطهای m:n را به شکل یک موجودیت نمایش می دهند، مثلا:

 

چند مثال جامع:

 

مثال اول:

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

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

هریک از اجناس فروشگاه یک کد مشخصه، نام و قیمت دارد. (توجه شود که اجناس یک نمونه کد مشخصه یکسانی دارند.)

هر مشتری می تواند در هر بار خرید از برخی اجناس تعدادی را خریداری کند. بازای هر خرید یک فاکتور صادر می شود که دارای شماره و تاریخ است.

حل:

طراحی نمودار ER:

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

ماهیت ارتباط بین مشتری و فاکتور: برای هر مشتری می تواند در زمانهای مختلف چندین فاکتور ثبت شود. اما هر فاکتور مربوط به یک مشتری است. بنابراین ماهیت ارتباط ۱:n است.

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

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

بعد از رسم یک جدول برای هریک از موجودیتها،

- ارتباط بین مشتری و فاکتور ۱:n است. پس کلید اصلی مشتری (موجودیت سمت ۱) را بعنوان کلید خارجی به جدول فاکتور (موجودیت سمت n) نیز اضافه می­کنیم.

- ارتباط بین جنس و فاکتور m:n است. بنابراین برای برقراری ارتباط بین دو جدول، یک جدول دیگر بعنوان جدول واسط طراحی می کنیم. در این جدول واسط، کلیدهای اصلی مربوط به هر دو موجودیت فاکتور و جنس بعنوان کلیدهای خارجی قرار می­گیرند. این جدول نشان می دهد که چه فاکتوری (شماره فاکتور) شامل چه جنسی (کد جنس) بوده است. با قرار دادن صفت تعداد خریداری شده در این جدول مشخص می شود که چه فاکتوری شامل چه جنسی و به چه تعدادی بوده است.

برای کلید اصلی این جدول می توان از ترکیب دو صفت ش فاکتور و کد جنس استفاده کرد و یا از کلیدهای شماره گذاری اتوماتیک (Auto Increment Number) استفاده کرد.

db-er1

مثال دوم:

برای یک سیستم دانشگاه با مشخصات زیر یک نمودار ER طراحی کنید و سپس آنرا به بانک اطلاعات رابطه ای تبدیل کنید.

دانشگاه شامل تعدادی دانشکده است که هر دانشکده یک کد، نام، رئیس و یک سال تاسیس دارد.

در هر دانشکده تعدادی رشته دایر است که هر رشته شامل یک کد، یک نام و یک مقطع است.

در هر رشته تعدادی دانشجو تحصیل می­کنند که هر دانشجو دارای شماره دانشجویی، نام و نام خانوادگی است.

هر رشته تعدادی استاد دارد که البته بعضی از اساتید بین چند رشته مشترکند. هر استاد دارای کد، نام است.

در سرفصل هر رشته تعدادی درس تعریف شده که هر درس دارای کد، نام درس و تعداد واحد است. هر درس می تواند چندین پیش نیاز داشته باشد و یا پیش نیاز چندین درس دیگر باشد.

در هر ترم از هر درس چندین گروه درسی ارائه می شود که هر گروه یک کد مشخصه، یک شماره گروه و یک ساعت تشکیل دارد.

از دروس ارائه شده هر دانشجو چندین مورد را انتخاب می کند و در نهایت برای هرکدام نمره ای کسب می­کند.

db-ER

 


db-er-tables

 

 

اسلاید مدل رابطه ای

 

dbSession4 -  مدل رابطه ای

dbSession5 -  جبر رابطه‌ای

dbSession6 دستورات مربوط به اسکیما (DDL) - دستورات کار با داده ها (DML) - دستورات کنترلی (DCL)

dbSession7 -  دستورات مربوط به اسکیما (DDL)   - دستورات کار با داده ها (DML)

dbSession8 -  دستور Select

dbSession9  - دستورات Insert و Update

dbSession10 نرمال سازی (قسمت اول: وابستگی های تابعی)

dbSession11 -  نرمال سازی ( تبدیل جداول غیر نرمال به صورتهای نرمال اصلی )

 

با کلیک روی آگهی زیر مبلغ 400 ریال به حساب من واریز می گردد

با کلیک روی آگهی زیر مبلغ 1000 ریال به حساب من واریز می گردد