پشتیبانی: 09131253620
ارتباط با ما
تلگرام: 09131253620

برجسته ترین ها
گروه های مقاله ها
HyperLink


پایگاه داده رابطه ای بخش هجدهم تاریخ درج: ١٣٩۴/٠٩/٢۴

6- 8 طراحی پایگاه داده برای پروژه بانکداری

اکنون نگاه دقیقتری به الزمات طراحی پایگاه داده یک پروژه بانکداری می اندازیم ویک طرح واقعی ترونیز پیچیده تر از آنچه درنمونه های قبلی دیده ایم ایجاد می کنیم. بااین حال، سعی درمدل سازی تمام جوانب طراحی پایگاه داده برای یک بانک رانداریم، فقط برخی ازجنبه ها رابررسی می کنیم تافرایند طراحی پایگاه داده رانشان دهیم.
مادوحالت اصلی طراحی پایگاه داده رابکار می بریم- که شامل جمع آوری الزامات داده وطراحی چهارچوب مفهومی برای مثال ما، پروژه بانکداری، می شود. ازمدل داده E-R برای تبدیل الزامات کاربر   به چهارچوب مفهومی طرح استفاده می کنیم که به عنوان نمودار E-R نشان داده می شود.
سرانجام، نتیجه فرآیند طراحی E-R، یک چهارچوب پایگاه داده رابطه ای است. فرآیند ایجاد طرح رابطه ای باتوجه به طرح E-R رادربخش 6- 9 بررسی می کنیم.
قبل از شروع طراحی پایگاه داده پروژه بانکداری، جایگزین های طرح E-R که طراح پایگاه داده ممکن است ازمیان آنها چیزی انتخاب کند رابه طور خلاصه بیان می کنیم.

6-8-1 جایگزین های طرح E-R 
مدل داده E-R دارای انعطاف زیادی در طراحی چهارچوب پایگاه داده برای مدل سازی یک پروژه خاص است. ما در زیر توضیح می دهیم که چگونه یک طراح پایگاه داده ازمیان طیف وسیعی ازجایگزین ها دست به انتخاب می زند. بعضی از تصمیمات اتخاذ شده توسط طراح عبارتند از: 
برای نشان دادن یک شی از یک صفت استفاده کنیم یا از یک گروه موجودیت. (قبلاً در بخش 6-5-1 به آن پرداخته شد.) 
یک مفهوم در جهان واقعی توسط یک گروه موجودیت بطور مناسبتری بیان می شود یا توسط یک گروه یک رابطه. (بخش 6-5-2)
از یک رابطه سه طرفه استفاده کنیم یا یک زوج رابطه دو طرفه. (بخش6-5-3)
از یک گروه موجودیت قوی استفاده کنیم یا یک گروه موجودیت ضعیف. (بخش6-6)، یک گروه موجودیت قوی و گروههای موجودیت ضعیف تابع آن، ممکن است به عنوان یک شی منفرد در پایگاه داده تلقی شود زیرا گروههای موجودیت ضعیف، موجود وابسته  به یک موجودیت قوی هستند.
آیا کاربرد عمومی سازی صحیح است یا خیر. (بخش 6-7-2). عمومی سازی طبقه بندی روابط ISA، از طریق امکان دادن به نمایش صفات مشترک گروههای موجودیت مشابه در یک جایگاه از یک نمودار E-R، به پیمانه ای بودن   کمک می کند.
آیا کاربرد ترکیب مناسب یا خیر. (بخش 6-7-5) ترکیب، یک بخش از یک نمودار E-R را در داخل یک گروه موجودیت واحد دسته بندی می کند و به ما امکان می دهد که این گروه موجودیت ترکیبی را به عنوان یک گروه واحد بررسی کنیم بدون اینکه به جزئیات ساختار میانی آن توجه کنیم.
ما متوجه خواهیم شد که طراح پایگاه داده به شناخت صحیحی از پروژه مدل سازی شده نیاز دارد تا درباره طرح های مختلف مورد نیاز تصمیم گیری کند.

6-8-2 الزامات داده برای پایگاه داده بانک
ممکن است که جزئیات اصلی الزامات کاربر براساس مصاحبه هایی با کاربران پایگاه داده و تجزیه و تحلیل خود طراح از پروژه باشد. شرح حاصل از این حالت طراحی، اساس تشخیص ساختار مفهوم پایگاه داده است. خصوصیات اصلی پروژه بانکداری عبارتند از:
بانک به شعبه های مختلف تقسیم می شود. هر شعبه در یک شهر خاص واقع است و با یک نام خاص مشخص می شود. بانک، منابع هر شعبه را بررسی می کند.
مشتریان بانک با اعداد customer-id مشخص می شوند.که در بانک ممکن است حساب داشته باشند و می توانند وام بردارند. یک مشتری ممکن است به یک بانکدار خاص مرتبط شود که به عنوان یک کارمند وام دهنده یا یک بانکدار شخصی برای آن مشتری عمل     می کند.
کارمندان بانک با اعداد employee-id مشخص می شوند. مدیریت بانک نام و شماره تلفن هر کارمند، نام افراد تحت تکلف کارمند و شماره شناسایی کارمندی رئیس آن کارمند ذخیره می سازد. بانک همچنین اطلاعات تاریخ شروع کار آن کارمند و در نتیجه طول مدت استخدام کارمند را دارد.
بانک دو نوع حساب را ارائه می کند. حساب پس انداز و حساب جاری. حساب می تواند توسط بیش از یک مشتری کنترل شود و یک مشتری می تواند بیش از یک حساب داشته باشد. به هر حساب یک شماره حساب خاص داده می شود. بانک یک گزارش از تراز حساب هر مشتری و آخرین تاریخی که مشتری صاحب حساب به حساب خود مراجعه کرده است را نگه می دارد. به علاوه، هر حساب پس انداز دارای یک نرخ سود است و برداشت از یک موجودی هم برای حساب جاری ثبت می شود.
یک وام از شعبه خاصی شروع می شود و می تواند توسط یک یا چند مشتری برداشته شود. یک وام با یک شماره خاص مشخص می شود. بانک برای هر وام اطلاعات مقدار وام و بازپرداخت های وام را نگه می دارد. اگر چه شماره بازپرداخت یک وام، یک باز پرداخت خاص را در بین بازپرداخت ها برای همه وام های آن بانک مشخص نمی کند، اما این شماره یک بازپرداخت خاص برای یک وام خاص را نشان می دهد. تاریخ و مقدار برای هر بازپرداخت ثبت می شود.
در یک پروژه بانکداری واقعی، بانک اطلاعات سپرده ها و برداشت ها از حساب جاری و پس انداز را نگه می دارد و نیز اطلاعات بازپرداخت ها به حساب های وام را نگه می دارد. از آنجائیکه الزامات مدل سازی برای آنها مشابه است و ما نیز می خواهیم کاربرد عملی این مثال را، جزئی و کوچک نگه داریم، اطلاعات چنین سپرده ها و برداشت هایی را در مدل خود حفظ نمی کنیم.

6-8-3 گروههای موجودیت برای پایگاه داده بانک
اطلاعات دقیق ما از الزامات داده، نقطه شروع برای ایجاد چهارچوب مفهومی برای پایگاه داده است از ویژگی های موجود در بخش 6-8-2 شروع به مشخص کردن گروههای موجودیت و صفات آنها می کنیم.
گروه موجودیتbranch با صفات نام شعبه، شهر شعبه و منابع آن .
گروه موجودیت customer با صفات شماره شناسایی مشتری ، نام مشتری، نام خیابان مشتری و نام شهر مشتری. یک صفت احتمالی دیگر نام بانکدار  است.
گروه موجودیت کارمند با صفات employee-id، employee-name، telephone-number، salary و manager . ویژگی های توصیفی دیگر عبارتند از صفات چند مقداری نام افراد تحت تکلف ، صفت مهم تاریخ شروع  و صفات حاصل از آن و مدت استخدام .
گروه موجودیت دو حساب – حساب پس انداز  و حساب جاری با صفات مشترک شماره حساب و تراز، به علاوه حساب پس انداز دارای صفت نرخ سود و حساب جاری دارای صفت  overdraft-amountاست.
گروه موجودیت وام با صفات شماره وام، حساب  و شعبه مبدأ  .
گروه موجودیت ضعیف بازپرداخت وام  با صفات شماره بازپرداخت، تاریخ بازپرداخت   و مقدار بازپرداخت .

6-8-4 گروههای رابطه برای پایگاه داده بانک
اکنون به برنامه طرح اصلی در بخش 6-8-3 بر می گردیم و گروههای رابطه زیر را مشخص می کنیم و قسمت های مشترک را تعیین می کنیم. در این فرایند همچنین بعضی از تصمیمات پیشین را در مورد صفات گروههای موجودیت اصلاح می کنیم.
Borrower  ، یک گروه رابطه چند به چند بین customerو loan
Loan- payment، یک رابطه یک به چند از loan به payment که دقیقاً ثبت می کند که یک بازپرداخت برای یک وام صورت گرفته است.
Depositor، باصفت رابطه access-date ، یک گروه رابطه چند به چند بینcustomerوaccess ، نشان می دهد که یک مشتری صاحب یک حساب است.
Cust-banker، باصفت رابطه type ، یک گروه رابطه چند به یک که نشان می دهد یک مشتری می تواند با یک کارمند بانک مشاوره کند و اینکه یک کارمند می تواند به یک یا بیش از یک کارمند مشاوره دهد. توجه داشته باشید که این گروه رابطه جایگزین صفت  banker-name از گروه موجودیت customer شده است.
Works-for، گروه رابطه بین موجودیت های employee با نقش نشانگرهای manager وworker طرح کاردینالیتی ها نشان می دهد که یک کارمند، فقط برای یک رئیس کار می کند ونیز یک رئیس بر یک یا بیش از یک کارمند نظارت می کند. توجه داشته باشید که این گروه رابطه جایگزین صفت manager در گروه employee       می شود.

6-8-5 نمودار E-R برای پایگاه داده بانک
با استفاده از توضیحات بخش 6-8-4، اکنون نمودار E-R کامل شده برای پروژه بانکداری در این مثال ارائه می کنیم. بیان می شود. نمودار شامل گروههای موجودیت، صفات، گروههای رابطه و طرح کاردینالیتی ها که در طی فرآیند طراحی در بخشهای 6-8-2و6-8-3 بیان شده و در  بخش 6-8-4 اصلاح شد.
نمودار E-R برای دیدگاه ساده ما از پروژه بانکداری کاملاً پیچیده است. نمودار E-R برای پروژه های واقعی را نمی توان روی یک صفحه کشید و باید به چندین قسمت تقسیم شود. موجودیت ها احتمالاً چندین بار در قسمت های مختلف نمودار ظاهر می شوند. صفات موجودیت دریک حضور موجودیت (ترجیحاً اولین حضور) نشان داده می شود و تمام حضورهای دیگر موجودیت بدون صفت نشان داده       می شود.

6-9 تبدیل شدن به الگوی رابطه ای
ما می توانیم یک پایگاه داده ارائه کنیم که منطبق بر یک چهار چوب پایگاه داده E-R توسط مجموعه چهار چوب های ارتباطی است. هر گروه موجودیت ونیز گروه رابطه در پایگاه داده دارای یک چهار چوب ارتباطی خاص هستند که نام گروه موجودیت و گروه رابطه مربوط به آن را منتقل می کند.
هر دو مدل E-R و مدل پایگاه داده رابطه ای، تصاویر مجرد و منطقی از پروژه های دنیای واقعی هستند. از آنجائیکه هر دو مدل، اصول طراحی مشابهی را بکار برند طرح E-R رامی توان به یک برنامه رابطه ای تبدیل کرد.
در این بخش توضیح می دهیم که چگونه می توان یک برنامه E-R را توسط برنامه رابطه ارائه داد ونیز چگونه محدودیت های ناشی از طرح E-R رامی توان به محدودیت های یک برنامه رابطه متصل کرد.
شکل 6-25 نمودار E-R برای پروژه بانکداری
 
شکل 6-25 نمودار E-R برای پروژه بانکداری

6-9-1 ارائه گروههای موجودیت قوی
فرض کنیم E یک گروه موجودیت قوی با صفات توصیفی an..., a2, a1 باشد. را با الگویی به نام E با n خصوصیات مجزا ارائه می کنیم. هر چندگانه در یک رابطه در این برنامه منطبق بر یک موجودیت از گروه موجودیت E می باشد. (نحوه کنترل خصوصیات ترکیبی و چند مقداری را بخش 6-9-4 توضیح    می دهیم.)
در مورد برنامه های ناشی از گروههای موجودیت قوی، اصول اولیه گروه موجودیت به عنوان اصول اولیه برنامه حاصله مفید و مناسب است. این موضوع نتیجه مستقیم این حقیقت است که هر چندگانه بر یک موجودیت خاص در گروه موجودیت منطبق است.
به عنوان نمونه، به گروه موجودیت loan از نمودار E-R در جدول 6-7 توجه کنید. این گروه موجودیت دارای دو صفت loan-number و amount است. این گروه موجودیت با برنامه ای به نام loan با دو صفت ارائه می دهیم:
Loan= (loan-number , amount)

amount

Loan-number

 

 

900

L-11

1500

L-14

1500

L-15

1300

L-16

1000

L-17

2000

L-23

500

L-93

شکل 6-26 جدول چندگانه loan
 
توجه داشته باشید که از آنجائیکه loan-number، کلید اولیه گروه موجودیت است، پس کلید اولیه الگوی رابطه هم هست.
یک رابطه با این الگودر شکل 6-26 نشان داده شده است. چندگانه  (L-17,1000) به این معنی است که شماره وام L-17 دارای وامی به مقدار 1000 دلار است، با وارد کردن یک چندگانه به رابطه مربوطه، می توان یک موجودیت جدید به پایگاه داده اضافه نمود. همچنین می توان با اصلاح چندگانه مربوطه، موجودیت ها را حذف و یا تعدیل نمود.

6-9-2 ارائه گروههای موجودیت ضعیف
فرض کنیم که A یک گروه موجودیت ضعیف با صفات a1,a2,…,am است و B گروه موجودیت قوی است که A وابسته به آن است. کلید اولیه B شامل صفات b1,b2,…,bn است. گروه موجودیت A را یک الگوی رابطه به نام A با یک صفت برای هر عضو گروه ارائه می کنیم.
{ a1,a2,…,am}U{ b1,b2,…,bn}
برای برنامه هایی که نتیجه یک موجودیت ضعیف هستند، ترکیب کلید اولیه گروه موجودیت قوی و شاخص گروه موجودیت ضعیف، به عنوان کلید اولیه برنامه استفاده می شوند. علاوه بر ایجاد کلید اولیه، ما همچنین محدودیت کلید خارجی در رابطه A را ایجاد می کنیم که مشخص می کند که خصوصیات bn..., b2, b1 کلید اولیه رابطه B را فراهم می کند. محدودیت کلید خارجی ثابت می کند که برای هر چندگانه که نشانگر یک موجودیت ضعیف است، یک چندگانه مشابه وجود دارد که یک موجودیت قوی را نشان
 می دهد.
به عنوان نمونه، گروه موجودیت payment در نمودار E-R از جدول 6-19 را مشاهده کنید. این گروه موجودیت سه صفت دارد: payment-number و payment-dateو payment-amountکلید اولیه گروه موجودیت loan که payment به آن وابسته است، loan-number می باشد. بنابراین، payment را با یک الگو با چهار صفت ارائه می کنیم.
Payment = ( loan-number, payment-number, payment-date, payment-amount)
کلید اولیه شامل کلید اولیه loan همراه با شاخص payment که payment-number است    می باشد. ما همچنین محدودیت کلید خارجی را در برنامه payment همراه با صفت loan-number که مرتبط کننده کلید اولیه برنامه loan است، ایجاد می کنیم.
 

تگها: پایگاه داده   پایگاه داده رابطه ای   پروژه بانکداری   جبر رابطه ای   حساب رابطه ای   
 

HyperLink

ارسال نظر در مورد این مطلب
نام :  
آدرس ایمیل :  
متن پیام :  
کد امنیتی :  
   
   
نظری برای نمایش وجود ندارد
 
این مطلب را به اشتراک بگذارید: